LCS Architecture for LTE EPS

3GPP considered 5 architecture alternatives for LCS during study and selected the one explained further according to 3GPP Release 9.

In the LCS architecture, an Evolved SMLC is directly attached to the MME.

The objectives of this evolution is to support location of an IMS emergency call, avoid impacts to a location session due to an inter-eNodeB handover, make use of an Evolved and support Mobile originated location request (MO-LR) and mobile terminated location request MT-LR services.

Release 9 LCS solution introduces new interfaces in the EPC:

• SLg between the GMLC and the MME
• SLs between the E-SMLC and the MME
• Diameter-based SLh between the HSS and the HGMLC

Network Initiated Location Request (NI-LR) Architecture

The shown architecture above supports an NI-LR for emergency calls. Evolved SMLC (E-SMLC) is connected to the MME. E-SMLC is analogous to an NSS based SMLC defined for GSM which is connected to an MSC.. An SLs interface is defined in between the E-SMLC and MME and an SLg interface between the MME and GMLC.

MT-LR and MO-LR Architecture

An extension to the architecture to support an MT-LR and MO-LR is shown below.

Location Procedure between the GMLC, MME and E-SMLC

The location procedure described below supports both an NI-LR for emergency calls and an MT-LR for an external LCS client.

The GMLC sends a location request to the serving MME , If the UE is in ECM-IDLE state, the MME performs a network triggered service request in order to establish a signalling connection with the UE and assign a specific eNodeB.

The MME forwards the location request to the E-SMLC and The E-SMLC performs a positioning procedure (explained below) and returns the resulting location information (e.g. location estimate) to the MME.

The MME returns the location information to the GMLC.

Network Based Positioning Procedure

The E-SMLC sends a Positioning Request to the MME including parameters for the E-UTRAN defining the type of measurement information required. The MME sends an S1AP Location Reporting Control to the serving eNodeB for the UE and eNodeB returns an S1AP Location report to the MME carrying the CGI and any requested measurements. The MME returns the CGI and measurements to the E-SMLC.

UE Assisted and UE Based Positioning Procedure

The E-SMLC sends a Positioning Request to the MME carrying an LTE Positioning Protocol (LPP) PDU which may request specific measurements by the UE. MME forwards the LPP PDU to the serving eNodeB in an existing S1AP Downlink NAS Transport

The eNodeB forwards the LPP PDU to the UE in an existing RRC DL Information Transfer message. The UE performs any positioning measurements requested by the LPP PDU and returns measurement information and/or information concerning its capabilities or requested assistance data in an LPP PDU to the eNodeB contained in an existing RRC UL Information Transfer message.

The eNodeB forwards the LPP PDU to the MME in an existing S1AP Uplink NAS Transport message. The MME forwards the LPP PDU to the E-SMLC in a Positioning Response

source: LteWorld

LTE: E-UTRAN UE Classes

UE class determines the speed at which data can be transferred in uplink and downlink directions. For GPRS & UMTS, most of us already are aware of it. LTE have class recomendations as well. Lets have a look at 3GPP proposed UE classes for LTE.

Each radio access technology has defined specific “classes” of terminals in terms of radio capabilities. E.g. in GPRS the “multislot classes” are defined, in UMTS R’99 different dedicated bearer classes are defined and for HSDPA and HSUPA 12 & 6 physical layer categories respectively are defined.

The definition of UMTS R’99 UE classes lead to 7 DL classes and 7 UL classes for FDD out of which only 2 DL and 3 UL classes were commercially realized.

For HSDPA , out of the 12 defined categories only approx. 4 will be realized in commercial HSDPA platform products. A similar situation is likely for HSUPA as well as for the combinations of HSDPA/HSUPA.

Generally the aim to mandate certain essential functions/requirements can help to simplify the system definition as well as the realization options (e.g. mandating 20 MHz of DL reception as well as 20 MHz UL transmission bandwidth significantly reduced the E-UTRAN system complexity).

To avoid unnecessary UE mandatory features but instead defining a limited set of UE radio classes allows simplification for the interoperability testing.

Based on above, 3GPP decided to limit the combination of radio capabilities to a clearly defined subset and ensuring that a given set of parameters is supported by certain UE classes as well as networks for rapid E-UTRAN deployment. It seems unrealistic to mandate only one single UE class which always mandates the maximum capability.

In order to address the different market requirements (low end, medium and high end), the definition of the following UE classes are proposed for LTE:

Class	UL	DL
A	50 Mbps	100 Mbps
B	25 Mbps	50 Mbps
C	2 Mbps	2 Mbps

source: LteWorld

LTE Handovers - Intra E-UTRAN Handover

Intra E-UTRAN Handover is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is unchanged. In the scenario described here Serving GW is also unchanged. The presence of IP connectivity between the Serving GW and the source eNodeB, as well as between the Serving GW and the target eNodeB is assumed.

The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation signalling in E-UTRAN.

To prepare the HO, the source eNB passes all necessary information to the target eNB (e.g. E-RAB attributes and RRC context) and UE accesses the target cell via RACH following a contention-free procedure using a dedicated RACH preamble.

The HO procedure is performed without EPC involvement, i.e. preparation messages are directly exchanged between the eNBs. The figure below shows the basic handover scenario where neither MME nor Serving Gateway changes:

Detailed explanation of above scenario is below.

• The source eNB configures the UE measurement procedures according to the area restriction information. UE sends MEASUREMENT REPORT by the rules set by i.e. system information, specification etc.
• Source eNB makes decision based on MEASUREMENT REPORT and RRM information to hand off UE and issues a HANDOVER REQUEST message to the target eNB passing necessary information to prepare the HO at the target side.
• Admission Control may be performed by the target eNB dependent on the received E-RAB QoS information to increase the likelihood of a successful HO. The target eNB configures the required resources according to the received E-RAB QoS information.
• Target eNB prepares HO with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source eNB. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to the UE as an RRC message to perform the handover.
• The UE receives the RRCConnectionReconfiguration message with necessary parameters (i.e. new C-RNTI, target eNB security algorithm identifiers, and optionally dedicated RACH preamble, target eNB SIBs, etc.) and is commanded by the source eNB to perform the HO.
• The source eNB sends the SN STATUS TRANSFER message to the target eNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status preservation applies (i.e. for RLC AM).
• After receiving the RRCConnectionReconfiguration message including the mobilityControlInformation , UE performs synchronisation to target eNB and accesses the target cell via RACH.
• The target eNB responds with UL allocation and timing advance.
• UE sends the RRCConnectionReconfigurationComplete message (C-RNTI) to confirm the handover to the target eNB to indicate that the handover procedure is completed for the UE. The target eNB verifies the C-RNTI sent in the RRCConnectionReconfigurationComplete message. The target eNB can now begin sending data to the UE.
• The target eNB sends a PATH SWITCH message to MME to inform that the UE has changed cell.
• The MME sends an UPDATE USER PLANE REQUEST message to the Serving Gateway.
• The Serving Gateway switches the downlink data path to the target side. The Serving gateway sends one or more "end marker" packets on the old path to the source eNB and then can release any U-plane/TNL resources towards the source eNB.
• Serving Gateway sends an UPDATE USER PLANE RESPONSE message to MME.
• The MME confirms the PATH SWITCH message with the PATH SWITCH ACKNOWLEDGE message.
• By sending UE CONTEXT RELEASE, the target eNB informs success of HO to source eNB and triggers the release of resources by the source eNB. The target eNB sends this message after the PATH SWITCH ACKNOWLEDGE message is received from the MME.
• Upon reception of the UE CONTEXT RELEASE message, the source eNB can release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.

Source : 3GPP TS 36.300