DESC:CROSS REFERENCE TO RELATED PATENT APPLICATIONS
[0001] This patent application is related to and claims the benefit of priority from the Indian Provisional Patent Application with Serial No. 4679/CHE/2015 titled “AN INTERFACE FOR MULTI VENDOR eNodeB HANDOVER”, filed on September 04, 2105, the contents of which are incorporated in entirety by the way of reference.

A) TECHNICAL FIELD
[0002] The present disclosure relates to Long Tem Evolution (LTE). Particularly, the present disclosure relates to an Evolved Universal Terrestrial Access Network (E-UTRAN). More particularly, the present disclosure relates to an optimized interface that enables communication between a source eNodeB and a target eNodeB.

B) BACKGROUND
[0003] Intra E-UTRAN handover is typically used to handover a User Equipment (UE) from a source eNodeB to a target eNodeB using an X2 interface. When a source eNodeB decides to handover the user equipment, it generates a ‘HANDOVER REQUEST’ message to the target eNodeB, thereby passing information necessary for preparing for a handover at the target side. Subsequently, the target eNodeB prepares for a handover and sends a ‘HANDOVER REQUEST ACKNOWLEDGE’ message to the source eNodeB. The ‘HANDOVER REQUEST ACKNOWLEDGE’ message typically includes a transparent container to be sent to the user equipment as a Radio Resource Control (RRC) message, to perform the handover. However, if the source eNodeB and the target eNodeB are from different vendors, then they would be unable to communicate with one another using an X2 application protocol (X2-AP) for initiating a handover, inter-alia. However, in such a case, the source eNodeB will have to use an S1 application protocol (S1-AP) to communicate with the target eNodeB, for initiating a handover, inter-alia. However, in a multivendor EUTRAN network, X2 protocol might not have been implemented in an eNodeB. Otherwise, an eNodeB can implement either partially or in a proprietary manner. Therefore, there was felt a need for a communication system that provides enhanced eNodeB connectivity in a multi vendor E-UTRAN network.

C) OBJECTS
[0004] An object of the present disclosure is to provide a system that solves the problem of interoperability between multi vendor eNodeB.
[0005] Yet another object of the present disclosure is to provide a system that optimizes an S1 interface for enabling communication between multi vendor eNodeB.
[0006] Still a further object of the present disclosure is to provide a system that provides for enhanced eNodeB connectivity in a multi vendor E-UTRAN network.
[0007] One more object of the present disclosure is to provide a system that enables low latency handover within a multi vendor E-UTRAN network.
[0008] Another objective of the present disclosure is to provide a system that provides for load balancing between eNodeBs of a multi vendor E-UTRAN network.
[0009] Yet another object of the present disclosure is to provide a system that provides multi vendor interoperability.

D) SUMMARY
[0010] The present disclosure envisages a network communication system that enables communication in a multi vendor E-UTRAN network. The present disclosure envisages a new communication interface between eNodeB for handover procedure, which would resolve multi vendor interoperability issues within a self-organized network. The present disclosure envisages placing a local Mobility management entity (MME) in every eNodeB, thereby ensuring that the handover can be performed at a lower cost and lower latency using S1 Lite application protocol.
[0011] In accordance with the present disclosure, predetermined critical functionalities of a central Mobility management entity (MME) are included in another local MME (referred to as Local MME-Lite). Typically, the central Mobility management entity and the Local MME-Lite are in the same pool. Alternatively, the critical functionalities of the central Mobility management entity can be included in either a source eNodeB or a target eNodeB. Alternatively, the critical functionalities of the central Mobility management entity can be included in both source eNodeB as well as the target eNodeB.
[0012] The system envisaged by the present disclosure includes an E-UTRAN network comprising a source eNodeB and a target eNodeB. The source eNodeB attempts to set up an X2 interface for communication with the target eNodeB. In the event that the source eNodeB and target eNodeB are from different vendors, the request for setting up an X2 interface fails, and subsequently, the source eNodeB requests a local MME-Lite to set up an interface between local MME-Lite and target eNodeB. In accordance with the present disclosure, certain critical functions of a central MME are incorporated into the local MME Lite. The incorporated functions include but are not restricted to functions related to load balancing, handover and failure notification.
[0013] In accordance with the present disclosure, since the local MME-Lite and the central MME are in the same pool, the target eNodeB is enabled to communicate with local MME Lite using optimized S1 Lite application protocol, over an S1-Flex interface. Subsequently, the local MME Lite establishes an S1-Flex interface with the target eNodeB using S1-Lite application protocol. Subsequent to setting up of the S1 Lite application protocol over the S1-Flex interface, the local MME-Lite informs the source eNodeB about the S1-Flex interface. To perform the handover to the target eNodeB, the source eNodeB transmits the handover request to the target eNodeB via local MME-Lite. Since S1-Flex interface is neither restricted nor proprietary, target eNodeB allows the handover request of source eNodeB. Subsequent to target eNodeB accepting the handover request, the source eNodeB performs the handover with the target eNodeB over the S1-Flex interface, using S1-Lite application protocol.

E) BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
[0014] The other objects, features and advantages will be apparent to those skilled in the art from the following description of the preferred embodiment and the accompanying drawings in which:
[0015] FIG.1 is a block diagrams illustrating a prior art E-UTRAN network;
[0016] FIG.2 is a block diagram illustrating a E-UTRAN network, in accordance with the present disclosure; and
[0017] FIG. 3A and 3B in combination represent a flow chart illustrating the steps involved in the method for performing a handover of a User Equipment (UE) from a source eNodeB to a target eNodeB.

F) DETAILED DESCRIPTION
[0018] The present disclosure envisages a network communication system that enables communication in a multi vendor E-UTRAN network. In contrary to the prior art interfaces exemplified in FIG.1, wherein multi vendor eNodeB is not achieved, the present disclosure envisages a new communication interface between eNodeBs for handover procedure, which would resolve multi vendor interoperability issues within a self-organized network. The present disclosure envisages placing a local Mobility management entity (MME) in every eNodeB , i.e., a source eNodeB as well as a target eNodeB, thereby ensuring that the handover can be performed at a lower cost and lower latency using S1 Lite application protocol.
[0019] In accordance with the present disclosure, certain critical functionalities of a central Mobility management entity (MME) are included in another local MME (referred to as Local MME-Lite). Typically, the central Mobility Management Entity (central MME) and the Local MME-Lite are in the same pool. Referring to FIG.2, there is shown an E-UTRAN network 100 comprising a source eNodeB 10 and a target eNodeB 12. The source eNodeB 10 attempts to set up an X2 interface for communication with the target eNodeB 12. In the event that the source eNodeB 10 and target eNodeB are from different vendors, the request for setting up an X2 interface fails, and subsequently, the source eNodeB 10 requests a local MME-Lite 14 to set up an interface between local MME-Lite 14 and target eNodeB 10. The local MME Lite 14 is installed as an intermediate entity between the source eNodeB 10 and the central MME 16. In accordance with the present disclosure, certain critical functions of a central MME 16 are incorporated into the local MME Lite 14. The incorporated functions include but are not restricted to functions related to load balancing, handover and failure notification.
[0020] In accordance with the present disclosure, since the local MME-Lite 14 and the central MME 16 are in the same pool, the target eNodeB 12 is enabled to communicate with local MME Lite 14 using an optimized S1 Lite application protocol, and through an S1-Flex interface. Subsequently, the local MME Lite 14 establishes an S1-Flex interface (also referred to as S1-Lite AP interface) with the target eNodeB using S1-Lite application protocol. Subsequent to setting up of the S1 Lite application protocol over the S1-Flex interface, the local MME-Lite 14 informs the source eNodeB 10 about the S1-Flex interface. To perform the handover to the target eNodeB 12, the source eNodeB 10 transmits the handover request to the target eNodeB 12 via local MME-Lite 14. Since S1-Flex interface is neither restricted nor proprietary, target eNodeB 12 allows the handover request of source eNodeB 10. Subsequent to target eNodeB 12 accepting the handover request, the source eNodeB 10 performs the handover with the target eNodeB 12 over the S1-Flex interface, using S1-Lite application protocol.
[0021] Referring to FIG.3A and FIG.3B in combination, there is shown a flowchart illustrating the steps involved in the method for performing a handover of a User Equipment (UE) from a source eNodeB to a target eNodeB. The method in accordance with the present disclosure is initiated with the source eNodeB requesting the User Equipment for a Radio Resource Control (RRC) measurement message (step 300). The User Equipment responds to the source eNodeB with the RRC measurement message at step 302. Further, at step 304, based on the RRC measurement message, the source eNodeB requests the local Mobility Management Entity (MME) for a handover via an S1-AP interface. At step 306, the source local MME requests the target eNodeB for the handover via an S1-Lite AP interface. Typically, the S1-Lite AP interface is an optimized version of the S1-AP interface.
[0022] Further, the target eNodeB acknowledges the source local MME via S1-Lite AP interface at step 308. Further, at step 310, the source local MME issues a handover command to the source eNodeB via the S1-Lite AP interface. Subsequent to receiving the handover command from the local MME, the source eNodeB generates and transmits an RRC reconfiguration request message to the User Equipment at step 312. Subsequent to generating the RRC reconfiguration request message, the source eNodeB transmits an eNodeB status transfer message to the source local MME via the S1-Lite AP interface (step 314).
[0023] At step 316, the source local MME forwards the eNodeB status transfer message (received from the source eNodeB) to the target eNodeB via the S1-Lite AP interface. Subsequently, at step 318, the target eNodeB notifies the source local MME about a successful handover of the User equipment. The notification of the successful handover is transmitted via the S1-Lite AP interface to the source local MME. At step 320, after going through a contention-free RACH process, the User Equipment connects to the target eNodeB. Soon after the establishment of connection between the target eNodeB and the User Equipment, the target eNodeB request the central MME for a path switch. The path switch request is typically transmitted via the S1-Lite AP interface (step 322).
[0024] Subsequently, the central MME transmits a modify bearer request to a Serving Gateway (SGW) through GPRS Tunneling Protocol (GTP), and subsequent to receiving a response from the serving gateway, the central MME acknowledges the path switch request received from the target eNodeB (step 324). The acknowledgement of the path switch request is typically communicated over the S1-Lite AP interface. At step 326, the source local MME instructs the source eNodeB to release the User Equipment (UE) context, post the completion of eNodeB handover. Subsequently, at step 328, the user data is transmitted from the source eNodeB to the source local MME via the S1-Lite AP interface, and the source local MME further transmits the user data to the target eNodeB over the S1-Lite AP interface.

