Patent Description:
Wireless communication systems are widely deployed to provide various types of communication; for instance, voice and/or data can be provided via such wireless communication systems. A typical wireless communication system, or network, can provide multiple users access to one or more shared resources (e.g., bandwidth, transmit power,. For instance, a system can use a variety of multiple access techniques such as Frequency Division Multiplexing (FDM), Time Division Multiplexing (TDM), Code Division Multiplexing (CDM), Third Generation Partnership Project (3GPP) Long-Term Evolution (LTE) systems, Orthogonal Frequency Division Multiplexing (OFDM), and others.

Generally, wireless multiple-access communication systems can simultaneously support communication for multiple mobile devices. Each mobile device can communicate with one or more base stations via transmissions on forward and reverse links. The forward link (or downlink) refers to the communication link from base stations to mobile devices, and the reverse link (or uplink) refers to the communication link from mobile devices to base stations. This communication link can be established via a single-in-single-out, multiple-in-single-out, or a multiple-in-multiple-out (MIMO) system.

For instance, a MIMO system can employ multiple (NT) transmit antennas and multiple (NR) receive antennas for data transmission. A MIMO channel formed by the NT transmit and NR receive antennas can be decomposed into NS independent channels, which are also referred to as spatial channels, where NS ≤ min{NT, NR}. Each of the NS independent channels can correspond to a dimension. The MIMO system can provide improved performance (e.g., higher throughput and/or greater reliability) if the additional dimensionalities created by the multiple transmit and receive antennas are utilized.

A MIMO system can support a time division duplex (TDD) and frequency division duplex (FDD) systems. In a TDD system, the forward and reverse link transmissions can be on the same frequency region so that the reciprocity principle allows the estimation of the forward link channel from the reverse link channel. This can enable the access point to extract transmit beamforming gain on the forward link when multiple antennas are available at the access point.

Wireless communication systems oftentimes employ one or more base stations that provide a coverage area. A typical base station can transmit multiple data streams for broadcast, multicast and/or unicast services, wherein a data stream may be a stream of data that can be of independent reception interest to a mobile device. A mobile device within the coverage area of such base station can be employed to receive one, more than one, or all the data streams carried by the composite stream. Likewise, a mobile device can transmit data to the base station or another mobile device.

Typically, mobile devices utilize power (e.g., battery power) while turned on as well as during periods of communication with a base station and/or other mobile devices via the base station. The amount of power consumed by a mobile device can depend in part on the configuration of the mobile device and/or function (e.g., operation) being performed by the mobile device. Reducing the amount of power utilized by a mobile device is desirable as such reduction can result in extended battery life and decreased cost to use the mobile device and battery. <CIT> describes an arrangement in which a mobile device transitions between different modes based on explicit signalling. <CIT> describes a device switching between a dormant mode and a traffic channel mode.

According to the present invention, a method operable on a mobile device for transitioning the mobile device from a first non-DRX mode to a second DRX mode as set forth in claim <NUM>, a wireless communication mobile device as set forth in claim <NUM> and a machine readable medium as set forth in claim <NUM> are provided. Embodiments of the invention are claimed in the dependent claims.

Various embodiments are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It may be evident, however, that such embodiment(s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing one or more embodiments.

As used in this application, the terms "component," "module," "system," and the like can refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components can communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).

Furthermore, various embodiments are described herein in connection with a mobile device. A mobile device can also be called a system, subscriber unit, subscriber station, mobile station, mobile, remote station, remote terminal, access terminal, user terminal, terminal, wireless communication device, user agent, user device, or user equipment (UE). A mobile device can be a cellular telephone, a cordless telephone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device having wireless connection capability, computing device, or other processing device connected to a wireless modem. Moreover, various embodiments are described herein in connection with a base station. A base station can be utilized for communicating with mobile device(s) and can also be referred to as an access point, Node B, or some other terminology.

Moreover, various aspects or features described herein can be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer-readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips, etc.), optical disks (e.g., compact disk (CD), digital versatile disk (DVD), etc.), smart cards, and flash memory devices (e.g., EPROM, card, stick, key drive, etc.). Additionally, various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, without being limited to, wireless channels and various other media capable of storing, containing, and/or carrying instruction(s) and/or data.

Referring now to <FIG>, a wireless communication system <NUM> is illustrated in accordance with various embodiments presented herein. System <NUM> comprises a base station <NUM> that can include multiple antenna groups. For example, one antenna group can include antennas <NUM> and <NUM>, another group can comprise antennas <NUM> and <NUM>, and an additional group can include antennas <NUM> and <NUM>. Two antennas are illustrated for each antenna group; however, more or fewer antennas can be utilized for each group. Base station <NUM> can additionally include a transmitter chain and a receiver chain, each of which can in turn comprise a plurality of components associated with signal transmission and reception (e.g., processors, modulators, multiplexers, demodulators, demultiplexers, antennas, etc.), as will be appreciated by one skilled in the art.

Base station <NUM> can communicate with one or more mobile devices such as mobile device <NUM> and mobile device <NUM>; however, it is to be appreciated that base station <NUM> can communicate with substantially any number of mobile devices similar to mobile devices <NUM> and <NUM>. Mobile devices <NUM> and <NUM> can be, for example, cellular phones, smart phones, laptops, handheld communication devices, handheld computing devices, satellite radios, global positioning systems, PDAs, and/or any other suitable device for communicating over wireless communication system <NUM>. As depicted, mobile device <NUM> is in communication with antennas <NUM> and <NUM>, where antennas <NUM> and <NUM> transmit information to mobile device <NUM> over a forward link <NUM> and receive information from mobile device <NUM> over a reverse link <NUM>. Moreover, mobile device <NUM> is in communication with antennas <NUM> and <NUM>, where antennas <NUM> and <NUM> transmit information to mobile device <NUM> over a forward link <NUM> and receive information from mobile device <NUM> over a reverse link <NUM>. In a frequency division duplex (FDD) system, forward link <NUM> can utilize a different frequency band than that used by reverse link <NUM>, and forward link <NUM> can employ a different frequency band than that employed by reverse link <NUM>, for example. Further, in a time division duplex (TDD) system, forward link <NUM> and reverse link <NUM> can utilize a common frequency band and forward link <NUM> and reverse link <NUM> can utilize a common frequency band.

Each group of antennas and/or the area in which they are designated to communicate can be referred to as a sector of base station <NUM>. For example, antenna groups can be designed to communicate to mobile devices (e.g., <NUM>) in a sector of the areas covered by base station <NUM>. In communication over forward links <NUM> and <NUM>, the transmitting antennas of base station <NUM> can utilize beamforming to improve signal-to-noise ratio of forward links <NUM> and <NUM> for mobile devices <NUM> and <NUM>. Also, while base station <NUM> utilizes beamforming to transmit to mobile devices <NUM> and <NUM> scattered randomly through an associated coverage, mobile devices in neighboring cells can be subject to less interference as compared to a base station transmitting through a single antenna to all its mobile devices.

In accordance with an aspect, a mobile device (e.g., <NUM>) can be configured so that such mobile device can transition (e.g., switch) between different modes, such as deep sleep (DS) mode, light sleep (LS) mode, and/or continuous reception (CRX) mode based in part on predefined sleep mode criteria. In one aspect, the mobile device (e.g., <NUM>) can have cycles (e.g., discontinuous transmission (DTX)) where each cycle can include an "on" period where the mobile device can monitor transmissions from the base station <NUM> and/or an "off' period where the radio frequency (RF) generation can be turned off in the mobile device to facilitate reducing power consumption. The length of a particular cycle associated with a particular mode can be based in part on the total length of a respective "off' period combined with a respective "on" period within the cycle. Thus, for example, since the "off' period associated with DS mode can be longer than the "off' period associated with LS mode, the DRX cycle for DS mode can be longer in length than the DRX cycle for LS mode. In one aspect, the DS mode can have a cycle (e.g., DRX cycle) with a specified "off' period associated with discontinuous reception (DRX) that can be longer than the specified "off' period for a cycle associated with the LS mode or the specified "off" period for a cycle associated with the CRX mode (e.g., which can have its "off' period set to <NUM>) to facilitate reducing power consumption (e.g., reduce use of battery power). During the "off' period, the mobile device (e.g., <NUM>) can turn off (e.g., deactivate) its RF generation (for example, where there is also a discontinuous transmission (DTX) period as well), where during the "off' period the mobile device is not able to receive data or control information, in order to facilitate reducing power consumption. The DS mode also can have a specified "off' period associated with DTX that can be longer than the "off' period associated with the LS mode or the CRX mode (e.g., which can have its "off' period set to <NUM>) to facilitate reducing power consumption. The DS mode can further have a specified "on" period of time during a cycle, where the "on" period can occur less frequently than an "on" period for the LS mode, and where the mobile device (e.g., <NUM>) can receive certain information (e.g., control information) during such "on" periods. The DS mode can also have a specified "on" period of time during a DTX cycle. While in DS mode, the mobile device (e.g., <NUM>) is not able to transmit data via the data channel, but can receive and/or transmit control information via the control channel during the "on" period (e.g., "on" intervals). In order to exchange data with the base station <NUM>, the mobile device (e.g., <NUM>) has to transition out of DS mode to either LS mode or CRX mode.

The LS mode can have a different cycle than the DS mode, as the "off" period associated with DRX, as compared to the DS mode, can be a shorter length of time than the "off'period associated with DRX of the DS mode. The LS mode also can have a defined "off" period associated with DTX that can be shorter than the "off" period associated with DTX of the DS mode. The LS mode can further have a defined "on" period of time related to DRX, which can occur more frequently than the "on" periods for the DS mode (but can occur less frequently than the CRX mode, which can be "on" continuously to receive information), where data and/or control information can be received during such non-DRX slots. The LS mode can have a defined "on" period of time associated with DTX. While in LS mode, the mobile device (e.g., <NUM>) can transmit and/or receive data via the data channel and/or control information via the control channel. In the LS mode, the mobile device (e.g., <NUM>) can facilitate reducing power consumption, although the reduction in power consumption typically will not be as great as the reduction in power consumption while in the DS mode.

In the CRX mode, the mobile device (e.g., <NUM>) can be in a state where it is "on" (e.g., in non-DRX mode) at all times while in such mode, and is able to receive data and/or control information. That is, in the CRX mode, the "off" period can be set to <NUM> so that there is no "off period" during a cycle. In accordance with an embodiment, the CRX mode (e.g., non-sleep mode) can be considered a special mode associated with the LS mode, where, for the CRX mode, the "off" period can be set to <NUM>, where the cycle can be made up of a series of "on" slots, for example, so that the mobile device (e.g., <NUM>) can be in an "on" state continuously. Thus, the LS mode can be configured so that the "off" period is set to <NUM>, and the mobile device (e.g., <NUM>) can be in an "on" state continuously. While in the CRX mode, the mobile device (e.g., <NUM>) typically can consume more power than when the mobile device is in the LS mode or DS mode.

The length of an "off' period (e.g., respectively associated with DRX and DTX) can be configurable, as desired, and can range from <NUM>, which can be associated with the CRX mode, for instance, to a desired number of seconds (e.g., <NUM> seconds), where the length of the "off' period typically can be larger for DS mode than LS mode. The length of an "on" period (e.g., respectively associated with DRX and DTX) can be configurable, as desired, and can range from <NUM> to more than <NUM>. The respective lengths of an "off' period and/or an "on" period can be based in part on the type of mode (e.g., DS mode, LS mode, CRX mode). The base station <NUM> can schedule and/or process data transmissions between the base station <NUM> and the mobile device (e.g., <NUM>) when the mobile device is in an "on" period (e.g., "on" slot), except that while in DS mode the mobile device (e.g., <NUM>) cannot exchange data with the base station <NUM>, but can exchange control information with the base station <NUM>.

Each of the DS mode, LS mode, and CRX mode can be further configured based in part on respective CQI attributes, respective sounding reference signal (SRS) attributes, respective measurement events, and/or respective timer values, where the timer values can be utilized to facilitate determining when the mobile device (e.g., <NUM>) is to transition from one mode to another mode. For example, CQI attributes can be configured or updated based in part on type of sleep mode, or transition from one sleep mode to another sleep mode.

