JP2014514813A - Managing network access requests - Google Patents

Abstract

  Methods, systems, and devices for intercepting requests from applications installed on mobile devices are described. The request is a system call that establishes a communication channel for the mobile device. The request is captured and deferred to arrive at the operating system's TCP / IP stack running on the mobile device. Intercepted requests are aggregated with other intercepted requests. Aggregated requests are bundled together and released to the operating system upon detection of a triggering event. Capture, hold, and aggregation of requests from applications are performed when the mobile device is in background mode.

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is filed by Giaretta et al., Having Attorney Docket No. 111354P1, filed March 18, 2011, the entire disclosure of which is expressly incorporated herein by reference. Claims the benefit under 35 USC 119 (e) to US Provisional Patent Application No. 61 / 454,457 entitled "CONNECTIVITY MANAGEMENT FOR APPLICATIONS ON A USER DEVICE".

  Applications or device applets are currently available that operate to give a wide range of add-on services and features to wireless devices. For example, a wireless device can currently download and launch a device applet to perform value-added functions such as shopping, searching, locating, driving navigation, or a series of other functions. Network and application providers generally offer these device applets to device users for an additional fee. Thus, the use of a device applet can enhance the functionality and usability of the wireless device, providing the device user with features and conveniences not originally available on the device itself.

  Generally, a wireless device interfaces with one or more communication networks using any of several radios. For example, a wireless device may include various radios that provide communication using cellular, WiFi, Bluetooth, or other types of radio access technologies. Thus, an application running on the wireless device interfaces with the radio to establish a communication channel, and the channel is used by the application to communicate with the appropriate network.

  The application may continue to interface with the radio on the wireless device to establish a communication channel even when the device is in background mode. As the number of applications installed on a device increases, repeated establishment of network communications while the device is inactive can unnecessarily consume the device's battery power. Further, as the use of wireless devices such as smartphones increases, network signaling associated with communication channel setup can become overloaded.

  A method, system, and device for managing connectivity between a network and an application running on a mobile device are described. In one example, a request for network access from an application running on the device may be intercepted. For example, a wrapper may be placed between the mobile device application and the operating system to intercept the request. Upon intercepting the request, the request may be suspended from arriving at the operating system's Transmission Control Protocol / Internet Protocol (TCP / IP) stack. In one example, the request can be released to the operating system when a triggering event occurs. Request capture, hold, and release may occur when the mobile device is in background mode.

  In one configuration, the request may be aggregated with other intercepted requests to communicate for the mobile device. The interception of requests from applications and the interception of other requests can occur at different times.

  In one example, instructions for the wrapper may be executed. The executed wrapper may perform the interception of the request from the first application. In one configuration, the wrapper may be located between the application layer of the mobile device and the socket layer of the operating system.

  In one configuration, the first application may be identified as the type of application for which the request is pending. Applications can be identified as critical applications or non-critical applications. Only requests from non-critical applications can be held.

  In one embodiment, the triggering event is due to timer expiration, display status change, microphone status change, speaker status change, mobile device global positioning system (GPS) sensor status change, universal serial bus port used An indication that an audio device is connected to the mobile device, an indication that a video device is connected to the mobile device, an indication that a connection to a Wi-Fi type network is available, or It may include at least one of indications that a wireless connection to the cellular type network is open.

  Further, in one example, the delay tolerance of the first application can be determined. Further, a callback function may be provided to the first application based on the determined delay tolerance. The callback function may instruct the first application to connect to the communication resource.

  In one configuration, the expiration time of the first timer associated with the first application may be determined. Also, a tolerance associated with the second application and an expiration time of the second timer can be determined. The second timer may be expired based on the expiration time of the first timer, the tolerance, and the expiration time of the second timer. A request from the first application to communicate for the mobile device and an intercepted request from the second application may be released.

  In one example, a deadline may be received from an application. Requests can be held until before the deadline. A request to connect to a communication resource may be released before the deadline. In one configuration, the request may include a system call to establish a communication channel for the mobile device. The request may be released to the operating system socket layer upon detecting a triggering event.

  In one embodiment, an indication of an interval related to how often a request is released may be received. The interval can be smaller than the timeout value in a stateful internet protocol (IP) middlebox in the network.

  A mobile device configured for wireless communication is also described. The device can include a processor and memory in electronic communication with the processor. The memory can include an operating system. The processor may include a connectivity engine. The engine may be further configured to execute an instruction to intercept a request from a first application on the mobile device. The request can be a request to communicate for a mobile device. The engine suspends the request from arriving at the operating system's TCP / IP stack running on the mobile device and releases the request to the operating system upon detecting a triggering event. Can be further configured.

  An apparatus configured to manage network access requests from applications on mobile devices is also described. The apparatus includes means for intercepting requests from applications on the mobile device. The request can be a request to communicate for a mobile device. The apparatus suspends the arrival of the request on the TCP / IP stack of the operating system running on the mobile device, and releases the request to the operating system upon detecting a triggering event. These means may be further included.

  A computer program product configured to manage network access requests from applications on mobile devices is also described. The product may include non-transitory computer readable media. The medium may include code for intercepting requests from applications on the mobile device. The request can be a request to communicate for a mobile device. The medium has a code for deferring the arrival of the request on the TCP / IP stack of the operating system running on the mobile device, and for releasing the request to the operating system upon detecting a triggering event. And a code.

  The foregoing has outlined rather broadly the features and technical aspects of the disclosed examples. In the following, additional features will be described. The disclosed concepts and specific examples can be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Such equivalent constructions do not depart from the spirit and scope of the appended claims. The features that are believed to characterize both the organization and method of operation of the concepts disclosed herein will be better understood from the following description when considered in conjunction with the accompanying figures. Each of the figures is provided for purposes of illustration and description only, and is not intended to limit the scope of the claims.

  A further understanding of the nature of the present invention may be obtained by reference to the following drawings. In the appended figures, similar components or features may have the same reference label. In addition, various components of the same type can be distinguished by following the reference label with a dash and a second label that distinguishes those similar components. Where only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label, regardless of the second reference label. is there.

Block diagram of a network environment. 1 is a block diagram illustrating a mobile device architecture. FIG. 1 is a block diagram of a mobile device that provides delays in requests for network access. FIG. 4 is an exemplary block diagram of an architecture on a mobile device for delaying requests for network access. FIG. 4 is an exemplary timing diagram for aggregating requests for network access. 1 is a diagram illustrating an example of an architecture implemented on a mobile device. FIG. 6 is a flowchart illustrating an example of a method for delaying a request for network access. 6 is a flowchart illustrating an example of a method for delaying network access requests based on application classification. 7 is a flowchart illustrating an example method for aggregating requests for network access received from several mobile devices. 6 is a flowchart illustrating an example of a method for synchronizing data connection requests. FIG. 4 is a timing diagram in which three applications periodically start connection requests. The timing diagram of FIG. 11 with some of the connection requests synchronized. FIG. 4 is a timing diagram in which three applications periodically start connection requests. FIG. 14 is a timing diagram of FIG. 13 in which some of the connection requests are synchronized.

Detailed description

  Methods, systems, and devices for intercepting requests from applications installed on mobile devices are described. The request may be a system call that establishes a communication channel for the mobile device. The terms “request” and “system call” may be used interchangeably. The request may be captured and deferred to arrive at the operating system's TCP / IP stack running on the mobile device. Intercepted requests can be aggregated with other intercepted requests. Aggregated requests can be bundled together and released to the operating system almost simultaneously with detecting a triggering event on the mobile device. Capturing, holding, and aggregating requests from applications can occur when the mobile device is in background mode.

  In mobile devices such as smartphones and personal digital assistants, software applications can continue to operate even if the user is not actively using the device. Social networking applications, e-mail or other communication applications, applications such as data feeds (popular examples include Facebook, Gmail, Twitter, etc.) Can continue to send and receive data even if they are not using the device. Applications that continue to operate even when the device is not in use on the surface, even under inactivity mode of operation, can cause power consumption and spikes in activity. Activities by these applications may utilize communication resources as provided by the external network.

  The application can trigger frequent transitions by the mobile device from background mode to connected mode, or the application can in some cases enter the background mode or discontinuous reception (DRX), etc. May interfere with entering other alternative connection modes. These high levels of wireless activity by the application when the user is not actively operating the device can result in premature depletion of battery life, undesirable increases in wireless network load, or other undesirable effects.

  A mobile device may be in background mode when some input of the device is not available or is in a sleep state. In other words, the device can be in background mode when the user is not using the device. For example, when an audio input (such as a microphone) is off, the device may be considered in background mode. Further, when visual input (such as the device display) is off, the device may be determined to be in background mode. As described below, additional inputs can be used to determine whether the mobile device is in background mode.

  Describe management of connectivity between a network and an application running on a mobile device. When some applications installed on a mobile device request access to the network when the device is in background mode, an unnecessary amount of network signaling can occur. For example, a first application may initiate a system call to establish a communication channel, and then the channel may be aborted after data is transmitted / received. The second application may then initiate a system call to also establish a communication channel for sending / receiving data. Each time a communication channel is established, the amount of network signaling can increase so that the available bandwidth of the network decreases. Furthermore, when some applications request access to the network while the device is in background mode, an unnecessary amount of battery power can be consumed. Each time a communication channel is established, battery power may decrease so that less power is available when the mobile device enters active mode. Thus, the present systems and methods may defer and aggregate network access requests to reduce network signaling and conserve battery power. As mentioned above, this can be done when the device is not active. Further, system call hold and aggregation may occur when the device battery power falls below a certain threshold amount. When a triggering event occurs (eg, the device enters active mode), the aggregated request reduces the amount of network signaling as well as the battery power consumption associated with each separate request Can be released together for.

  Request hold and aggregation may be performed when the mobile device is in an inactive mode so as not to interfere with the use of the device by the user. In one example, a request for network access from an application on a user device may be intercepted. For example, a wrapper may be placed between the application layer of the mobile device and the operating system layer of the device to intercept the request. In one example, the wrapper may be a software entity that intercepts the request. The wrapper may be transparent to the application in the application layer as well as the operating system in the operating system layer. Upon intercepting the request, the request may be suspended or delayed from arriving at the operating system. In one configuration, the request may be aggregated with other intercepted requests received from additional applications in the application layer. When a triggering event is detected, the aggregated request can be released to the operating system. Thus, the wrapper can intercept and aggregate requests transparently and then relay the aggregated requests when additional processing is complete.

  In addition, an interval may be determined that indicates how often the pending request should be released to the device operating system. The interval can be determined to maintain the state of the middle box described below. In one example, Internet Protocol (IP) hosts can be separated by a stateful middlebox. A stateful middlebox may perform firewall and network address translation (NAT) functions. The function of the firewall may be to determine which inbound / outbound ports of the device are open or available. The NAT function is not always deployed on the cellular network, but can be continuously deployed on the LAN / WLAN. An application running on a mobile device may not distinguish between a cellular network and a Wi-Fi network, and thus the application may “keep alive” requests to keep the NAT function operational on the cellular network. A timer can be used to send The state of the middle box can be maintained until the timer expires. If long-lived connections (TCP or UDP) are required, the middlebox can keep their state across the connection. An application running on a mobile device (eg, a smartphone) may not be adapted to a cellular network (as opposed to a Wi-Fi network). Thus, these applications may select a keep alive / reconnect interval that works everywhere, regardless of whether the interval causes a signaling peak for the cellular network. Therefore, in the following, deferring a request for network access while the device is in background mode, and releasing the request when certain triggering events occur or at intervals determined by a particular network. Describes a system and method for reducing the number of system calls for network access, conserving power and reducing signaling.

  The following description provides examples and does not limit the scope, applicability, or configuration described in the claims. Changes may be made in the function and configuration of the elements described without departing from the spirit and scope of the disclosure. Various embodiments may omit, substitute, or add various procedures or components as appropriate. For example, the described methods may be performed in an order different from the described order, and various steps may be added, omitted, or combined. Also, features described in connection with some embodiments may be combined in other embodiments.

  Referring now to FIG. 1, an example of a wireless network environment 100 is shown in a block diagram. Network environment 100 may include a mobile device 102 and a communication network 115. Device 102 may communicate with network 115 using several wireless channels 110-a. For example, the control channel 110-a-1 can be established between the device 105 and the network 115. In addition, other types of channels 110-a-2 to 110-an may be established. These other types of channels may include data channels, voice channels, and the like.

  In operation, device 102 may execute an application that may interface with network 115 using any of several radios. For example, the executing application may issue a request to establish communication with the network 115. In one example, the request may be a networking system call such as a socket layer call. The request may be intended for the operating system socket layer on the device 105. Conventional devices generally allow these types of requests to go directly to the operating system to be processed. Upon receiving the request, the conventional device initiates a network signaling process to establish control channel 110-a-1 through a data connection setup procedure. When the data connection setup procedure is executed on the mobile device 105, battery power is consumed and the level of signaling across the network can be increased. This can reduce the efficiency of the mobile device 105 and the network 115.

  In one configuration, the device 105 may include an architecture for delaying release of requests to the operating system. This architecture may intercept requests for network access from applications. Intercepting the request may cause the architecture to suspend or delay the request from reaching the operating system's TCP / IP stack. The TCP / IP stack may include a communication protocol that may be incorporated into the operating system and may provide the operating system with a standard for sending data over the network. Intercepted requests may be aggregated with other intercepted requests for network access received from additional applications. Aggregated requests can be bundled together and released as a single request for network access. In another example, the aggregated request may be released upon the occurrence of a specific event (eg, the mobile device becomes active). In one configuration, the architecture described above relating to intercepting, holding, and aggregation may be used when the device 105 is in an inactive mode.

  FIG. 2 illustrates an example of an architecture 200 of a mobile device 105-a that may be an example of the mobile device 105 of FIG. The architecture 200 of the device 105-a may include a connectivity engine 225. The connectivity engine 225 may manage when an application running in the application layer 220 on the device 105-a can access a network, such as the network 115 of FIG. Application layer 220 may include applications that may perform various functions and communicate with an external network, such as network 115, using one or more radios 250-a of wireless unit 245. .

  In one configuration, the connectivity engine 225 may execute the wrapper 230. In one example, the wrapper 230 may intercept system calls for network access that originate from applications in the application layer 220. The wrapper 230 may suspend the request from arriving at the operating system 235 running on the device 105-a. The wrapper 230 may also aggregate the intercepted system call with other system calls intercepted from additional applications. Wrapper 230 may suspend the aggregated system call from arriving at socket layer 240 of operating system 235. When a system call for network access arrives at the socket layer 240, a process for establishing a communication channel using one or more of the radios 250-a may be initiated. The socket layer 240 may process the request and notify the particular radio to initiate a connection setup procedure to establish a connection between the application that initiated the request and the network 115. For example, socket layer 240 may issue a call (or request) to establish a binding between a particular application and a radio, eg, radio 1 250-a-1. Radio 1 250-a-1 begins sending a signal to network 115 to initiate a connection setup procedure by establishing a control channel that may be an example of control channel 110-a-1 of FIG. Can do.

  Rather than initiating a setup procedure each time an application gives a system call for network access, when the aggregated request is released together to socket layer 240, the application that sent the request and the specific A socket layer function may be initiated once to establish a connection with the radio 250-a. The selected radio may then initiate network signaling to establish a data connection between the network 115 and the application that originated the request.

  Thus, device architecture 200 provides for the aggregation of system calls to access the network by applications running on device 105-a. Aggregation can help reduce battery consumption and network signaling by releasing several system calls as a bundle to socket layer 235.

  FIG. 3 shows a block diagram 300 of a mobile device 105-b that implements deferring network access requests and aggregation. Device 105-b may be an example of device 105 of FIG. 1 or FIG. Device 105-b may include a processor 360, memory 355, application layer 220, wrapper 230, connectivity engine 225, operating system 235, and wireless unit 245 all coupled to communicate using communication bus 314. . Memory 355 may store application layer 220, wrapper 230, and operating system 235. The processor 360 may include a connectivity engine 225. The connectivity engine 225 is a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, individual gate or transistor logic, individual hardware components, Alternatively, it may be implemented as any combination thereof designed to perform the functions described herein. The connectivity engine 225 detects a triggering event upon detecting a triggering event, a means for intercepting a request from an application on the mobile device, a means for holding the request from arriving at the operating system on the mobile device. Means for releasing requests to the system. Further, the connectivity engine 225 may include means for aggregating the request with other intercepted requests for communicating for the mobile device 105. The connectivity engine 225 may also include means for executing the wrapper 230 of FIG. 2, FIG. 3, or FIG. The executed wrapper can intercept the request from the application. Further, engine 225 may include means for identifying the application as the type of application for which the request is pending. Further, the connectivity engine 225 may include means for identifying the application as a critical application or a non-critical application, and means for holding only requests from the non-critical application. Note that device 105-b is only one implementation and other implementations are possible.

  In one aspect, the processor 360 includes at least one of a central processing unit (CPU), a processor, a gate array, hardware logic, memory elements, and / or hardware executing software. The processor 360 may suspend a system call for network access initiated by an application executing in the application layer 220 from arriving at the operating system 235 and may be aggregated with other system calls. Operate to control the operation of device 105-b. In one implementation, the processor 360 may execute computer readable instructions related to performing any of a number of functions. For example, the processor 360 may operate to analyze information received or communicated from the device 105-b to achieve interception and aggregation of requests for network access. In another aspect, the processor 360 may provide memory 355, wireless unit 245, application layer 220, wrapper 230, operating system 235, and / or to achieve system call aggregation for network access from several applications. Or it may operate to generate information that may be utilized by the connectivity engine 225.

  The wireless unit 245 may provide some radio / interface that may be used to interface the device 105-b to some external entity, such as an external communication network using some channels 110-a. And / or a processor that executes software and / or software. For example, the wireless unit 245 may provide a wireless / interface for communicating using cellular, WiFi, Bluetooth, or other techniques for communicating with a communication network using channel 110-a.

  Application layer 220 may include a processor executing hardware and / or software that may store and / or execute one or more applications on device 105-b. In one implementation, the application layer 220 allows an application to initiate networking function calls to request networking services, such as requesting a connection to a radio / interface for the purpose of communicating with an external network or system. obtain.

  The operating system 235 may include a socket layer. The socket layer may include hardware and / or software executing processors that may execute socket layer functions. In one implementation, socket layer functions may include functions such as Connect (), Bind (), and Setsockopt (). The Connect () function operates to establish a connection between an application and a specific radio / interface. For example, a particular radio / interface may be selected from a number of candidate radios provided by radio unit 245. In one aspect, the socket layer may perform various socket layer functions or commands.

  The connectivity engine 225 includes a processor executing hardware and / or software that may execute the wrapper 230 to cause the wrapper to intercept requests for network access from applications running on the mobile device 105-b. obtain. Wrapper 230 may also suspend the intercepted request from arriving at operating system 235. Further, the wrapper 230 may aggregate the intercepted request with other intercepted requests. Aggregated requests may be released to the operating system socket layer when a triggering event occurs (eg, mobile device 105-b enters active mode).

  Connectivity engine 225 may cause wrapper 230 to capture, defer, and aggregate requests for network access in various ways. For example, when device 105-b is in background mode, connectivity engine 225 intercepts some requests from some applications running on device 105-a. obtain. Intercepted requests can be aggregated together and deferred until some triggering event occurs. For example, the request may be released when the mobile device 105-b enters an active state. In one configuration, currently pending aggregated requests can be released together. For example, aggregated requests can be bundled and released together to the socket layer as a single system call. The socket layer may initiate a procedure for establishing a communication channel for data connection with the network 115.

  Memory 355 may include RAM, ROM, EEPROM, or other types of memory devices that operate to allow information to be stored and retrieved from device 105-b. In one implementation, the memory 355 may store computer-readable instructions that are executed by the processor 360. Memory 355 also includes several other types of data, including data generated by any of processor 360, wireless unit 245, application layer 220, wrapper 230, operating system 235, and / or connectivity engine 225. Either can be remembered. Memory 355 may include a number of different configurations, including random access memory, battery-backed memory, hard disk, magnetic tape, and the like. Various features may also be implemented on the memory 355, such as compression and automatic backup.

  In various implementations, the device 105-b may be stored on or implemented on a non-transitory computer readable medium, one or more program instructions (“instructions”) or “ A computer program product having a set of “codes” may be included. When code is executed by at least one processor, e.g., processor 360 and / or connectivity engine 225, their execution is transmitted to processor 360 and / or connectivity engine 225 as a function of the aggregation architecture described herein. Device 105-b may be controlled to provide For example, the non-transitory computer readable medium is a floppy disk, CDROM, memory card, flash memory device, RAM, ROM, or other type of memory device or computer readable medium that interfaces with device 105-b. obtain. In another aspect, the set of codes may be downloaded to device 105-b from an external device or communication network resource. The set of code, when executed, operates to provide aspects of the system call aggregation architecture described herein.

  FIG. 4 illustrates an exemplary block diagram 400 of an architecture on a mobile device 105-c that is useful for intercepting and aggregating requests for network access, as described above. Mobile device 105-c may be an example of mobile device 105 of FIG. 1, FIG. 2, or FIG.

  As shown, the blocks are divided between an application processor 490 and a modem processor 495, but various functions may be organized differently than in the example of FIG. Application layer 220 may interact with application connection engine (APP CnE) 475 and socket layer 240. Application connection engine 475 may communicate with modem connection engine (modem CnE) 485. The modem connection engine may manage communication resources such as the wireless unit 245 and some of the radios 250-a therein. The wrapper 230 may be executed in the application processor 490 between the application layer 220 and the operating system socket layer 240. The wrapper 230 may capture data passed between the application layer 220 and the socket layer 240. For example, the wrapper 230 may be placed between the application 220 and the socket layer 240 to intercept system calls sent from the application layer 220 and destined for the socket layer 240. In one configuration, wrapper 230 may intercept system calls from application layer 220 during periods of inactivity by device 105-c, and the wrapper may trigger a triggering event before releasing system calls to socket layer 240. Intercepted calls can be put on hold until a call occurs. A system call may be a request to establish a communication channel using radio 250 in radio unit 245.

  In another example, wrapper 230 may aggregate system calls intercepted from application layer 220 during periods of inactivity by device 105-c. Wrapper 230 was intercepted and aggregated until a specific event occurred before releasing the system call aggregated to socket layer 240 and ultimately wireless unit 245 for operation / transmission. You can put a call on hold.

  In one configuration, wrapper 230 may be invisible to applications at application layer 220 so that applications are not aware that their requests are pending to arrive at socket layer 240. Wrapper 230 can be a separate software component or can be incorporated into another component, such as connectivity engine 225 or application connectivity engine 475.

FIG. 5 shows a timing diagram 500 for several applications, such as a first application and a second application. Applications can be placed in the application layer 220 of the mobile device 105. Timing diagram 500 may be a result of the implementation of connectivity engine 225 of FIG. 2 or FIG. In one arrangement, the first request 505-a-1, can be sent from the first application at time t _0. The first request 505-a-1 may be a Connect () system call. The first request 505-a-1 may be suspended from arriving at the operating system 235 running on the mobile device. For example, the first request may be suspended from arriving at the operating system's TCP / IP stack. The time that the request is held can be represented as H ₀ . First request 505-a-1 can be released to the operating system 235 at time t _2.

In one example, the second request 505-a-2, can be sent from the second application at time t _1. Time t ₁ can be after time t ₀ . The second request 505-a-2 may also be a Connect () system call. Second request 505-a-2 during a certain period of time, expressed as H _1, it may be suspended from reaching the operating system 235. For example, the second request may also be deferred to arrive at the operating system's TCP / IP stack. Second request 505-a-2 may be released at time t _2. Thus, the first request 505-a-1 and the second request 505-a-2 can be released together or at the same time (ie, time t ₂ ). The time period H ₁ can be less than the time period H ₀ . In other words, the second request 505-a-2 may be held for a less time than the first request 505-a-1.

