SG1-WG1 (Radio Network Evolution and Spectrum (RNES))

1 TSDSI-SG1-WG1-SI13-WI1-V0.3.0-20170421

3 Work Item Report

7 SG1 (Wireless Systems)

8 SG1-WG1 (Radio Network Evolution and Spectrum (RNES))

10 WI1(SI13) (Open X2 interface specification development)

12 <>

16 1

2 1

1 Contents 2 3

3 1

1 1. References Content of Reference section 1 in SI13-WI1 Report (TSDSI- 2 WI1-SWIP292-[SI13]-V1.0.0-20170414) - 3 http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP- 4 Reference-Section.docx

5 1.1 TSDSI 6 [1].X2 interface specification development (TSDSI-SG1-WI1-[SI13]-V1.0.0-20160616)- 7 http://tsdsi.org/media/Report/2016-01-19/TSDSI-SG1-WG1-SI13-V0.2.0-20151103.docx 8 [2].Content of Definitions, Abbreviations and Acronyms section 2 in SI13-WI1 Report (TSDSI- 9 WI1-SWIP282-[SI13]-V1.0.0-20170414) - http://tsdsi.org/media/SWIP/2017-04-14/SI13- 10 WI1-SWIP-Definitions-Section.docx 11 [3].Content of User Plane Aspect section 4.5 in SI13-WI1 Report (TSDSI-WI1-SWIP283- 12 [SI13]-V1.0.0-20170414) - http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP-User- 13 Plane-Aspect-Section.docx 14 [4].Content of Overview of X2 section 4.2 in SI13-WI1 Report (TSDSI-WI1-SWIP284-[SI13]- 15 V1.0.0-20170414) - http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP-Overview 16 %20of%20X2-Section.docx 17 [5].Content of Scope section 3 in SI13-WI1 Report (Content of Scope section 3 in SI13-WI1 18 Report) - http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP-Scope-Section.docx 19 [6].Content of Overview of S1 section 4.1 in SI13-WI1 Report (TSDSI-WI1-SWIP286-[SI13]- 20 V1.0.0-20170414) - http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP-Overview 21 %20of%20S1-Section.docx 22 [7].Content of Overview of S1-Lite/Supporting non-X2 compliant equipment section 4.4 in 23 SI13-WI1 Report (TSDSI-WI1-SWIP287-[SI13]-V1.0.0-20170414) - 24 http://tsdsi.org/admin/track/swip/287/ 25 [8].Content of Reference section 1 in SI13-WI1 Report (TSDSI-WI1-SWIP292-[SI13]-V1.0.0- 26 20170414) - http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP-Reference- 27 Section.docx << Four SWIPs are not showing on the website. But were 28 discussed in FCC, 21 April 2017>>

29 1.2 External 30 [9]. 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

31 [10]. 3GPP TS 36.401: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); 32 Architecture description". 33 [11]. 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 application 34 protocol (S1-AP)". 35 [12]. 3GPP TS 36.420: “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 36 general aspects and principles”

4 1

1 [13]. 3GPP TS 36.421: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 layer 2 1".

3 [14]. 3GPP TS 36.422: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 4 signaling transport".

5 [15]. 3GPP TS 36.423: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 6 application protocol (X2AP)".

7 [16]. 3GPP TS 36.424: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 data 8 transport".

9 [17]. IETF RFC 4960 (2007-09): "Stream Control Transmission Protocol".

10 [18]. 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA), Evolved Universal 11 Terrestrial Radio Access Network (E-UTRAN)".

12 2. Definitions, abbreviations and acronyms Content of Definitions, 13 Abbreviations and Acronyms section 2 in SI13-WI1 Report (TSDSI- 14 WI1-SWIP282-[SI13]-V1.0.0-20170414) - 15 http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP- 16 Definitions-Section.docx

17 2.1 Definitions 18 For the purposes of the present document, the terms and definitions given in TR 21.905 3GPP 19 TR 21.905: "Vocabulary for 3GPP Specifications". and the following apply. A term defined 20 in the present document takes precedence over the definition of the same term, if any, in 21 TR 21.905 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".. 22 Dual Connectivity: Defined in TS 36.300 3GPP TS 36.300: "Evolved Universal Terrestrial 23 Radio Access (E-UTRA), Evolved Universal Terrestrial Radio Access Network (E- 24 UTRAN)"..

