Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

6.5  RRC security mechanisms

6.5.1  RRC integrity mechanisms

RRC integrity protection shall be provided by the PDCP layer between UE and gNB and no layers below PDCP shall be integrity protected. Replay protection shall be activated when integrity protection is activated (except for when the selected integrity protection algorithm is NIA0, see Annex D). Replay protection shall ensure that the receiver accepts each particular incoming PDCP COUNT value only once using the same AS security context.
The use and mode of operation of the 128-NIA algorithms are specified in Annex D.
The input parameters to the 128-bit NIA algorithms as described in Annex D are the RRC message as MESSAGE, an 128-bit integrity key K RRCint as KEY, a 5-bit bearer identity BEARER which value is assigned as specified by TS 38.323, the 1-bit direction of transmission DIRECTION and a bearer specific direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.
The RRC integrity checks shall be performed both in the ME and the gNB. In case failed integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message shall be discarded. This can happen on the gNB side or on the ME side. UE may trigger a recovery procedure as specified in TS 38.331.
Up

6.5.2  RRC confidentiality mechanisms

RRC confidentiality protection is provided by the PDCP layer between UE and gNB.
The use and mode of operation of the 128-NEA algorithms are specified in Annex D.
The input parameters to the 128-bit NEA algorithms as described in Annex D are a 128-bit cipher Key K RRCenc as KEY, a 5-bit bearer identity BEARER which corresponds to the radio bearer identity, the 1-bit direction of transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.
Up

6.5.3  RRC UE capability transfer procedure

The network should activate AS security (i.e., perform a successful AS SMC procedure) before running the RRC UE capability transfer procedure.
With the exception of unauthenticated emergency calls and the UEs using Control plane CIoT optimization,, if the network had acquired UE capabilities using RRC UE capability transfer procedure before AS security activation, then the network shall not store them locally for later use and shall not send them to other network entities. In that case, the network shall re-run the RRC UE capability transfer procedure after a successful AS SMC procedure.
Up

6.6  UP security mechanismsWord‑p. 62

6.6.1  UP security policy

The SMF shall provide UP security policy for a PDU session to the ng-eNB/gNB during the PDU session establishment procedure as specified in TS 23.502.
The UP security policy shall indicate whether UP confidentiality and/or UP integrity protection shall be activated or not for all DRBs belonging to that PDU session. The UP security policy shall be used to activate UP confidentiality and/or UP integrity for all DRBs belonging to the PDU session.
The ng-eNB/gNB shall activate UP confidentiality and/or UP integrity protection per each DRB, according to the received UP security policy, using RRC signalling as defined in clause 6.6.2. If the user plane security policy indicates "Required" or "Not needed", the ng-eNB/gNB shall not overrule the UP security policy provided by the SMF. If the ng-eNB/gNB cannot activate UP confidentiality and/or UP integrity protection when the received UP security policy is "Required", the gNB shall reject establishment of UP resources for the PDU Session and indicate reject-cause to the SMF. If the received UP security policy is " Not needed ", then the establishment of the PDU Session shall proceed as described in TS 23.502.
At an Xn-handover from the source ng-eNB/gNB to the target ng-eNB/gNB, the source ng-eNB/gNB shall include in the HANDOVER REQUEST message, the UE's UP security policy. If the UP security policy is 'Required', the target ng-eNB/gNB shall reject all PDU sessions for which it cannot comply with the corresponding received UP security policy and indicate the reject-cause to the SMF. For the accepted PDU sessions, the target ng-eNB/gNB shall activate UP confidentiality and/or UP integrity protection per DRB according to the received UE's UP security policy and shall indicate that to the UE in the HANDOVER COMMAND by the source ng-eNB/gNB.
If the UE receives an indication in the HANDOVER COMMAND that UP integrity protection and/or UP encryption for a PDU session is enabled at the target ng-eNB/gNB, the UE shall generate or update the UP encryption key and/or UP integrity protection key and shall activate UP encryption and/or UP integrity protection for the respective PDU session.
Further, in the Path-Switch message, the target ng-eNB/gNB shall send the UE's UP security policy and corresponding PDU session ID received from the source gNB to the SMF. The SMF shall verify that the UE's UP security policy received from the target ng-eNB/gNB is the same as the UE's UP security policy that the SMF has locally stored. If there is a mismatch, the SMF shall send its locally stored UE's UP security policy of the corresponding PDU sessions to the target gNB. This UP security policy information, if included by the SMF, is delivered to the target ng-eNB/gNB in the Path-Switch Acknowledge message. The SMF shall support logging capabilities for this event and may take additional measures, such as raising an alarm.
If the target gNB receives UE's UP security policy from the SMF in the Path-Switch Acknowledge message, the target gNB shall update the UE's UP security policy with the received UE's UP security policy. If UE's current UP confidentiality and/or UP integrity protection activation is different from the received UE's UP security policy, then the target gNB shall initiate intra-cell handover procedure which includes RRC Connection Reconfiguration procedure to reconfigure the DRBs to activate or de-activate the UP integrity/confidentiality as per the received policy from SMF.
In case of the target ng-eNB/gNB receives both UE security capability and UP security policy, then ng-eNB/gNB initiates the intra-cell handover procedure which contains selected algorithm and an NCC to the UE. New UP keys shall be derived and used at both the UE and the target gNB.
At an N2-handover the SMF shall send the UE's UP security policy to the target ng-eNB/gNB via the target AMF. The target ng-eNB/gNB shall reject all PDU sessions for which it cannot comply with the corresponding received UP security policy and indicate the reject-cause to the SMF via the target AMF. For all other PDU sessions, the target ng-eNB/gNB shall activate UP confidentiality and/or UP integrity protection per DRB according to the received UE's UP security policy.
Up

