Content for  TS 33.501  Word version:  19.0.0

The Control Plane Optimisation for 5GS CIoT is used to exchange small user data or SMS as payload of a NAS message in both uplink and downlink directions. The UE and the AMF perform integrity protection and ciphering for the small user data or SMS using NAS security context specific to the NAS connection. If UE uses Control Plane optimisation for 5GS CIoT for Mobile Originated data transport, the UE sends a Control Plane Service Request message including a container for small user data or SMS transport. The Control Plane Service Request message shall be partially ciphered (i.e. the container including uplink user data or SMS is ciphered, and non-cleartext remains unciphered) and integrity protected by the current 5G NAS security context specific to the NAS connection if such exists as depicted in TS 24.501. Upon reception of the Control Plane Service Request message with the ciphered container for small user data or SMS transport, the AMF shall verify integrity of the whole Control Plane Service Request message and decipher the ciphered container to obtain the small user data or SMS. When applying NAS ciphering/deciphering mechanism for the container, the LENGTH value shall be set to the length of the container contents. Additionally, if UE uses Control Plane optimisation for 5GS CIoT for Mobile Originated data transport, the UE in CM-CONNECTED mode sends small user data or SMS in UL NAS transport message to the AMF. The UL NAS transport message shall be ciphered and integrity protected with the current 5G NAS security context specific to the NAS connection. Upon reception of the UL NAS transport message for small user data or SMS transport, the AMF shall verify integrity and decipher the UL NAS transport message to obtain the small user data or SMS. If UE uses Control Plane optimisation for 5GS CIoT for Mobile Terminated data transport, the UE obtains small user data or SMS in DL NAS transport message from the AMF. The DL NAS transport message shall be ciphered and integrity protected with the current 5G NAS security context specific to the NAS connection. Upon reception of the DL NAS transport message for small user data or SMS transport, the UE shall verify integrity and decipher the DL NAS transport message to obtain the small user data or SMS.

If the UE experience a RLF when using Control Plane CIoT 5GS optimisation only, the AS layer of the UE may trigger an RRCConnectionReestablishment procedure. As there is no AS security available, this procedure can not be protected as described in subclause 6.11. In order to protect the the re-establishment procedure, the AS part of the UE triggers the NAS part of the UE to provide the UL_NAS_MAC and XDL_NAS_MAC. These parameter are used to show that the UE is requesting the re-establishment and that the UE is talking to a genuine network respectively. The UE calculates a UL_NAS_MAC and XDL_NAS_MAC by using the curently used NAS integrity algorithm with the following inputs, KNASint as the key, the uplink NAS COUNT that would be used for the next uplink NAS message, the DIRECTION bit set to 0 and the target Cell-ID as the message to be protected to calculate NAS-MAC (see Annex D.3.1). The uplink NAS COUNT is increased by the UE in exactly the same way as if it had sent a NAS message. The first 16 bits of NAS-MAC form UL_NAS_MAC and the last 16 bits form XDL_NAS_MAC, which is stored by the UE. The UE shall send the RRCConnectionRestablishmentRequest message to the target ng-eNB and shall include the Truncated 5G-S-TMSI (as described in TS 23.501, TS 23.003 and TS 36.331), the 5 least significant bits (LSB) of the NAS COUNT that was used to calculate NAS-MAC and UL_NAS_MAC in the message. The target ng-eNB recognises the RRCConnectionRestablishmentRequest message sent by a UE relates to the Control Plane CIoT 5GS optimisation based on the presence of the Truncated 5G-S-TMSI in the message. The target ng-eNB shall recreate the 5G-S-TMSI from the Truncated 5G-S-TMSI (as described in TS 23.501, TS 23.003 and TS 36.331). The target ng-eNB shall send the 5G-S-TMSI, LSB of NAS COUNT, UL_NAS_MAC and target Cell-ID in the CP Relocation Indication message to the AMF that is serving the UE (this can be deteremined by the S-TMSI). The AMF uses LSB of NAS COUNT to estimate the full uplink NAS COUNT and calculates XNAS-MAC (see Annex D.3.1) using the same inputs (i.e. estimated uplink NAS COUNT, DIRECTION bit set to 0 and the target Cell-ID as the message) as the UE used for calculating NAS-MAC. The AMF then compares the received UL_NAS_MAC with the first 16 bits of XNAS-MAC and if these are equal the network is sure that the geniune UE sent the RRCConnectionRestablishmentRequest message. The stored uplink NAS COUNT in the AMF is set as though the AMF received a sucessfully protected NAS message using that NAS COUNT. The AMF shall set DL_NAS_MAC to the last 16 bits of already calculated XNAS-MAC and send DL_NAS_MAC to the target ng-eNB in the Connection Establishment Indication message. The target ng-eNB shall send the DL_NAS_MAC to the UE in the RRCConnectionReestablisment message. The UE shall check that the received DL_NAS_MAC equal to the stored XDL_NAS_MAC. If so, the UE shall complete the re-establishment procedure.

The purpose of this procedure is to allow the ng-eNB to suspend an RRC connection to be resumed by the UE using User Plane CIoT 5GS Optimisation at a later time. The UE may resume the RRC connection in the same or different ng-eNB where the suspend took place. The UE and ng-eNB store the AS security context at suspend and reactivate the AS security context at resume. The UE and the ng-eNB may also use EDT (Early Data Transmission) or PUR (Preconfigured Uplink Resource) feature in this procedure, as defined in TS 36.300 and TS 36.331.

When the ng-eNB initiates the Connection Suspend procedure, it sends N2 Suspend Request message to the AMF. Upon reception of the N2 Suspend Request message, the AMF shall check its local policy. If the local policy indicates that a new NH derivation is needed, the AMF shall increase its locally kept NCC value by one and compute a fresh NH from its stored data using the function defined in Annex A.10. The AMF shall store that fresh {NH, NCC} pair and send it to the ng-eNB in the N2 Suspend Response message. Upon receipt of the N2 Suspend Response message from the AMF and if the message includes a {NH, NCC} pair, the ng-eNB shall store the fresh {NH, NCC} pair in the N2 Suspend Response message and remove any existing unused stored {NH, NCC} pairs. The ng-eNB shall send to the UE an RRC Release with releaseCause set to rrc-suspend message that is ciphered and integrity protected in PDCP layer using current AS security context. The ng-eNB shall include a fresh I-RNTI, and an NCC in that RRC Release message. The I-RNTI is used for context identification, and the UE ID part of the I-RNTI assigned by the ng-eNB shall be different in consecutive suspends of the same UE. This is to avoid tracking of UEs based on the I-RNTI. If the ng-eNB has a fresh and unused pair of {NCC, NH}, the ng-eNB shall include the NCC in the RRC Release message. Otherwise, the ng-eNB shall include the same NCC associated with the current KgNB in the RRC Release message. The NCC is used for AS security. The ng-eNB shall delete the current AS keys KRRCenc, KUPenc (if available), and KUPint (if available) after sending the RRC Release message to the UE, but shall keep the current AS key KRRCint. If the sent NCC value is fresh and belongs to an unused pair of {NCC, NH}, the ng-eNB shall save the pair of {NCC, NH} in the current UE AS security context and shall delete the current AS key KgNB. If the sent NCC value is equal to the NCC value associated with the current KgNB, the ng-eNB shall keep the current AS key KgNB and NCC. The ng-eNB shall store the sent I-RNTI together with the current UE context including the remainder of the AS security context. Upon receiving the RRC Release with releaseCause set to rrc-suspend message from the ng-eNB, the UE shall decrypt the RRC Release message using the KRRCenc key and verify that the integrity of the received the RRC Release message is correct by checking the PDCP MAC-I. If this verification is successful, then the UE shall take the received NCC value and save it as stored NCC with the current UE context.

When the UE using user plane CIoT 5GS Optimization decides to resume the RRC connection in CM-IDLE with suspend, the UE sends the RRC Resume Request message on SRB0 (i.e. it is not integrity protected). The UE shall include I-RNTI and a ShortResumeMAC-I in RRC Resume Request message. The I-RNTI is used for context identification and its value shall be the same as the I-RNTI that the UE had received from the source ng-eNB in the RRC Release with releaseCause set to rrc-suspend message in the source cell. The ShortResumeMAC-I is a 16-bit message authentication token, the UE shall calculate it using the integrity algorithm (EIA) in the stored AS security context, which was negotiated between the UE and the source ng-eNB and the current KRRCint with the following inputs:

• KEY: it shall be set to current KRRCint;
• BEARER: all its bits shall be set to 1.
• DIRECTION: its bit shall be set to 1;
• COUNT: all its bits shall be set to 1;
• MESSAGE: it shall be set to VarShortResumeMAC-Input as defined in TS 36.331 for ng-eNB with the following inputs:
  source C-RNTI, source PCI, resume constant, target Cell-ID.

The source PCI and source C-RNTI are associated with the cell where the UE was suspended. The target Cell-ID is the identity of the target cell where the UE sends the RRC Resume Request message. The resume constant allows differentiation of VarShortResumeMAC from VarShortMAC. For protection of all RRC messages except RRC Reject message following the sent RRC Resume Request message, the UE shall derive a KNG-RAN* using the target PCI, target EARFCN-DL and the KgNB/NH based on either a horizontal key derivation or a vertical key derivation as defined in clause 6.9.2.1.1 and Annex A.12. The UE shall further derive KRRCint, KRRCenc, KUPenc (optionally), and KUPint (optionally) from the newly derived KNG-RAN*. Then the UE resets all PDCP COUNTs to 0 and activates the new AS keys in PDCP layer. When the target ng-eNB receives the RRC Resume Request message from the UE, the target ng-eNB extracts the I-RNTI from the RRC Resume Request message. The target ng-eNB contacts the source ng-eNB based on the information in the I-RNTI by sending an Xn-AP Retrieve UE Context Request message with the following included: I-RNTI, ShortResumeMAC-I and target Cell-ID, in order to allow the source ng-eNB to validate the UE request and to retrieve the UE context including the UE 5G AS security context. The source ng-eNB retrieves the stored UE context including the UE 5G AS security context from its database using the I-RNTI. The source ng-eNB verifies the shortResumeMAC-I using the current KRRCint key stored in the retrieved UE 5G AS security context (calculating the shortResumeMAC-I in the same way as described above). If the verification of the shortResumeMAC-I is successful, then the source ng-eNB calculates KNG-RAN* using the target cell PCI, target EARFCN-DL and the KgNB/NH in the current UE 5G AS security context based on either a horizontal key derivation or a vertical key derivation according to whether the source ng-eNB has an unused pair of {NCC, NH} as described in Annex A.12. The source ng-eNB can obtain the target PCI and target EARFCN-DL from a cell configuration database by means of the target Cell-ID which was received from the target ng-eNB. Then the source ng-eNB shall respond with an Xn-AP Retrieve UE Context Response message to the target ng-eNB including the UE context that contains the UE 5G AS security context. The UE 5G AS security context sent to the target ng-eNB shall include the newly derived KNG-RAN*, the NCC associated to the KNG-RAN*, the UE EPS security capabilities, UP security policy, the UP security activation status, and the ciphering and integrity algorithms used by the UE with the source cell. The target ng-eNB shall check if it supports the ciphering and integrity algorithms the UE used with the last source cell. If the target ng-eNB does not support the ciphering and integrity algorithms used in the last source cell or if the target ng-eNB prefers to use different algorithms than the source ng-eNB, then the target ng-eNB shall send an RRC Setup message on SRB0 to the UE in order to proceed with RRC connection establishment as if the UE was in RRC_IDLE (i.e., a fallback procedure). If the target ng-eNB supports the ciphering and integrity algorithms used with the last source cell and these algorithms are the chosen algorithms by the target ng-eNB, the target ng-eNB shall derive new AS keys (RRC integrity key, RRC encryption key and UP keys) using the algorithms the UE used with the source cell and the received KNG-RAN*. The target ng-eNB shall reset all PDCP COUNTs to 0 and activate the new keys in PDCP layer. The target ng-eNB shall respond to the UE with an RRC Resume message on SRB1 which is integrity protected and ciphered in PDCP layer using the new RRC keys. If the UP security activation status can be supported in the target ng-eNB, the target ng-eNB shall use the UP security activations that the UE used at the last source cell. When the UE receives the RRC Resume message, the UE shall decrypt the message using the KRRCenc that was derived based on the newly derived KNG-RAN*. The UE shall also verify the RRC Resume message by verifying the PDCP MAC-I using the KRRCint that was derived from the newly derived KNG-RAN* If verification of the RRC Resume message is successful, the UE shall delete the current KRRCint key and the UE shall save the KRRCint, KRRCenc, KUPenc (optionally), and KUPint (optionally) from the newly derived KNG-RAN* as part of the UE current AS security context. In this case, the UE shall send the RRC Resume Complete message both integrity protected and ciphered to the target ng-eNB on SRB1 using the current KRRCint and KRRCenc. The UE shall use the UP security activations status to protect the UP data. If the UE receives RRC Reject message from the target ng-eNB in response to the RRC Resume Request message, the UE shall delete newly derived AS keys used for connection resumption attempt, including newly derived KNG-RAN*, newly derived RRC integrity key, RRC encryption key and UP keys, and keep the current KRRCint and the KgNB/NH in its current AS context. In that case, for the next resume to any target ng-eNB, the UE shall start with the same AS security context as it had when it was suspended originally, i.e., same KgNB/NH shall act as base key for derivation of new KNG-RAN*. After a successful resume, the target ng-eNB shall perform Path Switch procedure with the AMF as is done in case of X2-handover. The AMF shall verify the UE security capability as described in the clause 6.7.3.1, and the SMF shall verify the UE's UP security policy as described in the clause 6.6.1. When EDT or PUR feature is used, the UE shall use newly derived KUPenc to encrypt the UL UP data according to the UP security activations before transmitting the RRC Resume Request message, and send the encrypted UL UP data in the PDCP layer with RRC Resume Request message to the target ng-eNB. The target ng-eNB shall use newly derived KUPenc key to get the UL UP data according to the UP security activations after retrieving UE context from the source ng-eNB. The UE and the target eNB shall use the same KUPenc key and UP security activation to protect the DL data (if included) in PDCP layer in the RRC Release or RRC Resume message.

The target ng-eNB may be the same as the source ng-eNB in the description in the previous subclause. If so the single ng-eNB performs the roles of both the source and target ng-eNB. In particular, a new KNG-RAN* shall be derived even if the UE is resuming to the same cell from where it was suspended. However, there is the following difference. After a successful resume, the ng-eNB shall send N2 Resume Request message to the AMF. Upon reception of the N2 Resume Request message, the AMF shall check its local policy. If the local policy in the AMF indicates that a new NH derivation is needed, the AMF shall increase its locally kept NCC value by one and compute a fresh NH from its stored data using the function defined in Annex A.10. The AMF shall store that fresh pair and send it to the ng-eNB in the N2 Resume Response message. Upon receipt of the N2 Resume Response message from the AMF and if the message includes a {NH, NCC} pair, the ng-eNB shall store the {NH, NCC} pair in the N2 Resume Response message and remove any existing unused stored {NH, NCC} pairs. The {NH, NCC} pair may be used in the next suspend/resume or Xn handover procedures.