Meet the Needs of LTE Backhaul with the Tellabs 8600 Smart Routers

APPLICATION NOTE 

Meet the Needs of LTE Backhaul with the 

Tellabs ® 8600 Smart Routers 

The introduction of LTE changes the nature and requirements of 

mobile backhaul networks. As operators evolve their networks to 

Long Term Evolution (LTE), they need a backhaul network that 

enables more capacity and flexibility — not one that becomes a 

bottleneck. To maximize efficiency, operators should address these 

requirements as they’re planning and deploying a new backhaul 

network. 

LTE backhaul networks must provide great flexibility while meeting 

the scalability and operational requirements for traffic aggregation 

in large radio access networks. This application note highlights the 

main requirements for LTE, and some ways to address them. 

New LTE Architecture Brings Both Benefits and 

Challenges 

Traditional TDM-based transport technologies are not cost-efficient 

for LTE backhaul, which delivers tremendous, wireline-like speeds to 

the end user. So, operators are migrating to IP. 

LTE architecture is based on the concept of a flat IP architecture. 

So, the roles of the Radio Network Controller (RNC), Serving GPRS 

Support Node (SGSN) and Gateway GPRS Support Node (GGSN) 

have been redistributed to the LTE Core and the radios. As shown 

in Figure 1, the RNC functions in LTE networks move to the eNB. The 

SGSN functions are split into the Mobility Management Entity (MME) for 

control plane traffic and the Serving Gateway (S-GW) for user plane. 

In this new architecture, all the traffic is carried over IP. This leads to 

the implementation of new interfaces (S1 and X2), while the Iub and 

Iu interfaces for UMTS R99 disappear. 

GEOGRAPHICAL DISTRIBUTION 

BTS 

Abis 

BSC 

Figure 1: RAN Architectures for Data Traffic in 2G, 3G and LTE 

lu 

SG SN 

NB 

Access 

1ub 

Level 2 

aggregation 

RNC 

Level 1 

aggregation 

lu 

Core 

MME 

S/P- 

GW 

EPC 

eNB 

X2 

S1-U 

S1-MME 

New Requirements for LTE Backhaul 

The new, flat, IP architecture in LTE networks brings a new set of 

requirements for backhaul networks. Packet forwarding by the 

communicating Radio Access Network (RAN) devices (MMEs, 

S/P-GWs, eNBs) is based on Layer 3 (L3) IP addressing. This is 

supported by various underlying infrastructures. Additionally, the 

architecture in LTE is no longer strictly a point-to-point topology 

like in 3G networks. LTE networks need more diverse connectivity 

between the RAN network elements. The flat IP architecture and the 

absence of an RNC also create a need for providing security in the 

backhaul network, because the mobile core network is exposed. 

One of the benefits of an LTE network is a decreased delay for 

users, compared to mobile data services of previous generations. 

Therefore, fair, QoS class-based traffic management in the transport 

network becomes more important. To deliver these types of services, 

it is critical that operators align delay requirements end-to-end. 

This trend — kicked off by the introduction of data services for 

3G — continues with the dramatically increased data rates LTE 

networks offer. This trend puts more pressure on decreasing the 

price per bit in the mobile backhaul. Evolving to packet transport 

lowers the cost per bit for transport. But at the same time, 

this evolution forces operators to redesign the synchronization 

distribution network. The same level of syntonization, as required 

in 2G and 3G networks, is sufficient in the first phases of LTE 

deployments. But, further developments in LTE-Advanced require 

more accuracy and phase synchronization distribution. 

This paper uses the term “syntonization” to refer to frequency 

alignment of network clocks. This functionality is also 

commonly called “timing synchronization” and “frequency 

synchronization.” 

When discussing phase alignment of clocks, this paper uses the 

common industry term “phase synchronization.” 

LTE networks increase the capacity of the air interface compared 

to 3G technologies. But there is a limit to what can be provided 

with currently defined LTE standards. Cell size also limits the 

available user bandwidth and coverage. This determines the total 

number of users that can be served within a certain geographical 

area. Operators can consider small cells to increase the capacity 

in densely populated areas. The small cells (micro and pico cells) 

are located geographically in the same area as a macro cell, but 

offer capacity for increased number of users within the reach of the 

