5QI stands for 5G QoS Identifier. In one sentence, it is a single number that tells every node in the network how a specific stream of data should be treated. It is the 5G version of QCI in LTE. It just has more options and finer granularity, and it has one new resource type called Delay Critical GBR which does not exist in LTE QCI.

Even though the idea itself is simple, many people get confused when they see the big table in 23.501. So in this page, I will build up the concept step by step : first why we need such a thing at all, then what the number really means, then what is hidden behind the number, and finally how to read the standardized table.

• Why do we need something like 5QI ?
• What exactly is 5QI ? (It is just an index)
• What is hidden behind a 5QI value ? (QoS Characteristics)
• Three Types of 5QI
• Where does 5QI sit in the whole QoS picture ?
• How to read the standardized 5QI table
• Standardized 5QI Table (23.501 - Table 5.7.4-1)
• Examples
• Example 01 : 5QI 9 - Default Internet Data (the complete setup process)
• Example 02 : 5QI 5 and 5QI 1 - VoNR Call (adding a GBR flow to a live session)
• Example 03 : 5QI 82 - Delay Critical GBR (URLLC)
• Example 04 : Dynamically Assigned 5QI (operator specific QoS)
• Example 05 : Multiple 5QIs in one UE and how they end up in DRBs

Why do we need something like 5QI ?

Let's start with a simple question. Is every packet in your phone equally important ? Obviously not.

Think about what you do with your phone in a single minute. You may be talking on a VoLTE/VoNR call, downloading a large file in the background, and getting a push notification from a messenger, all at the same time. These three data streams have completely different needs.

• Voice call : the amount of data is very small, but it must arrive quickly and steadily. If a voice packet arrives 500 ms late, it is useless. You would rather lose the packet than hear a long delay.
• File download : the amount of data is huge, but a delay of one second does not really matter. What matters is that no single byte is lost, and that the average throughput is high.
• Push notification : very small, not urgent, and it happens only once in a while.

Now put yourself in the position of the scheduler in the gNB. At every slot (which can be as short as 0.125 ms), it has to decide which data to send first with how much radio resource. To make this decision, the scheduler needs to know the "personality" of each data stream : how fast it must be delivered, how much packet loss it can tolerate, whether the bit rate must be guaranteed or not, and how important it is compared to the others.

The problem is that this information cannot be decided by the gNB alone. The core network (SMF/PCF) is the one who knows the service and the subscription. The UE also needs to know it for uplink. And the gNB and the UPF are usually from different vendors. So we need a common language that all of these nodes understand in exactly the same way. That common language is 5QI.

What exactly is 5QI ? (It is just an index)

Here is the most important point of this page, and the point that is most often misunderstood.

5QI is not a set of QoS values. 5QI is just a pointer (an index number) to a row in a table that everybody already has.

An easy analogy is ordering food at a restaurant. Instead of describing the whole recipe to the waiter ("I want rice, with beef, with two eggs, medium spicy..."), you just say "Number 7, please". The waiter and the kitchen both have the same menu, so the single number "7" carries all the details. If the menu is shared, one number is enough.

5QI works in exactly the same way. The "menu" is Table 5.7.4-1 of 3GPP 23.501, which is shown at the bottom of this page. When the core network says "this data stream is 5QI 1", the gNB does not need any further explanation. It looks up row 1 of the same table and immediately knows :

• this is a GBR (Guaranteed Bit Rate) stream,
• priority level is 20,
• the packet must be delivered within 100 ms,
• up to 1 packet out of 100 may be lost,
• and this is typically a conversational voice service.

This is why only the number is carried in the signaling messages. The actual values are never sent over the air, because they are already written in the specification that both sides implement.

NOTE : The value range of 5QI is 0 ~ 255, but not all of the values are defined in the standard table. The reason will be explained in Three Types of 5QI.

What is hidden behind a 5QI value ? (QoS Characteristics)

Now let's open the menu and see what is written in each row. In 3GPP terminology, these are called QoS Characteristics (23.501 - 5.7.3). Each column of the big table is one of these characteristics. If you understand these six items, you can read any row of the table.

• Resource Type : This is the first branch point, and it decides the whole behavior of the flow. There are three types, described in more detail just below.
• Priority Level : Which flow should be served first when the radio resource is not enough for everybody. A lower number means higher priority (this is the part that confuses people the most). So Priority Level 10 is more urgent than Priority Level 80.
• Packet Delay Budget (PDB) : The maximum time a packet is allowed to spend between the UE and the UPF (the N6 termination point). It is a budget for the whole path, not only for the radio part. A part of this budget is consumed by the core network (this is called CN PDB, e.g, 1 ms, 2 ms, 20 ms depending on the 5QI as written in the NOTEs under the table), and what remains is the budget for the radio interface (5G-AN PDB). If a packet cannot be delivered within this budget, it is normally discarded rather than delivered late.
• Packet Error Rate (PER) : The rate of packets that may be lost even after all the retransmission mechanisms (HARQ, RLC) have done their best. 10^-2 means "1 packet out of 100 may be lost and the service still works". 10^-6 means "only 1 packet out of a million may be lost", which is a URLLC level requirement. This number directly influences how conservative the MCS and the HARQ configuration should be.
• Averaging Window : The time window over which the bit rate (GFBR/MFBR) is measured. Bit rate is meaningless without a time window. If the window is 2000 ms, the network checks whether the guaranteed bit rate is satisfied on average over 2 seconds, not at every single millisecond.
• Maximum Data Burst Volume (MDBV) : The largest amount of data that the network must be able to deliver within one PDB period. This one applies only to Delay Critical GBR. It tells the RAN "be prepared to move this much data in one shot within the delay budget", which is important for scheduling and admission control.

Among these, Resource Type is the one that changes the behavior most drastically, so let me describe the three types separately.

• GBR (Guaranteed Bit Rate) : The network commits to a minimum bit rate for this flow. To keep this promise, the network has to reserve resources and perform admission control (i.e, it may reject a new flow if it cannot keep the promise). Typical example is conversational voice or live video. With GBR, a packet that arrives later than the PDB is not counted as lost (see NOTE 1 of the table).
• Non-GBR : No bit rate is guaranteed. The flow gets whatever capacity is left, shared with other Non-GBR flows according to the priority level. Most of the ordinary internet traffic (web browsing, video streaming, file download, IMS signaling) uses Non-GBR. There is no admission control based on bit rate, so many Non-GBR flows can coexist and they just get slower when the cell is busy.
• Delay Critical GBR : This is the new type in 5G that does not exist in LTE QCI. It is GBR plus a much stricter delay and reliability contract, and it adds the MDBV parameter. Here, unlike normal GBR, a packet that is delayed more than the PDB is counted as lost and therefore contributes to the PER. This is the resource type used for URLLC services such as factory automation, motion control and remote driving.

NOTE : Notice that 5QI itself does not contain any bit rate value. Even for a GBR flow, the actual guaranteed bit rate (GFBR) and maximum bit rate (MFBR) are signaled separately as independent QoS parameters. 5QI tells the network what kind of treatment is needed, and GFBR/MFBR tell the network how much. Do not mix up these two.

Three Types of 5QI

Earlier I said that 5QI is an index into a table that everybody has. But what if an operator wants a QoS treatment which is not in the standard table ? For this reason, 3GPP defines three ways of using a 5QI value (23.501 - 5.7.4).

• Standardized 5QI : The values that are written in Table 5.7.4-1 (the table at the bottom of this page). The one-to-one mapping between the 5QI value and the QoS characteristics is hard-coded in the specification, so nothing needs to be signaled except the number itself. This is the most common case.
• Pre-configured 5QI : The QoS characteristics are configured in advance inside the RAN node by the operator (O&M), not defined by 3GPP. Again only the 5QI value is signaled, but the meaning of the value is operator-specific. This is used when an operator has its own service profile that does not match any standardized row.
• Dynamically Assigned 5QI : The QoS characteristics are explicitly signaled together with the 5QI value as a part of the QoS profile over N2 (NGAP). This is the most flexible way, but also the heaviest one because the full parameter set has to be carried in the signaling message.

So, when you capture a log and see a 5QI value that is not in the standard table, it does not mean the log is wrong. It most likely means the operator is using a pre-configured or dynamically assigned 5QI.

Where does 5QI sit in the whole QoS picture ?

It helps a lot to know exactly where this number lives. The QoS structure of 5G can be summarized as a chain of containers as follows.

• A UE has one or more PDU Sessions (a pipe toward a specific data network, e.g, internet or IMS).
• Within a PDU Session, there are one or more QoS Flows. The QoS Flow is the finest granularity of QoS in 5G : everything inside one QoS Flow gets exactly the same treatment.
• Each QoS Flow is identified by a QFI (QoS Flow Identifier), and each QoS Flow is associated with exactly one 5QI.
• On the radio side, one or more QoS Flows are mapped into a DRB (Data Radio Bearer). This mapping is done by the SDAP layer, and the gNB decides it based on (among other things) the 5QI of each flow.

So the relation can be memorized like this : QFI is the name tag of a flow, and 5QI is the service class of that flow. QFI answers "which flow is this ?" and 5QI answers "how should this flow be treated ?". QFI is what is actually written in the GTP-U header of every user data packet, and 5QI is what the network looked up when it decided the treatment for that QFI.

In terms of who does what :

• PCF / SMF decides the 5QI for each QoS Flow based on the subscription and the service.
• SMF -> AMF -> gNB : the 5QI is delivered to the RAN inside the QoS Profile of the NGAP PDU Session Resource Setup Request.
• SMF -> UE : the 5QI is delivered to the UE inside the QoS Flow Description of the NAS PDU Session Establishment Accept, so that the UE can apply the correct treatment for uplink.
• gNB translates the 5QI into real configuration : scheduling priority, DRB mapping, RLC mode (AM/UM), HARQ/MCS strategy, DRX setting and so on.

NOTE : Regarding where / how 5QI is configured in signaling message, check out the note on QoS.

How to read the standardized 5QI table

Now you are ready for the big table. The table looks scary only because it is long, but you read it row by row and each row is just one "menu item". Let me walk through three rows as examples.

• 5QI = 1 (GBR / Priority 20 / PDB 100 ms / PER 10^-2) : Conversational Voice. Read it as "reserve a small but guaranteed pipe, deliver within 100 ms, and it is fine to lose 1% of the packets". Losing a bit is acceptable because a lost voice frame is much less annoying than a late voice frame.
• 5QI = 9 (Non-GBR / Priority 90 / PDB 300 ms / PER 10^-6) : This is the default one, used for ordinary internet traffic such as video streaming or file download. Read it as "no guarantee, low priority, but please do not lose data". This is the 5QI you will see most often in a normal commercial log.
• 5QI = 82 (Delay Critical GBR / Priority 19 / PDB 10 ms / PER 10^-4 / MDBV 255 bytes) : Discrete Automation. Read it as "a small burst of 255 bytes must be delivered within 10 ms, almost every time, without fail". This is a typical URLLC profile.

A few practical tips while reading the table :

• Compare the Priority Level column vertically. It shows you the intended order of importance across all services. For example, 5QI 65 (Mission Critical Push To Talk) has priority 7, which is more urgent than the normal voice of 5QI 1 (priority 20).
• The Example Services column is only informative. It is a hint about the intention of that row, not a restriction. An operator can use a 5QI for any service that fits the characteristics.
• Do not ignore the NOTEs at the bottom of the table. Several of them (NOTE 4, 5, 6, 7, 13) tell you how much of the PDB is assumed to be consumed by the core network, which is what actually determines the delay budget left for the radio interface.
• Some rows exist only for a specific purpose. For example, 5QI 5 is dedicated to IMS signaling, and 5QI 79/80 are for V2X and low latency eMBB.

Standardized 5QI Table

The following is the standardized 5QI table quoted from 3GPP 23.501. When you compare this table with the LTE QCI table, the difference is obvious even before reading the contents : the 5G table is much longer, it has more columns, and it has the Delay Critical GBR block which simply did not exist in LTE. This is the direct consequence of 5G trying to serve eMBB, URLLC and mMTC with a single framework.

< 23.501 - Table 5.7.4-1: Standardized 5QI to QoS characteristics mapping >

Examples

Reading the table is one thing, but seeing how a 5QI value actually travels through the network is another thing. In this section, I will follow a few typical cases from the very beginning (the moment the network decides the QoS) to the very end (the moment a user data packet is scheduled over the air). If you understand the first example completely, the rest of them are just variations of the same story.

NOTE : The message snippets below are simplified and reconstructed to show only the QoS related IEs. A real log has many more IEs and the exact format differs a little bit depending on the equipment vendor. The point here is the structure and the flow, not the exact byte values.

Example 01 : 5QI 9 - Default Internet Data (the complete setup process)

This is the case you will meet most often. A UE powers on, registers to the network, and asks for a PDU Session to browse the internet. No application asks for any special treatment, so the network simply gives the default QoS Flow with 5QI 9. Let's follow the whole process step by step.

The overall picture of who talks to whom is as follows.

       UE                          gNB                         AMF                   SMF             PCF
        |                           |                           |                     |               |
Step 1  |--- PDU Session Establishment Request (NAS) -------------------------------->|               |
Step 2  |                           |                           |                     |<-- policy --->|
        |                           |                           |               (5QI is decided here) |
Step 3  |                           |<-- PDU Session Resource Setup Request (NGAP) ---|               |
Step 4  |                           |  (gNB translates 5QI 9 into DRB / scheduler settings)           |
Step 5  |<-- RRC Reconfiguration ---|                           |                     |               |
Step 6  |<--------------------------------- PDU Session Establishment Accept (NAS) ---|               |
Step 7  |                           |--- PDU Session Resource Setup Response (NGAP) ->|               |
Step 8  |=== user data (DRB) ======>| ==== N3 : GTP-U with QFI (to the UPF) ====>     |               |

Step 1 : The UE asks for a PDU Session (UE -> SMF, NAS)

The UE sends a PDU Session Establishment Request. Notice that the UE does not ask for a 5QI here. It only says which data network it wants (DNN), which slice (S-NSSAI), and which PDU session type (IPv4, IPv6 etc). Choosing the QoS is the network's job, not the UE's job.

 

PDU Session Establishment Request

  PDU session identity = 1

  PTI = 1

  Integrity protection maximum data rate = Full data rate

  PDU session type = IPv4

  SSC mode = SSC mode 1

  DNN = internet

 

Step 2 : The network decides the QoS (SMF and PCF, invisible in the air log)

The SMF asks the PCF (or uses a locally configured policy) "what QoS should I give to this subscriber for the DNN 'internet' ?". The answer comes back as a set of PCC rules, and from those rules the SMF builds the QoS profile of the default QoS Flow. In our case the answer is 5QI = 9, plus ARP, plus the Session-AMBR.

This step is the reason why you sometimes cannot find the "cause" of a QoS problem in the air interface log. If the 5QI in the log is not the one you expected, the mistake was made here, in the subscription data or in the policy, not in the RAN.

Step 3 : The QoS Profile is delivered to the gNB (5GC -> RAN, NGAP)

This is the most important message for us. The SMF sends the QoS profile to the gNB through the AMF, inside PDU Session Resource Setup Request. The 5QI appears here as nonDynamic5QI, which means "look up the standardized table".

 

PDU Session Resource Setup Request

  pDUSessionID 1,

  pDUSessionAggregateMaximumBitRateDL 1000000000,

  pDUSessionAggregateMaximumBitRateUL  100000000,

  pDUSessionType ipv4,

  qosFlowSetupRequestList {

    {

      qosFlowIdentifier 1,            -- this is QFI

      qosFlowLevelQosParameters {

        qosCharacteristics nonDynamic5QI : {

          fiveQI 9                -- the whole QoS in one number

        },

        allocationAndRetentionPriority {

          priorityLevelARP 8,

          pre-emptionCapability shall-not-trigger-pre-emption,

          pre-emptionVulnerability pre-emptable

        }

      }

    }

  }

 

Things to notice in this message :

• There is no gBR-QosInformation IE. This is normal, because 5QI 9 is Non-GBR and there is no bit rate to guarantee. If you see a GBR 5QI without this IE, that is an error.
• ARP (priorityLevelARP) is a completely different thing from the Priority Level of the 5QI. ARP decides whether this flow may be admitted or kicked out when resources run short. The 5QI priority decides the packet scheduling order once the flow is already admitted.
• The QFI (here 1) and the 5QI (here 9) are two different numbers. Do not assume QFI = 5QI. They are often different, and they happen to be equal only by coincidence.

Step 4 : The gNB translates 5QI 9 into a real radio configuration (gNB internal)

The gNB now looks up row 9 of the standardized table and turns each characteristic into a concrete configuration decision. This is the moment where an abstract number becomes real behavior.

Step 5 : The gNB configures the UE (gNB -> UE, RRC Reconfiguration)

The result of Step 4 is sent to the UE as a DRB configuration. Note that the 5QI value itself does not appear in the RRC message. What the UE receives is only the consequence of the 5QI : which DRB to use, which QoS Flow is mapped into it, and how RLC/PDCP/logical channel should behave.

 

rrcReconfiguration

  radioBearerConfig {

    drb-ToAddModList {

      {

        drb-Identity 1,

        cnAssociation sdap-Config : {

          pdu-Session 1,

          sdap-HeaderDL absent,

          sdap-HeaderUL absent,

          defaultDRB true,

          mappedQoS-FlowsToAdd { 1 }   -- QFI 1 goes into DRB 1

        },

        pdcp-Config { drb { discardTimer ms100, pdcp-SN-SizeUL len18bits, headerCompression notUsed }, t-Reordering ms100 }

      }

    }

  },

  rlc-BearerToAddModList {

    { logicalChannelIdentity 4, servedRadioBearer drb-Identity : 1,

      rlc-Config am : { ... },          -- because PER is 10e-6

      mac-LogicalChannelConfig { priority 13, prioritisedBitRate kBps0 }  -- because 5QI priority is low

    }

  }

 

Step 6 : The UE is told the same thing in NAS terms (5GC -> UE, PDU Session Establishment Accept)

In parallel with the RRC configuration, the UE receives the NAS level view of the same QoS Flow. Here the 5QI does appear, inside the QoS flow description, and the UE also gets the QoS rules which tell it how to classify its own uplink packets.

 

PDU Session Establishment Accept

  PDU session identity = 1

  Session-AMBR = DL 1 Gbps / UL 100 Mbps

  Authorized QoS rules :

    QoS rule 1 :

      Rule operation code = 1 (create new QoS rule)

      DQR = 1 (this is the default QoS rule)

      Packet filter = Match-all      -- everything that matches nothing else comes here

      QoS rule precedence = 255

      QFI = 1

  Authorized QoS flow descriptions :

    QoS flow description 1 :

      QFI = 1

      Operation code = 1 (create new QoS flow description)

      Parameter : 5QI = 9

 

So now both sides agree : "any packet that does not match a more specific rule goes to QFI 1, and QFI 1 is treated as 5QI 9".

Step 7 : The gNB confirms to the core (RAN -> 5GC, NGAP)

The gNB replies with PDU Session Resource Setup Response. The important part for QoS is the list of QoS Flows that were actually accepted (associatedQosFlowList) and, if any flow could not be accepted, qosFlowFailedToSetupList with a cause. For a Non-GBR flow like 5QI 9, a failure here is rare. For a GBR flow it is quite possible, and that is where admission control shows up (see Example 02).

Step 8 : Data flows

Finally the real traffic starts, and the 5QI keeps working silently in the background.

• Downlink : The UPF classifies the incoming IP packet using PDR, marks the GTP-U header with QFI = 1, and sends it to the gNB. The gNB sees QFI 1, remembers that QFI 1 is 5QI 9, and schedules the packet with low priority and a relaxed deadline.
• Uplink : The UE checks its QoS rules, finds that its packet matches the Match-all filter, so it puts the packet into QFI 1, which the SDAP layer maps into DRB 1.

NOTE : This is the key sentence to remember for the whole page. 5QI is decided once at session setup, but it is applied at every single packet, at every node, for the whole life of the flow.

Example 02 : 5QI 5 and 5QI 1 - VoNR Call (adding a GBR flow to a live session)

Example 01 was a session created from nothing. Now let's look at the case where a QoS Flow is added to a PDU session that is already running. A VoNR call is the classic case, and it involves two different 5QIs at the same time.

The story goes like this :

• When the UE registers to IMS, a separate PDU Session (DNN = ims) is created with a default QoS Flow using 5QI 5 (Non-GBR, Priority 10, PDB 100 ms, PER 10^-6). This flow carries only SIP signalling. It is Non-GBR because SIP messages are small and bursty, but its priority is very high (10) because a call cannot even start if SIP is delayed.
• When the user actually makes a call, SIP/SDP negotiation finishes and the IMS core (P-CSCF -> PCF) requests a dedicated bearer for the voice media. The SMF then modifies the existing PDU session and adds a new QoS Flow with 5QI 1 (GBR, Priority 20, PDB 100 ms, PER 10^-2) for the RTP stream.

Because the session already exists, the procedure is a modification, not an establishment. The message names change accordingly.

 

 1. SIP INVITE / 183 / PRACK ... (over QFI of 5QI 5)

 2. P-CSCF -> PCF -> SMF : "this call needs a voice bearer"

 3. SMF -> AMF -> gNB : PDU Session Resource Modify Request (new QoS Flow, 5QI 1 + GFBR/MFBR)

 4. gNB : admission control for the GBR flow, then RRC Reconfiguration (add DRB 2)

 5. 5GC -> UE : PDU Session Modification Command (new QoS rule with RTP packet filters)

 6. gNB -> AMF : PDU Session Resource Modify Response

 7. RTP voice packets start to flow on the new QFI

 

The QoS profile of the new flow looks like below. Compare it with Step 3 of Example 01 and you will immediately see the difference : the gBR-QosInformation block is now present.

 

qosFlowAddOrModifyRequestList {

  {

    qosFlowIdentifier 2,

    qosFlowLevelQosParameters {

      qosCharacteristics nonDynamic5QI : {

        fiveQI 1

      },

      allocationAndRetentionPriority {

        priorityLevelARP 2,           -- voice is protected

        pre-emptionCapability may-trigger-pre-emption,

        pre-emptionVulnerability not-pre-emptable

      },

      gBR-QosInformation {

        maximumFlowBitRateDL     44000,

        maximumFlowBitRateUL     44000,

        guaranteedFlowBitRateDL  13600,   -- GFBR : this is the promise

        guaranteedFlowBitRateUL  13600,

        notificationControl notification-requested

      }

    }

  }

}

 

This example shows three behaviors that only happen with a GBR 5QI :

• Admission control : Before saying yes, the gNB checks whether it can really guarantee 13.6 kbps in both directions for this UE at its current radio quality. If it cannot, it returns the flow in qosFlowFailedToSetupList, and the IMS core will either retry with a lower codec or let the call fall back (e.g, EPS fallback to LTE).
• Notification Control : Because notification-requested is set, if the gNB later becomes unable to keep the GFBR (for example the user walks to the cell edge), it must send a notification to the SMF instead of silently degrading the call. The network can then react, for example by switching to a lower rate codec.
• Different radio configuration : For 5QI 1, the gNB usually creates a separate DRB with RLC UM (not AM). For voice, a retransmitted packet that arrives late is useless, and the PER of 10^-2 says that losing 1% is acceptable. This is exactly the opposite decision from the 5QI 9 case in Example 01, and both decisions come from reading the same table.

And the uplink QoS rule for the new flow is no longer "Match-all". It contains real packet filters so that only the RTP stream goes into the expensive GBR flow :

 

QoS rule 2 :

  Rule operation code = 1 (create new QoS rule)

  DQR = 0 (not the default rule)

  Packet filter (uplink) : protocol = UDP, remote IP = <IMS media gateway>, remote port = 50000 ... 50003

  QoS rule precedence = 100   -- lower value is checked first, so this wins over the Match-all rule

  QFI = 2

 

Example 03 : 5QI 82 - Delay Critical GBR (URLLC)

Now the third resource type. 5QI 82 is defined for Discrete Automation, and its numbers are Delay Critical GBR / Priority 19 / PDB 10 ms / PER 10^-4 / MDBV 255 bytes / Averaging Window 2000 ms.

The signaling structure is the same as Example 02 (it is a GBR flow, so gBR-QosInformation is present), but two extra fields appear and they change everything.

 

qosFlowLevelQosParameters {

  qosCharacteristics nonDynamic5QI : {

    fiveQI 82,

    maximumDataBurstVolume 255    -- may be sent explicitly to override the default

  },

  allocationAndRetentionPriority { priorityLevelARP 1, ... },

  gBR-QosInformation {

    maximumFlowBitRateDL 2000000, maximumFlowBitRateUL 2000000,

    guaranteedFlowBitRateDL 2000000, guaranteedFlowBitRateUL 2000000,

    maximumPacketLossRateDL 10, maximumPacketLossRateUL 10

  }

}

 

What the gNB has to do differently for a Delay Critical flow :

• The delay budget is brutal : PDB is 10 ms, and NOTE 4 of the table says 1 ms of it is already spent in the core network. So the radio has about 9 ms to finish everything including scheduling request, grant, transmission and HARQ retransmission. With a 15 kHz subcarrier spacing (1 ms slot) this is almost impossible, so in practice such a flow requires a high subcarrier spacing (30 or 120 kHz), mini-slot (Type B) scheduling, and often a configured grant so that the UE does not have to wait for a scheduling request in uplink.
• Late equals lost : For normal GBR, NOTE 1 says a late packet is not counted as lost. For Delay Critical GBR the opposite is true : a packet delivered after the PDB is counted in the PER. So the gNB cannot solve the problem by simply retransmitting many times. It has to be right the first time, which usually means a very conservative MCS, and possibly PDCP duplication over two carriers.
• MDBV is a promise about a burst : 255 bytes means "you must be able to move up to 255 bytes within one 10 ms budget". The gNB uses this for admission control and for deciding the grant size. If the application sends more than the MDBV in one burst, the excess traffic is not protected by the QoS contract any more.
• Maximum Packet Loss Rate : this IE (in units of 0.1%, so 10 means 1%) is an additional per-flow limit which is signaled separately from the PER in the 5QI table. It is used mostly for voice and URLLC flows.

NOTE : Watch out for the units when you read a real NGAP log. The packetDelayBudget IE is expressed in units of 0.5 ms, so a PDB of 10 ms appears as the value 20, not 10. The PER is expressed as a scalar and an exponent, so 10^-4 appears as pERScalar 1 and pERExponent 4. Many people misread these two fields.

Example 04 : Dynamically Assigned 5QI (operator specific QoS)

In all the previous examples, the message only carried a number and both sides looked up the standardized table. Now let's see what happens when the operator wants a QoS profile that does not exist in the table. In this case the QoS characteristics are carried explicitly in the signaling using the dynamic5QI choice.

 

qosFlowLevelQosParameters {

  qosCharacteristics dynamic5QI : {

    priorityLevelQos 25,            -- the "Default Priority Level" column

    packetDelayBudget 60,           -- the "PDB" column, in 0.5 ms unit => 30 ms

    packetErrorRate { pERScalar 1, pERExponent 5 },  -- the "PER" column => 1x10e-5

    fiveQI 130,                   -- optional, just a label for this operator specific profile

    delayCritical non-delay-critical,  -- the "Resource Type" column

    averagingWindow 2000            -- the "Averaging Window" column, in ms

  },

  allocationAndRetentionPriority { ... },

  gBR-QosInformation { ... }

}

 

If you compare this block with the columns of the big table, you will notice that they are exactly the same items. This is the best proof of what I said at the beginning : a standardized 5QI is nothing more than a shortcut for this list of values. When the shortcut exists, we send one number. When it does not exist, we send the whole list.

Practical points about the dynamic case :

• The fiveQI field inside dynamic5QI is optional. When it is present, it is only a label so that the RAN can group and report the flow. It does not mean "look up the table".
• Every signaling message for this flow becomes bigger, and the RAN cannot use any pre-optimized profile, so most operators use dynamic 5QI only where they really need it.
• Values in the range 128 ~ 254 are typically used for operator specific 5QIs, while 1 ~ 127 are reserved for the standardized ones.

Example 05 : Multiple 5QIs in one UE and how they end up in DRBs

In real life, a single UE has several QoS Flows at the same time. Let's take a UE that is browsing the internet while making a VoNR call. This is the combination of Example 01 and Example 02.

Two rules are worth remembering from this table :

• A DRB never crosses a PDU Session. QFI 1 of PDU Session 1 and QFI 1 of PDU Session 2 are completely different flows, and they can never share a DRB. This is also why the QFI value is only unique inside one PDU session.
• Several QoS Flows may share one DRB, but only if their treatment is similar. The gNB is allowed to put two flows into the same DRB (this is why the SDAP header exists : it keeps the QFI so the receiver can still tell them apart). But it will never mix 5QI 1 and 5QI 9 in one DRB, because a single DRB has only one RLC mode and one logical channel priority, and these two 5QIs need opposite settings.

And this is a good place to close the loop of this page. Everything the RAN did above - three DRBs, two RLC modes, three different scheduling priorities - was derived from three small numbers : 9, 5 and 1. That is the whole purpose of 5QI.

Reference :

[1]