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.
A SL UE can be configured with DRX, in which case, PDCCH providing SL grants can be send to the UE only during its active time.
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.
Serving Cells of a MAC entity may be configured by RRC in two DRX groups with separate DRX parameters. When RRC does not configure a secondary DRX group, there is only one DRX group and all Serving Cells belong to that one DRX group. When two DRX groups are configured, each Serving Cell is uniquely assigned to either of the two groups. The DRX parameters that are separately configured for each DRX group are on-duration and inactivity-timer.
UE power saving in RRC_IDLE/RRC_INACTIVE may be achieved by providing the configuration for TRS with CSI-RS for tracking in TRS occasions. The TRS in TRS occasions may allow UEs in RRC_IDLE/RRC_INACTIVE to sleep longer before waking-up for its paging occasion. The TRS occasions configuration is provided in SIB17. The availability of TRS in the TRS occasions is indicated by L1 availability indication. These TRSs may also be used by the UEs configured with eDRX.
UE power saving may be achieved by UE relaxing measurements for RLM/BFD. When configured, UE determines whether it is in low mobility state and/or whether its serving cell radio link quality is better than a threshold. The configuration for low mobility and good serving cell quality criterion is provided through dedicated RRC signalling.
RLM and BFD relaxation may be enabled/disabled separately through RRC Configuration. Additionally, RLM relaxation may be enabled/disabled on per Cell Group basis while BFD relaxation may be enabled/disabled on per serving cell basis.
The UE is only allowed to perform RLM and/or BFD relaxation when relaxed measurement criterion for low mobility and/or for good serving cell quality is met. If configured to do so, the UE shall trigger reporting of its RLM and/or BFD relaxation status through UE assistance information if the UE changes its respective RLM and/or BFD relaxation status while meeting the UE minimum requirements specified in TS 38.133.
UE power saving may also be achieved through PDCCH monitoring adaptation mechanisms when configured by the network, including skipping of PDCCH monitoring and Search space set group (SSSG) switching. In this case UE does not monitor PDCCH during the PDCCH skipping duration except for the cases as specified in TS 38.213, or monitors PDCCH according to the search space sets applied in SSSG.
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 and IAB-MT in SA mode, 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. 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):
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:
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.
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.
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).
The UE capabilities in NR rely on a hierarchical structure where each capability parameter is defined per UE, per duplex mode (FDD/TDD), per frequency range (FR1/FR2), per band, per band combinations, … as the UE may support different functionalities depending on those (see TS 38.306).
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 peak data rate for a given set of aggregated carriers in a band or band combination is the sum of the peak data rates of each individual carrier in that band or band combination, where the peak data rate of each individual carrier is computed according to the capabilities supported for that carrier in the corresponding band or band combination.
For each block of contiguous serving cells in a band, the set of features supported thereon is defined in a Feature Set (FS). The UE may indicate several Feature Sets for a band (also known as feature sets per band) to advertise different alternative features for the associated block of contiguous serving cells in that band. The two-dimensional matrix of feature sets for all the bands of a band combination (i.e. all the feature sets per band) is referred to as a feature set combination. In a feature set combination, the number of feature sets per band is equal to the number of band entries in the corresponding band combination, and all feature sets per band have the same number of feature sets. Each band combination is linked to one feature set combination. This is depicted on Figure 14-1 below:
In addition, for some features in intra-band contiguous CA, the UE reports its capabilities individually per carrier. Those capability parameters are sent in feature set per component carrier and they are signalled in the corresponding FSs (per Band) i.e. for the corresponding block of contiguous serving cells in a band. The capability applied to each individual carrier in a block is agnostic to the order in which they are signalled in the corresponding FS.
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.
The AMF stores the UE Radio Capability uploaded by the gNB as specified in TS 23.501.
The gNB can request the UE capabilities for RAT-Types NR, EUTRA, UTRA-FDD. The UTRAN capabilities, i.e. the INTER RAT HANDOVER INFO, include START-CS, START-PS and "predefined configurations", which are "dynamic" IEs. In order to avoid the START values desynchronisation and the key replaying issue, the gNB always requests the UE UTRA-FDD capabilities before handover to UTRA-FDD. The gNB does not upload the UE UTRA-FDD capabilities to the AMF.