Systems and methods for synchronization of application communications

BACKGROUND

Field

The present application relates generally to wireless communications, and more specifically to systems, methods, and devices for synchronizing application communications.

Background

Applications ("apps") or device applets are now available that operate to provide a wide range of add-on services and features to wireless devices. For example, it is now possible for wireless devices to download and launch device applets to perform value-added functions such as, shopping, searching, position location, driving navigation, and an array of other functions. Network and application providers generally offer these device applets to device users for additional fees. Thus, the use of device applets increases the functionality and usability of wireless devices and offers device users features and convenience not originally available on the devices themselves.

A wireless device interfaces with one or more communication networks using any of a plurality of radios. For example, the wireless device may include a variety of radios providing communications using cellular, Wi-Fi, Bluetooth or other types of radio access technologies. Accordingly, applications executing on the wireless device are provided with a default routing that determines the radio and associated radio channel the applications will use to communicate with the appropriate network.

There is an increased interest, however, in intelligently managing application communications. This is due, in part, to an increase in the number of multi-radio devices (e.g. 3G/Wi-Fi devices) and an increase in network traffic that may create capacity problems for operators, and power consumption problems for users. Thus, with respect to such capacity and power consumption problems, it may be desirable to delay communications during certain periods.

Accordingly, there is a need for efficient and cost effective mechanisms to provide communication management for applications on wireless devices. Specifically, there is a need for systems and methods of managing policies regarding delayed transmission of communications.

SUMMARY

The systems, methods, and devices of the invention each have several aspects, no single one of which is solely responsible for its desirable attributes. Without limiting the scope of this invention as expressed by the claims which follow, some features will now be discussed briefly. After considering this discussion, and particularly after reading the section entitled "Description" one will understand how the features of this invention provide advantages that include management of application communication delay tolerance.

One aspect of the disclosure provides a method of aggregating data for transmission. The method includes receiving information from an application via an application programming interface. The information is indicative of a transmit delay tolerance. The method further includes receiving, via the application programming interface, a packet from the application. The method further includes determining when to transmit the packet based on the received transmit delay tolerance.

Another aspect of the disclosure provides a wireless device for aggregating data for transmission. The wireless device includes a processor configured to receive information from an application via an application programming interface. The information is indicative of a transmit delay tolerance. The processor is further configured to receive, via the application programming interface, a packet from the application. The wireless device further includes a network driver configured to determine when to transmit the packet based on the received transmit delay tolerance.

Another aspect of the disclosure provides a wireless device for aggregating data for transmission. The wireless device includes means for receiving information from an application via an application programming interface. The information is indicative of a transmit delay tolerance. The wireless device further includes means for receiving, via the application programming interface, a packet from the application. The wireless device further includes means for determining when to transmit the packet based on the received transmit delay tolerance.

Another aspect of the disclosure provides a non-transitory computer-readable medium having instruction encoded thereon which, when executed, cause an apparatus to perform a method of aggregating data for transmission. The method includes receiving information from an application, via an application programming interface. The information is indicative of a transmit delay tolerance. The method further includes receiving, via the application programming interface, a packet from the application. The method further includes determining when to transmit the packet based on the received transmit delay tolerance. <nplcit id="ncit0001" npl-type="s"><text>Liu et al (Mobi Arch ' 11 - Proceedings of the sixth international workshop on MobiArch</text></nplcit>.) discloses utilizing energy from the trailing end of transmission pulses. G. Ananthanarayaran et al. discloses a communications API. <patcit id="pcit0001" dnum="US2007104162A1"><text>US2007/104162A1</text></patcit> discloses various embodiments relating to the use of timing or timing-related information for handling aggregated frames in a wireless network.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects described herein will become more readily apparent by reference to the following Description when taken in conjunction with the accompanying drawings wherein: <ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">FIG. 1</figref> shows an exemplary network environment illustrating aspects of a communication management system;</li><li><figref idref="f0002">FIG. 2</figref> shows an exemplary wireless device configured to provide communication management;</li><li><figref idref="f0003">FIG. 3</figref> shows a flowchart of an exemplary method of providing communication management;</li><li><figref idref="f0004">FIG. 4</figref> shows a graph of application network activity for an exemplary device;</li><li><figref idref="f0005">FIG. 5</figref> shows an exemplary block diagram of a hardware/software system configured to aggregate application communication;</li><li><figref idref="f0006">FIG. 6</figref> shows an exemplary timeline of application communication aggregation implemented by the hardware/software system of <figref idref="f0005">FIG. 5</figref>;</li><li><figref idref="f0007">FIG. 7</figref> shows a timeline of application communication aggregations, according to another embodiment;</li><li><figref idref="f0008">FIG. 8</figref> shows an exemplary device configured to manage application communications;</li><li><figref idref="f0009">FIG. 9</figref> shows a flowchart of an exemplary method of managing application communications;</li><li><figref idref="f0010">FIG. 10</figref> shows another exemplary device configured to manage application communications.</li></ul>

DESCRIPTION

Various aspects of the novel systems, apparatuses, and methods are described more fully hereinafter with reference to the accompanying drawings. The teachings disclosure may, however, be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Based on the teachings herein one skilled in the art should appreciate that the scope of the disclosure is intended to cover any aspect of the novel systems, apparatuses, and methods disclosed herein, whether implemented independently of or combined with any other aspect of the invention. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the invention is intended to cover such an apparatus or method which is practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the invention set forth herein. It should be understood that any aspect disclosed herein may be embodied by one or more elements of a claim.

Although particular aspects are described herein, many variations and permutations of these aspects fall within the scope of the disclosure. Although some benefits and advantages of the preferred aspects are mentioned, the scope of the disclosure is not intended to be limited to particular benefits, uses, or objectives. Rather, aspects of the disclosure are intended to be broadly applicable to different wireless technologies, system configurations, networks, and transmission protocols, some of which are illustrated by way of example in the figures and in the following description of the preferred aspects. The detailed description and drawings are merely illustrative of the disclosure rather than limiting, the scope of the disclosure being defined by the appended claims and equivalents thereof.

The techniques described herein may be used for various wireless communication networks such as Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, Single-Carrier FDMA (SC-FDMA) networks, etc. The terms "networks" and "systems" are often used interchangeably. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA2000, etc. UTRA includes Wideband-CDMA (W-CDMA) and Low Chip Rate (LCR). CDMA2000 covers IS-2000, IS-95 and IS-856 standards. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA), IEEE 802.11, IEEE 802.15, IEEE 802.16, IEEE 802.20, Flash-OFDM®, etc. UTRA, E-UTRA, and GSM are part of Universal Mobile Telecommunication management system (UMTS). Long Term Evolution (LTE) is an upcoming release of UMTS that uses E-UTRA. UTRA, E-UTRA, GSM, UMTS and LTE are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). CDMA2000 is described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). These various radio technologies and standards are known in the art.

