Generate an authentication token

Abstract

A method (1000) for generating an authentication token includes obtaining (s1002) a first resumption-connection-request message including: i) a first field including a cause value; ii) a second field including an identity value; and iii) a third field including a predefined token value. The method further includes using (s1004) the first resumption-connection-request message to generate an authentication token.

Description

[Technical Field]

[0001] The present disclosure relates to generating authentication tokens for Radio Resource Control (RRC) messages, such as RRCResumeRequest and RRCResumeRequest1 messages. [Background technology]

[0002] RRC connection resumed The RRC connection resumption procedure is used to resume an interrupted RRC connection, including the resumption of one or more signaling radio bearers (SRBs) and one or more data radio bearers (DRBs), or the updating of a radio access network-based notification area (RNA).

[0003] RRC connection resumption conditions for sidelink (SL) communication For New Radio (NR) sidelink communications, the RRC connection is resumed only if: 1) higher layers have configured it to transmit NR sidelink communications and relevant data is available for transmission, and 2) the frequency on which the user equipment device (UE) is configured to transmit NR sidelink communications is included in the sl-FreqInfoList in the System Information Block 12 (SIB12) provided by the cell on which the UE is camped, and the valid version of SIB12 does not include sl-TxPoolSelectedNormal for that frequency.

[0004] For Vehicle-to-Any (V2X) sidelink communications, RRC connection resumption is initiated only if the conditions specified for V2X sidelink communications in sub-clause 5.3.3.1a of the 3rd Generation Partnership Project (3GPP®) Technical Specification (TS) 36.331 V16.5.0 ("TS36.331") are met. Note that higher layers initiate RRC connection resumption. Interaction with the Non-Access Stratum (NAS) is left to the UE implementation.

[0005] start As described in 3GPP TS38.331 V16.4.1 ("TS38.331"), the UE initiates this procedure when a higher layer or access stratum (AS) (such as in response to Radio Access Network (RAN) paging, when the UE triggers an RNA update during RRC_INACTIVE, or in the case of sidelink communication as specified in subclause 5.3.13.1a) requests the resumption of a suspended RRC connection. It further notes that "before initiating this procedure, the UE shall ensure that it has valid and up-to-date essential system information as specified in clause 5.2.2.2." TS38.331 states: "When the procedure is initiated, the UE: 1> If the resumption of the RRC connection is triggered by a response to NG-RAN paging: 2>Select "0" as the access category; 2> Execute the unified access control procedure specified in 5.3.14 using the selected access category and one or more access identifiers provided by the higher layer; 3> If the access attempt is prohibited, terminate the procedure; 1> Otherwise, if the resumption of the RRC connection is triggered by higher layers: 2> If the upper layer provides an Access Category and one or more Access IDs: 3> Execute the unified access control procedures specified in 5.3.14 using the access categories and access identities provided by the higher layer; 4> If the access attempt is prohibited, terminate the procedure; 2> Set resumeCause according to the information received from the upper layer; 1> Otherwise, if the RRC connection resumption is triggered by an RNA update as specified in 5.3.13.8: 2>If emergency services are ongoing: NOTE: How the RRC layer of the UE becomes aware of ongoing emergency services is up to the UE implementation. 3>Select "2" as the access category; 3>Set resumeCause to emergency; 2> Otherwise: 3>Select "8" as the access category; 2>Perform the uniform access control procedures specified in 5.3.14 using the selected access category and one or more applicable access IDs as specified in TS24.501

[23] ; 3>If your access attempt is prohibited: 4> Set variable pendingRNA-Update to true; 4>Finish the procedure; 1>If the UE is in NE-DC or NR-DC: 2> If the UE does not support maintaining SCG settings when resuming connection: 3> Release MR-DC related configurations (specified in 5.3.5.10) from the UE's InactiveAS context (if stored); 1> If the UE does not support maintaining the SCell configuration of the MCG when resuming connection: 2>Release the MCG's SCell(s) from the UE's InactiveAS context (if stored); 1>Apply the default L1 parameter values ​​specified in the corresponding physical layer specification, except for parameters for which values ​​are provided in SIB1; 1>Apply the default SRB1 configuration specified in 9.2.1; 1>Apply the default MAC cell group configuration specified in 9.2.2; 1>Release delayBudgetReportingConfig from the UE's InactiveAS context (if stored); 1> Stop timer T342 (if running); 1>Release overheatingAssistanceConfig from the UE's InactiveAS context (if stored); 1> Stop timer T345 (if running); 1> Release the idc-AssistanceConfig from the UE's InactiveAS context (if stored); 1>Release drx-PreferenceConfig for all configured cell groups from the UE's InactiveAS context (if stored); 1> Stop all instances of timer T346a (if running); 1>Release maxBW-PreferenceConfig for all configured cell groups from the UE's InactiveAS context (if stored); 1> Stop all instances of timer T346b (if running); 1>Release maxCC-PreferenceConfig for all configured cell groups from the UE's InactiveAS context (if stored); 1> Stop all instances of timer T346c (if running); 1> Release the maxMIMO-LayerPreferenceConfig for all configured cell groups from the UE's InactiveAS context (if stored); 1> Stop all instances of timer T346d (if running); 1>Release minSchedulingOffsetPreferenceConfig for all configured cell groups from the UE's InactiveAS context (if stored); 1> Stop all instances of timer T346e (if running); 1>Release releasePreferenceConfig from the UE's InactiveAS context (if stored); 1> Stop timer T346f (if running); 1>Release referenceTimePreferenceReporting from the UE's InactiveAS context (if stored); 1> Release sl-AssistanceConfigNR from the UE's InactiveAS context (if stored); 1> Apply the CCCH configuration specified in 9.1.1.2; 1>Apply timeAlignmentTimerCommon included in SIB1; 1> Start timer T319; 1>Set variable pendingRNA-Update to false; 1> Initiate sending of an RRCResumeRequest message or RRCResumeRequest1 according to 5.3.13.3.

[0006] Actions for sending a RRCResumeRequest or RRCResumeRequest1 message: TS38.331 states: "The UE sets the content of the RRCResumeRequest or RRCResumeRequest1 message as follows: 1>If the useFullResumeID field is signaled in SIB1: 2>Select RRCResumeRequest1 as the message to use; 2>Set resumeIdentity to the stored fullI-RNTI value; 1> Otherwise: 2>Select RRCResumeRequest as the message to use; 2>Set resumeIdentity to the stored shortI-RNTI value; 1> From the stored InactiveAS context of the UE, except for the following: RRC configuration, RoHC state, stored QoS flow and DRB mapping rules, and K gNB Key and K RRCintRestore the key: -masterCellGroup; -mrdc-SecondaryCellGroup (if stored); and -pdcp-Config; 1> Set resumeMAC-I to the least significant 16 bits of the calculated MAC-I: 2> ASN.1 encoded according to clause 8 (i.e., multiple of 8 bits) VarResumeMAC-Input; 2> UE's Inactive AS context K RRCint Use the key and the previously configured integrity protection algorithm; and 2>All input bits of COUNT, BEARER, and DIRECTION are set to binary 1; 1> As specified in TS33.501

[11] , use the stored nextHopChainingCount value to calculate the current K gNB Based on the key or NH, K gNB Derive the key; 1>K RRCenc key, K RRCint key, K UPint key, K UPenc Derive the key; 1> The constructed algorithm and the K derived in this section RRCint Key and K UPint Configure the lower layers to use the key to immediately apply integrity protection to all radio bearers except SRS0, i.e., integrity protection is applied to all subsequent messages sent and received by the UE; Note 1: Only DRBs that previously had integrity protection set to UP will resume integrity protection. 1> Encryption is applied to all radio bearers except SRB0, and the configured encryption algorithm, K RRCenc The key, K, derived in this subsection UPenc Configure lower layers to apply keys; 1>Re-establish the PDCP entity of SRB1; 1>Restart SRB1; 1> Send the selected message RRCResumeRequest or RRCResumeRequest1 to the lower layer. NOTE 2: Only DRBs that were previously configured for UP encryption will resume encryption.

[0007] If the lower layer indicates a consistency check failure during T319 execution, it shall take the action specified in 5.3.13.5.

[0008] The UE shall continue cell reselection related measurements as well as cell reselection evaluation. If the conditions for cell reselection are met, the UE shall perform cell reselection as specified in 5.3.13.6.

[0009] Abstract Syntax Notation One (ASN.1) message definitions according to TS38.331 RRCResumeRequest Message As stated in TS38.331: The RRCResumeRequest message is used to request the resumption of a suspended RRC connection or to perform an RNA update. Signaling radio bearer: SRB0 Radio Link Control Service Access Point (RLC-SAP): Transparent Mode (TM) Logical Channel: Common Control Channel (CCCH) Direction: UE to network

[0010] The RRCResumeRequest message consists of a series of RRC resume request information elements (IEs), as shown in Table 1 below.

[0011] Table 1: RRCResumeRequest message RRCResumeRequest ::= SEQUENCE { rrcResumeRequest RRRCResumeRequest-IEs } RRCResumeRequest-IEs ::= SEQUENCE { resumeIdentity ShortI-RNTI-Value, resumeMAC-I BIT STRING (SIZE (16)), resumeCause ResumeCause, spare BIT STRING (SIZE (1)) }

[0012] The resumeCauseIE provides the "resume cause for the RRC connection resume request provided by higher layers or RRC." The network shall not reject the RRCResumeRequest because the cause value used by the UE is unknown.

[0013] resumeIdentityIE is "the identity of the UE to facilitate UE context lookup at the gNB."

[0014] The resumeMAC-I IE is an "authentication token to facilitate UE authentication at the gNB." The least significant 16 bits of MAC-I are calculated using the AS security configuration specified in 5.3.13.3 [TS38.331].

[0015] RRCResumeRequest1 Message As stated in TS38.331: The RRCResumeRequest1 message is used to request the resumption of a suspended RRC connection or to perform an RNA update. Signaling radio bearer: SRB0 RLC-SAP:TM Logical channel: CCCH1 Direction: UE to network

[0016] The RRCResumeRequest1 message consists of a series of RRCResumeRequest1 information elements (IEs), as shown in Table 2 below.

[0017] Table 2: RRCResumeRequest1 message RRCResumeRequest1 ::= SEQUENCE { rrcResumeRequest1 RRRCResumeRequest1-IEs } RRCResumeRequest1-IEs ::= SEQUENCE { resumeIdentity I-RNTI-Value, resumeMAC-I BIT STRING (SIZE (16)), resumeCause ResumeCause, spare BIT STRING (SIZE (1)) }

[0018] The resumeCauseIE provides the "resume cause of the RRCResumeRequest1 provided by higher layers or RRC." The gNB will not reject the RRCResumeRequest1 on the grounds that it is not aware of the cause value used by the UE.

[0019] resumeIdentityIE is "the identity of the UE to facilitate UE context lookup at the gNB."

[0020] resumeMAC-IIE is an "authentication token to facilitate UE authentication at the gNB." The lowest 16 bits of MAC-I are calculated using the AS security configuration specified in 5.3.13.3 [TS38.331].

[0021] VarResumeMAC-Input The UE variable "VarResumeMAC-Input" specifies the input used to generate resumeMAC-I during the RRC connection resume procedure. Table 3 below shows the information elements that make up VarResumeMAC-Input.

[0022] Table 3: VarResumeMAC-Input variables VarResumeMAC-Input ::= SEQUENCE { sourcePhysCellId PhysCellId, targetCellIdentity CellIdentity, source-c-RNTI RNTI-Value }

