Optimized home evolved NodeB (eNB) handover in an LTE network

[0001] This disclosure relates generally to mobile broadband networking technologies, such as the Evolved 3GPP Packet Switched Domain that provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).

[0002] Evolved Packet Core (EPC) is the Internet Protocol (IP)-based core network defined by 3GPP in Release 8 for use by Long-Term Evolution (LTE) and other wireless network access technologies. The goal of EPC is to provide an all Internet Protocol (IP)-based core network architecture to efficiently give access to various services. In LTE, an MME (Mobility Management Entity) function provides an anchor for mobile devices (User Equipment or “UE”) as they move across the system within the geographic area covered by an MME node. EPC comprises a MME and a set of access-agnostic Gateways for routing of user datagrams. The radio access part of the LTE system is an evolved Node B (eNB). Each eNB typically comprises an antenna system, together with base station radio equipment. Moreover, in addition to a radio transmitter and a receiver, an eNB also includes resource management and logic control functions that, traditionally, were separated into base station controllers (BSCs) or radio network controllers (RNCs). By including this added capability, eNBs communicate directly with each other, thereby obviating mobile switching systems (MSCs) or controllers (BSCs or RNCs). Communications between eNBs include handover. Under the LTE standard, LTE eNB is required to implement both inter-eNB and intra-eNB handover procedure inside E-UTRAN.

[0003] A femto cell is a radio access network element that supports a limited number of simultaneous users in a home environment in a limited geographic area over one or more of the GSM/WCDMA family of radio interfaces. A 3G femto access point is called a home nodeB (HNB). A CSG (Closed Subscriber Group) is used to describe a specific group of mobile devices that are permitted access to a particular femto cell. For LTE, a logical architecture for a “home eNB” (HeNB) may be implemented. An HeNB has a set of S1 interfaces to connect the HeNB to the EPC. In this approach, the E-UTRAN architecture also may deploy a Home eNB Gateway (HeNB GW) to allow the S1 interface between the HeNB and the EPC to scale to support a large number of HeNBs.

[0004] The 3GPP specification requires that the HeNB GW relays all UE associated S1 application part messages between the HeNB and the MME. This requirement increases the amount of signaling the EPC (namely, the MME and the SGW (serving gateway)) needs to process. It would be desirable to optimize handover of a UE between the HeNBs that are connected to a same HeNB GW while reducing the amount of signaling to the EPC.

[0005] This disclosure addresses this need in the art.

[0006] This disclosure describes a method to provide an optimized intra-HeNB Gateway handover operation that reduces signaling to and from an LTE MME (Mobility Management Entity) function of the 3GPP E-UTRAN Evolved Packet core (EPC).

[0007] In operation, the HeNB Gateway (GW) intercepts handover requests from an HeNB (the “source HeNB”) and determines if the target cell is another HeNB (the “target HeNB”) that is connected to the gateway. If (i) the target HeNB is in the same tracking area (as identified by a tracking area identifier (TAI)) as the source HeNB, (ii) the target HeNB either is open or supports the CSG identifier indicated by the source, and (iii) both source and target HeNB use the HeNB GW S1-U data path interface, then the HeNB GW processes the handover procedure locally with limited interaction with the MME. If (i) the target HeNB either is open or supports the CSG identifier indicated by the source, and either (ii) the target HeNB is not in the same TAI as the source HeNB, or (iii) either source or target HeNB do not use the HeNB GW S1-U interface, then the HeNB GW still processes the handover procedure locally by converting it into an X2-based handover message to the MME. In both scenarios, messaging to and from the MME is minimized and/or reduced, irrespective of the 3GPP requirement that the GW relay all handover messages to the MME.

[0008] The foregoing has outlined some of the more pertinent features of the subject matter. These features should be construed to be merely illustrative. Many other beneficial results can be attained by applying the disclosed subject matter in a different manner or by modifying the subject matter as will be described.

[0012] The following detailed description presumes familiarity with the General Packet Radio Service (GPRS) enhancements for E-UTRAN access described in 3GPP Mobile Broadband Standard Reference Specification 3GPP TS 23.401. The LTE Intra E-UTRAN Handover, in particular, is described at 3GPP TS 36.300.

[0013] As illustrated in FIG. 1, a representative LTE network 100 in which the disclosed handover technique may be implemented comprises an MME 102, an SGW 104, a PGW 106, an HSS 108, and a set of home evolved Node Bs 110 (each an HeNB) coupled to a home evolved nodeB gateway (HeNB GW) 112. The MME 102 is the primary control node for the LTE access-network. Among other functions, the MME 102 is responsible for idle mode UE (User Equipment) tracking and paging procedure including retransmissions. The Serving Gateway (SGW) 104 routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers. The MME is responsible for choosing the SGW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. The PDN Gateway (PGW) 106 provides connectivity from the UE to external packet data networks by being the point of exit and entry of traffic for the UE. The Home Subscriber Server (HSS) 108 is a central database that contains user-related and subscription-related information. HSS 108 also provides mobility management, call and session establishment support, user authentication and access authorization.

[0014] The HeNB GW 112 provides S1-C and/or S1-U interfaces to the HeNBs 110 connected to the gateway. The HeNB GW allows the S1 interface between the HeNB and the EPC to scale to support a large number of HeNBs 110. In operation, the HeNB GW serves as a concentrator for the C-Plane, specifically the S1-MME interface. The S1-U interface from the HeNB may be terminated at the HeNB GW, or a direct logical U-Plane connection between HeNB and S-GW may be used.

[0015] An eNB is the radio access part of the LTE system. As is well-known, each eNB typically comprises at least one radio transmitter, a receiver, a control section, and a power supply. In addition, eNBs typically implement various software-based functions, such as radio resource management, access control, connection mobility management, resource scheduling, header compression, link encryption of the user data stream, packet routing of user data towards its destination (usually to the EPC or other eNBs), and measurement reporting (to assist in handover decisions).

[0016] An LTE eNB is required to implement handover procedure inside E-UTRAN. As seen in FIG. 1, intra E-UTRAN Handover is used, for example, to hand over a UE 114 from a source eNodeB 116 to a target eNodeB (not shown), typically using an X2-based handover message when the MME is unchanged. When there is no direct X interface between the source eNodeB and the target eNodeB, S1-based handover messaging sequence is used. Home eNodeB 110 based on Release 8 of the 3GPP Specification does not provide an X2 interface; therefore, S1-based handover is used. As described in the 3GPP Specification, during this handover procedure, the HeNB GW relays all messages to the MME, which is undesirable. To address this problem, a method of optimizing an intra-HeNB handover procedure is implemented by the HeNB GW, and is described below. This optimized GW handover procedure significantly reduces the amount of signaling relayed by the GW to and from the MME, thereby reducing EPC capacity requirements, reducing network bandwidth, increasing reliability, and reducing cost.

Optimized Intra-HeNB GW Handover

[0017] A preferred approach for this technique, is illustrated in FIG. 2, which is a time sequence diagram illustrating a first embodiment of this disclosure for reducing MME signaling during an intra-HeNB handover procedure. In this embodiment, the source HeNB 200 and the target HeNB 202 are co-located within a same tracking area (as identified by a tracking area identifier, or TAI), and both are coupled to the HeNB GW 204 and use the S1-U interface of the HeNB GW. The GW is coupled to the MME 206 over the S1-C interface and to the SGW (not shown) over the S1-U interface. To enable the handover signalizing optimization of this disclosure, preferably the HeNB GW stores data needed during the establishment of the signaling path among the UE (not shown), HeNB GW 204 and the MME 206. This information includes, without limitation, a handover restriction list, security parameters, UE radio access capability data, and the like.

[0018] As illustrated in FIG. 2, the handover procedure begins at step 1, with the source HeNB 200 issuing to the GW 204 a Handover Required message. At step 2, the GW 204 sends a Path Switch Request message to the MME 206, which, in response, returns a Path Switch Request Ack message in step 3. At step 4, the GW 204 issues a Handover Request message to the target HeNB 202, which responds back to the GW 204 at step 5 with a Handover Request Ack message. At step 6, the GW 204 issues a Handover command message to the source HeNB 200, which responds back to the GW 204 at step 7 with an eNB Status Transfer message. At step 8, the GW 204 issues an eBN Status Transfer message to the target HeNB 202, which responds back to the GW 204 at step 9 with a Handover Notify message. At step 10, the GW 204 issues a UE Context Release Command to the source HeNB 200. The source HeNB 200 responds back to the GW 204 at step 11 with a UE Context Release Complete message. This completes the typical handover sequence.

[0019] In the absence of the optimization technique disclosed herein, the GW 204 (to ensure 3GPP compliance) relays (to/from the MME) each of the signaling messages in steps 1 and 4-11. Such operations are obviated according to the embodiment described by having the HeNB GW 204 determine that the Handover Required message (in step 1) can be processed “locally”—i.e., without the necessity of having to relay all messages to and from the MME. According to this first embodiment, this determination (that local handover processing can be effected) is made when the following conditions are all met: (i) the target HeNB 202 is in the same tracking area (as identified by a tracking area identifier (TAI)) as the source HeNB 200, (ii) the target HeNB 202 either is open or supports the CSG identifier indicated by the source 200, and (iii) both source and target HeNB use the HeNB GW S1-U interface. In such case, and according to this disclosure, the HeNB GW 204 processes the handover procedure locally, i.e., with limited interaction with the MME. In this particular embodiment, as illustrated in FIG. 2, this limited interaction is merely the sending of the Path Switch Request message (step 2), and the receipt of the Path Switch Request Ack message (step 3). While these messages are conventional, one of ordinary skill in the art will appreciate that the messages themselves are being used here in a manner that differs from their typical use. In other words, according to this disclosure, these standardized messages, in effect, are re-purposed to facilitate the localized handover procedure. In this example scenario, the purpose of steps 2 and 3 is to ensure synchronization of security keys between the UE and the source and target HeNBs.

[0020] This alternative use of these standardized messages is a preferred implementation, but not a requirement, as other alternative solutions may be used. Thus, for example, one variant is to enhance an S1 message, or to define a new message, instead of reusing the Path Switch Request. In another variant, the Handover Required (step 1) and Handover Request (step 4) messages can be enhanced to pass (to the target HeNB 202) a current HeNB used by the source HeNB 200. In yet another variant to this approach, the MME 204 may be programmed to supply more than one Security Context when the UE context is established on a HeNB via the HeNB GW. These latter options eliminate the necessity of using steps 2 and 3 in FIG. 2, thereby further reducing the impact to the MME.

[0021] FIG. 3 is a time sequence diagram illustrating a second embodiment of this disclosure for reducing MME signaling during an intra-HeNB GW handover procedure wherein the source and target HeNBs are located in different tracking areas. In this embodiment, both of the source and target HeNBs are coupled to the HeNB GW 304; further, the target HeNB 302 either is open or supports the CSG id indicated by the source HeNB 300. Either or both of the following conditions differ from the first embodiment (namely, FIG. 2): the source HeNB 300 and the target HeNB 302 are not located within a same tracking area, or, at most, one of them (but not both) uses the S1-U interface of the HeNB GW. Once again, and as in the FIG. 2 embodiment, the GW 304 is coupled to the MME 306 over the S1-C interface and to the SGW (not shown) over the S1-U interface. Once again, and to enable the handover signalizing optimization of this disclosure, preferably the HeNB GW 304 stores data needed during the establishment of the signaling path among the UE (not shown), HeNB GW 304 and the MME 306.

