QoS Mechanism in EPS
"To adapt to the development of mobile communication technologies in the next 10-year timeframe and better meet an ever-increasing demand for data services, 3GPP has started the Long Term Evolution (LTE) and System Architecture Evolution (SAE) study projects. In view of the high-speed and bursty feature of future data services, the Evolved Packet System (EPS) makes quite a few enhancements and improvements in Quality of Service (QoS). By introducing such technologies as default bearer and aggregate resource scheduling, the EPS truly realizes the objective of ""Always Online"" for users, improves data rates and thus enhances user experience ultimately. Furthermore, an appropriate mapping between the EPS QoS Class Identifier (QCI) parameter and Universal Mobile Telecommunication System (UMTS) QoS parameter is designed regarding future interoperability scenario between UMTS Terrestrial Radio Access Network (UTRAN) and Evolved UTRAN (E-UTRAN)."
At present, one of the major challenges confronted by the mobile communication system is to deliver various types of multimedia services including data, voice, image and video with guaranteed Quality of Service (QoS)[1]. To guarantee QoS of various multimedia services, 3GPP clearly defines the end-to-end QoS architecture for Universal Mobile Telecommunication System (UMTS), and introduces several bearer and processing mechanisms to ensure UMTS can make full of its technical advantages to offer differentiated services for users.
To keep the competitive advantages of 3GPP systems in the next 10-year timeframe and better support the ever-increasing demand of users for data services, 3GPP launched the Long Term Evolution (LTE) and System Architecture Evolution (SAE) study projects[2] in 2004. The SAE project aims at optimizing and enhancing system performance in terms of network architecture, and the evolved network is called Evolved Packet System (EPS).
The QoS mechanism for EPS has made quite a few enhancements and improvements on the basis of UMTS.
Firstly, in view of the high-speed and bursty feature of future data services, the EPS introduces the concept of default bearer to effectively enhance user experience, reduce service setup latency and truly realize "Always Online". A default bearer with a constant data rate is established for a user when the user attaches to a network in order to ensure the user’s basic service requirements are met.
Secondly, the LTE uses shared channel mechanism to replace the dedicated channel in Radio Access Network (RAN), and adopts more flexible dynamic scheduling technology. Correspondingly, the EPS gives up complicated QoS negotiation mechanism for UMTS.
In addition, the EPS networks are required to enable various Radio Access Technologies (RATs), such as GSM, Wideband Code Division Multiple Access (WCDMA), LTE, CDMA2000 and Worldwide Interoperability for Microwave Access (WiMAX), to access a uniform packet-domain core network. Accordingly, the EPS must also support end-to-end QoS guarantee for users crossing different access networks, that is, User Equipment (UE) crossing access networks can fulfill mapping between the QoS parameters in order to ensure seamless user experience[3].
1 Evolution of QoS in 3GPP Mobile Networks
With the convergence of wireless communication technologies and IP technologies, the mobile communication networks have evolved from GSM network to General Packet Radio Service (GPRS) network and to present UMTS network capable of offering high-speed real-time data services. Following the evolution footsteps of mobile networks, the QoS mechanism also gradually comes to maturity in order to provide satisfying services for users based on various service features.
The GSM network is based on Circuit Switch (CS), and QoS is guaranteed once a circuit connection is established. Accordingly, QoS guarantee is quite simple and QoS parameters are basically not transferred in the GSM network.
The introduction of the IP bearer makes the GPRS network based Packet-Switched (PS) have far more complicated QoS guarantee mechanism than the GSM network. GPRS defines the following QoS parameters: latency level, reliability, maximum data traffic, priority, average data traffic, and retransmission request. These QoS parameters are required to be transferred between UE and such network-side entities as the Serving GPRS Support Node (SGSN) and Gateway GRRS Support Node (GGSN).
End-to-end QoS hierarchical architecture is introduced in R99. This architecture involves all Network Elements (NEs), including UE, radio access network entities and core network entities, and requires consistent QoS parameter processing on different interfaces. The end-to-end QoS hierarchical architecture introduced in UMTS is a great leap forward on the road of QoS evolution for mobile communication networks[4]. Furthermore, the core network IP bearer in R99 adopts the QoS technologies defined by IETF, including Integrated Services (IntServ)/Resource Reservation Protocol (RSVP), Multi-Protocol Label Switch (MPLS), Differentiated Services (DiffServ), Traffic Engineering (TE) and constraint-based routing. R99, for the first time, clearly defines four service types with different QoS: Conversational, Streaming, Interactive and Background.
To fulfill end-to-end QoS guarantee for IP Multimedia System (IMS) services, 3GPP proposed an IP-connection based Policy Decision Function (PDF) in R5/R6[5]. In the subsequent R7, the PDF and Flow Based Charging (FBC) specified in R6 were then combined, and the Policy and Charging Control (PCC) subsystem is added between the service control layer and the access/bearer layer to implement resource admission control function.
Considering the strong bursty feature of future data services, R8 introduces EPS dedicated and default bearers to effectively minimize bearer setup latency and truly realize "Always Online" for users[6]. In addition, the complicated QoS negotiation mechanism is eliminated in the bearing processes (bearer setup/modification/deletion) in the EPS network due to the channel sharing mechanism on LTE RAN.
The GSM network is based on Circuit Switch (CS), and QoS is guaranteed once a circuit connection is established. Accordingly, QoS guarantee is quite simple and QoS parameters are basically not transferred in the GSM network.
The introduction of the IP bearer makes the GPRS network based Packet-Switched (PS) have far more complicated QoS guarantee mechanism than the GSM network. GPRS defines the following QoS parameters: latency level, reliability, maximum data traffic, priority, average data traffic, and retransmission request. These QoS parameters are required to be transferred between UE and such network-side entities as the Serving GPRS Support Node (SGSN) and Gateway GRRS Support Node (GGSN).
End-to-end QoS hierarchical architecture is introduced in R99. This architecture involves all Network Elements (NEs), including UE, radio access network entities and core network entities, and requires consistent QoS parameter processing on different interfaces. The end-to-end QoS hierarchical architecture introduced in UMTS is a great leap forward on the road of QoS evolution for mobile communication networks[4]. Furthermore, the core network IP bearer in R99 adopts the QoS technologies defined by IETF, including Integrated Services (IntServ)/Resource Reservation Protocol (RSVP), Multi-Protocol Label Switch (MPLS), Differentiated Services (DiffServ), Traffic Engineering (TE) and constraint-based routing. R99, for the first time, clearly defines four service types with different QoS: Conversational, Streaming, Interactive and Background.
To fulfill end-to-end QoS guarantee for IP Multimedia System (IMS) services, 3GPP proposed an IP-connection based Policy Decision Function (PDF) in R5/R6[5]. In the subsequent R7, the PDF and Flow Based Charging (FBC) specified in R6 were then combined, and the Policy and Charging Control (PCC) subsystem is added between the service control layer and the access/bearer layer to implement resource admission control function.
Considering the strong bursty feature of future data services, R8 introduces EPS dedicated and default bearers to effectively minimize bearer setup latency and truly realize "Always Online" for users[6]. In addition, the complicated QoS negotiation mechanism is eliminated in the bearing processes (bearer setup/modification/deletion) in the EPS network due to the channel sharing mechanism on LTE RAN.
2 QoS Mechanism in EPS
A bearer is the basic level of QoS control granularity in R8 EPS, that is, all data traffic on the same bearer are granted identical QoS guarantee and various types of QoS guarantee are provided for different bearers. The bearer mechanism for EPS is different from that for UMTS in the following aspects:
(1) EPS bearers are used to replace Packet Data Protocol (PDP) contexts. An EPS bearer can be deemed as a logical circuit between UE and Packet Data Network Gateway (PDN-GW).
(2) A default bearer is set up according to the subscribed default QoS class in the process of a user’s initial attachment to the network, that is, each UE has at least one active bearer to shorten latency taking place during service initiation.
(3) The PDP context setup procedure initiated by terminal changes into the data bearer setup procedure triggered by the network side; the triggering conditions are various, including interaction between Policy and Charging Rules Function (PCRF) entities in IMS session, Mobility Management Entity (MME) indication during initial attachment, and UE request, so as to facilitate QoS and policy control of the services initiated by the network side in the future.
(4) EPS QoS mechanism is implemented based on the QCI parameter, which can be used to supersede over a dozen of parameters in UMTS, that is, the evolved NodeB (eNodeB) can deduce all parameter features from QCI.
2.1 EPS Bearer Service Architecture
EPS establishes and adopts the bearer service with clearly defined attributes and functions from the start to the end of a service to realize end-to-end QoS. Figure 1 shows the hierarchical structure of the EPS bearer service:
(1) EPS bearers are used to replace Packet Data Protocol (PDP) contexts. An EPS bearer can be deemed as a logical circuit between UE and Packet Data Network Gateway (PDN-GW).
(2) A default bearer is set up according to the subscribed default QoS class in the process of a user’s initial attachment to the network, that is, each UE has at least one active bearer to shorten latency taking place during service initiation.
(3) The PDP context setup procedure initiated by terminal changes into the data bearer setup procedure triggered by the network side; the triggering conditions are various, including interaction between Policy and Charging Rules Function (PCRF) entities in IMS session, Mobility Management Entity (MME) indication during initial attachment, and UE request, so as to facilitate QoS and policy control of the services initiated by the network side in the future.
(4) EPS QoS mechanism is implemented based on the QCI parameter, which can be used to supersede over a dozen of parameters in UMTS, that is, the evolved NodeB (eNodeB) can deduce all parameter features from QCI.
2.1 EPS Bearer Service Architecture
EPS establishes and adopts the bearer service with clearly defined attributes and functions from the start to the end of a service to realize end-to-end QoS. Figure 1 shows the hierarchical structure of the EPS bearer service:
The EPS bearer service architecture, as shown in Figure 1, has the similar hierarchical and region-based QoS framework with that in UMTS network, that is, the bearer service of each layer is offered through the bearer service of the layer immediately below it[7-8].
The end-to-end QoS service consists of the external bearer service and the EPS bearer service. The former is used to carry out services between the UMTS core network and external network nodes; and the latter is further subdivided into the EPS Radio Bearer (RB) service and the EPS Access Bearer (AB) service.
The EPS RB service implements the transport of EPS bearer service data units between eNodeB and UE according to requested QoS. Moreover, it supports IP header compression and user plane encryption functions, and provides mapping and multiplexing information for UEs.
EPS AB services implement the transport of EPS bearer service data units between MME and eNodeB based on requested QoS, and provide QoS guarantee for end-to-end IP traffic flow convergence[9].
The end-to-end QoS service consists of the external bearer service and the EPS bearer service. The former is used to carry out services between the UMTS core network and external network nodes; and the latter is further subdivided into the EPS Radio Bearer (RB) service and the EPS Access Bearer (AB) service.
The EPS RB service implements the transport of EPS bearer service data units between eNodeB and UE according to requested QoS. Moreover, it supports IP header compression and user plane encryption functions, and provides mapping and multiplexing information for UEs.
EPS AB services implement the transport of EPS bearer service data units between MME and eNodeB based on requested QoS, and provide QoS guarantee for end-to-end IP traffic flow convergence[9].
2.2 Concept of EPS Bearer
EPS defines a Packet Data Network (PDN) connection service as an IP connection between a UE and an external PDN of the Public Land Mobile Network (PLMN). The PDN connection service is able to support the transmission of one or more Service Data Flows (SDFs).
When the S5/S8 interface between a Serving Gateway (S-GW) and a PDN Gateway (PDN-GW) is based on GPRS Tunnel Protocols (GTP), the PDN connection service in EPS will be delivered by EPS bearers. When the S5/S8 interface is based on Proxy Mobile IP (PMIP), the PDN connection service will be delivered through both EPS bearers and the IP bearers between S-GW and PDN-GW. An EPS bearer solely identifies a set of one SDF, corresponding to a set of multiple SDFs with the same bearer level QoS. Each SDF corresponds to a packet filter in the Traffic Flow Template (TFT), which means every EPS bearer is associated with an Uplink TFT (UL-TFT) of UE and a Downlink TFT (DL-TFT) of PDN-GW.
In Figure 2, the GTP-based uplink EPS bearer is taken as an example to analyze its establishment process and principles. First, a UE binds an uplink SDF to form an EPS bearer through a UL-TFT. If the UL-TFT contains more than one uplink packet filters, multiple SDFs can multiplex the same EPS bearer.
When the S5/S8 interface between a Serving Gateway (S-GW) and a PDN Gateway (PDN-GW) is based on GPRS Tunnel Protocols (GTP), the PDN connection service in EPS will be delivered by EPS bearers. When the S5/S8 interface is based on Proxy Mobile IP (PMIP), the PDN connection service will be delivered through both EPS bearers and the IP bearers between S-GW and PDN-GW. An EPS bearer solely identifies a set of one SDF, corresponding to a set of multiple SDFs with the same bearer level QoS. Each SDF corresponds to a packet filter in the Traffic Flow Template (TFT), which means every EPS bearer is associated with an Uplink TFT (UL-TFT) of UE and a Downlink TFT (DL-TFT) of PDN-GW.
In Figure 2, the GTP-based uplink EPS bearer is taken as an example to analyze its establishment process and principles. First, a UE binds an uplink SDF to form an EPS bearer through a UL-TFT. If the UL-TFT contains more than one uplink packet filters, multiple SDFs can multiplex the same EPS bearer.
In EPS, a bearer always exists in the lifetime of the PDN connection service in order to provide UE with "Always Online" IP connections, and this bearer is called the default bearer. The QoS parameters of the default bearer are the subscription data obtained from the Home Subscriber Server (HSS), and their values can be modified through PCRF interactions or local configurations. Other EPS bearers in connection with the same PDN are called dedicated bearers, and their setup or modification can be triggered by the network side only. In addition, the bearer level QoS parameter values are always allocated by the packet core network. During the setup or modification of an EPS bearer, if the dedicated network resources related to the EPS bearer-associated Guaranteed Bit Rate (GBR) are allocated in a fixed mode, this EPS bearer is a GBR bearer; otherwise, it is a non-GBR bearer. Dedicated bearers can be either GBR or non-GBR bearers, but the default bearer must be a non-GBR bearer.
2.3 Bearer Level QoS Parameters
In EPS, the bearer level QoS parameters include Quality Class Identifier (QCI), Allocation and Retention Priority (ARP), GBR, Maximum Bit Rate (MBR) and Aggregated Maximum Bite Rate (AMBR). Where QCI and AMBR are newly added into EPS, while other parameters are inherited from UMTS.
Both GBR and non-GBR bearers contain QCI and ARP. As an order of magnitude, QCI refers to access point parameters used to control bearer level packet transfer, e.g. scheduling weights, admission thresholds, queue management thresholds, and link layer protocol configuration. ARP is used to determine whether to accept or reject the requests of establishing or modifying bearers in case of limited resources, and which bearer needs to be discarded in case of special resource limit (e.g., at handover). After a bearer is successfully established, ARP shall not have any impact on the bearer level packet transfer and processing.
Besides QCI and APR, every GBR bearer is also associated with GBR and MBR. GBR bearers are mainly used to carry voice, video and real-time gaming services through dedicated bearers or static scheduling. The GBR represents the bit rate that can be expected to be provided by a GBR bearer, while the MBR indicates the upper limit of GBR bearer.
Non-GBR bearers are mainly used to carry various data services. To improve bandwidth utilization, EPS introduces the concept of aggregated, and defines the AMBR. AMBR is an IP Connectivity Access Network (IP-CAN) session level QoS parameter of every PDN connection. Multiple EPS bearers for the same PDN connection share the same AMBR value. Each non-GBR bearer can potentially make use of the whole AMBR if other EPS bearers do not transfer any services. Therefore, an AMBR actually restricts the total bit rate of all the bearers sharing this AMBR.
AMBR can be classified into UE-AMBR and Access Point Name (APN)-AMBR based on different scenarios. UE-AMBR, saved in HSS as UE’s subscription data, is used to indicate the UE parameter attributes regarding different types of PDN access, and transfer from HSS to MME through the network registration procedure. When a UE establishes the first data connection to a PDN, the corresponding uplink and downlink UE-AMBRs can be established through the default bearer, and sent to the eNodeB entity for control and execution. APN-AMBR is an APN subscription parameter in HSS. It restricts the aggregated maximum bit rate that can be expected to be provide by all the PDN connections in the same APN. Where, downlink APN-AMBR is controlled by the PDN-GW, and uplink APN-AMBR is controlled by the UE or PDN-GW.
Both GBR and non-GBR bearers contain QCI and ARP. As an order of magnitude, QCI refers to access point parameters used to control bearer level packet transfer, e.g. scheduling weights, admission thresholds, queue management thresholds, and link layer protocol configuration. ARP is used to determine whether to accept or reject the requests of establishing or modifying bearers in case of limited resources, and which bearer needs to be discarded in case of special resource limit (e.g., at handover). After a bearer is successfully established, ARP shall not have any impact on the bearer level packet transfer and processing.
Besides QCI and APR, every GBR bearer is also associated with GBR and MBR. GBR bearers are mainly used to carry voice, video and real-time gaming services through dedicated bearers or static scheduling. The GBR represents the bit rate that can be expected to be provided by a GBR bearer, while the MBR indicates the upper limit of GBR bearer.
Non-GBR bearers are mainly used to carry various data services. To improve bandwidth utilization, EPS introduces the concept of aggregated, and defines the AMBR. AMBR is an IP Connectivity Access Network (IP-CAN) session level QoS parameter of every PDN connection. Multiple EPS bearers for the same PDN connection share the same AMBR value. Each non-GBR bearer can potentially make use of the whole AMBR if other EPS bearers do not transfer any services. Therefore, an AMBR actually restricts the total bit rate of all the bearers sharing this AMBR.
AMBR can be classified into UE-AMBR and Access Point Name (APN)-AMBR based on different scenarios. UE-AMBR, saved in HSS as UE’s subscription data, is used to indicate the UE parameter attributes regarding different types of PDN access, and transfer from HSS to MME through the network registration procedure. When a UE establishes the first data connection to a PDN, the corresponding uplink and downlink UE-AMBRs can be established through the default bearer, and sent to the eNodeB entity for control and execution. APN-AMBR is an APN subscription parameter in HSS. It restricts the aggregated maximum bit rate that can be expected to be provide by all the PDN connections in the same APN. Where, downlink APN-AMBR is controlled by the PDN-GW, and uplink APN-AMBR is controlled by the UE or PDN-GW.
2.4 Standardized QCI Characteristics
As one of the most important QoS parameters for EPS bearer, QCI represents the QoS features that EPS should offer for the SDF. Each SDF is associated with only one QCI. If more than one SDFs related to the same
IP-CAN session have identical QCI and ARP, they can be considered as one individual service set, which is called an SDF set. Table 1 lists standardized QCI characteristics defined in EPS. Operators may pre-configure all QCI Characteristics in eNodeB based on their actual conditions. These parameters determine the allocation of bearer resources on the RAN side.
The standardized QCI characteristics in Table 1 describe the packet transport characteristics of one SDF set:
(1) Resource Type
It determines whether the dedicated network resources related to
service/bearer GBR can be constantly allocated. The GBR SDF set requires dynamic PCC, while the non-GBR SDF set may only adopt static PCC.
(2) Priority
It is used to differentiate SDF connections of identical UE or those of different UE. Each QCI is associated with one priority; 1 refers to the highest priority.
(3) Packet Delay Budget (PDB)
PDB refers to possible latency of data packets transported between UE and PDN-GW. It is used to support configurations of time sequence and link layer functions. PDB is identical in both uplink and downlink for the same QCI.
(4) Packet Loss Rate (PLR)
PLR is defined as the rate of SDUs not successfully transported to the upper layer to the total number of SDUs processed by the link layer of the transmitting end. Therefore, PLR actually reflects the upper threshold of data packet loss rate in non-congested cases. PLR is also identical in both uplink and downlink for the same QCI.
(1) Resource Type
It determines whether the dedicated network resources related to
service/bearer GBR can be constantly allocated. The GBR SDF set requires dynamic PCC, while the non-GBR SDF set may only adopt static PCC.
(2) Priority
It is used to differentiate SDF connections of identical UE or those of different UE. Each QCI is associated with one priority; 1 refers to the highest priority.
(3) Packet Delay Budget (PDB)
PDB refers to possible latency of data packets transported between UE and PDN-GW. It is used to support configurations of time sequence and link layer functions. PDB is identical in both uplink and downlink for the same QCI.
(4) Packet Loss Rate (PLR)
PLR is defined as the rate of SDUs not successfully transported to the upper layer to the total number of SDUs processed by the link layer of the transmitting end. Therefore, PLR actually reflects the upper threshold of data packet loss rate in non-congested cases. PLR is also identical in both uplink and downlink for the same QCI.
3 Mapping Between EPS QCI and UMTS QoS Parameters
The evolution from UMTS to EPS is a step-by-step course. LTE networks may exist as hot spots during its primary commercialization, so LTE network coverage will be smaller than UMTS coverage. In this case, it is possible for UE to perform frequently interoperations, such as handover and cell reselection, between UMTS and EPS.
Since EPS and UMTS adopt different QoS mechanisms, most attention should be paid to the mapping relation between QCI parameters of EPS bearers and QoS parameters of Pre-R8 PDP contexts.
Since EPS and UMTS adopt different QoS mechanisms, most attention should be paid to the mapping relation between QCI parameters of EPS bearers and QoS parameters of Pre-R8 PDP contexts.
The parameter mapping between these two sets of QoS mechanism must comply with the following rules:
(1) One EPS bearer should have a one-to-one mapping relation with one PDP context.
(2) ARP, an EPS bearer parameter, should have a one-to-one mapping relation with ARP of
(1) One EPS bearer should have a one-to-one mapping relation with one PDP context.
(2) ARP, an EPS bearer parameter, should have a one-to-one mapping relation with ARP of
the Pre-R8 bearer. Different from UMTS, EPS allows two or more PDP contexts to have different ARP values.
(3) GBR and MBR of GBR-based EPS should have a one-to-one mapping relation with those of PDP contexts in Pre-R8 "conversational" or "streaming" class services.
(4) In the case of E-UTRAN-to-UTRAN handover, the latency in transport and SDU error rate in Pre-R8 system are respectively deduced from PDB and PLR in EPS, while in UTRAN-to-E-UTRAN handover, these two parameters in Pre-R8 system are ignored.
(4) In the case of E-UTRAN-to-UTRAN handover, the latency in transport and SDU error rate in Pre-R8 system are respectively deduced from PDB and PLR in EPS, while in UTRAN-to-E-UTRAN handover, these two parameters in Pre-R8 system are ignored.
Table 2 lists the one-to-one mapping relation between EPS QCIs and QoS parameters in Pre-R8 system including traffic class, traffic handling priority, signaling indication, and source
statistics descriptor.
Qualities of traffic
In packet-switched networks, quality of service is affected by various factors, which can be divided into “human” and “technical” factors. Human factors include: stability of service, availability of service, delays, user information. Technical factors include: reliability, scalability, effectiveness, maintainability, grade of service, etc.[5]
Many things can happen to packets as they travel from origin to destination, resulting in the following problems as seen from the point of view of the sender and receiver:
- Low throughput
- Due to varying load from disparate users sharing the same network resources, the bit rate (the maximum throughput) that can be provided to a certain data stream may be too low for realtime multimedia services if all data streams get the same scheduling priority.
- Dropped packets
- The routers might fail to deliver (drop) some packets if their data loads are corrupted, or the packets arrive when the router buffers are already full. The receiving application may ask for this information to be retransmitted, possibly causing severe delays in the overall transmission.
- Errors
- Sometimes packets are corrupted due to bit errors caused by noise and interference, especially in wireless communications and long copper wires. The receiver has to detect this and, just as if the packet was dropped, may ask for this information to be retransmitted.
- Latency
- It might take a long time for each packet to reach its destination, because it gets held up in long queues, or it takes a less direct route to avoid congestion. This is different from throughput, as the delay can build up over time, even if the throughput is almost normal. In some cases, excessive latency can render an application such as VoIP or online gaming unusable.
- Jitter
- Packets from the source will reach the destination with different delays. A packet's delay varies with its position in the queues of the routers along the path between source and destination and this position can vary unpredictably. This variation in delay is known as jitter and can seriously affect the quality of streaming audio and/or video.
- Out-of-order delivery
- When a collection of related packets is routed through a network, different packets may take different routes, each resulting in a different delay. The result is that the packets arrive in a different order than they were sent. This problem requires special additional protocols responsible for rearranging out-of-order packets to an isochronous state once they reach their destination. This is especially important for video and VoIP streams where quality is dramatically affected by both latency and lack of sequence.
The QoS concept as used in LTE networks is class-based, where each bearer type is assigned one QoS Class Identifier (QCI) by the network. The QCI is a scalar that is used within the access network (namely the eNodeB) as a reference to node specific parameters that control packet forwarding treatment, for example scheduling weight, admission thresholds and link-layer protocol configuration.
The QCI is also mapped to transport network layer parameters in the relevant Evolved Packet Core (EPC) core network nodes (for example, the PDN Gateway (P-GW), Mobility Management Entity (MME) and Policy and Charging Rules Function (PCRF)), by preconfigured QCI to Differentiated Services Code Point (DSCP) mapping.
According to 3GPP TS 23.203, 9 QCI values in Rel-8 (13 QCIs Rel-12, 15 QCIs Rel-14) are standardized and associated with QCI characteristics in terms of packet forwarding treatment that the bearer traffic receives edge-to-edge between the UE and the P-GW. Scheduling priority, resource type, packet delay budget and packet error loss rate are the set of characteristics defined by the 3GPP standard and they should be understood as guidelines for the pre-configuration of node specific parameters to ensure that applications/services mapped to a given QCI receive the same level of QoS in multi-vendor environments as well as in roaming scenarios. The QCI characteristics are not signalled on any interface.
Differentiated services or DiffServ is a computer networking architecture that specifies a simple and scalable mechanism for classifying and managing network traffic and providing quality of service (QoS) on modern IP networks. DiffServ can, for example, be used to provide low-latency to critical network traffic such as voice or streaming media while providing simple best-effort service to non-critical services such as web traffic or file transfers.
DiffServ uses a 6-bit differentiated services code point (DSCP) in the 8-bit differentiated services field (DS field) in the IP header for packet classification purposes. The DSCP field and ECN field replace the outdated IPv4 TOS field
Classification and marking
Network traffic entering a DiffServ domain is subjected to classification and conditioning. Traffic may be classified by many different parameters, such as source address, destination address or traffic type and assigned to a specific traffic class. Traffic classifiers may honor any DiffServ markings in received packets or may elect to ignore or override those markings. Because network operators want tight control over volumes and type of traffic in a given class, it is very rare that the network honors markings at the ingress to the DiffServ domain.[citation needed] Traffic in each class may be further conditioned by subjecting the traffic to rate limiters, traffic policers or shapers.[4]
The Per-Hop Behavior is determined by the DS field of the IP header. The DS field contains a 6-bit Differentiated Services Code Point (DSCP) value.[5] Explicit Congestion Notification (ECN) occupies the least-significant 2 bits of the IPv4 Type of Service field (TOS) and IPv6 Traffic Class field (TC).[6][7][8]
In theory, a network could have up to 64 (i.e. 26) different traffic classes using different DSCPs. The DiffServ RFCs recommend, but do not require, certain encodings. This gives a network operator great flexibility in defining traffic classes. In practice, however, most networks use the following commonly defined Per-Hop Behaviors:
- Default PHB—which is typically best-effort traffic
- Expedited Forwarding (EF) PHB—dedicated to low-loss, low-latency traffic
- Assured Forwarding (AF) PHB—gives assurance of delivery under prescribed conditions
- Class Selector PHBs—which maintain backward compatibility with the IP Precedence field.
Default Forwarding
A Default PHB (a.k.a. Default Forwarding (DF) PHB[2]) is the only required behavior. Essentially, any traffic that does not meet the requirements of any of the other defined classes is placed in the default PHB. Typically, the Default PHB has best-effort forwarding characteristics. The recommended DSCP for the Default PHB is 000000B (0).
Expedited Forwarding
The IETF defines Expedited Forwarding behavior in RFC 3246. The EF PHB has the characteristics of low delay, low loss and low jitter. These characteristics are suitable for voice, video and other realtime services. EF traffic is often given strict priority queuing above all other traffic classes. Because an overload of EF traffic will cause queuing delays and affect the jitter and delay tolerances within the class, EF traffic is often strictly controlled through admission control, policing and other mechanisms. Typical networks will limit EF traffic to no more than 30%—and often much less—of the capacity of a link[citation needed]. The recommended DSCP for expedited forwarding is 101110B (46 or 2EH).
Voice Admit
The IETF defines Voice Admit behavior in RFC 5865. The Voice Admit PHB has identical characteristics to the Expedited Forwarding PHB. However Voice Admit traffic is also admitted by the network using a Call Admission Control (CAC) procedure. The recommended DSCP for voice admit is 101100B (44 or 2CH).
Assured Forwarding
The IETF defines the Assured Forwarding behavior in RFC 2597 and RFC 3260. Assured forwarding allows the operator to provide assurance of delivery as long as the traffic does not exceed some subscribed rate. Traffic that exceeds the subscription rate faces a higher probability of being dropped if congestion occurs.
The AF behavior group defines four separate AF classes where all have the same priority. Within each class, packets are given a drop precedence (high, medium or low, where higher precedence means moredropping). The combination of classes and drop precedence yields twelve separate DSCP encodings from AF11 through AF43 (see table).
| Class 1 | Class 2 | Class 3 | Class 4 | |
|---|---|---|---|---|
| Low drop probability | AF11 (DSCP 10) | AF21 (DSCP 18) | AF31 (DSCP 26) | AF41 (DSCP 34) |
| Med drop probability | AF12 (DSCP 12) | AF22 (DSCP 20) | AF32 (DSCP 28) | AF42 (DSCP 36) |
| High drop probability | AF13 (DSCP 14) | AF23 (DSCP 22) | AF33 (DSCP 30) | AF43 (DSCP 38) |
Some measure of priority and proportional fairness is defined between traffic in different classes. Should congestion occur between classes, the traffic in the higher class is given priority. Rather than using strict priority queuing, more balanced queue servicing algorithms such as fair queuing or weighted fair queuing (WFQ) are likely to be used. If congestion occurs within a class, the packets with the higher drop precedence are discarded first. To prevent issues associated with tail drop, more sophisticated drop selection algorithms such as random early detection (RED) are often used.
Class Selector
Prior to DiffServ, IPv4 networks could use the Precedence field in the TOS byte of the IPv4 header to mark priority traffic. The TOS octet and IP precedence were not widely used. The IETF agreed to reuse the TOS octet as the DS field for DiffServ networks. In order to maintain backward compatibility with network devices that still use the Precedence field, DiffServ defines the Class Selector PHB.
The Class Selector code points are of the form 'xxx000'. The first three bits are the IP precedence bits. Each IP precedence value can be mapped into a DiffServ class. CS0 equals to IP precedence 0, CS1 to IP precedence 1, and so on. If a packet is received from a non-DiffServ aware router that used IP precedence markings, the DiffServ router can still understand the encoding as a Class Selector code point.
| DSCP | Binary | Hex | Decimal | Typical application | Examples |
|---|---|---|---|---|---|
| CS0 (Default) | 000 000 | 0x00 | 0 | ||
| CS1 | 001 000 | 0x08 | 8 | Scavenger | YouTube, Gaming, P2P |
| CS2 | 010 000 | 0x10 | 16 | OAM | SNMP,SSH,Syslog |
| CS3 | 011 000 | 0x18 | 24 | Signaling | SCCP,SIP,H.323 |
| CS4 | 100 000 | 0x20 | 32 | Realtime | TelePresence |
| CS5 | 101 000 | 0x28 | 40 | Broadcast video | Cisco IPVS |
| CS6 | 110 000 | 0x30 | 48 | Network control | EIGRP,OSPF,HSRP,IKE |
| CS7 | 111 000 | 0x38 | 56 |
Commonly used DSCP values
List of the commonly used DSCP values described in RFC 2475.
| DSCP value | Hex value | Decimal value | Meaning | Drop probability | Equivalent IP precedence value |
|---|---|---|---|---|---|
| 101 110 | 0x2e | 46 | Expedited forwarding (EF) | N/A | 101 Critical |
| 000 000 | 0x00 | 0 | Best effort | N/A | 000 - Routine |
| 001 010 | 0x0a | 10 | AF11 | Low | 001 - Priority |
| 001 100 | 0x0c | 12 | AF12 | Medium | 001 - Priority |
| 001 110 | 0x0e | 14 | AF13 | High | 001 - Priority |
| 010 010 | 0x12 | 18 | AF21 | Low | 010 - Immediate |
| 010 100 | 0x14 | 20 | AF22 | Medium | 010 - Immediate |
| 010 110 | 0x16 | 22 | AF23 | High | 010 - Immediate |
| 011 010 | 0x1a | 26 | AF31 | Low | 011 - Flash |
| 011 100 | 0x1c | 28 | AF32 | Medium | 011 - Flash |
| 011 110 | 0x1e | 30 | AF33 | High | 011 - Flash |
| 100 010 | 0x22 | 34 | AF41 | Low | 100 - Flash override |
| 100 100 | 0x24 | 36 | AF42 | Medium | 100 - Flash override |
| 100 110 | 0x26 | 38 | AF43 | High | 100 - Flash override |
Design considerations
Under DiffServ, all the policing and classifying is done at the boundaries between DiffServ domains. This means that in the core of the Internet, routers are unhindered by the complexities of collecting payment or enforcing agreements. That is, in contrast to IntServ, DiffServ requires no advance setup, no reservation, and no time-consuming end-to-end negotiation for each flow.
The details of how individual routers deal with the DS field is configuration specific, therefore it is difficult to predict end-to-end behaviour. This is complicated further if a packet crosses two or more DiffServ domains before reaching its destination. From a commercial viewpoint this means that it is impossible to sell different classes of end-to-end connectivity to end users, as one provider's Gold packet may be another's Bronze. DiffServ or any other IP based QoS marking does not ensure quality of the service or a specified service-level agreement (SLA). By marking the packets, the sender indicates that it wants the packets to be treated as a specific service, but it can only hope that this happens. It is up to all the service providers and their routers in the path to ensure that their policies will take care of the packets in an appropriate fashion.
The problem addressed by DiffServ does not exist in a system that has enough capacity to carry all traffic.
Comments
Post a Comment