HK1242060A1 - Techniques for managing idle state activity in mobile devices - Google Patents

Description

Techniques for managing idle state activity in a mobile device

Cross Reference to Related Applications

This application claims priority from U.S. provisional patent application No. 61/450,070 filed on 7/3/2011 and incorporated herein by reference in its entirety.

Background

Today, mobile communication devices are flooded with mobile data applications, including so-called "always-on" applications, which can send periodic messages to keep application sessions "alive" between different devices that can be remotely connected to each other. Additionally, other applications may periodically generate status update messages that provide messages between remotely coupled devices. These types of messages may be generated even when the mobile communication device is otherwise inactive, resulting in frequent transitions between idle and active states, which may unduly consume device power.

In view of these and other considerations, the present improvements are needed.

Drawings

Fig. 1 depicts a system consistent with various embodiments.

Fig. 2 depicts various messaging (messaging) scenarios facilitated by the system of fig. 1.

Fig. 3 depicts a conventional messaging scenario.

Fig. 4 depicts a messaging scenario consistent with the present embodiments.

Fig. 5 depicts a messaging scenario of another scenario consistent with the present embodiments.

Fig. 6 presents a comparison of a first curve of conventional UE operation with a second curve of UE operation consistent with the present embodiment.

Fig. 7 depicts a UE arranged in accordance with additional embodiments.

Fig. 8 depicts details of a network message aggregation module consistent with further embodiments.

Fig. 9 depicts details of another network message aggregation module, consistent with further embodiments.

Fig. 10 depicts details of a further network message aggregation module consistent with other embodiments.

FIG. 11 depicts one embodiment of a middleware module, wherein the middleware module is a keep-alive agent.

Fig. 12 depicts an embodiment of a network in which a network server includes a proxy module.

Fig. 13 depicts an exemplary logic flow.

Fig. 14 depicts another exemplary logic flow.

Fig. 15 depicts a further exemplary process flow.

FIG. 16 is a diagram of an exemplary system embodiment.

FIG. 17 illustrates an embodiment of an exemplary computing architecture.

Detailed Description

Various embodiments relate to reducing frequent idle and active transitions that may occur in a mobile device, and in particular to reducing the frequency of content and presence update messages and keep alive messages generated by a mobile data application.

In various embodiments, the message may be carried by an operator managing the radio access network and the core network to provide data to and from the mobile device. Some embodiments of the communication system may be implemented with radio technologies such as: institute of Electrical and Electronics Engineers (IEEE) 802.16 (WiMAX), IEEE 802-20, third Generation partnership project (3 GPP) evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio Access (UTRA) (E-UTRA), and so on. IEEE802.16 m is an evolution of IEEE802.16e and provides backward compatibility with IEEE802.16 based systems. UTRA is part of UMTS. The 3GPP Long Term Evolution (LTE) is part of an evolved UMTS (E-UMTS) that uses E-UTRA. LTE-advanced (LTE-a) is an evolution of 3gpp LTE. As used herein, any reference to the term "LTE" includes any version of LTE, which includes LTE-a and its revisions, progeny, and variants. The embodiments are not limited in this context.

Today, devices such as smart phones, tablet computing devices, and other devices may support a large number of mobile data applications, which may number in the hundreds of thousands. Many of the applications on mobile devices utilize broadband connections provided for linking mobile devices to provide various types of communications to the mobile devices. While some applications employ more traditional usage modes, such as web browsing and email reading, mobile devices are often configured with newly emerging applications, including social networking applications that allow users to "stay connected" with other users.

Currently, some existing "always-on" mobile data applications involve interactive communication with their application servers in the internet through the operator network. The server and applications residing on the mobile device (UE) periodically exchange "heartbeat" messages (also referred to as keep-alive) to keep the application session alive and also avoid expiration of Network Address Translation (NAT) mappings that cause the IP session to disconnect.

In addition to regular keep-alive messages, mobile data applications may also generate frequent status update messages to notify users of status updates related to the application. Some examples include presence information of buddies in an Instant Messaging (IM) buddy list, updates to the user's location when the user "check in", updates to the user's friends ' Facebook likes ", and so forth.

Thus, to facilitate maintaining a connection between a mobile device and another device, various mobile data applications may generate frequent communications, such as status update messages or keep-alive signals, even when there is no other data or content to transmit at the time of such messages. These communications, in turn, may cause the mobile device to frequently transition between idle and active modes in order to communicate communications scheduled by a given mobile data application. For example, to prevent loss of its connection, a voice over internet protocol (VoIP) application running in a mobile device typically needs to wake up periodically and report to its server. In particular, VoIP applications such as Skype and frying can generate keep-alive messages at intervals ranging from every 30 seconds to every 8 minutes. In addition, the social networking applications, e.g., Facebook FindMe applications, generate state update messages when the geographic location of the mobile device changes. The frequency of such messages may range from sporadic, e.g., when changing location from home to work, to periodic, where the period may be every 60 seconds (as frequency as average 60 seconds).

Frequent sending of keep-alive or status update messages may thus result in excessive signaling overhead in both the Radio Access Network (RAN) and the Core Network (CN) used to carry the messages, and may consume excessive power at the mobile device or "user equipment" (UE). In particular, various communication standards may require procedures that cause excessive power consumption and signaling to focus on such messages. For example, according to 3GPP TS 23.401 (third generation partnership project; technical specification group services and system aspects; General Packet Radio Service (GPRS) enhancements for evolved universal terrestrial radio access network (E-UTRAN) access (release 10) (9/2011), hereinafter "TS 23.401"), upon detection of user inactivity, the eNB (base station) may initiate an S1 release procedure to move the UE from an Evolved Packet System (EPS) connection management (ECM) state (e.g., ECM connected state) to an ECM idle state. Thus, when the average frequency of background messages is greater than the inactivity timer at the eNB, the UE is required to cycle through idle, wake up, reestablish connection, communicate update messages, back to idle in order to communicate these status update messages.

Furthermore, various aspects involved in typical operations of status updates and/or keep-alive messages may exacerbate their degree of impact on such features as signaling overhead and power consumption. First, these messages may be Mobile Originated (MO) or Mobile Terminated (MT). For example, the periodic FindMe message may be triggered by a change in location of a second device in communication with the user's device or may be triggered when the user's device changes location. Second, mobile devices often have installed multiple applications that each autonomously generate status updates, keep-alive, or similar messages. Thus, the aggregation of status updates and keep-alive messages from multiple mobile data applications can cause non-negligible and frequent (e.g., every 30 seconds to every few minutes) background traffic even when the user is not performing direct interaction with the mobile device.

