Patent Grant
8849936
The present invention relates generally to communication systems comprising a plurality of mobile terminals and, in particular, to communications between such mobile terminals and a plurality of network-based service providers.
Mobile wireless communication systems are well known in the art. Within such systems, a plurality of mobile terminals, such as cellular telephones, push-to-talk radios, etc., are able to communicate with one another via wireless channels supported by a wireless infrastructure. Traditionally, such mobile terminals only supported voice communications. Recently, however, the processing power available within such mobile terminals has increased to the point that, in addition to voice transmission services, it is not uncommon for mobile terminals to include, for example, instant messaging applications, electronic mail applications, calendar applications, address book applications, etc. Indeed, some service applications supported by mobile terminals are capable of implementing more than one of these functions. Service applications of this type are typically implemented using stored software programs on a mobile terminal that interact with a corresponding network-based service provider.
This is further illustrated in
Typically, each session 109 is implementing using the so-called Transmission Control Protocol (TCP) as known in the art. Quite often, TCP connections are implemented on top of Internet Protocol (IP) addresses (i.e., addresses uniquely associated with individual mobile terminals), as known in the art. Such TCP/IP connections (typically implemented in fixed, wired networks) allow applications running on different hosts to reliably exchange streams of data. However, in a wireless environment such as that depicted in
Additionally, the use of multiple connections 109 is less efficient because each connection 109 propagates the full communication protocol all the way to the mobile terminal 101, including all header information, thereby making implementation at the mobile terminal 101 more complex. Various solutions have been proposed to address the complexity of communications caused by multiple service applications. For example, the so-called Extensible Messaging and Presence Protocol (XMPP) and Instant Messaging and Presence Service (IMPS) have been developed as common protocols for instant messaging. However, in addition to being a relatively inefficient, these protocols are limited to support of instant messaging service and do not provide additional support for email operations, synchronization operations, etc.
It would therefore be advantageous to provide reliable and efficient techniques that allow multiple service applications to communicate with their corresponding service providers such that the limitations of prior art approaches described above may be overcome.
The instant disclosure describes techniques for communicating between a mobile terminal and a plurality of service via intervening wireless and wired communication network. In particular, an intermediate service provider operates to mediate communications between the mobile terminals and the various service providers. In one embodiment, the intermediate service provider and a given mobile terminal establish a persistent session supported by a logical communication channel that is used to convey communications for all of the various service applications implemented by the mobile terminal, i.e., a single, multiplexed channel. For example, the logical channel may be implemented using, for example, the so-called User Datagram Protocol (UDP) based on IP addresses. Using such a channel, both the mobile terminal and intermediate service provider multiplex data communications for at least two different service applications onto the logical communication channel. Because service providers typically operate on a session-based model, establishment of the persistent session allows the intermediate service provider to maintain communications with the service providers regardless of the reliability of the logical communication channel.
Additionally, in another embodiment, better efficiency in comparison to prior art communication protocols is provided through the use of common protocol subsystems in support of multiple service applications. For example, a first set of commands may be provided that supports functionality common to all of the various service applications available in the system. In contrast, one or more additional sets of commands may be defined in which each additional command set embodies functionality that is common to a given service class, e.g., IM services, email services, etc. In this manner, it is possible to support applications having common functionality in a much more efficient manner due to the reduction in overhead.
In yet another embodiment, establishment of communications with various service providers is greatly simplified through the use of a single connection request message whenever a mobile unit desires to establish communications with more than one service provider. In particular, the connection request message specifies at least two selected service applications such that the intermediate service provider can establish communications with the multiple service providers in response to the single connection request message.
The features of the present invention are set forth with particularity in the appended claims. The present invention itself, together with further features and attendant advantages, will become apparent from consideration of the following detailed description, taken in conjunction with the accompanying drawings. One or more embodiments of the present invention are now described, by way of example only, with reference to the accompanied drawings wherein like reference numerals represent like elements and in which:
Referring now to
Referring now to
As known in the art, each of the mobile terminals 302 may comprise a combination of processing components operating under control of various stored executable instructions, i.e., software programs. For example, each mobile terminal may comprise one or more processing devices (such as microprocessors, microcontrollers, digital signal processors, etc. or combinations thereof) coupled to suitable storage devices (such as volatile and/or non-volatile memory devices) having stored thereon suitable instructions for implementing the functionality described herein through execution of such instructions by the processing device(s). Additionally, the mobile units 302 may each comprise necessary hardware circuitry to communicate via wireless channels 306 with one or more wireless networks 304. Techniques for implementing such mobile terminals are well known to those having ordinary skill in the art. Similarly, the one or more communication networks 304 may comprise one or more wireless networks as described above, as well as any public or private data communication network such as the Internet, World Wide Web, local area networks (LANs), wide area networks (WANs), virtual private networks (VPNs), etc. Once again, techniques for implementing such wireless and wired networks, or combinations thereof, are well known to those having ordinary skill in the art.
As shown, the intermediate service provider 201 operates as an interface between the one or more networks 304 and the plurality of service providers 310. Preferably, the intermediate service provider 201 is implemented using stored software programs executing on one or more server computers as known to those of skill in the art. However, it is equally understood that other implementation techniques may be equally employed. For example, any portion of the intermediate service provider 201 or any of the specific components illustrated in
The load balancers 320, when provided, operate to assign communications received from various mobile terminals to corresponding client front ends 322. For any initial communication received from a mobile terminal, e.g., the first time a mobile terminal establishes communications with the intermediate service provider 201, the load balancer 320 may select a client front end 322 using know load balancing techniques such as round-robin or least-busy assignments. The present invention is not limited in this regard. In a presently preferred embodiment, each mobile terminal connects to a single client front end for the duration of a persistent session. In turn, a given instance of a client front end 322 may support multiple mobile terminals 302. As described in greater detail below, each client front end 322 serves as a switching point for determining which service provider a given message is destined for. Similarly, messages being sent by a service provider 310 to a mobile terminal 302 are handled by the mobile terminal's corresponding client front end 322 to ensure proper compliance with the persistent session and multiplexed channel. Because each client front end 322 is instantiated as a separate process, the intermediate service provider 201 may instantiate as many client front end processes as necessary to more efficiently support the currently active number of mobile terminals 302.
As shown, each client front end 322 is capable to communicating with multiple service instances 324 corresponding to a variety of service providers 310. As further illustrated, each application-specific service instance 324 may be replicated as many times as needed in order to support communication traffic at any given moment. In general, each service instance 324 serves as an interface between the proprietary protocols of each service 310 and the session-based protocol utilized within the intermediate service provider 201 and between the intermediate service provider 201 and the mobile terminals 302. Note that the session-based protocol (utilizing services messages as described below relative to
Referring now to
Regardless, messages received from a physical communication channel (i.e., a wireless channel not shown) and addressed to the IP address of a given mobile terminal 100, 302 are processed up through the logical channel 402. Messages received from the logical channel 402 are first handled by a transport reliability process 408 to acknowledge reliably transmitted messages. Thereafter, a session filter 410 is used to determine whether or not the received message is for a currently active persistent session. Techniques for establishing such persistent sessions are further described below. Messages for inactive sessions are discarded at this point whereas, if the received message is for a currently active persistent session, processing continues where a duplicate reduction process 412 eliminates any duplicate messages. As know by those of skill in the art, UDP does not provide the delivery reliability of other, more sophisticated protocols, such as TCP. As a result, it is possible that duplicate messages will be received, which messages, when received, may be discarded. Finally, as described below, it may be necessary to fragment longer messages due to the constraints of the UDP/IP implemented logical channel. As such de-fragmentation (or reassembly) 414 of such fragmented messages also provided. A connection management block 416 is also provided to assist in management of the logical channel 402, particularly to manage any changes thereto. For example, the connection management block 416, where UDP/IP is used, tracks the mobile device's port and/or IP addresses that may change during the persistent session.
Once fully de-fragmented, an optimized service message 418, e.g., one that is possibly compressed and secured (encrypted) as necessary, is provided to the upper layers of the transport layer 204. Furthermore, for the purposes of transmission, an optimized service message 418 may be serialized, i.e., represented in a location- or implementation-independent way so that it can be communicated or stored elsewhere. Where encryption is used to provide security for the service messages, received messages must be decrypted 420 in order to be properly processed. Similarly, in order to minimize bandwidth usage, it may be that the service messages have been compressed, thereby necessitating further decompression processing 422 as shown. Finally, a serializer/de-serializer block 424 is provided that takes the serialized message and de-serializes it to a normalized service message 426, i.e., converts it (using known techniques) into a format that can be directly used by a service application. At this point, a normalized service message 426 is available for provision to the one or more applications implemented by the mobile terminal. A technique for discriminating between which applications a given message targeted to is further described with references to
The transport layer 204 illustrated in
Referring now to
In the case of data provided by the mobile terminals, the incoming messages are first received by the load balancer 320 as shown. Assuming that multiple instances of client front ends are operating at any given moment, the load balancer 320 selects that client front end needed to preserve a load balance between the multiple client front end instances (assuming that this message is a first message received from the mobile terminal). Because mobile terminals are bound to corresponding client front ends after their initial contact, subsequent messages are not load balanced and, instead, pass directly through. However, in those instances in which a client front end fails, the load balance may operate to detect this condition and route subsequent messages to another available client front end. Techniques for implementing such load balancing are well known in the art. Within a given instance of a client front end, the incoming message is first processed in accordance with the initial UDP/IP layers 506 based on the IP address of the client front end. As described above relative to
Using UDP/IP identifications unique to a given service instance, the client front end transport layer 502 passes the resulting message (or fragment of a message) to the appropriate service instance. In the case of an inbound message, session filtering 528 to ensure that only messages associated with persistent sessions known to the service instance are processed. Thereafter, de-fragmentation processing 530 is performed, as necessary, to provide a fully-assembled optimized service message 532 (functionally equivalent to the optimized service message 418 described above). As before, if necessary, the optimized service message 532 is decrypted by decryption processing 534, decompressed 536 and de-serialized as described above. The resulting normalized service message 540 is thereafter available for provision to the appropriate service provider.
As before, the transport layers 504, 502 may be used to process communications received from the service provider and destined for the mobile terminal. To this end, the service messages 540 are received from the service provider and serialized 540, compressed 536 and encrypted 534, as needed. The resulting optimized service message 532 is then provided to the fragmentation processing block 530 where, if necessary, it is fragmented. The UDP/IP link between the service instance and the client front end then transports the resulting message (or fragment of a message) to the client front end corresponding to the particular mobile terminal. In one embodiment, this is accomplished by having the service instance maintain a mapping of session identifications to client front ends (as identified by their UPD/IP addresses) based on initial session creations. Once received by the appropriate client front end, the appropriate session information may be appended by the session manager 518 to the message and encapsulated within the necessary UDP/IP headers 506, 508 for transmission to the mobile terminal.
Finally, it is noted that the processing illustrated in
The processing described above is further illustrated with reference to
Referring now to
Having now established a session with the intermediate service provider 201 (more specifically, with a corresponding client front end 760), the mobile terminal 755 may send a connection request 710 to the client front end 760. In accordance with a presently preferred embodiment, the connection request message 710 includes a list of all selected services with which the mobile terminal desires to establish a connection. To this end, the mobile terminal receives indications of selections (provided by a user of the mobile terminal) of particular services to be included in the connection request message. Techniques for receiving such selection indications are well known to those having ordinary skill in the art.
Once the client front end 760 receives the connection request message 710, it forwards the connection request message 712 to the security server 765 where the selection indications are decrypted using the session key previously established. As described in further detail below, the connection request message 712 once decrypted, includes an identification of the particular service or services indicated by the mobile terminal 755. This is illustrated in
In response to the proprietary connection requests 718, 726, both of the service providers 780, 785 respond with proprietary connection response messages 720, 728 to their respective service instances 770, 775 (assuming, of course, that the proprietary connection requests 718, 726 are acceptable). Note that the order of arrival of the proprietary connection response messages 720, 728 illustrated in
As noted above, the present invention preferably utilizes UDP in order to communicate between the mobile terminal 755 and the client front end 760. However, as known in the art, data transfers using UDP messages typically may not exceed a maximum transmission unit (MTU) size, e.g., 1,500 bytes, based on limitations of the underlying datalink layer. Thus, messages that are larger than a single MTU must be broken up (i.e., fragmented, as described above) and subsequently reassembled (de-fragmented) in order to be successfully transferred. An example of the fragmentation process is illustrated in
It is noted that the opposite of the process illustrated by messages 734-738 may also occur. That is, a message sent by a service provider 780, 785 may be larger than a single MTU. In this case, the corresponding service provider service instance 770, 775 performs the fragmentation and sends the fragmentary messages to the client front end 760, which in turn forwards the various fragments to the mobile terminal. There, in accordance with processing by the mobile terminal's transport layer 204, the various fragments are reassembled as necessary.
As noted above, various embodiments of the present invention employ a standardized service message for transfer of messages between the mobile terminal and the intermediate service provider, as well as within the intermediate service provider. An exemplary service message is further illustrated with reference to
The options field identifies whether additional headers have been included in the service message, e.g., headers in support of fragmentation, encryption, compression, etc. In conjunction, if any of the options bits are set, indicating that additional headers are present in the message, the options data length field sets forth the length of such additional headers (e.g., in number of bytes) whereas the option data sets forth the additional header data. In a similar vein, the command data length field sets forth the length (again, preferably in number of bytes) of the command data.
The service message 900 described above is believed to be the message most often used. However, other message types may also be employed. For example, in a presently preferred embodiment, other message types include a “Keep Alive”, or “Ack” or “Non-Ack Keep Alive” messages. Such message types may be used in place the service message 900 where appropriate. For example, the Keep Alive message preferably comprises a “dummy” message that is sent to prevent a logical channel/persistent session from being closed. Preferably, such Keep Alive messages are acknowledged by the recipient. The Ack message acknowledges receipt of a message and preferably includes the session identification and sequence number (as described below) of the message being acknowledged. Finally, the Non-Ack Keep Alive message is another “dummy” message that is sent to prevent the logical channel/persistent session from being closed without requiring, however, acknowledgment by the recipient. Those having skill in the art that other message types could also be defined as a matter of design choice.
Referring now to
Referring now to
An example of a breakdown of common-functionality command or message sets in accordance with a presently preferred embodiment is further illustrated with reference to
Above the core base 1302, various service type-specific message sets are defined. In particular, synchronization base messages 1304, IM base messages 1324 and email base messages 1330 are shown. The synchronization base messages 1304 include messages embracing functionality common to all synchronization-related service applications, such as user data service applications, calendar service applications and/or address book service applications. Such messages may include, by way of non-limiting example, synchronization request and response messages, synchronization data, etc. Likewise, the IM base messages 1324 and email base messages 1330 include functionality common to those classes of service. Other classes of service suitable for definition in this manner may be apparent to those of skill in the art.
Further subsets of common functionality may be defined up to the point of specific implementations of a given service. For example, as shown, multiple IM service instances 1326-1328 are provided, each of which may include various messages that are specific to that implementation. Likewise, various email service instances 1332-1334 may be provided that use proprietary messages that cannot be generalized. On the other hand, further levels of common functionality may employed as illustrated, for example, by the user data base messages 1306, calendar base messages 1312 and address book base messages 1318 that serve as intermediate levels of common functionality specific to those service types. Once again, at the most specific level, one or more specific services instances for each service type may be provided, e.g., for user data services 1308-1310, calendar services 1314-1316 and address book services 1320-1322. By defining messages for such common functionality at various levels of abstraction, the present invention can beneficially reduce the amount of overhead required to implement multiple service applications.
Referring once again to
While the particular preferred embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that changes and modifications may be made without departing from the teachings of the invention. It is therefore contemplated that the present invention cover any and all modifications, variations or equivalents that fall within the scope of the basic underlying principles disclosed above and claimed herein.
This application is a divisional of U.S. Pat. No. 8,224,919, the entire disclosure of which is hereby incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6421707 | Miller et al. | Jul 2002 | B1 |
| 6742127 | Fox et al. | May 2004 | B2 |
| 6947431 | Bergeron | Sep 2005 | B1 |
| 7039394 | Bhaskaran | May 2006 | B2 |
| 7120455 | Chen et al. | Oct 2006 | B1 |
| 7136377 | Tweedly | Nov 2006 | B1 |
| 7155483 | Friend et al. | Dec 2006 | B1 |
| 20020194226 | Sheth et al. | Dec 2002 | A1 |
| 20030084177 | Mulligan | May 2003 | A1 |
| 20030129969 | Rucinski | Jul 2003 | A1 |
| 20030231207 | Huang | Dec 2003 | A1 |
| 20040087300 | Lewis | May 2004 | A1 |
| 20040199665 | Omar et al. | Oct 2004 | A1 |
| 20050002335 | Adamczyk et al. | Jan 2005 | A1 |
| 20050021638 | Caldini et al. | Jan 2005 | A1 |
| 20050097440 | Lusk et al. | May 2005 | A1 |
| 20050108334 | Tam et al. | May 2005 | A1 |
| 20050246445 | Panasyuk et al. | Nov 2005 | A1 |
| 20060009243 | Dahan et al. | Jan 2006 | A1 |
| 20060095529 | McNamara | May 2006 | A1 |
| 20060123079 | Sturniolo et al. | Jun 2006 | A1 |
| 20060218234 | Deng et al. | Sep 2006 | A1 |
| 20060224750 | Davies et al. | Oct 2006 | A1 |
| 20070033255 | Sanjeeva et al. | Feb 2007 | A1 |
| Number | Date | Country |
|---|---|---|
| 1021021 | Jul 2000 | EP |
| 1022875 | Jul 2000 | EP |
| 1315336 | May 2003 | EP |
| 1555793 | Jul 2005 | EP |
| 1667042 | Jul 2006 | EP |
| 2401011 | Oct 2004 | GB |
| 2005032055 | Mar 2005 | JP |
| 02058356 | Jul 2002 | WO |
| 03084136 | Oct 2003 | WO |
| 2004099919 | Nov 2004 | WO |
| 2004100586 | Nov 2004 | WO |
| 2006028760 | Mar 2006 | WO |
| Entry |
|---|
| “User Datagram Protocol”, http://en.wikipedia.org/wiki/user—datagram—protocol, Jan. 2007, pp. 1-7. |
| “Transmission Control Protocol”, http://en.wikipedia.org/wiki/transmission—control—protocol, Jan. 2007, pp. 1-13. |
| Number | Date | Country | |
|---|---|---|---|
| 20120269132 A1 | Oct 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11696282 | Apr 2007 | US |
| Child | 13532895 | US |