6.6.2  UP security activation mechanismWord‑p. 63
AS UP integrity protection and ciphering activation shall be done as part of the DRB addition procedure using RRC Connection Reconfiguration procedure as described in this clause, see Figure 6.6.2-1.
The SMF shall send the UP security policy to the gNB/ng-eNB as defined in Clause 6.6.1.
[not reproduced yet]
Figure 6.6.2-1: User plane (UP) security activation mechanism
Up
1a. This RRC Connection Reconfiguration procedure which is used to add DRBs shall be performed only after RRC security has been activated as part of the AS security mode command procedure defined in Clause 6.7.4.
1b. The gNB/ng-eNB shall send the RRC Connection Reconfiguration message to the UE for UP security activation containing indications for the activation of UP integrity protection and ciphering for each DRB according to the security policy.
1c. If UP integrity protection is activated for DRBs as indicated in the RRC Connection Reconfiguration message, and if the gNB does not have K UPint, the gNB shall generate K UPint and UP integrity protection for such DRBs shall start at the gNB. Similarly, if UP ciphering is activated for DRBs as indicated in the RRC Connection Reconfiguration message, and if the gNB/ng-eNB does not have K UPenc, the gNB/ng-eNB shall generate K UPenc and UP ciphering for such DRBs shall start at the gNB/ng-eNB.
2a. UE shall verify the RRC Connection Reconfiguration message. If successful:
2a.2. Similarly, if UP ciphering is activated for DRBs as indicated in the RRC Connection Reconfiguration message, and if the UE does not have K UPenc, the UE shall generate K UPenc and UP ciphering for such DRBs shall start at the UE
2b. If the UE successfully verifies integrity of the RRC Connection Reconfiguration message, the UE shall send the RRC Connection Reconfiguration Complete message to the gNB/ng-eNB.
If UP integrity protection is not activated for DRBs, the gNB and the UE shall not integrity protect the traffic of such DRB and shall not put MAC-I into PDCP packet.
If UP ciphering is not activated for DRBs, the gNB/ng-eNB and the UE shall not cipher the traffic of such DRBs.
Up

6.6.3  UP confidentiality mechanismsWord‑p. 64
The PDCP protocol, as specified in TS 38.323 between the UE and the NG-RAN, shall be responsible for user plane data confidentiality protection.
The use and mode of operation of the 128-bit NEA algorithms are specified in Annex D.
The input parameters to the 128-bit NEA algorithms as described in Annex D are the message packet, an 128-bit cipher key K UPenc as KEY, a 5-bit bearer identity BEARER which value is assigned as specified by TS 38.323, the 1-bit direction of transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific, and direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.
Up

6.6.4  UP integrity mechanisms

The PDCP protocol, as specified in TS 38.323 between the UE and the NG-RAN, shall be responsible for user plane data integrity protection.
The use and mode of operation of the 128-bit NIA algorithms are specified in Annex D.
The input parameters to the 128-bit NIA algorithms as described in Annex D are, the message packet, a 128-bit integrity key K UPint as KEY, a 5-bit bearer identity BEARER value of which is assigned as specified by TS 38.323, the 1-bit direction of transmission DIRECTION, and a bearer specific, and direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.
If the gNB or the UE receives a PDCP PDU which fails integrity check with faulty or missing MAC-I after the start of integrity protection, the PDU shall be discarded.
Up

6.7  Security algorithm selection, key establishment and security mode command procedure

6.7.1  Procedures for NAS algorithm selection

6.7.1.1  Initial NAS security context establishment

Each AMF shall be configured via network management with lists of algorithms which are allowed for usage. There shall be one list for NAS integrity algorithms, and one for NAS ciphering algorithms. These lists shall be ordered according to a priority decided by the operator.
To establish the NAS security context, the AMF shall choose one NAS ciphering algorithm and one NAS integrity protection algorithm. The AMF shall then initiate a NAS security mode command procedure, and include the chosen algorithm and UE security capabilities (to detect modification of the UE security capabilities by an attacker) in the message to the UE (see subclause 6.7.2 of the present document). The AMF shall select the NAS algorithm which have the highest priority according to the ordered lists.
Up

6.7.1.2  AMF change

If the change of the AMF at N2-Handover or mobility registration update results in the change of algorithm to be used for establishing NAS security, the target AMF shall indicate the selected algorithm to the UE as defined in Clause 6.9.2.3.3 for N2-Handover (i.e., using NAS Container) and Clause 6.9.3 for mobility registration update (i.e., using NAS SMC). The AMF shall select the NAS algorithm which has the highest priority according to the ordered lists (see subclause 6.7.1.1 of the present document).
Up

6.7.2  NAS security mode command procedureWord‑p. 65
The NAS SMC shown in Figure 6.7.2-1 shall be used to establish NAS Security context between the UE and the AMF. This procedure consists of a roundtrip of messages between the AMF and the UE. The AMF sends the NAS Security Mode Command message to the UE and the UE replies with the NAS Security Mode Complete message.
[not reproduced yet]
Figure 6.7.2-1: NAS Security Mode Command procedure
Up
1a. The AMF activates the NAS integrity protection before sending the NAS Security Mode Command message.
1b. The AMF sends the NAS Security Mode Command message to the UE. The NAS Security Mode Command message shall contain: the replayed UE security capabilities, the selected NAS algorithms, and the ngKSI for identifying the K AMF. The NAS Security Mode Command message may contain: K_AMF_change_flag (carried in the additional 5G security parameters IE specified in TS 24.501) to indicate a new K AMF is calculated, a flag requesting the complete initial NAS message (see subclause 6.4.6), Anti-Bidding down Between Architectures (ABBA) parameter. In the case of horizontal derivation of K AMF during mobility registration update or during multiple registration in same PLMN, K_AMF_change_flag shall be included in the NAS Security Mode Command message as described in clause 6.9.3.
This message shall be integrity protected (but not ciphered) with NAS integrity key based on the K AMF indicated by the ngKSI in the NAS Security Mode Command message (see Figure 6.7.2-1).
In case the network supports interworking using the N26 interface between MME and AMF, the AMF shall also include the selected EPS NAS algorithms (defined in Annex B of TS 33.401) to be used after mobility to EPS in the NAS Security Mode Command message (see clause 8.5.2). The UE shall store the algorithms for use after mobility to EPS using the N26 interface between MME and AMF. The AMF shall store the selected EPS NAS algorithms in the UE security context.
1c. The AMF activates NAS uplink deciphering after sending the NAS Security Mode Command message.
2a. The UE shall verify the NAS Security Mode Command message. This includes checking that the UE security capabilities sent by the AMF match the ones stored in the UE to ensure that these were not modified by an attacker and verifying the integrity protection using the indicated NAS integrity algorithm and the NAS integrity key based on the K AMF indicated by the ngKSI.
In case the NAS Security Mode Command message includes a K_AMF_change_flag, the UE shall derive a new K AMF as described in Annex A.13 and set the NAS COUNTs to zero.
If the verification of the integrity of the NAS Security Mode Command message is successful, the UE shall start NAS integrity protection and ciphering/deciphering with the security context indicated by the ngKSI.
2b. The UE sends the NAS Security Mode Complete message to the AMF ciphered and integrity protected. The NAS Security Mode Complete message shall include PEI in case AMF requested it in the NAS Security Mode Command message. The AMF shall set the NAS COUNTs to zero if horizontal derivation of K AMF is performed. The UE may include the complete initial NAS message (see subclause 6.4.6 for details).
If the verification of the NAS Security Mode Command message is not successful in the UE, it shall reply with a NAS Security Mode Reject message (see TS 24.501). The NAS Security Mode Reject message and all subsequent NAS messages shall be protected with the previous, if any, 5G NAS security context, i.e., the 5G NAS security context used prior to the failed NAS Security Mode Command message. If no 5G NAS security context existed prior to the NAS Security Mode Command message, the NAS Security Mode Reject message shall remain unprotected.
The AMF shall de-cipher and check the integrity protection on the NAS Security Mode Complete message using the key and algorithm indicated in the NAS Security Mode Command message. NAS downlink ciphering at the AMF with this security context shall start after receiving the NAS Security Mode Complete message.
1d. The AMF activates NAS downlink ciphering.
Up

6.7.3  Procedures for AS algorithm selectionWord‑p. 66

6.7.3.0  Initial AS security context establishment

This clause provides the details for AS security algorithms negotiation and consideration during the UE initial AS security context establishment.
Each gNB/ng-eNB shall be configured via network management with lists of algorithms which are allowed for usage. There shall be one list for integrity algorithms, and one for ciphering algorithms. These lists shall be ordered according to a priority decided by the operator. When AS security context is to be established in the gNB/ng-eNB, the AMF shall send the UE 5G security capabilities to the gNB/ng-eNB. The gNB/ng-eNB shall choose the ciphering algorithm which has the highest priority from its configured list and is also present in the UE 5G security capabilities.
The gNB/ng-eNB shall choose 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 shall be indicated to the UE in the AS SMC. The chosen ciphering algorithm is used for ciphering (when activated) of the user plane and RRC traffic. The chosen integrity algorithm is used for integrity protection (when activated) of the user plane and RRC traffic. Activation of ciphering and integrity protection for the RRC traffic shall be done as defined by clause 6.7.4. Activation of ciphering and integrity protection for the user plane traffic shall be done based on the UP security policy received from the SMF as defined by clause 6.6.2.
Up

6.7.3.1  Xn-handover

At handover from a source gNB/ng-eNB over Xn to a target gNB/ng-eNB, the source gNB/ng-eNB shall include the UE's 5G security capabilities and ciphering and integrity algorithms used in the source cell in the handover request message. The target gNB/ng-eNB shall select the algorithm with highest priority from the received 5G security capabilities of the UE according to the prioritized locally configured list of algorithms (this applies for both integrity and ciphering algorithms). The chosen algorithms shall be indicated to the UE in the Handover Command message if the target gNB/ng-eNB selects different algorithms compared to the source gNB/ng-eNB. If the UE does not receive any selection of integrity and ciphering algorithms, it continues to use the same algorithms as before the handover (see TS 38.331 for gNB or TS 36.331 for ng-eNB). When a Xn-handover takes place from ng-eNB to gNB or vice versa, then the selected algorithms in the target node shall always be signalled in the Handover Command to the UE. In the Path-Switch message, the target gNB/ng-eNB shall send the UE's 5G security capabilities received from the source gNB/ng-eNB to the AMF. The AMF shall verify that the UE's 5G security capabilities received from the target gNB/ng-eNB are the same as the UE's 5G security capabilities that the AMF has locally stored. If there is a mismatch, the AMF shall send its locally stored 5G security capabilities of the UE to the target gNB/ng-eNB in the Path-Switch Acknowledge message. The AMF shall support logging capabilities for this event and may take additional measures, such as raising an alarm.
If the target gNB/ng-eNB receives UE's 5G security capabilities from the AMF in the Path-Switch Acknowledge message, the target gNB/ng-eNB shall update the AS security context of the UE with these 5G security capabilities of the UE. The target gNB/ng-eNB shall select the algorithm with highest priority from these 5G security capabilities according to the locally configured prioritized list of algorithms (this applies for both integrity and ciphering algorithms). If the algorithms selected by the target gNB/ng-eNB are different from the algorithms used at the source gNB/ng-eNB, then the target gNB/ng-eNB shall initiate intra-cell handover procedure which includes RRC Connection Reconfiguration procedure indicating the selected algorithms and an NCC to the UE.
Up

6.7.3.2  N2-handoverWord‑p. 67
At handover from a source gNB/ng-eNB to a target gNB/ng-eNB over N2 (possibly including an AMF change and hence a transfer of the UE's 5G security capabilities from the source AMF to the target AMF), the target AMF shall send the UE's 5G security capabilities to the target gNB/ng-eNB in the NGAP HANDOVER REQUEST message (see TS 38.413). The target gNB/ng-eNB shall select the algorithm with highest priority from the UE's 5G security capabilities according to the locally configured prioritized list of algorithms (this applies for both integrity and ciphering algorithms). The chosen algorithms shall be indicated to the UE in the Handover Command message if the target gNB/ng-eNB selects different algorithms compared to the source gNB/ng-eNB. If the UE does not receive any selection of integrity and ciphering algorithms, it continues to use the same algorithms as before the handover (see TS 38.331).
For N2-handover, the source gNB/ng-eNB shall include AS algorithms used in the source cell (ciphering and integrity algorithms) in the source to target transparent container that shall be sent to the target gNB/ng-eNB. The AS algorithms used by the source cell are provided to the target gNB/ng-eNB so that it can use them during the potential RRC Connection Re-establishment procedure use them as specified in clause 6.11 for gNB and TS 33.401 for ng-eNB.
Up

6.7.3.3  Intra-gNB-CU handover/intra-ng-eNB handover

It is not required to change the AS security algorithms during intra-gNB-CU/intra-ng-eNB handover. If the UE does not receive an indication of new AS security algorithms during an intra-gNB-CU/intra-ng-eNB handover, the UE shall continue to use the same algorithms as before the handover (see TS 38.331 for gNB and TS 36.331 for ng-eNB).

6.7.3.4  Transitions from RRC_INACTIVE to RRC_CONNECTED states

At state transition from RRC_INACTIVE to RRC_CONNECTED, the source gNB/ng-eNB shall include the UE 5G security capabilities and the ciphering and integrity algorithms the UE was using with the source cell in the Xn-AP Retrieve UE Context Response message.
The target gNB/ng-eNB shall check if it supports the received algorithms, if the target gNB/ng-eNB supports the received ciphering and integrity algorithms, the target gNB/ng-eNB shall check the received algorithms to its locally configured list of algorithms (this applies for both integrity and ciphering algorithms). If the target gNB/ng-eNB selects the same security algorithms, the target gNB/ng-eNB shall use the selected algorithms to derive RRC integrity and RRC encryption keys to protect the RRCResume message and send to the UE on SRB1.
If the target gNB/ng-eNB does not support the received algorithms or if the target gNB/ng-eNB prefers to use different algorithms, the target gNB/ng-eNB shall send an RRCSetup message on SRB0 in order to proceed with RRC connection establishment as if the UE was in RRC_IDLE (fallback procedure) to the UE. Then the UE performs NAS based RRC recovery and negotiates a suitable algorithm with target gNB/ng-eNB via AS SMC procedure.
Up

6.7.3.5  RNA Update procedureWord‑p. 68
If the source gNB/ng-eNB decides to relocate UE context to the target gNB/ng-eNB during an RNA Update procedure, the source gNB/ng-eNB shall include the UE 5G security capabilities and the ciphering and integrity algorithms the UE was using with the source cell in the <Xn-AP Retrieve UE Context Response> message. AS security algorithm selection is as described in clause 6.7.3.4.

6.7.3.6  Algorithm negotiation for unauthenticated UEs in LSM

UEs that are in limited service mode (LSM) and that cannot be authenticated by the AMF/SEAF (for whatever reason) may still be allowed to establish emergency session by sending the emergency registration request message. It shall be possible to configure whether the AMF allows unauthenticated UEs in LSM to establish bearers for emergency session or not. If an AMF allows unauthenticated UEs in LSM to establish bearers for an emergency session, then for the NAS protocol, the AMF shall use NIA0 and NEA0 as the integrity and ciphering algorithm respectively.
If the AMF allows an unauthenticated UE in LSM to establish bearers for emergency session after it has received the emergency registration request message from the UE, the AMF shall:
  • Select NIA0 and NEA0, regardless of the supported algorithms announced previously by the UE as the NAS algorithms and signal this to the UE via the NAS security mode command procedure when activating the 5G NAS security context.
  • Set the UE 5G security capabilities to only contain EIA0, EEA0, NIA0 and NEA0 when sending these to the gNB/ng-eNB in the following messages:
  • NGAP UE INITIAL CONTEXT SETUP
  • NGAP UE CONTEXT MODIFICATION REQUEST
  • NGAP HANDOVER REQUEST
    If NIA0 is disabled at the gNB for regulatory requirements and the gNB receives the UE 5G security capabilities to only contain NIA0 for integrity protection algorithms from the AMF in one of the above messages, the gNB shall reject the session.
    The rules for when the AMF shall select NIA0 for NAS integrity protection, and when the UE shall accept a NAS security mode command selecting NIA0 for NAS integrity protection depends on whether the UE and AMF can be certain that no 5G NAS security context can be established. The rules for determining this is defined in clause 10 of this specification. If the AMF has selected NIA0 as the NAS integrity protection algorithm, the UE shall accept selection of NIA0 or EIA0 as the AS integrity protection algorithm. Selection of AS integrity protection algorithm happens via the AS security mode command procedure or via a handover command. The UE shall under no other circumstances accept selection of null integrity algorithm as the AS integrity protection algorithm.
  • Up

    6.7.4  AS security mode command procedure

    The AS SMC procedure is for RRC and UP security algorithms negotiation and RRC security activation. for the gNB/ng-eNB. AS SMC procedure can be triggered to establish a secure RRC signalling-only connection during UE registration or PDU session establishment as specified in TS 38.413 and TS 23.502. The activation of UP security is as described in clause 6.6.2. AS SMC procedure consists of a roundtrip of messages between gNB/ng-eNB and UE. The gNB/ng-eNB sends the AS security mode command to the UE and the UE replies with the AS security mode complete message. See Figure 6.7.4-1.
    The AS security mode command message sent from gNB/ng-eNB to UE shall contain the selected RRC and UP encryption and integrity algorithms. This AS security mode command message shall be integrity protected with RRC integrity key based on the current K gNB.
    The AS security mode complete message from UE to gNB/ng-eNB shall be integrity protected with the selected RRC algorithm indicated in the AS security mode command message and RRC integrity key based on the current K gNB.
    RRC downlink ciphering (encryption) at the gNB/ng-eNB shall start after sending the AS security mode command message. RRC uplink deciphering (decryption) at the gNB/ng-eNB shall start after receiving and successful verification of the AS security mode complete message.
    RRC uplink ciphering (encryption) at the UE shall start 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 security mode command message.
    If any control of the AS security mode command is not successful in the UE, the UE shall reply with an unprotected security mode failure message (see TS 38.331).
    Ciphering and integrity protection of UP downlink and uplink, at the UE and the gNB/ng-eNB, shall start as defined by clause 6.6.2.
    AS SMC shall be used only during an initial context setup between the UE and the gNB/ng-eNB (i.e., to activate an initial K gNB at RRC_IDLE to RRC_CONNECTED state transition).
    [not reproduced yet]
    Figure 6.7.4-1: AS Security Mode Command Procedure
    Up

    Up   Top   ToC