In particular, the present embodiments address issues identified for updating current 3GPP standards (technical report 22.801, § 5.2, 6; third generation partnership project; technical specification group services and system aspects; non-MTC mobile data application impact study (Release 11) (08/2011)). In particular, several proposed improvements have been identified and specified: 1) the network should be able to provide the ability to reduce the overhead associated with the transmission of huge amounts of small data packets generated by non-MTC mobile data applications; 2) the definition of a small amount of data should be configurable according to network operator policies; 3) the system should be able to provide the ability to minimize the signaling surge caused by mobile data application behavior such as keep-alive, status update, instant messaging, etc.; 4) the system should be able to provide the ability to classify the type of packets generated by the mobile data application; 5) the system should be able to apply the packet using an optimized service delivery mechanism for different types/classes of data; 6) the system should be able to provide mechanisms to optimize traffic due to a large number of real-time (live) streaming sessions of the same content (e.g., merging of unicast streams delivering the same content) from a given source outside the 3GPP network; 7) mechanisms should be provided that allow the network and UE to detect abnormally high data patterns (patterns) and provide countermeasures to protect the network and subscribers from data surges caused by mobile data applications intentionally (e.g., due to design) or accidentally (e.g., due to poor implementation); 8) the system should be able to provide a mechanism for efficiently managing the delivery of simultaneous push services (e.g., by taking into account the network status and timing requirements associated with each push service).

In some embodiments, the impact of the automatic generation of status updates and keep-alive messages may be addressed by aggregating status update traffic at the network side and/or UE side to reduce the frequency of update/keep-alive messages sent over the air interface between the UE and the network. This, in turn, may reduce signaling overhead and UE power consumption associated with frequent active-idle transitions.

The present embodiment takes advantage of the fact that many messages automatically generated by mobile data applications may be delay tolerant. In some embodiments, the transmission of messages generated by a given application, such as content and presence status update messages, may be delayed to the extent that the given application can tolerate while reducing the frequency of active-idle transitions in a mobile device hosting (host) the application. In particular, it is noted that a large portion of content and presence update messages from social networking applications (hereinafter also referred to as "applications") may be somewhat delay tolerant in terms of the frequency with which such status update messages are transmitted. Thus, the present embodiments facilitate merging or aggregating multiple status update messages generated at different instances such that some status update messages are not transmitted over the air when generated by an application. Rather, multiple status update messages generated by the mobile data application over a specified period of time may be stored and transmitted in a common batch.

For example, in one embodiment, an apparatus, such as a UE, may include a Radio Frequency (RF) transceiver and a message aggregation module. The message aggregation module is executable by the processing circuit to intercept a plurality of messages from one or more mobile data applications during an idle mode of the device. One or more of the plurality of messages may trigger a transition of the device from the idle mode to the connected mode by causing a radio resource control message to be sent from the device to the radio access network. The message aggregation module may store a plurality of messages in a buffer associated with one or more mobile data applications to maintain the device in an idle mode, and schedule the stored messages for transmission through the RF transceiver at defined time instances based on a delay tolerance of the one or more mobile data applications while the device is in a connected mode. Other embodiments are described and claimed.

Fig. 1 depicts a system 100 consistent with various embodiments. The architecture of system 100 includes a mobile device or User Equipment (UE) 102, a Radio Access Network (RAN) 104, a core network 106, and an application server 108. RAN 104 and core network 106 may be part of a single operator network that carries data to and from UE 102. Application server 108 may be a public server coupled to a public network, such as the internet. In the embodiment explicitly illustrated in fig. 1, UE102 includes a mobile data application 110, a middleware module 112, a processor 114, and a transceiver 116. The middleware module 112 (the operation of which is described in detail below) may act to reduce the overall frequency of active-idle transitions occurring in the UE102 by reducing the frequency of messages sent over the air from the UE102 to the RAN 104. The messages whose frequency is reduced by the middleware module 112 may include background traffic messages generated by the mobile data application, such as status update messages and keep-alive messages.

In the embodiment of fig. 1, the core network 106 includes known functions 118 and an aggregation/proxy module 120, the operation of which is also described in detail below. In some embodiments, the aggregation/proxy module 120 may be used to reduce traffic for status update messages and keep-alive messages for the UE102, thereby reducing the frequency with which the UE102 receives such messages, with a resultant reduction in active-idle transitions in the UE 102. In various embodiments, the middleware module 112 and/or the aggregation/proxy module 120 may aggregate background traffic messages to reduce the transmission frequency of such messages during periods when the UE102 is idle or when the UE102 is active. In the latter case, although aggregation of background traffic messages during the active period may not generally reduce the frequency of active-idle transitions for the UE102, signaling overhead may be reduced by the reduced frequency of transmission of background traffic messages.

Fig. 2 depicts various messaging scenarios facilitated by the system 100. In some instances, the mobile data application 110 may automatically generate messages at predetermined intervals, periodically or upon detection of a triggering event (e.g., a change in geographic location).

In embodiments where the mobile data application 110 is an application that generates the status update messages 202, the status update messages 202 may be aggregated at the middleware module 112. The middleware module 112 may periodically send a message 204 to the application server 108, where the message 204 may contain a plurality of status update information 202 generated at different instances in the application server 108. This may be used to reduce the number of instances in which the UE102 transitions between active and idle states. The inventors have recognized that mobile data applications, such as keep-alive messages and status update messages, may exhibit delay tolerance. The term "delay tolerance" as used herein refers to a period of time during which a message may be retained by an entity, e.g., a UE, from delivery to an intended recipient, e.g., a server, in a manner that keeps the operation of the application within tolerable limits after generation by the application.

In addition, the aggregation/proxy module 120 may be used to aggregate incoming messages, such as status update messages 208, which may be sent periodically or sporadically from the application server 108. A message 206 comprising a plurality of messages 208 sent by the application server 108 at different instances may be sent from the aggregation/proxy module 120. For example, if the application server 108 is a social networking server, the application server 108 may push content and presence update messages to a subscriber of the UE102, where the subscriber's friends perform activities such as "like" a particular item or "become" a particular group of "fans". Such content and frequency of presence update messages may be every few minutes (as soft as every other new minutes) for a given mobile data application. Thus, aggregation of such messages into a single message 206 may also be used to reduce the number of instances in which the UE102 transitions between active and idle states, as explained further below.

Similarly, in embodiments where the mobile data application 110 generates keep-alive messages 212, the keep-alive messages 212 may be aggregated for sending multiple keep-alive messages from the transceiver 116 at a single instance. Likewise, keep-alive messages 210 sent from the application server 108 may be aggregated in the aggregation/proxy module 120 for forwarding to the UE102 at a single instance. The aggregation/proxy module 120 may be located in any convenient location along the communication path to intercept messages generated by the mobile data application that may be transmitted from a party, such as the application server 108. For example, in an embodiment where the operator operates a mobile WiMAX network, the aggregation/proxy module 120 may reside in an access service network gateway (ASN-GW). In embodiments where the operator runs a 3GPP-LTE network, the aggregation/proxy module 120 may be located, for example, in a serving gateway (S-GW) that routes and forwards user data packets, and may terminate the downlink data path. The aggregation/proxy module 120 may alternatively be located in a packet data network gateway (P-GW) of a 3GPP-LTE network that provides connectivity of the UE to external packet data networks.

In some embodiments, the aggregation/proxy module 120 may store together different messages to be transmitted in the downlink to different respective UEs (which may be served by a common operator controlling the core network 106).

To further illustrate the operation of the present embodiment, fig. 3 depicts a conventional scenario and fig. 4 depicts a scenario consistent with the present embodiment in which a UE transitions between different states (modes) in response to a message generated by a mobile data application. In fig. 3, the variation of UE power over time is shown for a scenario in which a regular UE302 communicates with the application server 108. Curve 300 is intended to generally illustrate the power consumed by a UE.

As illustrated, the UE may initially be in an active mode represented by power level 304. In the active mode, a radio (not shown) of the UE may be powered on and various applications may run in the UE 302.

After certain intervals in which there is no communication air traffic between the UE302 and its associated RAN (not shown), the UE302 may at time t₁Automatically transitioning to idle mode. In the idle mode, the radio and related circuitry may be in a quiescent state, resulting in lower power consumption as represented by power level 308. As illustrated, the UE302 may remain in idle mode until t₂. At time t₂Here, the status update message 320 is generated by the first mobile data application 310 running on the UE 302. Generation of the status update message 320 triggers the radio and related circuitry to power on, and an uplink control signal 316 is sent by the UE302 to establish a connection with its RAN, followed by receipt of a downlink control signal in response. The status update message 320 is then wirelessly transmitted by the UE 302. During control signaling and transmission of the status update message, the UE302 may spend additional power, represented by power level 308, until time t₃Until now. The power level of the UE302 is then reduced to an active power level 306 specific to the active mode in which the radio is powered upThe circuit is powered on but does not receive or transmit data. Because the UE302 may be set to remain in the active mode for a predetermined period of time after waking up, the UE302 then remains in the active mode until time t₄Until now, even if no additional communication takes place.

At time t₄The UE302 transitions back to the idle mode represented by the power level 306 until a subsequent time t₅Until now. At time t₅At this point, the second mobile data application 312 running in the application server 108 triggers the sending of a status update message. The control signal 322 is received by the UE302, which causes the UE302 to wake up and return a control signal 324. The UE302 may then return a status update message 326. Again, the power level consumed by the UE302 during this period of signaling and data transmission may be represented by power level 308. The UE302 then at time t₆Returns to the active mode and remains at the power level 304 for a predetermined duration until time t₇Until now. When the active mode is at time t₇At "time out," UE302 may turn off the radio again and enter an idle mode, represented by power level 308.

At time t₈At this point, the third mobile data application 314 running in the UE302 generates a status update message that triggers the UE302 to exit the idle mode. An uplink control signal 328 is sent and a downlink control signal 330 is received, after which a status update message 332 is transmitted by the UE302, and the power consumed by the UE302 during this period of signaling and data transmission may be represented by the power level 308. Subsequently, at time t₉At this point, the UE302 returns to the active mode power level represented by power level 304 and may remain in the active mode for a predetermined duration until time t₁₀Until time t₁₀The UE302 may then transition to the idle state.

It is noted that the scenario generally depicted in fig. 3 may be extended in time such that each mobile data application 310, 312, 314 periodically or sporadically generates a message, e.g., a status update message, which triggers a transition of the UE302 from idle to active mode. As is apparent from examination of the curve 300, such a status update message may cause the UE302 to spend an excessive amount of time in either the active mode (level 304) or the transmit signal (curve 308), both of which consume excessive power. Furthermore, the periodic or sporadic generation of individual status update messages may cause excessive signaling overhead as depicted in fig. 3.

To summarize the problems caused by the behavior illustrated in fig. 3: as the UE continually flips between active and idle states, a number of problems are observed. In one example, increased control plane signaling occurs. In particular, there is an excessive amount of signaling overhead (both in the Radio Access Network (RAN) and in the Core Network (CN)) needed to just send these occasional, very small update messages. To send only one update message, it may take one round of idle-active transitions, which may incur significant signaling overhead, including multiple Radio Resource Control (RRC) messages in the RAN (e.g., service request, radio bearer establishment/release, and paging (paging) when the message is MT) and EPC signaling messages (e.g., service request, connection setup/release). The RRC Protocol and RRC connection request are defined in other 3GPP specifications, such as 3GPP TS 25.331 entitled "Technical Specification Group Radio Access Network", Radio Resource Control (RRC), Protocol Specification, Release 10 ", dated 2011, 10/2 (e.g., section 8.1.3.3). The second major issue is reduced battery life of the UE 302. In a worst case scenario, when multiple applications generate update messages shortly after the UE302 enters the idle state, the energy consumption of the UE302 increases due to the constant rollover between active and idle states, which may be higher than if the phone only remains in active mode.

Table 1 provides a summary of the problem scenario, the source of the problem, and the affected elements of the frequent idle-active state transition scenario.

TABLE 1 Signaling inefficiencies and reduced battery life caused by Mobile data application status updates and keep-alive messages

In the embodiment whose operation is depicted in fig. 4, these problems are addressed by providing a module in the UE102 and/or the network to manage the transmission of status update messages. Fig. 4 depicts a scenario in which multiple status update messages are generated from the UE side, which may be generated by two different mobile data applications in some embodiments. As illustrated by curve 402, the UE102 may initially be in an active power mode characterized by power level 304. In some embodiments, the active mode may correspond to an ECM connection state defined in section 4.6.3.2 of 3GPP TS 23.401. In the 3GPP standard, an Evolved Packet System (EPS) is defined that provides IP connectivity through a Radio Access Network (RAN). Two EPS Connection Management (ECM) states are defined: ECM idle and ECM connected. In the ECM idle mode, there is no non-access stratum signaling between the UE and a Mobility Management Entity (MME) connected to the core network of the RAN. In the ECM-connected state, there is signaling between the mobile terminal (UE) and the MME including signaling on the S1 interface, which may be used to transmit the first message.

At time t₁At this point, the UE may automatically transition to an idle mode, represented by power level 306. In some embodiments, this active mode may correspond to the ECM-idle mode defined in section 4.6.3.1 of 3GPP TS 23.401 and discussed above. As noted above, this may occur according to a predetermined duration set for the UE to remain in the active mode without receiving or transmitting any traffic. In one example, the predetermined duration may be determined by a timer in a base station (not shown) of the RAN 104, which may send an RRC connection release message to the UE after an inactivity period corresponding to the predetermined duration that causes the UE S1 connection to the MME to be released and the UE to transition to the ECM-idle mode.

At time t₁₁At this point, mobile data application 404 generates a status update message 406. The status update message 406 is forwarded to the middleware module 112. The middleware module may store the status update message 406 instead of forwarding the status update message 406 for transmission. Consistent with various embodiments, the middleware module 112 may be arranged to allow for the transmission of status update messages only according to a predetermined procedure. For example, the middleware module 112 may be arranged to schedule the transmission of any received status update messages only at fixed intervals. Any messages received between the first transmission time and the next scheduled transmission time of the status update message may be stored without transmission. Thus, referring also to FIG. 1, at time t₁₁No state update message is sent to the transceiver 116 for transmission. There is no need for the UE102 to exit the idle mode and the power consumption of the UE102 remains at the power level 306.

Subsequently, at time t₁₂At this point, the status update application 408, also running in the UE102, may generate a second status update message 410 that is intercepted by the middleware 112. At a time t₁₂At the instance of time represented, middleware 112 may determine that second status update message 410 is to be retained until a subsequent time corresponding to a next scheduled instance for transmitting the status update message. Accordingly, the UE102 may remain in idle mode and the power consumption of the UE102 remains at the power level 306.

At a time t₁₃At subsequent instances of the representation, the middleware module 112 may determine that a time has arrived for transmission of any queued (stored) state update messages. The UE102 may thus transition out of idle mode and send an uplink control signal 414 to initiate communication, followed by receipt of a downlink control signal 416. Subsequently, status update messages 406 and 408 may be transmitted by the UE 102. In some embodiments, the status update messages may be sent in the same batch of messages, e.g., within the same uplink communication frame or within the same uplink communication subframe. During this time, the UE102 may consume power, as represented by power level 308, as shown. At time t₁₄At this point, UE102 may reduce power consumption to an active power mode characterized by power level 306. Subsequently, at time t₁₅At this point, the UE102 may transition back to idle mode.

FIG. 5 depicts a field similar to FIG. 4In which multiple status update messages are generated from the UE side, which in some embodiments may be generated by two different mobile data applications. Additionally, in the scenario depicted in FIG. 5, a mobile data application 420 residing in application server 108 is at time t₁₆Generates a status update message 422, time t₁₆May be at time t₁And t₁₄In the meantime. Application server 108 may be linked to UE102 to facilitate operation of one or more mobile data applications, including application 420. Consistent with the present embodiment, the aggregation/proxy module 120 may intercept the status update message 422 and prevent the status update message 422 from being passed until a later time instance. In this way, the UE102 is at time t₁₆Does not receive any communication and continues in idle mode as characterized by power level 306. In some embodiments, subsequent time instances for sending the status update message 422 may be determined solely by the aggregation/proxy module 120, and the aggregation/proxy module 120 may be located in the operator network serving the UE102, as noted above. However, in other embodiments, the sending of the status update message 422 may be coordinated with the UE 102.

As further illustrated in FIG. 5, another mobile data application 424 resident in the application server 108 may be at time t₁₇Generates a status update message 426, time t₁₇Can also be located at time t₁And t₁₄In the meantime. The aggregation/proxy module 120 may also intercept the status update message 426 and prevent the status update message 426 from being passed until a subsequent time instance. In this way, at time t₁₇The UE102 that is not receiving any communication remains in idle mode characterized by the power level 306.

In the embodiment explicitly depicted in FIG. 5, at time t₁₃At this point, the middleware module 112 may determine that a time has arrived for transmission of any queued (stored) state update messages. The UE102 may thus transition out of idle mode and send status update messages 406 and 408, as in the scenario of fig. 4. Additionally, the aggregation/proxy module 120 may communicate status update cancellation during the same time period as may be communicated by the UE102 as shownAnd messages 422 and 426. During this time, the UE102 may consume power as represented by power level 306, as shown. At time t₁₈At this point, UE102 may reduce power consumption to an active power mode characterized by power level 304. Subsequently, at time t₁₉At this point, the UE102 may transition back to idle mode.

In both scenarios depicted in fig. 4, 5, the number of instances that the UE102 is required to transmit and receive control signals is reduced compared to the conventional operation of the UE302 shown in fig. 3. In addition, the total duration in the active mode (power level 304) or the signaling mode (power level 306) is reduced in the scenarios of fig. 4, 5. To further highlight the advantages provided by the present embodiment, fig. 6 presents a comparison of a curve 300 for normal operation of a UE providing a status update message and a curve 402 for operation of the UE consistent with the present embodiment. It is apparent that under normal operation, the UE may spend most of the time operating in active mode or signaling mode, while the present embodiments may reduce the total active and signaling mode time such that a greater portion or even most of the time (when the UE is not otherwise busy) is spent in idle mode.

In various other embodiments, an aggregation/proxy module in the network and/or the UE may be used to aggregate keep-alive messages similar to the operations depicted in fig. 4-6 for status update messages. Turning again to fig. 1, the middleware module 112 is operable to aggregate keep-alive messages generated by mobile data applications. It is further noted that the delay tolerance may vary among different applications. Thus, consistent with further embodiments, the UE and/or the network aggregation/proxy module may be operable to set different time periods for the aggregation of messages generated by an application depending on the particular application or application type used to generate the message. For example, a given VOIP application may exhibit less (or more) delay tolerance than a mobile data application that generates status update messages.

Fig. 7 depicts a UE 702 arranged in accordance with additional embodiments. The UE 702 may include a plurality of applications, including mobile data applications. As illustrated, the UE 702 contains a mobile data application module 703 that includes a VOIP application 704 and a social networking application 706, which are two exemplary mobile data applications among many that may be implemented by the mobile data application module 703. Each of these applications, when run on UE 702, may generate sporadic or periodic messages to be transmitted via transceiver 116 to a receiving entity, such as a server or other device hosting (host) UE 702 or otherwise interacting with UE 702 to facilitate the application. The UE 702 also includes a middleware component, referred to herein as a message aggregation module 708, that functions to aggregate messages to be transmitted by the transceiver 116. Message aggregation module 708, which may be embedded in the operating system of UE 702 in some embodiments, includes an application determination module 710 and a message scheduling module 712. Application determination module 710 may be operable to receive messages generated by mobile data application 703 (including VOIP application 704 and social networking application 706) and may ascertain the exact application of the type or generating a given message.

Such mobile data applications may include social networking applications such as Facebook, Linkedin, etc.; an instant messaging application; a social networking service application; various email applications; voice over IP applications including Skype; a geo-services application including targeted advertisements; news and weather applications; and other applications that may generate messages from the mobile terminal or from the network or both.

In one example, the signature of each application may be known to the operating system of the control message aggregation module 708 at the time of installation of each application in the UE 702. Thus, the application determination module 710 may simply examine the incoming message for a signature indicative of the application that generated the message. Application determination module 710 may forward this information to message scheduling module 712, which may schedule the transmission of a given message for transceiver 116 according to the time the message was received by message aggregation module 708 and the information regarding the type of message provided by application determination module 710.

In operation, the message scheduling module 712 may include a buffer or buffers for storing messages. For example, the first message may be placed in the first buffer when the first message constitutes a first background traffic message that includes a status update or keep-alive message. The application determination module 710 may ascertain that the second mobile data application has generated the second message such that the message scheduling module 712 places the second message in the second buffer when the second message constitutes a second background traffic message different from the first background traffic message.

The message scheduling module 712 may be operable to schedule messages stored in the first buffer for transmission at the first instance; and scheduling the messages stored in the second buffer for transmission at a second instance different from the first instance.

Further, the message determination module may determine a message type, e.g., a status update message type, for each of the plurality of status update messages, and the message scheduling module 712 may schedule each status update message for transmission according to an interval for the determined status message type.

Thus, the message scheduling module 712 may aggregate messages of the first type in the first buffer using the first aggregation period and may aggregate messages of the second type in the second buffer using the second aggregation period. Each aggregation period may be arranged such that any given message schedules transmission and, upon receipt from an application, transmits within a time corresponding to the delay tolerance of that application. For example, a VOIP application resident on the UE 702 may generate keep-alive messages every 30 seconds that are intercepted by the message aggregation module 702 before being sent for wireless transmission to a remote party (e.g., an application server). The message aggregation module 708 may set an aggregation period for such VOIP keep-alive messages to be two minutes, which is considered to be within the delay tolerance of the VOIP application. Thus, each VOIP message received and aggregated by the message aggregation module 708 is forwarded for transmission by the message scheduling module 712 within no more than two minutes of receipt of the message by the message aggregation module 706. In another aspect, the social networking application may generate a status update message every minute, which is also intercepted and stored by the message aggregation module 708. The message aggregation module 708 may set the aggregation period for such status update messages to be every eight minutes, which is considered to be within the delay tolerance of the social networking application. Thus, each status update message received and aggregated by the message aggregation module 708 is forwarded for transmission by the message scheduling module 712 within no more than eight minutes of receipt of the message by the message aggregation module 706.

In various embodiments, the message aggregation functionality described above (particularly with respect to fig. 4-7) may be employed while the UE is in active or idle mode. Thus, for example, if the UE is in an ECM-connected state, the message aggregation module 708 may act to aggregate the state updates and/or keep alive messages for a predetermined period of time that may exceed an expiration time set by the network timer for S1 release of the UE due to inactivity (as set forth in TS 23.401 § 5.3.5). Once the messages are aggregated such that the timer has expired for the S1 release, the network to which the UE is connected may initiate the release of the S1 connection, after which the UE may transition to a reduced power consumption ECM idle state. Otherwise, if message aggregation does not occur during the ECM-connected state of the UE, the generation of keep-alive messages and/or state update messages may prevent or strictly limit any transition to the ECM-idle mode. For example, if the interval between generated keep-alive and/or status update messages is less than the timer period released at S1, the base station or other entity of the network receiving the keep-alive and/or status update messages may detect activity before the timer expires, causing the timer to continually reset before expiration such that a transition to the ECM-idle state is never initiated.

Thus, the present embodiments not only facilitate maintaining the UE in the ECM-idle state for an extended period of time by aggregating mobile data application messages generated during the ECM-idle state, but also expedite transitioning the UE to the ECM-idle state.

In various additional embodiments, the message aggregation module 708 may provide information related to a context message to be transmitted by the UE 702 for transmission to the network in a control message. Such information may include different types of priorities and/or configurations of status update messages to be transmitted from the UE. This may help network entities, such as aggregation/proxy module 120, to make decisions regarding the merging (aggregation) of messages to be transmitted to UE102 in downlink communications.

Turning again to fig. 2, in various additional embodiments, as previously indicated, a network operator supporting communication with UEs may include an aggregation/proxy module 120 operable to aggregate messages generated by a third party, such as the application server 108. It is noted that the messages received by the proxy module 120 may include a status update message 208 and a keep-alive message 210.

In various embodiments, an aggregation module (e.g., aggregation/proxy module 120) may apply one or more types of filters to intercept messages, such as status update messages or keep-alive messages. Because the aggregation/proxy module may not have prior knowledge of the type of data traffic being received, such an aggregation/proxy module may have to apply one or more checking procedures in order to ascertain whether a given message is to be retained for aggregation, and more particularly, what type of message is being received.

