Technology for user equipment to generate security keys for data transmission in an inactive state

Abstract

An exemplary technique for secure key derivation in a wireless system includes: receiving a radio resource control (RRC) suspend message from a first node, the RRC suspend message including a first next hop (NH) chain counter (NCC) value; entering an RRC inactive state; deriving a first node key based on the first NCC value; generating a first uplink message for transmission in the RRC inactive state based on the first node key; and transmitting the first uplink message to a node while in the RRC inactive state.

Description

Technical Field

[0001] The present application relates to wireless devices, including apparatus, systems and methods for generating, by a user equipment, a security key for use in data transmission with a node when the user equipment is in an inactive state. Background Art

[0002] The use of wireless communication systems is growing rapidly. In recent years, wireless devices such as smart phones and tablet computers have become increasingly sophisticated. In addition to supporting phone calls, many mobile devices now also provide access to the Internet, email, text messaging, and navigation using the Global Positioning System (GPS), and are capable of operating sophisticated applications that utilize these capabilities. In addition, there are many different wireless communication technologies and wireless communication standards. Some examples of wireless communication standards include GSM, UMTS (e.g., associated with WCDMA or TD-SCDMA air interfaces), LTE, Advanced LTE (LTE-A), HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), IEEE 802.11 (WLAN or Wi-Fi), BLUETOOTH (BLUETOOTH), and UMTS (e.g., associated with WCDMA or TD-SCDMA air interfaces). TM wait.

[0003] The introduction of an ever-increasing number of features and functions in wireless communication devices also requires continuous improvements in wireless communications and improvements in wireless communication devices. In order to increase coverage and better serve the increased demand and range of intended uses of wireless communications, in addition to the above-mentioned communication standards, there are wireless communication technologies being developed, including fifth generation (5G) new air interface (NR) communications. Therefore, there is a need for improvements in the field of supporting such development and design. Summary of the invention

[0004] Aspects of the present disclosure relate to apparatus, systems, and methods for deriving security keys used by a user equipment to protect transmissions to a node when the user equipment is in an inactive state.

[0005] In some wireless systems, data between user equipment and a central network (CN) may be independently encrypted and / or integrity protected between the UE and a specific node. These independent layers of encryption and / or integrity protection help achieve data security and privacy. In some cases, the UE may enter a radio resource control (RRC) inactive state, whereby the non-access stratum (NAS) connection to the CN is maintained, but the access stratum (AS) resources are released. It is necessary to allow the user equipment to transmit data while remaining in the RRC inactive state. Since the AS resources are released, it is necessary to define a method for determining the encryption or integrity protection key used when the user equipment transmits UL data while remaining in the inactive state.

[0006] Therefore, according to some aspects disclosed herein, a method for security key derivation in a wireless system includes: receiving a radio resource control (RRC) suspend message from a first node, the RRC suspend message including a first next hop (NH) chain counter (NCC) value; entering an RRC inactive state; deriving a first node key based on the first NCC value; generating a first uplink message for transmission in the RRC inactive state based on the first node key; and transmitting the first uplink message to the node while in the RRC inactive state.

[0007] In some aspects, the method may also include a case where the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and where the first node key is the same as the second node key. In some aspects, the method may also include a case where the first NCC value is different from the second NCC value previously used to derive the second node key. In some aspects, the method may also include: receiving first cell information from a first node, wherein the first node key is derived based on the first NCC value from the first node and the first cell information; generating a second uplink message for transmission in an RRC inactive state based on the first node key; and transmitting the second uplink message when in the RRC inactive state. In some aspects, the method may also include: deriving a third node key based on the first node key; generating a third uplink message for transmission in an RRC inactive state based on the third node key; and transmitting a third uplink message to a third node when in the RRC inactive state. In some aspects, the method may also include a case where the RRC suspend message includes multiple NCC values, and further includes: vertically deriving a second node key based on a second NCC value in the multiple NCC values; generating a second uplink message for transmission in the RRC inactive state based on the second node key; and transmitting the second uplink message to the node when in the RRC inactive state. In some aspects, the method may also include a case where the first uplink message is transmitted to a second node, and further includes: receiving a second NCC value from the second node; vertically deriving a second node key based on the second NCC value; generating a second uplink message for transmission in the RRC inactive state based on the second node key; and transmitting the second uplink message to a third node when in the RRC inactive state.

[0008] The techniques described herein may be implemented in and / or used with a number of different types of devices, including, but not limited to, any of cellular telephones, wireless devices, tablet computers, wearable computing devices, portable media players, and a variety of other computing devices.

[0009] This disclosure is intended to provide a brief overview of some of the topics described in this document. Therefore, it should be understood that the above features are only examples and should not be construed as narrowing the scope or essence of the topics described herein in any way. Other features, aspects, and advantages of the topics described herein will become apparent through the following detailed description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] A better understanding of the present subject matter may be obtained when the following detailed description of various aspects is considered in conjunction with the following drawings, in which:

[0011] Figure 1 An exemplary wireless communication system in accordance with aspects of the present disclosure is shown.

[0012] Figure 2 A base station (BS) in communication with a user equipment (UE) device is shown in accordance with aspects of the present disclosure.

[0013] Figure 3 An exemplary block diagram of a UE according to aspects of the present disclosure is shown.

[0014] Figure 4 An exemplary block diagram of a BS according to aspects of the present disclosure is shown.

[0015] Figure 5 An exemplary block diagram of cellular communication circuitry in accordance with aspects of the present disclosure is shown.

[0016] Figure 6 An exemplary block diagram of a network element according to aspects of the present disclosure is shown.

[0017] Figures 7 and 8 is a communication flow diagram illustrating communication flows for entering and resuming from an RRC inactive state in accordance with aspects of the present disclosure.

[0018] Fig. 9 is a diagram illustrating key derivation according to aspects of the present disclosure.

[0019] Figures 10 to 20 is a communication flow diagram illustrating an exemplary technique for key generation for inactive state data transfer in accordance with aspects of the present disclosure.

[0020] Fig.21 is a flow chart illustrating a technique for generating keys by a user device for inactive state data transmission in accordance with aspects of the present disclosure.

[0021] Fig. 22 is a flow chart illustrating a technique for generating additional keys by a user device for inactive state data transmission in accordance with aspects of the present disclosure.

[0022] Fig.23 is a flow chart illustrating a technique for generating additional keys by a user device for inactive state data transmission in accordance with aspects of the present disclosure.

[0023] Fig.24 is a flow chart illustrating a technique for generating keys by a node for inactive state data transmission in accordance with aspects of the present disclosure.

[0024] Fig.25 is a flow chart illustrating a technique for generating additional keys by a node for inactive state data transmission in accordance with aspects of the present disclosure.

[0025] Fig.26 is a flow chart illustrating a technique for generating additional keys by a node for inactive state data transmission in accordance with aspects of the present disclosure.

[0026] Although the features described herein are susceptible to various modifications and alternative forms, specific aspects thereof are shown by way of example in the drawings and described in detail herein. However, it should be understood that the drawings and detailed description thereof are not intended to limit this document to the specific forms disclosed, but on the contrary, the purpose is to cover all modifications, equivalents and alternatives that fall within the spirit and scope of the subject matter as defined by the appended claims. DETAILED DESCRIPTION

[0027] The following is a glossary of terms that may be used in this disclosure:

[0028] Memory medium - any of various types of non-transitory memory devices or storage devices. The term "memory medium" is intended to include installation media, such as CD-ROM, floppy disk or tape devices; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media, for example, hard disk drive or optical storage device; registers or other similar types of memory elements, etc. The memory medium may also include other types of non-transitory memory or a combination thereof. In addition, the memory medium may be located in the first computer system executing the program, or may be located in a different second computer system connected to the first computer system via a network such as the Internet. In the latter case, the second computer system may provide program instructions to the first computer for execution. The term "memory medium" may include two or more memory media that may reside in different locations in different computer systems connected, for example, via a network. The memory medium may store program instructions (e.g., in the form of a computer program) that may be executed by one or more processors.

[0029] Carrier Media—storage media as described above and physical transmission media such as a bus, network, and / or other physical transmission media that carry signals such as electrical, electromagnetic, or digital signals.

[0030] Programmable hardware elements - include various hardware devices that include multiple programmable function blocks connected via programmable interconnects. Examples include FPGAs (field programmable gate arrays), PLDs (programmable logic devices), FPOAs (field programmable object arrays), and CPLDs (complex PLDs). Programmable function blocks can vary from fine-grained (combinational logic units or lookup tables) to coarse-grained (arithmetic logic units or processor cores). Programmable hardware elements may also be referred to as "configurable logic units."

[0031] Computer System—Any of various types of computing or processing systems, including a personal computer system (PC), a mainframe computer system, a workstation, a network appliance, an Internet appliance, a personal digital assistant (PDA), a television system, a grid computing system, or other devices or combinations of devices. In general, the term "computer system" can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0032] User Equipment (UE) (or "UE device") - any of various types of computer systems or devices that are mobile or portable and that perform wireless communications. Examples of UE devices include mobile phones or smart phones (e.g., iPhone TM , based on Android TM phones), portable gaming devices (e.g., Nintendo DS TM , PlayStation Portable TM 、Gameboy Advance TM , iPhone TM ), laptops, wearable devices (e.g., smart watches, smart glasses), PDAs, portable Internet devices, music players, data storage devices or other handheld devices, etc. In general, the term "UE" or "UE device" can be broadly defined to cover any electronic device, computing device and / or telecommunication device (or combination of devices) that can be easily transmitted by a user and capable of wireless communication.

[0033] Wireless Device—Any of various types of computer systems or devices that perform wireless communications. A wireless device may be portable (or mobile), or may be stationary or fixed at a certain location. A UE is an example of a wireless device.

[0034] Communication device - any of various types of computer systems or devices that perform communication, where the communication may be wired or wireless. A communication device may be portable (or mobile), or may be stationary or fixed at a location. A wireless device is an example of a communication device. A UE is another example of a communication device.

[0035] Base Station - The term "base station" has the full scope of its ordinary meaning and includes at least a wireless communication station that is installed at a fixed location and used to communicate as part of a wireless telephone system or radio system. For example, if a base station is implemented in the context of LTE, it may alternatively be referred to as an "eNodeB" or "eNB". If a base station is implemented in the context of 5G NR, it may alternatively be referred to as a "gNodeB" or "gNB". Although certain aspects are described in the context of LTE or 5G NR, references to "eNB", "gNB", "nodeB", "base station", "NB", etc. may also refer to one or more wireless nodes that serve a cell to provide wireless connectivity between a user device and a generally wider network, and the concepts discussed are not limited to any particular wireless technology. Although certain aspects are described in the context of LTE or 5G NR, references to "eNB", "gNB", "nodeB", "base station", "NB", etc. are not intended to limit the concepts discussed herein to any particular wireless technology, and the concepts discussed may be applied to any wireless system.

[0036] Node—As used herein, the term “node” may refer to one or more devices associated with a cell that provides wireless connectivity between user equipment and a typically wider network.

[0037] Processing element (or processor) - refers to various elements or combinations of elements that are capable of performing functions in a device such as user equipment or cellular network equipment. Processing elements may include, for example, processors and associated memory, portions or circuits of individual processor cores, entire processor cores, separate processors, processor arrays, circuits such as ASICs (application specific integrated circuits), programmable hardware elements such as field programmable gate arrays (FPGAs), and any of the above combinations.

[0038] Channel - a medium used to transmit information from a sender (transmitter) to a receiver. It should be noted that since the characteristics of the term "channel" may vary according to different wireless protocols, the term "channel" used in the present invention may be considered to be used in a manner that conforms to the standards of the type of device to which the term is used. In some standards, the channel width may be variable (e.g., depending on device capabilities, frequency band conditions, etc.). For example, LTE may support scalable channel bandwidths of 1.4MHz to 20MHz. In contrast, a WLAN channel may be 22MHz wide, while a Bluetooth channel may be 1Mhz wide. Other protocols and standards may include different definitions of channels. In addition, some standards may define and use multiple types of channels, such as different channels for uplink or downlink and / or different channels for different purposes such as data, control information, etc.

[0039] Frequency band—The term “frequency band” has the full breadth of its ordinary meaning and includes at least a segment of the spectrum (eg, radio frequency spectrum) in which channels are used or set aside for the same purpose.

[0040] Automatic—refers to an action or operation being performed by a computer system (e.g., software executed by a computer system) or a device (e.g., a circuit, a programmable hardware element, an ASIC, etc.) without the need for the action or operation to be directly specified or performed by a user input. Thus, the term "automatic" is in contrast to an operation that is manually performed or specified by a user, where the user provides input to directly perform the operation. An automatic process may be initiated by input provided by a user, but the subsequent actions performed "automatically" are not specified by the user, i.e., are not performed "manually," where the user specifies each action to be performed. For example, a user filling out an electronic form by selecting each field and providing input specifying information (e.g., by typing in information, selecting checkboxes, radio selections, etc.) is manually filling out the form, even though the computer system must update the form in response to the user action. The form may be automatically filled out by a computer system, where the computer system (e.g., software executed on the computer system) analyzes the fields of the form and fills out the form without any user input specifying the answers to the fields. As indicated above, a user may invoke automatic filling out of a form, but not participate in the actual filling out of the form (e.g., the user does not manually specify the answers to the fields but rather they are automatically completed). This specification provides various examples of operations that are automatically performed in response to actions taken by a user.

[0041] About - refers to a value that is close to a correct or exact value. For example, about can refer to a value that is within 1% to 10% of an exact (or desired) value. However, it should be noted that the actual threshold (or tolerance) may depend on the application. For example, in some aspects, "about" may mean within 0.1% of some specified or desired value, while in various other aspects, the threshold may be, for example, 2%, 3%, 5%, etc., depending on the desires or requirements of a particular application.

[0042] Concurrency - refers to parallel execution or implementation, where tasks, processes, or programs are executed in an at least partially overlapping manner. For example, concurrency can be achieved using "strong" or strict parallelism, where tasks are executed (at least partially) in parallel on respective computing elements, or using "weak parallelism," where tasks are executed in an interleaved manner (e.g., by time multiplexing of execution threads).

[0043] Configured to - Various components may be described as being "configured to" perform one or more tasks. In such environments, "configured to" is a broad statement that generally means "having a structure" that performs one or more tasks during operation. Thus, a component can be configured to perform a task even when the component is not currently performing the task (e.g., a set of electrical conductors can be configured to electrically connect a module to another module even when the two modules are not connected). In some contexts, "configured to" can be a broad statement that generally means "having a structure" that performs one or more tasks during operation. Thus, the component can be configured to perform a task even when the component is not currently turned on. Typically, the circuitry that forms the structure corresponding to "configured to" may include hardware circuitry.

[0044] For ease of description, various components may be described as performing one or more tasks. Such descriptions should be interpreted as including the phrase "configured to". The description of a component being configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. §112(f) interpretation of that component.

[0045] Exemplary Wireless Communication System

[0046] Now go to Figure 1 , shows a simplified example of a wireless communication system according to some aspects. Note that Figure 1 The system is only one example of possible systems, and features of the present disclosure may be implemented in any of a variety of systems as desired.

[0047] As shown, the exemplary wireless communication system includes a base station 102A, which communicates with one or more user equipment 106A, user equipment 106B to user equipment 106N, etc. through a transmission medium. Each user equipment may be referred to as a "user equipment" (UE) in this article. Therefore, user equipment 106 is referred to as UE or UE device.

[0048] The base station (BS) 102A may be a base transceiver station (BTS) or a cell site ("cellular base station") and may include hardware that enables wireless communications with the UEs 106A through 106N.

[0049] The communication area (or coverage area) of a base station may be referred to as a “cell.” The base station 102A and the user equipment 106 may be configured to communicate over a transmission medium using any of a variety of radio access technologies (RATs), also referred to as wireless communication technologies or telecommunication standards, such as GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interfaces), LTE, LTE-Advanced (LTE-A), 5G New Radio (5G NR), HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), and the like.

[0050] As shown, base station 102A may also be configured to communicate with network 100 (e.g., a core network of a cellular service provider, a telecommunications network such as a public switched telephone network (PSTN), and / or the Internet, among other possibilities). Thus, base station 102A may facilitate communications between user devices and / or between user devices and network 100. In particular, cellular base station 102A may provide UE 106 with various communication capabilities, such as voice, SMS, and / or data services.

[0051] Base station 102A and other similar base stations (such as base stations 102B...102N) operating according to the same or different cellular communication standards can therefore be provided as a network of cells that can provide continuous or nearly continuous overlapping service to UE 106A-N and similar devices over a geographic area via one or more cellular communication standards.

