Quality of Service (QoS) in LTE

Background: Why we need QoS ? 

There are premium subscribers who always want to have better user experience on their 4G LTE device. These users are willing to pay more for high bandwidth and better network access on their devices. Not only the subscribers but some services itself need better priority handling in the network (e.g. VoIP call). To be able to full fill this, QOS plays the key role. QOS defines priorities for certain customers / services during the time of high congestion in the network

3GPP definition for QoS

In LTE Network QoS is implemented between UE and PDN Gateway and is applied to a set of bearers. 'Bearer' is basically a virtual concept and is a set of network configuration to provide special treatment to set of traffic e.g. VoIP packets are prioritized by network compared to web browser traffic.
In LTE, QoS is applied on Radio bearer, S1 bearer and S5/S8 bearer, collectively called as EPS bearer as shown in figure below.

In order to comprehend the concept of QoS , we must understand the bearer types and properties associated with each bearer through hierarchical chart as shown below. First there are two types of Bearer, i.e. Dedicated bearer and Default bearer. There is  at-least one default bearer established when UE is attached to LTE network while dedicated bearer is always established when there is need to provide QoS to specific service (like VoIP, video etc). Please go through the article Default and Dedicated Bearer which hopefully will help to explain the concept in more detail.

Dedicated bearer can be subdivided into Non-GBR and GBR types. 

GBR provides guaranteed bit rate and is associated with parameters like GBR and MBR

- GBR: The minimum guaranteed bit rate per EPS bearer. Specified independently for uplink and downlink

- MBR: The maximum guaranteed bit rate per EPS bearer. Specified independently for uplink and downlink

On the other hand, Non-GBR bearer does not provide guaranteed bit rate and has parameter like A- AMBR and UE- AMBR

- A-AMBR: APN Aggregate maximum bit rate is the maximum allowed total non-GBR throughput to specific APN. It is specified interdependently for uplink an downlink 

- UE -AMBR: UE Aggregate maximum bit rate is the maximum allowed total non-GBR throughput among all APN to a specific UE

As you can see, the default bearer can only be non-GBR type. Some other  important terms associated with each bearer type are discussed below:

- ARP: Allocation and retention priority is basically used for deciding whether new bearer modification or establishment request should be accepted considering the current resource situation.

- TFT: Traffic flow template is always associated with dedicated bearer and while default bearer may or may not have TFT. As mentioned earlier, dedicated bearer provides QoS to special service or application and TFT defines rules so that UE and Network knows which IP packet should be sent on particular dedicated bearer. It usually has rules on the basis of IP packet destination/source or protocol used.

L-EBI: It stands for Linked EPS bearer ID. As I discussed in previous article about dedicated and default bearer, we know that each dedicated bearer is always linked to one of default bearers. L-EBI tells Dedicated bearer which default bearer it is attached to. 

IP Address/ PDN: Each default bearer is attached to some PDN network and has its own IP address while dedicated bearer does not need this since it is linked to default bearer.

You can also see one other parameter associated with all bearers i.e. QoS class of identifier (QCI).This parameter basically defines IP level packets characteristics as shown below

EXAMPLE

Let me try to explain here again with the same example I gave in Default and Dedicated Bearer section

Usually LTE networks with VoLTE implementations have two default and one dedicated bearer

Default bearer 1: Used for signaling messages (sip signaling) related to IMS network. It uses qci 5
Dedicated bearer: Used for VoLTE VoIP traffic. It uses qci 1 and is linked to default bearer 1
Default bearer 2: Used for all other smartphone traffic (video, chat, email, browser etc), assuming qci 9 is used here

This means that Default bearer 1 is associated with IMS PDN and has specific IP address. It has throughput limitations defined in terms of A-AMBR and UE-AMBR. Since it has qci 5 which means that its IP packets has the highest priority over other IP packets and maximum delay as 100ms between UE and PGW with packet loss percentage up to 10^-6

Default bearer 2 is associated with internet PDN and has specific IP. It has throughput limitations defined in terms of A-AMBR and UE-AMBR as well. Since it has qci 9 which means that its IP packets has the lowest priority over other IP packets and maximum delay possible as 300ms between UE and PGW with packet loss percentage up to 10^-6

Dedicated bearer will be linked to Default bearer 1 with L-EBI and it also has TFT which basically defines which IP packets should be allowed to travel on this bearer. It has throughput limitations defined in terms of MBR and GBR. Since it is using QCI 1, the IP packets traveling on this bearer have the second highest priority. The maximum delay possible to IP packets on this bearer is 100 ms and the percentage of packet loss will be under 10^-2

AKA Digest authentication scheme for VoLTE (IMS)

When a VoLTE client needs to connect to IMS network, it has to authenticate the network while network also needs to make sure that only the correct user is registered to its network. AKA Digest is one of the scheme to authenticate VoLTE client to the IMS server

AKA

AKA stands for "Authentication and key agreement". This scheme comes from the legacy 3gpp networks and has been widely used in LTE, 3G, CDMA and WiMAX technologies. In this mechanism, a secret key is already known to both user device (USIM, iSIM) and authentication servers (HSS, HLR). 

The server will challenge the end user using AKA algorithms and shared key and sends RAND, AUTN values towards UE. UE will authenticate network and prepares result (RES for network to authenticate UE) with the help of shared key in UICC and parameters sent by Server.

HTTP Digest

Http Digest is the popular authentication scheme used for authenticating users to access web servers and other applications which requires security and data integrity. This scheme is much secure than the basic authentication as it applies hash function to the password before sending it [RFC2617]. 

HTTP Digest is username / password based authentication procedure. The authentication server provides one time created " nonce " value to the client. The client uses the nonce value and creates a secure response that contains  the password, username and other parameters to the server. The password which is known both to server and client, is always fixed

Now For IMS

Now since IMS is a part of 3GPP and on the contrary SIP signaling defines http digest for authentication [RFC3261]. Therefore in order to use 3GPP AKA with IMS, the parameters from AKA are mapped onto http digest [RFC3310]. In simple words the parameters / headers used to transport http digest information, will transport AKA information in identical format

With 3GPP AKA digest, the "nonce" now contains RAND, AUTN. The password now contains the one time RESPONSE generated by client with help of UICC (USIM, ISIM). Thus the method is even more secure. 

Authentication in IMS networks

• VoLTE Client sends SIP register request to IMS Server. The user is not authenticated at this  point. The SIP register request contains IMS related identities (private identity, public identity, URI, etc)

• The IMS server (S-CSCF) obtains authentication vector and SQN from HSS that contains a random challenge RAND, authentication token AUTN, expected authentication result XRES, a session key for integrity check IK, and a session key for encryption CK

• The server creates an authentication request, which contains the random challenge RAND, and the network authenticator token AUTN

• The authentication request is delivered to the client with "401 UNAUTHORIZED" message

• The client verifies the AUTN with the ISIM. If the verification is successful, the network has been authenticated. The client then produces an authentication response RES, using the shared secret K and the random challenge RAND

3GPP AKA Operation in IMS

• The authentication response RES is delivered to the server using new regiser sip message

• The server compares the authentication response RES with the expected response. If the two match, the user has been successfully authenticated

• Session keys IK and CK can be used for protecting further communications between the client and the server

• Server sends "200 OK" message to inform the VoLTE client about successful registration

Semi persistent scheduling

Every VoIP packet is received / sent every 20ms when the user is talking whereas in silence period, discontinuous transmission (DTX) is used to reduce the transmission rate. Also, in order to sustain voice quality, silent insertion descriptor (SID) packet arrives every 160ms. The frequent arrival/transmission of VoIP packet means large control overhead for lower layers (L1/L2) in the radio protocol stack. To deal with this issue, semi persistent scheduling plays an important role.

Scheduling is a mechanism where UE requests eNB for the resource allocation during each transmission time interval (TTI). If UE has some data that it needs to transmit continuously, it will request eNB every TTI for the resource allocation. This scheduling type is dynamic scheduling. The advantage of dynamic scheduling is flexibility and diversity of resource allocation but as mentioned, this results in huge L1/L2 load which in turn means inefficient use of scarce radio resources.

In case of semi persistent scheduling, eNB can assign predefined chunk of radio resources for VoIP users with interval of 20ms. Therefore, UE is not required to request resources each TTI, saving control plan overhead. This scheduling is semi-persistent in the sense that eNB can change the resource allocation type or location if required for link adaptation or other factors.

TTI Bundling

With all the hype created around IMS and LTE, operators have started questioning network vendors if they are supporting RAN specific features for VoLTE. TTI bundling is one of the features among many others that can help VoIP (VoLTE) calls in LTE.

TTI Bundling is LTE feature to improve coverage at cell edge or in poor radio conditions. UE has limited power in uplink (only 23dBm for LTE) which can result in many re transmissions at cell edge (poor radio). Re transmission means delay and control plan overhead which may not be acceptable for certain services like VoIP. To understand TTI bundling one need to have the basic idea of Hybrid Automatic Repeat Request (HARQ) and Transmission Time interval (TTI).

HARQ

HARQ is a process where data at mac layer is protected against noisy wireless channels through error correction mechanism. There are couple of different versions of HARQ but in LTE we have a type known as 'Incremental Redundancy Hybrid ARQ'. When receiver detects erroneous data, it doesn't discard it. On the other hand, sender will send the same data again but this time, with different set of coded bits. The reciever will combine the previously recieved erroneous data with newly attempted data by the sender. This way the chances of successfully decoding the bits improve every time. This will repeat as long as the receiver is not able to decode the data. The advantage of this method is  that with each re-transmission, the coding rate is lowered. Whereas in other types of HARQ, it might use the same coding rate in every re-transmission

TTI

TTI is LTE smallest unit of time in which eNB is capable of scheduling any user for uplink or downlink transmission. If a user is receiving downlink data, then  during each 1ms, eNB will assign resources and inform user where to look for its downlink data through PDCCH channel. Check the following figure to understand the concept of TTI

Now coming to TTI Bundling ...

HARQ is a process where receiver combines the new transmission every time with previous erroneous data. There is one drawback however, that it can result in delay and too much control overhead in case of poor radio conditions if the sender has to attempt many transmissions. For services like VoIP this means bad end user experience. Well, there is another way- Instead of re-transmitting the erroneous data with new set of coded bits, why not send few versions (redundancy versions) of the same set of bits in consecutive TTI and eNB sends back Ack when it successfully decodes the bits. I hope  the figure below will make it clear. This way we are avoiding delay and reducing control plane overhead at mac layer 

Voice solutions in LTE

The original idea behind LTE is that it would provide only wireless internet services. However, major revenue for cellular operators comes from voice calls and SMS and therefore Voice in LTE has become a hot topic. Recently, I got an opportunity  to work with various voice solutions-the experience which I believe would be useful to share here.

LTE does not have a 'circuit switch core' which means that we cannot have voice calls as it is in 2G and 3G technologies. In the initial LTE deployment cases however, operators are using their legacy networks along with their 4G network for voice services.

So far we have heard of the following available voice solutions which I will discuss briefly.

• Circuit Switched Fall Back (CSFB)
• Simultaneous Voice and LTE (SV-LTE)
• Voice over LTE (VoLTE)
• Voice over LTE via Generic Access (VoLGA)
• Over the top (OTT)

Circuit Switched Fall Back 

An operator who deployed LTE network, already owning a 3G or 2G network can take benefit from the feature called "Circuit switched fall back'. The main idea is that 4G smartphones are going to have a radio capabilities for 3G/2G networks as well. Such handsets can connect at a time either to LTE or 2G/3G . The shortcoming is that someone on voice call will not be able to use LTE network for browsing or chatting etc.

CSFB for operator means very little investment since only few modifications are required in the network. Additional interface between MME and MSC is required (SGs). CSFB solution has also been standardized by 3GPP and has gained large industrial support.

Simultaneous Voice and LTE

SV-LTE is handset specific in which handset is capabile of using two radios (LTE and WCDMA/GSM/CDMA) at one time. So a user can use packet services from LTE while voice call can be made on other networks simultaneously unlike CSFB. The shortfall here is high battery utilization due to dual radio operation. 

For CDMA and  LTE pair, the SV-LTE is the standard solution and being widely adopted. There are already SV-LTE smartphones available in the market. I came across a few available for LGU+ in Korea and Verizon in USA. Both operate LTE networks as an overlay to their old CDMA networks. 

SV-LTE is the cheapest option for operators as no new modification is required to the network. Nevertheless, as mentioned earlier it is at the cost of high battery utilization

Voice over LTE (IMS)

I believe this is going to be the most popular and widely adopted future voice solution for LTE. Instead of using legacy networks, VoLTE utilizes IP Multimedia Subsystem (IMS) and provides voice services  using the application layer on LTE.
IMS is a group of core network entities responsible for providing rich multimedia services over IP network. VoIP call, SMS, MMS, LIVE TV are a few such services. IMS has been in the communication industry for long but with the emergence of 4G networks, it is gaining popularity again.

Voice over LTE via Generic Access

I think, operators will accept VoLGA as a last option for voice capability. This solution uses CS core only from legacy networks and also require new network elements. Therefore LTE handsets do not need 3G/2G radio capabilities since radio part won't be used from legacy networks. Good thing about this solution however is that unlike CSFB, LTE handset will be able to use voice and data simultaneously.

Over the top VoIP application

OTT is actually not LTE specific but a generic solution that we already have been using on 3G/WiFi networks. OTT application is completely transparent to network and also out of operators' control. I am talking about generic VoIP clients like Viber, skype, Tango etc. They do not give the real taste of voice flexibility as in other 3GPP networks and also lack the QoS for voice. Nonetheless,  these will be widely used by the consumers as an alternative, because of the fact that it gives them full flexibility to choose their own service.