Mobile Backhaul Reference Architecture - ICT Networks

REFERENCE ARCHITECTURE 

Mobile Backhaul Reference 

Architecture 

Copyright © 2011, Juniper Networks, Inc.

REFERENCE ARCHITECTURE - Mobile Backhaul Reference Architecture 

Table of Contents 

Introduction.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

High-Level Overview of Mobile Technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

Solution Profile Overview.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

What Constitutes a Mobile Radio Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

Mobile Core: PDSN/GGSN/SGSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

What is a Mobile Backhaul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

What are the Available Types of Backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

Flat IP Network Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Requirements from an IP Backhaul Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Transport and Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Reliability and Fault Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Network Configuration and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Legacy Backhaul Networks to Carrier Ethernet Migration Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Scenario B: BS Supports Ethernet in Addition to Legacy Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Solution Profile Overview.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Reference Solution Architecture Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Solution A: Umbrella Solution—Migration Strategy from 2/2.5 and 

3G Legacy Networks + Greenfield 3G/4G Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

Solution B: 3G/4G Backhaul Greenfield Deployment Subset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

Solution-Required Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

Design Considerations.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

VLAN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

Timing Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

Failure Recovery and Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

Solution-Type Profiles .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Solution A: Umbrella Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Solution B: Greenfield Deployment Subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

VPN Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

Conclusion.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

2 Copyright © 2011, Juniper Networks, Inc.


Table of Figures 

Appendixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

Examples of Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

J Series as an Access Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

CTP Series as an Access Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

About Juniper Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

Figure 1: Overview of a mobile backhaul network.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

Figure 2: 3GPP2 technology family. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

Figure 3: 3GPP technology family .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

Figure 4: Overview of a generic mobile backhaul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

Figure 5: Subcomponents of mobile backhaul network .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

Figure 6: ATM backhaul.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Figure 7: IP/Ethernet backhaul .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Figure 8: Services to be transported over Carrier Ethernet.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Figure 9: Components of IP RAN transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Figure 10: IP RAN QoS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Figure 11: MPLS-based transport.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Figure 12: Migrating to Carrier Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Figure 13: Co-existence of legacy technologies and Ethernet.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Figure 14: Legacy technologies carried over Ethernet network .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Figure 15: Dual support for Ethernet and legacy technology.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Figure 16: All IP-/Ethernet-based backhaul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Figure 17: High-level overview of solution.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

Figure 18: Simplified view of mobile backhaul network.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Figure 19: TDM-pseudowire-based technology migration.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Figure 20: TDM and Ethernet coexistence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

Figure 21: IP-/Ethernet-based mobile backhaul.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

Figure 22: Aggregation device internal to BGP domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Figure 23: Aggregation device external to BGP domain .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Figure 24: Example—BX7000 specific design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

Figure 25: Mobile backhaul test network .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

Figure 26: Logical view of mobile backhaul network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

Figure 27: VLAN tags at cell site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

Figure 28: Layer 2-based CoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

Figure 29: Layer 3 VPN-based CoS .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

Figure 30: VPLS view of mobile backhaul network .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

Figure 31: L3VPN view of mobile backhaul network.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

Figure 32: J Series as an access device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

Figure 33: CTP Series as an access device.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

Copyright © 2011, Juniper Networks, Inc. 3


Introduction 

Mobile backhaul networks have been gaining a lot of attention lately. There have been advancements in cellular 

technologies and the proliferation of consumer mobile devices such as smartphones and laptops capable of mobile 

broadband access. The newer cellular technologies have resulted in significant increases in connection speeds 

over the air both on the uplink and downlink—that is, to and from the user device. Needless to state, there have 

been a lot of improvements on the wired core network side. However, today, mobile backhaul networks that connect 

the access or RF side to the core of the mobile network have to catch up with all these changes and thus tend to 

counterbalance the enhancements on the rest of the network. 

At present, a large number of the existing backhaul networks are hierarchical and based on legacy technologies 

that are incapable of supporting higher speeds or service requirements. Most of these networks are based on 

traditional T1 circuit switching and used to transmit voice traffic. The introduction of the Apple iPhone in 2007 

heralded the first tolerable use of the Internet on a mobile handheld device. The subsequent smart mobile devices 

and unlimited data/voice services have led to the development of technologies supporting higher bandwidth and 

faster download rates. This has fueled the demand for higher backhaul network capacity and intelligence. Another 

important factor to bear in mind is that the cost of a T1-/E1-based backhaul increases with the bandwidth. Hence, 

there is a critical requirement to migrate the mobile backhaul network to technologies that can support quality of 

service (QoS) to separate traffic streams, timing synchronization, lower packet loss, and high availability (HA). 

The key drivers behind the demand for a new or reengineered mobile backhaul include: 

• Increase in data traffic and number of subscribers 

• Dynamically changing usage patterns 

• Variation in type of traffic transported across the network 

• Requirement for QoS-based prioritization of traffic 

• Timing synchronization 

Juniper Networks offers mobile backhaul solutions that can be either purely IP/Ethernet-MPLS based or a hybrid 

of Ethernet and other Layer 2 technologies such as ATM/T1-E1/Frame Relay. Juniper Networks products are suited 

for a wide range of mobile backhaul solutions that span migration strategies from legacy technologies to greenfield 

deployments that meet the requirements of the latest technologies. 

The primary focus of this document is on mobile backhaul architecture based on an Ethernet/MPLS solution 1 . This 

solution aims to describe the following concepts: 

• There can be multiple migration paths from the existing legacy technology-based backhaul networks. Some 

of these options can provide a migration strategy that fits with the long-term plan to move to the latest 

technologies such as LTE. 

• The functionality of the mobile backhaul network is independent and not influenced by the type of traffic that is 

transported across the network. 

• Services such as class of service (CoS), MPLS, and VPLS—coupled with features such as HA, OAM, and 

Reliability—can be leveraged for mobile traffic. 

• Mobile network operators that are already familiar with Juniper Networks ® Junos ® Operating System can 

implement all the IP and Carrier Ethernet 2 features with considerable ease. 

Figure 1 illustrates a mobile backhaul network that serves multiple generations of mobile technologies. There can 

be a device acting as the access gateway from the cell sites—the access type is dependent on the mobile technology 

generation. Thus the access gateway can service legacy TDM/ATM or IP/Ethernet technologies. Cell sites based on 

newer technologies can directly participate in the IP/Ethernet network. A variety of VPN services and CoS offerings 

are available on the Metro Ethernet network. MPLS serves as the transport mechanism for the data belonging to 

all these services. An aggregation device links the backhaul network to the network controller that interfaces with 

the mobile core. All the devices in the mobile backhaul need to be managed, provisioned, and monitored at node, 

service, transport, and network levels. 

1 

The Ethernet/MPLS solution references both the MEF22 (Mobile Backhaul Implementation Agreement) and the IP/MPLS Forum 20.0.0 standard. 

2 

When referring to Carrier Ethernet, this paper does not include transport services such as PBB, PBT, and connection-oriented Ethernet. 



Network Provisioning/Monitoring Fault Detection 

Wireline 

2G-GSM/CDMA 

Access Gateway 

Devices 

Wireline 

MSC 

ATM/TDM 

Capable 

2G BSC 

3G-UMTS/ 

CDMA/ 

EVDO/EDGE 

Ethernet Backhaul Network 

(L2/L3), IP/MPLS (with PWE) + 

VPN Services (L2VPN/L3VPN/ 

VPLS/NG-MVPN) + CoS 

3G RNC 

IP/Ethernet 

Capable 

Metro 

Network 

PE Router/ 

P Device 

Metro Network 

PE Router/ 

P Device and/or 

Aggregation Device 

4G SAE GW 

4G-LTE/WiMax 

IP/Ethernet 

ATM/TDM 

Scope 

Figure 1: Overview of a mobile backhaul network 

Highlights of the mobile backhaul solution discussed here include: 

• A main or unified scenario that offers migration strategies from legacy technologies such as TDM and ATM, IP-/ 

Ethernet-based design for greenfield and newer technologies such as WiMAX/LTE backhaul—This solution can 

be split into subsets based on the implementation applicability. One of the subsets that is described in addition 

to the umbrella solution is the greenfield deployment that is based on IP/Carrier Ethernet. 

• Flexibility of using a combined Layer 2- and Layer 3-based network—The requirement to use a Layer 2- or Layer 

3-based network that can offer services is dependent on the level of operator familiarity, existing infrastructure, 

and applications. 

• Aggregation performed closer to the BTS—Aggregation and Metro network functionality is pushed closer to 

the access. 

• VPN-based services across metro ring (E-Line 3 and emulated LAN [ELAN] 4 services)—These VPNs can offer 

either unicast or multicast services at Layer 2 or Layer 3 level. 

• Use of MPLS LSPs as transport mechanism in the metro ring. 

• User traffic prioritization and CoS. 

This document is intended to be a reference guide to those involved in planning and designing mobile backhaul networks. 

The mobile backhaul scenarios described here are based on products such as Juniper Networks BX7000 Multi- 

Access Gateway, EX Series Ethernet Switches, M Series Multiservice Edge Routers, and MX Series 3D Universal Edge 

Routers. RSVP-based MPLS is used as the transport mechanism for L3VPN and BGP-VPLS services within the Metro 

ring network. 

3 

E-Line is an MEF definition for different types of VPN connectivity. Please refer to the MEF standards for more details. 

4 

ELAN is an MEF definition for different types of VPN connectivity. Please refer to the MEF standards for more details. 



Framework 

Prior to launching into the discussion on the suggested backhaul scenarios, it is important to get familiar with the 

terms and concepts of mobile networks, available backhaul network options, and requirements of a next-generation 

backhaul network at a high level. This section helps provide such an understanding. The solution details are 

discussed later in the document. 

High-Level Overview of Mobile Technologies 

Mobile technologies are classified into different generations referred to as 2G/2.5G/3G/4G. Each generation of mobile 

technologies provides users with enhanced services, higher speeds, and better network capacity. Different bodies 

and forums such as 3GPP/3GPP2/ETSI/ITU recommend, approve standards, and advance the various technologies 

under each generation. Figure 1 and Figure 2 provides a brief summary of the different technology streams under 

each generation. 

Solution Profile Overview 

3GPP2 

2G – CDMAOne 

3G – CDMA2000 

EVDO 

Figure 2: 3GPP2 technology family 

GPRS 

EDGE 

3GPP 

2G – GSM 

3G – UMTS 

W-CDMA 

HSPA 

4G – LTE 

TD-CDMA/ 

TD-SCDMA 

3GPP Rel8 

E-UTRAN 

Figure 3: 3GPP technology family 

What Constitutes a Mobile Radio Access Network 

The main components of a Radio Access Network (RAN) are described briefly in the following sections. The 

terminology used for these components differs based on the technology that is used. Table 1 lists the different 

naming conventions used in the case of each technology. 



BTS 

A BTS is a device that can provide communication between mobile user equipment and a mobile network. The BTS 

communicates with the mobile user devices over the air interface. There can typically be as many as 50 BTS devices 

controlled by one BSC. (This document uses the generic term BS or RAN BS to refer to a cell tower/BTS.) 

BSC 

The main function of a BSC is to communicate and control multiple BTS devices over either the Abis or Iub interface. 

The BSC also controls handoffs that occur as a result of mobile devices moving between cell sites and communicates 

with the mobile core (The type of communication depends on interface to core that in turn depends on technology). A 

single 2G BSC can typically control as many as 50 BTS devices while a 3G RNC can control 200 NodeBs and up to 800 

base stations per BSC/RNC in a 2.5G/3G network. (This document uses the generic term RNC or RAN NC to refer to 

a BSC.) 

Mobile Core: PDSN/GGSN/SGSN 

The mobile core network can consist of a PDSN or GGSN/SGSN that acts as a gateway to the external packet 

data network. 

Table 1: RAN Components for Different Mobile Technologies 

MOBILE TECHNOLOGY 

GENERATION 

Generation 

TYPE OF 

TECHNOLOGY 

RAN 

COMPONENTS 

2G GSM BTS 

BSC 

MSC 

2.5G GPRS BTS 

SGSN 

GGSN 

BSC + PCU 

3G EVDO BTS 

RNC 

PDSN 

UTRAN 

NodeB 

RNC 

MSC 

4G LTE eNodeB 

SGW (Serving 

Gateway) 

MME (Mobility 

Management 

Entity) 

PDN Gateway 

WiMAX 

BS 

ASN GW 

CSN GW 

EXAMPLE OF ROLE 

• Communication between air interface and BSC 

• Controls multiple BS 

• Handles voice calls and SMS 

• Communication between air interface and BSC 

• Mobility management, data delivery to and 

from mobile user devices 

• Gateway to external data network 

• Controls multiple BS and processes data 

packets 

• Communication between air interface and RNC 

• Call processing and handoffs, 

communication with PDSN 

• Gateway to external network 

• Performs functions similar to BTS 

• Performs functions similar to BSC 

• Handles voice calls and SMS 

• Performs functions similar to BTS and radio 

resource management 

• Routing and forwarding of user data, mobility 

anchoring 

• Tracking idle user devices, handoff 

management 

• Gateway to external data network 

• DHCP, QoS policy enforcement, traffic 

classification 

• Layer 2 traffic aggregation point ASN 

• Connectivity to the Internet, external public 

or private networks 



What is a Mobile Backhaul 

In a nutshell, the backhaul can be considered to be the portion of the network that connects the BS (and air 

interface) to the BSCs and mobile core network. The backhaul can consist of a group of cell sites that are aggregated 

at a series of hub sites. (A cell site or cell tower consists of antennas, transmitting and receiving equipment mounted 

on a tower.) Figure 4 gives a high-level representation of the mobile backhaul. The cell site may either consist of a 

single BS that is connected to the aggregation device or a collection of BSs that are aggregated. 

Mobile Backhaul 

BS 

BSC 

Figure 4: Overview of a generic mobile backhaul 

The generic model for the newer backhaul networks consists of a cell, hub sites, or both connected to aggregation 

devices that in turn can either belong or be connected to a Metro network. Figure 5 shows the different 

subcomponents of the mobile backhaul network. The most commonly proposed metro network for 3G/4G 

technologies is an Ethernet-based services network. This network should be capable of providing multiaccess to 

different Layer 2 technologies such as FR/ATM/TDM and IP. 

Mobile Backhaul 

Cell Site Devices 

Hub/Aggregation 

Site Devices 

Metro Network 

Figure 5: Subcomponents of mobile 

backhaul network 

Another perspective of the mobile backhaul could lead to following 

classification of functionality: 

• Multiaccess gateway—This can consist of devices that can support 

TDM/ATM or Ethernet connectivity at the cell/hub sites. 

• Transport—The data from the different cell sites is carried over 

pseudowires that support circuit emulation. 

• Timing Synchronization—Clocking for the TDM data needs to be 

synchronized across the network. 

• Aggregation—An aggregation device performs aggregation of all the 

incoming connections before they reach the mobile core. 

The functionality and requirements of a mobile backhaul network are 

discussed in later sections. 

What are the Available Types of Backhaul 

The connectivity type offered by the backhaul network is influenced by the technology used in the RAN and factors 

such as geographical location of the cell site, bandwidth requirements, and local regulations. For instance, remote 

cell sites that cannot be connected via physical links instead use a microwave backhaul to connect to the BSC 

and mobile core network. The amount of available frequency spectrum and spectral efficiency of the air interface 

influence the bandwidth requirements of a cell site. Hence, the backhaul network can consist of either one or a 

combination of different physical media and transport mechanisms. Selecting between the different options available 

depends upon the type of radio technology, applications that are expected to be used, and transport mechanism. 

Table 2 lists the different technologies and the corresponding base station support. 

Table 2: Mobile Technologies and Base Station Support 

Generation Technology Base Station 

Interface 

Base Station 

Support 

Backhaul Network 

Support 

2/2.5G GPRS/TDMA/CDMA Abis Channelized TDM PDH/SDH 

3G (Rel99) UMTS Iub ATM ATM 

3G/4G 

EVDO, UMTS (Rel5), 

WiMAX , LTE 

Iub/Abis Ethernet/IP IP/MPLS/Ethernet 



2/2.5G technologies were designed for voice services, which are ideal for that purpose, but not efficient for data and 

video services. As of now, 8 to 12 T1s service a cell site (BTS). The requirement for T1s is directly proportional to the 

cost. Added to that, scalability is an issue due to the lack of support for reuse of bandwidth and bundling of links. 

RANs belonging to the 3G technology family aim to solve this problem by using either ATM or IP between the BTS and 

BSC instead of TDM. This approach—combined with other enhancements on the air interface and between RNCs— 

provides better scalability since it allows bandwidth reuse. 

ATM is used in case of a UMTS Rel99-based 3G network while EVDO, UMTS (3GPP Rel5) and WiMAX use IP. LTE uses 

completely IP-based RAN architecture. When using ATM (3GPP Rel99), T1/E1 or T3/E3/OC3 links can be used for low 

and high population density areas, respectively. AAL5 and AAL2 PDUs are carried at Layer 2. Figure 6 shows an ATM 

backhaul network. 

AAL5 

AAL2 

ATM-IMA 

lub 

ATM Backhaul 

lub 

BSC 

Figure 6: ATM backhaul 

3GPP Rel5 uses IP as the transport bearer. The IP packets, in cases of higher density cell sites, are carried over 

Ethernet—and MLPPP links are used for lower density sites. (MLPPP is used with T1/E1 links.) Figure 7 shows an 

IP/Ethernet-based backhaul. 

IP/UDP over Ethernet 

lub 

Ethernet 

Backhaul 

lub 

BSC 

Flat IP Network Architectures 

Figure 7: IP/Ethernet backhaul 

The move to using IP in the backhaul is driven by the requirements imposed by 3G/4G technologies. The term flat 

IP architecture can be applied to a network where all the nodes can reach each other via IP connectivity. A flat IP 

architecture can be applied to a network where the radio and routing functionality is pushed to the edge of the 

network. The end-to-end connectivity is achieved through a packet-based core network. Technologies such as LTE 

are based on a flat IP architecture. 

Note: The term “Packet core” is used in conjunction with technologies such as EVDO and GPRS. In this case, a 

tunnel needs to be created to carry and process native IP packets. In contrast, an IP core refers to an Internet-based 

model that can support native IP. 

One of the main advantages of using IP-based networks is the capability to transport different traffic types over 

a common IP-/MPLS-based infrastructure in addition to providing QoS guarantees and security requirements. 

For example, circuit- based voice, and 2G- or 3G-based voice and data can all be carried over a common IP/MPLS 

network. The main objectives driving the usage of IP-based architecture are the following: 

• Requirement for lower latency (serialization of data on a TDM network adds to latency delay.) 

• Requirement for lower cost 

• Reducing the total volume of equipment that is used (This objective can be achieved when equipment has 

integrated capability of BTS, RNC, Mobile core, or all three.) 



Requirements from an IP Backhaul Network 

As expected, transport forms the crux of the RAN—it needs to be able to scale in terms of capacity and demands of 

higher bandwidth, be reliable and efficient. Hence, the selection of the most suitable type of backhaul network needs 

to be made with the understanding of the end-to-end requirements of the mobile network. 

A solution that combines IP in the RAN with Carrier Ethernet in the metro aggregation network has the advantage 

of being cost effective, easy to use and manage; supporting various services; and maintaining performance 

requirements. The IP/Carrier Ethernet solution offers reliability, HA, and CoS in the backhaul space. Carrier Ethernet 

has the advantage of being a tried and tested carrier-class technology that is reliable. It is flexible enough to provide 

