WO2020056433A2 - Communication sécurisée de demande de commande de ressource radio (rrc) sur porteuse radio de signal zéro (srb0) - Google Patents

Communication sécurisée de demande de commande de ressource radio (rrc) sur porteuse radio de signal zéro (srb0) Download PDF

Info

Publication number
WO2020056433A2
WO2020056433A2 PCT/US2019/060766 US2019060766W WO2020056433A2 WO 2020056433 A2 WO2020056433 A2 WO 2020056433A2 US 2019060766 W US2019060766 W US 2019060766W WO 2020056433 A2 WO2020056433 A2 WO 2020056433A2
Authority
WO
WIPO (PCT)
Prior art keywords
rrc
resume
message
rnti
assigned
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2019/060766
Other languages
English (en)
Other versions
WO2020056433A8 (fr
WO2020056433A3 (fr
Inventor
Ahmad Shawky MUHANNA
Li Hu
Mazin Ali AL-SHALASH
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
FutureWei Technologies Inc
Original Assignee
FutureWei Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by FutureWei Technologies Inc filed Critical FutureWei Technologies Inc
Publication of WO2020056433A2 publication Critical patent/WO2020056433A2/fr
Publication of WO2020056433A3 publication Critical patent/WO2020056433A3/fr
Publication of WO2020056433A8 publication Critical patent/WO2020056433A8/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment

Definitions

  • 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).
  • RRC Radio Resource Control
  • SRBO Signal Radio Bearer Zero
  • LTE networks provide three basic security features, namely: LTE authentication, non-access stratum (NAS) security, and access stratum (AS) security.
  • LTE authentication feature ensures that a user is an authorized subscriber to the network (or network service) that the user is attempting to access
  • 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.
  • RAN radio access network
  • 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
  • FIG. 7 is a diagram of an embodiment transceiver.
  • An embodiment method for transmitting an RRC resume 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.
  • the at least one UE identity includes an Inactive Radio Network Temporary Identifier (I-RNTI) assigned to the UE.
  • I-RNTI Inactive Radio Network Temporary Identifier
  • the at least one UE identity includes a source cell radio network temporary identifier (C-RNTI) assigned to the UE.
  • 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.
  • I-RNTI Inactive Radio Network Temporary Identifier
  • C-RNTI source cell radio network temporary identifier
  • the RRC resume message further includes the source C- RNTI.
  • the resume cause field indicates a cause of a UE resume attempt.
  • 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.
  • 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.
  • I-RNTI Inactive Radio Network Temporary Identifier
  • 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.
  • I-RNTI Inactive Radio Network Temporary Identifier
  • 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).
  • I-RNTI Inactive Radio Network Temporary Identifier
  • UE-SN-Temp-ID UE secondary network temporary identifier
  • 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 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.
  • the at least one UE identity includes a source cell radio network temporary identifier (C-RNTI) assigned to the UE.
  • the RRC re-establishment message includes the source C-RNTI.
  • 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.
  • C-RNTI source cell radio network temporary identifier
  • PCI source physical cell idenfier
  • 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).
  • C-RNTI source cell radio network temporary identifier
  • PCI physical cell idenfier
  • UE-SN- Temp-ID UE secondary network temporary identifier
  • 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.
  • the target eNB 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.
  • 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.
  • 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.
  • 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”.
  • 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.
  • RAN2 agreed to use Resume ID, e.g. together 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”.
  • the RRC Resume Request message has a“Resumecause” field that identifies the cause of the Resume Request message, e.g. consistent“highPriority Access”,“emergency”, delayToleranceAccess,
  • SRB0 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. surround 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,
  • RRC message type RRC Resume Cause in the RRC Resume Request message, etc.
  • 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.
  • 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
  • I-RNTI may be replaced by the (source C-RNTI + Source PCI).
  • 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).
  • 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. simply ResumeMAC-I to be valid with a single cell ID, which the target cell ID.
  • 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.
  • the ShortMAC-I is calculated over the following parameters:
  • Source PCI The Source Cell physical Identity of the source gNB;
  • Target Cell ID This to bind the authentication token, e.g. compris 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;
  • RRC Message Type e.g.,, in this case RRC-Reestablishment Request message;
  • VARShortMAC-Input :: (Source C-RNTI, Source PCI, RRC Message Type, Target Cell ID).
  • 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. blunt ShortMAC-I to be valid with a single cell ID, which the target cell ID.
  • RRC Message Type e.g. precede in this case RRC-Reestablishment Request message
  • 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).
  • 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
  • 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.
  • 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.
  • the source gNB (gNB l) authenticates the UE & the RRC message to gNB2.
  • 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,
  • 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 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
  • 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.
  • 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
  • Target Cell ID Cell2 of gNB2
  • K RR( itl , & Integrity algorithm the Old key & the integrity protection algorithm that were used between the UE and gNBl.
  • the source gNB may authenticate the UE & the RRC message & send the UE Context to the gNB2.
  • 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 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 receives the UE Context from source gNB (gNBl).
  • the target gNB 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the UE may calculate the ResumeMAC-I or
  • 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.).
  • access interfaces e.g., radio access network (RAN) interfaces, etc.
  • 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.
  • Next Generation Radio, (NR, 5G Radio) long term evolution
  • LTE-A LTE advanced
  • HSPA High Speed Packet Access
  • Wi-Fi 802.1 la/b/g/n/ac etc.
  • 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.
  • 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.
  • 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.
  • the serving base station 110 sends an RRC connection release message 212 that includes the I-RNTI and NCC1 to the UE 130.
  • I-RNTI Inactive Radio Network Temporary Identifier
  • NCC1 a source cell ID
  • RRC connection release message 212 that includes the I-RNTI and NCC1 to the UE 130.
  • 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.
  • 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.
  • 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.
  • the target base station 120 may extract the RNTI and resume MAC address from the RRC resume request 220.
  • 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.
  • 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.
  • 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.
  • 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.
  • SRB0 signal radio bearer zero
  • 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.
  • the serving base station 110 sends a handover command 412 that includes an NCC2 to the UE 130.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the UE 230 may achieve synchronization with the target base station 120 based on the NCC2 and derive the K RR int and
  • 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.
  • 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.
  • 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.
  • SRB0 signal radio bearer zero
  • 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.
  • 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.
  • the UE 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.
  • 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.
  • 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.
  • MSG4 RRC Release message
  • 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.
  • 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
  • the memory 606 may be any component or collection of components adapted to store programming and/or instructions for execution by the processor 604.
  • 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.
  • 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.
  • 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.
  • 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.
  • the processing system 600 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.).
  • the processing system 600 is included in a network device that is accessing, or part otherwise of, a telecommunications network.
  • 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.
  • 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.
  • 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.
  • 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.
  • the transceiver 700 transmits and receives signaling over a wireless medium.
  • 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.).
  • 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.).
  • the network-side interface 702 comprises one or more antenna/radiating elements.
  • 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.
  • 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.
  • 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”,
  • EIA0 E-UTRAN Integrity protection algorithm No. zero.
  • NEA0 Next Generation (5G) Encryption Algorithm No. 1.
  • gNB Next Generation NB.
  • AMF Access Management Function
  • SMF Session Management Function
  • PDU Packet Data Unit -or- Protocol Data Unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Des modes de réalisation de l'invention concernent des procédés de transmission de messages de Reprise RRC et de Rétablissement RRC. Le message de reprise RRC peut comprendre une adresse de contrôle d'accès au support (MAC) de reprise et un champ de reprise. L'adresse MAC de reprise est calculée en fonction d'au moins une identité d'UE et d'une valeur du champ de cause de reprise. Le champ de cause de reprise indique une cause d'une tentative de reprise d'UE. Le message de rétablissement de RRC comprend une adresse MAC courte et un champ de type de message RRC. L'adresse MAC courte est calculée conformément à au moins une identité d'UE et une valeur d'un champ de type de message RRC. Le champ de cause de reprise indique une cause d'une tentative de reprise d'UE.
PCT/US2019/060766 2018-09-12 2019-11-11 Communication sécurisée de demande de commande de ressource radio (rrc) sur porteuse radio de signal zéro (srb0) Ceased WO2020056433A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862730110P 2018-09-12 2018-09-12
US62/730,110 2018-09-12

Publications (3)

Publication Number Publication Date
WO2020056433A2 true WO2020056433A2 (fr) 2020-03-19
WO2020056433A3 WO2020056433A3 (fr) 2020-04-30
WO2020056433A8 WO2020056433A8 (fr) 2020-08-13

Family

ID=68807379

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/060766 Ceased WO2020056433A2 (fr) 2018-09-12 2019-11-11 Communication sécurisée de demande de commande de ressource radio (rrc) sur porteuse radio de signal zéro (srb0)

Country Status (1)

Country Link
WO (1) WO2020056433A2 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114245484A (zh) * 2020-09-09 2022-03-25 大唐移动通信设备有限公司 Rrc连接恢复的处理方法、装置、电子设备及存储介质
WO2022084053A1 (fr) * 2020-10-22 2022-04-28 Nokia Technologies Oy Mécanisme de signalisation de radiomessagerie
WO2022206362A1 (fr) * 2021-04-02 2022-10-06 华为技术有限公司 Procédé et appareil de communication
CN116114281A (zh) * 2020-07-31 2023-05-12 苹果公司 生成安全密钥以用于处理来自非活动状态下用户设备的数据传输
WO2023083691A1 (fr) * 2021-11-10 2023-05-19 Telefonaktiebolaget Lm Ericsson (Publ) Génération d'un jeton d'authentification
EP4294113A1 (fr) * 2022-06-14 2023-12-20 Nokia Technologies Oy Récupération de contexte d'équipement utilisateur dans un état inactif de commande de ressources radio

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116114281A (zh) * 2020-07-31 2023-05-12 苹果公司 生成安全密钥以用于处理来自非活动状态下用户设备的数据传输
CN114245484A (zh) * 2020-09-09 2022-03-25 大唐移动通信设备有限公司 Rrc连接恢复的处理方法、装置、电子设备及存储介质
CN114245484B (zh) * 2020-09-09 2023-06-02 大唐移动通信设备有限公司 Rrc连接恢复的处理方法、装置、电子设备及存储介质
WO2022084053A1 (fr) * 2020-10-22 2022-04-28 Nokia Technologies Oy Mécanisme de signalisation de radiomessagerie
WO2022206362A1 (fr) * 2021-04-02 2022-10-06 华为技术有限公司 Procédé et appareil de communication
WO2023083691A1 (fr) * 2021-11-10 2023-05-19 Telefonaktiebolaget Lm Ericsson (Publ) Génération d'un jeton d'authentification
US20250023719A1 (en) * 2021-11-10 2025-01-16 Telefonaktiebolaget Lm Ericsson (Publ) Generating an authentication token
EP4294113A1 (fr) * 2022-06-14 2023-12-20 Nokia Technologies Oy Récupération de contexte d'équipement utilisateur dans un état inactif de commande de ressources radio
US12477616B2 (en) 2022-06-14 2025-11-18 Nokia Technologies Oy User equipment context retrieval in radio resource control inactive state

Also Published As

Publication number Publication date
WO2020056433A8 (fr) 2020-08-13
WO2020056433A3 (fr) 2020-04-30

Similar Documents

Publication Publication Date Title
US11653199B2 (en) Multi-RAT access stratum security
US20230353379A1 (en) Authentication Mechanism for 5G Technologies
US10674360B2 (en) Enhanced non-access stratum security
US11297502B2 (en) Method and device for negotiating security and integrity algorithms
US10382206B2 (en) Authentication mechanism for 5G technologies
EP3281434B1 (fr) Procédé, appareil et système pour assurer un chiffrement ou une protection d'intégrité dans un réseau sans fil
EP3554047B1 (fr) Procédé et système pour permettre une communication sécurisée pour transmission inter-enb
US9049594B2 (en) Method and device for key generation
WO2020056433A2 (fr) Communication sécurisée de demande de commande de ressource radio (rrc) sur porteuse radio de signal zéro (srb0)
US20170359719A1 (en) Key generation method, device, and system
CN109309920A (zh) 安全实现方法、相关装置以及系统
WO2019158117A1 (fr) Système et procédé pour assurer la sécurité dans un système de communication sans fil avec séparation de plan utilisateur
EP3562186B1 (fr) Procédé et dispositif de contrôle d'accès
CN114631398B (zh) 一种通信方法，通信装置及通信系统
EP3311599B1 (fr) Architecture et procédé de sécurité de réseau ultra-dense
CA3017611C (fr) Securite de strate de non-acces amelioree

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19816482

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19816482

Country of ref document: EP

Kind code of ref document: A2