Content for  TS 38.331  Word version:  18.0.0

RRC connection establishment involves the establishment of SRB1. The network completes RRC connection establishment prior to completing the establishment of the NG connection, i.e. prior to receiving the UE context information from the 5GC. Consequently, AS security is not activated during the initial phase of the RRC connection. During this initial phase of the RRC connection, the network may configure the UE to perform measurement reporting, but the UE only sends the corresponding measurement reports after successful AS security activation. However, the UE only accepts a re-configuration with sync message when AS security has been activated. Upon receiving the UE context from the 5GC, the RAN activates AS security (both ciphering and integrity protection) using the initial AS security activation procedure. The RRC messages to activate AS security (command and successful response) are integrity protected, while ciphering is started only after completion of the procedure. That is, the response to the message used to activate AS security is not ciphered, while the subsequent messages (e.g. used to establish SRB2, DRBs and multicast MRBs) are both integrity protected and ciphered. After having initiated the initial AS security activation procedure, the network may initiate the establishment of SRB2 and DRBs and/or multicast MRBs, i.e. the network may do this prior to receiving the confirmation of the initial AS security activation from the UE. In any case, the network will apply both ciphering and integrity protection for the RRC reconfiguration messages used to establish SRB2, DRBs and/or multicast MRBs. The network should release the RRC connection if the initial AS security activation and/ or the radio bearer establishment fails. A configuration with SRB2 without DRB or multicast MRB, or with DRB or multicast MRB without SRB2 is not supported (i.e., SRB2 and at least one DRB or multicast MRB must be configured in the same RRC Reconfiguration message, and it is not allowed to release all the DRBs and multicast MRBs without releasing the RRC Connection). For IAB-MT and NCR-MT, a configuration with SRB2 without any DRB/MRB is supported. The release of the RRC connection normally is initiated by the network. The procedure may be used to re-direct the UE to an NR frequency or an E-UTRA carrier frequency. The suspension of the RRC connection is initiated by the network. When the RRC connection is suspended, the UE stores the UE Inactive AS context and any configuration received from the network, and transits to RRC_INACTIVE state. The RRC message to suspend the RRC connection is integrity protected and ciphered. The resumption of a suspended RRC connection is initiated by upper layers when the UE needs to transit from RRC_INACTIVE state to RRC_CONNECTED state or by RRC layer to perform a RNA update or by RAN paging from NG-RAN or for SDT. When the RRC connection is resumed, network configures the UE according to the RRC connection resume procedure based on the stored UE Inactive AS context and any RRC configuration received from the network. The RRC connection resume procedure re-activates AS security and re-establishes SRB(s) and DRB(s) and/or multicast MRB(s), if configured. Upon initiating the resume procedure for SDT, AS security (both ciphering and integrity protection) is re-activated for SRB2 (if configured for SDT) and for SRB1. In addition, AS security is also re-activated (if security is configured) for all the DRBs configured for SDT. Further, the PDCP entities of SRB1 and PDCP entities of the radio bearers configured for SDT are re-established and resumed whilst the UE remains in RRC_INACTIVE state. Transmission and reception of data and/or signalling messages over radio bearers configured for SDT can happen whilst the UE is in RRC_INACTIVE state and SDT procedure is ongoing. In response to a request to resume the RRC connection or in response to a resume procedure initiated for SDT, the network may resume the suspended RRC connection and send UE to RRC_CONNECTED, or reject the request to resume and send UE to RRC_INACTIVE (with a wait timer), or directly re-suspend the RRC connection and send UE to RRC_INACTIVE, or directly release the RRC connection and send UE to RRC_IDLE, or instruct the UE to initiate NAS level recovery (in this case the network sends an RRC setup message).

AS security comprises of the integrity protection and ciphering of RRC signalling (SRBs) and user data (DRBs). RRC handles the configuration of the AS security parameters which are part of the AS configuration: the integrity protection algorithm, the ciphering algorithm, if integrity protection and/or ciphering is enabled for a DRB and two parameters, namely the keySetChangeIndicator and the nextHopChainingCount, which are used by the UE to determine the AS security keys upon reconfiguration with sync (with key change), connection re-establishment and/or connection resume. The integrity protection algorithm is common for SRB1, SRB2, SRB3 (if configured), SRB4 (if configured), SRB5 (if configured) and DRBs configured with integrity protection, with the same keyToUse value. The ciphering algorithm is common for SRB1, SRB2, SRB3 (if configured), SRB4 (if configured), SRB5 (if configured) and DRBs configured with the same keyToUse value. Neither integrity protection nor ciphering applies for SRB0. RRC integrity protection and ciphering are always activated together, i.e. in one message/procedure. RRC integrity protection and ciphering for SRBs are never de-activated. However, it is possible to switch to a 'NULL' ciphering algorithm (nea0). The 'NULL' integrity protection algorithm (nia0) is used only for SRBs and for the UE in limited service mode, see TS 33.501 and when used for SRBs, integrity protection is disabled for DRBs. In case the 'NULL' integrity protection algorithm is used, 'NULL' ciphering algorithm is also used. The AS applies four different security keys: one for the integrity protection of RRC signalling (KRRCint), one for the ciphering of RRC signalling (KRRCenc), one for integrity protection of user data (KUPint) and one for the ciphering of user data (KUPenc). All four AS keys are derived from the KgNB key. The KgNB key is based on the KAMF key (as specified in TS 33.501), which is handled by upper layers. The integrity protection and ciphering algorithms can only be changed with reconfiguration with sync. The AS keys (KgNB, KRRCint, KRRCenc, KUPint and KUPenc) change upon reconfiguration with sync (if masterKeyUpdate is included), and upon connection re-establishment and connection resume. For each radio bearer an independent counter (COUNT, as specified in TS 38.323) is maintained for each direction. For each radio bearer, the COUNT is used as input for ciphering and integrity protection. It is not allowed to use the same COUNT value more than once for a given security key. As specified in clause 6.9.4.1 of TS 33.501, the network is responsible for avoiding reuse of the COUNT with the same RB identity and with the same key, e.g. due to the transfer of large volumes of data, release and establishment of new RBs, and multiple termination point changes for RLC-UM bearers and multiple termination point changes for RLC-AM bearer with SN terminated PDCP re-establishment (COUNT reset) due to SN only full configuration whilst the key stream inputs (i.e. bearer ID, security key) at MN have not been updated. In order to avoid such re-use, the network may e.g. use different RB identities for RB establishments, change the AS security key, or an RRC_CONNECTED to RRC_IDLE/RRC_INACTIVE and then to RRC_CONNECTED transition. In order to limit the signalling overhead, individual messages/ packets include a short sequence number (PDCP SN, as specified in TS 38.323). In addition, an overflow counter mechanism is used: the hyper frame number (HFN, as specified in TS 38.323). The HFN needs to be synchronized between the UE and the network. For each SRB, the value provided by RRC to lower layers to derive the 5-bit BEARER parameter used as input for ciphering and for integrity protection is the value of the corresponding srb-Identity with the MSBs padded with zeroes. For a UE provided with an sk-counter, keyToUse indicates whether the UE uses the master key (KgNB) or the secondary key (S-KeNB or S-KgNB) for a particular DRB. The secondary key is derived from the master key and sk-Counter, as defined in TS 33.501. Whenever there is a need to refresh the secondary key, e.g. upon change of MN with KgNB change or to avoid COUNT reuse, the security key update is used (see clause 5.3.5.7). When the UE is in NR-DC, the network may provide a UE configured with an SCG with an sk-Counter even when no DRB is setup using the secondary key (S-KgNB) in order to allow the configuration of SRB3. The network can also provide the UE with an sk-Counter, even if no SCG is configured, when using SN terminated MCG bearers.

The purpose of this procedure is:

• to transmit paging information to a UE in RRC_IDLE or RRC_INACTIVE.
• to transmit paging information for a L2 U2N Remote UE in RRC_IDLE or RRC_INACTIVE to its serving L2 U2N Relay UE in any RRC state.

The network initiates the paging procedure by transmitting the Paging message at the UE's paging occasion as specified in TS 38.304. The network may address multiple UEs within a Paging message by including one PagingRecord for each UE. The network may also include one or multiple TMGI(s) in the Paging message to page UEs for specific MBS multicast session(s).

Upon receiving the Paging message by the UE or receiving PagingRecord from its connected L2 U2N Relay UE by a L2 U2N Remote UE, the UE shall: