WO2020056433A2 - SECURE COMMUNICATION OF RADIO RESOURCE CONTROL (RRC) REQUEST OVER SIGNAL RADIO BEARER ZERO (SRBo) - Google Patents

Abstract

Embodiment methods for transmitting RRC resume and RRC re-establishment messages are provided. The RRC resume message may includes a resume media access control (MAC) address and a resume field. The resume MAC address is calculated in accordance with at least one UE identity and a value of the resume cause field. The resume cause field indicates a cause of a UE resume attempt. The RRC re-establishment message includes a short MAC address and a RRC message type field. The short MAC address is calculated in accordance with at least a UE identity and a value of an RRC message type field. The resume cause field indicates a cause of a UE resume attempt.

Description

Secure Communication of Radio Resource Control (RRC) Request over Signal

Radio Bearer Zero (SRBo)

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 62/730,110 filed on

September 12, 2018 and entitled“Secure Communication of Radio Resource Control (RRC) Request over Signal Radio Bearer Zero (SRBO),” which is incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates generally to wireless telecommunications, and, in particular embodiments, to Secure Communication of Radio Resource Control (RRC) Request over Signal Radio Bearer Zero (SRBO).

BACKGROUND

Modern wireless networks typically include various security features to prevent unauthorized third parties from access and/or manipulating data. In particular, long term evolution (LTE) networks provide three basic security features, namely: LTE authentication, non-access stratum (NAS) security, and access stratum (AS) security. The LTE authentication feature ensures that a user is an authorized subscriber to the network (or network service) that the user is attempting to access, while the NAS security and AS security features ensure that control and user data communicated over a radio access network (RAN) is secure at the NAS and AS levels, respectively.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: FIG. 1 is a diagram of an embodiment wireless communications network;

FIG. 2 is a call flow diagram for an RNA update procedure using an RRC resume request;

FIG. 3 is a flowchart of an embodiment method for transmitting an RRC resume request;

FIG. 4 is a call flow diagram for an RRC Reestablishment procedure;

FIG. 5 is a flowchart of an embodiment method for transmitting an RRC re-establishment request; FIG. 6 is a diagram of an embodiment processing system; and

FIG. 7 is a diagram of an embodiment transceiver.

SUMMARY

An embodiment method for transmitting an RRC resume is provided. The embodiment method includes calculating a resume media access control (MAC) address in accordance with at least one UE identity and a value of a resume cause field and transmitting the RRC resume message over a Signal Radio Bearer Zero (SRB0) channel. The RRC resume message including the resume MAC address and the resume cause field. In one example, the at least one UE identity includes an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE. In the same example or another example, the at least one UE identity includes a source cell radio network temporary identifier (C-RNTI) assigned to the UE. In any of the preceding examples, in or in a new example, the at least one UE identity includes both an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE and a source cell radio network temporary identifier (C-RNTI) assigned to the UE.In any of the preceding examples, in or in a new example, the RRC resume message further includes the source C- RNTI. In any of the preceding examples, in or in a new example, the resume cause field indicates a cause of a UE resume attempt. In such an example, the resume cause field may indicate that an emergency is the cause of the UE resume attempt, that an RRC-based network access (RNA) update is the cause of the UE resume attempt, that high priority access is the cause of the UE resume attempt, or that delay tolerant access is the cause of the UE resume attempt. In any of the preceding examples, in or in a new example, the the resume MAC address is computed in accordance with an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE, a value of the resume cause field, and a target cell identifier. In any of the preceding examples, in or in a new example, the resume MAC address is computed in accordance with an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE, a value of an RRC message type field carried by the RRC resume message, a value of the resume cause field, and a target cell identifier. In any of the preceding examples, in or in a new example, the resume MAC address is computed in accordance with an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE, a value of an RRC message type field carried by the RRC resume message, a value of the resume cause field, a target cell identifier, and a UE secondary network temporary identifier (UE-SN-Temp-ID). In any of the preceding examples, in or in a new example, the RRC message type field indicates that the RRC re-establement message is associated with an RRC re-establement message type. A user equipment (UE) for performing the above-described method is also provided.

An embodiment method for transmitting an RRC re-establishment message is provided. The embodiment method includes calculating a short media access control (MAC) address in accordance with at least a UE identity and a value of an RRC message type field, and transmitting an RRC re establishment message over a Signal Radio Bearer Zero (SRB0) channel. The RRC re-establishment message includes the short MAC address and the RRC message type field. In one example, the at least one UE identity includes a source cell radio network temporary identifier (C-RNTI) assigned to the UE. In another example, the RRC re-establishment message includes the source C-RNTI. In any one of the preceding examples, or in an new example, the short MAC address is computed in accordance with a source cell radio network temporary identifier (C-RNTI) assigned to the UE, a source physical cell idenfier (PCI) assigned to a serving base station of the UE, a target cell identifier assigned to a target base station, and the value of the RRC message type field. In any one of the preceding examples, or in an new example, the short MAC address is computed in accordance with a source cell radio network temporary identifier (C-RNTI) assigned to the UE, a source physical cell idenfier (PCI) assigned to a serving base station of the UE, a target cell identifier assigned to a target base station, the value of the RRC message type field, and a UE secondary network temporary identifier (UE-SN- Temp-ID). In any one of the preceding examples, or in an new example, the RRC message type field indicates that the RRC re-establement message is associated with an RRC re-establement message type. A user equipment (UE) for performing the above-described method is also provided.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The making and using of embodiments of this disclosure are discussed in detail below. It should be appreciated, however, that the concepts disclosed herein can be embodied in a wide variety of specific contexts, and that the specific embodiments discussed herein are merely illustrative and do not serve to limit the scope of the claims. Further, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of this disclosure as defined by the appended claims. While the claimed aspects are described primarily in the context of 5G wireless networks, it should also be appreciated that those inventive aspects may also be applicable to 4G and 3G wireless networks.

