HK1110446A - Method and apparatus for mitigating the impact of receiving unsolicited ip packets at a wireless device - Google Patents

Abstract

To initiate dormancy early, a wireless device receives an IP packet from a wireless network and determines whether the received IP packet is an unsolicited IP packet. An unsolicited IP packet may be declared if the received IP packet causes the wireless device to reactivate from dormancy or is not delivered to an application or service running at the wireless device. The wireless device transitions to dormancy early if the received IP packet is deemed to be an unsolicited IP packet and no other events prevent transition to dormancy. The wireless device may use (1) a shortened value for an inactivity timer for a predetermined time duration if an unsolicited IP packet is detected and (2) a nominal value for the inactivity timer thereafter. The wireless device resets the inactivity timer whenever an IP packet is sent or received and transitions to dormancy upon expiration of the inactivity timer.

Description

Method and apparatus for mitigating the impact of receiving unsolicited IP packets at a wireless device

Technical Field

The present application claims priority from united states provisional application No. 60/630,260 entitled "Method for Reducing the Impact of a Reducing unorganized IP Packets on a Mobile Station," filed on 11, month 22, 2004, which is assigned to the assignee of the present application and is incorporated herein by reference in its entirety for all purposes.

The present disclosure relates generally to communication, and more specifically to techniques for processing Internet Protocol (IP) packets at a wireless device.

Background

Wireless communication networks are widely deployed to provide various communication services such as voice, packet data, and so on. A wireless device may obtain data services from a wireless network by using IP over an air link interface employed by the wireless network. The wireless device may establish a data session with a network entity and exchange data with other entities coupled to the wireless network via the internet or some other network.

The wireless device may operate in an active state or a dormant state at any given time during the data session. The wireless device may be active for only a portion of the time during a data session that may be opened for an extended period of time. For example, a wireless device may transmit and/or receive packet data in short pulses and may remain dormant for many periods of time between these data pulses. Dormant refers to the situation where a data session is open but radio resources are released. To conserve battery power, which is important for portable devices such as cellular telephones, wireless devices may have as much circuitry as possible to reduce power consumption while in a sleep state. A wireless device may only wake up periodically to receive (1) page messages that alert the wireless device to the presence of incoming calls or packet data, and (2) overhead messages that carry system information and other information for the wireless device.

The wireless device may receive unsolicited IP packets from the wireless network while in a dormant state. Unsolicited IP packets may be defined as IP packets that are not requested by the wireless device and that otherwise do not have a corresponding application or service running on the wireless device. Receiving IP packets while dormant typically results in the wireless device reestablishing a traffic channel with the wireless network and remaining active for some period of time. If the received IP packet is an unsolicited IP packet, the wireless device typically discards the IP packet and/or sends a reset packet and takes no further action. The unsolicited IP packet does not trigger an exchange of data with the wireless network. Rather, unsolicited IP packets waste system resources because the traffic channel is established and not used to exchange data. The unsolicited IP packet additionally consumes battery power and shortens standby time because the wireless device is switched on and ready for wireless communication as a result of receiving this IP packet.

Accordingly, there is a need in the art for techniques to mitigate the effects of receiving unsolicited IP packets.

Disclosure of Invention

Techniques for identifying unsolicited IP packets and initiating dormancy early at a wireless device are described herein. In an aspect, a received IP packet at a wireless device may be considered an unsolicited IP packet if the received IP packet (1) causes the wireless device to reactivate from dormancy (i.e., transition from a dormant state to an active state), (2) is not passed on to an application or service running at the wireless device, (3) does not cause any reply or causes a single "reject" reply for the wireless device, or (4) meets some other condition or criteria.

In another aspect, the wireless device initiates dormancy early for unsolicited IP packets. A wireless device receives an IP packet from a wireless network and determines whether the received IP packet is an unsolicited IP packet. If the received IP packet is considered to be an unsolicited IP packet, the wireless device transitions to dormancy early and any other events do not prevent the transition to dormancy.

The wireless device may use various mechanisms for early to sleep transition. For example, the wireless device may maintain an inactivity timer while in an active state during the data session. The wireless device may reset the inactivity timer when receiving or sending IP packets and may transition to sleep when the inactivity timer expires. The inactivity timer may operate with multiple timer values to mitigate the impact of unsolicited IP packets. In an embodiment, a received IP packet that results in a resumption of activity from dormancy is considered an unsolicited IP packet and results in the use of a shortened value for the inactivity timer for a predetermined duration. After this duration, a nominal value is used for the inactivity timer. The shortened value allows the wireless device to go to sleep early if the reactivation is due to an unsolicited IP packet.

Various aspects and embodiments of the disclosure are described in more detail below.

Drawings

The features and nature of the present invention will become apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference characters identify correspondingly throughout.

Fig. 1 shows an exemplary wireless deployment.

Fig. 2 shows an exemplary protocol stack.

Fig. 3 shows an embodiment of a wireless device.

Fig. 4 shows a process for early to dormancy transition for unsolicited IP packets.

Fig. 5 illustrates the use of two values for the inactivity timer.

FIG. 6 shows a process for operating an inactivity timer with multiple values.

FIG. 7 shows a process for selectively resetting an inactivity timer.

FIG. 8 shows a block diagram of a wireless device.

Detailed Description

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

The techniques described herein to identify unsolicited IP packets and initiate dormancy early may be used for various wireless networks. For example, these techniques may be used for Code Division Multiple Access (CDMA) networks, Universal Mobile Telecommunications System (UMTS) networks, wireless Local Area Networks (LANs), and so on. A CDMA network may implement a Radio Access Technology (RAT), such as CDMA2000, and a networking protocol, such as ANSI-41. The UMTS network may implement RATs, such as wideband CDMA (W-CDMA) and/or global system for mobile communications (GSM), and networking protocols, such as GSM mobile application part (GSM-MAP). The wireless LAN provides communication coverage for a limited geographic area and may be an IEEE 802.11 network, a bluetooth personal area network (BT-PAN), or the like. In general, the techniques described herein may be used for a wireless wide area network (e.g., a CDMA or UMTS network) or a wireless LAN (e.g., an IEEE 802.11 network or a BT-PAN).

Fig. 1 shows a deployment 100 of wireless devices 120 in communication with a wireless network 130 to obtain communication services. Wireless device 120 may also be referred to as a Mobile Station (MS), User Equipment (UE), user terminal, subscriber unit, or some other terminology. Wireless network 130 includes base station 142, packet data entity 144, and IP gateway 150. Base station 142 provides radio communication for wireless device 120. Packet data entity 144 controls packet transmission between base station 142 and IP gateway 150. IP gateway 150 supports data services for wireless devices in wireless network 130. For example, IP gateway 150 may be responsible for establishing, maintaining, and terminating data sessions for wireless devices, and may further assign dynamic IP addresses to wireless devices. IP gateway 150 may be coupled to data network 160a, internet 160b, and/or other data networks. IP gateway 150 may communicate with various entities coupled to these data networks, such as remote host 170.

Wireless network 130 may also be considered to include a radio network 140 and a packet data network. The radio network 140 comprises a base station 142 and a packet data entity 144 and supports radio communication. The packet data network includes an IP gateway 150 and supports packet-switched communications between the radio network 140 and external data networks.

Wireless network 130 may be a CDMA network, in which case packet data entity 144 is referred to as a Packet Control Function (PCF), and IP gateway 150 is referred to as a Packet Data Serving Node (PDSN). The wireless network 130 may also be a UMTS network, in which case the packet data entity 144 is referred to as a Serving GPRS Support Node (SGSN) and the IP gateway 150 is referred to as a Gateway GPRS Support Node (GGSN). The wireless network 130 may also be a wireless LAN.

Fig. 2 shows an exemplary protocol stack 200 for data communication between wireless device 120 and remote host 170 over wireless network 130. The protocol stack includes a transport layer, a network layer, a link layer, and a physical layer. Wireless device 120 and remote host 170 may communicate using Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or some other protocol at the transport layer. TCP and UDP typically operate on top of IP at the network layer. Transport layer data is encapsulated in IP packets that are exchanged between wireless device 120 and remote host 170 via radio network 140 and IP gateway 150.

The link layer between wireless device 120 and wireless network 130 typically depends on the wireless network technology. For CDMA networks, the link layer is implemented with a point-to-point protocol (PPP) over the Radio Link Protocol (RLP). Wireless device 120 maintains a PPP session with IP gateway 150 for a data session and communicates with radio network 140 via RLP for data exchanges. The RLP operates on top of an air link interface (e.g., cdma 2000). Radio network 140 communicates with IP gateway 150 via a technology-dependent interface (e.g., an "R-P" interface for a CDMA network) that operates on top of the physical layer. IP gateway 150 communicates with remote host 170 via IP over a link layer and a physical layer. The layers may be different for other wireless networks.

