The 5G QoS model is based on QoS Flows (see TS 23.501) and supports both QoS Flows that require guaranteed flow bit rate (GBR QoS Flows) and QoS Flows that do not require guaranteed flow bit rate (non-GBR QoS Flows). At NAS level (see TS 23.501), the QoS flow is thus the finest granularity of QoS differentiation in a PDU session. A QoS flow is identified within a PDU session by a QoS Flow ID (QFI) carried in an encapsulation header over NG-U. The QoS architecture in NG-RAN, both for NR connected to 5GC and for E-UTRA connected to 5GC, is depicted in the Figure 12-1 and described in the following:

• For each UE, 5GC establishes one or more PDU Sessions;
• Except for NB-IoT, IAB-MT in SA mode, and NCR-MT, for each UE, the NG-RAN establishes at least one Data Radio Bearers (DRB) together with the PDU Session and additional DRB(s) for QoS flow(s) of that PDU session can be subsequently configured (it is up to NG-RAN when to do so);
• If NB-IoT UE supports NG-U data transfer, the NG-RAN may establish Data Radio Bearers (DRB) together with the PDU Session and one PDU session maps to only one DRB;
• The NG-RAN maps packets belonging to different PDU sessions to different DRBs;
• NAS level packet filters in the UE and in the 5GC associate UL and DL packets with QoS Flows;
• AS-level mapping rules in the UE and in the NG-RAN associate UL and DL QoS Flows with DRBs.

NG-RAN and 5GC ensure quality of service (e.g. reliability and target delay) by mapping packets to appropriate QoS Flows and DRBs. Hence there is a 2-step mapping of IP-flows to QoS flows (NAS) and from QoS flows to DRBs (Access Stratum). At NAS level, a QoS flow is characterised by a QoS profile provided by 5GC to NG-RAN and QoS rule(s) provided by 5GC to the UE. The QoS profile is used by NG-RAN to determine the treatment on the radio interface while the QoS rules dictates the mapping between uplink User Plane traffic and QoS flows to the UE. A QoS flow may either be GBR or Non-GBR depending on its profile. The QoS profile of a QoS flow contains QoS parameters, for instance (see TS 23.501):

• For each QoS flow:
  • A 5G QoS Identifier (5QI);
  • An Allocation and Retention Priority (ARP).
• In case of a GBR QoS flow only:
  • Guaranteed Flow Bit Rate (GFBR) for both uplink and downlink;
  • Maximum Flow Bit Rate (MFBR) for both uplink and downlink;
  • Maximum Packet Loss Rate for both uplink and downlink;
  • Delay Critical Resource Type;
  • Notification Control.
• In case of Non-GBR QoS only:
  • Reflective QoS Attribute (RQA): the RQA, when included, indicates that some (not necessarily all) traffic carried on this QoS flow is subject to reflective quality of service (RQoS) at NAS;
  • Additional QoS Flow Information.

The QoS parameter Notification Control indicates whether notifications are requested from the RAN when the GFBR can no longer (or again) be fulfilled for a QoS Flow. If, for a given GBR QoS Flow, notification control is enabled and the RAN determines that the GFBR cannot be guaranteed, RAN shall send a notification towards SMF and keep the QoS Flow (i.e. while the NG-RAN is not delivering the requested GFBR for this QoS Flow), unless specific conditions at the NG-RAN require the release of the NG-RAN resources for this GBR QoS Flow, e.g. due to Radio link failure or RAN internal congestion. When applicable, NG-RAN sends a new notification, informing SMF that the GFBR can be guaranteed again. If Alternative QoS parameters Sets are received with the Notification Control parameter, the NG-RAN may also include in the notification a reference corresponding to the QoS Parameter Set which it can currently fulfil as specified in TS 23.501. The target NG-RAN node may include in the notification control indication the reference to the QoS Parameter Set which it can currently fulfil over Xn to the source NG-RAN node during handover. In addition, an Aggregate Maximum Bit Rate is associated to each PDU session (Session-AMBR), to each UE (UE-AMBR) and to each slice per UE (UE-Slice-MBR). The Session-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS Flows for a specific PDU Session and is ensured by the UPF. The UE-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS Flows of a UE and is ensured by the RAN (see clause 10.5.1). The UE-Slice-MBR limits the aggregate bit rate that can be expected to be provided across all GBR and Non-GBR QoS Flows corresponding to PDU Sessions of the UE for the same slice (S-NSSAI) as specified in TS 23.501 and is ensured by the RAN (see clause 10.5.1). The 5QI is associated to QoS characteristics giving guidelines for setting node specific parameters for each QoS Flow. Standardized or pre-configured 5G QoS characteristics are derived from the 5QI value and are not explicitly signalled. Signalled QoS characteristics are included as part of the QoS profile. The QoS characteristics consist for instance of (see TS 23.501):

• Priority level;
• Packet Delay Budget (including Core Network Packet Delay Budget);
• Packet Error Rate;
• Averaging window;
• Maximum Data Burst Volume.

At Access Stratum level, the data radio bearer (DRB) defines the packet treatment on the radio interface (Uu). A DRB serves packets with the same packet forwarding treatment. The QoS flow to DRB mapping by NG-RAN is based on QFI and the associated QoS profiles (i.e. QoS parameters and QoS characteristics). Separate DRBs may be established for QoS flows requiring different packet forwarding treatment, or several QoS Flows belonging to the same PDU session can be multiplexed in the same DRB. In the uplink, the mapping of QoS Flows to DRBs is controlled by mapping rules which are signalled in two different ways:

• Reflective mapping: for each DRB, the UE monitors the QFI(s) of the downlink packets and applies the same mapping in the uplink; that is, for a DRB, the UE maps the uplink packets belonging to the QoS flows(s) corresponding to the QFI(s) and PDU Session observed in the downlink packets for that DRB. To enable this reflective mapping, the NG-RAN marks downlink packets over Uu with QFI.
• Explicit Configuration: QoS flow to DRB mapping rules can be explicitly signalled by RRC.

The UE always applies the latest update of the mapping rules regardless of whether it is performed via reflecting mapping or explicit configuration. When a QoS flow to DRB mapping rule is updated, the UE sends an end marker on the old bearer. In the downlink, the QFI is signalled by NG-RAN over Uu for the purpose of RQoS and if neither NG-RAN, nor the NAS (as indicated by the RQA) intend to use reflective mapping for the QoS flow(s) carried in a DRB, no QFI is signalled for that DRB over Uu. In the uplink, NG-RAN can configure the UE to signal QFI over Uu. For each PDU session, a default DRB may be configured: if an incoming UL packet matches neither an RRC configured nor a reflective mapping rule, the UE then maps that packet to the default DRB of the PDU session. For non-GBR QoS flows, the 5GC may send to the NG-RAN the Additional QoS Flow Information parameter associated with certain QoS flows to indicate that traffic is likely to appear more often on them compared to other non-GBR QoS flows established on the same PDU session. Within each PDU session, it is up to NG-RAN how to map multiple QoS flows to a DRB. The NG-RAN may map a GBR flow and a non-GBR flow, or more than one GBR flow to the same DRB, but mechanisms to optimise these cases are not within the scope of standardization.

The gNB and the UE support of the Explicit Congestion Notification (ECN) is specified in Section 5 of RFC 3168.

The following principles apply to NR connected to 5GC security, see TS 33.501:

• For user data (DRBs), ciphering provides user data confidentiality and integrity protection provides user data integrity;
• For RRC signalling (SRBs), ciphering provides signalling data confidentiality and integrity protection signalling data integrity;
• For key management and data handling, any entity processing cleartext shall be protected from physical attacks and located in a secure environment;
• The gNB (AS) keys are cryptographically separated from the 5GC (NAS) keys;
• Separate AS and NAS level Security Mode Command (SMC) procedures are used;
• A sequence number (COUNT) is used as input to the ciphering and integrity protection and a given sequence number must only be used once for a given key (except for identical re-transmission) on the same radio bearer in the same direction.

The keys are organised and derived as follows:

• Key for AMF:
  • KAMF is a key derived by ME and SEAF from KSEAF.
• Keys for NAS signalling:
  • KNASint is a key derived by ME and AMF from KAMF, which shall only be used for the protection of NAS signalling with a particular integrity algorithm;
  • KNASenc is a key derived by ME and AMF from KAMF, which shall only be used for the protection of NAS signalling with a particular encryption algorithm.
• Key for gNB:
  • KgNB is a key derived by ME and AMF from KAMF. KgNB is further derived by ME and source gNB when performing horizontal or vertical key derivation.
• Keys for UP traffic:
  • KUPenc is a key derived by ME and gNB from KgNB, which shall only be used for the protection of UP traffic between ME and gNB with a particular encryption algorithm;
  • KUPint is a key derived by ME and gNB from KgNB, which shall only be used for the protection of UP traffic between ME and gNB with a particular integrity algorithm.
• Keys for RRC signalling:
  • KRRCint is a key derived by ME and gNB from KgNB, which shall only be used for the protection of RRC signalling with a particular integrity algorithm;
  • KRRCenc is a key derived by ME and gNB from KgNB, which shall only be used for the protection of RRC signalling with a particular encryption algorithm.
• Intermediate keys:
  • NH is a key derived by ME and AMF to provide forward security.
  • KgNB* is a key derived by ME and gNB when performing a horizontal or vertical key derivation.

The primary authentication enables mutual authentication between the UE and the network and provide an anchor key called KSEAF. From KSEAF, KAMF is created during e.g. primary authentication or NAS key re-keying and key refresh events. Based on KAMF, KNASint and KNASenc are then derived when running a successful NAS SMC procedure. Whenever an initial AS security context needs to be established between UE and gNB, AMF and the UE derive a KgNB and a Next Hop parameter (NH). The KgNB and the NH are derived from the KAMF. A NH Chaining Counter (NCC) is associated with each KgNB and NH parameter. Every KgNB is associated with the NCC corresponding to the NH value from which it was derived. At initial setup, the KgNB is derived directly from KAMF, and is then considered to be associated with a virtual NH parameter with NCC value equal to zero. At initial setup, the derived NH value is associated with the NCC value one. On handovers, the basis for the KgNB that will be used between the UE and the target gNB, called KgNB*, is derived from either the currently active KgNB or from the NH parameter. If KgNB* is derived from the currently active KgNB, this is referred to as a horizontal key derivation and is indicated to UE with an NCC that does not increase. If the KgNB* is derived from the NH parameter, the derivation is referred to as a vertical key derivation and is indicated to UE with an NCC increase. Finally, KRRCint, KRRCenc, KUPint and KUPenc are derived based on KgNB after a new KgNB is derived. This is depicted on Figure 13.1-1 below:

With such key derivation, a gNB with knowledge of a KgNB, shared with a UE, is unable to compute any previous KgNB that has been used between the same UE and a previous gNB, therefore providing backward security. Similarly, a gNB with knowledge of a KgNB, shared with a UE, is unable to predict any future KgNB that will be used between the same UE and another gNB after n or more handovers (since NH parameters are only computable by the UE and the AMF). The AS SMC procedure is for RRC and UP security algorithms negotiation and RRC security activation. When AS security context is to be established in the gNB, the AMF sends the complete UE 5G security capabilities to the gNB (i.e., all bits for every capability defined in TS 24.501 and received in NAS signalling). At handover (or at UE Context retrieval), the complete UE 5G security capabilities are also sent by the source gNB to the target gNB (or by the last serving gNB to the receiving gNB respectively). The gNB chooses the ciphering algorithm which has the highest priority from its configured list and is also present in the UE 5G security capabilities. The gNB also chooses the integrity algorithm which has the highest priority from its configured list and is also present in the UE 5G security capabilities. The chosen algorithms are indicated to the UE in the AS SMC and this message is integrity protected. RRC downlink ciphering (encryption) at the gNB starts after sending the AS SMC message. RRC uplink deciphering (decryption) at the gNB starts after receiving and successful verification of the integrity protected AS security mode complete message from the UE. The UE verifies the validity of the AS SMC message from the gNB by verifying the integrity of the received message. RRC uplink ciphering (encryption) at the UE starts after sending the AS security mode complete message. RRC downlink deciphering (decryption) at the UE shall start after receiving and successful verification of the AS SMC message. The RRC Connection Reconfiguration procedure used to add DRBs shall be performed only after RRC security has been activated as part of the AS SMC procedure. A UE connected to 5GC, shall support integrity protected DRBs at any data rate, up to and including the highest data rate supported by the UE for both UL and DL. In case of failed integrity check (i.e. faulty or missing MAC-I), the concerned PDU shall be discarded by the receiving PDCP entity. Key refresh is possible for KgNB, KRRCenc, KRRCint, KUPenc, and KUPint and can be initiated by the gNB when a PDCP COUNTs are about to be re-used with the same Radio Bearer identity and with the same KgNB. Key re-keying is also possible for the KgNB, KRRCenc, KRRCint, KUPenc, and KUPint and can be initiated by the AMF when a 5G AS security context different from the currently active one shall be activated.

The Table below describes the security termination points.

As a general principle, on RRC_IDLE to RRC_CONNECTED transitions, RRC protection keys and UP protection keys are generated while keys for NAS protection as well as higher layer keys are assumed to be already available. These higher layer keys may have been established as a result of an AKA run, or as a result of a transfer from another AMF during handover or idle mode mobility see TS 23.502). On RRC_CONNECTED to RRC_IDLE transitions, the gNBs deletes the keys it stores for that UE such that state information for idle mode UEs only has to be maintained in AMF. It is also assumed that gNB does no longer store state information about the corresponding UE and deletes the current keys from its memory. In particular, on connected to idle transitions:

• The gNB and UE delete NH, KgNB, KRRCint, KRRCenc, KUPint and KUPenc and related NCC;
• AMF and UE keeps KAMF, KNASint and KNASenc stored.

On mobility with vertical key derivation the NH is further bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the KgNB in the target gNB. On mobility with horizontal key derivation the currently active KgNB is further bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the KgNB in the target gNB (see clause 13.1). In both cases, ARFCN-DL is the absolute frequency of SSB of the target PCell. It is not required to change the AS security algorithms during intra-gNB-CU handover. If the UE does not receive an indication of new AS security algorithms during an intra-gNB-CU handover, the UE shall continue to use the same algorithms as before the handover (see TS 38.331).