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

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.

BACKGROUND

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

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 service 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 moment during the data session. The wireless device may be active for only a portion of the time during the data session, which may be opened for an extended period of time. For example, the wireless device may transmit and/or receive packet data in short bursts and may remain in dormancy for significant periods of time between these data bursts. Dormancy refers to a scenario in which the data session is opened but radio resources are released. To conserve battery power, which is important for a portable device such as a cellular phone, the wireless device may power down as much circuitry as possible while in dormancy. The wireless device may only wake up periodically to receive (1) page messages that alert the wireless device to the presence of an incoming call or packet data and (2) overhead messages that carry system and other information for the wireless device.

The wireless device may receive unsolicited IP packets from the wireless network while in dormancy. An unsolicited IP packet may be defined as an IP packet that is not requested by the wireless device and further has no corresponding application or service running at the wireless device. The reception of an IP packet while in dormancy typically causes the wireless device to re-establish traffic channels with the wireless network and remain in the active state for some period of time. If the received IP packet is an unsolicited IP packet, then the wireless device typically drops 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. Instead, the unsolicited IP packet wastes system resources since traffic channels are established but not used for exchanging data. The unsolicited IP packet further consumes battery power and shortens standby time since the wireless device is turned on and ready for wireless communication as a result of receiving this IP packet.

There is therefore a need in the art for techniques to mitigate the impact of receiving unsolicited IP packets.

SUMMARY

Techniques for identifying unsolicited IP packets and initiating dormancy early at a wireless device are described herein. In an aspect, an IP packet received at the wireless device may be deemed as an unsolicited IP packet if the received IP packet (1) causes the wireless device to reactivate from dormancy (e.g., transition from the dormant state to the active state), (2) is not delivered to an application or a service running at the wireless device, (3) results in no reply or a single “reject” reply by the wireless device, or (4) satisfies some other condition or criterion.

In another aspect, the wireless device initiates dormancy early for unsolicited IP packets. The wireless device receives an IP packet from the wireless network and determines whether the received IP packet is an unsolicited IP packet. 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 various mechanisms for transitioning to dormancy early. For example, the wireless device may maintain an inactivity timer while in the active state during the data session. The wireless device may reset the inactivity timer upon receiving or sending an IP packet and may transition to dormancy upon expiration of the inactivity timer. The inactivity timer may be operated with multiple timer values to mitigate the impact of unsolicited IP packets. In an embodiment, a received IP packet that causes reactivation from dormancy is deemed to be an unsolicited IP packet and results in the use of a shortened value for the inactivity timer for a predetermined time duration. A nominal value is used for the inactivity timer after this time duration. The shortened value allows the wireless device to go dormant early if reactivation was due to an unsolicited IP packet.

DETAILED DESCRIPTION

The techniques described herein to identify unsolicited IP packets and to initiate dormancy early may be used for various wireless networks. For example, these techniques may be used for a Code Division Multiple Access (CDMA) network, a Universal Mobile Telecommunications System (UMTS) network, a wireless local area network (LAN), and so on. A CDMA network may implement a radio access technology (RAT) such as cdma2000 and a networking protocol such as ANSI-41. A UMTS network may implement a RAT such as Wideband-CDMA (W-CDMA) and/or Global System for Mobile Communications (GSM) and a networking protocol such as GSM Mobile Application Part (GSM-MAP). A 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), and so on. 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. 1shows a deployment100in which a wireless device120communicates with a wireless network130to obtain communication services. Wireless device120may also be called a mobile station (MS), a user equipment (UE), a user terminal, a subscriber unit, or some other terminology. Wireless network130includes a base station142, a packet data entity144, and an IP gateway150. Base station142provides radio communication for wireless device120. Packet data entity144controls the transmission of packets between base station142and IP gateway150. IP gateway150supports data service for wireless devices in wireless network130. For example, IP gateway150may be responsible for the establishment, maintenance, and termination of data sessions for the wireless devices and may further assign dynamic IP addresses to the wireless devices. IP gateway150may couple to a data network160a, the Internet160b, and/or other data networks. IP gateway150can communicate with various entities (e.g., a remote host170) that couple to these data networks.