See tellabs.com for more information about Tellabs Solutions

2 MEET THE NEEDS OF LTE BACKHAUL WITH THE TELLABS 8600 SMART ROUTERS 

small cell. This kind of architecture also demands an additional, and 

extremely cost-optimized, aggregation capability at the connected 

macro sites. In some cases, operators may even need an external 

transport device next to the small cell site device. This will create a 

clear demarcation and aggregation between the radio and backhaul 

domains. 

Tellabs 8600 Routers Enables Flexibility in LTE Backhaul 

To address the architectural changes in LTE networks described 

above, operators need backhaul networks that provide more 

flexibility for IP connectivity than just pure point-to-point or hub 

and spoke topologies. IP routing inherently provides a scalable and 

manageable forwarding mechanism for the multipoint-to-multipoint 

IP connectivity that LTE backhaul requires. IP routing also ensures 

flexibility for possible changes in future LTE backhaul architectures. 

MPLS functionality, on the other hand, enables needed traffic 

separation and tight control of traffic flows including end-to-end 

resiliency. 

BGP-based MPLS IP VPN is an optimal option to separate traffic 

flows in the different LTE interfaces, as proposed in Figure 2. Figure 

2 highlights the high-level architecture of an LTE backhaul network 

with the Tellabs ® 8600 Smart Routers. By separating IP routing 

domains with different VRFs, this architecture provides clear visibility 

of the different connections for planning, provisioning, monitoring 

and troubleshooting activities. 

IP VPN for the S1-U and S1-MME provides point-to-point 

connectivity between eNodeBs and S-GW and MMEs, which may 

be collocated. As the LTE network grows, operators can utilize 

additional S-GWs and MMEs for resiliency and to extended capacity. 

As a result, operators will need to home the connections from an 

eNodeB to these additional S-GWs and MMEs. The initial point-topoint 

connection becomes a point-to-multipoint connection, where 

the S-GWs and MMEs are reachable from all eNodeBs. Operators 

must add additional end-points to the S1 IP VPN flexibly, without 

interruption to existing traffic. 

The topology requirement for the X2 interface is different from 

the S1 interface. So, operators may be able to utilize a separate 

IP VPN for the X2 interface between a group of neighboring 

eNodeBs. This applies if the X2 traffic does not need to pass 

through a centralized IPsec gateway. This IP VPN is already initially 

multipoint-to-multipoint in nature. This is because the eNodeBs 

require connectivity to the neighboring eNodeBs, and they require 

a reliable X2-based handover capability. In the initial phase of 

LTE deployments, the X2 interface may not be necessary. This is 

because the first phase end devices require reduced mobility (i.e. 

dongles for laptops), deployments are limited and the number 

of users is fewer. These factors result in a modest number of 

handovers. However, LTE-based mobile user devices (i.e. smart 

phones) become more widespread and the networks will expand. 

Then, the X2 interface will likely be used to limit the signaling load 

on the MME and to provide more reliable and lossless handovers. 

As seen in Figure 3, the traffic separation using the IP VPN 

architecture may start already at the cell site. The VLANs associated 

with the different LTE interfaces and handed over by the eNodeB are 

terminated at the first physical interface in the backhaul network. 

Access 

Aggregation 

Core 

VRF 

VRF 

VRF 

8609 

eNodeB 

VRF 

eNodeB 

VRF 

VRF 

VRF 

VRF 

VRF 

IP VPN for 3G 

IP VPN for LTE 

IP VPN for OAM 

VRF 

8000 INM 

8630 

8600 


VRF 

VRF 

VRF 

8607 

eNodeB (IP) 

VRF VRF 

8611 

VRF 

8660 

VRF 



VRF 

VRF 

8609 

eNodeB 

eNodeB 

VRF 

RNC(IP) 

Figure 2: IP VPN design optimizes LTE Backhaul 

S-GWs 

MMEs 



Therefore, the VLAN scalability and management, in addition to 

the Ethernet broadcast domain planning have already been tackled 

inherently. The aggregation device at a macro cell site functions 

additionally as an aggregation and demarcation device for possible 

small cell sites located in the area. 

Operators also need connectivity between the network elements 

(both RAN and backhaul) and the operations center. This includes 

the management connectivity between the Tellabs ® 8000 Intelligent 

