Method and apparatus for routing a bearer path in an internet protocol multimedia subsystem based communication system

A communication system is provided that routes a bearer path of a communication session between an originating Node B and a terminating Node B via an X2 interface, bypassing an IMS core network, while continuing to route the signaling path to an IMS network, thereby allowing the IMS network to retain control of the bearer path while avoiding delay, potential for data loss and jitter to the bearer stream, and additional backhaul capacity requirements that result from routing the bearer path between the originating and terminating Node Bs via the IMS core network. In determining whether the bearer path may bypass the IMS core network, the communication system determines whether IMS core network bearer associated services are required for the communication session such that a bearer path of the call will need to be routed to the IMS core network in order to provide such services.

FIELD OF THE INVENTION

The present invention relates generally to wireless communication systems, and more specifically to bearer path routing in an Internet Protocol Multimedia Subsystem (IMS)-based communication system.

BACKGROUND OF THE INVENTION

In fourth generation communication systems such as a 3GPP LTE (Third Generation Partnership Project Long Term Evolution) system, a 3GPP2 UMB (Third Generation Partnership Project 2 Ultra Mobile Broadband) system, or a WiMAX system, real time packet data services such as Voice over Internet Protocol (VOIP) are expected to be supported using an Internet Protocol Multimedia Subsystem (IMS) core network and session aware edge/border routers (SARs). As a result, it is planned to route all bearer traffic through the IMS core network and the SARs even when there is no need for IMS core services for a call. However, the routing of all calls through the IMS core network adds delay to each call, enhances the potential for data loss and jitter to the bearer stream, and increases the backhaul capacity requirements of the system.

Therefore, a need exists for an improved method and apparatus for propagating bearer data in a fourth generation, IMS-based communication system.

DETAILED DESCRIPTION OF THE INVENTION

To address the need that exists for an improved method and apparatus for propagating bearer data in a fourth generation, IMS-based communication system, a communication system is provided that routes a bearer path of a communication session between an originating Node B and a terminating Node B via an X2 interface, bypassing an IMS core network, while continuing to route the signaling path to an IMS network, thereby allowing the IMS network to retain control of the bearer path while avoiding delay, potential for data loss and jitter to the bearer stream, and additional backhaul capacity requirements that result from routing the bearer path between the originating and terminating Node Bs via the IMS core network. In determining whether the bearer path may bypass the IMS core network, the communication system determines whether IMS core network bearer associated services are required for the communication session such that a bearer path of the call will need to be routed to the IMS core network in order to provide such services.

Generally, an embodiment of the present invention encompasses a method for routing a bearer path in a wireless communication system. The method includes receiving an invitation to a communication session between an originating mobile station M(S) and a terminating MS and determining whether Internet Protocol Multimedia Subsystem (IMS) core network bearer associated services are required for the communication session such that a bearer path of the call will need to be routed to the IMS core network in order to provide such services. The method further includes, when the communication session does not require IMS core network bearer associated services that require that a bearer path of the communication session be routed to the IMS core network, routing a bearer path over an interface between a first Node B serving the originating MS and a second Node B serving the terminating MS and, concurrent with routing the bearer path over an interface between the first Node B and the second Node B, routing a signaling path for the communication session between the first Node B and the second Node B via the IMS core network.

Another embodiment of the present invention encompasses a method for routing a bearer path in a wireless communication system. The method includes routing a bearer path via an X2 tunnel over an X2 interface between a first Node B serving an originating MS and a second Node B serving a terminating MS, determining to reroute the bearer path through an IMS core network, routing the bearer path through the IMS core network, and canceling the X2 tunnel.

Yet another embodiment of the present invention encompasses a method for handing off a bearer path in a wireless communication system. The method includes routing a bearer path of a communication session via a first tunnel in a first X2 interface between a first Node B serving an originating MS and a second Node B serving a terminating MS and routing a signaling path of the communication session between the first Node B and the second Node B via an IMS core network. The method further includes determining to handoff the terminating MS from the second Node B to a third Node B, switching the bearer path from the first tunnel to a second tunnel in a second X2 interface between the first Node B and the third Node B, and modifying an S1 interface between the third Node B and a gateway such that the signaling path, but not the bearer path, is routed over the S1 interface.

