Section: 6.16.2.3 Connection Resume in CM-IDLE with Suspend to a new ng-eNB
Content: 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[ Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification ]  [69] 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. NOTE: UP security policy is only applicable for UP ciphering as UP integrity protection is not supported.