[0052] Thus, although base station 102A may function as Figure 1106A-N, but each UE 106 may also be able to receive signals from (and possibly be within communication range of) one or more other cells (which may be provided by base stations 102B-N and / or any other base stations), which may be referred to as "neighboring cells." Such cells may also be able to facilitate communications between user devices and / or between user devices and network 100. Such cells may include "macro" cells, "micro" cells, "pico" cells, and / or cells of any various other granularity of service area size. For example, in Figure 1 The base stations 102A-102B shown in FIG. 1 may be macro cells, while the base station 102N may be a micro cell. Other configurations are also possible.

[0053] In some aspects, base station 102A may be a next generation base station, such as a 5G New Radio (5G NR) base station or "gNB". In some aspects, the gNB may be connected to a legacy evolved packet core (EPC) network and / or to an NR core (NRC) / 5G core (5GC) network. In addition, a gNB cell may include one or more transition and reception points (TRPs). In addition, a UE capable of operating in accordance with 5G NR may be connected to one or more TRPs within one or more gNBs. For example, base station 102A and one or more other base stations 102 may support joint transmissions such that UE 106 may be able to receive transmissions from multiple base stations (and / or multiple TRPs provided by the same base station). For example, as Figure 1 As shown, base station 102A and base station 102C are both shown serving UE 106A.

[0054] It should be noted that the UE 106 is capable of communicating using multiple wireless communication standards. For example, in addition to at least one cellular communication protocol (e.g., GSM, UMTS (associated with, for example, WCDMA or TD-SCDMA air interface), LTE, LTE-A, 5G NR, HSPA, 3GPP2CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), etc.), the UE 106 can be configured to communicate using wireless networking (e.g., Wi-Fi) and / or peer-to-peer wireless communication protocols (e.g., Bluetooth, Wi-Fi peer-to-peer, etc.). If desired, the UE 106 can also or alternatively be configured to communicate using one or more global navigation satellite systems (GNSS, such as GPS or GLONASS), one or more mobile television broadcast standards (e.g., Advanced Television Systems Committee—Mobile / Handheld (ATSC-M / H)), and / or any other wireless communication protocol. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

[0055] Exemplary User Equipment (UE)

[0056] Figure 2 A user equipment 106 (e.g., one of devices 106A-106N) is shown in accordance with some aspects in communication with base station 102. UE 106 may be a device with cellular communication capabilities, such as a mobile phone, handheld device, computer, laptop, tablet, smart watch or other wearable device, or indeed any type of wireless device.

[0057] UE 106 may include a processor (processing element) configured to execute program instructions stored in a memory. UE 106 may perform any of the method aspects described herein by executing such stored instructions. Alternatively or in addition, UE 106 may include a programmable hardware element, such as an FPGA (field programmable gate array), an integrated circuit, and / or any of a variety of other possible hardware components configured to perform (e.g., individually or in combination) any of the method aspects described herein or any portion of any of the method aspects described herein.

[0058] UE 106 may include one or more antennas for communicating using one or more wireless communication protocols or technologies. In some aspects, UE 106 may be configured to communicate using, for example, NR or LTE using at least some shared radio components. As an additional possibility, the UE 106 may be configured to communicate using CDMA2000 (1xRTT / 1xEV-DO / HRPD / eHRPD) or LTE using a single shared radio component and / or GSM or LTE using a single shared radio component. The shared radio may be coupled to a single antenna, or may be coupled to multiple antennas (e.g., for MIMO) for performing wireless communications. Typically, the radio component may include any combination of a baseband processor, an analog radio frequency (RF) signal processing circuit (e.g., including filters, mixers, oscillators, amplifiers, etc.), or a digital processing circuit (e.g., for digital modulation and other digital processing). Similarly, the radio component may use the aforementioned hardware to implement one or more receive chains and transmit chains. For example, UE 106 may share one or more portions of a receive chain and / or transmit chain between multiple wireless communication technologies such as those discussed above.

[0059] In some aspects, the UE 106 may include a separate transmit chain and / or receive chain (e.g., including separate antennas and other radio components) for each wireless communication protocol with which it is configured to communicate. As another possibility, the UE 106 may include one or more radio components shared between multiple wireless communication protocols, and one or more radio components used uniquely by a single wireless communication protocol. For example, the UE 106 may include a shared radio component for communicating using either LTE or 5G NR (or, in various possibilities, either LTE or 1xRTT, or either LTE or GSM), and an independent radio component for communicating using each of Wi-Fi and Bluetooth. Other configurations are also possible.

[0060] Exemplary Communication Devices

[0061] Figure 3 1 shows an exemplary simplified block diagram of a communication device 106 according to some aspects. Note that Figure 3 The block diagram of the communication device is only an example of a possible communication device. According to various aspects, the communication device 106 can be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, a notebook or a portable computing device), a tablet computer and / or a combination of devices, in addition to other devices. As shown, the communication device 106 may include a group of components 300 configured to perform core functions. For example, the group of components may be implemented as a system on a chip (SOC), which may include parts for various purposes. Alternatively, the group of components 300 may be implemented as a separate component or group of components for various purposes. This group of components 300 may be coupled to various other circuits of the communication device 106 (e.g., communicatively; directly or indirectly).

[0062] For example, the communication device 106 may include various types of memory (e.g., including NAND flash memory 310), input / output interfaces such as connector I / F 320 (e.g., for connecting to a computer system; a docking station; a charging station; input devices such as a microphone, camera, keyboard; output devices such as speakers; etc.), a display 360 that may be integrated with the communication device 106 or external to it, and wireless communication circuitry 330 (e.g., for LTE, LTE-A, NR, UMTS, GSM, CDMA2000, Bluetooth, Wi-Fi, NFC, GPS, etc.). In some aspects, the communication device 106 may include wired communication circuitry (not shown), such as, for example, a network interface card for Ethernet.

[0063] Wireless communication circuitry 330 may be (e.g., communicatively; directly or indirectly) coupled to one or more antennas, such as one or more antennas 335 as shown. Wireless communication circuitry 330 may include cellular communication circuitry and / or short- to medium-range wireless communication circuitry, and may include multiple receive chains and / or multiple transmit chains for receiving and / or transmitting multiple spatial streams, such as in a multiple-input multiple-output (MIMO) configuration.

[0064] In some aspects, as further described below, the cellular communication circuitry 330 can include one or more receive chains (including and / or coupled to (e.g., communicatively; directly or indirectly) dedicated processors and / or radio components (e.g., a first receive chain for LTE and a second receive chain for 5G NR) for multiple RATs. Moreover, in some aspects, the cellular communication circuitry 330 can include a single transmit chain that can switch between radio components dedicated to specific RATs. For example, a first radio component can be dedicated to a first RAT (e.g., LTE) and can communicate with a dedicated receive chain and a transmit chain shared with a second radio component. A second radio component can be dedicated to a second RAT (e.g., 5G NR) and can communicate with a dedicated receive chain and a shared transmit chain.

[0065] The communication device 106 may also include and / or be configured for use with one or more user interface elements. The user interface elements may include various elements such as a display 360 (which may be a touch screen display), a keyboard (which may be a separate keyboard or may be implemented as part of a touch screen display), a mouse, a microphone and / or speakers, one or more cameras, one or more buttons, and / or any of a variety of other elements capable of providing information to a user and / or receiving or interpreting user input.

[0066] The communication device 106 may also include one or more smart cards 345 having SIM (Subscriber Identity Module) functionality, such as one or more UICC cards (one or more Universal Integrated Circuit Cards) 345 .

[0067] As shown, the SOC 300 may include a processor 302 that may execute program instructions for the communication device 106 and a display circuit 304 that may perform graphics processing and provide display signals to a display 360. The one or more processors 302 may also be coupled to a memory management unit (MMU) 340 (which may be configured to receive addresses from the one or more processors 302 and convert those addresses to locations in a memory (e.g., a memory 306, a read-only memory (ROM) 350, a NAND flash memory 310)), and / or to other circuits or devices (such as the display circuit 304, the wireless communication circuit 330, the connector I / F 320, and / or the display 360). The MMU 340 may be configured to perform memory protection and page table translation or setup. In some aspects, the MMU 340 may be included as part of the processor 302.

[0068] As described above, the communication device 106 may be configured to communicate using wireless and / or wired communication circuits. As described herein, the communication device 106 may include hardware and software components for implementing any of the various features and techniques described herein. For example, by executing program instructions stored on a memory medium (e.g., a non-transient computer-readable memory medium), the processor 302 of the communication device 106 may be configured to implement part or all of the features described in the present invention. Alternatively (or in addition thereto), the processor 302 may be configured as a programmable hardware element, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). Alternatively (or in addition thereto), in combination with one or more components in other components 300, 304, 306, 310, 320, 330, 340, 345, 350, 360, the processor 302 of the communication device 106 may be configured to implement part or all of the features described herein.

[0069] In addition, as described in the present invention, processor 302 may include one or more processing elements. Therefore, processor 302 may include one or more integrated circuits (ICs) configured to perform the functions of processor 302. In addition, each integrated circuit may include circuits (e.g., first circuits, second circuits, etc.) configured to perform the functions of one or more processors 302.

[0070] In addition, as described herein, wireless communication circuit 330 may include one or more processing elements. In other words, one or more processing elements may be included in wireless communication circuit 330. Therefore, wireless communication circuit 330 may include one or more integrated circuits (ICs) configured to perform the functions of wireless communication circuit 330. In addition, each integrated circuit may include circuits (e.g., a first circuit, a second circuit, etc.) configured to perform the functions of wireless communication circuit 330.

[0071] Exemplary Base Station

[0072] Figure 4 1 shows an exemplary block diagram of a base station 102 according to some aspects. Note that Figure 4 The base station of is only one example of a possible base station. As shown, the base station 102 may include a processor 404 that may execute program instructions for the base station 102. The processor 404 may also be coupled to a memory management unit (MMU) 440 or other circuit or device, which may be configured to receive addresses from the processor 404 and convert these addresses to locations in memory (e.g., memory 460 and read-only memory (ROM) 450).

[0073] Base station 102 may include at least one network port 470. Network port 470 may be configured to couple to a telephone network and provide access to the telephone network described above. Figure 1 and Figure 2 Multiple devices of the telephone network described in, such as UE device 106.

[0074] The network port 470 (or an additional network port) may also or alternatively be configured to couple to a cellular network, such as a core network of a cellular service provider. The core network may provide mobility-related services and / or other services to multiple devices, such as the UE device 106. In some cases, the network port 470 may be coupled to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., in other UE devices served by the cellular service provider).

[0075] In some aspects, base station 102 may be a next generation base station, e.g., a 5G New Radio (5G NR) base station or "gNB". In such aspects, base station 102 may be connected to a legacy evolved packet core (EPC) network and / or to an NR core (NRC) / 5G core (5GC) network. Furthermore, base station 102 may be considered a 5G NR cell and may include one or more transition and reception points (TRPs). Furthermore, a UE capable of operating in accordance with 5G NR may be connected to one or more TRPs within one or more gNBs.

[0076] The base station 102 may include at least one antenna 434 and possibly multiple antennas. The at least one antenna 434 may be configured to function as a wireless transceiver and may be further configured to communicate with the UE device 106 via the radio component 430. The antenna 434 communicates with the radio component 430 via a communication chain 432. The communication chain 432 may be a receive chain, a transmit chain, or both. The radio component 430 may be configured to communicate via various wireless communication standards, including but not limited to 5G NR, LTE, LTE-A, GSM, UMTS, CDMA2000, Wi-Fi, etc.

[0077] Base station 102 may be configured to perform wireless communications using multiple wireless communication standards. In some cases, base station 102 may include multiple radios that enable base station 102 to communicate according to multiple wireless communication technologies. For example, as one possibility, base station 102 may include an LTE radio component for performing communications according to LTE and a 5G NR radio component for performing communications according to 5GNR. In this case, base station 102 may be able to operate as both an LTE base station and a 5G NR base station. As another possibility, base station 102 may include a multimode radio component capable of performing communications according to any one of multiple wireless communication technologies (e.g., 5GNR and LTE, 5G NR and Wi-Fi, LTE and Wi-Fi, LTE and UMTS, LTE and CDMA2000, UMTS and GSM, etc.).

[0078] As further described later herein, BS102 may include hardware and software components for implementing or supporting specific implementations of the features described herein. The processor 404 of the base station 102 may be configured to implement or support a portion or all of the embodiments of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively, the processor 404 may be configured as a programmable hardware element such as an FPGA (field programmable gate array), or as an ASIC (application-specific integrated circuit) or a combination thereof. Alternatively (or in addition thereto), in combination with one or more of the other components 430, 432, 434, 440, 450, 460, 470, the processor 404 of the base station 102 may be configured to implement or support a portion or all of the embodiments of the features described herein.

[0079] In addition, as described herein, the one or more processors 404 may include one or more processing elements. Thus, the processor 404 may include one or more integrated circuits (ICs) configured to perform the functions of the processor 404. In addition, each integrated circuit may include circuits (e.g., first circuits, second circuits, etc.) configured to perform the functions of the one or more processors 404.

[0080] In addition, as described herein, radio 430 may include one or more processing elements. Thus, radio 430 may include one or more integrated circuits (ICs) configured to perform the functions of radio 430. In addition, each integrated circuit may include a circuit (e.g., a first circuit, a second circuit, etc.) configured to perform the functions of radio 430.

[0081] Exemplary Cellular Communications Circuitry

[0082] Figure 5 An exemplary simplified block diagram of a cellular communication circuit according to some aspects is shown. Note that Figure 5 The block diagram of the cellular communication circuitry of is only one example of possible cellular communication circuitry; other circuitry, such as circuitry that includes or is coupled to sufficient antennas for different RATs to perform uplink activities using separate antennas, or circuitry that includes or is coupled to fewer antennas, such as circuitry that can be shared between multiple RATs, is also possible. According to some aspects, the cellular communication circuitry 330 may be included in a communication device such as the communication device 106 described above. As described above, the communication device 106 may be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device), a tablet computer, and / or a combination of devices, among other devices.

[0083] The cellular communication circuitry 330 may be (e.g., communicatively; directly or indirectly) coupled to one or more antennas, such as antennas 335a-b and 336 as shown. In some aspects, the cellular communication circuitry 330 may include dedicated receive chains for multiple RATs (including and / or coupled to (e.g., communicatively; directly or indirectly) dedicated processors and / or radio components (e.g., a first receive chain for LTE and a second receive chain for 5G NR). For example, Figure 5 As shown, the cellular communication circuit 330 may include a first modem 510 and a second modem 520. The first modem 510 may be configured for communication according to a first RAT (e.g., such as LTE or LTE-A), and the second modem 520 may be configured for communication according to a second RAT (e.g., such as 5G NR).

[0084] As shown, the first modem 510 may include one or more processors 512 and a memory 516 in communication with the processor 512. The modem 510 may communicate with a radio frequency (RF) front end 530. The RF front end 530 may include circuits for transmitting and receiving radio signals. For example, the RF front end 530 may include a receiving circuit (RX) 532 and a transmitting circuit (TX) 534. In some aspects, the receiving circuit 532 may communicate with a downlink (DL) front end 550, which may include circuits for receiving radio signals via an antenna 335a.

[0085] Similarly, the second modem 520 may include one or more processors 522 and a memory 526 in communication with the processor 522. The modem 520 may communicate with the RF front end 540. The RF front end 540 may include circuits for transmitting and receiving radio signals. For example, the RF front end 540 may include a receiving circuit 542 and a transmitting circuit 544. In some aspects, the receiving circuit 542 may communicate with the DL front end 560, which may include circuits for receiving radio signals via the antenna 335b.

[0086] In some aspects, the switch 570 may couple the transmit circuit 534 to an uplink (UL) front end 572. In addition, the switch 570 may couple the transmit circuit 544 to the UL front end 572. The UL front end 572 may include circuitry for transmitting radio signals via the antenna 336. Thus, when the cellular communication circuit 330 receives an instruction to transmit according to a first RAT (e.g., via a transmit chain including the transmit circuit 534 and the UL front end 572) supported by the first modem 510, the switch 570 may be switched to a first state that allows the first modem 510 to transmit signals according to the first RAT (e.g., via a transmit chain including the transmit circuit 534 and the UL front end 572). Similarly, when the cellular communication circuit 330 receives an instruction to transmit according to a second RAT (e.g., via a transmit chain including the transmit circuit 544 and the UL front end 572) supported by the second modem 520, the switch 570 may be switched to a second state that allows the second modem 520 to transmit signals according to the second RAT (e.g., via a transmit chain including the transmit circuit 544 and the UL front end 572).

[0087] As described herein, the first modem 510 and / or the second modem 520 may include hardware and software components for implementing any of the various features and techniques described herein. For example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium), the processors 512, 522 may be configured to implement part or all of the features described herein. Alternatively (or in addition), the processors 512, 522 may be configured as programmable hardware elements, such as an FPGA (field programmable gate array) or as an ASIC (application-specific integrated circuit). Alternatively (or in addition), in combination with one or more of the other components 530, 532, 534, 540, 542, 544, 550, 570, 572, 335, and 336, the processors 512, 522 may be configured to implement part or all of the features described herein.

[0088] In addition, as described herein, the processors 512, 522 may include one or more processing elements. Thus, the processors 512, 522 may include one or more integrated circuits (ICs) configured to perform the functions of the processors 512, 522. In addition, each integrated circuit may include circuits (e.g., first circuits, second circuits, etc.) configured to perform the functions of the processors 512, 522.

[0089] In some aspects, the cellular communication circuit 330 may include only one transmit / receive chain. For example, the cellular communication circuit 330 may not include the modem 520, the RF front end 540, the DL front end 560, and / or the antenna 335b. As another example, the cellular communication circuit 330 may not include the modem 510, the RF front end 530, the DL front end 550, and / or the antenna 335a. In some aspects, the cellular communication circuit 330 may also not include the switch 570, and the RF front end 530 or the RF front end 540 may communicate with the UL front end 572, for example, directly.

[0090] Exemplary Network Elements

[0091] Figure 6 An exemplary block diagram of a network element 600 according to some aspects is shown. According to some aspects, the network element 600 may implement one or more logical functions / entities of a cellular core network, such as a mobility management entity (MME), a serving gateway (S-GW), an access and management function (AMF), a session management function (SMF), a network slice quota management (NSQM) function, etc. It should be noted that Figure 6The network element 600 is only one example of a possible network element 600. As shown, the core network element 600 may include one or more processors 604 that may execute program instructions of the core network element 600. The processor 604 may also be coupled to a memory management unit (MMU) 640 (which may be configured to receive addresses from the processor 604 and translate these addresses into locations in memory (e.g., memory 660 and read-only memory (ROM) 650)), or to other circuits or devices.

[0092] The network element 600 may include at least one network port 670. The network port 670 may be configured to couple to one or more base stations and / or other cellular network entities and / or devices. The network element 600 may communicate with a base station (e.g., eNB / gNB) and / or other network entities / devices by means of any of a variety of communication protocols and / or interfaces.

[0093] As further described later herein, the network element 600 may include hardware and software components for implementing or supporting the implementation of the features described herein. The processor 604 of the core network element 600 may be configured to implement or support a portion or all of the implementation of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively, the processor 604 may be configured as a programmable hardware element such as an FPGA (field programmable gate array) or as an ASIC (application-specific integrated circuit) or a combination thereof. The network element 600 may operate according to the various methods disclosed herein to enable a wireless device to perform cell measurements in a cellular communication system using a configured reference signal when in an inactive state.

[0094] Radio Resource Control (RRC) Idle and Inactive States

[0095] Various cellular communication technologies include the use of a radio resource control (RRC) protocol (eg, which may facilitate connection establishment and release, radio bearer establishment, reconfiguration, and release) and / or various other possible signaling functions supporting the air interface between a wireless device and a cellular base station.

[0096] A wireless device may generally operate in one of a number of possible states with respect to RRC. For example, in LTE, a wireless device may operate in an RRC connected state (e.g., where the wireless device may perform continuous data transmission, and where handovers between cells are managed by the network, and where access stratum (AS) context information is retained for the wireless device), or may operate in an RRC idle state (e.g., where the wireless device may operate in a battery-efficient state when not performing continuous data transmission, where the wireless device may process its cell reselection activities, and where the network may not retain AS context information for the wireless device).

[0097] In addition to the RRC connected state and the RRC idle state, at least according to some aspects, one or more other types of RRC states for the wireless device may be supported. For example, for NR, an RRC inactive state may be supported, in which the wireless device may be able to operate in a relatively battery-efficient state while the network also retains at least some AS context information. In some aspects, the wireless device may maintain a non-access stratum connection (NAS) and RRC configuration with the CN, as before the UE entered the inactive state. In some cases, dedicated AS resources may not be allocated to the UE in the inactive state. At least according to some aspects, this state may adopt mobility based on the wireless device, for example, so that the wireless device can move within a radio access network notification area (RNA) without notifying the next generation (NG) radio access network (RAN). While in this state, the wireless device can perform cell reselection and system information acquisition for itself. At the same time, the previous serving base station (e.g., gNB) can maintain the wireless device context and the NG connection with the 5G core network (CN) associated with the wireless device, for example, to facilitate easier transition back to the RRC connected state. When paging a wireless device in the RRC inactive state, the RAN may use RNA specific parameters including, for example, UE specific DRX and UE identity index value (eg, I-RNTI).

[0098] According to some aspects, a wireless device operating in such an RRC inactive state may perform RNA updates periodically (e.g., based on a configured periodic RNA update timer) and / or in an event-based manner, for example, when the wireless device moves out of its currently configured RNA to a different RNA.

[0099] At least in some cases, using the RRC inactive state can help reduce network signaling overhead for wireless device connections. For example, for wireless devices that do not transmit data frequently, using such an RRC inactive state can reduce the amount of required mobility-related signaling (e.g., for handover) compared to using the RRC connected state, for example, because the wireless device may be able to manage its own cell reselection process when moving between cells. For such wireless devices, using the RRC inactive state can also reduce the amount of required connection establishment-related signaling compared to using the RRC idle state, for example, because the network can retain at least some context information for the wireless device. This can directly reduce the signaling latency associated with the transition to the RRC connected state.

[0100] As another potential benefit, such a state may reduce control plane latency of the wireless device compared to operating in the RRC idle state, for example. For example, it is possible that the access layer connection establishment time period and / or the non-access layer connection establishment time period is shortened for the RRC inactive state relative to the RRC idle state. Thus, the time to transition from a battery-effective state to the start of continuous data transmission may be reduced.

[0101] Additionally, such a state may improve power saving capabilities of the wireless device, for example, compared to operating in an RRC connected state. For example, serving and / or neighbor cell measurements may be required more frequently when in the RRC connected state than when in the RRC inactive state, for example, at least in line with a connected mode discontinuous reception (C-DRX) cycle of the wireless device.

[0102] The wireless device may manage cell reselection while in an RRC inactive state. The goal of the cell reselection process may include keeping the wireless device camped on a suitable cell, which may include a cell with sufficient signal strength, signal quality, and / or other characteristics so that the wireless device can establish / activate a connection and perform data transmission via the cell. Cell reselection may include either or both of intra-frequency cell reselection or inter-frequency cell reselection. As part of the cell reselection process while in such an RRC inactive state, the wireless device may perform cell measurements on the serving cell and / or neighboring cells. The manner in which these cell measurements are performed may potentially have a significant impact on the wireless device power consumption and the amount of time required to access continuous data transmission capabilities (e.g., by resuming operation in an RRC connected state). For example, if a synchronization signal block (SSB) is used to perform cell measurements, there may be a delay between an inactive state wake-up instance of the wireless device and the next SSB burst, and / or measurements may be performed over a relatively long period of time to allow receiver beam scanning over multiple SSB bursts. Furthermore, such SSB bursts may be performed at a different frequency and / or with a wider bandwidth than a designated inactive state wake-up instance of the wireless device. Alternatively, the cellular base station may provide paging instances aligned with the SBS in the time domain and / or frequency domain, for example, to facilitate reducing power consumption of the wireless device in the RRC inactive state.

[0103] Figure 7 700 for entering and resuming from an RRC inactive state according to aspects of the present disclosure. Aspects of the communication flow may be implemented by a wireless device, for example, in conjunction with one or more wireless devices and one or more portions of a core network (CN), such as in Figure 7 UE 702, gNB 704, previous serving gNB 706, and access and mobility function (AMF) 708 shown and described in the above figures, or more generally, any one of the computer circuits, systems, devices, elements, or components shown in the above figures may be implemented as needed. For example, the processor (and / or other hardware) of such a device may be configured to cause the device to perform any combination of the method elements shown and / or other method elements.

[0104] In the communication flow 700, a wireless device such as a UE 702 receives, for example, an RRC release message from a last serving gNB 706 (step 1). The RRC release message may include suspension configuration information for the UE 702 to enter an RRC inactive state. The suspension configuration information may include information for operating in an RRC inactive state and / or resuming a connection from an RRC inactive state, such as information about an RNA and security parameters for supporting encrypted resume messages, such as a UE identity and resumption security information. The RNA may include an area associated with a set of gNBs within which the UE is allowed to move without notifying the network.

[0105] In some cases, UE 702 may want to perform dedicated data transmission / reception that cannot be performed in the inactive state. To exit the inactive state, UE 702 may initiate an RRC recovery procedure by transmitting an RRC recovery request to a gNB, which in this example is gNB 704, which is a different gNB from the last serving gNB 706 (step 2). The RRC recovery request may include, for example, a UE identity and recovery security information. gNB 704 may then retrieve the context about UE 702 from the last serving gNB (step 3). After receiving the UE context (step 4), gNB 704 may send an RRC recovery message to UE 702 in response to the RRC recovery request (step 5). UE 702 may then transition to RRC connected state 710 and send an RRC recovery complete message to gNB 704 (step 6).

[0106] The gNB 704 then performs a UE handover from the previous serving gNB 706 by sending a Data Forwarding Address Indication to the previous serving gNB (step 7) and a Path Switch Request to the AMF 708 (step 8). The AMF 708 responds with a Path Switch Request Response (step 9) and the gNB sends a UE Context Release to the previous serving gNB 706 (step 10).

[0107] In certain wireless communication networks, encryption and / or integrity protection may be used to help provide data integrity and security. For example, in 5G NR, user data in a data radio bearer (DRB) block may be encrypted to provide data confidentiality and integrity protection for the user data. Additionally, RRC signaling in a signaling radio bearer (SRB) block is encrypted separately from user data to help provide signaling data confidentiality and wireless network integrity. The keys used for NAS-level security between the CN and the wireless device are therefore cryptographically separated from, for example, the AS keys used for RRC signaling. In some cases, a sequence number may be used as an input for encryption and / or integrity protection. For example, a next hop (NH) chain counter (NCC) sequence number may be used in conjunction with the NH parameter value to generate a key (K gNB ). The NH parameter value may be calculated by the AMF and the UE, rather than by the gNB, and the NCC sequence number may be provided by the AMF (as discussed in more detail below).

[0108] Figure 8 800 is a communication flow diagram illustrating a communication flow 800 for entering and recovering from an RRC inactive state in accordance with various aspects of the present disclosure. In the communication flow 800, the UE 802 receives an RRC release message from gNB1 804. In some cases, the RRC release message includes suspension configuration information and recovery security information including a first NCC sequence number. gNB1 804 may obtain an NCC and a corresponding NH parameter pair, for example from an AMF 810, before transmitting the RRC release message to the UE 802 (not shown). After receiving the RRC release message from gNB1 804, the UE 802 may enter an RRC inactive state. After determining that the UE needs to exit the RRC inactive state, the UE 802 may derive 812 a gNB key (K ) before transmitting an RRC recovery message to the target gNB (in this case, the target gNB2 806). gNB *) for use between UE 802 and the target gNB within the RNA of the UE. The RRC recovery message may use the derived gNB key (K gNB *) for encryption and / or integrity protection and may include security information such as an authentication token. gNB *) can be derived based on the target gNB information. For example, the target gNB information may include the physical cell ID (PCI), cell identity (Cell-ID) and cell radio network temporary identifier (C-RNTI) of the target gNB2 806.

[0109] After receiving the RRC recovery message, the target gNB 806 forwards the security information along with the target gNB 806 information to the source gNB (e.g., the gNB that previously communicated with the UE), here gNB1 804 (not shown). The source gNB1 804 then calculates the gNB key (K) based on the target gNB2 806 information and the NCC / NH parameter pair and other variables. gNB *). Then, the source gNB 1804 can calculate the gNB key (K gNB *) together with the gNB key (K gNB *) The associated NCC, encryption and / or integrity protection algorithm, security policy and other security information (not shown) are transmitted back to the target gNB2 806.

[0110] The target gNB2 806 may also send a path switch request to the AMF to initiate a handover of the UE 802 from the source gNB1 804 to the target gNB2 806. The AMF may respond with a path switch response, confirming the handover and providing a second NCC to the target gNB 806. 2 and the corresponding second NH 2 The target gNB2 806 may send an RRC recovery procedure message back to the UE 802 and use the calculated gNB key (K gNB *) communicates with UE 802 in the RRC connected state. After the communication, UE 802 may return to the RRC inactive state 814 after receiving a second RRC release message from target gNB2 806. The second RRC release message may also include suspension configuration information and a second NCC 2 and the corresponding second NH 2 Parameter pair to restore security information.

[0111] Similarly, to exit the RRC inactive state, UE 802 may derive a second gNB key (K gNB2 *) for use between UE 802 and a second target gNB3 808, which is also within the UE’s RNA. gNB Key (K gNB2 *) may be derived based on the target gNB information, which may include, for example, the PCI, cell ID, and C-RNTI of the target gNB3 806. Then, the UE 802 may use the second gNB key (K gNB2*) transmits a second RRC recovery message to the target gNB 3 808. The second RRC recovery message may also include security information, such as an authentication token. After receiving the second RRC recovery message, the target gNB3 forwards the security information along with the second target gNB3 808 information to the second source gNB, which is now gNB2 806 because the UE was previously switched from gNB1 to gNB2. The second source gNB2 806 then calculates the second gNB key (K) based on the second target gNB3 808 information and the NCC / NH parameter pair and other variables. gNB2 *). Then, the second source gNB2 806 may calculate the second gNB key (K gNB2 *) together with the second gNB key (K gNB2 *) associated NCC, encryption and / or integrity protection algorithm, security policy and other security information (not shown) are transmitted back to the second target gNB3 808. The second target gNB3 808 may also send a path switch request to the AMF to initiate a second handover of the UE 802 from the second source gNB2 806 to the second target gNB2 808. The AMF may respond with a path switch response, confirming the handover and providing the third NCC to the second target gNB 808 3 and the corresponding third NH 3 The second target gNB 808 may send an RRC recovery procedure message back to the UE 802 and use the second calculated gNB key (K gNB2 *) communicates with UE 802 in the RRC connected state. After the communication, UE 802 may return to the RRC inactive state after receiving a third RRC release message from the second target gNB1 808. The third RRC release message may also include suspension configuration information and a third NCC 3 and the corresponding third NH 3 Parameter pair to restore security information.

[0112] Fig. 9 900 is a diagram illustrating key derivation according to aspects of the present disclosure. As part of the initial establishment of AS keys, the UE and AMF may share the AMF key K AMF , both UE and AMF can derive the initial gNB key K from this AMF key gNB 902 and first NH 904 parameters. Initial gNB key K gNB 902 may be derived based in part on the NAS uplink count of the CN. The initial gNB key K gNB 902 may be associated with NCC=0, and the first NH 904 may be obtained from the initial gNB key K gNB 902 is derived and associated with NCC=1.

[0113] After this initial establishment, the first pair of gNB keys and NH parameters, i.e., the initial K gNB 902 and the first NH 904, will not be used to derive the gNB key. To derive the new gNB key, two techniques may be used. Vertical derivation of the new gNB key may be performed when there is an unused NCC / NH pair at the gNB. As described above, the gNB may obtain the NH / NCC pair from the AMF, and if the gNB has an unused NH / NCC pair, the gNB may use this unused NH 906 along with gNB information (such as PCI, Cell ID, C-RNTI, etc.) to vertically derive the new gNB key K gNB The gNB may also provide the NCC / NH pair to the UE to derive the new gNB key K gNB If no unused NCC / NH pair is available at the gNB, a horizontal derivation of new gNB keys can be performed. The horizontal derivation is based on the currently active gNB key (called K NG-RAN ) and gNB information. The gNB may signal the UE in the RRC Release message to use vertical derivation or horizontal derivation of the new gNB key. If the NCC included in the RRC Release message matches the currently used NCC value, then the new gNB key may be derived using horizontal derivation. If the NCC value included in the RRC Release message is a new NCC value, then the new gNB key may be derived using vertical derivation.

[0114] UE data transmission in RRC inactive state