Fig. 8 depicts details of the network aggregation module 802 consistent with further embodiments. In various embodiments, the network aggregation module 802 may include an IP transport layer filter 804 that filters incoming messages 806 for a user (e.g., UE 102). In some embodiments, the IP transport layer filter 804 may receive the message 806 as packet switched data and filter out update messages or keep-alive messages for mobile data applications in regular packet switched data traffic. This may be accomplished by determining an IP/transport layer signature that includes, for example, the type of service (TOS), domain, or port number. If the IP transport layer filter 804 determines that the message 806 is regular packet-switched data, the message may be at time t₀As message 808, that is, forwarding may occur without further delay to the intended recipient (e.g., UE 102). For example, message 808 may represent data for a mobile application, such as voice, video, or other data. If incoming message 806 is determined to constitute a status update message or keep-alive message to be aggregated, or the like, incoming message 806 may be forwarded to a message scheduleModule 812 is for later delivery to the recipient. Each status update or keep-alive message received and aggregated by the message scheduling module 812 may be transmitted according to a message type as discussed above with respect to fig. 7. Thus, messages of the first category may be aggregated into the first message buffer 814 and at a subsequent time t_d1May be forwarded as a first message output 816 while messages of a second category may be aggregated into a second message buffer 818 and at a subsequent time t_d2And forwarded as a second message output 820.

Fig. 9 depicts details of another network aggregation module 902 consistent with further embodiments. In various embodiments, the network aggregation module 902 may include a deep packet inspection filter 904, the filter 904 also filtering incoming messages 906 for a user (e.g., the UE 102). In some embodiments, deep packet inspection filter 904 may receive message 906 as packet-switched data and filter out update messages or keep-alive messages for mobile data applications in regular packet-switched data traffic. This may be accomplished by using deep packet inspection to find the signature of the mobile data application within the content of the data packet to determine the content of the message.

If deep packet inspection filter 904 determines that message 906 is regular packet-switched data, the message may be at time t₀As message 908, i.e., forwarding may occur without further delay to the intended recipient (e.g., UE 102). For example, message 908 may represent data of a mobile application, such as voice, video, or other data. If the incoming message 806 is determined to constitute a status update message or keep-alive message to be aggregated, or the like, the incoming message 906 may be forwarded to a message scheduling module 912 for later delivery to the recipient. Each status update or keep-alive message received and aggregated by the message scheduling module 912 may be transmitted according to a message type as discussed above with respect to fig. 7. Thus, messages of a first category may be aggregated into the first message buffer 914 and at a subsequent time t_d3May be forwarded as a first message output 916 while messages of a second category may be aggregated to a second message outputWithin the message buffer 918 and at a subsequent time t_d4And forwarded as a second message output 920.

Fig. 10 depicts details of a further network aggregation module 1002 consistent with other embodiments. As illustrated, the network aggregation module 1002 may receive incoming messages 1004 and forward them for processing by the IP transport layer filter 1006 and the deep packet inspection filter 1008. In one embodiment, the IP transport layer filter may initially examine the incoming message 1004 and forward the incoming message 1004 as message 1010 if it is determined by examining the IP/transport layer signature of the incoming message 1004 that the incoming message 1004 is not aggregated. If the nature of the incoming message is not determined by the IP transport layer filter 1006, the message may be forwarded as message 1012 to the deep packet inspection filter 1008 for inspection. If the message is determined by the IP transport layer filter to be a status update message, keep-alive message, or other message to be aggregated by the network message aggregation module 1002, the message may be forwarded as message 1014 to the message scheduling module 1016. Deep packet inspection module 1008 may receive message 1012 and use deep packet inspection to determine whether it is an update message or a keep-alive message or other message to be aggregated. If so, the message may be forwarded to the message scheduling module as message 1018. If the messages are not aggregated, it may be at time t₀Where a message 1020 is transmitted. Any messages to be aggregated may then be transmitted according to the message type as discussed above with respect to fig. 7. Thus, messages of the first category may be aggregated into the first message buffer 1022 and at a subsequent time t_d5May be forwarded as a first message output 1024 while messages of a second category may be aggregated into a second message buffer 1026 and at a subsequent time t_d6And forwarded as second message output 1028.

Turning again to fig. 2, in embodiments where the core network includes an aggregation/proxy module 120, such a module may act as a proxy for messages generated by the mobile data application 110 that, for example, remain alive messages. Because keep-alive messages may be generated periodically to maintain applications such as VOIP communications, the middleware module 112 may generate signals to maintain VOIP communications.

FIG. 11 depicts one embodiment of a middleware module, wherein the middleware module is a keep-alive agent. The UE 1102 includes an agent 1104 coupled to a VOIP application 1106. The proxy VOIP application 1106 may periodically generate keep-alive signals 1108 that are intercepted by the proxy (or proxy module) 1104 while the VOIP communication is active. Rather than transmitting the message to an external party, the proxy 1104 can send a return message 1110 to the VOIP application 1106, the return message 1110 being used to maintain the VOIP communication in place of the message from the external server.

Fig. 12 depicts an embodiment of a network in which a web server 1202 includes a proxy module 1204. During an active VOIP communication session, the proxy module 1204 may intercept a keep-alive message 1206 output from the application server 108 and, instead of transmitting to the UE102, the proxy module 1204 returns a message 1208 to the network server to maintain the VOIP communication session. Thus, according to the embodiments of fig. 11 and 12, the VOIP communication session may remain active without waking up the transmitter 116 of the UE 1102, i.e., without causing a transition from idle to active mode.

Included herein is a set of flow charts representative of exemplary methodologies for performing novel aspects of the disclosed systems and architectures. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, e.g., in the form of a flow chart or flow diagram, 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 may, in accordance therewith, occur in a different order and/or concurrently with different 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 acts illustrated in a methodology may be required for a novel implementation.

Fig. 13 depicts an exemplary logic flow 1300. At block 1302, a first incoming message is received. At block 1304, a type of message represented by the first message is determined. At block 1306, a determination is made as to whether the first incoming message is to be aggregated. This determination may be based on factors such as the message type of the first incoming message, the current operating mode of the UE (e.g., idle mode or active mode), and other factors. If the message is not aggregated with other messages for later delivery, flow moves to block 1308 where the first incoming message is forwarded for delivery.

If at block 1306 the first incoming message is to be aggregated, the flow moves to block 1310 where the first incoming message is stored for later delivery. At block 1312, a determination is made as to whether the time for transmitting the stored message has arrived. If not, flow is back to block 1310. If so, flow moves to block 1314 where all stored messages are forwarded for delivery.

Fig. 14 depicts another exemplary logic flow 1400. At block 1402, the system is monitored for receipt of a message. The message may be generated by software in an automatic or sporadic form, for example. At block 1404, if the system is not registered with the network, the flow ends. If the system is registered, flow moves to block 1406 where any received messages of the first message type are stored. At block 1408, any received messages of the second message type are also stored.

At block 1410, a determination is made as to whether a time for transmitting the first type of message has arrived. If not, flow is back to block 1402. If so, the flow moves to block 1412 where all stored messages of the first message type are forwarded for transmission.

At block 1414, a determination is made as to whether a time for transmitting the second type of message has arrived. If not, flow is back to block 1402. If so, flow moves to block 1416 where all stored messages of the second message type are forwarded for delivery. The flow may return to block 1402 and loop through blocks 1402-1416 multiple times until the system is no longer registered.

Fig. 15 depicts a further exemplary process flow 1500. At block 1502, an IP transport filter is applied to an incoming message to determine the nature of the incoming message. At block 1504, a determination is made as to whether the incoming message is to be aggregated. If not, flow moves to block 1506 where the incoming message is forwarded for delivery. If so, flow moves to block 1508 where the incoming message is stored for later delivery. If the IP transport layer filter does not determine whether the message is to be aggregated, e.g., if the nature of the incoming message remains undetermined, flow moves to block 1510.

At block 1510, deep packet inspection of the inbound box is performed. At block 1512, a determination is made as to whether the incoming message is to be aggregated based on the deep packet inspection of block 1510. If not, flow moves to block 1506 where the incoming message is forwarded for delivery. If so, flow moves to block 1508 where the incoming message is stored for later delivery.

The flow then moves to block 1514. At block 1514, if the time for transmission of the stored message has arrived, flow moves to block 1516 where the stored message is forwarded for transmission. If not, flow is back to block 1508.

Fig. 16 is a diagram of an exemplary system embodiment and, in particular, fig. 16 is a diagram illustrating a platform 1600, which platform 1600 may include various elements. For example, fig. 16 illustrates that a platform (system) 1610 may include a processor/graphics core 1602, a chipset/Platform Control Hub (PCH) 1604, input/output (I/O) devices 1606, Random Access Memory (RAM) (e.g., dynamic RAM (dram)) 1608 and Read Only Memory (ROM) 1610, display electronics 1620, display backlight 1622, and various other platform components 1614 (e.g., fans, cross-flow fans, heat sinks, DTM systems, cooling systems, housings, openings, etc.). The system 1600 may also include a wireless communication chip 1616 and a graphics device 1618. However, embodiments are not limited to these elements.

As shown in fig. 16, I/O device 1606, RAM 1608, and ROM 1610 are coupled to processor 1602 by way of a chipset 1604. Chipset 1604 may be coupled to processor 1602 by a bus 1612. Thus, bus 1612 may include multiple lines.

Processor 1602 may be a central processing unit including one or more processor cores and may include any number of processors having any number of processor cores. The processor 1602 may include any type of processing unit, such as, for example, a CPU, a multi-processing unit, a Reduced Instruction Set Computer (RISC), a processor with a pipeline, a Complex Instruction Set Computer (CISC), a Digital Signal Processor (DSP), or the like. In some embodiments, the processor 1602 may be multiple independent processors located on independent integrated circuit chips. In some embodiments, the processor 1602 may be a processor with integrated graphics, while in other embodiments the processor 1602 may be one or more graphics cores.

Fig. 17 illustrates an embodiment of an exemplary computing system (architecture) 1700 suitable for implementing various embodiments as previously described. As used in this application, the terms "system" and "device" and "component" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, or software in execution, examples of which are provided by the exemplary computing architecture 1700. For example, a component can be, but is not limited to being, a process running on a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server 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. Further, the components may be communicatively coupled to each other by various types of communications media to coordinate operations. Coordination may involve one-way or two-way exchange of information. For example, a component may transmit information in the form of signals transmitted over a communication medium. The information may be implemented as signals distributed to various signal lines. In such an allocation, each message is a signal. However, further embodiments may alternatively employ data messages. Such data messages may be sent over various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

In one embodiment, the computing architecture 1700 may comprise or be implemented as part of an electronic device. Examples of an electronic device may include, without limitation, a mobile device, a personal digital assistant, a mobile computing device, a smartphone, a cellular telephone, a handset, a one-way pager, a two-way pager, a messaging device, a computer, a Personal Computer (PC), a desktop computer, a laptop computer, a notebook computer, a handheld computer, a tablet computer, a server array or server farm, a web server, a network server, an Internet server, a workstation, a microcomputer, a mainframe computer, a supercomputer, a network appliance, a web appliance, a distributed computing system, multiprocessor systems, processor-based systems, consumer electronics, programmable consumer electronics, television, digital television, set-top box, wireless access point, base station, subscriber station, mobile subscriber center, wireless network controller, subscriber station, wireless network controller, a wireless network, a router, hub, gateway, bridge, switch, machine, or combination thereof. The embodiments are not limited in this context.

The computing architecture 1700 includes various common computing elements, such as one or more processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input/output (I/O) components, and so forth. However, embodiments are not limited to implementation by the computing architecture 1700.

As shown in fig. 17, the computing architecture 1700 includes a processing unit 1704, a system memory 1706, and a system bus 1708. The processing unit 1704 can be any of various commercially available processors. Dual microprocessors and other multiprocessor architectures also can be employed as the processing unit 1704. The system bus 1708 provides an interface for system components including, but not limited to, the system memory 1706 to the processing unit 1704. The system bus 1708 can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures.

The computing architecture 1700 may comprise or implement various articles of manufacture. An article of manufacture may comprise a computer readable storage medium to store various forms of programming logic. Examples of a computer-readable memory medium may include any tangible medium capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of programming logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.

The system memory 1706 may include various types of computer-readable storage media in the form of one or more higher speed memory units such as Read Only Memory (ROM), Random Access Memory (RAM), dynamic RAM (dram), dual data rate dram (ddram), synchronous dram (sdram), static RAM (sram), programmable ROM (prom), erasable programmable ROM (eprom), electrically erasable programmable ROM (eeprom), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, or any other type of media suitable for storing information. In the illustrated embodiment shown in FIG. 17, the system memory 1706 can include non-volatile memory 1710 and/or volatile memory 1712. A basic input/output system (BIOS) may be stored in the non-volatile memory 1710.

The computer 1702 may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal Hard Disk Drive (HDD) 1714, a magnetic Floppy Disk Drive (FDD) 1716 to read from or write to a removable magnetic disk 1718, and an optical disk drive 1720 to read from or write to a removable optical disk 1722 such as a CD-ROM or DVD. The HDD 1714, FDD 1716 and optical disk drive 1720 can be connected to the system bus 1708 by a HDD interface 1724, an FDD interface 1726 and an optical drive interface 1728, respectively. The HDD interface 1724 for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 1294 interface technologies.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units 1710, 1712, including an operating system 1730, one or more application programs 1732, other program modules 1734, and program data 1736.

A user can enter commands and information into the computer 1702 through one or more wired/wireless input devices, such as a keyboard 1738 and a pointing device, such as a mouse 1740. Other input devices may include a microphone, an Infrared (IR) remote control, a joystick, a game pad, a stylus pen, touch screen, or the like. These and other input devices are often connected to the processing unit 1704 through an input device interface 1742 that is coupled to the system bus 1708, but may be connected by other interfaces, such as a parallel port, IEEE 1294 serial port, game port, USB port, IR interface, or the like.

A monitor 1744 or other type of display device is also connected to the system bus 1708 via an interface, such as a video adapter 1746. In addition to the monitor 1744, computers typically include other peripheral output devices such as speakers, printers, etc.

The computer 1702 may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer 1748. The remote computer 1748 may be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 1702, although, for purposes of brevity, only a memory/storage device 1750 is illustrated. The logical connections depicted include wired/wireless connectivity to a Local Area Network (LAN) 1752 and/or larger networks, e.g., a Wide Area Network (WAN) 1754. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, e.g., the Internet.

When used in a LAN networking environment, the computer 1702 is connected to the LAN 1752 through a wire and/or wireless communication network interface or adapter 1756. The adapter 1756 may facilitate wired and/or wireless communication to the LAN 1752, the LAN 1752 may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter 1756.

When used in a WAN networking environment, the computer 1702 can include a modem 1758, or is connected to a communications server on the WAN1754, or has other means for establishing communications over the WAN1754, such as by way of the Internet. The modem 1758, which can be internal or external and a wired and/or wireless device, is connected to the system bus 1708 via the input device interface 1742. In a networked environment, program modules depicted relative to the computer 1702, or portions thereof, can be stored in the remote memory/storage device 1750. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

The computer 1702 is operable to communicate with wire and wireless devices or entities, such as wireless devices operatively disposed in wireless communication (e.g., IEEE802.11 over-the-air modulation techniques) with, for example, a printer, scanner, desktop and/or portable computer, Personal Digital Assistant (PDA), communications satellite, any piece of equipment or location associated with a wirelessly detectable tag (e.g., a kiosk (kiosk), news stand, restroom), and telephone. This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth ™ wireless technologies. Thus, the communication may be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE802.11x (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3-related media and functions).

Embodiments as described previously may be implemented using various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processor circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, Application Specific Integrated Circuits (ASIC), Programmable Logic Devices (PLD), Digital Signal Processors (DSP), Field Programmable Gate Array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, programs, software interfaces, Application Program Interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary according to a number of factors, such as: such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

In some embodiments, an element is defined as a particular structure that performs one or more operations. For example, User Equipment (UE) 102 may be an electronic device having one or more platform components as described with respect to fig. 16, 17. It may be appreciated, however, that any element defined as a specific structure that performs a specified function may be expressed as a means or step for performing the specified function without recitation of structure, material, or acts in support thereof, and such means or step is intended to encompass the corresponding structure, material, or acts described in the detailed description or equivalents thereof. The embodiments are not limited in this context.

Some embodiments may be described using the expression "one embodiment" or "an embodiment" along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment. Furthermore, some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "coupled" and/or "connected" to indicate that two or more elements are in direct physical or electrical contact with each other. The term "coupled," however, may also mean that two or more elements are not in direct contact with each other, but yet still interact or cooperate with each other.

It is emphasized that the abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "including" and "in …" are used as the plain-english equivalents of the respective terms "comprising" and "wherein," respectively. Furthermore, the terms "first," "second," "third," and the like are used merely as labels, and are not intended to impose numerical requirements on their objects.

Examples have been described above that include the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and/or methodologies, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.

Claims (6)

1. At least one computer-readable storage medium comprising instructions that, when executed, cause a system to:

intercepting a first message from a first mobile data application during an idle mode of a wireless device and a second message from a second mobile data application during the idle mode of the wireless device, the first and second messages each operable to trigger a transition of the wireless device from the idle mode to a connected mode;

storing the first message in a first buffer and the second message in a second buffer for later transmission to maintain the wireless device in the idle mode for an extended period of time;

scheduling the first message for transmission at a first time based on a delay tolerance associated with the first mobile data application; and

scheduling the second message for transmission at a second time based on a delay tolerance associated with the second mobile data application, the first and second times including a time at which the wireless device is in the connected mode, the first time being different from the second time.

2. The computer-readable storage medium of claim 1, comprising instructions that when executed cause the system to:

scheduling messages stored in the first buffer for periodic transmission according to a first interval; and

scheduling messages stored in the second buffer for periodic transmission according to a second interval different from the first interval.

3. The computer-readable storage medium of claim 1, comprising instructions that when executed cause the system to:

receiving a multi-state update message;

determining a status update message type for each of the one or more received status update messages; and

scheduling each status update message for transmission according to an interval of the determined status update message type of the one or more status update messages.

4. The computer-readable storage medium of claim 1, comprising instructions that when executed cause the system to:

generating a control indication to switch the device from the idle mode comprising an evolved packet system connection management, ECM, idle state to the connected mode comprising an ECM, connected state to transmit the stored message.

5. The computer-readable storage medium of claim 1, comprising instructions that when executed cause the system to:

intercepting a keep-alive message generated by a mobile data application of the plurality of mobile data applications; and

sending a return message to the mobile data application after intercepting the keep-alive message.

6. The computer-readable storage medium of claim 1, comprising instructions that when executed cause the system to:

performing one or more of Internet Protocol (IP) transport layer filtering and deep packet inspection of messages; and

placing the message in the first buffer when the message constitutes a background traffic message to be stored.