Wireless network130may also be viewed as being composed of a radio network140and a packet data network. Radio network140includes base station142and packet data entity144and supports radio communication. The packet data network includes IP gateway150and supports packet-switched communication between radio network140and external data networks.

Wireless network130may be a CDMA network, in which case packet data entity144is called a Packet Control Function (PCF) and EP gateway150is called a Packet Data Serving Node (PDSN). Wireless network130may also be a UMTS network, in which case packet data entity144is called a Serving GPRS Support Node (SGSN) and IP gateway150is called a Gateway GPRS Support Node (GGSN). Wireless network130may also be a wireless LAN.

FIG. 2shows an exemplary protocol stack200for data communication between wireless device120and remote host170via wireless network130. The protocol stack includes a transport layer, a network layer, a link layer, and a physical layer. Wireless device120and remote host170may 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, which are exchanged between wireless device120and remote host170via radio network140and IP gateway150.

The link layer between wireless device120and wireless network130is typically dependent on the wireless network technology. For a CDMA network, the link layer is implemented with a Point-to-Point Protocol (PPP) over a Radio Link Protocol (RLP). Wireless device120maintains a PPP session with IP gateway150for a data session and communicates with radio network140via RLP for data exchanges. RLP operates on top of an air-link interface (e.g., cdma2000). Radio network140communicates with IP gateway150via a technology-dependent interface (e.g., an “R-P” interface for a CDMA network) that operates on top of a physical layer. IP gateway150communicates with remote host170via IP over a link layer and a physical layer. The various layers may be different for other wireless networks.

FIG. 3shows an embodiment of wireless device120. At wireless device120, applications and services320execute over sockets322and a data protocol stack324. A socket is one endpoint of a two-way communication path between two applications running on a network. In the context of the Internet, a socket is associated with an IP address, a protocol at the transport layer (e.g., TCP or UDP), and a port number for the transport layer protocol. Each application running at wireless device120is associated with one or more sockets and exchanges data with external entities via the associated sockets. Each service (e.g., FTP, Telnet, and so on) may also be associated with one or more sockets. For the embodiment shown inFIG. 3, data protocol stack324utilizes TCP and/or UDP operating on top of IP. In general, a data protocol stack may implement any combination of protocols for any number of layers. Wireless device120communicates with wireless network130via a Um interface328aand may further communicate with a terminal equipment via an Rm interface328b. The terminal equipment may be a laptop computer, a personal digital assistant (PDA), or some other computing device.

Wireless device120may have an open data session with IP gateway150but may exchange data sporadically. During the data session, the wireless device may enter the active state when there is data to exchange (e.g., send or receive) and may enter the dormant state when there is no data to exchange. The wireless device transitions between the active and dormant states depending on data activity.

Wireless device120communicates with radio network140in order to exchange data with IP gateway150and remote host170. In the active state, wireless device120may establish (1) a forward link traffic channel used to receive data from radio network140and (2) a reverse link traffic channel used to send data to radio network140. In the dormant state, the wireless device relinquishes the traffic channels and may power down as much circuitry as possible in order to conserve battery power.

Wireless device120may receive an IP packet from wireless network130while in the dormant state. The received IP packet reactivates the wireless device from dormancy and causes the wireless device to reestablish the traffic channels for the forward and/or reverse links in anticipation of possible exchange of data with the wireless network. If the received IP packet is an unsolicited IP packet, then the wireless device typically drops the IP packet and/or sends a TCP reset packet and performs no other action. In this case, it is desirable to release the traffic channels and transition back to dormancy early.

FIG. 4shows a flow diagram of a process400for transitioning to dormancy early for unsolicited IP packets. Initially, an IP packet is received from the wireless network (block412). A determination is made whether the received IP packet is an unsolicited IP packet (block414). This determination may be made based on various criteria. 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, e.g., no other activity occurs (block416).