[0022] As illustrated in FIG. 3, the handover procedure in this embodiment begins at step 1, with the source HeNB 300 issuing to the GW 304 a Handover Required message. At step 2, the GW 304 issues a Handover Request message to the target HeNB 302, which responds back to the GW 304 at step 3 with a Handover Request Ack message. At step 4, the GW 304 issues a Handover Command message to the source HeNB 300, which responds back to the GW 304 at step 5 with an eNB Status Transfer message. At step 6, the GW 304 issues an eBN Status Transfer message to the target HeNB 302, which responds back to the GW 304 at step 7 with a Handover Notify message. At step 8, the GW 304 sends a Path Switch Request message to the MME 306, which, in response, returns a Path Switch Request Ack message in step 9. At step 10, the GW 304 issues a UE Context Release Command to the source HeNB 300. The source HeNB 300 responds back to the GW 304 at step 11 with a UE Context Release Complete message. This completes the typical handover sequence.

[0023] As contrasted with the FIG. 2 embodiment, in the FIG. 3 embodiment the Path Switch Request (step 8) and Path Switch Request Ack messages (step 9) are used in their conventional manner. Primarily, these messages are used in this embodiment to ensure that the UE and the MME remain in synchronization, and to pass location information.

[0024] According to the FIG. 3 embodiment, the HeNB GW also performs “local” processing of the handover. The determination that local handover processing can be carried out, however, is made when the following conditions are all met: (i) the target HeNB 302 either is open or supports the CSG identifier indicated by the source HeNB 300, and either (ii) the target HeNB 302 is not in the same TAI as the source HeNB 300, or (iii) either source or target HeNB do not use the HeNB GW S1-U interface. When these conditions are met, the HeNB GW processes the handover procedure locally, preferably by converting it into an X2-based handover message to the MME. While the MME messaging (steps 8-9) is required here, the technique still meets the goal of reducing the amount of messaging sent to and from the MME, as messages 1-7 and 10-11 need not traverse the GW to/from the MME.

[0025] Thus, in the FIG. 3 embodiment as well, messaging to and from the MME is reduced, irrespective of the 3GPP requirement that the GW relay all handover messages to the MME.

[0026] Preferably, the HeNB GW is implemented as hardware, namely one or more processors, computer memory, and software executed by the processors to perform the functions described above. Thus, the functions illustrated in FIGS. 2 and 3 preferably are implemented as software, e.g., processor-executed program instructions, in each of the machines as needed to implement the above-described operations. Each machine comprises associated data structures and utilities (e.g., communication routines, database routines, and the like) as needed to facilitate the communication, control and storage functions.

[0027] An HeNB GW that provides the functionality described herein is implemented in a machine comprising hardware and software systems. The described handover functionality may be practiced, typically in software, on one or more such machines. Generalizing, a machine typically comprises commodity hardware and software, storage (e.g., disks, disk arrays, and the like) and memory (RAM, ROM, and the like). The particular machines used in the network are not a limitation. A given machine includes the described network interfaces (including, without limitation, the S1-C, S1-U and other interfaces) and software to connect the machine to other components in the radio access network in the usual manner. More generally, the techniques described herein are provided using a set of one or more computing-related entities (systems, machines, processes, programs, libraries, functions, or the like) that together facilitate or provide the inventive functionality described above. In a typical implementation, the HeNB-GW comprises one or more computers. A representative machine comprises commodity hardware, an operating system, an application runtime environment, and a set of applications or processes and associated data, that provide the functionality of a given system or subsystem. As described, the functionality may be implemented in a standalone node, or across a distributed set of machines.

[0028] The handover technique may be implemented by other nodes in the network, such as HeNB nodes, the MME itself, or the like.

[0029] There is no requirement that the specific handover messaging protocol described above in FIG. 2 or FIG. 3 be implemented, provided that the GW can determine that the Handover Required message can be processed locally.

[0030] Having described our invention, what we now claim is set forth below: