Content for TS 33.501 Word version: 19.0.0

1… 4… 5… 5.3… 5.9… 5.10… 6… 6.1.3… 6.1.4… 6.2… 6.2.2… 6.3… 6.4… 6.5… 6.6… 6.7… 6.8… 6.9… 6.10… 6.11 6.12… 6.13 6.14… 6.15… 6.16… 7… 7A… 7A.2.3… 7B… 8… 9… 10… 11… 12… 13… 13.2.2… 13.2.4… 13.3… 13.4… 14… 15… 16… A… B… C… D… E… F… G… I… I.9… J… K… M… N… O… P… R S… T… U… V… W… X… Y… Z…

6.10 Dual connectivity 6.10.1 Introduction 6.10.1.1 General 6.10.1.2 Dual Connectivity protocol architecture for MR-DC with 5GC 6.10.2 Security mechanisms and procedures for DC 6.10.2.1 SN Addition or modification 6.10.2.2 Secondary Node key update 6.10.2.2.1 General 6.10.2.2.2 MN initiated 6.10.2.2.3 SN initiated 6.10.2.3 SN release and change 6.10.2.4 Security mechanism and procedures for SCPAC 6.10.2.4.1 General 6.10.2.4.2 Security context initialization for selective SCPAC 6.10.2.4.3 Security mechanism for UE to access target PSCell or SN 6.10.2.4.4 Security procedure for UE to access target PSCell or SN 6.10.3 Establishing the security context between the UE and SN 6.10.3.1 SN Counter maintenance 6.10.3.2 Derivation of keys 6.10.3.3 Negotiation of security algorithms 6.10.4 Protection of traffic between UE and SN 6.10.5 Handover Procedure 6.10.6 Signalling procedure for PDCP COUNT check 6.10.7 Radio link failure recovery
...

This clause describes the security functions necessary to support a UE that is simultaneously connected to more than one NG-RAN node, i.e., Multi-Radio dual connectivity (MR-DC) with 5GC as described in TS 37.340. The security functions are described in the context of the functions controlling the dual connectivity.

6.10.1.2 Dual Connectivity protocol architecture for MR-DC with 5GC p. 102

The dual connectivity protocol architecture for MR-DC with 5GC is shown in Figure 6.10.1.2-1. The TS 37.340 is to be referred for further details of the architecture illustrating MCG, SCG, and Split bearers for both SRBs and DRBs. The architecture has the following variants:

NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC) is the variant when the UE is connected to one ng-eNB that acts as a Master Node (MN) and one gNB that acts as a Secondary Node (SN). The ng-eNB is connected to the 5GC and the gNB is connected to the ng-eNB via Xn interface.
NR-E-UTRA Dual Connectivity (NE-DC) is the variant when the UE is connected to one gNB that acts as a MN and one ng-eNB that acts as a SN. The MN (i.e., gNB) is connected to 5GC and the ng-eNB (i.e., SN) is connected to the gNB via Xn interface.
NR-NR Dual Connectivity (NR-DC) is the variant when the UE is connected to one gNB that acts as a MN and one gNB that acts as a SN. The MN is connected to 5GC while the SN is connected to MN via Xn interface.

Reproduction of 3GPP TS 33.501, Fig. 6.10.1.2-1: Multi-Radio dual connectivity (MR-DC) protocol architecture.

Figure 6.10.1.2-1: Multi-Radio dual connectivity (MR-DC) protocol architecture.

When the MN establishes security context between an SN and the UE for the first time for a given AS security context shared between the MN and the UE, the MN generates the KSN for the SN and sends it to the SN over the Xn-C. To generate the KSN, the MN associates a counter, called an SN Counter, with the current AS security context. The SN Counter is used as freshness input into KSN derivations as described in the clause 6.10.3.2. The MN sends the value of the SN Counter to the UE over the RRC signalling path when it is required to generate a new KSN. The KSN is used to derive further RRC and UP keys that are used between the UE and SN.

6.10.2 Security mechanisms and procedures for DC p. 103

6.10.2.1 SN Addition or modification p. 103

When the MN is executing the Secondary Node Addition procedure (i.e. initial offload of one or more radio bearers to the SN), or the Secondary Node Modification procedure (as in clauses 10.2.2 and 10.3.2 in TS 37.340) which requires an update of the KSN, the MN shall derive an KSN as defined in clause 6.10.3.2. The MN shall maintain the SN Counter as defined in clause 6.10.3.1. In the case of Conditional PSCell Change and conditional PSCell addition as specified in TS 37.340, if there are more than one candidate SNs, for each SN, the MN shall derive a different KSN via using different SN counter as defined in clause 6.10.3.2.

