System and method for performing hand-offs between internet protocol (IP) core networks in the wireless domain

[0001] This invention relates in general to the field of communications and in particular to a system and method for performing hand-offs between IP core networks in the wireless domain.

[0002] In a typical mobile communications system, mobile units are supported by radio networks coupled to different mobile switching centers (MSCs) providing an interface between the radio networks and the public switched telephone network (PSTN). In traditional circuit-switched environments, an MSC controls both the signaling and bearer paths for a call. When a mobile unit participating in a communications session roams from the service area of one radio network to the service area of another radio network, the communications session may be handed-off between the MSCs coupled to the radio networks. When a hand-off occurs between two MSCs, the source MSC establishes a circuit-switched connection to the next switch in the network providing service to the mobile unit. The source MSC has to maintain the original circuit-switched connection, providing an anchor for the bearer path and the second circuit-switched connection. Additional connections may need to be added if the mobile unit roams into other network service areas, and these connections may need to be linked to the original connection.

[0003] IP networks have begun to replace MSCs. Accordingly, systems and methods are needed for handing-off mobile communications sessions between IP networks coupling radio networks to the PSTN

[0004] In accordance with the present invention, the disadvantages and problems associated previous systems and methods for performing hand-offs have been substantially reduced or eliminated.

[0005] A system for performing a hand-off between two IP core networks in the wireless domain includes a source mobility control function (MCF) within a source IP core network coupled to a source access network providing service to a mobile unit. The source MCF is coupled to a source bearer path gateway (BPGW) within the source IP core network. The source BPGW communicates bearer traffic associated with the mobile unit between the source access network and a PSTN gateway within the source IP core network. The PSTN gateway communicates the bearer traffic between the source BPGW and a PSTN coupled to the source IP core network. The source MCF is functionally separate from a call agent (CA) within the source IP core network. The CA is also coupled to the source BPGW. The CA sets up a first segment of a bearer path for the bearer traffic between the source BPGW and the PSTN gateway, and the source MCF sets up a second segment of the bearer path for the bearer traffic between the source access network and the source BPGW. A hand-off occurs between the source IP core network and the target IP core network in the wireless domain when the source MCF takes down the second segment and sets up third and fourth segments of the bearer path for the bearer traffic in response to the mobile unit entering a service area of a target access network coupled to a target IP core network. The third bearer segment is between the source BPGW and a target BPGW within the target IP core network that communicates the bearer traffic between the target access network and the source BPGW, and the fourth bearer segment is between the target access network and the target BPGW.

[0006] Embodiments of the present invention may provide a number of important technical advantages over previous systems and methods for performing hand-offs. In certain embodiments, hand-offs between core networks may be performed by mobility control functionality without accessing call control functionality. Accordingly, hand-offs may be performed entirely within the IP wireless domain, allowing mobility control functionality within a core network to be separated from call control functionality. Separating these functionalities in turn allows functionalities associated with legacy architecture MSCs to be distributed among components in an IP-based system. Distributing functionality in this way may provide benefits such as greater network scalability, greater operability between core network components built by different manufacturers, and support for different access technologies. Distributing MSC functionality among components in an IP-based system also allows for a convergence of fixed and mobile services in a core network, which has become increasingly important as communications networks have evolved.

[0007] Certain embodiments of the present invention may also allow the control path of a call to remain fixed for the duration of the call. The bearer path between the source BPGW and a network such as the PSTN, the Internet, or other suitable network may also remain fixed for the duration of the call. Moreover, resetting the bearer path between the radio access network (RAN) and the source BPGW during a hand-off allows old resources to be released and fewer core network resources to be used when the mobile unit roams from one network service area to another. Certain embodiments of the present invention may also provide for the use of IP-based protocols, such as media gateway control protocol (MGCP) and session initiation protocol (SIP), to control call hand-offs from one IP core network to another. The use of such protocols may, in certain embodiments, substantially replace circuit-switched based methods used in the past.

[0008] Systems and methods incorporating one or more of these or other technical advantages are well suited for performing hand-offs between IP core networks. Other technical advantages are readily apparent to those skilled in the art from the following figures, descriptions, and claims.

