ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

LTE transport concepts and issues

Updated on February 20, 2015
Antonios Karvelas profile image

15+ years experience in technology development. Experienced in understanding and working engineering concepts and market requirements.

1. Introduction

Whereas the Radio Network Layer (RNL) for LTE is being specified by 3GPP, for the Transport Network Layer (TNL) references to protocols outside 3GPP are made. The main standardization bodies that define the Transport Network Layer (TNL) are IETF (Internet Engineering Task Force), IEEE (Institute of Electrical and Electronics Engineers), ITU-T (International Telecommunication Union - Telecommunication) and MEF (Metro Ethernet Forum).

This document tries to give an overview of generic LTE transport concepts and issues.

2. LTE Network Architecture

I will not give details about LTE network architecture. There are many good LTE tutorials in the Web. Main characteristics of LTE networks are the following:

  • flat architecture
  • circuit switched (CS) part has been eliminated
  • the LTE network elements are:
    • Mobility Management Entity (MME): manages and stores the UE context
    • SAE Gateway (SAE-GW): contains the Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW)
    • eNodeB: provides the air interface to the UE

3. LTE traffic types

Evolved Packet System (EPS) reference points are given from the figure below.

X2 is the control & user plane reference point between two eNodeBs.

S1-U is the user plane reference point between eNodeB and the SAE-GW.

S1-C is the control plane reference point between eNodeB and the MME.

The Synchronization plane (S-plane) is used to connect the Synchronization Slave in the eNodeB with the Synchronization Grandmaster in the network.

Management plane (M-plane) is not specified by 3GPP, but used for O&M traffic.

4. LTE Transport Requirements

4.1 Throughput (Capacity)

LTE has high cell peak rates due to large available bandwidth. So for 20MHz bandwidth we can achieve 150Mbps Downlink (64QAM 2x2 MIMO) and 75Mbps Uplink (64QAM single stream). But these cell peak rates are achievable only under ideal conditions i.e. very close to the Base Station and without interference from other cells.

Of the same importance is the cell average capacity. LTE provides higher spectral efficiency than other similar systems. Simulations show 1.75 and 0.75 b/s/Hz/cell for LTE Release 8 [REF1].

The basic dimensioning tasks are:

  • Last-mile bandwidth dimensioning for one eNodeB
  • Aggregate bandwidth dimensioning of n eNodeB

There are two methods to calculate the required transport capacity:

  • Based on air interface capabilities
  • Based on user traffic profile

While dimensioning based on the user traffic profile requires planning data from the operator, dimensioning based on air interface is very quick and simple and it is based on radio-interface average and peak cell throughput. So it is sufficient for initial planning considerations.

4.1.1 Last-mile bandwidth dimensioning

X2 traffic

The X2 interface between eNodeBs is mainly used for user traffic during UE handover between eNodeBs.

The volume of X2 traffic is often expressed as a volume of S1 traffic. NGMN [REF2] proposes a typical value of 4% but for sites serving highly mobile users an X2 overhead of about 10% is suggested.

Control Plane, OAM and Synchronization Signaling

Capacity for Control Plane Signaling on both S1 and X2 is negligible in comparison to associated user plane traffic (~0.3Mbps). The same is true for M-plane (~1Mbps) and synchronization signaling (S-plane).

User Plane

In order to calculate the transport capacity required for specific capacity at the air interface, we need to subtract the air overhead and to add transport overhead.

Concerning the air overhead, the protocol overhead for the PDCP, RLC and MAC is 9 bytes. If a mix of packet sizes is assumed then the air overhead could be estimated to be around 2% (REF1].

The user plane transport overhead in S1_U and X2_U interfaces depends on the utilization of IPsec. So the total transport protocol headers for GTP-U, UDP, IP and Ethernet is 144 bytes with IPsec, and 78 bytes without it. For a traffic profile with 50% small (60 bytes), 25% medium-size (600 bytes) and 25% large (1500 bytes) IP packets, the transport overhead is about 27% with IPsec and about 15% without IPsec.

Transport Overhead
Number of bytes
IPv4 Header
(optional) IPSec ESP Header
(optional) IPSec AES IV
(optional) IPSec ESP Trailer
(optional) IPSec Authentication (ICV)
(optional) IPSec Tunnel IPv4 Header
Ethernet Header (incl. 4 bytes VLAN)
Ethernet IF Gap, Preamble & SFD
144 bytes (78 bytes)

Subtracting the air overhead (~2%) we need to add 25% with IPsec and 13% without IPsec to the data rate at the air interface in order to calculate the corresponding transport capacity.

Dimensioning Based on Cell Air Interface Capacity

There are three methods to for the dimensioning of the transport capacity. Let’s N the number of cells of one eNodeB site, Cpeak and Cavrg the peak and average capacity of one cell and Ctrs the required transport capacity.

- All-Average (Ctrs = N x Cavrg)

The transport link supports the aggregated average capacity of all cells.

- All-Average/Single-Peak (Ctrs = Max (N x Cavrg ; Cpeak))

The transport link supports the aggregated average capacity of all cells, while at least supports the peak capacity of one cell.

- All-Peak (Ctrs = N x Cpeak)

The transport link supports the aggregated peak capacity of all cells. The peak capacity is achieved under ideal air interface conditions and with a single user per cell. This method leads to over-dimensioning, so it is costly.

‘AllAverage/Single Peak’ is a good trade-off but it may be not suitable for hot spots (under-dimensioned) or for sites with low utilization (over-dimensioned).

All-Average/Single-Peak Last mile dimensioning example

For an eNodeB (DL=64QAM 2x2 MIMO, UL=64QAM single stream) with three sector and 10MHz channel bandwidth the air bandwidth is:

Downlink Ctrs = Max (N x Cavrg ; Cpeak)=Max[3x(DL spectral efficiency * channel BW) ; 75Mbps]= 75Mbps

Uplink Ctrs = Max (N x Cavrg ; Cpeak)=Max[3x(UL spectral efficiency * channel BW) ; 37.5Mbps]= 37.5Mbps

After subtracting the air overhead and adding the transport overhead, the required transport capacity is:

Downlink transport capacity with IPsec =75Mbps * 1.25 ~ 94Mbps

Uplink transport capacity with IPsec =37.5Mbps * 1.25 ~ 47Mbps

4.1.2 Aggregate link bandwidth dimensioning

For aggregate transport links the required transport capacity could be given by the following:

Transport Capacity=#cells x average cell capacity + transport overhead

Average cell capacity= spectral efficiency * channel BW = 1.75 * 10MHz=17.5Mbps

Transport overhead = 25% for IPsec

An example network of six eNodeBs (three cells each eNodeB) would require the following transport capacity.

4.2 Delay and Delay variation

There are delay requirements for user services (U-plane), from Radio Network protocols (C-plane) and from Synchronization (S-plane).

4.2.1 U-plane

Based on NGMN [REF3] the Backhaul solution must guarantee E2E maximum two-way delay of 10 ms and should guarantee 5 ms when and where required by the operator.

There is a relationship between U-plane delay and TCP throughput performance
as explained below.


A single TCP connection is rate limited by the ratio between the TCP window size and the RTT. Using a standard 64 KB TCP receive window size (RFC793), 20 ms RTT would limit the user service data rate at ∼25 Mbps for a single TCP connection in the steady state. In order to mitigate this limitation web browsers use multiple concurrent TCP connections and/or enlarge the receive window through TCP Window Scaling (RFC1323).

RTT also affects TCP connection start-up (“TCP slow start”). Because web sites have an average page size of 1 MB it can be assumed that most web traffic is transferred within the slow start phase, so TCP Window Scaling will not help.

4.2.2 C/M-plane

In LTE the transport latency requirements are mainly driven by user services (U-plane).

4.2.3 S-plane

For 2G and 3G base stations synchronization has been carried over TDM-based transport networks or derived from satellites (GPS). Since transport networks for LTE are IP based only, we need new solutions like Precision Time Protocol (PTP) and Synchronous Ethernet.

Transport network must support low delay variation (jitter) for PTP packets. Jitter up to ±5 ms can be tolerated from robust PTP slave implementations.

The PTP solution consists of a PTP Grandmaster (server) at the core site and PTP Slaves (clients) implemented in the eNodeBs, as shown in the figure below:

While LTE FDD requires only frequency synchronization (±50 ppb), LTE TDD requires also accurate phase synchronization (±1.5 μs).

For frequency synchronization PTP slaves can tolerate typical network jitter in the order of several milliseconds. For phase synchronization the network jitter requirements are more strict and also any uplink/downlink delay asymmetry negatively affects it. In order to solve this problem, all intermediate nodes on the synchronization traffic path need to support either boundary clock or transparent clock.

Synchronous Ethernet (SyncE), as per G.8261/8262/8264, is a Layer 1 mechanism for distributing frequency, so the stability of the recovered frequency does not depend on network load and impairments, but all intermediate nodes on the synchronization traffic path must support it.

5. LTE Transport Network Architecture

According to [REF6] a basic structure of a Mobile backhaul network is the following:

In [REF6] six different architectures are given.

  • Carrier Ethernet: This is a pure IEEE 802.1ad based scenario where Service VLANs (S-VLAN) are used to carry Customer VLANs (C-VLAN) across the Ethernet domain. One or more C-VLANs can be used per eNB. One or more MEF EVCs spans both Access and Aggregation networks.
  • Carrier Ethernet + L2/L3 VPN: In this case Access is implemented using Carrier Ethernet, while Aggregation is based on MPLS. One or more MEF EVCs spans Access network and L2/L3 VPN is used for the Aggregation.
  • MPLS access + L2/L3 VPN: This case is based on the transport capability of MPLS, which is also used in access. So, MPLS-TP is used to build connection oriented flows in the access domain as a way to enter a VPN into the aggregation. One or more MEF EVCs spans Access network and L2/L3 VPN is used for the Aggregation.
  • L2/L3 VPN in access + L2/L3 VPN in aggregation: Several combinations are possible but the most likely is a L3 VPN in the Aggregation, based on IP/MPLS, and a L2 VPN in access. No MEF EVCs exist in this case.
  • End-to-end (Multi-segment) Pseudowire: This case could use for example two pseudowire circuits, one for Access and one for Aggregation. No MEF EVCs exist in this case.
  • Full L3: This architecture is based on MPLS/MPLS-TP from the eNB to the MME and S/P-GW controllers. On top of MPLS/MPLS-TP the VPN could be a L2 or L3 VPN. The advantage here is that both Access and Aggregation belong to the same logical domain.

5.1 Carrier Ethernet deployment scenarios

[REF7] defines the following Ethernet services:

  • E-Line Service Type
  • E-LAN Service Type
  • E-Tree Service Type

Below there is an analysis about how these Ethernet services could be used for Mobile Backhaul networks.

5.1.1 E-Line Service Type

This architecture uses Point-to-point Ethernet Virtual Connections (EVC) between the eNodeB and Edge Router (or Security Gateway). Each eNodeB is identified by specific VLAN ID.

The Edge Router (or Security Gateway) performs routing of S1 traffic between eNodeBs and the core nodes as well as routing of X2 traffic between eNodeBs within one group and between eNodeBs belonging to different groups.

5.1.2 E-LAN Service Type

In this architecture eNodeBs belonging to the same group will be assigned to the same E-LAN. Each eNodeB group is identified by one VLAN ID. Inside the eNodeB group, each eNodeB is identified by its MAC address.

The S1 and X2 traffic between eNodeBs in the same group will be switched inside the E-LAN, while S1 traffic between eNodeBs and the core nodes as well as routing of X2 traffic between eNodeBs belonging to different groups will be routed by the Edge Router (or Security Gateway).

The drawback here is that the E-LAN is an open broadcast domain, so any L2 broadcast will reach any leaf node of the E-LAN. E-LAN is recommended if IPsec is not used.

5.1.3 E-Tree Service Type

The E-Tree service will have as root the Edge Router so connectivity between eNodeBs is not allowed. Also with E-Tree, L2 broadcast attacks are no longer possible.

If IPsec is not used, E-Tree is not recommended because of configuration complexity. In this case E-LAN is more suitable approach.

6. LTE Transport QoS

3GPP works on the QoS architecture at the service layer (RAN and mobile core) but the underlying mobile backhaul transport layer is not taken into account.

So there in a need to address the mobile backhaul network QoS and to align the LTE QoS architecture with the transport layer QoS mechanisms.

IETF, MEF and Broadband Forum are working for that. For example MEF [REF5] defines the following CoS model:

With the following performance objectives:

NGMN [REF4] performed a Service Flow Classification Poll and asked both operators and vendors what schemes they are applying in their network or plan to use for LTE.

They proposed all contributors to use the following template, with abstract CoS names:

Class Of Service

As [REF4] mentions the results were:

There is a high variance of service flow classification and their priorities between operators, both in the number of CoS used (from 4 up to 8) and the relative priority of some service flows. However, some service flows receive a very homogeneous treatment: QCI 9 has the lowest priority in all cases, and packet synchronization the highest.

The most stark contrast between answers is found in the Management Plane service flows, with answers ranging from C1 (highest priority) to C8. This, however, is possibly due to a different definition of "MP" being used in different organizations (for instance, inclusion of detection mechanisms for protection algorithms or not).

6.1 NGMN Service Flow Classification Proposal

NGMN proposal includes three different schemes:

  • Two-CoS Classification Scheme
  • Three-CoS Classification Scheme
  • Four-CoS Classification Scheme

6.1.1 Two-CoS Classification Scheme

Voice, Real-Time Gaming, Synchronization and Control Plane/OAM
Everything else

The Target Performance Indicators for the 2-CoS Scheme are shown in the table below.

(ms or Low/Medium/High)
Very Low

The values shown in the table above are for the end-to-end application level requirements.

3GPP suggests that 20ms can be considered a valid representative value for the delay in a mobile backhaul network between the PCEF (Policy & Charging Enforcement Function) and the base station.

6.1.2 Three-CoS Classification Scheme

Voice, Real-Time Gaming, Synchronization and Control Plane/OAM
2G Data (EDGE) and Real-Time Video
Everything else

The Target Performance Indicators for the 3-CoS Scheme are shown in the table below.

(ms or Low/Medium/High)
Very Low

Also in this scheme the values shown in the table above are for the end-to-end application level requirements.

3GPP suggests that 20ms can be considered a valid representative value for the delay in a mobile backhaul network between the PCEF (Policy & Charging Enforcement Function) and the base station.

6.1.3 Four-CoS Classification Scheme

Voice, Real-Time Gaming, Synchronization and Control Plane/OAM
2G Data (EDGE) and Real-Time Video
Premium Data (buffered Video, non-GBR Real-Time)
Everything else

The Target Performance Indicators for the 4-CoS Scheme are shown in the table below.

(ms or Low/Medium/High)
Very Low

6.2 Inter-layer Class of Service Alignment

It is clear that we need a mapping of the classes of service of different service and transport layers to each other, that is a “inter-layer CoS alignment”, such as between the IP and Ethernet layer for example.

Below is an example of aligning the CoS of the RAN service layer which is transported by an IP layer, which by turns is running on top of an Ethernet layer.


[REF1] THE LTE/SAE DEPLOYMENT HANDBOOK - Edited by Jyrki T. J. Penttinen

[REF2] Guidelines for LTE Backhaul Traffic Estimation by NGMN Alliance

[REF3] Next Generation Mobile Networks Optimised Backhaul Requirements Release Date: August 14th, 2008

[REF4] Integrated QoS Management by NGMN Alliance

[REF5] MEF 22 – Mobile Backhaul Implementation Agreement

[REF6] LTE backhauling deployment scenarios by NGMN Alliance Version: 1.4.2

[REF7] MEF 6.2 EVC Ethernet Services Definitions Phase 3 August, 2014

© 2015 Antonios Karvelas


    0 of 8192 characters used
    Post Comment

    No comments yet.


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)