The early transition to dormancy may be achieved in various manners. Several embodiments for transitioning to dormancy early based on an inactivity timer are described below.

Wireless device120may maintain an inactivity timer while in the active state. The inactivity timer determines the amount of time to remain in the active state without exchanging any data. The wireless device may reset the inactivity timer to a nominal value upon receiving or sending an IP packet and may enter the dormant state when the inactivity timer expires. The inactivity timer allows the wireless device to release the traffic channels when data is not being exchanged, thus saving radio resources.

The nominal value for the inactivity timer is typically selected to provide good performance for expected data usage. A short inactivity timer value may result in the wireless device being timed-out and entering dormancy too quickly, which may result in loss of data, e.g., due to a delayed response from a remote server. A long inactivity timer value may result in the wireless device maintaining the traffic channels for too long without exchanging any data, thereby wasting radio resources. The nominal value is typically selected based on a tradeoff between these two factors. A nominal value of around 20 seconds has been found to provide good performance under certain data usage scenarios.

The wireless device may receive an unsolicited IP packet while in dormancy. The unsolicited IP packet results in reactivation of the wireless device and sets the inactivity timer to the nominal value. The wireless device would then need to wait until the inactivity timer expires before transitioning back to dormancy and releasing the traffic channels.

In an embodiment of early dormancy, the inactivity timer is operated with 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 dormancy. The shortened value allows the wireless device to go back to dormancy and release the traffic channels earlier if the reactivation was 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 noted above. The shortened value may be selected to achieve good performance, e.g., for the two factors noted above. 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 that is selected based on typical patterns for unsolicited traffic, network behavior, and so on. The configurable shortened value may also be restricted to be within a predetermined range of values, e.g., from one to five seconds.

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

FIG. 6shows a flow diagram of a process600for operating the inactivity timer with multiple values. Initially, an IP packet is received from the wireless network (block612). A determination is made whether the received IP packet causes the wireless device to reactivate from dormancy (block614). If the answer is ‘Yes’, then the inactivity timer value is set equal to the shortened value (block616) and the wait timer is reset to the wait period (block618). Otherwise, if the answer is ‘No’ for block614, then the inactivity timer value is set equal to the nominal value (block620). The inactivity timer is then reset to the current inactivity timer value, which may be the shortened value or the nominal value depending on whether the wireless device was reactivated from dormancy by the received IP packet (block622). The inactivity timer and the wait timer each count down or up after being reset and expire upon reaching the value loaded in the timer.

Thereafter, a determination is made (e.g., periodically) whether another IP packet is exchanged with the wireless network (block624). If the answer is ‘Yes’, then the process returns to block622and the inactivity timer is reset to the current inactivity timer value. Otherwise, if the answer is ‘No’ for block624, then a determination is made whether the inactivity timer has expired (block626). If the answer is ‘No’ for block626, then a determination is made whether the wait timer has expired (block630). If the answer is ‘Yes’ for block630, then the inactivity timer value is set equal to the nominal value, which is used for the inactivity timer from this point forward (block632). From block632and also if the answer is ‘No’ for block630, the process returns to block624.

If the inactivity timer has expired and the answer is ‘Yes’ for block626, then the wireless device initiates dormancy and releases the traffic channels (block628). The process then terminates. Although not shown inFIG. 6, the inactivity timer value may be set equal to the nominal value when the wireless device goes dormant for any reason. This ensures that the nominal value is used if the wireless device thereafter sends an IP packet to the wireless network.

For process600, a received IP packet that causes reactivation from dormancy also results in the shortened value being used 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, then the wireless device initiates dormancy after the shortened period has elapsed and the inactivity timer expires. This early transition to dormancy reduces the amount of time the traffic channels are unnecessarily established. For example, if the nominal value is 20 seconds and the shortened value is 5 seconds, then dormancy may be initiated up to 15 seconds earlier. The early dormancy conserves both radio resources for the wireless network and battery power for the wireless device. Conversely, if the received IP packet is a valid IP packet, then other IP packets may be exchanged thereafter and the inactivity timer would be reset after each IP packet exchange. If the wireless device does not go dormant for the entire wait period, then the nominal value is used for the inactivity timer. The wireless device would then operate in the same manner as in the conventional case.

Process600relies on assumptions that (1) unsolicited IP packets are received sporadically, so that the inactivity timer is not continually reset by inbound unsolicited IP packets, and (2) subsequent IP packets are not exchanged in response to receiving unsolicited IP packets, so that the inactivity timer is not reset by outbound IP packets. Process600is simple to implement. However, performance is dependent on the accuracy of the underlying assumptions.

FIG. 6shows a specific embodiment in which two values are used for the inactivity timer, and the shortened value is used for the entire wait period. In another embodiment, the shortened value is used whenever a received IP packet causes reactivation from dormancy, and the nominal value is used once a valid IP packet is received or sent. A received IP packet may be deemed to be a valid IP packet if, e.g., it is delivered to an application or a service running at the wireless device. The wait timer is not needed for this embodiment. In yet another embodiment, the 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 upon receiving the valid IP packet. In yet another embodiment, the shortened value is used only for the first received IP packet that causes reactivation from dormancy, and the nominal value is used thereafter. For this embodiment, it is not necessary to maintain the wait timer.

In yet another embodiment, more than two values are used for the inactivity timer. For example, each received IP packet may result in the inactivity timer being reset with a progressively longer value, from the shortest value to the nominal value. The first received IP packet may result in the inactivity timer being reset with the shortest value, the next received IP packet may result in the inactivity timer being reset with a longer value, and so on, and the n-th received IP packet may result in the inactivity timer being reset with 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 the detected traffic. A single value or multiple values may be used for the inactivity timer. The inactivity timer is not automatically reset upon receiving an inbound IP packet or sending an outbound IP packet. Instead, the inactivity timer is selectively reset whenever an IP packet is deemed to be a valid IP packet.

FIG. 7shows a flow diagram of a process700for selectively resetting the inactivity timer. Initially, an IP packet is received from the wireless network (block712). This received IP packet may or may not have caused reactivation from dormancy. The destination for the received IP packet within the wireless device is then determined (block714). This may be achieved by (1) examining a destination port number for the received IP packet and (2) determining whether an application or service is listening on this port number. For example, a web application may be running at the wireless device and may use a particular port to send out data. An inbound IP packet destined for this port would be delivered to the web application. The web application may be viewed as having silently solicited the traffic. An inbound IP packet may thus be considered as a valid IP packet if it is destined for a port associated with an application or service running at the wireless device.

A determination is then made whether the received IP packet was delivered to an application or a service running at the wireless device (block716). If the answer is ‘Yes’, then the received IP packet is deemed to be a valid IP packet and the inactivity timer is reset to the nominal value (block718). Otherwise, if the received IP packet is not delivered to an application or service, then the inactivity timer may be allowed to continue (i.e., not reset) or may be reset to a shortened value (block720). After blocks718and720, the process proceeds to block722.

In block722, a determination is made (e.g., periodically) whether an outbound IP packet is sent by the wireless device to the wireless network. If the answer is ‘Yes’, then the process returns to block718and the inactivity timer is reset to the nominal value. Otherwise, a determination is made whether an inbound IP packet is received from the wireless network (block724). If the answer is ‘Yes’, then the process returns to block714to determine the destination for the received IP packet. If an IP packet was not received and the answer is ‘No’ for block724, then a determination is made whether the inactivity timer has expired (block726). If the answer is ‘No’, then the process returns to block722. Otherwise, if the inactivity timer has expired and the answer is ‘Yes’ for block726, then the wireless device initiates dormancy and releases the traffic channels (block728). The process then terminates.

For process700, the inactivity timer is reset to the nominal value by either a valid received IP packet or an outbound IP packet. The inactivity timer is thus reset to the nominal value whenever valid traffic is detected. The inactivity timer is not reset, or is reset to the shortened value, by an unsolicited IP packet that is not delivered to an application or service running at the wireless device, which may then result in early transition to dormancy.