25 2.2 Abbreviations 26 For the purposes of the present document, the abbreviations given in TR 21.905 3GPP TR 27 21.905: "Vocabulary for 3GPP Specifications". and the following apply. An abbreviation 28 defined in the present document takes precedence over the definition of the same abbreviation, if 29 any, in TR 21.905 3GPP TR 21.905: "Vocabulary for 3GPP Specifications"..

30 2.3 Acronyms 31 <>

5 1

1 3. Scope Content of Scope section 3 in SI13-WI1 Report (Content of Scope 2 section 3 in SI13-WI1 Report) - http://tsdsi.org/media/SWIP/2017- 3 04-14/SI13-WI1-SWIP-Scope-Section.docx 4 The present document defines interface that will enable two eNodeB each from different 5 vendors, to interoperate without complying with X2 interface specifications 3GPP TS 36.420: 6 “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 general aspects 7 and principles”-3GPP TS 36.424: "Evolved Universal Terrestrial Radio Access Network 8 (E-UTRAN); X2 data transport". with interface and application protocol speeds comparable to 9 X2 interface and also a way forward for telecom operators to realize interoperability in a phased 10 manner. It is an interface for the interconnection of two E-UTRAN NodeB (eNB) components 11 within the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) architecture (TS 12 36.401 3GPP TS 36.401: "Evolved Universal Terrestrial Radio Access Network (E- 13 UTRAN); Architecture description".).

14 3.1 Intended Audiences 15 Following are the intended audiences: 16 1. TSDSI Members 17 2. Others 18 a. SSOs and SDOs 19 b. Vendors 20 c. Operators 21 d. Academia 22 e. R&D Centers 23 f. Manufacturers 24

25 3.2 Abstract 26 X2 interface is abstractly defined in 3GPP specifications 3GPP TS 36.420: “Evolved 27 Universal Terrestrial Radio Access Network (E-UTRAN); X2 general aspects and 28 principles”-3GPP TS 36.424: "Evolved Universal Terrestrial Radio Access Network (E- 29 UTRAN); X2 data transport". and this poses a big interoperability problem for inter vendor 30 eNB. When considered under the HETNET scenario the interoperability issue becomes even 31 severe. To overcome the interoperability issue in E-UTRAN network, a new architecture is 32 proposed in E-UTRAN network which will place a local MME called as MME-Lite (Placing 33 certain latency critical functions of central MME) in eNodeB to communicate with other eNodeB 34 via S1-Flex interface (S1-Lite AP). This architecture does not alter the MME functionalities, 35 S1-interface and X2-interface as defined in the 3GPP specifications 3GPP TS 36.420: 36 “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 general aspects 37 and principles”-3GPP TS 36.424: "Evolved Universal Terrestrial Radio Access Network 38 (E-UTRAN); X2 data transport".. Efforts are made to be fully compliant to and not alter any 39 of the 3GPP specifications.

6 1

1 3.3 Purpose 2 To overcome the X2 interoperability issue in E-UTRAN network. 3 For this a new architecture is proposed in E-UTRAN network which will place a local MME 4 called as MME-Lite (placing certain latency critical functions of central MME) in eNodeB to 5 communicate with other eNodeB via S1-Flex interface ( in this case it is S1-Lite AP). 6 In HetNet scenario, this document will also introduce an intermediate and short-term approach 7 that will enable operators to deploy purely S1 based equipment and then to seamlessly migrate 8 their equipment in phases to combination of S1 and X2 interfaces. This would mean that there 9 are three phases: 10 1) Only S1-interface based equipment 11 2) Equipment with S1-interface and S1-Lite interface. (See Section 4.3) 12 3) Equipment with S1-interface and X2 interface 13 Phase ‘2’ allows operators to open their network to new vendors without worrying about 14 interoperability issue between multiple vendors. Phase ‘2’ also allows seamless migration from 15 phase ‘1’ to phase ‘3’

16 4. Architecture 17 As per the current 3GPP standards currently two interfaces are used to perform handover 18 between E-UTRAN. 19  S1- provides the signaling service between E-UTRAN and the evolved packet core (EPC) 20  X2- used to handle the UE mobility within E-UTRAN 21 We propose intermediate or third interface-types, S1-Lite interface. 22 Though, the explanation has been provided with a handover scenario involving source and target 23 eNodeB, it can be expanded to include other uses of X2 interface, such as ICIC, SON, Cloud 24 RAN, etc. X2 interface is extensively used to help in information exchange between eNodeB for 25 ICIC, SON, Cloud RAN, etc. 26

27 4.1 Overview of S1 Content of Overview of S1 section 4.1 in SI13-WI1 Report 28 (TSDSI-WI1-SWIP286-[SI13]-V1.0.0-20170414) - 29 http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP-Overview 30 %20of%20S1-Section.docx 31 The E-UTRAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer 32 (TNL). The E-UTRAN architecture, i.e. the E-UTRAN logical nodes and interfaces between 33 them, are defined as part of the RNL. 34 The E-UTRAN architecture consists of a set of eNBs connected to the EPC through the S1 35 interface. The overall LTE architecture and E-UTRAN architecture are described in 3GPP TS 36 36.401 3GPP TS 36.401: "Evolved Universal Terrestrial Radio Access Network (E-

7 1

1 UTRAN); Architecture description".. This sub clause specifies only the architecture of the S1 2 interface, and shall not constrain the network architecture of either core or radio access networks. 3 The S1 interface is specified at the boundary between the EPC and the E-UTRAN. 4 The E-UTRAN may thus have several S1 access points towards the EPC. As a minimum, each 5 S1access point (in E-UTRAN or EPC) shall independently fulfill the requirements of the relevant 6 S1 specifications (3GPP 36.41x series - see clause 7). 7 S1 is a logical interface. 8 There may be multiple S1-MME logical interfaces towards the EPC from any one eNB. The 9 selection of the S1-MME interface is then determined by the NAS Node Selection function as 10 described in clause 5 (3GPP 36.41x series – clause 5) . 11 There may be multiple S1-U logical interfaces towards the EPC from any one eNB. The 12 selection of the S1-U interface is done within the EPC and signaled to the eNB by the MME. 13 The radio network signaling over S1 consists of the S1 Application Part (S1AP). The S1AP 14 protocol consists of mechanisms to handle all procedures between the EPC and E-UTRAN. It is 15 also capable of conveying messages transparently between the EPC and the UE without 16 interpretation or processing by the E-UTRAN. 17 Over the S1 interface the S1AP protocol is, e.g., used to: 18 - Facilitate a set of general E-UTRAN procedures from the EPC such as paging-notification as 19 defined by the notification Service Access Point (SAP). 20 - Separate each User Equipment (UE) on the protocol level for mobile specific signalling 21 management as defined by the dedicated SAP. 22 - Transfer of transparent non-access signalling as defined in the dedicated SAP. 23 - Request of various types of E-RABs through the dedicated SAP.

24 - Perform the mobility function

25 4.2 Overview of X2 Content of Overview of X2 section 4.2 in SI13-WI1 Report 26 (TSDSI-WI1-SWIP284-[SI13]-V1.0.0-20170414) - 27 http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP-Overview 28 %20of%20X2-Section.docx 29 The interface allowing interconnecting eNBs with each other is referred to as the X2 interface. 30 The X2 interface provides capability to support radio interface mobility and Dual Connectivity 31 between eNBs, of UEs having a connection with E-UTRAN. 32 The list of functions on the X2 interface is the following: 33 - Intra LTE-Access-System Mobility Support for ECM-CONNECTED UE: 34 - Context transfer from source eNB to target eNB; 35 - Control of user plane transport bearers between source eNB and target eNB; 36 - Handover cancellation; 37 - UE context release in source eNB; 8 1

1 - Dual Connectivity. 2 - Load Management 3 - Inter-cell Interference Coordination 4 - Uplink Interference Load Management; 5 - Downlink interference avoidance. 6 - General X2 management and error handling functions: 7 - Error indication; 8 - Reset. 9 - Application level data exchange between eNBs 10 - Trace functions 11 - Data exchange for self-optimisation

12 Compliance to X2 specification will allow operators to deploy eNodeB from different vendors. 13 However, different operators have different implementation of X2 and so there is interoperability 14 issue. S1-Lite is an alternative to X2 as explained in section 4.3.

