Patent Application
20060274759
The present invention relates generally to a method and system for establishing communications between mobile nodes and to Session Initiation Protocol (SIP)-based mobility management.
Future wireless communication systems will provide a wide range of services using a variety of access technologies. Such systems are often described as Beyond 3G (B3G) systems and will include support for heterogeneous network access, communication service, user devices and mobility service. Modern networks are becoming increasingly diverse in their interconnectivity and transport capabilities, and B3G systems will need to be capable of managing even greater diversity. B3G systems may thus need to operate in an environment where almost all devices are networked, and almost all network entities are mobile.
Current trends in network technology also indicate that Internet technology will continue to dominate the future. Internet Protocol (IP) will likely remain the common method for transmitting data across a variety of networks. B3G systems will therefore operate between IP backbone networks and proprietary local environments.
One proposed B3G mobility management concept is the IP-based IMT Network platform (IP2). It is envisaged that IP2 will enable advanced mobility management by separating mobility management functions from network transport functions. Existing Internet standards are based on a fixed network where an IP address is used both as a terminal identifier and as a routing address. IP2 is intended to enable an entirely mobile IP environment where a terminal identifier of a mobile device does not need to be changed when the device changes location. In IP2 it is planned that a terminal identifier will be used only to identify a mobile device, and a routing address will be used only to transport packets within a network.
It has been suggested that many of the routing methods and protocols for accomplishing the mobile IP environment of IP2 will need to be fabricated and customized exclusively for such an IP2 environment. However, developing entirely new methods and protocols is a difficult undertaking that requires additional expense, time, and educational initiatives for the user community, and that may fail to capture many of the advantages and features of existing methods and protocols.
According to one aspect, the present invention is therefore a method for establishing communication between a first Mobile Node (MN1) and a second Mobile Node (MN2) using Session Initiation Protocol (SIP)-based mobility management, where the MN1 is in communication with a first Access Router (AR1) and the MN2 is in communication with a second Access Router (AR2). The method includes receiving, from the AR1 acting as an SIP User Agent (UA), at a Routing Manager (RM) a first call initiation message including an Internet Protocol host address (IPha) of the MN2. Next, a query is transmitted, which includes the IPha of the MN2, from the RM to a Location Manager (LM) acting as an SIP Registrar. The RM then receives from the LM, in response to the query, an Update message including an IP routing address (IPra) of the MN2 that is used to identify the AR2. The RM then transmits to the AR2 a second call initiation message that includes the IPra of the MN2. The present invention thus supports location privacy by preventing IPras from reaching end users, and also saves significant development resources and time by adapting an existing protocol to the core network part of an IP2 system.
According to another aspect, the present invention is A Network Control Platform (NCPF) system for establishing communication between a MN1 and a MN2 using SIP-based mobility management. The system includes a RM adapted to receive a first call initiation message from a AR1, which AR1 acts as an SIP User Agent in communication with the MN1, the message including an IPha of the MN2. The system also includes a LM acting as an SIP Registrar and adapted to receive a query from the RM, the query including the IPha of the MN2, where the LM is further adapted to transmit to the RM, in response to the query, an IP routing address (IPra) of the MN2 that is used to identify the AR2.
In order that the invention may be readily understood and put into practical effect, reference will now be made to exemplary embodiments as illustrated with reference to the accompanying figures, wherein like reference numbers refer to identical or functionally similar elements throughout the separate views. The figures together with a detailed description below, are incorporated in and form part of the specification, and serve to further illustrate the embodiments and explain various principles and advantages, in accordance with the present invention, where:
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
Before describing in detail embodiments that are in accordance with the present invention, it should be observed that the embodiments reside primarily in combinations of method steps and apparatus components related to establishing communications between mobile nodes and to Session Initiation Protocol (SIP)-based mobility management. Accordingly, the apparatus components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
In this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by “comprises . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.
Referring to
The ARs 130, 135 include Routing Cache Tables (RCTs) RCT1140 and RCT2145 that list a unique correspondence for each MN 120, 125 between an IP host address (IPha) and an IP routing address (IPra). It is planned that when the MN1120 first registers with the NCPF 115, the AR1130 assigns an IPra to the MN1120 by establishing in the RCT1140 correspondence between the IPha and the IPra of the MN1120.
Using methods and protocols that have not yet been invented, the prior art envisages that when a data packet 160 is transferred from the MN1120 to the MN2125, the MN1120 will first transmit the packet to the AR1130 and attach to the packet 160 in an IP header a source identifier that is the IPha of the MN1120, and a destination identifier which is the IPha of the MN2125. Through a query and response mechanism using the IPha of the MN2125, the AR1130 will then obtain from the NCPF 115 the IPra of the MN2125. The data packet 160 is then transmitted from the AR1130 across the IP-BB 150 to the AR2135; but the IPra, instead of the IPha, of the MN2125 is now used as the destination identifier. After the data packet 160 is received by the AR2135, the packet 160 is finally transmitted from the AR2135 to the MN2125, but again including only the IPha of the MN1120 as a source identifier and the IPha of the MN2125 as the destination identifier in an IP header. In such a manner the location information of the MN1120 and the MN2125 that is included in the IPras is never transmitted to another mobile node, where it could be subject to improper use; instead the location information is securely retained within the AR1130 and the AR2135. However, according to the prior art no packet formats, fall-back procedures, or protocols between the LM 110 and the RM 105 have been developed to implement the above described procedures of an IP system.
An embodiment of the present invention is therefore a specific method and system for establishing communications between a MN1120 and a MN2125 in an IP2 environment. Referring to
The present invention thus supports location privacy, which is a primary objective of IP2 concepts, by preventing IPras from reaching end users. The invention also saves significant development resources and time by adapting an existing protocol to the core network part of an IP2 system.
SIP-based mobility management according to the present invention is efficient because it reuses several SIP schemes, including those concerning message formatting, retransmission mechanisms, and server software. The SIP-based methods and systems of the present invention are also desirable because SIP is an extensible text-based messaging protocol that can integrate Authentication, Authorization and Accounting (AAA) features, Quality of Service (QoS) features, and security negotiation features.
Referring to
First, where the MN1120 acts as a caller and intends to initiate communications with the MN2125 as a callee, the MN1120 transmits to the AR1130 a Call Setting message including the IPha of the MN1120 and the IPha of the MN2125. The AR1130 then forwards the Call Setting message to the RM 105 and includes both the IPha and IPra of the MN1120 and the IPha of the MN2125. The RM 105 then begins to setup an SIP session with the AR2135, although the RM 105 still does not know the location of the MN2125. The RM 105 therefore transmits a Query message to the LM 110 so as to identify the current location of the MN2125. Next, the LM 110 finds the location of the MN2125 by searching for the IPra of the MN2125 in a database of the LM 110, by a paging method, or by some other type of method. After the MN2's 125 location is identified, the LM 110 transmits to the RM 105 an Update message including the IPra of the MN2125. Those skilled in the art will recognize that the Query and Update messages can be realized using an SIP Invite request and an SIP 302 Temporary moved response, respectively, or using other proprietary messages.
After the RM 105 receives the IPra of the MN2125, the RM 105 sends an SIP Invite request message that identifies the IPra of the MN2125 and which is routed to the AR2135. The Invite message includes the IPha and the IPra of both the MN1120 and the MN2125. The AR2135 then translates the received Invite message to a proprietary message called a Call Request and sends it to the MN2125. The AR2135 also creates a routing cache entry in an RCT2135 that records the IPha and IPra of the MN1120 for use in future address conversions.
When the MN2125 receives the Call Request message it notifies a user of the MN2125 of a call arrival, such as through a ring tone or vibration, and sends a Call Ringing message to the AR2135. The AR2135 then sends an SIP 180 ringing status message to the to the RM 105.
When MN2125 accepts the call, the MN2125 sends a Call Response message to the AR2135. The AR2135 then transmits an SIP 200 OK message to the RM 105. After the RM 105 receives an SIP 180 ringing message or an SIP 200 OK message from the AR2135, the RM 105 initiates an SIP session with the AR1130. That is done by sending an SIP Invite message from the RM 105 to the AR1130, which message includes the IPha and IPra of the MN2125 and the IPra of the MN1120. The AR1130 then translates the received Invite message to a proprietary Call Request message and sends it to the MN1120. The AR1130 also creates a routing cache entry in an RCT2140 that records the IPha and IPra of the MN2125 for future address conversions. The MN1120 then sends back a Call Response message to the AR1130 and the AR1130 sends an SIP 200 OK message to the RM 105. When the RM 105 receives the 200 OK messages from both the AR1130 and the AR2135, the RM 105 sends SIP ACK messages to both the AR1130 and the AR2135. The AR1130 and the AR2135 then transmit Call Ack messages to the MN1120 and the MN2125, respectively. Finally, the MN1120 and the MN2125 commence data transmission between each other through the AR1130 and the AR2135. Both the MN1120 and the MN2125 use the IPha addresses as source/destination addresses. As described above, the destination address of an IP header in a data packet 160 is translated from an IPha to an IPra at ingress to an AR 130, 135 and then translated back from an IPra to an IPha at egress from an AR 130, 135.
Referring to
Similar to sequences where the RM 105 acts as an SIP Controller, where the MN1120 acts as a caller and intends to initiate communications with the MN2125 as a callee, as shown in
After the RM 105 receives the IPra of the MN2125, the RM 105 sends an SIP Invite request message that identifies the IPra of the MN2125 and which is routed to the AR2135. The Invite message includes the IPha and the IPra of both the MN1120 and the MN2125. The AR2135 then translates the received Invite message to a proprietary message called a Call Request and sends it to the MN2125. The AR2135 also creates a routing cache entry in an RCT2135 that records the IPha and IPra of the MN1120 for use in future address conversions.
When the MN2125 receives the Call Request message it notifies a call arrival to a user of the MN2125, such as through a ring tone or vibration, and sends a Call Ringing message to the AR2135. The AR2135 then sends an SIP 180 ringing status message to the AR1130 via the RM 105.
When MN2125 accepts the call, the MN2125 sends a Call Response message to the AR2135. The AR2135 then transmits an SIP 200 OK message to the AR1130 via the RM 105. When the AR1130 receives the SIP 200 OK message, it sends back an SIP ACK message to the AR2135 and notifies the MN1120 of completion of the call set up with a Call Ack message. The AR2135 then sends a Call Ack message to the MN2125. Finally, the MN1120 and the MN2125 commence data transmission between each other through the AR1130 and the AR2135. Both the MN1120 and the MN2125 use the IPha addresses as source/destination addresses. As described above, the destination address of an IP header in a data packet 160 is translated from an IPha to an IPra at ingress to an AR 130, 135 and then translated back from an IPra to an IPha at egress from an AR 130, 135.
By adapting SIP to facilitate communications between ARs 130, 135 and a NCPF 115, the present invention is thus able to satisfy in a very efficient manner many of the IP2 requirements for mobility management. Such requirements include hiding a user's location information; optimizing routing paths and avoiding triangle routing; minimizing packet overhead and avoiding encapsulation; separating network control functions from IP transport functions; and hiding the IP addresses of the RM 105 and the LM 110 from network users.
Referring to
Referring to
In summary, advantages of particular embodiments of the present invention include saving significant development resources and time by adapting an existing protocol to the core network part of an IP system. SIP-based mobility management according to the present invention is efficient because it reuses several SIP schemes, including those concerning message formatting, retransmission mechanisms, and server software. Embodiments of the present invention also satisfy IP2 mobility management requirements such as location privacy for MNs 120, 125 and separate IP transport features and network control features. The SIP-based methods and systems of the present invention are also desirable because SIP is an extensible text-based messaging protocol that can integrate Authentication, Authorization and Accounting (AAA) features, Quality of Service (QoS) features, and security negotiation features.
It will be appreciated that embodiments of the invention described herein may be comprised of one or more conventional processors and unique stored program instructions that control the one or more processors to implement, in conjunction with certain non-processsor circuits, some, most, or all of the functions of establishing communications between mobile nodes and of SIP-based mobility management described herein. The non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method to perform SIP-based mobility management. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Thus, methods and means for these functions have been described herein. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.
In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. The benefits, advantages, solutions to problems, and any elements that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any or all of the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims.