[0023] The 'targetCellIdentity' IE is an input variable used in the calculation of resumeMAC-I. It is set to the cellIdentity of the first PLMN-Identity included in the PLMN-IdentityInfoList broadcasted in SIB1 of the target cell (the cell where the UE is trying to resume).

[0024] The "source-c-RNTI" IE is set to "C-RNTI of the PCell to which the UE was connected before the RRC connection was interrupted."

[0025] The "sourcePhysCellId" IE is set to the "physical cell identity of the PCell to which the UE was connected before the RRC connection was terminated."

[0026] Security processing during the transition between RRC_INACTIVE and RRC_CONNECTED states: General: In 5G, the RRC_INACTIVE state allows the gNB / ng-eNB to suspend the UE's RRC connection while the gNB / ng-eNB and UE continue to maintain the UE_5G_AS security context. The UE's RRC connection can be resumed later by the UE transitioning to the RRC_CONNECTED state. The UE can transition from the RRC_INACTIVE state to the RRC_CONNECTED state with the same last serving gNB / ng-eNB that transitioned the UE to the RRC_INACTIVE state, or with a different gNB / ng-eNB. While the UE is in the RRC_INACTIVE state, the UE and last serving gNB / ng-eNB store the UE_5G_AS security context, which can be reactivated when the UE transitions from RRC_INACTIVE to RRC_CONNECTED. The gNB / ng-eNB and UE shall behave as defined in the following subsections. In addition, ng-eNBs connected to the 5G Core (5GC) must support the same security handling during RRC state transitions.

[0027] State transition from RRC_CONNECTED to RRC_INACTIVE: To transition a UE from RRC_CONNECTED to RRC_INACTIVE, the gNB may send an RRCRelease message (with suspend indication suspendConfig) to the UE, for example, as a result of an inactivity timer expiration. The RRCRelease message with suspendConfig is encrypted and integrity protected at the Packet Data Convergence Protocol (PDCP) layer using the current AS security context. The gNB / ng-eNB must include a new Inactive-Radio Network Temporary Identifier (I-RNTI) and Next Hop Chaining Counter (NCC) in the RRCRelease message with suspendConfig. The I-RNTI is used to identify the context, and the UE_ID portion of the I-RNTI assigned by the gNB / ng-eNB must be different for consecutive suspends of the same UE. This is to avoid tracking UEs based on the I-RNTI. The gNB / ng-eNB includes the NCC in the RRCRelease message with suspendConfig if there is a new, unused pair {NCC, NH}. Otherwise, the gNB / ng-eNB gNB The same NCC associated with the AS shall be included in the RRCRelease message with suspendConfig. The NCC is used for AS security.

[0028] The gNB / ng-eNB sends an RRCRelease message with suspendConfig to the UE, and then sends the current AS key K RRCenc , K. UPenc (if available), K UPint Remove the current AS key K (if available) RRCint If the transmitted NCC value is new and belongs to an unused pair {NCC,NH} (NH=NextHop), the gNB / ng-eNB shall store the pair {NCC,NH} in the current UE_AS security context and the current AS key K gNB The transmitted NCC value is the current K gNBIf the NCC value associated with the current AS key K is equal to the gNB The gNB / ng-eNB shall store the transmitted I-RNTI together with the current UE context, including the rest of the AS security context.

[0029] When the UE receives the RRCRelease message with suspendConfig from the gNB / ng-eNB, it shall verify the integrity of the received RRCRelease message with suspendConfig by checking the integrity (MAC-I) of the PDCP Message Authentication Code (MAC). If this verification is successful, the UE shall store the received NCC value as a saved NCC together with the current UE context. The UE shall store the current AS key K RRCenc , K. UPenc (if available), and K UPint Remove the current AS key K (if available) RRCint The saved NCC value is the current K gNB If the NCC value associated with the current AS key K is different from the NCC value associated with the current AS key K, the UE gNB The saved NCC value is the current K gNB If the NCC value associated with the current AS key K gNB The UE shall store the received I-RNTI together with the current UE context, including the rest of the AS security context, for the next state transition.

[0030] State transition from RRC_INACTIVE to RRC_CONNECTED to new gNB / ng-eNB: If the UE decides to resume the RRC connection to transition from RRC_INACTIVE to RRC_CONNECTED, the UE sends an RRCResumeRequest message to SRB0, and therefore integrity is not protected. However, the RRCResumeRequest message must include I-RNTI and ResumeMAC-I or shortResumeMAC-I.

[0031] The I-RNTI (short or full I-RNTI) is used for context identification and its value must be the same as the I-RNTI that the UE received from the source gNB / ng-eNB in ​​the RRCRelease message with suspendConfig.

[0032] ResumeMAC-I / shortResumeMAC-I is a 16-bit message authentication token that the UE uses to authenticate the integrity protection algorithm of the stored AS security context (Integrity Algorithm for 5G (NIA) or Evolved Packet System Integrity Algorithm (EIA)) negotiated between the UE and the source gNB / ng-eNB and the current K RRCint This must be calculated using the following inputs: (1) KEY: current K RRCint (2) BEARER: all bits are set to 1; (3) DIRECTION: bits are set to 1; (4) COUNT: all bits are set to 1; (5) MESSAGE: set to VarResumeMAC-Input / VarShortInactiveMAC-Input as defined in TS38.331 for gNB and TS36.331 for ng-eNB using the following inputs: source physical cell ID (PCI), target cell ID, source cell radio network temporary identifier (C-RNTI).

[0033] For protection of all RRC messages except for the RRCReject message following the sent RRCResumeRequest message, the UE shall determine the target PCI, target absolute radio frequency channel number - downlink (ARFCN-DL) / E-UTRA absolute radio frequency channel number - downlink (EARFCN-DL), and K based on either horizontal or vertical key derivation as defined in clause 6.9.2.1.1 and Annex A.11 / A.12 of 3GPP TS33.501 (e.g., V16.7.0). gNB / NH using K NG-RAN The UE further derives the newly derived K NG-RAN *From, K RRCint , K. RRCenc , K. UPenc (Optional), and K UPint (Optional) shall be derived.

[0034] When the target gNB / ng-eNB receives the RRCResumeRequest message from the UE, it extracts the I-RNTI from the RRCResumeRequest message. The target gNB / ng-eNB contacts the source gNB / ng-eNB based on the information in the I-RNTI by sending an Xn-AP Search UE Context Request message containing the following: This is so that the source gNB / ng-eNB can verify the UE request and obtain the UE context, including the UE_5G_AS security context.

[0035] The source gNB / ng-eNB uses the I-RNTI to retrieve the stored UE context, including the UE_5G_AS security context, from its database. The source gNB / ng-eNB then uses the current K stored in the retrieved UE_5G_AS security context. RRCintValidate ResumeMAC-I / shortResumeMAC-I using the key (calculate ResumeMAC-I / shortResumeMAC-I in the same way as above). If the validation of ResumeMAC-I / shortResumeMAC-I is successful, the source gNB / ng-eNB will then validate the target PCI, target ARFCN-DL / EARFCN-DL, and K in the current UE_5G_AS security context. gNB / NH to derive K based on either horizontal or vertical key derivation, depending on whether the source gNB / ng-eNB has an unused pair of {NCC,NH}, as described in Annex A.11 / Annex A.12. NG-RAN * is calculated. The source gNB / ng-eNB can obtain the target PCI and target ARFCN-DL / EARFCN-DL from the cell configuration database using the target Cell-ID received from the target gNB / ng-eNB. The source gNB / ng-eNB then responds to the target gNB / ng-eNB with an Xn-AP Search UE Context Response message containing the UE context, including the UE_5G_AS security context. The UE_5G_AS security context sent to the target gNB / ng-eNB contains the newly derived K NG-RAN *, K NG-RAN * Shall include the associated NCC, UE_5G_security capabilities, user plane (UP) security policy, UP security activation status including corresponding protocol data unit (PDU) session ID, and encryption and integrity protection algorithms used by the UE in the source cell.

[0036] The target gNB / ng-eNB shall check whether the UE supports the encryption and integrity protection algorithms used in the last source cell. If the target gNB / ng-eNB does not support the encryption and integrity protection algorithms used in the last source cell, or if the target gNB / ng-eNB prefers to use different algorithms than the source gNB / ng-eNB, the target gNB / ng-eNB shall send an RRCSetup / RRCSetup message on SRB0 to the UE to proceed with the RRC connection establishment as if the UE were in RRC_IDLE (i.e., fallback procedure).

[0037] If the target gNB / ng-eNB supports the encryption and integrity protection algorithms used in the last source cell and these algorithms are the algorithms selected by the target gNB / ng-eNB, the target gNB / ng-eNB shall notify the UE of the algorithms used in the source cell and the received K NG-RAN * to derive new AS keys (RRC integrity key, RRC ciphering key and UP key). The target gNB / ng-eNB resets all PDCP COUNTs to 0 and activates the new keys at the PDCP layer. The target gNB / ng-eNB responds to the UE with an RRCResume message on SRB1. This message is integrity protected and encrypted at the PDCP layer using the new RRC keys.

[0038] If the target gNB / ng-eNB can support the UP security activation status, the target gNB / ng-eNB shall use the UP security activation that the UE used in the last source cell. Otherwise, the target gNB / ng-eNB shall respond with an RRCSetup message to establish a new RRC connection with the UE.

[0039] When the UE receives the RRCResume message, it NG-RAN*K derived based on RRCenc The UE shall decode the message using the newly derived K NG-RAN *K derived based on RRCint By verifying the PDCP MAC-I using <rrcconnectionresume>If the RRCResume message is successfully verified, the UE shall RRCint Delete the key and use the newly derived K NG-RAN * to K RRCint , K. RRCenc , K. UPenc (Optional), and K UPint (Optional) shall be stored as part of the UE's current AS security context. In this case, the UE RRCint and K. RRCenc The UE shall send an integrity protected and encrypted RRCResumeComplete message to the target gNB / ng-eNB on SRB1 using UP security activation that was in use before transitioning to RRCInactive.

[0040] UE <rrcresumerequest>If the UE receives an RRCReject message from the target gNB / ng-eNB in ​​response to the message, the UE shall NG-RAN * Delete the newly derived AS keys used for the connection resumption attempt, including the newly derived RRC integrity key, RRC encryption key, and UP key, and delete the current K in the current AS context. RRCint and K. gNB / NH shall be retained.

[0041] On the UE side, security is fully resumed after receiving and processing the RRCResume message. After receiving and processing the RRC Connection Resume message, the UE can receive data on the DRB. After the RRCResumeComplete message is successfully sent, uplink (UL) data on the DRB can be sent.

[0042] After a successful transition from RRC_INACTIVE to RRC_CONNECTED, the target gNB / ng-eNB performs a path switch procedure with the Access and Mobility Management Function (AMF). The AMF must verify the UE's security capabilities as described in TS33.501, clause 6.7.3.1, and the SMF must verify the UE's UP security policy as described in TS33.501, clause 6.6.1. Summary of the Invention

[0043] Currently, certain challenges exist. For example, the RRCResumeRequest message is sent without protection. For example, the resume cause field of the RRCResumeRequest message is currently not protected by the ResumeMAC-I token. This means that the integrity of the resume cause field of the RRCResumeRequest message is not provided and is not integrity protected. Therefore, a man-in-the-middle (MiTM) attack is possible by changing the resume cause from one value to another using a fake base station. This attack could degrade the type of service the network provides to the UE. Furthermore, because 5G adds "rna-Update" as another value for the resume cause field, if an attacker changes the value of the resume cause field from "emergency" to "rna-Update," the network will not be able to detect the tampering.

[0044] Furthermore, when the UE initiates the RRCResume procedure, it sends an RRCResumeRequest. This RRCResumeRequest contains a ResumeMAC-I based on the old Krrcint and, among other parameters, an I-RNTI. If the new 5G base station (gNB) is busy, the gNB typically sends an RRCReject with a waiting timer. When the UE receives the RRCReject message, it returns to INACTIVE and retries again after the waiting timer expires. When the UE retries, it is expected to use the same I-RNTI and the same old Krrcint key. This means that the second RRCResumeRequest message is exactly the same as the original message before the RRCReject. Therefore, a MiTM-based rogue base station that can capture the first RRCResumeRequest message may be able to send it to the new gNB before the UE's waiting timer expires. The old gNB will then successfully verify the ResumeMAC-I as valid and transfer the UE context to the new gNB. If the UE attempts the resume procedure again, the new target gNB will fail to allocate the UE context, and the resume procedure will fail.

[0045] Therefore, it is important that 5G systems support a mechanism to avoid replaying the RRCResumeRequest message after the UE receives an RRCReject. This point is also emphasized in the Liaison Statement (LS) published in 3GPP document S3-212349, which states: One solution #17 proposes to protect the RRCResumeRequest message. In this solution, when the UE initiates the RRCResume procedure, it must use the entire RRCResumeRequest message, except for ResumeMAC-I / shortResumeMAC-I, as additional input parameters to the VarResumeMac-Input part for calculating ResumeMAC-I / shortResumeMAC-I. The UE must send the calculated ResumeMAC-I / shortResumeMAC-I in the RRCResumeRequest message. The UE and the network negotiate / learn the capability / support of using new versions of ResumeMAC-I / shortResumeMAC-I as follows: · The UE capabilities are part of the RRC message (AS Security Mode Complete (SMComplete) message). The gNB / ng-eNB capabilities are part of the System Information (SI) message (i.e., SIB1, see the closely related function called useFullResumeID in SIB1). The solution under consideration needs to address backward compatibility issues, since if the capabilities of the target gNB (Rel-15 / Rel-16) do not match those of the UE and source gNB, the UE and source gNB will not be aware of the capabilities of the target gNB. Therefore, the verification of ResumeMAC-I / ShortResumeMAC-I may fail. Because the target gNB in ​​Rel-15 / Rel-16 sends limited parameters to the source gNB instead of the entire RRCResumeRequest message, it is not enough for the source gNB to calculate ResumeMAC-I / shortResumeMAC-I for verification.

[0046] An object of the present invention is to improve the security of wireless communication networks with regard to RRC signalling, and in particular to avoid or at least mitigate MiTM fake base station attacks related to RRCResumeRequest messages sent by UEs.

[0047] In one aspect, a method for generating an authentication token is provided. In one embodiment, the method includes obtaining (e.g., generating, receiving, obtaining) a first connection resume request message (e.g., RRCResumeRequest or RRCResumeRequest1) that includes: i) a first field (e.g., a resume cause field) that includes a cause value; ii) a second field (e.g., a resume identity field) that includes an identity value; and iii) a third field (e.g., a token field such as a ResumeMAC-I field) that includes a predefined token value (e.g., all 0s or all 1s). The method also includes using the first connection resume request message to generate an authentication token.

[0048] In another embodiment, a method for generating an authentication token includes obtaining a first resume connection request message that includes a first field containing a cause value / restart cause field and a second field containing an identity value / restart identity field, but does not include any token fields (e.g., a resume MAC-I field), and using the first resume connection request message to generate an authentication token.

[0049] In another embodiment, a method for generating an authentication token includes obtaining a first resume connection request message including: i) a resume cause field including a cause value, ii) a resume identity field including an identity value, and iii) a token field having a first type (e.g., a “NULL” type). The method also includes using the first resume connection request message to generate an authentication token.

[0050] In another aspect, there is provided a computer program comprising instructions that, when executed by processing circuitry of a UE, cause said UE to perform any of the UE methods disclosed herein. In one embodiment, there is provided a carrier comprising the computer program, the carrier being one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium.

[0051] In another aspect, a computer program is provided that includes instructions that, when executed by processing circuitry of a network node / network device, cause the network node / device to perform any of the network node / device methods disclosed herein. In one embodiment, a carrier is provided that includes the computer program, the carrier being one of an electrical signal, an optical signal, a radio signal, and a computer-readable storage medium.

[0052] In another aspect, a UE configured to perform the UE methods disclosed herein is provided. The UE may include a memory and a processing circuit coupled to the memory.

[0053] In another aspect, there is provided a network node / device configured to perform the network node / device methods disclosed herein. The network node / device may include a memory and a processing circuit coupled to the memory.

[0054] An advantage of the embodiments disclosed herein is that they reduce the likelihood of a MiTM fake base station attack when a UE sends an RRCResumeRequest message. Additionally, the embodiments disclosed herein reduce the likelihood of a resumeMAC-I verification failure. [Brief explanation of the drawings]

[0055] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments.

[0056] [Figure 1] FIG. 1 illustrates a network according to some embodiments. [Figure 2] FIG. 1 is a state transition diagram of a UE. [Figure 3] A diagram showing a gNB suspending the RRC connection of a UE. [Figure 4] FIG. 1 is a message flow diagram illustrating processing according to some embodiments. [Figure 5] A diagram showing signaling related to successful RRC resumption. [Figure 6] A diagram showing successful RRC connection resumption fallback to RRC connection establishment. [Figure 7] FIG. 10 illustrates the successful resumption of the RRC connection followed by the release of the network. [Figure 8] FIG. 10 illustrates the successful resumption of the RRC connection followed by the network suspending. [Figure 9] FIG. 1 illustrates an RRC connection resumption request from a UE followed by a rejection from the network. [Figure 10] 1 is a flowchart illustrating a process according to some embodiments. [Figure 11] 1 is a flowchart illustrating a process according to some embodiments. [Figure 12] 1 is a flowchart illustrating a process according to some embodiments. [Figure 13] 1 is a flowchart illustrating a process according to some embodiments. [Figure 14] 1 is a flowchart illustrating a process according to some embodiments. [Figure 15] 1 is a flowchart illustrating a process according to some embodiments. [Figure 16] 1 is a flowchart illustrating a process according to some embodiments. [Figure 17] 1 is a flowchart illustrating a process according to some embodiments. [Figure 18] 1 is a flowchart illustrating a process according to some embodiments. [Figure 19] 1 is a flowchart illustrating a process according to some embodiments. [Figure 20] FIG. 1 is a block diagram of a UE according to some embodiments. [Figure 21] FIG. 1 is a block diagram of a network node according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0057] This disclosure aims to avoid or at least mitigate MiTM fake base station attacks when a UE sends an RRCResumeRequest message. Additionally, this disclosure describes a coordination mechanism to inform the source gNB (when the UE transitions from RRC_INACTIVE to RRC_CONNECTED) whether the target gNB supports the new mechanism proposed herein. This avoids a failed resumeMAC-I verification that would require the UE to set up an RRC connection from scratch.

[0058] Although the embodiments disclosed herein are illustrated in the context of NR, the embodiments are not limited to NR and are also applicable to Long Term Evolution (LTE), where the use of gNB for base station can alternatively be referred to as eNodeB (eNB). It is also contemplated that the present invention is applicable to future networks, such as future sixth generation 3GPP networks. Furthermore, while the embodiments are based on the RRCResumeRequest message, the same embodiments can also be used for the RRCResumeRequest1 message.

[0059] FIG. 1 shows a network 100 including a UE 102, a first network node / network device 104 (e.g., a first gNB or eNB), a second network node 106 (e.g., a second gNB or eNB), and a third network node 108 (e.g., an Access and Mobility Function (AMF) or Mobility Management Entity (MME)). A UE is any communication device capable of communicating with a network node (e.g., a base station) of an access network. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, voice-over-IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback appliances, wearable terminals, wireless endpoints, mobile stations, tablets, laptops, laptop-embedded equipment (LEEs), laptop-mounted equipment (LMEs), smart devices, wireless customer premises equipment (CPEs), in-vehicle wireless terminals / telematics units, connected vehicles, etc. When the UE is in the form of an Internet of Things (IoT) device, it may be a device for use in one or more application domains, including, but not limited to, urban wearable technology, augmented industrial applications, and healthcare.Non-limiting examples of such IoT devices include devices such as: connected refrigerators or freezers, televisions, connected lighting devices, power meters, robot vacuums, voice-controlled smart speakers, home security cameras, motion sensors, thermostats, smoke detectors, door / window sensors, flood / moisture sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smart watches, fitness trackers, augmented reality (AR) or virtual reality (VR) head-mounted displays, haptic or sensory augmentation wearables, water sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and medical equipment of any kind such as heart rate monitors and remote surgical robots.

[0060] In this example, the first and second network nodes 104 and 106 are network nodes of an access network (e.g., a Radio Access Network (RAN)) of the network 100, and the third network node 108 is a network node of a core network of the network 100. Also in this example, the UE 102 has been released to RRC_INACTIVE by the first network node 104 (aka, “gNB1”), and at a later point in time, the UE attempts to transition from RRC_INACTIVE to RRC_CONNECTED toward the second network node 106 (aka, “gNB2”) by sending a connection resume request message.

[0061] RRC connection resumption is available in NR and enhanced Long Term Evolution (eLTE). In particular, as shown in Figure 2, the RRC state model in NR (and eLTE, i.e., LTE connected to the 5G core, 5GC) is updated to introduce a new RRC_INACTIVE state in addition to the existing RRC_IDLE and RRC_CONNECTED states inherited from LTE. In RRC_INACTIVE, the UE context from the previous RRC connection is stored in the radio access network (RAN) and reused the next time an RRC connection is established. The UE context includes information such as the UE security configuration and configured radio bearers. Storing the UE context in the RAN avoids the signaling required for security activation and bearer establishment that is typically required when transitioning from RRC_IDLE to RRC_CONNECTED. This improves latency and reduces signaling overhead.

[0062] The RRC_INACTIVE mode is realized by introducing two new procedures: "RRC connection suspend" (also called RRC connection release with SuspendConfig) and "RRC connection resume." The gNB suspends the connection and moves the UE from RRC_CONNECTED to RRC_INACTIVE by sending an RRC release message with a suspend indication (or configuration) to the UE 102, as shown in Figure 3. This can occur, for example, after the UE has been inactive for a period of time and the gNB's internal inactivity timer expires. Both the UE and the gNB store an identifier (herein referred to as I-RNTI) associated with the UE context. A recent update has revealed that two identifiers, a long I-RNTI and a short I-RNTI, are configured during the suspend configuration. The I-RNTI used upon resumption depends on an indication from the network in the system information of the cell where the UE attempts to resume. The two I-RNTI identifiers are introduced to support the scenario when a UE resumes in a cell that provides the UE with only a small amount of scheduling grants for the first uplink (UL) message. For this reason, two resume messages are introduced: RRCResumeRequest and RRCResumeRequest1. However, in this document, we use "RRC resume request" to refer to both messages.

[0063] Upon transitioning to RRC_CONNECTED, the UE then resumes the connection by sending a connection resume request message (referred to herein as "RRC resume request") to the gNB to which the UE is attempting to resume the connection (note that this may be a different cell / gNB than the cell / gNB where the connection was interrupted), containing the following information: 1) I-RNTI (either long or short I-RNTI, depending on the system information indication), 2) an authentication token (MAC called resumeMAC-I in 3GPP terminology) used to identify and verify the UE when the RRC connection resumes, and 3) an indication of the resume cause, such as mobile originated data.

[0064] The gNB serving the cell to which the UE resumes its connection may be referred to as the target gNB, and the gNB serving the cell to which the UE had suspended its connection may be referred to as the source gNB. To resume the UE's connection, the target gNB determines which gNB is the source gNB (considering the gNB portion of the I-RNTI) and obtains the UE's context from the source gNB (e.g., the target gNB sends a UE Context Request message to the source gNB requesting the UE's context). In this request, the target provides, among other things, the UE_ID and security token received from the UE, and the Cell_ID of the target cell. This is shown in Figure 4.

[0065] The source gNB then locates the UE context based on the I-RNTI and validates the request based on the security token. If successful, the source gNB transfers the UE context to the target gNB, which responds with an RRCresume to the UE to confirm that the connection is resumed. The RRCresume message may also include configurations for re-establishing the resumed radio bearers. Finally, the UE acknowledges receipt of the RRC reestablishment by sending an RRC reestablishment complete.

[0066] The described NR RRC resumption procedure works similarly for LTE (in the state model, the UE is considered to be in RRC_IDLE with context saved) and eLTE (e.g., when LTE is connected to 5GC).

[0067] In NR and eLTE (LTE connected to 5GC), the RRCResume message in response to the RRCResumeRequest is encrypted and integrity protected using a new security key derived based on the stored AS security context. The derivation of this new key (a kind of rekeying) is done as part of the resume procedure, specifically as part of the transmission of the RRCResumeRequest (or RRCResumeRequest1).

[0068] The RRCResume message is not the only message sent in response to the RRCResumeRequest message. In NR and eLTE, after the UE sends a message of type RRCResumeRequest (such as RRCResumeRequest or RRCResumeRequest1), the UE may receive messages on SignalingRadioBearer#1 (SRB1): RRCRelease in suspended configuration, which moves the UE to RRC_INACTIVE; RRCRelease without suspend configuration that moves the UE to RRC_IDLE; RRCResume to move the UE to RRC_CONNECTED.

[0069] Other messages may also be sent: RRCReject with a waiting timer, or RRCSetup (fallback to RRC_IDLE) but SRB0 (i.e. not ciphered or integrity protected). All these possible responses are shown below: Figure 5 shows the signaling associated with a successful RRC resumption, Figure 6 shows the fallback from a successful RRC connection resumption to an RRC connection establishment, Figure 7 shows a network release following a successful RRC connection resumption, Figure 8 shows a network interruption following a successful RRC connection resumption, and Figure 9 shows a rejection from the network following an RRC connection resumption request from the UE.

[0070] A. How the UE calculates the new ResumeMAC-I / shortResumeMAC-I When the UE 102 initiates the RRC resume procedure, the UE generates an RRCResumeRequest message and sends the RRCResumeRequest message to a gNB (e.g., gNB2 in this example). As described above, to generate the RRCResumeRequest message, the UE needs to generate an authentication token (i.e., generate / calculate a ResumeMAC-I or shortResumeMAC-I). As further explained above, to generate the authentication token, the UE uses the integrity protection algorithm (NIA or EIA, 128-NIA1, 128-NIA2, etc.) indicated in the stored AS security context and the following inputs to the integrity protection algorithm: (1) KEY set to the current KRRCint, (2) BEARER (all bits set to 1), (3) DIRECTION (all bits set to 1), (4) COUNT (all bits set to 1), and (5) VarResumeMAC input (or VarShortInactiveMAC input).

[0071] In one embodiment, VarResumeMAC-Input (or VarShortInactiveMAC-Input) used to generate the authentication token includes or consists of i) the value of the resumeCauseIE included in the RRCResumeRequest sent from the UE to the gNB, and ii) the value of the resumeIdenityIE included in the RRCResumeRequest sent from the UE to the gNB, although in some embodiments, VarResumeMAC-Input (or VarShortInactiveMAC-Input) further includes iii) a predefined initial value for ResumeMAC-I / shortResumeMAC-I (e.g., a bit string of all 0s or all 1s, or other predefined bit string).

[0072] In other words, in one embodiment, the UE includes at least a portion of one or more RRCResumeRequest messages in the UE variable VarResumeMac-Input to calculate ResumeMAC-I / shortResumeMAC-I. In one embodiment, the entire initial RRCResumeRequest message is included in the UE variable VarResumeMac-Input in a container (i.e., an OCTET STRING). Since the final RRCResumeRequest message that is finally sent from the UE to the gNB includes the calculated ResumeMAC-I / shortResumeMAC-I fields, at least one (or a combination) of the following options can be applied to avoid incorrect behavior on the UE and network side regarding how to fill these fields:

[0073] Option 1 When the UE 102 includes the initial RRCResumeRequest message in a container (i.e., an OCTET STRING) into the UE variable VarResumeMac-Input, it sets the field ResumeMAC-I / shortResumeMAC-I of the RRCResumeRequest message to an initial value, e.g., a bit string of zeros or ones, or any predefined value. After the field ResumeMAC-I / shortResumeMAC-I is calculated by the UE, the initial RRCResumeRequest message is transformed into a final RRCResumeRequest message that is sent to the gNB, as the field ResumeMAC-I / shortResumeMAC-I is set to the calculated value.

[0074] Option 2 If the UE 102 includes the initial RRCResumeRequest message in the container (i.e., OCTET STRING) of the UE variable VarResumeMac-Input, the UE 102 does not include the fields ResumeMAC-I / shortResumeMAC-I in the initial RRCResumeRequest. This means that the fields ResumeMAC-I / shortResumeMAC-I are included in the final RRCResumeRequest message only after being calculated based on the UE variable VarResumeMac-Input. This means that the fields ResumeMAC-I / shortResumeMAC-I in the RRCResumeRequest message are optional, rather than mandatory. This optionality is to allow ASN.1-compliant encoding for the calculation of ResumeMAC-I / shortResumeMAC-I. They remain mandatory for the final RRCResumeRequest message that the UE sends to the network.

[0075] Option 3 The field ResumeMAC-I / shortResumeMAC-I in the RRCResumeRequest message is declared with two types in the specification: one is "bit string" and the other is "null". Therefore, when the UE sends an RRCResumeRequest message with the ResumeMAC-I / shortResumeMAC-I field to the network, it uses the "bit string" type (same as in the current legacy specification), but when the UE uses the RRCResumeRequest message in the UE variable VarResumeMac-Input to calculate the field ResumeMAC-I / shortResumeMAC-I, it uses the "null" type for the field ResumeMAC-I / shortResumeMAC-I in the UE variable VarResumeMac-Input.

[0076] Therefore, in one option, the UE initiates the RRC resume procedure and includes all fields of the RRCResumeRequest message except for the field ResumeMAC-I / shortResumeMAC-I in the UE variable VarResumeMac-Input to calculate ResumeMAC-I / shortResumeMAC-I. This means that a new structure is created in the UE variable VarResumeMac-Input that contains the fields of the RRCResumeRequest message except for the field ResumeMAC-I / shortResumeMAC-I.

[0077] Example In one example, the VarResumeMAC-Input variable is defined as in Table 4 below.

[0078] Table 4: VarResumeMAC-Input variables VarResumeMAC-Input-r17 ::= SEQUENCE { sourcePhysCellId PhysCellId, targetCellIdentity CellIdentity, source-c-RNTI RNTI-Value rrcResumeRequest CHOICE { rrcResumeReq OCTET STRING, rrcResumeReq1 OCTET STRING } OPTIONAL }

[0079] The rrcResumeRequestIE is an input variable that contains the entire initial RRCResumeRequest message. The field rrcResumeReq is used to contain the initial RRCResumeRequest message, and the field rrcResumeReq1 is used to contain the initial RRCResumeRequest1 message. When including an RRCResumeRequest or RRCResumeRequest1 message, the UE must set the field resumeMAC-I in rrcResumeReq or rrcResumeReq1 to a bit string of zero.

[0080] In another example, the VarResumeMAC-Input variable is defined as in Table 5 below.

[0081] Table 5: VarResumeMAC-Input variables VarResumeMAC-Input-r17 ::= SEQUENCE { sourcePhysCellId PhysCellId, targetCellIdentity CellIdentity, source-c-RNTI RNTI-Value resumeIdentity ShortI-RNTI-Value, resumeCause ResumeCause, }

[0082] The resumeCauseIE is an input variable used to calculate resumeMAC-I and provides the resume cause of the RRC connection resume request provided by higher layers or RRC. The resumeIdentityIE is an input variable used to calculate resumeMAC-I and provides the UE_ID to facilitate UE context lookup in the gNB.

[0083] B. UE and Network Capability Indication for New ResumeMAC-I / shortResumeMAC-I Calculation In one embodiment, the UE indicates to the network whether it supports the new calculation for the field ResumeMAC-I / shortResumeMAC-I. To that end, the UE can indicate to the network that it supports (or does not support) the new calculation for the field ResumeMAC-I / shortResumeMAC-I using at least one (or a combination) of the following options:

[0084] Option 1: The UE indicates support (or non-support) of the new calculation for the field ResumeMAC-I / shortResumeMAC-I in the RRCResumeRequest message, for example, if a new field of type BOOLEAN indicating the new calculation is present.

[0085] Option 2: The UE includes an indication in the UECapabilityInformation message regarding its support (or lack of support) for the new calculation of the ResumeMAC-I / shortResumeMAC-I field.

[0086] Option 3: The UE includes an indication on whether it supports the new calculation of the field ResumeMAC-I / shortResumeMAC-I in a new uplink dedicated RRC message (sent over the network before sending the RRCResumeRequest message).

[0087] Option 4: The UE provides an indication of its support (or lack of support) for the new calculation of the ResumeMAC-I / shortResumeMAC-I field to a core network function, such as the AMF. For example, the UE can provide this indication to the AMF as the UE's network or security capabilities in a NAS message (such as Registration Request). The AMF then provides the UE's indication to a radio access network function, such as a gNB.

[0088] In another embodiment, the network indicates to the UE its support (or lack of support) for the new computation of the fields ResumeMAC-I / shortResumeMAC-I. To that end, the network can use at least one (or a combination) of the following options to indicate to the network its support (or lack of support) for the new computation of the ResumeMAC-I / shortResumeMAC-I fields:

[0089] Option 1: The network includes an indication of whether it supports (or does not support) the new calculation of the ResumeMAC-I / shortResumeMAC-I fields in a System Information Block (SIB) sent to the UE via broadcast or dedicated signaling. A possible SIB for including such an indication could be SIB1, but could also be any other SIB that the UE can receive, or even an entirely new SIB created for this purpose.

[0090] Option 2: The network includes an indication of support (or lack of support) for the new calculation of the fields ResumeMAC-I / shortResumeMAC-I in an existing DL RRC dedicated message. Possible candidates for the DL RRC dedicated message are RRCRelease, RRCReconfiguration, or DLInformationTransfer.

[0091] Option 3: The network includes an indication of support (or non-support) of the new calculation of field ResumeMAC-I / shortResumeMAC-I in the new Medium Access Control Element (MAC-CE) or new Downlink Control Information (DCI) format.

[0092] In one embodiment, the network can use the indication sent to the UE to indicate support for the new calculation for field ResumeMAC-I / shortResumeMAC-I as a means to turn this feature on or off. In fact, the network can use this indication to indicate to the UE whether to use the new or old calculation.

[0093] In another embodiment, the indication sent by the UE or the network is a one-bit indication, where "1" means support for a new calculation for field ResumeMAC-I / shortResumeMAC-I and "0" means that a new calculation for field ResumeMAC-I / shortResumeMAC-I is not supported, or vice versa. In yet another embodiment, the indication sent by the UE or the network is a Boolean value, where "true" means support for a new calculation for field ResumeMAC-I / shortResumeMAC-I and "false" means that a new calculation for field ResumeMAC-I / shortResumeMAC-I is not supported, or vice versa. In yet another embodiment, the indication is just a field (it doesn't matter what type it is), where the mere presence of this field means that a new calculation for field ResumeMAC-I / shortResumeMAC-I is supported, and the absence of this field means that a new calculation for field ResumeMAC-I / shortResumeMAC-I is not supported.

[0094] Example The IE UE-NR-Capability is used to convey UE radio access capability parameters for NR (see 3GPP TS38.306 (V16.5.0, etc.)). In one embodiment, the UE-NR-Capability information element is defined as shown in Table 6 below.

[0095] Table 6: UE-NR-Capability IE UE-NR-Capability ::= SEQUENCE { accessStratumRelease AccessStratumRelease, pdcp-Parameters PDCP-Parameters, rlc-Parameters RLC-Parameters OPTIONAL, mac-Parameters MAC-Parameters OPTIONAL, phy-Parameters Phy-Parameters, rf-Parameters RF-Parameters, measAndMobParameters MeasAndMobParameters OPTIONAL, fdd-Add-UE-NR-Capabilities UE-NR-CapabilityAddXDD-Mode OPTIONAL, tdd-Add-UE-NR-Capabilities UE-NR-CapabilityAddXDD-Mode OPTIONAL, fr1-Add-UE-NR-Capabilities UE-NR-CapabilityAddFRX-Mode OPTIONAL, fr2-Add-UE-NR-Capabilities UE-NR-CapabilityAddFRX-Mode OPTIONAL, featureSets FeatureSets OPTIONAL, featureSetCombinations SEQUENCE (SIZE (1..maxFeatureSetCombinations)) OF FeatureSetCombination OPTIONAL, lateNonCriticalExtension OCTET STRING (CONTAINING UE-NR-Capability-v15c0) OPTIONAL, nonCriticalExtension UE-NR-Capability-v1530 OPTIONAL } -- Regular non-critical extensions: UE-NR-Capability-v1530 ::= SEQUENCE { fdd-Add-UE-NR-Capabilities-v1530 UE-NR-CapabilityAddXDD-Mode-v1530 OPTIONAL, tdd-Add-UE-NR-Capabilities-v1530 UE-NR-CapabilityAddXDD-Mode-v1530 OPTIONAL, dummy ENUMERATED {supported} OPTIONAL, interRAT-Parameters InterRAT-Parameters OPTIONAL, inactiveState ENUMERATED {supported} OPTIONAL, delayBudgetReporting ENUMERATED {supported} OPTIONAL, nonCriticalExtension UE-NR-Capability-v1540 OPTIONAL } UE-NR-Capability-v1540 ::= SEQUENCE { sdap-Parameters SDAP-Parameters OPTIONAL, overheatingInd ENUMERATED {supported} OPTIONAL, ims-Parameters IMS-Parameters OPTIONAL, fr1-Add-UE-NR-Capabilities-v1540 UE-NR-CapabilityAddFRX-Mode-v1540 OPTIONAL, fr2-Add-UE-NR-Capabilities-v1540 UE-NR-CapabilityAddFRX-Mode-v1540 OPTIONAL, fr1-fr2-Add-UE-NR-Capabilities UE-NR-CapabilityAddFRX-Mode OPTIONAL, nonCriticalExtension UE-NR-Capability-v1550 OPTIONAL } UE-NR-Capability-v1550 ::= SEQUENCE { reducedCP-Latency ENUMERATED {supported} OPTIONAL, nonCriticalExtension UE-NR-Capability-v1560 OPTIONAL } UE-NR-Capability-v1560 ::= SEQUENCE { nrdc-Parameters NRDC-Parameters OPTIONAL, receivedFilters OCTET STRING (CONTAINING UECapabilityEnquiry-v1560-IEs) OPTIONAL, nonCriticalExtension UE-NR-Capability-v1570 OPTIONAL } UE-NR-Capability-v1570 ::= SEQUENCE { nrdc-Parameters-v1570 NRDC-Parameters-v1570 OPTIONAL, nonCriticalExtension UE-NR-Capability-v1610 OPTIONAL } -- Late non-critical extensions: UE-NR-Capability-v15c0 ::= SEQUENCE { nrdc-Parameters-v15c0 NRDC-Parameters-v15c0 OPTIONAL, partialFR2-FallbackRX-Req ENUMERATED {true} OPTIONAL, nonCriticalExtension SEQUENCE {} OPTIONAL } -- Regular non-critical extensions: UE-NR-Capability-v1610 ::= SEQUENCE { inDeviceCoexInd-r16 ENUMERATED {supported} OPTIONAL, dl-DedicatedMessageSegmentation-r16 ENUMERATED {supported} OPTIONAL, nrdc-Parameters-v1610 NRDC-Parameters-v1610 OPTIONAL, powSav-Parameters-r16 PowSav-Parameters-r16 OPTIONAL, fr1-Add-UE-NR-Capabilities-v1610 UE-NR-CapabilityAddFRX-Mode-v1610 OPTIONAL, fr2-Add-UE-NR-Capabilities-v1610 UE-NR-CapabilityAddFRX-Mode-v1610 OPTIONAL, bh-RLF-Indication-r16 ENUMERATED {supported} OPTIONAL, directSN-AdditionFirstRRC-IAB-r16 ENUMERATED {supported} OPTIONAL, bap-Parameters-r16 BAP-Parameters-r16 OPTIONAL, referenceTimeProvision-r16 ENUMERATED {supported} OPTIONAL, sidelinkParameters-r16 SidelinkParameters-r16 OPTIONAL, highSpeedParameters-r16 HighSpeedParameters-r16 OPTIONAL, mac-Parameters-v1610 MAC-Parameters-v1610 OPTIONAL, mcgRLF-RecoveryViaSCG-r16 ENUMERATED {supported} OPTIONAL, resumeWithStoredMCG-SCells-r16 ENUMERATED {supported} OPTIONAL, resumeWithStoredSCG-r16 ENUMERATED {supported} OPTIONAL, resumeWithSCG-Config-r16 ENUMERATED {supported} OPTIONAL, ue-BasedPerfMeas-Parameters-r16 UE-BasedPerfMeas-Parameters-r16 OPTIONAL, son-Parameters-r16 SON-Parameters-r16 OPTIONAL, onDemandSIB-Connected-r16 ENUMERATED {supported} OPTIONAL, nonCriticalExtension UE-NR-Capability-v1640 OPTIONAL } UE-NR-Capability-v1640 ::= SEQUENCE { redirectAtResumeByNAS-r16 ENUMERATED {supported} OPTIONAL, phy-ParametersSharedSpectrumChAccess-r16 Phy-ParametersSharedSpectrumChAccess-r16 OPTIONAL, nonCriticalExtension UE-NR-Capability-v17xy OPTIONAL } UE-NR-Capability-v17xy ::= SEQUENCE { newCalcResumeMAC-I-r17 ENUMERATED {supported} OPTIONAL, nonCriticalExtension SEQUENCE {} OPTIONAL } UE-NR-CapabilityAddXDD-Mode ::= SEQUENCE { phy-ParametersXDD-Diff Phy-ParametersXDD-Diff OPTIONAL, mac-ParametersXDD-Diff MAC-ParametersXDD-Diff OPTIONAL, measAndMobParametersXDD-Diff MeasAndMobParametersXDD-Diff OPTIONAL } UE-NR-CapabilityAddXDD-Mode-v1530 ::= SEQUENCE { eutra-ParametersXDD-Diff EUTRA-ParametersXDD-Diff } UE-NR-CapabilityAddFRX-Mode ::= SEQUENCE { phy-ParametersFRX-Diff Phy-ParametersFRX-Diff OPTIONAL, measAndMobParametersFRX-Diff MeasAndMobParametersFRX-Diff OPTIONAL } UE-NR-CapabilityAddFRX-Mode-v1540 ::= SEQUENCE { ims-ParametersFRX-Diff IMS-ParametersFRX-Diff OPTIONAL } UE-NR-CapabilityAddFRX-Mode-v1610 ::= SEQUENCE { powSav-ParametersFRX-Diff-r16 PowSav-ParametersFRX-Diff-r16 OPTIONAL, mac-ParametersFRX-Diff-r16 MAC-ParametersFRX-Diff-r16 OPTIONAL } BAP-Parameters-r16 ::= SEQUENCE { flowControlBH-RLC-ChannelBased-r16 ENUMERATED {supported} OPTIONAL, flowControlRouting-ID-Based-r16 ENUMERATED {supported} OPTIONAL }

[0096] Comparing the definition shown in Table 6 above with the current definition in 3GPP TS38.306 (e.g., V16.5.0), we see that "nonCriticalExtension" is a UE-NR-Capability-v17xyIE, which contains the newCalcResumeMAC-I-r17IE, which is used to indicate whether the UE supports new calculation capabilities.

[0097] In one embodiment, the network (e.g., gNB) uses SIB1 to indicate support for the new calculation of resumeMAC-I as a capability. SIB1, which the gNB transmits on the Broadcast Control Channel (BCCH), contains information relevant when evaluating whether a UE is authorized to access the cell and defines the scheduling of other system information. It also contains radio resource configuration information common to all UEs and barring information that applies to unified access control.

[0098] In one embodiment, SIB1 is defined as shown in Table 7 below.

[0099] Table 7:SIB1 SIB1 ::= SEQUENCE { cellSelectionInfo SEQUENCE { q-RxLevMin Q-RxLevMin, q-RxLevMinOffset INTEGER (1..8) OPTIONAL, -- Need S q-RxLevMinSUL Q-RxLevMin OPTIONAL, -- Need R q-QualMin Q-QualMin OPTIONAL, -- Need S q-QualMinOffset INTEGER (1..8) OPTIONAL -- Need S } OPTIONAL, -- Cond Standalone cellAccessRelatedInfo CellAccessRelatedInfo, connEstFailureControl ConnEstFailureControl OPTIONAL, -- Need R si-SchedulingInfo SI-SchedulingInfo OPTIONAL, -- Need R servingCellConfigCommon ServingCellConfigCommonSIB OPTIONAL, -- Need R ims-EmergencySupport ENUMERATED {true} OPTIONAL, -- Need R eCallOverIMS-Support ENUMERATED {true} OPTIONAL, -- Need R ue-TimersAndConstants UE-TimersAndConstants OPTIONAL, -- Need R uac-BarringInfo SEQUENCE { uac-BarringForCommon UAC-BarringPerCatList OPTIONAL, -- Need S uac-BarringPerPLMN-List UAC-BarringPerPLMN-List OPTIONAL, -- Need S uac-BarringInfoSetList UAC-BarringInfoSetList, uac-AccessCategory1-SelectionAssistanceInfo CHOICE { plmnCommon UAC-AccessCategory1-SelectionAssistanceInfo, individualPLMNList SEQUENCE (SIZE (2..maxPLMN)) OF UAC-AccessCategory1-SelectionAssistanceInfo } OPTIONAL -- Need S } OPTIONAL, -- Need R useFullResumeID ENUMERATED {true} OPTIONAL, -- Need R lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SIB1-v1610-IEs OPTIONAL } SIB1-v1610-IEs ::= SEQUENCE { idleModeMeasurementsEUTRA-r16 ENUMERATED{true} OPTIONAL, -- Need R idleModeMeasurementsNR-r16 ENUMERATED{true} OPTIONAL, -- Need R posSI-SchedulingInfo-r16 PosSI-SchedulingInfo-r16 OPTIONAL, -- Need R nonCriticalExtension SIB1-v1630-IEs OPTIONAL } SIB1-v1630-IEs ::= SEQUENCE { uac-BarringInfo-v1630 SEQUENCE { uac-AC1-SelectAssistInfo-r16 SEQUENCE (SIZE (2..maxPLMN)) OF UAC-AC1-SelectAssistInfo-r16 } OPTIONAL, -- Need R nonCriticalExtension SIB1-v17xy-IEs OPTIONAL } SIB1-v17xy-IEs ::= SEQUENCE { newCalcResumeMAC-I-r17 ENUMERATED {true} OPTIONAL, -- Need R nonCriticalExtension SEQUENCE {} OPTIONAL } UAC-AccessCategory1-SelectionAssistanceInfo ::= ENUMERATED {a, b, c} UAC-AC1-SelectAssistInfo-r16 ::= ENUMERATED {a, b, c, notConfigured}

[0100] Comparing the definition shown in Table 7 above with the current definition, "nonCriticalExtension" is an SIB1-v17xy-IEsIE, which contains the newCalcResumeMAC-I-r17IE used to indicate whether the cell supports new calculation of resumeMAC-I according to the fields contained in the RRCResumeRequest or RRCResumeRequest1 message. Table 8 below provides a description of the SIB1 fields.

[0101] Table 8: SIB1 Field Descriptions cellSelectionInfo Cell selection parameters for the serving cell. eCallOver IMS-Support Indicates whether the cell supports eCall over IP Multimedia Subsystem (IMS) services as defined in TS23.501 (e.g. V17.1.1). If not present, eCall over IMS is not supported by the network in the cell. idleModeMeasurementsEUTRA This field indicates that a UE configured for Evolved Universal Mobile Telecommunications System Terrestrial Radio Access (EUTRA) idle / inactive measurements shall perform measurements while camped on this cell and report the availability of these measurements when establishing or resuming a connection on this cell. Without this capability, the UE does not need to perform EUTRA idle / inactive measurements. idleModeMeasurementsNR This field indicates that a UE configured for NR idle / inactive measurements must perform measurements while camping on this cell and report the availability of these measurements when establishing or resuming a connection on this cell. If not present, the UE does not need to perform NR idle / inactive measurements. ims-EmergencySupport Indicates whether the cell supports IMS emergency bearer services for UEs in restricted service mode. If not present, IMS emergency calls are not supported by the network in the cell for UEs in restricted service mode. newCalcResumeMAC-I According to a field contained in the RRCResumeRequest or RRCResumeRequest1 message, the cell indicates whether it supports a new calculation of resumeMAC-I. q-QualMin The parameter "Qqualmin" of TS38.304 (e.g. V16.4.0) that applies to the serving cell. If this field is not present, the UE shall apply a negative infinity (default) value for Qqualmin. q-QualMinOffset TS38.304 parameter "Qqualminoffset". Actual value Qqualminoffset = field value [dB]. If the field is not present, the UE applies a (default) value of 0 dB for Qqualminoffset. Affects the minimum required quality level in the cell. q-RxLevMin TS38.304 parameter "Qrxlevmin", which applies to the serving cell. q-RxLevMinOffset TS38.304 parameter "Qrxlevminoffset". Actual value Qrxlevminoffset = field value * 2 [dB]. If not present, the UE applies the (default) value 0 dB to Qrxlevminoffset. Affects the minimum required Rx level in the cell. q-RxLevMinSUL TS38.304 parameter "Qrxlevmin", which applies to the serving cell. servingCellConfigCommon Serving cell configuration. uac-AccessCategory1-SelectionAssistanceInfo Information used to determine whether Access Category 1 applies to the UE, as defined in TS 22.261 (e.g., V17.7.0). If plmnCommon is selected, UAC-AccessCategory1-SelectionAssistanceInfo applies to all public land mobile networks (PLMNs) in plmn-IdentityList. If individualPLMNList is selected, the first entry in the list corresponds to the first PLMN in plmn-IdentityList and the second entry in the list corresponds to the second PLMN in plmn-IdentityList. If uac-AC1-SelectAssistInfo-r16 is present, the UE shall ignore uac-AccessCategory1-SelectionAssistanceInfo. uac-AC1-SelectAssistInfo Information used to determine whether Access Category 1 applies to a UE, as defined in TS 22.261 (e.g. V17.7.0). The first entry in the list corresponds to the first PLMN in plmn-IdentityList, the second entry in the list corresponds to the second PLMN in plmn-IdentityList, etc. The value notConfigured indicates that AccessCategory1 is not configured for the corresponding PLMN. uac-BarringForCommon Access control parameters common to each access category. Common values ​​are used for all PLMNs unless overridden by PLMN-specific configuration provided in uac-BarringPerPLMN-List. Parameters are specified by providing an index into a set of configurations (uac-BarringInfoSetList). UE behavior in the absence of this field is specified in clause 5.3.14.2 (e.g. V16.4.1) of TS38.331. ue-TimersAndConstants Timer and constant value used by the UE. A cell acting as a PCell always provides this field. useFullResumeID Indicates which resume identifier and resume request message to use. If the field is present, the UE shall use fullI-RNTI and RRCResumeRequest1, if the field is not present, it shall use shortI-RNTI and RRCResumeRequest. Conditional Presence: Standalone Description: This field is required for cells that support standalone operation and is absent otherwise.

[0102] In one embodiment, the network indicates support for the new calculation of resumeMAC-I in an RRCRelease message, which is a message sent from the gNB to the UE on the Downlink Control Channel (DCCH). The RRCRelease message is used to command the release of the RRC connection or the suspension of the RRC connection. In one embodiment, RRCRelease is defined as shown in Table 9 below.

[0103] Table 9: RRCRelease RRCRelease ::= SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { rrcRelease RRCRelease-IEs, criticalExtensionsFuture SEQUENCE {} } } RRCRelease-IEs ::= SEQUENCE { redirectedCarrierInfo RedirectedCarrierInfo OPTIONAL, -- Need N cellReselectionPriorities CellReselectionPriorities OPTIONAL, -- Need R suspendConfig SuspendConfig OPTIONAL, -- Need R deprioritisationReq SEQUENCE { deprioritisationType ENUMERATED {frequency, nr}, deprioritisationTimer ENUMERATED {min5, min10, min15, min30} } OPTIONAL, -- Need N lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension RRCRelease-v1540-IEs OPTIONAL } RRCRelease-v1540-IEs ::= SEQUENCE { waitTime RejectWaitTime OPTIONAL, -- Need N nonCriticalExtension RRCRelease-v1610-IEs OPTIONAL } RRCRelease-v1610-IEs ::= SEQUENCE { voiceFallbackIndication-r16 ENUMERATED {true} OPTIONAL, -- Need N measIdleConfig-r16 SetupRelease {MeasIdleConfigDedicated-r16} OPTIONAL, -- Need M nonCriticalExtension RRCRelease-v17xy-IEs OPTIONAL } RRCRelease-v17xy-IEs ::= SEQUENCE { newCalcResumeMAC-I-r17 ENUMERATED {true} OPTIONAL, -- Need R nonCriticalExtension SEQUENCE {} OPTIONAL } RedirectedCarrierInfo ::= CHOICE { nr CarrierInfoNR, eutra RedirectedCarrierInfo-EUTRA, ... } RedirectedCarrierInfo-EUTRA ::= SEQUENCE { eutraFrequency ARFCN-ValueEUTRA, cnType ENUMERATED {epc,fiveGC} OPTIONAL -- Need N } CarrierInfoNR ::= SEQUENCE { carrierFreq ARFCN-ValueNR, ssbSubcarrierSpacing SubcarrierSpacing, smtc SSB-MTC OPTIONAL, -- Need S ... } SuspendConfig ::= SEQUENCE { fullI-RNTI I-RNTI-Value, shortI-RNTI ShortI-RNTI-Value, ran-PagingCycle PagingCycle, ran-NotificationAreaInfo RAN-NotificationAreaInfo OPTIONAL, -- Need M t380 PeriodicRNAU-TimerValue OPTIONAL, -- Need R nextHopChainingCount NextHopChainingCount, ... } PeriodicRNAU-TimerValue ::= ENUMERATED { min5, min10, min20, min30, min60, min120, min360, min720} CellReselectionPriorities ::= SEQUENCE { freqPriorityListEUTRA FreqPriorityListEUTRA OPTIONAL, -- Need M freqPriorityListNR FreqPriorityListNR OPTIONAL, -- Need M t320 ENUMERATED {min5, min10, min20, min30, min60, min120, min180, spare1} OPTIONAL, -- Need R ... } PagingCycle ::= ENUMERATED {rf32, rf64, rf128, rf256} FreqPriorityListEUTRA ::= SEQUENCE (SIZE (1..maxFreq)) OF FreqPriorityEUTRA FreqPriorityListNR ::= SEQUENCE (SIZE (1..maxFreq)) OF FreqPriorityNR FreqPriorityEUTRA ::= SEQUENCE { carrierFreq ARFCN-ValueEUTRA, cellReselectionPriority CellReselectionPriority, cellReselectionSubPriority CellReselectionSubPriority OPTIONAL -- Need R } FreqPriorityNR ::= SEQUENCE { carrierFreq ARFCN-ValueNR, cellReselectionPriority CellReselectionPriority, cellReselectionSubPriority CellReselectionSubPriority OPTIONAL -- Need R } RAN-NotificationAreaInfo ::= CHOICE { cellList PLMN-RAN-AreaCellList, ran-AreaConfigList PLMN-RAN-AreaConfigList, ... } PLMN-RAN-AreaCellList ::= SEQUENCE (SIZE (1.. maxPLMNIdentities)) OF PLMN-RAN-AreaCell PLMN-RAN-AreaCell ::= SEQUENCE { plmn-Identity PLMN-Identity OPTIONAL, -- Need S ran-AreaCells SEQUENCE (SIZE (1..32)) OF CellIdentity } PLMN-RAN-AreaConfigList ::= SEQUENCE (SIZE (1..maxPLMNIdentities)) OF PLMN-RAN-AreaConfig PLMN-RAN-AreaConfig ::= SEQUENCE { plmn-Identity PLMN-Identity OPTIONAL, -- Need S ran-Area SEQUENCE (SIZE (1..16)) OF RAN-AreaConfig } RAN-AreaConfig ::= SEQUENCE { trackingAreaCode TrackingAreaCode, ran-AreaCodeList SEQUENCE (SIZE (1..32)) OF RAN-AreaCode OPTIONAL -- Need R } -- TAG-RRCRELEASE-STOP -- ASN1STOP

[0104] Table 10 below provides a description of the RRCRelease-IEs fields. Table 10: RRCRelease-IE Field Descriptions cnType Indicates that the UE is redirected to EvolvedPacketCore (EPC) or 5GC. deprioritizationReq Indicates whether the current frequency or radio access technology (RAT) is non-preferred. deprioritizationTimer Indicates the period during which either the current carrier frequency or NR is non-prioritized. The value minN corresponds to N minutes. measIdleConfig Indicates the measurement configuration that the UE will store and use during RRC_IDLE or RRC_INACTIVE. newCalcResumeMAC-I A field included in the RRCResumeRequest or RRCResumeRequest1 message indicates whether the cell supports new calculation of resumeMAC-I. suspendConfig This indicates the configuration of the RRC_INACTIVE state. The network does not set suspendConfig if the network redirects the UE to an inter-RAT carrier frequency or if the UE has a Dual Active Protocol Stack (DAPS) bearer configured. redirectedCarrierInfo Indicates the carrier frequency (downlink in case of Frequency Division Duplex (FDD)) and is used to redirect the UE to an NR or inter-RAT carrier frequency by cell selection upon transition to RRC_IDLE or RRC_INACTIVE as specified in TS38.304 (e.g., V16.4.0). Based on the UE capabilities, the network can include redirectedCarrierInfo in the RRCRelease message along with suspendConfig if this message is sent in response to an RRCResumeRequest or an NAS layer triggered RRCResumeRequest1 (see 5.3.1.4 of TS24.501 (e.g., V17.3.0)). voiceFallbackIndication Indicates that the Evolved Packet System (EPS) fallback for IMS voice triggers RRC release as specified in TS 23.502 (e.g., V17.1.0). CarrierInfoNR Field Description carrierFreq Indicates the redirected NR frequency. ssbSubcarrierSpacing Subcarrier spacing of the synchronization signal block (SSB) on redirected SSB frequencies. Only 15 kHz or 30 kHz (FR1), 120 kHz or 240 kHz (FR2) apply. smtc SSB period / offset / duration configuration for redirected SSB frequency, based on the PCell timing reference. If this field is not present, the UE uses the SSB-based measurement timing configuration (SMTC) set to measObjectNR with the same SSB frequency and subcarrier spacing. RAN-NotificationAreaInfo field description cellList A list of cells configured as RAN areas. ran-AreaConfigList A list of RAN area codes or RA codes as RAN areas. PLMN-RAN-AreaConfig Field Description plmn-Identity The PLMN_ID to which the cells in the ran-Area belong. If this field is not present, the UE uses the ID of the registered PLMN. ran-AreaCodeList RAN-AreaCode of all PLMNs (total number not to exceed 32). ran-Area Indicates whether to use Tracking Area (TA) codes or RAN area codes for RAN notification areas. The network configures the UE using only TA codes or both TA codes and RAN area codes. The total number of TACs across all PLMNs does not exceed 16. PLMN-RAN-AreaCell Field Description plmn-Identity PLMN_ID to which the cells in ran-AreaCells belong. If this field is not present, the UE uses the ID of the registered PLMN. ran-AreaCells The number of cells in all PLMNs (total not to exceed 32). SuspendConfig field description ran-NotificationAreaInfo The network ensures that a UE in RRC_INACTIVE always has a valid ran-NotificationAreaInfo. ran-PagingCycle Refers to a UE-specific cycle of RAN-initiated paging. The value rf32 corresponds to 32 radio frames, and the value rf64 corresponds to 64 radio frames. t380 Refers to the timer that triggers the UE periodic RAN-based Notification Area Update (RNAU) procedure. The value min5 corresponds to 5 minutes, and the value min10 corresponds to 10 minutes.

[0105] C. Inter-gNB Capability Indication of New ResumeMAC-I / shortResumeMAC-I Calculation In one embodiment, if the UE attempts to resume at a gNB (i.e., a target gNB) different from the gNB that previously released the UE to the RRC_INACTIVE state (i.e., the source gNB), the target gNB, when triggering the Search UE Context Request procedure, includes in the Search UE Context Request message: i) a support indication indicating that it supports (or does not support) a new calculation for the fields ResumeMAC-I / shortResumeMAC-I, and ii) all fields included in VarResumeMac-Input.

[0106] Therefore, the source gNB can determine whether the target gNB supports (or does not support) the new calculation of resumeMAC-I from the support indication itself or only by the presence of all fields included in VarResumeMac-Input. Furthermore, how the target gNB includes all fields of VarResumeMac-Input can be done by a container (i.e., an OCTET STRING) in which all fields of VarResumeMac-Input are included. Otherwise, another solution is for the target gNB to include the fields one by one in different fields.

[0107] In another embodiment, such an indication from the target gNB to the source gNB is included in new or existing X2 / Xn signaling / messages, or alternatively, such an indication is included in new or existing inter-node RRC messages.

[0108] In one embodiment, if the source gNB does not receive an indication from the target gNB that the target gNB supports the new calculation of the fields ResumeMAC-I / shortResumeMAC-I, the source gNB uses the old / traditional calculation to verify the UE's ResumeMAC-I / shortResumeMAC-I. Further, if the source gNB receives an indication from the target gNB that the target gNB supports the new calculation for calculating and verifying the ResumeMAC-I / shortResumeMAC-I fields, the source gNB calculates and verifies the UE's ResumeMAC-I / shortResumeMAC-I using the new calculation.

[0109] The target gNB may provide resumeMAC-I and a modified version of the resume request to the source gNB, in which case the source gNB simply uses the provided resume request to calculate a version of resumeMAC-I and compares it with the provided resumeMAC-I to verify the UE (i.e., determine that the UE is authentic).

[0110] The target gNB may provide resumeMAC-I and the resume request (received from the UE) to the source gNB, in which case the source gNB prepares a modified version of the provided resume request message and uses it to calculate the source gNB's version of resumeMAC-I and compare it with the provided version of resumeMAC-I.

[0111] The target gNB may provide the resume request (received from the UE) to the source gNB, in which case the source gNB extracts resumeMAC-I from the provided resume request message, prepares a modified version of the provided resume request message, calculates the source gNB's version of resumeMAC-I using the modified version, and compares it with the provided version of resumeMAC-I (i.e., the resumeMAC-I extracted from the resume request received from the target gNB).

[0112] Preparing a modified version of a history request means modifying the resumeMAC-I field in the manner described above in this document (e.g., replacing the value contained in the resumeMAC-I field with a predefined value, removing the field, replacing it with a different type, etc.).

[0113] Example In some embodiments, the target gNB may indicate support for a new calculation of resumeMAC-I to the source gNB using a Search UE Context Request message. This message is sent by the new NG-RAN node to request the old NG-RAN node to transfer the UE context to the new NG-RAN. In one embodiment, the Search UE Context Request message is defined as shown in Table 11 below.

[0114] Table 11: RetrieveUEContextRequest message TIFF0007738734000001.tif106170TIFF0007738734000002.tif183170TIFF00077387340 00003.tif161170TIFF0007738734000004.tif208170TIFF0007738734000005.tif166170

[0115] 20 is a block diagram of a UE 102, according to some embodiments. As shown in FIG. 20, the UE 102 includes one or more processors (P) 2055 (e.g., one or more general-purpose microprocessors and / or one or more other processors, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc.), a transmitter (Tx) 2045 and a receiver (Rx) 2047 coupled to an antenna arrangement 2049 including one or more antennas, through which the UE 102 transmits and receives data (e.g., transmits / receives data wirelessly), and a local storage device (a.k.a., a "data storage system") 2008, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments in which the PC 2002 includes a programmable processor, a computer program product (CPP) 2041 may be provided. The CPP 2041 includes a computer-readable medium (CRM) 2042 that stores a computer program (CP) 2043, which includes computer-readable instructions (CRI) 2044. The CRM 2042 may be a non-transitory computer-readable medium, such as, for example, a magnetic medium (e.g., a hard disk), an optical medium, a memory device (e.g., a random access memory, a flash memory), or the like. In some embodiments, the CRI 2044 of the computer program 2043, when executed by the PC 2002, is configured such that the CRI causes the UE 102 to perform the steps described herein (e.g., steps described herein with reference to flowcharts). In other embodiments, the UE 102 may be configured to perform the steps described herein without the need for code. That is, for example, the PC 2002 may simply be comprised of one or more ASICs. Thus, features of the embodiments described herein may be implemented in hardware and / or software.

[0116] 21 is a block diagram of a network node (e.g., any one of network nodes 104, 106, or 108) according to some embodiments. As shown in FIG. 21, network node 104, 106, or 108 may comprise processing circuitry (PC) 2102, which may include one or more processors (P) 2155 (e.g., a general-purpose microprocessor and / or one or more other processors, e.g., an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc.), which may be co-located in a single housing or in a single data center, or may be geographically distributed (i.e., the network node may be a distributed computing device); at least one network interface 2148 including a transmitter (Tx) 2145 and a receiver (Rx) 2147 to enable the PC 2102 to transmit data to and receive data from other nodes connected to the network 110 (e.g., an Internet Protocol (IP) network) to which it is indirectly (or indirectly) connected (e.g., the network interface 2148 may be wirelessly connected to the network 110, in which case the network interface 2148 is connected to an antenna arrangement); and a storage device (a.k.a., a "data storage system") 2108, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments in which the PC 2102 includes a programmable processor, a computer program product (CPP) 2141 may be provided. The CPP 2141 includes a computer readable medium (CRM) 2142 that stores a computer program (CP) 2143 including computer readable instructions (CRI) 2144. The CRM2142 may be a non-transitory computer-readable medium such as a magnetic medium (e.g., a hard disk), an optical medium, or a memory device (e.g., a random access memory, a flash memory).In some embodiments, the CRI 2144 of the computer program 2143, when executed by the PC 2102, is configured such that the CRI causes the network node to perform the steps described herein (e.g., steps described herein with reference to one or more of the flowcharts). In other embodiments, the network node may be configured to perform the steps described herein without the need for code. That is, for example, the PC 2102 may simply be comprised of one or more ASICs. Thus, features of the embodiments described herein may be implemented in hardware and / or software.

[0117] Overview of various embodiments Embodiment A - Option 1 A1. A method (1000) for generating an authentication token (see FIG. 10), comprising: obtaining (e.g., generating, receiving, obtaining) (s1002) a first connection resume request message including: i) a first field / resume cause field including a cause value; ii) a second field / resume identity field including an identity value; and iii) a third field / token field (e.g., a ResumeMAC-I field) including a predefined token value (e.g., all 0s or all 1s); and using the first connection resumption request message to generate an authentication token (s1004). A1.1. The method of embodiment A1, wherein the third field is a ResumeMAC-I field or a ShortMAC-I field.

[0118] Embodiment A - Option 2 A2. A method (1100) for generating an authentication token (see FIG. 11), comprising: obtaining (s1102) a first connection resume request message that includes a first field including a cause value / resume cause field and a second field including an identity value / resume identity field, but does not include any token field (e.g., a ResumeMAC-I field); and using (s1104) the first connection resume request message to generate an authentication token. A2.1. The method of embodiment A1 or A2, wherein the first field is a resume cause field, the cause value indicates a resume cause of the connection resume request, the second field is a resume identity field, and the identity value is a value of type Radio Network Temporary Identifier (RNTI).

[0119] Embodiment A - Option 3 A3. A method (1200) for generating an authentication token (see FIG. 12), comprising: obtaining (s1202) a first connection resume request message including: i) a resume cause field including a cause value; ii) a resume identity field including an identity value; and iii) a token field having a first type (e.g., a "NULL" type); and using (s1204) the first connection resume request message to generate an authentication token.

[0120] A4. A method according to any one of the preceding embodiments, wherein the first connection resumption request message is encoded according to Unaligned Packed Encoding Rules (UPER).

[0121] A5. A method as in any one of the preceding embodiments, wherein the method is performed by a user equipment (UE) / communication device.

[0122] A6. The method of embodiment A5, further comprising the UE generating a second connection resume request message including: i) a resume cause field including the cause value; ii) an identity field including the resume identity value; and iii) a token field including the generated authentication token; and transmitting the second connection resume request message to a network node of an access network. A6.1. The method of embodiment A6 when dependent on embodiment A3, wherein the first type is NULL and the token field of the second resume-connection-request message has a type of bit string.

[0123] A7. The method of any one of embodiments A1 to A4, wherein the method is performed by a first network node / network device (e.g., a source gNB) of an access network.

[0124] A8. The method of embodiment A7, further comprising receiving a message sent by a second network node / network device (e.g., a target gNB) and including a second connection resume request message sent by a user equipment (UE), the second connection request message including: i) a resume cause field including the cause value; ii) a resume identity field including the identity value; and iii) a token field including an authentication token, and obtaining the first connection resume request includes generating the first connection resume request message using the received second connection resume request message. A8.1. The method described in embodiment A8, wherein generating the first resume connection request message using the second resume connection request message includes: i) modifying the second resume connection request message (e.g., replacing a value included in the resumeMAC-I field with a predefined value, deleting the field, replacing it with a different type, etc.), or ii) using information included in the second resume connection request message to generate the first resume connection request message (e.g., generating a first message from the second message using at least the cause value and identity value, but not an authentication token).

[0125] A9. The method of embodiment A8 or A8.1, further comprising the first network node / network device determining whether the generated authorization token is identical to the received authorization token (i.e., the token included in the second connection resume request message sent by the UE). A9.1. The method described in embodiment A7, wherein obtaining the first connection resumption request message includes the first network node / network device receiving a message sent by a second network node / network device (e.g., a target gNB), the message sent by the second network node / network device including the first connection resumption request and an authentication token. A9.2. The method of embodiment A9.1, further comprising the first network node / network device determining whether the generated authorization token is identical to the received authorization token (i.e., the token included in the message sent by the second network node / network device).

[0126] A10. The method of embodiment A9 or A9.2, further comprising, as a result of determining that the generated authorization token is identical to the received authorization token, the first network node / network device sending a message to the second network node / network device to trigger the second network node / network device to send an RRC message (e.g., an RRCResume message, an RRCRelease message, etc.) to the UE.

[0127] A11. The method of embodiment A10, wherein the message sent to the second network node includes a UE context for the UE.

[0128] A12. A method as in any one of the preceding embodiments, wherein using the first connection resume request message to generate the authentication token includes: i) generating a data structure (e.g., VarResumeMAC-Input) including the connection resume request message; ii) encoding the data structure to generate an encoded data structure (e.g., generating an ASN.1 encoded data structure); and iii) using the encoded data structure to generate the authentication token.

[0129] Embodiment C C1. A method (1300) (see FIG. 13) performed by a first network node, comprising: receiving (s1302) a message sent by a second network node, the message indicating whether the first network node should use a first method to generate an authentication token; and if the message indicates that the first network node should use the first method to generate an authentication token, generating an authentication token using the first method; otherwise, generating an authentication token using a second method (s1304).

[0130] C2. The method of embodiment C1, wherein the first method includes the steps of embodiment A1, A2, or A3.

[0131] C3. The method of embodiment C1 or C2, wherein the message is a user equipment (UE) context request message.

[0132] C4. A method (1900) performed by a target network node / network device (see FIG. 19), comprising: sending (s1902) a message to the source network node / network device, the message comprising: i) a first connection resume request message received by the target from a user equipment; or ii) a second connection resume request message generated by the target based on the first connection resume request message.

[0133] C5. The method of embodiment C4, further comprising the target obtaining an authentication token from the first connection resume request message and including the authentication token in the message.

[0134] Embodiment B - Option 4 B4.1. A method (1400) performed by a user equipment (UE) (see FIG. 14), comprising: generating (s1402) a message indicating whether the UE supports use of a first method for generating an authentication token for authenticating a connection resume request message; and sending (s1404) the message to a core network node. B4.2. A method (1500) (see FIG. 15) performed by a core network node / core network device, comprising: receiving (s1502) a first message, the first message being sent by a user equipment (UE), the first message indicating whether the UE supports use of a first method for generating an authentication token for authenticating a connection resume request message; and, after receiving the first message, sending (s1504) a second message to a network node of an access network, the second message indicating whether the UE supports use of the first method for generating an authentication token. B4.3. A method (1600) (see FIG. 16) performed by a network node / network device (e.g., a radio base station) of an access network, comprising: receiving (s1602) a message sent by a core network node, the message identifying a user equipment (UE) and indicating whether the identified UE supports use of a first method for generating an authentication token for authenticating a connection resume request message; and, after receiving the message, determining (s1604) based on the message received from the core network node whether to use the first method or the second method for generating an authentication token to be used for authenticating the connection resume request sent by the identified UE.

[0135] Embodiment B - Option 3 B3.1. A method (1700) (see FIG. 17) performed by a network node / network device (e.g., a radio base station) of an access network, comprising: sending (s1702) information to a user equipment (UE), the information indicating that i) the network node supports use of a first method for generating an authentication token for authenticating a connection resume request message, and / or ii) the information instructs the UE to use the first method for generating an authentication token for authenticating a connection resume request message. B3.2. A method (1800) (see FIG. 18) performed by a user equipment (UE), comprising receiving (s1802) information transmitted by a network node of an access network, wherein i) the information indicates that the network node supports use of a first method for generating an authentication token for authenticating a connection resume request message, and / or ii) the information instructs the UE to use the first method for generating an authentication token for authenticating a connection resume request message. B3.3. The method of embodiment B3.1 or B3.2, wherein the information is included in a medium access control element (MAC-CE) or downlink control information (DCI).

[0136] D1.1. A computer program (2043) including instructions (2044) that, when executed by a processing circuit (2002) of a user equipment (UE) (102), causes the UE to perform any one of the methods (e.g., A1, A2, A3, B4.1, B3.2) of the UE embodiments described above. D1.2. A computer program (2143) including instructions (2144) that, when executed by a processing circuit (2102) of a network node (104, 106, 108), cause the network node to perform any one of the methods (e.g., A1, A2, A3, C1, C4, B4.2, B4.3, B3.1) of the network node embodiments described above.

[0137] D2. A carrier comprising the computer program of embodiment D1.1 or D1.2, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium (2042, 2142).

[0138] E1. A UE (102) configured to perform the method of any one of the UE embodiments described above (e.g., A1, A2, A3, B4.1, B3.2).

[0139] F1. A user equipment (UE) (102), the UE including a memory (2042) and a processing circuit (2002), the UE configured to perform any one of the methods of the UE embodiments (e.g., A1, A2, A3, B4.1, B3.2).

[0140] G1. A network node (104, 106, 108), wherein the network node is configured to perform the method of any one of the network node embodiments (e.g., A1, C1, C4, B4.2, B4.3, B3.1).

[0141] H1. A network node (104, 106, 108), the network node including a memory (2142) and a processing circuit (2102), the network node configured to execute any one of the methods of the network node embodiments (e.g., A1, C1, C4, B4.2, B4.3, B3.1).

[0142] While various embodiments have been described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0143] Additionally, while the steps described above and illustrated in the figures are shown as a series of steps, this is done for illustrative purposes only, and it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be rearranged, and some steps may be performed in parallel.

[0144] Abbreviation Abbreviation Description ACK Acknowledgment AP Application Protocol BSR Buffer Status Report BWP Bandwidth Portion CA Carrier Aggregation CE Control Elements CP Control Plane CQI Channel Quality Indicator DC Dual Connectivity DL Downlink eNB (EUTRAN) base station E-RAB EUTRAN Radio Access Bearer gNB NR base station, gNodeB GTP-U GPRS Tunneling Protocol - User Plane IP Internet Protocol LTE Long Term Evolution MCG Master Cell Group MeNB Master eNB MgNB Master gNB MME Mobility Management Entity MN Master Node NACK Negative Acknowledgment PCell Primary Cell PSCell Primary SCell PUSCH Physical Uplink Shared Channel RLC Radio Link Control RLF Radio Link Failure SCell Secondary Cell SCG Secondary Cell Group SCTP Stream Control Transmission Protocol SeNB Secondary eNB SINR Signal to Interference and Noise Ratio SN Secondary Node SR Scheduling Request SUL Supplemental Uplink TDD Time Division Duplex TEID Tunnel Endpoint Identifier TNL Transport Network Layer UCI Uplink Control Information UDP User Datagram Protocol URLLC: Ultra-reliable, low-latency communication X2 Base Station Interface< / rrcresumerequest> < / rrcconnectionresume>

Claims

Claim 1: A method (1000) for generating an authentication token executed by a first network node (104) of an access network, comprising: receiving (s1002) a message from a second network node, the message including an authentication token and a first Radio Resource Control (RRC) connection resume request message, the first RRC connection resume request message including: i) a first field including a cause value; ii) a second field including an identity value; and iii) a third field including a predefined token value, the first RRC connection resume request message being encoded according to a non-aligned packed encoding rule; using the first RRC connection resume request message to generate an authentication token (s1004); A method comprising:

2. The third field is a ResumeMAC-I field or a ShortMAC-I field. The method of claim 1.

3. A method (1100) for generating an authentication token executed by a first network node (104) of an access network, comprising: receiving (s1002) a message from a second network node, the message including an authentication token and a first Radio Resource Control (RRC) connection resume request message, the first RRC connection resume request message including a first field including a cause value and a second field including an identity value, but not including any token field, and the first RRC connection resume request message being encoded according to a non-aligned packed encoding rule; using the first RRC connection resume request message to generate an authentication token (s1104); A method comprising:

4. the first field is a resume cause field, and the cause value indicates a resume cause of the first RRC connection resume request message; The second field is a resume identity field, and the identity value is a Radio Network Temporary Identifier (RNTI) type value. The method according to claim 1 or 3.

5. A method (1200) for generating an authentication token executed by a first network node (104) of an access network, comprising: receiving (s1002) a message from a second network node, the message including an authentication token and a first Radio Resource Control (RRC) connection resume request message, the first RRC connection resume request message including: i) a resume cause field including a cause value; ii) a resume identity field including an identity value; and iii) a token field having a first type, the first RRC connection resume request message being encoded according to a non-aligned packed encoding rule; using the first RRC connection resume request message to generate an authentication token (s1204); A method comprising:

6. using the first RRC connection resume request message to generate the authentication token, i) generating a data structure including the first RRC connection resume request message; ii) encoding the data structure to generate an encoded data structure; and iii) using the encoded data structure to generate the authentication token; Contains 6. The method according to any one of claims 1 to 3 and 5.

7. The method further includes the first network node determining whether the generated authentication token is the same as the received authentication token.

6. The method according to any one of claims 1 to 3 and 5.

8. and, as a result of determining that the generated authentication token is identical to the received authentication token, the first network node transmits a message to the second network node to trigger the second network node to transmit an RRC message to a user equipment (UE). The method of claim 7.

9. The message sent to the second network node includes a UE context for the UE. The method of claim 8.

10. A computer program (2143) comprising instructions (2144) which, when executed by a processing circuit (2102) of a network node (104), cause said network node to perform the method of any one of claims 1 to 3 and 5.

11. A network node (104), configured to perform the method according to any one of claims 1 to 3 and 5.

Images