G) TECHNICAL ADVANTAGES
[0025] The technical advantages of the present disclosure include the realization of an interface that solves the problem of interoperability between multi vendor eNodeB. The interface optimizes an S1 interface for enabling communication between multi vendor eNodeB. The interface provides for enhanced eNodeB connectivity in a multi vendor E-UTRAN network. The interface enables low latency handover within a multi vendor E-UTRAN network. The interface also provides for load balancing between eNodeBs of a multi vendor E-UTRAN network. ,CLAIMS:1. A system for facilitating eNodeB handover in a multi-vendor communication network, said system comprising:
a source eNodeB and a target eNodeB, wherein said source eNodeB generates a handover request for configuration of a communication interface with said target eNodeB, and wherein said source eNodeB redirects said handover request in the event that a communication interface is not configured between said source eNodeB and target eNodeB;
a source MME-Lite (Mobility Management Entity-Lite) cooperating with said source eNodeB and configured to receive redirected handover request from said source eNodeB, said source MME-Lite further configured to establish a S1-flex interface for communication between the source MME-Lite and the target eNodeB; and
wherein said source MME-Lite communicates with the target eNodeB using an S1-Lite application protocol, and wherein the source eNodeB transmits the redirected handover request to the target eNodeB through said source MME-Lite and using said S1-flex interface.
2. The communication interface as claimed in claim 1, wherein said source eNodeB generates a handover request based on a Radio Resource Control (RRC) report received from a User Equipment communicably coupled thereto.
3. The communication interface as claimed in claim 1, wherein said source MME Lite is configured to issue a handover command to the source eNodeB, subsequent to receiving an acknowledgement of the redirected handover request from the target eNodeB.
4. A method for performing a handover of a User Equipment (UE) from a source eNodeB to a target eNodeB, said method comprising the following steps:
requesting for a Radio Resource Control (RRC) measurement message from the User Equipment;
receiving the RRC measurement message from the User Equipment and analyzing the RRC measurement message at the source eNodeB;
generating a handover request at the source eNodeB and routing said handover request through a source Mobility Management Entity Lite (MME-Lite) communicably coupled to the source eNodeB;
configuring said source MME-Lite to transmit said handover request to the target eNodeB, via an S1-flex interface;
receiving an acknowledgment of the handover request from said target eNodeB via said S1-flex interface;
causing said source MME-Lite to issue a handover command subsequent to receiving the acknowledgement;
transmitting said handover command to the source eNodeB, and causing said source eNodeB to respond to said handover command by the way of transmitting an eNodeB status transfer message to the target eNodeB via said source MME-Lite; and
generating a handover confirm message at the target eNodeB, and notifying said source MME-Lite of a successful handover of the User Equipment from source eNodeB to Target eNodeB.
5. The method as claimed in claim 4, wherein the step of generating a handover confirm message at the target eNodeB, further includes the step of generating a handover confirm message at the target eNodeB, only in the event that a status transfer message is sent from the source eNodeB to the target eNodeB.