KR20140005298A - Management of network access requests - Google Patents

Abstract

Methods, systems, and devices are described for intercepting requests from applications installed on a mobile device. Requests are system calls that establish communication channels for a mobile device. Requests are captured and held from reaching the TCP / IP stack of the operating system running on the mobile device. Intercepted requests are collected along with other intercepted requests. The collected requests are bundled together and released to the operating system upon detection of the triggering event. Capture, hold, and collection of requests from applications occur when the mobile device is in background mode.

Description

MANAGEMENT OF NETWORK ACCESS REQUESTS}

Cross-Reference to Related Applications

This application is referred to as "SYSTEMS AND METHODS FOR SYNCHRONIZING DATA CONNECTION REQUESTS," US Provisional Patent Application No. 61 / 434,253, filed January 19, 2011, entitled "CONNECTIVITY MANAGEMENT FOR APPLICATIONS ON A USER DEVICE." U.S. Provisional Patent Application No. 61 / 454,457 filed March 18, 2011, et al., Filed June 30, 2011, entitled " Controlling Application Access to a Network. &Quot; Priority of US Patent Application No. 61 / 503,395 and US Patent Application No. XX / XXX, XXX filed under the name “SYSTEMS AND METHODS FOR SYNCHRONIZATION OF APPLICATION COMMUNICATIONS” shall be 35 USC. Claimed under § 119 (e), their disclosures are hereby expressly incorporated by reference in their entirety.

Applications or device applets that operate to provide a wide range of add-on services and features to wireless devices are now available. For example, it is now possible for wireless devices to download and launch device applets to perform an array of shopping, searching, position location, driving navigation, or other functions. Network and application providers generally supply these device applets to device users for an additional cost. Thus, a user of device applets can increase the functionality and usability of wireless devices and provide device users with features and conveniences that are not originally available on the devices themselves.

Typically, a wireless device uses any of a number of radios to interface with one or more communication networks. For example, a wireless device can include various radios that provide communications 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 applications to communicate with the appropriate network.

Applications may continue to interface with radios on the wireless device to establish communication channels even when the device is in background mode. As the number of applications installed on a device increases, the battery power of the device may be unnecessarily consumed due to the repeated setup of network communications while the device is not active. In addition, with the increased use of wireless devices such as smartphones, data networks may be overloaded by network signaling associated with the setup of communication channels.

Methods, systems, and devices are described for managing connectivity between an application running on a mobile device and a network. In one example, a request for network access from an application running on a device can be intercepted. For example, the wrapper can be placed between the operating system and the application of the mobile device to intercept the request. Upon intercepting the request, the request can be suspended from reaching 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. Capturing, holding and releasing requests can occur when the mobile device is in background mode.

In one configuration, the request can be collected along with other intercepted requests to perform communication for the mobile device. Intercept of a request from an application and intercept of other requests may occur at different times.

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

In one configuration, the first application may be identified as the class of application that holds the requests. The application can be identified as a critical application or a non-critical application. Only requests from non-critical applications can be suspended.

In one embodiment, the triggering event may expire the timer, change the state of the display, change the state of the microphone, change the state of the speaker, change the state of the Global Positioning System (GPS) sensor of the mobile device, an indication that the universal serial bus port is busy, At least one of an indication that the audio equipment is connected to the mobile device, an indication that the video equipment is connected to the mobile device, an indication that a connection to a Wi-Fi type network is available, or an indication that a radio connection to a cellular type network is open at least. It may include one.

Also, in one example, the delay tolerance of the first application can be determined. In addition, 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 resources.

In one configuration, the expiration time of the first timer associated with the first application may be determined, and the tolerance and expiration time of the second timer associated with the second application may also be determined. The second timer may be forced to expire based on the expiration time of the first timer, the tolerance, and the expiration time of the second timer. Requests from the first application and intercepted requests from the second application may be released to perform communication for the mobile device.

In one example, a deadline may be received from the application. The request may be held until before the deadline. The request to access the communication resources 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 can be released to the socket layer of the operating system upon detecting a triggering event.

In one embodiment, an indication of the interval as to how often a release of the request occurs may be received. The interval may be smaller than the timeout value in the stateful Internet Protocol (IP) middlebox in the network.

Also described are mobile devices configured for wireless communication. The device may include a processor and memory in electronic communication with the processor. The memory may include an operating system. The processor may include a connectivity engine. The engine may be configured to execute instructions to intercept a request from the first application on the mobile device. The request can be a request to perform communication for the mobile device. The engine may be further configured to withhold the request from reaching the TCP / IP stack of the operating system running on the mobile device and release the request to the operating system upon detecting a triggering event.

Also described is an apparatus configured to manage requests for network access from applications for a mobile device. The apparatus includes means for intercepting a request from an application on the mobile device. The request can be a request to perform communication for the mobile device. The apparatus can further include means for withholding the request from reaching the TCP / IP stack of the operating system running on the mobile device, and means for releasing the request to the operating system upon detection of the triggering event.

Also described is a computer program product configured to manage requests for network access from applications on a mobile device. The article may comprise a non-transitory computer-readable medium. The medium can include code for intercepting a request from an application on a mobile device. The request can be a request to perform communication for the mobile device. The medium may further include code for withholding the request from reaching the TCP / IP stack of the operating system running on the mobile device, and code for releasing the request to the operating system upon detection of the triggering event.

The foregoing has outlined rather broadly the features and technical aspects according to the disclosure. Additional features will be described below. The conception and specific examples disclosed may 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. For both its construction and method of operation, features considered to be characteristic of the concepts as disclosed herein will be better understood from the following description when considered in conjunction with the accompanying drawings. Each of the figures is provided for the purpose of illustration and description only and not as a definition of the limits of the claims.

Further understanding of the nature of the invention may be realized with reference to the following figures. In the accompanying drawings, similar components or features may have the same reference label. In addition, several components of the same type can be distinguished by following a reference label by a dashed line and a second label that distinguishes between similar components. If 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 independent of the second reference label.

1 shows a block diagram of a network environment.
2 shows a block diagram illustrating an architecture for a mobile device.
3 shows a block diagram of a mobile device providing a delay of requests for network access.
4 shows a sample block diagram of an architecture on a mobile device for delaying requests for network access.
5 shows an example timing diagram for collecting requests for network access.
6 shows an example of architecture implemented on a mobile device.
7 is a flow diagram illustrating an example of a method for delaying requests for network access.
8 is a flow diagram illustrating an example of a method for delaying requests for network access based on a classification of an application.
9 is a flow diagram illustrating an example of a method for collecting requests for network access received from multiple mobile devices.
10 is a flowchart illustrating an example of a method for synchronizing data connection requests.
11 illustrates a timing diagram in which three applications periodically initiate connection requests.
12 illustrates the timing diagram of FIG. 11 with some of the connection requests synchronized.
13 illustrates a timing diagram in which three applications periodically initiate connection requests.
14 illustrates the timing diagram of FIG. 13 in which some of the connection requests are synchronized.

Methods, systems, and devices for intercepting requests from applications installed on a mobile device are described. The requests can be system calls that establish communication channels for the mobile device. The terms "requests" and "system calls" can be used interchangeably. Requests can be held from reaching the TCP / IP stack of the operating system that is captured and running on the mobile device. Intercepted requests can be collected along with other intercepted requests. The collected requests can be bundled together and released to the operating system at about the same time upon detecting the triggering event on the mobile device. Capture, hold, and collection of requests from applications can occur when the mobile device is in background mode.

In mobile devices, such as smartphones, personal digital assistants, and the like, software applications can continue to operate even if the user is not actively using the device. Applications such as social networking applications, email or other communication applications, data feeds, and the like (popular examples include Facebook®, Gmail®, Twitter®, etc.) can be used to retrieve data even when the user is not using the device. Can continue to transmit and receive. Even under inactive mode of operation, power consumption and spikes during activation may arise from applications that continue to operate, even if the device is not used on the surface. Operation by these applications may use communication resources such as those provided by an external network.

Applications may trigger frequent transitions by the mobile device from background mode to connected mode, or they may otherwise interfere with the device entering other alternative connected modes such as background mode or discontinuous reception (DRX). have. These elevated levels of radio operation by applications when the user is not actively involved in the device can result in premature exhaustion of battery life, unwanted increased load of radio networks, or other unwanted effects.

The mobile device may be in background mode when certain inputs of the device do not operate or are in a sleep state. In other words, the device may be in background mode when the user uses the device. For example, if audio inputs (eg, a microphone) are off, the device may be considered to be in background mode. In addition, when visual inputs (eg, display of the device) are off, the device may be determined to be in background mode. As will be described below, additional inputs can be used to determine whether the mobile device is in background mode.

Management of connectivity between a network and an application running on a mobile device is described. If a number of applications installed on the mobile device request access to the network when the device is in background mode, an unnecessary amount of network signaling may occur. For example, the first application may initiate a system call to establish a communication channel, and then after the data is transmitted / received, the channel may be disconnected. The second application may then initiate a system call to establish a communication channel for sending / receiving data. Each time a communication channel is established, the amount of network signaling may increase so that the available bandwidth of the network may be reduced. In addition, if multiple applications request access to the network while the device is in background mode, an unnecessary amount of battery power may be consumed. Each time a communication channel is established, battery power may be reduced such that the available power is lower when the mobile device enters an active mode. As a result, the systems and methods of the present invention may suspend and collect requests for network access to reduce network signaling and conserve battery power. As mentioned previously, this may occur if the device is not active. In addition, hold and collection of system calls can occur when the device's battery power falls below a certain threshold amount. When a triggering event occurs (e.g., when the device enters active mode), the collected requests are combined to reduce the amount of network signaling as well as to reduce the battery power associated with each separate request. Can be released.

Pending and collecting requests may be performed when the mobile device is in an inactive mode to not 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 can be intercepted. For example, a wrapper can be placed between the operating system layer of the device and the application layer of the mobile device to intercept requests. In one example, the wrapper may be a software entity that intercepts requests. The wrapper may be transparent to the applications in the application layer and the operating system in the operating system layer. Upon intercepting a request, the request can be held or delayed from reaching the operating system. In one configuration, the request may be collected with other intercepted requests received from additional applications in the application layer. If a triggering event is detected, the collected requests can be released to the operating system. As a result, the wrapper can transparently intercept and collect the requests and then relay the collected requests when further processing is complete.

In addition, an interval may be determined that indicates how often requests are released for the operating system of the device. The interval may be determined to hold the state of the middlebox described below. In one example, Internet Protocol (IP) hosts may be separated by stateful middleboxes. Stateful middleboxes can perform firewall and network address translation (NAT) functions. The function of the firewall may be to determine if the inbound / outbound ports of the device are open or available. NAT functions may not be constantly deployed on cellular networks, but may still be deployed on a LAN / WLAN. Applications running on the mobile device may not differentiate between the cellular network and the Wi-Fi network, as a result of which the timers may be used to issue "keep-live" requests to withhold NAT functions that are operable on the cellular network. Can be used. The state of the middleboxes may be held until the timer keeps up. If long-lived connections (TCP or UDP) are required, the middleboxes can maintain their state throughout the connection. Applications running on mobile devices (eg, smartphones) may not be coordinated for cellular networks (compared to Wi-Fi networks). As a result, these applications can select keep-alive / reconnect intervals wherever the peak is signaling for cellular networks, regardless of what the spacing causes. Thus, the follow up reduces the number of system calls for network access by holding these requests for network access while the device is in background mode and releasing the requests at intervals determined by the particular network or when a specific triggering event occurs. Systems and methods for conserving power and reducing signaling are described.

The following description provides examples and is not a limitation of the scope, applicability, or configuration described in the claims. Changes may be made in the function and arrangement of elements discussed 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 a different order than described, and various steps may be added, described, or combined. Furthermore, the features described for particular embodiments may be combined in other embodiments.

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

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

In one configuration, device 105 may include an architecture for delaying the release of a request to the operating system. This architecture can intercept requests for network access from applications. When intercepting a request, the architecture can withhold or delay the request from reaching the operating system's TCP / IP stack. The TCP / IP stack may include communication protocols that may be embedded into the operating system, providing the operating system with a standard for transferring data over the network. Intercepted requests may be collected along with other intercepted requests for network access received from additional applications. The collected requests can be bundled together and released as a single request for network access. In another example, the collected requests may be released upon the occurrence of a particular event (eg, the mobile device becomes active). In one configuration, the architecture described above with respect to intercepting, holding and collecting may be used when the device 105 is in inactive mode.

FIG. 2 shows an example of architecture 200 of mobile device 105-a, which may be an example of mobile device 105 of FIG. 1. Architecture 200 of device 105-a may include connectivity engine 225. The connectivity engine 225 may manage when applications running in the application layer 220 on the net device 105-a can access a network, such as the network 115 of FIG. 1. Application layer 220 includes applications that can execute to provide various functions and communicate with external networks, such as network 115, using one or more of radios 250-a of radio unit 245. can do.

In one configuration, connectivity engine 225 may execute wrapper 230. In one example, wrapper 230 may intercept system calls for network access originating from an application within application layer 220. The wrapper 230 may withhold the request from reaching the operating system 235 running on the device 105-a. The wrapper 230 may also collect intercepted system calls along with other system calls that are intercepted from additional applications. The wrapper 230 may suspend the collected system calls from reaching the socket layer 240 of the operating system 235. When a system call for network access reaches socket layer 240, a process may be initiated to establish a communication channel using one or more of radios 250-a. The socket layer 240 may process a request and notify a particular radio to initiate a connection establishment procedure to establish a connection between the network 115 and the application that initiated the request. For example, socket layer 240 may issue calls (or requests) to establish a binding between a particular application and radio, eg, radio 1 250-a-1. Radio 1 250-a-1 may begin transmitting signals to the network 115 to begin the connection setup procedure by setting up a control channel, which may be an example of the control channel 110-a-1 of FIG. 1. have.

When the collected requests are released together in the socket layer 240, the socket layer functions do not initiate setup procedures each time the application provides a system call for network access, but rather initiate specific radio 250-a and requests. It may be initiated once to establish a connection between the sending applications. The selected radios can then begin network signaling to establish a data connection with the network and the applications that sent the requests.

Thus, device architecture 200 provides a collection of system call access to the network by applications running on device 105-a. The collection may serve to reduce battery consumption and network signaling by releasing multiple system calls as a bundle for the socket layer 235.

3 shows a block diagram 300 of a mobile device 105-b that implements the hold and collection of requests for network access. The device 105-b may be an example of the device 105 of FIG. 1 or 2. The device 105-b may include a processor 360, a memory 355, an application layer 220, a wrapper 230, a connectivity engine 225, an operating system 235, and a radio unit 245. All of which are coupled to communicate using a communication bus 314. The memory 355 may store the application layer 220, the wrapper 230, and the operating system 235. Processor 360 can include connectivity engine 225. Connectivity engine 225 may be a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC), 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. Connectivity engine 225 may include means for intercepting a request from an application on the mobile device, means for holding the request from reaching the operating system on the mobile device, and sending a request to the operating system upon detecting a triggering event. It may include means for release. In addition, connectivity engine 225 may include means for collecting the request along with other intercepted requests to perform communication for mobile device 105. Connectivity engine 225 may include means for implementing wrapper 230 of FIGS. 2, 3, or 4. The executed wrapper can intercept the request from the application. In addition, the engine 225 may include means for identifying the application as the class of the application holding the requests. In addition, the connectivity engine 225 may include means for identifying an application as a critical or non-critical application, and means for withholding only requests from non-critical applications. It should be noted that the device 105-b is an implementation of one terminal, and other implementations are possible.

In one aspect, 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 operates to control the operation of the device 105-b, so that system calls for network access initiated by applications executing at the application layer 220 are suspended from arriving from the operating system. And can be collected with other system calls. In one implementation, processor 360 may execute computer-readable instructions related to performing any of a number of functions. For example, processor 360 may be operable to analyze information received or communicated from device 105-b to effect intercept and collection of requests for network access. In another aspect, processor 360 may execute memory 355, radio unit 245, application layer 220, wrapper 230, to execute collection of system calls for network access from multiple applications. It may be operable to generate information that may be used by operating system 235 and / or connectivity engine 225.

The radio unit 245 can be used to interface the device 105-b with a number of external entities, such as external communication networks using the plurality of channels 110-a. Processor and / or hardware executing software capable of providing the software. For example, radio unit 245 provides radios / interfaces for communicating using cellular, WiFi, Bluetooth, or any other technology for communicating with communication networks using channels 110-a. can do.

The application layer 220 can include a processor and / or hardware that executes software that can store and / or execute one or more applications on the device 105-b. In one implementation, the application layer 220 initiates networking function calls to request applications to connect to the radio / interface, for example for communication with an external network or system, to request networking services. It can be done.

Operating system 235 may include a socket layer. The socket layer may include a processor and / or hardware that executes software capable of performing socket layer functions. In one implementation, the socket layer functions may include functions such as Connect (), Bind (), and Setsockopt (). The Connect () function operates to establish a connection between a particular radio / interface and an application. 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.

Connectivity engine 225 may include processor execution software and / or hardware capable of executing wrapper 230 to cause the wrapper to intercept a request for network access from an application running on mobile device 105-b. Can be. The wrapper 230 may also suspend the intercepted request from arriving from the operating system 235. In addition, wrapper 230 may collect the intercepted request along with other intercepted requests. The collected requests may be released to the socket layer of the operating system when a triggering event occurs (eg, when the mobile device 105-b enters active mode).

Connectivity engine 225 may cause wrapper 230 to capture, withhold, and collect requests for network access in a variety of ways. For example, if device 105-b is in background mode, connectivity engine 225 (via wrapper 230) may have multiple requests from multiple applications executing on device 105-a. Can intercept them. Intercepted requests can be collected and held together until a specific triggering event occurs. For example, requests can be released when the mobile device 105-b enters an active state. In one configuration, the collected requests currently pending may be released together. For example, the collected requests can be bundled and released together in the socket layer as a single system call. The socket layer can initiate procedures to establish communication channels for data communication with the network 115.

Memory 355 may include RAM, ROM, EEPROM, or any other type of memory device operative to cause information to be stored and retrieved from device 105-b. In one implementation, the memory 355 may store computer-readable instructions executed by the processor 360. Memory 355 is also created by any of processor 360, radio unit 245, application layer 220, wrapper 230, operating system 235, and / or connectivity engine 225. Any of a number of other types of data, including data, may be stored. Memory 355 may include a number of different configurations including random access memory, battery-back memory, hard disks, magnetic tape, and the like. Various features, such as compression and automatic backup, can also be implemented on memory 355.

In various implementations, device 105-b includes a computer program product having one or more program instructions (“instructions”) or a set of “codes” embedded or stored on a non-transitory computer readable medium. If the code is executed by at least one processor, for example, the processor 360 and / or the connectivity engine 225, their execution is performed by the processor 360 and / or the connectivity engine 225. ) May control device 105-b to provide the functions of the collection architecture described herein, for example, non-transitory computer-readable media may include floppy disks, CDROMs, memory cards, flash memory devices. , RAM, ROM, or any other type of memory device or computer-readable medium that interfaces with device 105-b. Teuneun may be downloaded into the device (105-b) from an external device or communication network resource. A set of codes, operates to provide aspects of a, when executed, call the system described herein acquisition architecture.

4 shows a sample block diagram 400 of an architecture on a mobile device 105-c useful for intercepting and collecting requests for network access as described above. Mobile device 105-c may be an example of mobile architecture 105 of FIG. 1, 2, or 3.