Turning now to the drawings, the present invention may be more fully described with reference toFIGS. 1-6.FIG. 1is a block diagram of a wireless communication system100in accordance with various embodiments of the present invention. Communication system100includes multiple mobile stations (MSs)102,106(two shown), for example but not limited to a cellular telephone, a radiotelephone, or a Personal Digital Assistant (PDA), personal computer (PC), or laptop computer equipped for wireless communications. In various radio technologies, a mobile station (MS) such as MSs102and106may be referred to as a user equipment (UE), a subscriber station (SS), an access terminal (AT), or the like.

Communication system100further includes multiple Radio Access Networks (RANs)110,120,130(three shown), preferably evolved Universal Terrestrial Radio Access Networks (E-UTRANs), that each provides wireless communication services to MSs, such as MSs102and106, located in a coverage area of the RANs via a respective air interface104,108, and109. Each air interface104,108,109includes a forward link that includes a pilot channel, at least one forward link traffic channel, and forward link common and dedicated signaling channels. Each air interface104,108,109further includes a reverse link that includes at least one reverse link traffic channel, reverse link common and dedicated signaling channels, and an access channel.

Each RAN110,120,130includes a respective Node B, preferably an evolved Node B (eNode B)112,122,132. Node Bs112,122, and132may communicate directly with each other via an X2 interface, such as X2 interface116between Node Bs112and122and X2 interface118between Node Bs112and132, that provides both control and user plane signaling. Communication system100further includes an Evolved Packet Core (EPC)140that includes a gateway142, preferably a Mobility Management Entity and System Architecture Evolution (MME/SAE) gateway that is coupled to each of Node Bs112,122, and132via a respective S1 interface114,124, and134. For purposes of the present description, gateway142includes an MME, a Serving Gateway (S-GW), and a Packet Data Network Gateway (P-GW); however, in other embodiments of the present invention one or more of the MME, S-GW, and P-GW may be implemented in a network entity separate from, and in communication with, the others.

In one embodiment of the present invention, both MS102and MS106may be in communication with a same RAN, such as RAN110, and a corresponding Node B, such as Node B112. In another embodiment of the present invention, each of MS102and MS106may be in communication with a different RAN, such as RANs110,120, and their respective Node Bs112and122.

Communication system100further includes an Internet Protocol Multimedia Subsystem (IMS)150and a Session Border Controller (SBC)170that each are in communication with gateway142via an Internet Protocol (IP)-based data network144. IMS150comprises an IMS core network152and multiple application servers158,160,162(three shown), such as a SIP server and multiple application servers. IMS core network152includes a Call Session Control Function (CSCF)156in communication with a Home Subscriber Server (HSS)154. Together, RANs110,120, and130, EPC140, data network144, IMS150, and SBC170collectively may be referred to as a network of communication system100.

As is known in the art, the CSCF implements one or more of a Proxy CSCF (P-CSCF), a Serving CSCF (S-CSCF), and an Interrogating CSCF (I-CSCF). The CSCF serves as a centralized routing engine, policy manager, and policy enforcement point to facilitate the delivery of multiple real-time applications using IP transport. It is application-aware and uses dynamic session information to manage network resources (feature servers, media gateways, and edge devices) and to provide advance allocation of these resources depending on the application and user context. The I-CSCF is the contact point within an operator's network for all connections destined for a user of that network, or for a roaming user currently located within that network's service area. The S-CSCF is responsible for identifying the user's service privileges, selecting access to an application server coupled to the IMS network, and providing access to those servers. The P-CSCF is the SIP signaling contact point in the IMS core network for an MS, such as MSs102and104. The P-CSCF is responsible for forwarding Session Initiation Protocol (SIP) registration messages from a subscriber's endpoint, that is, for forwarding call set-up requests and responses to the S-CSCF. P-CSCF maintains a mapping between a logical subscriber SIP Uniform Resource Identifier (URI) address and an MS IP (Internet Protocol) address and a security association for both authentication and confidentiality. Unless otherwise specified herein, the functions performed by IMS150preferably are performed by CSCF156.