[0115] In some cases, it may be desirable to allow the UE to transmit UL data while remaining in the RRC Inactive state without transitioning to the RRC Connected state. To transmit in the RRC Inactive state, the UE will not send an RRC Resume Request prior to transmitting UL data. A target gNB that is within the UE's configured RNA but is not the previous serving gNB will not be able to retrieve the NCC and calculated gNB keys from the original serving gNB prior to the UL, and it may be desirable to provide improved techniques for generating keys for transmissions while in the Inactive state.

[0116] Fig.10 is a communication flow diagram illustrating a technique 1000 for key generation for inactive state data transmission in accordance with aspects of the present disclosure. In some cases, key generation for inactive state data transmission may be performed using a single NCC value to generate keys for multiple gNBs. In these cases, multiple new gNB values ​​may be derived from a single NCC value included in an RRC release message. The NCC value may be a new NCC value or a currently used NCC value. There may be multiple options for deriving multiple new gNB keys from a single NCC value.

[0117] In the first option 1002, the last gNB key from the last serving cell can be reused for each data transmission in the RRC inactive state. In the first option 1002, the UE 802 receives the NCC value from the source gNB1 804 in the RRC release message and derives the gNB key (K) based on the received NCC value. gNB ), and stores the derived gNB key (K gNB ). Then, while in the RRC inactive state, UE 802 may transmit a key to the target gNB2 806 using the derived gNB key (K gNB ) encrypted and / or integrity protected data, the target gNB2 being different from the source gNB1 804 and within the UE's configured RNA. The UE 802 may also transmit data encrypted and / or integrity protected data using the same stored derived gNB key (K) to another target gNB3 808 within the UE's configured RNA. gNB ) encrypted and / or integrity protected data, the other target gNB3 is different from the source gNB1 804 and the target gNB2 806 and is within the configured RNA of the UE. It is worth noting that the same gNB key (K gNB ) to encrypt and / or integrity protect data sent to multiple gNBs.

[0118] As described above, the source gNB 804 receives the NCC / NH pair from the AMF to derive the gNB key (K gNB ). This NCC / NH pair is provided only from the AMF to the source gNB 804. For each option, on the network side, data security processing may be provided by the source gNB, or data security may be performed by each accessed gNB. In the first option 1002, if data security is handled by the source gNB1 804, when data is transmitted by the UE 802 in an inactive state to a target gNB (such as target gNB2 806 or target gNB3 808), the target gNB forwards the security information of the data transmitted together with the target gNB information to the source gNB1 804. The source gNB1 804 then forwards the derived gNB key (K gNB ) is returned to the target gNB. If data security is handled by each accessed gNB, the source gNB1 804, after transmitting an RRC release message including RNA information to the UE 802, may broadcast UE context information including the derived gNB key to other gNBs in the configured RNA of the UE 802. Then, when the UE 802 transmits data to, for example, the target gNB3 808 in an inactive state, the target gNB3 808 will use the derived gNB key (K gNB ) to decrypt the transmitted AS data.

[0119] In some cases, the second option 1004 may be used to derive a new gNB key (K) for each data transmission in the RRC inactive state. gNB *). In the second option 1004, the UE 802 also receives the NCC value from the source gNB1 804. For each data transmission in the RRC inactive state, the UE derives a new gNB key (K gNB *). Horizontal export can be based on the currently active gNB key (K NG-RAN ), based on the received NCC value, and the gNB information of the target gNB. For example, UE 802 receives the NCC value from source gNB1 804 in an RRC Release message, and derives the gNB key (K) based on the received NCC value. NG-RAN ). When UE 802 wants to transmit data in an inactive state, UE 802 selects a target gNB (such as target gNB2 806) and obtains gNB information (such as PCI, cell ID, C-RNTI, etc.) broadcast by target gNB2 806. Then, UE 802 determines the gNB information based on the gNB information and the derived gNB key (K NG-RAN ) horizontally derives the new gNB key (K gNB2 *). For each additional transmission, the UE horizontally derives another new gNB key (K gNB2 *). If UE 802 wants to transmit to another target gNB such as target gNB3 808 in the inactive state, UE 802 horizontally derives a new gNB key (K) of target gNB3 808 based on the gNB information of target gNB3 808. gNB3 *).

[0120] For the second option 1004, on the network side, data security processing may be provided again by the source gNB, or data security may be performed by each accessed gNB in ​​a manner similar to that discussed above with respect to the first option 1002.

[0121] In some cases, the third option 1006 may be used to derive a new gNB key (K gNB ) is used for data transmission in RRC inactive state. The new gNB key (K gNB ) can be used for all data transmissions in the RRC inactive state. For example, the UE 802 receives the NCC value from the source gNB1 804 in the RRC release message. In some cases, the UE 802 can vertically derive a new gNB key (K) based on the NCC value and the gNB information of the target gNB2 806. gNB). In other cases, UE 802 may determine an initial target gNB (such as target gNB2 806) to which to transmit data in the RRC inactive state, and obtain gNB information broadcast by target gNB2 806. In this example, the initial target gNB may be the first gNB to which UE 802 transmits in the inactive state. UE 802 may then vertically derive a new gNB key (K) based on the NCC value and the obtained gNB information of target gNB2 806. gNB ). The UE 802 may then reuse the derived new gNB key (K) for each subsequent data transmission. gNB Continuing with the previous example, UE 802 may then use the new gNB key (K gNB ) to transmit data to another target gNB, such as target gNB3 808, in the RRC inactive state.

[0122] For the third option 1006, on the network side, data security processing may be provided again by the source gNB, or data security may be performed by each accessed gNB in ​​a manner similar to that discussed above with respect to the first option 1002. In addition, data security may be performed by the source gNB and the initial target gNB. For example, the initial target gNB, such as target gNB2 806, may forward security information for the data transmitted by the UE 802 to the source gNB1 804 along with the initial target gNB information. The source gNB1 804 then forwards the derived gNB key (K gNB ) is returned to the initial target gNB. The source gNB 806 or the initial target gNB2 may then broadcast the derived gNB key (K gNB ).

[0123] In some cases, the fourth option 1008 may be used to derive a new gNB key (K gNB ) is used for each data transmission in the RRC inactive state. For example, the serving gNB1 804 receives the NCC value and the NH parameter pair from the AMF. The UE 802 receives the NCC value from the source gNB1 804 in the RRC release message. When the UE 802 wants to transmit data in the inactive state, the UE 802 selects a target gNB (such as the target gNB2 806) and obtains the gNB information broadcast by the target gNB2 806. Then, the UE 802 can vertically derive a new gNB key (K) based on the NCC value and the obtained gNB information of the target gNB2 806. gNB2 *). UE 802 may then use the new gNB key (K gNB2*) transmits data to the target gNB2 806. The target gNB2 806 may then forward the security information and gNB information from the received data to the source gNB1804, which may then forward the derived gNB key (K gNB2 ) is returned to the target gNB2 806. In other cases, data security may be performed by each accessed gNB in ​​a manner similar to that discussed above with respect to the first option 1002, where the source gNB1 804 may broadcast the NCC value and NH parameter pair to other gNBs in the configured RNA of the UE 802. If the UE 802 wants to transmit data to another target gNB, such as the target gNB3 808, in an inactive state, the UE 802 obtains the gNB information of the target gNB3 808, vertically derives a new gNB key (K) based on the previously obtained NCC value and the obtained gNB information of the target gNB3 808. gNB3 *), and transmits the data to the target gNB3 808. The target gNB3 808 can then obtain the derived gNB key (K gNB3 ), or derive the gNB key (K) from the broadcasted NCC value and NH parameters in a manner similar to that described above with respect to target gNB2 806 gNB3 ).

[0124] In some cases, the fifth option 1010 may be used to derive a new gNB key (K) for data transmission in the RRC inactive state vertically and horizontally. gNB In the fifth option 1010, a new gNB key (K gNB *), where the new gNB key (K gNB *), and derives a new gNB key horizontally for subsequent data transmission. For example, the serving gNB1 804 receives the NCC value and the NH parameter pair from the AMF. The UE 802 receives the NCC value from the source gNB1 804 in the RRC release message. When the UE 802 wants to transmit data in an inactive state, the UE 802 selects a target gNB (such as the target gNB2 806) and obtains the gNB information broadcast by the target gNB 806. Then, the UE 802 may derive a new gNB key (K) vertically based on the NCC value and the obtained gNB information of the target gNB2 806. gNB2*). If UE 802 wants to transmit more data in the inactive state, UE 802 may select another target gNB, such as target gNB3 808, obtain gNB information from target gNB3 808, and horizontally derive a new gNB key (K) based on the previous gNB key, NCC value, and gNB information from target gNB3 808. gNB3 *).

[0125] For the fifth option 1010, on the network side, data security processing may be provided again by the source gNB, or data security may be performed by each accessed gNB in ​​a manner similar to that discussed above with respect to the first option 1002 and the fourth option 1008.

[0126] Fig.11 1 is a communication flow diagram illustrating a communication flow 1100 for entering and resuming from an RRC inactive state according to aspects of the present disclosure. The communication flow 1100 illustrates an example corresponding to the fourth option 1008 and in which data security is handled by each accessed gNB, such as in conjunction with Fig.10 As discussed. In this example, the serving gNB1 1104 receives a first NCC value and a NH parameter pair from an AMF (not shown). Then, the serving gNB1 1104 transmits an RRC release message to the UE 1102, the RRC release message having the first NCC value and the suspension configuration information including RNA information. Then, the serving gNB1 1104 sends UE context information including the received first NCC value and the NH parameter pair to other gNBs in the RNA of the UE 1102, such as the target gNB2 1106 and the target gNB3 1109. Then, the other gNBs may vertically derive a new gNB key (K ) based on the received first NCC value, the NH parameter, and their gNB information. gNB *). When UE 1102 wants to transmit data in an inactive state, UE 1102 selects a target gNB (such as target gNB2 1106) and obtains gNB information broadcast by target gNB2 1106. Then, UE 1102 may vertically derive a new gNB key (K) based on the NCC value and the obtained gNB information of target gNB2 1106. gNB2 *). UE 1102 may then use the new gNB key (K gNB2 *) transmits data to the target gNB2 1106. The target gNB2 1106 derives 1112 a new gNB key (K gNB2*) to access the AS data received from UE 1102. Similarly, when UE 1102 wants to transmit data to target gNB3 1108 in the active state, UE 1108 may vertically derive another new gNB key (K *) based on the NCC value and the gNB information of target gNB8 1108 obtained. gNB3 *). The target gNB8 1108 derives 1114 a new gNB key (K gNB3 *) to access AS data received from UE 1102. In some cases, UE 1102 may want to transition to a different connection state on target gNB2 1106 than source gNB1 1104. In this case, UE 1102 may adopt a similar approach to the above combined Figure 7 The UE 1102 may also use a method similar to the above combined method. Figure 7 The described method returns to the inactive state.

[0127] Fig.12 1 is a communication flow diagram illustrating a communication flow 1200 for entering and resuming from an RRC inactive state in accordance with aspects of the present disclosure. The communication flow 1200 illustrates an example corresponding to the fourth option 1008 and in which data security is handled by the source gNB, as in conjunction with Fig.10 As discussed. In this example, the serving gNB1 1104 receives a first NCC value and a NH parameter pair from an AMF (not shown). Then, the serving gNB1 1104 transmits an RRC release message to the UE 1102, the RRC release message having the first NCC value and the suspension configuration information including RNA information. After the data transmitted by the UE 1102 in the inactive state is received by the target gNB (such as target gNB2 1106), the target gNB forwards the security information together with the target gNB information to the source gNB1 1104. Then, the source gNB1 1104 vertically derives 1202 a new gNB key (K ) based on the target gNB information, the first NCC value, and the NH parameter. gNB2 *), and the derived new gNB key (K gNB *) is transmitted to the target gNB2 1106. Similarly, when another target gNB3 1108 of the RNA of the UE requests UE context information, the source gNB1 1104 may vertically derive 1204 another new gNB key (K gNB2 *). In some cases, UE 1102 may want to transition to a different connection state on target gNB2 1106 than source gNB1 1104. In this case, UE 1102 may adopt a similar approach to the above combined Figure 7The UE 1102 may also use a method similar to the above combined method. Figure 7 The described method returns to the inactive state.

[0128] Fig.13 1 is a communication flow diagram illustrating a communication flow 1300 for entering and resuming from an RRC inactive state according to aspects of the present disclosure. The communication flow 1300 illustrates an example corresponding to the fifth option 1010 and in which data security is handled by the source gNB, as in conjunction with Fig.10 as discussed. In this example, the serving gNB1 1104 receives a first NCC value and an NH parameter pair from an AMF (not shown). Then, the serving gNB1 1104 transmits an RRC release message to the UE 1102, the RRC release message having the first NCC value and suspension configuration information including RNA information. After receiving the RRC release message, the UE transitions to an RRC inactive state. When the UE 1102 wants to transmit data in the RRC inactive state, the UE 1102 selects a target gNB (such as a target gNB2 1106) and obtains the gNB information broadcast by the target gNB2 1106. Then, the UE 1102 may vertically derive 1302 a new gNB key (K gNB2 *). UE 1102 may then use the new gNB key (K gNB2 *) transmits data to the target gNB2 1106. After the data transmitted by the UE 1102 in the inactive state is received by the target gNB2 1106, the target gNB2 1106 forwards the security information together with the target gNB information to the source gNB1 1104. Then, the source gNB1 1104 vertically derives 1212 a new gNB key (K gNB2 *), and the derived new gNB key (K gNB2 *) is transmitted to target gNB2 1106. When UE 1102 transmits data to another target gNB (such as target gNB2 1108) in the RRC inactive state, after the initial data transmission, UE 1102 obtains gNB information broadcast by target gNB3 1108 and horizontally derives 1304 a new gNB key (K) based on the previous gNB key, the first NCC value and the gNB information from target gNB3 1108. gNB3*). After the data transmitted by UE 1102 in the inactive state is received by target gNB3 1103, target gNB3 1108 forwards the security information together with the target gNB information to source gNB1 1104. Then, source gNB1 1104 horizontally derives a new gNB key (K) based on the target gNB information, the first NCC value, and the NH parameter. gNB3 *), and the derived new gNB key (K gNB3 *) to target gNB2 1106. In some cases, UE 1102 may want to transition to a different connection state on target gNB2 1106 than source gNB1 1104. In this case, UE 1102 may adopt a similar approach to the above combined Figure 7 The described approach uses the gNB key (K gNB2 *) to perform the RRC recovery process. UE 1102 may also use a method similar to the above combined Figure 7 The described method returns to the inactive state.

[0129] In some cases, key generation for inactive state data transmission may be performed using a set of consecutive integer NCC values ​​provided by the source gNB in ​​an RRC release message for generating keys for multiple gNBs. The set of consecutive NCC values ​​may be described by a starting NCC value and an integer n indicating how many consecutive NCC values ​​are in the set. In these cases, multiple new gNB values ​​may be derived from the set of NCC values ​​included in the RRC release message. For example, the source gNB may receive a path switch process response message including a set of NCC values ​​and NH parameters before transmitting an RRC release to the UE. The set may include any integer n of consecutive NCC values, where n>1. The source gNB may then transmit an RRC release message with suspend configuration information including the set of NCC values. After the UE enters the RCC inactive state, the UE may want to transmit data in the RCC inactive state. The UE may then vertically derive a new gNB key for the first transmission based on a first NCC value from the set of NCC values. The UE may continue to vertically derive new gNB keys for each data transmission in the RCC Inactive state based on successive NCC values ​​from the set of NCC values. After n data transmissions, the UE will have used all NCC values ​​from the set of NCC values.

[0130] On the network side, data security processing can be provided by multiple alternative processing procedures. In the first alternative network side data security processing procedure, data processing security can be performed by the source gNB. For example, in this first alternative, when data is transmitted by the UE to the target gNB in ​​an inactive state, the target gNB forwards the security information of the transmitted data together with the target gNB information to the source gNB. The source gNB then forwards the gNB key (K gNB ) is returned to the target gNB. In the second alternative network-side data security processing process, data processing security can be performed by each accessed gNB based on the NCC / NH pair broadcasted by the source gNB. For example, in this second alternative, after the source gNB transmits an RRC release message including RNA information to the UE, it can broadcast UE context information including the set of NCC values ​​and NH parameters to other gNBs in the configured RNA of UE 802. Then, when UE 802 transmits data to the target gNB in ​​an inactive state, the target gNB can derive the gNB key (K gNB ). In the third alternative network-side data security processing process, data processing security can be performed by each accessed gNB based on UE context data retrieved from the source gNB. For example, in this third alternative, when data is transmitted by the UE to the target gNB in ​​an inactive state, the target gNB forwards the security information of the transmitted data together with the target gNB information to the source gNB. The source gNB then returns the UE context data including the NCC value and the NH parameter to the target gNB. The target gNB can then derive the gNB key (K gNB ).

[0131] In addition, there may be multiple options for processing subsequent data transmission after all NCC values ​​from the set of NCC values ​​have been used. Each of the multiple options may be combined with any of the alternative network-side data security processing procedures described in detail above.

[0132] In the first option, the last gNB key (N gNBn *) can be used together with gNB information from the target gNB to horizontally derive subsequent gNB keys (N gNBn+m *). For example, after all n NCC values ​​in the set of NCC values ​​have been used, the UE may use a key based on the currently active (e.g., last) gNB key (N NCC value) derived from the set of NCC values ​​to obtain the NCC key. gNBn *) and horizontal export of gNB information of the target gNB to derive the new gNB key (N gNBn+1*). For each additional data transmission in the RRC inactive state, additional new gNB keys may be generated using horizontal derivation. On the network side, data security may be performed using any of the alternative network-side data security processes described in detail above.

[0133] In the second option, the last gNB key (N gNBn *) may be reused for subsequent data transmission in the RRC inactive state. For example, after all n NCC values ​​in the set of NCC values ​​have been used, the UE may continue to use the currently active (e.g., last) gNB key (N NCC) derived from the set of NCC values. gNBn *) For additional data transmission in the RRC inactive state. On the network side, data security may be performed using any of the alternative network side data security processing procedures described in detail above.

[0134] In a third option, the RRC recovery procedure may be triggered after an NCC value in the set of NCC values ​​has been used. For example, after all n NCC values ​​in the set of NCC values ​​have been used, the UE may send an RRC recovery procedure to the target gNB. The NCC value used for the RRC recovery procedure may be the last NCC value in the set of NCC values, or there may be a dedicated NCC value for the RRC recovery procedure provided with the set of NCC values. The target gNB may then transmit a path switch request to the AMF. The AMF may then respond with a path switch response message including another set of NCC values ​​and an NH parameter. In some cases, the path switch request procedure may also hand over the UE from the previous source gNB to the target gNB. The target gNB may then transmit the other set of NCC values ​​to the UE in an RRC release message.

[0135] In a fourth option, after the NCC values ​​in the set of NCC values ​​have been used, a method similar to combining Fig.10 The method for deriving additional gNB keys from a single NCC value as described in the third option 1006 of the present invention is to derive additional new gNB keys (N gNBn *). For example, after all NCC values ​​in the set of NCC values ​​have been used, a gNB key (N gNBn *), NCC value and gNB information to vertically derive the new gNB key (K gNB The UE may then reuse the derived new gNB key (K) for each subsequent data transmission. gNB ).

[0136] In a fifth option, after the NCC values ​​in the set of NCC values ​​have been used, a method similar to combining Fig.10The fourth option 1008 of the present invention is used to derive an additional new gNB key (N) from a single NCC value. gNBn *). For example, after all NCC values ​​in the set of NCC values ​​have been used, a gNB key (N gNBn *), NCC value and gNB information of the target gNB to vertically derive the new gNB key (K gNB2 *). For subsequent transactions, the currently active gNB key (e.g., K gNB2 *), NCC value and gNB information of the target gNB are used to vertically derive the additional new gNB key (K gNBN *).

[0137] In a sixth option, after the NCC values ​​in the set of NCC values ​​have been used, a method similar to combining Fig.10 The method for deriving additional gNB keys from a single NCC value described in the sixth option 1010 is to derive additional new gNB keys (N gNBn *). For example, after all NCC values ​​in the set of NCC values ​​have been used, a gNB key (N gNBn *), NCC value and gNB information of the target gNB to vertically derive the new gNB key (K gNB2 *). For subsequent data transmission, the currently active gNB key (e.g., gNB key (K gNB2 *)) to horizontally derive additional new gNB keys (K gNBN *).

[0138] Fig.1414 is a communication flow diagram illustrating an exemplary technique 1400 for key generation for inactive state data transmission according to various aspects of the present disclosure. Technique 1400 illustrates an example of the third option described above, which is used to process subsequent data transmission after using all NCC values ​​from the group of NCC values ​​in conjunction with the first alternative network-side data security processing process. In this example, the source gNB1 1104 may receive a path switching process response message including a set of NCC values ​​and NH parameters from the AMF 1110 before transmitting an RRC release to the UE 1102. In this example, the group includes two consecutive NCC values ​​and NH parameters (e.g., n=2). The source gNB1 1104 may then transmit an RRC release message based on the group of NCC values ​​received from the AMF 1110, the RRC release message having a suspension configuration information including a set of NCC values. After the UE 1102 enters the RCC inactive state, the UE 1102 may want to transmit data in the RCC inactive state. The UE 1102 may then vertically derive 1402 a first gNB key (K ) based on a first NCC value from the set of NCC values ​​and gNB information of the first target gNB2 1106. gNB2 ) for the first transmission to the first target gNB2 1106, and then forwards the security information of the first transmission together with the gNB information to the source gNB1 1104. The source gNB1 1104 then vertically derives the first gNB key (K) based on the NCC value and NH parameter received from the AMF and the gNB information received from the first target gNB2 1106. gNB2 ), and will include the first gNB key (K gNB2 ) is transmitted back to the first target gNB2 1106. As the source gNB1 1102 derives each gNB key, the source gNB1 1102 may track the NCC value usage and know which NCC value is currently active. When the UE 1102 wants to transmit additional data to, for example, the second target gNB3 1108 in the RRC inactive state, the UE 1102 may vertically derive 1404 the second gNB key (K) based on the next (e.g., last) NCC value from the set of NCC values ​​and the gNB information of the second target gNB3 1108. gNB3 ) for a second transmission to the second target gNB3 1108. The second target gNB3 1108 may obtain the first gNB key (K) in a manner similar to that of the first target gNB2 1106. gNB2 ) to obtain the second gNB key (K gNB3 ).

[0139] After the second transmission, the UE 1102 may perform an RRC recovery procedure with, for example, the first target gNB2 1106, and transition to RRC connected mode. In this example, the UE 1102 may transmit an RRC recovery message using a dedicated NCC value included in the set of NCC values. In other cases, the last NCC value in the set of NCC values ​​may be used to transmit the RRC recovery message. In some cases, the RRC recovery message may include an indication that an additional NCC value is required for protecting additional data transmission in RRC inactive mode. The first target gNB2 1106 may then transmit a UE context acquisition message to the source gNB1 1104. The source gNB1 1104 may then vertically derive a first gNB key (K ) based on the NH value received from the AMF and the gNB information received from the first target gNB2 1106. gNB2 ). The first target gNB2 1106 may then transmit a path switch request to the AMF 1110. The AMF 1110 may then respond with a path switch response message including another set of NCC values ​​and NH parameters. In some cases, the path switch request process may also hand over the UE 1102 from the previous source gNB1 1104 to the first target gNB2 1106. The first target gNB2 1106 may then transmit another set of NCC values ​​to the UE 1102 in an RRC release message.

[0140] Fig.15 is a communication flow diagram illustrating an exemplary technique 1500 for key generation for inactive state data transmission according to various aspects of the present disclosure. Technique 1500 illustrates an example of the third option described above, which is used to process subsequent data transmission after using all NCC values ​​from the group of NCC values ​​in conjunction with a second alternative network-side data security processing process. In this example, the source gNB1 1104 may receive a path switching process response message including a set of NCC values ​​and NH parameters from the AMF 1110 before transmitting an RRC release to the UE 1102. In this example, the group includes two NCC values ​​(e.g., n=2). The source gNB11104 may then transmit an RRC release message based on the NCC value received from the AMF 1110, the RRC release message having a suspension configuration information including a set of NCC values. The source gNB1 1104 may broadcast UE context information including the set of NCC values ​​and NH parameters to other gNBs (e.g., gNB21106 and gNB3 1108) in the configured RNA of UE 1102.

[0141] After the UE 1102 enters the RCC inactive state, the UE 1102 may want to transmit data in the RCC inactive state. The UE 1102 may then vertically derive 1502 a first gNB key (K ) based on a first NCC value from the set of NCC values ​​and gNB information of the first target gNB2 1106. gNB2 ) for the first transmission to the first target gNB2 1106. After receiving the first transmission, the first target gNB2 1106 may also vertically derive the first gNB key (K) based on the set of NCC values ​​and NH parameters broadcast by the source gNB1 1104. gNB2 ). The first target gNB2 1106 also broadcasts a UE data transmission number indicating which NCC has been used by UE 1102 (e.g., incrementing a counter) to other gNBs in the configured RNA of UE 1102 (e.g., gNB1 1104 and gNB3 1108). When UE 1102 wants to transmit additional data to, for example, a second target gNB3 1108 in the RRC inactive state, UE 1102 may vertically derive 1504 a second gNB key (K) based on the next (e.g., last) NCC value from the set of NCC values ​​and the gNB information of the second target gNB3 1108. gNB3 ) for a second transmission to the second target gNB3 1108. The second target gNB3 1108 may similarly derive a second gNB key (K) based on the set of NCC values ​​broadcast by the source gNB1 1104. gNB3 ). The second target gNB3 1108 also broadcasts another UE data transmission number indicating which NCC value has been used by UE 1102 to other gNBs in the configured RNA of UE 1102 (e.g., gNB11104 and gNB2 1106).

[0142] After the second transmission, UE 1102 may employ a method similar to that described above with respect to Fig.14 The RRC recovery process is performed in the manner described. For example, UE 1102 may use a dedicated NCC value included in the group of NCC values ​​to transmit an RRC recovery message. In other cases, the last NCC value in the group of NCC values ​​may be used to transmit the RRC recovery message. In some cases, the RRC recovery message may include an indication that an additional NCC value is required to protect additional data transmission in RRC inactive mode. The first target gNB2 1106 may then transmit a UE context acquisition message to the source gNB1 1104. The source gNB1 1104 may then vertically derive a first gNB key (K ) based on the NH parameters received from the AMF and the gNB information received from the first target gNB2 1106. gNB2). The first target gNB2 1106 may then transmit a path switch request to the AMF 1110. The AMF 1110 may then respond with a path switch response message including another set of NCC values ​​and NH parameters. In some cases, the path switch request process may also hand over the UE 1102 from the previous source gNB11104 to the first target gNB2 1106. The first target gNB2 1106 may then transmit another set of NCC values ​​to the UE 1102 in an RRC release message.

[0143] Fig.16 is a communication flow diagram illustrating an exemplary technique 1600 for key generation for inactive state data transmission according to various aspects of the present disclosure. Technique 1600 illustrates an example of the third option described above, which is used to process subsequent data transmission after using all NCC values ​​from the group of NCC values ​​in conjunction with a third alternative network-side data security processing process. In this example, the source gNB1 1104 may receive a path switching process response message including a set of NCC values ​​and NH parameters from the AMF 1110 before transmitting an RRC release to the UE 1102. In this example, the group includes two NCC values ​​(e.g., n=2). The source gNB11104 may then transmit an RRC release message based on the NCC value received from the AMF 1110, the RRC release message having a suspension configuration information including a set of two NCC values. After the UE 1102 enters the RCC inactive state, the UE 1102 may want to transmit data in the RCC inactive state. The UE 1102 may then vertically derive 1602 a first gNB key (K ) based on the first NCC value from the set of NCC values ​​and the gNB information of the first target gNB2 1106. gNB2 ) for the first transmission to the first target gNB2 1106. After receiving the first transmission, the first target gNB2 1106 sends a UE Context Acquisition message to the source gNB1 1104, and the source gNB1 1104 responds by returning a UE Context Response message including the next NCC value and the NH parameter. Since the UE context is accessed by the source gNB1 1104 each time another gNB receives a data transmission from UE 1102, the source gNB1 1104 can track the NCC value usage and know which NCC value is currently active. The first target gNB2 1106 can then vertically derive the first gNB key (K) based on the next NCC value, the NH parameter, and the gNB information. gNB2). When UE 1102 wants to transmit additional data to, for example, a second target gNB3 1108 in the RRC inactive state, UE 1102 may vertically derive 1604 a second gNB key (K) based on the last NCC value from the set of NCC values ​​and the gNB information of the second target gNB3 1108. gNB3 ) for a second transmission to the second target gNB3 1108. The second target gNB3 1108 also transmits a UE Context Acquisition message to the source gNB1 1104, and the source gNB1 1104 responds by returning a UE Context Response message including the next NCC value and the NH parameter. The second target gNB3 1108 may then vertically derive the first gNB key (K) based on the next NCC value, the NH parameter, and the gNB information. gNB2 ). After the second transmission, UE 1102 may adopt a method similar to that described above with respect to Fig.14 The RRC recovery process is performed in the manner described.

[0144] Fig.171 is a communication flow diagram illustrating an exemplary technique 1700 for key generation for inactive state data transmission according to various aspects of the present disclosure. Technique 1700 illustrates an example of using a list of non-continuous NCC values. Technique 1700 is a variant using a set of consecutive integer NCC values, and all options and alternative network-side data security processing procedures described with respect to the set of consecutive integer NCC values ​​may also be applied to variants using a list of non-continuous NCC values. For example, technique 1700 illustrates the operation of a non-continuous list of NCC values ​​used in conjunction with a first alternative network-side data security processing procedure, and omits details about processing subsequent data transmission after all NCC values ​​from the list of NCC values ​​have been used. It will be understood that all options for processing subsequent data transmission after all NCC values ​​from the list of NCC values ​​and other alternative network-side data security processing may also be combined with a non-continuous list of NCC values. Instead of using a starting NCC value and an integer to describe a set of consecutive NCC values, the set of NCC values ​​may be a non-continuous list of NCC value and NH parameter pairs. The operation of deriving gNB keys using a list of NCC values ​​is substantially similar on both the UE side and the network side, as described above with respect to the set of consecutive NCC values. Compared to the operation utilizing the set of consecutive NCC values, the operation utilizing a non-continuous list of NCC values ​​will operate utilizing a specific NCC value rather than a continuously increasing starting NCC value. For example, in technique 1700, the source gNB1 1104 may receive a path switching process response message including a list of NCC value and NH parameter pairs (e.g., ((NCC1, NH1), (NCC3, NH3)…)) from the AMF1110 before transmitting an RRC release to the UE 1102. The source gNB1 1104 may then transmit an RRC release message to the UE 1102 having the suspension configuration information including the list of NCC values. After the UE 1102 enters the RCC inactive state, the UE 1102 may want to transmit data in the RCC inactive state. The UE 1102 may then vertically derive 1702 a first gNB key (K ) based on a first NCC value (NCC1) from the set of NCC values ​​and gNB information of a first target gNB2 1106. gNB2 ) for the first transmission to the first target gNB2 1106. After receiving the first transmission, the first target gNB2 1106 may then forward the security information of the first transmission together with the gNB information to the source gNB1 1104. The source gNB1 1104 then vertically derives the first gNB key (K) based on the NCC value and NH parameter received from the AMF and the gNB information received from the first target gNB2 1106. gNB2 ), and will include the first gNB key (K gNB2) is transmitted back to the first target gNB2 1106. When the UE 1102 wants to transmit additional data to, for example, the second target gNB3 1108 in the RRC inactive state, the UE 1102 may vertically derive 1704 a second gNB key (K) based on the next (e.g., last) NCC value (e.g., NCC3) from the NCC value list and the gNB information of the second target gNB3 1108. gNB3 ) for a second transmission to the second target gNB3 1108. The second target gNB3 1108 may obtain the first gNB key (K) in a manner similar to that of the first target gNB2 1106. gNB2 ) to obtain the second gNB key (K gNB3 ).

[0145] Fig.18 is a communication flow diagram illustrating an exemplary technique 1800 for key generation for inactive state data transmission according to aspects of the present disclosure. Technique 1800 is a variant of other exemplary techniques using a set of consecutive integer NCC values, whereby the UE includes an indication of which NCC value is currently active, such as by using an incrementing counter. It should be understood that all options and alternative network-side data security processing procedures described with respect to the set of consecutive integer NCC values ​​may also be applied to technique 1800. For example, as shown, technique 1800 applies a second alternative network-side data security processing procedure and omits details about processing subsequent data transmission after all NCC values ​​from the list of NCC values ​​have been used. It will be understood that all options for processing subsequent data transmission after all NCC values ​​from the list of NCC values ​​and other alternative network-side data security processing may also be combined with a non-continuous list of NCC values. In this example, the source gNB1 1104 may receive a path switch process response message including a set of NCC values ​​and NH parameters from the AMF1110 before transmitting an RRC release to the UE 1102. In this example, the set includes two NCC values ​​(e.g., n=2). The source gNB1 1104 may then transmit an RRC release message with suspension configuration information including a set of NCC values ​​based on the NCC values ​​received from the AMF 1110. The source gNB1 1104 may broadcast UE context information including the set of NCC values ​​and NH parameters to other gNBs in the configured RNA of the UE 1102 (e.g., gNB2 1106 and gNB3 1108).

[0146] After the UE 1102 enters the RCC inactive state, the UE 1102 may want to transmit data in the RCC inactive state. The UE 1102 may then vertically derive 1802 a first gNB key (K ) based on a first NCC value from the set of NCC values ​​and gNB information of the first target gNB2 1106.gNB2 ) for a first transmission to the first target gNB2 1106. The first transmission includes a first indication of the current NCC access number. After receiving the first transmission, the first target gNB2 1106 may also vertically derive a first gNB key (K) based on the set of NCC values ​​broadcasted by the source gNB1 1104, the indication of the current NCC access number, and the NH parameter. gNB2 ). When UE 1102 wants to transmit additional data to, for example, a second target gNB3 1108 in the RRC inactive state, UE 1102 may vertically derive 1804 a second gNB key (K) based on the next (e.g., last) NCC value from the set of NCC values ​​and the gNB information of the second target gNB3 1108. gNB3 ) for a second transmission to a second target gNB3 1108. The second transmission includes a second indication of the current NCC access number, the second indication being different from the first indication (e.g., incremented). The second target gNB3 1108 may similarly derive a second gNB key (K) based on the set of NCC values ​​broadcasted by the source gNB1 1104 and the second indication of the current NCC access number. gNB3 ).

[0147] Fig.191 is a communication flow diagram illustrating an exemplary technique 1900 for key generation for inactive state data transmission according to various aspects of the present disclosure. Technique 1900 is an exemplary variation of using a non-contiguous list of NCC values, whereby the UE includes an indication of which NCC value is currently active, such as by using an incrementing counter. It should be understood that all options and alternative network-side data security processing procedures described with respect to the set of consecutive integer NCC values ​​may also be applied to technique 1900. For example, as shown, technique 1900 applies a second alternative network-side data security processing procedure and omits details about processing subsequent data transmission after all NCC values ​​from the list of NCC values ​​have been used. It will be understood that all options for processing subsequent data transmission after all NCC values ​​from the list of NCC values ​​and other alternative network-side data security processing may also be combined with a non-contiguous list of NCC values. For example, in technique 1900, source gNB1 1104 may receive a path switch process response message including a list of NCC value and NH parameter pairs (e.g., ((NCC1, NH1), (NCC3, NH3) ...)) from AMF 1110 before transmitting an RRC release to UE 1102. Source gNB1 1104 may then transmit an RRC release message to UE 1102, the RRC release message having suspension configuration information including the NCC value list. Source gNB1 1104 may broadcast UE context information including the NCC value list and NH parameters to other gNBs (e.g., gNB2 1106 and gNB3 1108) in the configured RNA of UE 1102.

[0148] After the UE 1102 enters the RCC inactive state, the UE 1102 may want to transmit data in the RCC inactive state. The UE 1102 may then vertically derive 1902 a first gNB key (K ) based on a first NCC value (NCC1) from the set of NCC values ​​and gNB information of the first target gNB2 1106. gNB2 ) for a first transmission to the first target gNB2 1106. The first transmission includes a first indication of the current NCC access number. After receiving the first transmission, the first target gNB2 1106 may also vertically derive a first gNB key (K) based on the NCC value list broadcasted by the source gNB1 1104, the indication of the current NCC access number, and the NH parameter. gNB2 ). When UE 1102 wants to transmit additional data to, for example, the second target gNB3 1108 in the RRC inactive state, UE 1102 may vertically derive 1904 the second gNB key (K) based on the next (e.g., last) NCC value from the NCC value list and the gNB information of the second target gNB3 1108. gNB3) for a second transmission to a second target gNB3 1108. The second transmission includes a second indication of the current NCC access number, the second indication being different from the first indication (e.g., incremented). The second target gNB3 1108 may similarly derive a second gNB key (K) based on the NCC value list broadcasted by the source gNB1 1104 and the second indication of the current NCC access number. gNB3 ).

[0149] In some cases, key generation for inactive state data transmission may be performed using a set of NCC values ​​and NH parameters, where the NCC value for the next transmission in the RRC inactive state is provided to the UE. Fig. 20 is a communication flow diagram illustrating an exemplary technique 2000 for key generation for inactive state data transmission in accordance with aspects of the present disclosure. Technique 2000 illustrates an example of providing an NCC value for a next transmission in an RRC inactive state to a UE. In this example, the source gNB1 1104 may receive a path switch process response message including a set of NCC values ​​and NH parameters before transmitting an RRC release to the UE. In a first option, the set may include multiple NCC values ​​and NH parameters. The multiple NCC values ​​and NH parameters may be consecutive NCC values ​​described by a starting NCC value and an integer n indicating how many consecutive NCC values ​​there are in the set, or the set may be a list of multiple non-consecutive NCC values. In a second option, the set may include a single NCC value and NH parameter pair. In the second option, each subsequent gNB that receives data transmission from the UE 1102 while in the RRC inactive state requests a new NCC value (NCC1) and NH parameter pair from the CN (such as AMF1110) for the next transmission in the RRC inactive state. In either option, source gNB1 1104 may then transmit an RRC release message to UE 1102 with the suspension configuration information including the first NCC value (NCC1) and RNA information. UE 1102 may enter an RRC inactive state. UE 1102 may want to transmit a first transmission to a first target gNB2 1106 in the RRC inactive state, and may vertically derive 2002 a new first gNB key (K ) based at least in part on the single NCC value (NCC1) sent by source gNB1 1104 to UE 1102. gNB2). After receiving the first transmission, the first target gNB2 1106 may perform the alternative network-side data security processing process discussed below. In addition, the first target gNB2 1106 may obtain a next second NCC value (NCC2) and NH parameters. The first target gNB2 1106 may provide the next second NCC value (NCC2) to the UE 1102 by using, for example, a medium access control (MAC) control element (MAC-CE), a radio link control (RLC) control packet data unit (PDU), or a packet data convergence protocol (PDCP) control PDU signaling. The UE 1102 may also want to transmit a second transmission to the second target gNB3 1108 in an RRC inactive state, and may vertically derive 2004 a new second gNB key (K) based at least in part on the next second NCC value (NCC2) sent by the first target gNB2 1106 to the UE 1102. gNB3 ). After receiving the first transmission, the second target gNB3 1108 may also perform the alternative network-side data security processing process discussed below. In addition, the second target gNB3 1108 may obtain a next third NCC value (NCC3) and a NH parameter. The second target gNB3 1108 may provide the next third NCC value (NCC3) to the UE 1102 by using, for example, MAC-CE, RLC control PDU, or PDCP control PDU signaling. The UE 1102 may perform an RRC recovery process with, for example, the first target gNB21106, and transition to RRC connected mode. In this example, the UE 1102 may derive 2006 a new third gNB key (K based on the third NCC value (NCC3), the NH parameter, and / or the gNB information for the previous serving gNB3 1108. gNB3 *) to transmit an RRC recovery message. The first target gNB2 1106 may then transmit a path switch request to the AMF 1110. The AMF 1110 may then respond with a path switch response message including another set of NCC values ​​and NH parameters. In some cases, the path switch request process may also be handed over to the UE 1102. The first target gNB2 1106 may then transmit another set of NCC values ​​to the UE 1102 in an RRC release message.

[0150] On the network side, in either option, network side data security processing may be provided by a plurality of alternative processing procedures. In a first alternative, data processing security may be performed by the source gNB. The first alternative may be combined with the first option. In the first alternative combined with the first option, upon receiving a first transmission addressed to the first target gNB2 1106, the first target gNB2 1106 forwards security information of the first transmission to the source gNB1 1104 along with the first target gNB2 1106 information. The source gNB1 1104 then vertically derives 2002 a new first gNB key (K ) based on the set of NCC values ​​and the first target gNB2 1106 information. gNB2 ), and the new first gNB key (K gNB2 ) is returned to the first target gNB2 1106. Similarly, upon receiving the second transmission addressed to the second target gNB3 1108, the second target gNB3 1108 also forwards the security information of the second transmission along with the second target gNB3 1108 information to the source gNB1 1104. The source gNB1 1104 may then vertically derive 2004 a new second gNB key (K) based on the set of NCC values ​​and the second target gNB3 1108 information. gNB3 ), and the new second gNB key (K gNB3 ) is returned to the second target gNB31108.

[0151] This first alternative may also be combined with the second alternative with some modifications compared to the combination with the first alternative. In this combination, upon receiving the first transmission addressed to the first target gNB2 1106, the first target gNB2 1106 forwards the security information of the first transmission to the source gNB1 1104 along with the first target gNB2 1106 information. The source gNB1 1104 then vertically derives 2002 a new first gNB key (K NCC1 ) based on the NCC value (NCC1) and the first target gNB2 1106 information. gNB2 ), and the new first gNB key (K gNB2) is returned to the first target gNB2 1106. The first target gNB2 1106 then connects to the CN, such as AMF 1110, and obtains the next second NCC value (NCC2) and NH parameters. The target gNB2 1106 then provides the next second NCC value (NCC2) to the UE 1102 by using, for example, MAC-CE, RLC control PDU, or PDCP control PDU signaling. The target gNB2 1106 may then broadcast an indication that the target gNB2 1106 has the next second NCC value (NCC2) to other gNBs in the RNA of the UE (e.g., gNB1 1104 and gNB3 1108). After receiving the second transmission sent to the second target gNB3 1108, the second target gNB3 1108 forwards the security information of the second transmission to the first target gNB2 1106 based on the broadcasted indication along with the second target gNB3 1108 information. The first target gNB2 1106 may then vertically derive 2004 a new second gNB key (K ) based on the now current second NCC value (NCC2), the NH parameter received from the CN, and the second target gNB3 1108 information. gNB3 Then, the first target gNB2 1106 sends the new second gNB key (K gNB3 ) is returned to the second target gNB3 1108. The second target gNB3 1108 then obtains the next third NCC value (NCC3) and the NH parameter from the CN. The second target gNB3 1108 may then provide the next third NCC value (NCC3) to the UE 1102 by again using, for example, MAC-CE, RLC control PDU, or PDCP control PDU signaling. The second target gNB3 1108 may then also broadcast an indication that the second target gNB3 1108 has the next third NCC value (NCC3) to other gNBs in the RNA of the UE (e.g., gNB1 1104 and gNB2 1106).

[0152] In a second alternative network-side data security processing procedure, data processing security may be performed by each accessed gNB based on the NCC / NH pair broadcast by the source gNB. The second alternative may be combined with the first option or the second option in substantially the same manner. In the second alternative, the source gNB1 1104 may broadcast UE 1102 context information including the group of NCC values ​​(or a single NCC value for option 2) and NH parameters to other gNBs (e.g., gNB21106 and gNB2 1108) in the configured RNA of UE 1102. After UE 1102 enters the RCC inactive state, UE 1102 may want to transmit data in the RCC inactive state. Then, UE 1102 may vertically derive 2002 the first gNB key (K NCC1) based on the first NCC value (NCC1) received from source gNB1 1104. gNB2 ), and transmits a first transmission to the first target gNB2 1106 in the RRC inactive state. The first target gNB2 1106 may derive a first gNB key (K based on the first NCC value (NCC1) broadcasted by the source gNB1 1104 and the NH parameter gNB2 ). The first target gNB2 1106 may also broadcast a UE data transmission number indicating which NCC has been used by UE 1102 (e.g., incrementing a counter) to other gNBs in the configured RNA of UE 1102 (e.g., gNB1 1104 and gNB3 1108). The first target gNB2 1106 may also obtain the next second NCC value (NCC2) via the set of NCC values ​​transmitted by source gNB1 1104 (e.g., for option 1) or by connecting to a CN (such as AMF 1110) and obtaining the next second NCC value (NCC2) and NH parameters (e.g., for option 2). The first target gNB2 1106 then provides the next second NCC value (NCC2) to UE 1102 by using, for example, MAC-CE, RLC control PDU, or PDCP control PDU signaling. The first target gNB2 1106 may (e.g., for option 2) broadcast the NCC value and NH parameters obtained from the CN to another gNB (e.g., gNB1 1104 and gNB3 1108) in the configured RNA of UE 1102. If UE 1102 wants to transmit more data in the RCC inactive state, UE 1102 may vertically derive 2004 a second gNB key (K NCC2) based on the second NCC value (NCC2) received from the first target gNB2 1106. gNB2) and transmits a second transmission to the second target gNB3 1108 in RRC inactive mode. After receiving the second transmission from UE 1102 to the second target gNB3 1108, the second target gNB3 1108 may vertically derive a second gNB key (K) based on the second NCC value (NCC2) and NH parameters broadcasted by the source gNB1 1104 (e.g., for option 1) or based on the second NCC value (NCC2) and NH parameters broadcasted by the first target gNB2 1106 (e.g., for option 2). gNB2 ). The second target gNB3 1108 may also obtain a next third NCC value (NCC3) via the set of NCC values ​​transmitted by the source gNB1 1104 (e.g., for option 1) or by connecting to the CN (such as AMF 1110) and obtaining the next third NCC value (NCC3) and NH parameters (e.g., for option 2). The second target gNB3 1108 then provides the next second NCC value (NCC2) to the UE 1102 by using, for example, MAC-CE, RLC control PDU, or PDCP control PDU signaling. The third target gNB3 1108 may (e.g., for option 2) broadcast the NCC value and NH parameters obtained from the CN to another gNB (e.g., gNB1 1104 and gNB2 1106) in the configured RNA of the UE 1102. The second target gNB3 1108 may also broadcast another UE data transmission number indicating which NCC value has been used by UE 1102 to other gNBs in the configured RNA of UE 1102 (e.g., gNB1 1104 and gNB2 1106).

[0153] In a third alternative, data handling security may be performed by each accessed gNB based on UE context data retrieved from the source gNB. The third alternative may be combined with the first option. In the third alternative, using the first option, after UE 1102 transmits data to the first target gNB2 1106 in an inactive state, the first target gNB2 1106 requests UE context data from the source gNB1 1104. The source gNB1 1104 then returns the UE context data including at least a first NCC value (NCC1) and NH parameters to the first target gNB2 1106. The first target gNB2 1106 may then vertically derive the 2002 first gNB key (K ) based on the first NCC value (NCC1) and the NH parameters. gNB2). Similarly, after receiving the second transmission to the second target gNB3 1108, the second target gNB3 1108 also requests UE context data from the source gNB1 1104. The source gNB1 1104 then returns the UE context data including at least the second NCC value (NCC2) and the NH parameter to the second target gNB3 1108. The second target gNB3 1108 may then vertically derive the second gNB key (K2) based on the second NCC value (NCC2) and the NH parameter received from the source gNB1 1104. gNB3 ).

[0154] Compared to the combination with the first option, this third alternative can also be combined with the second option with certain modifications. In this combination, after receiving the first transmission sent to the target gNB2 1106, the target gNB2 1106 requests UE context data from the source gNB11104. The source gNB11104 then returns the UE context data including the first NCC value (NCC1) and the NH parameters to the first target gNB2 1106. The first target gNB2 1106 then connects to the CN, such as the AMF 1110, and obtains the second NCC value (NCC2) and the NH parameters. The target gNB21106 then provides the second NCC value (NCC2) to the UE 1102 by using, for example, MAC-CE, RLC control PDU or PDCP control PDU signaling. The first target gNB2 1106 may then broadcast an indication to other gNBs in the RNA of the UE (e.g., gNB1 1104 and gNB3 1108) that the first target gNB2 1106 has the next second NCC value (NCC2). After receiving the second transmission to the second target gNB3 1108, the second target gNB3 1108 requests UE context data from the first target gNB2 1106 based on the broadcasted indication. The first target gNB2 1106 then returns the UE context data including the second NCC value (NCC2) and the NH parameter to the second target gNB3 1108. The second target gNB3 1108 may then vertically derive 2004 a new second gNB key (K NCC2) based on the now current second NCC value (NCC2) and the NH parameter received from the first gNB2 1106. gNB3). The second target gNB3 1108 then obtains the next third NCC value (NCC3) and NH parameters from the CN. The second target gNB3 1108 may then provide the next third NCC value (NCC3) to the UE 1102 by again using, for example, MAC-CE, RLC control PDU, or PDCP control PDU signaling. The second target gNB3 1108 may then also broadcast an indication that the second target gNB3 1108 has the next third NCC value (NCC3) to other gNBs in the UE's RNA (e.g., gNB1 1104 and gNB2 1106).