With regard to the predefined sleep mode criteria, such criteria can relate to, for example, an explicit signal (e.g., control message) from the base station <NUM> indicating and/or directing the mobile device (e.g., <NUM>) to transition from one mode to another mode (e.g., from LS mode to DS mode), but in the embodiment an implicit signal is used (e.g., lack of data communication associated with the mobile device for a predetermined period of time or more). The mobile device (e.g., <NUM>) monitors and analyzes received information, such as control messages, data messages, and/or information regarding the length of time between events (in particular receiving or sending a data transmission or control information), and/or the type of events that occur, and can control the selection of, and/or the switching between, the different modes based in part on the predefined sleep mode criteria. The mobile device (e.g., <NUM>) also tracks the length of time between events to facilitate determining whether the predetermined period of time has elapsed between particular events so as to trigger a transition from one mode to another mode. The mobile device (e.g., <NUM>) can transition to LS mode or DS mode based in part on the predefined sleep mode criteria to facilitate reducing power consumption. As a result, the mobile device (e.g., <NUM>) can facilitate reducing power consumption as compared to conventional mobile devices.

In one aspect, when the mobile device (e.g., <NUM>) is in DS mode, an implicit signal to transition from DS mode to the LS mode can include receiving information regarding a downlink data transmission, such as a scheduling of a downlink data transmission from the base station <NUM> to the mobile device (e.g., <NUM>), or accessing or scheduling an uplink data transmission (e.g., scheduled uplink transmission), and upon the occurrence of any of the aforementioned events, the predefined sleep mode criteria can indicate that the mobile device is to transition from DS mode to LS mode. The mobile device (e.g., <NUM>) can transition from DS mode to LS mode upon the occurrence of any such event(s) based in part on the predefined sleep mode criteria.

If in the DS mode, a mobile device (e.g., <NUM>) can still transmit uplink control signals at predefined time instances (e.g., during "on" periods). The mobile device (e.g., <NUM>) can also remain in DS mode if it receives "special" control information via the control channel (e.g., PDCCH). For example, while in the DS mode, the mobile device (e.g., <NUM>) can receive power control information, Layer <NUM> (e.g., physical layer)/Layer <NUM> (e.g., data link layer) (L1/L2) control channel message, or Up/Down commands. For instance, when the mobile device (e.g., <NUM>) receives information, the mobile device (e.g., <NUM>) can signal to the base station <NUM> that only the L1/L2 control is successfully decoded (e.g., where the downlink data transmission is not successfully decoded), and the signal can be a negative acknowledgement (NAK); or the mobile device can signal that both the L1/L2 control and scheduled downlink (e.g., of data) are successfully decoded, which can be an acknowledgement (ACK).

In the embodiment an implicit signal is used such that, while the mobile device (e.g., <NUM>) is in the LS mode, if the mobile device does not exchange (e.g., transmit and/or receive) data with the base station <NUM> for a predetermined amount of time, the predefined sleep mode criteria can specify that the mobile device is to transition from LS mode to DS mode, and the mobile device can switch from the LS mode to the DS mode, to facilitate reducing power consumption in the mobile device. The mobile device (e.g., <NUM>) can be configured such that the implicit signals for the transitions from DS mode to LS mode, and from LS mode to DS mode, associated with the DRX can correspond with or be constrained with the transitions from DS mode to LS mode, and from LS mode to DS mode, associated with the DTX, or the transitions respectively associated with the DRX and DTX can be configured without regard to the other. Where the mobile device (e.g., <NUM>) is accessing in DS mode associated with DRX, the mobile device typically is not able to transition out of DS mode until it receives implicit or explicit confirmation regarding access from the base station <NUM>.

In the embodiment an implicit signal relates to transitioning between CRX mode and LS mode. While the mobile device (e.g., <NUM>) is in the CRX mode, if the mobile device (e.g., <NUM>) does not exchange (e.g., transmit and/or receive) data with the base station <NUM> for a predetermined amount of time, the predefined sleep mode criteria can specify that the mobile device is to transition from CRX mode to LS mode, and the mobile device can switch from the CRX mode to the LS mode, to facilitate reducing power consumption in the mobile device.

With regard to explicit signal, an explicit signal can include a L1/L2 control message, and/or an L1/L2 control message and a scheduled downlink of data (e.g., L1/L2 control channel + DL SCH), sent from the base station <NUM> to the mobile device (e.g., <NUM>), where the predefined sleep mode criteria can provide that upon receiving such explicit signal, the mobile device is to transition from DS mode to LS mode (e.g., with regard to DRX and/or DTX), and the mobile device can transition from DS mode to LS mode. An explicit signal can be generated by the base station <NUM> and sent to the mobile device (e.g., <NUM>), for instance, when the base station <NUM> knows that there will be no data exchanges, and/or there has been no data exchanges, between the base station <NUM> and the mobile device for a predefined period of time based in part on the predefined sleep mode criteria. The base station <NUM> also can track the amount of time that has elapsed between data exchanges with the mobile device (e.g., <NUM>) to facilitate determining whether a predefined period of time has elapsed between data exchanges.

As another example of an explicit signal, an explicit signal can also include a L1/L2 control message, and/or an L1/L2 control message and a scheduled downlink of data, sent from the base station <NUM> to the mobile device (e.g., <NUM>), where the predefined sleep mode criteria can provide that upon receiving such explicit signal, the mobile device is to transition from LS mode to DS mode (e.g., with regard to DRX and/or DTX), and the mobile device can transition from LS mode to DS mode.

Another example of an explicit signal can relate to transitioning from/to CRX mode to/from LS mode or DS mode. Such an explicit signal can include a L1/L2 control message, and/or an L1/L2 control message and a scheduled downlink of data, sent from the base station <NUM> to the mobile device (e.g., <NUM>), where the predefined sleep mode criteria can provide that upon receiving such explicit signal, the mobile device is to transition from/to CRX mode to/from LS mode or DS mode (e.g., with regard to DRX and/or DTX), and the mobile device can transition from/to CRX mode to/from the desired mode (e.g., LS mode, DS mode), as specified in the message providing the explicit signal.

In accordance with another aspect, the mobile device (e.g., <NUM>) can be configured to send CQI information. The CQI offset can range from <NUM> to several slots, for example. It can be desirable to synchronize the uplinks when sending CQI information. CQI typically cannot be sent if the "off' period (e.g., associated with DRX) is a significant period of time (e.g., <NUM> seconds or more) and there is a possibility for losing synchronization. It can also be desirable to be power controlled when sending of CQI information, as there can be little benefit of sending CQI if the probability of successful decoding at the base station <NUM> is low. To facilitate power control, an additional broadband reference signal can be provided with the CQI. For instance, SRS can be employed when sending CQI from the mobile device (e.g., <NUM>) to the base station <NUM>. The CQI information can be utilized by the base station <NUM> to facilitate determining the proper data transmission rates between the base station <NUM> and the mobile device (e.g., <NUM>), as a channel with a higher quality indicator typically can support a higher data transmission rate than a channel with a lower quality indicator.

In one embodiment, the mobile device (e.g., <NUM>) can employ CRX mode, LS mode, and DS mode (e.g., DRX and/or DTX). Such embodiment of the subject innovation can result in substantial reduction in power consumption by the mobile device (e.g., <NUM>), as compared to conventional mobile devices, while also providing suitable support for certain applications, such as gaming or Voice over Internet Protocol (VoIP), for instance. The mobile device can transition between LS mode and DS mode (e.g., DRX and/or DTX) based in part on explicit signaling and/or implicit signaling. Explicit signaling can also be utilized to facilitate transitioning to and/or from CRX mode (e.g., with regard to DRX and/or DTX).

In accordance with another embodiment, the mobile device (e.g., <NUM>) can employ CRX mode and LS mode (e.g., DRX and/or DTX). As a result there can be a reduction in power consumption (e.g., by transitioning into LS mode) by the mobile device (e.g., <NUM>), as compared to conventional mobile devices, while also providing suitable support for certain applications, such as gaming or VoIP, for example. Transitions between the CRX mode and LS mode can be performed using explicit signaling and/or implicit signaling.

In accordance with yet another embodiment, the mobile device (e.g., <NUM>) can employ CRX mode and DS mode (e.g., DRX and/or DTX). As a result there can be a significant reduction in power consumption (e.g., by transitioning into DS mode) by the mobile device (e.g., <NUM>), as compared to conventional mobile devices. Transitions between the CRX mode and DS mode can be performed using explicit signaling and/or implicit signaling, for example.

With reference to <FIG>, illustrated is a system <NUM> that can facilitate transitions between different sleep modes associated with a mobile device within a wireless communication environment. System <NUM> includes a base station <NUM> that can communicate with one or more mobile devices, such as mobile device <NUM>. It is to be appreciated and understood that only one mobile device is depicted in <FIG> for clarity and brevity. Moreover, base station <NUM> can communicate with other base station(s) and/or any disparate devices (e.g., servers) (not shown) that can perform functions such as, for example, authentication, authorization, accounting, billing, and so forth. The base station <NUM> and mobile device <NUM> each can be respectively the same or similar as, and/or can comprise respectively the same or similar functionality as, respective components as more fully described herein, such as, for example, with regard to system <NUM>.

Mobile device <NUM> can be communicatively connected (e.g., wireless connection) with the base station <NUM>, where the connection can comprise a data channel and a control channel. The data channel can facilitate transmission of data between the mobile device <NUM> and the base station <NUM>, and the control channel can facilitate the transmission of control information between the mobile device and the base station <NUM>.

In one aspect, the mobile device <NUM> can include a sleep mode controller <NUM> that can facilitate transitioning the mobile device <NUM> between the various sleep modes, such as DS mode, LS mode, and/or CRX mode (e.g., with regard to DRX and DTX) based in part on predefined sleep mode criteria that can be stored in data store <NUM>. The sleep mode controller <NUM> can facilitate retrieving information associated with the predefined sleep mode criteria from the data store <NUM>, and can provide the predefined sleep mode criteria to an analyzer component <NUM> that can evaluate received information regarding activity (e.g., data exchanges associated with the mobile device <NUM>) and can compare such received information with the predefined sleep mode criteria to facilitate determining whether the mobile device <NUM> is to transition from one mode to another mode.

It will be appreciated that the data store <NUM> described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), flash memory, and/or nonvolatile random access memory (NVRAM). Volatile memory can include random access memory (RAM), which can act as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). The memory <NUM> of the subject systems and methods is intended to comprise, without being limited to, these and any other suitable types of memory.

The mobile device <NUM> can further include a timer <NUM> that can track the amount of time that has elapsed between the occurrence of events, such as, for instance, the amount of time that has elapsed between data exchanges associated with the mobile device <NUM>. The timer <NUM> can provide information regarding the elapsed time between events to the sleep mode controller <NUM> and/or the analyzer <NUM> in order to facilitate determining whether the mobile device <NUM> has been inactive with respect to data exchanges for a predetermined amount of time or more, where such predetermined amount of time can be specified by the predefined sleep mode criteria, and where there can be disparate predetermined amounts of time employed with regard to the different types of transitions (e.g., one predetermined amount of time associated with determining whether to transition from CRX mode to LS mode; a disparate predetermined amount of time associated with determining whether to transition between LS mode and DS mode) and/or different types of transmissions (e.g., reception of data, transmission of data).

For example, the mobile device <NUM> can be in CRX mode, and the analyzer component <NUM> can receive time information from timer <NUM> indicating that there has not been a data exchange between the mobile device <NUM> and the base station <NUM> for two seconds. The analyzer <NUM> can compare such time information with the predefined sleep mode criteria, which in this example, can specify that the mobile device <NUM> is to be transitioned from CRX mode to LS mode if two or more seconds has elapsed since the last data exchange. The analyzer <NUM> can determine that the predefined sleep mode criteria has been met to transition from CRX mode to LS mode, and can communicate that determination to the sleep mode controller <NUM>. The sleep mode controller <NUM> can facilitate transitioning (e.g., switching) the mobile device <NUM> from CRX mode to LS mode based in part on the determination and/or predefined sleep mode criteria. The elapsed time that meets the predefined sleep mode criteria for transitioning from CRX mode to LS mode can be an implicit signal to perform such transition.

As another example, a mobile device <NUM> can be in LS mode. The mobile device <NUM> can receive an explicit signal, such as an L1/L2 control channel or L1/L2 control + DL SCH, from the base station <NUM> that indicates that the mobile device <NUM> is to transition from the LS mode to the DS mode. Such message can be provided to the analyzer <NUM>, which can compare the received message with the predefined sleep mode criteria, where such criteria can specify that a LS mode to DS mode transition should be performed upon receiving such a message, and the analyzer <NUM> can determine that there is to be a transition from LS mode to DS mode. The analyzer <NUM> can communicate such determination to the sleep mode controller <NUM>, and the sleep mode controller <NUM> can facilitate transitioning the mobile device <NUM> from the LS mode to the DS mode.

