Purchase the MEF-CECP Exam Today!
Home

Login/Register

Recent Members

Online Users

  • Daniel Bar-Lev
  • Hieu Hieu
  • Donamark Mirabel
  • Ayal Lior
  • Eng. Anuradha Udunuwara
5 user(s) and 869 guest(s) online | Show All
Today
Ayal Lior added a new wall post in the group, Operations, Administration & Maintenance 04:43 AM
Yesterday
Ravi Prakash Vaish added a new wall post in the group, Operations, Administration & Maintenance 04:10 PM
Francesco Fucelli and Richard Strike are now friends 02:33 PM
 
Follow us on Twitter
Carrier Ethernet Backhaul Services for Mobile Operators PDF Print E-mail
(13 votes, average: 4.15 out of 5)
Papers - Ethernet Academy Articles
Saturday, 06 December 2008 00:00

Carrier Ethernet Backhaul Services

for Mobile Operators

Written by Jonathan Olsson

Content Disclaimer

Abstract

This article focuses on how Carrier Ethernet connectivity services can be utilized by mobile operators to address the traffic demand. Packet based radio systems along with Carrier Ethernet can easily handle the convergence of existing services and support the scale required by the changing mobile landscape.

Introduction

Traditional mobile user behavior is evolving to embrace high speed mobile data services. Mobile users, used to flat rate subscriptions for voice and text services, are demanding the same for mobile broadband services. Mobile devices enhanced for e-mail, web browsing, streaming video, and other multimedia services are driving the demand for higher bandwidth from the mobile network. This introduces new challenges for the mobile operator, as traffic volumes steadily increase, burdening the existing mobile backhaul network.

During 2008 the number of mobile broadband (HSPA) subscribers exceeded 50 million, compared to the 11 million last year, as reported in a press release by GSMA [1]. An additional 4 million subscriptions per month are expected by the end of 2008. Mobile networks will be forced to grow to increase coverage for mobile broadband and to handle the traffic capacity to support the new subscriptions and user expectations.

Carrier Ethernet connectivity services from network operators and the advent of packet based mobile systems are predicted to provide mobile operators with scalable and cost efficient solutions to handle both the increasing number of mobile devices attached to their networks and the traffic volumes they generate.

This article focuses on how Carrier Ethernet connectivity services can be utilized by mobile operators to address the traffic demand. Packet based radio systems along with Carrier Ethernet can easily handle the convergence of existing services and support the scale required by the changing mobile landscape.

The article begins by providing an overview of current and next generation 3GPP mobile architectures. Next, a few key concept of the Metro Ethernet Forum (MEF) Carrier Ethernet services and reference points are described. Finally, the article concludes with a case example of a Carrier Ethernet enabled mobile backhaul network; detailing some considerations that should be made when designing the networking solutions.

Mobile Backhaul Architecture

The current Third Generation Partnership Project (3GPP) mobile systems, such as Global System for Mobile (GSM) and Wideband Code Division Multiple Access (WCDMA), have a similar mobile backhaul, also referred to as Radio Access Network (RAN), architecture with radio base stations (BTS in GSM and NodeB in WCDMA) and common control nodes (BSC and RNC respectively). In the architectural evolution currently developed in 3GPP, known as Long Term Evolution (LTE), the common control functions will be distributed to the radio base stations and core network nodes, effectively creating a mobile backhaul consisting of a single node type, i.e., the radio base station called eNodeB [2]. Refer to Figure 1.

For GSM and WCDMA, the terms RAN transport and RAN backhaul normally refer to the transport network between the control nodes (BSC, RNC) and the base stations. The RAN interfaces for GSM and WCDMA are Abis and Iub (see Figure 1), respectively, while the other interfaces are handled under core transport network. For LTE with its simpler architecture, the mobile backhaul network between base stations (eNodeB) and the access gateways (aGW) in the evolved packet core network is defined by the S1 interfaces, and the X2 interface between base stations.

The Abis, Iub, S1 and X2 interfaces include both control signalling and mobile traffic payload. Operations and management traffic to the base stations normally utilizes the same transmission as Abis, Iub and S1. The X2 interface is for handover purposes only and for that reason only connects base stations that are “radio neighbors”. X2 does not provide general connectivity between LTE base stations. As a result the volume of traffic over the X2 is very small.