In 4G RAN architecture, many RRC procedures initiated by the UE start with an RRC message that is sent from the UE on SRB0 before the establishment of any UE AS security context with the RAN. In addition, many communications on SRB0 are restricted in size, e.g., 48-64 bits, and thus adding security protection to RRC messages is challenging. In 4G, there was an attempt to optimize the RRC Connection Reestablishment procedure by allowing the source eNB to derive multiple K_eNB* based on the identity of the multiple cells of the target eNB and then deliver them to the target eNB in order to facilitate the UE’ s attempt to re-establish its connection, rather than allowing the UE to fall back to RRC-IDLE. Since the RRC-Reestablishment message is sent on SRB0, there may be a need to allow the target eNB to validate the identity of the UE which is trying to re-establish its RRC connection, for example, due to handover RLC failure. As mentioned above, one of the serious challenges to protect messages on SRB0 is the limited space for messages sent over SRB0, e.g., mostly 48-64 bits. In order to provide some security assurance of the identity of the UE to the target eNB before granting the UE RRC connection access, a mechanism is provided that allows the target eNB to securely validate the identity of the UE and extract the AS security context from the source eNB. This mechanism allows the UE to include an“Authentication Token” in the RRC Reestablishment Request message. In this way, the proposed mechanism allows the UE to hash“its own identity” +“Target Cell ID” +“KRRC in_t key” using the integrity protection algorithm that was being used between the UE and the source eNB.

The least significant 16 bits of the hash function output may be referred to as the“Authentication Token” and will be included in the RRC Re-establishment Request message. During the RRC- Reestablishment procedure, the UE is in a CONNECTED state and the UE mobility and movement is very limited and not far from the source eNB, e.g., the UE identity was represented using the combination of“Source C-RNTI + Source PCI”. The source PCI identifies the source cell that the UE was connected to, and the source C-RNTI identifies the context of the UE which was saved at that source cell.

The combination of“Source C-RNTI + Source PCI” may not be uniquely assigned to a UE within a single PLMN, e.g., single 3GPP operator, although it may be uniquely assigned to a UE within a particular geographical area of the PLMN. By extension, using“Source C-RNTI + Source PCI” for RRC Reestablishment procedure was relatively effective at ensuring collision avoidance since no more than one UE in the same geographical area is assigned the same“C-RNTI + PCI”.

Another RRC procedure called SUSPEND/RESUME was proposed for the NB-IoT use case where the NB-IoT UE mobility is limited and thus the UE identity requirement is somewhat similar to the UE identity in RRC-Reestablishment. Despite that, a Resume ID is used as the UE identity during the SUSPEND/RESUME procedure.

A new state machine has been introduced to enable the Resume procedure and the transition of the UE from RRC-INACTIVE state to RRC-CONNECTED, which is applicable to ah types of 5G handsets, UEs, and gNBs. The UE mobility or movement is no longer restricted to a specific geographical area from the time the UE has been sent to an INACTIVE state to when the UE is requesting to transition into RRC-CONNECTED state, e.g., the UE sends RRC Resume Request message; the UE could have crossed the boundaries where the PCI value is no longer unique within the same PLMN. Thus, RAN2 agreed to use Resume ID, e.g.„ I-RNTI, as the UE identity but continues to have the authentication token to protect the UE identity as represented by“Source C-RNTI + Source PCI”, therefore, the current RAN2 solution communicate the UE identity as I-RNTI in the RRC Resume Request message without this UE identity being protected by the authentication token. Rather the authentication token protects a completely different UE identity“Source C-RNTI + Source PCI”.

Moreover, the RRC Resume Request message has a“Resumecause” field that identifies the cause of the Resume Request message, e.g.„“highPriority Access”,“emergency”, delayToleranceAccess,

“RNA Update”, etc. and yet that is not protected.

An Unprotected Common Control Channel (SRB0) is naturally UNPROTECTED such that it has neither PDCP integrity protection nor PDCP encryption. RRC procedures which allow the UE to send an RRC message over SRB0 while the UE in a state of INACTIVE or CONNECTED, e.g.„ while the UE does not have an AS security context with the serving network (RAN), Authentication Token is used to provide the following: (1) Authenticate the UE identity, e.g., I-RNTI, (source C-RNTI + Source PCI); (2) Prove the UE is in the possession of the last AS security key and more broadly in possession of the AS security context between the UE and the last serving gNB that the UE was using when was connected to before Handover occurred or when the UE was sent to INACTIVE state or SUSPENDED; (3) Protect the message itself in order NOT to allow an attacker to change the RRC message type and resend the message causing a mismatch between the UE and the Network, e.g.,

RRC message type, RRC Resume Cause in the RRC Resume Request message, etc.; (4) Bind the message to the target physical cell identity in order to prevent an attacker from capturing a message on celll, for example, and replay it back on cell 2.; and (5) Any other information that impact the network response to the UE requested service as captured in the RRC message. E.g., let us assume the UE has two temporary identities, one with the Master Node and another with the Secondary Node and the UE would like to resume both connections in one single RRC message. Embodiments of this disclosure provide techniques for generating and using an RRC Resume Authentication Token. In one embodiment, ResumeMAC-I can be calculated over the following parameters: (i) I-RNTI - The UE INACTIVE temporary identifier as assigned to the UE by the last serving gNB which sent the UE to INACTIVE; (ii) “Resume Cause” of the RRC Resume Request message; (iii) Target Cell ID: This to bind the authentication token ,e.g., ResumeMAC-I to be valid with a single cell ID, which is the target cell ID the UE is trying to transition to CONNECTED state over. This prevents an attacker from successfully capturing a specific UE RRC Resume Request message and send it to another Cell (iv) VARResumeMAC-Input is: (I-RNTI, Resume Cause, Target Cell ID). It should be appreciated that in all embodiments for the RRC Resume Request