As shown, the blocks are split between the application processor 490 and the modem processor 495, but various functionality may be organized differently from the example of FIG. 4. The application layer 220 may interact with the socket layer 240 and the application connection engine (APP CnE) 475. The application connection engine 475 may communicate with a modem connection engine (Modem CnE) 485. The modem connection engine may manage communication resources such as the radio unit 245 and the plurality of radios 250-a therein. The wrapper 230 may run in an application processor 490 between the socket layer 240 and the application layer 220 of the operating system. The wrapper 230 may capture data transferred between the socket layer 240 and the application layer 220. For example, wrapper 230 may be placed between application layer 220 and socket layer 240 to intercept system calls intended for socket layer 240 and transmitted from application layer 220. In one configuration, wrapper 230 may intercept system calls from application layer 220 during the period of inactivity by device 105-c, and the wrapper may trigger the event before releasing the system call to socket layer 240. You can hold the intercepted call until it occurs. The system call may be a request to establish a communication channel using radio 250 in radio unit 245.

In another example, the wrapper 230 may collect intercepted system calls from the application layer 220 during the period of inactivity by the device 105-c. The wrapper 230 may suspend the intercepted collected calls until a specific event occurs before releasing the collected system calls for the socket layer 240 and ultimately the radio unit 245 for operation / transmission. .

In one configuration, the wrapper 230 may be invisible to the applications at the application layer 220, so that the applications do not know that their requests are being held from reaching the socket layer 240. The wrapper 230 may be a separate software component or may be incorporated into another component, such as the connectivity engine 225 or the application connection engine 475.

5 shows timing diagrams 500 for a number of applications, such as a first application and a second application. The applications may be located in the application layer 220 of the mobile device 105. Timing diagrams 500 may be the result of an implementation of the connectivity engine 225 of FIG. 2 or 3. In one configuration, the first request 505-a-1 may be sent from the first application at time t ₀ . The first request 505-a-1 may be a Connect () system call. The first request 505-a-1 may be suspended from reaching from an operating system 235 running on the mobile device. For example, the first request may be suspended from the TCP / IP stack of the operating system. The time at which the request is held can be expressed as H ₀ . The first request 505-a-1 may be released to the operating system 235 at time t ₂ .

In one example, the second request 505-a-2 may be sent from the second application at time t ₁ . Time t ₁ may be after time t ₀ . The second request 505-a-2 may also be a Connect () system call. The second request 505-a-2 may be suspended from reaching operating system 235 for the time period represented as H ₁ . For example, the second request may also be suspended from reaching the TCP / IP stack of the operating system. The second request 505-a-2 may be released at time t ₂ . As a result, 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 ₁ may be smaller than the time period H ₀ . In other words, the second request 505-a-2 may be held for a smaller time than the first request 505-a-1.

In one configuration, during the time period H ₀ , the first request may be collected with the second request 505-a-2 when the second request 505-a-2 is intercepted at time t ₁ . The collection of requests causes all of the requests to be released at substantially the same time (ie, time t ₂ ). Thus, timing diagram 500 shows that requests sent at different times t ₀ and t ₁ may be held for different time periods H ₀ and H ₁ and then released at the same time t ₂ . To illustrate.

6 shows an example of a collection architecture that may be implemented on mobile device 105-d. Mobile device 105-d may be an example of device 105 of FIGS. 1, 2, 3, and 4. As illustrated, the device 105-d may include an application layer 220-a, a wrapper 230-b, and an operating system 235. The operating system 235 can include a socket layer 240. The connectivity engine 225 of FIG. 2 or 3 may execute instructions for executing the wrapper 230-b software. In one configuration, the device 105-d may be in background mode. The mobile device 105-d may be connected to the device (eg, when the screen or display of the device 105-d is off, or when the microphone, speaker, or other audio output of the device 105-d is off). If the global positioning system (GPS) mechanism of 105-d determines that the device 105-d is stationary, it may be considered to be in background mode, such as when the battery level of the device falls below a certain threshold level.

In one example, multiple applications 605-a executing in application layer 220-a may transmit a system call 505-a for network access, such as a Connect () system call. System calls 505-a may be sent from each application at different times. The wrapper 230-b may capture these requests and suspend them from reaching the operating system 235. In particular, calls may be suspended from reaching the socket layer 240 of the operating system 235. In one configuration, the collection module 610 may collect intercepted system calls 505-a. The collected calls may be released together (or substantially simultaneously) from the wrapper 230-a-1 to the socket layer 240 of the operating system 235. Upon receiving the collected requests, socket layer 240 may be processed to establish a connection with network 115. The procedure may include sending a signaling message between the network 115 and the mobile device 105-d to establish the control channel 110-a-1.

Thus, intercepting, holding and collecting requests for network access can reduce the power consumption of the mobile device 105-d because multiple system calls are not executed at the socket layer 240 at different times. Because. Instead, multiple requests are bundled together and released to socket layer 240 at about the same time. In addition, the collection of requests can reduce the frequency of connection setup procedures with the network 115 and thus reduce network traffic.

The hold and collection of requests from applications 605-a may be made selectively (ie, implemented so that the user may not be disturbed). Various factors may be used to determine when to hold and collect requests from applications 605-a to establish communication channels. For example, the decision to intercept the request may be made based on certain characteristics of the mobile device 105-d, such as the screen being off, the audio being off, and the like. Pending requests can be applied to applications known to be able to handle these delays if the radio is not loaded and the mobile device 105-d is not otherwise busy (no phone calls, audio streaming, etc.). Can only be implemented. Intercept and withholding of system calls from an application may be implemented based on whether the user subscribes to a service provided by the application. When a user subscribes to a service, requests from the application may not be held from reaching the operating system. Instead, requests from such subscription-based applications can be allowed to pass immediately to the socket layer. In one example, applications running on mobile device 105-d may 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. Non-critical applications may be applications with specific delay tolerances. In other words, system calls from non-critical applications to establish a communication channel can be delayed. However, the critical application may be an application with a small delay tolerance or no delay tolerance. Examples of critical applications may include, but are not limited to, child tracking applications, emergency-based applications, subscription-based applications, and the like. In one configuration, suspension and collection of requests may occur for requests originating from non-critical applications. Requests sent from critical applications are not held (or collected), but instead can proceed directly to the socket layer of the operating system. Retention and collection can also be implemented using a combination of the above factors or other factors.