Referring now toFIG. 2, a block diagram of an MS200, such as MSs102and106, is provided in accordance with an embodiment of the present invention. MS200includes a processor202, such as one or more microprocessors, microcontrollers, digital signal processors (DSPs), combinations thereof or such other devices known to those having ordinary skill in the art, which processor is configured to execute the functions described herein as being executed by MS200. MS200further includes an at least one memory device204, such as random access memory (RAM), dynamic random access memory (DRAM), and/or read only memory (ROM) or equivalents thereof, that is coupled to the processor and that maintains data and programs that may be executed by the associated processor and that allows the UE to perform all functions necessary to operate in communication system100.

Referring now toFIG. 3, a block diagram of gateway142is provided in accordance with an embodiment of the present invention. Gateway142includes a processor302, such as one or more microprocessors, microcontrollers, digital signal processors (DSPs), combinations thereof or such other devices known to those having ordinary skill in the art, which processor is configured to execute the functions described herein as being executed by the feature server. Gateway142further include an at least one memory device304that may comprise random access memory (RAM), dynamic random access memory (DRAM), and/or read only memory (ROM) or equivalents thereof, that maintain data and programs that may be executed by the associated processor and that allow the feature server to perform all functions necessary to operate in communication system100. The at least one memory device304further maintains a tunnel management table, which table includes a tunnel identifier (TEIDs) assigned by the gateway in association with each tunnel to a Node B served by the gateway and further maps logical radio channel path identifiers, that is, radio bearer identifiers (RBIDs), that identify radio paths to MSs served by the gateway, such as MSs102and106, to the TEIDs. Preferably, gateway142is implemented by processor302based on programs and data maintained by at least one memory device304.

The functionality described herein as being performed by MSs102and106and by gateway142is implemented with or in software programs and instructions stored in the respective at least one memory device204,304of the MSs and gateway and executed by a processor202,302of the MSs and gateway. One of ordinary skill in the art realizes, however, that the embodiments of the present invention alternatively may be implemented in hardware, for example, integrated circuits (ICs), application specific integrated circuits (ASICs), and the like, such as ASICs implemented in one or more of the MSs and gateway. Based on the present disclosure, one skilled in the art will be readily capable of producing and implementing such software and/or hardware without undue experimentation.

Preferably, communication system100is a 3GPP (Third Generation Partnership Project) LTE (Long Term Evolution) communication system that provides packet data communication services to subscribers serviced by the network; however, other applicable packet data systems include, but are not limited to, 3GPP2 UMB and WiMAX packet data systems and any one of a variety of wireless packet data communication systems that support multimedia packet data-based communication sessions. To ensure compatibility, radio system parameters and call processing procedures are specified by the standards, including call processing steps that are executed by an MS and a RAN or other access network serving the MS and between the RAN or other access network and associated infrastructure.

In order to avoid the data delays associated with routing a bearer path through an IMS network and to minimize the potential for data loss and jitter to a bearer stream, and further to minimize the requirements for backhaul capacity in the system, communication system100provides for a routing of bearer traffic over an X2 interface between originating and terminating Node Bs, bypassing the IMS network, when IMS core network services are not required by a communication session. Meanwhile signaling still is routed to the IMS network, thereby allowing the IMS network to maintain control over the communication session.

Referring now toFIG. 4, a signal flow diagram400is provided that depicts a routing of a bearer path between an originating MS, such as MS102, and a terminating MS, such as MS106, in accordance with an embodiment of the present invention. Signal flow diagram400begins when a first, originating MS, such as MS102, attempts to set up a communication session with a second, terminating MS, such as MS106, via IMS150. MS102initiates the communication session by conveying a first session invitation, preferably a first Session Initiation Protocol (SIP) Invite, to MS106. More particularly, originating MS102conveys402the session invitation to IMS150, and in particular the SIP server, via a first Node B serving the MS, that is, Node B112, and gateway142, which session invitation invites the terminating MS106to participate in a call. The session invitation includes a callee (calling party) identifier, such as an Internet Protocol (IP) address, associated with the calling party, that is, MS102, and a destination identifier, such as a Uniform Resource Indicator (URI), associated with the terminating party, that is, MS106.

In response to receiving the session invitation, IMS150determines a called party identifier, preferably an IP address, for MS106based on the destination identifier, stores404at least a portion of the session invitation, including the calling party identifier and the called party identifier, and conveys406a second session invitation to MS106via a second Node B serving MS106. As referred to herein, MS102, RAN110, and Node B112are on an originating side of the call and may be referred to herein an originating MS, RAN, and Node B. Similarly, MS106, and a RAN and Node B serving MS106, are on a terminating side of the call and may be referred to herein as a terminating MS, RAN, and Node B. It may be noted that in one embodiment of the present invention, MSs102and106may be served by a same RAN and Node B, that is, RAN110and Node B112, in which event RAN110and Node B112serve as both the originating and the terminating RAN and Node B. However, in another embodiment of the present invention, MSs102and106may be served by different RANs and Node Bs, for example, where MS102is served by RAN110and Node B112while MS106is served by RAN120and Node B122, in which event RAN120and Node B122are the terminating RAN and Node B.

In response to receiving the session invitation, terminating MS106generates a session description protocol (SDP) proposal. As is known in the art, an SDP proposal identifies the parties to the session and identifies the sending MS's capabilities by proposing parameters for participating in the session, for example, a session name and purpose, a type of media involved (video, audio, etc.), a format of the media, a transport protocol, and information needed to receive the media, such as addresses, ports, media formats, and the like. In response to receiving the session invitation from IMS150and when a user of terminating MS106then answers the call, MS106notifies408originating MS102that the call has been answered by conveying a SIP 200 OK message back to MS102via the terminating Node B, gateway142, IMS150, and originating Node B, which SIP 200 OK message includes the SDP proposal.

Based on the session invitation and the SDP proposal included in the SIP 200 OK message, IMS150determines410whether any IMS core network bearer associated services are needed for the call, such as PSTN termination, transcoding, CALEA, E911, three-way calling, voice mail, and packet/bit metering for billing. IMS150further obtains412routing information, such as IP addresses, of the gateways serving originating MS102and terminating MS106based on the session invitation received from MS102and the SIP 200 OK message received from MS106and/or from HSS154based on location information, such as a Node B, serving each MS and a corresponding gateway serving each Node B, which location and serving gateway information is maintained by the HSS.

When IMS150determines410that IMS core network bearer associated services are needed for the communication session such that a bearer path of the call will need to be routed to IMS core network152in order to provide such services, for example, PSTN termination, transcoding, CALEA, E911, three-way calling, voice mail, and packet/bit metering for billing, then the IMS routes the call through the IMS system in accordance with well known techniques. However, when IMS150determines that the communication session does not require IMS core network bearer associated services that require a routing of a bearer path of the communication session to IMS core network152, then communication system100optimizes the bearer path between originating MS102and terminating MS106, and more particularly between originating Node B112and terminating Node B122, by routing the bearer path directly between the originating and terminating Node Bs, bypassing IMS150. Meanwhile, the signaling path between the originating and terminating Node Bs will continue to be routed through IMS150. For example, since signaling information is still being sent to IMS core network152, IMS core network services that use signaling information only can still be supported when the bearer path bypasses IMS150, such as billing based on call hold times and call waiting indication. Thus, the delay and potential for data loss and jitter resulting from routing the bearer stream through IMS150may be avoided and the backhaul capacity requirements of the system are reduced relative to the prior art while the IMS core is able to maintain control of the call and can connect to the bearer path if a need arises.

More particularly, in response to determining that IMS core network services are not needed for the call, IMS150instructs414gateway142to determine whether user bearer paths for both the originating MS102and the terminating MS106are handled by a same gateway, by conveying a first Bearer Optimization Request to the gateway. The Bearer Optimization Request includes routing information, preferably IP addresses, for each of MS102and MS106. In response to receiving the Bearer Optimization Request, gateway142determines416whether user bearer paths for both MS102and MS106are handled by the same gateway, that is, gateway142. For example, in one embodiment of the present invention, gateway142may check the tunnel management table maintained in the at least one memory device304of the gateway to determine whether user bearer paths for both the originating and terminating Node Bs, respectively serving each of MS102and MS106, are handled by the same gateway142.

In response to determining that user bearer paths for both MS102and MS106are handled by gateway142, the gateway executes a bearer optimization process. That is, gateway142assigns a flow identifier (flow ID) to a dialogue being set up between the originating and terminating MSs102,106and conveys418a second Bearer Optimization Request to originating Node B112. The second Bearer Optimization Request includes the flow ID, a first tunnel identifier (TEID) that is associated with a pre-existing tunnel between the gateway and originating Node B112(an originating TEID), and a second TEID that is associated with a pre-existing tunnel between the gateway and the terminating Node B (terminating TEID), and routing information, such as an IP address, associated with the terminating Node B.

In response to receiving the second Bearer Optimization Request and based on the IP address associated with the terminating Node B, originating Node B112determines418whether both originating MS102and terminating MS106are under a same Node B. That is, Node B112determines whether the IP address associated with the terminating Node B matches Node B112's own IP address. In one embodiment of the present invention, where MS102and MS106are both served by a same Node B, that is Node B112, then the two IP addresses should match and, in response, originating Node B112bridges420,428logical radio channel paths of each of originating and terminating MSs102and106by linking, or bridging, logical radio channel path identifiers, that is, radio bearer identifiers (RBIDs), associated with the TEIDs of the originating and terminating Node Bs (that is, Node B112), and with each of MS102and106, thereby internally (to the Node B) bridging the bearer paths to each of MSs102and106.

If the two IP addresses do not match, then originating Node B112sets up428an X2 bearer tunnel with the terminating Node B, that is, Node B122. Preferably, originating Node B112sets up the tunnel by conveying424a request to set up an X2 bearer tunnel, preferably an X2 Create Bearer Request, to terminating Node B122via X2 interface116, which request includes the flow ID, the originating TEID, and the terminating TEID. In response to receiving the X2 bearer tunnel set up request, terminating Node B122conveys426a response to the request, preferably an X2 Create Bearer Response, that includes the flow ID and the terminating TEID. Based on the exchanged identifiers, Node Bs112and122set up428an X2 bearer tunnel for data communications between MSs102and106via X2 interface116.

Originating Node B112informs430gateway142of the X2 tunnel set up between Node Bs112and122, or the bridging of the radio channel paths within Node B112, by conveying a first Bearer Optimization Response to the gateway. In response to being informed of the set up of the X2 tunnel or the bridging of radio channel paths, gateway142informs432IMS150of the X2 tunnel set up, or the bridging of the radio channel paths, by conveying a second Bearer Optimization Response to IMS150. IMS150then acknowledges the message and confirms434being bypassed in the bearer path between Node B112and Node B122by conveying a Bearer Optimization Confirmation to gateway142.

Gateway142and each of the originating and terminating Node Bs, that is, Node Bs112and122if they are different Node Bs, then modify the existing S1 tunnels114,124between the Node Bs and the gateway to permit signaling to continue to be routed through IMS150while the bearer path is rerouted to bypass IMS150. Preferably, gateway142instructs436originating Node B112to no longer tunnel bearer data associated with a communication session between MSs102and106to the gateway (while continuing to tunnel signaling associated with the communication session to the gateway via S1 tunnel114) by conveying a first S1 Bearer Request to the Node B. In response to receiving the first S1 Bearer Request, Node B112modifies444S1 tunnel114with gateway142accordingly and confirms438the modification of the tunnel by conveying a first S1 Bearer Response back to gateway142. Similarly, gateway142instructs440the terminating Node B, such as Node B122, to no longer tunnel bearer data associated with a communication session between MSs102and106to the gateway (while continuing to tunnel signaling associated with the communication session to the gateway via S1 tunnel124) by conveying a second S1 Bearer Request to the terminating Node B. In response to receiving the S1 Bearer Request, the terminating Node B modifies444its S1 tunnel, such as S1 tunnel124, with gateway142accordingly and confirms442the modification by conveying a second S1 Bearer Response back to gateway142. Signal flow diagram400then ends.

Communication system100further provides for IMS150to reroute, to the IMS, a bearer path that is currently routed over an intra- or inter-Node B interface (bypassing IMS150) and to cancel the intra- or inter-Node B bearer path. For example, IMS150may decide to return bring back the bearer path in order to add IMS services to a communication session, such as interception services. Referring now toFIG. 5, a signal flow diagram500is provided that depicts a process whereby IMS150brings the bearer path back to the IMS in accordance with an embodiment of the present invention. Signal flow diagram500begins when an inter-Node B X2 tunnel has already been established502between an originating Node B, such as Node B112, and a terminating Node B, such as Node B122, via an intervening X2 interface, that is, X2 interface116. IMS150then determines503to reroute the bearer path through the IMS150network and initiates the rerouting of the bearer path by instructing504gateway142to cancel the X2 tunnel between originating Node B112and terminating Node B122and to reroute the bearer path back to IMS150. Preferably IMS150instructs the gateway to cancel the X2 tunnel and to reroute the bearer path back to the IMS by conveying a first Bearer Optimization Cancel message that includes the flow ID associated with the communication session between MS102and MS106.

In response to receiving the instruction to cancel the X2 tunnel from IMS150, gateway142instructs506originating Node B112to cancel the X2 tunnel by conveying, to the Node B, a second Bearer Optimization Cancel message that includes the flow ID. In conveying the second Bearer Optimization Cancel message, gateway142may just forward the first Bearer Optimization Cancel message. In response to receiving the instruction to cancel the X2 tunnel from gateway142, originating Node B112requests508of gateway142, preferably by conveying a first Update Bearer Request, that the modification of the S1 bearer tunnel between the originating Node B and the gateway be undone so that the bearer path may be rerouted to gateway142over S1 interface114, and via the gateway to IMS150. Gateway142acknowledges510receipt of the request to undo the modification of the bearer tunnel by conveying a first Update Bearer Response to Node B112, and the Node B and gateway modify512the S1 tunnel between the Node B and the gateway to tunnel the bearer path over S1 tunnel114.

Further in response to receiving the instruction to cancel the X2 tunnel from gateway142, originating Node B112requests514that terminating Node B122cancel the X2 tunnel between the originating Node B and the terminating Node B, preferably by conveying an X2 Delete Bearer Request to the terminating Node B. In response to receiving the request to cancel the X2 tunnel, terminating Node B122requests516of gateway142, preferably by conveying a second Update Bearer Request, that the modification of the S1 bearer tunnel between the terminating Node B and the gateway be undone so that the bearer path may be rerouted to gateway142over S1 interface124, and via the gateway to IMS150. Gateway142acknowledges518receipt of the request to undo the modification of the bearer tunnel by conveying a second Update Bearer Response to Node B112, and the Node B and gateway modify520the S1 tunnel between the Node B and the gateway to tunnel the bearer path over S1 interface124.