[0013] FIG. 1 illustrates an exemplary distributed system 10 for providing service to mobile unit 22. System 10 includes IP core network 12 coupling radio access network (RAN) 14 to SS7 network 16 and PSTN 18. RAN 14 is coupled to a base transceiver station (BTS) 20 providing wireless communications services for mobile unit 22. Mobile unit 22 may be an analog or digital cellular telephone, personal digital assistant (PDA), pager, or other suitable wireless device providing wireless communications for voice, data, video, signaling, control, or other data using any suitable wireless communications protocol or combination of protocols by establishing a wireless link with BTS 20. For example, IS-95B may be used for communications between mobile unit 22 and BTS 20. BTS 20 includes hardware, software, or a combination of hardware and software supporting a wireless link with mobile unit 22 using any suitable packet-switched or circuit-switched wireless communications protocols. RAN 14 provides a link coupling BTS 20 with IP core network 12 and may manage wireless resources for BTS 20. For example, RAN 14 may perform channel setup, frequency hopping, “soft” hand-offs, and other suitable functions for BTS 20. Although RAN 14 is shown coupled to one BTS 20, RAN 14 may be coupled to a plurality of BTSs 20 providing services to a plurality of mobile units 22. RAN 14 includes radio network control system (RNCS) 24 and selection and distribution unit (SDU) 26 for communicating signaling and bearer traffic, respectively, with IP core network 12.

[0014] IP core network 12 provides a link coupling RAN 14 with PSTN 18 and SS7 network 16. IP core network 12 may include a universal mobile telecommunications system (UMTS) core network and may support multiple wireline and wireless access networks, such as digital subscriber line (DSL) networks, third-generation (3G) RANs, second-generation (2G) RANs, cable networks, existing wireline networks (such as PSTNs and integrated services digital networks (ISDNs)), enterprise networks, and any other suitable networks. IP core network 12 includes mobility control function (MCF) 28, call agent (CA) 30, media gateway controller (MGC) 32, SS7 gateway 34, BPGW 36, and PSTN gateway 38.

[0015] In general, MCF 28 is a wireless-specific core network component that sets up and takes down connections between core network 12 and RAN 14 or any other suitable wireless access network. MCF 28 may also set up and take down connections between IP core network 12 and another IP core network 12. Additionally, MCF 28 may convert RAN-specific protocol information to generic IP-based protocol information, and vice versa, to provide a signaling interface between RAN 14 and core network 12. In particular, MCF 28 may communicate signaling traffic between RAN 14 and CA 30. Signaling traffic may be any traffic containing data used for system control, synchronization, checking, signaling, or service signals used in system management and operations or any other appropriate signaling data. The path through system 10 taken by signaling traffic associated with a particular mobile unit 22 may be referred to as a signaling path. MCF 28 may communicate signaling traffic with RNCS 24 using any suitable application-layer protocol or combination of protocols over any suitable transport-layer protocol or combination of protocols. For example, MCF 28 may communicate signaling traffic with RNCS 24 using IS-634 over signaling connection control part (SCCP) over signaling transport (SIGTRAN). A protocol such as the UMTS-defined protocol radio access network access protocol (RANAP) may be used instead of IS-634. SCCP is part of the ITU-T #7 signaling protocol and the SS7 protocol. SIGTRAN is defined by Internet Engineering Task Force (IETF) Request for Comment (RFC) 2719 and may be used for transporting packet-based PSTN signals over IP networks, including transporting signals between a signaling gateway and media gateway or media gateway controller, transporting “backhaul” signals from a media gateway to a media gateway controller, and transporting transaction capabilities application part (TCAP) information between a signaling gateway and other IP nodes. MCF 28 may communicate signaling traffic with CA 30 using any suitable application-layer signaling protocol or combination of protocols. For example, MCF 28 may communicate with CA 30 using session initiation protocol (SIP) or an extension of SIP over TCP/IP. SIP is an application-layer call-control protocol defined by IETF RFC 2543 for creating, modifying, and terminating sessions, including Internet multimedia conferences, Internet telephone calls, and multimedia distribution sessions, with one or more participants communicating by unicast, multicast, or a combination of unicast and multicast.

[0016] MCF 28 controls bearer paths between BPGW 36 and RAN 14. The path through system 10 taken by bearer traffic associated with a particular mobile unit 22 may be referred to as a bearer path, and bearer traffic may be any traffic containing user data, such as audio, video, a combination of audio and video, encoded for transmission over system 10. MCF 28 may communicate with BPGW 36 to, for example, set up or take down the segment of a bearer path between BPGW 36 and RAN 14 using any suitable application-layer protocol for externally controlling media gateways. For example, MCF 28 may communicate with BPGW 36 using media gateway control protocol (MGCP) or H.248 over UDP/IP. MGCP is a call-control protocol defined by IETF RFC 2705 for communication between media gateways and signaling devices.

[0017] IP core network 12 may route signaling and bearer traffic for a mobile call originating within the service area of RAN 14 between SS7 network 16 and PSTN 18 on one side of IP core network 12 and RAN 14 on the other side of IP core network 12. In particular, bearer traffic for a mobile call originating within the service area of RAN 14 is communicated between SDU 26 and BPGW 36, between BPGW 36 and PSTN gateway 38, and between PSTN gateway 38 and PSTN 18. Signaling traffic for the mobile call is communicated between RNCS 24 and MCF 28, between MCF 28 and CA 30, between CA 30 and MGC 32, between MGC 32 and SS7 gateway 34, and between SS7 gateway 34 and SS7 network 16. Reference to mobile calls is meant to include any communication sessions in which mobile unit 22 may participate. When mobile unit 22 roams into the service area of a RAN 14 coupled to a different IP core network 12, a hand-off may be performed between the source IP core network 12 and the target IP core network 12. Such a hand-off may be referred to as an “inter-core” hand-off. In general, “source” is meant as a reference to devices providing service to mobile unit 22 before an inter-core hand-off. Similarly, “target” is meant as a reference to devices providing service to mobile unit 22 after an inter-core hand-off in lieu of corresponding source devices. A source device may provide service to mobile unit 22 both before and after a hand-off and that reference to a device as a “source” or “target” device is not meant to be limiting in any way. During an inter-core hand-off, source MCF 28 may take down the segment of the bearer path between source SDU 26 and source BPGW 36 and set up a new bearer path segment between source BPGW 36 and target BPGW 36 providing a link between the target RAN 14 and PSTN 18. In this way, the bearer path segments between source BPGW 36 and PSTN gateway 38 and between PSTN gateway 38 and PSTN 18 may remain fixed for the duration of the mobile call and CA 30 need not be involved in the hand-off. Additionally, the signaling path segments between source MCF 28a and SS7 network 16 may remain fixed throughout the mobile call. In one embodiment, source MCF 28 sets up the new bearer path segment by determining the IP address of target MCF 28 and communicating a SIP “invite” message to the target MCF 28 and, in response, receiving information about the IP address of target BPGW and the port thereof for communication with target BPGW 36. Source MCF 28 then communicates that information (using MGCP) to source BPGW 36, which communicates bearer traffic for the mobile call with target BPGW 36 after the hand-off. Source MCF 28 and target MCF 28 may communicate with each other in any appropriate manner. For example, source MCF 28 and target MCF 28 may communicate with each other over an IP network coupling source IP core network 12 and target IP core network 12. When a mobile call is handed-off to IP core network 12, MCF 28 may set up a bearer path segment between SDU 26 and BPGW 36 for bearer traffic associated with a mobile unit that has entered the service area of RAN 14 in response to a SIP invite message received from another MCF 28, MCF 28 may also communicate information about BPGW 36, such as the IP address of BPGW 36 and the port thereof for communication with the source BPGW 36, to the source MCF 28.

[0018] CA 30 communicates signaling traffic between MCF 28 and MGC 32 and controls bearer paths between BPGW 36 and PSTN gateway 38. CA 30 is functionally separate from MCF 28 and lacks mobility specific functions. In particular, CA 30 need not participate in inter-core hand-offs. As a result, CA 30 provides support for different access technologies and allows for a convergence of fixed and mobile services in core network 12. CA 30 may have an open-standard interface instead of a closed proprietary interface and may interface with MCFs 28 and other appropriate network devices built by different vendors. CA 30 may communicate signaling traffic with MCF 28 and MGC 32 using any suitable application-layer signaling protocol or combination of protocols. For example, CA 30 may communicate with MCF 28 and MGC 32 using SIP or an extension of SIP over TCP/IP. CA 30 may control bearer paths between BPGW 36 and PSTN gateway 38 by communicating with BPGW 36 using any suitable application-layer protocol for externally controlling media gateways. For example, CA 30 may communicate with BPGW 36 using MGCP or H.248 over UDP/IP.

[0019] MGC 32 provides a link between CA 30 and SS7 gateway 34, controls PSTN gateway 38, and may be responsible for call processing, service logic, routing, billing, and other appropriate gateway control functions. MGC 32 may communicate signaling traffic with CA 32 using any suitable application-layer signaling protocol. For example, as described above, MGC 32 may communicate with CA 30 using SIP over TCP/IP. MGC 32 may also communicate with CA 30 using an extension of SIP for communication between the components of IP core network 12. MGC 32 may communicate signaling traffic with SS7 gateway 34 using any suitable application-layer protocol for communicating call set up signaling information over any suitable transport layer protocol for transporting packet-based PSTN signals over IP networks. For example, MGC 32 may communicate with SS7 gateway 34 using ISDN user part (ISUP) over SIGTRAN. SS7 gateway 34 may provide a signaling interface between core network 12 and SS7 network 16. MGC 32 may control PSTN gateway 38 using any suitable application layer protocol for externally controlling media gateways. For example, MGC 32 may communicate with PSTN gateway 38 using MGCP or H.248 protocol over UDP/IP.

[0020] In general, BPGW 36 provides a media interface between IP core network 12 and RAN 14 or another core network 12. Specifically, BPGW 36 communicates bearer traffic between PSTN gateway 38 and RAN 14 or another core network 12 and may perform negotiation, transcoding, bearer traffic switching, media control, media conversion, and any other suitable media gateway tasks. BPGW 36 may communicate with RAN 14 and other media gateways, such as other BPGWs 36 and PSTN gateways 38, using any suitable set of protocols for communicating bearer traffic. For example, BPGW 36 may communicate bearer traffic using adaptive multi-rate (AMR) over real-time transport protocol (RTP) on top of UDP/IP. AMR is a voice encoding algorithm, and RTP is a protocol for the transport of real-time data, including audio and video, over an IP network. MCF 28 and CA 30 may both control BPGW 36. Specifically, MCF 28 sets up and takes down bearer paths between BPGW 36 and RAN 14 or another IP core network 12 and CA sets up and takes down bearer paths between BPGW 36 and PSTN gateway 38. As described above, MCF 28 and CA 30 may control BPGW 36 using MGCP or H.248 over UDP/IP. During an inter-core hand-off to a target IP core network 12, MCF “instructs” BPGW 36 to communicate bearer traffic associated with a mobile unit 22 that has entered the service area of a target RAN 14 with a target BPGW 36 within the target IP core network 12. In one embodiment, the port of BPGW 36 previously used for communication with SDU 26 is modified by MCF 28 for communication with a target BPGW 36 within target IP core network 12. While the segment of the bearer path for bearer traffic associated with mobile unit 22 between BPGW 36 and RAN 14 changes during an inter-core hand-off, the bearer path segment between BPGW 36 and PSTN gateway 38 does not change. In this way, CA 30 need not be involved in inter-core hand-offs and may provide support for both fixed and mobile access technologies.

[0021] PSTN gateway 38 provides a media gateway between IP core network 12 and PSTN 18, translating bearer traffic from IP format to PSTN circuit-switched format, and vice versa. As described above, PSTN gateway 38 may communicate bearer traffic with BPGW 36 using AMR over RTP on top of UDP/IP and may communicate with MGC 32 using MGCP or H.248 over UDP/IP. PSTN gateway 38 is controlled by MGC 32, which may set up and take down bearer paths between PSTN gateway 38 and other media gateways, such as BPGW 36, and networks, such as PSTN 18.

[0022] FIG. 2 illustrates the routing of signaling and bearer traffic after a hand-off between two IP core networks 12. As described above, an inter-core hand-off may be performed when a hand-off between RANs 14 requires a hand-off between IP core networks 12. For example, when mobile unit 22 leaves the service area of source RAN 14a and enters the service area of target RAN 14b, an inter-core hand-off may be required due to the fact that RANs 14 are coupled to different IP core networks 12. An inter-core hand-off may also be required when there are no links between RANs 14 or RANs 14 communicate using different frequency bands. Although target IP core network 12b is depicted including only target MCF 28b and target BPGW 36b, core networks 12 may include similar network architectures. IP core networks 12 may communicate with each other, for example, using an IP network coupling IP core networks 12.

[0023] Mobile unit 22 has moved out of the service area of source BTS 20a and into the service area of target BTS 20b, and the mobile call in which mobile unit 22 is participating has been handed-off from source IP core network 12a to target IP core network 12b. Prior to the inter-core hand-off, signaling traffic associated with mobile unit 22 was communicated between source RAN 14a and SS7 network 16 using source RNCS 24a, source MCF 28a, CA 30, MGC 32, and SS7 gateway 34. Bearer traffic associated with mobile unit 22 was communicated between mobile unit 22 and PSTN 18 using source BTS 20a, source SDU 26a, source BPGW 36a, and PSTN gateway 38. After the inter-core hand-off, the signaling path 40 between source MCF 28a and SS7 network 16 is unchanged, traversing source MCF 28a, CA 30, MGC 32, and SS7 gateway 34. On the other hand, certain segments of signaling path 40 and bearer path 42 have changed as a result of the hand-off. Specifically, signaling traffic associated with mobile unit 22 is no longer communicated using source RNCS 24a. Signaling traffic associated with mobile unit 22 is instead communicated using target RNCS 24b and target MCF 28b, before reaching source MCF 28a or mobile unit 22. Moreover, bearer traffic associated with mobile unit 22 is no longer communicated using source BTS 20a and source SDU 26a. Instead, bearer traffic associated with mobile unit 22 traverses target BTS 20b, target SDU 26b, and target BPGW 36b before reaching source BPGW 36a or mobile unit 22.

[0024] FIG. 3 illustrates an exemplary method for performing a hand-off between two IP core networks. The method starts at step 100, where source RNCS 24a determines that an inter-core hand-off should be performed. As described above, an inter-core hand-off may be performed when mobile unit 22 enters the service area of target RAN 14b, which is coupled to target IP core network 12b. Source RNCS 24a may determine whether an inter-core hand-off should be performed in any suitable manner. For example, as mobile unit 22 approaches the service area of target BTS 20b, mobile unit 22 may communicate a pilot strength measurement message to source RNCS 24a identifying target BTS 20b. Source RNCS 24a may then access an internal database to determine whether target BTS 20b is coupled to RAN 14a. In FIG. 3, target BTS 20b is coupled to target RAN 14b, which is coupled to target IP core network 12b. Accordingly, source RNCS 24a determines that an inter-core hand-off should be performed between source IP core network 12a and target IP core network 12b, and the method proceeds to step 102, where source RNCS 24a communicates a “hand-off required” message to a source MCF 28a identifying mobile unit 22 and target BTS 20b. Source MCF 28a then determines the IP address of target MCF 28b at step 104 using the ID of target BTS 20b. After locating target MCF 28b, source MCF 28a communicates, at step 106, a SIP “invite” message to target MCF 28b containing the ID of target BTS 20b. As described above, source MCF 28a may communicate with target MCF 28b, for example, using an IP network coupling source IP core network 12a and target IP core network 12b.

[0025] Target MCF 28b receives the SIP invite message and, at step 108, determines the IP address of target RNCS 24b using the ID of target BTS 20b. Target MCF 28b may make this determination by, for example, accessing an internal database containing information about RNCSs 24 within target RAN 14b or an external server containing similar information. After locating target RNCS 24b, target MCF 28b opens two ports of target BPGW 36b for bearer path 42 at step 110. One port is opened for communication with source BPGW 36a, and the other port is opened for communication with target SDU 26b within target RAN 14b. Target MCF 28b then, at step 112, communicates a hand-off request to target RNCS 24b identifying the IP address of target BPGW 36b and the port thereof opened for communication with target SDU 26b. Target RNC 24b receives the request and, at step 114, locates target SDU 26b for communicating bearer traffic between target BTS 20b and target BPGW 36b, specifically identifying the ID and IP address of target SDU 26b and the port thereof for communication with target BPGW 36b. Target RNCS 24b then communicates a hand-off request to target BTS 20b at step 116. This request may be communicated in any appropriate manner. For example, target RNCS 24b may communicate the request to target BTS 20B via target SDU 26b providing a link to target BTS 20b. After receiving the hand-off request, target BTS 20b communicates null traffic frames at step 118 to mobile unit 22. Target BTS 20b then communicates a hand-off request acknowledgement to target RNCS 24b at step 120 along with information about the allocated channel between target BTS 20b and mobile unit 22. Target RNCS 24b receives the acknowledgement and, at step 122, communicates the acknowledgement to target MCF 28b along with the IP address of target SDU 26b, the port of SDU 26b for communication with BPGW 36b, and information about the allocated channel between target BTS 20b and mobile unit 22.

[0026] The method then proceeds to step 124, where target MCF 28b communicates a “trying” message to source MCF 28a. Source MCF 28a and target MCF 28b then set up bearer path 42 between target SDU 26b and source BPGW 36a at step 126. The port of source bearer path gateway 36a previously used for communication with source SDU 26a is modified by source MCF 28a for communication with target BPGW 36b. Source MCF 28a may make this modification to bearer path 42 by providing source BPGW 36a the IP address of BPGW 36b, the port of target BPGW 36b for communication with source BPGW 36A, and information about the bearer traffic associated with mobile unit 22. In this way, MCF 28a sets up bearer path 42 between source BPGW 36a and target BPGW 36b. Target MCF 28b sets up bearer path 42 between target BPGW 36b and target SDU 26b by communicating to target BPGW 36b the IP address of target SDU 26b and the port thereof for communication with target BPGW 36b. Source MCF 28a and target MCF 28b may set up these segments of bearer path 42 substantially simultaneously or sequentially in any order without departing from the intended scope of the present invention. After bearer path 42 between target SDU 26B and source BPGW 36a has been set up, source MCF 28a communicates a hand-off command to mobile unit 22 via source RNCS 24a, source SDU 26a, and source BTS 20a at steps 128–134.

[0027] The method then proceeds to step 136, where, after receiving the hand-off command, mobile unit 22 communicates to target BTS 20b reverse traffic channel frames along with a “hand-off” complete message indicating that mobile unit 22 has acquired the forward channels communicated at step 118. Source RNCS 24a then communicates a “hand-off complete” message to source MCF 28a at step 138, and target BTS 20b communicates a “mobile unit acquired” message to target RNCS 24B at step 140. Steps 138 and 140 may occur substantially simultaneously or sequentially in any order without departing from the intended scope of the present invention. After receiving the “mobile unit acquired” message, target RNCS 24b communicates a “hand-off complete” message to target MCF 28b at step 142. Target MCF 28b then communicates, at step 144, an “OK” message to source MCF 28a. The method then proceeds to step 146, where source MCF 28a communicates an acknowledgement to target MCF 28b terminating the hand-off, and the method ends.

[0028] Although the present invention has been described with one embodiment, divers changes, variations, alterations, transformations, and modifications may be suggested to a person of skill in the art, and it is intended that the present invention encompass such changes, variations, alterations, transformations, and modifications as fall within the spirit and scope of appended claims.