In one configuration, during the time period H ₀ , the first request may be aggregated with the second request 505-a-2 when the second request 505-a-2 is intercepted at time t ₁ . Request aggregation allows both requests to be released at substantially the same time (ie, time t ₂ ). Thus, the timing diagram 500 shows that requests sent at different times (t ₀ and t ₁ ) can be held for different time periods (H ₀ and H ₁ ) and then released at the same time (t ₂ ). It shows that.

  FIG. 6 shows an example of an aggregation architecture that may be implemented on the mobile device 105-d. The mobile device 105-d may be an example of the mobile device 105 of FIGS. 1, 2, 3, and 4. As shown, the device 105-d may include an application layer 220-a, a wrapper 230-b, and an operating system 235. Operating system 235 may include a socket layer 240. The connectivity engine 225 of FIG. 2 or FIG. 3 may execute an instruction to execute the wrapper 230-b software. In one configuration, device 105-d may be in background mode. The mobile device 105-d can, for example, switch all devices in the device 105-d when the screen or display of the device 105-d is off, and when the microphone, speaker, or other audio output of the device 105-d is off. When the Global Positioning System (GPS) mechanism determines that device 105-d is stationary, it may be considered to be in background mode, such as when the device's battery level is below a certain threshold level.

  In one example, some applications 605-a running in the application layer 220-a may send system calls 505-a for network access, such as Connect () system calls. System calls 505-a may be sent from each application at different times. Wrapper 230-b may capture these requests and suspend arriving at operating system 235. In particular, the call may be suspended from arriving at the socket layer 240 of the operating system 235. In one configuration, aggregation module 610 may aggregate intercepted system call 505-a. Aggregated requests may be released together (or substantially at the same time) from wrapper 230-a-1 to socket layer 240 of operating system 235. Upon receiving the aggregated request, socket layer 240 may subsequently establish a connection with network 115. The procedure may include sending a signaling message between the mobile device 105-d and the network 115 to establish the control channel 110-a-1.

  Thus, intercepting, holding, and aggregating requests for network access may reduce power consumption of the mobile device 105-d because multiple system calls are not performed at the socket layer 240 at different times. Instead, multiple requests are bundled together and released to the socket layer 240 at about the same time. Further, request aggregation may reduce the frequency of connection setup procedures with the network 115 and thus reduce network traffic.

  Pending and aggregating requests from application 605-a can be done selectively (ie, implemented so that the user cannot be interrupted). Various factors may be employed to determine when to hold a request from application 605-a to establish a communication channel and determine when to aggregate. For example, the decision to intercept the request may be made based on several characteristics of the mobile device 105-d, such as the screen is off or the audio output is off. Holding the request may be able to handle such a delay when the radio is not loaded, or when the mobile device 105-d is not in use (no call, audio streaming, etc.). Can be implemented only for known applications. Interception and hold of system calls from the application may be implemented based on whether the user subscribes to a service provided by the application. When a user registers for a service, a request from an application may not be deferred from arriving at the operating system. Instead, requests from this subscription-based application may be allowed to pass immediately to the socket layer. In one example, applications running on the mobile device 105-d can be classified. For example, the first application 605-a-1 may be classified as a non-critical application and the second application 605-a-2 may be classified as a critical application. A non-critical application can be an application with some delay tolerance. In other words, system calls from non-critical applications to establish a communication channel can be delayed. However, critical applications can be applications that have little or no delay tolerance. Examples of critical applications can include, but are not limited to, child tracking applications, emergency-based applications, subscription-based applications, and the like. In one configuration, request suspension and aggregation may be performed for requests originating from non-critical applications. Requests sent from critical applications may not be held (or aggregated) and may instead go directly to the operating system socket layer. Pending and aggregation can also be implemented utilizing the above factors or a combination of other factors.

  In addition, various factors may be employed to determine when to release the aggregated request and allow application connectivity. For example, if there is a trigger to establish a data connection setup procedure (such as receiving a system call from a critical application such as an emergency application that cannot be delayed), a communication channel can be established in connection with the emergency application, Pending requests can be released to the socket layer 240 so that the number of transitions between background and connected states can be reduced. Another example is that an aggregated request can be released when a more desirable radio (eg, a wide local area network (WLAN) radio) is activated or selected as the default. The request may also be released if the radio channel is very good (eg, high signal strength, SNR, or other desirable performance metric). The request may also be released periodically as determined in advance or as selectively determined by the mobile device 105-d. Another heuristic for releasing a request to operate incognito may be when the user approaches the device (before the user turns on the screen). In this example, the accelerometer may detect that the user has picked up the phone, or a user proximity sensor may indicate that the user is approaching. In another aspect, while running on battery, the request can be released as soon as the screen is unlocked (eg, after the PIN has been entered correctly). In this manner, the request cannot be released when a random button is pressed (device 105-d is in the wallet or pocket).

  In one example, the triggering event that causes a pending request to be released may be a timer expiration. The event can also be a display status change. For example, the display may change from an “off” state to an “on” state. A microphone status change (off to on) can also be a trigger event. Furthermore, a status change of the GPS sensor can be a triggering event. For example, the sensor may change state when the sensor detects movement of the mobile device. Additional triggering events for releasing the request may include an indication that the universal serial bus port is in use, or an indication that the audio device is connected to the device. In addition, an indication that the video device is connected to the mobile device may also serve as a triggering event to release a pending request to the mobile device operating system. Furthermore, an indication that a connection to a network is available may trigger the release of the request. For example, an indication of connection to a Wi-Fi type network may cause the request to be released. Similarly, an indication that a wireless connection to a cellular type network is already open may trigger the release of the request to the device operating system. In yet another aspect, the request may be released according to some combination of the above or other factors. Although the above description relates to an API architecture, the concepts can be equally applied in hardware, firmware, or any combination of hardware and software.

  In one configuration, the application may be associated with a timer. The time period before the expiration of the timer may indicate the tolerance level of the associated application. For example, a timer that does not accept a tolerance may be referred to as a “hard timer”. A hard timer may be a timer that is intended to expire at a relatively fixed time. Conversely, a timer that accepts a tolerance value can be a “soft timer”. The soft timer may expire at the intended expiration time, but may also allow expiration within a specified tolerance range. As an example, some applications such as an email update service may not require that connection requests be made at a well-defined fixed time. Thus, timers for such applications can be given wide tolerances, and soft timers can be generated and associated with such applications. Conversely, stock programs used by stock traders may require consistent updates at fixed times to ensure the accuracy of stock price information. Such an application may accept little or no tolerance and will therefore be associated with a hard timer.

  In one example, a timer such as one of a soft timer or a hard timer may be about to expire. Once the expiration time is identified, for example, the connectivity engine 225 of FIG. 2 or FIG. 3 may determine whether the expiration time falls within the soft timer tolerance of any of the various applications. For all soft timers whose tolerance falls within the expiration time, the connectivity engine may instruct the timers to expire early. An intercepted network access request from an application whose timer has expired may be released to the mobile device operating system. In some configurations, the network connection may remain open until each of the applications whose timers have expired complete their required communication activity. Since a communication request is made when the timer expires, resource management becomes more efficient as a result of sharing the communication system by applications.

  As described above, an interval or refresh rate can be determined that indicates how often a request should be released. The interval may be determined to maintain the state of the middlebox that performs the firewall and NAT functions. The state of the middlebox can be maintained by the application issuing a keep alive message or a series of shorter connection requests. In one configuration, the network may provide information regarding the minimum refresh rate to maintain the state of the middle box on the mobile device. A refresh rate may be given for a UDP-to-TCP connection. The network may adapt the refresh rate in the middlebox based on the radio load generated due to the amount of keep alive / reconnect messages. For example, if the number of keep-alive messages exceeds a certain threshold, the state in the middlebox can be maintained for a longer time period and the refresh rate for the mobile device can be slowed down. The interval (or refresh rate) can be smaller than the timeout value in the stateful middle box. Thus, the mobile device may open the gate for the uplink (ie, release the request) according to the refresh rate (or interval) indicated by the network. The gate can be opened when the device is not in background mode and closed when the mobile device is in background mode.

  FIG. 7 is a flowchart illustrating an example of a method 700 for holding a request for network access. For clarity, the method 700 is described below with respect to the mobile device 105 shown in FIG. 1, FIG. 2, FIG. 3, or FIG. In one implementation, the processor 360 may execute one or more sets of code for controlling functional elements of the device 105 to perform the functions described below. In one configuration, the method 700 described below may be implemented when the device 105 is in the background mode.

  At block 705, a request from an application on the mobile device 105 is intercepted. The request may be a request for communication for the mobile device, such as establishing a communication channel for the mobile device 105. The request may be sent from an application executing at the application layer 220 of the mobile device 105. In one example, the request can be a request to initiate a data connection setup procedure to allow an application to interface with an external network, such as network 115. For example, the request can be a system call to socket layer 240 of operating system 235 on mobile device 105.

  At block 710, the request may be deferred to arrive at the operating system 235 running on the mobile device 105. For example, the request may be deferred to arrive at socket layer 240 of operating system 235. In one configuration, the wrapper 230 may intercept and hold the request.

  At block 715, upon detecting a triggering event, the request may be released to the operating system. For example, device 105 may enter active mode as described above.

  Accordingly, the method 700 may provide interception and hold of requests for network access submitted by an application executing at the application layer 220 of the mobile device 105. Note that the method 700 is only one implementation, and that the operation of the method 700 can be reordered or possibly modified, as other implementations are possible.

  FIG. 8 is a flowchart illustrating an example method 800 for intercepting a request for network access from a non-critical application running on a mobile device. For clarity, the method 800 is described below with respect to the device 105 shown in FIG. 1, FIG. 2, FIG. 3, or FIG. In one implementation, the processor 360 may execute one or more sets of code for controlling functional elements of the device 105 to perform the functions described below.

  At block 805, a request for network access is intercepted. The request may be sent from an application executing at the application layer 220 of the mobile device 105. In one example, the request can be a request to establish a communication channel with an external network, such as network 115. The request can be a system call to socket layer 240 of operating system 235 on device 105. Upon receiving the request, the socket layer 240 may initiate a procedure for establishing a communication channel and may provide a callback function to the application when the channel is established.

  At block 810, a determination may be made regarding whether the device 105 is in background mode. For example, a determination may be made regarding whether the device 105 is powered off, in sleep mode, and the like. Device 105 may also be determined to be in background mode, for example, when the display of device 105 is inactive, or when the audio output is inactive. If it is determined that device 105-a is inactive, a second determination may be made at block 815 to determine whether the application that initiated the system call is a non-critical application. Critical applications can be emergency applications with priority for network access, subscription-based applications, applications with low tolerance for delay, and so on.

  If it is determined that the device 105 is active or the application is a critical application, the request can be released to the socket layer 240 of the operating system 235. In other words, the request may be released to allow the socket layer to initiate a procedure for establishing a communication channel with the network 115. If it is determined that the device is in background mode and that the application is classified as a non-critical application, at block 820, the request may be suspended from arriving at the operating system and thus set up a communication channel. Delay the start of the procedure for

  At block 825, the request may be aggregated with other intercepted requests. Other requests may be initiated by additional applications running on the mobile device 105. At block 830, a determination may be made regarding whether a triggering event has been detected, as described above. If it is determined that a triggering event is not detected, the method 800 may return to continue to aggregate the intercepted request for network access. However, if it is determined that a triggering event has been detected, at block 835 the aggregated request to the socket layer 240 of the operating system 240 can be released. In other words, system calls from several applications can be suspended, bundled together, and then released as a single system call to the socket layer 240.

  Accordingly, the method 800 may provide intercepting, deferring, and aggregating requests for network access from non-critical applications running on the mobile device 105. By holding and aggregating requests, several system calls can be bundled together and released as a single system call. This can reduce the amount of system calls to initiate a procedure for setting up a communication channel, thus saving battery power for the mobile device 105 as well as reducing network signaling. Note that the method 800 is only one implementation, and that the operation of the method 800 can be reordered or possibly modified, as other implementations are possible.

  FIG. 9 is a flowchart illustrating one configuration of a method 900 for intercepting requests for network access from several applications running on a mobile device. For clarity, the method 900 is described below with respect to the device 105 shown in FIG. 1, FIG. 2, FIG. 3, or FIG. In one implementation, the processor 360 may execute one or more sets of code for controlling functional elements of the device 105 to perform the functions described below.

  At block 905, a first request for network access from a first application is intercepted at a first time. In one example, at block 910, a second request from a second application may be intercepted at a second time. The second time can be different from the first time. At block 915, a third request from the third application may be intercepted at a third time. In one configuration, the third time may be different from the first time and the second time. The intercepted request can be a system call to establish a communication channel for network access. The application may be running on the mobile device 105.

  When the request is intercepted, at block 920, a determination may be made regarding whether the mobile device 105 is in background mode. If it is determined that the device 105 is in the background mode, at blocks 925, 930, and 935, the request may be suspended from reaching the operating system. If the device 105 is in active mode, at block 950, a request may be released to the socket layer 240 of the operating system 235 on the mobile device 105.

  In one configuration, at block 940, the first, second, and third requests may be aggregated or bundled together. At block 945, a determination may be made regarding whether a triggering event has occurred. For example, a determination may be made regarding whether the device has entered active mode, whether the display on the device has been activated, whether the device has changed location, whether the user is near the device, and so on. If no triggering event is detected, the method 900 may return to continue monitoring for detection of the triggering event. If a triggering event is detected, at block 950, the aggregated request to the operating system socket layer may be released. Upon receiving the request, the socket layer may initiate a procedure for establishing a communication channel with an external network such as network 115.

  Accordingly, the method 900 can provide intercepting, holding, and aggregating requests for network access from multiple applications running on the mobile device 105. Thus, several system calls can be bundled together and released as a single system call. This can reduce the amount of system calls, thus reducing battery consumption for the mobile device 105 as well as network signaling. Note that the method 900 is only one implementation and that the operation of the method 900 can be reordered or possibly modified, as other implementations are possible.

  FIG. 10 illustrates one possible process 1000 implemented in some embodiments for improving synchronization between application connection requests, such as network access requests. As described in the examples below, some embodiments may implement process 1000 on a mobile device. For clarity, the method 1000 is described below with respect to the device 105 shown in FIG. 1, FIG. 2, FIG. 3, or FIG. In one implementation, the processor 360 or connectivity engine 225 of FIG. 2 or FIG. 3 executes one or more sets of code for controlling functional elements of the device 105 to perform the functions described below. Can do.

  The method begins at block 1005 by identifying that a first timer, such as one of a soft timer or a hard timer, may be about to expire. This can be accomplished by a central system that polls timers for various applications. Alternatively, each application can individually monitor its own timer and provide notification when the timer expires.

  Once the expiration time is identified, a determination is made at block 1010 as to whether additional timers that may also expire are identified. For example, a determination may be made as to whether the expiration time of the first timer falls within a soft timer tolerance. For all soft timers whose tolerance falls within the expiration time, an additional timer may expire early at block 1015. At block 1020, data for the application associated with the expiration timer may be synchronized. For example, channel access may be granted to an application whose timer has expired by forming a connection. In some embodiments, the connection may then remain open until each of the timer expired applications has completed their required communication activity. Since a communication request is made when the timer expires, resource management becomes more efficient as a result of sharing the communication system by applications. The method 1000 may be performed indefinitely by waiting again for the timer to expire at block 1005, or the method may end.

  At block 1005, the one or more timers that first expire at the intended time may be referred to as a “master timer” or interchangeably referred to as a “trigger event” in some embodiments. . That is, these timers define when other timers (“soft timers”) can expire based on their respective tolerances. Thus, the soft timer or hard timer can act as a master timer. However, only the soft timer can be affected by the master timer (since only the soft timer owns the tolerance).

  FIG. 11 shows one possible series of connection requests for each of the three applications (App1, App2, and App3). These applications may be executed on a mobile device such as the mobile device 105 of FIG. 1, FIG. 2, FIG. 3, or FIG. In particular, FIG. 11 represents a technique for forming a connection based on communication requests from various applications. In this example, connection requests are not coordinated. Thus, each application requests a connection at non-cooperative intervals from other applications. This lack of coordination makes the use of mobile device resources inefficient, as applications ignore the opportunity to share connections. Timer expiration is represented by a vertical arrow at each point in time, and the resulting request period is indicated by a rectangle. Each connection period is represented by a window in a request period rectangle with a width of 30 seconds (this is perceived as a fairly arbitrary duration, and a much shorter or longer duration can occur for each connection. ). This width is merely illustrative and any width may exist in actual devices. The numerical ranges of FIG. 11 as well as the subsequent figures have been selected for illustration only. These diagrams should not necessarily be construed as representing an actual implementation of any system or embodiment.

  In FIG. 11, App1 may initiate a communication request every 5 minutes (connection at times 1, 6, 11, 16, etc.). Similarly, App2 may initiate a connection request every 5 minutes but offset by 1 minute from App1. That is, App2 requests share the same period as App1 requests, but do not share the same phase. Finally, App3 can perform a connection every 10 minutes, and is similarly offset from App1 by 4 minutes. App1, App2, and App3 asynchronous connection requests result in inefficient use of battery power and communication bandwidth because the connection is always activated and deactivated. In this example, 14 separate connections (requiring reactivation of the mobile device's communication elements) to the communication system are made between times 6 and 32.

  Some of the embodiments contemplate providing a system that can coordinate connection requests such that a more efficient connection pattern results. For example, if the mobile device 105 already has a connection to the network for one application, the mobile device 105 can tear down that connection and form another connection without The same connection may be used for another application. Thus, coordinating the timing between application connection requests so that applications share connections may reduce the number of connections that need to be formed. Some of these embodiments may include programming modules that may be used by application developers when implementing applications for platforms that run on the mobile device 105. In some of these embodiments, the mobile device 105 may send information about scheduling to the network. In many embodiments, an application running on the mobile device 105 is a software, firmware, or hardware configured to determine when a “timer”, ie, a specific “expiration time” has occurred. Modules can be included. The timer may be executed by the connectivity engine 225 of FIG. 2 or FIG. The timer may be implemented as part of the connectivity engine 225. These timers indicate the time or time interval during which the application may require a connection. Applications that require periodic updates from the network (or that periodically send information to the network) may rely on these timers to determine when they should request a connection. An application may also need data aperiodically and may request data within a certain time defined by a timer. Some applications may be flexible in how often they need a connection. Some of the embodiments contemplate different types or configurations of timers to accommodate the flexibility or lack thereof associated with each application. In the following description, for ease of explanation, the application will be referred to as having a “timer”, but those skilled in the art will recognize many components that an application can individually associate with one or more timers themselves. Recognize that you prepare.

  12 represents a timing diagram for the application from FIG. 11, where the application employs either a soft timer or a hard timer in connection with a process such as the method of FIG. As described above, the application may run on a mobile device such as mobile device 105 of FIG. 1, FIG. 2, FIG. 3, or FIG. Further, the connectivity engine 225 of FIG. 2 or FIG. 3 may implement process 1000 to coordinate scheduling. In the example of FIG. 12, each of the applications (App1, App2, and App3) includes a soft timer with a tolerance of 2 minutes. The timer expiration that would have occurred in FIG. 11 in the absence of a process, such as process 1000, is indicated by a dashed arrow. A solid arrow represents a timer expiration that occurs under the control of a process such as process 1000. In some embodiments, process 1000 may be performed at each time interval (ie, minutes 1, 2, 3, etc.).

  For example, at time 7, App2's soft timer would normally expire. However, since the App1 timer expired at time 6, which is within the 2-minute tolerance of the App2 soft timer, the App2 soft timer expired early at time 6. Similarly, the expiration of the App3 clock at time 14 falls within the 2-minute tolerance of the clock for both App1 and App2. By time 19, each of the clocks for App1, App2, and App3 has a period (5 minutes, 5 minutes, and 10 minutes, respectively) that is equal or harmonics of each other, so the clocks Be exactly in phase (communication requests are then made at times 19, 24, and 29, the master clock has no impact on other applications) and will utilize communication resources much more efficiently . In general, if timers share equal periods, or if those periods are harmonics (ie, multiples) of each other, they are permanent, excluding interference from the expiration of other “master” timers. (Of course, synchronization can also be interrupted if any period of the application's timer changes). Thus, this example shows that instead of 14 connection requests, 6 connection requests are made between minutes 6 and 33, as compared to the timing diagram 11 when the process is not applied.

  As another example, FIG. 13 shows another situation where the applications (App1, App2, and App3) do not own the same period (8 minutes, 5 minutes, and 10 minutes, respectively). As in the timing diagram of FIG. 11, the connection request of FIG. 13 reflects the traditional non-cooperative techniques employed by most applications. This lack of coordination results in inefficient use of mobile device resources and will reactivate mobile device communication resources 12 times between minutes 7 and 34.

  The application of FIG. 13 differs from FIG. 11 in that App1 of FIG. 13 is time sensitive. A developer or system designer who wishes to adopt some of the benefits of this embodiment may generate a timer with little or no tolerance for App1 in FIG. Therefore, a hard timer can be used for App1. App2 and App3 of FIG. 13 are in contrast not time sensitive and can therefore be adapted by a soft timer. In FIG. 13, App2 and App3 are each given a soft timer with a tolerance of 2 minutes.

  FIG. 14 shows the effect of applying a process such as the process 1000 to the application of FIG. 13 this time. Since the timer App1 in FIG. 14 is a hard timer, it remains the same as App1 in FIG. 13 in the timing diagram 13. However, App3 of FIG. 14 expires early at time 12 based on the expiration of the App2 timer, as App2 expires within 2 minutes of App3's intended expiration time. Then, App2 is synchronized with App1 at time 25, and App3 is synchronized with App2 at time 30. As described above, the application may run on the mobile device 105 of FIG. 1, FIG. 2, FIG. 3, or FIG. Further, mobile device 105 can implement process 1000 to coordinate scheduling. This example shows how the previous synchronization of one clock (App2 at time 25 based on App1) can affect the subsequent synchronization of another clock (App3 at time 30 based on App2). Since the duration of the application clock is not equal or not harmonic, the clock cannot be synchronized accurately forever. Nevertheless, in this example, compared to the timing diagram of FIG. 13 when a process such as process 1000 is not applied, eight connection requests are made between minute 6 and minute 33 instead of 12 connection requests. Indicates that

  Master clocks can be prioritized based on the application with which they are associated. That is, an application that consumes more bandwidth or battery power may be less suitable for sharing resources than an application that consumes less bandwidth or battery power. Thus, in some embodiments, the mobile device 105 may respond to and / or respond to an expired “master” timer behavior before the process 1000 prematurely expires a soft timer with a tolerance within an appropriate range. It can be adjusted to take into account priorities. As an example, the process may determine the bandwidth requirements for each application for which the timer (ie, the master timer) has expired in block 1005 as compared to the application bandwidth requirements for which tolerance allows early expiration of the timer. Further considerations can be made. If the cumulative bandwidth requirement of the application with the master timer relaxes against sharing the channel with other applications, the mobile device 105 can take appropriate action. For example, a connection request may be made in an application with a master timer that is enabled to perform an operation. The soft timers will then have their intended expiration (if allowed by the soft timer tolerance) so that the application will utilize existing connections once the master timer application no longer consumes excessive bandwidth. Can be expired at an appropriate time (possible after time). Alternatively, the expiration of the soft timer can be delayed until a new connection request is made that employs less bandwidth, or until the end of the soft timer tolerance.

  In some of the embodiments described above, as described with reference to FIGS. 11 and 13, timer expiration is shown to occur at the rising edge of the communication window. Some embodiments instead contemplate performing the analysis at the “falling edge” of the data connection, ie, when communication with the node is about to go to sleep. Because both opening and closing a connection are costly, the mobile device 105 does not initiate a new request if any application is trying to open a connection and when the current connection is closed, To ascertain whether an existing connection can be used instead, a process similar to process 1000 may be performed before closing the connection.

  Employing the techniques and structures disclosed herein, a mobile device captures system calls from applications and provides an application program interface (API) to hold them from arriving at the operating system. A software layer (called a wrapper for explanation) may be employed. Because captured calls can be aggregated, frequent activation of the mobile device can be reduced and other communication resources can be preserved during periods when the user is not actively using the mobile device.

  Those of skill in the art will 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 referred to throughout the above description are voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any of them Can be represented by a combination.

  Further, those skilled in the art will appreciate that the various exemplary logic blocks, modules, circuits, and algorithm steps described with respect to the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. Will be understood. 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. Those skilled in the art may implement the described functionality in a variety of ways for each particular application, but such implementation decisions will be interpreted as deviating from the scope of exemplary embodiments of the invention. Should not.

  Various exemplary logic blocks, modules, and circuits described in connection with the embodiments disclosed herein include general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gates. Implemented or implemented using an array (FPGA) or other programmable logic device, individual gate or transistor logic, individual hardware components, or any combination thereof designed to perform the functions described herein. obtain. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor is also implemented as a combination of computing devices, eg, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors associated with a DSP core, or any other such configuration. obtain.

  The method or algorithm steps described with respect to the embodiments disclosed herein may be implemented directly in hardware, may be implemented in software modules executed by a processor, or may be implemented in a combination of the two. Software modules include random access memory (RAM), flash memory, read only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disk, removable disk, CD-ROM, Or it may reside in any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can 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 can reside in an ASIC. The ASIC may reside in the 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 the non-transitory computer readable medium as one or more instructions or code, or transmitted via the non-transitory computer readable medium. Computer-readable media includes both computer storage media and computer 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 can be accessed by a computer. By way of example, and not limitation, such computer readable media can be RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or desired program in the form of instructions or data structures. Any other medium that can be used to carry or store the code and that can be accessed by a computer can be provided. Any connection is also properly termed a computer-readable medium. For example, software sends from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, wireless, and microwave Where included, coaxial technology, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. As used herein, a disk and a disc are a compact disc (CD), a laser disc (registered trademark) (disc), an optical disc (disc), a digital versatile disc (DVD). ), Floppy® disk and Blu-ray® disk, which normally reproduces the data magnetically, and the disk uses a laser to reproduce the data. Reproduce optically. 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 present 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 spirit or scope of the invention. Can be done. Accordingly, the present invention is not limited to the exemplary embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (41)

A method for wireless communication on a mobile device, comprising:
Intercepting a request from a first application on the mobile device, wherein the request is a request to communicate for the mobile device;
Suspending the request from arriving at a transmission control protocol / internet protocol (TCP / IP) stack of an operating system running on the mobile device;
Upon detecting a triggering event, releasing the request to the operating system;
A method comprising:   The method of claim 1, wherein the holding is performed during a period in which the mobile device is in a background mode. The method of claim 1, further comprising aggregating the request with another intercepted request to communicate for the mobile device.   The method of claim 3, wherein the intercepting the request from the application and the intercepting the other request are performed at different times. The method of claim 1, further comprising executing instructions for a wrapper, wherein the executed wrapper performs the intercepting the request from the first application. Method.   The method of claim 5, wherein the wrapper is located between an application layer of the mobile device and a socket layer of the operating system. The method of claim 1, further comprising identifying the first application as a type of application for which a request is pending. Identifying the application as a critical or non-critical application;
Hold only requests from non-critical applications,
The method of claim 7, further comprising:   The triggering event includes timer expiration, display status change, microphone status change, speaker status change, global positioning system (GPS) sensor status change of the mobile device, universal serial bus port in use An instruction that an audio device is connected to the mobile device, an instruction that a video device is connected to the mobile device, an instruction that a connection to a Wi-Fi type network is available, or a cellular The method of claim 1, comprising at least one of indications that a wireless connection to a type of network is open. Determining a delay tolerance of the first application;
Providing a callback function to the first application based on the determined delay tolerance, wherein the callback function instructs the first application to connect to a communication resource. When,
The method of claim 1, further comprising: Determining an expiration time of a first timer associated with the first application;
Determining a tolerance associated with the second application and an expiration time of the second timer;
Expiring the second timer based on the expiration time of the first timer, the tolerance, and the expiration time of the second timer;
Releasing the request from the first application and the intercepted request from the second application to communicate for the mobile device;
The method of claim 1, further comprising: Receiving a deadline from the application;
Deferring the request until before the deadline;
Releasing the request to connect to the communication resource before the deadline;
The method of claim 1, further comprising:   The method of claim 1, wherein the request comprises a system call to establish a communication channel for the mobile device. The method of claim 1, further comprising releasing the request to a socket layer of the operating system upon detecting the triggering event. The method of claim 1, further comprising receiving an indication about an interval related to how often the release of the request is made.   The method of claim 15, wherein the interval is less than a timeout value in a stateful internet protocol (IP) middlebox in the network. A mobile device configured for wireless communication,
A processor;
A memory in electronic communication with the processor, the memory comprising an operating system,
The processor comprises a connectivity engine, the engine comprising:
Intercepting a request from a first application on the mobile device, wherein the request is a request to communicate for the mobile device;
Suspending the request from arriving at the TCP / IP stack of the operating system running on the mobile device;
Upon detecting a triggering event, releasing the request to the operating system;
A mobile device configured to execute instructions for performing.   The mobile device according to claim 17, wherein the holding is performed during a period in which the mobile device is in a background mode. The mobile device of claim 17, further comprising aggregating the request with other intercepted requests to communicate for the mobile device.   20. The mobile device of claim 19, wherein the intercepting the request from the first application and the intercepting the other request occur at different times.   The memory further comprises a wrapper, and the connectivity engine is further configured to execute instructions for the wrapper, and the wrapper intercepts the request from the application when the instructions are executed. The mobile device according to claim 17, configured as follows.   The mobile device of claim 21, wherein the wrapper is located between an application layer of the mobile device and a socket layer of the operating system. The connectivity engine is
The mobile device of claim 17, further configured to execute instructions for identifying the first application as a type of application for which a request is pending. The connectivity engine is
Identifying the application as a critical or non-critical application;
Hold only requests from non-critical applications,
24. The mobile device of claim 23, further configured to execute instructions for performing.   The triggering event includes timer expiration, display status change, microphone status change, speaker status change, global positioning system (GPS) sensor status change of the mobile device, universal serial bus port in use An instruction that an audio device is connected to the mobile device, an instruction that a video device is connected to the mobile device, an instruction that a connection to a Wi-Fi type network is available, or a cellular The mobile device of claim 17, comprising at least one of indications that a wireless connection to a type of network is open. The connectivity engine is
Determining a delay tolerance of the first application;
Providing a callback function to the first application based on the determined delay tolerance, wherein the callback function instructs the first application to connect to the communication resource And
The mobile device of claim 17, further configured to execute instructions for performing. The connectivity engine is
Determining an expiration time of a first timer associated with the first application;
Determining a tolerance associated with the second application and an expiration time of the second timer;
Expiring the second timer based on the expiration time of the first timer, the tolerance, and the expiration time of the second timer;
Releasing the request from the first application and the intercepted request from the second application to communicate for the mobile device;
The mobile device of claim 17, further configured to execute instructions for performing. The connectivity engine is
Receiving a deadline from the application;
Deferring the request until before the deadline;
Releasing the request to connect to the communication resource before the deadline;
The mobile device of claim 17, further configured to execute instructions for performing.   The mobile device of claim 17, wherein the request comprises a system call to establish a communication channel. The connectivity engine is
The mobile device of claim 17, further configured to execute instructions to release the request to a socket layer of the operating system upon detecting the triggering event. The connectivity engine is
The mobile device of claim 17, further configured to execute instructions for receiving an indication of an interval related to how often the release of the request is made.   32. The mobile device of claim 31, wherein the interval is less than a timeout value in a stateful internet protocol (IP) box in the network. An apparatus configured to manage requests for network access from applications on a mobile device,
Means for intercepting a request from an application on the mobile device, wherein the request is a request to communicate for the mobile device;
Means for deferring the arrival of the request at a TCP / IP stack of an operating system running on the mobile device;
Means for releasing the request to the operating system upon detection of a triggering event;
An apparatus comprising:   34. The apparatus of claim 33, wherein the holding is performed during a period when the mobile device is in a background mode. 34. The apparatus of claim 33, further comprising means for aggregating the request with other intercepted requests for communicating for the mobile device.   34. The apparatus of claim 33, wherein the intercepting the request from the application and the intercepting the other request occur at different times. 34. A means for executing a wrapper, the executed wrapper further comprising means for executing configured to intercept the request from the first application. Equipment.   The apparatus of claim 37, wherein the wrapper is located between an application layer of the mobile device and a socket layer of the operating system. 34. The apparatus of claim 33, further comprising means for identifying the application as a type of application for which requests are pending. Means for identifying the application as critical or non-critical, and
A means to defer requests only from non-critical applications;
40. The apparatus of claim 39, further comprising: A computer program product configured to manage requests for network access from applications on a mobile device, the product comprising a non-transitory computer readable medium, the medium comprising:
Code for intercepting a request from an application on the mobile device, wherein the request is a request for communicating for the mobile device;
Code for deferring the arrival of the request at a TCP / IP stack of an operating system running on the mobile device;
Code for releasing the request to the operating system upon detection of a triggering event;
A computer program product comprising: