The PDCCH monitoring activity of the UE in RRC connected mode is governed by DRX, BA, and DCP.
When DRX is configured, the UE does not have to continuously monitor PDCCH. DRX is characterized by the following:
on-duration: duration that the UE waits for, after waking up, to receive PDCCHs. If the UE successfully decodes a PDCCH, the UE stays awake and starts the inactivity timer;
inactivity-timer: duration that the UE waits to successfully decode a PDCCH, from the last successful decoding of a PDCCH, failing which it can go back to sleep. The UE shall restart the inactivity timer following a single successful decoding of a PDCCH for a first transmission only (i.e. not for retransmissions);
retransmission-timer: duration until a retransmission can be expected;
cycle: specifies the periodic repetition of the on-duration followed by a possible period of inactivity (see figure 11-1 below);
active-time: total duration that the UE monitors PDCCH. This includes the "on-duration" of the DRX cycle, the time UE is performing continuous reception while the inactivity timer has not expired, and the time when the UE is performing continuous reception while waiting for a retransmission opportunity.
When BA is configured, the UE only has to monitor PDCCH on the one active BWP i.e. it does not have to monitor PDCCH on the entire DL frequency of the cell. A BWP inactivity timer (independent from the DRX inactivity-timer described above) is used to switch the active BWP to the default one: the timer is restarted upon successful PDCCH decoding and the switch to the default BWP takes place when it expires.
In addition, the UE may be indicated, when configured accordingly, whether it is required to monitor or not the PDCCH during the next occurrence of the on-duration by a DCP monitored on the active BWP. If the UE does not detect a DCP on the active BWP, it does not monitor the PDCCH during the next occurrence of the on-duration, unless it is explicitly configured to do so in that case.
A UE can only be configured to monitor DCP when connected mode DRX is configured, and at occasion(s) at a configured offset before the on-duration. More than one monitoring occasion can be configured before the on-duration. The UE does not monitor DCP on occasions occurring during active-time, measurement gaps, BWP switching, or when it monitors response for a CFRA preamble transmission for beam failure recovery (see clause 9.2.6), in which case it monitors the PDCCH during the next on-duration. If no DCP is configured in the active BWP, UE follows normal DRX operation.
When CA is configured, DCP is only configured on the PCell.
One DCP can be configured to control PDCCH monitoring during on-duration for one or more UEs independently.
Power saving in RRC_IDLE and RRC_INACTIVE can also be achieved by UE relaxing neighbour cells RRM measurements when it meets the criteria determining it is in low mobility and/or not at cell edge.
UE power saving may be enabled by adapting the DL maximum number of MIMO layers by BWP switching.
Power saving is also enabled during active-time via cross-slot scheduling, which facilitates UE to achieve power saving with the assumption that it won't be scheduled to receive PDSCH, triggered to receive A-CSI or transmit a PUSCH scheduled by the PDCCH until the minimum scheduling offsets K0 and K2. Dynamic adaptation of the minimum scheduling offsets K0 and K2 is controlled by PDCCH.
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, 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;
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.
In addition, an Aggregate Maximum Bit Rate is associated to each PDU session (Session-AMBR) and to each UE (UE-AMBR). 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 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):
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 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:
K AMF is a key derived by ME and SEAF from KSEAF.
Keys for NAS signalling:
K NASint is a key derived by ME and AMF from K AMF, which shall only be used for the protection of NAS signalling with a particular integrity algorithm;
K NASenc is a key derived by ME and AMF from K AMF, which shall only be used for the protection of NAS signalling with a particular encryption algorithm.
Key for gNB:
K gNB is a key derived by ME and AMF from K AMF. K gNB is further derived by ME and source gNB when performing horizontal or vertical key derivation.
Keys for UP traffic:
K UPenc is a key derived by ME and gNB from K gNB, which shall only be used for the protection of UP traffic between ME and gNB with a particular encryption algorithm;
K UPint is a key derived by ME and gNB from K gNB, which shall only be used for the protection of UP traffic between ME and gNB with a particular integrity algorithm.
Keys for RRC signalling:
K RRCint is a key derived by ME and gNB from K gNB, which shall only be used for the protection of RRC signalling with a particular integrity algorithm;
K RRCenc is a key derived by ME and gNB from K gNB, which shall only be used for the protection of RRC signalling with a particular encryption algorithm.
NH is a key derived by ME and AMF to provide forward security.
K gNB* 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, K AMF is created during e.g. primary authentication or NAS key re-keying and key refresh events. Based on K AMF, K NASint and K NASenc 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 K gNB and a Next Hop parameter (NH). The K gNB and the NH are derived from the K AMF. A NH Chaining Counter (NCC) is associated with each K gNB and NH parameter. Every K gNB is associated with the NCC corresponding to the NH value from which it was derived. At initial setup, the K gNB is derived directly from K AMF, 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 K gNB that will be used between the UE and the target gNB, called K gNB*, is derived from either the currently active K gNB or from the NH parameter. If K gNB* is derived from the currently active K gNB, this is referred to as a horizontal key derivation and is indicated to UE with an NCC that does not increase. If the K gNB* 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, K RRCint, K RRCenc, K UPint and K UPenc are derived based on K gNB after a new K gNB is derived. This is depicted on Figure 13.1-1 below:
With such key derivation, a gNB with knowledge of a K gNB, shared with a UE, is unable to compute any previous K gNB that has been used between the same UE and a previous gNB, therefore providing backward security. Similarly, a gNB with knowledge of a K gNB, shared with a UE, is unable to predict any future K gNB 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 UE 5G security capabilities to the gNB. 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 K gNB, KRRC-enc, KRRC-int, KUP-enc, and KUP-int 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 K gNB. Key re-keying is also possible for the K gNB, KRRC-enc, KRRC-int, KUP-enc, and KUP-int and can be initiated by the AMF when a 5G AS security context different from the currently active one shall be activated.
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, K gNB, K RRCint, K RRCenc, K UPint and K UPenc and related NCC;
AMF and UE keeps K AMF, K NASint and K NASenc 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 K gNB in the target gNB. On mobility with horizontal key derivation the currently active K gNB is further bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the K gNB 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).
The UE capabilities in NR do not rely on UE categories: UE categories associated to fixed peak data rates are only defined for marketing purposes and not signalled to the network. Instead, the network determines the UL and DL data rate supported by a UE from the supported band combinations and from the baseband capabilities (modulation scheme, MIMO layers, …).
To limit signalling overhead, the gNB can request the UE to provide NR capabilities for a restricted set of bands. When responding, the UE can skip a subset of the requested band combinations when the corresponding UE capabilities are the same.
If supported by the UE and the network, the UE may provide an ID in NAS signalling that represents its radio capabilities for one or more RATs in order to reduce signalling overhead. The ID may be assigned either by the manufacturer or by the serving PLMN. The manufacturer-assigned ID corresponds to a pre-provisioned set of capabilities. In the case of the PLMN-assigned ID, assignment takes place in NAS signalling.