The radio networks require either frequency or phase synchronization from an external source. If not supplied from a GPS receiver at the base station site, frequency synchronization may be obtained from an SDH/PDH transmission network when TDM or ATM transmission is used. For packet-based RANs, frequency synchronization may be transmitted from centrally located sources, e.g., at the BSC/RNC/SAE GW sites, over the mobile backhaul network as time stamp messages by means of NTP, IEEE 1588 or other packet-based methods. Synchronous Ethernet is another method to delivery frequency synchronization by making the Ethernet physical layer synchronous.

Phase or time of day synchronization may be required by other mobile technologies, such as WCDMA and LTE using Time Division Duplex (TDD). GPS is traditionally used for these synchronization requirements. Other methods for delivering phase and time of day in packet networks are currently being standardized.

Carrier Ethernet Overview

The Metro Ethernet Forum (MEF) has led the industry in propagating Carrier Ethernet and has identified five key attributes that distinguishes Carrier Ethernet from traditional LAN based Ethernet, these are: standardized services, scalability, service manageability, quality of service and reliability. This section explores how the MEF User Network Interface, Services, and Ethernet Service Operations, Administration, and Maintenance (OAM) enables these attributes and illustrates their value in the context of Carrier Ethernet services for mobile backhaul.

The MEF defines several demarcation points identifying the boundary between administrative domains. The key demarcation point from the perspective of the Ethernet service subscriber (the mobile operator in this case) is where the Ethernet service is delivered from the Metro Ethernet Network (MEN) to the mobile operator’s network; this is called the User Network Interface (UNI). The UNI is a physical demarcation point between the responsibility of the service provider and the responsibility of the mobile operator.

A UNI is formed of two functional blocks that separate the functions performed by the mobile operator, called UNI-C, and the functions performed by the MEN service provider, called UNI-N. The UNI-C is managed by the subscriber and has capabilities suited to the UNI type employed. Typical functions that are configured on the UNI-C include: tagging frames with VLAN IDs, classifying and marking frames with CoS indicators, configuration of Ethernet OAM entities and traffic management. Three UNI types are identified by the MEF, whereof two have been standardized: UNI Type 1 [6] and UNI Type 2 [8].

A standardized interface plays an important role when mobile operators purchase Ethernet services and attach their network to another administrative domain. The UNI clearly specifies the expected behavior of the mobile operator’s and service provider’s network equipment and where the responsibility of administrative domains begins and ends.

Ethernet Virtual Connections (EVC) represents transport relationships between two or more UNIs. Each EVC has an associated set of attributes that defines the behavior of the Ethernet service. [5]

There are three categories of EVCs: point-to-point (E-Line), multipoint-to-multipoint (E-LAN), and rooted-multipoint (E-Tree). E-Line services are similar to traditional TDM leased line circuits and provide connectivity between two UNIs. An E-LAN service is used for connecting multiple UNIs in a LAN-like fashion. The E-Tree service restricts the communication between UNIs offered by E-LAN services. E-Tree UNIs are categorized as either roots or leaves, with the basic connectivity principle that roots can send and receive frames from other roots and all leaves, whereas leaves are limited to sending and receiving frames from roots. [4]

These services may be combined to create a variety of connectivity options between sites and configured to meet the specific network performance and behavior requirements for a particular application. Service attributes that can be configured include: performance objectives, VLAN ID to EVC mapping, and bandwidth profiles. Refer to MEF 10.1 for a complete list of the service attributes [5].

An EVC can specify the frame delivery performance using the four attributes Frame Delay, Frame Delay Variation, Frame Loss Ratio, and Availability. If specified, the performance attributes are defined for a particular class of service identifier (CoS ID) on the EVC, where a CoS ID could be a Priority Code Point (PCP) value, the DiffServ Code Point (DSCP) value, a Layer 2 Control Protocol, or the EVC.

Bandwidth profiles are used to control the amount of traffic in a service to achieve overall performance objectives. They can also be used as a form of protection from traffic flooding. For example, assuming the customer equipment is attached to a multipoint service and has limited traffic processing capabilities. A bandwidth profile defined to control the traffic to acceptable levels that can be processed by the customer’s equipment, e.g. a radio base station, would protect it from potential traffic flooding.

Ingress and egress bandwidth profiles may be configured using the parameters Committed Information Rate (CIR), Excess Information Rate (EIR), Committed Burst Size (CBR), and Excess Burst Size (EBS), with the option to enable color marking. Color marking is used to determine the frames compliance to the defined profile.

MEF Ethernet services provide service providers and mobile operators with a framework that offers a broad array of flexible services that can be tailored to meet the requirements for various mobile technologies and mobile network deployments. The dynamic properties of Ethernet services can be ideally leveraged during the migration process between mobile technologies and to adjust to current network requirements.

IEEE 802.1ag, ITU-T Y.1731, and the MEF specify a framework for Ethernet Service OAM providing a means for subscribers and service providers to execute fault management and performance monitoring on services and networks. Fault management is used to detect continuity loss, isolate faults, validate configurations, verify connectivity, and fault notifications. Performance monitoring enables performance attributes to be monitored in order to verify that a service is delivered according to the negotiated service contract. [7][9][10]

Ethernet Service OAM provides the ability to establish hierarchical maintenance domains. This means that it is possible to have nested maintenance domains, called Maintenance Associations (MA) containing the two basic OAM entities MA End Point (MEP) and MA Intermediate Point (MIP). MEPs reside at the peripheral of the MA and MIPs are located between MEPs on intermediate network nodes. IEEE 802.1ag and ITU-T Y.1731 specify that eight Maintenance Domain (MD) levels are allowed.

Three fundamental OAM messages are defined by IEEE 802.1ag that ITU-T extends for performance monitoring. These are, Continuity Check Message (CCM), Linktrace, and Loopback [9].

CCM messages are exchanged by MEPs periodically at a preconfigured interval and are primarily used to identify connectivity faults between MEPs. CCM can also detect configuration errors, such as OAM messages leaking from higher MD levels.

Linktrace is similar to IP traceroute. Functioning on the Ethernet layer, it is used to trace the path between two MEPs. They are initiated to localize faults or identify the path taken by a service.

Loopback can be initiated on demand to check the connectivity between MEPs. It is the Ethernet equivalent to IP ping.

The toolset offered by Ethernet Service OAM allows mobile operators to monitor and verify their Ethernet services. This will prove to be an important capability during the transition to packet based mobile backhaul networks and valuable in order to ease management as mobile networks grow in size and capacity.

Applying Carrier Ethernet - A Case Study

As the RAN becomes packet based, Carrier Ethernet services provide an alternative from traditional TDM-based leased circuits to more cost efficient and scalable Ethernet connectivity services.

This section explores some of the challenges involved in a mobile backhaul network with multiple IP based mobile technologies. In the example below, we have a network where base stations of different technologies are co-located on RAN sites. The example assumes that base stations recover frequency synchronization using a packet-based method, such as NTP, that is distributed from a centralized time server. Because NTP is used, intermediary transport elements do not need to actively participate in the synchronization distribution and forward NTP messages as normal Ethernet frames.

Figure 2 - Example of a Mobile Network with WCDMA and LTE

Some of the challenges the mobile operator faces in this example are how to separate traffic, how to allocate bandwidth, and how to monitor the services.

Traffic separation

Several options are available to the mobile operator for separating the mobile traffic in the backhaul: a single EVC for all connectivity, an EVC per radio base station site, or an EVC per radio technology. This example defines an EVC per RAN interface for WCDMA (Iub) and LTE (S1 and X2). These are illustrated in Figure 2 as Iub_EVC for WCDMA and S1_EVC and X2_EVC for LTE.

A RAN interface may be sub-partitioned such that different traffic types, such as control signaling, voice, and data are identified by different VLAN IDs. Mapping at the UNIs to the EVC is based on these preconfigured VLAN IDs. To simplify configuration, VLAN IDs are preserved in the service, e.g. the same VLAN ID at the network controller UNI is used to identify a service as at any of the peer UNIs. The simpler approach adopted in this example is to have all traffic on the same VLAN ID.

Rooted-multipoint services, or Ethernet Virtual Private Trees (EVP-Tree), are configured for the S1 and Iub RAN interfaces, S1_EVC and Iub_EVC respectively. A rooted-multipoint service appropriately mirrors the relationship between the radio base stations and network controllers for these interfaces. S1 and Iub do not require traffic to go between radio base stations; instead traffic flows only between the network controllers and the radio base stations.

The X2 interface is realized using a multipoint-to-multipoint service, Ethernet Virtual Private LAN (EVP-LAN). A single EVP-LAN service provides connectivity between all of the radio base station sites with LTE eNodeBs. A site may choose to filter incoming traffic to sources that are known radio neighbors to restrict the amount of traffic entering the base station site.

Traffic classification at the radio and controller sites will assign appropriate service classes to frames to indicate the desired delivery performance. Choosing the number of classes and how to map traffic to a particular class is a key aspect of the design.

For example, when a mobile device connects to the LTE wireless network, the radio system negotiates resources on the air interface for the application and establishes a service bearer. A bearer is configured with a QoS Class Identifier (QCI) by the radio system that is used to classify the traffic on the bearer [3]. All QCI values are internal to the radio system and are not visible to the transport layer. Instead, QCI values need to be mapped to appropriate transport class of service identifiers, such as Ethernet PCP or DSCP.

The mapping of QCI values to transport QoS values is performed by the radio site (e.g., the base station, the cell site gateway, or the switch site) and should be configurable depending on which QoS marking method is applied and the number of service classes available. This allows additional traffic separation within an EVC. The fewer service classes that are available, the more QCI values will be bundled in each service class, giving less service differentiation in case of network congestion. Ethernet has the possibility to distinguish eight PCP values; however four classes are generally agreed to be optimal. Table 1 illustrates an example of how traffic classes are mapped to four classes of service.

Name of Class of Service

Example of traffic types mapped a Class of Service

Very High

Synchronization

High

Conversational,
Signaling and Control

Medium

Streaming

Low

Interactive and
Background

Table 1 - Example of traffic class mapping

Certain critical traffic, such as synchronization and control, have high availability requirements which means they will be associated to a transport class with low discard priority to ensure that these frames are delivered even during periods of high congestion. Whereas interactive and best effort data traffic are assigned a low CoS as they are able to tolerate periods of packet loss and high delay.

Each service class will be associated with expected performance characteristics such as Frame Delay (FD), Frame Delay Variation (FDV), and Frame Loss Ratio (FLR) that are designed to meet the requirements of the traffic types associated with the CoS. For example, if a CoS is associated with both video streaming and VoIP, then the performance requirements will be configured such that it fulfills the requirements of the most stringent traffic type – VoIP in this example. If a packet based time distribution method is used to distribute time, then it is generally recommended to map this traffic to the class with the lowest FLR and FDV.

Bandwidth Allocation

Bandwidth profiles are defined to regulate the amount of traffic sent over a UNI, EVC, and/or CoS ID. They can be used to protect nodes from being flooded by traffic from other nodes. An egress bandwidth profile (for traffic coming from the MEN to the customer equipment) may be configured to limit the traffic arriving at a user node. For example, if a base station is not capable of processing traffic above a certain rate, then an egress bandwidth profile for the UNI and service at the base station may be configured such that packets are dropped if the amount of traffic exceeds a predefined threshold.

Bandwidth profiles are configured for each EVC in this scenario as illustrated in Figure 3. By using such configurations, there will be committed bandwidth for certain critical traffic such as control signaling and voice traffic, and shared resources for less critical traffic as Internet data and email.

The CIR and EIR configured will be different for each EVC. Since traffic from several base stations is aggregated at the network controller site UNI, it will have a bandwidth profile for each service (EVC) configured with a CIR that is approximately equal to the sum of all the UNI CIRs for that service. For example, the egress bandwidth profile for S1_EVC at the network controller UNI will configured to be equal to the sum of all the CIR for the leaf UNIs in the service. If the CIR is too low, there is a risk that frames are dropped by the UNI if all the leaf UNIs simultaneously send traffic at their maximum CIR.

EIR is configured to handle burst traffic, such as traffic generated by best-effort Internet applications. Traffic within EIR is marked as ‘out of profile’ and is not subject to the performance requirements in the service layer agreement.

Service Monitoring