In addition, various factors can be used to determine when to release collected requests and allow application connectivity. For example, if there is a trigger for establishing a data connection setup procedure (eg, receiving a system call from a critical application, such as an emergency application that cannot be delayed), the pending requests are placed on the socket layer 240. Can be released, and thus communication channels can be established with the emergency application and reduce the number of transitions between the background and connection states. Another example is that collected requests may be released if the more preferred radio is activated or selected as the default (eg, a Wide Local Area Network (WLAN) radio). Requests may also be released if the radio channel is very good (eg, high signal strength, SNR or other desirable performance metrics). The requests may also be released periodically as optionally determined by the mobile device 105-d or as predetermined. Another heuristic for releasing requests may be when the user accesses the device (before he turns on the screen) to operate anonymously. In this example, the accelerometer may detect that the user makes a call, or the user proximity sensor may indicate that the user is approaching. In another aspect, while executing on the batteries, requests can be released as soon as the screen is unlocked (eg, after the PIN is entered correctly). In this aspect, release of requests may not occur if the random button is pressed (the device 105-d is in a wallet or pocket).

In one example, the triggering event that causes the hold request to be released can be the expiration of the timer. The event may also be a state change of the display. For example, the display can change from an "off" state to an "on" state. The state change (from off to on) of the microphone may also be a trigger event. In addition, the state change of the GPS sensor may be a triggering event. For example, the sensor can change states when it detects movement of the mobile device. Additional triggering events for releasing the request may include an indication that the universal serial bus port is busy or an indication that audio equipment is connected to the device. In addition, the indication that the video equipment is connected to the mobile device may also serve as a triggering event to release the hold request to the mobile device's operating system. In addition, an indication that a connection to a particular network is available may trigger the release of the request. For example, a connection indication for a Wi-Fi type network can cause the request to be released. Similarly, an indication that a radio connection to a cellular type network has already been opened may also trigger the release of a request for the operating system of the device. In another aspect, the requests may be released according to some combination of the above or other factors. Although the previous description is for an API architecture, the concepts may be applied uniformly 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 expiration of the timer may indicate the tolerance level of the associated application. For example, a timer that does not receive a tolerance at all can be referred to as a "hard-timer." The hard-timer may be a timer that is intended to expire at a relatively fixed point in time. Conversely, a timer that receives a tolerance value can result in a "soft-timer". The soft-timer may expire at the intended expiration time, but may also allow expiration within a specified tolerance. As one example, certain applications, such as an email update service, may not require connection requests to occur at finite fixed times. Thus, a timer for such an application can be given a wide tolerance, and a soft timer can be created and associated with these applications. Conversely, a stock program used by stock traders may require constant updates at fixed times to ensure the accuracy of stock quotes. Such an application may or may not receive a small tolerance and therefore will be associated with a hard timer.

In one example, a timer, eg, one of a soft-timer or a hard-timer, may expire. Once the expiration time is identified, for example, the connectivity engine of FIG. 2 or 3 may determine whether the expiration time falls within the tolerance of any soft-timer of various applications. For all those soft-timers whose tolerance falls within the expiration time, the connectivity engine may execute instructions to force those timers to expire early. Intercepted network access requests from applications whose timers have expired may be released to the operating system of the mobile device. In some configurations, the network connection may remain open until each of the applications whose timers have expired completes their required communication operations. As communication requests are made when the timers expire, more efficient resource management will result as a result of shared use of applications in the communication system.

As mentioned above, an interval and refresh rate may be determined that indicate how often requests should be released. Intervals can be determined to maintain the state of the middleboxes that perform firewall or NAT functions. The state of the middleboxes may be maintained by applications that issue keep-alive messages or a series of shorter connection requests. In one configuration, the network may provide information regarding the minimum refresh rate to maintain states in the middleboxes on the mobile device. The refresh rate may be provided for UDP to TCP connections. The network may adapt the refresh rate in the middleboxes based on the radio load caused by the amount of keep-alive / reconnect messages. For example, if the number of keep-alive messages exceeds a certain threshold, the state may be maintained for a longer period of time in the middleboxes and the refresh rate for the mobile device may be slow. The interval (or refresh rate) may be less than the timeout value in the stateful middleboxes. As a result, the mobile device can open the gate for the uplink (ie, release requests) according to the refresh rate (or interval) indicated by the network. The gate may open when the device is not in background mode and may be closed when the mobile device is in background mode.

7 is a flow diagram illustrating an example of a method 700 for withholding requests for network access. For clarity, the method 700 is described below with reference to the mobile device 105 shown in FIGS. 1, 2, 3, or 4. In one implementation, processor 360 may execute one or more sets of codes for controlling the functional elements of device 105 to perform the functions described below. In one configuration, the method 700 described below may be executed when the device 105 is in a background mode.

At block 705, a request from an application on mobile device 105 may be intercepted. The request may be a request to perform communication for the mobile device, eg, to establish a communication channel for the mobile device 105. The request can be sent from an application running in 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 cause an application to interfere with an external network, such as network 115. For example, the request may be a system call to the socket layer 240 of the operating system 235 on the mobile device 105.

At block 710, the request may be suspended from reaching an operating system 235 running on the mobile device. For example, the request may be suspended from reaching the socket layer 240 of the operating system 235. In one configuration, wrapper 230 may intercept and hold the request.

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

Thus, the method 700 may provide for intercepting and holding of requests for network access submitted by applications executing in an application layer implementation. It should be noted that the method is just one implementation and that the operations of the method 700 may be rearranged or otherwise modified such that other implementations are possible.

8 is a flow diagram illustrating an example of a method 800 for intercepting requests for network access from non-critical applications running on a mobile device. For clarity, the method 800 is described below with reference to the device 105 shown in FIGS. 1, 2, 3, or 4. In one implementation, processor 360 may execute one or more sets of codes for controlling the functional elements of device 105 to perform the functions described below.

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

At block 810, a determination may be made whether the device 105 is in a background mode. For example, a determination may be made whether the device 105 is powered down, in sleep mode, or the like. The device 105 may also be determined to be in the background mode, for example when the display of the device 105 is inactive, audio outputs are inactive, and so on. If it is determined that the 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 may be emergency applications with network access, subscription-based applications, applications with low tolerance to delay, and the like.

If the device 105 is active or it is determined that 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 cause the socket layer to initiate procedures for establishing a communication channel with the network 115. If the device is in background mode and it is determined that the application is classified as a non-critical application, then at block 820, the request is suspended from reaching the operating system, thus delaying initiation of procedures for setting up a communication channel. You can.

At block 825, the request can be collected 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 as to whether a triggering event is detected, as described above. If it is determined that the triggering event is not detected, the method 800 may return to continue collecting intercepted requests for network access. However, if it is determined that a triggering event has been detected, at block 835, the collected requests may be released to the socket layer 240 of the operating system 240. In other words, system calls from multiple applications may be held and bundled together and then released as a single system call to socket layer 240.

Thus, the method 800 can provide for intercepting, withholding, and collecting requests for network access from non-critical applications running on the mobile device 105. By holding back and collecting requests, multiple system calls can be bundled together and released as a single system call. This may result in a reduction in network signaling as well as battery power savings for the mobile device 105 because the amount of system calls to initiate procedures for setting up communication channels may be reduced. It should be noted that the method 800 is just one implementation and that the operations of the method 800 may be rearranged or otherwise modified such that other implementations are possible.

9 is a flow diagram illustrating one configuration of a method for intercepting requests for network access from multiple applications running on a mobile device. For clarity, the method 900 is described below with reference to the device 105 shown in FIGS. 1, 2, 3, or 4. In one implementation, processor 360 may execute one or more sets of codes to control the functional elements of device 105 to perform the functions described below.

At block 905, the first request for network access is intercepted from the first application at a first time. In one example, at block 910, the second request may be intercepted from the second application at a second time. The second time may be different from the first time. At block 915, the third request may be intercepted from the third application at the third time. In one configuration, the third time may be different from the first time and the second time. Intercepted requests may be system calls for establishing communication channels for network access. The applications may run on the mobile device 105.

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

In one configuration, at block 940, the first, second and third requests may be collected or bundled together. At block 945, a determination may be made whether a triggering event has occurred. For example, a determination can be made 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 collected requests may be released to the socket layer of the operating system. Upon receipt of the requests, the socket layer may initiate procedures for establishing a communication channel with an external network, such as network 115.

Thus, the method 900 may provide for intercepting, holding, and collecting requests for network access from multiple applications running on the mobile device 105. As a result, multiple system calls can be bundled together and released as a single system call. This may result in reduced battery signaling as well as reduced battery signaling for the mobile device 105 because the amount of system calls may be reduced. It should be noted that the method 900 is just one implementation and that the operations of the method 900 may be rearranged or otherwise modified such that other implementations are possible.

10 shows one possible process 1000 implemented in certain embodiments to improve synchronization between application connection requests, such as network access requests. Certain embodiments as discussed in the example below may implement process 1000 on a mobile device. For clarity, the method 1000 is described below with reference to the device 105 shown in FIGS. 1, 2, 3, or 4. In one implementation, processor 360 or connectivity engine 225 of FIG. 2 or 3 may execute one or more sets of codes to control functional elements of device 105 to perform the functions described below. .

The method begins by identifying at block 1005 that a first timer, eg, one of a soft-timer or a hard-timer, may expire. This can be accomplished by a central system that polls timers of various applications. Alternatively, each application can individually monitor its own timer and provide a notification upon timer expiration.

Once the expiration time is identified, a determination may be made at block 1010 as to whether additional timers that may also expire may be identified. For example, a determination can be made whether the expiration time of the first timer falls within the tolerance of any soft-timer. For all soft-timers whose tolerance falls within the expiration time, at block 1015, additional timers may be forced to expire early. At block 1020, data may be synchronized for applications associated with expired timers. For example, channel access may be provided to applications whose timers have expired by establishing a connection. In some embodiments, the connection may remain open until each of the applications whose timers have expired completes their required communication operations. As communication requests are made when the timer expires, more efficient resource management will result as a result of shared usage of applications in the communication system. The method 1000 may be performed indefinitely by waiting again for the timers to expire at block 1005, or the method may end.

The timer or timers that initially expired at block 1005 at the intended time may be referred to as “master timers” or interchangeably “trigger events” in certain embodiments. That is, these timers indicate when other timers can expire based on individual tolerances. Thus, a soft or hard-timer can serve as a master timer. However, only soft-timers can be affected by the master timer (as only soft-timers have a tolerance).

11 illustrates one possible series of connection requests for each of three applications (App1, App2 and App3). These applications may run on a mobile device, eg, the mobile device of FIGS. 1, 2, 3 or 4. In particular, FIG. 11 illustrates techniques for establishing connections based on communication requests from various applications. In this example, connection requests are not coordinated. Thus, each application requests a connection at uncoordinated intervals from other applications. This lack of coordination leads to inefficient use of resources of the mobile device as applications ignore opportunities for sharing connections. Timer expirations are represented by vertical arrows at each point in time, and the resulting request periods are represented by squares. Each connection period is represented by a window in the request period rectangle that is 30 seconds wide (this will be perceived as somewhat arbitrary duration, and much smaller or longer durations may occur for each connection). This width is for illustrative purposes only, and any widths may exist in the actual device. The numerical ranges in FIG. 11 as well as the subsequent figures have been chosen for illustrative purposes only. The drawings should not necessarily be construed as indicating an actual implementation of any system or embodiment.

In FIG. 11, App1 may initiate a communication request every 5 minutes (connections at times 1, 6, 11, 16, etc.). Similarly, App2 may initiate connection requests every 5 minutes, but is offset from App1 by 1 minute. In other words, App2's requests share the same time period as App1's requests but do not share the same phase. Finally, App3 can make connections every 10 minutes, likewise offset from App1 by 4 minutes. Asynchronous connection requests of App1, App2, and App3 result in inefficient use of battery power and communication bandwidth as connections are constantly rising and falling. In this example, 14 separate connections (requires reactivation of communication elements of the mobile device) with the communication system occur between time 6 and time 32.

Some of the embodiments of the present invention contemplate providing a system that can coordinate connection requests such that more efficient connection patterns occur. For example, if the mobile device 105 already has a connection to the network for one application, the mobile device 105 does not disconnect and form another connection, and establishes the same connection to another application. Can be used. Thus, adjusting the timing between application connection requests so that applications share connections can reduce the number of connections that need to be formed. Some of these embodiments may include a programming module that application developers can use in executing applications for a platform running on mobile device 105. In some of these embodiments, mobile device 105 may transmit information for scheduling to the network. In many embodiments, applications running on mobile device 105 may include software, firmware, or hardware modules configured to determine when “timers”, ie, when a particular “expiration time” occurs. The timers may be executed by the connectivity engine 225 of FIG. 2 or 3. The timers may be implemented as part of the connectivity engine 225. These timers indicate the time or time interval that an application can request a connection. Applications that request periodic updates from the network (or periodically send information to the network) may rely on these timers to determine when they should request a connection. Applications can also request data aperiodically and can request data within a specific time defined by a timer. Some applications can be flexible in how often they require a connection. Some of the embodiments of the present invention take into account different types or configurations of timers to accommodate the flexibility, or lack of flexibility, associated with each application. Although the following description refers to an application as having a "timer" for ease of discussion, those skilled in the art will recognize that the application may itself include a number of components that can be individually associated with one or more timers. will be.