Fig. 3 shows an embodiment of a wireless device 120. At wireless device 120, applications and services 320 execute on sockets 322 and data protocol stacks 324. A socket is an end point of a bi-directional communication path between two applications running on a network. In the internet scenario, a socket is associated with an IP address, a protocol at the transport layer (e.g., TCP or UDP), and a port number of the transport layer protocol. Each application running at wireless device 120 is associated with one or more sockets and exchanges data with external entities via the associated sockets. Each service (e.g., FTP, Telnet, etc.) may also be associated with one or more sockets. For the embodiment shown in fig. 3, the data protocol stack 324 utilizes TCP and/or UDP operating on top of IP. In general, the data protocol stack may implement any combination of protocols for any number of layers. Wireless device 120 communicates with wireless network 130 via Um interface 328a and may further communicate with terminal equipment via Rm interface 328 b. The terminal equipment may be a laptop computer, a Personal Digital Assistant (PDA), or some other computing device.

Wireless device 120 may have an open data session with IP gateway 150, but may exchange data sporadically. During a data session, a wireless device may enter an active state when there is data to be exchanged (e.g., sent or received) and may enter a dormant state when there is no data to be exchanged. The wireless device transitions between active and dormant states as a function of data activity.

Wireless device 120 communicates with radio network 140 to exchange data with IP gateway 150 and remote host 170. In the active state, wireless device 120 may establish (1) a forward link traffic channel for receiving data from radio network 140 and (2) a reverse link traffic channel for sending data to radio network 140. In the dormant state, the wireless device releases the traffic channel and can have as much circuitry as possible reduce power consumption in order to conserve battery power.

Wireless device 120 may receive IP packets from wireless network 130 while in a dormant state. The received IP packets reactivate the wireless device from dormancy and cause the wireless device to re-establish traffic channels for the forward and/or reverse links in anticipation of a possible data exchange with the wireless network. If the received IP packet is an unsolicited IP packet, the wireless device typically discards the IP packet and/or sends a TCP reset packet, and does not perform any other action. In this case, the traffic channel needs to be released and transition back to sleep early.

Fig. 4 shows a flow diagram of a process 400 for early to dormancy transition for unsolicited IP packets. Initially, an IP packet is received from a wireless network (block 412). A determination is made as to whether the received IP packet is an unsolicited IP packet (block 414). This determination may be made based on various criteria. If the received IP packet is deemed to be an unsolicited IP packet, the wireless device transitions to dormancy early and no other events prevent the transition to dormancy, i.e., no other activity occurs (block 416).

Early to sleep transition may be achieved in various ways. Several embodiments of early to sleep transition based on inactivity timers are described below.

Wireless device 120 may maintain an inactivity timer while in the active state. The inactivity timer determines the amount of time to remain active without exchanging any data. The wireless device may reset the inactivity timer to a nominal value when receiving or sending IP packets and may enter a dormant state when the inactivity timer expires. The inactivity timer allows the wireless device to release the traffic channel when no data is exchanged, thereby saving radio resources.

The nominal value of the inactivity timer is typically selected to provide good performance for the expected data usage. A shorter inactivity timer value may cause the wireless device to time out and go to sleep too quickly, e.g., due to a delayed response by a remote server, which may result in data loss. A longer inactivity timer value may result in the wireless device maintaining the traffic channel for too long without exchanging any data, wasting radio resources. The nominal value is typically selected based on a tradeoff between these two factors. A nominal value of about 20 seconds has been found to provide good performance under certain data usage scenarios.

The wireless device may receive unsolicited IP packets while dormant. The unsolicited IP packet causes the wireless device to resume activity and sets the inactivity timer to a nominal value. The wireless device would then need to wait until the inactivity timer expires before transitioning back to dormancy and releasing the traffic channel.

In an early dormancy embodiment, the inactivity timer operates at multiple values to mitigate the impact of receiving unsolicited IP packets. A shortened value (which is shorter than the nominal value) may be used for the inactivity timer when the wireless device is reactivated from hibernation. The shortened value allows the wireless device to return to sleep and release the traffic channel earlier if the reactivation is due to an unsolicited IP packet. The nominal value may be used for the inactivity timer when the wireless device is exchanging data with the wireless network. The nominal value allows the wireless device to achieve the desired behavior in terms of the two factors described above. The shortened value may be selected, for example, for the two factors described above to achieve good performance. For example, the nominal value may be 20 seconds and the shortened value may be 5 seconds. The shortened value may also be a configurable value selected based on typical patterns of unsolicited traffic, network behavior, etc. The configurable shortening value may also be limited to be within a predetermined range of values, such as from one second to five seconds.

FIG. 5 illustrates the use of shortened and nominal values for an inactivity timer in accordance with an embodiment. For this embodiment, the shortened value is used for a predetermined duration after the wireless device resumes activity from hibernation, which is referred to as a wait period, and after the wait period, the nominal value is used. The wait period may be a fixed value selected to provide good performance. For example, the wait period may be equal to a shortened value or a nominal value. Alternatively, the wait period may be a configurable value selected based on a typical pattern of unsolicited traffic. A wait timer may be used to track the elapsed time that the shortened value is used. By using nominal values after a waiting period, the wireless device can (1) process network-originated traffic and mobile-originated traffic in the same manner, and (2) provide the same behavior for both traffic types depending on when inactivity should result in dormancy and release of the traffic channel.

FIG. 6 shows a flow diagram of a process 600 for operating an inactivity timer with multiple values. Initially, an IP packet is received from the wireless network (block 612). A determination is made whether the received IP packet caused the wireless device to resume activity from hibernation (block 614). If the answer is "yes," the inactivity timer value is set equal to the shortened value (block 616) and the wait timer is reset to the wait period (block 618). Otherwise, if the answer to block 614 is no, then the inactivity timer value is set equal to the nominal value (block 620). The inactivity timer is then reset to the current inactivity timer value, which may be a shortened value or a nominal value depending on whether the wireless device has reactivated from dormancy with received IP packets (block 622). The inactivity timer and the wait timer each increment or decrement upon reset and expire when the value loaded in the timer is reached.

Thereafter, a determination is made (e.g., periodically) whether to exchange another IP packet with the wireless network (block 624). If the answer is "yes," the process returns to block 622 and the inactivity timer is reset to the current inactivity timer value. Otherwise, if the answer to block 624 is no, a determination is made as to whether the inactivity timer has expired (block 626). If the answer to block 626 is no, a determination is made as to whether the wait timer has expired (block 630). If the answer to block 630 is yes, then the inactivity timer value is set equal to the nominal value that was used for the inactivity timer since this point (block 632). From block 632 and otherwise if the answer to block 630 is "no," the process returns to block 624.

If the inactivity timer has expired and the answer is yes to block 626, the wireless device initiates dormancy and releases the traffic channel (block 628). The process then terminates. Although not shown in fig. 6, the inactivity timer value may be set equal to the nominal value when the wireless device goes to sleep for any reason. This ensures that the nominal value is used when the wireless device thereafter sends IP packets to the wireless network.

For process 600, received IP packets that result in a resumption of activity from dormancy also result in the use of a shortened value for the inactivity timer. If the received IP packet is an unsolicited IP packet (e.g., an MS RPC packet) and no other IP packets are exchanged thereafter, the wireless device initiates dormancy after the shortened time period has elapsed and the inactivity timer has expired. This early to dormant transition reduces the amount of time that traffic channels are unnecessarily established. For example, if the nominal value is 20 seconds and the shortened value is 5 seconds, sleep may be initiated up to 15 seconds in advance. Early dormancy conserves both radio resources of the wireless network and battery power of the wireless device. Conversely, if the received IP packet is a valid IP packet, other IP packets may be exchanged thereafter, and the inactivity timer will be reset after each IP packet exchange. If the wireless device does not go to sleep for the entire latency period, a nominal value is used for the inactivity timer. The wireless device will then operate in the same manner as in the conventional case.

The process 600 relies on the following assumptions: (1) occasionally receiving unsolicited IP packets such that inbound unsolicited IP packets do not continually reset the inactivity timer, and (2) not switching subsequent IP packets in response to receiving unsolicited IP packets such that outbound IP packets do not reset the inactivity timer. The implementation of the process 600 is relatively simple. However, performance depends on the accuracy of the underlying assumptions.

FIG. 6 shows a particular embodiment that uses two values for the inactivity timer and a shortened value throughout the wait period. In another embodiment, the shortened value is used whenever a received IP packet results in a reactivation from dormancy, and the nominal value is used once a valid IP packet is received or sent. A received IP packet may be considered a valid IP packet if, for example, the received IP packet is passed to an application or service running at the wireless device. No wait timer is required for this embodiment. In yet another embodiment, a shortened value is used for the wait duration, or until a valid IP packet is received, whichever occurs first. For this embodiment, the wait timer effectively expires when a valid IP packet is received. In yet another embodiment, the shortened value is used only for the first received IP packet that results in a resumption of activity from dormancy, and the nominal value is used thereafter. For this embodiment, the wait timer is not necessarily maintained.

In yet another embodiment, more than two values are used for the inactivity timer. For example, each received IP packet may cause the inactivity timer to be reset by a progressively longer value (from the shortest value to the nominal value). The first received IP packet may cause the inactivity timer to be reset by the shortest value, the next received IP packet may cause the inactivity timer to be reset by the longer value, and so on, and the nth received IP packet may cause the inactivity timer to be reset by the nominal value. In general, any number of values may be used for the inactivity timer, and each timer value may be applied in any manner.

In another embodiment of early dormancy, the inactivity timer is selectively reset based on detected traffic. A single value or multiple values may be used for the inactivity timer. The inactivity timer is not automatically reset upon receipt of an inbound IP packet or upon sending an outbound IP packet. Instead, the inactivity timer is selectively reset whenever an IP packet is considered a valid IP packet.

Fig. 7 shows a flow diagram of a process 700 for selectively resetting an inactivity timer. Initially, an IP packet is received from a wireless network (block 712). This received IP packet may or may not have resulted in a recovery from dormancy. The destination of the received IP packet within the wireless device is then determined (block 714). This can be achieved by: (1) checking a destination port number of the received IP packet; and (2) determining whether the application or service is listening to the port number. For example, a website application may run on the wireless device, or a particular port may be used to send out data. The inbound IP packet destined for this port will be passed to the web application. The web application may be considered to silently request for service. An in-transit IP packet may therefore be considered a valid IP packet if it is destined for a port associated with an application or service running at the wireless device.

It is then determined whether the received IP packet has been delivered to an application or service running at the wireless device (block 716). If the answer is "yes," then the received IP packet is considered a valid IP packet and the inactivity timer is reset to the nominal value (block 718). In a further aspect, if the received IP packet is not passed to an application or service, the inactivity timer may be allowed to continue (i.e., not reset), or may be reset to a shortened value (block 720). After blocks 718 and 720, the process proceeds to block 722.

In block 722, it is determined (e.g., periodically) whether the wireless device sends an outgoing IP packet to the wireless network. If the answer is "yes," the process returns to block 718 and the inactivity timer is reset to the nominal value. In another aspect, a determination is made as to whether an inbound IP packet is received from the wireless network (block 724). If the answer is "yes," the process returns to block 714 to determine the destination of the received IP packet. If an IP packet has not been received and the answer to block 724 is "No," a determination is made as to whether the inactivity timer has expired (block 726). If the answer is "no," the process returns to block 722. In addition, if the inactivity timer has expired and the answer to block 726 is yes, the wireless device initiates dormancy and releases the traffic channel (block 728). The process then terminates.

For process 700, the inactivity timer is reset to a nominal value by either a valid IP packet or an outgoing IP packet received. Thus, whenever valid traffic is detected, the inactivity timer is reset to the nominal value. Unsolicited IP packets that are not delivered to an application or service running at the wireless device do not reset the inactivity timer or reset the inactivity timer to a shortened value, which may then result in an early transition to dormancy.

Process 700 may be triggered by a received IP packet resulting in a resumption of activity from dormancy, as indicated in fig. 7. In general, process 700 may be used for recovery activities caused by a wireless network or wireless device, and for both inbound and outbound traffic. Process 700 requires more processing to determine whether each received IP packet is valid or unsolicited. However, process 700 may be more accurate in initiating dormancy early because an attempt is made to determine the validity of each received IP packet.

The values of the inactivity timer and the wait timer may be fixed values or configurable values. For example, the fixed value may be selected based on a characterization of unsolicited traffic present for the wireless network. Using a fixed value may simplify the implementation of the timer. The configurable values allow for adaptation to the operating environment, which may improve performance. For example, the timer value may be determined based on the nature of the unsolicited IP packet, wireless network behavior, and the like.

Fig. 6 and 7 show particular embodiments of identifying unsolicited IP packets and early to dormant transitions such that the impact of receiving unsolicited IP packets is mitigated. In general, unsolicited IP packets may be identified in various ways. For example, a received IP packet may be considered an unsolicited IP packet if the received IP packet (1) causes the wireless device to reactivate from dormancy (as described with respect to fig. 6), (2) is not passed on to an application or service running at the wireless device (as described with respect to fig. 7), (3) causes the wireless device to not have any replies or causes a single rejection by the wireless device, or (4) satisfies some other condition or criteria. Unsolicited IP packets may also be identified by the amount of time required for subsequent data exchanges (if any). For example, a received IP packet may be considered an unsolicited IP packet if the data exchange following the received IP packet is less than a predetermined duration. The data exchange for unsolicited IP packets is typically very short compared to the data exchange for valid IP packets. In any case, detecting a received IP packet as an unsolicited IP packet may be used to initiate dormancy earlier and thus save radio resources and battery power.

Fig. 8 shows a block diagram of an embodiment of wireless device 120. Wireless device 120 includes a wireless modem for communicating with wireless network 130, a controller 840, a memory 842, and a timer 844. On the transmit path, data and signaling to be sent by wireless device 120 are processed (e.g., formatted, encoded, and interleaved) by an encoder 822 and further processed (e.g., modulated, propagated, channelized, and scrambled) by a modulator (Mod)824 to generate a stream of data chips. A transmitter unit (TMTR)832 then conditions (e.g., converts to analog, filters, amplifies, and frequency upconverts) the data chip stream to generate a reverse link signal, which is transmitted via an antenna 836. On the receive path, forward link signals transmitted by base stations in wireless network 130 are received by an antenna 836 and provided to a receiver unit (RCVR) 838. Receiver unit 838 conditions (e.g., filters, amplifies, frequency downconverts, and digitizes) the received signal to generate data samples. A demodulator (Demod)826 processes (e.g., descrambles, despreads, channelizes, and demodulates) the samples to obtain symbol estimates. A decoder 828 further processes (e.g., deinterleaves and decodes) the symbol estimates to obtain decoded data. Encoder 822, modulator 824, demodulator 826, and decoder 828 may be implemented by a modem processor 820. These units perform processing according to the wireless technology used by wireless network 130 (e.g., W-CDMA or CDMA2000)

Controller 840 directs the operation of various units within wireless device 120 and may further execute applications and implement the protocol stacks shown in fig. 3. A memory unit 842 stores program codes and data used by controller 840 and other units. Timer 844 may implement an inactivity timer, a wait timer, and/or other timers.

Controller 840 may implement processes 400, 600, and/or 700 shown in fig. 4, 6, and 7 to mitigate the impact of receiving unsolicited IP packets. Controller 840 may receive coherence information identifying unsolicited IP packets. This information may include, for example, an indication as to whether a received IP packet resulted in a reactivation from dormancy, a destination port number of the received IP packet, and so forth. Controller 840 identifies unsolicited IP packets based on the received information and operates an inactivity timer and/or a wait timer based on the detected traffic, e.g., as described above with respect to fig. 6 and/or 7. If an unsolicited IP packet is detected, controller 840 may initiate dormancy early.

The techniques described herein may be implemented in a variety of ways. For example, these techniques may be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units that identify unsolicited IP packets and initiate early dormancy may 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, electronic devices, other electronic units designed to perform the functions described herein, or a combination thereof.

For a software implementation, the techniques may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit (e.g., memory unit 842 of fig. 8) and executed by a processor (e.g., controller 840). The memory unit may be implemented within the processor or external to the processor.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (28)

1. A wireless device, comprising:

a processor operable to receive a packet from a wireless network; and

a controller operable to determine whether the received packet is an unsolicited packet that is not requested from the wireless network and to initiate a transition to dormancy early when the received packet is considered to be an unsolicited packet.

2. The wireless device of claim 1, wherein the controller is operable to assert a received packet as an unsolicited packet when the received packet causes an out-of-sleep transition.

3. The wireless device of claim 1, wherein the controller is operable to declare the received packet to be an unsolicited packet when the received packet is not delivered to an application or service running on the wireless device.

4. The wireless device of claim 1, wherein the controller is operable to declare the received packet to be an unsolicited packet when the received packet does not result in any reply or results in a denial of reply.

5. The wireless device of claim 1, wherein the controller is operable to declare the received packet to be an unsolicited packet when a subsequent data exchange, if present, is less than a predetermined duration.

6. The wireless device of claim 1, wherein the controller is operable to reset an inactivity timer to a shortened value when the received packet is deemed to be a non-request packet, and to initiate a transition to sleep upon expiration of the inactivity timer.

7. The wireless device of claim 1, wherein the controller is operable to reset an inactivity timer to a predetermined value when the received packet is deemed not to be a non-request packet, and to initiate a transition to sleep upon expiration of the inactivity timer.

8. A method, comprising:

receiving a packet from a wireless network;

determining whether the received packet is a non-request packet that is not requested from the wireless network; and

early transition to dormancy when the received packet is considered to be a non-request packet.

9. The method of claim 8, wherein the determining whether the received packet is an unsolicited packet comprises asserting the received packet as an unsolicited packet when the received packet causes a transition out of dormancy.

10. The method of claim 8, wherein the determining whether the received packet is an unsolicited packet comprises declaring the received packet to be an unsolicited packet when the received packet is not delivered to an application or service.

11. The method of claim 8, further comprising:

resetting an inactivity timer to a shortened value when the received packet is considered to be a non-request packet; and transitioning to sleep upon expiration of the inactivity timer.

12. An apparatus, comprising:

means for receiving a packet from a wireless network;

means for determining whether the received packet is a non-request packet that is not requested from the wireless network; and means for early transition to sleep when the received packet is deemed to be a non-request packet.

13. The apparatus of claim 12, further comprising:

means for asserting the received packet as an unsolicited packet when the received packet causes a transition out of dormancy.

14. The apparatus of claim 12, further comprising:

means for declaring the received packet as an unsolicited packet when the received packet is not delivered to an application or service.

15. The apparatus of claim 12, further comprising:

means for resetting an inactivity timer to a shortened value when the received packet is considered to be a non-request packet; and

means for transitioning to sleep upon expiration of the inactivity timer.

16. A processor-readable medium for storing instructions operable in a wireless device to:

determining whether a packet received from a wireless network is a non-request packet that is not requested from the wireless network; and

initiating a transition to dormancy early when the received packet is considered to be a non-request packet.

17. The processor-readable medium of claim 16, further for storing instructions operable to:

resetting an inactivity timer to a shortened value when the received packet is considered to be a non-request packet; and initiating a transition to sleep upon expiration of the inactivity timer.

18. A wireless device, comprising:

a processor operable to receive a packet from a wireless network; and

a controller operable to determine whether the received packet is an unsolicited packet that is not requested from a wireless network, operable to use a first timer value for an inactivity timer for a predetermined duration of time when the received packet is considered to be an unsolicited packet, and operable to use a second timer value for the inactivity timer after the predetermined duration of time.

19. The apparatus of claim 18, wherein the controller is operable to reset the inactivity timer to the first timer value for each packet received during the predetermined duration.

20. The apparatus of claim 18, wherein the controller is operable to reset the inactivity timer to the second timer value for each packet received after the predetermined duration.

21. The apparatus of claim 18, wherein the predetermined duration is equal to the first timer value or the second timer value.

22. The apparatus of claim 18, wherein the controller is operable to initiate a transition to sleep upon expiration of the inactivity timer.

23. The apparatus of claim 18, wherein the first timer value is configurable.

24. A method, comprising:

determining whether the received packet is an unsolicited packet that is not solicited from the wireless network;

using a first timer value for an inactivity timer when the received packet is considered a non-request packet, wherein the first timer value is used for a predetermined duration of time; and

after the predetermined duration, using a second timer value for the inactivity timer.

25. The method of claim 24, further comprising:

resetting the inactivity timer to the first timer value for each packet received during the predetermined duration.

26. The method of claim 24, further comprising:

resetting the inactivity timer to the second timer value for each packet received after the predetermined duration.

27. The method of claim 24, wherein the predetermined duration is equal to the first timer value or the second timer value.

28. The method of claim 24, further comprising:

transitioning to sleep upon expiration of the inactivity timer.