While LTE is mainly designed for broadband application, NR is designed for accomodating various application including broadband, mMTC and URLLC all in the single protocol. So the QoS architecture is more flexible (probably more difficult to understand ?) to provide appropriate service for all those application. One obvious difference you may notice is to compare LTE QCI and NR 5QI table, and just compare the length of the tables.
- QoS Structure
- QoS Mapping in Signaling Message
- Mapping between IP packet and QoS Pipe
- QoS Parameters
- What clause 5.7 gained after Release 15
- Reference
QoS Structure
In fact, the QoS is determined / affected by almost every components involved in the communication between the parties of the commication, but major players determining QoS is those components on the bold lines in the UE + Network architecture shown below. Those components are UE, AN(RAN, gNB), UPF (User Plane Function), DN(Data Network). In this illustration, I illustrated a specific sample case of QoS flow so that you can make more tangible sense out of it.
As shown below, the user data would flow from a source (DN in this case) and final destination (UE in this case). Each of the data packet goes though a specific PDU and Data Radio Bearer(DRB). Within these pipe line can be one or more imaginary flow with different level of priority, data rate, latency etc. These imaginary flow is called a QoS Flow. Each of those QoS flow would be eventually mapped to a specific items in 5QI table. In order to meet the requirement in the selected 5QI, network need to configure all the elements from wireless physical resources through all the physical resources on core network interfaces.
Source : Reconstructed based on 3GPP 23.501 and 5G Quality of Service (DEVOPEDIA)
The NR QoS be illustrated in other way as well illustrated by Rahim Navael as shown below. Rahim kindly approved me to share the illustration in my note.
The diagram below takes the same architecture from the control plane end. The top row is the set of network functions that feed policy into the PCF, each on its own reference point, and the PCF passes the result down to the SMF. The lower half is where those decisions land. Three red ovals mark the three places: QoS rules at the UE, QoS profiles at the gNB, and packet detection rules at the UPF.
Image Source : Rahim Navaei's linked in post
The PCF is the single decision point : six network functions feed it. They arrive on N11 and N15 from the AMF, N23 from the NWAF, N40 from the CHF, N30 from the NEF, N5 from the AF and N25 from the UDR. PCC rules leave for the SMF over N7.The SMF distributes to three places over three protocols : QoS rules reach the UE in NAS-5GSM. QoS profiles reach the gNB through the AMF, over HTTP/2 and then NGAP. Packet detection rules reach the UPF over N4 using PFCP.Each of the three does one job : QoS rules map uplink packets to QoS flows and mark them. QoS profiles let the gNB map those flows onto DRBs. PDRs classify downlink packets for the same marking.Uplink and downlink enter at opposite ends : UL IP flows arrive from the application layer at the UE, and DL IP flows arrive from the data network at the UPF. Both are funnelled into one PDU session.The DRB mapping can be told to the UE two ways : the note at the lower left gives both. The gNB configures it by RRC reconfiguration, or through the SDAP header when reflective QoS is used.
The following diagram splits the gNB open. In a centralised RAN the gNB is three units rather than one, so the QoS pipe has to be built across the interfaces between them. The upper half places each interface, the middle shows two DRBs carrying three QoS flows inside one PDU session, and the lower right is the message sequence that sets them up.
Image Source : Rahim Navaei's linked in post
Two tunnels, counted differently : the F1-U tunnel is one per Data Radio Bearer and the N3 tunnel is one per PDU Session. The tunnel count therefore changes at the CU-UP.SDAP sits in the CU-UP and in the UE : that is where QoS flows are mapped onto DRBs. The CU-CP decides the mapping, and sends the SDAP and PDCP configuration to the CU-UP.Three protocols carry the setup : E1AP between CU-CP and CU-UP, F1AP between CU-CP and DU, and RRCReconfiguration to the UE.The two TEIDs are allocated at opposite ends : the F1-U UL-TEID comes from the CU-UP and reaches the DU in messages 2 and 3. The F1-U DL-TEID comes from the DU and reaches the CU-UP in messages 4 and 5.The sequence starts from the core : step 0 is the PDU Session Resource Setup Request arriving from the AMF. That is the same NGAP message decoded in the Example 01 capture further down this page.
The diagram below answers a question the ones above it leave open. One PDU session can carry several non-GBR flows at once, and nothing described so far stops them from consuming the whole link between them. Two aggregate limits do that, and the diagram shows where each one is enforced and where its value comes from.
Image Source : Rahim Navaei's linked in post
Session-AMBR is per PDU session, UE-AMBR is per UE : the diagram enforces the first at the UE for uplink and at the UPF for both directions. 23.501 states that neither applies to GBR QoS flows.The red rings skip the GBR flow : in each of the two PDU sessions they enclose only the non-GBR flows, which is the drawn form of that same rule.The UE-AMBR is a minimum, not a sum : the formula in the middle reads UE-AMBR = Min(sum of Session-AMBRs, subscribed UE-AMBR). 23.501 puts the same rule asthe sum of the Session-AMBR of all PDU Sessions … up to the value of the UE-AMBR received from AMF .Three messages carry the values : the NAS PDU Session Establishment Accept gives the UE the uplink Session-AMBR. The NGAP PDU Session Resource Setup Request gives the gNB both directions and the UE-AMBR. PFCP carries the Session-AMBR to the UPF inside a QER.The subscription is the ceiling : the UDM supplies the SM subscription and the default QoS values, and the PCF supplies the PCC rules. The network cannot hand out more than was subscribed.Both limits are measured over a window : 23.501 adds that the AMBR averaging window is a standardised value. The diagram does not show it, and it is what decides whether a short burst counts against the limit.
QoS Mapping in Signaling Message
QoS is applied for each data stream all the way from wireless physical layer through the every core network sitting on the data path. As mentioned above, the most fundamental units of QoS is QoS Flow. But the QoS flow is a logical pipeline defined for core network flow (more specifically for the data flow between AN(gNB) and UPF, in other words N3 interface). For the wireless part, the data flow is managed in different flow called DRB(Data Radio Bearer). To make a complete QoS pipe from the source of the data through the final destination, there should be some link (mapping) connecting the core network QoS pipe (i.e, QoS Flow) and AN pipe (i.e, DRB), and these mapping need to be informed to UE via signaling message. The signaling message getting involved in the creation and mapping of QoS pipe is illustrated below. The creation (definition) of QoS pipe on core network side is done by PDU Session Establishment Accept and the mapping between the core network QoS pipe and Wireless QoS Pipe(DRB) is done by SDAP configuration in a Rrc message (RrcSetup or RrcReconfiguration). The Indicator (Identification) that connect the whole QoS pipe at every level is called QFI (QoS Flow Identifier).
The figure is worth reading as two halves joined by two arrows. The upper half is the RRC message, and the lower half is the NAS message. Neither one carries the whole mapping, and the arrows are where they meet.
The green arrow carries the PDU session identity : SDAP Config in DRB-ToAddMod names a PDU-SessionID, and the same identity appears at the top of the PDU Session Establishment Accept.The yellow arrows carry the QFI : mappedQoS-FlowsToAdd lists QFI 1 to QFI i for one DRB. The same QFI values appear in the authorized QoS rules and in the QoS flow descriptions.Two lists in NAS, not one : the QoS rules say which packets go to which QFI. The QoS flow descriptions say what treatment that QFI gets, by naming its 5QI.The DRB is the only part RRC decides : drb-Identity and eps-BearerIdentity sit under DRB-ToAddMod, and nothing in the NAS message mentions a DRB.QFI is the value common to both messages : it is the one field carried in each of them. That is what makes the end to end pipe traceable in a log.
Mapping between IP packet and QoS Pipe
In what has been described above, how a QoS pipe is created and what the QoS pipe is made up of is relatively well described. But how various type of original user data (IP packet in most case) is mapped to different type of QoS pipe is not explained in detail. For example, Take a look at the illustration shown at the beginning of this page. If you start streaming a YouTube, at first the packet goes through the internet PDU and within the internet PDU the packet should map to QoS Flow3. Then you may ask 'how the YouTube IP packet is directed (mapped) to QoS Flow3'. You would have similar questions in Uplink IP Packet as well. This mapping is done in both downlink and uplink IP packet as described below.
- By signaling message : Network can inform UE of QoS rules in NAS messages PDU Session Establishment / Modification procedure
- Pre-configured in the UE or implicitly derived by the UE by applying Reflective QoS
A QoS rule contains the QFI of the associated QoS Flow, a Packet Filter Set and a precedence value as shown in the following example.
QoS rule 1:
QoS rule identifier = 1
Rule operation code = 1 (create new QoS rule)
DQR = 1 (the QoS rule is the default QoS rule)
Number of packet filters = 1
Packet filter direction = 3 (bidirectional)
Match-all
QoS Parameters
There are many different Parameters that are involved in NR QoS. According to 23.501-5.7.2, following is the list of the NR QoS parameters. Some of these parameters are pretty straightforward to understand (e.g, 5QI, Bit Rates, Packet Loss Rate) but I would need some more time to get clear understandings on some other parameters (e.g, ARP, RQA, Notification Control).
- 5QI
- ARP (Allocation and Retention Priority)
- RQA (Reflective QoS Attribute)
- Notification Control
- Flow Bit Rates
- Guaranteed Flow Bit Rate (GFBR)
- Maximum Flow Bit Rate (MFBR)
- Aggregate Bit Rates
- per Session Aggregate Maximum Bit Rate (Session-AMBR)
- per UE Aggregate Maximum Bit Rate (UE-AMBR)
- Maximum Packet Loss Rate
Many of those parameters are explcitely specified in signaling messages when a QoS pipe is created. Following example of PDU Session Establishment Accept message shows QoS parameters in it (This is a sample message from the log provided by Amarisoft)
Example 01 >
I tried to list all the important (relavent) messages in RRC, NAS, NGAP which are related to QoS setup and some data packets. Try to follow through the messages and draw a mapping diagram on your own.
NGAP capture, PDU Session Resource Setup Request. Field values are from a live capture, not from the specification.
Message: 127.0.1.100:38412 PDU session resource setup request
initiatingMessage: {
procedureCode id-PDUSessionResourceSetup,
criticality reject,
value {
protocolIEs {
{
id id-AMF-UE-NGAP-ID,
criticality reject,
value 100
},
{
id id-RAN-UE-NGAP-ID,
criticality reject,
value 1
},
{
id id-PDUSessionResourceSetupListSUReq,
criticality reject,
value {
{
pDUSessionID 1,
pDUSessionNAS-PDU '7E02AB8A6BEE047E00680100772E0105C2110009....'H,
s-NSSAI {
sST '01'H
},
pDUSessionResourceSetupRequestTransfer {
protocolIEs {
{
id id-PDUSessionAggregateMaximumBitRate,
criticality reject,
value {
pDUSessionAggregateMaximumBitRateDL 5000000000,
pDUSessionAggregateMaximumBitRateUL 2000000000
}
},
{
id id-UL-NGU-UP-TNLInformation,
criticality reject,
value gTPTunnel:{
transportLayerAddress '7F000164'H,
gTP-TEID '3CE04ECC'H
}
},
{
id id-PDUSessionType,
criticality reject,
value ipv4
},
{
id id-QosFlowSetupRequestList,
criticality reject,
value {
{
qosFlowIdentifier 1,
qosFlowLevelQosParameters {
qosCharacteristics nonDynamic5QI: {
fiveQI 9
},
allocationAndRetentionPriority {
priorityLevelARP 15,
pre-emptionCapability shall-not-trigger-pre-emption,
pre-emptionVulnerability not-pre-emptable
}
},
e-RAB-ID 5
}
}
}
}
}
}
}
},
{
id id-UEAggregateMaximumBitRate,
criticality ignore,
value {
uEAggregateMaximumBitRateDL 5000000000,
uEAggregateMaximumBitRateUL 2000000000
}
}
}
}
}
NAS capture, DL NAS Transport carrying PDU Session Establishment Accept. Field values are from a live capture, not from the specification.
Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x2 (Integrity protected and ciphered)
Auth code = 0xab8a6bee
Sequence number = 0x04
Protocol discriminator = 0x7e (5GS Mobility Management)
Security header = 0x0 (Plain 5GS NAS message, not security protected)
Message type = 0x68 (DL NAS transport)
Payload container type = 1 (N1 SM information)
Payload container:
Protocol discriminator = 0x2e (5GS Session Management)
PDU session identity = 1
Procedure transaction identity = 5
Message type = 0xc2 (PDU session establishment accept)
Selected PDU session type = 0x1 (IPv4)
Selected SSC mode = 0x1 (1)
Authorized QoS rules:
QoS rule 1:
QoS rule identifier = 1
Rule operation code = 1 (create new QoS rule)
DQR = 1 (the QoS rule is the default QoS rule)
Number of packet filters = 1
Packet filter identifier = 15
Packet filter direction = 3 (bidirectional)
Match-all
QoS rule precedence = 255
QFI = 1
Session AMBR:
Session-AMBR for downlink = 5000 Mbps
Session-AMBR for uplink = 2000000 kbps
5GSM cause = 0x32 (PDU session type IPv4 only allowed)
PDU address:
SI6LLA = 0
PDU session type = 1 (IPv4)
IPv4 = 192.168.3.2
S-NSSAI:
Length of S-NSSAI contents = 1 (SST)
SST = 0x01
Mapped EPS bearer contexts:
Mapped EPS bearer context 1:
EPS bearer identity = 5
Operation code = 1 (create new EPS bearer)
E = 1 (parameters list is included)
Number of EPS parameters = 2
Mapped EPS QoS parameters:
QCI = 9
APN-AMBR:
APN-AMBR for downlink = 4864000000 bits
APN-AMBR for uplink = 1792000000 bits
Authorized QoS flow descriptions:
QoS flow description 1:
QFI = 1
Operation code = 1 (create new QoS flow description)
E = 1 (parameters list is included)
Number of parameters = 2
5QI = 9
EPS bearer identity = 5
Extended protocol configuration options:
Ext = 1
Configuration protocol = 0
Protocol ID = 0x8021 (IPCP)
Data = 03 00 00 0a 81 06 08 08 08 08
Protocol ID = 0x000d (DNS Server IPv4 Address)
Data = 8.8.8.8
DNN = "internet.mnc001.mcc001.gprs"
PDU session ID = 1
RRC capture, rrcReconfiguration. Field values are from a live capture, not from the specification.
message c1:rrcReconfiguration : { rrc-TransactionIdentifier 0, criticalExtensions rrcReconfiguration: { radioBearerConfig { srb-ToAddModList { { srb-Identity 2 } }, drb-ToAddModList { {cnAssociation sdap-Config: {pdu-Session 1, sdap-HeaderDL absent, sdap-HeaderUL present, defaultDRB TRUE, mappedQoS-FlowsToAdd { 1 } }, drb-Identity 1, pdcp-Config { drb { discardTimer infinity, pdcp-SN-SizeUL len18bits, pdcp-SN-SizeDL len18bits, headerCompression notUsed: NULL, statusReportRequired true } } } } },
NGAP capture, PDU Session Resource Setup Response. Field values are from a live capture, not from the specification.
Message: 127.0.1.100:38412 PDU session resource setup response
successfulOutcome: {
procedureCode id-PDUSessionResourceSetup,
criticality reject,
value {
protocolIEs {
{
id id-AMF-UE-NGAP-ID,
criticality ignore,
value 100
},
{
id id-RAN-UE-NGAP-ID,
criticality ignore,
value 1
},
{
id id-PDUSessionResourceSetupListSURes,
criticality ignore,
value {
{
pDUSessionID 1,
pDUSessionResourceSetupResponseTransfer {
dLQosFlowPerTNLInformation {
uPTransportLayerInformation gTPTunnel: {
transportLayerAddress '7F000101'H,
gTP-TEID '3D0C6C10'H
},
associatedQosFlowList {
{
qosFlowIdentifier 1
}
}
}
}
}
}
}
}
}
}
GTP-U capture, uplink packet. Field values are from a live capture, not from the specification.
Message: 127.0.1.100:2152 G-PDUTEID=0x3ce04ecc QFI=1 SDU_len=60: IP/UDP 192.168.3.2:10884 > 8.8.8.8:53 Data: 0000: 34 ff 00 44 3c e0 4e cc 00 00 00 85 01 10 01 00 4..D<.N......... 0010: 45 00 00 3c db 6e 40 00 40 11 8b 88 c0 a8 03 02 E..><.n@.@....... 0020: 08 08 08 08 2a 84 00 35 00 28 df a2 92 e0 01 00 ....*..5.(...... 0030: 00 01 00 00 00 00 00 00 03 77 77 77 06 67 6f 6f .........www.goo 0040: 67 6c 65 03 63 6f 6d 00 00 01 00 01 gle.com.....>
GTP-U capture, downlink packet. Field values are from a live capture, not from the specification.
Message: 127.0.1.100:2152 G-PDUTEID=0x3d0c6c10 QFI=1 SDU_len=91: IP/UDP 8.8.8.8:53 > 192.168.3.2:29701 Data: 0000: 34 ff 00 63 3d 0c 6c 10 00 00 00 85 01 00 01 00 4..c=.l......... 0010: 45 00 00 5b d4 b4 00 00 78 11 9a 23 08 08 08 08 E..[....x..#.... 0020: c0 a8 03 02 00 35 74 05 00 47 49 22 f8 08 81 80 .....5t..GI".... 0030: 00 01 00 01 00 00 00 00 11 63 6f 6e 6e 65 63 74 .........connect 0040: 69 76 69 74 79 63 68 65 63 6b 07 67 73 74 61 74 ivitycheck.gstat 0050: 69 63 03 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00 ic.com.......... 0060: 01 00 00 00 7e 00 04 8e fb 20 43 ....~.... C
What clause 5.7 gained after Release 15
The parameter list above is the Release 15 set, and it is still the core of 5G QoS. Clause 5.7 of 23.501 has grown since then, and the current version is v20.2.0. Two of the additions matter enough to know about, because they change what a QoS flow can be asked to carry.
23.501 clause |
What it adds |
|---|---|
5.7.1.2a Alternative QoS Profile |
A ranked set of fallback QoS values for a GBR flow, so the network can be told what to do when the requested profile cannot be met. |
5.7.2.4.1a and 5.7.2.4.1b |
Notification control split into a version without alternative QoS profiles and a version with them. |
5.7.2.9 Wireline access network specific 5G QoS parameters |
A parameter group for wireline access, which did not exist when the list on this page was written. |
5.7.7 PDU Set QoS Parameters |
Three parameters that treat a group of PDUs as one unit: PSDB, PSER and PSIHI. |
The alternative QoS profile answers a question the original design left open. Notification control lets the network tell the application when a guaranteed flow can no longer be guaranteed, and in Release 15 that was the whole of it. An alternative QoS profile adds a ranked list of weaker profiles. The notification can then say which of them the flow is now using, rather than only that the original one failed.
The PDU set parameters come from the extended reality work, and they exist because a video frame is not one packet. A decoder needs every PDU of a frame or none of them, and losing one PDU can make the rest useless. Clause 5.7.7 therefore parameterises the set rather than the packet.
PSDB is a delay budget for the set : 23.501 defines the PDU Set Delay Budget in clause 5.7.7.2, alongside the per packet budget the 5QI table already carried.PSER is an error rate for the set : clause 5.7.7.3, the PDU Set Error Rate, measured over sets rather than over individual PDUs.PSIHI says whether the set is all or nothing : clause 5.7.7.4, PDU Set Integrated Handling Information, which tells the network that every PDU of the set is needed.The Release 15 parameters did not change : 5QI, ARP, RQA, notification control, the bit rates and the maximum packet loss rate all still sit where the list above puts them.One row was missing from that list : clause 5.7.2.9 covers wireline access specific parameters, and the list above stops at 5.7.2.8.
Reference
- 5G Quality of Service
- 5G NR QoS Architecture, QoS Attribute and QoS Flow
- Learn about QoS in 5G Networks by Paul Shepherd
- Qos in 5G (Quality of service in 5G) - Part 1 (YouTube)
- Qos in 5G (Quality of service in 5G) - Part 2 (YouTube)
- QoS (Quality of Service) in 5G (YouTube)
- SERVICE DATA ADAPTATION PROTOCOL (SDAP) (YouTube)
- 3GPP 38.300 - NR and NG-RAN Overall description; Stage-2 => Chapter 12
- 3GPP 23.501 - 5G;System architecture for the 5G System (5GS) => Section 5.7
- 3GPP 24.501 - 5G;System architecture for the 5G System (5GS) => Section 9.11.4.12 ~ 9.11.4.14
- 23.501 v20.2.0 : System architecture for the 5G System. Clause 5.7 is the source for the QoS parameter list and for the section on what it gained after Release 15.
- 3GPP 38.413 - 5G; NG-RAN;NG Application Protocol (NGAP) => Section 8.2