FIG. 12 shows a timing diagram for the applications from FIG. 11, where the applications now use soft or hard-timers with a process such as the method of FIG. 10. As discussed above, applications may run on a mobile device, eg, mobile device 105 of FIGS. 1, 2, 3, or 4. In addition, the connectivity engine 225 of FIG. 2 or 3 may implement a process 1000 for coordinating scheduling. In the example of FIG. 12, each of the applications (App1, App2, and App3) includes a soft-timer with a tolerance of two minutes. In the absence of a process, such as process 1000, timer expirations are indicated by dashed arrows, as they would have occurred in FIG. 11. Solid arrows indicate timer expirations that occur under management of a process, such as process 1000. In some embodiments, process 1000 may be performed at each time interval (ie, at 1, 2, 3 minutes, etc.).

For example, at time 7, the soft-timer of App2 would have expired normally. However, as App1's timer expired at time 6, which is within the two minute tolerance of App2's soft-timer, App2's soft timer expired early at time 6. Similarly, the expiration of the clock of App3 at time 14 falls within two minute tolerances of the clocks for both App1 and App2. By time 19, the clocks are exactly in phase (communication) because each of the clocks for App1, App2, and App3 have the same or mutually harmonic periods (5 minutes, 5 minutes, and 10 minutes, respectively). Requests occur subsequently at times 19, 24 and 29 with master clocks having no effect on other applications), resulting in a much more efficient use of communication resources. In general, if the timers share the same periods, or if their periods are harmonics (ie, multiples) of each other, they suppress interference from the expiration of other "master" timers, permanently in phase with each other. (Of course, synchronization may also be interrupted if the periodicity of any of the applications' timers is changed). Thus, this example illustrates that six, rather than four, connection requests occur between three and 33 minutes compared to the timing diagram of FIG. 11 when no process is applied.

As another example, FIG. 13 shows another situation where applications (App1, App2 and App3) do not own the same periods (8 minutes, 5 minutes and 10 minutes, respectively). As in the timing diagram of FIG. 11, the connection requests of FIG. 13 reflect a conventional uncoordinated technique used in most applications. This lack of coordination results in an inefficient use of the resources of the mobile device, resulting in reactivation of the communication resources of the 12 mobile devices between 7 and 34 minutes.

The applications of FIG. 13 differ from FIG. 11 in that App 1 of FIG. 13 is time sensitive. Developers or system designers wishing to use some of the advantages of embodiments of the present invention are likely to create a timer with little or no tolerance for App1 in FIG. 13. Thus, a hard-timer can be used for App1. On the other hand, App2 and App3 in FIG. 13 are not time sensitive and can therefore be accommodated by soft-timers. In Fig. 13, App2 and App3 are each given soft-timers with a tolerance of two minutes.

FIG. 14 shows the effects of applying a process such as process 1000, but this time to the applications of FIG. 13. The timer of App1 of FIG. 14 remains the same as App1 of FIG. 13 in the timing diagram of FIG. 13 as it is a hard-timer. However, App3 of FIG. 14 expires based on the expiration of the App2's timer at time 12 since App2's expiration is within 2 minutes of App3's intended expiration time. Subsequently, App2 synchronizes with App1 at time 25 and App3 synchronizes with App2 at time 30. As discussed above, the applications may run on the mobile device 105 of FIG. 1, 2, 3, or 4. In addition, the mobile device 105 can implement a process 1000 for coordinating scheduling. This example illustrates how a previous synchronization of one clock (app 2 at time 25 based on app 1) can affect subsequent synchronization of another clock (app 3 at time 30 based on app 2). do. As the periods of the application clocks are the same or not harmonics, the clocks may not be permanently correctly synchronized. Still, this example illustrates that eight, rather than twelve, connection requests occur between 6 minutes and 33 minutes when no process such as process 1000 is applied.

Master clocks can be prioritized based on the application with which they are associated. In other words, applications that consume very much bandwidth or battery power may be less suitable for sharing resources than applications that consume less bandwidth or battery power. Thus, in certain embodiments, mobile device 105 may operate with a corresponding master and / or corresponding priority of expired “master” timers before process 1000 may prematurely expire soft-timers with tolerances within an appropriate range. It may be adjusted to consider the ranking. As an example, the process may include a bandwidth for each application for which the timers expired (ie, master timers) at block 1005, compared to the bandwidth requirements of the applications where the tolerance allows for early expiration of their timers. Additional requirements may be considered. If the cumulative bandwidth requirements of applications with master timers are relaxed for shared use of the channel with other applications, the mobile device 105 can take appropriate action. For example, a connection request may be made in applications with master timers that are allowed to perform their operations. Soft-timers are then used to ensure that these applications use existing connections when the master timer applications no longer consume excessive bandwidth (after the intended expiration time possible if allowed by its tolerance). Can be made to expire. Alternatively, the expiration of soft-timers may be delayed until the end of their tolerance or until a new connection request is made to use less bandwidth.

For example, in some of the foregoing embodiments discussed with reference to FIGS. 11 and 13, timer expiration is shown as occurring at the leading edge of communication windows. Certain embodiments instead consider performing an analysis at the "trailing edge" of the data connection, i.e., when communication with the node is almost idle. As the costs relate to both opening and closing the connection, the mobile device 105 does not initiate a new request when the current connection is closed, but rather establishes a connection to know whether any applications are trying to open the connection. A process similar to process 1000 can be executed before closing, and an existing connection can be used instead.

Using the techniques and structures disclosed herein, a mobile device provides a software layer (for illustrative purposes, providing an application program interface (API)) for capturing system calls from applications and withholding them from reaching the operating system. Named wrappers). Captured calls can be collected, so that frequent waking of the device can be reduced, and other communication resources are preserved for periods of time in which the user is actively associated with the mobile device.

Those skilled in the art will appreciate 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 skilled in the art will 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 thereof. 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 on 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 present invention.

