scribd-download.com_lte-e2e-part2.pdf

LTE End to End System Part 2 - Technology

© Nokia Siemens Networks

1 (126)


Legal notice Intellectual Property Rights All copyrights and intellectual property rights for Nokia Siemens Networks training documentation, product documentation and slide presentation material, all of which are forthwith known as Nokia Siemens Networks training material, are the exclusive property of Nokia Siemens Networks. Nokia Siemens Networks owns the rights to copying, modification, translation, adaptation or derivatives including any improvements or developments. Nokia Siemens Networks has the sole right to copy, distribute, amend, modify, develop, license, sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individuals can use the Nokia Siemens Networks training material for their own personal self-development only, those same individuals cannot subsequently pass on that same Intellectual Property to others without the prior written agreement of Nokia Siemens Networks. The Nokia Siemens Networks training material cannot be used outside of an agreed Nokia Siemens Networks training session for development of groups without the prior written agreement of Nokia Siemens Networks. Indemnity The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products are given “as is” and all liability arising in connection with such hardware or software products shall be defined conclusively in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in the document as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY MONETARY LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT This document and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright © Nokia Siemens Networks 2012. All rights reserved.


2 (126)


Table of Contents: 1

2

3 4

5

6

LTE / SAE Architecture ...................................................................................... 6 1.1 Main Benefits of LTE (1) ............................................................................ 7 1.2 Main Benefits of LTE (2) ............................................................................ 8 1.3 LTE End-to-End Technology and Procedures ............................................ 9 Radio Network Planning – Introduction ............................................................ 11 2.1 Spectrum Allocation ................................................................................. 11 2.2 Spectrum Refarming ................................................................................ 12 2.3 Planning Process ..................................................................................... 13 2.4 General Planning Principles ..................................................................... 17 2.5 LTE Deployment Scenarios ..................................................................... 18 2.6 Exercise ................................................................................................... 19 2.7 Automatic Neighbor Relation (ANR) Function (RL30) .............................. 20 2.8 ANR – LTE Intra-Frequency (RL30) ......................................................... 21 2.9 ANR – Inter-RAT (RL30) .......................................................................... 22 2.10 ANR – Inter-RAT (RL30) .......................................................................... 24 Voice Evolution ................................................................................................ 26 3.1 Voice Evolution ........................................................................................ 26 3.2 IMS emergency sessions (RL30) ............................................................. 27 Interoperability between LTE and 2G/3G/3GPP2............................................. 29 4.1 Interoperability – Introduction ................................................................... 29 4.2 Interworking with 2G/3G Networks ........................................................... 30 4.3 Common Core Concept ........................................................................... 31 4.4 CS Fallback ............................................................................................. 31 4.5 CS Fallback to UTRAN (RL40)................................................................. 33 4.6 Single Radio Voice Call Continuity (RL40) ............................................... 35 4.7 SRVCC to WCDMA (RL40) ...................................................................... 36 4.8 SRVCC to GSM (RL40) ........................................................................... 38 4.9 Emergency Call Handling......................................................................... 39 Transport Solutions ......................................................................................... 41 5.1 Transport Solutions - Introduction ............................................................ 41 5.2 Evolution towards Flat Network Architecture ............................................ 42 5.3 Transport Network for S1-U Interface....................................................... 43 5.4 Carrier Ethernet Transport ....................................................................... 43 5.5 Carrier Ethernet Transport (RL30) ........................................................... 45 5.6 IP Transport Network Measurement (RL30) ............................................. 46 5.7 Pseudo Wire Solutions ............................................................................. 47 5.8 Flexi Transport Sub-module FTIB (RL10 onwards) .................................. 48 5.9 Flexi Transport Sub-module FTIF (RL40)................................................. 49 5.10 Traffic Differentiation (RL10 onwards) ...................................................... 50 5.11 Synchronisation over Packet Networks .................................................... 52 5.12 Synchronisation Hub ................................................................................ 53 5.13 IP Layer Addressing (RL10 onwards)....................................................... 54 5.14 Ethernet OAM .......................................................................................... 55 5.15 QoS-aware Ethernet Switching ................................................................ 56 5.16 Ethernet Jumbo Frames........................................................................... 57 5.17 Multi-Operator Core Network ................................................................... 58 5.18 FlexiPacket Radio Connectivity ................................................................ 59 Security Solutions ............................................................................................ 61 6.1 Introduction .............................................................................................. 61 6.2 EPS AKA Key Hierarchy .......................................................................... 61 6.3 Key Management during Inter-eNB Handover.......................................... 62 © Nokia Siemens Networks

3 (126)


6.4 EPS AKA Signalling ................................................................................. 64 6.5 Confidentiality and Integrity Protection ..................................................... 65 6.6 Exercise ................................................................................................... 67 6.7 Lawful Interception ................................................................................... 68 6.8 LTE Firewall Support ............................................................................... 68 6.9 LTE Certificate Management ................................................................... 69 6.10 LTE User Account Management .............................................................. 70 6.11 LTE User Event Log Management ........................................................... 71 6.12 LTE IPsec Support ................................................................................... 72 6.13 LTE O&M Transport Security ................................................................... 73 6.14 Certificate Management for iOMS (RL40) ................................................ 75 6.15 Crypto Agent (RL40) ................................................................................ 77 6.16 SW Verification Agent (RL40) .................................................................. 78 6.17 Local Link Layer Security (RL40) ............................................................. 79 7 QoS Solutions ................................................................................................. 81 7.1 Introduction (RL20 onwards) .................................................................... 81 7.2 EPS Bearer Concept................................................................................ 82 7.3 EPS QoS Profile Structure ....................................................................... 83 7.4 QoS Control in the EPS (RL 09 and RL10) .............................................. 84 7.5 QoS Control in the EPS (RL20 onwards) ................................................. 85 7.6 Rate Capping in UL and DL (RL20 onwards) ........................................... 86 7.7 Support of UE-AMBR Modification (RL20 onwards) ................................. 87 7.8 Support of Multiple EPS Bearers (RL20 onwards) ................................... 88 7.9 Multiple GBR EPS Bearers per UE .......................................................... 89 7.10 EPS Bearers for Conversational Voice (RL20 onwards)........................... 90 7.11 Service Differentiation for Non-GBR EPS Bearer (RL20 onwards) ........... 91 7.12 Operator specific QCI (RL30) ................................................................... 92 7.13 Support of QCI 2, 3 and 4 (RL40) ............................................................ 93 7.14 Smart Admission Control (RL40).............................................................. 95 7.15 ARP Based Admission Control for E-RABs (RL40) .................................. 96 7.16 E-RAB Modification (RL40) ...................................................................... 97 7.17 Policy and Charging Control .................................................................... 98 7.18 PCC Signalling during LTE Attach ......................................................... 100 7.19 QoS Management Example 1 ................................................................ 101 7.20 QoS Management Example 2 (RL20 onwards) ...................................... 104 7.21 Exercise ................................................................................................. 105 7.22 Commercial Mobile Alert System (RL40) ............................................... 106 7.23 ETWS Broadcast (RL40)........................................................................ 107 8 LTE Charging Architecture ............................................................................ 109 8.1 Offline Charging ..................................................................................... 109 8.2 Online Charging ..................................................................................... 111 9 Location Solutions ......................................................................................... 113 9.1 Support of Cell Based Location Service (RL30) ..................................... 113 9.2 OTDOA .................................................................................................. 114 10 Subscriber Data Management ....................................................................... 116 10.1 Subscriber Data Management ............................................................... 116 11 Network Management.................................................................................... 117 11.1 Overview ................................................................................................ 117 11.2 Self-Organising Network (SON) Solutions .............................................. 118 11.3 Hybrid SON Concept ............................................................................. 119 11.4 PRACH management (RL30) ................................................................. 120 11.5 Automatic interface alarm correlation (RL30) ......................................... 121 11.6 LTE Timing Advance Evaluation ............................................................ 122 © Nokia Siemens Networks

4 (126)


11.7 Configurable cell trace content ............................................................... 123 12 Configuration Management............................................................................ 125 12.1 System Upgrade with Backward Compatibility ....................................... 125


5 (126)


1

LTE / SAE Architecture

UTRAN Long Term Evolution (LTE) refers to the long term evolution of the 3GPP radio access technology and is considered the successor of the current UMTS system. The LTE work in 3GPP is closely aligned to the 3GPP system architecture evolution (SAE) framework which is concerned with the evolved core network architecture. The LTE/SAE framework defines the flat, scalable, IP-based architecture of the Evolved Packet System (EPS) consisting of a radio access network part (Evolved UTRAN) and the Evolved Packet Core (EPC). Note that the Evolved Packet System is purely packet based. Voice transport is thus based on Voice over IP (VoIP) technology. Circuit-switched (CS) voice traffic is supported by using the CS fallback (CSFB) solution. Voice call continuity between the packet-switched and circuit-switched domain is enabled by the single radio voice call continuity (SR-VCC) interworking solution. Move your mouse pointer over the items in the architecture figure for a short introduction to each item.

The LTE radio interface (air interface, LTE-Uu) is between the user equipment (UE) and the eNB.


6 (126)


The evolved Node B (eNodeB, eNB) supports the LTE radio interface and provides similar packet-switched functionality as a traditional radio network controller (RNC). As a result, the Evolved UTRAN does not require a separate RNC network element, in other words the architecture is “flat” (architecture contains fewer types of network entities and interfaces). The X2 interface between two eNB network elements carries signalling and user plane traffic during an inter-eNB handover. The S1-MME interface carries control plane signalling information between the eNodeB and Mobility Management Entity. The S1-U interface between the eNodeB and Serving Gateway carries the user plane data over a so-called GTP tunnel. The S4 interface between the S-GW and SGSN provides a GTP tunnel for the user plane during inter-system mobility. The S3 interface carries signalling between the MME and Serving GPRS Support Node (SGSN) located in a 2G/3G packet-switched core network. In the case of a pre3GPP Rel-8 SGSN, the Gn interface is used instead. The S11 interface carries signalling messages between the Serving Gateway and the Mobility Management Entity. The S6a interface is used for transferring subscription and authentication data between the Home Subscriber Server (HSS) and MME. The SGi interface is between the PDN Gateway and the packet data network (PDN). The packet data network may be an operator-external public or private IP network, or an IP network belonging to the operator, for instance providing IP Multimedia Subsystem (IMS) services. The Serving Gateway (S-GW) and PDN Gateway (P-GW) provide the user plane connectivity between the access network and the external packet data network (PDN). The P-GW also includes GGSN functionality.

In the Nokia Siemens Networks LTE solution, it is possible to implement these functional entities either within a single node or as separate nodes. The Mobility Management Entity (MME) provides the basic control plane functionality in the Evolved Packet Core network. Note that user plane traffic does not go through the MME. Legacy Gn/Gp interface connectivity to the EPS is also supported.

1.1 Main Benefits of LTE (1) LTE technology offers the following benefits: • LTE offers peak data rates of 150 Mbit/s in downlink (assuming 2 x 2 MIMO spatial multiplexing and 20 MHz channel bandwidth) and 50 Mbit/s in uplink, thus supporting UE category 4 devices as defined in 3GPP TS 36.306. © Nokia Siemens Networks

7 (126)


• LTE enables round trip times (RTT) of less than 10 ms. The round trip time or user plane latency is the time it takes for information to travel from the mobile terminal to the server in the network and back to the terminal. • Also the control plane latency - the time needed to allocate transport resources - is important. The requirement for the control plane latency in LTE is less than 100 ms. • Contrary to HSPA, LTE offers packet scheduling in the frequency domain in addition to packet scheduling in the time domain. This feature greatly increases the spectrum efficiency of LTE. • The LTE capacity or spectrum efficiency is two to four times higher than that of a 3GPP Release 6 HSPA system.