[0155] Fig.21 21 is a flow chart illustrating a technique 2100 for generating a key by a user equipment for inactive state data transmission according to various aspects of the present disclosure. At box 2102, a radio resource control (RRC) suspend message may be received from a first node, the RRC suspend message including a next hop (NH) chain counter (NCC) value. At box 2104, an RRC inactive state may be entered. At box 2106, a first node key may be derived based on the first NCC value. It will be understood that, as used herein, a node key refers to an derived key that can be used to access a cell (such as a gNB cell, an eNB cell, a small cell, etc.). For example, the first node key may be based on a previously used node key, a horizontally derived node key, or a vertically derived node key. At box 2108, a first uplink message for transmission in an RRC inactive state may be generated based on the first node key. At box 2110, a first uplink message may be transmitted to a node while in an RRC inactive state. It will be understood that reference Fig. 22 One or more of the various options described may be used at different times and / or according to different settings in a given wireless communication system.

[0156] Fig. 22 2200 is a flow chart illustrating a technique 2200 for generating additional keys by a user device for inactive state data transmission according to aspects of the present disclosure. At block 2202, a second node key may be derived based on a second NCC value of a plurality of NCC values ​​included in an RCC suspend message. For example, the second node key may be based on a previously used node key, a horizontally derived node key, or a vertically derived node key. At block 2204, a second uplink message for transmission in an RRC inactive state may be generated based on the second node key. At block 2206, a second uplink message may be transmitted to a third node while in an RRC inactive state.

[0157] Fig.2323 is a flow chart illustrating a technique 2300 for generating an additional key by a user equipment for inactive state data transmission in accordance with aspects of the present disclosure. At block 2302, a second NCC value may be received from a second node. At block 2304, a second node key may be derived based on the second NCC value. At block 2306, a second uplink message for transmission in an RRC inactive state may be generated based on the second node key. At block 2308, a second uplink message may be transmitted to a third node while in the RRC inactive state.

[0158] Fig.24 2400 is a flow chart illustrating a technique 2400 for generating a key by a node for inactive state data transmission according to various aspects of the present disclosure. At box 2402, a radio resource control (RRC) suspend message may be sent from a first node to a first user device, the RRC suspend message including a first next hop (NH) chain counter (NCC) value. At box 2204, access stratum (AS) resources associated with the first user device may be released. At box 2206, a first node key may be derived based on the first NCC value. For example, the first node key may be based on a previously used node key, a horizontally derived node key, or a vertically derived node key. At box 2208, a first uplink message may be received from the first user device without allocating AS resources to the first user device. At box 2210, the first uplink message may be descrambled based on the first NCC value. It will be appreciated that reference Fig.24 One or more of the various options described may be used at different times and / or according to different settings in a given wireless communication system.

[0159] Fig.25 25 is a flow chart illustrating a technique 2500 for generating additional keys by a node for inactive state data transmission according to various aspects of the present disclosure. At box 2502, a second node key may be derived based on a second NCC value in a plurality of NCC values, wherein the RCC suspend message includes the plurality of NCC values. For example, the second node key may be based on a previously used node key, a horizontally derived node key, or a vertically derived node key. At box 2504, a second uplink message may be received from a first user device without allocating AS resources to the first user device. At box 2506, the second uplink message may be descrambled based on the second node key.

[0160] Fig.2626 is a flow chart illustrating a technique 2600 for generating additional keys by a node for inactive state data transmission according to aspects of the present disclosure. At block 2602, a second NCC value may be transmitted from a second node. At block 2604, a second node key may be derived based on the second NCC value. At block 2606, a second uplink message may be received from a first user device without allocating AS resources to the first user device. At block 2608, the second uplink message may be descrambled based on the second node key.

[0161] Note that while the above examples and aspects focus on methods for calculating the maximum number of non-overlapping CCEs in a carrier aggregation scenario, similar methods and formulas may also be applied to calculate the maximum number of PDCCH candidates (i.e., M) in a wireless communication scenario. Similarly, while the above examples and aspects focus on methods for calculating the maximum number of non-overlapping CCEs in a carrier aggregation scenario, similar methods and formulas may also be applied to calculate the limit on the number of blind decodings (BD) that may be attempted by a UE in a carrier aggregation scenario.

[0162] Example

[0163] In the following sections, additional examples are provided.

[0164] According to embodiment 1, a method for secure key derivation in a wireless system is disclosed, the method comprising: receiving a radio resource control (RRC) suspend message from a first node, the RRC suspend message comprising a first next hop (NH) chain counter (NCC) value; entering an RRC inactive state; deriving a first node key based on the first NCC value for use in the RRC inactive state; generating a first uplink message for transmission in the RRC inactive state based on the first node key; and transmitting the first uplink message to the node while in the RRC inactive state.

[0165] Embodiment 2 includes the subject matter of embodiment 1, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein the first node key is the same as the second node key.

[0166] Embodiment 3 includes the subject matter of Embodiment 1, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein deriving the first node key includes horizontally deriving the first node key based on the second node key.

[0167] Embodiment 4 includes the subject matter of embodiment 1, wherein the first NCC value is different than a second NCC value previously used to derive the second node key.

[0168] Embodiment 5 includes the subject matter according to embodiment 4, further comprising: receiving first cell information from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; generating a second uplink message for transmission in an RRC inactive state based on the first node key; and transmitting the second uplink message while in the RRC inactive state.

[0169] Embodiment 6 includes the subject matter according to embodiment 4, and further includes: receiving first cell information from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; deriving a third node key horizontally based on the first node key; generating a third uplink message for transmission in an RRC inactive state based on the third node key; and transmitting a third uplink message to the node when in the RRC inactive state.

[0170] Embodiment 7 includes the subject matter according to embodiment 5, and further includes: receiving third cell information from a third node; vertically deriving a fourth node key based on the first NCC value and the third cell information; generating a third uplink message for transmission in an RRC inactive state based on the fourth node key; and transmitting a third uplink message to the third node when in the RRC inactive state.

[0171] Embodiment 8 includes the subject matter described in Embodiment 1, wherein the RRC suspend message includes multiple NCC values, and further includes: vertically deriving a second node key based on a second NCC value among the multiple NCC values; generating a second uplink message for transmission in an RRC inactive state based on the second node key; and transmitting a second uplink message to the node when in the RRC inactive state.

[0172] Embodiment 9 includes the subject matter according to embodiment 8, and also includes: determining that each NCC value of the multiple NCC values ​​has been used to derive a node key; based on the determination that each NCC value of the multiple NCC values ​​has been used, horizontally deriving a third node key based on a most recently used previous node key; generating a third uplink message for transmission in an RRC inactive state based on the third node key; and transmitting a third uplink message to the node when in the RRC inactive state.

[0173] Embodiment 10 includes the subject matter described in Embodiment 8, further comprising: determining that each NCC value of the multiple NCC values ​​has been used to derive a node key; generating a third uplink message for transmission in an RRC inactive state based on a most recently used previous node key; and transmitting the third uplink message to the node while in the RRC inactive state.

[0174] Embodiment 11 includes the subject matter of embodiment 8, further comprising: determining that each NCC value of the plurality of NCC values ​​has been used to derive a node key; and triggering an RRC recovery procedure.

[0175] Embodiment 12 includes the subject matter described in Embodiment 1, wherein a first uplink message is transmitted to a second node, and further includes: receiving a second NCC value from the second node; vertically deriving a second node key based on the second NCC value; generating a second uplink message for transmission in an RRC inactive state based on the second node key; and transmitting a second uplink message to a third node while in the RRC inactive state.

[0176] Embodiment 13 includes the subject matter described in Embodiment 1, wherein a first uplink message is transmitted to a second node, and further includes: receiving a second NCC value from the second node; determining that the second NCC value is the same as the first NCC value; deriving a second node key horizontally based on the first or second NCC value; generating a second uplink message for transmission in an RRC inactive state based on the second node key; and transmitting a second uplink message to a third node while in the RRC inactive state.

[0177] According to embodiment 14, a wireless device is disclosed, which includes: an antenna; a radio component, which is capable of being operably coupled to the antenna; and a processor, which is capable of being operably coupled to the radio component; wherein the wireless device is configured to: receive a radio resource control (RRC) suspend message from a first node, the RRC suspend message including a first next hop (NH) chain counter (NCC) value; enter an RRC inactive state; derive a first node key based on the first NCC value for use in the RRC inactive state; generate a first uplink message for transmission in the RRC inactive state based on the first node key; and transmit the first uplink message to the node when in the RRC inactive state.

[0178] Embodiment 15 includes the subject matter of Embodiment 14, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein the first node key is the same as the second node key.

[0179] Embodiment 16 includes the subject matter of Embodiment 14, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein deriving the first node key includes horizontally deriving the first node key based on the second node key.

[0180] Embodiment 17 includes the subject matter of Embodiment 14, wherein the first NCC value is different than a second NCC value previously used to derive the second node key.

[0181] Embodiment 18 includes the subject matter of embodiment 17, wherein the wireless device is further configured to: receive first cell information from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; generate a second uplink message for transmission in an RRC inactive state based on the first node key; and transmit the second uplink message while in the RRC inactive state.

[0182] Embodiment 19 includes the subject matter described in embodiment 18, wherein the wireless device is further configured to: receive first cell information from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; horizontally derive a third node key based on the first node key; generate a third uplink message for transmission in an RRC inactive state based on the third node key; and transmit a third uplink message to the node when in the RRC inactive state.

[0183] Embodiment 20 includes the subject matter described in embodiment 18, wherein the wireless device is further configured to: receive third cell information from a third node; vertically derive a fourth node key based on the first NCC value and the third cell information; generate a third uplink message for transmission in an RRC inactive state based on the fourth node key; and transmit a third uplink message to the third node while in the RRC inactive state.

[0184] Embodiment 21 includes the subject matter of embodiment 14, wherein the RRC suspend message includes multiple NCC values, and the wireless device is further configured to: vertically derive a second node key based on a second NCC value among the multiple NCC values; generate a second uplink message for transmission in an RRC inactive state based on the second node key; and transmit a second uplink message to the node when in the RRC inactive state.

[0185] Embodiment 22 includes the subject matter of embodiment 21, wherein the wireless device is further configured to: determine that each of the multiple NCC values ​​has been used to derive a node key; based on the determination that each of the multiple NCC values ​​has been used, horizontally derive a third node key based on a most recently used previous node key; generate a third uplink message for transmission in an RRC inactive state based on the third node key; and transmit a third uplink message to the node while in the RRC inactive state.

[0186] Embodiment 23 includes the subject matter of embodiment 21, wherein the wireless device is further configured to: determine that each of the multiple NCC values ​​has been used to derive a node key; generate a third uplink message for transmission in an RRC inactive state based on a most recently used previous node key; and transmit the third uplink message to the node while in the RRC inactive state.

[0187] Embodiment 24 includes the subject matter of embodiment 21, wherein the wireless device is further configured to: determine that each NCC value of the plurality of NCC values ​​has been used to derive a node key; and trigger an RRC recovery procedure.

[0188] Embodiment 25 includes the subject matter described in embodiment 14, wherein a first uplink message is transmitted to a second node, and the wireless device is further configured to: receive a second NCC value from the second node; vertically derive a second node key based on the second NCC value; generate a second uplink message for transmission in an RRC inactive state based on the second node key; and transmit a second uplink message to a third node while in the RRC inactive state.

[0189] Embodiment 26 includes the subject matter of embodiment 14, wherein a first uplink message is transmitted to a second node, and the wireless device is further configured to: receive a second NCC value from the second node; determine that the second NCC value is the same as the first NCC value; horizontally derive a second node key based on the first or second NCC value; generate a second uplink message for transmission in an RRC inactive state based on the second node key; and transmit a second uplink message to a third node while in the RRC inactive state.

[0190] According to embodiment 27, an integrated circuit is disclosed, which includes a circuit configured to perform the following operations: causing a wireless device to receive a radio resource control (RRC) suspend message from a first node, the RRC suspend message including a first next hop (NH) chain counter (NCC) value; causing the wireless device to enter an RRC inactive state; deriving a first node key based on the first NCC value for use in the RRC inactive state; generating a first uplink message for transmission in the RRC inactive state based on the first node key; and causing the wireless device to transmit a first uplink message to a node when in the RRC inactive state.

[0191] Embodiment 28 includes the subject matter of Embodiment 27, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein the first node key is the same as the second node key.

[0192] Embodiment 29 includes the subject matter of Embodiment 27, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein deriving the first node key includes horizontally deriving the first node key based on the second node key.

[0193] Embodiment 30 includes the subject matter of Embodiment 27, wherein the first NCC value is different than a second NCC value previously used to derive the second node key.

[0194] Embodiment 31 includes the subject matter of embodiment 30, wherein the circuit is further configured to: cause the wireless device to receive first cell information from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; generate a second uplink message for transmission in an RRC inactive state based on the first node key; and cause the wireless device to transmit the second uplink message when in the RRC inactive state.

[0195] Embodiment 32 includes the subject matter described in embodiment 31, wherein the circuit is further configured to: cause the wireless device to receive first cell information from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; horizontally derive a third node key based on the first node key; generate a third uplink message for transmission in an RRC inactive state based on the third node key; and cause the wireless device to transmit a third uplink message to the node when in the RRC inactive state.

[0196] Embodiment 33 includes the subject matter described in embodiment 31, wherein the circuit is further configured to: cause the wireless device to receive third cell information from a third node; vertically derive a fourth node key based on the first NCC value and the third cell information; generate a third uplink message for transmission in an RRC inactive state based on the fourth node key; and cause the wireless device to transmit a third uplink message to the third node when in the RRC inactive state.

[0197] Embodiment 34 includes the subject matter of embodiment 27, wherein the RRC suspend message comprises a plurality of NCC values, and wherein the circuit is further configured to: vertically derive a second node key based on a second NCC value among the plurality of NCC values; generate a second uplink message for transmission in an RRC inactive state based on the second node key; and cause the wireless device to transmit a second uplink message to the node when in the RRC inactive state.

[0198] Embodiment 35 includes the subject matter of embodiment 34, wherein the circuit is further configured to: determine that each of the multiple NCC values ​​has been used to derive a node key; based on the determination that each of the multiple NCC values ​​has been used, horizontally derive a third node key based on a most recently used previous node key; generate a third uplink message for transmission in an RRC inactive state based on the third node key; and cause the wireless device to transmit a third uplink message to the node when in the RRC inactive state.

[0199] Embodiment 36 includes the subject matter of embodiment 34, wherein the circuit is further configured to: determine that each NCC value of the multiple NCC values ​​has been used to derive a node key; generate a third uplink message for transmission in an RRC inactive state based on a previous node key most recently used; and cause the wireless device to transmit the third uplink message to the node when in the RRC inactive state.

[0200] Embodiment 37 includes the subject matter of embodiment 34, wherein the circuit is further configured to: determine that each NCC value of the plurality of NCC values ​​has been used to derive a node key; and trigger an RRC recovery procedure.

[0201] Embodiment 38 includes the subject matter of embodiment 27, wherein a first uplink message is transmitted to a second node, and wherein the circuit is further configured to: cause the wireless device to receive a second NCC value from the second node; vertically derive a second node key based on the second NCC value; generate a second uplink message for transmission in an RRC inactive state based on the second node key; and cause the wireless device to transmit a second uplink message to a third node when in the RRC inactive state.

[0202] Embodiment 39 includes the subject matter of embodiment 27, wherein a first uplink message is transmitted to a second node, and wherein the circuit is further configured to: cause the wireless device to receive a second NCC value from the second node; determine that the second NCC value is the same as the first NCC value; horizontally derive a second node key based on the first or second NCC value; generate a second uplink message for transmission in an RRC inactive state based on the second node key; and cause the wireless device to transmit a second uplink message to a third node when in the RRC inactive state.

[0203] According to embodiment 40, a method for security key derivation in a wireless system is disclosed, the method comprising: sending a radio resource control (RRC) suspend message from a first node to a first user equipment, the RRC suspend message comprising a first next hop (NH) chain counter (NCC) value; releasing access stratum (AS) resources associated with the first user equipment; deriving a first node key based on the first NCC value for use in an RRC inactive state; receiving a first uplink message from the first user equipment without allocating AS resources to the first user equipment; and de-scrambling the first uplink message based on the first NCC value.