When executing the procedure for adding subsequent radio bearer(s) to the same SN, the MN shall, for each new radio bearer, assign a radio bearer identity that has not previously been used since the last KSN change. If the MN cannot allocate an unused radio bearer identity for a new radio bearer in the SN, due to radio bearer identity space exhaustion, the MN shall increment the SN Counter and compute a fresh KSN, and then shall perform a SN Modification procedure to update the KSN.

The dual connectivity procedure with activation of encryption/decryption and integrity protection follows the steps outlined on the Figure 6.10.2.1-1.

Reproduction of 3GPP TS 33.501, Fig. 6.10.2.1-1: Security aspects in SN Addition/Modification procedures (MN initiated)

Figure 6.10.2.1-1: Security aspects in SN Addition/Modification procedures (MN initiated)

Step 1.

The UE and the MN establish the RRC connection.

Step 2.

The MN sends SN Addition/Modification Request to the SN over the Xn-C to negotiate the available resources, configuration, and algorithms at the SN. The MN computes and delivers the KSN to the SN if a new key is needed. The UE security capabilities (see subclause 6.10.4) and the UP security policy received from the SMF shall also be sent to SN. In case of PDU split, UP integrity protection and ciphering activation decision from MN may be also included as described in subclause 6.10.4.

When the MN decides to configure CPA or CPC, if there are more than one candidate SNs, for each SN, the MN shall derive a different KSN and delivers the KSN to each SN seperately..

Step 3.

The SN allocates the necessary resources and chooses the ciphering algorithm and integrity algorithm which has the highest priority from its configured list and is also present in the UE security capability. If a new KSN was delivered to the SN then the SN calculates the needed RRC. The UP keys may be derived at the same time when RRC key derived. The SN shall activate the UP security policy as described in subclause 6.10.4.

Step 4.

The SN sends SN Addition/Modification Acknowledge to the MN indicating availability of requested resources and the identifiers for the selected algorithm(s) for the requested DRBs and/or SRB for the UE. The UP integrity protection and encryption indications shall be send to the MN.

Step 5.

The MN sends the RRC Connection Reconfiguration Request to the UE instructing it to configure the new DRBs and/or SRB for the SN. The MN shall include the SN Counter parameter to indicate a new KSN is needed and the UE shall compute the KSN for the SN. The MN forwards the UE configuration parameters (which contains the algorithm identifier(s) received from the SN in step 4) , and UP integrity protection and encryption indications(received from the SN in step 4) to the UE (see subclause 6.10.3.3 for further details).

If an SN sends more than one candidate PScell SCG configuration, the MN signals to the UE that all these configurations are associated with the same SN counter value.

Step 6.

The UE accepts the RRC Connection Reconfiguration Request after validating its integrity. The UE shall compute the KSN for the SN if an SN Counter parameter was included. The UE shall also compute the needed RRC and UP keys and activate the RRC and UP protection as per the indications received for the associated SRB and/or DRBs respectively. The UE sends the RRC Reconfiguration Complete to the MN. The UE activates the chosen encryption/decryption and integrity protection keys with the SN at this point.

Step 7.

MN sends SN Reconfiguration Complete to the SN over the Xn-C to inform the SN of the configuration result. On receipt of this message, SN may activate the chosen encryption/decryption and integrity protection with UE. If SN does not activate encryption/decryption and integrity protection with the UE at this stage, SN shall activate encryption/decryption and integrity protection upon receiving the Random Access request from the UE.

6.10.2.2 Secondary Node key update p. 105

6.10.2.2.1 General p. 105

The SN shall request the Master Node to update the KSN over the Xn-C, when uplink and/or downlink PDCP COUNTs are about to wrap around for any of the SCG DRBs or SCG SRB.

If the Master Node re-keys its currently active AS key in an 5G AS security context the Master Node shall update any KSN associated with that 5G AS security context.

Whenever the UE or SN start using a fresh KSN, they shall re-calculate the RRC and UP keys from the fresh KSN.

6.10.2.2.2 MN initiated p. 105

The Master Node may update the KSN for any reason. If the MN decides to update the KSN, the MN shall perform a SN modification procedure to deliver the fresh KSN to the SN as defined in clause 6.10.2.1. The MN shall provide the value of the SN Counter used in the derivation of the KSN to the UE in an integrity protected RRC Connection Reconfiguration procedure. The UE shall derive the KSN as described in clause A.16.

6.10.2.2.3 SN initiated p. 105

When uplink and/or downlink PDCP COUNTs are about to wrap around for any of the SCG DRBs or SCG SRB, the SN shall request the MN to update the KSN over the Xn-C using the SN Modification procedure with MN involvement. The SN shall send the SN Modification Required message including KSN key update an indication to the MN as shown in Figure 6.10.2.2.3-1. When the MN receives KSN Key update indication, the MN shall derive a fresh KSN and send the derived KSN to the SN in the SN Modification Request message as in clause 6.10.2.1. Rest of the flows are like the call flow in Clause 6.10.2.1.

Reproduction of 3GPP TS 33.501, Fig. 6.10.2.2.3-1: SN Key update procedure using SN Modification procedure (SN initiated with MN involvement)

Figure 6.10.2.2.3-1: SN Key update procedure using SN Modification procedure (SN initiated with MN involvement)

6.10.2.3 SN release and change p. 105

When the SN releases the last UE radio bearer on the SN or when the SN is changed, i.e., the UE radio bearer(s) is moved from the SN, the SN and the UE shall delete the SN RRC and UP keys. The SN and UE shall also delete the KSN, if it was not deleted earlier.

6.10.2.4 Security mechanism and procedures for SCPAC |R18| p. 105

6.10.2.4.1 General p. 105

In subsequent CPAC (SCPAC), the MN may provide one or several candidate SCG configuration(s) for one or multiple candidate SN(s) to the UE. The UE may select and execute precisely one of these conditional reconfigurations to change PSCell based on the measurement results on candidate target PSCells. The conditional reconfiguration for the selected PScell remains valid after the UE selects the target and executes the target cell access procedure. Thus, the UE can connect to the same SN several times without any further reconfiguration by the network.

6.10.2.4.2 Security context initialization for selective SCPAC p. 106

To prevent key-stream reuse when the UE switches back and forth to the same PSCell or SN, the MN shall assign a sequence of distinct SN Counter values (maintained for dual connectivity detailed in clause 6.10.3.1 of this document) per candidate SN during the SCPAC procedure. The same SN Counter as used for DC shall be used to generate the keys also for SCPAC and the MN shall ensure that no generated SN Counter value will accidentally be used to derive a KSN more than once. Each SN Counter value is unique, and the sequences (i.e. sequences of SN Counter values of candidate SNs) are non-overlapping. These sequence s shall be provided to the UE by the MN. The UE shall store these sequences.

The MN shall derive the KSN keys corresponding to the SN Counter values from the KgNB of the UE as described in Annex A.16. The MN shall send the KSN keys associated with the SN together with their corresponding SN Counter values to that SN in the SN Addition Request. The SN shall store the received KSN keys and the SN Counter values of the UE. The MN shall maintain the largest assigned SN Counter value and monotonically increment it either for the next KSN calculation for DC as described in clause 6.10.3.1 of this document or for further assignment for the SCPAC detailed in this clause.

When a new AS root key, KgNB, in the associated 5G AS security context of the UE is established, and the SN Counter is set to '0' as specified in clause 6.10.3.1, the MN derives a new sequence of distinct SN Counter values per candidate SN and sends these to the UE in the same RRC Reconfiguration as the one that activates the new KNG-RAN. The UE shall delete the stored SN Counter value sequences and store the received new SN Counter values. Further, the MN derives the corresponding KSN for each target SN, and the derived KSN keys and the corresponding SN Counter values are sent to the SN from the MN. Each SN shall delete the stored KSNs and corresponding SN Counter values and store the received new KSNs and the corresponding SN Counter values.

6.10.2.4.3 Security mechanism for UE to access target PSCell or SN p. 106

A UE can access a SN, disconnect to it and then access it again. Regardless of whether the UE has accessed the SN earlier, the UE shall select the first unused SN Counter value in the sequence of SN Counter values (i.e. sequence per SN) associated with the SN. Because all counter values are distinct, selecting the first unused one ensures that it is not previously used with the current KgNB. The UE shall then derive the corresponding KSN using the SN Counter value as described in Annex A.16 of this document and shall initiate the access procedure.

In parallel, UE shall inform the SN Counter value utilized for KSN derivation in the RRC Connection Reconfiguration Complete to the MN. The MN, in turn, shall relay the SN Counter value to the SN in the SN Reconfiguration Complete message.

The protected UP messages may reach the SN before the SN has received the SN counter value in the SN Reconfiguration Complete message. In this scenario, the SN chooses the first unused KSN key of the UE to establish the security association with the UE.

The UE and the SN shall derive the user plane encryption key and user plane integrity protection key, when configured, from the KSN for protecting their communications. The SN, upon receiving the SN counter value from the UE via the MN, shall check whether the corresponding SN Counter value of the chosen KSN is the same as the received SN Counter value to determine the KSN mismatch. In case of KSN mismatch, after receiving the SN counter in the SN Reconfiguration Complete message, the SN, having stored the KSN keys and the corresponding SN counter values, selects the appropriate KSN based on the received SN Counter value for subsequent data access under the same reconfiguration.

6.10.2.4.4 Security procedure for UE to access target PSCell or SN p. 106

The SCPAC procedure in dual connectivity procedure with activation of encryption/decryption and/or integrity protection follows the steps outlined in Figure 6.10.2.4.4-1.

Reproduction of 3GPP TS 33.501, Fig. 6.10.2.4.4-1: Security procedures for SCPAC

Figure 6.10.2.4.4-1: Security procedures for SCPAC

Step 1.

The UE and the MN establishes the RRC connection.

Step 2a-b.

The MN sends SN Addition/Modification Request to each candidate target SN over the Xn-C to negotiate the available resources, configuration, and security algorithms at each candidate target SN. The MN assigns a sequence of distinct SN Counter values per candidate target SN during the SCPAC procedure. The MN derives the KSN keys corresponding to the sequence of SN Counter values from the KgNB of the UE. The MN delivers the sequence of SN Counter values and corresponding KSN keys of the UE to the respective candidate target SN. The UE security capabilities (see clause 6.10.2.1) and the UP security policy received from the SMF shall also be sent to SN. In case of PDU split, UP integrity protection and/or ciphering activation decision from MN may be also included as described in clause 6.10.2.1.

Step 3.

The candidate target SNs store the received sequence of SN Counter values and corresponding KSN keys of the UE and allocates the necessary resources and chooses the ciphering algorithm and integrity algorithm which has the highest priority from its configured list and is also present in the UE security capability as described in clause 6.10.2.1.

Step 4.

The respective target SN sends SN Addition/Modification Acknowledge to the MN indicating availability of requested resources and the identifiers for the selected algorithm(s) for the requested DRBs for the UE. The UP integrity protection and encryption indications shall be send to the MN.

Step 5.

The MN sends the RRC Reconfiguration Request to the UE, instructing it to configure the new DRBs for the selected target SNs.

The MN also includes all candidate SCG configuration(s) for one or multiple candidate SN(s) in the same RRC Reconfiguration Request message as the one that activates the new KgNB to the UE.

Step 6.

The UE accepts the RRC Reconfiguration Request after validating its integrity using the KRRCint of the MN.

Step 7.

When the UE selects a target SN, the UE shall choose the first unused SN Counter value in the SN Counter values sequence in the SCG configuration for the selected candidate target SN and compute the KSN. The UE shall also compute the needed UP keys and activate the UP protection per the indications received for the associated DRBs.

Step 8.

The UE sends the RRC Reconfiguration Complete to the MN, including the SN Counter value used in the derivation of the KSN.

Step 9.

The MN shall send the SN Reconfiguration Complete, including the SN Counter value received in step 8, to the target SN over the Xn-C to inform the target SN of the configuration result.

Step 10.

The SN shall activate encryption/decryption and integrity protection/verification with the UE upon receiving the SN Reconfiguration Complete message or the Random Access request from the UE.

If the SN activates the UP protection upon receiving the SN Reconfiguration Complete message, then the SN chooses the KSN key of the UE corresponding to the SN Counter value received in SN Reconfiguration Complete message and activates the UP protection after computing the needed UP keys.

Step 11.

In case the SN activates the UP protection upon receiving the Random Access request from the UE, then the target SN shall select the first unused KSN key of the UE in the sequence and computing the needed UP keys. Further, upon receiving the SN Reconfiguration Complete message, the SN shall determine the KSN mismatch as described in the clause 6.10.2.4.3. In case of KSN mismatch, the target SN chooses the KSN key of the UE corresponding to the SN Counter value received in SN Reconfiguration Complete message and activates the UP protection after computing the needed UP keys. The SN shall delete the configured KSN and corresponding SN counter value only after determining that there is no KSN key mismatch. The SN shall terminate the connection with the UE if the SN does not receive the SN Reconfiguration Complete message.

Even if a subsequent CPAC with a pre-configured list of SN Counter values already have been pre-configured in the UE and SN, the MN may run a CPAC procedure as described in TS 37.340 configuring a single SN counter value. This single SN Counter value shall be unique for the current KgNB and not have been configured in any earlier pre-configured list of SN Counter values for CPAC for the current KgNB or subsequent CPAC and shall not be added to any future list of SN Counter values for the current KgNB. The single SN Counter value does not impact the pre-configured list of SN Counter values. Further details are described in TS 37.340.

6.10.3 Establishing the security context between the UE and SN p. 108

6.10.3.1 SN Counter maintenance p. 108

The MN shall maintain a 16-bit counter, SN Counter, in its AS security context. The SN Counter is used when computing the KSN.

The MN maintains the value of the counter SN Counter for a duration of the current 5G AS security context between UE and MN. The UE does not need to maintain the SN Counter after it has computed the KSN since the MN provides the UE with the current SN Counter value when the UE needs to compute a new KSN.

The SN Counter is a fresh input to KSN derivation. That is, the UE assumes that the MN provides a fresh SN Counter each time and does not need to verify the freshness of the SN Counter.

The MN shall set the SN Counter to '0' when a new AS root key, KNG-RAN, in the associated 5G AS security context is established. The MN shall set the SN Counter to '1' after the first calculated KSN, and monotonically increment it for each additional calculated KSN. The SN Counter value '0' is used to calculate the first KSN.

If the MN decides to release the offloaded connections to the SN and later decides to re-start the offloading to the same SN, the SN Counter value shall keep increasing, thus keeping the computed KSN fresh.

The MN shall refresh the root key of the 5G AS security context associated with the SN Counter before the SN Counter wraps around. Refreshing the root key is done using intra cell handover as described in subclause 6.7.3.3 of the present document. When the root key is refreshed, the SN Counter is reset to '0' as defined above.

6.10.3.2 Derivation of keys p. 109

The UE and MN shall derive the security key KSN of the SN as defined in Annex A.16 of the present document.

The SN RRC and UP keys shall be derived from the KSN both at the SN and the UE using the function given in Annex A.7 of TS 33.401 if the SN is a ng-eNB or using the function given in Annex A.8 of the present specification if the SN is a gNB.

Once all the SN RRC and UP keys have been derived from the KSN, the SN and UE may delete the KSN.

6.10.3.3 Negotiation of security algorithms p. 109

The MN shall receive the UE security capabilities from the AMF or the previous NG-RAN node. These security capabilities include both LTE and NR security capabilities.

When establishing one or more DRBs and/or SRBs for a UE at the SN, as shown on Figure 6.10.2.1-1, the MN shall provide the UE security capabilities of the UE to the SN in the SN Addition/Modification Request message.

Upon receipt of this message, the SN shall select the algorithms with highest priority in its locally configured list of algorithms that are also present in the received UE security capabilities and include the selected algorithms in SN Addition/Modification Request Acknowledge.

The MN shall provide the selected algorithms to the UE during the RRCConnectionReconfiguration procedure that configures the DRBs and/or SRB with the SN for the UE. The UE shall use the indicated algorithms for the DRBs and/or SRB whose PDCP terminates on the SN.

6.10.4 Protection of traffic between UE and SN p. 109

This subclause provides the details of the needed SN RRC and UP keys and the algorithms used to protect the traffic whose PDCP terminates on the SN. The UE and SN may either calculate all the SN RRC and UP keys at once or as there are required to be used. The RRC and UP keys are KRRCenc and KRRCint for the SRB whose PDCP terminates on the SN and KUPenc for the DRBs whose PDCP terminate on the SN.

When the SN is a gNB, the RRC traffic protection directly between the UE and SN is done using the mechanism described in subclause 6.5 of the present document with the algorithms specified in Annex D of the present document.

When the SN is a gNB, the UP traffic protection and activation is done using the mechanism described in subclauses 6.6 of the present document using the algorithms specified in Annex D of the present document. The UP security activation procedure for MR-DC (meaning NR-DC, NE-DC and NGEN-DC) scenarios use the mechanism described in subclause 6.10.2.1 with the following additional procedures:

In the case of split PDU session where some of the DRB(s) is terminated at the MN and some DRB(s) is terminated at the SN, the MN shall ensure that all DRBs which belong to the same PDU session have the same UP integrity protection and ciphering activation. To achieve this, the MN shall inform the SN with its UP integrity protection and ciphering activation decision of any DRB that is offloaded and to be terminated at the SN. The SN shall activate the UP integrity protection and ciphering based on the MN decision.

For UP Integrity Protection, if the UE does not indicate that it supports the use of integrity protection with ng-eNB:

Case 1:

UP security policy indicates UP Integrity Protection "required":

In NGEN-DC scenario, the MN shall reject the PDU session.

In NE-DC scenario, if the MN decides to activate the UP integrity protection for this PDU session, the MN shall not offload any DRB of the PDU session to the SN.

In NR-DC scenario, the MN makes the decision for PDU sessions that are terminated at the MN while the SN makes the decision for PDU sessions that are terminated at the SN.

Case 2:

UP security policy indicates UP Integrity Protection "preferred":

In NGEN-DC scenario, the MN shall always deactivate UP integrity protection. In this case, the SN shall always deactivate the UP integrity protection of any PDU session terminated at the SN.

In NE-DC scenario, if the MN has activated any of this PDU session DRBs with UP integrity protection "on", the MN shall not offload any DRB of this PDU session to the SN. However, if the MN has activated all DRBs of this PDU session with integrity protection "off", the MN may offload DRBs of this PDU session to the SN. In this case, the SN shall not activate the UP integrity protection and shall always set the UP integrity protection indication to "off".

In NR-DC scenario, the MN makes the decision for PDU sessions that are terminated at the MN while the SN makes the decision for PDU sessions that are terminated at the SN.

Case 3:

UP security policy indicates UP Integrity Protection "not needed":

In all MR-DC scenarios, the MN and SN shall always deactivate UP integrity protection.

For UP integrity protection, if the UE indicates that it supports use of integrity protection with ng-eNB, in all 5GC-based MR-DC scenarios, the MN and SN shall make a decision on UP integrity protection according to the UP security policy for PDU sessions which terminate at the MN and SN, respectively, where all DRBs belonging to the same PDU session shall have the integrity protection either "on" or "off".

For UP Ciphering Protection:

In all MR-DC scenario, the MN and SN shall make a decision on UP ciphering protection according to the UP security policy for PDU sessions which terminate at the MN and SN, respectively, where all DRBs belonging to the same PDU session shall have the ciphering protection either "on" or "off".

In all scenarios of MR-DC, the SN shall send the UP integrity protection and encryption indications to the MN in the SN Addition/Modification Request Acknowledgement message. The MN shall forward the UP integrity protection and encryption indications to the UE in RRC Connection Reconfiguration message. The UE activate the UP security protection with the SN based on the UP integrity protection and encryption indications using the scheme described in subclause 6.6.2. If the MN has not activated the RRC security before sending the RRC Connection Reconfiguration message, the MN shall perform AS SMC procedure first.

When the SN is a ng-eNB, the RRC and UP traffic is protected using the mechanism described in subclauses 7.4 and 7.3 respectively of TS 33.401 with the algorithms specified in Annex C of TS 33.401. Additionally, the UP traffic is integrity protected based on the UP security policy and the indication that the UE supports the use of UP integrity protection with ng-eNB.

6.10.5 Handover Procedure p. 110

During N2 and Xn handover, the DRB and/or SRB connections between the UE and the SN shall be released, and the SN and the UE shall delete the SN RRC and UP keys since they shall be refreshed by the new KSN derived by the target-MN.

6.10.6 Signalling procedure for PDCP COUNT check p. 111

SN may request the MN to execute a counter check procedure specified in Clause 6.13 of this specification to verify the value of the PDCP COUNT(s) associated with DRB(s) offloaded to the SN. To accomplish this, the SN shall communicate this request, including the expected values of PDCP COUNT(s) and associated radio bearer identities to the MN over the Xn-C.

If the MN receives a RRC counter check response from the UE that contains one or several PDCP COUNT values (possibly associated with both MN and SN), the MN may release the connection or report the difference of the PDCP COUNT values to the serving AMF or O&M server for further traffic analysis, e.g., detecting the attacker.

6.10.7 Radio link failure recovery p. 111

Since the MN holds the control plane functions in MR-DC as in clause 6.10.1.2, the UE runs the RRC re-establishment procedure with the MN as specified in Clause 6.11 of the present document. During the RRC re-establishment procedure, the radio bearers between the UE and the SN shall be released.