Now referring to <FIG>, illustrated is a system <NUM> that can facilitate transitions between different sleep modes associated with a mobile device within a wireless communication environment. System <NUM> includes a base station <NUM> that can communicate with one or more mobile devices, such as mobile device <NUM>. It is to be appreciated and understood that only one mobile device is depicted in <FIG> for clarity and brevity. Moreover, base station <NUM> can communicate with other base station(s) and/or any disparate devices (e.g., servers) (not shown) that can perform functions such as, for example, authentication, authorization, accounting, billing, and so forth. The base station <NUM> and mobile device <NUM> each can be respectively the same or similar as, and/or can comprise respectively the same or similar functionality as, respective components as more fully described herein, such as, for example, with regard to system <NUM> and/or system <NUM>.

Base station <NUM> can include a controller <NUM> that can facilitate controlling transitions between various sleep modes in the mobile device <NUM>. For example, the controller <NUM> in conjunction with analyzer <NUM> can facilitate evaluating and/or comparing information relevant to transition determinations in view of the predefined sleep mode criteria to facilitate determining whether to generate and send an explicit signal (e.g., control message) to the mobile device <NUM> directing the mobile device <NUM> to transition from one sleep mode to another mode.

The base station <NUM> also can include a timer <NUM> that can track the length of time that has elapsed between data exchanges, or from the last data exchange, between the base station <NUM> and the mobile device <NUM>. The timer <NUM> can provide such time information to the controller <NUM> and/or analyzer <NUM>, and such time information can be evaluated (e.g., compared) in relation to the predefined sleep mode criteria to facilitate determining whether a transition is to be performed.

The base station <NUM> can also comprise a scheduler <NUM> that can schedule uplink and/or downlink transmissions between the base station <NUM> and the mobile device <NUM>. The scheduler <NUM> can schedule the downlink transmissions to occur when the mobile device <NUM> is in a "on" period or state (e.g., "on" period of LS mode, or CRX mode which can be in a continuous "on" state). The scheduler <NUM> also can schedule the uplink transmissions to occur when the mobile device <NUM> is in a "on" period (e.g., "on" period of LS mode, or CRX mode which can be in a continuous "on" state). The scheduler <NUM> can facilitate transmitting desired control messages and/or associated data as part of the particular transmission.

Referring to <FIG>, methodologies relating to selecting sleep modes and/or transitioning between sleep modes associated with a mobile device in a wireless communication environment are illustrated. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts can, in accordance with one or more embodiments, occur in different orders and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts can be required to implement a methodology in accordance with one or more embodiments.

With reference to <FIG>, illustrated is a methodology <NUM> that can facilitate selecting a sleep mode in a mobile device associated with a wireless communication system. At <NUM>, a sleep mode can be selected based in part on a predefined sleep mode criteria. In one aspect, the sleep modes available to be selected can include a LS mode, a DS mode, and/or a non-sleep mode (e.g., CRX mode). The mobile device can facilitate selecting the desired sleep mode. At <NUM>, there can be a signaling to facilitate selecting the sleep mode. For instance, the signaling can be an explicit signaling, such as a control message from the base station (e.g., <NUM>) to a mobile device (e.g., <NUM>), instructing the mobile device to transition from one sleep mode to another sleep mode by selecting another sleep mode; or can be an implicit signaling that can be based in part on a condition being met, such as a predetermined length of time elapsing between the last data exchange between the base station and the mobile device, where the condition(s) can be defined by the predefined sleep mode criteria, for example.

Turning to <FIG>, illustrated is a methodology <NUM> that can facilitate transitioning to a sleep mode in a mobile device associated with a wireless communication system. At <NUM>, information related to a sleep mode(s) can be evaluated. In one aspect, an analyzer associated with a mobile device (e.g., <NUM>) or a base station (e.g., <NUM>) can evaluate information related to sleep modes, such as, for example, information related to the elapsed amount of time since the last data exchange between the base station and mobile device. At <NUM>, a determination can be made regarding whether a transition from a first sleep mode to another sleep mode is to be performed, based in part on the predefined sleep mode criteria. For example, the analyzer can make a determination regarding whether to transition from a LS mode to a DS mode after evaluating received information related to sleep modes and comparing such received information to the predefined sleep mode criteria to determine whether a transition condition has been met. At <NUM>, there can be a signal to facilitate a transition from the first sleep mode to another sleep mode. For instance, if it is determined that a transition condition has been met based in part on the received information and/or the predefined sleep mode criteria, an explicit and/or implicit signal can be generated to facilitate transitioning from the first sleep mode to the other sleep mode. An explicit signaling can be a control message from the base station to the mobile device indicating that the mobile device is to transition from the first sleep mode to another sleep mode. An implicit signaling can be, for instance, a certain condition related to the predefined sleep mode criteria being met, where the certain condition being met can indicate (e.g., implicitly signal) to the mobile device and/or base station that the mobile device is to transition from the first sleep mode to another sleep mode. At <NUM>, there can be a transition from the first sleep mode to the other sleep mode. For example, the signal can indicate that the mobile device is to transition from the first sleep mode (e.g., LS mode) to another sleep mode (e.g., DS mode).

It will be appreciated that, in accordance with one or more aspects described herein, inferences can be made regarding selecting sleep modes and/or determining when to transition between sleep modes with respect to a mobile device. As used herein, the term to "infer" or "inference" refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic-that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.

According to an example, one or more methods presented above can include making an inference(s) pertaining to selecting a sleep mode and/or transitioning from one sleep mode to another sleep mode. By way of further illustration, an inference(s) can be made related to determining whether a transition between one sleep mode and another sleep mode is to be performed or has occurred. It will be appreciated that the foregoing examples are illustrative in nature and are not intended to limit the number of inferences that can be made or the manner in which such inferences are made in conjunction with the various embodiments and/or methods described herein.

<FIG> is an illustration of a mobile device <NUM> that can facilitate transitions between sleep modes in a mobile device associated with a wireless communication system. Mobile device <NUM> comprises a receiver <NUM> that receives a signal from, for instance, a receive antenna (not shown), and performs typical actions thereon (e.g., filters, amplifies, downconverts, etc.) the received signal and digitizes the conditioned signal to obtain samples. Receiver <NUM> can be, for example, an MMSE receiver, and can comprise a demodulator <NUM> that can demodulate received symbols and provide them to a processor <NUM> for channel estimation. Processor <NUM> can be a processor dedicated to analyzing information received by receiver <NUM> and/or generating information for transmission by a transmitter <NUM>, a processor that controls one or more components of mobile device <NUM>, and/or a processor that both analyzes information received by receiver <NUM>, generates information for transmission by transmitter <NUM>, and controls one or more components of mobile device <NUM>. Mobile device <NUM> can also comprise a modulator <NUM> that can work in conjunction with the transmitter <NUM> to facilitate transmitting signals (e.g., data) to, for instance, a base station <NUM>, another mobile device, etc..

The processor <NUM> can also comprise a sleep mode controller <NUM> that can facilitate determining and/or controlling transitions between the various sleep modes associated with the mobile device <NUM>. It is to be appreciated and understood that the sleep mode controller <NUM> can be the same or similar as, or can comprise the same or similar functionality as, respective components such as more fully described herein, for example, with regard to system <NUM>. It is to be further appreciated and understood that the sleep mode controller <NUM> can be included within the processor <NUM> (as depicted), can be a stand-alone unit, can be incorporated within another component, and/or virtually any suitable combination thereof, as desired.

Mobile device <NUM> can additionally comprise data store <NUM> that can be operatively coupled to processor <NUM> and can store data to be transmitted, received data, information related to the predefined sleep mode criteria, information (e.g., elapsed time between data exchanges, explicit signals, implicit signals,. ) relevant to determinations regarding transitions between the various sleep modes, and any other suitable information that can facilitate determining whether to transition from one sleep mode to another mode. Data store <NUM> can additionally store protocols and/or algorithms associated with and facilitating determining whether to transition from one sleep mode to another mode. It is to be appreciated that the data store <NUM> can be the same or similar as, or can comprise the same or similar functionality as, respective components such as more fully described herein, for example, with regard to system <NUM>.

Processor <NUM> can be operatively coupled to analyzer <NUM> that can evaluate information, such as information related to determinations regarding transitions between the various sleep modes. It is to be appreciated that the analyzer <NUM> can be the same or similar as, or can comprise the same or similar functionality as, respective components such as more fully described herein, for example, with regard to system <NUM>. It is to be further appreciated and understood that analyzer <NUM> can be a stand-alone unit (as depicted), can be included within the processor <NUM>, can be incorporated within another component, and/or virtually any suitable combination thereof, as desired.

Processor <NUM> also can be operatively coupled to timer <NUM> that can track the amount of elapsed time between data exchanges, or since the last data exchange, between the mobile device <NUM> and base station <NUM> to facilitate determinations regarding transitions between the various sleep modes. It is to be appreciated that the timer <NUM> can be the same or similar as, or can comprise the same or similar functionality as, respective components such as more fully described herein, for example, with regard to system <NUM>. It is to be further appreciated and understood that timer <NUM> can be a stand-alone unit (as depicted), can be included within the processor <NUM>, can be incorporated within another component, and/or virtually any suitable combination thereof, as desired.

<FIG> is an illustration of a system <NUM> that can facilitate transitions between sleep modes in a mobile device associated with a wireless communication system. System <NUM> comprises a base station <NUM> (e.g., access point,. ) with a receiver <NUM> that can receive signal(s) from one or more mobile devices <NUM> through a plurality of receive antennas <NUM>, and a transmitter <NUM> that can transmit signals (e.g., data) to the one or more mobile devices <NUM> through a transmit antenna <NUM>. Receiver <NUM> can receive information from receive antennas <NUM> and can be operatively associated with a demodulator <NUM> that can demodulate received information. Demodulated symbols can be analyzed by a processor <NUM> that can be a processor dedicated to analyzing information received by receiver <NUM> and/or generating information for transmission by a transmitter <NUM>, a processor that controls one or more components of base station <NUM>, and/or a processor that both analyzes information received by receiver <NUM>, generates information for transmission by transmitter <NUM>, and controls one or more components of base station <NUM>. The base station <NUM> can also comprise a modulator <NUM> that can work in conjunction with the transmitter <NUM> to facilitate transmitting signals (e.g., data) to, for instance, a mobile device <NUM>, another device, etc..

Processor <NUM> can be coupled to a memory <NUM> that can store information related to data to be transmitted, received data, information related to the predefined sleep mode criteria, information (e.g., elapsed time between data exchanges, explicit signals, implicit signals,. ) relevant to determinations regarding transitions between the various sleep modes, and any other suitable information that can facilitate determining whether to transition from one sleep mode to another mode. Memory <NUM> can additionally store protocols and/or algorithms associated with and facilitating determining whether to the mobile device <NUM> is to transition from one sleep mode to another mode.

Processor <NUM> can be and/or can comprise controller <NUM> that can facilitate making determinations associated with transitions between various sleep modes in a mobile device <NUM>. It is to be appreciated and understood that the controller <NUM> can be the same or similar as, or can comprise the same or similar functionality as, respective components such as more fully described herein, for example, with regard to system <NUM>. It is to be further appreciated and understood that the controller <NUM> can be included within the processor <NUM> (as depicted), can be a stand-alone unit, can be incorporated within another component, and/or virtually any suitable combination thereof, as desired.

Processor <NUM> can be coupled to an analyzer <NUM> that can evaluate information related to the mobile device <NUM>, such as information relevant to determinations regarding transitions between various sleep modes in the mobile device <NUM>, and can analyze predefined sleep mode criteria to facilitate determining whether a mobile device <NUM> is to be transitioned from one sleep mode to another mode. The analyzer <NUM> can receive information obtained from the mobile device <NUM> and/or information (e.g., elapsed time information related to data exchanges) generated within the base station <NUM>, and such information can be evaluated to facilitate making transition determinations. It is to be appreciated that the analyzer <NUM> can be the same or similar as, or can comprise the same or similar functionality as, respective components such as more fully described herein, for example, with regard to system <NUM>. It is to be further appreciated and understood that analyzer <NUM> can be a stand-alone unit (as depicted), can be included within the processor <NUM>, can be incorporated within another component, and/or virtually any suitable combination thereof, as desired.

