Abstract:
Embodiments of the invention relate to techniques to allow a wireless device engaged in a Session Initiation Protocol (SIP) communication session to move between heterogeneous wireless networks without terminating the SIP session.

Description:
TECHNICAL FIELD 
       [0001]    Embodiments of the invention relate to wireless communications. More particularly, embodiments of the invention relate to techniques to allow a wireless device engaged in a Session Initiation Protocol (SIP) based communication session to move seamlessly between heterogeneous wireless networks without terminating the SIP session. 
       BACKGROUND 
       [0002]    The Session Initiation Protocol (SIP) is a signaling protocol for creating, modifying and terminating sessions with one or more participants. SIP is defined in Request For Comments (RFC) 3261 published by the Internet Engineering Task Force (IETF) entitled, “SIP: Session Initiation Protocol,” published in June 2002. SIP may be used, for example, as a signaling protocol for Voice over IP (VoIP). However, SIP may be used in any application where session initiation is a requirement. 
         [0003]    SIP clients may use Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) to connect to SIP servers and other SIP endpoints. TCP is defined in RFC 793 entitled, “Transmission Control Protocol,” published in September 1981. UDP is defined in RFC 768 entitled, “User Datagram Protocol,” published in August 1980. 
         [0004]      FIG. 1  is a block diagram of one embodiment of a network utilizing SIP. A user of client device  120  may wish to communicate with a user of client device  140  over network  100 , which may be, for example, the Internet or any other network. Prior to communicating both client device  120  and client device  140  register with SIP server  180 . Registration provides SIP server with information related to client devices such as, for example, IP addresses for the respective client devices. 
         [0005]    In order to initiate a session, client device  120  sends a request to SIP server  180  indicating another client device with which a session is to be initiated. SIP server  180  sends a message to client device  140  indicating that client device  120  is attempting to initiate a SIP session. Client device  140  may accept or reject the invitation by responding to SIP server  180 . 
         [0006]    If the invitation is accepted by client device  140 , SIP server sends the appropriate information to client device  120 . Once the session is initiated, client devices  120  and  140  communicate directly over network  100  until one of the client devices terminates the session through SIP server  180 . While SIP allows communication between two client devices including wireless devices, SIP does not currently provide a mechanism to support all potential uses of SIP with wireless devices. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    Embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements. 
           [0008]      FIG. 1  is a block diagram of one embodiment of a network utilizing SIP. 
           [0009]      FIG. 2  illustrates one embodiment of an exchange of information between a SIP-based application and a connection manager to support SIP mobility awareness. 
           [0010]      FIG. 3  illustrates another embodiment of an exchange of information between a SIP-based application and a connection manager to support SIP mobility awareness. 
           [0011]      FIG. 4  is a block diagram of one embodiment of an electronic device. 
           [0012]      FIG. 5  is a block diagram of one embodiment of a SIP client agent that may be resident on a client device. 
           [0013]      FIG. 6  is a block diagram of one embodiment of a connection manager agent that may be resident on a client device. 
       
    
    
     DETAILED DESCRIPTION 
       [0014]    In the following description, numerous specific details are set forth. However, embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. 
         [0015]    Mobile multi-radio devices like laptops, Ultra-Mobile PCs (UMPCs), cell phones and other cellular-enabled devices may be used for real-time interactive applications like VoIP, Instant Messaging (IM), with many of these applications using the Session Initiation Protocol (SIP) as the signaling and session mobility protocol. Once a session is established a change in session parameters is likely to result in changes that the end users can perceive (e.g. change of codec rate, type). When mobile devices move from one network to another, changes in the network characteristics might result in changes to the SIP session parameters from the session&#39;s IP address to the session&#39;s video/audio codec properties. 
         [0016]    In IP networks, the IP addresses of the end points are key identifiers for the SIP sessions and a move to a different network will terminate the SIP session unless the SIP application takes appropriate actions. The new network characteristics can be different, requiring an adaptation of the audio/video rate/quality. For example, a user watching a video stream can move from a high capacity network like Wireless Local Area Network (WLAN) to a lower capacity network like Wireless Wide Area Network (WWAN) thus requiring sending lesser video information. In the following description, techniques to utilize a Connection Manager and SIP-based application support SIP sessions and enable seamless SIP application mobility are described. In general the Connection Manager resides on a client device having access to multiple networks and manages network connections by, for example, selecting a network to which the client device will connect, select connection parameters, etc. 
         [0017]    In one embodiment, when mobile devices move from one network to another, the Connection Manager selects a network to connect to by considering parameters including, for example, cost of network access, network security, quality of service (QoS), data-rate, network reliability, device battery life, user-defined policies, in order to provide a seamless transition. Key parameters to consider are the applications&#39; bandwidth and QoS requirements among others. 
         [0018]      FIG. 2  illustrates an exchange of information between a SIP-based application and a connection manager to support SIP mobility awareness. SIP client application  210  on client device  200  establishes a SIP session with client device  260 , registers with connection manager  220  and queries for the capabilities of the connected network(s). 
         [0019]    In one embodiment, client application  210  performs a SIP registration with connection manager  220  (Message A). In response, connection manager  220  informs client application  210  of current network capabilities (Message B). These properties may be gathered from multiple inputs (e.g. querying network devices, etc). 
         [0020]    Based on the network capability information client application  210  on client device  200  adapts the session description parameters appropriately and conveys the information to a counterpart client on client device  260  using the Session Description Protocol (SDP), defined in RFC 4566, or other appropriate protocol. 
         [0021]    In one embodiment, client application sends a SIP register message to SIP server  240  (Message C). In response SIP server  240  accepts the SIP register message by sending a SIP Register OK message to client application  210  (Message D). Upon completion of the registration process, client application  210  may send a SIP Session Invite message to client device  260  via SIP server  240  (Message E). The Session Invite message may include SDP parameters to be used in for the SIP session. 
         [0022]    In response to the Session Invite message, client device  260  may reply with a SIP Session Invitation Successful message to client application  210  via SIP server  240  (Message F). At this point, the SIP session is established and client device  200  may communicate with client  260  directly over the network, maybe using Realtime Transmission Protocol (RTP), as defined in RFC 3350. 
         [0023]    Sometime later due to device mobility or external/internal condition changes connection manager  220  may select a new network to connect to. At this point, if connection manager  220  disconnects from the current network and connects to the new network it will break the on-going SIP session. Instead, as shown in  FIG. 2 , connection manager  220  provides the network capabilities of the new network to client application  210  (Message G). 
         [0024]    Client application  210  may then determine the new SDP parameters to be used. Once client application  210  gets the IP address of the new network from connection manager  220  (Message H), client application  210  deregisters the old IP address and re-registers the new IP address. Deregistering the old SIP address does not affect the data traffic flow (which can use a RTP session) from client device  200  to client device  260 . Client application  210  on client device  200  then sends a SIP re-invite to the SIP client on client device  260  with the new IP address and the new SDP parameters to establish a new SIP session. This series of events results in a make-before-break model to enable seamless mobility for a SIP based applications. Make-before-break refers to a process in which a second SIP connection is established between clients and the SIP session traffic is transferred to the second connection before the first SIP connection is broken. This allows a seamless transfer between network so that, for example, a VoIP call is not dropped when a network change occurs. 
         [0025]    In one embodiment, to de-register the original IP address for client device  200 , client application  210  may send a SIP Deregister message to SIP server  240  (Message I). SIP server  240  may respond with a SIP Deregister OK message to client application  210  (Message J). 
         [0026]    In one embodiment, client application  210  sends a SIP Re-Register message to SIP server  240  with the IP address for the new network (Message K). In response SIP server  240  accepts the SIP Re-Register message by sending a SIP Re-Register OK message to client application  210  (Message L). 
         [0027]    Upon completion of the re-registration process, client application  210  may send a SIP Session Re-Invite message with the new IP address to client device  260  via SIP server  240  (Message M). The Session Re-Invite message may include the new SDP parameters to be used in for the SIP session. In response to the Session Re-Invite message, client device  260  may send a SIP Session Re-Invitation Successful message to client application  210  via SIP server  240  (Message N). 
         [0028]    At this point, the SIP session continues utilizing the new network. Client application  210  may then disconnect from the original network (Message O). The result of this process is a make-before-break SIP connection that allows a wireless device to move seamlessly between wireless networks without losing previously established SIP session. 
         [0029]    The above example illustrates how SIP clients may interact with the Connection Manager to get SDP information and adapt the SIP session while performing a make-before-break operation and provide seamless transition of the SIP session from one network to another, a key requirement for multi-radio devices supporting real-time packet based applications, e.g. VoIP. 
         [0030]    In the above description the Connection Manager provides the SIP client with the network information and the SIP client uses it to evaluate the new SDP parameters and adapt the session. That is, the intelligence is in the SIP client.  FIG. 3  shows a variation in the interaction where the connection manager provides network capability information to the SIP client which determines if the network is suitable for SIP sessions or not and informs the connection manager what services can be supported on the network. This may be considered a hybrid model where intelligence is both with the SIP application as well as the Connection Manager. 
         [0031]    In one embodiment, SIP client application  310  performs a registration with connection manager  320  (Message A). In response, connection manager  320  informs client application  310  of current network capabilities (Message B) using standardized Session Description Protocol (SDP) parameters. These parameters may be gathered from multiple inputs (e.g. querying network devices, querying an IEEE 802.21 compliant Information Server or other repository of networks and their capabilities). IEEE 802.21 refers to a proposed standard that supports seamless handover between networks of the same type as well as handover between different network types also called Media Independent Handover (MIH) or vertical handover. The standard provides information to allow handing over to and from cellular, GSM, GPRS, WiFi, Bluetooth and 802.11 networks through different handover mechanisms. 
         [0032]    In one embodiment, client application sends a SIP register message to SIP server  340  (Message C). In response SIP server  340  accepts the SIP register message by sending a SIP Register OK message to client application  310  (Message D). Upon completion of the registration process, client application  310  may send a SIP Session Invite message to client device  360  via SIP server  340  (Message E). The Session Invite message may include SDP parameters to be used in for the SIP session. 
         [0033]    In response to the Session Invite message, client device  360  may send a SIP Session Invitation Successful message to client application  310  via SIP server  340  (Message F). At this point, the SIP session is established and client device  200  may communicate with client  360  directly over the network. 
         [0034]    Sometime later due to device mobility or external/internal condition changes connection manager  320  may select a new network to connect to. At this point, if connection manager  320  disconnects from the current network it will break the on-going SIP session. Instead, as shown in  FIG. 3 , connection manager  320  provides the network capabilities of the new network to client application  310  (Message G) and can use SDP parameters to provide network capability. 
         [0035]    In response to receiving the new network capabilities, client application  310  may send a message to connection manager indicating the SIP services supported by client application  310  (Message H). Connection manager  320  may utilize the listing of supported SIP services to select a new network to use. Connection manager  320  may inform client application  310  the IP address for the new network (Message I). 
         [0036]    In one embodiment, to de-register the original IP address for client device  300 , client application  310  may send a SIP Deregister message to SIP server  340  (Message J). SIP server  340  may respond with a SIP Deregister OK message to client application  310  (Message K). 
         [0037]    In one embodiment, client application  310  sends a SIP Re-Register message to SIP server  340  with the IP address for the new network (Message L). In response SIP server  340  accepts the SIP Re-Register message by sending a SIP Re-Register OK message to client application  310  (Message M). 
         [0038]    Upon completion of the re-registration process, client application  310  may send a SIP Session Re-Invite message with the new IP address to client device  360  via SIP server  340  (Messages N and O). The Session Re-Invite message may include the new SDP parameters to be used in for the SIP session. In response to the Session Re-Invite message, client device  360  may send a SIP Session Re-Invitation Successful message to client application  310  via SIP server  240  (Messages P and Q). 
         [0039]    At this point, the SIP session continues utilizing the new network. Client application  310  may then disconnect from the original network (Message R). The result of this process is a make-before-break SIP connection that allows a wireless device to move seamlessly between wireless networks without losing previously established SIP session. 
         [0040]    It is also possible for the SIP client to provide its capabilities to the Connection Manager using SDP parameters so that the connection manager can use the information to select a new network. In this model the intelligence is with the Connection Manager. There is flexibility in the scheme in order to support various models based on operator or ISV preferences. 
         [0041]      FIG. 4  is a block diagram of one embodiment of an electronic device. The electronic device illustrated in  FIG. 4  is intended to represent a range of electronic devices including, for example, the client devices discussed above. Alternative electronic devices can include more, fewer and/or different components. In one embodiment the electronic device of  FIG. 4  is a desktop or a laptop computer system. In one embodiment, the electronic device of  FIG. 4  is a mobile device, for example, a laptop, an Ultra Mobile PC (UMPC, a smartphone or other cellular-enabled device. In one embodiment, UMPC refers to a small form factor tablet computing device. 
         [0042]    Electronic system  400  includes bus  405  or other communication device to communicate information, and processor  410  coupled to bus  405  to process information. While electronic device  400  is illustrated with a single processor, electronic device  400  can include multiple processors and/or co-processors. Electronic device  400  further includes random access memory (RAM) or other dynamic storage device  420  (referred to as memory), coupled to bus  405  to store information and instructions to be executed by processor  410 . Memory  420  also can be used to store temporary variables or other intermediate information during execution of instructions by processor  410 . 
         [0043]    In one embodiment, memory  420  may include SIP client agent  425  and/or connection manager agent  427 . SIP client agent  425  may provide the functionality of the SIP client applications described above. SIP client agent  425  may be implemented as hardware, software, firmware, or any combination thereof. Connection manager agent  427  may provide the functionality of the connection manager applications described above. Connection manager agent  427  may be implemented as hardware, software, firmware, or any combination thereof. 
         [0044]    Electronic device  400  also includes read only memory (ROM) and/or other static storage device  430  coupled to bus  405  to store static information and instructions for processor  410 . Data storage device  440  is coupled to bus  405  to store information and instructions. Data storage device  440  such as a magnetic disk or optical disc and corresponding drive can be coupled to electronic device  400 . 
         [0045]    Electronic device  400  can also be coupled via bus  405  to display device  450 , such as liquid crystal display (LCD) or other display device, to display information to a user. Input device(s)  460  may include keys, a mouse, a trackball, or other input devices and may be coupled to bus  405  to communicate information and command selections to processor  410 . Electronic device  400  further includes network interface  470  to provide access to a network, such as a local area network. Network interface  470  may include one or more antennae  480  to communicate utilizing wireless protocols and/or cable  485  to communicate utilizing wired protocols. 
         [0046]    Instructions are provided to memory from a computer-readable storage device, such as magnetic disk, a read-only memory (ROM) integrated circuit, CD-ROM, DVD, flash memory, via a remote connection (e.g., over a network via network interface  470 ) that is either wired or wireless, etc. In alternative embodiments, hard-wired circuitry can be used in place of or in combination with software instructions. Thus, execution of sequences of instructions is not limited to any specific combination of hardware circuitry and software instructions. 
         [0047]      FIG. 5  is a block diagram of one embodiment of a SIP client agent that may be resident on a client device. SIP client agent  500  includes control logic  510 , which implements logical functional control to direct operation of SIP client agent  500 , and/or hardware associated with directing operation of SIP client agent  500 . Logic may be hardware logic circuits and/or software routines. In one embodiment, SIP client agent  500  includes one or more applications  512 , which represent code sequence and/or programs that provide instructions to control logic  510 . 
         [0048]    SIP client agent  500  includes memory  514 , which represents a memory device and/or access to a memory resource for storing data and/or instructions. Memory  514  may include memory local to SIP client agent  500 , as well as, or alternatively, including memory of the host system on which SIP client agent  500  resides. SIP client agent  500  also includes one or more interfaces  516 , which represent access interfaces to/from (an input/output interface) SIP client agent  500  with regard to entities (electronic or human) external to SIP client agent  500 . 
         [0049]    SIP client agent  500  also includes SIP engine  520 , which represents one or more functions that enable SIP client agent  500  to provide SIP-based services for a host device. SIP engine  520  may include Voice over IP (VoIP) module  530  that provides VoIP communications utilizing SIP services. SIP engine  520  may also include SIP protocol stack  530  for use in SIP compliant communications. Additional modules may also be supported. These additional modules may, for example, support RTP interaction and/or TCP/IP interaction. As used herein, a module refers to routine, a subsystem, etc., whether implemented in hardware, software, or some combination. 
         [0050]      FIG. 6  is a block diagram of one embodiment of a connection manager agent that may be resident on a client device. Connection manager agent  600  includes control logic  610 , which implements logical functional control to direct operation of connection manager agent  600 , and/or hardware associated with directing operation of connection manager agent  600 . Logic may be hardware logic circuits and/or software routines. In one embodiment, connection manager agent  600  includes one or more applications  612 , which represent code sequence and/or programs that provide instructions to control logic  610 . 
         [0051]    Connection manager agent  600  includes memory  614 , which represents a memory device and/or access to a memory resource for storing data and/or instructions. Memory  614  may include memory local to connection manager agent  600 , as well as, or alternatively, including memory of the host system on which connection manager agent  600  resides. Connection manager agent  600  also includes one or more interfaces  616 , which represent access interfaces to/from (an input/output interface) connection manager agent  600  with regard to entities (electronic or human) external to connection manager agent  600 . 
         [0052]    Connection management agent  600  also includes connection manager engine  620 , which represents one or more functions that enable connection management agent  600  to provide connection management services for a host device. Connection management engine  620  may include connection management module  630  that provides management of connections to wired and/or wireless networks as described above. Additional modules may also be supported. As used herein, a module refers to routine, a subsystem, etc., whether implemented in hardware, software, or some combination. 
         [0053]    Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. 
         [0054]    While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.