1.2 Main Benefits of LTE (2) A major advantage of LTE over WCDMA or HSPA is the possibility of allocating spectrum bandwidths of varying size to the mobile users. LTE offers several channel bandwidth values between 1.4 and 20 MHz. By contrast, the channel bandwidth in WCDMA or HSPA is always fixed at 5 MHz. A small channel bandwidth allows easier spectrum refarming and is beneficial for mobile operators short on spectrum. On the other hand, a large channel bandwidth is required if large peak data rates are to be supported.


8 (126)


1.3 LTE End-to-End Technology and Procedures In LTE End to End System Part 1, we looked into LTE procedures such as mobility management procedures in the ECM-IDLE state, connection management procedures, and mobility management procedures in the ECM-CONNECTED state, also known as handovers. In this course, LTE End to End System Part 2, we will turn our attention to various supporting technologies and solutions needed for achieving a complete functioning end-to-end system. Topics in the course include: · User plane transport, including the new Carrier Ethernet Transport options and synchronisation · Security solutions such as authentication and encryption of user and control data · Quality of Service (QoS) solutions · A new concept called policy and charging control (PCC) · Charging solutions


9 (126)


· Interoperability between LTE and 2G/3G or 3GPP2 systems, including concepts such as CS fallback and SRVCC · Network management · Radio network planning · Subscriber data management.


10 (126)


2

Radio Network Planning – Introduction

LTE radio network planning is quite similar to HSPA network planning. There are several evolution paths towards LTE as shown in the figure. LTE networks are likely to be deployed by existing 2G/3G and TD-SCDMA operators. These operators will be re-using existing sites, providing large benefits in terms of lower capital expenditure (CAPEX). Note that TD-SCDMA operators will be interested in the time division duplex (TDD) version of LTE, or TD-LTE. Note also that Internet-HSPA (I-HSPA) paves the path towards LTE by introducing a flat network architecture. Also greenfield operators may be interested in deploying LTE networks, but such operators are naturally not able to re-use existing sites.

2.1 Spectrum Allocation LTE can be allocated in various frequency bands between 700 and 2600 MHz. As you can see from the figure, separate frequency bands are available in the Americas, in Japan, and in other parts of the world.


11 (126)


The most likely frequency bands to be allocated during the first phase of LTE are as follows: · In the Americas the 1700/2100 MHz and 700 MHz bands · In Japan the 2100 MHz, 1500 MHz and 800 MHz bands · In Europe and Asia the 2600 MHz, 1800 MHz and 900 MHz bands.

2.2 Spectrum Refarming The figure illustrates the idea of spectrum refarming, an important concept related to LTE network planning. In fact, spectrum refarming was already employed during the deployment of UMTS networks. This is shown at the top of the figure where a number of GSM channels with 200 kHz bandwidth are replaced by a single UMTS channel with a nominal bandwidth of 5 MHz. Since the GSM and UMTS equipment is co-located in the BTS, inter-channel interference calculations reveal that it is possible to squeeze the UMTS channel into a bandwidth of 4.2 MHz, which corresponds to 21 GSM channels. The lower parts of the figure show similar GSM-to-LTE spectrum refarming examples where the LTE channel bandwidth is 1.4, 3 and 5 MHz, respectively.


12 (126)


2.3 Planning Process The radio planning process basically consists of four steps. Dimensioning means computing the number of sites required to serve a certain area while fulfilling the coverage and capacity requirements. The next step is to create a nominal plan using a planning tool like Atoll or NetAct Planner. Next, a detailed coverage and capacity analysis is performed, again using a suitable planning tool. The last part of the planning process is pre-launch optimisation, which can also be done as part of the cluster acceptance process. Move your mouse pointer over the steps in the planning process for more details. Note that LTE networks are likely to be deployed by existing network operators. These operators will be re-using existing sites, so the eNodeB site selection does not start from scratch.


13 (126)



14 (126)



15 (126)



16 (126)


2.4 General Planning Principles When planning LTE radio networks, it should be taken into account that the modulation and coding scheme has a considerable influence on the cell coverage and capacity as illustrated in the figure. For instance, 64 Quadrature Amplitude Modulation (QAM) with a coding ratio of 5/6 provides large capacity but small coverage. At the other extreme, Quadrature Phase Shift Keying (QPSK) provides large coverage but low capacity. In a frequency-re-use-factor-of-1 scenario it is important to control the interference in the network. Consequently, the dimensioning and planning tools should be able to calculate not only the signal attenuation due to propagation effects but also the signal-to-interference-plus-noise ratio (SINR) distribution in the network. Furthermore, the network load should be taken into account in order to obtain realistic uplink and downlink SINR, throughput and coverage values. Let our tutor show how prudent planning can decrease the level of interference in the network and thus increase the network capacity.


17 (126)


2.5 LTE Deployment Scenarios There are basically three LTE deployment scenarios: Macrocells, microcells and indoor solutions. Macrocells - the standard deployment solution - provide outdoor coverage across wide areas. Microcells and indoor cells can be added to expand the capacity and coverage of the radio network at specific locations. Microcells can be used to provide coverage at traffic hotspots or where macrocell sites are not available. A microcell can be categorised as an eNodeB that has an outdoor, below-rooftop antenna placement. The isolation provided by neighbouring buildings limits both the coverage and the inter-cell interference. Modelling of microcells is a relatively complex task, involving two- or threedimensional building data (so-called building vectors). The propagation modelling is usually based on ray tracing methods. Indoor solutions provide high capacity and improve coverage in locations where indoor macrocell coverage is weak. The eNodeB can be connected to a passive distributed antenna system (DAS) in indoor areas of small or moderate size, or to an active distributed antenna system in large indoor areas. Repeaters can be used for extending outdoor coverage into indoor areas.


18 (126)


2.6 Exercise


19 (126)


2.7 Automatic Neighbor Relation (ANR) Function (RL30) In an LTE network, the mobility of a user device needs information about the neighboring cells so that the handover decision is possible. Each eNode B keeps track of neighboring cells and their configurations. This information has been traditionally managed manually by the operator, but the automatic neighbor relation (ANR) function makes the neighbor relation management automatic. The ANR function implements the discovery and integration of unknown cells to its neighbor relation table (NRT). The ANR consists of: · NRT management function and · neighbor detection and removal functions

The NRT management function interacts with the NetAct system to send NR reports and receive NR updates. A neighbor cell relation in this context means that the eNode B: · has an entry in the NRT for the target cell · knows the ECGI and PCI identifiers, and · has the attributes set for it

The attributes are 'no remove', 'no handover', and 'no X2'. If 'no remove' is checked, the eNode B will not remove the entry from the NRT. If 'no handover' is checked, the entry will not be used by the eNode B for handovers. If 'no X2' is checked, the eNode B will not use the X2 interface towards that eNode B. Note that the X2 link is bi-directional and between eNode Bs, while the neighbor relation is between cells and is unidirectional.


20 (126)


2.8 ANR – LTE Intra-Frequency (RL30) This feature covers the automated neighbor relation (ANR) in the case of an intrafrequency LTE configuration. At a handover situation, the mobile device reports all the detected cells above a given threshold. Therefore it may report cells that are currently unknown to the Flexi BTS. In this case, the Flexi BTS may send a measurement request to the mobile device to report the E-UTRAN Cell Global Identifier (ECGI) of the unknown cell ID. Then the Flexi BTS resolves the IP address of the previously unknown cell by using the ECGI identifier. After this it can establish an X2 connection. On the X2 application layer the Flexi BTS exchanges a list of cells served and other configuration parameters, with the new neighbor. There may be cases when the Flexi BTS cannot establish an X2 link, these are: · if the maximum number of X2 connections have been reached, or · if the target is in the operator's blacklist for X2 connection

When the new neighbor is successfully stored in the local configuration, the Flexi BTS sends a configuration change notification to NetAct to inform the operator.


21 (126)


In order to reduce the probability of a call drop when the first handover is made to a newly detected neighbor cell, the Flexi BTS supports active ANR-mechanism. The active ANR pro-actively scans for other cells and optimizes the performance before any handover situation, while the passive ANR waits for normal handover measurement reports to detect new neighbors.

2.9 ANR – Inter-RAT (RL30) This feature covers the automated neighbor relation (ANR) in the case of inter-radioaccess-technology (inter-RAT) configuration. In this case, the neighbor relations will be handled by the NetAct – not by eNode B as is the case with intra-LTE. Automated inter-RAT neighbor relations will provide a solid base for interworking as soon as the network is setup or extended. NetAct will upload or retrieve configuration data, relevant for the inter-RAT neighbor relations, from any existing 2G or 3G network configuration management database. Corresponding inter-RAT neighbor relations are then created for the Flexi BTS in question. The relation takes into account: the location and distance of the source and target cell antennas, and sectorization or antenna horizontal main lobe direction of source and target cells © Nokia Siemens Networks

22 (126)


Information about the co-location of source and target cells is derived from NetAct Optimizer, but has effect only if an intra-site neighbor relation is created – regardless of any other user settings. The relevant parameters for inter-RAT neighbor relations are provisioned by NetAct in the case of a co-existing Nokia Siemens Networks legacy network. In the case of another vendor's co-existing network, the parameters are provisioned by NetAct's northbound interface.


23 (126)


2.10 ANR – Inter-RAT (RL30) The optimization of LTE neighbor cell relations is introduced in release RL30. The optimization includes NetAct Optimizer, which supervises all the registered neighboring cell relations between LTE cells. It checks that the neighbors are still valid and reliable candidates to a handover destination. The NetAct Optimizer utilizes the Flexi Multiradio BTS configuration information and performance counters including, intra- and inter-frequency handover counters, in order to perform the analysis. The evaluation results in either no action being taken, or that the neighbor relation is blacklisted. No action is taken when the handover performance is at least satisfactory. On the other hand, if the given neighbor relation was identified as being unreliable or weak – for example due to weak handover success rate – the neighbor relation is blacklisted. In this case, NetAct suggests or automatically deploys the new configuration plan with updated entries for appropriate blacklists. Note that in the case of a neighboring cell being blacklisted, any outgoing handover to the target cell is not allowed neither via X2 nor via S1 interface. The benefit to the operator is that it reduces the operating expenses due to a reduced workload in neighbor relationship management. The benefit for the end user is that the service quality is better as handovers are less likely to fail.


24 (126)



25 (126)


3

Voice Evolution

3.1 Voice Evolution An important consideration when deploying LTE networks is the fact that operators have already heavily invested in circuit-switched (CS) networks - primarily for offering CS voice services - and do not want to totally abandon this technology, at least in the short term. As a viable interworking solution, Nokia Siemens Networks offers the possibility to add VoIP application server functionality to the MSC Server in a 3GPP Release 4 network. This solution is called Nokia Siemens Networks Mobile VoIP Server (NVS). The NVS primarily functions as a VoIP application server connected to an IP Multimedia Subsystem (IMS) network via the standard 3GPP IMS Service Control (ISC) interface. This allows the operator to offer existing 2G or 3G services to VoIP clients behind the IMS. Such services are, for instance, 2G or 3G supplementary services, Intelligent Network (IN) services, mobile IN services (also known as CAMEL services), and emergency services. Also LTE users can access these CS services via the IMS and NVS. In the user plane, interworking is provided by the Mobile Media Gateway (MGW). The voice call is packet-switched towards the VoIP terminal and circuit-switched towards the terminal behind the CS network.


26 (126)


3.2 IMS emergency sessions (RL30) The LTE release RL30 enables the Flexi Multiradio BTS to support emergency sessions via IP Multimedia Subsystem (IMS). Support for an emergency session is a regulatory requirement for voice service over an LTE network. IMS emergency sessions are identified by a cause value at the establishment of an RRC connection, and by an ARP value in the EPS bearer. The Flexi Multiradio BTS allows all IMS emergency sessions until the operatorconfigured thresholds are reached. Emergency sessions will be rejected by the eNode B if: · the admission control threshold has been reached · the related QCI is not enabled · the related EPS bearer combination is not enabled

Handovers can be handled differently for emergency sessions. First, handover restriction lists are ignored. And second, separate neighbor cell lists are applied for intra- and inter-frequency, and inter-RAT handover cases.


27 (126)



28 (126)


4

Interoperability between LTE and 2G/3G/3GPP2

4.1 Interoperability – Introduction Seamless interworking between LTE and non-LTE 3GPP and 3GPP2 networks will be ensured by various means. The interworking support will include seamless cell reselection in idle mode as well as during packet transport sessions. As a result, subscribers will not notice possible discontinuities in LTE coverage. Nokia Siemens Networks’ load and service based handover features today allow the network operator to balance the system load between 2G and 3G networks in an optimal fashion. It is possible to direct voice traffic and data-centric services towards specific networks or frequency layers. Similar functionality will also enable load sharing between 2G/3G and LTE networks. Initial LTE implementations will be focusing on offering high-speed mobile broadband services. In this context the possibility of providing a common packet core for LTE and 2G/3G systems will be an important issue. Regarding voice services, it should be noted that the Evolved Packet Core cannot handle circuit-switched voice traffic. However, solutions such as CS fallback and single radio voice call continuity (SRVCC) will ensure seamless interworking also in the case of circuit-switched voice services.


29 (126)


4.2 Interworking with 2G/3G Networks LTE interworking with 2G/3G networks is required for instance during 3GPP inter radio access technology (inter-RAT) handovers. On the 2G/3G side, the Serving GPRS Support Node (SGSN) is responsible for the transfer of packet data between the Evolved Packet Core and the legacy 2G/3G radio access network (RAN). It should be noted that the functionality of the SGSN differs depending on whether it is a 3GPP release 8 node or not and whether a direct tunnel is used between the Serving Gateway and 3G RAN or not. In the case of a 3GPP release 8 SGSN, the interworking always requires the S3 signalling interface between the MME and SGSN. Obviously, there is no user data traffic over this interface. The GTP tunnel for the user data can be established either via the SGSN or directly between the Serving Gateway and 3G RAN. In the former case, the S4 interface is necessary for handling both the GTP-related signalling and the user plane traffic. In the latter case, the S12 interface provides the direct GTP tunnel, whereas the SGSN is still needed for establishing this tunnel. If the SGSN is not 3GPP release 8 compatible, interworking can be supported by providing the Gn interface between the SGSN and the MME (instead of the S3 interface) and between the SGSN and the PDN Gateway (instead of the Serving Gateway).


30 (126)


4.3 Common Core Concept As far as mobile broadband services are concerned, it is possible to implement a common packet core, provided there exists the S4 interface between SGSN and Serving Gateway network entities. The common core offers optimised interworking between LTE and non-LTE 3GPP access networks. This concept provides similar handling for LTE and 2G/3G bearers, as well as a common interface towards the Home Subscriber Server (HSS). Moreover, the common core enables a common QoS solution for LTE and non-LTE systems, for instance employing the Policy and Charging Rules Function (PCRF) which will be introduced later in this course.

4.4 CS Fallback Regarding voice services, it could be that first-generation LTE terminals will support neither VoIP nor circuit-switched voice, and voice services will continue to be handled separately by the 2G/3G network. However, multi-mode LTE terminals will eventually become available. These will support both LTE packet services and circuit-switched voice, but not necessarily VoIP. These terminals can be simultaneously attached to LTE and 2G/3G radio networks.


31 (126)


When the user initiates a voice call, the call is transferred to the 2G/3G network. When the user receives a voice call, the paging takes place via the LTE network, after which the terminal is transferred from the LTE to the 2G/3G radio network before the call is set up. This is called CS fallback. CS fallback requires modifications to the Evolved Packet Core and the 2G/3G circuitswitched core network to support the enhanced signalling over the new SGs interface between the MME and MSC Server. The CS fallback procedure is being standardised in 3GPP Release 8 in Technical Specification 23.272.


32 (126)


4.5 CS Fallback to UTRAN (RL40) From LTE release RL40 onwards the Flexi Multiradio BTS supports circuit-switched (CS) fallback to UTRAN – for multimode devices with according UE capabilities – using the packet switched (PS) handover mechanism. Previously, CS fallback to UTRAN was supported using the RRC connection release with redirection mechanism. A major benefit of CS fallback is that the CS core network investments can be reused during the initial phase of LTE. As far as packet switched handover based CS fallback is concerned, this mechanism shows better performance than redirection based CS fallback. The following CS fallback scenarios are supported: • Mobile originated CS fallback where the UE is in RRC IDLE mode • Mobile originated CS fallback where the UE is in RRC CONNECTED mode • Mobile terminated CS fallback where the UE is in RRC IDLE mode • Mobile terminated CS fallback where the UE is in RRC CONNECTED mode. Note that the operator can configure neighbor cells to be considered for inter radio access technology (IRAT) measurements to support either “normal” CS fallback or “emergency” CS fallback. The operator can enable or disable CS fallback to UTRAN on a per-cell basis via O&M means. Use your pointer to see the related performance counters provided by the Flexi Multiradio BTS.


33 (126)



34 (126)


4.6 Single Radio Voice Call Continuity (RL40) If the user terminal supports VoIP over LTE, a solution called single radio voice call continuity (SRVCC) is available for performing a handover from the LTE radio network to the 2G/3G radio network without interrupting the call. Such a handover is necessary when the terminal enters an area without LTE coverage. SRVCC requires modifications to the Evolved Packet Core and the 2G/3G circuitswitched core network in order to support the handover signalling over the new Sv interface between the MME and MSC Server. Note also the fact that VoIP session control requires interfacing towards a VoIP Application Server in the IP Multimedia Subsystem (IMS). Nokia Siemens Networks also offers solutions where the VoIP Application Server is integrated in the MSC Server. At a later point in time, when LTE coverage becomes more widespread, the need for SRVCC will gradually disappear. The SRVCC procedure is being standardised in 3GPP Release 8 in Technical Specification 23.216.


35 (126)


4.7 SRVCC to WCDMA (RL40) The LTE-to-WCDMA Single Radio Voice Call Continuity (SRVCC) functionality of the Flexi Multiradio BTS provides seamless service continuity for voice services when performing a handover from an LTE cell to a WCDMA cell. All non-voice services will be handed over to the packet switched (PS) domain of the UMTS network. The functionality is only applicable to SRVCC capable multimode devices supporting both LTE and WCDMA in the corresponding frequency band. The handover procedure itself is identical to a conventional LTE-to-WCDMA handover; in other words the lists, measurements and thresholds of the same neighbor cells are used. The eNodeB indicates to the MME with a “Handover Required” message that SRVCC should be initiated. The eNodeB will trigger SRVCC only if the UE has an EPS bearer with QCI=1 established and the MME and UE are SRVCC-capable. The operator can enable or disable the SRVCC functionality on a per-cell basis via O&M means.


36 (126)



37 (126)


4.8 SRVCC to GSM (RL40) The LTE-to-GSM Single Radio Voice Call Continuity (SRVCC) functionality of the Flexi Multiradio BTS provides seamless service continuity for voice services when performing a handover from an LTE cell to a GSM cell. The SRVCC functionality does not support dual transfer mode (DTM) or packet switched handovers, in other words existing non-voice bearers are not handed over to GSM. An operator-configurable switch is supported that determines whether to suspend the data session or not. The functionality is only applicable to SRVCC capable multimode devices supporting both LTE and GSM in the corresponding frequency band. The eNodeB will trigger SRVCC – by performing inter radio access technology (IRAT) measurements – only if the UE has an EPS bearer with QCI=1 established and the MME and UE are SRVCC-capable. The target cells for the IRAT measurements can be configured by the operator. Furthermore, the measurement configuration such as source cell thresholds (RSRP), target cell thresholds (RSSI), hysteresis, time to trigger, and speed dependent scaling can also be configured by the operator. The operator can enable or disable the SRVCC functionality on a per-cell basis via O&M means.


38 (126)


4.9 Emergency Call Handling Regarding voice services, it could be that first-generation LTE terminals will support neither VoIP nor circuit-switched voice, and voice services will continue to be handled separately by the 2G/3G network. However, multi-mode LTE terminals will eventually become available. These will support both LTE packet services and circuit-switched voice, but not necessarily VoIP. These terminals can be simultaneously attached to LTE and 2G/3G radio networks. When the user initiates a voice call, the call is transferred to the 2G/3G network. When the user receives a voice call, the paging takes place via the LTE network, after which the terminal is transferred from the LTE to the 2G/3G radio network before the call is set up. This is called CS fallback. CS fallback requires modifications to the Evolved Packet Core and the 2G/3G circuitswitched core network to support the enhanced signalling over the new SGs interface between the MME and MSC Server. The CS fallback procedure is being standardised in 3GPP Release 8 in Technical Specification 23.272.


39 (126)



40 (126)


5

Transport Solutions

5.1 Transport Solutions - Introduction In order to support the increase in data traffic anticipated in an LTE radio network, the transport network also has to be significantly expanded. Nokia Siemens Networks provides a comprehensive portfolio of transport solutions both for existing or new radio access networks and for existing or new backhaul, aggregation and backbone networks. Mobile operators can easily transition from a classic backhaul design to a hybrid backhaul network, by adding Ethernet connectivity to existing nodes already offering TDM connectivity. The TDM and Ethernet networks extend in parallel from the cell site to the controller nodes in the 2G or 3G radio access network and the Ethernet network extends in solitude to the Serving Gateway in the Evolved Packet Core. New backhaul networks can be deployed using Carrier Ethernet Transport (CET) technology. Pseudo wire solutions are available for taking care of the native TDM and ATM traffic, if required.


41 (126)


5.2 Evolution towards Flat Network Architecture User plane transport solutions are closely interconnected with the evolution towards a flat network architecture. In a traditional 3GPP network both the user plane data and control plane signalling is carried between the UE and GGSN via the BTS, RNC and SGSN. The high-speed packet access (HSPA) solution in 3GPP release 6 provides greatly increased radio access capacity when compared to earlier solutions. As a next step in the network architecture evolution, 3GPP release 7 offers the possibility of implementing a direct GTP tunnel for carrying user data between the RNC and GGSN. The control plane signalling still takes place via the SGSN. The basic idea of the Internet HSPA (I-HSPA) solution is to integrate the RNC packet switched functionality into the base stations. At the same time, the GTP tunnel for the user plane traffic is extended to the I-HSPA adapter in the BTS. The direct tunnel solution offers high bitrates in a very cost efficient manner and reduces the round trip time (RTT) in the user plane. The LTE network architecture is similar to the I-HSPA architecture, although the functionality and names of the network elements have changed. Also, the LTE radio interface provides greatly increased radio access capacity when compared to HSPA.


42 (126)


5.3 Transport Network for S1-U Interface A typical user plane transport network solution between eNodeB entities and the Serving Gateway consists of access network sections, aggregation networks, and a Multi-Protocol Label Switching (MPLS) backbone network. The access network typically consists of FlexiPacket microwave radio links interconnected via a FlexiPacket radio hub. This solution offers low-delay and highcapacity interconnection links enabling fast inter-eNodeB handovers over the X2 interface. The access network is partitioned into different virtual LANs (VLANs) containing one or more eNodeB entities each. The aggregation network typically uses a ring topology and virtual private LAN service (VPLS) transport which in turn is based on MPLS technology. One Label Switch Path (LSP) is reserved for each access network VLAN connection as shown in the figure. The aggregation network can be connected to the Serving Gateway via a more “traditional” MPLS backbone network, where the layer 3 routers are interconnected using a mesh topology, and the IP traffic to/from a certain aggregation network is directed to/from the Serving Gateway again along a certain Label Switch Path.

5.4 Carrier Ethernet Transport The ever-increasing popularity of Ethernet technology has resulted in a world-wide effort to develop standardised carrier-grade Ethernet transport solutions, collectively known under the name Carrier Ethernet Transport (CET), as a cost-effective alternative to traditional time division multiplex (TDM) transport solutions such as SDH. © Nokia Siemens Networks

43 (126)


Carrier Ethernet Transport could be deployed in both access and aggregation networks. In this case, all LTE, 3G and 2G traffic can be carried over the packetbased backhaul infrastructure as explained on the next page. Carrier Ethernet can be characterised by five attributes: · Standardised services · Scalability · Reliability · Quality of Service · Service management

Use your mouse pointer to learn more about these attributes.


44 (126)


5.5 Carrier Ethernet Transport (RL30) The LTE release RL30 introduces the feature "Fast IP Rerouting". It enables Bidirectional Forwarding Detection (BFD) support for static routing to eNode B. In the example scenario, the eNode B sees two routers connected to it – R1 and R2. The primary route in the routing table of the router R1 is connected to the BFD session. If the BFD session fails, the route is removed from the routing table of the R1 router and the eNode B, and the secondary route is selected. The backhaul configuration can be single link or dual link. In the dual link configuration, the integrated Ethernet capabilities of the eNode B are used directly for the backhaul links. The feature brings cost savings to operators in the form of a more robust network and improved resilience.


45 (126)


5.6 IP Transport Network Measurement (RL30) The LTE release RL30 introduces the feature IP Transport Network Measurement. It enables active measurements of IP network quality in the mobile backhaul network between two points – an eNode B and another point. One point performs test traffic generation and analysis. The other point must be able to send back the test traffic. With this feature, the operator is able to monitor the network conditions and can react quickly to potential service degradations. Furthermore, the measurements provide an indication of possible violations against a Service Level Agreement. The built-in feature provides savings for the operator because it removes the need for expensive measurement equipment. The measured values are: round-trip time - presented as minimum, maximum and average value - and the number of sent and lost packets. Measurements can be made separately for each quality of service class. The measurements are performed using Two-way Active Measurement Protocol (TWAMP), where one end point is a sender and the other can be either a responder that generates response messages or an echo server that only returns the messages that are sent. The measurements are aggregated into performance measurement counters. Alarms will be raised if the network condition falls below a configurable threshold.


46 (126)


5.7 Pseudo Wire Solutions Not only LTE traffic, but also 2G, WCDMA and HSPA traffic can be carried over the packet-based infrastructure extending towards the BTS site. This is possible using Carrier Ethernet Transport as explained on the previous page together with a concept called pseudo wire transport. In the case of a 3G radio access network, if the Iub interface is based on ATM transport the traffic is carried over ATM pseudo wire connections, for instance one connection for circuit-switched traffic and another for packet-switched traffic. If the Iub interface is based on IP transport, a pseudo wire solution is naturally not required. In a similar fashion, 2G traffic can be carried over a TDM pseudo wire connection between the BTS and the base station controller (BSC). In this case the time division multiplex (TDM) signals are carried transparently over the radio access network without ”noticing” the underlying packet technology.


47 (126)


5.8 Flexi Transport Sub-module FTIB (RL10 onwards) The LTE release RL10 introduces a new transport sub-module of type FTIB to be used in a Flexi Multiradio BTS. This transport sub-module supports WCDMA, I-HSPA and LTE system technology, enabling seamless migration from WCDMA to LTE via a software update. The FTIB sub-module provides the following physical interfaces: · two electrical Gigabit Ethernet interfaces · one optical Gigabit Ethernet interface via a small form-factor pluggable (SFP) module · four symmetrical E1/T1/JT1 interfaces. Furthermore, the sub-module hardware supports the Timing over Packet (ToP) and Synchronous Ethernet synchronisation solutions, as well as IPsec-based security solutions with 160 Mbit/s downlink-plus-uplink throughput performance.


48 (126)


5.9 Flexi Transport Sub-module FTIF (RL40) The LTE release RL40 introduces a new transport sub-module of type FTIF to be used together with a multiradio system module in a Flexi Multiradio 10 BTS. This transport sub-module variant provides eight time division multiplex (TDM) interfaces and two Gigabit Ethernet Combo ports. Each Gigabit Ethernet Combo port consists of one Gigabit Ethernet electrical interface and one optical interface based on small form-factor pluggable (SFP) module interfacing. Note that the interfaces in a Combo port share the same port in the system module and thus cannot be used at the same time. The eight TDM interfaces are accessed via four RJ48 ports. A special cable is required for providing two TDM interfaces per port. Note that the Flexi multiradio system module (for instance FSMF) plus the transport sub-module of type FTIF form a single logical transport entity that provides up to three Gigabit Ethernet interfaces. The transport sub-module of type FTIF supports the following functionality: • Synchronization via the TDM interface • eNodeB chaining using the two optical or electrical connections


49 (126)


• Synchronization hub functionality if based on Synchronous Ethernet input or output • Transport link redundancy using the two optical or electrical connections • Circuit Emulation Service over Packet Switched Network (CESoPSN) functionality for legacy BTS co-location.

5.10 Traffic Differentiation (RL10 onwards) The LTE release RL10 introduces the following traffic differentiation solutions: · Traffic differentiation in the IP layer (also known as Layer 3) · Traffic differentiation in the Ethernet layer (also known as Layer 2) · VLAN-based traffic differentiation. Traffic differentiation in the IP layer is based on the Differentiated Services Code Point (DSCP) - a 6-bit traffic priority indicator in the IP packet header. Traffic end points set the DSCP values, and the IP routers in the network handle the packets according to the DSCP value. Traffic differentiation in the Ethernet layer is based on three Priority Code Point (PCP) bits, contained in the Ethernet frame header, as defined in the standard IEEE 802.1p. Traffic end points perform the mapping between DSCP values and PCP values, and the Ethernet switches in the network handle the packets according to the PCP value. © Nokia Siemens Networks

50 (126)


Traffic differentiation can also be achieved by assigning different virtual LANs (VLANs) for different types of traffic. In this way, the IP traffic in the control, user, management and synchronisation plane can be separated, offering benefits both in terms of QoS and security. VLAN traffic differentiation is based on a 32-bit field (VLAN tag) inserted in the Ethernet frame header. Each VLAN may also be associated with a dedicated IP address at the eNodeB side of the connection.


51 (126)


5.11 Synchronisation over Packet Networks The eNodeB entities in the E-UTRAN require highly accurate timing information. This timing information can be extracted directly from the received digital signal if the transport network is based on time division multiplex (TDM) technology, for instance a Synchronous Digital Hierarchy (SDH) transmission system. However, the interfacing towards the Evolved Packet Core is most probably based on Ethernet transport at the physical layer level. In this case the timing information is retrieved either using the Timing over Packet (ToP) solution in accordance with the IEEE 1588 version 2 specification, or using the Synchronous Ethernet timing solution. In the ToP timing solution, specific timing packets with time stamps are sent over the Ethernet transport network from a ToP master clock to timing receivers in the eNodeB entities, where the timing information is extracted.


52 (126)


The reference clock signal for the ToP master clock is received either from the TDM network or from the global positioning system (GPS). The ToP timing solution relies on using protocol layers 2 or 3 for carrying the timing information through the network. By contrast, in the more advanced Synchronous Ethernet timing solution (to be used together with a Carrier Ethernet transport network) the timing information is embedded in the physical layer.

5.12 Synchronisation Hub The LTE release RL40 introduces a synchronization hub that allows one of several synchronization output signals to be derived from a number of synchronization input sources. As a benefit, co-located or chained base stations can rely on the synchronization capabilities of the eNodeB. The synchronization capabilities are aligned between WCDMA and LTE. Selectable synchronization input signals are: • Timing over Packet (ToP) according to the IEEE1588-2008 specification • “ToP with phase” input signal • Synchronous Ethernet (SyncE) input signal • Plesiochronous Digital Hierarchy (PDH) E1/T1 line interface © Nokia Siemens Networks

53 (126)


• 2.048 MHz input signal • Global Positioning System (GPS) one-pulse-per-second (1PPS) input signal. The synchronization output signal options are: • PDH E1/T1 line interface • 2.048 MHz output signal • 1PPS output signal (derived from GPS 1PPS input). Note that the capability to generate Synchronous Ethernet signals is part of the RL40 feature “Synchronous Ethernet Generation”.

5.13 IP Layer Addressing (RL10 onwards) LTE technology offers the following IP layer addressing features: • Separate IP addresses for each VLAN • SCTP multihoming in the control plane. When applying traffic differentiation by assigning different virtual LANs for the control, user, management and synchronisation plane, the eNodeB can be configured with a separate IP address for each plane.


54 (126)


Address sharing, that is, configuration using the same IP address, is also possible. In the simplest configuration, the eNodeB provides a single IP address for all four planes. Stream Control Transmission Protocol (SCTP) is a transmission layer protocol, like UDP or TCP, located above IP in the protocol stack. SCTP is often used in the control plane. SCTP multihoming means that SCTP provides the possibility of reaching a certain node via several IP addresses - thus increasing the reliability of the connection.

5.14 Ethernet OAM The LTE release RL20 offers a transport solution called Ethernet OAM. Ethernet OAM means adding OAM (Operations, Administration and Maintenance) functionality to the Ethernet layer. This is achieved using two Ethernet OAM protocols: Link Layer OAM and Ethernet Service OAM. Use your mouse pointer to see the supported functionality in LTE release RL20.


55 (126)


5.15 QoS-aware Ethernet Switching The RL20 feature ”QoS-aware Ethernet Switching” means that the integrated Ethernet switch of the transport sub-module in the Flexi Multiradio BTS supports blocking-free and Quality-of-Service (QoS)-aware Ethernet switching. One Gigabit Ethernet interface of the transport sub-module supports the backhaul connection, while one or two more interfaces may be connected to one or two more eNodeBs at the same or another site. Thus the need for a separate external switch device for daisy-chaining at the eNodeB site is avoided. Four QoS priority levels are supported. The traffic differentiation is based either on the Differentiated Services Code Point (DSCP) traffic priority indicator contained in the IP packet header, or the three Priority Code Point (PCP) bits contained in the VLAN tag in the Ethernet frame header. Also VLAN filtering based on the VLAN ID in the VLAN tag is supported. © Nokia Siemens Networks

56 (126)


The feature also includes policing of the traffic, and shaping of the aggregated traffic in the uplink according to the service level agreement (SLA). The traffic policing is applied in order to protect the eNodeB from flooding and interfering with the internal message flows of the eNodeB. It can be configured per ingress port, or can be switched of - the default option.

5.16 Ethernet Jumbo Frames In LTE release RL30, the Flexi Multiradio BTS supports Ethernet jumbo frames. The jumbo frames are Ethernet frames with more than 1500 bytes of payload. If the user's IP packet is 1500 bytes long, it will cause fragmentation at the Ethernet transport layer due to additional overhead from enclosing protocol headers such as GTP, UDP, and IPsec. Thus the resulting packet is larger than the 1500 bytes, which is the maximum payload size for an Ethernet frame – without the jumbo frame feature. The Flexi Multiradio BTS supports Ethernet jumbo frames up to 1644 bytes at the transport interface. The benefit of this is to avoid IP fragmentation and re-assembly or the reduction of the user's IP layer maximum transmission unit (MTU) size.


57 (126)


5.17 Multi-Operator Core Network This RL20 feature enables a Flexi Multiradio BTS to be connected to the Evolved Packet Core (EPC) of two different operators. In this way the operators are able to share: · spectrum · BTS sites · RF lines and equipment · BTS transport interfaces · BTS RF capacity · BTS baseband capacity · Operations support system (OSS) functions in the BTS. The assignment of PLMN IDs to the shared cells is done via SIB1 configuration. This information is necessary for selecting the correct S1 interface during the LTE attach procedure.


58 (126)


All enabled BTS features are available for both operators. Furthermore, all O&M settings, including neighbour cell lists, are common for both operators in the case of shared cells. Also, the same IPsec transport settings are applied for both operators.

5.18 FlexiPacket Radio Connectivity The LTE release RL20 provides the possibility of managing both near-end and farend FlexiPacket Radio equipment by using a local management terminal (LMT) attached to the local management port of the Flexi Multiradio BTS. The Flexi Multiradio BTS assigns a separate virtual LAN (VLAN) for the management traffic. Note that the VLAN ID selected in the Flexi Multiradio BTS has to match the VLAN ID configured for the management plane in the near-end FlexiPacket Radio equipment. As a benefit of using a separate VLAN for the management plane, local commissioning and management of the FlexiPacket Radio equipment does not require interrupting the backhaul traffic. Also, the Ethernet cabling between the Flexi Multiradio BTS and the FlexiPacket Radio near-end equipment need not be modified in any way.


59 (126)



60 (126)


6

Security Solutions

6.1 Introduction The LTE security architecture is being defined by the 3GPP Services and System Aspects Working Group on Security, SA3. The Evolved Packet System (EPS) authentication and key agreement (AKA) is based on UMTS AKA. Since the AKA framework involves mutual authentication, 2G subscribers with a GSM Subscriber Identity Module (SIM) will not be allowed to access an LTE network. EPS authentication and key agreement is explained on the following pages. First, we will examine the key management process, and then the actual signalling taking place during authentication. Interworking with non-3GPP networks will be based on Extensible Authentication Protocol (EAP) AKA. For this purpose, the Evolved Packet Core must include a socalled authentication, authorisation and accounting (AAA) server.

6.2 EPS AKA Key Hierarchy The EPS authentication and key agreement procedure (EPS AKA) specified in 3GPP Release 8 in Technical Specification 33.401 is based on the UMTS AKA procedure, providing mutual authentication between the UE and the network as in UMTS AKA, © Nokia Siemens Networks

61 (126)


but employing a more elaborate key hierarchy, resulting among others in faster handovers. At the top of the hierarchy, a permanent key (K) is safely stored in the Universal Subscriber Identity Module (USIM) and in the Authentication Center (AuC) in the home network of the subscriber. From this key, a pair of keys (CK, IK) are derived and stored in the UE and home subscriber server (HSS), respectively. Using these keys in combination with the serving network's identity (SN ID), the Access Security Management Entity (ASME) key is derived. On the network side, this key is then included in the EPS authentication vector and is sent to the MME. From the ASME key, the UE and MME derive three keys: two keys for encryption and integrity protection of the Non Access Stratum (NAS) signalling, and another key that on the network side is sent to the eNodeB. This eNodeB key is used in the eNodeB and UE for generating two more keys for encryption and integrity protection of the RRC signalling over the radio interface, and one more key for user plane traffic encryption over the radio interface. Note that there is no integrity protection (and corresponding key) for the user plane traffic.

6.3 Key Management during Inter-eNB Handover During an inter-eNodeB handover, the keys for encryption and integrity protection of the Non Access Stratum signalling need not be changed, unless the handover also involves the MME relocation procedure. © Nokia Siemens Networks

62 (126)


However, the eNodeB key must be changed during an inter-eNodeB handover. This means that the keys derived from the eNodeB key are also automatically changed. The eNodeB key handling procedure is as follows. · The source eNodeB generates an interim eNodeB key and sends this key to the target eNodeB. · The target eNodeB derives the new eNodeB key using the received interim eNodeB key. · The target eNodeB naturally also derives new RRC signalling and user data protection keys.

On the UE side, the same algorithms are used, resulting in the same new keying information. Note that this key management solution is much faster than the alternative of performing a completely new authentication and key agreement run ”from scratch” involving the Home Subscriber server (HSS).


63 (126)


6.4 EPS AKA Signalling In LTE End to End System Part 1, we investigated several signalling procedures where authentication was an integral part of the procedure. Now let us examine the authentication signalling in more detail. The MME starts the authentication procedure by sending the user’s International Mobile Subscriber Identity (IMSI) and the serving network's identity (SN ID) to the HSS in the user’s home network. If the MME does not know the IMSI, this information must first be retreived from the UE. Since the IMSI is sent over the radio interface in cleartext, this step should be avoided whenever possible. The HSS responds to the user authentication request by returning an EPS authentication vector to the MME, including the information RAND, AUTN, XRES, and the ASME key. Next, the MME sends the random challenge (RAND) and authentication token (AUTN) to the UE. The UE uses this information both to authenticate the network and to calculate a response (RES) which is returned to the MME. Using the same algorithm and input parameters as in the UE, the HSS previously calculated the expected response (XRES) and sent this value to the MME in the authentication vector. The MME checks that RES = XRES, in which case the UE is successfully authenticated. As a result, the Non Access Stratum signalling can be secured, the eNodeB key can be calculated and sent to the eNodeB, and the radio interface signalling and user data traffic can be secured.


64 (126)


6.5 Confidentiality and Integrity Protection LTE provides both confidentiality and integrity protection for the signalling traffic between the UE and the MME. Confidentiality protection means ciphering or encrypting the signalling messages. Integrity protection means ensuring that the content of the signalling messages has not been altered during the transport. Over the radio interface the traffic is secured using Packet Data Convergence Protocol (PDCP). In the control plane, PDCP offers both encryption and integrity protection for the RRC signalling messages carried within the PDCP packet payload. In the user plane, PDCP only performs encryption of the user data, but not integrity protection. As a consequence of the widespread encryption in the control plane, tracing is no longer possible with an external protocol analyser, if the network entity does not have a dedicated unciphered trace port. Protection of the network-internal interfaces, for instance the S1 interface, is optional. Two new sets of security algorithms are being developed for LTE networks: one set will be based on Advanced Encryption Standard (AES) and the other on SNOW 3G. SNOW is a stream cipher developed at Lund university. The principle being adopted is that the two sets of algorithms are as different from each other as possible, to prevent attacks from compromising both at the same time. The ETSI Security Algorithms Group of Experts (SAGE) is responsible for specifying the algorithms. The foreseen key length is 128 bits, with the possibility to introduce 256-bit keys in the future if necessary.


65 (126)



66 (126)


6.6 Exercise


67 (126)


6.7 Lawful Interception Closely related to security is a concept called lawful interception (LI), which is a mandatory regulatory requirement in many countries. Lawful interception allows the operator to intercept user data flows in the PDN Gateway and produce interception related information (IRI) and content of communication (CC) data required by the authorities. It is possible to intercept IRI and CC data simultaneously on a case-by-case basis, using the international mobile subscriber identity (IMSI) or the mobile subscriber international ISDN number (MSISDN) for identifying the user data flow. The Nokia Siemens Networks PDN Gateway enables intercepting 1 % of all active user data flows simultaneously. The lawful interception implementation in the PDN Gateway is based on the Nokia Siemens Networks Lawful Interception Gateway (LIG) solution. The local lawful interception extension (LIE) functionality in the PDN Gateway acts according to LIG instructions, performs the actual interception, and sends the intercepted data to the Lawful Interception Gateway.

6.8 LTE Firewall Support A Flexi Multiradio BTS based eNodeB includes in-host firewall or packet filtering functionality in order to protect against potential attacks over IP interfaces. The © Nokia Siemens Networks

68 (126)


firewall examines all packets to see if they meet certain criteria. If they do, the packets are accepted; otherwise they are discarded. The firewall filters IP packets based on their source and destination addresses and port numbers. The firewall blocks network-level attacks such as denial-of-service (DoS), oversized-packet, SYN flooding and fragmentation attacks. The implementation is fully software-based. Fixed, non-configurable filtering rules are applied to the IP traffic. These rules are created automatically, based on the configuration, and are permanently active. Furthermore, the rate of Internet Control Message Protocol (ICMP) messages is limited to protect against denial-of-service attacks using faked ICMP messages. It is possible, via the BTS Site Manager or via NetAct Configurator, to enable and disable the Flexi Multiradio BTS to respond to "ping" and "traceroute” requests.

6.9 LTE Certificate Management LTE release RL10 introduces the support of Flexi Multiradio BTS certificate management. Certificate management is part of the Nokia Siemens Networks Identity Management (IDM) system, or part of a 3rd party public key infrastructure (PKI) solution, and is required for handling private and public keys as well as digital certificates in X.509v3 format. A certificate is basically a document that contains, along with the public key of the sender, the name of an independent and trusted third party, called certification authority, as well as the digital signature of this certification authority to ensure the © Nokia Siemens Networks

69 (126)


validity of the transmitted information. The format of an X.509 certificate is based on ITU-T recommendation X.509. Certificates are primarily used for establishing mutual authentication between IPsec peers as well as between TLS protocol peers.

6.10 LTE User Account Management The LTE release RL10 introduces centralised user account management for the Flexi Multiradio BTS, and also enables the mass updating of local user passwords. Centralised user account management means that the system administrator is able to manage, via NetAct, user access to any Flexi Multiradio BTS. In the login phase, the network checks the user’s access rights by querying a Lightweight Directory Access Protocol (LDAP) server providing the authentication and authorisation information. The access rights can be managed separately for individual users or for user groups. The operator can define different access classes with specific access rights for different user groups on a per-BTS basis. Security alarms are raised if a user attempts to access a Flexi Multiradio BTS using wrong credentials. Updating the local user account passwords in the network elements is a timeconsuming operation, which needs to be performed frequently. The mass updating functionality - performed remotely from NetAct - helps keeping the local passwords up-to-date. © Nokia Siemens Networks

70 (126)


6.11 LTE User Event Log Management The LTE release RL10 also enables the auditing of user actions in the Flexi Multiradio BTS and provides fast means to start corrective actions in order to prevent possible damages to the configuration. Consequently, the security of the system is increased. The operator is able to trace all changes in all eNodeBs in a centralised fashion, using the NetAct "Audit Trail" tool. The uploading of the event log files from the Flexi Multiradio BTS is triggered from NetAct. The event log files are in XML file format and are transmitted over a secure connection using Secure File Transfer Protocol (SFTP). NetAct also provides tools for processing the collected log files. The log files can also be made available for 3rd party applications.


71 (126)


6.12 LTE IPsec Support From LTE release RL10 onwards, IPsec security solutions can be utilised for securing the following types of IP traffic originating or terminating in the Flexi Multiradio BTS: •User plane traffic between the eNodeB and the Serving Gateway or another eNodeB •Control plane traffic between the eNodeB and the Mobility Management Entity or another eNodeB •Management traffic between the eNodeB and, for instance, NetAct. Using IPsec-based Virtual Private Networks (VPNs), the user plane traffic, control plane traffic and management traffic can be separated from each other, and from any other operator's IP traffic if part of the transport network is shared. The separation ensures that denial-of -service attacks in the user plane, for instance, does not affect the operation in the control plane or management network. It is possible to configure the security settings for each IPsec connection independently. The supported IPsec capabilities follow 3GPP recommendation TS 33.210, TS 33.401 and TR 33.821. Since the IPsec standards include a large number of selectable security parameter options, 3GPP has recommended to cut down on the number of these options in order to guarantee interoperability between different security domains. Use your mouse pointer to see a list of supported IPsec capabilities.


72 (126)


6.13 LTE O&M Transport Security From LTE release RL10 onwards, the O&M data traffic between the Flexi Multiradio BTS and the BTS Site Manager, NetAct, or a 3rd party network management system is secured using the Transport Layer Security (TLS) protocol. This results in CAPEX savings, since there is no need for any external hardware for achieving secure data transport. TLS provides server authentication, encryption, and integrity protection, and secures both HTTP and LDAP traffic. The Lightweight Directory Access Protocol (LDAP) is primarily employed for retrieving usernames and passwords from LDAP servers, as part of the remote user information management (RUIM) functionality. Usernames and passwords should never be sent in plaintext, so LDAP traffic should be carried over TLS. © Nokia Siemens Networks

73 (126)


Note that TLS can be used together with IPsec; that is, it is possible to run TLS within an IPsec tunnel.


74 (126)


6.14 Certificate Management for iOMS (RL40) From LTE release RL40 onwards certificate management is provided for the Operation and Management Server (OMS) or the more recent integrated Operation Mediation System (iOMS) solution. This supports the life cycle management of the operator certificate and trust anchor (that is, the self-signed certificate of the root certificate authority) included in the OMS/iOMS. Certificate management is needed during the enrollment of the operator certificate when a public key infrastructure (PKI) is used for network node authentication. The operator certificate is used for mutual authentication between the OMS/iOMS and a Flexi Multiradio BTS or NetAct during the establishment of a Transport Layer Security (TLS) or HyperText Transfer Protocol Secure (HTTPS) connection. The iOMS supports certificates in X.509v3 format. The operator certificate is either derived from a certification authority (CA), or is included in the iOMS set-up configuration. In the first mentioned case, the operator certificate management is based on Certificate Management Protocol version 2 (CMPv2).


75 (126)



76 (126)


6.15 Crypto Agent (RL40) From LTE release RL40 onwards, the Flexi Multiradio BTS supports the crypto agent functionality. This means that each Flexi Multiradio BTS hardware module contains a personal secure environment (PSE) for storing private keys, passwords, sensitive files, etc., and for executing sensitive tasks such as key creation, data encryption and decryption. Such a personal secure environment is based either on a software solution or a hardware solution - using a Trusted Platform Module (TPM) security device. The corresponding software solution, used in the Flexi Multiradio BTS, involves as central entity the crypto agent (CRA). The crypto agent makes use of the OpenSSL suite and provides its services via a common application programming interface to the applications. This concept ensures that private keys never leave the crypto agent in unencrypted form. Moreover, all operations involving private keys are performed by the crypto agent. Let our tutor shortly explain the role of private and public keys. The crypto agent also provides a secure file storage service, where the file content is encoded and decoded by the crypto agent, and the files are stored only in encrypted form within the file system.


77 (126)


6.16 SW Verification Agent (RL40) From LTE release RL40 onwards, Flexi Multiradio 10 BTS modules provide secure booting. Only integrity checked code is accepted for activation. This significantly enhances risk management. The secure boot process enforces verification and execution of trusted software in a predefined sequential order. It guarantees that a system boots only into a specific state. Software verification agents ensure that no malicious code can be inserted. During the production phase of the hardware module, private and public keys are created and securely stored within read-only memory. Furthermore, boot load software, boot software, kernel software and application software are initially hashed, and the hash values are encrypted with the private key and stored in non-volatile memory. During the boot process, the verification agent calculates the hash value of the boot software, and decrypts the stored hash value with the help of the public key of the module. If the hash pairs match, the boot continues since there was no integrity violation. In this way the boot software, kernel software and application software are checked before being taken into use. Software updates are handled in a similar way. The software updates are downloaded via a secure channel, and hash values are calculated, encrypted, and securely stored. During software activation, at a later point in time, the software verification process takes place as illustrated in the animation.


78 (126)


Failures are logged and if online connectivity is available a security alarm is sent to the Network Management System.

6.17 Local Link Layer Security (RL40) Starting with LTE release RL40, the serial communication of the RapidIO bus between Flexi Multiradio 10 BTS modules is authenticated and ciphered. The improved Flexi Multiradio software and hardware security significantly enhances risk management. In the Flexi Multiradio 10 BTS, hardware modules (such as FSMF, FSMG, FBBA and FBBB) provide serial RapidIO (sRIO) ports on the front panel. These can be used, for instance, to connect extension sub-modules to the core module. The sRIO bus ports provide direct access to memory and allow the configuration of sRIO chips. To protect these interfaces, module authentication and link layer encryption is provided. The confidentiality of the data sent via the serial RapidIO bus is protected by a crypto unit that is embedded in the sRIO chip sets. The link layer security is closely connected to the sRIO transport layer and sRIO physical layer. First, an sRIO transport header is added to the payload. Then, the payload and the header are encrypted. The encryption algorithm, AES128-CTR, is the same as specified by 3GPP for airlink encryption. This algorithm is hard coded inside the sRIO chips and cannot be changed. It is only used for BTS-internal transport security purposes.


79 (126)



80 (126)


7

QoS Solutions

7.1 Introduction (RL20 onwards) The class-based Quality of Service (QoS) concept specified for LTE networks in 3GPP Release 8 provides network operators with effective techniques to enable service or subscriber differentiation at the application level, and to maintain the required QoS level across the end-to-end system. We start our QoS investigation by describing some important concepts such as EPS bearer and packet flow. On the following pages, the EPS QoS profile structure is explained, and it is shown what QoS control means in practice at the bearer level, at the transport level and at the air interface. Next, a concept called policy and charging control (PCC) will be introduced. The PCC framework specified in 3GPP Release 7 is closely related to QoS management and provides operators with advanced tools for service-aware QoS and charging control. Finally, QoS management as a process is illustrated using a signalling flow chart example.


81 (126)


7.2 EPS Bearer Concept In the Evolved Packet System, basic entities called EPS bearers are employed for carrying the user data between the UE and the PDN Gateway, or as another option between the UE and the Serving Gateway. In the first option, the GTP tunnel associated with the bearer extends between the eNodeB and the PDN Gateway. In the second option, the GTP tunnel extends to the Serving Gateway only. Over the S5/S8 interface the IETF Proxy Mobile IP (PMIP) solution is used instead for carrying the user data traffic. Each EPS bearer can handle one or more packet flows or, in official terms, service data flows. A packet flow is defined by the quintuple of source and destination IP address, source and destination layer 4 port, and the layer 4 protocol used (TCP, UDP, or SCTP). All packet flows belonging to a certain EPS bearer are associated with a certain bearer-level Quality of Service (QoS) profile. Thus, packet flows with different bearer-level QoS requirements must be carried by different EPS bearers. When a UE connects to a packet data network (PDN), a so-called default bearer is permanently established for the lifetime of the PDN connection to provide always-on IP connectivity with that PDN. Additional dedicated EPS bearers may be allocated for the transport of user data traffic with different bearer-level QoS requirements. Let us next examine the QoS profile structure in LTE.


82 (126)


7.3 EPS QoS Profile Structure In 3G, the QoS profile structure is rather complicated, with a large number of parameters and possible value combinations. The Evolved Packet System uses instead a single QoS class identifier (QCI). Nine QCI values have been defined in 3GPP technical specification 23.203. You can examine the QoS attributes mapped to these QCI values with your mouse pointer. The Allocation and Retention Priority (ARP) can be used by the network to decide whether a certain bearer can be established or must be rejected in case of resource limitations, or to decide which bearers are dropped in case of exceptional resource limitations, for instance during a handover. This QoS parameter, however, does not affect the packet forwarding in the network. Regarding bit rate limitations, there are two types of bearers: Guaranteed bit rate (GBR) and non-guaranteed bit rate (non-GBR) bearers. For GBR bearers, a maximum bit rate and a guaranteed bit rate are defined for both uplink and downlink traffic. Guaranteed bit rate means that the network makes sure that congestion-related packet drops will not occur as long as the bit rate remains below this value. In 3GPP Release 8, the guaranteed bit rate is always equal to the maximum bit rate.


83 (126)


For non-GBR bearers, the aggregate maximum bit rate (AMBR) of the aggregate packet flows is defined instead for the uplink and downlink traffic. Note that the default EPS bearer is always a non-GBR bearer.

7.4 QoS Control in the EPS (RL 09 and RL10) QoS control in the Evolved Packet System can be implemented in various network nodes at several levels. At the EPS bearer level, QoS control takes place in the PDN Gateway and the eNodeB. In the case of non-GBR bearers, separate downlink and uplink aggregate maximum bit rate values are used for traffic flow enforcement in the PDN Gateway and in the eNodeB. In other words, the QoS profile includes, in total, four AMBR values. Since packet flows are identified by their quintuple as mentioned earlier, this information must also be included in the QoS context in the PDN Gateway and eNodeB. At the transport level, QoS control is based on mapping the QCI value associated with the EPS bearer into the six-bit Differentiated Services Code Point (DSCP) carried in the IP packet header indicating the priority of the packet. The routers in the IP network take this information into account when routing the packets to their destination. Packets with high priority experience less delay in the routers. The QCIto-DSCP mapping is performed in the PDN Gateway for downlink traffic and in the eNodeB for uplink traffic. The mapping tables are installed to these network nodes by O&M means.


84 (126)


QoS control can also be applied at the radio interface. This requires some kind of mapping between the QoS parameters and the scheduling priority in the eNodeB. Again, the mapping is controlled by O&M means. Finally, note that the first commercial Nokia Siemens Networks LTE release does not support non-GBR QoS nor multiple EPS bearers per UE.

7.5 QoS Control in the EPS (RL20 onwards) QoS control in the Evolved Packet System can be implemented in various network nodes at several levels. At the EPS bearer level, QoS control takes place in the PDN Gateway and the eNodeB. In the case of non-GBR bearers, separate downlink and uplink aggregate maximum bit rate values are used for traffic flow enforcement in the PDN Gateway and in the eNodeB. In other words, the QoS profile includes, in total, four AMBR values. Since packet flows are identified by their quintuple as mentioned earlier, this information must also be included in the QoS context in the PDN Gateway and eNodeB. At the transport level, QoS control is based on mapping the QCI value associated with the EPS bearer into the six-bit Differentiated Services Code Point (DSCP) carried in the IP packet header indicating the priority of the packet. The routers in the IP network take this information into account when routing the packets to their © Nokia Siemens Networks

85 (126)


destination. Packets with high priority experience less delay in the routers. The QCIto-DSCP mapping is performed in the PDN Gateway for downlink traffic and in the eNodeB for uplink traffic. The mapping tables are installed to these network nodes by O&M means. QoS control can also be applied at the radio interface. This requires some kind of mapping between the QoS parameters and the scheduling priority in the eNodeB. Again, the mapping is controlled by O&M means.

7.6 Rate Capping in UL and DL (RL20 onwards) The LTE release RL20 introduces a feature called rate capping, that is, restricting the maximum aggregated non guaranteed bit rate (non-GBR) throughput in both uplink and downlink directions. The Flexi Multiradio BTS uses the QoS attribute UEaggregate maximum bit rate (UE-AMBR) for this purpose. The UE-AMBR values for uplink and downlink are stored in the home subscriber server (HSS) and are sent to the MME for instance during the attach procedure. The MME then sends the UE-AMBR values to the eNodeB in the S1-AP message ”initial context setup request”. The Flexi Multiradio BTS limits the uplink and downlink bit rate of all non-GBR EPS bearers allocated to this specific UE according to the UE-AMBR values. The BTS considers the aggregated throughput as averaged over a period of one second.


86 (126)


The operator can enable or disable this new functionality on a per-cell basis by using O&M.

7.7 Support of UE-AMBR Modification (RL20 onwards) The LTE release RL20 allows the QoS attribute UE-AMBR (aggregate maximum bit rate) to be modified by the MME. The initial assigned value of UE-AMBR can be changed, that is, increased or decreased by the MME. The Flexi Multiradio BTS supports the following S1-AP messages for this purpose: · UE context modification request · UE context modification response · UE context modification failure. This new functionality can be enabled or disabled by using O&M.


87 (126)


7.8 Support of Multiple EPS Bearers (RL20 onwards) The LTE release RL20 supports up to four EPS bearers per mobile device. Previously, only a single default EPS bearer was available for data transport. EPS bearers are associated with a certain bearer-level QoS profile. Thus, all traffic sent over a certain EPS bearer will receive the same QoS treatment. This is the main reason why multiple EPS bearers are needed. In order to be able to benefit from this functionality, mobile devices must also be capable of supporting multiple bearers. Regarding the radio bearer part of the EPS bearer, you can use your mouse pointer to see which radio bearer combinations are supported by the Flexi Multiradio BTS per mobile device. The different EPS bearers may or may not have the same QoS class identifier (QCI) value. The downlink scheduler in the eNodeB provides prioritisation among multiple non-GBR EPS bearers in order to avoid starvation of the downlink traffic.


88 (126)


7.9 Multiple GBR EPS Bearers per UE From LTE release RL40 onwards the Flexi Multiradio BTS supports up to three guaranteed bit rate (GBR) EPS radio bearers per UE. Up to six data radio bearers (DRBs) can be established per UE. As a result, operators are able to offer additional service combinations. Multiple data radio bearers can be either multiple default EPS bearers or a combination of default and dedicated EPS bearers. In downlink, the BTS controls the target delay for the guaranteed bit rate EPS bearers individually. In uplink, the target delay is controlled per logical channel group to which the guaranteed bit rate EPS bearer is mapped statically. The Flexi Multiradio BTS provides checks for the total number of data radio bearers per cell, the maximum number of data radio bearers per UE and the bearer combination per UE. © Nokia Siemens Networks

89 (126)


The Flexi Multiradio BTS supports the following scenarios for establishing and releasing EPS bearers: · establish individual EPS bearers · release individual EPS bearers · add multiple EPS bearers to a set of existing EPS bearers · release multiple EPS bearers from a set of existing EPS bearers.

The various EPS bearers per UE can have the same or a different QoS class identifier (QCI). Intra-LTE handovers must include all EPS bearers – otherwise the handover cannot be performed. The functionality described above can be enabled or disabled on a per-BTS basis via O&M means.

7.10 EPS Bearers for Conversational Voice (RL20 onwards) The LTE release RL20 allows the introduction of high-quality operator-managed voice services in LTE by introducing guaranteed bit rates (GBR) in LTE. This is necessary to enable voice call related features such as CS fallback and single radio voice call continuity (SRVCC). © Nokia Siemens Networks

90 (126)


The Flexi Multiradio BTS supports EPS bearers with the QoS class identifier (QCI) equal to one for voice services. Naturally, in order to be able to benefit from this functionality, mobile devices must also be capable of supporting this QoS class. The Flexi Multiradio BTS takes the QoS information received from the MME into account when assigning radio resources. The uplink and downlink schedulers use the GBR delay budget for their scheduling decisions. The delay budget can be configured by the operator. Non-GBR data transmission might be reduced in order to achieve the GBR performance for voice users. Dynamic scheduling is applied to EPS bearers with QCI equal to one. The support of EPS bearers with QCI equal to one can be enabled or disabled on a per-eNodeB basis by means of O&M.

7.11 Service Differentiation for Non-GBR EPS Bearer (RL20 onwards) The LTE release RL20 also enables service differentiation as applied to non guaranteed bit rate (non-GBR) EPS bearers. These EPS bearers are covered by the QoS classes five to nine. The Flexi Multiradio BTS assigns relative scheduling weights for each non-GBR QCI class on a per-cell basis. The relative weights are taken into account by the uplink and downlink scheduler in the BTS when scheduling the traffic over the radio interface. Furthermore, the service differentiation functionality allows one to define three different Radio Link Control (RLC) or Packet Data Convergence Protocol (PDCP) profiles per BTS. These profiles can be assigned to different QoS classes. © Nokia Siemens Networks

91 (126)


The operator can enable or disable the support of individual QoS classes.

7.12 Operator specific QCI (RL30) In LTE release RL30, the operator can define up to 21 additional QCIs (QoS Class Identifiers) for EPS bearers that have non-guaranteed bit-rates. The benefit is that the operator can more easily differentiate users and services in order to receive different levels of service. One example could be silver, gold, and platinum service levels. In a multi-operator use case, the operator-specific QCIs can naturally separate the traffic of the operators by different QCI values. The QCI value is configurable in the range from 128 to 254. And each QCI is defined by various parameters. The Flexi Multiradio BTS supports up to three QCI groups to combine QCI related performance counters. Also, standard QCIs can be grouped together with operatorspecific QCIs.


92 (126)


7.13 Support of QCI 2, 3 and 4 (RL40) From LTE release RL40 onwards the Flexi Multiradio BTS supports QoS classes two, three, and four. These QoS classes belong to the guaranteed bit rate (GBR) bearer type category. Thus, the operator is able to offer GBR services like gaming or streaming. The MME decides the GBR values to be used in downlink and uplink, and sends this information to the Flexi Multiradio BTS, typically in an “E-RAB Setup Request” message. The BTS takes these values into account when making radio resource management decisions. The maximum accepted GBR values for each QoS class are operator configurable, for instance 2 Mbit/s in downlink and 512 kbit/s in uplink. Note that the same GBR admission control thresholds are applied as for EPS bearers with QoS class identifier (QCI) = 1. Dynamic scheduling is applied to EPS bearers with QCI value 2, 3, or 4. The scheduling priority is used in case of congestion in order to prioritise different EPS bearers. Non-GBR data transmission might be reduced in order to achieve the guaranteed bit rate. The support of individual QoS classes as well as the complete functionality can be enabled or disabled on a per-BTS basis via O&M means.


93 (126)


The feature is enabled together with the RL40 features “Smart Admission Control” and “ARP Based Admission Control for E-RABs”. Each QoS class is defined by a set of operator configurable parameters.


94 (126)


7.14 Smart Admission Control (RL40) From LTE release RL40 onwards the Flexi Multiradio BTS supports smart admission control that extends the fixed-threshold-based radio admission control for guaranteed bit rate (GBR) EPS bearers and introduces a congestion supervision mechanism at the radio interface. Smart admission control enhances the resource utilisation of the BTS and keeps the radio interface in a healthy state during congestion. The radio admission control entity checks the downlink and uplink resource situation on the Physical Downlink and Uplink Shared Channels, respectively, before deciding on the admission of new GBR bearers. The transport admission control entity estimates the transmission rates of new QoS class 2, 3 or 4 bearers to be admitted to the network. During congestion the BTS triggers the release of GBR bearers, taking into account the allocation and retention priority (ARP) of each bearer. The ARP value together with the QCI priority might also be used for scheduling GBR bearers in order to align the scheduling and bearer drop behavior during congestion. Smart admission control can be enabled or disabled on a per-BTS basis via O&M means. This feature is enabled together with the RL40 features “Support of QCI 2, 3 and 4” and “ARP Based Admission Control for E-RABs”.


95 (126)


7.15 ARP Based Admission Control for E-RABs (RL40) Starting from LTE release RL40, the Flexi Multiradio BTS supports allocation and retention priority (ARP) handling during the admission control of guaranteed bit rate (GBR) and non-GBR EPS bearers. When performing admission control during bearer establishment or handover operations, the following ARP parameters are considered: · priority level · pre-emption capability · pre-emption vulnerability. During admission control the BTS first checks the radio resources. If admission of the new resource is not possible without pre-empting existing resources, and the preemption capability of the new resource has the value “may trigger pre-emption”, the BTS automatically triggers the release of existing lower-priority pre-emptable resources.


96 (126)


EPS bearers of emergency sessions are usually handled in a similar way, that is, they are prioritised according to their ARP parameter values. ARP based admission control can be enabled or disabled on a per-BTS basis via O&M means. Note that this feature is enabled together with the RL40 features “Support of QCI 2, 3 and 4” and “Smart Admission Control”.

7.16 E-RAB Modification (RL40) From LTE release RL40 onwards the operator can change the following parameters of EPS bearers: · QoS class identifier (QCI) value of a non-guaranteed bit rate EPS bearer · Allocation and retention priority (ARP) value · Aggregate maximum bit rate (AMBR) of the UE.


97 (126)


In other words, the operator has the possibility to change the QoS profile of EPS bearers dynamically. The QCI of EPS bearers with QCI value equal to five cannot be changed if this bearer is used for signalling. Furthermore, ARP changes to emergency calls are rejected.

7.17 Policy and Charging Control Closely related to QoS control is a concept called policy and charging control (PCC). The PCC framework provides operators with advanced tools for service-aware or dynamic QoS and charging control. The basic policy and charging control structure of the 3GPP packet-switched domain is defined in 3GPP Release 7 TS 23.203. LTEspecific enhancements were added in TS 23.401 and TS 23.402 in 3GPP Release 8. In the PCC context, “policy” means making real-time decisions regarding access to services or allocation and use of network resources. The PCC concept is based on PCC rules. Using relevant information received from the application function and the subscription profile repository, the Policy and Charging Rules Function (PCRF) generates or selects dynamic PCC rules on a perpacket flow and per-session basis. The PCC rules are then forwarded to the Policy and Charging Enforcement Function (PCEF) in the PDN Gateway, which ensures that the rules are enforced during the © Nokia Siemens Networks

98 (126)


packet flow. It is also possible to install predefined or static PCC rules directly to the PCEF by O&M means without involving the PCRF. Let our tutor tell you more about the role of policy and charging control. You can also move your mouse pointer over the items in the figure for a short explanation of each item.

The subscription profile repository (SPR) is where the subscriber profile (with QoS and charging-related information) is permanently stored - in a 3GPP network this is usually the home subscriber server (HSS). The Policy and Charging Rules Function (PCRF) generates or selects PCC rules on a per-packet flow and per-session basis. The application function (AF) interacts with the application that requires dynamic policy and charging control, and provides relevant information to the PCRF. The Gx and Gy interfaces are based on the IETF Diameter Credit-Control Application (DCCA) protocol. The Policy and Charging Enforcement Function (PCEF) ensures that the PCC rules received from the PCRF are enforced during the packet flow. The online charging system enables flow-based charging by providing online credit control. The offline charging system collects offline charging information and sends it to the billing domain. © Nokia Siemens Networks

99 (126)


The Gz interface is based on GPRS Tunnelling Protocol (GTP).

7.18 PCC Signalling during LTE Attach We have to remember that there are two EPS bearer connectivity options: the GTP and the IETF option. In the GTP option, where the GTP tunnel associated with the EPS bearer extends between the eNodeB and the PDN Gateway, the PCC-related signalling during LTE attach is as shown in the figure. The Serving Gateway is not involved in policy and charging control, since the GTP tunnel extends beyond this gateway. In the IETF option, however, the GTP tunnel extends to the Serving Gateway only. Over the S5/S8 interface, IETF Proxy Mobile IP (PMIP) signalling is used instead, as indicated by the blue callouts. Note that the Serving Gateway needs to receive policy and charging control information from the PCRF in this case, as indicated by the green callout. Use your mouse pointer to compare the different PCC signalling sequences © Nokia Siemens Networks

100 (126)


7.19 QoS Management Example 1 Let us next see how the QoS-related information is distributed in the Evolved Packet System when the default EPS bearer is established in connection with the LTE attach procedure. The QoS profile for the default bearer is stored in the Home Subscriber Server (HSS). During the attach procedure this information is transferred to the MME. When activating the default EPS bearer, the MME sends relevant QoS-related information to the PDN Gateway in the “Create Session Request” message and to the eNodeB in connection with the “Attach Accept” message. The eNodeB forwards the “Attach Accept” message and relevant QoS information to the UE using RRC signalling. You can examine the QoS information distributed to the various network nodes by using your mouse pointer.


101 (126)



102 (126)



103 (126)


7.20 QoS Management Example 2 (RL20 onwards) As a second example, let us assume that a dedicated EPS bearer is being established for the purpose of carrying VoIP traffic. Now, the Policy and Charging Rules Function (PCRF) network entity retreives the necessary QoS-related information from the Home Subscriber Server (HSS) and the VoIP Application Server, creates the PCC rules using this information, and sends the PCC rules to the PDN Gateway. Next, the relevant QoS information is forwarded to the UE. Finally, the eNodeB indicates whether the dedicated bearer could be allocated or not.


104 (126)


7.21 Exercise


105 (126)


7.22 Commercial Mobile Alert System (RL40) From LTE release RL40 onwards the Flexi Multiradio BTS supports the Commercial Mobile Alert System (CMAS) – a solution for broadcasting public warning messages. The MME sends CMAS notifications to the BTS using the S1AP message “WriteReplace Warning Request”. Mobile terminals in RRC IDLE or RRC CONNECTED state are informed, via paging, about the presence of CMAS notifications. The CMAS notifications are broadcast in system information block (SIB) 12. The segmentation of warning messages into consecutive system information blocks, and the autonomous adaptation of the scheduling info list in system information block 1 are also supported. In the case of S1-flex network configurations, where the Flexi Multiradio BTS can be connected to several MMEs, the BTS may receive the same CMAS notification from multiple MMEs. The BTS stops the broadcasting of notifications by using the “Kill Request” message or after the maximum number of required notifications have been broadcast. The CMAS functionality can be enabled or disabled on a per-BTS basis via O&M means.