[0204] Embodiment 41 includes the subject matter described in embodiment 40, wherein the first uplink message is transmitted to the second node, and wherein the first node key is derived by the first node, and further includes: receiving a request for the first node key from the second node; and transmitting the first node key to the second node.

[0205] Embodiment 42 includes the subject matter of Embodiment 40, wherein the first uplink message is transmitted to the second node, and further comprising transmitting the first NCC value to the second node, wherein the first node key is derived by the second node.

[0206] Embodiment 43 includes the subject matter of Embodiment 42, wherein the first NCC value is transmitted to the second node in response to the second node's request for the first node key.

[0207] Embodiment 44 includes the subject matter of Embodiments 40-43, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein the first node key is the same as the second node key.

[0208] Embodiment 45 includes the subject matter of Embodiments 40-43, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein deriving the first node key includes horizontally deriving the first node key based on the second node key.

[0209] Embodiment 46 includes the subject matter of Embodiments 40-43, wherein the first NCC value is different from a second NCC value previously used to derive the second node key.

[0210] Embodiment 47 includes the subject matter described in Embodiment 46, and further includes: transmitting first cell information from a second node, wherein the first node key is derived based on the first NCC value and the first cell information from the second node; receiving a second uplink message from the first user equipment without allocating AS resources to the first user equipment; and de-scrambling the second uplink message based on the first node key.

[0211] Embodiment 48 includes the subject matter described in Embodiment 46, further comprising: transmitting first cell information from a second node, wherein the first node key is derived based on the first NCC value and the first cell information from the second node; horizontally deriving a third node key based on the first node key; receiving a third uplink message from the first user device without allocating AS resources to the first user device; and de-scrambling the third uplink message based on the third node key.

[0212] Embodiment 49 includes the subject matter described in Embodiment 47, and further includes: transmitting third cell information from a third node; deriving a fourth node key based on the first NCC value and the third cell information; receiving a third uplink message from the first user equipment without allocating AS resources to the first user equipment; and de-scrambling the third uplink message based on the fourth node key.

[0213] Embodiment 50 includes the subject matter described in Embodiments 40-43, wherein the RRC suspend message includes multiple NCC values, and further includes: deriving a second node key based on a second NCC value among the multiple NCC values; receiving a second uplink message from the first user equipment without allocating AS resources to the first user equipment; and de-scrambling the second uplink message based on the second node key.

[0214] Embodiment 51 includes the subject matter according to embodiment 50, and further includes: determining that each NCC value of the multiple NCC values ​​has been used to derive a node key; based on the determination that each NCC value of the multiple NCC values ​​has been used, horizontally deriving a third node key based on a most recently used previous node key; receiving a third uplink message from the first user device without allocating AS resources to the first user device; and de-scrambling the second uplink message based on the third node key.

[0215] Embodiment 52 includes the subject matter according to embodiment 50, and also includes: determining that each NCC value of the multiple NCC values ​​has been used to derive a node key; receiving a second uplink message from the first user device without allocating AS resources to the first user device; and de-scrambling the second uplink message based on a previous node key most recently used.

[0216] Embodiment 53 includes the subject matter described in embodiment 50, further comprising: receiving an RRC resumption request from the first user equipment after each of the multiple NCC values ​​has been used to derive the node key; and transmitting another RRC suspend message including another set of multiple NCC values ​​to the first user equipment.

[0217] Embodiment 54 includes the subject matter described in accordance with Embodiments 40-43, wherein a first uplink message is transmitted to a second node, and further includes: transmitting a second NCC value from the second node; deriving a second node key based on the second NCC value; receiving a second uplink message from the first user device without allocating AS resources to the first user device; and de-scrambling the second uplink message based on the second node key.

[0218] Embodiment 55 includes the subject matter described in accordance with Embodiments 40-43, wherein a first uplink message is transmitted to a second node, and further includes: transmitting a first NCC value from the second node; horizontally deriving a second node key based on the first NCC value; receiving a second uplink message from the first user device without allocating AS resources to the first user device; and de-scrambling the second uplink message based on the second node key.

[0219] According to embodiment 56, a device is disclosed, comprising: a processor, the processor being configured to: send a radio resource control (RRC) suspend message from the device to a first user equipment, the RRC suspend message comprising a first next hop (NH) chain counter (NCC) value; release access stratum (AS) resources associated with the first user equipment; derive a first node key based on the first NCC value for use in an RRC inactive state; receive a first uplink message from the first user equipment without allocating AS resources to the first user equipment; and de-scramble the first uplink message based on the first NCC value.

[0220] Embodiment 57 includes the subject matter described in accordance with embodiment 56, wherein the first uplink message is transmitted to the second node, and wherein the first node key is derived by the device, and wherein the processor is further configured to: receive a request for the first node key from the second node; and transmit the first node key to the second node.

[0221] Embodiment 58 includes the subject matter of Embodiment 56, wherein the first uplink message is transmitted to the second node, and wherein the processor is further configured to transmit the first NCC value to the second node, wherein the first node key is derived by the second node.

[0222] Embodiment 59 includes the subject matter of Embodiment 58, wherein the first NCC value is transmitted to the second node in response to the second node's request for the first node key.

[0223] Embodiment 60 includes the subject matter of Embodiments 56-59, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein the first node key is the same as the second node key.

[0224] Embodiment 61 includes the subject matter of Embodiments 56-59, wherein the first NCC value is unchanged from a second NCC value previously used to derive the second node key, and wherein deriving the first node key includes horizontally deriving the first node key based on the second node key.

[0225] Embodiment 62 includes the subject matter of Embodiments 56-59, wherein the first NCC value is different than a second NCC value previously used to derive the second node key.

[0226] Embodiment 63 includes the subject matter of embodiment 62, wherein the processor is further configured to: transmit first cell information from a second node, wherein the first node key is derived based on the first NCC value and the first cell information from the second node; receive a second uplink message from the first user device without allocating AS resources to the first user device; and descramble the second uplink message based on the first node key.

[0227] Embodiment 64 includes the subject matter of embodiment 62, wherein the processor is further configured to: transmit first cell information from a first node, wherein the first node key is derived based on a first NCC value and the first cell information from the first node; horizontally derive a third node key based on the first node key; receive a third uplink message from the first user device without allocating AS resources to the first user device; and descramble the third uplink message based on the third node key.

[0228] Embodiment 65 includes the subject matter of embodiment 64, wherein the processor is further configured to: transmit third cell information from a third node; derive a fourth node key based on the first NCC value and the third cell information; receive a third uplink message from the first user device without allocating AS resources to the first user device; and de-scramble the third uplink message based on the fourth node key.

[0229] Embodiment 66 includes the subject matter of Embodiments 56-59, wherein the RRC suspend message includes multiple NCC values, and the processor is further configured to: derive a second node key based on a second NCC value among the multiple NCC values; receive a second uplink message from the first user device without allocating AS resources to the first user device; and descramble the second uplink message based on the second node key.

[0230] Embodiment 67 includes the subject matter of embodiment 66, wherein the processor is further configured to: determine that each of the multiple NCC values ​​has been used to derive a node key; based on the determination that each of the multiple NCC values ​​has been used, horizontally derive a third node key based on a most recently used previous node key; receive a third uplink message from the first user device without allocating AS resources to the first user device; and descramble the second uplink message based on the third node key.

[0231] Embodiment 68 includes the subject matter of embodiment 66, wherein the processor is further configured to: determine that each NCC value of the plurality of NCC values ​​has been used to derive a node key; receive a second uplink message from the first user device without allocating AS resources to the first user device; and descramble the second uplink message based on a most recently used previous node key.

[0232] Embodiment 69 includes the subject matter of embodiment 66, wherein the processor is further configured to: receive an RRC resume request from the first user device after each of the multiple NCC values ​​has been used to derive the node key; and transmit another RRC suspend message including another set of multiple NCC values ​​to the first user device.

[0233] Embodiment 70 includes the subject matter of Embodiments 56-59, wherein a first uplink message is transmitted to a second node, and the processor is further configured to: transmit a second NCC value from the second node; derive a second node key based on the second NCC value; receive a second uplink message from the first user device without allocating AS resources to the first user device; and descramble the second uplink message based on the second node key.

[0234] Embodiment 71 includes the subject matter of Embodiments 56-59, wherein a first uplink message is transmitted to a second node, and the processor is further configured to: transmit a first NCC value from the second node; horizontally derive a second node key based on the first NCC value; receive a second uplink message from the first user device without allocating AS resources to the first user device; and descramble the second uplink message based on the second node key.

[0235] Yet another exemplary embodiment may include a method, the method comprising: performing, by a device, any or all portions of the aforementioned embodiments.

[0236] Yet another exemplary embodiment may include a non-transitory computer-accessible storage medium including program instructions that, when executed at a device, cause the device to implement any or all portions of any of the aforementioned embodiments.

[0237] Yet another exemplary embodiment may include a computer program including instructions for performing any or all portions of any of the aforementioned embodiments.

[0238] Yet another exemplary embodiment may include an apparatus comprising means for performing any or all of the elements of any of the preceding embodiments.

[0239] Yet another exemplary embodiment may include an apparatus comprising a processor configured to cause the device to perform any or all elements of any of the preceding embodiments.

[0240] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0241] Aspects of the present disclosure can be implemented in any of a variety of forms. For example, some aspects can be implemented as computer-implemented methods, computer-readable storage media, or computer systems. Other aspects can be implemented using one or more custom-designed hardware devices such as ASICs. Other aspects can be implemented using one or more programmable hardware elements such as FPGAs.

[0242] In some aspects, a non-transitory computer-readable memory medium may be configured such that it stores program instructions and / or data, wherein if the program instructions are executed by a computer system, the computer system is caused to perform a method, such as any one of the method embodiments described herein, or any combination of the method embodiments described herein, or any subset of any method embodiments described herein, or any combination of such subsets.

[0243] In some embodiments, a device (e.g., UE 106, BS 102, network element 600) may be configured to include a processor (or a group of processors) and a memory medium, wherein the memory medium stores program instructions, wherein the processor is configured to read and execute the program instructions from the memory medium, wherein the program instructions are executable to implement any of the various method embodiments described herein (or any combination of the method embodiments described herein, or any subset of any method embodiment of the method embodiments described herein, or any combination of such subsets). The device may be implemented in any of various forms.

[0244] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to encompass all such variations and modifications.

Claims

1. A method for secure key derivation in a wireless system, include: receiving a radio resource control (RRC) suspend message from the first node, the RRC suspend message comprising a plurality of next hop (NH) chain counter (NCC) values; Enter RRC inactive state; deriving a first node key based on a first NCC value of the plurality of NCC values ​​for use in the RRC inactive state; generating a first uplink message for transmission in the RRC inactive state based on the first node key; transmitting the first uplink message to a node while in the RRC inactive state; vertically deriving a second node key based on a second NCC value among the plurality of NCC values; transmitting a second uplink message to a node while in the RRC inactive state, wherein the second uplink message is generated based on the second node key; determining that each NCC value of the plurality of NCC values ​​has been used to derive a node key; as well as A third uplink message is transmitted to a node while in the RRC inactive state, wherein the third uplink message is generated based on a most recently used previous node key. The method of claim 1 , wherein the first NCC value is different from the second NCC value.

3. The method according to claim 2, further comprising: include: First cell information is received from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node.

4. The method according to claim 2, further comprising: include: receiving first cell information from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; horizontally deriving a third node key based on the first node key; as well as A fourth uplink message is transmitted to a node while in the RRC inactive state, wherein the fourth uplink message is generated based on the third node key.

5. The method according to claim 3, further comprising: include: receiving third cell information from a third node; vertically deriving a fourth node key based on the first NCC value and the third cell information; as well as A fourth uplink message is transmitted to the third node while in the RRC inactive state, wherein the fourth uplink message is generated based on the fourth node key.

6. The method according to claim 1, further comprising: include: Trigger the RRC recovery process.

7. The method of claim 1, wherein the first uplink message is transmitted to a second node, and the method further include: receiving a second NCC value from the second node; Wherein transmitting a second uplink message to a node while in the RRC inactive state further comprises transmitting the second uplink message to a third node while in the RRC inactive state.

8. A wireless device, the wireless device include: antenna; a radio operably coupled to the antenna; and a processor operatively coupled to the radio; The wireless device is configured to: receiving a radio resource control (RRC) suspend message from the first node, the RRC suspend message comprising a plurality of next hop (NH) chain counter (NCC) values; Enter RRC inactive state; deriving a first node key based on a first NCC value of the plurality of NCC values ​​for use in the RRC inactive state; generating a first uplink message for transmission in the RRC inactive state based on the first node key; as well as transmitting the first uplink message to a node while in the RRC inactive state; vertically deriving a second node key based on a second NCC value among the plurality of NCC values; transmitting a second uplink message to a node while in the RRC inactive state, wherein the second uplink message is generated based on the second node key; determining that each NCC value of the plurality of NCC values ​​has been used to derive a node key; as well as A third uplink message is transmitted to a node while in the RRC inactive state, wherein the third uplink message is generated based on a most recently used previous node key.

9. The wireless device of claim 8, wherein the first NCC value is different from the second NCC value.

10. The wireless device of claim 9, wherein the wireless device is further configured to: First cell information is received from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node.

11. The wireless device of claim 9, wherein the wireless device is further configured to: receiving first cell information from the second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; horizontally deriving a third node key based on the first node key; as well as A fourth uplink message is transmitted to a node while in the RRC inactive state, wherein the fourth uplink message is generated based on the third node key.

12. The wireless device of claim 10, wherein the wireless device is further configured to: receiving third cell information from a third node; vertically deriving a fourth node key based on the first NCC value and the third cell information; and A fourth uplink message is transmitted to the third node while in the RRC inactive state, wherein the fourth uplink message is generated based on the fourth node key.

13. The wireless device of claim 8, wherein the wireless device is further configured to: Trigger the RRC recovery process.

14. The wireless device of claim 8, wherein the wireless device is further configured to: transmitting the first uplink message to a second node; and receiving a second NCC value from the second node; Wherein transmitting a second uplink message to a node while in the RRC inactive state further comprises transmitting the second uplink message to a third node while in the RRC inactive state.

15. A non-transitory computer readable medium storing instructions which, when executed, cause a processor to perform the method according to any one of claims 1 to 7.

16. An integrated circuit comprising circuitry configured to: causing the wireless device to receive a radio resource control (RRC) suspend message from the first node, the RRC suspend message comprising a plurality of next hop (NH) chain counter (NCC) values; placing the wireless device into an RRC inactive state; deriving a first node key based on a first NCC value of the plurality of NCC values ​​for use in the RRC inactive state; generating a first uplink message for transmission in the RRC inactive state based on the first node key; causing the wireless device to transmit the first uplink message to a node while in the RRC inactive state; vertically deriving a second node key based on a second NCC value among the plurality of NCC values; causing the wireless device to transmit a second uplink message to a node while in the RRC inactive state, wherein the second uplink message is generated based on the second node key; determining that each NCC value of the plurality of NCC values ​​has been used to derive a node key; as well as The wireless device is caused to transmit a third uplink message to a node while in the RRC inactive state, wherein the third uplink message is generated based on a most recently used previous node key.

17. The integrated circuit of claim 16, wherein the first NCC value is different from the second NCC value.

18. The integrated circuit of claim 17, wherein the circuit is further configured to: The wireless device is caused to receive first cell information from a second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node.

19. The integrated circuit of claim 17, wherein the circuit is further configured to: causing the wireless device to receive first cell information from the second node, wherein the first node key is vertically derived based on the first NCC value and the first cell information from the second node; horizontally deriving a third node key based on the first node key; as well as The wireless device is caused to transmit a fourth uplink message to a node while in the RRC inactive state, wherein the fourth uplink message is generated based on the third node key.

20. The integrated circuit of claim 18, wherein the circuit is further configured to: causing the wireless device to receive third cell information from a third node; vertically deriving a fourth node key based on the first NCC value and the third cell information; and The wireless device is caused to transmit a fourth uplink message to the third node while in the RRC inactive state, wherein the fourth uplink message is generated based on the fourth node key.

21. The integrated circuit of claim 16, wherein the circuit is further configured to: Trigger the RRC recovery process.

22. The integrated circuit of claim 16, wherein the circuit is further configured to: causing the wireless device to transmit the first uplink message to a second node; and causing the wireless device to receive a second NCC value from the second node; Wherein causing the wireless device to transmit a second uplink message to a node while in the RRC inactive state further comprises causing the wireless device to transmit the second uplink message to a third node while in the RRC inactive state.

Images