EVC services can be monitored by configuring MAs between radio base station sites and network controller sites. In the example below, a MEP is configured at each UNI-C for each service, S1_EVC, X2_EVC, and Iub_EVC. The MAs are used to monitor a service end-to-end. One or more MIPs are configured in the Carrier Ethernet network providing monitoring points in the service provider’s domain. These can be used by the mobile operator to identify and localize faults to an administrative domain. This basic configuration allows the OAM entities controlled by the mobile operator to perform fault management and performance monitoring operations.

Detecting connectivity faults between sites is one of the primary functions for fault management. This is accomplished by enabling CCM at an appropriate transmit interval on each MA. A MEP detects a connectivity failure when CCM messages are not received within 2.5 times the transmit period. The CCM transmit period is configurable to give fast or slow connectivity failure detection time. Some protection mechanisms utilize alarms raised by CCM to trigger a protection failover action. A higher transmit interval would decrease the connectivity failure detection time and consequently the restoration time, at the expense of using more CCM bandwidth. Lower periods may be used if the detection time is not critical. Alternatively, the mobile operator could initiate loopback messages to perform on demand connectivity checks.

Carrier Ethernet Backhaul - Overview of the location of ethernet OAM entities

MIPs configured inside the transport network, such as at the UNI-N, at the same MD Level as the Mobile Operator MA enable the mobile operator to isolate faults to a particular domain; for example by using linktrace. In the case of a leased service, the mobile operator is interested to know whether a fault occurred in their own network domain or in the service provider’s domain. This is important when identifying who is accountable for a network failure.

Persistent performance monitoring of critical traffic types, such as synchronization and voice, enable the mobile operator to have a constant overview of the state of the service. This may be used as a preventive measure to identify service degradation and possibly predict problems before they affect end-users. The mobile operator has the option to initiate measurements on-demand to test a particular service and service class. Additional measurements or monitoring on a particular service class could be triggered by alarms from the radio system.

Conclusion

Mobile operators will be faced with new challenges and opportunities during the transition to packet based mobile networks that will grow in size and capacity. Mobile operators are also faced with a choice between several technologies to base next generation mobile network on. This article illustrates the properties of Carrier Ethernet that make it the right technology for mobile operators. Carrier Ethernet can simplify the transition from circuit-based to packet-based mobile networks. This is enabled by the capabilities offered by Carrier Ethernet highlighted above: providing standardized demarcation points and services, and the ability to monitor service performance and connectivity.

Furthermore, a standardized approach to mobile backhaul based on Carrier Ethernet creates a common plane of communication between mobile operators and service providers. With a common nomenclature and service framework, parties with different backgrounds can efficiently communicate together to successfully address the new challenges and opportunities ahead. These properties are what make Carrier Ethernet ready to face the challenges awaiting the deployment of packet based mobile backhaul networks.

References
  • “Global Mobile Broadband subscribers hit 50 million”, GSM World, August 2008
  • 3GPP TS 36.401 “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture description (Release 8)”, V8.3.0
  • 3GPP TS 23.107 “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, V8.3.0
  • MEF 6.1 “Metro Ethernet Services Definitions Phase 2”
  • MEF 10.1 “Ethernet Service Attributes Phase 2”
  • MEF 13 “UNI Type 1 Implementation Agreement”
  • MEF 17 “Service OAM Requirements & Framework – Phase 1”
  • MEF 20 “UNI Type 2 Implementation Agreement”
  • IEEE 802.1ag “Connectivity Fault Management”
  • ITU-T Y.1731, “OAM functions and mechanisms for Ethernet based networks”

About the Author

 

Written by:
Jonathan Olsson
 
Trackback(0)
Comments (2)add
...
written by Guest , November 05, 2009
Does NTP really support the frequency synchronization function?
I think it can only support time sync.
report abuse
vote down
vote up
Votes: +0
...
written by Antonis Karvelas , December 16, 2008
Hi Jonathan,

your paper is very interesting but it has no information about the pseudowires, a technology that will be needed at least at the 1st phase of moving to a packet network. IETF has made significant work for this technology and has RFCs for TDM and ATM pseudowires. MEF has published the MEF8 for emulation of PDH over PSN, but has nothing about ATM pseudowires.

What is your opinion about that?

report abuse
vote down
vote up
Votes: +1
You must be logged in to a comment. Please register if you do not have an account yet.

busy
Last Updated on Tuesday, 26 May 2009 20:23
 
MEF Accredited Training Providers