Patent Application
20100287273
The present invention is related generally to network communications and, more particularly, to communicating efficiently in a heterogeneous network environment.
For many wireless devices, the network communications environment changes constantly, often minute-by-minute. Even for a stationary wireless device, signal strengths grow stronger and weaker, so new communications links become possible while other links become too weak and are dropped. When the device is mobile, this effect is even more strongly pronounced, of course. For a wireless device that supports multiple communications technologies, the availability of links supporting these various technologies can vary over time independently of one another.
When more than one communications link is available to a wireless device, the available links may vary in the capabilities they provide. For example, different links provide greater or lesser amounts of bandwidth or support different qualities of service. Also, different communications technologies may require differing amounts of battery power and may be associated with different billing structures.
Even when multiple communications links are simultaneously available to the wireless device, applications running on the device might be designed to work with only one, or with a small set, of possible communications technologies. (These limits may be imposed so that an application need only work with those links that can provide the quality of service needed by the application.) Thus an application may become “stranded” when its preferred link goes down even though other links are still available.
The above considerations, and others, are addressed by the present invention, which can be understood by referring to the specification, drawings, and claims. According to aspects of the present invention, a communications device monitors the status of its communications links. When more than one communications link is available, an “appropriate” link is selected for use by an application running on the device. The links are continually monitored, and, as circumstances change, the link selection can also change. In some embodiments, the application need not be aware of the particular link it is using or when it is reconnected to a different link. In some embodiments, link-selection and status information is provided to the applications.
In some embodiments, a link is “appropriate” when it is available to transfer data and when it satisfies certain “hard” rules set by the application or by a user of the communications device. For example, hard rules can state a minimum bandwidth needed by an application, or a maximum acceptable latency, or a maximum cost-per-minute of connectivity. A hard rule may exclude as inappropriate a link using a certain technology if the level of battery charge in the device is below a certain level. Some embodiments monitor the behaviour of the communications device and of its user and capture that behaviour in “soft” rules that are applied when selecting an appropriate link and when the hard rules leave the choice open.
An application may be simultaneously connected to multiple links as circumstances permit. When multiple applications are running simultaneously on the device, they may share links or may use different links as circumstances and application requirements allow. When multiple links choose to transmit on the same frequency, they may be supported “virtually simultaneously” by time-slicing the actual data transmissions. If more links are available than are needed to support current requirements, extra links may be shut down to save battery power.
Different architectural implementations are contemplated. In some embodiments, the methods of the present invention are implemented, at least in part, by an “intelligent connectivity engine” that logically resides between the applications and the MAC (media-access control) layer logic running the various communications links.
While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
a and 2b together form a flowchart of an exemplary method for directing communications within a heterogeneous network environment;
a and 3b are schematics of an exemplary personal communications device usable with the present invention; and
Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable environment. The following description is based on embodiments of the invention and should not be taken as limiting the invention with regard to alternative embodiments that are not explicitly described herein.
In
Note that the present invention is not limited to devices such as the personal communications device 104 as illustrated in
Different network links can have different characteristics including strength of signal, bandwidth available, cost to use, and amount of power required from the personal communications device 104. While many network links support two-way communications, in this discussion a “network link” could also be a one-way service such as GPS broadcast signals received by the personal communications device 104.
Different network links also differ in how well they support user applications running on the personal communications device 104. For example, a voice-calling application requires only moderate bandwidth, but it does require low and reasonably consistent latency. A video application, on the other hand, may require much greater bandwidth but, with adequate buffering on the personal communications device 104, may be relatively insensitive to variations in latency. These and other network-link requirements of the applications are generally called “Quality of Service” (or “QoS”) requirements. Network links differ in the QoS requirements that they support. Also, as conditions in the heterogeneous networking environment 100 change, the ability of a given network link to support QoS requirements may change. Applications often codify their QoS requirements in a number of “hard” rules. If a network link cannot satisfy the hard rules of an application, then the application will not use that link. Of course, if no network link is available that satisfies the hard rules of the application, then that application must either quit or be suspended. The user 102 of the personal communications device 104 can also create hard rules that embody his preferences for the use of network links.
a and 2b present a method, according to aspects of the present invention, for managing communications within a heterogeneous networking environment, such as environment 100 of
In step 202, a network link is selected for use with an application. In general, the requirements of the application are compared against the capabilities of the network links currently available to handle traffic, and a suitable link is chosen. The “hard” rules mentioned above in reference to
The selected network link is “plumbed” into the application in step 204. Note that in some situations, the plumbing is “one-way,” as when the selected link carries GPS signals to a location-mapping application. The location-mapping application does not send any traffic back to the GPS satellites, so the link is strictly one-way. Other sensors work in this same way.
In some embodiments, steps 200 through 204 are kept out of sight of the application. That is, the application knows whether or not it connected to a working link that satisfies its QoS requirements (if any), but the application does not need to know anything more about the link it is using. In other embodiments, the application is given the status of the link it is using in step 206. It is also possible to give the status of other links so that the application can decide on its own to select another link.
In some embodiments, traffic for an application may be supported simultaneously on multiple links, possibly without the knowledge of the application itself. Step 208 allows for this possibility by plumbing a second link to the application. The second link can be chosen using the same criteria as in step 202.
In a more common circumstance, steps 208 and 210 are used together to hand off the application's traffic from one link to another. The handoff can be motivated by, say, a reduction in signal strength of the first link, which may indicate that the first link will shortly become unavailable. In another situation, a better information provider may become available. For example, the user 102 when driving may run a location application where his personal communications device 104 receives location information over Bluetooth from a GPS receiver in the car. When the user 102 enters a shopping mall, the device 104 may begin to receive location information from a Wi-Fi or ZigBee network. In general, a second link can be selected (step 202) and plumbed in (step 204) before the first link is dropped in step 210. Especially when the device 104 is mobile, it is expected that steps 200 through 210 will be applied repeatedly to support traffic for the application as the situation, specifically the availability of links, constantly changes. As discussed for step 206, these changes in the links used to support an application may occur with or without informing the application.
Step 212 of
It usually takes some resources, specifically some battery power, to support a link even when the link is not being used. In step 214, an unused link can be shut down to save power. This step may interact with the above steps when the amount of remaining power becomes a matter of concern. When it is necessary to conserve power, links may be selected (step 202) based on their power requirements, even when otherwise more desirable links (e.g., links of higher bandwidth or lower latency) are available. Traffic for the applications can be handed off to these lower-power links (steps 208 and 210), and the higher-power links can be shut down (step 214). This process may be reversed when more power becomes available or when the amount of power drain decreases (e.g., when some applications are shut down).
In the discussion of step 202 of
Step 208 discusses sharing traffic for one application over multiple links. Step 212 discusses sharing traffic for multiple applications over a common link. Step 218 shows another possible type of sharing. Multiple links may use the same radio frequency. To simultaneously support these links, the resource of their common frequency is shared by time-slicing their transmissions. Each link remains available, although the total bandwidth available to each link is reduced by the bandwidth requirements of the other links sharing this frequency.
a and 3b show a personal communications device 104 (e.g., a cellular telephone, personal digital assistant, or personal computer) that incorporates an embodiment of the present invention. Note that the present invention is not restricted to mobile devices but can be implemented in any device that connects to a network.
b illustrates some of the more important internal components of the personal communications device 104. The device 104 includes at least one communications transceiver 302, a processor 304, a memory 306 for storing, among other things, applications and rules, an antenna 308, and a battery 310.
Connected to the one or more antennae 308 are network communications engines 400. The example of
Sitting logically above the network communications engines 400 is the intelligent connectivity engine, shown in three parts: a lower-layer interface 402 that communicates with the network communications engines 400, a control middleware 404, and an upper-layer interface 406 that communicates with applications and other upper-layer clients 408. In the embodiment of
Some of the functions of the control middleware 404 are shown in
By its logical position between the upper-layer clients 408 and the network communications engines 400, the intelligent connectivity engine 402, 404, 406 is able to abstract connectivity details from the upper-layer clients 408. The upper-layer clients 408 are provided with the best connectivity available without having to worry about such considerations as which links are available, how much they cost in money and power, etc. The control middleware 404 can combine traffic from multiple upper-layer clients 408 onto one network link, split traffic from one network link to multiple upper-layer clients 408, and move traffic from one network link to another, all without the notice of the upper-layer clients 408. As noted above, however, in some embodiments, the upper-layer clients 408 can be kept informed of these changes (step 206 of
The position of the intelligent connectivity engine 402, 404, 406 also allows it, in some embodiments, to route traffic coming in from one network link out to another network link without the mediation of an upper-layer client 408.
In view of the many possible embodiments to which the principles of the present invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. For example, different communications protocols may call for differences in the architecture of the intelligent connectivity engine. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
