US20190208411A1 - Security framework for msg3 and msg4 in early data transmission - Google Patents
Security framework for msg3 and msg4 in early data transmission Download PDFInfo
- Publication number
- US20190208411A1 US20190208411A1 US16/294,653 US201916294653A US2019208411A1 US 20190208411 A1 US20190208411 A1 US 20190208411A1 US 201916294653 A US201916294653 A US 201916294653A US 2019208411 A1 US2019208411 A1 US 2019208411A1
- Authority
- US
- United States
- Prior art keywords
- ncc
- message
- edt
- encryption key
- transmission
- 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.)
- Abandoned
Links
- 230000005540 biological transmission Effects 0.000 title claims description 54
- 238000000034 method Methods 0.000 claims abstract description 110
- 230000008859 change Effects 0.000 claims abstract description 9
- 238000009795 derivation Methods 0.000 claims description 44
- 230000004044 response Effects 0.000 claims description 43
- 230000015654 memory Effects 0.000 claims description 32
- 238000004891 communication Methods 0.000 claims description 20
- 238000012545 processing Methods 0.000 claims description 15
- 239000000725 suspension Substances 0.000 claims description 7
- 101100059553 Caenorhabditis elegans cdk-1 gene Proteins 0.000 description 13
- 230000006870 function Effects 0.000 description 12
- 108091006623 SLC12A3 Proteins 0.000 description 8
- 102100034261 Solute carrier family 12 member 3 Human genes 0.000 description 8
- 230000008569 process Effects 0.000 description 7
- 238000004364 calculation method Methods 0.000 description 6
- 238000010276 construction Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- 102100023702 C-C motif chemokine 13 Human genes 0.000 description 4
- 102100023705 C-C motif chemokine 14 Human genes 0.000 description 4
- 101100382872 Homo sapiens CCL13 gene Proteins 0.000 description 4
- 101100382874 Homo sapiens CCL14 gene Proteins 0.000 description 4
- 101100533725 Mus musculus Smr3a gene Proteins 0.000 description 4
- 230000000977 initiatory effect Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000005291 magnetic effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 230000007274 generation of a signal involved in cell-cell signaling Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
-
- H04W12/001—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
-
- H04W12/0401—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/041—Key generation or derivation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
- H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access
- H04W74/08—Non-scheduled access, e.g. ALOHA
- H04W74/0833—Random access procedures, e.g. with 4-step access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/30—Connection release
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
Definitions
- Embodiments pertain to radio access networks (RANs). Some embodiments relate to cellular networks, including Third Generation Partnership Project Long Term Evolution (3GPP LTE) networks and LTE advanced (LTE-A) networks, 4 th generation (4G) networks and 5 th generation (5G) or next generation (NG) networks. Some embodiments relate to a security framework for network connectivity.
- 3GPP LTE Third Generation Partnership Project Long Term Evolution
- LTE-A LTE advanced
- 4G 4 th generation
- 5G 5 th generation
- NG next generation
- Some embodiments relate to a security framework for network connectivity.
- Such network processes may include the security processes for UEs, and in particular security processes used during early data transmission (EDT).
- EDT early data transmission
- FIG. 1 illustrates combined communication system in accordance with some embodiments.
- FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments.
- FIG. 3 illustrates key handling in accordance with some embodiments.
- FIG. 4 illustrates radio resource control (RRC) message exchange in accordance with some embodiments.
- RRC radio resource control
- FIG. 5 illustrates a resumption procedure in accordance with some embodiments.
- FIG. 1 illustrates a combined communication system in accordance with some embodiments.
- the system 100 includes 3GPP LTE/4G and NG network functions.
- a network function can be implemented as a discrete network element on a dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., dedicated hardware or a cloud infrastructure.
- the evolved packet core (EPC) of the LTE/4G network contains protocol and reference points defined for each entity.
- These core network (CN) entities may include a mobility management entity (MME) 122 , serving gateway (S-GW) 124 , and paging gateway (P-GW) 126 .
- MME mobility management entity
- S-GW serving gateway
- P-GW paging gateway
- the control plane and the user plane may be separated, which may permit independent scaling and distribution of the resources of each plane.
- the UE 102 may be connected to either an access network or random access network (RAN) 110 and/or may be connected to the NG-RAN 130 (gNB) or an Access and Mobility Function (AMF) 142 .
- the RAN may be an eNB, a gNB or a general non-3GPP access point, such as that for Wi-Fi.
- the NG core network may contain multiple network functions besides the AMF 112 .
- the network functions may include a User Plane Function (UPF) 146 , a Session Management Function (SMF) 144 , a Policy Control Function (PCF) 132 , an Application Function (AF) 148 , an Authentication Server Function (AUSF) 152 and User Data Management (UDM) 128 .
- UPF User Plane Function
- SMF Session Management Function
- PCF Policy Control Function
- AF Application Function
- AUSF Authentication Server Function
- UDM User Data Management
- the AMF 142 may provide UE-based authentication, authorization, mobility management, etc.
- the AMF 142 may be independent of the access technologies.
- the SMF 144 may be responsible for session management and allocation of IP addresses to the UE 102 .
- the SMF 144 may also select and control the UPF 146 for data transfer.
- the SMF 144 may be associated with a single session of the UE 102 or multiple sessions of the UE 102 . This is to say that the UE 102 may have multiple 5G sessions. Different SMFs may be allocated to each session. The use of different SMFs may permit each session to be individually managed. As a consequence, the functionalities of each session may be independent of each other.
- the UPF 126 may be connected with a data network, with which the UE 102 may communicate, the UE 102 transmitting uplink data to or receiving downlink data from the data network.
- the AF 148 may provide information on the packet flow to the PCF 132 responsible for policy control to support a desired QoS.
- the PCF 132 may set mobility and session management policies for the UE 102 . To this end, the PCF 132 may use the packet flow information to determine the appropriate policies for proper operation of the AMF 142 and SMF 144 .
- the AUSF 152 may store data for UE authentication.
- the UDM 128 may similarly store the UE subscription data.
- the gNB 130 may be a standalone gNB or a non-standalone gNB, e.g., operating in Dual Connectivity (DC) mode as a booster controlled by the eNB 110 through an X2 or Xn interface. At least some of functionality of the EPC and the NG CN may be shared (alternatively, separate components may be used for each of the combined component shown).
- the eNB 110 may be connected with an MME 122 of the EPC through an S1 interface and with a SGW 124 of the EPC 120 through an S1-U interface.
- the MME 122 may be connected with an HSS 128 through an S6a interface while the UDM is connected to the AMF 142 through the N8 interface.
- the SGW 124 may connected with the PGW 126 through an S5 interface (control plane PGW-C through S5-C and user plane PGW-U through S5-U).
- the PGW 126 may serve as an IP anchor for data through the internet.
- the NG CN may contain an AMF 142 , SMF 144 and UPF 146 , among others.
- the eNB 110 and gNB 130 may communicate data with the SGW 124 of the EPC 120 and the UPF 146 of the NG CN.
- the MME 122 and the AMF 142 may be connected via the N26 interface to provide control information there between, if the N26 interface is supported by the EPC 120 .
- the gNB 130 is a standalone gNB, the 5G CN and the EPC 120 may be connected via the N26 interface.
- FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments.
- the communication device may be a peer machine in peer-to-peer (P2P) (or other distributed) network environment.
- the communication device 200 may be a specialized computer, a personal or laptop computer (PC), a tablet PC, a personal digital assistant (PDA), a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
- the communication device 200 may be embedded within other, non-communication based devices such as vehicles and appliances.
- Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms.
- Modules and components are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner.
- circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module.
- the whole or part of one or more computer systems e.g., a standalone, client or server computer system
- one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations.
- the software may reside on a machine readable medium.
- the software when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
- module (and “component”) is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein.
- each of the modules need not be instantiated at any one moment in time.
- the modules comprise a general-purpose hardware processor configured using software
- the general-purpose hardware processor may be configured as respective different modules at different times.
- Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.
- the communication device 200 may include a hardware processor 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), a main memory 204 and a static memory 206 , some or all of which may communicate with each other via an interlink (e.g., bus) 208 .
- the main memory 204 may contain any or all of removable storage and non-removable storage, volatile memory or non-volatile memory.
- the communication device 200 may further include a display unit 210 such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse).
- a hardware processor 202 e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof
- main memory 204 may contain any or all of removable storage and non-removable storage, volatile memory or non-volatile memory.
- the communication device 200
- the display unit 210 , input device 212 and UI navigation device 214 may be a touch screen display.
- the communication device 200 may additionally include a storage device (e.g., drive unit) 216 , a signal generation device 218 (e.g., a speaker), a network interface device 220 , and one or more sensors, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.
- GPS global positioning system
- the communication device 200 may further include an output controller, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
- a serial e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
- USB universal serial bus
- IR infrared
- NFC near field communication
- the storage device 216 may include a non-transitory machine readable medium 222 (hereinafter simply referred to as machine readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein.
- the instructions 224 may also reside, completely or at least partially, within the main memory 204 , within static memory 206 , and/or within the hardware processor 202 during execution thereof by the communication device 200 .
- the machine readable medium 222 is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 224 .
- machine readable medium may include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 200 and that cause the communication device 200 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions.
- Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media.
- machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks.
- non-volatile memory such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices
- EPROM Electrically Programmable Read-Only Memory
- EEPROM Electrically Erasable Programmable Read-Only Memory
- flash memory devices e.g., electrically Erasable Programmable Read-Only Memory (EEPROM)
- EPROM Electrically Programmable Read-Only Memory
- EEPROM Electrically Erasable Programmable Read-Only Memory
- flash memory devices e.g
- the instructions 224 may further be transmitted or received over a communications network using a transmission medium 226 via the network interface device 220 utilizing any one of a number of transfer protocols (e.g., frame relay, interne protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.).
- Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks.
- Communications over the networks may include one or more different protocols, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi, IEEE 802.16 family of standards known as WiMax, IEEE 802.15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, a next generation (NG)/5 th generation (5G) standards among others.
- the network interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the transmission medium 226 .
- RRC messages are provided over the course of the connection between the UE and a RAN.
- RRC messages include initial connection messages, such as RRC connection request, RRC connection setup and RRC connection setup, reconfiguration messages, such as RRC connection reconfiguration and RRC connection reconfiguration complete messages, and suspension and release messages, such as RRC Connection Release and RRC Connection Reestablish/Resume messages.
- At least some of the RRC messages may involve security procedures, such as the generation of keys.
- a shortResumeMAC-I message authentication token is calculated taking into account the stored K RRCint which is associated with a previous Next Hop Chaining Counter (NCC) from a previous connection (e.g., a source eNB where the UE RRC connection was suspended).
- NCC Next Hop Chaining Counter
- the RRCConnectionResumeRequest message is transmitted using SRB0 and is thus neither integrity protected nor ciphered
- the RRCConnectionResumeRequest message re-uses only the existing key K RRCint for the shortResumeMAC-I calculation.
- the UE may derive new access stratum (AS) keys using the key K eNB* derived based on the new NCC.
- AS access stratum
- EDT allows one uplink data transmission, optionally followed by one downlink data transmission during the random access procedure.
- Bandwidth reduced Low complexity (BL) UEs, UEs in coverage enhancement (CE) mode or Narrow Band Internet of Things (NB-IoT) UEs may use EDT.
- EDT is triggered when the upper layers have requested the establishment or resumption of the RRC Connection for Mobile Originated data and the uplink data size is less than or equal to a transport block size indicated in the system information.
- the user data is to be protected in the RRCConnectionResumeRequest message (Msg3) and hence the RRCConnectionResumeRequest message also uses a fresh user plane (UP) AS key (K UPpenc ) before sending the RRCConnectionResumeRequest message. Therefore, the new fresh AS keys (K RRCint , K RRCenc and K UPenc ) are derived from K eNB* that is either derived from the currently active K eNB of the source cell (referred as horizontal derivation assuming same old NCC) or derived from the NH associated with the new NCC (referred as vertical derivation). Whether the derivation is horizontal or vertical, the UE may obtain a new K eNB* for the derivation of fresh keys.
- K eNB* is either derived from the currently active K eNB of the source cell (referred as horizontal derivation assuming same old NCC) or derived from the NH associated with the new NCC (referred as vertical derivation).
- the UE can perform a horizontal derivation from K eNB to derive new keys before sending Msg3 in EDT.
- K ASME is the MME (ASME) Base/Intermediate key that is derived in the HSS and UE from the Cipher key and Integrity key (which are derived in the USIM using AKA) using AKA.
- K eNB is the eNB Base key, which is an intermediate key derived in MME and UE from K ASME when the UE transits to ECM CONNECTED STATE or by UE and target eNB from K eNB* during handover.
- K eNB* is the eNB handover transition key, which is an intermediate key derived in source eNB and UE during handover when performing horizontal (K eNB ) or vertical key (NH) derivation. It is used at target eNB to derive K eNB .
- K RRCint is an encryption key for protection of RRC data derived in the eNB and the UE.
- K UPenc is the encryption key for protection of user plane data derived in eNB and UE.
- All EPS security keys may be 256 bits in length.
- the ciphering and integrity keys for AS and NAS algorithms may use only the 128 Least Significant Bits (LSB) of the derived keys.
- FIG. 4 illustrates RRC message exchange in accordance with some embodiments.
- the overall framework of using NCC for EDT following legacy UE behavior wherever possible is shown in FIG. 4 .
- the UE does not transition from the RRC_Idle state to the RRC_Connected state during EDT.
- the UE may send a RACH Request (Msg1) in the RACH procedure.
- Msg1 RACH Request
- a UE in the RACH group may synchronize to the network using the RACH procedure.
- the RACH Request may contain an EDT indication.
- the RACH request may be transmitted by the UE to the eNB using a RACH resource.
- the RACH request may be transmitted over 6 Resource blocks.
- the RACH request may contain a preamble index, which may be randomly selected based on the size of the RRC connection request from preamble information in system information block (SIB).
- SIB system information block
- the RACH Request for EDT may use a unique preamble that is different from that used for a legacy procedure.
- the eNB having received the RACH request may allocate a temporary Cell Radio Network Temporary Identifier (C-RNTI) for the UE.
- C-RNTI Cell Radio Network Temporary Identifier
- the temporary Cell RNTI may be transmitted to the UE in a RACH Response message (RAR—Msg 2) from the eNB.
- RAR—Msg 2 RACH Response message
- the RAR message may also contain the appropriate timing advance (TA) for the UE, determined by the eNB.
- the RAR message may contain a scheduling grant for the UE to send a RRCConnectionResumeRequest message, where the scheduling grant may indicate whether frequency hopping is to be used as well as the resource block assignment.
- the RAR message may further indicate the modulation and coding scheme and the power for the PUSCH to be used by the UE.
- the UL grant in the RAR message may be larger than that of a legacy RAR grant to provide additional UL resources for transmission by the UE of a UL message in addition to a RRCConnectionResumeRequest message.
- the UE may transmit a RRCConnectionResumeRequest message including a shortResumeMAC-I calculated using currently stored K RRCint .
- the UE may also derive the new key (K UPenc ) to cipher the UL user plane (UP) data in a Dedicated Traffic Channel (DTCH) and multiplex the UL UP data with the RRC message to transmit in Msg3.
- K UPenc new key
- UP UL user plane
- DTCH Dedicated Traffic Channel
- the RRC message in the Dedicated Control Channel is integrity protected using the key (K RRCint ) generated prior to the transmission of Msg3 and DL data in the DTCH is ciphered using the key (K UPenc ) that was also generated prior to the transmission of Msg3. Since the AS security is active and the Packet Data Convergence Protocol (PDCP) is already established, the PDCP layer performs the verification of the integrity protection of the RRC message in DCCH.
- K RRCint the key generated prior to the transmission of Msg3
- K UPenc the key that was also generated prior to the transmission of Msg3.
- the PDCP layer performs the verification of the integrity protection of the RRC message in DCCH.
- a UE may be suspended by an eNB that supports EDT and resumes in a legacy eNB that does not support EDT, the UE may perform the legacy resume procedure.
- the UE derives new keys based on the currently stored value of NCC before sending Msg3.
- the UE and eNB may be out-of-sync if the legacy eNB has an unused NCC.
- the UE may have resumed in the same cell of a Rel-14 network or network that does not support EDT.
- the network may have new NCC_1 provided by the MME.
- the MME may store a fresh NCC and send the new NCC to the eNB in the S1-AP UE Context Resume Response message.
- the eNB may not provide the NCC_1 to the UE during the suspend procedure (prior to the RACH transmission). The UE is thus unaware of the new NCC_1 provided by the MME until the UE engages in a new resumption or re-establishment of the RRC connection, or handover is performed.
- the UE may continue to use the old NCC_0 to initiate EDT.
- the legacy source eNB may use the unused NCC_1 to derive KeNB*. That is, if the source eNB has a fresh ⁇ NH, NCC ⁇ pair from the MME then the fresh pair may be used and the fresh NH may be used in the new K eNB* derivation.
- the AS security context sent to the target eNB may include the new derived K eNB* , the NCC associated to the K eNB* . In this case, deciphering of UL data can result in a corrupted packet due to the differences between the NCC used by the eNB and that used by the UE.
- the eNB rejects the connection from the UE during the RRC connection resumption process.
- the UE may not use EDT in the resume procedure if the RRC connection was suspended by a legacy eNB that did not support EDT in the previous connection.
- the UE may determine whether or not it received the NCC in the previous connection or previous suspend procedure and if it did not receive the NCC in the previous connection or previous suspend procedure, the UE may avoid using EDT in the resume procedure.
- the UE may echo back (i.e., transmit) the used ⁇ KeNB*, NCC ⁇ pair in Msg3 using a Medium Access Control (MAC) Control element (CE) or PDCP control packet data unit (PDU).
- MAC Medium Access Control
- CE Control element
- PDU packet data unit
- a UE may be suspended by a Rel-15 eNB that has disabled EDT and resumed in a (source) eNB that has enabled EDT.
- a change in legacy behaviour at the network side may be provided if the eNB decides to move the UE in the RRC_CONNECTED mode after receiving RRCConnectionResumeRequest for EDT.
- the UE connection is suspended and the eNB has new fresh NCC_1.
- the eNB has not delivered NCC_1 to the UE yet because the eNB is currently disabling the EDT feature.
- the eNB is capable of supporting EDT or new Rel-15 eNB. Now, the UE resumes the connection in a different target eNB and the UE still uses the old NCC_0.
- the UE may determine whether or not it received the NCC in the previous connection or previous suspend procedure and if it did not receive the NCC in the previous connection or previous suspend procedure, the UE avoids using EDT in the resume procedure.
- the source eNB may decide to move the UE to the RRC_CONNECTED state and provide only KeNB* and the associated NCC_1 to the target eNB.
- the target eNB may provide the new NCC_1 in the RRCConnectionResume message as mandatory in Msg4 and the UE may be unable to ignore the new NCC_1.
- the target eNB may decide to move the UE to the RRC_CONNECTED state. This means that the source eNB may provide KeNB* and the associated NCC_0 for EDT to the target eNB, as well as providing KeNB* and the associated NCC_1 to move the UE to the RRC CONNECTED state. In other embodiments, the source eNB may always provide KeNB* and associated NCC_0 and any unused NCC_1, if any, to the target eNB. In both of these embodiments, the target eNB has option to provide either the old NCC_0 or the new NCC_1 in Msg4 when Msg4 contains a legacy RRCConnectionResume message.
- NCC_0 is provided in Msg4
- the UE ignores NCC_0 and keeps using current keys for subsequent messages because the UE has already derived the keys associated with NCC_0 before sending Msg3.
- NCC_1 is provided in Msg4, then the UE may follow the legacy procedure and derive new keys using KeNB* that is derived with vertical derivation as the UE has received a new NCC.
- the eNB may reject the EDT request of the UE if the MME is down, the AS security context has been lost or there is network congestion. If the eNB rejects the RRCConnectionResumeRequest message from the UE due to network congestion or AS security context being lost, the eNB may be unable to derive any keys. In this case, if the UE goes back to IDLE mode with a suspend indication, the UE and eNB may have a different value of the keys. Therefore, after the connection reject, the UE may not derive new key and may instead use the same key for the calculation of shortResumeMAC-I in Msg3 in the next resume procedure for EDT.
- the UE may use the newly derived key (KRRCint) for every calculation of shortResumeMAC-I in Msg3 in every attempt of the RRC connection resume procedure.
- KRRCint newly derived key
- the UE may count how many times the key is derived from the first attempt of the unsuccessful ongoing resume procedure. The count may be included in Msg3 as a MAC CE or PDCP control PDU.
- the eNB may also derive the key for the same number of times to be in-sync with the UE.
- a UE may fall back due to a legacy grant in the RAR.
- the UE may be unable to send UL data. Instead, the UE may send the legacy RRCConnectionResumeRequest message.
- the UE may activate AS security during the construction of the RRC message for Msg3 in EDT.
- the RRC sends the RRC message for EDT to lower layers so that the lower layers can initiate EDT using the RACH procedure. Since the UL data should also be in the transmission buffer in RLC, the RRC connection may resume the dedicated radio bearers (DRBs) and AS security so that PDCP can encrypt the user UL data.
- DRBs dedicated radio bearers
- the UE can ask the Assembly and Multiplexing entity to get the MAC PDU to transmit from the transmission buffer. In this case, the UE may derive new AS keys prior to receiving the RAR. However, when the UL grant is not sufficient, the UE may fall back to the legacy procedure. If the UE follows the legacy procedure, then the UE may rederive new keys when the UE receives the legacy RRCConectionResume message in Msg4.
- KeNB* a second time could make the UE and eNB out of sync if the eNB derives KeNB* only once (as the eNB received the preamble from the UE and in response sent the legacy UL grant in the RAR) while the UE derived KeNB* twice using same value of NCC in the same RRC connection.
- the UE may use the same AS keys in case of fallback to the legacy RRC connection procedure if the AS keys are derived (security is activated) during the construction of the RRC message for Msg3 prior to receiving the RAR in EDT.
- the AS security has already been established, thus, these procedures are skipped by the UE. Similar to the legacy procedure, however, the UE may enter the RRC_CONNECTED state.
- the RRCConnectionResume from the eNB may include a dummy NCC (e.g., a NCC that has an invalid value) as the UE and eNB are using the correct NCC.
- the dummy NCC number may be ignored by the UE and the eNB in subsequent legacy steps as AS security has already been established and the NCC value is current.
- the UE may follow the legacy procedure in case of fallback to the legacy RRC connection procedure if the AS keys are derived (security is activated) during the construction of RRC message for Msg3 after receiving the RAR in EDT.
- the MAC layer may indicate to the RRC layer to construct the RRC message. In this case, it is assumed that there is enough processing time before the scheduled UL transmission time.
- the UE may fall back due to a change in the coverage enhancement (CE) level during power ramping.
- CE coverage enhancement
- the UE may change the CE level due to power ramping.
- the CE level is changed, the maximum transport block (TB) size that can be transmitted in EDT is changed. Due to this change, the UL data or Msg3 may not fit in a single transmission. In this case, the UE fall backs to the legacy procedure.
- the KeNB may not be updated if the NCC received by the UE in Msg4 is the same as that already stored by the UE.
- the UE may revert to the configuration prior to sending the preamble for EDT in Msg1.
- the UE may check the NCC. If the NCC provided in Msg4 is same as the currently stored NCC, the UE may not update the KeNB.
- the UP keys may be derived using the KeNB.
- the UE does not derive the keys and uses the same UP keys (KRRCint, KRRCenc and KUPenc). If the NCC provided in Msg4 is different from the currently stored NCC, the UE may perform a vertical derivation of the KeNB and derive new UP keys.
- multiple KeNBs may be stored. For example, when two KeNBs are stored, one may be the old KeNB and the other the new KeNB that is derived based on the NCC that was provided in the RRCConnectionRelease message with the suspend indication in the previous connection.
- the UE when the UE activates the AS security (deriving KeNB and AS Keys) before sending the RRCConnectionResumeRequest message for EDT, the UE may store the new KeNB as well as the old KeNB if horizontal derivation is performed based on the NCC. The new KeNB may be derived based on the old KeNB. If vertical derivation is performed, the UE may store only the new KeNB.
- the UE may delete the new KeNB and keep only the old KeNB.
- the UE resumes all SRBs and DRBs and re-establishes the AS security using the old KeNB before entering the RRC_CONNECTED state.
- the UE may recalculate the new KeNB in response to the legacy grant. If there is no old KeNB, the UE may not store any KeNB.
- the UE may perform horizontal derivation of the KeNB when the UE has a stored value of the KeNB. If the UE has no stored value of the KeNB, the UE may always derive the KeNB based on the currently stored NH count and the NCC. If NCC provided in Msg4 is different than the stored value of NCC, the UE may always perform the vertical derivation of the KeNB.
- a RRCConnectionReject message may be received in response to the RRCConnectionResumeRequest message for EDT.
- the reception of the RRCConnectionReject message may indicate to the UE that at least one of the messages between the eNB and the MME, and between the MME and SGW (i.e., UEContextResumeRequest message, Modify Bearer message, UEContextResumeResponse message, Suspend procedure message) was unsuccessful.
- the UE may enter the IDLE mode with a suspend indication and store the AS context.
- the UE may activate AS security before sending the Msg3.
- the UE may store two old KeNB and a new KeNB when horizontal derivation is performed to derive the new key.
- the UE may delete the new KeNB and store the old KeNB. If there is no old KeNB, the UE may not store any KeNB.
- the UE may perform the horizontal derivation of the KeNB—otherwise the UE may perform a derivation of the KeNB based on the stored values of NH and NCC.
- the UE may perform horizontal derivation of the KeNB when the UE has a stored value of the KeNB. If the UE has no stored value of KeNB, the UE may always derive the KeNB based on the currently stored NH count and the NCC. If the NCC provided in Msg4 is different than the stored value of NCC, the UE may always perform the vertical derivation of the KeNB.
- the UE may store only one KeNB. If a RRCConnectionReject message is received by the UE after initiating EDT, the UE may not update the KeNB in the next resume procedure in the same cell. Using the same KeNB, the UP keys may be derived in the next resume procedure for EDT before sending Msg3. In another embodiment, the UE may store both the KeNB and UP Keys and may not derive any keys in the next resume procedure for EDT in the same cell.
- the UE may not update the KeNB and instead use the same KeNB, while the UP keys are derived. In another option, the UE may not derive any keys and instead use the same stored KeNB and UP keys. If the NCC provided in Msg4 is different than the stored NCC, the UE may always perform vertical derivation of KeNB.
- EDT for a UP solution, if the UE has received a NCC in the RRCConnectionRelease message in the preceding connection, the UE can initiate the EDT. In this case, the old KRRCint key may be used to calculate the shortResumeMAC-I.
- the UE may use the currently stored old KRRCint to calculate the shortResumeMAC-I before deriving new keys using the NCC.
- the UE may derive new keys and store two sets of AS security—one corresponding to the old KRRCint and the other corresponding to the new KRRCint—until the resume procedure fails or succeeds.
- the UE may discard the new AS security corresponding to the new KRRCint so that the UE uses the same KRRCint to calculate the shortResumeMAC-I in the next resume procedure.
- the UE may also delete the old AS security keys.
- the UE may discard the old security context corresponding to the KRRCint that was used to calculate the shortResumeMAC-I.
- the resume procedure may fail due to cell reselection, which may lead to the MAC being reset.
- the UE may also discard the new security context as the UE restarts the resume procedure.
- the UE may also transmit the RRCConnectionResumeRequest message for EDT and re-select a cell before receiving Msg4.
- the eNB did not receive Msg3.
- the eNB has not derived the new keys, so the old KRRCint is still used for shortResumeMAC-I verification.
- the eNB may have received Msg3 and sent Msg4 (RRCConnectionRelease with the new NCC) but the UE may or may not receive Msg 4.
- shortResumeMAC-I may be verified by the old KRRCint and the eNB may now have a new set of Keys (corresponding to new KRRCint).
- a resume procedure for EDT may be considered a failure and the UE may delete the new security context corresponding to the new KRRCint that was derived after the calculation of the shortResumeMAC-I.
- the UE may return to the IDLE mode with a suspend indication.
- a first embodiment if the UE resumes in the same cell where the UE was previously suspended, the resumption is handled by the source eNB. If the eNB is unable to verify that Msg4 for EDT is successfully received by the UE, the eNB may attempt with both the new and old KRRCint (assuming new NCC provided in Msg4 for EDT is either received or not) to verify shortResumeMAC-I in the next resume procedure. In this case, the resume procedure for EDT may be considered failure and the UE may delete the new security context corresponding to the new KRRCint that was derived after the calculation of the shortResumeMAC-I. The UE may then return to the IDLE mode with a suspend indication.
- the UE may enter the RRC IDLE mode without a suspend indication with a release cause “other” or “RRC connection failure.”
- the UE may either use a control plane (CP) solution for EDT or initiate the legacy RRC connection establishment procedure next time.
- CP control plane
- the UE may enter the RRC_IDLE mode without a suspend indication with release cause “other” or “RRC connection failure.”
- the UE may either use a CP solution for EDT or initiate the legacy RRC connection establishment procedure next time.
- FIG. 5 illustrates a resumption procedure in accordance with some embodiments.
- FIG. 5 illustrates various messages between the UE, the eNB, the MME and S-GW in a EDT resumption procedure with new and old NCC handling.
- the eNB may provide a new NCC that can be different than the NCC used in Msg3 and Msg4.
- the shortResumeMAC-I calculation may be associated with the old NCC, whereas the new NCC may be used to derive new keys and encrypt the user data in Msg3.
- the key derivation may be either horizontal or vertical. If the old and new NCC values are same, horizontal derivation may be used, otherwise vertical derivation may be used.
- KeNB* is derived, further AS keys (KRRCenc, KRRCint and KUPenc) may be derived. Therefore, the UE and eNB may be synchronized on the difference of the old NCC and new NCC to correctly perform the derivation of keys.
- Msg4 may be lost, as described above.
- the UE may not receive the new NCC provided in the lost Msg4. This would mean the UE still has old NCC, whereas the eNB has the new NCC. Therefore, the eNB may store the old NCC as well as the new NCC.
- Various options can be considered to handle the old and new NCC.
- a single NCC may be stored.
- the UE may simply store one NCC or ignore the new NCC.
- multiple NCCs may be stored. In this case, either the same or different NCCs may be stored.
- the UE may also engage in vertical derivation i.e., derive the new NH and use the new NH immediately to derive the keys. This is to say that before KeNB* key derivation, the UE may decide whether vertical or horizontal derivation is to be used by comparing two NCCs. For example, when the UE stores NCC1 and NCC2 (where NCC1 is the old NCC and NCC2 is latest unused NCC received in the suspend message), if the UE initiates EDT, the UE may compare NCC2 with NCC1 before transmitting the preamble (Msg1).
- the UE may wait until Msg4 (RRCConnectionResume) and receive a new NCC (NCC3). The UE may then compare only NCC3 with NCC1 (not with NCC2) and derive KeNB* using vertical or horizontal derivation accordingly.
- Msg4 RRCConnectionResume
- NCC3 new NCC
- the UE may then compare only NCC3 with NCC1 (not with NCC2) and derive KeNB* using vertical or horizontal derivation accordingly.
- the UE may employ horizontal derivation i.e., use the current KeNB immediately to update the KeNB* and derive the keys.
- the UE may employ vertical derivation i.e., derive the new NH and use the new NH immediately to derive the KeNB* and keys.
- the eNB always rejects EDT request or moves the UE to RRC_CONNECTED.
- the UE does not use EDT in the resume procedure if it was suspended by a legacy eNB that did not support EDT in the previous connection.
- the UE may move to RRC_CONNECTED when the EDT request is sent.
- the source eNB may decide to move the UE to RRC_CONNECTED and provide only KeNB* and associated new unused NCC to the target eNB.
- the target eNB may provide the new NCC in the RRCConnectionResume message as mandatory in Msg4.
- the target eNB may decide to move the UE to RRC_CONNECTED, the source eNB may provide KeNB* and an associated old used NCC for EDT to the target eNB and additionally provide KeNB* and the associated new unused NCC for moving the UE to RRC_CONNECTED.
- the source eNB may provide KeNB* and the associated old used NCC and any unused NCC, if any, to the target eNB.
- the eNB may decide to use either the old NCC or new NCC.
- the UE may fall back to a legacy resume procedure due to a legacy UL grant being received in RAR for legacy Msg3, and use the same AS security keys if the AS keys are derived (security is activated) during the construction of the RRC message for Msg3 prior to receiving the RAR in EDT.
- the UE may fall back to a legacy resume procedure due to a legacy UL grant being received in RAR for legacy Msg3, and derive new AS security keys based on the stored NCC if the AS keys are derived (security is activated) during the construction of the RRC message for Msg3 after receiving RAR in EDT.
- the UE may not use EDT in the resume procedure if it didn't receive a value of NCC in the previous connection or previous suspend procedure or may use EDT in the resume procedure using the currently stored value of NCC even if it didn't receive NCC in the previous suspend procedure.
- the UE may not initiate EDT in the resume procedure if it received a RRCConnectionReject message in the previous resume attempt or the previous resume attempt was unsuccessful.
- the UE may store the old KeNB, if any, and the new KeNB when the UE derives the new KeNB (updated from KeNB*) during the construction of the RRC message for the resume procedure for EDT.
- the UE may delete the new KeNB and store the old KeNB, if any, when the UE falls back to the legacy procedure to send a legacy preamble due to a CE level change during a Random Access Procedure for EDT.
- the UE may delete the new KeNB and store old KeNB, if any, when the UE receives s RRCConnectionReject with suspend indication in response to s RRCConnectionResumeRequest message for EDT.
- the UE may derive keNB based on the stored value of the NH count and the NCC (same as a vertical derivation) if the UE has no stored value of KeNB or perform a horizontal derivation of KeNB if the UE has a stored value of KeNB when the NCC provided in RRCConnectionResume message in Msg4 is the same as the stored value of NCC.
- the UE may derive KeNB based on the stored value of the NH count and NCC if the UE has no stored value of KeNB or perform horizontal derivation of KeNB if the UE has a stored value of KeNB in the next resume procedure for EDT.
- the UE may not update KeNB when the NCC provided in the RRCConnectionResume message in Msg4 is the same as the stored value of NCC.
- the UE may not update the KeNB and use the same KeNB and derive new AS keys (KRRCint, KRRCenc and KUPenc) when the UE falls back to a legacy procedure to send a legacy preamble due to a CE level change during a Random Access Procedure for EDT.
- the UE may not update the KeNB and use the same KeNB and the same AS keys (KRRCint, KRRCenc and KUPenc) when the UE falls back to a legacy procedure to send a legacy preamble due to a CE level change during the Random Access Procedure for EDT.
- the UE may revert to the original old KeNB or NH and NCC pair to and restart EDT deriving new keys when a new cell is selected after initiating EDT (i.e., after deriving new keys for EDT), or after receiving a RRCConnectionReject message in response to a RRCConnectionResumeRequest message for EDT.
- the old security context corresponding to the KRRCint that was used to calculate the shortResumeMAC-I may be discarded when the UE receives a RRCConnectionResume message or a RRCConnectionRelease message in response to a RRCConnectionResumeRequest for EDT or in response to Msg3 that is sent after the EDT preamble in Msg1.
- the UE may initiate an UP EDT in the same cell where the UE was moved to IDLE with a suspend indication in the preceding connection and fail to resume before receiving Msg4, the UE may discard the new security context and move to IDLE with a suspend indication.
- the UE may move to IDLE without a suspend indication with a release cause “other” or “RRC connection failure”.
- the UE may initiate an UP EDT in a different cell where the UE was not moved to IDLE with a suspend indication in the preceding connection and fail to resume before receiving Msg4, the UE may move to IDLE without s suspend indication with s release cause “other” or “RRC connection failure”.
- the UE may store only a single NCC but calculate the NH parameter immediately after receiving a new NCC different that currently stored in the RRCConnectionRelease message during the suspend procedure.
- the UE may store two NCCs (both old and new) and in case of a next legacy resume procedure, the UE may receive another new NCC in Msg4 and compare with the last used NCC (i.e., the said old NCC).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Power Engineering (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
- This application claims the benefit of priority under 35 U.S.C. 119(e) to U.S. Provisional Patent Application Ser. No. 62/644,102, filed on Mar. 16, 2018, U.S. Provisional Patent Application Ser. No. 62/677,994, filed May 30, 2018, U.S. Provisional Patent Application Ser. No. 62/716,440, filed Aug. 9, 2018, and U.S. Provisional Patent Application Ser. No. 62/753,841, filed Oct. 31, 2018, each which is incorporated herein by reference in its entirety.
- Embodiments pertain to radio access networks (RANs). Some embodiments relate to cellular networks, including Third Generation Partnership Project Long Term Evolution (3GPP LTE) networks and LTE advanced (LTE-A) networks, 4th generation (4G) networks and 5th generation (5G) or next generation (NG) networks. Some embodiments relate to a security framework for network connectivity.
- The use of various types of systems has increased due to both an increase in the types of devices user equipment (UEs) using network resources as well as the amount of data and bandwidth being used by various applications, such as video streaming, operating on these UEs. To increase the ability of the network to contend with the explosion in network use and variation, various changes to existing systems are being contemplated to improve network processes. Such network processes may include the security processes for UEs, and in particular security processes used during early data transmission (EDT).
- In the figures, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The figures illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.
-
FIG. 1 illustrates combined communication system in accordance with some embodiments. -
FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments. -
FIG. 3 illustrates key handling in accordance with some embodiments. -
FIG. 4 illustrates radio resource control (RRC) message exchange in accordance with some embodiments. -
FIG. 5 illustrates a resumption procedure in accordance with some embodiments. - The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.
-
FIG. 1 illustrates a combined communication system in accordance with some embodiments. Thesystem 100 includes 3GPP LTE/4G and NG network functions. A network function can be implemented as a discrete network element on a dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., dedicated hardware or a cloud infrastructure. - The evolved packet core (EPC) of the LTE/4G network contains protocol and reference points defined for each entity. These core network (CN) entities may include a mobility management entity (MME) 122, serving gateway (S-GW) 124, and paging gateway (P-GW) 126.
- In the NG network, the control plane and the user plane may be separated, which may permit independent scaling and distribution of the resources of each plane. The UE 102 may be connected to either an access network or random access network (RAN) 110 and/or may be connected to the NG-RAN 130 (gNB) or an Access and Mobility Function (AMF) 142. The RAN may be an eNB, a gNB or a general non-3GPP access point, such as that for Wi-Fi. The NG core network may contain multiple network functions besides the AMF 112. The network functions may include a User Plane Function (UPF) 146, a Session Management Function (SMF) 144, a Policy Control Function (PCF) 132, an Application Function (AF) 148, an Authentication Server Function (AUSF) 152 and User Data Management (UDM) 128. The various elements are connected by the NG reference points shown in
FIG. 1 . - The AMF 142 may provide UE-based authentication, authorization, mobility management, etc. The AMF 142 may be independent of the access technologies. The SMF 144 may be responsible for session management and allocation of IP addresses to the UE 102. The SMF 144 may also select and control the UPF 146 for data transfer. The SMF 144 may be associated with a single session of the UE 102 or multiple sessions of the UE 102. This is to say that the UE 102 may have multiple 5G sessions. Different SMFs may be allocated to each session. The use of different SMFs may permit each session to be individually managed. As a consequence, the functionalities of each session may be independent of each other. The UPF 126 may be connected with a data network, with which the UE 102 may communicate, the UE 102 transmitting uplink data to or receiving downlink data from the data network.
- The AF 148 may provide information on the packet flow to the PCF 132 responsible for policy control to support a desired QoS. The PCF 132 may set mobility and session management policies for the UE 102. To this end, the PCF 132 may use the packet flow information to determine the appropriate policies for proper operation of the AMF 142 and SMF 144. The AUSF 152 may store data for UE authentication. The UDM 128 may similarly store the UE subscription data.
- The gNB 130 may be a standalone gNB or a non-standalone gNB, e.g., operating in Dual Connectivity (DC) mode as a booster controlled by the eNB 110 through an X2 or Xn interface. At least some of functionality of the EPC and the NG CN may be shared (alternatively, separate components may be used for each of the combined component shown). The eNB 110 may be connected with an
MME 122 of the EPC through an S1 interface and with a SGW 124 of the EPC 120 through an S1-U interface. The MME 122 may be connected with an HSS 128 through an S6a interface while the UDM is connected to the AMF 142 through the N8 interface. The SGW 124 may connected with the PGW 126 through an S5 interface (control plane PGW-C through S5-C and user plane PGW-U through S5-U). The PGW 126 may serve as an IP anchor for data through the internet. - The NG CN, as above, may contain an AMF 142, SMF 144 and UPF 146, among others. The eNB 110 and gNB 130 may communicate data with the SGW 124 of the EPC 120 and the UPF 146 of the NG CN. The MME 122 and the AMF 142 may be connected via the N26 interface to provide control information there between, if the N26 interface is supported by the EPC 120. In some embodiments, when the gNB 130 is a standalone gNB, the 5G CN and the EPC 120 may be connected via the N26 interface.
-
FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments. In some embodiments, the communication device may be a peer machine in peer-to-peer (P2P) (or other distributed) network environment. Thecommunication device 200 may be a specialized computer, a personal or laptop computer (PC), a tablet PC, a personal digital assistant (PDA), a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. In some embodiments, thecommunication device 200 may be embedded within other, non-communication based devices such as vehicles and appliances. - Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules and components are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
- Accordingly, the term “module” (and “component”) is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.
- The
communication device 200 may include a hardware processor 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), amain memory 204 and astatic memory 206, some or all of which may communicate with each other via an interlink (e.g., bus) 208. Themain memory 204 may contain any or all of removable storage and non-removable storage, volatile memory or non-volatile memory. Thecommunication device 200 may further include adisplay unit 210 such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In an example, thedisplay unit 210,input device 212 andUI navigation device 214 may be a touch screen display. Thecommunication device 200 may additionally include a storage device (e.g., drive unit) 216, a signal generation device 218 (e.g., a speaker), anetwork interface device 220, and one or more sensors, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. Thecommunication device 200 may further include an output controller, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.). - The
storage device 216 may include a non-transitory machine readable medium 222 (hereinafter simply referred to as machine readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. Theinstructions 224 may also reside, completely or at least partially, within themain memory 204, withinstatic memory 206, and/or within thehardware processor 202 during execution thereof by thecommunication device 200. While the machinereadable medium 222 is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one ormore instructions 224. - The term “machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the
communication device 200 and that cause thecommunication device 200 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks. - The
instructions 224 may further be transmitted or received over a communications network using atransmission medium 226 via thenetwork interface device 220 utilizing any one of a number of transfer protocols (e.g., frame relay, interne protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks. Communications over the networks may include one or more different protocols, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi, IEEE 802.16 family of standards known as WiMax, IEEE 802.15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, a next generation (NG)/5th generation (5G) standards among others. In an example, thenetwork interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to thetransmission medium 226. - Various RRC messages are provided over the course of the connection between the UE and a RAN. These RRC messages include initial connection messages, such as RRC connection request, RRC connection setup and RRC connection setup, reconfiguration messages, such as RRC connection reconfiguration and RRC connection reconfiguration complete messages, and suspension and release messages, such as RRC Connection Release and RRC Connection Reestablish/Resume messages.
- At least some of the RRC messages may involve security procedures, such as the generation of keys. In a legacy RRCConnectionResumeRequest message message, a shortResumeMAC-I message authentication token is calculated taking into account the stored KRRCint which is associated with a previous Next Hop Chaining Counter (NCC) from a previous connection (e.g., a source eNB where the UE RRC connection was suspended). As the RRCConnectionResumeRequest message is transmitted using SRB0 and is thus neither integrity protected nor ciphered, the RRCConnectionResumeRequest message re-uses only the existing key KRRCint for the shortResumeMAC-I calculation. When the UE receives the new NCC in the RRC connection release (Msg4), the UE may derive new access stratum (AS) keys using the key KeNB* derived based on the new NCC. Using the new keys, the UE verifies the integrity protection of the legacy RRC message in the RRC connection release and starts using the keys in the subsequent messages.
- In EDT, however, the RRC resume procedure is different from legacy resume procedure. EDT allows one uplink data transmission, optionally followed by one downlink data transmission during the random access procedure. Bandwidth reduced Low complexity (BL) UEs, UEs in coverage enhancement (CE) mode or Narrow Band Internet of Things (NB-IoT) UEs may use EDT. EDT is triggered when the upper layers have requested the establishment or resumption of the RRC Connection for Mobile Originated data and the uplink data size is less than or equal to a transport block size indicated in the system information. The user data is to be protected in the RRCConnectionResumeRequest message (Msg3) and hence the RRCConnectionResumeRequest message also uses a fresh user plane (UP) AS key (KUPpenc) before sending the RRCConnectionResumeRequest message. Therefore, the new fresh AS keys (KRRCint, KRRCenc and KUPenc) are derived from KeNB* that is either derived from the currently active KeNB of the source cell (referred as horizontal derivation assuming same old NCC) or derived from the NH associated with the new NCC (referred as vertical derivation). Whether the derivation is horizontal or vertical, the UE may obtain a new KeNB* for the derivation of fresh keys.
-
FIG. 3 illustrates key handling in accordance with some embodiments. As shown inFIG. 3 , when a UE receives a value of NCC from the eNB and determines that the NCC value is different from the stored NCC value, the UE derives the new keys using vertical derivation from the NH associated with new NCC. Similarly, in EDT if UE received new NCC in the previous connection (for example, a previous Msg4 or in an RRC suspend message) and the NCC is unused, the UE can perform vertical derivation from the NH parameter to derive keys before sending Msg3. If the UE received the same value of the currently used NCC in the previous connection or the UE already used the new NCC received in the previous connection, the UE can perform a horizontal derivation from KeNB to derive new keys before sending Msg3 in EDT. - KASME is the MME (ASME) Base/Intermediate key that is derived in the HSS and UE from the Cipher key and Integrity key (which are derived in the USIM using AKA) using AKA. KeNB is the eNB Base key, which is an intermediate key derived in MME and UE from KASME when the UE transits to ECM CONNECTED STATE or by UE and target eNB from KeNB* during handover. KeNB* is the eNB handover transition key, which is an intermediate key derived in source eNB and UE during handover when performing horizontal (KeNB) or vertical key (NH) derivation. It is used at target eNB to derive KeNB. KRRCint is an encryption key for protection of RRC data derived in the eNB and the UE. KUPenc is the encryption key for protection of user plane data derived in eNB and UE. All EPS security keys may be 256 bits in length. The ciphering and integrity keys for AS and NAS algorithms may use only the 128 Least Significant Bits (LSB) of the derived keys.
-
FIG. 4 illustrates RRC message exchange in accordance with some embodiments. The overall framework of using NCC for EDT following legacy UE behavior wherever possible is shown inFIG. 4 . As is evident, unlike the legacy resume procedure, the UE does not transition from the RRC_Idle state to the RRC_Connected state during EDT. Similar to the legacy procedure, the UE may send a RACH Request (Msg1) in the RACH procedure. In general, a UE in the RACH group may synchronize to the network using the RACH procedure. The RACH Request may contain an EDT indication. - The RACH request may be transmitted by the UE to the eNB using a RACH resource. For example, the RACH request may be transmitted over 6 Resource blocks. The RACH request may contain a preamble index, which may be randomly selected based on the size of the RRC connection request from preamble information in system information block (SIB). However, the RACH Request for EDT may use a unique preamble that is different from that used for a legacy procedure.
- The eNB, having received the RACH request may allocate a temporary Cell Radio Network Temporary Identifier (C-RNTI) for the UE. The temporary Cell RNTI may be transmitted to the UE in a RACH Response message (RAR—Msg 2) from the eNB. The RAR message may also contain the appropriate timing advance (TA) for the UE, determined by the eNB. The RAR message may contain a scheduling grant for the UE to send a RRCConnectionResumeRequest message, where the scheduling grant may indicate whether frequency hopping is to be used as well as the resource block assignment. The RAR message may further indicate the modulation and coding scheme and the power for the PUSCH to be used by the UE. If EDT is to be used, the UL grant in the RAR message may be larger than that of a legacy RAR grant to provide additional UL resources for transmission by the UE of a UL message in addition to a RRCConnectionResumeRequest message.
- When the UE receives the UL grant in RAR for EDT, as in legacy, the UE may transmit a RRCConnectionResumeRequest message including a shortResumeMAC-I calculated using currently stored KRRCint. The UE may also derive the new key (KUPenc) to cipher the UL user plane (UP) data in a Dedicated Traffic Channel (DTCH) and multiplex the UL UP data with the RRC message to transmit in Msg3.
- When UE receives Msg4 (the RRCConnectionRelease message), the RRC message in the Dedicated Control Channel (DCCH) is integrity protected using the key (KRRCint) generated prior to the transmission of Msg3 and DL data in the DTCH is ciphered using the key (KUPenc) that was also generated prior to the transmission of Msg3. Since the AS security is active and the Packet Data Convergence Protocol (PDCP) is already established, the PDCP layer performs the verification of the integrity protection of the RRC message in DCCH.
- In some cases, a UE may be suspended by an eNB that supports EDT and resumes in a legacy eNB that does not support EDT, the UE may perform the legacy resume procedure. However, when the UE is suspended by a legacy eNB that does not support EDT and resumes in an eNB that supports EDT to initiate EDT, the UE derives new keys based on the currently stored value of NCC before sending Msg3. The UE and eNB may be out-of-sync if the legacy eNB has an unused NCC.
- For example, assuming that the UE is currently using NCC_0, as shown in
FIG. 4 , the UE may have resumed in the same cell of a Rel-14 network or network that does not support EDT. In this case, the network may have new NCC_1 provided by the MME. In particular, the MME may store a fresh NCC and send the new NCC to the eNB in the S1-AP UE Context Resume Response message. However, because the eNB does not support EDT, the eNB may not provide the NCC_1 to the UE during the suspend procedure (prior to the RACH transmission). The UE is thus unaware of the new NCC_1 provided by the MME until the UE engages in a new resumption or re-establishment of the RRC connection, or handover is performed. - If the UE moves to a target eNB in a Rel-15 network that supports EDT and starts the RRC resume procedure for EDT, the UE may continue to use the old NCC_0 to initiate EDT. However, the legacy source eNB may use the unused NCC_1 to derive KeNB*. That is, if the source eNB has a fresh {NH, NCC} pair from the MME then the fresh pair may be used and the fresh NH may be used in the new KeNB* derivation. Moreover, the AS security context sent to the target eNB may include the new derived KeNB*, the NCC associated to the KeNB*. In this case, deciphering of UL data can result in a corrupted packet due to the differences between the NCC used by the eNB and that used by the UE.
- Various solutions to these issues may include that the eNB rejects the connection from the UE during the RRC connection resumption process. Alternatively, the UE may not use EDT in the resume procedure if the RRC connection was suspended by a legacy eNB that did not support EDT in the previous connection. In another embodiment, the UE may determine whether or not it received the NCC in the previous connection or previous suspend procedure and if it did not receive the NCC in the previous connection or previous suspend procedure, the UE may avoid using EDT in the resume procedure. In another embodiment, the UE may echo back (i.e., transmit) the used {KeNB*, NCC} pair in Msg3 using a Medium Access Control (MAC) Control element (CE) or PDCP control packet data unit (PDU). If source eNB provided different {KeNB*, NCC} pair to target eNB, the target eNB derives keys using KeNB* provided by the UE in msg3.
- In some cases, a UE may be suspended by a Rel-15 eNB that has disabled EDT and resumed in a (source) eNB that has enabled EDT. In this case, a change in legacy behaviour at the network side may be provided if the eNB decides to move the UE in the RRC_CONNECTED mode after receiving RRCConnectionResumeRequest for EDT. Assuming that the UE is using NCC_0, the UE connection is suspended and the eNB has new fresh NCC_1. The eNB has not delivered NCC_1 to the UE yet because the eNB is currently disabling the EDT feature. However, the eNB is capable of supporting EDT or new Rel-15 eNB. Now, the UE resumes the connection in a different target eNB and the UE still uses the old NCC_0.
- In some embodiments, as above, the UE may determine whether or not it received the NCC in the previous connection or previous suspend procedure and if it did not receive the NCC in the previous connection or previous suspend procedure, the UE avoids using EDT in the resume procedure.
- In some embodiments, the source eNB may decide to move the UE to the RRC_CONNECTED state and provide only KeNB* and the associated NCC_1 to the target eNB. In this case, the target eNB may provide the new NCC_1 in the RRCConnectionResume message as mandatory in Msg4 and the UE may be unable to ignore the new NCC_1.
- In some embodiments, the target eNB may decide to move the UE to the RRC_CONNECTED state. This means that the source eNB may provide KeNB* and the associated NCC_0 for EDT to the target eNB, as well as providing KeNB* and the associated NCC_1 to move the UE to the RRC CONNECTED state. In other embodiments, the source eNB may always provide KeNB* and associated NCC_0 and any unused NCC_1, if any, to the target eNB. In both of these embodiments, the target eNB has option to provide either the old NCC_0 or the new NCC_1 in Msg4 when Msg4 contains a legacy RRCConnectionResume message. In this case, if NCC_0 is provided in Msg4, the UE ignores NCC_0 and keeps using current keys for subsequent messages because the UE has already derived the keys associated with NCC_0 before sending Msg3. If NCC_1 is provided in Msg4, then the UE may follow the legacy procedure and derive new keys using KeNB* that is derived with vertical derivation as the UE has received a new NCC.
- In some cases, the eNB may reject the EDT request of the UE if the MME is down, the AS security context has been lost or there is network congestion. If the eNB rejects the RRCConnectionResumeRequest message from the UE due to network congestion or AS security context being lost, the eNB may be unable to derive any keys. In this case, if the UE goes back to IDLE mode with a suspend indication, the UE and eNB may have a different value of the keys. Therefore, after the connection reject, the UE may not derive new key and may instead use the same key for the calculation of shortResumeMAC-I in Msg3 in the next resume procedure for EDT. When using same key, however, there is risk of a replay attack as the UE uses the same resume ID and shortResumeMAC-I in Msg3 in the next resume procedure. To combat this, the UE may use the newly derived key (KRRCint) for every calculation of shortResumeMAC-I in Msg3 in every attempt of the RRC connection resume procedure. In this case, the UE may count how many times the key is derived from the first attempt of the unsuccessful ongoing resume procedure. The count may be included in Msg3 as a MAC CE or PDCP control PDU. The eNB may also derive the key for the same number of times to be in-sync with the UE.
- In some cases, a UE may fall back due to a legacy grant in the RAR. In particular, when a UE initiates EDT by using a PRACH resource corresponding to EDT and receives a legacy UL grant in RAR for the legacy Msg3, the UE may be unable to send UL data. Instead, the UE may send the legacy RRCConnectionResumeRequest message. The UE may activate AS security during the construction of the RRC message for Msg3 in EDT. The RRC sends the RRC message for EDT to lower layers so that the lower layers can initiate EDT using the RACH procedure. Since the UL data should also be in the transmission buffer in RLC, the RRC connection may resume the dedicated radio bearers (DRBs) and AS security so that PDCP can encrypt the user UL data.
- When the UE receives the UL grant in RAR, the UE can ask the Assembly and Multiplexing entity to get the MAC PDU to transmit from the transmission buffer. In this case, the UE may derive new AS keys prior to receiving the RAR. However, when the UL grant is not sufficient, the UE may fall back to the legacy procedure. If the UE follows the legacy procedure, then the UE may rederive new keys when the UE receives the legacy RRCConectionResume message in Msg4. However, deriving KeNB* a second time could make the UE and eNB out of sync if the eNB derives KeNB* only once (as the eNB received the preamble from the UE and in response sent the legacy UL grant in the RAR) while the UE derived KeNB* twice using same value of NCC in the same RRC connection.
- To avoid this issue, the UE may use the same AS keys in case of fallback to the legacy RRC connection procedure if the AS keys are derived (security is activated) during the construction of the RRC message for Msg3 prior to receiving the RAR in EDT. However, unlike the legacy procedure, in which the UE resumes all SRBs and DRBs and re-establishes the AS security, the AS security has already been established, thus, these procedures are skipped by the UE. Similar to the legacy procedure, however, the UE may enter the RRC_CONNECTED state. In addition, in the fallback to the legacy procedure, in response to receiving the RRCConnectionResumeRequest from the UE, the RRCConnectionResume from the eNB may include a dummy NCC (e.g., a NCC that has an invalid value) as the UE and eNB are using the correct NCC. The dummy NCC number may be ignored by the UE and the eNB in subsequent legacy steps as AS security has already been established and the NCC value is current.
- Alternatively, the UE may follow the legacy procedure in case of fallback to the legacy RRC connection procedure if the AS keys are derived (security is activated) during the construction of RRC message for Msg3 after receiving the RAR in EDT. In this latter embodiment, when the UE receives the UL grant in the RAR for Msg3, the MAC layer may indicate to the RRC layer to construct the RRC message. In this case, it is assumed that there is enough processing time before the scheduled UL transmission time.
- In another fallback scenario, the UE may fall back due to a change in the coverage enhancement (CE) level during power ramping. In this scenario, when the UE does not receive the RAR in response to the preamble transmission for EDT, the UE may change the CE level due to power ramping. When the CE level is changed, the maximum transport block (TB) size that can be transmitted in EDT is changed. Due to this change, the UL data or Msg3 may not fit in a single transmission. In this case, the UE fall backs to the legacy procedure.
- To avoid this issue, in some embodiments, the KeNB may not be updated if the NCC received by the UE in Msg4 is the same as that already stored by the UE. In this case, when the UE falls back to the legacy resume procedure to send the legacy preamble, the UE may revert to the configuration prior to sending the preamble for EDT in Msg1. When the UE receives the RRCConnectionResume message in Msg4 after initiating the legacy resume procedure, the UE may check the NCC. If the NCC provided in Msg4 is same as the currently stored NCC, the UE may not update the KeNB. Then, the UP keys (KRRCint, KRRCenc and KUPenc) may be derived using the KeNB. In another embodiment, the UE does not derive the keys and uses the same UP keys (KRRCint, KRRCenc and KUPenc). If the NCC provided in Msg4 is different from the currently stored NCC, the UE may perform a vertical derivation of the KeNB and derive new UP keys.
- In some embodiments, multiple KeNBs may be stored. For example, when two KeNBs are stored, one may be the old KeNB and the other the new KeNB that is derived based on the NCC that was provided in the RRCConnectionRelease message with the suspend indication in the previous connection. In this case, when the UE activates the AS security (deriving KeNB and AS Keys) before sending the RRCConnectionResumeRequest message for EDT, the UE may store the new KeNB as well as the old KeNB if horizontal derivation is performed based on the NCC. The new KeNB may be derived based on the old KeNB. If vertical derivation is performed, the UE may store only the new KeNB. In case of this fallback scenario, the UE may delete the new KeNB and keep only the old KeNB. Unlike the above embodiment, in which fallback occurs due to a legacy grant being provided in the RAR message, similar to the legacy procedure the UE resumes all SRBs and DRBs and re-establishes the AS security using the old KeNB before entering the RRC_CONNECTED state. Thus, the UE may recalculate the new KeNB in response to the legacy grant. If there is no old KeNB, the UE may not store any KeNB.
- In this fallback scenario, if the NCC provided in Msg4 is same as the stored NCC, the UE may perform horizontal derivation of the KeNB when the UE has a stored value of the KeNB. If the UE has no stored value of the KeNB, the UE may always derive the KeNB based on the currently stored NH count and the NCC. If NCC provided in Msg4 is different than the stored value of NCC, the UE may always perform the vertical derivation of the KeNB.
- In some embodiments, a RRCConnectionReject message may be received in response to the RRCConnectionResumeRequest message for EDT. The reception of the RRCConnectionReject message may indicate to the UE that at least one of the messages between the eNB and the MME, and between the MME and SGW (i.e., UEContextResumeRequest message, Modify Bearer message, UEContextResumeResponse message, Suspend procedure message) was unsuccessful. In this case, when the UE receives the RRCConnectionReject message with a suspend indication in response to the RRCConnectionResumeRequest message, the UE may enter the IDLE mode with a suspend indication and store the AS context. In the next resume procedure for EDT, the UE may activate AS security before sending the Msg3.
- When the RRCConnectionReject message may be received in response to the RRCConnectionResumeRequest message for EDT, in some embodiments, the UE may store two old KeNB and a new KeNB when horizontal derivation is performed to derive the new key. When entering IDLE mode with a suspend indication, the UE may delete the new KeNB and store the old KeNB. If there is no old KeNB, the UE may not store any KeNB. In the next resume procedure for EDT, if the UE has a stored value of the KeNB, the UE may perform the horizontal derivation of the KeNB—otherwise the UE may perform a derivation of the KeNB based on the stored values of NH and NCC. Similarly, in the next legacy resume procedure, if the NCC provided in Msg4 is same as the stored NCC, the UE may perform horizontal derivation of the KeNB when the UE has a stored value of the KeNB. If the UE has no stored value of KeNB, the UE may always derive the KeNB based on the currently stored NH count and the NCC. If the NCC provided in Msg4 is different than the stored value of NCC, the UE may always perform the vertical derivation of the KeNB.
- Alternatively, the UE may store only one KeNB. If a RRCConnectionReject message is received by the UE after initiating EDT, the UE may not update the KeNB in the next resume procedure in the same cell. Using the same KeNB, the UP keys may be derived in the next resume procedure for EDT before sending Msg3. In another embodiment, the UE may store both the KeNB and UP Keys and may not derive any keys in the next resume procedure for EDT in the same cell.
- In some cases, if a legacy resume procedure (no EDT) is started in the next resume procedure, and if the NCC provided in the Msg4 is same as the stored NCC, the UE may not update the KeNB and instead use the same KeNB, while the UP keys are derived. In another option, the UE may not derive any keys and instead use the same stored KeNB and UP keys. If the NCC provided in Msg4 is different than the stored NCC, the UE may always perform vertical derivation of KeNB.
- Other issues may involve handling different AS security context in the UP EDT process. In EDT for a UP solution, if the UE has received a NCC in the RRCConnectionRelease message in the preceding connection, the UE can initiate the EDT. In this case, the old KRRCint key may be used to calculate the shortResumeMAC-I. Thus, when the UE is released to the IDLE mode with a suspend indication and provided a new NCC for the next resume procedure for EDT, the UE may use the currently stored old KRRCint to calculate the shortResumeMAC-I before deriving new keys using the NCC. After calculating shortResumeMAC-I, the UE may derive new keys and store two sets of AS security—one corresponding to the old KRRCint and the other corresponding to the new KRRCint—until the resume procedure fails or succeeds.
- If the UE receives a RRCConnectionReject message in Msg4, the UE may discard the new AS security corresponding to the new KRRCint so that the UE uses the same KRRCint to calculate the shortResumeMAC-I in the next resume procedure. Similarly, when the UE receives the RRCConnectionRelease message with a suspend indication in Msg4, the EDT procedure is complete. In this case, the UE may also delete the old AS security keys. Also, when the UE falls back to the RRC_CONNECTED state upon reception of a legacy RRCConnectionResume message in response to a RRCConnectionResumeRequest for EDT, the UE may discard the old security context corresponding to the KRRCint that was used to calculate the shortResumeMAC-I.
- In some cases, after deriving new key for EDT procedure, the resume procedure may fail due to cell reselection, which may lead to the MAC being reset. Similarly, when the UE reselects a cell during the Random Access Procedure for EDT, or when timer T300 expires after initiating EDT, the UE may also discard the new security context as the UE restarts the resume procedure. However, if the UE resumes in a different eNB than the eNB where the UE was previously suspended and resume failure happens due to cell reselection, there is risk of keys mismatch between the UE and eNB as same key cannot be used in two different eNBs. The UE may also transmit the RRCConnectionResumeRequest message for EDT and re-select a cell before receiving Msg4.
- In this case, following scenarios are possible: the eNB did not receive Msg3. In this case, the eNB has not derived the new keys, so the old KRRCint is still used for shortResumeMAC-I verification. Alternatively, the eNB may have received Msg3 and sent Msg4 (RRCConnectionRelease with the new NCC) but the UE may or may not receive
Msg 4. In this case, shortResumeMAC-I may be verified by the old KRRCint and the eNB may now have a new set of Keys (corresponding to new KRRCint). - In the former scenario, a resume procedure for EDT may be considered a failure and the UE may delete the new security context corresponding to the new KRRCint that was derived after the calculation of the shortResumeMAC-I. The UE may return to the IDLE mode with a suspend indication.
- In the latter scenario, various embodiments may be considered. In a first embodiment, if the UE resumes in the same cell where the UE was previously suspended, the resumption is handled by the source eNB. If the eNB is unable to verify that Msg4 for EDT is successfully received by the UE, the eNB may attempt with both the new and old KRRCint (assuming new NCC provided in Msg4 for EDT is either received or not) to verify shortResumeMAC-I in the next resume procedure. In this case, the resume procedure for EDT may be considered failure and the UE may delete the new security context corresponding to the new KRRCint that was derived after the calculation of the shortResumeMAC-I. The UE may then return to the IDLE mode with a suspend indication.
- In a second embodiment, if the UE resumes in a different cell than the cell where the UE was previously suspended, the UE may enter the RRC IDLE mode without a suspend indication with a release cause “other” or “RRC connection failure.” In this case, the UE may either use a control plane (CP) solution for EDT or initiate the legacy RRC connection establishment procedure next time.
- Alternatively, for both the first and second embodiment, the UE may enter the RRC_IDLE mode without a suspend indication with release cause “other” or “RRC connection failure.” In this case, the UE may either use a CP solution for EDT or initiate the legacy RRC connection establishment procedure next time.
-
FIG. 5 illustrates a resumption procedure in accordance with some embodiments. In particular,FIG. 5 illustrates various messages between the UE, the eNB, the MME and S-GW in a EDT resumption procedure with new and old NCC handling. As shown inFIG. 5 , when the eNB completes the EDT in Msg4 (RRCConnectionRelease message in Msg4), the eNB may provide a new NCC that can be different than the NCC used in Msg3 and Msg4. In the next resume procedure, the shortResumeMAC-I calculation may be associated with the old NCC, whereas the new NCC may be used to derive new keys and encrypt the user data in Msg3. The key derivation (KeNB*) may be either horizontal or vertical. If the old and new NCC values are same, horizontal derivation may be used, otherwise vertical derivation may be used. Once KeNB* is derived, further AS keys (KRRCenc, KRRCint and KUPenc) may be derived. Therefore, the UE and eNB may be synchronized on the difference of the old NCC and new NCC to correctly perform the derivation of keys. - Also, Msg4 may be lost, as described above. In this case, the UE may not receive the new NCC provided in the lost Msg4. This would mean the UE still has old NCC, whereas the eNB has the new NCC. Therefore, the eNB may store the old NCC as well as the new NCC. Various options can be considered to handle the old and new NCC.
- In a first option, a single NCC may be stored. In this case, if the received NCC in the RRCConnectionRelease message is same as the stored one, the UE may simply store one NCC or ignore the new NCC. In the next resume procedure, the KeNB* derivation may be based on current KeNB (considered flag=0). On the other hand, if the received NCC in the RRCConnectionRelease message is different from the stored one, the KeNB may be derived and the NH updated immediately. In this case, the received NCC may be stored and, during the next resume procedure the KeNB* derivation may be based on the NH (considered flag=1). When the next resume procedure is a legacy resume procedure (not applicable to the RRC INACTIVE mode), the UE may receive the new NCC in a RRCConnectionResume message (in Msg4) and determine whether the currently received NCC is same as the stored one and whether the currently received NCC is different than the stored one. If the currently received NCC is same as the stored one, if flag=0, the UE may continue using the current KeNB to derive the keys immediately, while if flag=1, the UE may continue using the NH to derive the keys immediately. If the currently received NCC is different than the stored one, the UE may use vertical derivation, i.e., derive the new NH and use the new NH immediately to derive the keys.
- In a second option, multiple NCCs may be stored. In this case, either the same or different NCCs may be stored. When different NCCs are stored, two different NCC old (for example, =2) and NCC new (for example, =5) may be stored. For the RRC_INACTIVE state and EDT in the next resume, the NCC new (=5) may be used compared with the old NCC (=2) to derive the key, i.e. via vertical derivation. When a next legacy resume procedure is used (not applicable to the RRC_INACTIVE state), the UE may receive another new NCC in Msg4 and compare with the last used NCC (i.e., =2). The UE may use the new received NCC (compare with old NCC (=2) to derive key). The UE may also engage in vertical derivation i.e., derive the new NH and use the new NH immediately to derive the keys. This is to say that before KeNB* key derivation, the UE may decide whether vertical or horizontal derivation is to be used by comparing two NCCs. For example, when the UE stores NCC1 and NCC2 (where NCC1 is the old NCC and NCC2 is latest unused NCC received in the suspend message), if the UE initiates EDT, the UE may compare NCC2 with NCC1 before transmitting the preamble (Msg1). If, however, the UE initiates a legacy RRC connection, the UE may wait until Msg4 (RRCConnectionResume) and receive a new NCC (NCC3). The UE may then compare only NCC3 with NCC1 (not with NCC2) and derive KeNB* using vertical or horizontal derivation accordingly.
- When the same NCCs are stored, the same NCC old (for example, =2) and NCC new (for example, =2) may be stored. For the RRC INACTIVE state and EDT in the next resume, NCC new (=2) may be used (compare with old NCC (=2) to derive key, i.e. horizontal derivation). When a next legacy resume procedure is used (not applicable to the RRC_INACTIVE state), the UE may receive another new NCC in Msg4 and compare the new NCC with the last used NCC (i.e., =2). When the newly received NCC (for example=2) is the same as current NCC (=2): the UE may employ horizontal derivation i.e., use the current KeNB immediately to update the KeNB* and derive the keys. When the newly received NCC (for example=4) is same as the current NCC (=2): the UE may employ vertical derivation i.e., derive the new NH and use the new NH immediately to derive the KeNB* and keys.
- Thus, in various embodiments, where the UE is suspended by a legacy source eNB that does not support EDT and resumed in a target eNB that supports EDT, the eNB always rejects EDT request or moves the UE to RRC_CONNECTED. The UE does not use EDT in the resume procedure if it was suspended by a legacy eNB that did not support EDT in the previous connection. Where the UE is suspended by a Rel-15 eNB that has disabled EDT without providing NCC and resumed in an eNB that has enabled EDT, the UE may move to RRC_CONNECTED when the EDT request is sent. The source eNB may decide to move the UE to RRC_CONNECTED and provide only KeNB* and associated new unused NCC to the target eNB. The target eNB may provide the new NCC in the RRCConnectionResume message as mandatory in Msg4. The target eNB may decide to move the UE to RRC_CONNECTED, the source eNB may provide KeNB* and an associated old used NCC for EDT to the target eNB and additionally provide KeNB* and the associated new unused NCC for moving the UE to RRC_CONNECTED. The source eNB may provide KeNB* and the associated old used NCC and any unused NCC, if any, to the target eNB. The eNB may decide to use either the old NCC or new NCC. The UE may fall back to a legacy resume procedure due to a legacy UL grant being received in RAR for legacy Msg3, and use the same AS security keys if the AS keys are derived (security is activated) during the construction of the RRC message for Msg3 prior to receiving the RAR in EDT. The UE may fall back to a legacy resume procedure due to a legacy UL grant being received in RAR for legacy Msg3, and derive new AS security keys based on the stored NCC if the AS keys are derived (security is activated) during the construction of the RRC message for Msg3 after receiving RAR in EDT. The UE may not use EDT in the resume procedure if it didn't receive a value of NCC in the previous connection or previous suspend procedure or may use EDT in the resume procedure using the currently stored value of NCC even if it didn't receive NCC in the previous suspend procedure. The UE may not initiate EDT in the resume procedure if it received a RRCConnectionReject message in the previous resume attempt or the previous resume attempt was unsuccessful. The UE may store the old KeNB, if any, and the new KeNB when the UE derives the new KeNB (updated from KeNB*) during the construction of the RRC message for the resume procedure for EDT. The UE may delete the new KeNB and store the old KeNB, if any, when the UE falls back to the legacy procedure to send a legacy preamble due to a CE level change during a Random Access Procedure for EDT. The UE may delete the new KeNB and store old KeNB, if any, when the UE receives s RRCConnectionReject with suspend indication in response to s RRCConnectionResumeRequest message for EDT. The UE may derive keNB based on the stored value of the NH count and the NCC (same as a vertical derivation) if the UE has no stored value of KeNB or perform a horizontal derivation of KeNB if the UE has a stored value of KeNB when the NCC provided in RRCConnectionResume message in Msg4 is the same as the stored value of NCC. The UE may derive KeNB based on the stored value of the NH count and NCC if the UE has no stored value of KeNB or perform horizontal derivation of KeNB if the UE has a stored value of KeNB in the next resume procedure for EDT. The UE may not update KeNB when the NCC provided in the RRCConnectionResume message in Msg4 is the same as the stored value of NCC. The UE may not update the KeNB and use the same KeNB and derive new AS keys (KRRCint, KRRCenc and KUPenc) when the UE falls back to a legacy procedure to send a legacy preamble due to a CE level change during a Random Access Procedure for EDT. The UE may not update the KeNB and use the same KeNB and the same AS keys (KRRCint, KRRCenc and KUPenc) when the UE falls back to a legacy procedure to send a legacy preamble due to a CE level change during the Random Access Procedure for EDT. The UE may revert to the original old KeNB or NH and NCC pair to and restart EDT deriving new keys when a new cell is selected after initiating EDT (i.e., after deriving new keys for EDT), or after receiving a RRCConnectionReject message in response to a RRCConnectionResumeRequest message for EDT. The old security context corresponding to the KRRCint that was used to calculate the shortResumeMAC-I may be discarded when the UE receives a RRCConnectionResume message or a RRCConnectionRelease message in response to a RRCConnectionResumeRequest for EDT or in response to Msg3 that is sent after the EDT preamble in Msg1. The UE may initiate an UP EDT in the same cell where the UE was moved to IDLE with a suspend indication in the preceding connection and fail to resume before receiving Msg4, the UE may discard the new security context and move to IDLE with a suspend indication. The UE may move to IDLE without a suspend indication with a release cause “other” or “RRC connection failure”. The UE may initiate an UP EDT in a different cell where the UE was not moved to IDLE with a suspend indication in the preceding connection and fail to resume before receiving Msg4, the UE may move to IDLE without s suspend indication with s release cause “other” or “RRC connection failure”. The UE may store only a single NCC but calculate the NH parameter immediately after receiving a new NCC different that currently stored in the RRCConnectionRelease message during the suspend procedure. The UE may store two NCCs (both old and new) and in case of a next legacy resume procedure, the UE may receive another new NCC in Msg4 and compare with the last used NCC (i.e., the said old NCC).
- Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show, by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
- The Abstract of the Disclosure is provided to comply with 37 C.F.R. § 1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
Claims (20)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/294,653 US20190208411A1 (en) | 2018-03-16 | 2019-03-06 | Security framework for msg3 and msg4 in early data transmission |
US16/407,166 US11064356B2 (en) | 2018-03-16 | 2019-05-08 | Security framework for MSG3 and MSG4 in early data transmission |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201862644102P | 2018-03-16 | 2018-03-16 | |
US201862677994P | 2018-05-30 | 2018-05-30 | |
US201862716440P | 2018-08-09 | 2018-08-09 | |
US201862753841P | 2018-10-31 | 2018-10-31 | |
US16/294,653 US20190208411A1 (en) | 2018-03-16 | 2019-03-06 | Security framework for msg3 and msg4 in early data transmission |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/407,166 Continuation US11064356B2 (en) | 2018-03-16 | 2019-05-08 | Security framework for MSG3 and MSG4 in early data transmission |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190208411A1 true US20190208411A1 (en) | 2019-07-04 |
Family
ID=67060123
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/294,653 Abandoned US20190208411A1 (en) | 2018-03-16 | 2019-03-06 | Security framework for msg3 and msg4 in early data transmission |
US16/407,166 Active 2039-08-08 US11064356B2 (en) | 2018-03-16 | 2019-05-08 | Security framework for MSG3 and MSG4 in early data transmission |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/407,166 Active 2039-08-08 US11064356B2 (en) | 2018-03-16 | 2019-05-08 | Security framework for MSG3 and MSG4 in early data transmission |
Country Status (1)
Country | Link |
---|---|
US (2) | US20190208411A1 (en) |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190215872A1 (en) * | 2017-11-15 | 2019-07-11 | Lg Electronics Inc. | Method for performing early data transmission in random access procedure in wireless communication system and apparatus therefor |
US10701702B2 (en) * | 2018-10-31 | 2020-06-30 | Asustek Computer Inc. | Method and apparatus for transmission using Preconfigured Uplink Resources while in RRC idle or RRC inactive in a wireless communication system |
US20200260348A1 (en) * | 2018-03-28 | 2020-08-13 | Telefonaktiebolaget L M Ericsson (Publ) | Method for avoiding unnecessary actions in resume procedure |
CN111836280A (en) * | 2019-08-27 | 2020-10-27 | 维沃移动通信有限公司 | Data transmission method and terminal |
WO2021012119A1 (en) * | 2019-07-19 | 2021-01-28 | Lenovo (Beijing) Limited | Method and apparatus for data transmission |
WO2021031008A1 (en) * | 2019-08-16 | 2021-02-25 | 北京小米移动软件有限公司 | Random access method and apparatus, and storage medium |
US11032715B2 (en) * | 2018-04-16 | 2021-06-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Security handling for RRC resume from inactive state |
WO2021226793A1 (en) * | 2020-05-11 | 2021-11-18 | Qualcomm Incorporated | Low-latency transmit for rolling comments |
WO2021238813A1 (en) * | 2020-05-26 | 2021-12-02 | 华为技术有限公司 | Method and apparatus for obtaining key |
US20220007423A1 (en) * | 2020-07-06 | 2022-01-06 | Samsung Electronics Co., Ltd. | Method and apparatus for small data transmission |
WO2022001330A1 (en) * | 2020-06-29 | 2022-01-06 | 中兴通讯股份有限公司 | Handover method, network device, user equipment and communication system |
US20220022266A1 (en) * | 2020-07-17 | 2022-01-20 | Samsung Electronics Co., Ltd. | Method and apparatus for random access procedure for small data transmission in wireless communication system |
US20220039068A1 (en) * | 2018-05-10 | 2022-02-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Fallback for Random Access Early Data Transmission |
WO2022021367A1 (en) * | 2020-07-31 | 2022-02-03 | Apple Inc. | Techniques for security key generation by user devices for data transmission in inactive state |
WO2022027433A1 (en) * | 2020-08-06 | 2022-02-10 | Apple Inc. | User equipment (ue) rach procedures for reduced latency in high-propagation-delay networks |
CN114158141A (en) * | 2020-09-08 | 2022-03-08 | 华硕电脑股份有限公司 | Method and apparatus for connection recovery procedure in wireless communication system |
US20220095389A1 (en) * | 2019-06-06 | 2022-03-24 | Huawei Technologies Co., Ltd. | Data Transmission Method and Apparatus |
US20220330372A1 (en) * | 2021-04-12 | 2022-10-13 | Nokia Technologies Oy | Methods, devices, and medium for handling of non-sdt data |
US20230144223A1 (en) * | 2020-07-31 | 2023-05-11 | Apple Inc. | Security Key Generation for Handling Data Transmissions from User Devices in an Inactive State |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220346152A1 (en) * | 2019-09-25 | 2022-10-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Optimization for early data transmission (edt) |
WO2022141025A1 (en) * | 2020-12-29 | 2022-07-07 | 华为技术有限公司 | Method and apparatus for transmitting data |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180324869A1 (en) * | 2017-05-04 | 2018-11-08 | Qualcomm Incorporated | Uplink early data transmission |
WO2018201483A1 (en) * | 2017-05-05 | 2018-11-08 | 华为技术有限公司 | Data transmission method, terminal device and access network device |
WO2018212699A1 (en) * | 2017-05-16 | 2018-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Wireless device, network node, and methods performed thereby for handling grant use |
EP3636031B1 (en) * | 2017-05-17 | 2021-01-20 | Telefonaktiebolaget LM Ericsson (publ) | Partitioning of random access preambles |
US10397833B2 (en) * | 2017-07-27 | 2019-08-27 | Lg Electronics Inc. | Method and apparatus for performing EDT |
US11350445B2 (en) * | 2017-08-10 | 2022-05-31 | Kyocera Corporation | Communication control method for controlling a user equipment to perform early data transmission |
US10849164B2 (en) * | 2017-09-29 | 2020-11-24 | Mediatek Inc. | High reliability and early data transmission |
US20190104553A1 (en) * | 2017-09-29 | 2019-04-04 | Media Tek Inc. | High Reliability and Early Data Transmission |
WO2019098713A1 (en) * | 2017-11-15 | 2019-05-23 | 엘지전자 주식회사 | Method for performing early data transmission during random access procedure in wireless communication system, and apparatus therefor |
CN110012557A (en) * | 2018-01-05 | 2019-07-12 | 夏普株式会社 | Wireless telecom equipment and method |
WO2019145129A1 (en) * | 2018-01-24 | 2019-08-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Multiple tbs for msg3 in data transmission during random access |
US11570819B2 (en) * | 2018-02-02 | 2023-01-31 | Sony Corporation | Telecommunications apparatus and methods |
BR112020022928A2 (en) * | 2018-05-10 | 2021-02-02 | Beijing Xiaomi Mobile Software Co., Ltd. | methods, devices and systems for transmitting data and storage medium |
-
2019
- 2019-03-06 US US16/294,653 patent/US20190208411A1/en not_active Abandoned
- 2019-05-08 US US16/407,166 patent/US11064356B2/en active Active
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10721775B2 (en) * | 2017-11-15 | 2020-07-21 | Lg Electronics Inc. | Method for performing early data transmission in random access procedure in wireless communication system and apparatus therefor |
US20190215872A1 (en) * | 2017-11-15 | 2019-07-11 | Lg Electronics Inc. | Method for performing early data transmission in random access procedure in wireless communication system and apparatus therefor |
US11259337B2 (en) * | 2017-11-15 | 2022-02-22 | Lg Electronics Inc. | Method for performing early data transmission in random access procedure in wireless communication system and apparatus therefor |
US20200260348A1 (en) * | 2018-03-28 | 2020-08-13 | Telefonaktiebolaget L M Ericsson (Publ) | Method for avoiding unnecessary actions in resume procedure |
US11838760B2 (en) | 2018-04-16 | 2023-12-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Security handling for RRC resume from inactive state |
US11032715B2 (en) * | 2018-04-16 | 2021-06-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Security handling for RRC resume from inactive state |
US11166164B2 (en) * | 2018-04-16 | 2021-11-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Security handling for RRC resume from inactive state |
US20220039068A1 (en) * | 2018-05-10 | 2022-02-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Fallback for Random Access Early Data Transmission |
US11882548B2 (en) * | 2018-05-10 | 2024-01-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Fallback for random access early data transmission |
US10701702B2 (en) * | 2018-10-31 | 2020-06-30 | Asustek Computer Inc. | Method and apparatus for transmission using Preconfigured Uplink Resources while in RRC idle or RRC inactive in a wireless communication system |
US20220095389A1 (en) * | 2019-06-06 | 2022-03-24 | Huawei Technologies Co., Ltd. | Data Transmission Method and Apparatus |
WO2021012119A1 (en) * | 2019-07-19 | 2021-01-28 | Lenovo (Beijing) Limited | Method and apparatus for data transmission |
CN112673702A (en) * | 2019-08-16 | 2021-04-16 | 北京小米移动软件有限公司 | Random access method, device and storage medium |
WO2021031008A1 (en) * | 2019-08-16 | 2021-02-25 | 北京小米移动软件有限公司 | Random access method and apparatus, and storage medium |
CN111836280A (en) * | 2019-08-27 | 2020-10-27 | 维沃移动通信有限公司 | Data transmission method and terminal |
WO2021226793A1 (en) * | 2020-05-11 | 2021-11-18 | Qualcomm Incorporated | Low-latency transmit for rolling comments |
WO2021238813A1 (en) * | 2020-05-26 | 2021-12-02 | 华为技术有限公司 | Method and apparatus for obtaining key |
WO2022001330A1 (en) * | 2020-06-29 | 2022-01-06 | 中兴通讯股份有限公司 | Handover method, network device, user equipment and communication system |
US20220007423A1 (en) * | 2020-07-06 | 2022-01-06 | Samsung Electronics Co., Ltd. | Method and apparatus for small data transmission |
US20220022266A1 (en) * | 2020-07-17 | 2022-01-20 | Samsung Electronics Co., Ltd. | Method and apparatus for random access procedure for small data transmission in wireless communication system |
WO2022021367A1 (en) * | 2020-07-31 | 2022-02-03 | Apple Inc. | Techniques for security key generation by user devices for data transmission in inactive state |
US12052566B2 (en) | 2020-07-31 | 2024-07-30 | Apple Inc. | Techniques for security key generation by user devices for data transmission in an inactive state |
GB2612725A (en) * | 2020-07-31 | 2023-05-10 | Apple Inc | Techniques for security key generation by user devices for data transmission in inactive state |
US20230144223A1 (en) * | 2020-07-31 | 2023-05-11 | Apple Inc. | Security Key Generation for Handling Data Transmissions from User Devices in an Inactive State |
WO2022027433A1 (en) * | 2020-08-06 | 2022-02-10 | Apple Inc. | User equipment (ue) rach procedures for reduced latency in high-propagation-delay networks |
US12052763B2 (en) | 2020-08-06 | 2024-07-30 | Apple Inc. | User equipment (UE) RACH procedures for reduced latency in high-propagation-delay networks |
CN114158141A (en) * | 2020-09-08 | 2022-03-08 | 华硕电脑股份有限公司 | Method and apparatus for connection recovery procedure in wireless communication system |
US20220078875A1 (en) * | 2020-09-08 | 2022-03-10 | Asustek Computer Inc. | Method and apparatus for timer control for rrc connection resume procedure in a wireless communication system |
US11849497B2 (en) * | 2021-04-12 | 2023-12-19 | Nokia Technologies Oy | Methods, devices, and medium for handling of non-SDT data |
US20220330372A1 (en) * | 2021-04-12 | 2022-10-13 | Nokia Technologies Oy | Methods, devices, and medium for handling of non-sdt data |
Also Published As
Publication number | Publication date |
---|---|
US11064356B2 (en) | 2021-07-13 |
US20190373456A1 (en) | 2019-12-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11064356B2 (en) | Security framework for MSG3 and MSG4 in early data transmission | |
US10849181B2 (en) | NR RRC connection setup optimisation | |
US11678400B2 (en) | Location and context management in a ran inactive mode | |
CN110786065B (en) | Downlink transmission in RAN inactive mode | |
CN110383868B (en) | Inactive state security support in a wireless communication system | |
EP3979764A1 (en) | Ue identifier in rrc resume | |
CN112400356A (en) | System and method for enabling DL-EDT | |
JP7390359B2 (en) | Security key generation technology | |
ES2963419T3 (en) | Verifying security when an RRC connection is resumed | |
TW201831031A (en) | Device and Method of Handling a State Mismatch in a Wireless Communication System | |
US20220345883A1 (en) | Security key updates in dual connectivity | |
US20240244666A1 (en) | Managing random access in early data communication | |
WO2023154332A1 (en) | Managing small data transmission with a configured grant configuration | |
WO2023154401A1 (en) | Managing radio configurations for small data transmission | |
CN116982271A (en) | Method for satellite hard feeder link handoff | |
CN116783986A (en) | Method and device for data transmission processing | |
CN115175181A (en) | Communication method and device | |
CN118985162A (en) | Managing resources for data transmission in an inactive state | |
WO2023164014A1 (en) | Managing resources for data transmission in an inactive state | |
WO2023196633A1 (en) | Managing small data transmission configuration parameters when detecting a failure | |
WO2023154437A1 (en) | Managing uplink synchronization for a user equipment | |
CN118947215A (en) | Managing small data transmissions with configuration authorization configuration | |
WO2023154439A1 (en) | Managing uplink synchronization at a user equipment | |
CN118947185A (en) | Managing uplink synchronization at user equipment | |
CN118923188A (en) | Managing small data transmissions with a network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHRESTHA, BHARAT;LIM, SEAU S;GUO, YI;SIGNING DATES FROM 20190205 TO 20190307;REEL/FRAME:048563/0001 |
|
AS | Assignment |
Owner name: APPLE INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTEL CORPORATION;REEL/FRAME:052916/0308 Effective date: 20191130 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |