LTE Transport Tutorial

1 (86)

Radio Transport PM

LTE Transport Confidential

LTE Transport Tutorial Nokia Siemens Networks Radio Transport Product Management Confidential

____________________________________________________________________________ Version

Date

Author

4.0

24-Jun-2010

Torsten Musiol

____________________________________________________________________________

2 (86)

Radio Transport PM


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 5.4 Congestion Control ..............................................................................................................61

3 (86)

6.

Radio Transport PM


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 12. Change History ....................................................................................................................86

4 (86)

Radio Transport PM


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.

5 (86)

Radio Transport PM


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 PMIPbased 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 Cplane and U-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.

6 (86)

Radio Transport PM


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

GBR

Guaranteed Bit Rate

7 (86)

Radio Transport PM


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

PDU

Protocol Data Unit

8 (86)

Radio Transport PM


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

WFQ

Weighted Fair Queuing

9 (86)

Radio Transport PM


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)

Radio Network Layer

UE

SAE-GW

MME

O&M eNB

Transport Network Layer

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.

10 (86)

Radio Transport PM


The following figures indicate a number of Frequently Asked Questions and corresponding misconceptions which deserve clarification. How to share transport with a cosited base station? What are the synchronization requirements?

Point-to-point or Multipoint-toMultipoint Ethernet?

How should IP addresses and VLANs be used

Is Transport security needed?

How to implement QoS?

MME

Ethernet / IP SAE-GW eNB What about performance impact with IPSec?

What transport capacity is required? How to connect automatically (plug‘n‘play)?

Ethernet switch or IP router?

What transport delay is acceptable?

O&M

Figure 2 FAQ’s

Phase synchronization is always needed

Adjacent eNBs need to have direct links (fully meshed network)

Multipoint-toMultipoint is more suited to flat architecture

Subscriber security is sufficient

MME

Ethernet / IP SAE-GW eNB Transport capacity has to be >500Mbit/s per eNB

Transport delay has to be <5ms

All transport nodes have to be IP routers

O&M

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 options.

11 (86)

Radio Transport PM


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.

12 (86)

Radio Transport PM


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).

3GPP Rel. 6 / HSPA Internet NB

RNC

SGSN

GGSN

3GPP Rel. 7 / HSPA Internet NB

Direct tunnel

3GPP Rel. 7 / Internet HSPA Internet iNB

Direct tunnel

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.

13 (86)

Radio Transport PM


3GPP Rel 8 / LTE/SAE Internet

MME eNB

Direct tunnel

SAE-GW

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/Mplane traffic correspondingly (see chapter 6.2).

14 (86)

Radio Transport PM


S-Plane

eNB 2

Inter-eNB connection (X2)

X2 U/C-Plane

Synchronization Grandmaster (optional)

S1 C-Plane MME

IP S1 U-Plane SAE-GW M-Plane

eNB1 NMS

Figure 6 LTE traffic types

15 (86)

Radio Transport PM


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 PDNGW and are anchored at the S-GW. Within the E-UTRAN, the GPRS Tunneling Protocol (GTP-U) is used as tunneling protocol.

Uu

S1-U

X2

User IP PDCP

PDCP

GTP-U

GTP-U

GTP-U

GTP-U

RLC

RLC

UDP

UDP

UDP

UDP

MAC

MAC

IP

IP

IP

IP

PHY

PHY

L1/L2

L1/L2

L1/L2

L1/L2

UE

eNB

S-GW

eNB

eNB

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).

Uu

S1-MME

NAS

X2 RRC

RRC S1-AP

PDCP

S1-AP

PDCP

X2-AP

X2-AP

RLC

RLC

SCTP

SCTP

SCTP

SCTP

MAC

MAC

IP

IP

IP

IP

PHY

PHY

L1/L2

L1/L2

L1/L2

L1/L2

MME

eNB

eNB

UE

eNB

Figure 8 Control-plane protocol stacks

16 (86)

Radio Transport PM


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).

Target eNB

Target eNB

Target eNB

S1-u

X2-u S-GW

S-GW

Source eNB

Before

S-GW

S1-u

S1-u

Source eNB

Source eNB

During

After

Figure 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.

17 (86)

Radio Transport PM


Target eNB

Target eNB X2-u S-GW

S-GW

S1-u

Source eNB

S1-u

Source eNB

During HO (1)

During HO (2)

Figure 10 Handover over X2 - Capacity

18 (86)

Radio Transport PM


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 350 300

Mbps

250

Downlink Uplink

200 150 100 50 0 LTE 2x20 MHz (2x2 MIMO

LTE 2x20 MHz (4x4 MIMO

Figure 11 Cell peak capacity

19 (86)

Radio Transport PM


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) 60

50

Downlink Uplink

Mbps

40

30

20

10

0 LTE (2x2 MIMO), 20 MHz carrier

LTE 4x4 MIMO, 20 MHz carrier

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.

20 (86)

Radio Transport PM


GTP-U (without header extension) UDP IPv4 (transport) IPSec ESP Header (SPI/Sequence Number) AES Initialisation Vector ESP Trailer (2-17 bytes, incl. 0-15 padding bytes, average 8 bytes) IPSec Authentication (HMAC-SHA-1-96) IPSec Tunnel mode IP header Ethernet higher layer (incl. 4 bytes for VLAN) Eth. Inter Frame Gap, Preamble/SFD Total transport overhead

8 8 20 8 16 10 12 20 22 20 144

bytes bytes bytes bytes bytes bytes bytes bytes bytes bytes 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

Radio Transport PM


Cell average

eNB transport

Cell peak

Peak Rate!

Overbooking

21 (86)

All-Average/ All-Peak AllAverage Single-Peak Figure 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.

22 (86)

Radio Transport PM


+20%

75

90

25

30

Air Interface

eNB

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)

Transport Interface Ethernet layer, with IPsec

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.

+20%

830

1000

300

360

Air Interface

eNB

Transport Interface

Ethernet layer, with IPsec 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.

23 (86)

Radio Transport PM


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 SAEGW (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

24 (86)

Radio Transport PM


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). NSN recommendations on network performance can be found in chapter 3.3.2.

25 (86)

Radio Transport PM


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.

25

20

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.

26 (86)

Radio Transport PM


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).

eNB Group eNBs with high HO probability within one group

Mobile Backhaul

Backbone

Network

Network

eNB 11

eNB 12

X2-u/c MME

S1-u/c Small or no HO probability between eNB groups

eNB 21

eNB 22 SAE-GW Edge router

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.

27 (86)

Radio Transport PM


eNB Mobile Backhaul Network

eNB

X2-u/c

Backbone Network

S1-u/c MME

SAEGW

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. eNB Mobile Backhaul Network

eNB

X2-u/c

Backbone Network

S1-u/c MME

SAEGW

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).

28 (86)

Radio Transport PM


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. Mobile Backhaul Network eNB

Backbone Network

Access

Aggregation

Network

Network

eNB MME

SAEGW

MME

SAEGW

eNB

eNB

L2

L2 or L3

L3

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.

29 (86)

Radio Transport PM


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

•

E-Tree

30 (86)

Radio Transport PM


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

UNI EVC 11 (E-Line) UNI

eNB 12

UNI EVC 12 (E-Line)

eNB 21

UNI

UNI EVC 21 (E-Line) UNI

eNB 22

UNI EVC 22 (E-Line)

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 •

Scalability (high number of EVC’s)

31 (86)

Radio Transport PM


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

UNI EVC 1 (E-LAN) UNI

eNB 12

eNB 21

UNI

UNI EVC 2 (E-LAN) UNI

eNB 22

UNI

Near-End X2 switching between eNBs of one group

Far-End X2 routing between eNB groups

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)

•

Operability (troubleshooting is more complex)

32 (86)

Radio Transport PM


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

UNI

EVC 1 (E-Tree) UNI

eNB 12

eNB 21

UNI

UNI

EVC 2 (E-Tree) UNI

eNB 22

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)

•

Security (impact of DoS attacks is limited to one eNB)

33 (86)

Radio Transport PM


3.2.2.4 Comparison In the table below, E-Line, E-Tree and E-LAN services are compared. Advantages E-Line

Disadvantages

QoS assurance

Scalability

(simple traffic engineering)

(high number of EVC’s)

Operability (simple troubleshooting) Security E-Tree

(impact of DoS attacks is limited to one eNB) Scalability

E-LAN

(low number of EVC’s)

Security (adjacent eNB’s can be attacked) QoS assurance (Traffic engineering is more difficult) 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.

34 (86)

Radio Transport PM


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.

Access Network eNB 11

Ethernet switch at MWR hub location

Aggregation

Backbone

Network

Network

eNB 12 MME

eNB 21

Fiber connection

eNB 22 SAE-GW

Carrier Ethernet Transport L2 Access & Aggregation

IP/MPLS L3 Backbone

Figure 25 Implementation example: Carrier Ethernet Transport for Access & Aggregation, IP/MPLS for Backbone

35 (86)

Radio Transport PM


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.

Access Network eNB 11

Ethernet switch at MWR hub location

Aggregation

Backbone

Network

Network

eNB 12 MME

eNB 21

Fiber connection

eNB 22 SAE-GW

CET L2 Access

IP/MPLS 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.

36 (86)

Radio Transport PM


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 L3: Packet Delay (PD)

Value

Comments

≤ 10 ms

TCP based applications require low transport latency

≤ +/- 5.0 ms

If Timing-over-Packet (ToP) based on IEEE15882008) is applied (could be relaxed otherwise)

L3: Packet Loss Ratio (PLR)

≤ 10e-4

May be different depending on user service

L2: Frame Loss Ratio

(0.01%)

L2: Frame Delay (FD) L3: Packet Delay Variation (PDV) L2: Frame Delay Variation

Table 3 Transport Service Attributes (Recommendation)

37 (86)

Radio Transport PM


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 2. Assignment of interface IP addresses to eNB interfaces

38 (86)

Radio Transport PM


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.

Binding to interface address

eNB

Binding to virtual address

S1/X2 U-plane application

U

S1/X2 C-plane application

C

M-plane application

M

S-plane application

S

Virtual IP address

Interface IP address

Figure 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.

39 (86)

Radio Transport PM


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.

eNB

Physical interface (Ethernet)

eNB Interface address assigned to physical interfaces

Interface addresses assigned to logical interfaces Physical interface (Ethernet)

Logical interface (VLAN) VLAN1 VLAN2

VLAN (optional) VLAN3 VLAN4

Figure 28 Assignment of interface IP addresses to eNB interfaces

40 (86)

Radio Transport PM


Figure 29 and Figure 30 below illustrate the configuration flexibility. Application(s) bound to interface address No or single VLAN per eNB

U C

Application(s) bound to virtual address(es)

Multiple VLANs per eNB

U

VLAN1

U

C

VLAN2

C

VLAN (optional)

No or single VLAN per eNB

VLAN (optional)

M

M

VLAN3

M

S

S

VLAN4

S

Figure 29 IP addressing with VLAN examples (RL10)

Application(s) bound to virtual address(es) Multiple VLANs per eNB U

VLAN1

C

VLAN2

M

VLAN3

S

VLAN4

Figure 30 IP addressing with VLAN examples (RL20)

41 (86)

Radio Transport PM


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

SAE-GW eNB U C

MME

Ethernet

VLAN (optional) S M

IP Router O&M eNB

~ ToP Master

Figure 31 E-Line with single IP address

42 (86)

Radio Transport PM


E-LAN with single IP Address •

Simplest configuration for E-LAN service

•

1 VLAN per eNB group

SAE-GW eNB U

MME

Ethernet

C VLAN (optional) S M

IP Router O&M eNB

~ ToP Master

Figure 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)

Example configuration

SAE-GW eNB

U C

EVC/VLAN 11, 12 VLAN1

M

MME

Ethernet

S

EVC/VLAN 21, 22

VLAN2

IP Router O&M eNB

~ ToP Master

Figure 33 E-Line with L2 differentiation

L2 differentiation can be supported in the same way with E-LAN.

43 (86)

Radio Transport PM


IPsec VPN with L3 separation •

Single interface IP address for IPsec tunnel termination

SAE-GW

Ethernet

eNB U C M

Application IP address

IPsec Tunnel S

VLAN


MME

IP IP Router

SEG

O&M eNB

~ IPsec VPN

ToP Master

Figure 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).

44 (86)

Radio Transport PM


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

o

Simultaneous provision of multiple synchronization technologies (e.g. GPS and ToP)

45 (86)

Radio Transport PM


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.

Single interface Single IP address

Dual interface Dual IP address

IP MME

eNB

Figure 35 SCTP Multi-homing

46 (86)

Radio Transport PM


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. QoS aware shaping low low

low

high

high

EVC

high UNI‘(1)

Ethernet

integrated Ethernet switch

eNB low

UNI

UNI‘(2)

high

other base station

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).

47 (86)

Radio Transport PM


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 submodules): •

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.

48 (86)

Radio Transport PM


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.

UE User App User

Flexi Multiradio BTS

Security GW (optional)

IP

SAE-GW

Server User App

IP

User

G TP-U

IP

G TP-U

UDP LTE App

Internet Operator Services

UDP

IP

IP

LTE App

IP

PDC P

PDC P

LTE MAC

LTE MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

LTE PHY

LTE PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

IPsec Tunnel

IP

IP

IPsec Tunnel

IP

Figure 37 IP layers

49 (86)

Radio Transport PM


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. In the following, the options will be elaborated more in detail.

50 (86)

Radio Transport PM


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

UE


S-GW / PDN-GW

Server

User IP layer Path MTU

User App Us er

User App

IP

IP G TP-U

IP

Application IP layer Path MTU

UDP LTE App

Us er

IP

G TP-U UDP

IP

IP

Tunnel IP layer Path MTU

LTE App

IP

PDC P

PDC P

LTE MAC

LTE MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

LTE PHY

LTE PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

UE_MTU

IPsec Tunnel

IP

IP

eNB_MTU

IPsec Tunnel

IP

S-GW_MTU

Figure 38 Path MTU Discovery

PDN-GW _MTU

51 (86)

Radio Transport PM


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). 20 RAN IP

8

16

1500

UDP

GTP-U

User IP Payload

UE_MTU

1544 20 RAN IP

8

16

1394

UDP

GTP-U

User IP Payload

UE_MTU

1500

eNB_MTU

1500

S-GW_MTU

1438

1438 (1st fragment)

20 IPsec Tunnel IP

24 ESP

20 RAN IP

8 UDP

16 GTP-U

1394 User IP Payload

0

2

12

Padding

PL/ NH

Auth

90 x 16 = 1440

1496 ≤ 1500

eNB_MTU

eNB

S-GW_MTU

SEG

SAE-GW

Figure 39 Fragmentation & Reassembly with IPv4

Flexi Multiradio BTS supports Fragmentation and Reassembly at the LTE application IP layer.

52 (86)

Radio Transport PM


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.

20 RAN IP

8

16

1500

UDP

GTP-U

User IP Payload

UE_MTU

UE_MTU

1500

eNB_MTU

1608

S-GW_MTU

1544

1544 20 IPsec Tunnel IP

24 ESP

20 RAN IP

8

16

1500

6

2

12

UDP

GTP-U

User IP Payload

Padding

PL/ NH

Auth

97 x 16 = 1552

1608

eNB_MTU

eNB

S-GW_MTU

SEG

Figure 40 Ethernet Jumbo Frames with IPv4

Support for Ethernet Jumbo Frames is a study item for RL30.

SAE-GW

53 (86)

Radio Transport PM


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).

UE User App User



IP

SAE-GW

User App

IPv4

User

G TP-U

IP

G TP-U

UDP LTE App

Server

UDP

IPv4

IP

LTE App

IP

PDC P

PDC P

LTE MAC

LTE MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

LTE PHY

LTE PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

IPsec Tunnel

IP

IPv4

IPsec Tunnel

IP

Figure 41 User IPv4 over LTE transport IPv4

54 (86)

Radio Transport PM


User IPv4/IPv6 over LTE transport IPv4 Some user services are running on IPv6. This scenario is completely transparent to the eNB, thus also available with RL09 (if supported by the SAE-GW).

UE User App User



IP

LTE MAC

LTE MAC LTE PHY

User

G TP-U

G TP-U

UDP

UDP

LTE App

PDC P

IPv4

IP

IPsec Tunnel

IP

IPv4

IPsec Tunnel

Server User App

IPv4/IPv6

PDC P

LTE PHY

SAE-GW

LTE App

IP

IP

IP

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Figure 42 User IPv4/IPv6 over LTE transport IPv4

User IPv4/IPv6 over LTE transport IPv4/IPv6 The transport network is (partially) based on IPv6 (RL30 study item). If both LTE application IP layer and IPsec tunnel IP layer are owned by the mobile operator, it is possible to use the same address for tunnel termination(s) and LTE applications (binding to interface addresses, collapsed “inner” and “outer” addresses, see chapter 3.4.1 and 7.4) in order to save IP addresses and reduce complexity.

UE User App User



IP

SAE-GW

User App

IPv4/IPv6

User

G TP-U

IP

G TP-U

UDP LTE App

Server

UDP

IPv4/IPv6

IP

LTE App

IP

PDC P

PDC P

LTE MAC

LTE MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth MAC

LTE PHY

LTE PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Eth PHY

IPsec Tunnel

IP

IPv4/IPv6

IPsec Tunnel

IP

Figure 43 User IPv4/IPv6 over LTE transport IPv4/IPv6

55 (86)

Radio Transport PM


5. QOS 5.1 End-to-End QoS In order to facilitate a certain end-to-end QoS for a user service, radio and transport QoS have to be considered consistently. Radio interface resources are scarce, so strict control has to be applied. This means, capacity has to be reserved for Guaranteed Bit Rate (GBR) type of services through Connection Admission Control (CAC). Controlled overbooking with prioritization is the solution for non-GBR type of services. The resource situation in the access section (“last mile”) of the mobile backhaul network is similar, so the solution principles are similar: Committed Information Rate (CIR) guarantees continuation of GBR services, whereas Extended Information Rate (EIR) with overbooking and prioritization can be applied for nonGBR traffic. Nevertheless, it is recommended to reserve also a minimum capacity using CIR for nonGBR traffic. In the aggregation section of the network the situation is more relaxed, so less strict control is required. Still, there might be a need for capacity reservation and traffic prioritization. If sufficient resources are available, this section may be ignored by the CAC. The mobile network up to the SAE-GW is operator controlled, so with proper network dimensioning the service quality can be guaranteed. Naturally, CAC makes most sense here. This is not the case if the actual user service is provided by a server located anywhere in the Internet. Only Best Effort can be expected. If the user service is based on TCP (80…90% of the traffic), TCP congestion control mechanisms will assure a fair distribution of capacity.

QoS features

• Scarce resources • Fair resources • Scarce resources • Strict control (RRM) • Less strict control • Strict control (Transport) • Reservation for GBR • Reservation (MPLS TE) • Reservation (CIR) • Controlled overbooking • Controlled overbooking with • Overbooking with with prioritization prioritization (802.1p) prioritization (DiffServ) for non-GBR

• • Flow & congestion • control (TCP) • • Traffic marking

Radio & Transport CAC (CIR for GBR, EIR for non-GBR) Radio scheduling per UE (UL+DL) Transport UL policing and • DL policing and shaping per eNB shaping per eNB

Ethernet Service quality

UE

• DL policing and shaping per UE

IP IP Router

eNB

Access Guaranteed

• No control

IP SAE-GW

Aggregation Core

Best effort

Figure 44 End-to-End QoS

• Flow & congestion control (TCP)

Internet Operator Server

Internet Server

56 (86)

Radio Transport PM


5.2 Transport QoS Features 5.2.1 Traffic Prioritization on IP Layer LTE131 “Traffic prioritization on IP layer” (RL10, RL05TD)

In order to avoid over-dimensioning in the backhaul network, Flexi Multiradio BTS supports QoS differentiation between user, control and management plane traffic as outlined in Figure 45. DiffServ is the most common way of traffic prioritization on IP layer [RFC2474], [RFC2475]. Traffic end points (eNB, S-GW, MME, O&M/NetAct) will set DSCP values, while intermediate network elements have to handle the packets accordingly. DSCP values for different U/C/M-plane traffic types are configurable.

~

MME

IP

Eth


IP Router (Security GW) SAE-GW

U-plane C-plane M-plane S-plane (User) IP GTP-U

S1AP / X2AP

UDP

SCTP

ToP Server

BTSOM

IEEE1588

TCP

UDP

U-plane C-plane M-plane S-plane

QoS marking (DSCP)

IP

NetAct

DSCP aware

IP

(User) IP GTP-U

S1AP

BTSOM

IEEE1588

UDP

SCTP

TCP

UDP

IP

IP

IP

IP

L2

L2

L2

Eth MAC

Eth MAC

Eth MAC

Eth MAC

L1

L1

L1

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Figure 45 Traffic prioritization on IP layer

57 (86)

Radio Transport PM


5.2.2 Traffic Prioritization on Ethernet Layer LTE129 “Traffic prioritization on Ethernet layer” (RL10, RL15TD)

If traffic aggregation is performed by Ethernet switching, not IP routing, the transport network may not be IP QoS (DiffServ) aware. In this case, Flexi Multiradio BTS supports traffic prioritization on the Ethernet layer, using frame marking methods (code points) applicable to Ethernet as illustrated in Figure 46. Ethernet priority bits (IEEE 802.1p) are set based on the DiffServ Code Point (DSCP). The mapping table is configurable.

~

MME

Ethernet

Eth


ToP Server

IP Router (Security GW) SAE-GW

NetAct

U-plane C-plane M-plane S-plane

U-plane C-plane M-plane S-plane (User) IP

(User) IP

GTP-U

S1AP / X2AP

UDP

SCTP

BTSOM

IEEE1588

TCP

UDP

802.1p marking

802.1p aware

IP L2 L1

Ethermet Switching Eth PHY

Eth PHY

GTP-U

S1AP

BTSOM

IEEE1588

UDP

SCTP

TCP

UDP

IP

IP

IP

IP

Eth MAC

Eth MAC

Eth MAC

Eth MAC

Eth PHY

Eth PHY

Eth PHY

Eth PHY

Figure 46 Traffic prioritization on Ethernet layer

58 (86)

Radio Transport PM


5.2.3 Packet Scheduling Flexi Multiradio BTS performs packet scheduling using 6 queues with SPQ (Strict Priority Queuing) and WFQ (Weighted Fair Queuing). Each Per-Hop-Behavior (PHB) is mapped to a queue. Expedited Forwarding (EF) is served with Strict Priority Queuing (SPQ). Assured Forwarding (AF1…4) and Best Effort (BE) PHBs are served with Weighted Fair Queuing (WFQ). The highest priority queue is rate limited by Connection Admission Control (CAC). In case of queue overflow, packets are discarded according to the following strategies: •

Tail drop for EF queue

•

Weighted random early discard (WRED) for AF1…4 queues

•

Random Early Discard (RED) for BE queue

LTE Traffic Cla sses, marked with DSCPs

Shaping is performed per L2 interface(s) (either Ethernet or individual VLANs) with or without taking L2 overhead into account (i.e. L2 or L3 shaping).

PHB Q ueue EF

Packet Distribution acc . to DSCPs

SP

PHB Q ueue AF4

WAF4

PHB Q ueue AF3

WAF3 WAF2

Layer 2 Interface + Shaper

WFQ_ OUT WFQ

PHB Q ueue AF2 WAF1 PHB Q ueue AF1

WBE

PHB Q ueue BE

Figure 47 Packet scheduling

If multiple VLAN’s are configured for traffic separation, scheduling will be performed first per VLAN (one set of PHB’s / queues per VLAN), followed by WFQ scheduling for combining the traffic. Shaping can be applied per VLAN (supporting SLA related to VLAN/EVC) and for the aggregate traffic (supporting SLA related to the Ethernet UNI).

59 (86)

Radio Transport PM


5.2.4 Traffic Shaping LTE138 “Traffic shaping” (RL10, RL15TD)

The Flexi Multiradio BTS Ethernet interface (FE or GE) supports data rates (100Mbit/s or 1000Mbit/s) and burst sizes which may be higher than the capacity of the Ethernet backhaul link (e.g. leased line or capacity limited microwave radio link). Traffic shaping is required to ensure conformance to the link capacity in order to minimize packet loss. This applies in particular to Ethernet leased lines where the link capacity is governed by a Service Level Agreement (SLA). Traffic shaping reduces the burstiness of Ethernet or IP traffic in conformance with a given •

Maximum average output rate on Ethernet or IP layer

•

Maximum burst size on Ethernet or IP layer

If packets need to be dropped despite shaping, this will be done based on priorities (QoS aware). Flexi Multiradio BTS performs single-stage traffic shaping in UL direction according to [MEF10.1] with a shaping granularity of 100kbit/s, exceeding the requirements of [MEF11]. Shaping can be applied per L2 interface, i.e. per physical Ethernet interface and per VLAN. That means, traffic can be shaped per traffic type (U/C/M/S-plane) if VLAN differentiation is used accordingly. Shaping in DL direction is supported per bearer at the SAE-GW. eNB level shaping is recommended to be done by the Edge Router which routes the traffic into one or more VLAN’s (EVC’s) per eNB.

60 (86)

Radio Transport PM


5.3 Mapping RRM QoS onto Transport QoS QoS has to be applied consistently to both the radio and the transport interface. As per [TS23.401], each U-plane Service Data Flow (SDF) is associated with a QoS Class Identifier (QCI). Table 4 illustrates an exemplary configuration, including M/C/S-plane traffic. LTE Radio domain LTE Traffic Class

QCI

LTE Transport domain Resource Type

DSCP

DiffServ PHB

Ethernet p-bits

46

EF

5

26

AF31

3

46

EF

5

28

AF32

3

34

AF41

4

18

AF21

2

20

AF22

2

Conversational Voice

1

Conversational Video

2

Real Time Gaming

3

Non-conversational Video

4

IMS signaling

5

Voice, video, interactive gaming

6

Video (buffered streaming)

7

TCP-based (e.g. www, email, ftp, p2p file sharing, etc.

8

10

AF11

1

9

0

BE

0

C-plane

46

EF

5

M-plane

34

AF41

4

S-plane

46

EF

5

ICMP

10

AF11

1

GBR

non-GBR

Table 4 Mapping RRM QoS onto transport QoS

Flexi Multiradio BTS supports configurable mapping between QCI, DSCP and Ethernet p-bits.

61 (86)

Radio Transport PM


5.4 Congestion Control In contrast to the Iub interface in HSDPA, there are no standardized means for congestion control at the S1 interface in LTE. This has to be taken into account when designing the network. GBR traffic should be governed by CAC, so performance should be assured by SLA/SLS (CIR/CBS attributes) and traffic prioritization. Most of the user traffic is TCP based (web browsing, file transfer, email, etc.). In case of congestion, the load will be automatically reduced through TCP congestion control. So, not the eNB will address the load situation, but the UE and/or the application server. “Misbehaving” UDP based applications may require additional treatment at the SAE-GW, using Deep Packet Inspection (DPI). Further optimization techniques (e.g. ECN) may be applied in order to avoid that TCP need to resend lost packets and the radio interface (UL) will carry packets which will be dropped later. Note: The HSDPA flow control algorithm was initially designed to control the air interface scheduler only. Since now often the transport network (Iub) is the bottleneck and inefficient RLC retransmission between RNC and UE shall be avoided, it was recognized that the transport network shall have its own congestion detection mechanism which contributes to the flow control. So, transport protocol independent information elements have been standardized, namely Frame Sequence Number (FSN) and Delay Reference Time (DRT). [TS25.435] defines the information elements for congestion detection, but not the congestion control algorithm itself. TCP cannot efficiently participate in HSDPA congestion control since RLC retransmission will hide congestion situations, both in the air interface and in the transport network.

62 (86)

Radio Transport PM


6. SYNCHRONIZATION As per 3GPP requirement, the air interface at an eNB in FDD mode needs to be frequency synchronized with an accuracy of ±50ppb. In addition, phase (time) synchronization is required now for LTE TDD mode and in the future also for Single Frequency Network (SFN) Multimedia Broadcast Multicast Service (MBMS) and location based services. 6.1 Synchronization from GPS Synchronization from GPS interface is a field-proven technology. The GPS antenna with integrated receiver is connected with a single-cable (power, sync, control) to the Flexi System Module. This is a site solution rather than a transport feature, but mentioned here for completeness reasons. FYGA + mounting kit FYMA

↑ Power and control to the GPS receiver FYHA or FYHB cable

↓

PPS signal to BTS System Module

FYEA GPS Surge Protector Kit (optional)

System Module

Figure 48 Synchronization from GPS

63 (86)

Radio Transport PM


6.2 Synchronization from Transport Network 6.2.1 IEEE1588-2008 Precision Time Protocol (Timing-over-Packet) LTE134 “Timing-over-Packet” (RL10) LTE891 “Timing-over-Packet with phase synchronization” (RL25TD)

Precision Time Protocol (PTP) based on [IEEE1588-2008] is a field-proven method to support synchronization through an IP transport network. It has to be noted that the network has to have sufficient quality (in particular low frame/packet delay variation). The NSN PTP solution, a.k.a. Timing-over-Packet (ToP), consists of a Grandmaster (server) at the core site and Timing Slaves (client) implemented in the Flexi Multiradio BTS. The master and slaves communicate through the bidirectional protocol containing time stamps. The slaves use these timestamps to synchronize themselves to the grandmaster’s clock. Accurate frequency can be derived from that clock.

Timing over Packet (IEEE 1588-2008)

Grandmaster


~ ToP Slave

~ IP / Ethernet

Eth

MME

eNB SAE-GW

Figure 49 Timing-over-Packet (IEEE1588-2008)

The following engineering rules apply: •

Maximum one way delay < 100ms

•

Packet delay variation (jitter) < ±5 ms

•

Packet loss ratio < 2%

•

Timing packets (S-plane traffic) should have the highest priority or at least the same priority as the real-time traffic (should receive Expedited Forwarding (EF) QoS)

•

High-priority traffic share of total traffic should be ~ 60 % or less

•

Maximum 20 hops with packet switching

•

Maximum 6 delay jumps (spontaneous, major change of delay, e.g. caused by re-routing or path switching) per day

LTE TDD mode requires accurate phase synchronization (±1.5us) in addition to frequency synchronization (±50ppb). While frequency synchronization can tolerate typical network jitter in the order

64 (86)

Radio Transport PM


of several milliseconds through long-time averaging, UL/DL delay asymmetry cannot be controlled with the required accuracy. In order to solve this problem, PTP has to be implemented at all intermediate nodes on the synchronization traffic path so that outgoing timing packets will be (re-)marked based on the local node clock (on-path support with IEEE1588-2008 boundary clock or transparent clock).

Timing over Packet (IEEE 1588-2008)

Grandmaster


~ ToP Slave

~

MME

IP / Ethernet

eNB SAE-GW

Figure 50 Timing-over-Packet for time/phase synchronization

65 (86)

Radio Transport PM


6.2.2 Synchronous Ethernet LTE713 “Synchronous Ethernet” (RL10)

Synchronous Ethernet (SyncE) as per G.8261/8262/8264 is an SDH like mechanism for distributing frequency at layer 1. In contrast to Timing-over-Packet, which is essentially a layer 3 technology, frequency synchronization will be extracted directly from the Ethernet interface at the Flexi Multiradio BTS. In contrary to packet based synchronization (IEEE1588-2008, NTP), the stability of the recovered frequency does not depend on network load and impairments. SyncE has to be implemented at all intermediate nodes on the synchronization traffic path. Primary Reference Clock

Synchronous Ethernet

~

~ Eth

Eth

~ Eth

Eth

~ Eth

Eth

MME

eNB SAE-GW

Figure 51 Synchronous Ethernet

66 (86)

Radio Transport PM


6.3 Solutions for Co-location with Legacy Equipment 6.3.1 Synchronization from PDH interface LTE710 “Synchronization from PDH interface” (RL10)

Synchronization from PDH interface is the conventional method applied for legacy base stations (2G, 3G). The synchronization signal is recovered from a selected E1/T1/JT1 line, the clock of which is traceable to a Primary Reference Clock (PRC). PRC synchronization is usually injected at the core site. The co-located legacy base station forwards the clock through a spare E1/T1/JT1 interface to the Flexi Multiradio BTS.

~

IP / Ethernet

Eth E1/T1

eNB BTS E1/T1

TDM

Figure 52 Synchronization from PDH interface

67 (86)

Radio Transport PM


6.3.2 Synchronization from 2.048MHz signal LTE711 “Synchronization from 2.048MHz signal” (RL10)

Instead of forwarding the synchronization signal through an E1/T1/JT1 line, a co-located legacy base station may provide a 2.048MHz G.703 signal for synchronizing Flexi Multiradio BTS as illustrated in the figure below.

~

IP / Ethernet

Eth SYNC

eNB

2.048MHz G.703

BTS SYNC E1/T1

TDM

. Figure 53 Synchronization from 2.048MHz signal

68 (86)

Radio Transport PM


7. TRANSPORT SECURITY LTE689 “LTE IPsec Support” (RL10, RL15TD) LTE564 “IPsec on FTIB” (RL20) LTE150 “OAM Transport Layer Security (TLS) Support” (RL10, RL15TD)

7.1 General As compared to TDM and ATM, IP based protocols enable lower transport cost and easier planning and configuration. On the other hand, mobile backhaul traffic becomes more vulnerable to hacker attacks. Attack methods have evolved rapidly with cheap HW providing high processing power and better tools which are widely available. In addition, base stations which were traditionally located in secure, locked sites are increasingly set up in public places or homes. Furthermore, there are two major differences compared to WCDMA with respect to transport security (see Figure 54): 1. Air interface encryption of user plane traffic is terminated at the eNB, thus user plane traffic in the LTE mobile backhaul network is not secured by Radio Network Layer protocols. 2. Since the LTE network architecture is flat, adjacent base stations and core nodes (MME, S-GW) become directly IP-reachable from base station sites. If physical access to the site cannot be prohibited, a hacker could connect his device to the network port and attack aforementioned network elements. Transport security features are seen mandatory if not both the mobile backhaul network and the eNB site can be regarded as secure. IPsec provides a comprehensive set of security features (data origin authentication, encryption, integrity protection), solving both problems above. The 3GPP security architecture, based on IPsec and Public Key Infrastructure (PKI), is outlined in following specifications: [TS33.210], [TS33.310] and [TS33.401]. This chapter gives an overview of the transport aspects of LTE mobile backhaul security. More details, in particular addressing the operability issues, can be found in [SDI]. NSN recommends using IPsec.

69 (86)

Radio Transport PM


3GPP U-plane security

3G NB

UE

RNC Mobile Backhaul

Server Core

User traffic can be can be compromised U-plane security

eNB UE

Server

LTE Core nodes and adjacent eNBs can be attacked

Figure 54 Security with WCDMA and LTE

IPsec is applied between Security Gateways (SEG). Each eNB site instantiates one SEG function. One or more Security Gateways (SEG) should be located at the edge of the operators “Security Domain” (as per 3GPP Network Domain Security). Typically, the Security Domain includes the backbone network. Connectivity provided by a 3rd party (leased lines) is usually treated as outside the Security Domain. The SEG is effectively hiding the core nodes (MME, SAE-GW, Network Management System) from the mobile backhaul network. Since the traffic itself is transparent to the SEG, various core network configurations can be supported (e.g. MME/SAE-GW pooling, S1-flex, etc.).

70 (86)

Radio Transport PM


Security Gateway (SEG)

Security Gateway (SEG) integrated in Flexi BTS

Server Core eNB

Figure 55 Security Gateway functions in the network

3GPP recommends re-using IPsec also for O&M (M-plane) traffic. In addition to that, NSN has developed an M-plane security solution based on TLS. TLS provides end-to-end security since the session secured by TLS is terminated at the O&M equipment (Element Manager, Network Management System). Optionally, both concepts could be combined (TLS-over-IPsec). In this case, all traffic (U/C/M/S-plane) may flow through one single IPsec tunnel. Flexi Multiradio BTS has an integrated Security Gateway function, supporting all options above. The SEG at the core side may be a separate equipment or integrated within the Edge Router. 7.2 X2 Issues In the simplest scenario, all S1 and X2 traffic of an eNB could pass through a single IPsec tunnel. That means that X2 traffic would need to be routed back through an SEG, i.e. passing this SEG function twice (“IPsec X2 Star” architecture, Figure 56). Alternatively, X2 traffic (U/C-plane) may be secured directly between eNB integrated SEG’s (“IPsec X2 Mesh” architecture, Figure 57). There is a common misconception that the “flat” LTE architecture implies the „IPsec X2 Mesh“ architecture. In reality, the advantages are minor. The amount of backhaul traffic which can be saved in the aggregation network is very small. Even though X2 latency will be reduced, the effect will be insignificant since the transport path used for S1 should be designed for low latency anyhow (see also chapter 3.1). NSN recommends the “IPsec X2 Star” architecture.

71 (86)

Radio Transport PM


X2-u/c MME U C M

IPsec Tunnel S*

VLAN

SEG

SAE-GW

eNB

O&M

IPsec VPN IPsec tunnel: “outer” IP layer IPsec tunnel: “inner” IP layer

Figure 56 “IPsec X2 Star” architecture

U S1 Tunnel

C

X2 Tunnel

...

M

S

X2 Tunnel

VLAN

IPsec VPN

X2-u/c eNB

MME

SEG

SAE-GW

eNB O&M

Figure 57 “IPsec X2 Mesh” architecture

It should be noted that the 3GPP Rel.8/9 X2 self-configuration as per [TS36.300] does not fully support the “X2 Mesh” architecture. The TNL Address Discovery procedure determines the C-plane application address only, which is not sufficient in case the eNB application IP addresses shall be different from the interface IP address which terminates the IPsec tunnel layer.

72 (86)

Radio Transport PM


7.3 IPsec Tunnel Mode vs. Transport Mode [TS33.210] requires IPsec Tunnel Mode. Transport Mode is declared as optional. With Tunnel Mode, the payload IP frame is encapsulated with an extra IP header (IPv4: 20bytes). IPsec Transport Mode doesn’t need that extra IP header, so the transport efficiency is slightly better. However, a Transport Mode SA is defined as a security association between two IP hosts (see RFC2401). So, if a centralized SEG is applied, Tunnel Mode is the only choice. In turn, IPsec Transport Mode would only be applicable to direct X2 connections. For a more generic network design, NSN recommends to use only tunnel mode, for both S1 and X2. Due to the very low amount of X2 traffic, the transport efficiency impact is negligible. If IPsec Tunnel Mode is used, the transport QoS mechanism (DiffServ) will not be affected. Flexi Multiradio BTS copies the application layer (“inner”) DSCP values into the IPsec tunnel (“outer”) DSCP’s, so that each packet will be treated properly. Correspondingly, an edge router should do that in DL direction. NSN recommends the IPsec Tunnel Mode.

7.4 Security Associations and IP Addressing In case of the “X2 star architecture” (see chapter 7.2) each eNB has to build up Security Associations (SA) to one (or very few) SEG(s) only. SA’s are established and maintained automatically by the Internet Key Exchange (IKE) protocol. Flexi Multiradio BTS supports both IKEv1 (RFC2409) and IKEv2 (RFC4306) The IP address for IPsec tunnel termination (interface IP address) may be different from the IP addresses which eNB U/C/M/S-plane applications are bound to (virtual IP addresses). This is important if IP addresses in the mobile backhaul network are managed separately, i.e. by another operator (IP transport service). See Figure 58.

73 (86)

Radio Transport PM


• Application(s) bound to interface address • Collapsed "inner" and "outer" address

• Application(s) bound to virtual address(es) ("inner“) address)

• Tunnel terminated at the interface address ("outer“ address) Multiple tunnels per eNB

Single tunnel per eNB

Tunnel1 U VLAN1

U

U Single tunnel per eNB

C

Tunnel2 VLAN1

C

M VLAN1 Tunnel3

M

C VLAN IPsec (optional) tunnel

Tunnel

M

VLAN optional S

S

VLAN1 Tunnel4

S

VLAN optional

Figure 58 IP addressing with IPsec Tunnel Mode

A typical configuration is shown in Figure 59. Here, the U/C/M-planes are bound to virtual addresses and forwarded via an IPsec tunnel. The S-plane is bound to the physical interface address, bypassing the IPsec tunnel. All traffic is going through a single VLAN.

U C

IPsec Tunnel S

M

Application IP address

VLAN


Figure 59 Mixed IP addressing

Traffic of different eNB applications (planes) may be routed through different SA’s (Figure 60) or even through different IPsec tunnels, based on a set of rules. For example, U/C-plane traffic and M-plane traffic may be terminated in different SEGs, belonging to different IP subnets. Source and destination IP addresses or IP subnets can be used for making the routing decision. In order to keep the number of SA’s to be managed at the SEG reasonably low, it is recommended to assign eNB’s of the same group (adjacent eNB’s) to the same subnet. This assignment can be done per plane (U/C/M). Typically, the corresponding core nodes will belong to different subnets, so X2 traffic will need its own SA(s). In the simplest scenario, S1 and X2 traffic is passing through a single IPsec tunnel containing two (pairs of unidirectional) Security Associations: one IKE SA and two Child SA’s for the traffic to be protected. With U/C/M-plane separation, this would result in one IKE SA and 5 Child SA’s:

74 (86)

Radio Transport PM

•

IKE

•

S1 U-plane

•

S1 C-plane

•

M-plane

•

X2 U-plane

•

X2 C-plane


SEG

eNB IKE_SA 1 CHILD_SA 1.1 C

C

CHILD_SA 1.2

CHILD_SA 1.3 U

U

CHILD_SA 1.4 M

M

CHILD_SA 1.5

S

S

CHILD_SA 1.6 Neighbor eNB (via X2) U

C

C

Control plane

M

Management plane

Application address (inner IP address)

U

User plane

S

Synchronization plane

Interface address (outer IP address)

Figure 60 IPsec “Tunnels” and Security Associations

. Flexi Multiradio BTS supports all those scenarios.

~

75 (86)

Radio Transport PM


7.5 Public Key Infrastructure (PKI) For secure transport of information, mutual authentication of both sender and receiver and robust encryption of the information, which provides confidentiality and integrity, is needed. Both functions are based on secret credentials. Basically, there are two approaches with respect to the distribution of these in the context of the LTE network: 1. Pre-shared key (PSK) In the simplest way, all eNB’s would share the same key. If this key is compromised, security is completely gone. Thus, this is not an acceptable solution. Alternatively, each eNB could have a unique key assigned. This would provide better security, but has scalability issues. Each time an eNB will be added, removed or replaced, the key database of its communication partners need to be updated. In particular, this would be very difficult in case of direct X2 tunnels between adjacent eNB’s (“X2 mesh architecture”). 2. Digital certificate, Public Key Infrastructure (PKI) PKI is the solution recommended by 3GPP. It is based on digital certificates and public/private key pairs. The eNB certificate including the public key is sent openly to the other party in order to prove authenticity. The eNB private key is securely stored inside the eNB. PKI provides good flexibility for network changes. However, it requires investments into the security infrastructure. Flexi Multiradio BTS supports PKI with X.509 certificates.

76 (86)

Radio Transport PM


8. TRANSPORT OPERABILITY

8.1 Ethernet OAM LTE140 “Ethernet OAM” (RL20, RL15TD)

Ethernet OAM (Operation, Administration, Maintenance) features support management of Ethernet (L2) networks in terms of Fault Management (FM), Performance Management (PM) and Configuration Management (CM). This is beneficial for detection and localizing faults, examining and reporting network status, monitoring network performance, and provisioning and configuring parameters. Ethernet OAM functions and protocols are standardized as follows: •

Link Layer OAM (IEEE 802.3ah)

•

Ethernet Service OAM (IEEE 802.1ag / ITU-T Y.1731), a.k.a. “Service Layer OAM”

Due to different objectives, these protocols complement each other. Link Layer OAM (IEEE 802.3ah) operates at a single link and is mainly targeting as "Ethernet in the first mile" application. Flexi Multiradio BTS supports the following functions: •

OAM Discovery: Identify peer device and its OAM capabilities (with active mode support)

•

Remote Failure Indication: Mechanism to provide failure information to the peer. Includes Link Fault, Dying Gasp, Critical Events

•

Remote Loopback: allows to check the quality of the link for diagnosis and troubleshooting (w/ active mode support).

•

Link Monitoring: Event notifications, including diagnosis information (threshold alarms)

Service Layer OAM (IEEE 802.1ag / ITU-T Y.1731) covers Ethernet end-to-end- and network segmentconnectivity as well as service guarantees. Flexi Multiradio BTS supports the following functions: •

Ethernet Continuity Check: Reports loss of continuity between two MEP’s (Maintenance Endpoints), within a MEG (Maintenance Entity Group) or unintended connectivity

•

Ethernet Alarm Indication Signal: indicates alarms to next nodes and suppresses alarms to NMS if indicated alarms occurs on lower levels

•

Ethernet Remote Defect Indication: Used by a MEP to communicate to its peer MEP that a defect condition has been encountered.

•

Loopback: behavior in Ethernet similar to "Ping" on L3 (with optional troubleshooting extensions)

•

Link Trace: behavior in Ethernet similar to "Trace Route" on L3

77 (86)

Radio Transport PM


8.2 Transport Plug’n’Play (SON) Self-Organizing / Self-Optimizing Networks (SON) principles are essential to decrease operator OPEX. This chapter recapitulates transport related items. 8.2.1 Auto-Connection LTE154 “SON LTE BTS Auto Connectivity” (RL10, RL15TD)

Flexi Multiradio BTS is delivered from the factory with an initial basic SW to perform the basic boot process, the auto-connectivity agent SW for the establishment of a connection to the IP backhaul network and the self-configuration agent SW. Auto Connection supports fast integration of new or relocated base stations by an automated process based on DHCP [RFC2131], [RFC2132]. The following steps have to be performed beforehand: 1. Site plan preparation Transport planning data related to the new Flexi Multiradio BTS have to be prepared. This is not needed for the auto-connection phase itself, but for the unambiguous Flexi Multiradio BTS detection in the subsequent auto-configuration step. 2. DHCP server preparation: DHCP servers have to be preconfigured with suitable options and Flexi Multiradio BTS specific data (vendor specific attributes): •

IP address of the Identity Management System (IDM) respectively another 3rd party PKI Certificate Server providing a CMPv2 interface

•

IP address of the Security Gateway protecting the responsible O&M system (NetAct)

•

IP address of the management peer of the responsible O&M system

•

optionally an IP address of a dedicated LDAP server for Certificate Management

Auto-Connection comprises the following functions. 1. Establishment of IP connectivity The Flexi Multiradio BTS transport sub-module is automatically configured to enable the following steps: •

L1/L2 auto negotiation

•

IP Address Assignment

In order to retrieve all information necessary for the IP connection establishment between Flexi Multiradio BTS and NetAct the Flexi Multiradio BTS acts as DHCP client. DHCP requests are submitted first untagged. If not successful, the whole VLAN ID range is scanned (VLAN probing). The DHCP server assigns an IP address, netmask and the IP address of the default gateway to the Flexi Multiradio BTS and delivers in addition further information as vendor specific attributes as listed above. 2. Retrieval of operator certificates (optional)

78 (86)

Radio Transport PM


If the address of a PKI Certificate Server has been delivered in the previous step, Flexi Multiradio BTS retrieves a new certificate from the operator’s CA using the CMPv2 protocol. 3. Connection to the Security Gateway (optional) If the address of a Security Gateway has been delivered in step 1, Flexi Multiradio BTS establishes a connection to the gateway and sets up Security Associations for the M-plane. 4. (Secure) O&M plane connection Flexi Multiradio BTS starts the (secure) M-plane connection to the NetAct framework. In addition to the previously established IPsec tunnel to the SEG, security may be extended further to the O&M application using TLS (optional).

79 (86)

Radio Transport PM


8.2.2 Auto-configuration LTE720 “SON LTE BTS Auto Configuration” (RL10, RL15TD)

Based upon successful Auto-connection, the Flexi Multiradio BTS configuration plan file (RAML2.1 format) will be downloaded which also contains all transport related parameters. This configuration will be operationally available after an automatically performed reset of the base station. To derive IP connectivity information of neighbor sites the following procedure is applied: •

During the auto-configuration process each Flexi Multiradio BTS registers itself with its eNB global ID and given IP configuration at NetAct.

•

NetAct uses the eNB Global ID to access the related configuration plan file of the newly registered BTS

•

NetAct searches for given pre-planned neighbor configurations (respectively for their eNB global IDs)

•

NetAct checks if the listed neighbor sites are already registered. For all sites in operation NetAct queries the database for the assigned IP configurations.

•

NetAct stores the found IP configurations into the neighbor cell configuration area within the configuration plan file of the newly registered Flexi Multiradio BTS.

•

The updated configuration plan file is now ready to be downloaded automatically as part of the auto-configuration process.

The operator is able to start the neighbor site scan and configuration plan file update also manually on demand for a single Flexi Multiradio BTS or a list of BTS’s.

80 (86)

Radio Transport PM


9. FLEXI TRANSPORT SUB-MODULES FOR LTE LTE800 “FTLB” (RL09, RL05TD) LTE707 “FTIB” (RL10)

Flexi Multiradio BTS interfaces to the backhaul connection are provided by field-replaceable Flexi Transport sub-modules (FTM) which are mounted on top of the Flexi System Module (FSM) core. Out of the FTM product family, most recent variants FTIB and FTLB also support LTE. This allows for cost efficient migration from WCDMA to LTE through SW upgrade (Flexi System Module multimode capability).

2008

Mainstream product

2009

2010

Premium product

LTE RL10

SW FTPB FTEB

FTIA FTJA

FTIB

8xE1/T1

4xE1/T1 3xEth

4xE1/T1 3xEth

de ra g Up

SW Upgrade

RL09

FTLB 4xE1/T1 3xEth

I-HSPA Rel.3

FTFA

FTOA

FTIB FTHA

2xFlexBus

1xSTM-1

16xE1/T1

RU10

RU20 On Top

Figure 61 Flexi Transport sub-Modules (FTM) family

FTIB is sufficient for many sites, whereas FTLB is positioned as premium product. FTLB supports the same features as FTIB, but additionally an increased IPsec throughput (HW acceleration) and I-HSPA adapter functionality. Thus, upgrading from I-HSPA to LTE can be done easily through SW download.

81 (86)

Radio Transport PM


Main features are listed here: FTIB

FTLB

GE 100/1000Base-T interface (electrical, RJ45)

22)

2

GE SFP receptacle, supporting 1000Base-SX/LX/ZX (optical)

12)

1

160Mbit/s

2Gbit/s

Timing-over-Packet1) (IEEE1588-2008)

yes

yes

Synchronous Ethernet1)

yes

yes

Ethernet switching1)

yes

yes

IPsec throughput performance (HW capability, DL + UL) 1)

Table 5 Field-replaceable Flexi Transport sub-module variants

Notes 1) The list above indicates HW support. Specific features may require a SW license to be enabled. 2) Two out of three GE ports are usable at the same time If IPsec is not enabled, the eNB transport throughput performance is non-blocking, i.e. exceeding the air interface capacity. With IPsec enabled, 160Mbit/s throughput as provided by the lower-cost Flexi Transport sub-module FTIB will be sufficient for many eNB sites. Based on an integrated IPsec HW accelerator, Flexi Transport sub-module FTLB can even support up to 2Gbit/s throughput (HW capability).

82 (86)

Radio Transport PM


FTLB

3 x GE 1) 4 x E1/T1/JT1 2)4) High-capacity IPSec 3)4) ToP (IEEE1588-2008), Sync Ethernet 4) Ethernet switching 5)

Non-blocking throughput performance with IPSec

1) 2 x GE electrical + 1 x GE optical via SFP module 2) E1/T1/JT1 interface for synchronization 3) IPSec HW capability: 2 Gbit/s DL+UL 4) SW support with RL10 5) SW support with RL20

Flexi Multiradio BTS System Module with Flexi Transport sub-module

FTIB

2 x GE 1) 4 x E1/T1/JT1 2) IPSec 3)4) ToP (IEEE1588-2008), Sync Ethernet Ethernet switching 4)

Non-blocking throughput performance without IPSec

1) 2 x GE electrical or 1 x GE electrical + 1 x GE optical via SFP module 2) E1/T1/JT1 interface for synchronization 3) IPSec HW capability: 160 Mbit/s DL+UL 4) SW support with RL20

Figure 62 Flexi Transport sub-Modules for LTE

83 (86)

Radio Transport PM


10. LIST OF FEATURES LTE132 “VLAN based traffic differentiation” (RL10, RL15TD) ............................................................37 LTE875 “Different IP addresses for U/C/M/S-plane” (RL10, RL15TD)................................................37 LTE775 “SCTP multi-homing (MME)” (RL20, RL15TD)......................................................................45 LTE649 “QoS aware Ethernet switching” (RL20, RL15TD) ................................................................46 LTE118 “Fast Ethernet (FE) / Gigabit Ethernet (GE) electrical interface” (RL09, RL05TD).................47 LTE119 “Gigabit Ethernet (GE) optical interface” (RL09, RL05TD) ....................................................47 LTE491 “FlexiPacket Radio Connectivity” (RL20, RL15TD) ...............................................................47 LTE664 “LTE transport protocol stack” (RL09, RL05TD)....................................................................48 LTE131 “Traffic prioritization on IP layer” (RL10, RL05TD) ................................................................56 LTE129 “Traffic prioritization on Ethernet layer” (RL10, RL15TD) ......................................................57 LTE138 “Traffic shaping” (RL10, RL15TD).........................................................................................59 LTE134 “Timing-over-Packet” (RL10) ................................................................................................63 LTE891 “Timing-over-Packet with phase synchronization” (RL25TD) ................................................63 LTE713 “Synchronous Ethernet” (RL10) ............................................................................................65 LTE710 “Synchronization from PDH interface” (RL10) .......................................................................66 LTE711 “Synchronization from 2.048MHz signal” (RL10)...................................................................67 LTE689 “LTE IPsec Support” (RL10, RL15TD) ..................................................................................68 LTE564 “IPsec on FTIB” (RL20).........................................................................................................68 LTE150 “OAM Transport Layer Security (TLS) Support” (RL10, RL15TD) .........................................68 LTE140 “Ethernet OAM” (RL20, RL15TD) .........................................................................................76 LTE154 “SON LTE BTS Auto Connectivity” (RL10, RL15TD) ............................................................77 LTE720 “SON LTE BTS Auto Configuration” (RL10, RL15TD)...........................................................79 LTE800 “FTLB” (RL09, RL05TD) .......................................................................................................80 LTE707 “FTIB” (RL10) .......................................................................................................................80

84 (86)

Radio Transport PM


11. REFERENCES [IEEE802.1p]

IEEE 802.1p

[IEEE802.1q]

IEEE 802.1q - 2005, Virtual Bridged Local Area networks

[IEEE802.1ad]

IEEE 802.1ad - 2005, Virtual Bridged Local Area Networks - Amendment 4: Provider Bridges

[IEEE 802.3]

IEEE 802.3 – 2004, "Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications"

[IEEE1588-2008] IEEE 1588 - 2008, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems [LTE for UMTS]

LTE for UMTS - OFDMA and SC-FDMA Based Radio Access Harri Holma, Antti Toskala, Wiley, 1st edition, 2009

[MEF6.1]

Metro Ethernet Forum, Technical Specification 6.1 Ethernet Services Definitions - Phase 2

[MEF10.1]

Metro Ethernet Forum, Technical Specification 10.1 (Ethernet Services Attributes Phase 2)

[MEF11]

Metro Ethernet Forum, Technical Specification 11 (User Network Interface (UNI) Requirements and Framework)

[RFC792]

IETF RFC 792, Internet Control Message Protocol

[RFC793]

IETF RFC 793, Transmission Control Protocol (TCP)

[RFC826]

IETF RFC 826, Address Resolution Protocol (ARP)

[RFC894]

IETF RFC 894, A Standard for the Transmission of IP Datagrams over Ethernet Networks

[RFC1191]

IETF RFC 1191, Path MTU Discovery

[RFC1323]

IETF RFC 1323, TCP Extensions for High Performance

[RFC1981]

IETF RFC 1981, Path MTU Discovery for IP version 6

[RFC2131]

IETF RFC 2131, Dynamic Host Configuration Protocol

[RFC2132]

IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions

[RFC2409]

IETF RFC 2409, The Internet Key Exchange (IKE)

[RFC2474]

IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

[RFC2475]

IETF RFC 2475, An Architecture for Differentiated Services

[RFC4306]

IETF RFC 4306, Internet Key Exchange (IKEv2) Protocol

[RFC4861]

IETF RFC 4861, Neighbor Discovery for IP version 6

[SDI]

NSN, Secure Device Identity solution J. Kosonen, 20.03.2009, v.2.0

[TS23.401]

3GPP TS 23.401, GPRS enhancements for E-UTRAN access; Stage 2

[TS23.402]

3GPP TS 23.402, Architecture Enhancements for non-3GPP accesses; Stage 2

[TS33.210]

3GPP TS 33.210, 3G Network domain security (NDS), IP layer security

[TS33.310]

3GPP TS 33.310, Authentication Framework

85 (86)

Radio Transport PM


[TS33.401]

3GPP TS 33.401, Draft technical specification for LTE/SAE

[TS36.300]

3GPP TS 36.300, Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Stage 2 overall description

86 (86)

Radio Transport PM

12. CHANGE HISTORY v1.0

03-Jul-2009

v2.0

22-Oct-2009

v3.0

19-Feb-2010

v4.0

24-Jun-2010


LTE Transport Tutorial

Recommend Documents