The various illustrative logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programs. It may be implemented or performed with possible logic devices, 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 conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, eg, a combination of a DSP and a microprocessor, multiple 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 implemented directly in hardware, in a software module executed by a processor, or 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 disks, removable disks, CD-ROMs. Or 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. Alternatively, the storage medium may be integrated into 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 illustrative 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 non-transitory 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. The storage medium may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media may be desired program code in the form of RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or instructions or data structures. And any other medium that can be used to deliver or store the information and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using wireless technologies such as coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or infrared, radio, and microwave, Coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio and microwave are included within the definition of the medium. Disks and discs, as used herein, include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where the disks generally magnetically store data. In contrast, discs optically reproduce data using 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 present invention. Various modifications to these exemplary embodiments will be 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. Thus, the present invention is not intended to be limited to the example 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 in a mobile device,
Intercepting a request from a first application on the mobile device, the request being a request to perform communication for the mobile device;
Withholding the request from reaching a Transmission Control Protocol / Internet Protocol (TCP / IP) stack of an operating system running on the mobile device; And
Releasing the request to an operating system upon detecting a triggering event. The method of claim 1,
The hold occurs during a period of time that the mobile device is in a background mode. The method of claim 1,
Collecting the request along with other intercepted requests to perform communication for the mobile device. The method of claim 3,
Intercepting the request from the application and intercepting other requests occur at different times. The method of claim 1,
Executing instructions for a wrapper, wherein the executed wrapper performs intercepting of the request from the first application. The method of claim 5,
And the wrapper is located between an application layer and a socket layer of an operating system of the mobile device. The method of claim 1,
Identifying the first application as a class of application for which requests are withheld. The method of claim 7, wherein
Identifying the application as a critical application or a non-critical application; And
Suspending only requests from non-critical applications. The method of claim 1,
The triggering event may expire the timer, change the state of the display, change the state of the microphone, change the state of the speaker, change the state of the Global Positioning System (GPS) sensor of the mobile device, indicate that the universal serial bus port is in use, the audio device is mobile At least one of an indication that the device is connected, an indication that the video equipment is connected to the mobile device, an indication that a connection to a Wi-Fi type network is available, or an indication that a radio connection to a cellular type network is opened. , A method for wireless communication in a mobile device. The method of claim 1,
Determining a delay tolerance of the first application; And
Providing a callback function to the first application based on the determined delay tolerance, wherein the callback function instructs the first application to access the communication resources. Way. The method of claim 1,
Determining an expiration time of a first timer associated with the first application;
Determining a tolerance and an expiration time of a second timer associated with the second application;
Causing the second timer to expire based on the expiration time of the first timer, the tolerance, and the expiration time of the second timer; And
Releasing a request from the first application and an intercepted request from the second application to perform communication for the mobile device. The method of claim 1,
Receiving a deadline from the application;
Withholding said request until said deadline; And
Releasing a request to access the communication resources prior to the deadline. The method of claim 1,
The request includes a system call to establish a communication channel for the mobile device. The method of claim 1,
Releasing the request to the socket layer of the operating system upon detecting the triggering event. The method of claim 1,
Receiving an indication of an interval as to how often the release of the request occurs. 16. The method of claim 15,
Wherein the interval is less than a timeout value in a stateful Internet Protocol (IP) middlebox in a 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 includes a connectivity engine, the engine comprising:
Intercept a request from a first application on the mobile device, the request being a request to perform communication for the mobile device;
Suspend the request from reaching a TCP / IP stack of an operating system running on the mobile device; And
And execute instructions for releasing the request to the operating system upon detecting a triggering event. 18. The method of claim 17,
And the hold occurs during a period when the mobile device is in a background mode. 18. The method of claim 17,
And collecting the request along with other intercepted requests to perform communication for the mobile device. 20. The method of claim 19,
And intercepting the request from the first application and intercepting other requests occur at different times. 18. The method of claim 17,
The memory further includes a wrapper, the upper connectivity engine is further configured to execute instructions on the wrapper, and wherein the wrapper is further configured to intercept the request from the application when the instructions are executed. Mobile device configured for. The method of claim 21,
And the wrapper is located between an application layer and a socket layer of an operating system of the mobile device. 18. The method of claim 17,
The connectivity engine is:
And execute instructions for identifying the first application as a class of application for which requests are withheld. 24. The method of claim 23,
The connectivity engine is:
Identify the application as a critical application or a non-critical application; And
A mobile device configured for wireless communication, further configured to execute instructions for holding only requests from non-critical applications. 18. The method of claim 17,
The triggering event may expire the timer, change the state of the display, change the state of the microphone, change the state of the speaker, change the state of the Global Positioning System (GPS) sensor of the mobile device, indicate that the universal serial bus port is in use, the audio device is mobile At least one of an indication that the device is connected, an indication that the video equipment is connected to the mobile device, an indication that a connection to a Wi-Fi type network is available, or an indication that a radio connection to a cellular type network is opened. , A mobile device configured for wireless communication. 18. The method of claim 17,
The connectivity engine is:
Determine a delay tolerance of the first application; And
Further execute instructions for providing a callback function to the first application based on the determined delay tolerance, wherein the callback function instructs the first application to access the communication resources. Mobile device configured for. 18. The method of claim 17,
The connectivity engine is:
Determine an expiration time of a first timer associated with the first application;
Determine a tolerance and an expiration time of a second timer associated with a second application;
Cause the second timer to expire based on the expiration time of the first timer, the tolerance, and the expiration time of the second timer; And
And execute instructions for releasing a request from the first application and an intercepted request from the second application to perform communication for the mobile device. 18. The method of claim 17,
The connectivity engine is:
Receive a deadline from the application;
Withhold the request until the deadline; And
And configured to execute instructions for releasing a request to access the communication resources prior to the deadline. 18. The method of claim 17,
And the request comprises a system call to establish a communication channel. 18. The method of claim 17,
And the connectivity engine is further configured to execute instructions for releasing the request to a socket layer of the operating system upon detecting the triggering event. 18. The method of claim 17,
And the connectivity engine is further configured to execute instructions to receive an indication of an interval as to how often a release of the request occurs. 32. The method of claim 31,
And the interval is less than a timeout value in a stateful internet protocol (IP) middlebox in a network. An apparatus configured to manage requests for a network from applications on a mobile device, the apparatus comprising:
Means for intercepting a request from a first application on the mobile device, the request being a request to perform communication for the mobile device;
Means for withholding the request from reaching a TCP / IP stack of an operating system running on the mobile device; And
Means for releasing the request to an operating system upon detecting a triggering event. 34. The method of claim 33,
The hold is configured to manage requests for a network that occur during a period when the mobile device is in a background mode. 34. The method of claim 33,
And means for collecting the request along with other intercepted requests to perform communication for the mobile device. 34. The method of claim 33,
Intercepting the request from the application and intercepting other requests are configured to manage requests for the network at different times. 34. The method of claim 33,
Means for executing instructions for a wrapper, wherein the executed wrapper is configured to intercept the request from the first application. 39. The method of claim 37,
And the wrapper is configured to manage requests for a network located between an application layer and a socket layer of an operating system of the mobile device. 34. The method of claim 33,
And means for identifying the first application as a class of application for which requests are withheld. 40. The method of claim 39,
Means for identifying the application as a critical application or a non-critical application; And
And means for withholding only requests from non-critical applications. A computer program product configured to manage requests for network access from applications on a mobile device, the article comprising a non-transitory computer-readable medium, the medium comprising:
Code for intercepting a request from a first application on the mobile device, the request being a request to perform communication for the mobile device;
Code for withholding the request from reaching a TCP / IP stack of an operating system running on the mobile device; And
And code for releasing said request to an operating system upon detecting a triggering event.

Images