Network Manager (INM) and the Tellabs 8600 network elements. 

Another IP VPN can help accommodate this OAM traffic. 

Small Cells 

VRFs 

VLANs 

OAM 86113G IP 

X2 

S1- 

U/MME 

Figure 3: IP VPN based traffic separation at cell site 

Macro Cell 

a) 

ASy 

Growing and Dynamic LTE backhaul networks need a 

Hierarchical IP VPN Architecture 

Operators with growing and dynamic LTE backhaul network can 

address scalability with a hierarchical IP VPN architecture using 

the Tellabs 8600 LTE backhaul solution. Figure 4 depicts the 

different alternatives to address iBGP neighbor scalability and IP 

address scalability. To limit the number of direct iBGP neighbors, 

operators can use the route reflector model depicted in Figure 4 

part c). Operators can additionally limit the number of IP routes to 

be advertised in the network, as depicted in Figure 4 part b). To do 

this, operators can use route aggregation at the Autonomous System 

Border Router (ASBR). To learn more about these architectures 

including the Tellabs developed inter-AS option for IP VPNs, read 

Tellabs’ IP VPN Application Note at www.tellabs.com. 

LTE Backhaul Networks Need Better Security 

LTE networks have different backhaul security requirements than 2G 

and 3G networks. LTE’s basic goals include high data-throughput 

rates, improved spectrum efficiency, reduced latency, improved 

coverage and packet-based support for multiple radio access 

technologies. These goals are driving the evolution of the mobile 

network to a more efficient, all-IP infrastructure. IP-based transport 

is more open and therefore more vulnerable than transport based on 

TDM technology. 


PE 


PE 

iBGP 


PE 


iBGP PE 


PE 


PE 

Flat IP VPN 

Full iBGP mesh 

b) c) 

ASx 

ASy 

ASy 


U-PE 


PE 


U-PE 

eBGP 


ASBR 


iBGP N-PE 


PE 

iBGP 


RR 


iBGP PE 


U-PE 


N-PE 

Hierarchical IP VPN 

Tellabs InterAS-option 



PE 

PE 

Hierarchical IP VPN 

Route Reflector based 

Figure 4: Enhanced Scalability Options for IP VPN Architectures 



In 3G networks, traffic is encrypted between the subscriber 

equipment, NodeB and the RNC – which is installed in a “trusted” 

environment, such as a secure building. 

With LTE, air interface security (encryption) measures are terminated 

at the base stations, or eNodeBs. In an effort to increase network 

capacity, the eNodeBs, pico and femto cells are likely to be deployed 

in publicly-accessible locations such as airports and shopping 

centers. It is nearly impossible to protect the active electronics 

in these locations. The result is that eNodeBs are in unsecure 

locations, where IP connectivity may open a direct access to 

vulnerable network core functions. This would create a security risk 

for the entire network. 

Additionally, 3G architectures typically link each node with a single 

RNC. However, LTE architectures, according to the Next Generation 

Mobile Networks (NGMN) Alliance, potentially enable each eNodeB 

to support up to 32 X2 interfaces (meshed with other eNodeBs) and 

up to 16 S1 interfaces to the core network. As a result, many more 

elements in an LTE network are vulnerable to attack than in a 3G 

network. 

Operators need to provide end-to-end security that operates at the 

packet processing layer to protect the network and higher-layer 

applications. So, the Internet Engineering Task Force (IETF) has 

defined a suite of security protocols, collectively known as Internet 

Protocol Security or “IPsec.” IPsec authenticates and encrypts 

each IP packet within a communications session. So, it is capable 

of providing secure communications on a host-to-host, network-tonetwork 

and network-to-host basis. 

Tellabs mobile backhaul solutions can ensure a high level of security 

functionality by supporting IPsec functionality. This functionality 

can be integrated into the access backhaul elements, such as 

aggregation sites, or centralized into the backhaul devices handling 

the IP connectivity at the gateway sites. With stand-alone security 

gateways, the backhaul network must offer flexible connectivity for 

different deployment scenarios. Operators can then choose the 

deployment model that gives the best fit for their security strategy. 

More Stringent Service Quality in LTE 

In 2G and 3G networks, the signaling traffic poses strict criteria for 

the latency between the base stations and the controller (BSC and 

RNC respectively) in the order of 30-40 ms. If these criteria are not 

met, the base station will lose the connection to the controller. All 

active services are lost, and users experience delays. In the overall 

delay budget, the significance of the backhaul delay is relatively 

low. Compared to 3G, LTE reduces the latency for the user traffic. 

Therefore, the delay introduced by the backhaul network becomes 

more significant. Furthermore, radio network control functions are 

integrated into the eNodeB. So, similar strict latency requirements 

are no longer needed in LTE. Therefore, the latency requirements for 

LTE backhaul come purely from the service quality perspective. If the 

backhaul network becomes the bottleneck for latency, it will defeat the 

goal of reduced delays for user traffic. 

LTE architectures greatly simplified QoS signaling with the 

introduction of a QoS Class Identifier (QCI). This points to a set of 

QoS metrics. The QCI is associated with each bearer, or IP flow, 

between the user terminal and the Evolved Packet Core (EPC). The 

network utilizes the QCI and additional QoS-related parameters 

for Connection Admission Control. This ensures that the required 

resources for the defined service class characteristics are available 

in the radio network. Additionally, the scheduling functionality in the 

eNodeB utilizes the QoS information for offering fair treatment to 

packets towards the radio interface. 

The QCI is not visible to the transport network. Therefore, to 

guarantee the required service level also in the backhaul network, 

the QCI value must be mapped to the IP headers of the packets 

transmitted from the eNodeB and the SAE-GW. 

Example QCIs have been defined in 3GPP standard 23.203. These 

are shown in Figure 5 with their associated QoS parameters. The 

mapping between QCI and standard DiffServ service classes has not 

been defined in standards. An option for the mapping to DiffServ 

Per-Hop Behaviors is suggested also in Figure 5. A Guaranteed Bit Rate 

(GBR) can be defined and associated to a QCI category. 

QCI 

Resource 

Type 

Priority 

Packet 

Delay 

Budget 

Packet 

Error Loss 

Rate 

Example Service 

1 Guaranteed 2 100 10 -2 Conversational Voice EF 

2 

BitRate 

4 150 10 -3 Conversational Video (Live Streaming) AF3 

(GBR) 

3 3 50 10 -3 Real Time Gaming EF 

4 5 300 10 -6 Non-Conversational Video (Buffered Streaming) AF4 

5 Non- 

1 100 10 -6 IMS Signalling AF4 

6 Guaranteed 6 300 10 -6 Video (Buffered Streaming) 

AF1 

Bit Rate 

TCP-based (eg., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) 

(Non-GBR) 

7 7 100 10 -3 Voice, Video (Live Streaming), Interactive Gaming AF2 

8 8 300 10 -6 Video (Buffered Streaming) 

AF1 

9 9 300 10 -6 TCP-based (eg., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) BE 

Figure 5: LTE QCI Definitions and Mapping Example 

DiffServ 

PHB 



This guaranteed bit rate is used for connection admission control in the 

eNodeB and radio interface, but is not reflected in the backhaul network. 

Furthermore, operators must make sure that the whole end-to-end 

path from the EPC to the eNodeB is aligned to a consistent QoS 

marking and handling. With an end-to-end IP routed solution, such as 

the Tellabs 8600 routers, the QoS mapping configuration is simplified. 

This is because a single mapping at the hand-over interface from the 

eNodeB and SAE-GW to the network is sufficient to ensure the proper 

and consistent treatment through the backhaul network. Operators 

do not need to configure further mappings from different layers (e.g. 

Ethernet) for IP unaware devices. Additionally, Tellabs 8000 intelligent 

network manager tools make the QoS-related configurations, 

monitoring and troubleshooting easy. 

LTE Brings Syntonization and Synchronization 

Challenges 

The majority of LTE deployments today require the same level 

of accuracy for syntonization (i.e. frequency synchronization) 

between the eNodeBs as has been required in the past by 2G and 

3G networks. Therefore, in this respect, the introduction of LTE does 

not pose a challenge in itself before LTE-Advanced deployments. The 

syntonization challenge, however, is created by the evolution of the 

backhaul network from TDM-based technology to IP and Ethernet. 

Syntonization distribution was inherent in the SDH/SONET-based 

devices, but the same no longer applies for Ethernet and IP-based 

packet networks. Tellabs 8600 routers address this challenge in 

mobile backhaul solutions for LTE. The whole platform was designed 

from day one to be fully synchronous with a high quality node clock. 

Tellabs 8600 routers also synchronize the output signals, whether 

they are traditional TDM interfaces or Ethernet. 

Multivendor and multitechnology backhaul networks that carry 

mobile traffic are not always synchronous end-to-end. Therefore, 

operators must implement additional mechanisms to provide 

syntonization to the base stations. One of the most attractive 

mechanisms is IEEE1588v2, which provides an end-to-end 

syntonization mechanism over packet networks. The IEEE1588 slave 

functionality is embedded in the devices of Tellabs 8600 routers to 

syntonize the network element. It may be preferable to separate the 

IEEE1588 traffic to an IP routing domain of its own using an additional 

IP VPN. The syntonized network element, on the other hand, can pass 

the synchronous signal to the LTE eNodeB. With the Tellabs 8600 LTE 

backhaul solution, operators can get rid of costly TDM facilities to the 

cell sites that existed purely for syntonization purposes. 

To help in the migration process Tellabs 8600 network elements 

provide also testing functionality to ensure the network and IEEE1588 

can provide good quality syntonization to the base stations. This 

functionality is presented in Figure 6. 

E1/T1 only 

for sync 

TDM 

network 

1588v2 

master 

E1/FE/GE 

1588 

8605 

GE/FE 

for services 

Packet 

network 

GE 

10GE 


RNC 

1 

Configure 1588 as 

a clock reference 

Enable Monitoring 

(Set fault filtering) 

2 

Open the clock 

monitoring window 

TIE and MTIE against 

selected mask 

Monitor for alarms 

for mask crossing 

Monitoring continues 

3 

Remove the E1 

at convenience 

Some E1 may be 

left for further 

monitoring 

Figure 6: Integrated Synchronization Quality Measurement for Migration from Legacy E1 Sync to IEEE1588 



Additional challenges are created by the requirement for more 

accurate phase synchronization. This is needed for TDD-mode LTE 

technology, coordinated multipoint transmission (CoMP, defined 

in 3GPP R10) and location-based services. Operators typically use 

an end-to-end model with IEEE1588 for syntonization. An end-toend 

model means that only the IEEE1588 master and slave devices 

participate in the IEEE1588 message exchange. The intermediate 

network elements are not IEEE1588-aware. This end-to-end model 

will no longer be sufficient. To achieve the required accuracy and 

phase sync in TDD-mode LTE and for location-based services, each 

hop in the network must be phase synchronized. Operators can 

achieve this by implementing IEEE1588 boundary clock functionality 

in the intermediate network elements. The Tellabs 8600 routers 

provide product compatibility and a migration path for the required 

synchronization evolution. 

End-to-end Management Makes LTE Backhaul 

More Scalable 

Operators can easily manage frequent changes in the mobile 

backhaul with the Tellabs 8000 intelligent network manager VPN 

Provisioning tool. For example, operators can simultaneously add 

multiple new sites to the IP VPN as one simple guided process 

with the IP VPN End-point Wizard. This is especially critical for the 

expanding LTE deployments in competitive environments. In these 

cases, provisioning of backhaul connectivity must not slow down 

turning up new sites and expanding coverage. 

Operators generally perceive IP VPNs and the related routing 

protocols and parameters to be too complex to manage. Easy, endto-end 

service level management that supports the Self-Organizing 

Network (SON) concept has been a key component of Tellabs 8600 

routers from the beginning. The GUI-based Tellabs 8000 intelligent 

network manager makes IP VPN provisioning easy for the operator. 

The system automates many complicated tasks and hides the 

unnecessary details from the user. The user can select IP VPN endpoints 

from the GUI. They can copy or define the service-related basic 

parameters from ready-made templates. The Tellabs 8000 intelligent 

network manager configures all the elements related to the IP VPN 

with the needed objects such as VRFs, Route Distinguishers and 

Route Targets. The system gives detailed reports in case there are any 

conflicts in the configuration. Multiple in-built wizards guide the user 

through the right steps. These features speed up operations and help 

to avoid mistakes. 

The Tellabs 8000 intelligent network manager makes verifying and 

troubleshooting an IP VPN easy with Packet Loop Test tools. With 

the Packet Loop Test tool, operators can remotely test, without 

external testers, the whole IP VPN or just part of it for connectivity, 

delay, jitter, through-put and packet loss. 

The Tellabs 8000 intelligent network manager is built to manage 

large carrier networks, which may consist of up to 30,000 network 

elements. Still, it achieves the same service level of management 

granularity. 

Figure 7: Tellabs 8000 INM tools for IP VPN provisioning and testing 



Make LTE Backhaul Simpler and More Scalable with the 

Tellabs 8600 Routers 

The Tellabs 8600 routers provide a great IP VPN feature suite for 

IP based 3G, LTE and LTE-Advanced mobile backhaul networks. It 

includes integrated service level management tools, which takes the 

IP VPN provisioning, change management and maintenance to the 

next level. 

With the Tellabs 8600 routers, LTE mobile backhaul may be built costefficiently 

and with greater scalability on IP/MPLS and IP VPN — even 

down to the cell sites. Network architecture options, such as dividing 

the network into regions, and platform flexibility enable operators to 

choose the right implementation scope to meet their needs. 

Next Step: 

Visit http://www.tellabs.com/products/8000/ 

tellabs8600.shtml to access more case 

studies and application notes on how Tellabs 

is helping operators advance their 

backhaul networks. If you have a question 

about Tellabs mobile backhaul solutions, 

please email ask@tellabs.com. 

It’s paramount that operators have reliable and scalable 

management tools in mobile backhaul networks where IP VPNs are 

very large and change often. The Tellabs 8000 intelligent network 

manager makes the IP VPN management a straightforward, routine 

task for operators. It hides the various technology layers from users 

and automatically builds service-related objects into the database 

and elements. 

The IP/MPLS-based Tellabs 8600 smart routers and Tellabs 8000 

intelligent network manager have been used in mobile backhaul 

applications since 2005. The typical applications have been the 

transport of 3G and 2G traffic over MPLS-based Ethernet, TDM and 

ATM pseudowires as well as IP and IP VPN connectivity for IP based 

services. IP/MPLS based design and platform flexibility enable 

operators to mix and match multiple interface, protocol and service 

types into a single platform. By choosing the right devices, line cards 

and interfaces, operators can optimize their platform. The Tellabs 

8600 routers enable operators to fulfill the different requirements for 

LTE, 3G or 2G transport depending on their unique network evolution 

path. 

North America 

Asia Pacific 

Europe, Middle East & Africa 

Latin America & Caribbean 

Tellabs 

1415 West Diehl Road 

Naperville, IL 60563 

U.S.A. 

+1 630 798 8800 

Fax: +1 630 798 2000 


3 Anson Road 

#14–01 Springleaf Tower 

Singapore 079909 

Republic of Singapore 

+65 6215 6411 

Fax: +65 6215 6422 


Abbey Place 

24–28 Easton Street 

High Wycombe, Bucks 

HP11 1NT 

United Kingdom 

+44 871 574 7000 

Fax: +44 871 574 7151 


Rua James Joule No. 92 

EDIFÍCIO PLAZA I 

São Paulo – SP 

04576-080 

Brasil 

+55 11 3572 6200 

Fax: +55 11 3572 6225 

The following trademarks and service marks are owned by Tellabs Operations, Inc., or its affiliates in the United States and/or in other countries: TELLABS ® , TELLABS and T symbol ® , T symbol ® , and SMARTCORE ® . Statements herein may contain 

projections or other forward-looking statements regarding future events, products, features, technology and resulting commercial or technological benefits and advantages. These statements are for discussion purposes only, are subject to change and are 

not to be construed as instructions, product specifications, guarantees or warranties. Actual results may differ materially. The information contained herein is not a commitment, promise or legal obligation to deliver any material, code, feature or functionality. 

It is intended to outline Tellabs’ general product direction. The development, release and timing of any material, code, feature or functionality described herein remains at Tellabs’ sole discretion. 

© 2012 Tellabs. All rights reserved. 74.2488E Rev. B 09/12

Meet the Needs of LTE Backhaul with the Tellabs 8600 Smart Routers

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?