LIGHTWEIGHT COMMUNICATIONS PROTOCOL FOR REDUCING WHlELESS DATA TRANSACTIONS IN MOBILE SUBSCRIBER SESSIONS

Background Of The Invention

[0001] The present invention relates generally to mobile communications networks and, more particularly, to a lightweight communications protocol for reducing the number of over- the-air data transactions in mobile subscriber sessions.

[0002] The popularity of SIP (Session Initiation Protocol) as a communication protocol has greatly increased in recent years. SIP is modeled after HTTP (HyperText Transfer Protocol), the underlying protocol used by the World Wide Web, and is widely expected to revolutionize telecommunications similar to the way HTTP revolutionized the web. SIP has roots in the wire line broadband world where the driving requirement was to create a loose and flexible protocol that was access independent and generic. Because of the flexible nature of the protocol, standard bodies have begun adopting SIP as a communication protocol on user endpoints. Bandwidth requirements and transaction rates however have not been emphasized.

[0003] Mobile networks are undergoing the transformation and migration from the 2G standard to the 3 G standard. 3 G enables high speed data access to the mobile endpoints, thus opening the doors to many multimedia services. However, although 3G offers high speed data access, it is heavily oversubscribed, i.e., the users/channel ratio is very high (greater than \ 100 in some markets compared to 5 typically in wireline networks). Heavy oversubscription is primarily caused by the high startup cost in setting up a mobile access network. This high oversubscription significantly reduces the effective bandwidth available to mobile users and network throughput.

[0004] By way of example, a typical SIP call flow for VIM (voice instant messaging) is now described. The bandwidth requirements and transaction exchange rate is quantified for a typical VIM session setup and an instant message delivery.

[0005] A SIP client has to register with a SIP registrar/server if it wishes to be reached. The registration is valid for a configured time (e.g., one hour) and has the client's network address included in the registration. If at anytime the client changes its network address (e.g.,

als re-register with its registrar.

[0006] FIGURE 1 shows a typical call flow of a SIP client registering with a SIP registrar or server. This procedure is invoked if any change in the mobile network address is made or after some configured time period ends, whatever comes first. Exemplary transactions in a registration procedure shown below require 1 KB.

Via: SIP/2.0/TLS 10.0.33.241 :5061;branch=z9hG4bKnashds7 Max-Forwards: 70

From: XXXXX <sips:XXXXX@10.0.33.241>;tag=a73kszlfl To: XXXXX <sips:XXXXX@10.0.33.241> Call-ID: lj9FpLxk3uxtm8tn@l 0.0.33.241 CSeq: 1 REGISTER Contact: mailto:XXXXX@vzw.com

Authorization: Digest username- "XXXXX", reahn= "boston.vzw.com", qop="auth", nonce="lcec4341ae6cbe5a359ea9c8e88dβ4f, opaque="", uri= "sips:ss2.vzw. com ", respo _n se="71ba27c64bd01de719686aa4590d5824" Content-Length: 0

SIP/2.0 200 OK

Via: SIP/2.0/TLS 10.0.33.241: 506 l;branch=z9hG4bKnashds7 ;received^l 0.0.33.241

From: XXXXX <sips:XXXXX@10.0.33.241>;tag=a73kszlfl To: XXXXX <sips:XXXXX@10.0.33.241>;tag=34095828jh Call-ID: lj9FpLxk3uxtm8tn@10.0.33.241 CSeq: 1 REGISTER

Contact: <sips:XXXXX@10.0.33.241>;expires=3600 Contact: <mailto:XXXXX@vzw. co?n>;expires=4294967295 Content-Length: 0

[0007] Once the registration is performed, the SIP client can transmit and receive messages over the network. FIGURE 2 shows an exemplary call flow for a SIP client originating a VIM message. In this example, the SIP call flow takes a total of 5.25K Bytes and 9 SIP transactions to deliver one VIM message.

[0008] A fully loaded SIP application server chassis can typically serve 20,000 media ports. Using the standard oversubscription model, such a configuration can serve up to 2,000,000 subscribers. At a 0.02 erlang traffic per subscriber and an average individual message of 10 seconds, the total number of VIM messages the SIP application server will handle is 24,000,000/day or 1,000,000/hour. Using the results from the SEP call flow of 9 SP messages per VIM, such a configuration will result in 9,000,000 SIP transactions per hour

