End-to-End QoS Performance Management Across LTE Networks

Li Li and Subin Shen Dept. of Software Engineering

Nanjing University of Posts & Telecommunications Nanjing, China

{lli, sbshen}@njupt.edu.cn

Abstract—Performance management (PM) is critical for supporting end-to-end QoS (Quality of Service) across long term evolution (LTE) network elements over heterogeneous networks. In order to effectively deliver QoS traffic from different applications, LTE can be delivered through implementation of logical Class of Service (CoS)/QoS controls in a variety of methods and with variety services. While LTE network domains (e.g., Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Backhaul transport network, and Evolved Packet Core (EPC) network) can have different QoS implementations that work within a given domain, these differences can cause problems when domains intersect. Therefore, the design strategy must specifically and logically fit to allow multiple offers on limited network resources. This paper presents a high level PM system architecture for monitoring and troubleshooting harmonization of CoS/QoS based on 802.1p/DSCP (Diffserv Code Point)/EXP (EXPerimental bits) mappings that optimize end-to-end network performances over multiple LTE network elements.

Keywords-LTE, CoS/QoS mapping, Performance Monitoring

I. INTRODUCTION The deployment of LTE imposes high demands on network

performance. The number of users will increase as a result of new high-speed services available. The traffic volume per subscriber increase rapidly as multiple services such as voice, video, and data may be carried on multiple network domains, each with its own traffic pattern and quality of service (QoS) requirements. Initially, the primary interests of network operators are to improve coverage and spectral efficiency of the Radio Access Network (RAN). Hence, QoS may not be needed at this time. The network is characterized by low traffic load (a likely case during the initial deployment phase) and mostly non-delay-critical data traffic. A legacy network can be used to provide voice service based on the circuit switched fall back capability. A network that offers best effort cannot provide capabilities to support different levels of QoS for different types of real-time applications such as voice, video streaming, interactive (e.g., instant messaging, games etc.), and bulk data transfer (e.g., ftp, P2P file downloads etc.). It is not economical to resolve this problem through capacity over-provisioning [1]. The benefits of LTE networks with QoS include priority handling, dedicated bandwidth, controlled latency, jitter, and improved loss characteristics. Guarantying QoS requirements for some delay-sensitive services at the network level is a

business imperative that exceeds customer expectations. The best QoS class can lead to more efficient resource utilization while maintaining performance for critical applications. This can provide substantial cost savings for network operators. The increasing popularity of 4G smart phones and the migration of 2G/3G applications to LTE will magnify and exacerbate the need for end-to-end QoS that satisfy different service needs.

From a network operation’s perspective, LTE equipments are deployed in a heterogeneous network environment. Such deployment may be managed by different service providers or a service provider may implement different network components for different technologies, or have different network stacks. From the finding of this research, heterogeneous networks consist of three network domains: RAN, backhaul, and core network (CN). In a heterogeneous network environment, QoS cannot be implemented on a single protocol layer, or implemented by a particular network component [2]. End-to-end QoS support requires QoS requests to traverse different protocol layers and different network portions. Therefore, to effectively deliver solutions with end-to-end CoS/QoS capabilities, all network elements including transport equipments must be taken into account. Failure to coordinate these efforts could lead to worst case scenarios where service degradations and/or outages may not be detected for hours or even days in the LTE networks.

LTE standards specify a bearer-level QoS model with a variety of CoS/QoS mechanisms [1]. However, LTE network elements alone cannot guarantee end-to-end QoS. During network congestion, a bottleneck might be occurred in a particular router or switch. However, the QoS control specified by LTE network elements cannot address these types of problems. LTE can specify that the EPC bearer tunnel header could contain a diffserv code point (DSCP) value [3]. However, when traffics enter transport networks, if the transport network cannot perceive the DSCP values that marked in packets, the QoS control will be lost in these networks. Therefore, it is important to enforce QoS control in transport networks such as the mobile backhaul (MBH) and the core network.

CoS and QoS mapping is one of the methods to implement this objective. The DSCP values will be mapped into service classes defined by different network components in LTE

This work is supported by Research and Innovation Project for College Graduates of Jiangsu Province in 2011(CXZZ11_0408).

networks. The mapping enables a universal understanding of the QoS requests in LTE traffic. The mapping between UMTS CoS and MPLS/DiffServ CoS has been studied [4]. This paper proposes a design strategy of CoS/QoS mapping in a harmonizing fashion. It presents a high-level PM system architecture that monitors network performance measurements of LTE mobility and transport elements. It addresses monitoring class type and bandwidth type of LTE interfaces.

The rest of the paper is organized as the follows: Section II describes the design strategy of CoS and QoS mapping. Section III describes the architecture of the performance management system. Section IV is the conclusion.

II. DESIGN STRATEGY OF COS AND QOS MAPPING CoS and QoS mapping involves two aspects: cross-layer

mapping and cross-domain mapping [2]. The network is composed of multiple layers, each with its role in QoS provisioning. The overall performance depends on the QoS achieved at each layer of the network. Cross-layer mapping occurs when the lower layer wants to perceive the QoS needs of the upper layer. The cross-domain mapping transfers QoS requests among network segments. CoS and QoS mapping makes full use of the QoS mechanisms in each layer of the protocol stack, and in each portion of the network. It will improve the network throughput and service availability.

The QoS mechanism specified by LTE addresses QoS control inside LTE equipment. Though it defines a QoS Class Identifier (QCI) to DSCP mapping function, it only works when all the network domains have the same DSCP values. Such consistency is difficult to achieve in a heterogeneous environment. For example, the VLAN may use the 802.1p bit as the QoS class identifier, and the experimental field (EXP) [5] is used in MPLS networks. QoS control in these transport networks is also very important for end-to-end QoS in LTE networks. Therefore, it is critical that DSCP to QoS classes are mapped in transport networks.

This section proposes a CoS and QoS mapping strategy in LTE networks. The high-level design strategy is as follows:

(1) LTE provides EPS bearer level QoS support. Each bearer is associated with a QCI and ARP (Allocation and Retention Priority).

(2) LTE network equipment including evolved NodeBs (eNodeBs), Mobile Management Entity (MME), serving gateway (SGW), packet data network gateway (PGW) will map QCI to DSCP before forwarding traffic towards transport network equipment. Each DSCP identifies a unique QCI and DSCP markings are written to the ToS field in the header of IP packets.

(3) Transport network equipment such as edge routers should apply the DSCP markings in the traffic to implement classification, prioritization, and schedule. Multiple DSCP values will be grouped to a service class in transport networks. Equipment in transport networks will only apply the DSCP value to map to a specific service class according to the mapping rules and will not write or rewrite the DSCP in the packets.

Table 1 shows an example of the CoS and QoS mapping design. This table describes the QoS mapping for all Mobility user plane applications traffic where each QCI identifies a specific mobility application type with unique RAN QoS requirement. The primary goal is to map each QCI to a unique DSCP. Multiple DSCPs are grouped to a Transport Class – transport QoS classes are chosen identical to what already is implemented in MPLS for VPN transport. A 4-class DSCP-based QoS classification and scheduling scheme is adopted for end-to-end transport.

In Table 1, the first column shows example services in LTE networks [6]. The first cell in this column named “Control” is not a type of application traffic. It represents all mobility signaling traffic such as S1-MME S1-U, etc. The last cell in this column named “OAM” represents operation, administration and maintenance traffic. LTE technology standards define QoS classes using QCIs. In this example, the second column shows that 9 QoS classes are supported by LTE equipment, with QCI values from 1 to 9. Priority, packet delay budget, and packet error loss rate are given in the table [6]. Bearers with QCI values from 1 to 4 are Guaranteed Bit Rate (GBR) bearers. For GBR bearers, resources are permanently allocated during bearer’s lifetime. A certain bit rate can be guaranteed. Bearers with QCI values from 5 to 9 are non-GBR bearers. No particular bit rate is guaranteed. With LTE equipment such as eNodeB, MME, SGW, PGW, each packet will be marked with a specific DSCP value when entering the transport network. Each QCI maps to a unique DSCP. This mapping should be the same across the LTE equipment in the network so they can have a common understanding of treatment required by the packet.

In the DSCP column, Class Selector (CS) is used to designate IP precedence traffic types. The third column shows the Per-Hop Behaviors (PHB) type assigned to each QCI, and the corresponding DSCP value is given in parenthesis. For example, CS7 and CS6 are assigned to control and signaling traffic. The Expedited Forwarding (EF) PHB is assigned to real-time traffic such as voice, which is sensitive to delay and jitter. The Assured Forwarding (AF) PHB is assigned to non-real time services such as buffered streaming.

In the MBH network, there might be different transport technologies such as SDH, ATM, IP/MPLS/Ethernet. Current trend uses IP/Carrier Ethernet, which offers reliability and CoS [7]. Carrier Ethernet is used as the transport mechanism in the backhaul network in this example. The 802.1p bit in the VLAN tag is used to identify the priority. It is a 3-bit field, and is capable to provide 8 classes with 0 the lowest priority and 7 the highest. Six 802.1p bit values are used in this example. In Table 1, columns 3 and 4 show the mapping between DSCP and 802.1p bit where multiple DSCPs aggregate into a service class in the backhaul network. MPLS is used as the transport mechanism in the core network in this example. Differentiation between the traffic types is done by marking the EXP field. The EXP field can be used to support traffic classification by MPLS. It ranges from 0 to 7 with 0 the lowest priority and 7 the highest. Values from 3 to 6 in the EXP filed are used in this example.

The CoS Model column in Table 1 shows the four service classes from COS1 to COS4. COS1 reserves bandwidth for all control traffic. This class typically enjoys higher scheduling priority over other classes. Real-time traffic which requires low latency and low jitter can be classified into COS2. Usually, strict priority queue is applied to COS2. In order to avoid starvation of other classes during heavy congestion, the total amount of resources allocated to COS2 is capped – unable to burst and take away bandwidth from other classes. Unused bandwidth in COS2 is available to COS3 and COS4 for use. COS3 class is for low latency traffic. Low Latency of this class is not achieved by hardware support but through careful engineering of the allocated bandwidth and preventing queue

depth growth. If this class experiences congestion due to customer applications transmitting more than the allotted bandwidth, neither low-latency nor jitter will be controlled. By default, this class has an ingress policer and output shaping enabled, making it behave as close to COS2 as possible with the hardware support present on the delivery platforms. COS4 provides queuing for all traffic that does not match the above. It is expected that this class will handle the bulk of the traffic, but will be under allocated resources so that the applications in COS3 can be given better performance than the applications in COS4. The queue that supports this class is processes as a FIFO queue.

TABLE I. AN EXEMPLARY COS AND QOS MAPPING TABLE

Example Service Service IP Carrier

Ethernet MPLS CoS Model Bandwidth

Priority Packet delay budge (ms)

Packet error loss rate QCI DSCP 802.1p bit EXP

(Control) - - - - CS7(56) 6 6 COS1 10%

IMS signalling 1 100 10-6 5 CS6(48) 6 6 COS1

Conversational voice 2 100 10-2 1 EF(46) 5 5 COS2

50% Real time gaming 3 50 10-3 3 CS5(40) 5 5 COS2 Conversational video (live streaming) 4 150 10-3 2 AF42(36) 4 5 COS2

Non-conversational video (buffered streaming) 5 300 10-6 4 AF41(34) 4 5 COS2

Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

6 300 10-6 6 AF31(26) 3 4 COS3

35% Voice, Video (Live Streaming), Interactive Gaming 7 100 10-6 7 AF22(20) 3 4 COS3

Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

8 300 10-3 8 AF21(18) 3 4 COS3

`9 300 10-6 9 CS0(0) 2 3 COS4 5%

(OAM) - - - - AF12(12) 1 3 COS4

III. PERFORMANCE MANAGEMENT SYSTEM Performance management is an important part in network

management system. It includes the functions for performance measurements of network services. Depending on the source, the performance management can be defined in different ways. In 3GPP, the purpose of performance management is to collect data, which can be used to verify the physical and logical configuration of the network and to locate potential problems as early as possible [8].

Fig. 1 shows the architecture of the performance management system. The performance management system includes the following logical modules: (1) QoS Diagnose Engine (2) Data Collection Module (3) Databases including PM data repository, network

topology inventory, and QoS service policy (4) Service Optimization Module (5) Performance Business/Operations Impact Analysis

Module

(6) Web service interface Data Collection Modules will collect and record

performance data from network elements directly or via network element managers or probes. There are two logical data collection modules as shown in Fig. 1. LTE PM Data Collection Module collects performance data from LTE equipment. The IP Transport PM Data Collection Module collects performance data from transport equipment in IP networks. Data collected by these two modules is stored in PM Data Repository. The Network Topology Inventory Database stores the topology view of all equipment within LTE networks. The QoS Service Policy Database stores QoS policies retrieved from equipment such as Home Subscriber Server (HSS), Policy Control and charging Rules Function (PCRF).

The QoS Diagnostic Engine is the core of the PM system. To determine whether the network is impaired (the QoS cannot be guaranteed), data collected from PM data collection modules is correlated with network topology and service models. The result of correlations may indicate possible service

outage or service degradation - an alert in PM system. There are several types of alerts, such as service outage, network congestion, and so on. When an alert appears, the QoS Diagnose Engine will perform root-cause analysis to determine the cause of the problem.

If the root-cause is identified, the Performance Business/Operations Impact Analysis Module will determine

the next action step and will send instructions to QoS Optimization Module. The Service Optimization Module communicates with one or more network equipment to perform instructions and network administrators can access the PM system through the web service interface.

Figure 1. The Performance Management System Architecture

IV. CONCLUSIONS QoS is a critical issue in the deployment of LTE in today’s

telecoms networks. This paper presents a work in progress for developing a systematic approach for performing end-to-end QoS management in LTE networks. A novel PM system architecture is proposed to provide PM monitoring capabilities to detect if an impairment state has occurred based on PM measurements. Diagnositcs will be performed to determine whether the impairment state is due to tCoS and QoS mismatch. We also propose a design strategy of CoS and QoS mapping between different technologies, services and networks. The proposed PM architecture has the capability and flexibility to provide harmonization of CoS/QoS in deployed functional LTE networks. Our preliminary simulation study indicated [9] that lower Cos/QoS control setting has a service path over transport networks that always exceed maximum allocated usage. The detection and troubleshooting methods will be refined after results of measured LTE traffic characteristics from an initial deployment phase in controlled environments.

There are many challenges in the QoS policy and traffic handling mechanisms that supports LTE voice quality through IP Multimedia Subsystem (IMS). Future research plans of QoS management will include traffic conditioning (classification/mark/police) and dynamic policy based QoS through the use of service control infrastructure.

ACKNOWLEDGMENT The authors would like to thank Visiting Professor Charlie

Yang for his many helpful suggestions and comments.

REFERENCES [1] H. Ekstrom, “QoS control in the 3GPP evolved packet system,” IEEE

Communications Magazine, Vol. 47, Issue 2, pp. 76-83, Feb. 2009. [2] M. Marchese, “QoS over heterogeneous networks,” John Wiley & Sons

Ltd, 2007. [3] 3GPP, “General Packet Radio Service (GPRS); GPRS Tunnelling

Protocol (GTP) across the Gn and Gp interface,” 3GPP Technical Specification 29.060-810, June 2007.

[4] N. Kubinidze, M. O’Droma, I. Ganchev, “UMTS CoS support in MPLS-enabled IP backbones,” Proc. IEEE Tenth International Symposium on Consumer Electronics, St. Petersburg, Sep. 2006, pp. 1-5.

[5] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, et al., “Multi-Protocol Label Switching (MPLS) support of differentiated services,” RFC3270, IETF, May 2002.

[6] 3GPP, “Policy and charging control architecture”, 3GPP Technical Specification 23.203-920, September 2009.

[7] JUNIPER Networks, “Mobile backhaul reference architecture,” http://www.juniper.net/us/en/local/pdf/reference-architectures/8030008-en.pdf.

[8] 3GPP, “Telecommunication Management; Performance Management (PM); concept and requirements,” 3GPP Technical Specification 32.401-710, December 2007.

[9] L. Li, S. Shen, and C.Yang, “LTE CoS/QoS Harmonization Emulator”, to be published.