underlying infrastructure to higher level services and applications. Carrier Ethernet can thus be leveraged to 

bring the IP and MPLS capabilities available on the core side to the backhaul network. Figure 8 shows the different 

services that can be transported over Carrier Ethernet. 

Carrier Ethernet 

IP Routing 

MPLS 

PWE 

L2/L3 VPN 

Figure 8: Services to be transported over Carrier Ethernet 

Figure 9 shows the key components that need to be transported over an IP-based RAN. All the devices in the RAN need 

to be manageable either through in-band or out-of-band management. Network timing synchronization is required 

when transporting technologies such as TDM over the IP network. RAN signaling messages need to be carried with 

proper encapsulation applied to the IP packets. QoS needs to be applied on the user (and RAN signaling) traffic. 

IP Transport over RAN 

Management 

Timing 

Synchronization 

Signaling 

User Generated 

Traffic 

Figure 9: Components of IP RAN transport 

Detailed requirements of an IP-/Ethernet-based mobile backhaul network are discussed in detail in the following sections. 

CoS 

Services are offered on the mobile network end to end between the user mobile devices. The mobile network, 

including the backhaul, serves as a bearer infrastructure for these services. Each service can be assigned to a 

particular traffic class and prioritized. In general, services signaling, user plane transport, and management 

traffic can be classified, prioritized, and scheduled using CoS. The mobile backhaul network needs to be capable 

of recognizing the CoS settings, doing any re-marking of packets if required, prioritizing between the packets, and 

applying CoS rules to the different traffic streams. Figure 10 shows the different types of CoS marking that can be 

done to differentiate between the traffic streams. 

IP RAN QoS Scenarios 

VLAN Service 

based (Layer 2) 

802.1p (Layer 2) DSCP (IP) EXP (MPLS) 

Figure 10: IP RAN QoS 



Backhaul networks need to be able to support the main traffic types—voice, video, network signaling/management, 

and best-effort data. The network should also be able to provide low packet loss. For this, CoS definitions need to 

be determined and maintained at each node in the backhaul such that the different traffic types can be prioritized 

through the network accordingly. 

The mobile technology standards define classes that can be used for the traffic classification but do not mandate 

how many of these classes are actually to be used. This number will depend on the network implementation and 

traffic profile. In general, differentiation between the traffic types is done by marking and prioritizing packets as 

“High,” “Medium,” or “Low.” The prioritization depends on the traffic type. 

There are four classes of traffic defined in case of the 3GPP-based technologies such as UMTS. These traffic classes 

can be shared between the wired and mobile traffic streams and are all prioritized based on their CoS marking. The 

different classes may either be spilt or aggregated at each node in the backhaul or core network. Each hop in the 

network can classify the packet based on 802.1p or DSCP or EXP classifiers. Additional levels of granularity can be 

added by prioritizing different traffic streams within a traffic class. The level of granularity will depend on the type 

of CoS guarantees, network spanning multiple domains, complexity of implementation, and the capability of the 

network interfaces and equipment. 

Table 3 provides a summary of the different traffic classes defined in the mobile backhaul solution test network and 

the corresponding DSCP/802.1p/EXP marking. 

Table 3: CoS Mapping 

CoS TRAFFIC 

CLASS 

Background 

Interactive 

Streaming 

CoS SERVICE CLASS 

Low (non-real-time 

traffic) 

Low (non-real-time 

traffic) 

Medium (real-time 

traffic) 

DIFFSERV TRAFFIC 

CLASS (WIRED-/ 

PACKET-SWITCHED 

NETWORK) 

Best Effort (BE) 

Assured Forwarding 

(AF12) 

Assured Forwarding 

(AF11) 

Conversational High (real-time traffic) Expedited Forwarding 

(EF) 

TYPICAL APPLICATIONS 

Wired/Mobile IP data/email 

TCP-based services—HTTP/Telnet 

UDP/RTP—Streaming video 

Voice—VoIP/Video conferencing 

Bidirectional traffic such as VoIP and video conferencing that require low latency is assigned to the Conversational 

class. Unidirectional traffic such as streaming video (UDP/RTP streams) is classified into the Streaming class. 

The Interactive class can be used for applications that use TCP-based transactions such as HTTP and Telnet. The 

Background traffic class can contain a combination of both low-priority traffic from mobile or wired applications and 

background data from mobile applications. The traffic streams will carry different CoS markings based on their origins. 

Transport and Services 

MPLS and pseudowires are used as the transport mechanism in both the IP/Ethernet and hybrid types of mobile 

backhaul networks. The pseudowires themselves can be transported over the MPLS LSPs. The advantage of using 

MPLS for transporting pseudowires is that it is agnostic to the transport media and more scalable than pure Layer 2 

networks. While Layer 2 networks are cheaper and easier to implement, on the other hand, they are neither scalable 

nor easily manageable. For example, one major issue with pure Layer 2 networks is the scalability with respect 

to the number of MAC addresses that can be learned and stored. Also, Layer 2 communication is based on the 

forwarding table information that cannot be entirely controlled under circumstances such as duplicate MAC address 

learning that results in loops and flooding. A Layer 3 network can solve such an issue since the routing information is 

obtained from the control plane, thus making it more deterministic. 

Layer 3 networks offer reliability, convergence of services (2G/3G traffic), QoS, OAM, inherent security (when using 

VPNs), and synchronization. MPLS (and pseudowires) can support transport of multiple technologies such as ATM, 

TDM, and Ethernet over the same physical links. MPLS protection schemes ensure faster convergence and failure 

detection times 



Implementing MPLS in conjunction with VPN services in the metro provides mobile network carriers with new 

revenue opportunities. The VPN services could be either Layer 2 (L2VPN/VPLS) or Layer 3 (L3VPN/MVPN) based. The 

traffic belonging to different VPNs can be transported over pseudowire (and thus over MPLS LSPs). Figure 11 shows 

two nodes, PE1 and PE2, which are a part of the Metro network. The provider edge (PE) routers are configured to 

offer two VPN services (VPN-A and VPN-B). 

Traffic belonging to each of these VPNs is carried over a separate set of pseudowires. There can be several such sets 

of pseudowires carried within an MPLS LSP tunnel. 

The connectivity offered by the MPLS LSPs to the VPN service can either be point-to-point, point-to-multipoint, or 

multipoint-to-multipoint. Based on the MEF definitions, the services offered would be either E-Line/Ethernet Virtual 

Private Line; ELAN/Ethernet Virtual Private LAN, or E-Tree. Typically, E-Line connectivity delivers unicast traffic 

while ELAN can be used either for unicast or multicast traffic. Mapping connectivity to services results in typically 

L2/L3VPNs using E-line connectivity while VPLS/MVPN use the ELAN or E-Tree connectivity based on the topology 

and requirements. 

The CoS requirements of the traffic streams being transported across the MPLS LSP can be achieved using the 

EXP classifiers. Granular prioritization of streams belonging to different VPN services can also be done using a 

combination of behavior aggregate (BA) and multifield (MF) classifiers. 

PE-1 

VPN-A 

VPN-B 

MPLS Transport Tunnel 

PE-2 

Pseudowire 

Figure 11: MPLS-based transport 

Synchronization 

The continuity of a circuit clock is lost when the circuit is transported over an IP- or packet-based network. The 

fundamental difference between the two is that the circuit is synchronous while the IP network is asynchronous. 

Clock synchronization in a mobile backhaul network is an essential requirement for handoff support, voice quality, 

and low interference. Loss of timing synchronization can result in poor user experience, service disruptions, and 

wastage of frequency spectrum. Hence, timing in a mobile network can be distributed by one of the following 

methods to maintain the clock synchronization: 

• Using GPS or a legacy TDM network that is external to the IP-packet based network 

• Packet-based dedicated streams (IEEE1588- or NTP-based ) 

• Using Synchronous Ethernet over the physical layer 

• Adaptive clocking 

• DSL clocking 

The accuracy for timing delivered at the BS should be at least 50 ppb according to G.8261. 

Reliability and Fault Detection 

Fault detection mechanisms need to be in place at different levels of the network. For example, OAM can be used 

to detect failures at both Ethernet physical and link layers. Various MPLS protection schemes offer options such 

as make-before-break, and link- and node-level failure detection while protocols such as Bidirectional Forwarding 

Detection (BFD) enable better route convergence times. All these schemes enable faster detection, notification, and 

recovery from failures—thus increasing the reliability of the network. 

Network Configuration and Monitoring 

It is essential to use software tools that provide ease of network provisioning, management, and monitoring. The 

tools need to be able to maintain a database of the network node information in order to support configuration and 

monitoring. There may not be a single software tool that performs all the functions. In such a case, provisioning 

and monitoring can be split between a combination of different tools that are capable of providing essential chassis, 

node, routing, transport, and services related to configuration and statistics. 



Key Performance Indicators 

The following is a list of metrics that can be used to quantify the performance of the mobile backhaul network: 

• Per CoS traffic class. 

• Delay—Both Maximum and Average delay need to be measured. When performing TDM circuit emulation, delay, 

latency, and bandwidth efficiency impact each other significantly. 

• Jitter—Jitter plays a major role when doing TDM circuit emulation. The jitter introduced in the network will 

depend upon the jitter buffer. 

• Packet Loss—The rate of packet loss depends on the service that is supported and the underlying technology 

that is used. 

• Latency, Availability—The availability of the network has to compare to the requirements from a carrier. 

Legacy Backhaul Networks to Carrier Ethernet Migration Strategy 

This section describes two main scenarios when migrating from existing legacy networks to Carrier Ethernet. 

The type of scenario encountered mainly depends upon the extent of Ethernet support available on the BS. 

Irrespective of the level of Ethernet support, the migration path involves an intermediate step of a TDM/ATM/Packet 

hybrid backhaul. This is shown in Figure 12. The hybrid nature of the backhaul will depend upon either using an 