<figref idref="f0001"><b>FIG.</b> 1</figref> shows an exemplary network environment <b>100</b> illustrating aspects of a communication management system <b>108.</b> The network environment <b>100</b> includes a wireless device <b>102,</b> a communication network <b>104,</b> and a server <b>110.</b> The device <b>102</b> includes a plurality of radios/interfaces (not shown) to communicate with the network <b>104</b> using corresponding radio/interface channels <b>106.</b> The device <b>102</b> also includes a communication management system <b>108</b> that operates to control access to the plurality of radios/interfaces, for example by a particular application.

The wireless device <b>102</b> may communicate with the server <b>110</b> via the communication network <b>104.</b> The server <b>110</b> connects to the communication network <b>104</b> via a communication channel <b>112.</b> The communication channel <b>112</b> may be either a wired or wireless channel.

During operation, the wireless device <b>102</b> executes applications which may interface with the network <b>104</b> using any of the plurality of radios/interfaces. For example, an executing application may issue a networking function call, such as a socket layer call, to request a network resource for communication with the network <b>104.</b> In an embodiment, the communication management system <b>108</b> may process the socket layer call based on a default routing configuration to bind a pre-determined radio/interface resource to the application.

The application may transmit one or more packets of data, for example, via the communication channel <b>112</b> to the server <b>110.</b> In an embodiment, the application may include a transmit delay tolerance parameter in the transmitted packets. The transmit delay tolerance parameter may be included in, for example, a header of each packet. The transmit delay tolerance parameter may indicate an allowable delay for application communication. For example, applications that occasionally access the server <b>110</b> for updates, such as social media applications, may be relatively delay-tolerant. On the other hand, interactive applications, such as video chat or web browsing applications, may be relatively delay-intolerant.

In various embodiments, the transmit delay tolerance parameter may indicate the allowable delay demarcated in a number of temporal units such as, for example, minutes, seconds, milliseconds, microseconds, symbols, clock ticks, frame periods, etc. In an embodiment, the transmit delay tolerance parameter may indicate the allowable delay demarcated as a relative priority value (e.g., high, medium, or low). In an embodiment, the transmit delay tolerance parameter may indicate a maximum allowable number of packets that may be delayed at one time. In various embodiments, the transmit delay tolerance parameter may indicate the maximum allowable number of delayed packets from a single application, or as an aggregate of all application traffic.

The application may generate the transmit delay tolerance for a packet based on a number of factors, including user preferences, whether the application is running in the foreground or the background, or the time of day. The application can set the transmit delay tolerance differently for different types of packets, e.g., FIN packets or content packets. The transmit delay tolerance may be set for each packet individually or may be set by an application using an application programming interface (API) to define kernel metadata regarding future generated packets of a particular type.

In various implementations, the communication management system <b>108</b> operates to intercept packets from the application. For example, the communication management system <b>108</b> may receive packets from the application via an application programming interface (API). The communication management system <b>108</b> may modify communications of the application according to the transmit delay tolerance parameter in each intercepted packet. As used herein, modification of communications can include, but is not limited to, delaying communications or otherwise impacting or affecting communications.

In embodiments where the communication management system <b>108</b> delays communications according to the delay tolerance parameter, the communication management system <b>108</b> may disable one or more radios/interfaces in order to conserve power. After the delay, the communication management system <b>108</b> may power-up one or more disabled radios/interfaces. The communication management system <b>108</b> may then bind the application to a network resource (i.e., the radio/interface that has been selected). A more detailed description of the communication management system <b>108</b> is provided below.

<figref idref="f0002"><b>FIG. 2</b></figref> shows an exemplary wireless device <b>200</b> configured to provide communication management. The device <b>200</b> includes a processor <b>202,</b> a memory <b>204,</b> and a TX/RX radio <b>212,</b> all coupled to communicate using a communication bus <b>214.</b> The wireless device <b>200</b> may be the wireless device <b>102,</b> described above with respect to <figref idref="f0001"><b>FIG. 1</b></figref><b>.</b> It should be noted that the device <b>200</b> is just one implementation and that other implementations are possible.

In one aspect, the processor <b>202</b> includes an application layer module <b>206,</b> a connectivity engine <b>208,</b> and a networking module <b>210.</b> The processor <b>202</b> may also include at least one of a CPU, microprocessor, gate array, hardware logic, memory elements, and/or hardware executing software (not shown). The processor <b>202</b> is configured to control the operation of the device <b>200</b> such that communications of applications executing on the device <b>200</b> may be selectively modified, impacted, delayed and/or bound to a desired radio. In one implementation, the processor <b>202</b> is configured to execute computer-readable instructions related to performing any of a plurality of functions. For example, the processor <b>202</b> operates to analyze information received or communicated from the device <b>200</b> to effectuate communication management. In another aspect, the processor <b>202</b> operates to generate information that may be utilized by the memory <b>204,</b> the application layer module <b>206,</b> the TX/RX radio <b>212,</b> and/or connectivity engine <b>208</b> to effectuate communication management.

The TX/RX radio <b>212</b> includes hardware and/or a processor executing software that is configured to provide a plurality of radios/interfaces that may be used to interface the device <b>200</b> with a plurality of external entities, such as the external communication network <b>104 (</b><figref idref="f0001"><b>FIG. 1</b></figref><b>)</b> using a plurality of radio channels <b>216.</b> The radio channels <b>216</b> may be, for example, the radio channels <b>106</b> described above with respect to <figref idref="f0001"><b>FIG. 1</b></figref><b>.</b> The TX/RX radio <b>212</b> may provide radios/interfaces to communicate using cellular, Wi-Fi, Bluetooth, or any other technologies to communicate with communication networks using the radio channels <b>216.</b> The radios/interfaces of the TX/RX radio <b>212</b> may be selectively enabled and disabled, for example to conserve power when there is no data to be transmitted.

The application layer module <b>206</b> includes hardware and/or a processor executing software that is configured to execute one or more applications on the device <b>200</b> and to store the applications in the memory <b>204.</b> In one implementation, the application layer module <b>206</b> is configured to allow applications to initiate networking function calls to the networking module <b>210</b> to request networking services. The networking function calls may include a connection request to a radio/interface at the TX/RX radio <b>212</b> for the purpose of communicating with an external network or system via the radio channels <b>216.</b>

The networking module <b>210</b> includes hardware and/or a processor executing software that is configured to perform networking functions. In one implementation, the networking functions include such functions as connect(), Bind(), write(), and Setsockopt(). The connect() function operates to establish a connection between an application and a particular radio/interface. The write() function operates to send data over the connection. For example, a particular radio/interface may be selected from the plurality of candidate radios provided by the TX/RX radio <b>212.</b> In an embodiment, the Setsockopt() function may be used to set the delay tolerance parameter. In an aspect, networking module <b>210</b> is configured to perform a variety of networking functions or commands. In one aspect, the networking module <b>210</b> may allow certain functions to proceed, and may not allow other functions to proceed, based on, for example, the delay tolerance parameter.

The connectivity engine <b>208</b> includes hardware and/or a processor executing software that is configured to assess system resources to manage communication from applications. In various implementations, the connectivity engine <b>208</b> is configured to intercept application communication, selectively modify, impact, and/or delay the communication, and/or select a particular radio based on one or more of the following selection criteria. <ol id="ol0001" compact="compact" ol-style=""><li>1. User Policy - policy set by the device user regarding radio access by applications executing at the device.</li><li>2. Operator Policy - policy set by network operators regarding network access by devices or applications.</li><li>3. Radio metrics - measurements of radio performance or other types of measurements that are used to select the most preferred radio for a particular application or operating environment.</li><li>4. Application requirements - requirements associated with requesting applications, such as bandwidth requirements or latency/performance requirements. Application requirements may include, for example, the delay tolerance parameter.</li><li>5. Network usability - information regarding the availability of a particular network on a particular radio interface.</li><li>6. Vendor Supplied Metrics - information to translate from radio metrics such as Receive Signal Strength Indication and Packet Loss Rate to the throughput and latency available for a particular radio interface.</li><li>7. Access Point Availability - information specifying the unique identifier for access points congested by the traffic from other devices or those that may configure a radio link but do not forward packets to the network.</li></ol>

The processor <b>202</b> may download one or more of the aforementioned selection criteria via the TX/RX radio <b>212.</b> The selection criteria may be stored in the memory <b>204.</b> For example, the processor <b>202</b> may retrieve the operator policy and the connectivity engine <b>208</b> may apply the operator policy. The operator policy may include a plurality of rules regulating network access by applications on the wireless device <b>200.</b>

The memory <b>204</b> includes RAM, ROM, EEPROM or any other type of memory device that operates to allow the applications and/or the selection criteria to be stored and retrieved at the device <b>200.</b> In one implementation, the memory <b>204</b> is configured to store computer-readable instructions executed by processor <b>202.</b> The memory <b>204</b> may also be configured to store any of a plurality of other types of data including data generated by any of the processor <b>202,</b> TX/RX radio <b>212,</b> application layer module <b>206,</b> networking module <b>210,</b> and/or connectivity engine <b>208.</b> The memory <b>204</b> may be configured in a number of different configurations, including as random access memory, battery-backed memory, hard disk, magnetic tape, etc. Various features may also be implemented upon memory <b>204,</b> such as compression and automatic back up.

The memory <b>204</b> is configured to store a pre-load library <b>218</b> and a networking library <b>220.</b> The pre-load library <b>218</b> intercepts socket calls from applications. The networking library <b>220</b> provides the networking API used by applications to create and connect sockets to establish network communications.

The connectivity engine <b>208</b> is configured to selectively modify, impact, and/or delay application communication in various ways. For example, the connectivity engine <b>208</b> may be configured to delay communication using one or more of the above selection criteria. For example, the connectivity engine <b>208</b> may delay only communication from delay-tolerant applications, based on the delay tolerance parameter.

In an embodiment, the connectivity engine <b>208</b> may delay communication based on whether the wireless device <b>200</b> is in an idle state. In an embodiment, the connectivity engine <b>208</b> delays communication for delay-tolerant applications until the wireless device <b>200</b> enters an active state. In another embodiment, the connectivity engine <b>208</b> delays communication for delay-tolerant applications until a delay-intolerant application initiates communication.

The connectivity engine <b>208</b> may also be configured to select a radio from the plurality of candidate radios in various ways. For example, the connectivity engine <b>208</b> may be configured to select a radio using one or more of the above selection criteria. In an embodiment, the connectivity engine <b>208</b> may selectively enable/disable one or more radios, for example, to save power when application communications are being delayed. When application communications are not being delayed, the connectivity engine <b>208</b> binds the application to the interface representing that radio. For example, in one implementation, the connectivity engine <b>208</b> binds the application to the radio's interface by calling into the original networking library <b>220.</b> Thus, functions at the connectivity engine <b>208</b> and the pre-load library <b>218</b> may easily access functions, such as a bind() function, in the networking library <b>220</b> to bind to the radio that has been selected for the application.

In various implementations, the communication management system includes a computer program product having one or more program instructions ("instructions") or sets of "codes" stored or embodied on a computer-readable medium. When the codes are executed by at least one processor, for instance, processor <b>202,</b> their execution causes the processor <b>202</b> to control the device <b>200</b> to provide the functions of the intelligent interface selection system described herein. For example, the computer-readable medium includes a floppy disk, CDROM, memory card, FLASH memory device, RAM, ROM, or any other type of memory device or computer-readable medium that interfaces to the device <b>200.</b> In another aspect, the sets of codes may be downloaded into the device <b>200</b> from an external device or communication network resource. The sets of codes, when executed, operate to provide aspects of the intelligent interface selection system described herein.

<figref idref="f0003"><b>FIG. 3</b></figref> shows a flowchart <b>300</b> of an exemplary method of providing communication management. For clarity, the flowchart <b>300</b> is described below with reference to the device <b>200</b> shown in <figref idref="f0002"><b>FIG. 2</b></figref><b>.</b> However, a person having ordinary skill in the art will appreciate that the illustrated method can be implemented with any suitable device. In one implementation, the processor <b>202</b> executes one or more sets of codes to control the functional elements of the device <b>200</b> to perform the functions described below.

At block <b>302,</b> the processor <b>202</b> launches an application. The application may be a legacy or non-legacy application that is part of the application layer module <b>206.</b> For example, the application may be a network browser that generates a networking function call to connect to a wireless network using a radio available at the TX/RX radio <b>212.</b>

At block <b>304,</b> the processor <b>202</b> configures and loads a pre-load library. For example, the pre-load library <b>218</b> includes a subset of the networking functions that are provided in the networking library <b>220</b> used by applications to assess communication networks. The networking functions in the pre-load library <b>218</b> are configured to intercept networking function calls from applications executing at a device. For example, the pre-load library <b>218</b> includes POSIX socket functions that may be used to intercept socket calls by applications executing at the device <b>200.</b> In one implementation, the pre-load library <b>218</b> in stored in memory <b>204.</b>

In one implementation, the pre-load library <b>218</b> functions are configured to receive arguments passed from calling applications and use these arguments to generate a request to the connectivity engine <b>208</b> to select the radio best suited for the application's purpose.

At block <b>306,</b> the processor <b>202</b> links the pre-load library into the execution environment. For example, the processor <b>202</b> links the pre-load library <b>218</b> into the execution environment at a higher priority than the networking library <b>220.</b> Thus, networking functions calls by applications will be intercepted and processed by functions in the pre-load library <b>218</b> and not processed by similar functions in the networking library <b>220.</b>

At block <b>308,</b> the processor <b>202</b> receives a packet from the application. The processor <b>202</b> may also receive a transmit delay tolerance from the application. In an embodiment, the application may initiate transmission of the packet via an API using, for example, a networking function call. The networking function call may be a POSIX socket function call, such as the connect() function or the write() function. In an embodiment, the application may indicate a delay tolerance of the packet by setting the transmit delay tolerance. In an embodiment, the application may set the transmit delay tolerance using, for example, a setsockopt() function call.

In an embodiment, the application may generate the transmit delay tolerance for a packet based on a user preferences. For example, an application that receives periodic updates may allow a user to determine a minimum and maximum amount of time between updates. In another embodiment, the application may generate the transmit delay tolerance for a packet based whether the application is running in the foreground or the background. For example, the application may assign a lower delay tolerance when operating in the foreground, and a higher delay tolerance when operating in the background. In another embodiment, the application may generate the transmit delay tolerance for a packet based on the time of day. For example, the application may assign a higher delay tolerance to packets sent in the middle of the night.

In certain embodiments, the application can set the transmit delay tolerance differently for different types of packets. For example, a Web browsing application may set a relatively high transmit delay tolerance for FIN packets, and a relatively low transmit delay tolerance for content packets. Accordingly, FIN packets might be delayed until content packets reach their delay tolerance. In various embodiments, different transmit delay tolerances can be assigned to different packet types including, SYN packets, FIN packets, and data packets.

In an embodiment, the application may set the transmit delay tolerance for each packet individually. In another embodiment, the application may provide a delay policy via an application programming interface (API) to define kernel metadata regarding future generated packets of a particular type. The delay policy may include one or more rules, based on which the network stack may assign delay tolerances. For example, the application may provide a rule that the network stack should assign a particular delay tolerance to all FIN packets. The rules can include criteria including source application, destination host name, destination host address, source and destination port numbers, environment variables, etc.

The application generates the networking function call to connect to a radio to allow communication with external networks. Due to the linking of the pre-load library <b>218</b> into the execution environment at a higher priority than the networking library <b>220,</b> the processor <b>202</b> intercepts (or processes) the networking function call via the functions in the pre-load library <b>218.</b> In an embodiment, the processor <b>202</b> can delay the networking function call in accordance with the application delay parameter. Additional details are described herein, for example, with respect to <figref idref="f0009"><b>FIG. 9</b></figref><b>.</b>

At block <b>310,</b> the called function in the pre-load library <b>218</b> generates a selection request to the connectivity engine <b>208</b> to select the appropriate radio for use by the application. The request includes any information that is part of the selection criteria used by the connectivity engine <b>208</b> to select the appropriate radio for use by the application. In another embodiment, the called function in the pre-load library <b>218</b> generates a selection request to the connectivity engine <b>208</b> to determine whether the communication should be delayed.

At block <b>312,</b> selection criteria are assessed. In one implementation, the connectivity engine <b>208</b> operates to assess the selection criteria described above. For example, the connectivity engine <b>208</b> may communicate with the processor <b>202</b> to assess Operator Policies that are part of the selection criteria.

At block <b>314,</b> the connectivity engine <b>208</b> selects a radio based on the assessment of the selection criteria. For example, the connectivity engine <b>208</b> operates to select the radio that best matches the selection criteria.

At block <b>316,</b> the connectivity engine <b>208</b> binds to the radio's interface that has been selected for the application. For example, in one implementation, the connectivity engine <b>208</b> calls a bind() function of the networking library <b>220</b> to bind to the radio that has been selected for the application. For example, the connectivity engine <b>208</b> is aware of the networking library <b>220</b> and how to access its functions directly without being intercepted by the pre-load library <b>218.</b> In an embodiment, the connectivity engine <b>208</b> delays communication prior or post to binding the application to the radio. In an embodiment, binding the radio may include enabling or powering-up a disabled or powered-down radio after delaying application communications.

At block <b>318,</b> the application then utilizes the radio that has been selected for network communications.

In an optional operation, the method proceeds to block <b>312</b> where the connectivity engine <b>208</b> operates to perform periodic assessment of the selection criteria to determine if the current radio best matches the selection criteria. If the connectivity engine <b>208</b> determines after another assessment of the selection criteria that a radio other than the current radio best matches the selection criteria, then the connectivity engine <b>208</b> may destroy the connection as a means to trigger the application into restarting the connection to select a different radio for the new connection. Thus, the optional operation allows the selection criteria to be periodically assessed to assure that the most appropriate radio is selected to conduct the desired communication.

Therefore, the flowchart <b>300</b> provides communication management for use with legacy and non-legacy applications. It should be noted that the flowchart <b>300</b> is just one implementation and that the operations of the flowchart <b>300</b> may be rearranged or otherwise modified such that other implementations are possible.

Application Delay Management for Wireless Device Applications

In wireless devices such as smart phones, personal digital assistants, etc., software applications may run in the background, and may initiate network activity every few minutes. For example, a mailer application may cause the network driver to wake up the modem to transmit information every three minutes. A financial tracker application may cause the network driver to wake up the modem to transmit information every two minutes. Because of the different periods (and relative phases), the modem is woken more frequently than every two minutes, wasting power. Applications such as social networking applications, email or other communication applications, data feeds, etc. (popular examples include Facebook, Gmail, Market, Twitter, etc.) may send and receive data with varied periodicity.

<figref idref="f0004"><b>FIG. 4</b></figref> shows a graph <b>400</b> of application network activity for an exemplary device. The x-axis of the graph <b>400</b> shows time, and the y-axis shows an amount of data transferred, in bytes, at each time. The graph <b>400</b> shows network activity during an approximately two-hour period, during which the device is in an idle mode. In an embodiment, the device is in an idle mode when a user does not interact with the device and/or a display is off. Although the device is in the idle mode, applications that continue to operate create spikes in activity, for example, first application spikes <b>410a-i.</b> Such applications can be referred to as "background" applications. The activity by these applications may utilize communication resources such as the radios in radio <b>212,</b> etc.

Network activity spikes, such as first application spikes <b>410a-i,</b> may cause the wireless device to transition from the idle mode to a connected mode. In the connected mode, the device may power-up a radio, may generate signaling traffic, and may consume a greater amount of power than when in the idle mode. In some cases, the spikes may prevent the wireless device from transitioning from the connected mode to the idle mode, or to alternate connection modes such as a discontinuous reception (DRX) mode. Such elevated levels of radio activity by the applications when the user is not actively engaging the device may result in shortened battery life, increased load of radio networks, or other undesired effects. Moreover, different applications may generate traffic at different times, potentially increasing the number of times the radio powers-up, or increasing the amount of time the radio stays powered-up. For example, second application spikes <b>420a-e</b> do not occur at the same times as the first application spikes <b>410a-i.</b>

Employing the techniques and structures disclosed herein, a device may employ a software layer (also referred to as a "wrapper") that provides an application program interface (API) to capture data from background applications and hold them until a desired point where radio resources may be activated and the application data transferred and tasks executed in a synchronized manner. By aggregating such tasks/data requests, frequent waking of the wireless device may be reduced and other communication resources conserved during periods where the user is not actively engaging with the device.

<figref idref="f0005"><b>FIG. 5</b></figref> shows an exemplary block diagram of a hardware/software system <b>500</b> configured to aggregate application communication. As shown, the software components are divided between an application processor <b>550</b> and a modem processor <b>560,</b> but the various functionalities may be organized differently from the example of <figref idref="f0005"><b>FIG. 5</b></figref><b>.</b> For example, functions described as software may be implemented in hardware and vice versa, functions may be distributed differently between components, etc. In an embodiment, the hardware/software system <b>500</b> may be the communication management system <b>108,</b> discussed above with respect to <figref idref="f0001"><b>FIG. 1</b></figref><b>.</b> In another embodiment, the hardware software system <b>500</b> may be implemented on the wireless device <b>200,</b> described above with respect to <figref idref="f0002"><b>FIG. 2</b></figref><b>.</b> For example, functions of the application processor <b>550</b> may be implemented by one or more of the processor <b>202,</b> the application layer module <b>206,</b> and/or the connectivity engine <b>208.</b> Functions of the modem processor <b>560</b> may be implemented by one or more of the TX/RX radio <b>212,</b> the networking module <b>210,</b> and/or the connectivity engine <b>208.</b>

In the illustrated embodiment, applications <b>502</b> interact with an application connection engine <b>508</b> and with a high level operating system (HLOS) <b>506.</b> The HLOS <b>506</b> may be, for example, the Android operating system produced by Google Inc., Mountain View, CA. The application connection engine <b>508</b> may communicate with a modem connection engine <b>510.</b> The modem connection engine may manage communication resources such as a radio <b>212</b> and the radios therein. The wrapper <b>504</b> is capable of capturing data between the applications <b>502</b> and the HLOS <b>506.</b> The wrapper <b>504</b> may aggregate data from the applications <b>502</b> during a period of user inactivity and hold them until a determined time before releasing them to the HLOS <b>506</b> and ultimately the radio <b>212</b> for operation/transmission. The wrapper <b>504</b> may be invisible to the applications <b>502</b> such that they are unaware that their data/requests are being held/aggregated. In an embodiment, the wrapper <b>504</b> may emulate functions of the HLOS <b>506.</b> The wrapper <b>504</b> may be a separate component or may be incorporated into another component such as the application connection engine <b>508.</b> For example, the wrapper <b>504</b> may be implemented by the connectivity engine <b>208,</b> described above with respect to <figref idref="f0002"><b>FIG. 2</b></figref><b>.</b>

<figref idref="f0006"><b>FIG. 6</b></figref> shows an exemplary timeline <b>600</b> of application communication aggregation implemented by the hardware/software system <b>500</b> of <figref idref="f0005"><b>FIG. 5</b></figref><b>.</b> As shown, applications <b>APP 1-4</b> each initiate a request for use of a radio resource in succession during an aggregation period <b>610.</b> In an embodiment, application communication may be delayed during the aggregation period <b>610.</b> In an embodiment, the aggregation period <b>610</b> can include a period in which the device <b>200</b> and/or the TX/RX radio <b>212</b> is in the idle mode. The applications <b>APP 1-4</b> may be delay-tolerant applications. Delay-tolerant applications may carry relatively time-insensitive data such as, for example, e-mail or a bulk file transfer.

In the illustrated embodiment, the application <b>APP 1</b> transmits a packet, which may include a first transmit delay tolerance. Then, the application <b>APP 2</b> transmits a packet, which may include a second transmit delay tolerance. Next, the application <b>APP 3</b> transmits a packet, which may include a third transmit delay tolerance. Finally, the application <b>APP 4</b> transmits a packet, which may include a fourth transmit delay tolerance. The wrapper <b>504</b> receives the packets (for example, via API calls such as connect() and write() socket calls). Instead of acting on the socket calls immediately, the wrapper <b>504</b> delays the communication during the aggregation period <b>610.</b> At a determined time, the wrapper <b>504</b> releases the socket calls together, as aggregated packets <b>620.</b>

In an embodiment, the wrapper <b>504</b> may release the aggregated packets <b>620</b> during a transmit window <b>630.</b> In various embodiments, the transmit window <b>630</b> may include a period in which the device <b>200</b> is in the idle mode, and may include a period in which the device <b>200</b> is in the active mode. During the transmit window <b>630,</b> one or more radio interfaces (such as, for example TX/RX radio <b>212</b>) may be enabled or powered-up. The wrapper <b>504</b> may release aggregated packets <b>620</b> from <b>APPs 1-4.</b> The wrapper <b>504</b> may also allow application communications requests made during the transmit window <b>630</b> to proceed without delay. In other words, during the transmit window <b>630,</b> the wrapper <b>504</b> may not delay further communication. For example, in the illustrated embodiment, <b>APP 5</b> transmits a packet, which may include a fifth transmit delay tolerance, during the transmit window <b>630.</b> The wrapper <b>504</b> packet received from <b>APP 5</b> to proceed without delay.

In an embodiment, wrapper <b>504</b> may open the transmit window <b>630</b> at regular or intermittent intervals. For example, the wrapper <b>504</b> may open transmit window <b>630,</b> once every 5 minutes, 10 minutes, 15 minutes, 30 minutes, 60 minutes, etc. In another example, the wrapper <b>504</b> may release delayed application communications at a random or pseudo-random time. The intervals at which the wrapper <b>504</b> opens the transmit window <b>630</b> may be determined by the device <b>200</b> or received from another device, such as the server <b>110</b> (<figref idref="f0001"><b>FIG. 1</b></figref>).

In an embodiment, the wrapper <b>504</b> can determine when to open the transmit window <b>630</b> dynamically, based on the aggregated packets <b>620.</b> For example, the wrapper <b>504</b> can open the transmit window when any of the aggregated packets <b>620</b> has experienced a delay equal to its transmit delay tolerance. In other words, once a single delayed packet has reached a threshold delay (e.g., the transmit delay tolerance), all delayed packets may be released. As another example, the wrapper <b>504</b> can open the transmit window <b>630</b> when the number of aggregated packets <b>620</b> surpasses a threshold. The threshold can be determined by the device <b>200</b> or received from another device, such as the server <b>110.</b>

The wrapper <b>504</b> can keep the transmit window <b>630</b> open for a predetermined or dynamic period of time. For example, the wrapper <b>504</b> may keep the transmit window <b>630</b> open for 15 seconds, 30 seconds, 1 minute, 5 minutes, etc., after the transmit window <b>630</b> is opened. As another example, the wrapper <b>504</b> may keep the transmit window <b>630</b> open for 15 seconds, 30 seconds, 1 minute, 5 minutes, etc., after the last application communication is transmitted. The amount of time which the wrapper <b>504</b> keeps the transmit window <b>630</b> open may be determined by the device <b>200</b> or received from another device, such as the server <b>110.</b> When the transmit window <b>630</b> is closed, one or more radio interfaces (such as, for example TX/RX radio <b>212</b>) may be disabled or powered-down.

In an embodiment, the wrapper <b>504</b> can close the transmit window <b>630</b> after all aggregated packets <b>620</b> have been transmitted. In another embodiment, the wrapper <b>504</b> can close the transmit window <b>630</b> after all aggregated packets <b>620</b> that have been delayed longer than a threshold value have been transmitted. The threshold value for each packet may be the transmit delay tolerance. In various embodiments, the threshold delay value for each packet can be that packet's transmit delay tolerance, modified by a safety factor. For example, the threshold delay value for each packet can be that packet's transmit delay tolerance divided by a constant, or minus a constant.

In an embodiment, the wrapper <b>504</b> may open the transmit window <b>630</b> when a delay-intolerant application initiates communication. For example, <b>APP 5</b> may be a delay-intolerant application. Accordingly, the wrapper <b>504</b> may open the transmit window <b>630</b> when a packet is received from <b>APP</b> 5. The wrapper <b>504</b> may allow the packet from <b>APP 5</b> to proceed, and may also release the aggregated packets <b>620</b> from the <b>APPs 1-4.</b>

<figref idref="f0007"><b>FIG. 7</b></figref> shows a timeline <b>700</b> of application communication aggregations, according to another embodiment. As shown, applications <b>APP 1-2</b> each initiate a request for use of a radio resource in succession. The applications <b>APP 1-2</b> may indicate their delay tolerance via a connection engine API. For example, the application <b>APP 1-2</b> may include background activity and/or requirements for operation that are only tolerant of specific delays. For example, the applications <b>APP 1-2</b> may be location tracking applications that report the location of the device <b>200</b> periodically, such as every 10 seconds.

As shown, the application <b>APP 1</b> initiates a communication request, and indicates to the wrapper <b>504</b> that it will only tolerate an X-second delay. Next, the application <b>APP 2</b> initiates a communication request, and indicates to the wrapper 504 that it will only tolerate a Y-second delay. The wrapper <b>504</b> may provide a callback function (e.g., API.Go), which may indicate to an application that communication is allowed. After receiving the callback, the application may proceed with communication.

As shown, the wrapper <b>504</b> provides the API.Go callback to the application <b>APP 1</b> before the X-second delay has elapsed. The application <b>APP 1</b> then communicates through the wrapper <b>504,</b> without further delay. Similarly, the wrapper <b>504</b> provides the API.Go callback to the application <b>APP 2</b> before the Y-second delay has elapsed. The application <b>APP 2</b> then communicates through the wrapper <b>504,</b> without further delay.

In an alternative embodiment, applications may provide the wrapper <b>504</b> with specific transmission deadlines via the API. The wrapper <b>504</b> may transparently delay communication from the applications, within the constraints of the provided deadlines. Accordingly, the wrapper <b>504</b> will allow the application communication to proceed prior to any deadlines.

In yet another aspect, the API may allow also an application to register as a delay-intolerant application. Applications that may request immediate access include child tracking applications, emergency notification applications, etc. In an embodiment, the wrapper <b>504</b> may learn the delay tolerance of various applications by monitoring the application communications. In another embodiment, the wrapper <b>504</b> may receive a list of transmit delay tolerances from a list or database, either stored locally on the device <b>102</b> or received from the server <b>110.</b> The list or database may be received along with a communication access policy such as the operator policy.

The wrapper <b>504</b> may aggregate or delay application communications in a manner that reduces user disruption. The wrapper <b>504</b> may analyze a variety of factors to determine when to delay or aggregate application communication. For example, the wrapper <b>504</b> may delay application communication based on characteristics of the wireless device <b>102</b> such as a display state (on or off), an audio state (on or off), etc. The wrapper <b>504</b> may only delay application communications known to be tolerant of delay. The wrapper <b>504</b> may delay application communication when the radio is not loaded, when the wireless device is not otherwise in use (e.g., no phone calls, audio streaming, etc.). A person having ordinary skill in the art would appreciate that the wrapper <b>504</b> may determine when to delay application communication based on any combination of the above factors, in addition to other suitable factors.

Moreover, the wrapper <b>504</b> may analyze a variety of factors to determine when to release delayed or aggregated communication and to permit unrestricted application communication. For example, a delay-intolerant application (such as, for example, an emergency notification application) may initiate an unrestricted application communication. The unrestricted application communication may trigger the wrapper <b>504</b> to release previously delayed or aggregated application communications. Accordingly, previously delayed application communications may use radio resources in conjunction with the emergency application. In other words, the wrapper <b>504</b> may open a transmit window for all applications when a delay-intolerant application communication is initiated.

In an embodiment, the wrapper <b>504</b> may release delayed or aggregated application communications when a specific radio is activated or selected as a default. The specific radio may include, for example, a Wi-Fi radio, a cellular radio, a particular mode of the cellular radio (e.g. 2G or 3G communication modes), a Bluetooth radio, etc. For example, the wrapper <b>504</b> may delay application communications when only a cellular radio is enabled, and may release the delayed application communications when a Wi-Fi radio is enabled.

In another embodiment, the wrapper <b>504</b> may release delayed or aggregated application communications when a radio channel quality is above a threshold. Radio channel quality may include metrics such as signal strength, signal-to-noise ratio (SNR), etc. For example, the wrapper <b>504</b> may delay application communications when the SNR of a cellular radio is below a threshold, and may release the delayed application communications when the SNR of the cellular radio rises to or above the threshold.

In an embodiment, the wrapper <b>504</b> releases delayed or aggregated application communications when user interaction is received. For example, the wrapper <b>504</b> may release delayed application communications when a display is activated, a button press is detected, etc. In another embodiment, the wireless device <b>102</b> may anticipate user interaction. For example, the wireless device <b>102</b> may include an accelerometer that may detect movement of the wireless device <b>102.</b> The wrapper <b>504</b> may release delayed application communications when accelerometer output indicates a likelihood of imminent user interaction. In another example, the wireless device <b>102</b> may anticipate user interaction via a proximity detector. A person having ordinary skill in the art will appreciate that the wrapper <b>504</b> may release delayed application communications in response to any combination of the above, and additionally in response to any other suitable event.

Although the preceding description discusses application communication aggregation and delay with respect to an API, the concepts equally apply in hardware, firmware, or any combination of hardware and software.

<figref idref="f0008"><b>FIG. 8</b></figref> shows an exemplary device <b>802</b> configured to manage application communications. The device may be employed within the network environment <b>100,</b> described above with respect to <figref idref="f0001"><b>FIG. 1</b></figref>. The device <b>802</b> is an example of a device that may be configured to implement the various methods described herein. For example, the device <b>802</b> may implement one or more functions of the wireless device <b>102.</b> In another embodiment, the device <b>802</b> may implement one or more functions of the server <b>110.</b>

The device <b>802</b> may include a processor <b>804</b> which controls operation of the device <b>802.</b> The processor <b>804</b> may also be referred to as a central processing unit (CPU). The memory <b>806</b>, which may include both read-only memory (ROM) and random access memory (RAM), provides instructions and data to the processor <b>804.</b> A portion of the memory <b>806</b> may also include non-volatile random access memory (NVRAM). The processor <b>804</b> may perform logical and arithmetic operations based on program instructions stored within the memory <b>806.</b> The instructions in the memory <b>806</b> may be executable to implement the methods described herein.

When the device <b>802</b> is implemented or used as the wireless device <b>102</b>, the processor <b>804</b> may be configured to execute one or more applications, which may be stored in the memory <b>806</b>. During execution, the applications may initiate communication over the transceiver <b>814</b>, the transmitter <b>810,</b> and/or the receiver <b>812</b>. The processor <b>804</b> may implement the hardware/software system <b>500,</b> described above with respect to <figref idref="f0005"><b>FIG. 5</b></figref>. For example, the processor <b>804</b> may manage application communications as described above with respect to <figref idref="f0006 f0007"><b>FIGs. 6-7</b></figref>.

The processor <b>804</b> may comprise or be a component of a processing system implemented with one or more processors. The one or more processors may be implemented with any combination of general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate array (FPGAs), programmable logic devices (PLDs), controllers, state machines, gated logic, discrete hardware components, dedicated hardware finite state machines, or any other suitable entities that may perform calculations or other manipulations of information.

The processing system may also include machine-readable media for storing software. Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the one or more processors, cause the processing system to perform the various functions described herein.

The device <b>802</b> may also include a housing <b>808</b> that may include a transmitter <b>810</b> and/or a receiver <b>812</b> to allow transmission and reception of data between the device <b>802</b> and a remote location. The transmitter <b>810</b> and receiver <b>812</b> may be combined into a transceiver <b>814</b>. An antenna <b>816</b> may be attached to the housing <b>808</b> and electrically coupled to the transceiver <b>814</b>. In some embodiments, the antenna <b>816</b> may be omitted, and the device <b>802</b> may be configured for wired communication. The device <b>802</b> may also include (not shown) multiple transmitters, multiple receivers, multiple transceivers, and/or multiple antennas.

The device <b>802</b> may also include a signal detector <b>818</b> that may be used in an effort to detect and quantify the level of signals received by the transceiver <b>814</b>. The signal detector <b>818</b> may detect such signals as total energy, energy per subcarrier per symbol, power spectral density and other signals. The device <b>802</b> may also include a digital signal processor (DSP) <b>820</b> for use in processing signals. The DSP 820 may be configured to generate a packet for transmission. In some aspects, the packet may comprise a physical layer data unit (PPDU).

The device <b>802</b> may further comprise a user interface <b>822</b> in some aspects. The user interface <b>822</b> may comprise a proximity detector, one or more input buttons, a keypad, a microphone, a speaker, an interface port (for example, a Universal Serial Bus (USB) port, a High-Definition Multimedia Interface (HDMI) port, etc.), a touchscreen, and/or a display. The user interface <b>822</b> may include any element or component that conveys information to a user of the device <b>802</b> and/or receives input from the user. In an embodiment, the user interface <b>822</b> may be considered active when it is receiving input, or sending output (for example, from a USB port, to a display, from a microphone, etc.). The user interface <b>822</b> may also be considered active when it has received input, or has sent output within a threshold time period (for example, 1 second, 1 minute, 5 minutes, etc.). The user interface <b>822</b> may be considered inactive or idle when it is not active.

When the user interface <b>822</b> receives no input, the device <b>802</b> may be said to be in an idle state, or an idle mode. In the idle state, a display may be off, and one or more functions of the device <b>802</b> may be disabled. In an embodiment, processes and communications of the device <b>802</b> that are not initiated in response to user interface <b>822</b> input may be referred to as background or idle processes or communications.

When the user interface <b>822</b> receives input, the device <b>802</b> may be said to be in an active state, or an active mode. In the active state, the display may be on, and input may have been received within an input idle period. The input idle period may be configurable and may be, for example, 1 minute. In an embodiment, background processes and communications may occur in the active mode, but may not be initiated in direct response to user interface <b>822</b> input.

The various components of the device <b>802</b> may be coupled together by a bus system <b>826</b>. The bus system <b>826</b> may include a data bus, for example, as well as a power bus, a control signal bus, and a status signal bus in addition to the data bus. Those of skill in the art will appreciate the components of the device <b>802</b> may be coupled together or accept or provide inputs to each other using some other mechanism.

Although a number of separate components are illustrated in <figref idref="f0008"><b>FIG. 8</b></figref>, those of skill in the art will recognize that one or more of the components may be combined or commonly implemented. For example, the processor <b>804</b> may be used to implement not only the functionality described above with respect to the processor <b>804</b>, but also to implement the functionality described above with respect to the signal detector <b>818</b> and/or the DSP <b>820.</b> Further, each of the components illustrated in <figref idref="f0008"><b>FIG. 8</b></figref> may be implemented using a plurality of separate elements.

<figref idref="f0009"><b>FIG. 9</b></figref> shows a flowchart <b>900</b> of an exemplary method of managing application communications. In one embodiment, one or more aspects of the flowchart <b>900</b> can correspond to block <b>308</b> of <figref idref="f0003"><b>FIG. 3</b></figref>. Although the method of flowchart <b>900</b> is described herein with reference to the device <b>802</b> discussed above with respect to <figref idref="f0008"><b>FIG. 8</b></figref>, a person having ordinary skill in the art will appreciate that the method of flowchart 900 may be implemented by the wireless device <b>102</b> discussed above with respect to <figref idref="f0001"><b>FIG. 1</b></figref>, the wireless device <b>202</b> discussed above with respect to <figref idref="f0002"><b>FIG. 2</b></figref>, and/or any other suitable device. In an embodiment, the steps in flowchart <b>900</b> may be performed by the processor <b>805</b> in conjunction with the transmitter <b>810</b>, the receiver <b>812</b>, the memory <b>806</b>, and the user interface <b>822</b>. Although the method of flowchart <b>900</b> is described herein with reference to a particular order, in various embodiments, blocks herein may be performed in a different order, or omitted, and additional blocks may be added.

First, at block <b>910</b>, the device <b>802</b> receives the transmit delay tolerance from an application. In an embodiment, the transmit delay tolerance is received in a packet. In an embodiment, the transmit delay tolerance is received via the API described above. The processor <b>804</b> may store the transmit delay tolerance in the memory <b>806</b>. In an embodiment, the device <b>802</b> receives the transmit delay tolerance from the server <b>110</b>. As discussed above with respect to <figref idref="f0007 f0008"><b>FIGs. 7-8</b></figref>, the transmit delay tolerance may specify how the device <b>802</b> should delay application communication.

Next, at block <b>920</b>, the processor <b>804</b> receives one or more communications (e.g. a packet) from an application executing on the processor <b>804</b>. The processor <b>804</b> may intercept the communications via facilities described above with respect to the communication management system <b>108</b> and/or the connectivity engine <b>208.</b> In an embodiment, the DSP <b>820</b>, the signal detector <b>818</b>, the transmitter <b>810</b>, and/or the transceiver <b>814</b> may intercept the communications. When the packet is received, the transceiver <b>814</b> (including one or more of the transmitter <b>810</b> and the receiver <b>812</b>) may be in a powered-off, disabled, inactive, and/or idle state.

Then, at block <b>930</b>, the processor <b>804</b> determines when to transmit the packet. For example, the processor <b>804</b> may determine a delay threshold as described above with respect to <figref idref="f0006 f0007"><b>FIGs. 6-7</b></figref>. In an embodiment, the processor <b>804</b> may determine when to open and close the transmit window <b>630</b>. Subsequently, at block <b>940</b>, the processor <b>804</b> transmits the packet via the transmitter <b>810</b> at the time determined at block <b>930</b>. Before the packet is transmitted, the processor <b>804</b> may power-on, enable, and/or activate the transceiver <b>814</b>.

<figref idref="f0010"><b>FIG. 10</b></figref> shows another exemplary device <b>1000</b> configured to manage application communications. The device <b>1000</b> comprises a receiving module <b>1010,</b> a determining module <b>1020,</b> and a transmitting module <b>1030.</b> The receiving module <b>1010</b> may be configured to perform one or more of the functions discussed above with respect to the block <b>910</b> and/or the block <b>920</b> illustrated in <figref idref="f0009"><b>FIG. 9</b></figref>. The receiving module <b>1010</b> may correspond to one or more of the receiver <b>812</b>, the processor <b>804</b>, the transceiver <b>814</b>, and the memory <b>806</b>, discussed above with respect to <figref idref="f0008"><b>FIG. 8</b></figref>. The receiving module <b>1010</b> may also correspond to one or more of the TX/RX radio <b>212</b> and the processor 202 (including the application layer module <b>206</b>, the networking module <b>210</b>, and the connectivity engine <b>208</b>), discussed above with respect to <figref idref="f0002"><b>FIG. 2</b></figref><b>.</b>

The determining module <b>1020</b> may be configured to perform one or more of the functions discussed above with respect to the block <b>930</b> illustrated in <figref idref="f0009"><b>FIG. 9</b></figref><b>.</b> The determining module <b>1020</b> may correspond to one or more of the processor <b>804</b>, the DSP <b>820</b>, and the memory <b>808</b> discussed above with respect to <figref idref="f0008"><b>FIG. 8</b></figref>. The determining module <b>1020</b> may also correspond to one or more of the processor <b>202</b> and the memory <b>204</b> discussed above with respect to <figref idref="f0002"><b>FIG. 2</b></figref>.

The transmitting module <b>1030</b> may be configured to perform one or more of the functions discussed above with respect to the block <b>940</b> illustrated in <figref idref="f0009"><b>FIG. 9</b></figref>. The transmitting module <b>1030</b> may correspond to one or more of the processor <b>804</b> and the transmitter <b>810</b>, discussed above with respect to <figref idref="f0008"><b>FIG. 8</b></figref>. The transmitting module <b>1030</b> may correspond to one or more of the transmitter <b>810</b>, the processor <b>804</b>, the transceiver <b>814</b>, and the memory <b>806</b>, discussed above with respect to <figref idref="f0008"><b>FIG. 8</b></figref>. The transmitting module <b>1030</b> may also correspond to one or more of the TX/RX radio <b>212</b> and the processor <b>202</b>, discussed above with respect to <figref idref="f0002"><b>FIG. 2</b></figref>.

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the exemplary embodiments of the invention.

The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor may read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

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

It is to be understood that the claims are not limited to the precise configuration and components illustrated above. Various modifications, changes and variations may be made in the arrangement, operation and details of the methods and apparatus described above without departing from the scope of the claims.

While the foregoing is directed to aspects of the present disclosure, other and further aspects of the disclosure may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.