Authentication Token (ResumeMAC-I) Input, I-RNTI may be replaced by the (source C-RNTI + Source PCI).

In another embodiment, ResumeMAC-I can be calculated over the following parameters: (i) I-RNTI: The UE INACTIVE temporary identifier as assigned to the UE by the last serving gNB which sent the UE to INACTIVE state; (ii) RRC Message Type: in this case, RRC Resume Request message; (iii) RRC Resume Cause: The“Resume Cause” field value of the RRC Resume Request message; (iv) Target Cell ID: This to bind the authentication token, e.g., ResumeMAC-I to be valid with a single cell ID, which the target cell ID. This prevents an attacker from successfully capturing a specific UE RRC Resume Request message and send it to another Cell; (v) VARResumeMAC-Input : : (I-RNTI, RRC message type, ResumeCause, Target Cell ID).

In another embodiment, ResumeMAC-I can be calculated over the following parameters: (i) I-RNTI: The UE INACTIVE temporary identifier as assigned to the UE by the last serving gNB which sent the UE to INACTIVE state; (ii) RRC Message Type: in this case, RRC Resume Request message; (iii) RRC Resume Cause: The“Resume Cause” field value of the RRC Resume Request message; (iv) Target Cell ID: This to bind the authentication token, e.g.„ ResumeMAC-I to be valid with a single cell ID, which the target cell ID. This prevents an attacker from successfully capturing a specific UE RRC Resume Request message and send it to another Cell; (v) UE-SN-Temporary-ID: In case of Dual connectivity, the UE may have two temporary identifiers. One with the Master Node (MN), I-RNTI for example, and another with the Secondary Node (SN), UE-SN-Temp-ID. Then the UE SN ID should be also protected; (vi) VARResumeMAC-Input :: (I-RNTI, UE-SN-ID, RRC message type, ResumeCause, Target Cell ID).

Embodiments of this disclosure provide techniques for generating and using an RRC Reestablishment Authentication Token. A ShortMAC-I is the authentication token of the RRC Reestablishment Request message. In one embodiment, the ShortMAC-I is calculated over the following parameters:

(i) Source C-RNTI - UE Connected temporary identifier as assigned to the UE by the source gNB; (ii) Source PCI: The Source Cell physical Identity of the source gNB; (ii) Target Cell ID: This to bind the authentication token, e.g.„ ShortMAC-I to be valid with a single cell ID, which the target cell ID. This prevents an attacker from successfully capturing a specific UE RRC Reestablishment Request message and send it to another Cell; (iv) RRC Message Type: e.g.,, in this case RRC-Reestablishment Request message; (v) VARShortMAC-Input :: (Source C-RNTI, Source PCI, RRC Message Type, Target Cell ID).

In another embodiment, the ShortMAC-I is calculated over the following parameters: (i) Source C- RNTI - UE Connected temporary identifier as assigned to the UE by the source gNB; (ii) Source PCI: The Source Cell physical Identity of the source gNB; (iii) Target Cell ID: This to bind the authentication token, e.g.„ ShortMAC-I to be valid with a single cell ID, which the target cell ID. This prevents an attacker from successfully capturing a specific UE RRC Reestablishment Request message and send it to another Cell; (iv) RRC Message Type: e.g.„ in this case RRC-Reestablishment Request message; (v) UE-SN-Temporary-ID: In case of Dual connectivity, the UE may have two temporary identifiers. One with the Master Node (MN), C-RNTI + PCI for example, and another with the Secondary Node (SN), UE-SN-Temp-ID. Then the UE SN ID should be also protected; (vi) VARShortMAC-Input : : (Source C-RNTI, Source PCI, UE-SN-ID, RRC Message Type, Target Cell ID).

Embodiments of this disclosure provide techniques for generating and using a Common

Authentication Token. This solution proposes a common“authentication Token” to be calculated for both RRC Reestablishment Request and RRC Resume Request and forward compatible to other RRC messages if needed.

A VARCommonMAC-Input may include the following (UE-ID1, UE-ID2, RRC Message Type, RRC-Message-Subtype, Target Cell ID). The CommonMAC-I may include the following input parameters: (i) UE-ID1 - UE identity with last serving gNB (in case of Dual Connectivity, this ID is with the Master Node); (ii) UE-ID2 - UE identity with last serving Secondary Node gNB (in case DC, this ID is with the SN); (iii) RRC Message Type: Type of RRC Request message, e.g., RRC Resume Request, RRC Reestablishment Request, etc.; (iv) RRC-Message-Subtype: Subtype of the RRC Request message e.g.,“Resume Cause” in case of RRC Resume Request message. If RRC Request message does NOT have this parameter, it is automatically not included as an input to the

CommonMAC-I or the field is set to all zeroes; (v) Target Cell ID: This binds the“authentication token” to be valid with a single cell ID, e.g.,, the target cell ID. This prevents an attacker from successfully capturing a specific UE RRC Request message and then send it to another Cell.

Embodiments of this disclosure provide techniques for generating and using an RRC Reestablishment Request. In one example, a CommonMAC-I is applied to RRC Reestablishment Request message in the case of Single Connectivity to last serving gNB (gNBl). The RRC Reestablishment Request message includes UE-ID1 (Source C-RNTI + Source PCI). The RRC Reestablishment Request message, for example, does not have a Subtype. The RRC Reestablishment Request message include Target Cell ID as (Cell2 of gNB2). In some cases, a Target gNB (gNB2) is not prepared and does not have a Token. A UE builds RRC Reestablishment message & send over SRB0 to gNB2. In particular, the UE calculate UE-CommonMAC-I by setting the respective fields of the VARCommonMAC-Input as follows: UE-ID =“C-RNTI1 + PCI1”; RRC Message Type = RRC Reestablishment Request; RRC Message Subtype = NULL (not included or set to all zeroes); Target Cell ID = Cell2 of gNB2; Use L_RRCint & Integrity protection algorithm = the Old key & integrity algorithm that were used between the UE and gNB l.

The gNB2 receives RRC Reestablishment Request & sends to gNB 1 a Context Letch message containing the following fields: (i) UE-ID =“C-RNTI1 + PCI1”; (ii) RRC Message Type = RRC Reestablishment Request; (iii)RRC Message Subtype = NULL (not included or set to all zeroes); and (iv) Target Cell ID = Cell2 of gNB2. A CommonMAC-I as received from UE in RRC

Reestablishment Request - UE-CommonMAC-I.

The source gNB (gNB l) authenticates the UE & the RRC message to gNB2. In particular, the source gNB may identifies the UE AS security context based on C-RNTI1 and PCI1. Since RRC Message Subtype is not included, the gNBl does not include the field as input or set to all zeroes. The source gNB may calculate the gNB-CommonMAC-I based on Input parameters (C-RNTI1, PCI1,

Reestablishment Request, Cell2-ID) & old K_{RR( itl}, + Integrity Protection algorithm that the UE was using with the last gNB and was saved in UE security context. The source gNB may compare gNB- CommonMAC-I to UE-CommonMAC-I, and if successful, the source gNB may derive new K_gNB* key based on new [NCC & NH] pair or based existing NCC and K_gNB. The source gNB may then send the UE context to gNB2 with (New KgNB*, UE security capabilities, algorithms used between UE and gNBl).

The target gNB (gNB2) receives the UE Context from source gNB (gNB l). Thereafter, the target gNB (gNB2) may perform the following steps: (i) Derive K_{RR( itlt} & K_{RR( tl} keys based on the received K_gNB* & the security algorithms that have been used between UE and gNBl ; (ii) Build RRC Reestablishment message and include the received NCC; (iii) Integrity protect the RRC

Reestablishment message using the K_{RR( itl}, & Integrity protection algorithm that was used between the UE and gNB 1 ; (iv) Send RRC Reestablishment message to UE on SRB 1.

The UE receives RRC Reestablishment message over SRB1 from gNB2. Thereafter, the UE may compare the received NCC to the current NCC. If the same, the UE may derive K_gNB* based on the target cell ID and Freq. If received NCC is different, the UE may synchronize the NH based on the new NCC and then derive the K_gNB*. The UE may derive K_{RR( itl}, & K_{RRr .tl} based on newly derived K_gNB*- The UE may validate the integrity of the received RRC Reestablishment message. If Successful, the UE sends RRC Reestablishment Complete message while integrity protected and encrypted on SRB 1.

In another example, an RRC Resume Request is received. The RRC Resume Request message may include a UE-ID 1 (Source C-RNTI + Source PCI). The RRC Resume Request message may include a Resume Cause as an“RNA Update” as Subtype.

The RRC Resume Request message may include a Target Cell ID as (Cell2 of gNB2). Target gNB (gNB2) may not have a token. A UE may build an RRC Resume message & send it over SRB0 to gNB2. The UE may calculate a UE-CommonMAC-I by setting the respective fields of

VARCommonMAC-Input as follows: UE-ID =“C-RNTI1 + PCI1” - Another option is to use I-RNTI as the UE ID; RRC Message Type = RRC Resume Request; RRC Message Subtype =

(Resumecause=RNA Update); Target Cell ID = Cell2 of gNB2; use K_{RR( itl}, & Integrity algorithm = the Old key & the integrity protection algorithm that were used between the UE and gNBl.

The Target gNB (gNB2) may sends to gNBl a Context Fetch message which contains UE-ID =“C- RNTI1 + PCI1”, RRC Message Type = RRC Resume Request, RRC Message Subtype = (Resume Cause =“RNA Update”), Target Cell ID = Cell2 of gNB2, and CommonMAC-I as received from UE in RRC Resume Request - UE-CommonMAC-I.

The source gNB (gNBl) may authenticate the UE & the RRC message & send the UE Context to the gNB2. In particular, the source gNB may identifies the UE AS security context based on C-RNTI1 and PCI1. Since RRC Message Subtype is included, the source gNB (gNBl) may set RRC Message Subtype to“resume cause=RNA Update”. The source gNB (gNBl) may calculate gNB- CommonMAC-I based on Input parameters (C-RNTI1, PCI1,“Resume Request”,“RNA Update”, Cell2-ID) & old K_{RR( itl}, + Integrity Protection algorithm that was used with the UE and the last gNB and was saved in UE security context. The source gNB (gNBl) may compare gNB -CommonMAC-I to UE-CommonMAC-I, and if successful, the source gNB (gNBl) may derive new K_gNB* based on new [NCC & NH] pair or based existing NCC and K_gNB. The source gNB (gNBl) may send the UE context to gNB2 with (New K_gNB*, UE security capabilities, algorithms used between UE and gNBl). The target gNB (gNB2) receives the UE Context from source gNB (gNBl). Thereafter, the target gNB (gNB2) may perform the following steps: Derive K_{RR( itlt} & K_{RR( tl} based on newly derived K_gNB* & security algorithms that have been used between UE and gNBl. gNB2 shall generate a new I-RNTI, e.g., I-RNTI2 and include in the RRC Resume message. Build RRC Resume message.

Integrity protect & Encrypt the RRC Resume message using the K_{RR( itl}, & K_{RRr .tl} & Integrity protection & Encryption algorithms that were used between the UE and gNB 1. Send RRC Resume message to UE on SRB1. The UE receives RRC Resume message over SRB1 from gNB2. Thereafter, the UE may decrypt the message using the correct K^c_e^., validate the integrity of the RRC Resume message using the correct K_RRntlt, and save the new I-RNTI2.

In one embodiment, a Target gNB may extract the UE ID from the RRC message based on the source C-RNTI + source PCI for the case of RRC Reestablishment Request message and the I-RNTI for the case of RRC Resume Request message. Another option is to continue to use the UE ID as“Source C- RNTI + Source PCI”. If UE-ID2 is included it may be extracted.

The target gNB sends the UE ID and all information that are required for the calculation of the RRC Request message’s Authentication Token to the source gNB. The Reestablishment Request may include a target Cell ID & RRC message type, as well as US-SN-ID if available. The Resume Request may include a Target Cell ID, Resume Cause, RRC message type, and US-SN-ID if available. The Source gNB may identify the UE AS security context based on the received UE ID. In case of RRC Reestablishment procedure, the source gNB may not set the resume cause or message subtype, but instead may calculate the ShortMAC-I or CommonMAC-I based on one of the proposed solutions provided herein.

In case of RRC Resume Request procedure, the source gNB calculates the ResumeMAC-I or CommonMAC-I based on one of the proposed solutions provided herein.

The Source gNB may compare the UE received Authentication Token to the calculated

Authentication Token. If successful (e.g., if the tokens match), the source gNB may send the UE context with the KgNB* to the target gNB to complete the RRC procedure.

The UE may include the correct UE ID based on the type of RRC procedure in the RRC message. Additionally, the RRC message may include the source C-RNTI + source PCI for the case of RRC Reestablishment Request message, I-RNTI for the case of RRC Resume Request message. Another option is to continue to use the UE ID as“Source C-RNTI + Source PCI” in both cases. In case of RRC Reestablishment procedure, the UE may calculate the ShortMAC-I or CommonMAC-I based on one of the proposed solutions provided herein.

In case of RRC Resume Request procedure, the UE may calculate the ResumeMAC-I or

CommonMAC-I based on one of the proposed solutions provided herein.

The UE may determine whether the RRC procedure is successful by validating the received RRC message (MSG4). The RRC Reestablishment message which is only integrity protected using new K_RRCint + security algorithm which was used between the UE and the source gNB.

The RRC Resume message, which is integrity protected & encrypted using new (K^ci_nt & K_{RR( tl )} + security algorithms which was used between the UE and the last gNB, may be communicated between target gNB and the UE .

FIG. 1 illustrates a network 100 for communicating data. The network 100 comprises a serving base station 110 having a coverage area 102, a target base station 120 having a coverage area 102, a user equipment (UE) 110, and a Access Management Function (AMF) entity 190. The base stations 110, 120 and the AMF entity 190 communicate with one another over backhaul interfaces, while the UE 130 communicates with the base station 110, 120 via access interfaces (e.g., radio access network (RAN) interfaces, etc.). As used herein, the term“base station” refers to any component (or collection of components) configured to provide wireless access to a network, such as next generation base station (gNB), an E-UTRAN base station (eNB), a macro-cell, a femtocell, a Wi-Fi access point (AP), or other wirelessly enabled devices. Base stations may provide wireless access in accordance with one or more wireless communication protocols, e.g., Next Generation Radio, (NR, 5G Radio), long term evolution (LTE), LTE advanced (LTE-A), High Speed Packet Access (HSPA), Wi-Fi 802.1 la/b/g/n/ac, etc. As used herein, the term“UE” refers to any component (or collection of components) capable of establishing a wireless connection with a base station, such as a mobile device, a mobile station (STA), an IoT device (e.g., a smart sensor, etc.) and other wirelessly enabled devices. In some embodiments, the network 100 may comprise various other wireless devices, such as relays, low power nodes, etc.

FIG. 2 is a call flow diagram for an RNA update procedure 200 using an RRC resume request. The RNA update procedure 200 begins when the serving base station 110 obtains the UE security context 210, which may include an Inactive Radio Network Temporary Identifier (I-RNTI), an old K_RRntlt, an NCC1, a source cell ID, and various algorithms. Next, the serving base station 110 sends an RRC connection release message 212 that includes the I-RNTI and NCC1 to the UE 130.

Upon receiving the RRC connection release message 212, the UE 130 enters an inactive state at step 214, calculates a Resume MAC address at step 216, and derives various parameters (e.g., an KgNB, an RRC key (K_{RRr .tl )}, uplink keys, etc.) at step 218. The KgNB may be derived based on the NCC1, while the K_{RRr .tl} and uplink keys may be derived based on source algorithms. The UE 130 may also save various information (e.g., the old K_RRCmt and NCC1), as well as perform a re-selection of a trigger RNA update.

Next, the UE 130 sends an RRC resume request 220 to the target base station 120. The RRC resume request 220 may include an I-RNTI, a resume cause field, and a resume MAC address. Upon receiving the RRC resume request 220, the target base station 120 may extract an I-RNTI, and send a retrieve UE context message 224 to the serving base station 110. The retrieve UE context message 224 may include the I-RNTI, the resume cause field, and the resume MAC address. Prior to sending the retrieve UE context message 224, the target base station 120 may extract the RNTI and resume MAC address from the RRC resume request 220.

Upon receiving the retrieve UE context message 224, the serving base station 110 may locate a context (e.g., an I-RNTI) and validate the resume MAC address. The serving base station 110 may also calculate a KgNB* based on the NCC1, and then send a response 228 to the target base station 120. The response 228 may include a KgNB*, the NCC1, and various algorithms.

Upon receiving the response 228, the target base station 120 may allocate an I-RNTI2 and calculate a new K_RRCint and K_{RR( tl} . Thereafter, the target base station 120 may send a path switch request 231 that includes an NCC2 to the AMF entity 190. Upon receiving the path switch request 231, the AMF entity 190 may switch a path associated with the UE 130, and return an acknowledgement message 232 to the target base station 120. The target base station 120 may then send an RRC connection release 234 that includes the I-RNTI2 and NCC2 to the UE 130. Upon receiving the RRC connection release 234, the UE 130 may decrypt and validate the RRC connection release 234 and enter an inactive state at step 236. The UE 130 may also select the old K_RRCmt and NCC1, and save the new K_RRCint and NCC2.

FIG. 3 is a flowchart of an embodiment method 300 for transmitting an RRC resume request, as might be performed by the UE 130. At step 310, the UE 1309 calculates a resume media access control (MAC) address in accordance with at least one UE identity and a value of a resume cause field. At step 320, the UE transmits an RRC resume message to a target base station. The RRC resume message includes the resume MAC address and the resume cause field, and is communicated over a signal radio bearer zero (SRB0) channel.

FIG. 4 is a call flow diagram for an RRC re-establishment procedure 400 using an RRC re establishment request. The re-establishment 400 begins when the serving base station 110 obtains the UE security context 410, which may include an I-RNTI, an old K_RRntlt, an NCC1, a source cell ID, and various algorithms. Next, the serving base station 110 sends a handover command 412 that includes an NCC2 to the UE 130.

Upon receiving the handover command 412, the UE 130 determines that the handover has failed at step 414, calculates a Short MAC address at step 416, and derives various parameters (e.g., an KgNB*, an RRC, uplink keys, etc.) at step 418. The Source MAC address may be calculated using the old K_RRCint· The KgNB* may be derived based on the NCC1, while the RRC and uplink keys may be derived based on source algorithms. The UE 130 may also save various information (e.g., the old K_RRCint and NCC1), as well as perform a re-selection of a trigger RNA update.

Next, the UE 130 sends an RRC re-establishment request 420 to the target base station 120. The RRC re-establishment request 420 may include a source C-RNTI, a source PCI (S-PCI), and the short MAC address. Upon receiving the RRC re-establishment request 420, the target base station 120 may extract the C-RNTI and S-PCI, validate the short MAC address, and send a retrieve UE context message 424 to the serving base station 110. The retrieve UE context message 424 may include the C- RNTI-1, the S-PCI, and the short MAC address.

Upon receiving the retrieve UE context message 424, the serving base station 110 may locate a UE context (e.g., a C-RNTI-2) and validate the short MAC address. The serving base station 110 may also calculate a KgNB* based on the NCC1, and send a response 428 to the target base station 120. The response 428 may include the C-RNTI-2, a PCI-2, and an NCC2.

Upon receiving the response 428, the target base station 120 may allocate a C-RNTI-2 and calculate the K_RRCim and K_RRCCHC- Thereafter, the target base station 120 may send an RRC re-establishment response 432 that includes the C-RNTI2, the PCI-2, and the NCC2 to the UE 130. Upon receiving the RRC re-establishment response 432, the UE 130 may validate the integrity of the RRC re establishment response 432 and send an RRC -re-establishment complete message 436 to the target base station 120. The RRC -re-establishment complete message 436 may be integrity protected and/or encrypted. Prior to sending the RRC -re-establishment complete message 436, the UE 230 may achieve synchronization with the target base station 120 based on the NCC2 and derive the K_{RR int} and

KRR enc-

FIG. 5 is a flowchart of an embodiment method 500 for transmitting an RRC re-establishment request, as may be performed by the UE 130. At step 510, the UE calculates a resume media access control (MAC) address in accordance with at least one UE identity and a value of a resume cause field. At step 520, the UE transmits an RRC resume message to a target base station. The RRC resume message includes the resume MAC address and the resume cause field, and is communicated over a signal radio bearer zero (SRB0) channel.

Embodiments of this disclosure provide a replay protection protocol for RNA update without context relocation. RNA Update may use the same RRC Resume Request message but with a resumecause value of“RNA Update”. Since in the case of RNA Update w/o context relocation, the UE context stays at the old gNB (Last serving gNB), the old gNB can continue to track the UE context using the same old I-RNTI. However, if the UE is assigned the same I-RNTI ID, then in the next time the UE sends RRC Resume Request message, the UE will include the same old I-RNTI ID. However, since the UE will use a new K_RRCmt key, the ResumeMAC-I authentication token of the new RRC Resume Request message with Resumecause“RNA Update” will be different than the one of the old RRC Resume Request message, Thus, there is no replay protection problem for the UE RRC Resume Request message. On the other hand, since the UE will save the C-RNTI and PCI of the new gNB in its AS security context while the source gNB continues to track the“source C-RNTI & source PCI” of the last serving gNB, using C-RNTI+PCI for the UE identity in the case of RNA Update without context relocation will create an out of synch state between the UE and the last serving gNB.

Therefore, using I-RNTI as a UE IE for RNA Update without context relocation allows the continuous synchronization of the RRC Resume procedure between the UE and the network. In 5G RAN, after successfully validating the RRC Resume Request authentication token, e.g.,

ResumeMAC-I, it may be possible to allocate and assign the UE a new I-RNTI including RNA Update without context relocation. If the last serving gNB (old gNB) decides to process the UE RRC Resume Request message with resumecause value of“RNA Update” without relocating the UE context to the new gNB, the old gNB may allocate and assign the UE a new I-RNTI and shall include the new I-RNTI in the RRC Release message (MSG4) which is integrity protected and encrypted. The same concept may be applicable if the RRC Resume Request message with“resume cause” value set to“RNA Update” is sent directly to the last gNB, e.g., the old gNB and the new gNB are a single gNB (same gNB). The same gNB may allocate a new I-RNTI to the UE if the same gNB decides to send the UE directly to INACTIVE.

FIG. 6 illustrates a block diagram of an embodiment processing system 600 for performing methods described herein, which may be installed in a host device. As shown, the processing system 600 includes a processor 604, a memory 606, and interfaces 610-614, which may (or may not) be arranged as shown in FIG. 6. The processor 604 may be any component or collection of components adapted to perform computations and/or other processing related tasks, and the memory 606 may be any component or collection of components adapted to store programming and/or instructions for execution by the processor 604. In an embodiment, the memory 606 includes a non-transitory computer readable medium. The interfaces 610, 612, 614 may be any component or collection of components that allow the processing system 600 to communicate with other devices/components and/or a user. For example, one or more of the interfaces 610, 612, 614 may be adapted to communicate data, control, or management messages from the processor 604 to applications installed on the host device and/or a remote device. As another example, one or more of the interfaces 610,

612, 614 may be adapted to allow a user or user device (e.g., personal computer (PC), etc.) to interact/communicate with the processing system 600. The processing system 600 may include additional components not depicted in FIG. 6, such as long term storage (e.g., non-volatile memory, etc.).

In some embodiments, the processing system 600 is included in a network device that is accessing, or part otherwise of, a telecommunications network. In one example, the processing system 600 is in a network-side device in a wireless or wireline telecommunications network, such as a base station, a relay station, a scheduler, a controller, a gateway, a router, an applications server, or any other device in the telecommunications network. In other embodiments, the processing system 600 is in a user- side device accessing a wireless or wireline telecommunications network, such as a mobile station, a user equipment (UE), a personal computer (PC), a tablet, a wearable communications device (e.g., a smartwatch, etc.), or any other device adapted to access a telecommunications network.

In some embodiments, one or more of the interfaces 610, 612, 614 connects the processing system 600 to a transceiver adapted to transmit and receive signaling over the telecommunications network. FIG. 7 illustrates a block diagram of a transceiver 700 adapted to transmit and receive signaling over a telecommunications network. The transceiver 700 may be installed in a host device. As shown, the transceiver 700 comprises a network-side interface 702, a coupler 704, a transmitter 706, a receiver 708, a signal processor 710, and a device-side interface 712. The network-side interface 702 may include any component or collection of components adapted to transmit or receive signaling over a wireless or wireline telecommunications network. The coupler 704 may include any component or collection of components adapted to facilitate bi-directional communication over the network-side interface 702. The transmitter 706 may include any component or collection of components (e.g., up- converter, power amplifier, etc.) adapted to convert a baseband signal into a modulated carrier signal suitable for transmission over the network-side interface 702. The receiver 708 may include any component or collection of components (e.g., down-converter, low noise amplifier, etc.) adapted to convert a carrier signal received over the network-side interface 702 into a baseband signal. The signal processor 710 may include any component or collection of components adapted to convert a baseband signal into a data signal suitable for communication over the device-side interface(s) 712, or vice-versa. The device-side interface(s) 712 may include any component or collection of components adapted to communicate data-signals between the signal processor 710 and components within the host device (e.g., the processing system 600, local area network (LAN) ports, etc.).

The transceiver 700 may transmit and receive signaling over any type of communications medium. In some embodiments, the transceiver 700 transmits and receives signaling over a wireless medium. For example, the transceiver 700 may be a wireless transceiver adapted to communicate in accordance with a wireless telecommunications protocol, such as a cellular protocol (e.g., long-term evolution (LTE), etc.), a wireless local area network (WLAN) protocol (e.g., Wi-Fi, etc.), or any other type of wireless protocol (e.g., Bluetooth, near field communication (NFC), etc.). In such embodiments, the network-side interface 702 comprises one or more antenna/radiating elements. For example, the network-side interface 702 may include a single antenna, multiple separate antennas, or a multi antenna array configured for multi-layer communication, e.g., single input multiple output (SIMO), multiple input single output (MISO), multiple input multiple output (MIMO), etc. In other embodiments, the transceiver 700 transmits and receives signaling over a wireline medium, e.g., twisted-pair cable, coaxial cable, optical fiber, etc. Specific processing systems and/or transceivers may utilize all of the components shown, or only a subset of the components, and levels of integration may vary from device to device.

The following ABBREVIATIONS are used herein:

AS: Access Stratum

ShortMAC-I: Authentication token, e.g., for RRC-Reestablishment Request message.

ResumeMAC-I: Authentication token, e.g., for RRC-Resume Request message.

Last gNB: The last gNB the UE was connected to before the UE initiates RRC Resume or RRC Reestablishment procedure, also can be referred to as old gNB, Source gNB (S-gNB) or Anchor gNB.

New gNB: The gNB that the UE is trying to connect to during the RRC Reestablishment procedure or the RRC Resume procedure, also can be referred to as Target gNB (T-gNB). I-RNTI: Inactive Radio Network Temporary Identifier, assigned to UE as 40 bits (20 gNB-ID & 20 UE)

C-RNTI: Connected Radio Network Temporary Identifier, assigned to UE by serving cell of serving gNB.

PCI: Physical Cell ID, a value of 504 in total within any PLMN. A PLMN may have multiple geographical areas which may have overlapping PCIs but geographically is almost impossible to collide.

ResumeCause: The cause filed in the RRC Resume Request message. It indicates to the RAN the purpose from the UE Resume attempt e.g.,,“emergency”,“RNA Update”,

“highPrioirty Access”,“delayToleranceAcces”, etc.

SMC: Security Mode Command

EIA0: E-UTRAN Integrity protection algorithm No. zero.

EEA1 : E-UTRAN Encryption Algorithm No. 1

NEA0: Next Generation (5G) Encryption Algorithm No. 1.

gNB: Next Generation NB.

SEAF: Security Anchor Function

AMF: Access Management Function

SMF: Session Management Function PDU: Packet Data Unit -or- Protocol Data Unit

DRB: Data Radio Bearer

Although the present disclosure has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from scope of the disclosure. The specification and drawings are, accordingly, to be regarded simply as an illustration of the disclosure as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present disclosure.

The following documents are related to this disclosure, and are incorporated by reference herein as if reproduced in their entireties:

3GPP TS 33.401 v 13.0.0“3GPP System Architecture Evolution - Security Architecture” http : // www.3gpp .org/DynaReport/33401.htm

3GPP TS 33.102 vl3.0.0“3G Security - Security Architecture”

http : // www.3gpp .org/DynaReport/33102.htm 3GPP TS 33.501 v0.3.0“5G Security - Security Architecture”

http : // www.3gpp .org/DynaReport/33501.htm

3GPP TS 23.501 vl.2.0“System Architecture for the 5G System”

http : // www.3gpp .org/DynaReport/23501.ht

Claims

WHAT IS CLAIMED IS:

1. A method comprising:

calculating, by a user equipment (UE), a resume media access control (MAC) address in accordance with at least one UE identity and a value of a resume cause field; and

transmitting, by the UE, a radio resource control (RRC) resume message over a Signal Radio Bearer Zero (SRBO) channel, the RRC resume message including the resume MAC address and the resume cause field.

2. The method of claim 1 , wherein the at least one UE identity includes an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE.

3. The method of claim 1 or claim 2, wherein the at least one UE identity includes a source cell radio network temporary identifier (C-RNTI) assigned to the UE.

4. The method of any of claims 1-3, wherein the at least one UE identity includes both an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE and a source cell radio network temporary identifier (C-RNTI) assigned to the UE.

5. The method of either claim 3 or claim 4, wherien the RRC resume message further includes the source C-RNTI.

6. The method of any of claim 1-5, wherein the resume cause field indicates a cause of a UE resume attempt.

7. The method of claim 6, wherein the resume cause field indicates that an emergency is the cause of the UE resume attempt.

8. The method of claim 6, wherein the resume cause field indicates that an RRC-based network access (RNA) update is the cause of the UE resume attempt.

9. The method of claim 6, wherein the resume cause field indicates that high priority access is the cause of the UE resume attempt.

10. The method of claim 6, wherein the resume cause field indicates that delay tolerant access is the cause of the UE resume attempt.

11. The method of any of claim 1-10, wherein the resume MAC address is computed in accordance with an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE, a value of the resume cause field, and a target cell identifier.

12. The method of any of claim 1-10, wherein the resume MAC address is computed in accordance with an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE, a value of an RRC message type field carried by the RRC resume message, a value of the resume cause field, and a target cell identifier.

13. The method of any of claim 1-10, wherein the resume MAC address is computed in accordance with an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE, a value of an RRC message type field carried by the RRC resume message, a value of the resume cause field, a target cell identifier, and a UE secondary network temporary identifier (UE-SN-Temp-ID).

14. The method of any of claims 1-13, wherein the RRC message type field indicates that the RRC re-establement message is associated with an RRC re-establement message type.

15. A user equipment (UE) comprising:

a processor; and

a non-transitory computer readable storage medium storing programming for execution by the processor, the programming including instructions to:

calculate a resume media access control (MAC) address in accordance with at least one UE identity and a value of a resume cause field; and

transmit a radio resource control (RRC) resume message over a Signal Radio Bearer Zero (SRB0) channel, the RRC resume message including the resume MAC address and the resume cause field.

16. A method comprising:

calculating, by a user equipment (UE), a short media access control (MAC) address in accordance with at least a UE identity and a value of an RRC message type field; and transmitting, by the UE, a radio resource control (RRC) re-establishment message over a Signal Radio Bearer Zero (SRBO) channel, the RRC re-establishment message including the short MAC address and the RRC message type field.

17. The method of claim 16, wherein the at least one UE identity includes a source cell radio network temporary identifier (C-RNTI) assigned to the UE.

18. The method of claim 17, wherien the RRC re-establishment message further includes the source C-RNTI.

19. The method of claim 17 or claim 18, wherein the short MAC address is computed in accordance with a source cell radio network temporary identifier (C-RNTI) assigned to the UE, a source physical cell idenfier (PCI) assigned to a serving base station of the UE, a target cell identifier assigned to a target base station, and the value of the RRC message type field.

20. The method of claim 17 or claim 18, wherein the short MAC address is computed in accordance with a source cell radio network temporary identifier (C-RNTI) assigned to the UE, a source physical cell idenfier (PCI) assigned to a serving base station of the UE, a target cell identifier assigned to a target base station, the value of the RRC message type field, and a UE secondary network temporary identifier (UE- SN-Temp-ID).

21. The method of any of claims 16-20, wherein the RRC message type field indicates that the RRC re-establement message is associated with an RRC re-establement message type.

22. A user equipment (UE) comprising:

a processor; and

a non-transitory computer readable storage medium storing programming for execution by the processor, the programming including instructions to:

calculate a short media access control (MAC) address in accordance with at least a UE identity and a value of an RRC message type field; and

transmit a radio resource control (RRC) re-establishment message over a Signal Radio Bearer Zero (SRBO) channel, the RRC re-establishment message including the short MAC address and the RRC message type field.