Processor <NUM> can be operatively coupled to timer <NUM> that can track the amount of elapsed time between data exchanges, or since the last data exchange, between the mobile device <NUM> and base station <NUM> to facilitate determinations regarding transitions between the various sleep modes. It is to be appreciated that the timer <NUM> can be the same or similar as, or can comprise the same or similar functionality as, respective components such as more fully described herein, for example, with regard to system <NUM>. It is to be further appreciated and understood that timer <NUM> can be a stand-alone unit (as depicted), can be included within the processor <NUM>, can be incorporated within another component, and/or virtually any suitable combination thereof, as desired.

Processor <NUM> also can be operatively coupled to scheduler <NUM> that can schedule data transmissions (e.g., uplinks, downlinks) between the base station <NUM> and a mobile device <NUM>. It is to be appreciated that the scheduler <NUM> can be the same or similar as, or can comprise the same or similar functionality as, respective components such as more fully described herein, for example, with regard to system <NUM>. It is to be further appreciated and understood that scheduler <NUM> can be a stand-alone unit (as depicted), can be included within the processor <NUM>, can be incorporated within another component, and/or virtually any suitable combination thereof, as desired.

<FIG> shows an example wireless communication system <NUM>. The wireless communication system <NUM> depicts one base station <NUM> and one mobile device <NUM> for sake of brevity. However, it is to be appreciated that system <NUM> can include more than one base station and/or more than one mobile device, wherein additional base stations and/or mobile devices can be substantially similar or different from example base station <NUM> and mobile device <NUM> described below. In addition, it is to be appreciated that base station <NUM> and/or mobile device <NUM> can employ the systems (<FIG><FIG>and <FIG>and/or methods (<FIG>) described herein to facilitate wireless communication there between. It is to be appreciated that base station <NUM> and mobile device <NUM> each can be respectively the same or similar as, and/or can comprise respectively the same or similar functionality as, respective components as more fully described herein, such as, for example, with regard to system <NUM>, system <NUM>, system <NUM>, system <NUM>, and/or system <NUM>.

At base station <NUM>, traffic data for a number of data streams is provided from a data source <NUM> to a transmit (TX) data processor <NUM>. According to an example, each data stream can be transmitted over a respective antenna. TX data processor <NUM> formats, codes, and interleaves the traffic data stream based on a particular coding scheme selected for that data stream to provide coded data.

The coded data for each data stream can be multiplexed with pilot data using orthogonal frequency division multiplexing (OFDM) techniques. Additionally or alternatively, the pilot symbols can be frequency division multiplexed (FDM), time division multiplexed (TDM), or code division multiplexed (CDM). The pilot data is typically a known data pattern that is processed in a known manner and can be used at mobile device <NUM> to estimate channel response. The multiplexed pilot and coded data for each data stream can be modulated (e.g., symbol mapped) based on a particular modulation scheme (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM), etc.) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream can be determined by instructions performed or provided by processor <NUM>.

The modulation symbols for the data streams can be provided to a TX MIMO processor <NUM>, which can further process the modulation symbols (e.g., for OFDM). TX MIMO processor <NUM> then provides NT modulation symbol streams to NT transmitters (TMTR) 822a through 822t. In various embodiments, TX MIMO processor <NUM> applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

Further, NT modulated signals from transmitters 822a through 822t are transmitted from NT antennas 824a through 824t, respectively.

At mobile device <NUM>, the transmitted modulated signals are received by NR antennas 852a through 852r and the received signal from each antenna <NUM> is provided to a respective receiver (RCVR) 854a through 854r. Each receiver <NUM> conditions (e.g., filters, amplifies, and downconverts) a respective signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream.

An RX data processor <NUM> can receive and process the NR received symbol streams from NR receivers <NUM> based on a particular receiver processing technique to provide NT "detected" symbol streams. RX data processor <NUM> can demodulate, deinterleave, and decode each detected symbol stream to recover the traffic data for the data stream. The processing by RX data processor <NUM> is complementary to that performed by TX MIMO processor <NUM> and TX data processor <NUM> at base station <NUM>.

A processor <NUM> can periodically determine which pre-coding matrix to use (discussed below). Further, processor <NUM> can formulate a reverse link message comprising a matrix index portion and a rank value portion.

The reverse link message can comprise various types of information regarding the communication link and/or the received data stream. The reverse link message can be processed by a TX data processor <NUM>, which also receives traffic data for a number of data streams from a data source <NUM>, modulated by a modulator <NUM>, conditioned by transmitters 854a through 854r, and transmitted back to base station <NUM>.

At base station <NUM>, the modulated signals from mobile device <NUM> are received by antennas <NUM>, conditioned by receivers <NUM>, demodulated by a demodulator <NUM>, and processed by a RX data processor <NUM> to extract the reverse link message transmitted by mobile device <NUM>. Further, processor <NUM> can process the extracted message and can determine which precoding matrix to use for determining the beamforming weights.

Processors <NUM> and <NUM> can direct (e.g., control, coordinate, manage, etc.) operation at base station <NUM> and mobile device <NUM>, respectively. Respective processors <NUM> and <NUM> can be associated with memory <NUM> and <NUM> that store program codes and data. Processors <NUM> and <NUM> can also perform computations to derive frequency and impulse response estimates for the uplink and downlink, respectively.

In an aspect, logical channels are classified into Control Channels and Traffic Channels. Logical Control Channels can comprise Broadcast Control Channel (BCCH) which is DL channel for broadcasting system control information. Paging Control Channel (PCCH) which is DL channel that transfers paging information. For instance, PCCH can be utilized when the network does not know the location cell of the UE. Common control channel (CCCH) which is a channel that can be utilized for transmitting control information between UEs and the network. This channel can be used by the UEs having no RRC connection with the network. Multicast Control Channel (MCCH) which is Point-to-multipoint DL channel used for transmitting Multimedia Broadcast and Multicast Service (MBMS) scheduling and control information for one or several MTCHs. Generally, after establishing RRC connection this channel is only used by UEs that receive MBMS (Note: old MCCH+MSCH). It is noted that it is FFS how MBMS is transmitted by either L2/<NUM> signaling on MCCH or L1 signaling. Dedicated Control Channel (DCCH) is Point-to-point bi-directional channel that transmits dedicated control information and used by UEs having an RRC connection. In aspect, Logical Traffic Channels can comprise a Dedicated Traffic Channel (DTCH) which is Point-to-point bi-directional channel, dedicated to one UE, for the transfer of user information. A DTCH can be used in both UL and DL. Also, a Multicast Traffic Channel (MTCH) for Point-to-multipoint DL channel for transmitting traffic data. This channel can be used by UEs that receive MBMS.

In an aspect, Transport Channels are classified into DL and UL. DL Transport Channels comprise a Broadcast Channel (BCH), a Downlink Shared Data Channel (DL-SDCH), a Paging Channel (PCH), and a Multicast Channel (MCH). A BCH can be characterized by a fixed-predefined format and can be broadcast in the entire coverage area of the cell. A DL-SDCH can be characterized by having support for hybrid automatic repeat request (HARQ); support for dynamic link adaptation by varying the modulation, coding, and transmit power; ability to be broadcast in the entire cell; ability to use beamforming; support for both dynamic and semi-static resource allocation; support for UE discontinuous reception (DRX) to enable UE power saving; support for MBMS transmission. It is noted that the ability to utilize slow power control can be based in part on the physical layer. The PCH can be characterized by having support of UE power saving (DRX cycle is indicated by the network to the UE); ability to be broadcast in the entire coverage area of the cell, and can be mapped to physical resources which can be used dynamically for traffic channels or other control channels. The MCH can be characterized by having ability to be broadcast in the entire coverage area of the cell; support for MBSFN combining of MBMS transmission on multiple cells; and support for semi-static resource allocation (e.g., with a time frame of a long cyclic prefix. The UL Transport Channels comprise a an Uplink Shared Channel (UL-SCH), a Random Access Channel (RACH), and plurality of PHY channels. The UL-SCH can be characterized by having ability to use beamforming; support for dynamic link adaptation by varying the transmit power and potentially modulation and coding; support for HARQ; support for both dynamic and semi-static resource allocation. It is noted that the possibility to use UL synchronization and timing advance can depend in part on the physical layer. The RACH can be characterized by having limited control information, and collision risk. It is noted that the possibility to use open loop power control can depend in part on the physical layer solution. The PHY channels comprise a set of DL channels and UL channels.

The PHY channels (e.g., of E-UTRA) can be: Physical broadcast channel (PBCH), the coded BCH transport block can be mapped to four subframes within a <NUM> interval, <NUM> timing can be blindly detected (e.g., there is no explicit signaling indicating <NUM> timing, each subframe can be assumed to be self-decodable (e.g., the BCH can be decoder from a single reception, assuming sufficiently good channel conditions; Physical control format indicator channel (PCFICH) that can inform the UE about the number of OFDM symbols used for PDCCHs, and can be transmitted in every subframe; Physical downlink control channel (PDCCH) that can inform the US about the resource allocation of PCH and DL-SCH, and hybrid ARQ information related to DL-SCH, and can carry the uplink scheduling grant; Physical hybrid ARQ indicator channel (PHICH) that can carry hybrid ARQ ACK/NAKs in response to uplink transmissions; Physical downlink shared channel (PDSCH) that can carry DL-SCH and PCH; Physical multicast channel (PMCH) that can carry the MCH; Physical uplink control channel (PUCCH) that can carry hybrid ARQ ACK/NAKs in response to downlink transmission, can carry scheduling (SR), and can carry CQI reports; Physical uplink shared channel (PUSCH) that can carry the UL-SCH; and Physical random access channel (PRACH) that can carry the random access preamble.

In an aspect, a channel structure is provided that preserves low PAR (at any given time, the channel is contiguous or uniformly spaced in frequency) properties of a single carrier waveform.

It is to be understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For a hardware implementation, the processing units can be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof.

When the embodiments are implemented in software, firmware, middleware or microcode, program code or code segments, they can be stored in a machine-readable medium, such as a storage component. A code segment can represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, etc..

For a software implementation, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes can be stored in memory units and executed by processors. The memory unit can be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

With reference to <FIG>, illustrated is a system <NUM> that can facilitate transitions between different sleep modes in a mobile device associated with a wireless communication environment. For example, system <NUM> can reside at least partially within a mobile device (e.g., <NUM>). It is to be appreciated that system <NUM> is represented as including functional blocks, which can be functional blocks that represent functions implemented by a processor, software, or combination thereof (e.g., firmware). System <NUM> includes a logical grouping <NUM> of electrical components that can act in conjunction.

For instance, logical grouping <NUM> can include an electrical component for selecting a sleep mode based in part on a predefined sleep mode criteria, wherein the sleep mode can be a LS mode, a DS mode, or a non-sleep mode (e.g., CRX mode) <NUM>. For instance, the selecting of a sleep mode can involve switching from one sleep mode to another sleep mode. In accordance with an aspect, the non-sleep mode can be considered a special mode associated with the LS mode, where, for the non-sleep mode, the "off' period can be set to <NUM>, so that the mobile device (e.g., <NUM>) can be in an "on" state continuously. Further, logical grouping <NUM> can comprise an electrical component for signaling related to a sleep mode <NUM>. For example, the signaling can comprise explicit signaling (e.g., control signal) and/or implicit signaling (e.g., a predefined condition associated with the predefined sleep mode criteria has been met). Additionally, system <NUM> can include a memory <NUM> that retains instructions for executing functions associated with electrical components <NUM> and <NUM>. While shown as being external to memory <NUM>, it is to be understood that one or more of electrical components <NUM> and <NUM> can exist within memory <NUM>.

Claim 1:
A method operable on a mobile device (<NUM>) that facilitates transitioning the mobile device (<NUM>) from a first non-DRX mode to a second DRX mode, comprising:
receiving signaling to facilitate selection of the first non-DRX mode or second DRX mode, wherein the signaling relates to a predetermined amount of time since a last data exchange between the mobile device and a base station; and
selecting the second DRX mode based in part on a length of time since a last data exchange between the mobile device and the base station being the predetermined amount of time; and
transitioning, if the second DRX mode is selected, from the first non-DRX mode to the second DRX mode.