ulllizifegϋ G Bytes of SIP message data (overhead). These numbers show that extending SIP to mobile terminals is not efficient in mobile networks; hence improvements for increasing throughput in such an environment would be desirable.

Brief Summary Of Embodiments Of The Invention

[0009] In accordance with one or more embodiments of the invention, a method and system are provided for reducing the number of wireless transactions between an application server and mobile subscribers in a wireless communications system. The communications system includes a plurality of wireless mobile subscribers communicating with network devices via the application server. Each of the mobile subscribers includes a lightweight client, and the application server includes an alias for each mobile subscriber. For each session between a mobile subscriber and a network device: the application server receives a communication from the network device intended to be processed at a client residing on the mobile subscriber in accordance with a given protocol. The system distributes the processing of the communication between the lightweight client on the mobile subscriber and the alias for the mobile subscriber on the application server to reduce the processing performed by the lightweight client and the number of wireless transactions between the mobile subscriber and the application server.

[0010] These and other features and advantages of the present invention will become readily apparent from the following detailed description, wherein embodiments of the invention are shown and described by way of illustration of the best mode of the invention. As will be realized, the invention is capable of other and different embodiments and its several details maybe capable of modifications in various respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature and not in a restrictive or limiting sense, with the scope of the application being indicated in the claims.

Brief Description Of Drawings

[0011] FIGURE 1 illustrates an exemplary call flow of a SIP client registering with a SIP registrar/server in accordance with the prior art.

[0012] FIGURE 2 illustrates an exemplary call flow of a SIP-mobile originating a VIM message in accordance with the prior art.

P0ϊ3! S CIRfG.URiE'3 ifffitfiates a mobile communications system in accordance with one or more embodiments of the invention.

[0014] FIGURE 4 illustrates the distribution of SIP client functionality between the mobile subscriber and the application server in accordance with one or more embodiments of the invention.

[0015] FIGURE 5 illustrates an exemplary call flow of a SIP -mobile originating a VIM message in accordance with one or more embodiments of the invention.

[0016] FIGURE 6 illustrates the general structure of the lightweight communications protocol between a mobile device client and its SIP alias at a SIP application server in accordance with one or more embodiments of the invention.

Description Of The Preferred Embodiments

[0017] FIGURE 3 illustrates a wireless communications system 10 in accordance with one or more embodiments of the invention. The system includes a plurality of mobile subscribers 12 (also known as mobile devices or mobile nodes). The mobile subscribers 12 maybe any suitable device that is capable of communicating with a wireless network, such as, e.g., cellular phones, PDAs (personal digital assistants), mobile PCs (personal computers) with modems, and other mobile computing devices. The mobile subscribers communicate with the wireless network through a plurality of base stations 14. The base stations 14 act as the interface between the network and the mobile subscribers 12, in that they convert digital data into radio signals and vice versa. Each of the base stations 14 typically has an associated radio tower or antenna and communicates with various mobile subscribers 12 using radio links. In particular, the base stations 14 can communicate with various mobile subscribers 12 through the modulation and transmission of sets of forward signals, while base stations 14 receive and demodulate sets of reverse signals from various mobile subscribers 12 that are engaged in a wireless network activity (e.g., a telephone call, Web browsing session, interactive gaming, etc.).

[0018] A network 16 includes (preferably near an edge thereof) one or more application servers 18, which are used for interconnecting the mobile subscribers 12 and network resources 20, which can be other network devices such as, e.g., network servers and media servers. The application servers 18 communicate with other network devices 20 to provide

e jmp ^jiϊ p il ιj|jfgρss o a w e va e y o app ca ons an services inc u ing, e.g., instant messaging, push-to-talk services, interactive gaming, music and video streaming, and voice, video and Web conferencing.

[0019] In conventional systems, the application servers and other network devices communicate with the mobile subscribers using SIP as the session control mechanism, hi these conventional systems, each mobile subscriber includes a SIP client allowing it to communicate with other SIP devices, hi accordance with various embodiments of the invention, as illustrated, e.g., in FIGURE 4, the SIP functionality of each mobile subscriber 12 is distributed between the mobile subscriber 12 and the application server 18. hi particular, a light MM (multimedia) client 30 is implemented on the mobile subscriber 12, which communicates with an image 32, i.e., alias, of the subscriber implemented in the SIP application server 18. Together, the light client 30 and the subscriber alias 32 complete the SIP endpoint function for the mobile subscriber with respect to the external world (particularly, other devices in the network in a communication session with the mobile subscriber). By distributing the SIP functionality of a mobile subscriber between the mobile subscriber 12 and the application server 18, the mobile subscriber 12 and the application server 18 can communicate using a lightweight protocol, and the number of wireless transactions between the application server 18 and the mobile subscriber 12 can be significantly reduced.

[0020] The light client 30 can be implemented in the mobile subscribers 12 using various standards including, e.g., the J2ME (MIDP2.0, JSR 135) standard popular among mobile phones.

[0021] A number of advantages can be achieved by distributing the functionality of the SIP client between the mobile subscriber 12 and the application server 18. Throughput is enhanced by reducing the number of SP messages transmitted over the air. hi addition, the light MM client 30 has a smaller footprint on the mobile subscriber 12 since it uses preferably only core application specific code, and there is preferably no need for a SIP stack. Furthermore, the MM client 30 would need fewer CPU cycles as much or most of the SIP function would be delegated to its clone 32 residing at the application server 18. Reducing processing on the mobile subscriber also reduces the power consumed by the mobile subscriber, thereby increasing the time intervals between recharging of the device batteiy. hi addition, the high bandwidth processing architecture of the application server 18 can be

ϊfveragefd. core network.

[0022] FIGURE 5 illustrates an exemplary VIM call flow in accordance with one or more embodiments of the invention provided for comparison to the prior art call flow of FIGURE 2. As shown, in the FIGURE 5 call flow, only two wireless transactions are needed between the mobile subscriber and the application server, unlike the FIGURE 2 call flow in which nine transactions are needed to deliver one VIM message.

[0023] The MM client can use the Real-Time Transport Protocol (RTP) for the access to the application server. To improve throughput, high RTP packetization intervals could be used with large frame sizes. As an example, using an 8 kbps coder, a frame size of 1400 Bytes could carry > 1 sec of voice data. Such a scheme could be very efficient over the standard 20 msec packetization rate that would generate 50 packets for the same 1 sec of voice data.

[0024] The lightweight communication protocol used between the MM client 30 on the mobile subscriber 12 and its SIP alias 32 at the SIP application server 18 is compact and preferably extensible. It can significantly improve application throughput for 3 G and other wireless data networks. One possible general structure of the lightweight communication protocol PDU (protocol data unit) is illustrated in FIGURE 6. An 8 Byte header can be used containing fixed length fields starting with version number, followed by Application ID etc. Total Len represents the total length of the PDU and can be 2 Bytes wide. OpCode, which can be 2 Byte wide, carries the control instructions, e.g., the "Message" as shown in the call flow above. Many (e.g., 64,000) different types of opcodes can be defined. Len, which is a 2 Byte field, indicates the length of data associated with the OpCode. Data is a variable sized data field following the len. The syntax of this field can be opcode dependent.

[0025] An MM client 30 in accordance with one or more embodiments of the invention can be installed on a mobile subscriber 12 by downloading the client 30 from the network. Alternately, the software can be pre-installed on mobile subscribers 12 purchased by system users. Once the mobile subscriber 12 has the client application 30, the system can be optionally configured such that every invocation of the MM client 30 will preferably first check an associated portal to see if it has the most recent version of the software. If not, the portal can alert the client to upgrade the software to a new version.

[0026] Although various examples described in the application refer to use of the SIP

^otQco ^x|p ipu. >9F» ?F^P ^O( t at t e nvent on s not m te to use w t any part cu ar standard protocol, but can be used with a variety of communications protocols including, e.g., the H.323 protocol.

[0027] The MM client 30, subscriber alias 32 and associated processes are preferably implemented in software, and accordingly one of the preferred implementations is as a set of instructions (program code) in a code module resident in the random access memory of the respective devices. Until required, the set of instructions may be stored in another computer memory, e.g., in a hard disk drive, or in a removable memory, or downloaded via the Internet or some other computer network, hi addition, although the various methods described are conveniently implemented in a device selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the specified method steps.

[0028] Having described preferred embodiments of the present invention, it should be apparent that modifications can be made without departing from the spirit and scope of the invention.

[0029] Method claims set forth below having steps that are numbered or designated by letters should not be considered to be necessarily limited to the particular order in which the steps are recited.