Tag Archives: Quality Class Indicator

QoS in LTE (4G) – QCI

EPC, EUTRAN, LTE, Mobile Networks, RF, , , , , , ,

The QCI (Quality Class Indicator) is a value of 0-9 to denote the service type and the maximum delays, packet loss and throughput the service requires.

Different data flows have different service requirements, let’s look at some examples:

A VoLTE call requires low latency and low packet loss, without low latency it’ll be impossible to hold a conversation with long delays, and with high packet loss you won’t be able to hear each other.

On the other hand a HTTP (Web) browsing session will be impervious to high latency or packet loss – the only perceived change would be slightly longer page load times as lost packets are resent and added delay on load of a few hundred ms.

So now we understand the different requirements of data flows, let’s look at the columns in the table above so we can understand what they actually signify:

GBR

Guaranteed Bit Rate bearers means our eNB will reserve resource blocks to carry this data no matter what, it’ll have those resource blocks ready to transport this data.

Even if the data’s not flowing a GBR means the resources are reserved even if nothing is going through them.

This means those resource blocks can’t be shared by other users on the network. The Uu interface in the E-UTRAN is shared between UEs in time and frequency, but with GBR bearers parts of this can be reserved exclusively for use by that traffic.

Non-GBR

With a Non-GBR bearer this means there is no guaranteed bit rate, and it’s just best effort.

Non-GBR traffic is scheduled onto resource blocks when they’re not in use by other non-GBR traffic or by GBR traffic.

Priority

The priory value is used for preemption by the PCRF.

The lower the value the more quickly it’ll be processed and scheduled onto the Uu interface.

Packet Delay Budget

Maximum allowable packet delay as measured from P-GW to UE.

Most of the budget relates to the over-the-air scheduling delays.

The eNB uses the QCI information to make its scheduling decisions and packet prioritisation to ensure that the QoS requirements are met on a per-EPS-bearer basis.

(20ms is typically subtracted from this value to account for the radio propagation delay on the Uu interface)

Packet Error Loss Rate (PELR)

This is packets lost on the Uu interface, that have been sent but not confirmed received.

The PELR is an upper boundary for how high this can go, based on the SDUs (IP Packets) that have been processed by the sender on RLC but not delivered up to the next layers (PDCP) by the receiver.

(Any traffic bursting above the GBR is not counted toward the PELR)

(The list is now larger than 0-9 with 3GPP adding extra QCI values for MCPTT, V2X, etc, the full list is available here in table 6.1.7A)

QoS in LTE (4G) – GBR & Non-GBR Bearers

EPC, EUTRAN, LTE, Mobile Networks, RF, , , , , , , , ,

GBR is a confusing concept at the start when looking at LTE but it’s actually kind of simple when we break it down.

GBR stands for Guaranteed Bit Rate, meaning the UE is guaranteed a set bit rate for the bearer.

The default bearer is always a non-GBR bearer, with best effort data rates.

Let’s look at non-GBR bearers to understand the need for GBR bearers:

As the Uu (Air) interface is shared between many UEs, each is able to transfer data. Let’s take an example of a cell with two UEs in it and not much bandwidth available.

If UE1 and UE2 are both sending the same amount of data it’ll be evenly split between the two.

But if UE1 starts sending a huge amount of data (high bit rate) this will impact on the other UEs in the cells ability to send data over the air as it’s a shared resource.

So if UE2 needs to send a stream of small but important data over the air interface, while UE2 is sending huge amounts of data, we’d have a problem.

To address this we introduce the concept of a Guaranteed Bit Rate. We tell the eNB that the bearer carrying UE2’s small but important data needs a Guaranteed Bit Rate and it reserves blocks on the air interface for UE2’s data.

So now we’ve seen the need for GBR there’s the counter point – the cost.

While UE1 can still continue sending but the eNB will schedule fewer resource blocks to it as it’s reserved some for UE2’s data flow.

If we introduced more and more UEs each requiring GBR bearers, eventually our non-GBR traffic would simply not get through, so GBR bearers have to be used sparingly.

Note: IP data isn’t like frame relay or circuit switched data that’s consistent, bit rate can spike and drop away all the time. GBR guarantees a minimum bit rate, which is generally tuned to the requirements of the data flow. For example a GBR for a Voice over IP call would reserve enough for the media (RTP stream) but no more, so as not to use up resources it doesn’t need.