interworking function between the BS and BSC or running a dual TDM/Ethernet stack on the BS and BSC. 

Step 1 – TDM/ATM Legacy Backhaul 

Step 2 – Packet + ATM Hybrid Backhaul 

Step 3 – Packet Carrier Ethernet Backhaul 

Figure 12: Migrating to Carrier Ethernet 

The two main scenarios include: 

Scenario A: BS with no Ethernet Support 

In this scenario, both the BS and RAN NC in the mobile core do not have native Ethernet interface support and so 

cannot be directly connected to the Carrier Ethernet network. An interworking capability is required to be able to 

connect the TDM/ATM interfaces on the BS and NC to the Ethernet network. This scenario mainly pertains to the 

migration step where both legacy and Ethernet technologies need to be supported. 

• Option 1: Run IP/Carrier Ethernet in Parallel to TDM/ATM Backhaul 

In this scenario, low-priority high-bandwidth traffic can be offloaded from the legacy TDM/ATM network to the 

Carrier Ethernet IP network for scalability purposes. For example, the IP packet portion of the network can be 

used for data transport while 2G/3G voice traffic can be sent over the TDM portion of the backhaul. In this case, 

an interworking function between the legacy technology on the BS, such as TDM/ATM, and the Carrier Ethernet 

is required in the RAN. Figure 13 shows the BS and RAN NC connected to the Ethernet backhaul that includes 

an interworking functionality. 



Legacy Backhaul 

Network – TDM/ATM 

TDM/ATM 

TDM/ATM 

RAN BS 

Interworking – 

TDM/ATM - Ethernet 


Ethernet + IP/MPLS + 

Services 



RAN NC 

Mobile Core 

Network 

Figure 13: Co-existence of legacy technologies and Ethernet 

• Option 2: Emulate Native Service over Ethernet Using PWE 

This option requires the use of an interworking function but all the traffic between the BS and RAN NC is carried 

over the Carrier Ethernet network. (Here, Ethernet replaces the legacy technology.) The native TDM/ATM service 

can be carried over Ethernet using pseudowires for circuit emulation. Figure 14 shows a logical representation 

of the TDM/ATM traffic and Ethernet traffic being carried over the Ethernet backhaul. 

RAN BS 



TDM/ATM 

Ethernet 



Services 



TDM/ATM 

Ethernet 

RAN NC 


Network 

Figure 14: Legacy technologies carried over Ethernet network 

Scenario B: BS Supports Ethernet in Addition to Legacy Technology 

In this scenario, the BS and Ran NC are capable of supporting both Ethernet and the legacy technology. This leads to 

the options of either using the legacy network in conjunction with Ethernet or just the latter. 

• Option 3: Using both Packet/Ethernet and Legacy Technologies 

In this case, the RAN nodes are equipped with dual stacks to support TDM/ATM and packet traffic. The legacy 

technology is use alongside with the Ethernet network. Figure 15 illustrates this option. Low-priority highbandwidth 

traffic can be offloaded from the legacy TDM/ATM network to the Carrier Ethernet network for 

scalability purposes. 



Legacy Backhaul 

Network – TDM/ATM 

TDM/ATM 

TDM/ATM 

RAN BS 

Supports Legacy and 

Ethernet Technologies 

Ethernet 



Services 

Ethernet 


Network 

RAN NC 

Supports Legacy and 

Ethenet Technology 

• Option 4: Use Packet/Ethernet All Through Backhaul 

Figure 15: Dual support for Ethernet and legacy technology 

In this case, the BS and RAN NC can support Ethernet and are directly connected to the Carrier Ethernet 

network. All traffic is carried over the Ethernet network. Figure 16 shows this option. 

RAN BS 

Ethernet 



VPNs 

Ethernet 

RAN NC 


Network 

Solution Profile Overview 

Figure 16: All IP-/Ethernet-based backhaul 

As discussed in the earlier sections, it is imperative for mobile backhaul networks to be able to support the 

requirements for growing bandwidth, scalability, and classification or prioritization of services. IP-/Carrier Ethernetbased 

mobile networks support all these requirements and are hence ideally suited for use in mobile backhaul 

networks. Greenfield and upcoming 3G-/4G-based networks can use IP/Carrier Ethernet as the backhaul without 

any migration issues. However, existing 2/2.5 and some of the 3G networks need to migrate to IP/Carrier Ethernet 

while still continuing to support legacy technologies such as TDM/ATM. 

Juniper products can be used in either of these scenarios to provide a scalable, reliable backhaul network that 

is capable of offering VPN services, CoS, and MPLS-based transport. This document describes a main umbrella 

solution that can be used either for migration from legacy technologies or for newer deployments. It addresses the 

issue of migration, coexistence of legacy technologies such as TDM with an IP/Ethernet backhaul, and addresses 

new deployments. A subset of this umbrella solution that focuses on greenfield deployments based on newer 3G/4G 

technologies is also explained in detail. 

Reference Solution Architecture Types 

There are two aspects to the main mobile backhaul architecture discussed in this document. The first is a 

pseudowire-based aspect that can be used to implement a hybrid of a legacy and IP/Ethernet backhaul network. The 

second is a pure Carrier Ethernet-based aspect using IP/MPLS, L3VPN, and VPLS. Both these aspects are explained 

to illustrate the design and planning of migration strategies and greenfield deployments. 



Solution A: Umbrella Solution—Migration Strategy from 2/2.5 and 3G Legacy Networks + 

Greenfield 3G/4G Deployments 

This solution addresses the following requirements: 

• Migration and coexistence of TDM and Ethernet in the backhaul by using pseudowires and circuit emulation 

• Purely IP/Ethernet-based greenfield deployment that can deliver CoS, MPLS transport, and VPN services 

The first requirement is described under Solution A while details on the second can be found under Solution B. 

As listed in Table 5, the BX7000 can serve as a multi-access gateway in combination with the M Series routers (with 

circuit emulation PICs) in a hybrid environment. Such a hybrid scenario involves either migration or coexistence 

between IP/Ethernet and legacy technologies. In case of the pure IP/Ethernet scenarios, the BX7000, Juniper 

Networks J Series Services Routers, or EX Series can act as the cell or hub site devices. In all the possible scenarios, 

MX Series or M Series routers can be used in the Metro network that supports services such as VPNs, CoS, and IP/ 

MPLS. Juniper Networks Junos Scope can be used to manage the different network elements. 

Figure 17 shows a high-level overview of the mobile backhaul network solution. 

Junos Scope + IBM ITNM 

2G-GSM/CDMA 

TDM/ATM 

NetworksProvisioning/ 

Monitoring Fault Detection 

3G-UMTS/ 

EDGE CDMA/ 

EVDO 

BX Series 

J Series 

MX Series 

Ethernet Backhaul 

Network (L2/L3) 

Psuedowire over MPLS LSP 

M Series 

2G BSC 

EX Series 

IP/MPLS (with PWE) + 

VPN Services (L2VPN/L3VPN/ 

VPLS/NG-MVPN) + CoS 

3G RNC 

4G SAE GW 

4G-LTE/ 

WiMax 

IP/Ethernet 

IP/Ethernet 

ATM/TDM 

Figure 17: High-level overview of solution 

Figure 18 shows a simplified view of the backhaul solution with the BX7000 and EX Series acting as the cell site 

devices. The connections from these devices to the Metro network can be either Layer 2 or Layer 3 based. The 

BX7000 sets up a pseudowire across the Metro network to the M Series router (M120-PE) that has the circuit 

emulation PICs. CoS can be applied across all the nodes including the EX Series in the 3G/4G scenario. As mentioned 

earlier, the Metro network offers transport and services in all scenarios. 



CELL SITE DEVICES 

METRO NETWORK 

NG-MVPN/VPLS/L3VPN/L2VPN 

+ IP/MPLS + CoS 

BX Series-CSD 

L2/L3 Ethernet 

Pseudowire Circuit 

Emulation 

MX Series-1-PE 

2G-RAN NC 

3G 

M120 

4G 

EX Series-CSD 



3G RAN 

NC/4G GW 

Ethernet Links 

TDM/ATM Links 

Backup Links 

Figure 18: Simplified view of mobile backhaul network 

For better understanding, the umbrella solution has been described based on the migration, coexistence, and 

greenfield deployment aspects: 

• TDM-Pseudowire-Based Technology Migration 

Figure 19 shows a TDM-Ethernet-based backhaul network. Here, the BS and RAN NC are only capable of 

supporting TDM. A BX7000 is used as the cell/hub site device and has incoming T1/DS3/SDH links. It is 

connected to an IP/Ethernet-based metro network that can deliver CoS, VPN services, and MPLS transport. 

The TDM traffic is carried over the metro network using circuit emulation over pseudowires. As described 

earlier, pseudowires involve the use of MPLS LSPs across the metro network. The pseudowires terminate on an 

M Series router that acts as an aggregation device and consists of circuit emulation PICs (4-port channelized 

STM1/OC3 or 12-port T1/E1) that achieve the translation from Ethernet to TDM. The RAN NC (BSC) then receives 

the TDM stream from the M Series router. The Metro network can consist of a combination of M Series routers, 

MX Series routers, or both. 

IP/MPLS LSP 

RAN BS 

TDM 

Cell Hub 

Site Device 

Ethernet 

Ethernet Metro 

Network 

TDM 

RAN NC 


Network 

Pseudowire – TDM Emulation 

Aggregation 

Device 

Figure 19: TDM-pseudowire-based technology migration 



• Dual Stack-Based Technology Migration 

Figure 20 depicts the case where the BS and RAN NC have the dual stack capability and can thus support both 

TDM and Ethernet. The BX7000 is used as a multi-access gateway at the cell/hub site. The Metro Ethernet 

network provides connectivity between both the TDM and Ethernet interfaces of the BS and RAN NC. The TDM 

traffic is carried over the metro network using pseudowires and MPLS LSPs as described earlier. The Ethernet 

traffic also uses the IP/MPLS LSPs. 

Note: It is possible to reuse the same MPLS LSPs for both TDM and Ethernet traffic based on the design and 

implementation. 

The M Series router acts as the aggregation device for both types of connections. The circuit emulation PICs 

perform the Ethernet to TDM conversion function. The Metro network can consist of a combination of M Series 

routers, MX Series routers, or both. The dual stack that enables TDM and Ethernet support on the BX7000 device 

provides the required flexibility for it to be used either in a hybrid, pure IP/Ethernet or migration scenario. 

Pseudowire – TDM Emulation 

TDM 

Ethernet 

RAN BS 

Cell Hub 

Site Device 

Ethernet 

Metro Network 

IP/MPLS LSP 

TDM 

Ethernet 

RAN NC 

Aggregation 

Device 


Network 

Figure 20: TDM and Ethernet coexistence 

Solution B: 3G/4G Backhaul Greenfield Deployment Subset 

An all IP/Carrier Ethernet solution is depicted in Figure 21. The BS and RAN NC support native Ethernet connections 

into a Juniper Networks EX4200 Ethernet Switch that is used as a cell/hub site device. The Metro network is an all 

IP/Ethernet services-based one that can support MPLS LSPs for data transport, VPN services, CoS, and reliability 

requirements. The MX Series device is used as an aggregation device in this case. This solution is well-suited for 

either greenfield 3G or 4G deployments. 

RAN BS 

Ethernet 

Cell Hub 

Site Device 

Ethernet L2/L3 

Metro Network 

IP/MPLS + VPN 

Services CoS 

Ethernet 

RAN NC 


Network 

Figure 21: IP-/Ethernet-based mobile backhaul 

Table 4 lists the various VPN services and MPLS transport implementation options offered by Juniper. These services 

and transport options can be implemented in the Metro network. 



Table 4: Transport and Services Implementation Options 

FEATURE IMPLEMENTATION OPTION UNICAST AND MULTICAST SUPPORT 

MPLS LSP 

RSVP 

LDP 

PW setup 

BGP 

LDP 

NG-MVPN 

BGP 

VPLS 

BGP-VPLS 

LDP-VPLS 

Unicast (Multicast using point-to-point LSP) 

Layer 2 Multicast—point to multipoint 

H-VPLS BGP-LDP Interworking 

L3VPN BGP Unicast (Multicast using point-to-point LSP) 

L2VPN BGP Unicast (Multicast using point-to-point LSP) 

L2Circuits LDP Unicast 

Solution-Required Devices 

Table 5 shows the list of devices used in case of the migration and greenfield deployment scenarios. 

Table 5: List of Devices Used 

SCENARIO TYPE DEVICE USED FUNCTION TECHNOLOGIES SUPPORTED 

Migration strategy BX7000 Multi-access gateway TDM/ATM/Ethernet 

from 2/2.5 and 3G 

Pseudowires 

legacy networks 

CTP Series 

Cell/hub site gateway TDM/Ethernet 

device 

M Series routers 

Circuit emulation PICs 

(OC3/T1/E1) 

Aggregation devices Ethernet 

TDM/ATM 

Pseudowires 

MPLS LSP 

OAM 

M Series/MX Series 

routers 

IP/Ethernet metro 

network 

Ethernet 

Pseudowires 

MPLS LSP 

VPN Services 

OAM 

Coexistence of BX7000 Multiaccess gateway TDM/ATM/Ethernet 

legacy 2G/2.5G/3G 

Pseudowires 

and newer 3G/4G 

technologies M Series routers Aggregation devices Ethernet 

Circuit emulation PICs 

(OC3/T1/E1) 

TDM/ATM 

Pseudowires 

MPLS LSP 

OAM 


routers 


network 

Ethernet 

Pseudowires 

MPLS LSP 

VPN Services 

OAM 



Table 5: List of Devices Used (continued) 

SCENARIO TYPE DEVICE USED FUNCTION TECHNOLOGIES SUPPORTED 

3G/4G backhaul EX3200 

Cell site gateway device Ethernet 

greenfield 

EX4200 

Hub site gateway device 

deployment 

BX Series Multiaccess gateway Ethernet 

MPLS LSP 

J Series 

Cell/hub site gateway 

device 

Ethernet 

MPLS LSP 

VPN Services 

MX Series/M Series 

routers 

Aggregation devices Ethernet 

MPLS LSP 

VPN Services 

OAM 

MX Series/M Series 

routers 


network 

Ethernet 

MPLS LSP 

VPN Services 

OAM 

Design Considerations 

Certain Layer 2 or Layer 3 capabilities of the BS, RAN NC, or the backhaul equipment determine the design of the 

network. Some of these factors to consider when designing a mobile backhaul network include: 

VLAN Models 

The VLAN tagging function may not be available on BS in case of the IP/Ethernet solution. The backhaul network 

design can change depending on whether the BS can perform VLAN tagging. 

A location-based VLAN can be considered to be analogous to a Layer 2 ATM or Frame Relay circuit. Packets are 

tagged with the location-based VLAN information based on the site from where they originated. This location-based 

VLAN tag is present all through the backhaul network and packets are handed off into the mobile core with the tag 

information. 

A service VLAN tag identifies the service that is being provided on the particular VLAN. The backhaul network could 

be designed in such a way that each service is offered on a separate VLAN or all the services are bundled into a 

single pipe that uses one VLAN—that is, one VLAN for all services versus VLAN per service. The service tag may get 

popped at some point in the backhaul network and does not need to be preserved and sent to the mobile core. 

The traffic in the backhaul can thus be separated either based on services or location. There are two scenarios based 

on whether the frames from the cell tower are VLAN tagged: 

• Tagged Frames 

1. Location and Service tags (Q-in-Q)—The frames coming in from the cell tower are tagged with both location 

and service information. The location tag is stripped from the frames at the cell site device. The frames are 

then sent with only the service tags that are recognized all through the network into the core. 

2. Only Location-based tags—The frames coming in from the cell tower are only tagged with the location 

information. The service tags can be added at the cell site depending on the type of services available at 

the particular site. Location-based VLAN tags are usually necessary when using a combination of Carrier 

Ethernet and a legacy Layer 2 network. 

• Untagged Frames 

The BS is not capable of tagging the frames with the appropriate location or service information. The frames 

come in untagged into the cell site device. The appropriate location and service VLAN tags are added on the 

cell site device. The location VLAN tag information is determined based on the port that the untagged frames 

were received. 



CoS 

The following factors need to be considered when designing the CoS rules: 

• The traffic profile and requirement of the granular classification of the traffic streams within a forwarding class 

using of MF classifiers—that is, combination of BA and MF classifiers 

• Type of CoS marking—that is, DSCP versus 802.1p will depend on whether the incoming frames are VLAN tagged. 

• Assigning EXP classifiers to traffic based on the VPN routing instances 

MPLS LSPs 

There can be either a single LSP or multiple LSPs assigned to carry the traffic within the backhaul network. The 

same MPLS LSP can be used to carry different traffic streams originating and destined to the same VPN instance. 

The alternative is to use multiple LSPs—either one per VPN offering or one for each traffic type. 

Timing Synchronization 

As mentioned earlier, there are multiple ways of distributing the timing information across the mobile backhaul 

network— traditional TDM-based timing distribution, packet network-based timing distribution using Adaptive Clock 

Recovery, 1588v2, and Sync-E and NTPv3/v4. When applying CoS rules, packets carrying adaptive clock recovery 

timing information need to be classified into the high-priority, low-latency queue. Juniper Networks supports 

multiple timing synchronization options since a single timing solution does not fit all network types or requirements. 

1588v2 is a versatile fit for the IP/Ethernet-based mobile backhaul since it is topology agnostic and supports both 

frequency and phase. 

Failure Recovery and Reliability 

At the very least, two types of failures need to be considered when designing mobile backhaul networks—link 

failures and node failures. Juniper Networks products offer protection schemes against failures at both levels. The 

various failure detection and recovery options include: 

• OAM 

OAM can provide Carrier Ethernet failure detection at the physical and link levels. Hence it is possible to provide 

either link or connectivity fault management with this scheme. It also notifies higher layers of failures, thus 

enabling BFD and fast reroute to repair and provide better recovery times. 

• LSP Link and Node Protection 

Enabling MPLS LSP link protection allows the LSP to be rerouted to a different interface on the same affected 

node through a bypass LSP. 

The MPLS LSP node-link protection scheme allows the LSP to be rerouted through a bypass LSP that traverses 

a different node—that is, the node where the failure occurred is bypassed in favor of a different node. 

Another method of providing redundancy could be achieved by dual homing links. In such a case, the following 

options can be used: 

• Routing Metrics 

Metrics associated with routing protocol such as link cost can be used to manage active paths over which the 

traffic is received. Configuring the cumulative cost of say one path to be much lower than the other results in 

all data traffic and LSPs using the path of least cost. One of the issues with using cost to select the active path 

is that if there is a failure anywhere along the active path, the LSPs and traffic can get rerouted through an 

available least cost path, which might not be the preferred path. To avoid this, metrics need to be set at optimal 

values such that the network administrators can predict the path chosen after every single failure. 

• Dual Homing 

In case of VPLS, the routing instance supports the dual-homing feature. Enabling dual homing within the VPLS 

instance allows only one link to be active while the other link is in standby or passive mode. 

Note: Although Routing Trunk Group (RTG) can be used at the Layer 2 level, it is well-suited for enterprise 

environment rather than service provider networks. 



Solution-Type Profiles 

Solution A: Umbrella Solution 

This section provides the configuration snippets that support the 2G/2.5G legacy technology migration solution 

information that was discussed in the earlier sections. Figure 24 shows an example of a mobile backhaul network 

where the BX7000 acts as a multiaccess gateway device for legacy and Ethernet-based technologies. The 

connections from the BS to the BX7000 device could be either TDM/ATM or Ethernet depending on the type of mobile 

network. The BX7000 device has outgoing primary and backup Gigabit Ethernet connections to the Metro network. In 

case of TDM/ATM, it sets up pseudowires to perform circuit emulation across the Metro network. These pseudowires 

terminate on the M Series device that has a circuit emulation PIC. The PE and P nodes of the Metro network can 

be interconnected by either Gigabit Ethernet or 10G links. MPLS LSPs can be used as a means to transport all data 

within the Metro. VPN services such as Layer 2/Layer 3 VPNs can deliver unicast services while VPLS and NG-MVPN 

can be used for multicast services. 

Note: Please refer to Table 4 for unicast and multicast service options. 

Note: When using BGP-based L2VPNs in the Metro network, the BX7000 device can perform LDP-based pseudowire 

stitching. Here, LDP-based pseudowire is created from the BX7000 to the ingress PE router that is the entry point to 

the BGP L2VPN domain on the Metro network. The requisite MPLS to BGP L2VPN label translation is performed on 

this ingress PE. A converse action occurs on the egress PE router that is the exit point of the BGP L2VPN domain. If 

the aggregation device is a part of this domain, no additional step needs to occur. Figure 22 shows this scenario. 

IP/MPLS LSP 

RAN BS 

TDM 

Cell Hub 

Site Device 

LDP-based 

Pseudowire 

Ingress 

PE Router 

Ethernet 

Metro Network 

BGP – 

L2VPN/VPLS 

Egress 

PE Router + 

Aggregation 

Device 

TDM 

RAN NC 


Network 

Figure 22: Aggregation device internal to BGP domain 

Also, LDP-based pseudowire should be created from the egress PE router to the aggregation device as shown in 

Figure 23. 

RAN BS 

TDM 

Cell Hub 

Site Device 

LDP-based 

Pseudowire 

IP/MPLS LSP 

Ingress 

PE Router 

Ethernet 

Metro Network 

BGP – 

L2VPN/VPLS 

Egress 

PE Router 

LDP-based 

Pseudowire 

Aggregation 

Device 

TDM 

RAN NC 


Network 

Figure 23: Aggregation device external to BGP domain 

The BX7000 also signals static MPLS LSPs to the M Series aggregation router to transport all pseudowires. 

This option leverages the BGP L2 VPN mechanism to provide a solution for the issues previously explained. An LDPbased 

pseudowire is created from the MAG to the BGP L2 VPN ingress PE, which translates the MPLS outer label 

into a BGP L2 VPN label. The egress PE router then swaps the labels at the egress of the BGP L2 VPN domain. If it is 

not part of the BGP L2 VPN domain, the ASG also has an LDP based pseudowire to the egress PE. 



This scenario has the following benefits: 

• Scaling: it is not necessary to monitor a large number of pseudowires end to end within the network cloud— 

the BGP L2 VPN network provides the control plane and hides the underlying complexity. No provisioning of 

pseudowires is necessary within the network cloud. 

• Redundancy: The MAG may just have a “local” redundancy mechanism using a backup pseudowire to the 

ingress PE, 

• Failure detection: The mechanism to detect failure is not end to end but “local” to the ingress PE, matching RAN 

backhaul requirements for fast restoration of pseudowires. Detection and restoration within the network cloud 

is ensured using BGP L2 VPN standard mechanisms. Moreover, BGP L2 VPN dual-homing capabilities may be 

leveraged to ensure dynamic and transparent protection of the local segment. 


METRO NETWORK 

NG-MVPN/VPLS/L3VPN/L2VPN 

+ IP/MPLS + CoS 

2G 

BX Series-CSD 


Pseudowire Circuit 

Emulation 


2G-RAN NC 

3G 

M120-PE 

4G 

EX Series-CSD 


3G RAN NC/ 

4G GW 

Ethernet Links 

TDM/ATM Links 

Backup Links 

Figure 24: Example—BX7000 specific design 

Table 6 lists the configuration snippets of the legacy migration solution using BX7000 and M Series routers that was 

described in the previous sections. (Please refer to the simplified mobile backhaul view depicted in Figure 18 and 

Figure 24). 

The snippets show the sample configuration to set up E1 interfaces and pseudowires on the BX7000 and E1 

interfaces and LSPs on the M Series router. In this example, a 12 port-Channelized T1/E1 PIC provides the circuit 

emulation capability on the M Series router. 



Table 6: Code Snippet of BX7000 and M Series Solution 

CONFIGURATION SNIPPET 

BX7000—Cell Site Device 

EXPLANATION 

l2circuit p2 { 

Pseudowire set up between M Series router and BX7000 

admin-state enable; 

neighbor-address 31.1.1.1 { 

tunnel tnnl2; 

interface e1-0/0/1 { 

payload 256; 

jitter-buffer 5000; 

idle-pattern 10; 

dummy-pattern 255; 

lossy-state-entry 12; 

remote-vc-id 2; 

} 

} 

} 

} 

e1-0/0/1 { 

E1 interface connected to BS 

admin-state enable; 

encapsulation trans; 

framing unframed; 

clock-source ces; 

} 

M Series Router with Circuit Emulation PIC (Aggregation Device) 

mpls { 

MPLS LSP tunnel on the aggregation device that can 

transport the pseudowire from the BX7000 

label-switch-path tnnl2 { 

to-address 31.1.1.1; 

from-address 13.1.1.1; 

primary tnnl2 { 

priority 7 0; 

} 

} 

e1-1/2/0 { 

satop-options payload-size 256; 

clocking external; 

encapsulation satop; 

e1-options { 

framing unframed; 

} 

unit 0; 

} 

E1 interface configured for external clocking 



Solution B: Greenfield Deployment Subset 

The mobile backhaul subset solution discussed in this section uses a network that can deliver both Layer 2 and 

Layer 3 services. EX Series or J Series devices are used at the cell or hub site devices while the aggregation is done 

on an M Series or MX Series router that is a part of the Metro Ethernet network. This Metro network also consists 

of other MX Series and M Series routers. The BS is connected to the EX Series/J Series devices while the Metro 

network connects to the RAN NC and mobile core. 

Figure 25 shows a sample mobile backhaul network that can be used for greenfield deployments. Gigabit Ethernet 

connections serve as links between the simulated BS and the EX4200 line of cell site devices (EX Series-1, EX 

Series-2, and EX Series-3). EX-4 acts as a hub site device to EX Series-1 and EX Series-2. A Juniper Networks 

MX240 3D Universal Edge Router (MX Series-1-PE) that is a part of the Metro Ethernet network aggregates the 

connections from EX Series-4 and EX Series-3. Another MX240 (MX Series-2-PE) and a Juniper Networks M120 

Multiservice Edge Router (M120-PE) complete the Metro network. All the nodes within the Metro network are 

connected by 10 Gigabit Ethernet links. Redundant links are provided between the node pairs EX Series-4/EX 

Series-3 and MX Series-1-PE/MX Series-2-PE. 


METRO NETWORK 

VPLS/L3VPN + MPLS + CoS 

2G 

EX Series-1 


EX Series-4 

3G 

EX Series-2 

M120-PE 

RAN NC 

4G 

EX Series-3 


Layer 2 Link 

Layer 3 Link 

Coon Links 

Figure 25: Mobile backhaul test network 

Figure 26 shows a logical view of the same mobile backhaul network. When using a Q-in-Q VLAN model, the frames 

coming into the EX4200 devices are double tagged with the location and service tags. The cell site devices strip the 

location tag and maintained the service tag. In Figure 26, the frames received at the cell site devices contain location 

tags of 175, 180, and 33, respectively. The service tags 550, 600, and 650 are carried through the network into the 

core. The Multicast VLAN 1000 is used to deliver multicast streaming video to all the sites. 

Note: The multicast streaming video is distributed using point-to-point LSPs as opposed to using point-tomultipoint 

or multipoint-to-multipoint optimization and PIM/IP Multicast. 



CELL SITE 

DEVICES 

HUB SITE 

DEVICE 

AGGREGATION 

DEVICES 

Cell Site 

175 

EX3200 

VLAN 

550 

EX3200 

MX240 

METRO 

NETWORK 

MX240 

Cell Site 

180 

EX3200 

VLAN 

600 


Network 

VPLS + L3VPN 

RSVP BASED 

MPLS 

EX3200 

VLAN 

Cell Site 

650 

MX240 

33 VLAN550 

Multicast VLAN 

VLAN600 

VLAN650 

1000 

VLAN550 (backup) 



10G Links in Metro (Trunk) 

Figure 26: Logical view of mobile backhaul network 

Figure 27 illustrates the handling of the VLAN tags at the cell site. 

Tag1 – Site175 Tag2 – Service550 Tag2 – Service550 

Figure 27: VLAN tags at cell site 

Connections from Site175 and Site180 are Layer 2 Ethernet based while that from Site33 is Layer 3 IP based. As a 

result the Metro network offers Layer 2-based VPLS and Layer 3-based VPN services to these sites. VPN services 

in the Metro network introduce the concept of separate routing instances within the Metro network. This concept is 

based on the logical partitioning of the physical nodes in the Metro network between different services. The network 

implementation details are discussed in the following sections. 

Routing 

OSPF or ISIS can be used as the IGP to achieve network connectivity on all IP interfaces. In most cases, these 

interfaces belong to a single backbone area or level. BGP is required to support the VPLS and L3VPN signaling 

messages in the Metro network. Enabling BFD on both the IGP routing protocol and BGP results in better fault 

detection times. 

CoS 

The CoS scenarios change based on the type of connectivity (that is, Layer 2/3) and services offered. Figure 28 

shows the classifiers used in the Layer 2 portion of the network. 802.1p classifiers are used when applying CoS to 

tagged frames. The cell and hub site devices perform queuing, scheduling, and prioritization based on the 802.1p bit 

marking. When the frames need to be transported across the Metro network using MPLS LSPs, EXP classifiers are 

used. Hence, the 802.1p CoS values need to be rewritten into EXP classifiers and transported over the LSPs. 



The aggregation device does this in the VPLS instance on the Metro network. A rewrite back from EXP to 802.1p 

classifiers is done when handing the frames from the Metro in the RAN NC. The converse actions take place on 

frames destined to the cell site and BS. The CoS classifiers can be applied if necessary on each routing instance. 

If the frames received from the BS are untagged, the cell site device can rewrite the DSCP value of the incoming 

frames to 802.1.p. From there the frames would be rewritten with the EXP value in the Metro and back to DSCP when 

sending to the RAN NC. 

Typically BA classifiers are used to achieve the required CoS guarantees in a network. However, using a combination 

of BA and MF classifiers introduces an extra level of granularity. Traffic streams within a particular class can be 

prioritized—for example, prioritizing Web browsing over Telnet traffic within the Interactive queue. In cases where 

the BS does not mark the incoming packets, the cell site gateway needs to be able to identify the traffic streams, for 

example, based on port number or IP address and then perform the classification. 

Note: Default Cos classifiers need to be used to classify traffic in a VPLS instance. In addition to the BA classifiers, 

MF-based firewall filters can be applied to the CE-facing interfaces on the metro ring nodes to ensure that the 

packets are classified based on the default EXP into the appropriate queues. The same CoS rules are applied to all 

core-facing VPLS interfaces. 

802.1p to EXP Rewrite 

802.1p 802.1p 802.1p 

EXP 802.1p 

BS 

RAN NC 

802.1p 802.1p 802.1p EXP 802.1p 

Figure 28: Layer 2-based CoS 

Layer 3 VPN-based CoS involves the use of DSCP or IP precedence marking being rewritten to EXP classifiers at the 

aggregation device. Figure 29 shows the different classifiers used for the Layer 3-based traffic. 

IP Precedence to EXP Rewrite 

IP Precedence IP Precedence IP Precedence EXP IP Precedence 

BS 

RAN NC 

IP Precedence IP Precedence IP Precedence EXP IP Precedence 

Figure 29: Layer 3 VPN-based CoS 



Table 7 shows salient CoS configuration steps on the EX Series cell site and MX Series aggregation devices. 

Table 7: CoS Config Snippets on EX Series and MX Series Devices 


Cell Site Device - EX4200 

classifiers { 

ieee-802.1 DOTP-CLASSIFIER { 

forwarding-class CONVERSATIONAL { 

loss-priority low code-points ef; 

} 

forwarding-class INTERACTIVE { 

loss-priority low code-points 

af12; 

} 

forwarding-class STREAMING { 

loss-priority low code-points 

af11; 

} 

forwarding-class BACKGROUND { 

loss-priority high code-points 

be; 

} 

} 

} 

forwarding-classes { 

queue 0 BACKGROUND; 

queue 3 CONVERSATIONAL; 

queue 2 INTERACTIVE; 

queue 1 STREAMING; 

} 

rewrite-rules { 

ieee-802.1 DOTP-RW { 

forwarding-class CONVERSATIONAL { 

loss-priority low code-point ef; 

} 

forwarding-class INTERACTIVE { 

loss-priority low code-point 

af12; 

} 

forwarding-class STREAMING { 

loss-priority low code-point 

af11; 

} 

forwarding-class BACKGROUND { 

loss-priority high code-point be; 

} 

} 

} 

EXPLANATION 

Definition of 802.1p Classifiers to be applied on 

incoming tagged frames. 

There are four queues defined: 

CONVERSATIONAL (EF) - Voice 

INTERACTIVE – (AF12) – HTTP/Telnet 

STREAMING (AF11) – Streaming Video 

BACKGROUND (BE) – Email 

Forwarding classes are assigned to the 

respective queues. 

Defines the rules to be applied when a rewrite 

is required. 



Table 7: CoS Config Snippets on EX Series and MX Series Devices (continued) 


schedulers { 

CONVERSATIONAL-SCHED { 

transmit-rate remainder; 

buffer-size percent 80; 

priority strict-high; 

} 

INTERACTIVE-SCHED; 

STREAMING-SCHED { 

transmit-rate percent 20; 

} 

BACKGROUND-SCHED { 

transmit-rate remainder; 

priority low; 

} 

} 

MX Series Aggregation Device 

routing-instances { 

VPLS-AGG1 { 

classifiers { 

exp EXP-CLASSIFIER; 

} 

} 

} 

drop-profiles { 

BACKGROUND-DROP { 

interpolate { 

fill-level [ 20 40 60 80 ]; 

drop-probability [ 0 50 75 100 ]; 

} 

} 

CONVERSATIONAL-DROP { 

interpolate { 

fill-level [ 90 100 ]; 

drop-probability [ 0 100 ]; 

} 

} 

INTERACTIVE-DROP { 

interpolate { 

fill-level [ 35 55 75 95 100 ]; 

drop-probability [ 0 35 55 75 95 

]; 

} 

} 

STREAMING-DROP { 

interpolate { 

fill-level [ 5 25 50 75 ]; 

drop-probability [ 40 60 80 95 ]; 

} 

} 

} 

EXPLANATION 

Schedulers define the buffer size and prioritization. 

EXP classifiers applied to the VPLS routing instance. 

Handling of each queue based on a separate Random 

Early Detection (RED) drop-profile. Additional levels 

of granularity to distinguish between streams of a 

particular traffic queue can be added by defining 

different drop profiles for low, medium and high priority 

traffic. 



Table 7: CoS Config Snippets on EX Series and MX Series Devices (continued) 


firewall { 

family vpls { 

filter MF-CLASSIFIER { 

term VOICE { 

from { 

source-port 5060; 

} 

then { 

count VOICE-CNT; 

loss-priority low; 

forwarding-class 

CONVERSATIONAL; 

accept; 

} 

} 

term INTER-STREAM-TELNET { 

from { 


} 

then { 

count INTER-STREAM-CNT; 

loss-priority medium-low 


INTERACTIVE; 

accept; 

} 

} 

term INTER-STREAM-SQL { 

from { 


} 

then { 

count INTER-STREAM-CNT1; 

loss-priority medium-high 


INTERACTIVE; 

accept; 

} 

} 

EXPLANATION 

MF based firewall classifier is applied to the VPLS 

instance. 

Here the classifier looks for traffic from UDP port 

5060 (SIP packets) and classifies them into the 

CONVERSATIONAL class. 

Packets destined for UDP port 23 (Telnet) are assigned 

to the INTERACTIVE forwarding class and marked with a 

medium-low priority. 

Packets destined for UDP port 3306 (SQL) are assigned 

to the INTERACTIVE forwarding class but marked with a 

medium-high priority. 

} 

} 

} 



VPN Services 

The VPN services are offered in the Metro network that consists of Juniper Networks MX480 3D Universal Edge 

Router devices (MX Series-PE1 and MX Series-PE2 ) and an M120 (M120-PE3) shown in Figure 25. 10 Gigabit links 

connect all the three nodes. The metro network highlighted by this solution offers VPLS and L3VPN services. This 

illustrates the flexibility of service offerings possible when using a Carrier Ethernet- based mobile backhaul network. 

Both the services use BGP as the underlying mechanism for exchange of signaling information. The routing and MPLS 

information is contained in separate tables for each instance. Each of these services is discussed in the following 

section. 

• VPLS 

VPLS offers a Layer 2-based VPN service that can be used for either unicast or multicast purposes. When using 

multicast, IGMP snooping and point-to-multipoint LSPs provide optimization. Both unicast and multicast traffic 

can be carried using point-to-point LSPs across the VPLS network. This example highlights the latter scenario. 

Figure 30 depicts the VPLS-based logical view of the backhaul network used in the discussion. Please refer to 

Table 4 for other service implementation options. 

One BGP-based VPLS routing instance (VPLS-AGG1) is configured on the three nodes of the metro ring. The 

VPLS-AGG1 instance is associated with the Layer2 connections from the hub site EX4. This single routing 

instance can support connections from multiple VLANs (location- or service-based depending on the frames 

arriving tagged at the cell site). As shown in Figure 30, there are two separate VLANs, 550 and 600, which offer 

services to the sites 175 and 180, respectively. A third VLAN 1000, termed as a multicast VLAN, offers streaming 

video to both sites. The hub site device EX4 is dual- homed to the two MX Series PE routers. Dual homing is 

enabled within the VPLS instance to ensure that only one link is active at a given time. 

Point-to-point MPLS LSPs serve as the transport mechanism between all the PE routers in the metro network. 

EXP-based CoS classifiers are applied to the VPLS instance as discussed in the CoS section. In this scenario, 

multicast and point to multipoint do not offer much optimization and so the point-to-point LSPs are used to 

transport both unicast traffic and the multicast streaming video. 

Implementation Notes: 

• A tunnel PIC need not be identified on an MX Series router if point-to-multipoint/IGMP snooping and other 

multicast services are not enabled on the network. The “no-tunnel-services” command can be enabled instead. 

• VPLS only supports the use of default EXP values to classify any VPLS traffic. 

• In addition to the BA classifiers, MF-based firewall filters can be applied to the CE-facing interfaces on the 

metro ring nodes to ensure that the packets are classified based on the default EXP into the appropriate queues. 

The same CoS rules are applied to all core-facing VPLS interfaces. 




METRO NETWORK 

VPLS + MPLS + CoS 

STE 175-550 

EX Series-1 

VLANs 

550 


EX Series-4 

VLANs 

550 and 

600 

STE 180-600 

EX Series-2 

VLANs 

600 

M120-PE 

RAN NC 


1000 


Figure 30: VPLS view of mobile backhaul network 

Table 8: VPLS Code Snippet 


MX Series-PE2 - Aggregation Router 

VPLS-AGG1 { 

instance-type vpls; 

vlan-id all; 

interface xe-3/1/0.550; 



route-distinguisher 1:500; 

vrf-target target:900:500; 

protocols { 

vpls { 

site-range 15; 




no-tunnel-services; 

site 1 { 

site-identifier 1; 

multi-homing; 

site-preference backup; 




} 

} 

} 

} 

EXPLANATION 

Define instance type, interfaces routing instance 

information and allow all vlan-ids through the instance. 

Enable dual homing and specify the backup site. 



• L3VPN 

L3VPN offers a Layer 3-based VPN service that is typically used for unicast purposes. (When using multicast, 

PIM and point-to-multipoint LSPs can be used in an NG-MVPN instance.) Figure 31 shows the L3VPN view of 

the mobile backhaul network under discussion. 

One BGP-based L3VPN routing instance (L3VPN-AGG1) is configured on the three nodes of the metro ring. The 

L3VPN-AGG1 instance is associated with the Layer 3 IP connections from the cell site EX Series-1. This single 

routing instance can support connections from multiple VLANs (location- or service-based depending on the 

frames arriving tagged at the cell site). As shown in Figure 31, there is one VLAN 650 that offers services to the 

site 33 while VLAN 1000 offers streaming video to the sites. The cell site device EX Series-1 is dual homed to the 

two MX Series PE routers. The OSPF metrics are configured in such a way that the traffic is received only from 

one of the links. 

Point-to-point MPLS LSPs serve as the transport mechanism between all the PE routers in the metro network. 

EXP-based CoS classifiers are applied to the traffic belonging to the L3VPN instance as discussed in the CoS 

section. In this scenario, multicast and point to multipoint do not offer much optimization and so the point-topoint 

LSPs are used to transport both L3 unicast traffic and the multicast streaming video. 


METRO NETWORK 

L3VPN + MPLS + CoS 


VLAN650 

STE 33-650 

EX Series-1 

VLAN650 

M120-PE 

RAN NC 


1000 


Figure 31: L3VPN view of mobile backhaul network 



Table 9 provides a sample L3VPN configuration snippet. 

Table 9: L3VPN Code Snippet 


L3VPN-AGG1 { 

instance-type vrf; 

interface ge-0/1/0.600; 

route-distinguisher 900:600; 

vrf-import L3VPN-IMPORT; 

vrf-export L3VPN-EXPORT; 

vrf-target { 

target:900:600; 

import target:900:600; 

export target:900:600; 

} 

vrf-table-label; 

protocols { 

bgp { 

import L3VPN-IMPORT; 

export L3VPN-EXPORT; 

graceful-restart; 

group L3VPN { 

neighbor 11.1.1.9 { 

local-address 12.1.1.131; 

peer-as 500; 

local-as 500; 

} 

neighbor 12.1.1.3 { 


peer-as 500; 

local-as 500; 

} 

} 

} 

ospf { 

domain-id disable; 

domain-vpn-tag 0; 

export [ L3VPN-EXPORT export ]; 

import [ L3VPN-IMPORT export ]; 

area 0.0.0.0 { 

interface ge-0/1/0.600 { 

bfd-liveness-detection { 

minimum-interval 50; 

multiplier 3; 

} 

} 

} 

} 

} 

EXPLANATION 

Define instance type, interfaces routing instance 

information and allow appropriate import and export of 

routes between the PEs. 



• OAM 

Ethernet Link management OAM is configured to offer reliability and fault detection. The table below gives a 

sample configuration snippet. 

Table 10: OAM Configuration Snippet 


ethernet { 

link-fault-management { 

interface xe-3/1/0 { 

pdu-interval 100; 

link-discovery active; 

remote-loopback; 

} 




} 




} 

} 

} 

EXPLANATION 

Configure link fault management on interfaces. 

Table 11: BFD 


bgp { 

group MBHL { 

type internal; 


family inet { 

unicast; 

any; 

} 

peer-as 500; 

local-as 500; 

bfd-liveness-detection { 

minimum-interval 10; 

} 

EXPLANATION 

BFD enabled on BGP group. 

• MPLS Transport 

RSVP-based LSPs transport the data belonging to different services across the Metro network. Either link 

protection or fast reroute can be enabled on RSVP and MPLS to provide faster failure recovery. The table below 

gives a sample configuration of RSVP and MPLS. 



Table 12: MPLS Configuration Snippet 


label-switched-path MX480-L3-to-M120-L3 { 

from 15.1.1.1; 

to 17.1.1.1; 

fast-reroute; 

} 

fast-reroute optimize-timer 1; 

interface all { 

link-protection; 

} 

EXPLANATION 

MPLS LSP with fast reroute enabled. 

RSVP with fast reroute enabled. 

• Network Provisioning, Monitoring, and Diagnostics 

Junos Scope can be used to provision infrastructure such as interfaces, VPN services, CoS, MPLS LSP, and 

routing—and maintains a database of all this information. History of essential parameters such as Jitter, Delay, 

Packet loss, and Clock variation needs to be made available to the network operator. Bulk statistics and realtime 

performance monitoring (RPM) support provide an additional layer of network monitoring and performance 

measurement. Third-party software such as IBM ITNM can be used to monitor the status of the network and 

services. 

Table 12 shows a sample SNMP configuration snippet on the MX Series router that can send alarms, traps, and 

events to the network management system. 

Table 13: SNMP Configuration Snippet 


snmp { 

view mpls { 

oid mplsLspEntry.2 include; 

} 

view general { 

oid jnxOperatingTemp; 

oid .1.3.6.1.1.3; 

oid ip.12; 

} 

view jnxRedundancySwitchoverCount { 

oid jnxRedundancyEntry.8; 

} 

view jnxCosIfqTailDropPktRate { 

oid jnxCosIfqStatsEntry.12; 

} 

view jnxPowerSupplyFailure { 

oid 1.3.6.1.4.1.2636.4.1.1 include; 

} 

view jnxCmCfgChange { 

oid 1.3.6.1.4.1.2636.4.5.0.1; 

} 

view jnxCmRescueChange { 

oid 1.3.6.1.4.1.2636.4.5.0.2; 

} 

EXPLANATION 

Configure trap and event related information, 

specify community 



Table 13: SNMP Configuration Snippet (continued) 


(continued) 

EXPLANATION 

(continued) 

} 

community public; 

trap-options { 

source-address 172.28.113.131; 

} 

trap-group MBHL { 

categories { 

authentication; 

chassis; 

link; 

remote-operations; 

routing; 

startup; 

rmon-alarm; 

vrrp-events; 

configuration; 

} 

targets { 

172.28.113.48; 

} 

} 

routing-instance-access; 

rmon { 

event 1 { 

type snmptrap; 

} 

} 

Conclusion 

Juniper products offer mobile network operators a wide range of backhaul options. The comprehensive solutions 

based on the BX7000, EX4200, and M Series/MX Series routers address both the needs of green field/new 4G 

technology deployments or migration from legacy technologies such as TDM or ATM to IP-/Ethernet- and MPLSbased 

networks. 

Appendixes 

Examples of Deployment Scenarios 

J Series as an Access Device 

Figure 32 shows a J Series device used as the access gateway for a 4G pure IP/Ethernet scenario. The J Series 

device is capable of applying CoS, delivering VPN services and setting up MPLS LSPs. The LSPs from the J Series 

can either terminate on the ingress or egress PE router of the Metro network. Similarly, the J Series device can also 

participate in the VPN service based on the network design and requirements. 



IP/MPLS LSP 

RAN BS 

Ethernet 

J Series 

Cell/Hub Site Device 

CoS + MPLS + VPN 


Ingress PE Router + 


Ethernet 

Metro Network 

VPN + CoS 

+ MPLS 

M Series/ 

MX Series 

Egress PE 

Router 

Ethernet 

RAN NC 


Network 

Figure 32: J Series as an access device 

CTP Series as an Access Device 

Figure 33 shows Juniper Networks CTP Series Circuit to Packet Platforms used as an access device in a legacy TDM 

network. The CTP Series platform performs the requisite TDM to Ethernet conversion and vice versa. 

IP/MPLS LSP 

RAN BS 

TDM 

CTP Series 

Cell/Hub 

Site Device 

M Series/ 

MX Series 

Ingress 

PE Router 

Ethernet 

Metro Network 

VPN + CoS 

+ MPLS 

M Series/ 

MX Series Egress 

PE Router + 


Ethernet 

TDM 

RAN NC 


Network 

Figure 33: CTP Series as an access device 

About Juniper Networks 

Juniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud 

providers, Juniper Networks delivers the software, silicon and systems that transform the experience and economics 

of networking. The company serves customers and partners worldwide. Additional information can be found at 

www.juniper.net. 

Corporate and Sales Headquarters 

Juniper Networks, Inc. 

1194 North Mathilda Avenue 

Sunnyvale, CA 94089 USA 

Phone: 888.JUNIPER (888.586.4737) 

or 408.745.2000 

Fax: 408.745.2100 

www.juniper.net 

APAC Headquarters 

Juniper Networks (Hong Kong) 

26/F, Cityplaza One 

1111 King’s Road 

Taikoo Shing, Hong Kong 

Phone: 852.2332.3636 

Fax: 852.2574.7803 

EMEA Headquarters 

Juniper Networks Ireland 

Airside Business Park 

Swords, County Dublin, Ireland 

Phone: 35.31.8903.600 

EMEA Sales: 00800.4586.4737 

Fax: 35.31.8903.601 

To purchase Juniper Networks 

solutions, please contact your Juniper 

Networks representative at 1-866-298- 

6428 or authorized reseller. 

Copyright 2011 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos, 

NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. 

All other trademarks, service marks, registered marks, or registered service marks are the property of their respective 

owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves 

the right to change, modify, transfer, or otherwise revise this publication without notice. 

8030008-002-EN Jan 2011 

Printed on recycled paper 

38

Mobile Backhaul Reference Architecture - ICT Networks

Create successful ePaper yourself

Delete template?

Save as template?