Patent Application
20070088830
1. Technical Field
The present inventions relate to communication over an air interface and, more particularly, relate to selective communication of a mobile application over an air interface.
2. Description of the Related Art
CDMA wireless data networks have a concept of dormancy. When a mobile device is not actively using an RF traffic channel, the traffic channel is taken away by the base station or base station controller and preferably assigned to a mobile that has data to send or receive. When a mobile is registered on the network but not allocated a traffic channel, the mobile is said to be dormant.
Dormancy is an important concept in CDMA, because traffic channels are the most valuable resource in the network. The temporal multiplexing of traffic channels suits the needs of bursty data applications, as it gives the bandwidth to mobiles that need it and does not allocate bandwidth to idle mobiles. CDMA operators try to conserve traffic channels as much as possible.
A problem arises when a CDMA data transceiver is put into the form factor of a PCMCIA card. When plugged into a laptop, the card becomes just like any other network interface. Certain applications periodically or regularly request communications with associated servers on the network. These applications do not necessarily know whether they are using CDMA RF rather than 802.11 or Ethernet.
An object of the present inventions is to allow applications to communicate more effectively over wireless channels.
A further object of the present inventions is to delay periodic and/or regular communications requests with associated servers on a wireless network.
Another further object of the present inventions is to keep a radio communications channel open for periodic and/or regular communications requests with associated servers on the network when of critical importance.
A further additional object of the present inventions is to delay periodic and/or regular communications requests with associated servers on a wireless network when not of critical importance.
Another object of the present inventions is for applications to have the opportunity to “piggyback” on a wireless channel that has already become active for some other application to use.
An additional object of the present inventions is to enable concurrent sessions to efficiently utilize the air interface when available.
A further additional object of the present inventions is to enable concurrent sessions to efficiently utilize the air interface when available by enabling some and not other sessions, so that the air interface to the user appears available always.
Applications on a mobile radio device selectively communicate over a wireless network based on a dormancy of the air interface. Middleware is provided between the applications and drivers of the mobile radio device for facilitating communication sessions based on the dormancy status of the air interface. The middleware effects selective communication sessions, in one embodiment, by informing applications of the state of the air interface and, in another embodiment, to allow and disallow one or more communication sessions.
These and other objects and features of the inventions will be more readily understood from the following detailed description when read in conjunction with the accompanying drawings wherein:
A wireless radio such a CDMA cellular module presents status information to applications so that applications can make intelligent decisions on whether or not to communicate. In doing so, wireless RF resources are conserved because each mobile device's communications are “batched” to take advantage of the traffic channel when it is available, and to conserve bandwidth when it is not.
Typically these applications demand access to the wide area network when needed. Because the wired connection, such as 10/100/1000 ethernet, or a wireless LAN such as 802.11, is nearly constantly available, conventional Internet applications expect the network to be there when communication is needed. On a mobile wireless network, however, constant access of the wireless network is impractical for many reasons. One reason is the scarcity of the mobile wireless bandwidth. Another reason is the overhead of setting up a session over the air interface. A further reason is the character of a mobile link which is subject to blank-outs due to fades or handoffs between cells. The present inventions provide middleware between these applications and the drivers of the mobile device for selective communication of these applications based on a dormancy status of the air interface.
The present inventions tend to be applicable to a class of applications that may have some the following characteristics:
1. They periodically or on user request communicate with a remote server;
2. They can be configured to periodically communicate with the remote server;
3. They can be instructed to immediately communicate with the remote server by the user;
4. Some portion of the communications result in minimal or no state change on the client application (in other words, the communication did not contain new and/or useful information); and
5. They do not need to present information to the user in strict “real time” (in other words, if the application does not communicate with the server every so often, then the user's experience is not seriously degraded).
These applications can be modified to take advantage of knowledge of the dormancy status of the wireless mobile network.
Example applications that fall into this category are described below. Note that this is not an exhaustive list of applications.
The middleware is a piece of logic that performs a function between and the applications and drivers. The location of the middleware in the software stack depends on the choice of operating system.
Middleware 335 is provided between and the application 310 and the driver 340. The middleware 335 is a piece of logic that performs a function between the applications and drivers. The middleware 335 facilitates selective communication of the mobile applications based on air interface dormancy.
The location of the middleware in the software stack depends on the choice of operating system. The operating system used in the example illustrated in
In this first embodiment, according to a first approach, the application 310 requests of the middleware 335 the air interface dormancy status indication at 363. The middleware 335 requests of the driver 340 the air interface dormancy status at 364. The driver 340 then reports the dormancy status of the radio unit to the middleware 335 at 365. The middleware 335 reports the dormancy status to the application 310 at 367. The application 310 then knows when to best communicate over the air interface of the radio unit 350 based on its dormancy status.
In this first embodiment, according to a second approach, the radio unit 350 of the hardware continually reports its dormancy status at 361 to the driver 340. The driver 340 continually reports the dormancy status of the radio unit to the middleware 335 at 362. The middleware continually reports the dormancy status to the application 310. Reporting may occur via an API 320. Reporting also may occur using interrupts or not. By using the middleware to facilitate reporting of the dormancy status to the application 310, the application 310 already knows when to best communicate over the air interface of the radio unit 350 based on its dormancy status.
According to a second approach of the first embodiment, the application 410 has data to send at step 421. The application 410 has been continually monitoring the dormancy status of the air interface via the middleware 425 and driver 430 at step 451. When to the dormancy status is active, the application 410 sends the data to radio hardware 480 at step 471. When the dormancy status is inactive, the application 410 can queue or drop the data.
The basic strategy that we take is as follows. Software or firmware (for example, a driver) associated with the CDMA wireless interface presents a mechanism with which the application can discover the dormancy status of the CDMA air interface. This mechanism preferably has two parts:
Client operation would be as follows. If the driver is in polling mode and the application has non-critical real-time data to send, the application would first poll the driver. If the CDMA air interface is active, the application would proceed to send the data. If the CDMA air interface is dormant, the application would defer sending the data for a period of time.
Similarly, if the driver is in indication mode and the application has non-critical real-time data to send, the application will examine the most recent indication from the driver. If this indication is that the air interface is active, the application would proceed to send the data. If the indication is that the air interface is dormant, the application would defer sending the data for a period of time.
Also if the driver is in indication mode, applications may defer or queue communications when the air interface is dormant. When the air interface becomes active, the driver will notify all registered applications. These applications then have the opportunity to “piggyback” their on an air interface that has already become active for some other application to use. For example, if a user starts a web browsing session, an RSS client that has previously been deferred may decide to update its feeds at that point.
In the first embodiment, the application knew when best to communicate over the air interface based on the dormancy status, with help of the middleware. Nevertheless, not all applications are capable of knowing when best to communicate. For example, conventional applications, such as e-mail, instant messaging and web browsers are designed for conventional portable computers such as laptops. They communicate over a network regardless of its dormancy status of the network. This is because conventional applications have been designed for communication over a continuously available, wired network.
In a second embodiment (according to
Middleware 535 is provided between and the application 310 and the driver 540. The middleware 535 is a piece of logic that performs a function between the applications and drivers. The middleware 535 allows for selective communication of the mobile applications based on air interface dormancy.
The location of the middleware in the software stack depends on the choice of operating system. The operating system used in the example illustrated in
In the second embodiment, according to a first approach, the middleware 535 requests of the driver 540 the air interface dormancy status indication at 563. The driver 540 then reports the dormancy status to the middleware at 565. The middleware then permits communication by the application over the air interface of the radio.
In the second embodiment, according to a second approach, the radio unit 550 of the hardware continually reports its dormancy status at 561 to its driver 540. Its driver 540 continually reports its dormancy status at 562 to the middleware 535. Reporting also may occur using interrupts or not. When an application 510 attempts a communication over the air interface of the radio unit 550, the middleware then knows the status of the air interface and can allow or deny the communication.
A decision whether or not to communicate based on the dormancy status of the air interface can be made more intelligently based on priority factors and the kind of application according to further implementations of the first and second embodiments of the present inventions. In the first embodiment, the application learns its priority and monitors a predetermined amount to decide when to use the air interface. The middleware can facilitate the application learning this status. In the second embodiment, the middleware knows the priority of each application and monitors a predetermined amount to decide when to allow use of the air interface.
There would be some instances in which the mechanism could be overridden. If the application or middleware decides that the communication does not fall into the class of “non-critical real-time” data, the application may transmit the data without first checking the dormancy status of the air interface. Also, if the communication is requested by a user, such as the user manually refreshing their POP3 client or an RSS feed, then the communication should occur regardless of the dormancy status of the CDMA interface.
In the second embodiment the middleware may know the priority of each application. One way the middleware can know the priority of each application by examining the communication packets within a communication request. Another way the middleware can know the priority of each application by recognizing the name and/or type of application requesting communication. The name or type is recognized by the middleware by comparing incoming packets in a communication attempt against a list of known names and types of the application requesting communication. This list might be occasionally updated to include new kinds of applications.
The data communication can be disabled by deferring sending data for a predetermined amount. After the predetermined amount, sending the data and thereby forcing the air interface active. The predetermined amount is shorter for higher priority applications. The predetermined amount is a predetermined period of time in one implementation. The predetermined amount is a predetermined number of retries in another implementation.
The application itself may on occasion decide to override the dormancy status as well. One of the reasons that an application may do this is that it has been deferred a certain number of times or for a certain period of time. For example, a weather application that presents the local temperature to the user may be programmed to check the current temperature at a remote server every 15 minutes. However if the CDMA air interface has been dormant last n times (e.g., 4 times) it has tried to communicate with the server, or due to dormancy it has been unable to communicate with the server for n minutes (e.g., 60 minutes), it may decide to initiate the communication, thus activating the air interface. In these scenarios, the application has determined that updating its status is more important than conserving bandwidth. Note that when an application is first launch or when a CDMA network interface first becomes available after no network interface has been available for a period of time, the application should not defer its communications with the server.
The updates discussed here are “non-critical real-time” communications. In other words, if the updates are missed or deferred, the user experience is not deleteriously impacted. The goal of this work is to allow the application to decide whether or not to send updates of this type when the wireless air interface is dormant. Critical “real-time” updates, such as web page requests, FTP transfers or voice over IP calls would be not be subject to deferral.
According to a second approach of the second embodiment, the application 610 has data to send at step 621, and the application 610 attempts to send the data at 690. The middleware 630 has been continually monitoring the dormancy status of the air interface at step 651. And the radio unit 685 reported the status of the air interface to the driver 680 at 652. When to the dormancy status is active, the middleware 630 sends the data to the radio unit 680 at step 671. When the dormancy status is inactive, the middleware 630 can queue or drop the data.
Wireless networks currently suffer from “chatty” mobile applications. A wireless client interface can present some indication of network status to applications. The applications may then use this indication to decide whether or not to transmit data over the wireless network.
Although the inventions have been described and illustrated in the above description and drawings, it is understood that this description is by example only, and that numerous changes and modifications can be made by those skilled in the art without departing from the true spirit and scope of the inventions. Although the examples in the drawings depict only example constructions and embodiments, alternate embodiments are available given the teachings of the present patent disclosure. For example, although wireless examples are disclosed, the inventions are applicable to other bandwidth sensitive or intermittently available communication mediums.