15 4.3 Overview of S1-Lite/Supporting non-X2 compliant equipment Content of 16 Overview of S1-Lite/Supporting non-X2 compliant equipment section 4.4 17 in SI13-WI1 Report (TSDSI-WI1-SWIP287-[SI13]-V1.0.0-20170414) - 18 http://tsdsi.org/admin/track/swip/287/ 19 The new interface, called S1-Lite, allows operators to deploy new or non-incumbent eNodeB. If 20 incumbent eNodeB does not support standards-compliant X2, S1-Lite interface will allow 21 latency critical functions of both S1-AP and X2-AP. 22 The operators will have three phases of deployment: 23 1. Only S1 (and no X2) 24 2. S1-Lite and with S1 (and no X2) (note: S1-Lite interface can evolve gradually towards 25 X2 once all vendors support X2-interoperability as specified in 3GPP or can remain as it is) 26 3. Both X2 and S1 (note: When all vendors support X2-interoperability as specified in 27 3GPP, then phase 2 can be replaced or evolved towards this phase.) 28 29 <>

32 4.4 Relationship between S1, X2 and S1-Lite 33 If one observes closely S1 functions encompasses X2 functions. Those functions which are 34 common to S1 and X2 improve performance when data exchange depends on two eNodeB, 35 particularly of two different vendors, that are close or in adjacent cells. Such common functions 36 are identified as S1-Lite and abstracted as MME-Lite and configured within each eNodeB that 37 needs to interoperate with adjacent but non-X2 compliant eNodeB. Configuring such MME-Lite 9 1

1 is simple as each eNodeB has protocol stacks related to S1-AP and also because all such 2 abstractions, e.g. MME-Lite and other MMEs, can be grouped into a pool and thereby making 3 inter-vendor-eNodeB-interoperation possible. 4 Current state of X2 is as follows: 5  X2 implemented partially in eNodeB 6  X2 was not implemented in eNodeB 7  Proprietary implementation of X2 in eNodeB 8  X2 implemented to setup the interface but proprietary implementation of hardware to do 9 handover. 10  X2 handover setup messages can be dropped using proprietary algorithms via Procedure 11 Code 11. 12  Both X2 and S1 are having similar functions 13  Handover between E-UTRAN over S1 interface is similar as handover between E- 14 UTRAN using X2 interface. 15  By comparing functions of S1 and X2 we can observe that X2 is a subset of S1

16 4.5 User plane aspect Content of User Plane Aspect section 4.5 in SI13-WI1 17 Report (TSDSI-WI1-SWIP283-[SI13]-V1.0.0-20170414) - 18 http://tsdsi.org/media/SWIP/2017-04-14/SI13-WI1-SWIP-User-Plane- 19 Aspect-Section.docx 20 An IP packet for a UE is encapsulated in an EPC-specific protocol and tunneled between the P- 21 GW and the eNodeB for transmission to the UE. Different tunneling protocols are used across 22 different interfaces. A 3GPP-specific tunneling protocol called the GPRS Tunneling Protocol 23 (GTP) is used over the core network interfaces, S1 and S5/S8. The E-UTRAN user plane 24 protocol stack consists of the Packet Data Convergence Protocol (PDCP), Radio Link Control 25 (RLC) and Medium Access Control (MAC) sub layers which are terminated in the eNodeB on 26 the network side. 27 The S1-Lite user plane interface (S1-Lite-U) is defined between the eNodeB and another 28 eNodeB. The S1-Lite-U interface provides non-guaranteed delivery of user plane PDUs between 29 the eNodeB and another eNodeB. The transport network layer is built on IP transport and GTP-U 30 is used on top of UDP/IP to carry the user plane PDUs between the eNodeB and the other 31 eNodeB. Protocol stack is same as S1-AP protocol which is defined in 3GPP TS 36.413 3GPP 32 TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 33 application protocol (S1-AP)"..

34 4.6 Control plane aspect 35 The control plane protocol function is to control the radio access bearers and the connection 36 between the UE and the network, i.e., signaling between E-UTRAN and EPC. 37 The control plane consists of protocols for control and support of the user plane functions:

10 1

1  controlling the E-UTRAN network access connections, such as attaching to and 2 detaching from E-UTRAN; 3  controlling the attributes of an established network access connection, such as activation 4 of an IP address; 5  controlling the routing path of an established network connection in order to support user 6 mobility; 7  Controlling the assignment of network resources to meet changing user demands. 8 In the control plane, the NAS protocol, which runs the MME and the UE, is used for control 9 purposes such as network attach, authentication, setting up of bearers, and mobility management. 10 All NAS messages are ciphered and integrity protected by the MME and UE. The Radio 11 Resource Control (RRC) layer in the eNodeB makes handover decisions based on neighbor cell 12 measurements sent by the UE, pages for the UEs over the air, broadcasts system information, 13 controls UE measurement reporting such as the periodicity of Channel Quality Information 14 (CQI) reports, and allocates cell-level temporary identifiers to active UEs. It also executes 15 transfer of UE context from the source eNodeB to the target eNodeB during handover and does 16 integrity protection of RRC messages. The RRC layer is responsible for the setting up and 17 maintenance of radio bearers. 18 The S1 control plane interface (S1-MME) is defined between the eNodeB and the MME. The 19 transport network layer is built on IP transport, similarly to the user plane, but for the reliable 20 transport of signaling messages SCTP is added on top of IP. The application layer signaling 21 protocol is referred to as S1-Lite-AP (S1-AP Application Protocol). Protocol stack is same as S1- 22 AP protocol which is defined in 3GPP TS 36.413 3GPP TS 36.413: "Evolved Universal 23 Terrestrial Radio Access Network (E-UTRAN); S1 application protocol (S1-AP)"..

24 5. Signaling procedures 25 <>

26 5.1 Handover procedure 27 There are three ways to place MME-lite. Following sections will show all the possible three 28 MME-lite placements.

29 5.1.1 Three ways to place MME-Lite: 30 Below three pictures show the three ways or scenarios to place MME-Lite. Below these pictures 31 we provide Handover Flow for the first scenario. Other scenarios can be similarly handled.

11 1

3 Figure 1: Scenario 1

4 6 Figure 2: Scenario 2

12 1

1 3 Figure 3: Scenario 3

4 5.1.2 S1-Lite AP Handover Flow for scenario 1

5 6 Figure 4: S1-Lite Handover Flow for scenario 1

7 5.1.3 Handover Procedure for scenario 1 8 1. Source eNodeB request UE for RRC Measurement Control message. 9 2. UE will send RRC measurement report to eNodeB 10 3. Based on the RRC measurement report the source eNodeB will request the source local 11 MME for handover via S1-MME(S1-AP) interface . 12 4. Upon the request received from source eNodeB, source local MME will request target 13 eNodeB via S1-Flex(S1-Lite AP) interface. 14 5. Target eNodeB will acknowledge to source local MME via S1-Flex( S1-Lite AP) interface.

13 1

1 6. Source local MME will issue handover command to source eNodeB via S1-Flex(S1-Lite AP) 2 interface. 3 7. After receiving the handover command from local MME, source eNodeB will send RRC 4 reconfiguration request message to UE. 5 8. Source eNodeB does the eNB Status transfer to source local MME via S1-Flex(S1-Lite AP ) 6 interface. 7 9. Upon on receiving the eNB status transfer from source eNodeB, source local MME will 8 forward the same to target eNodeB via S1-Flex(S1-Lite AP) interface. 9 10.Upon receiving the eNB Status transfer, target eNodeB will notify source local MME about 10 successful handover via S1-Flex(S1-Lite AP) interface. 11 11.After RACH Procedure UE will connect to target eNodeB. 12 12.Target eNodeB will request central MME for Path Switch Request via S1-Flex interface 13 13.Central MME will request for Modify Bearer via GTP. 14 14.Serving GW (SGW) will response for the request sent by central MME for Modify Bearer 15 via GTP. 16 15.Upon receiving response from SGW, central MME will acknowledge the Path Switch 17 Request of target eNodeB via S1-Flex interface. 18 16.Source Local MME will command source eNodeB for UE context release after successful 19 handover. 20 17.Once UE context is released by source eNodeB, it will notify source local MME. 21 18.While doing handover source eNodeB will forward user data to source local MME via S1- 22 Flex(S1-Lite AP) interface. 23 Upon receiving of user data from source eNodeB, the source local MME will forward the same 24 to target eNodeB via S1-Flex(S1-Lite AP) interface.

25 6. Radio aspects 26 <>

27 7. Backhaul aspects

28 29 <>

30 8. Summary 31 <>

14 1

1 9. Appendix 2 <>

3 10. Revision history

Version Date Released by Change Description Version 0.1.0 16th March, Champion: Vinod Kumar, Tejas SG1-WG1-MTG8 2017 Networks 20170316 Version 0.2.0 21th April, Champion: Vinod Kumar, Tejas SG1-WG1-MTG9 2017 Networks 20170421 4 5