106 (126)


7.23 ETWS Broadcast (RL40) From LTE release RL40 onwards the Flexi Multiradio BTS supports Earthquake and Tsunami Warning System (ETWS) warning delivery, under the control of the Mobility Management Entity (MME). The following notification actions are supported: · Broadcasting of a primary notification that alerts communities of an impending earthquake or tsunami · Broadcasting of secondary notifications for delivering additional information, like where to get help · Stopping the delivery of notifications. In the case of S1-flex network configurations, where the Flexi Multiradio BTS can be connected to several MMEs, the BTS may receive each warning message item from multiple MMEs. The primary notification is broadcast as soon as possible to all camping and connected UEs under the coverage of the BTS, by using repeated paging in all paging groups. The notification is broadcast in system information block (SIB) 10. The secondary notification is broadcast in a segmented manner in system information block 11, in line with 3GPP specifications. Note that the warning delivery is prioritised if there is congestion in the network. The ETWS broadcast functionality can be enabled or disabled on a per-BTS basis via O&M means.


107 (126)



108 (126)


8

LTE Charging Architecture

In a telecommunications network, charging is the function whereby information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it possible to bill the charged party at a later time (offline charging) or to interact with the charged service in real time (online charging). In offline charging, the charging information does not affect, in real-time, the service being charged. In online charging, the charging information can affect, in real-time, the service being charged. Therefore a direct interaction of the charging mechanism with bearer, session or service control is required. This is where the Policy and Charging Enforcement Function (PCEF) plays a certain role.

8.1 Offline Charging In offline charging, the charging information does not affect, in real-time, the service being charged. The charging information is transferred from the network to the billing domain (BD) after the resource usage has occurred. In the billing domain, the charging information is processed for billing purposes. In the PDN Gateway, the charging trigger function (CTF) detects chargeable events, such as bearer resource usage, and transforms each chargeable event into a charging event. From the received charging events, the charging data function (CDF) produces charging data records (CDRs) with a specified format. The CDRs are transferred to © Nokia Siemens Networks

109 (126)


the charging gateway function (CGF), which in turn generates a CDR file from a number of CDRs and forwards the file to the billing domain. Move your mouse pointer over the charging interfaces (Rf, Ga, Bp) to see where these interfaces are defined. The Evolved Packet Core charging architecture is flexible and allows the implementation of different charging functions (CTF, CDF and CGF) in the same physical network element. In the first Nokia Siemens Networks EPC release only the Bp interface will be externally visible.


110 (126)


8.2 Online Charging In online charging, the charging information may affect, in real-time, the service being charged. The charging information is transferred from the PDN Gateway to the online charging system (OCS) which performs real-time credit control. In the PDN Gateway, the charging trigger function (CTF) detects chargeable events, such as bearer resource usage, and transforms each chargeable event into a charging event. The charging events are forwarded to the online charging function (OCF) in order to check whether the network resources can still be used. The online charging function interacts with the account balance management function (ABMF) that stores and updates the number of credits on the user account, and the rating function (RF) that determines the cost of service usage according to tariffs. If the balance goes too low or the user runs out of credits, the online charging system may interrupt or terminate the service. The Gy interface between the Policy and Charging Enforcement Function (PCEF) and the online charging system is defined in 3GPP Technical Specification 23.203. The signalling is based on the IETF Diameter Credit Control Application (DCCA) framework as defined in RFC 4006.


111 (126)



112 (126)


9

Location Solutions

9.1 Support of Cell Based Location Service (RL30) In LTE release RL30, the Flexi Multiradio BTS supports location reporting of a mobile device to the MME on a cell ID level. The benefit of being able to locate a mobile device is to support mandatory regulatory services such as emergency calls and lawful interception requirements. The location reporting can be triggered either directly or by a change of serving-cell. Direct location reporting is triggered by a location report request from the MME. The Flexi Multiradio BTS then returns the global cell ID that the requested mobile device is in at that moment. Change of serving-cell based reporting is triggered either by the · S1AP location report request message from the MME, or · X2AP handover request message during a handover, or · S1AP handover request message Also, each internal cell change in Flexi BTS of a mobile device in the ECMCONNECTED state is reported to the MME.


113 (126)


9.2 OTDOA Starting from LTE release RL40, the Flexi Multiradio BTS supports the positioning method Observed Time Difference of Arrival (OTDOA). This positioning method provides greater location accuracy than cell ID based positioning. Consequently, the operator is able to provide location services with better accuracy in those situations where GPS is not working. In OTDOA the UE performs measurements on the downlink signals received from several cells, and the evolved Serving Mobile Location Center (eSMLC) calculates the UE position by using this information. Additional positioning reference symbols (PRS) are inserted in the downlink signal in order to increase the signal hearability for the OTDOA measurements. Note that a number of PRS-related parameters are operator configurable, as shown in the figure. The additional positioning reference symbols and the muting configuration may lead to decreased downlink performance. The UE and the eSMLC communicate directly by using the LTE Positioning Protocol (LPP). This signalling is transparent to the BTS. OTDOA can be enabled or disabled on a per-BTS basis via O&M means.


114 (126)



115 (126)


10 Subscriber Data Management 10.1 Subscriber Data Management

In subscriber data management the current trend is towards subscriber-centric networks and a converged subscription database solution - that is, one common database instead of separate databases for each type of network. The subsriber data management solution should also take into account that subscriber data is increasingly “dynamic”; it is constantly updated as the subscriber interacts with services, manages subscriptions and changes between environments. Furthermore, the prediction of customer needs is important. It is necessary to spot, analyse and act on events as they happen. Operators also see identity management and the managing of multiple subscriber identities as a key issue. Network-agnostic identity management is the key component of tomorrow’s multi-access multi-service network. As a final observation, operators see access and authentication data as obstacles to providing seamless services between different access networks.


116 (126)


11 Network Management 11.1 Overview Nokia Siemens Networks NetAct is a network and service management framework that specifically addresses operators’ challenges in the following way when deploying LTE networks: The NetAct Operations Support System (OSS) framework provides sophisticated and field tested applications for LTE management, such as Traffica, Configurator and Optimizer. As a new approach, key operational processes will be extensively automated using self-organising network (SON) solutions. This will lead to improved visibility to network quality and end user behavior. The high level of automation will also result in OPEX savings since fewer people are needed for network planning and for operation and maintenance (O&M) activity. Also, the higher service availability and increased end-user-quality-of experience provides the potential to increase revenues. As far as evolution aspects are concerned, NetAct customers can manage LTE networks from day one using familiar applications. The NetAct framework is fieldproven and supports multi-vendor integration. Last but not least, NetAct allows network operators to manage multi-technology and multi-vendor networks seamlessly using a single network management system


117 (126)


11.2 Self-Organising Network (SON) Solutions Due to the large number of network parameters and the expanding number of eNodeB nodes, it is necessary to increase the degree of automation during the rollout and operation of LTE networks in order to decrease operational expenditures. This observation resulted in the following self-organising network solutions: Self-configuration effectively means “plug and play” behavior when installing network elements in order to reduce costs and simplify the installation procedure. Self-optimisation means automatic parameter optimisation based on network monitoring and measurement data obtained from various network nodes and terminals. Self-healing means that the system detects problems itself and mitigates or solves these problems to avoid unnecessary user participation and to significantly reduce maintenance costs. You can learn more details by using your mouse pointer. Note that regardless the degree of automation, the operator will always be the final control instance.


118 (126)


11.3 Hybrid SON Concept Nokia Siemens Networks is developing a hybrid solution where some of the selforganising functions and algorithms are executed at the NetAct application level while others are done in the eNodeBs. The task division is roughly as follows: · Simple, short-term optimisation tasks are performed autonomously in the eNodeBs · Complex, mid- and long-term optimisation tasks are performed by the network operator using NetAct Optimizer. The optimisation framework is flexible; various scenarios will be supported.


119 (126)


11.4 PRACH management (RL30) The LTE release RL30 introduces an automatic configuration of settings of Physical Random Access Channel (PRACH). The benefit for the operator is that less effort is required in setting and optimizing PRACH parameters in the O&M system. NetAct Optimizer automatically assigns the following PRACH parameters: · cyclic shift · configuration index · frequency offset · root sequence

The algorithm uses different information as an input. This feature is embedded in a framework called "self-organizing network (SON) LTE BTS auto-configuration“. The framework provides automated configuration of Flexi Multiradio BTSs via NetAct. More information can be found in the course "NetAct for LTE".


120 (126)


11.5 Automatic interface alarm correlation (RL30) In LTE release RL30, the automatic interface alarm correlation feature minimizes the number of alarms that are raised in case of a connection loss in a central interface or node. Depending on the failed connection or node, a single failure can cause, in a worst case, 2000, or even more, alarm events which need to be acknowledged by the operator in NetAct. In the flat architecture of the LTE, it is more important to aggregate alarms than in legacy systems, because there are many more common interfaces like S1 and X2 that can cause many alarms. By using alarm correlation instead of hundreds or thousands of alarms, only one dedicated alarm is sent to the operator in a case of interface problems. The solution consists of: · The Flexi Multiradio BTS providing correlation information in the alarm message, and · NetAct providing the basic correlation rules for appropriate LTE alarms.


121 (126)


Whenever more than a configurable number of alarms with the same correlation information is received, then NetAct suppresses the original alarms and triggers a new common alarm for all the failures targeted to this type of object.

11.6 LTE Timing Advance Evaluation In LTE release RL30, the timing advance measurements can be used by the operator for network planning and optimization tasks. With the introduction of timing advance measurements the operator is able: · to locate areas in the cell with high and low traffic volumes · to plot a generic geographic user distribution in the cell, and · to obtain dropped call statistics to find areas with a high drop rate These are possible within the limited scope and accuracy of timing advance measurements. Timing advance alone is not accurate enough to provide locationbased services.


122 (126)


11.7 Configurable cell trace content In LTE release RL30, the operator is able to filter cell traces on a message level. The operator can choose which messages will be taken into the trace record. It could mean that only the handover messages are recorded. The trace depth is based on the maximum trace depth setting and the trace content can be reduced with this feature. The feature is a configurable alternative to the standard 3GPP-defined trace depths. The configuration of trace content is based on a simple input format with specific markings of the messages which are collected for the trace record. These settings will be stored in a file. For each trace configuration in NetAct Trace Viewer, it is possible to apply selected trace settings individually. This means that either maximum trace depths or a specific trace profile can be applied. For operator usage, there are some pre-defined templates for certain use cases.


123 (126)



124 (126)


12 Configuration Management 12.1 System Upgrade with Backward Compatibility In LTE release RL30, the system upgrade with backward compatibility enables a smooth upgrade from a major software release to the next release in the overall network. This includes upgrading the following elements: · Flexi Multiradio BTS · NetAct with all LTE relevant applications including Optimizer, Trace Viewer, the Northbound interfaces, and the iOMS The upgrade is done remotely and requires very little manual intervention. It supports the following functionalities: · One-step software upgrade to the next major version, without intermediate versions. · All operator-configured data are maintained in the system, including Flexi Multiradio BTS configuration, operator specific adaptations in NetAct or BTS system module, and performance management configuration · System data is stored and a backup is made; the data includes items such as measurements, user accounts, and certificates · scripts are also updated · NetAct and BTS system module support both releases – the old and the new – to ensure that a mixed configuration works · The LTE system-wide upgrade is defined as top-down sequence · The downtime of a network entity during the upgrade is reduced to the activation of the new software · Automatic or manual fallback to the original release if the upgrade fails · A delta-description lists all differences to the old version


125 (126)



126 (126)

scribd-download.com_lte-e2e-part2.pdf

Recommend Documents