In response to the modification of the S1 bearer tunnel between terminating Node B122and gateway142, that is, to the rerouting of the bearer path over S1 interface124, terminating Node B122confirms522to originating Node B112that the X2 tunnel may be torn down by conveying an X2 Delete Bearer Response to the originating Node B. Originating Node B122and terminating Node B112then tear down524the X2 tunnel that they had set up for the communication session between originating MS102and terminating MS106. Further, in response to receiving the X2 Delete Bearer Response from terminating Node B122, originating Node B112confirms526to gateway142that the X2 tunnel has been torn down and that the bearer path is being rerouted over S1 interfaces114and124by conveying a first Bearer Optimization Confirm message to gateway142. In turn, in response to receiving the first Bearer Optimization Confirm message, gateway142informs IMS150that the bearer path has been rerouted back to the IMS by conveying a second Bearer Optimization Confirm message to IMS150. Logic flow500then ends.

By routing a bearer path between originating Node B112and terminating Node B122via X2 interface116and bypassing IMS core network152, while continuing to route the signaling path to IMS network150, communication system100avoids delay, potential for data loss and jitter to the bearer stream, and additional backhaul capacity requirements that result from routing the bearer path between the originating and terminating Node Bs via the IMS core network while allowing the IMS network to retain control of the bearer path. In order to determine whether the bearer path may bypass the IMS core network, communication system100determines whether IMS core network bearer associated services are required for the communication session such that a bearer path of the call will need to be routed to the IMS core network in order to provide such services. Communication system100then may route the bearer path over the X2 interface, bypassing the IMS core network, when the communication session does not require such IMS core network bearer associated services.

Communication system100further provides for a handoff of an inter-Node B bearer path wherein IMS150continues to be bypassed by the bearer path. Referring now toFIG. 6, a signal flow diagram600is provided that depicts a handoff of the bearer path in accordance with an embodiment of the present invention. Signal flow diagram600begins when a first, originating MS102and a second, terminating MS106are engaged in a communication session wherein bearer data is exchanged602between a first, originating Node B, such as Node B112, and a second, terminating Node B, such as Node B122, via a first X2 tunnel over a first X2 interface, such as X2 interface116. Concurrent with the bearer path being routed over the first X2 tunnel, a signaling path for the communication session is routed between Node Bs112and122via IMS150.

At some point during the communication session, terminating MS106roams to a coverage area of a target terminating Node B, such as Node B132. As a result, a decision is made to handoff the target MS106from the source terminating Node B, that is, Node B122, to the target terminating Node B, that is, Node B132. Assuming the handoff is MS-initiated, terminating MS106requests of the Node B serving the MS, that is, source terminating Node B122, that the MS be handed off to the third, target terminating Node B132by conveying a Handover Request to the source terminating Node B122. However, in other embodiments of the invention, the handoff may be network-initiated and may be based on air interface measurements made by either the MS or the network, as the basis for the handoff and the device initiating the handoff are not critical to the present invention.

In response to receiving the handover request, source terminating Node B122requests604a handoff of MS106to target terminating Node B132, preferably by conveying a Handover Request to the target terminating Node B. The Handover Request includes all relevant handoff information, such as identifiers of the MS and the target terminating Node B, a packet data convergence protocol (PDCP) context, and so on. In response to receiving the Handover Request, target terminating Node B132sets up connections to support the MS106's packet data communication session and conveys606a Handover Request ACK message back to source terminating Node B122, which message includes information for establishment of the new radio link at the target terminating Node B, such as radio channels allocated to the MS at the target terminating Node B. Source terminating Node B122then instructs MS106to move to the radio channels allocated to the MS at target terminating Node B132by conveying a Handover Command message to the MS.

Terminating MS106then tunes to the indicated radio channels at target terminating Node B132and informs source terminating Node B132of the success of the handover by conveying a Handover Confirmation message to the source terminating Node B132. Source terminating Node B forwards the Handover Confirmation message to target terminating Node B132and the target terminating Node B informs610gateway132that it has established a connection with MS106and initiates a bearer path switch by conveying a conveying a Handover Complete message to the gateway142.

As part of the handoff, the bearer path for the communication session is being switched from the first X2 interface and X2 tunnel to a second X2 tunnel over a second X2 interface118between originating Node B112and target terminating Node B132. Meanwhile the signaling path will continue to be routed though IMS150. That is, in response to being informed that target terminating Node B132has acquired terminating MS106, gateway142negotiates612a modification of an S1 bearer tunnel between the gateway and target terminating Node B132, as the bearer path for MS106will not be routed over S1 interface134between the gateway and target terminating Node B while the signaling path will be routed over the S1 interface. Gateway142conveys614a Bearer Optimization Request to originating Node B112, which Bearer Optimization Request includes a flow identifier (flow ID) associated with the communication session, a tunnel identifier (TEID) that is associated with the tunnel between the gateway and originating Node B112(an originating TEID), a TEID that is associated with a pre-existing tunnel between the gateway and target terminating Node B132(target terminating TEID), and an IP address associated with the target terminating Node B.

Originating Node B112then sets up622an X2 bearer tunnel with the target terminating Node B132. Preferably, originating Node B112sets up the tunnel by conveying616a request to set up an X2 bearer tunnel, preferably an X2 Create Bearer Request, to target terminating Node B132, which request includes the flow ID associated with the communication session, the originating TEID, and the target terminating TEID. In response to receiving the X2 bearer tunnel set up request, target terminating Node B132conveys618a response to the request, preferably an X2 Create Bearer Response, that includes the flow ID and the terminating TEID. Based on the exchanged identifiers, Node Bs112and132set up622the second X2 bearer tunnel over X2 interface118for data communications between MSs102and106. Originating Node B112then conveys data to MS106via each of the first X2 tunnel existing with source terminating Node B112and the second X2 tunnel set up with target terminating Node B132.

Originating Node B112further informs620gateway142of the X2 tunnel set up between Node Bs112and132by conveying a Bearer Optimization Response to the gateway. In response to being informed of the set up of the X2 tunnel, gateway142initiates624a switch of the bearer path from the X2 tunnel between originating Node B112and source terminating Node B122to the X2 tunnel between originating Node B112and target terminating Node B132, by conveying a Handover Complete ACK message to target terminating Node B132. In response to receiving the Handover Complete ACK message, target terminating Node B132conveys a release resource message to source terminating Node B122and the source terminating Node B flushes its downlink data buffer of any data stored for retransmissions to MS106. However, any in-transit data packets received by source terminating Node B122still are forwarded to MS106.

In response to receiving the release resource message, source terminating Node B122releases all resources allocated to MS106and instructs628originating Node B112to cancel the X2 tunnel between the originating Node B and source terminating Node B122, preferably by conveying an X2 Delete Bearer Request to the originating Node B. Originating Node B112acknowledges630receipt of the request to cancel the X2 tunnel by conveying an X2 Delete Bearer Request to source terminating Node B122, and the originating Node B and the source terminating Node B and tear down632the X2 bearer tunnel between them. Signal flow600then ends.

By providing for a handing off of a bearer path from one X2 interface to another X2 interface when a terminating MS is handed off from one terminating Node B to another terminating Node B, communication system100maintains a routing of a bearer path between originating and terminating MSs that bypasses an IMS core network even when a communication session is handed off. Meanwhile, the signaling path continues to routed to the IMS network, allowing the IMS network to retain control of the bearer path.

While the present invention has been particularly shown and described with reference to particular embodiments thereof, it will be understood by those skilled in the art that various changes may be made and equivalents substituted for elements thereof without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather then a restrictive sense, and all such changes and substitutions are intended to be included within the scope of the present invention.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims. As used herein, “conference call” and “three-way call” are interchangeable terms. Further, as used here, the terms “comprises,” “comprising,” or any 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. The terms ‘including’ and/or ‘having’, as used herein, are defined as comprising. Furthermore, unless otherwise indicated herein, the use of relational terms, if any, such as first and second, top and bottom, and the like are 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. An element preceded by “a . . . ” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus.