LTE Transport
Tutorial
Nokia Siemens Networks
Radio Transport Product Management
Confidential
____________________________________________________________________________
Version Date Author
4.0 24-Jun-2010 Torsten Musiol
Terminology ...5
Glossary of Acronyms ...6
1. Introduction ...9
2. LTE Basics...12
2.1 Network Architecture Evolution ...12
2.2 Protocol Stacks...15
2.2.1 User Plane...15
2.2.2 Control Plane...15
2.3 Intra-LTE Handover ...16
2.4 Transport Performance Requirements ...18
2.4.1 Throughput (Capacity) ...18
2.4.2 Delay (Latency), Delay Variation (Jitter)...23
2.4.3 TCP Issues ...25
3. Mobile Backhaul Architecture for LTE ...26
3.1 X2 Connectivity Requirements...26
3.2 Implementation Options ...28
3.2.1 L2 vs. L3 ...28
3.2.2 Ethernet Based Backhaul Network...29
3.2.2.1 E-Line ...30
3.2.2.2 E-LAN ...31
3.2.2.3 E-Tree ...32
3.2.2.4 Comparison...33
3.2.3 Implementation Examples...34
3.3 Transport Service Attributes...36
3.3.1 Capacity ...36
3.3.2 Performance ...36
3.4 Traffic Differentiation with VLAN and IP Addressing ...37
3.4.1 Generic eNB IP Addressing Model...37
3.4.2 Network Reference Configurations ...41
3.5 Transport Redundancy ...44
3.5.1 General...44
3.5.2 SCTP Multi-homing...45
3.6 Base Station Co-location ...46
4. LTE Transport Interfaces and Protocols ...47
4.1 Ethernet ...47
4.2 IP ...48
4.2.1 General...48
4.2.2 MTU Size Issues...49
4.2.2.1 Enforcement of lower MTU size ...50
4.2.2.2 IP Fragmentation and Reassembly ...51
4.2.2.3 Ethernet Jumbo Frames...52
4.2.3 IPv6 ...53
5. QoS...55
5.1 End-to-End QoS ...55
5.2 Transport QoS Features ...56
5.2.1 Traffic Prioritization on IP Layer ...56
5.2.2 Traffic Prioritization on Ethernet Layer ...57
5.2.3 Packet Scheduling ...58
5.2.4 Traffic Shaping ...59
5.3 Mapping RRM QoS onto Transport QoS...60
6. Synchronization...62
6.1 Synchronization from GPS...62
6.2 Synchronization from Transport Network ...63
6.2.1 IEEE1588-2008 Precision Time Protocol (Timing-over-Packet) ...63
6.2.2 Synchronous Ethernet ...65
6.3 Solutions for Co-location with Legacy Equipment ...66
6.3.1 Synchronization from PDH interface ...66
6.3.2 Synchronization from 2.048MHz signal ...67
7. Transport Security...68
7.1 General...68
7.2 X2 Issues...70
7.3 IPsec Tunnel Mode vs. Transport Mode...72
7.4 Security Associations and IP Addressing ...72
7.5 Public Key Infrastructure (PKI)...75
8. Transport Operability...76
8.1 Ethernet OAM ...76
8.2 Transport Plug’n’Play (SON)...77
8.2.1 Auto-Connection ...77
8.2.2 Auto-configuration...79
9. Flexi Transport Sub-Modules for LTE...80
10. List of Features ...83
11. References ...84
How to Read this Document
This document is intended to support LTE pre-sales activities. It describes standardized techniques as well as NSN concepts, recommendations and solutions.
Any statements regarding release planning in this document are of informative character only and are subject to change. This document will be further revised as product planning progresses.
Terminology
Control Plane The protocols, functions and interactions that are related to the control of the system
DiffServ The Differentiated Services protocol which provides a mechanism for applying Quality of Service in IP [RFC2474], [RFC2475]
eNodeB A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. It terminates the S1 interface towards the MME and Serving GW. This is usually abbreviated to eNB.
EPS Bearer An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. In the case of GTP-based S5/S8 an EPS bearer runs between a UE and a PDN GW; in the case of PMIP-based S5/S8 it runs between a UE and a Serving GW.
Long Term Evolution The name given to the work on the evolution of the UTRAN for the next 10 years and beyond working towards a high data rate, low latency and packet-optimized radio-access technology.
Mobility Management Entity The C-plane functional element in the EPC that manages and stores UE context (UE/user identities, UE mobility state, user security parameters). It is responsible for the management of identities, checking authorization, bearer management, mobility management and NAS termination.
Network Domain Security The security mechanism employed to protect IP traffic in 3GPP and fixed broadband core networks.
Packet Data Network Gateway The Packet Data Network (PDN) Gateway (P-GW) is one of the gateways that provide the U-plane gateway functionality for the EPC. The P-GW terminates the SGi interface to the PDN. Its functionality includes policy enforcement and charging support.
Quality of Service The concept of providing varying levels of service depending on a variety of factors such as resources available, priority of data, subscription paid.
Serving GW The Serving Gateway (S-GW) is one of the gateways that provide the U-plane gateway functionality for the EPC. The S-GW is the gateway to the E-UTRAN and serves as a mobility anchor point.
System Architecture Evolution This is name given to the work on the evolution of the core network system architecture for the next 10 years and beyond towards a high data rate, low latency and packet-switched system supporting
multiple radio access networks.
Transport Plane The protocols, functions and interactions related to transport of C-plane and U-C-plane data over the interfaces between network nodes of the E-UTRAN and EPC (and within the E-UTRAN and EPC).
User Plane The protocols, functions and interactions related to the transport and manipulation of user data in the system.
Glossary of Acronyms
AAA Authentication, Authorization and Accounting
AMBR Aggregate Maximum Bit Rate
ANR Automatic Neighbor Relation
ARP Allocation and Retention Priority
BTS Base Transceiver Station
BTSEM BTS Element Management application
BTSOM BTS OAM protocol
BTSSM BTS Site Manager
CA Certificate Authority
CAC Connection Admission Control
CAPEX Capital Expenditure
CBS Committed Burst Size
CDN Content Distribution Network
CESoPSN Circuit Emulation Service over Packet Switched Network
CIR Committed Information Rate
CoMP Cooperative Multipoint
DL Downlink
DSCP DiffServ Code Point
EBS Excess Burst Size
EIR Excess Information Rate
EMS Element Management System
eNB Evolved Node B (also abbreviated as eNodeB)
EPC Evolved Packet Core
EPS Evolved Packet System
E-UTRAN Evolved Universal Terrestrial Radio Access Network
EVC Ethernet Virtual Connection
FD Frame Delay
FDD Frequency Division Duplex
FDV Frame Delay Variation
FFS For Further Study
FLR Frame Loss Ratio
FM Fault Management
FTM Flexi Transport sub-Modules
GGSN Gateway GPRS Support Node
GPS Global Positioning System
GTP GPRS Tunneling Protocol
HO Handover
IDU Indoor Unit
IETF Internet Engineering Task Force
IKE Internet Key Exchange
L2 Layer 2
LTE Long Term Evolution
MAC Medium Access Control
MBH Mobile Backhaul
MBMS Multimedia Broadcast/Multicast Service
MBR Maximum Bit Rate
MEF Metro Ethernet Forum
MEG Maintenance Entity Group
MEP Maintenance End Point
MIMO Multiple Input Multiple Output
MLO Multi-Layer Optimization
MME Mobility Management Entity
MTU Maximum Transmission Unit
MWR Microwave Radio
NDS Network Domain Security
NE Network Element
NGMN Next Generation Mobile Networks
NMS Network Management System
NRT Non Real Time
NTP Network Time Protocol
O&M Operations and Maintenance
OAM Operation, Administration, Maintenance
ODU Outdoor Unit
OPEX Operating Expenses
PD Packet Delay
PDCP Packet Data Convergence Protocol
PDN Packet Data Network
PDN-GW Packet Data Network (PDN) Gateway
PDV Packet Delay Variation
PKI Public Key Infrastructure
PLR Packet Loss Ratio
PRC Primary Reference Clock
PS Packet Switched
PSK Pre-Shared Key
PW Pseudo-Wire
QoS Quality of Service
RLC Radio Link Control
RNC Radio Network Controller
RNL Radio Network Layer
RRM Radio Resource Management
RT Real Time
RTT Round-Trip Time
SA Security Association
SAE System Architecture Evolution
SAE-GW System Architecture Evolution Gateway
SCTP Stream Control Transmission Protocol
SDF Service Data Flow
SDU Service Data Unit
SEG Security Gateway
SFN Single Frequency Network
S-GW Serving Gateway
SGSN Serving GPRS Support Node
SLA Service Level Agreement
SLS Service Level Specification
SPQ Strict Priority Queuing
SW Software
TDD Time Division Duplex
TNL Transport Network Layer
UE User Equipment
UL Uplink
UNI User Network Interface
VPLS-TE Virtual Private Line Services Transport Equipment
VPN Virtual Private Network
1. INTRODUCTION
LTE refers to the Long Term Evolution of the 3GPP radio access technology and is considered the successor of the current UMTS system with the rollout anticipated to begin with trials in 2009. The work in 3GPP is closely aligned to the 3GPP System Architecture Evolution (SAE) study which examines the overall evolved 3GPP architecture and its operation in conjunction with the Evolved UTRAN (E-UTRAN). SAE work in 3GPP has been renamed into Evolved Packet Core (EPC). Together EPC and LTE form Evolved Packet System (EPS).
Whereas the Radio Network Layer (RNL) is being specified by 3GPP, the Transport Network Layer (TNL) for LTE is nowhere defined consistently. Contributing standardization bodies are:
• IETF
• IEEE
• ITU-T
• Metro Ethernet Forum (MEF)
Transport
Network
Layer
Radio
Network
Layer
SAE-GW MMEO&M eNB
UE
Figure 1 Standardization landscape
To some extent, the Next Generation Mobile Networks (NGMN) consortium of mobile operators aims at closing the gap. Naturally, there is a lot of room for innovation and a need for education.
The following figures indicate a number of Frequently Asked Questions and corresponding misconceptions which deserve clarification.
eNB
What about performance impact with IPSec?
Ethernet / IP
What transport capacity is required? What transport delay is acceptable? What are thesynchronization requirements? Point-to-point or Multipoint-to-Multipoint Ethernet? How to connect automatically (plug‘n‘play)? How to implement QoS? How to share
transport with a co-sited base station?
O&M MME SAE-GW How should IP addresses and VLANs be used Ethernet switch or IP router? Is Transport security needed? Figure 2 FAQ’s eNB
Ethernet / IP
Transport capacity has to be >500Mbit/sper eNB Transport delay has to be <5ms Subscriber security is sufficient Phase synchronization is always needed All transport nodes have to be IP routers O&M MME SAE-GW Adjacent eNBs need
to have direct links (fully meshed network)
Multipoint-to-Multipoint is more
suited to flat architecture
Figure 3 Common misconceptions
This document provides an overview of generic LTE transport concepts and issues with special focus on the E-UTRAN, i.e. mobile backhaul (MBH) solutions for LTE Base Stations. Related features and
functionalities of the NSN LTE solution will be described. The document aims at providing answers to the questions above, while also indicating NSN recommendation if there are multiple implementation
The NSN LTE FDD product roadmap comprises the following stages:
• RL09 provides basic connectivity functions (LTE protocol stack, IP/Ethernet interface)
• RL10 supports in particular transport QoS, transport security and a variety of synchronization options
• RL20 provides support for base station co-location and operability enhancements
• RL30 and beyond will focus on transport resilience, IPv6 and other optimizations
Features are also linked to TDD releases (RLxxTD) following a similar logic.
This document is focused on features planned until RL20 / RL15TD. However, some functionality intended for later releases is also included. In general, the functionality of a next release extends the functionality of the previous release rather than changing it. Where this is not the case it will be highlighted.
2. LTE BASICS
2.1 Network Architecture Evolution
Two general trends can be observed which have a great impact on the architecture of mobile networks: First, circuit switched (CS) connectivity services will be gradually replaced by packet switched (PS) services. This implies in particular that legacy voice services will sooner or later disappear and be replaced by Voice-over-IP (VoIP) service.
Secondly, mobile networks evolve towards flat architectures, leading to more favorable economies with the ever-increasing amount of user traffic. With 3GPP Rel.6 (WCDMA), both the Radio Access Network (RAN) and the Core Network (CN) were built hierarchically. The RAN was composed of the base station (NodeB, NB) and the Radio Network Controller (RNC) and the CN of the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). In a first evolution step (3GPP Rel.7), the concept of “direct tunnel” between RNC and GGSN has been introduced, so that user plane (U-plane) traffic can bypass the SGSN (“flat” CN). In a next step, pioneered by NSN, RNC functions have been merged into the I-HSPA base station (iNB, “flat” RAN).
NB RNC SGSN GGSN Internet 3GPP Rel. 6 / HSPA Direct tunnel 3GPP Rel. 7 / HSPA Internet Direct tunnel 3GPP Rel. 7 / Internet HSPA
Internet
NB
iNB
Figure 4 Evolution towards flat network architecture
The LTE network architecture (Figure 5) introduced with 3GPP Rel.8 is built upon the same principles. Consequently, the CS part has been eliminated completely.
Direct tunnel
Internet
eNB SAE-GW
MME 3GPP Rel 8 / LTE/SAE
Figure 5 LTE network architecture The LTE network elements are as follows:
• The Mobility Management Entity (MME) is the control plane (C-plane) functional element in EPC. The MME manages and stores the UE context, generates temporary identities and allocates them to UEs, authenticates the user, manages mobility and bearers, and is the termination point for Non-Access Stratum (NAS) signaling.
• The Serving Gateway (S-GW) is the user plane (U-plane) gateway to the E-UTRAN. The S-GW serves as an anchor point both for inter eNodeB (eNB) handover and for intra 3GPP mobility, i.e. handover to and from 2G or 3G.
• The Packet Data Network Gateway (P-GW) is the U-plane gateway to the PDN, e.g. the Internet or the operator’s IP Multimedia Subsystem (IMS). The P-GW is responsible for policy enforcement, charging support, and user’s IP address allocation. It also serves as a mobility anchor point for non-3GPP access.
• Most often, the S-GW and P-GW functions are combined in one network element, often called
SAE Gateway (SAE-GW).
• The E-UTRAN contains only the base station, eNB, which provides the air interface to the UE.
Evolved Packet System (EPS) reference points are specified in [TS36.300], [TS23.401] and [TS23.402]. The following ones apply to the E-UTRAN:
• S1-MME Control plane reference point between eNB and MME
• S1-U User plane reference point between eNB and the S-GW
• X2 Control & user plane reference point between two eNBs
eNBs can be connected to each other via the X2 reference point and connected to MMEs and S-GWs via the S1-MME/S1-U reference points. A single eNB can be connected to multiple MMEs and multiple S-GWs.
O&M traffic, a.k.a. Management plane (M-plane) is not specified by 3GPP, but yet to be considered. A fourth functional plane shall be introduced here: The Synchronization plane (S-plane). Terminated by respective applications in the network (synchronization grandmaster) and in the base station
(synchronization slave), this concept can easily be understood since synchronization traffic flowing over the IP transport network has its own set of QoS requirements and should be distinguished from U/C/M-plane traffic correspondingly (see chapter 6.2).
Inter-eNB connection (X2) IP NMS X2 U/C-Plane M-Plane S1 U-Plane S1 C-Plane MME SAE-GW eNB 2 eNB1 S-Plane Synchronization Grandmaster (optional)
Figure 6 LTE traffic types
2.2 Protocol Stacks
All protocol stacks for user (U), control (C), management (M) and (optionally) synchronization (S) planes are based on IP. This section outlines the protocol stacks of the S1 and X2 interfaces.
2.2.1 User Plane
The U-plane service layer is IP. UE mobility is achieved through tunnels which originate from the PDN-GW and are anchored at the S-PDN-GW. Within the E-UTRAN, the GPRS Tunneling Protocol (GTP-U) is used as tunneling protocol.
PDCP RLC MAC PHY User IP PDCP RLC MAC PHY Uu UE eNB S1-U UDP IP L1/L2 GTP-U S-GW UDP IP L1/L2 GTP-U eNB X2 UDP IP L1/L2 GTP-U eNB UDP IP L1/L2 GTP-U
Figure 7 User-plane protocol stacks
2.2.2 Control Plane
Within the E-UTRAN, SCTP is used to carry the control plane protocols (“Application Protocols”) S1-AP and X2-AP. SCTP has been used previously to carry NBAP over IP (Iub/IP).
PDCP RLC MAC PHY RRC PDCP RLC MAC PHY Uu UE eNB S1-MME IP L1/L2 MME SCTP IP L1/L2 NAS RRC S1-AP SCTP S1-AP eNB X2 IP L1/L2 eNB SCTP IP L1/L2 SCTP X2-AP X2-AP
Figure 8 Control-plane protocol stacks
2.3 Intra-LTE Handover
Intra-LTE handover (HO) can be performed over the S1 interface (“S1 handover”) or X2 interface (“X2 handover”). S1 handover is always required for MME relocation. With X2 handover, DL data forwarding between Source eNB and Target eNB will be optimized. Furthermore, most of the C-plane messages are exchanged directly between the involved eNB’s, so the MME processing load will be reduced
significantly.
Implications on the Mobile Backhaul Network will be elaborated in the following. In principle, the considerations apply similarly to both S1 and X2 handover. Since the X2 interface is expected to be present in many cases (X2 is required for ANR), this will be analyzed in more detail.
During the handover procedure the radio link is interrupted for a short moment (30…50ms). DL packets arriving at the Source eNB will be forwarded to the Target eNB via the (logical) X2 interface until the S1 path has been switched to the Target eNB (Hard Handover).
S1-u S-GW Target eNB Source eNB
Before
S1-u S-GW Target eNB Source eNBAfter
S1-u S-GW Target eNB Source eNBDuring
X2-uFigure 9 Handover over X2 - Principle
In the first phase (1) of the handover (see Figure 10, left side), the DL traffic destined to the Source eNB fills the normally lightly used Source eNB UL path (asymmetric user traffic and symmetric backhaul capacity DL/UL assumed). The duration of phase (1) T1 is determined by C-plane processing (including transport latency) and may be significantly longer than the air interface interruption time.
In the second phase (2) (see Figure 10, right side), the Target eNB connection may be temporarily congested if many handovers are taking place simultaneously and DL packets are already arriving through the S1 path to the Target eNB while X2 packets are still in transit. This “overlap time” T2 is mainly given by the X2 transport latency, assuming S1 latency toward Source eNB and Target eNB are almost equal. If congestion occurs packets may be queued (and potentially QoS aware dropped) at the affected transport node(s). But even if the X2 traffic goes completely along with S1 traffic (T2 ~ S1 UL latency + S1 DL latency), the probability and duration of such bursts will be very limited.
As a conclusion, the capacity need for X2 is very small compared to S1. Analysis of the mobility model resulted in 2%…3% extra capacity.
S1-u S-GW Target eNB Source eNB During HO (1) S1-u S-GW Target eNB Source eNB During HO (2) X2-u
2.4 Transport Performance Requirements
2.4.1 Throughput (Capacity)
Cell peak rates will increase dramatically with LTE. This is mainly due to larger available bandwidth (max 20MHz per cell compared to 5MHz with WCDMA). It should be noted, however, that HSPA evolution will also bring multi-carrier modes, leveling this advantage at least partly.
Maximum cell peak rates of 150Mbit/s downlink (64QAM 2x2 MIMO) and 75Mbit/s uplink (64QAM single stream) are available for a 20MHz configuration (ref. [LTE for UMTS], chapter 9.2, Table 9.3 and 9.4). DL/UL peak rates of 172Mbit/s / 58Mbit/s have often been used for marketing purposes, but are actually not achievable since the code rate 1/1 is not defined by 3GPP.
It should also be noted that the cell peak rates are achievable only under ideal air interface conditions, i.e. very close to the base station (up to 20% of cell range, corresponding to 4% of cell area) and without interference from other cells.
Max. peak data rate
M b p s LTE 2x20 MHz (2x2 MIMO LTE 2x20 MHz (4x4 MIMO Downlink Uplink 350 300 250 200 150 100 50 0
As important as the cell peak rate is the cell average capacity (Figure 12). Average downlink cell spectral efficiency has been determined as ~1.5…1.7 bit/s/Hz in macro cell deployment with three sectors and 2.4…2.9 bit/s/Hz in micro cells with one sector (based on 3GPP simulations, 10MHz bandwidth, ref. [LTE for UMTS], Figure 9.12). It should be noted that this describes the cell peak capacity under average conditions, not an averaging over time.
The spectral efficiency also varies with the available bandwidth. For further consideration in this chapter, macro cell configurations with a spectral efficiency of 1.7 bit/s/Hz downlink and 0.7 bit/s/Hz uplink are assumed which is a good approximation for 10MHz and 20MHz bandwidth.
Average throughput (macro cell, 20 MHz)
M b p s LTE (2x2 MIMO), 20 MHz carrier LTE 4x4 MIMO, 20 MHz carrier 60 50 40 30 20 10 0 Downlink Uplink
Figure 12 Cell average capacity
The required transport capacity can be dimensioned with two different approaches: 1) Dimensioning based on user traffic profile (recommended)
2) Dimensioning based on air interface capabilities
Dimensioning based on the user traffic profile requires planning data from the operator. It can be tailored to the actual needs and allows QoS parameters to be taken into account. On the other hand,
dimensioning based on air interface capabilities provides a simple and straightforward alternative if the traffic profile is not available and should be sufficient for initial planning considerations. This approach will be elaborated further in this chapter. Note that the considerations herein refer to the eNB backhaul interface only. Depending on the traffic profile, statistical multiplexing gain could reduce the total capacity requirements at aggregation points.
For “translating” the capacity at the air interface into an equivalent capacity need at the transport (backhaul) interface of the eNB, air interface overhead has to be subtracted, while transport overhead has to be added.
GTP-U (without header extension) 8 bytes
UDP 8 bytes
IPv4 (transport) 20 bytes
IPSec ESP Header (SPI/Sequence Number) 8 bytes
AES Initialisation Vector 16 bytes
ESP Trailer (2-17 bytes, incl. 0-15 padding bytes, average 8 bytes) 10 bytes
IPSec Authentication (HMAC-SHA-1-96) 12 bytes
IPSec Tunnel mode IP header 20 bytes
Ethernet higher layer (incl. 4 bytes for VLAN) 22 bytes
Eth. Inter Frame Gap, Preamble/SFD 20 bytes
Total transport overhead 144 bytes
Table 1 Transport overhead (with IPv4 and IPsec)
For a typical traffic profile with 50% small (60 bytes), 25% medium-size (600 bytes) and 25% large (1500 bytes) packets, the transport overhead can be estimated as ~25% with IPv4 and IPsec (~15% without IPsec). After subtracting the air interface overhead (PDCP/RLC), 20% (with IPsec) has to be added to the data rate at the air interfaces to calculate the corresponding transport capacity (15% without IPsec).
If N is the number of cells of one eNB site and Cpeak and Cavrg denote the peak and average capacity of one cell, the following main concepts can be distinguished (example in Figure 13 with 3 cells):
• „All-Average“
The backhaul connection supports the aggregated average capacity of all cells. Ctrs = N x Cavrg
• „All-Average/Single-Peak“
The backhaul connection supports the aggregated average capacity of all cells and the peak capacity of one cell, whatever value is greater.
Ctrs = MAX (N x Cavrg ; Cpeak)
• „All-Peak“
The backhaul connection supports the aggregated peak capacity of all cells (“non-blocking”). Ctrs = N x Cpeak
C e ll p e a k Cell average e N B tr a n s p o rt
All-Average
All-Average/
Single-Peak
Peak Rate!All-Peak
O v e rb o o k in gFigure 13 Transport capacity dimensioning scenarios
In most cases, “All-Average/Single-Peak" is a reasonable trade-off between user service capabilities and transport capacity requirements, which may have a great impact on the operating costs. With that
approach, advertised user service peak rates up to the cell peak rate can be (momentarily) supported in one cell. The advertised maximum user service (average) rate will be, however, only a fraction of the cell peak rate. It is mainly driven by fixed broadband user experience (xDSL service rates) and applications and will be enforced by LTE QoS parameters. This also means that multiple users can be supported with that rate simultaneously. With service differentiation, different maximum rates could be applied to
different users, i.e. premium users could be served with highest rates. If the number of users is (initially) low, transport costs could be reduced even further if the maximum user service (average) rate will be applied for dimensioning instead of the cell peak rate. In summary, „All-Average/Single Peak“ is a good trade-off in general, but it may be under-dimensioned for hot spots where users are located close to the antenna in multiple cells of the same eNB, and it may be over-dimensioned for sites with low utilization. The “All-Peak” concept will always lead to over-dimensioning, thus usually extra costs. However, if fiber is available at eNB sites, the incremental cost impact may be tolerable. So, there will be cases where the operator requires that the transport sub-system shall be no bottleneck at all.
As an example for the “All-Average/Single-Peak” concept, a 1+1+1 10MHz 2x2MIMO configuration is shown in Figure 14.
Air
Interface eNB
90
30
Ethernet layer, with IPsec Transport
Interface 3 cells, 10MHz
DL 17 Mbit/s net PHY average rate per cell UL 7 Mbit/s net PHY average rate per cell
DL 75 Mbit/s net PHY peak rate per cell (64QAM 2x2 MIMO) UL 25 Mbit/s net PHY peak rate per cell (16QAM)
75
25
+20%
Figure 14 Example: “All-Average/Single-Peak” 1+1+1 10MHz
The maximum configuration with Flexi Multiradio BTS is the “All-Peak” scenario with a 2+2+2 20MHz 2x2MIMO air interface as shown below. It should be noted that with a single Gigabit Ethernet interface at the eNB the DL transport capacity is limited to 1Gbit/s, so the theoretically possible air interface capacity cannot fully be utilized.
Air Interface eNB 1000 360 830 300
Ethernet layer, with IPsec Transport
Interface
+20%
6 cells, 20MHz
DL 150 Mbit/s net PHY peak rate per cell (64QAM 2x2 MIMO) – transport capacity limited UL 50 Mbit/s net PHY peak rate per cell (16QAM)
Figure 15 Example: “All-Peak” 2+2+2 20MHz
As stated in chapter 2.3, the capacity need for Intra-LTE handover (over S1 or X2 U-plane) is very small compared to S1 U-plane traffic (2%…3%).
Also, M-plane (~1Mbit/s) and C-plane (~0.3Mbit/s) capacity requirements are negligible compared to S1 U-plane.
2.4.2 Delay (Latency), Delay Variation (Jitter)
Delay requirements originate from both user services (U-plane end-to-end delay / delay variation for VoIP, web surfing, file transfer, gaming, streaming, email, etc.), radio network layer protocols (C-plane) and synchronization (S-plane).
U-plane
U-plane delay requirements are determined by user service quality expectations. Obviously, delay requirements are important for interactive services (impact on response time, see Figure 16). However, there is also a relationship between U-plane delay and throughput performance if the user service is based on TCP (see chapter 2.4.3).
Figure 16 U-plane latency requirements
With respect to LTE system performance, less than 15ms round-trip time (RTT) can be achieved with pre-allocated resources, ~20ms including scheduling (ref. [LTE for UMTS], chapter 9.7). This can be verified with ping delay measurements starting from the UE, where the server is located near the SAE-GW (ignoring processing delays in the IP stacks and ping application). In contrast to GSM and WCDMA, the relative contribution of the mobile backhaul delay to the RTT has become significant and thus should be treated with special care. It is important to note that each 500km one-way distance between a base station and a usually centralized SAE-GW contribute 5ms to the RTT. This is only taking into account the unavoidable fiber delay (~200,000km/s is the speed of light in glass). Including the delay introduced by intermediate transport nodes, the transport part of the RTT can easily exceed the radio part.
In addition to delay (latency), also delay variation (jitter) has to be considered. Both the LTE air interface (scheduler) and the transport network contribute to the end-to-end jitter. Real-time end user applications (e.g. VoIP, audio/video streaming) are usually designed so that they can tolerate jitter in the order of 10…20ms, using a properly dimensioned jitter buffer. Network dimensioning and in-built QoS
mechanisms have to assure that the end-to-end delay and delay variation budget of supported applications are not exceeded.
In principle, the user service related considerations above apply to both S1 and X2. As described in chapter 2.3, DL packets during handover arriving at the Source eNB will be forwarded to the Target eNB, i.e. will take a longer route. Basically, implementing X2 latency significantly less than the radio link
interruption time (30…50ms) would have no benefit since those packets would have to wait at the Target eNB anyway. Most user applications will tolerate such a very short-term delay increase.
C/M-plane
In contrast to WCDMA, where RNL related latency requirements are imposed by a number of RAN functions over Iub/Iur (e.g. Macro-Diversity Combining, Outer Loop Power Control, Frame
Synchronization, Packet Scheduler), LTE transport latency requirements are mainly driven by user services (U-plane). In particular, most of the handover messaging is performed in the latency-insensitive preparation phase. C-plane protocol timers give implicitly an upper bound for the S1/X2 transport RTT (50ms default, configurable 10…2000ms).
S-plane
A specific requirement for delay variation (jitter) applies if Precision Time Protocol (PTP) based on IEEE1588-2008, a.k.a. Timing-over-Packet, is used for eNB synchronization (see chapter 6.2.1).
2.4.3 TCP Issues
The Transmission Control Protocol (TCP) is designed to provide reliable transport for packet data. Today TCP is used for 80-90% of all packet traffic in the internet. TCP is typically used for applications and their respective protocols where reliability is important, e.g. web browsing (HTTP), Email (SMTP) and file transfer (FTP). Due to its acknowledgement mechanism, a single TCP connection is rate limited by the ratio between the TCP window size and the RTT. Given a standard 64KB TCP receive window size (RFC793), 20ms RTT would limit the achievable service data rate at ~25Mbit/s for a single TCP connection in the steady state (TCP flow control). This limitation could be mitigated with multiple concurrent TCP connections (typically the case for web browsing) and/or enlarging the receive window through TCP Window Scaling (RFC1323) which is supported by many web servers today. In particular large file transfers (music, video, SW download) will benefit from these measures, if high service rates would be offered by the operator.
20 25
Figure 17 TCP data rate in steady state vs. RTT (without Window Scaling)
Apart from the steady state, also TCP connection start-up (“TCP slow start”) and behavior after packet loss (“TCP congestion avoidance”) is affected by the RTT. With today’s browsers and web sites (average page size <1MB), it can be assumed that most of the web traffic is transferred within the slow start phase, so TCP Window Scaling will not help that much here. In any case, the transport network should be designed for low latency.
Perhaps more important in the early days of LTE is the potential impact on cell throughput performance tests which are often based on FTP. The test set-up has to be planned carefully (using Window Scaling, running multiple FTP sessions in parallel). Otherwise the transport network could be a bottleneck and distort the test results.
Content Distribution Networks (CDN) such as Akamai do not only reduce the network load but also reduce the end-to-end RTT, thus having a positive impact on the file transfer performance. For CDN supported services, the mobile network related RTT will be dominating.
3. MOBILE BACKHAUL ARCHITECTURE FOR LTE 3.1 X2 Connectivity Requirements
Mobile networks are commonly structured with respect to user densities (metropolitan areas vs. rural areas), topological requirements (highways, railways, etc.) and capacities of network elements. Respectively, eNBs should be assigned to groups (clusters) where the handover probability between eNBs belonging to the same group is high and the handover probability between eNBs belonging to the different groups is zero or low. Since all LTE protocols are built upon IP, all network elements which need to communicate with each other must be “IP reachable” (logical view). This includes in particular eNBs within the same group which have to be able to reach their adjacent eNBs via the (logical) X2 interface (Figure 18). Backbone Network Mobile Backhaul Network eNB Group eNB 11 eNB 12 eNBs with high HO probability within one group eNB 21 eNB 22 Small or no HO probability between eNB groups X2-u/c S1-u/c Edge router MME SAE-GW
Figure 18 End-to-end architecture and connectivity
X2 handover principles are explained in chapter 2.3. There is some common misconception with respect to the requirements on the transport network, which shall be analyzed here.
At a first glance, it seems obvious that it would be beneficial if the X2 “turning point” would be located close to the base stations (Near-End X2 connectivity, Figure 19). This can be implemented with Ethernet switching or IP routing functions, which implies additional CAPEX and OPEX in many cases. X2 latency would be low and X2 traffic wouldn’t load higher parts of the Mobile Backhaul Network. On the other hand, the S1 transport path should be optimized for low latency anyhow (see chapter 2.4.2). X2 latency significantly less than radio link interruption time (30...50ms) doesn’t add value. Furthermore, the amount of X2 traffic is marginal compared to S1 traffic, so the potential for savings is very limited.
Mobile Backhaul Network Backbone Network eNB eNB MME SAE-GW X2-u/c S1-u/c
Figure 19 Near-End X2 connectivity
Far-End X2 connectivity (Figure 20), on the other hand, can be built on existing topologies (hub & spoke). It requires IP routing at the Far-End (Edge Router or Security Gateway) in order to limit the size of L2 broadcast domains. Also this architecture meets the latency and capacity requirements analyzed earlier.
Mobile Backhaul Network Backbone Network
eNB
eNB
MME SAE-GW
X2-u/c S1-u/c
Figure 20 Far-End X2 connectivity
It can be concluded that Near-End X2 connectivity is not advantageous for 3GPP Rel.8/9/10 LTE network architectures. In particular, direct physical connections between adjacent eNBs (fully meshed network) are not required. This conclusion has to be reviewed again if functional requirements change with the architectural evolution. This might be the case when inter-site Cooperative Multipoint (CoMP) technology will be introduced (not expected before 3GPP Rel.11).
3.2 Implementation Options
3.2.1 L2 vs. L3
There is a common misconception that the mobile backhaul network for LTE requires an IP router at every transport node.
As a matter of fact, most LTE backbone networks will be IP/MPLS based. The borderline between backbone network and Mobile Backhaul Network, implemented by an Edge Router, deserves further consideration with respect to network security (Security Gateway, see chapter 7). If IPsec is applied, the Security Gateway (SEG) terminates the IP layer with the eNB at the other end, thus would be a natural termination point of the Mobile Backhaul Network.
Aggregation Network Mobile Backhaul Network Backbone Network eNB eNB MME SAE-GW L2 or L3 L3 eNB eNB MME SAE-GW Access Network L2 Figure 21 L2 vs. L3
Since the eNB supports an IP-over-Ethernet interface, both Ethernet (L2 VPN) and IP (L3 VPN) transport services would be adequate in the Mobile Backhaul Network.
In the following subchapter, an Ethernet based backhaul network implementation option shall be elaborated further.
3.2.2 Ethernet Based Backhaul Network
An Ethernet transport service can be delivered by the mobile operator itself (self-built transport network) or by another operator (a.k.a. leased line service). In both cases, service attributes and parameters are usually stated in a Service Level Specification (SLS), which in the latter case is part of a Service Level Agreement (SLA). While this makes a big difference with respect to the operator business case, it will be treated here conceptually as equal.
The following Ethernet services types will be distinguished as defined by Metro Ethernet Forum [MEF6.1]:
• E-Line
• E-LAN
3.2.2.1 E-Line
The mobile backhaul network can be purely based on L2 (Ethernet) transport. Point-to-point Ethernet Virtual Connections (EVC) between a User Network Interface (UNI) at the eNBs and another UNI at the (redundant) edge router are the straightforward solution. EVC attributes can be well controlled (see [MEF10.1]) and commercial services are commercially available in many markets, known as E-Line services (“Ethernet leased lines”). At the UNI between Mobile Backhaul and Backbone Network, the VLAN ID identifies a specific eNB.
The Edge Router (or Security Gateway) performs routing of S1 traffic between eNBs and the core nodes as well as routing of X2 traffic between eNBs within one group and between eNBs belonging to different groups. eNB Group eNB 11 eNB 12 eNB 21 eNB 22 UNI UNI UNI UNI EVC 11 (E-Line) EVC 12 (E-Line) EVC 21 (E-Line) EVC 22 (E-Line) UNI UNI UNI UNI Far-End X2 routing between eNBs within
one group and between eNB groups
Figure 22 L2 mobile backhaul network with E-Line Advantages
• Security (impact of DoS attacks is limited to one eNB)
• QoS assurance (simple traffic engineering)
• Operability (simple troubleshooting) Disadvantages
3.2.2.2 E-LAN
As an alternative, the Mobile Backhaul Network could be built based on multipoint-to-multipoint EVC’s (E-LAN service). Most appropriately, eNB’s belonging to one group should be assigned to one E-LAN (Figure 23). At the UNI between Mobile Backhaul and Backbone Network, the VLAN ID identifies an eNB group. Inside the eNB group, an eNB is identified by its MAC address.
The Edge Router (or Security Gateway) performs routing of S1 traffic between eNB’s and the core nodes as well as routing of X2 traffic between eNB’s belonging to different groups, but traffic between eNB’s within one group will be switched inside the (virtual) LAN.
eNB Group eNB 11 eNB 12 eNB 21 eNB 22 UNI UNI UNI UNI UNI EVC 1 (E-LAN)
EVC 2 (E-LAN)UNI
Far-End X2 routing between eNB groups Near-End X2 switching between eNBs of one group
Figure 23 L2 mobile backhaul network with E-LAN Advantages
• Scalability (low number of EVC’s) Disadvantages
• Security (adjacent eNB’s can be attacked)
• QoS assurance (traffic engineering is more difficult)
3.2.2.3 E-Tree
Using an E-Tree service with its root at the Edge Router means in a way a restricted E-LAN service, where inter-eNB connectivity would not be possible. So, X2 traffic would go through the Edge Router. From that perspective, it corresponds to the E-Line service.
eNB Group eNB 11 eNB 12 eNB 21 eNB 22 UNI UNI UNI UNI EVC 2 (E-Tree) EVC 1 (E-Tree) UNI UNI Far-End X2 routing between eNBs within
one group and between eNB groups
Figure 24 L2 mobile backhaul network with E-Tree
Advantages
• Scalability (low number of EVC’s)
3.2.2.4 Comparison
In the table below, E-Line, E-Tree and E-LAN services are compared.
Advantages Disadvantages
QoS assurance
(simple traffic engineering) Operability (simple
troubleshooting)
E-Line
Security
(impact of DoS attacks is limited to one eNB)
E-Tree
Scalability
(high number of EVC’s)
Security
(adjacent eNB’s can be attacked) QoS assurance
(Traffic engineering is more difficult)
E-LAN
Scalability
(low number of EVC’s)
Operability
(Troubleshooting is more complex)
Table 2 Comparison of Ethernet Services In summary,
If physical security is considered not sufficient
o E-Line or E-Tree type of Ethernet service are most suitable.
o E-LAN: The scalability advantage has to be balanced against the security disadvantage.
If physical security is considered sufficient
o E-Line or E-LAN type of Ethernet service is recommended.
o E-Tree is possible but would require configuration of host routes for each eNB at the Edge Router.
3.2.3 Implementation Examples
Figure 25 below illustrates the physical view where the Mobile Backhaul Network is further sub-divided into the Access Network and the Aggregation Network. In many cases, the Access Network is built upon a microwave radio infrastructure, whereas the Aggregation Network uses fiber rings.
The Access Network may be purely implemented on L2 (Ethernet). For scalability reasons (limiting broadcast domains), the network should be partitioned into different VLAN’s where bridging takes place at intermediate nodes (e.g. microwave radio hubs).
The Aggregation Network could also be built upon L2 (Figure 25). As one solution, VPLS-TE with one VPLS instance per VLAN can be provisioned. The logical point-to-point structure allows for sophisticated traffic engineering while high availability can be supported through physical ring or mesh topologies. This concept is also known as Multi-Layer Optimization (MLO). It aims at saving network CAPEX and OPEX through optimized application of different types of network elements, working on L1, L2 or L3 at different locations in the network topology. NSN Carrier Ethernet Transport (CET) supports this approach completely.
Backbone Network Access Network Aggregation
Network
eNB 11
eNB 12
eNB 21
eNB 22
Carrier Ethernet Transport
MME SAE-GW Ethernet switch at MWR hub location Fiber connection
L2 Access & Aggregation
IP/MPLS L3 Backbone
Figure 25 Implementation example: Carrier Ethernet Transport for Access & Aggregation, IP/MPLS for Backbone
Alternatively, the Aggregation Network could be built upon L3 (Figure 26). It should be noted, however, that the IP layers in the Aggregation and Backbone Network will be separated by a Security Gateway in case IPsec is used.
Backbone Network Access Network Aggregation
Network eNB 11 eNB 12 eNB 21 eNB 22 CET MME SAE-GW Ethernet switch at MWR hub location Fiber connection IP/MPLS
L2 Access L3 Aggregation L3 Backbone
Figure 26 Implementation example: Carrier Ethernet Transport for Access, IP/MPLS for Aggregation & Backbone
If an IP router is present at the base station site it can be used to provide routed connections between the eNB and the core nodes as well as between neighboring eNBs for X2 traffic. Alternatively, the router can be used for providing VPLS services. In this case the topology from the eNB point of view is similar to the E-Line architecture presented earlier.
3.3 Transport Service Attributes
Transport service attributes are used to describe the requirements on the transport service for eNB backhaul. It should be noted that these attributes are defined end-to-end (between eNB and core network elements) on the IP layer (L3) and have to be allocated in general to multiple parts of the network. In particular, if the transport service is (partially) provided by Ethernet Virtual Connections (EVC), these attributes have to be translated into their L2 equivalents.
Ethernet service attributes are defined by Metro Ethernet Forum [MEF6.1]. Note that these attributes are optional and a subset can be fully sufficient to define an LTE transport service.
3.3.1 Capacity
Ethernet capacity requirements are described by the service attributes
• Committed Information Rate (CIR) / Committed Burst Size (CBS) and
• Excess Information Rate (EIR) / Excess Burst Size (EBS) (optional). Dimensioning of eNB backhaul capacity (“last mile”) is described in chapter 2.4.1.
3.3.2 Performance
As explained in chapter 2.4, performance requirements on the transport service are primarily driven by user service aspects.
NSN recommends the following performance values:
Service Attribute Value Comments
L3: Packet Delay (PD) L2: Frame Delay (FD)
≤ 10 ms TCP based applications require low transport latency
L3: Packet Delay Variation (PDV) L2: Frame Delay Variation
≤ +/- 5.0 ms If Timing-over-Packet (ToP) based on IEEE1588-2008) is applied (could be relaxed otherwise) L3: Packet Loss Ratio (PLR)
L2: Frame Loss Ratio
≤ 10e-4 (0.01%)
May be different depending on user service
3.4 Traffic Differentiation with VLAN and IP Addressing
LTE132 “VLAN based traffic differentiation” (RL10, RL15TD)
LTE875 “Different IP addresses for U/C/M/S-plane” (RL10, RL15TD)
The traffic differentiation capability is tightly coupled with VLAN support and IP addressing. So, these topics will be handled here together.
Traffic differentiation can be used for various purposes. First, there may be a need to separate traffic of different planes (eNB applications) from each other for network planning reasons. E.g. M-plane traffic may need to be separated from U/C-plane traffic. S-plane traffic may require further separation. In another network scenario, traffic may be split into multiple paths which have different QoS capabilities (path selection).
The destination IP address is used as differentiation criteria. Traffic differentiation could be performed on multiple layers:
• L3: Using different IP subnets
• L2: Using different VLANs (Note: Each VLAN is terminated with a dedicated IP address at the eNB)
• L1: Using different physical paths (Note: External equipment required. Support for multiple physical interfaces is an RL30 study item)
First, the generic eNB IP addressing model shall be explained. Based on that, typical network scenarios will be elaborated.
3.4.1 Generic eNB IP Addressing Model The model is based on two basic components:
1. Binding of eNB applications to IP addresses
Binding of eNB applications to IP addresses
eNB applications (S1/X2 U-plane, S1/X2 C-plane, M-plane, S-plane) may be arbitrarily bound to
• eNB interface address(es) or
• eNB virtual address(es)
as illustrated in Figure 27 below. Interface addresses are “directly visible” at eNB interfaces, whereas virtual addresses appear behind an eNB internal IP router.
S1/X2 U-plane application S1/X2 C-plane application S-plane application M-plane application U C M S Binding to virtual address Binding to interface address Virtual IP address
eNB
Interface IP addressFigure 27 Binding of eNB applications to IP addresses
Configurations where eNB applications are bound to virtual addresses are typically used in scenarios where the transport link (VLAN, IPsec tunnel) shall be terminated with one IP address (interface IP address) while application separation on L3 is also required.
Address sharing, i.e. configuration with the same IP address, is possible. In the simplest configuration, the eNB features a single IP address for U-plane, C-plane, M-plane and S-plane.
Assignment of interface IP addresses to eNB interfaces
eNB interface IP address(es) may be assigned to different types of data link layer interfaces, which are provided by
• physical interface(s) or
• logical interface(s)
as illustrated in Figure 28. A physical interface is provided by an Ethernet port, whereas a logical interface is provided by a VLAN termination. RL10 supports one physical interface and max 4 logical interfaces. Different interfaces belong to different IP subnets.
Physical interface (Ethernet) VLAN (optional) Interface address assigned to physical interfaces
eNB
Interface addresses assigned to logical interfaceseNB
VLAN2 VLAN3 VLAN4 VLAN1 Physical interface (Ethernet) Logical interface (VLAN)Figure 29 and Figure 30 below illustrate the configuration flexibility.
Application(s) bound to interface address Application(s) bound to virtual address(es)
VLAN (optional) U C M S No or single VLAN per eNB
VLAN2 VLAN3 VLAN4 VLAN1 M S U C Multiple VLANs per eNB VLAN (optional) No or single VLAN per eNB U
C
M
S
Figure 29 IP addressing with VLAN examples (RL10)
Application(s) bound to virtual address(es)
VLAN2 VLAN3 VLAN4 VLAN1 Multiple VLANs per eNB U C M S
3.4.2 Network Reference Configurations
The figures on the next pages illustrate the eNB addressing options with some typical network scenarios (Network Reference Configurations). Those are different with respect to the underlying transport
services. Ethernet transport services may be implemented as “E-Line” or “E-LAN”. As per MEF definition, E-Line denotes an Ethernet transport service based on point-to-point Ethernet Virtual Connection (EVC), whereas E-LAN denotes an Ethernet transport service based on multipoint-to-multipoint Ethernet Virtual Connection (EVC).
The IP address concept is also related to the IPsec architecture (see chapter 7). Configurations where eNB applications are bound to virtual addresses are typically used in a scenario where the IP transport layer is separately administered (IPsec VPN). In that case, the IPsec tunnel is terminated with separate interface addresses at the eNB and SEG (Figure 34).
E-Line with single IP Address
• Simplest configuration for E-Line service
• 1 VLAN per eNB
VLAN (optional) M S U C Ethernet eNB eNB SAE-GW
~
ToP Master O&M IP Router MMEE-LAN with single IP Address
• Simplest configuration for E-LAN service
• 1 VLAN per eNB group
VLAN (optional) M S U C eNB Ethernet eNB SAE-GW
~
ToP Master O&M IP Router MMEFigure 32 E-LAN with single IP address
E-Line with L2 Differentiation
• Supporting virtually separate networks for different planes
• 2 VLANs per eNB (max 4 VLAN’s possible)
VLAN2 VLAN1 M S U C Example configuration eNB eNB Ethernet SAE-GW
~
ToP Master O&M MME IP Router EVC/VLAN 11, 12 EVC/VLAN 21, 22Figure 33 E-Line with L2 differentiation
IPsec VPN with L3 separation
• Single interface IP address for IPsec tunnel termination
IPsec Tunnel S VLAN Interface IP address Application IP address U C M IP eNB eNB MME SEG SAE-GW
~
ToP Master O&M IPsec VPN E th e rn e t IP RouterFigure 34 IPsec VPN (separate interface IP address)
S-plane binding to interface address is recommended to avoid additional jitter due to IPsec processing. It is required for on-path support to enable accurate phase synchronization (see chapter 6.2.1).
3.5 Transport Redundancy
3.5.1 General
Transport redundancy can be applied on different layers. As a basic principle, if multiple redundancy features are present, the redundancy mechanism on the lower layer needs to be faster than another mechanism on an upper layer.
Layer 1 (physical layer) based redundancy
An example is 1+1 link redundancy with MWR equipment.
L1 based redundancy doesn’t require any specific support from Flexi Multiradio BTS.
Layer 2 (data link layer) based redundancy
Ethernet switching procedures apply in case of L1 failure. One of the following concepts may be utilized:
• Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP)
• IEEE802.3ad (Ethernet Link Aggregation)
• ITU-T G.8031 (Ethernet Protection Switching)
• ITU-T G.8032 (Ethernet Ring Protection)
• Ethernet APS (RFC3619)
L2 based redundancy is a study item for RL30.
Layer 3 (network layer) based redundancy
IP re-routing, optionally supported by a routing protocol such as OSPF, applies in case of L2 link failure. IP based load balancing mechanisms, e.g. Equal Cost Multi-Path (ECMP) routing, could be utilized if supported by a corresponding edge router.
L3 based redundancy is a study item for RL30.
Layer 4 (transport layer) based redundancy
SCTP multi-homing for the C-plane is supported with RL20. See chapter 3.5.2 below.
Layer 7 (application layer) based redundancy Examples are:
• U-plane: Multiple S-GW’s available per eNB
• C-plane: Multiple MME’s available per eNB (S1 Flex)
• S-plane: Multiple clock sources available per eNB, e.g. o Multiple IEEE1588 (ToP) Grandmasters
o Multiple Ethernet links supporting SyncE
3.5.2 SCTP Multi-homing
LTE775 “SCTP multi-homing (MME)” (RL20, RL15TD)
Multi-homed nodes can be reached under several IP addresses. With this feature, the eNB supports two IP addresses at the MME for S1 C-plane termination.
SCTP (RFC4960) supports multi-homing for failover (no load-sharing). Associations become tolerant against physical interface and network failures. At the set-up of an SCTP association, one of the several destination MME IP addresses is selected as initial primary path. Data is transmitted over this primary transmission path by default. Retransmissions happen on other available paths. Path status and reachability is monitored at the SCTP layer (via data chunks and heartbeats).
The feature is primarily meant for MME interface redundancy, not path redundancy. So, C-plane termination with a single IP address at the eNB is sufficient.
eNB IP Dual interface Dual IP address MME Single interface Single IP address Figure 35 SCTP Multi-homing
3.6 Base Station Co-location
LTE649 “QoS aware Ethernet switching” (RL20, RL15TD)
At least initially, existing (macro) 2G/3G base stations sites will be reused for LTE in order to keep deployment costs reasonably low. As a consequence, there is a clear demand for 2G/3G/LTE common backhaul solutions. The most straightforward way is to upgrade legacy base stations with an Ethernet backhaul option and aggregate the traffic using an Ethernet switch. With the eNB integrated Ethernet switching function, Flexi Multiradio BTS eliminates the need for an external device.
FTLB supports three Ethernet interfaces, while two Ethernet interfaces are usable with FTIB. The aggregated Ethernet traffic is shaped according to a configurable level with respect to the available uplink capacity. eNB UNI‘(1) UNI‘(2) UNI QoS aware shaping Ethernet integrated Ethernet switch high low other base station EVC high high low low high low
Figure 36 QoS aware Ethernet switching
Synchronization solutions with co-located base stations are described in chapter 6.3
If a co-located 2G base station doesn’t support Ethernet, the Flexi Multiradio BTS integrated CESoPSN feature can be applied (RL30 study item).
4. LTE TRANSPORT INTERFACES AND PROTOCOLS 4.1 Ethernet
LTE118 “Fast Ethernet (FE) / Gigabit Ethernet (GE) electrical interface” (RL09, RL05TD)
LTE119 “Gigabit Ethernet (GE) optical interface” (RL09, RL05TD) LTE491 “FlexiPacket Radio Connectivity” (RL20, RL15TD)
Ethernet based on the [IEEE 802.3] standard will be the main eNB backhaul technology. In many cases, a network terminating device (leased line termination equipment, MWR IDU, xDSL CPE, etc.) is present at the eNB site. Electrical connection is most economical in that case which connects to the eNB via Ethernet. Flexi Multiradio BTS supports suitable indoor and outdoor site solutions.
No such device is needed in case FlexiPacket Radio is used. This MWR ODU can be directly connected and managed through the Ethernet interface of the Flexi Multiradio BTS (“zero footprint" solution). Also, if fiber access is available at the site, it can be connected directly.
The following interface types are supported (see chapter 9 for details of different Flexi Transport sub-modules):
• Gigabit Ethernet (GE) 100/1000Base-T, electrical
• Gigabit Ethernet (GE) 1000Base-SX/LX/ZX through optional SFP module, optical
The Ethernet interfaces, based on the [IEEE 802.3] standard (with type interpretation of the type length field, Ethernet II/DIX frame), support the following features:
• Full-duplex transmission mode
• Auto-negotiation and forced mode for the duplex mode (only full duplex advertised)
• Auto-negotiation and forced mode for the data rate
• Auto-negotiation and forced mode for MDI/MDIX
• VLAN tagging according to [IEEE 802.1q]
• Ethernet priority bits (p-bits) according to [IEEE 802.1p]
• IPv4 over Ethernet [RFC894]
• Address Resolution Protocol [RFC826] (ARP)
• MEF UNI Type 1 [MEF11]
It should be noted that U-plane IP packets may exceed the maximum SDU size of the Ethernet backhaul link due to additional packet overhead (GTP-U, UDP, IP/IPsec). See chapter 4.2.2.
4.2 IP
LTE664 “LTE transport protocol stack” (RL09, RL05TD)
4.2.1 General
All eNB applications (U/C/M/S-plane) are running on top of IP. Protocol stacks are explained in chapter 2.2.
User applications are hooked upon the user IP layer which is independent from the LTE application IP layer between eNB and SAE-GW. GTP-U is used as a tunneling mechanism in between. This traffic may optionally be put into yet another tunnel if IPsec (tunnel mode) is used for transport security purposes (see chapter 7). So, there may be up to three IP layers which are all independent from each other (Figure 37):
• User IP layer, terminated by user application at the UE and corresponding peer
• LTE application IP layer, terminated by LTE/SAE network element applications
• IPsec tunnel IP layer (optional), terminated by SEG (integrated in the eNB, external device at the other end)
The eNB terminates the LTE application IP layer (and optionally the IPsec tunnel IP layer). Thus, the U/C/M/S-plane address („application address“) type is in principle independent from the IPsec tunnel termination address („interface address“).
Note: The term “Transport IP layer” is ambiguous. It refers to the IP layer used by the transport network. If IPsec is not used, this would coincide with the LTE application IP layer; with IPsec it would coincide with the IPsec tunnel IP layer.
Flexi Multiradio BTS Eth MAC Eth PHY UDP G TP-U SAE-GW Server Internet Operator Services Eth MAC Eth PHY User App Eth MAC Eth PHY UDP G TP-U LTE PHY User App LTE PHY UE LTE MAC PDC P Eth MAC Eth PHY Security GW (optional) Eth MAC Eth PHY Eth MAC Eth PHY LTE MAC PDC P IP IP IP UserIP UserIP IPsec TunnelIP
LTE AppIP LTE AppIP
IPsec TunnelIP
4.2.2 MTU Size Issues
Both GTP/UDP/IP and (optional) IPsec tunneling add overhead to the user IP packet. If this has been generated with an MTU size of 1500 bytes, corresponding to the maximum SDU size of a standard Ethernet frame between Internet routers, it will not fit to the Ethernet interface SDU of the mobile backhaul network. In principle, there are three ways to solve this problem:
1. Enforcement of lower MTU size at the user IP layer
2. IP fragmentation & reassembly at the LTE application IP layer
3. Enlargement of Ethernet SDU using Jumbo Frames under the LTE application IP layer (or IPsec tunnel IP layer, respectively)
All solutions have their pros and cons. Lower MTU size cannot be enforced in all circumstances. Ethernet Jumbo Frames would solve the problem nicely but are not available everywhere. IP fragmentation & reassembly would always work but has performance issues.
4.2.2.1 Enforcement of lower MTU size
The MTU size used for packets at the user IP layer can be determined through static or dynamic configuration of the IP protocol stack SW of the UE. Unfortunately, this approach will not solve the problem completely.
With one approach, the MTU size of the IP protocol stack in the UE could be configured to a lower value. There are UE vendor specific settings (e.g. 1400 bytes in Symbian) which support this idea, but this is not mandated by any standard.
In case of IPv6, the MTU size at the UE could be set with the Router Advertisement message that the PDN-GW sends after PDN connection establishment ([RFC4861], section 4.6.4).
Alternatively, the user IP layer MTU could also be enforced through Path MTU discovery with a lower MTU properly set in the PDN-GW. This approach has been adopted with [TS29.275 v8.4.0] where a default MTU of 1280 bytes is proposed (equivalent to the minimum MTU size defined for IPv6). Unfortunately, Path MTU discovery (IPv4: RFC1191, MTU ≥68, IPv6: RFC1981, MTU ≥1280) is not mandated for neither IPv4 nor IPv6 (though strongly recommended). It’s usually performed for TCP/SCTP, but not for UDP based applications.
The impact of a lower MTU size on the transport efficiency is negligible (<1%).
eNB Eth MAC Eth PHY UDP G TP-U S-GW / PDN-GW Server Eth MAC Eth PHY User App Eth MAC Eth PHY UDP G TP-U LTE PHY User App LTE PHY UE LTE MAC PDC P Eth MAC Eth PHY Security GW (optional) Eth MAC Eth PHY Eth MAC Eth PHY LTE MAC PDC P IP IP IP S-GW_MTU PDN-GW _MTU eNB_MTU UE_MTU IP
Application IP layer Path MTU User IP layer Path MTU
Tunnel IP layer Path MTU
Us erIP
Us erIP
IPsec TunnelIP
LTE AppIP LTE AppIP
IPsec TunnelIP
4.2.2.2 IP Fragmentation and Reassembly
Without using IPsec, Fragmentation and Reassembly of LTE application IP layer packets is terminated at the eNB at one end and the SAE-GW at the other end. With IPsec, the same approach should be applied in order to avoid multiple fragmentation. In this case IPsec packets are carrying fragments, but are not fragmented themselves. The MTU size (S1-GW_MTU) would need to be set up to a maximum of 1438 bytes in order not to exceed a value of 1500 for the Ethernet SDU at the eNB (example with IPv4 S1-U over IPv4 IPsec tunnel, see Figure 39). While this is a well standardized and generic solution, there are potential drawbacks, such as additional processing delay and throughput degradation due to
processing load at the end points. Anyway, the performance impact will be limited due to the countermeasures taken in the user IP layer as described above.
The impact on transport efficiency is minor (~2.5%). Large packets (~25%) will be fragmented, i.e. cause double transport overhead (~10% per fragment).
GTP-U UDP 16 8 1394 ESP IPsec Tunnel IP 20 20
User IP Payload Padding PL/NH Auth RAN IP 24 0 2 12 1496 ≤1500 90 x 16 = 1440 GTP-U UDP 16 8 1500 20 User IP Payload RAN IP 1544 GTP-U UDP 16 8 1394 20 User IP Payload RAN IP 1438 (1st fragment) 1438 S-GW_MTU 1500 eNB_MTU 1500 UE_MTU eNB_MTU S-GW_MTU SAE-GW SEG eNB UE_MTU
Figure 39 Fragmentation & Reassembly with IPv4
4.2.2.3 Ethernet Jumbo Frames
This solution has no impact on user IP layer and a slightly higher transport efficiency. On the other hand, it is not standardized (vendor specific SDU sizes up to 9000 bytes are possible) and therefore not
generally supported by Ethernet equipment and Ethernet transport services.
1544 S-GW_MTU 1608 eNB_MTU 1500 UE_MTU GTP-U UDP 16 8 1500 ESP IPsec Tunnel IP 20 20
User IP Payload Padding PL/NH Auth RAN IP 24 6 2 12 1608 97 x 16 = 1552 GTP-U UDP 16 8 1500 20 User IP Payload RAN IP 1544 eNB_MTU S-GW _MTU UE_MTU
eNB
SEG SAE-GWFigure 40 Ethernet Jumbo Frames with IPv4 Support for Ethernet Jumbo Frames is a study item for RL30.
4.2.3 IPv6
The GTP-U tunneling concept allows for using private IP addresses in the LTE transport network (eNB backhaul) while user applications require a public IP address. Instead of assigning a public address directly to the UE, mobile operators often use NAPT for saving public IPv4 addresses.
There are more than 16M private IPv4 addresses available which are even reusable in distinct parts of the operator network if routing in between is not needed. This is particularly the case with respect to the transport network (LTE application IP layer, optionally IPsec tunnel IP layer). Nevertheless, some
operators claim to face a shortage of private IP addresses already now. Migration to IPv6 in the transport network is seen as a solution. Sooner or later, IPv6 in the transport network will become an operational cost optimization topic for network elements that anyway have to have IPv6 addresses due to support for IPv6 in the User IP layer (PDN-GW). It can be expected that these network elements would be simpler to manage if the number of IPv4 addresses is minimized.
The network elements are typically connected to a separate O&M network which is logically or even physically separated. Private IPv4 addressing can be used here and there is no technical reason to transport O&M traffic over IPv6. Migration to IPv6 is a major step since several O&M system components (incl. NetAct, iOMS, DHCP server, CMP server, etc.) are typically also used for legacy mobile networks. Anyway, IPv6 for M-plane transport will probably become an operational cost
optimization topic later when all other networks are running on IPv6. However, NetAct will support IPv6 in LTE M-plane applications, i.e. where IP addresses are handled (NetAct Top level UI, Object browser, NetAct Configurator, NetAct topology database, etc.).
QoS (DiffServ) and security (IPsec) mechanisms are basically the same for IPv4 and IPv6. In the following the relevant scenarios will be analyzed.
User IPv4 over LTE transport IPv4
This is the basic scenario, supported already with RL09 (IPsec option with RL10).
Flexi Multiradio BTS Eth MAC Eth PHY UDP G TP-U SAE-GW Server Eth MAC Eth PHY UserIP User App Eth MAC Eth PHY UDP G TP-U LTE PHY User App LTE PHY UserIP UE LTE MAC PDC P Eth MAC Eth PHY Security GW (optional) Eth MAC Eth PHY Eth MAC Eth PHY LTE MAC PDC P IPv4 IPv4 IPv4 IPsec TunnelIP
LTE AppIP LTE AppIP
IPsec TunnelIP
Figure 41 User IPv4 over LTE transport IPv4