Process700may be triggered by a received IP packet that causes reactivation from dormancy, as indicated inFIG. 7. In general, process700may be used for reactivation caused by the wireless network or the wireless device and for both inbound traffic and outbound traffic. Process700requires more processing to determine whether each received IP packet is valid or unsolicited. However, process700may be more accurate at initiating dormancy early since an attempt is made to ascertain the validity of each received IP packet.

The values for the inactivity timer and the wait timer may be fixed values or configurable values. For example, fixed values may be selected based on characterization of unsolicited traffic that exists for the wireless network. The use of fixed values can simplify implementation of the timers. Configurable values allow for adaptation to the operating environment, which may improve performance. For example, the timer values may be determined based on the nature of the unsolicited IP packets, the wireless network behavior, and so on.

FIGS. 6 and 7show specific embodiments of identifying unsolicited IP packets and transitioning to dormancy early so that the impact of receiving unsolicited IP packets is mitigated. In general, unsolicited IP packets may be identified in various manners. For example, a received IP packet may be deemed as an unsolicited IP packet if it (1) causes the wireless device to reactivate from dormancy, as described forFIG. 6, (2) is not delivered to an application or service running at the wireless device, as described forFIG. 7, (3) results in no reply or a single reject by the wireless device, or (4) satisfies some other condition or criterion. An unsolicited IP packet may also be identified by the amount of time required for a subsequent data exchange, if any. For example, if a data exchange following a received IP packet is shorter than a predetermined time duration, then the received IP packet may be deemed as an unsolicited IP packet. A data exchange for an unsolicited IP packet is typically quite short in comparison to a data exchange for a valid IP packet. In any case, the detection of received IP packets as unsolicited IP packets may be used to initiate dormancy earlier and hence conserve both radio resources and battery power.

FIG. 8shows a block diagram of an embodiment of wireless device120. Wireless device120includes a wireless modem for communication with wireless network130, a controller840, a memory842, and timers844. On the transmit path, data and signaling to be sent by wireless device120are processed (e.g., formatted, encoded, and interleaved) by an encoder822and further processed (e.g., modulated, spread, channelized, and scrambled) by a modulator (Mod)824to generate a stream of data chips. A transmitter unit (TMTR)832then 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 antenna836. On the receive path, forward link signals transmitted by base stations in wireless network130are received by antenna836and provided to a receiver unit (RCVR)838. Receiver unit838conditions (e.g., filters, amplifies, frequency downconverts, and digitizes) the received signal to generate data samples. A demodulator (Demod)826processes (e.g., descrambles, despreads, channelizes, and demodulates) the samples to obtain symbol estimates. A decoder828further processes (e.g., deinterleaves and decodes) the symbol estimates to obtain decoded data. Encoder822, modulator824, demodulator826, and decoder828may be implemented by a modem processor820. These units perform processing in accordance with the wireless technology (e.g., W-CDMA or cdma2000) used by wireless network130.

Controller840directs the operation of various units within wireless device120and may further execute the applications and implement the protocol stack shown inFIG. 3. Memory unit842stores program codes and data used by controller840and other units. Timers844may implement the inactivity timer, the wait timer, and/or other timers.

Controller840may implement processes400,600and/or700shown inFIGS. 4,6and7to mitigate the impact of receiving unsolicited IP packets. Controller840may receive pertinent information used to identify unsolicited IP packets. This information may include, e.g., an indication as to whether a received IP packet causes reactivation from dormancy, the destination port number for the received IP packet, and so on. Controller840identifies unsolicited IP packets based on the received information and operates the inactivity timer and/or wait timer based on the detected traffic, e.g., as described above forFIGS. 6and/or7. Controller840may initiate dormancy early if unsolicited IP packets are detected.

The techniques described herein may be implemented by various means. For example, these techniques may be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units used to identify unsolicited IP packets and initiate dormancy early 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 unit842inFIG. 8) and executed by a processor (e.g., controller840). The memory unit may be implemented within the processor or external to the processor.