NR mobility security considerations associated with inter-cu ltm

Abstract

Systems, methods, and instrumentalities are provided for security in inter-CU L1 / L2 triggered mobility (LTM). A WTRU can receive configuration information indicating a candidate set of cells and security key relationships. The WTRU can receive a cell handover command specifying at least one or more of a target cell or a security key update indication while in a source cell. A security key update can be used if the target cell belongs to a different set or if the update is explicitly indicated. The WTRU can derive an updated security key, hand over to the target cell, and send a transmission to the target cell. The transmission can be security protected data using the updated key.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Patent Application No. 63 / 552,553, filed February 12, 2024, the contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communication using wireless communication continues to evolve. The fifth generation can be called 5G. The previous generation (older) mobile communication can be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] Systems, methods, and means are provided that can be associated with security considerations for L1 / L2 triggered mobility (LTM) between central units (CUs). The WTRU can receive configuration information indicating one or more of the following: a first group of candidate cells, a second group of candidate cells, or security key relationship information associated with the first and second groups. When operating in a source cell, the WTRU can receive a cell handover command indicating a handover from the source cell to a target cell. The cell handover command can indicate one or more of target cell identification information or a security key update indication. The WTRU can determine that a security key update is required. Determining the need for a security key update can be based on one or more of the following: security key relationship information indicating that the target cell belongs to a different group than the source cell, or a security key update indication indicating a security key update is required. The WTRU can determine the updated security key based on the determination that a security key update is required. The WTRU can perform a cell handover from the source cell to the target cell. The WTRU can send a transmission to the target cell. The updated security key can be used to securely protect the transmission.

[0004] Security key relationship information can indicate that the updated security key will be determined based on one of the following: horizontal key derivation, vertical key derivation, or Access and Mobility Management Function (AMF) key. The WTRU can, based on the determined security key relationship information, instruct a request for horizontal key derivation, and determine the updated security key by performing horizontal key derivation. The WTRU can, based on the determined security key relationship information, instruct a request for vertical key derivation, and determine the updated security key by performing vertical key derivation. If the determined security key relationship information instructs a request for an AMF-based security key update, the WTRU can derive the updated security key based on the AMF key. Performing a cell handover from the source cell to the target cell may include applying configuration information to the target cell. The transmission may include an indication that a cell handover has been performed.

[0005] Systems, methods, and means are provided for security considerations in L1 / L2 triggered mobility (LTM) between central units (CUs). A radio transmit-receive unit (WTRU) can receive configuration information indicating a first set of candidate cells, a second set of candidate cells, and a security key update relationship between the first and second sets of candidate cells. The WTRU can receive handover commands to hand over from a source cell associated with the first set of candidate cells to a target cell associated with the second set of candidate cells. The WTRU can determine to perform a security key update based on the security key update relationship. The WTRU can derive an updated key based on the security key update relationship. The updated key can be associated with the target cell. The WTRU can send a transmission to the target cell. The transmission can be associated with the updated key.

[0006] The WTRU can compare the security key update relationships between the first group of candidate cells and the second group of candidate cells. Based on this comparison, the WTRU can perform security key derivation.

[0007] The derivation of the update key can include one of horizontal derivation, vertical derivation, or Accessibility and Mobility Management Function (AMF) derivation. Transmissions associated with the update key may include at least a portion of the transmission encrypted by the WTRU using the update key. The transmission may include a handover completion message. The handover completion message may be encrypted using the update key. Attached Figure Description

[0008] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0009] Figure 1B The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0010] Figure 1C The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used in the communication system.

[0011] Figure 1D The illustration shows that, according to the embodiment, it is possible to... Figure 1A The illustrated system diagram shows another example RAN and another example CN used in the communication system.

[0012] Figure 2 The example switching process is illustrated.

[0013] Figure 3 The diagram illustrates the generation of key levels.

[0014] Figure 4 The diagram illustrates horizontal key derivation (HKD) and vertical key derivation (VKD).

[0015] Figure 5 The illustration shows an example L1 / 2 inter-cell mobility using CA.

[0016] Figure 6 The example LTM process is illustrated.

[0017] Figure 7 The illustration shows an example LTM cell handover command MAC CE. Detailed Implementation

[0018] Figure 1A This is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and so on.

[0019] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, any of WTRU 102a, 102b, 102c, and 102d may be referred to as a “station” and / or “STA”, may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), mobile station, fixed or mobile subscriber unit, subscription-based unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable device, head-mounted display (HMD), vehicle, drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and so on. Any of WTRU 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0020] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106 / 115, Internet 110, and / or other networks 112. By way of example, base stations 114a and 114b may be a basic transceiver station (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR NodeB, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0021] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0022] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. The air interface can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0023] More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0024] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0025] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish air interface 116 using new radio (NR).

[0026] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use the dual connectivity (DC) principle to implement both LTE and NR radio access. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0027] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (e.g., Wi-Fi), IEEE 802.16 (e.g., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced GSM Evolution Data Rate (EDGE), GSM EDGE (GERAN), and so on.

[0028] Figure 1ABase station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, residence, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, it is not required that base station 114b access Internet 110 via CN 106 / 115.

[0029] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but will be understood, RAN 104 / 113 and / or CN106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to connecting to RAN 104 / 113, which may be using NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

[0031] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which may employ cellular-based radio technology, and with base station 114b, which may employ IEEE 802 radio technology.

[0032] Figure 1B The following diagram illustrates the system of example WTRU 102. Figure 1B As shown, among other things, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0033] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal decoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving element 122. Although... Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together into an electronic package or chip.

[0034] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be appreciated that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0035] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0036] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

[0037] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from these devices. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from any type of suitable memory and store the data in memory such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store the data in that memory.

[0038] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cell units, fuel cell units, etc.

[0039] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or alternatively to, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0040] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0041] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with a specific subframe of both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with a specific subframe of either UL (e.g., for transmission) or downlink (e.g., for reception) may be concurrent and / or simultaneous.

[0042] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0043] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0044] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0045] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0046] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0047] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during handover between eNode Bs, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0048] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as Internet 110 to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0049] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, 102c with access to circuit-switched networks such as PSTN 108 to facilitate communication between WTRU 102a, 102b, 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0050] Despite WTRU in Figures 1A-1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0051] In a representative embodiment, the other network 112 may be a WLAN.

[0052] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface to a distributed system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can arrive via the AP and be transmitted to the STA. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for transmission to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where a source STA can send traffic to the AP, and the AP can transmit traffic to a destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between a source STA and a destination STA (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0053] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can exit. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0054] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0055] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can be divided into two streams by a segmented parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0056] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to those used in 802.11n and 802.11ac, the channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, including limited capabilities such as supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain very long battery life).

[0057] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be referred to as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by one STA operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example due to STAs (only supporting the 1 MHz operating mode) transmitting to the AP, the entire available band may be considered busy, even if most of the band remains idle and may be available.

[0058] In the United States, the available frequency band for 802.11ah is 902 MHz to 928 MHz. In South Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. Depending on the country code, the total available bandwidth for 802.11ah ranges from 6 MHz to 26 MHz.

[0059] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0060] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0061] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and / or a continuously varying length of absolute time).

[0062] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0063] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0064] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0065] AMF 182a and 182b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service type used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies such as WiFi.

[0066] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0067] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0068] CN 115 can facilitate communication with other networks. For example, CN 115 may include, or can communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can connect to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0069] Given Figures 1A-1D as well as Figures 1A-1D The functions described herein with respect to one or more of the following items can be performed by one or more emulation devices (not shown): WTRU 102a-102d, base station 114a-114b, eNode-B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0070] Simulation devices can be designed to perform tests on one or more other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. For testing purposes, simulation devices can be directly coupled to another device and / or can use over-the-air wireless communication to perform tests.

[0071] One or more emulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios within test laboratories and / or non-deployed (e.g., test) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices can be test rigs. Emulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0072] According to the explicit instructions in the LTM MAC CE, the WTRU can be configured to apply a security key update during LTM cell handover. The explicit instructions can further indicate the type of security update to be performed (e.g., horizontal, vertical, AMF-based).

[0073] The WTRU can be configured with a mapping between signaled security-related parameters / configurations (e.g., NCC) and the actual security-related parameters to be applied. When an indication to apply a security update is received during LTM, the WTRU can apply the security parameters / configurations mapped to the signaled parameters / configurations (e.g., the actual ones).

[0074] The WTRU can be configured with LTM candidate cell groups. For example, if an LTM cell handover is performed between cells that do not belong to the same group, the WTRU can be configured to apply a security update (e.g., or to not apply a security update) and / or an update to be applied (e.g., vertical to horizontal).

[0075] If an LTM cell handover is performed between candidate cells (e.g., different candidate cells), the WTRU can (e.g., in an LTM configuration) be configured to apply (e.g., or not in the example) security updates and / or apply which updates (e.g., vertical vs. horizontal).

[0076] The WTRU can be configured with LTM configuration (e.g., the WTRU can receive configuration information) which includes (e.g., indicating) grouping cells into LTM candidate groups (e.g., the grouping may include one or more of a first group of candidate cells or a second group of candidate cells), and the relationships between the groups regarding security key updates (e.g., no security update, horizontal, vertical, from AMF key, etc.) during LTM cell handover between cells belonging to the groups (e.g., different groups). Based on the received LTM cell handover command, the WTRU can determine whether to apply a security key update (e.g., whether a security key update is requested), and if so, what type of security update to perform based on a comparison of the groups to which the source cell and the target cell belong (e.g., the WTRU can determine whether to apply a security key update based on security key relationship information indicating that the target cell belongs to a different group than the source cell) and the configured security key derivation rules for handover between the two groups of cells.

[0077] The WTRU can receive LTM-related configuration information, which includes (e.g., indications) one or more of the following: LTM candidate cell configuration; grouping LTM candidate cells into LTM candidate groups (e.g., one or more of a first group or a second group of candidate cells); or relationships (e.g., security key relationship information) between candidate cells or cell groups (e.g., the first group and the second group) regarding security key updates during cell handovers between candidate cells (or cells belonging to different candidate groups). The relationship can include any of the following: no security key update; horizontal key derivation; vertical key derivation; or key derivation based on the Access and Mobility Management Function (AMF) key.

[0078] The WTRU can receive LTM cell handover commands to switch from a source cell (e.g., the source cell in which the WTRU is operating) to a target cell (e.g., LTM MAC CE). The WTRU can derive the KgNB (e.g., the updated security key) to be used in the target cell based on the following (e.g., based on determining that a security key update is needed).

[0079] If cell grouping is configured, the following situations may occur. If the target cell belongs to the same LTM candidate group as the source cell, or if the target cell belongs to a different LTM candidate group but the security key update relationship between the two groups is indicated as "no security update," the WTRU can maintain the current (one or more) security keys (e.g., not requiring a security key update). If the relationship between the LTM cell groups of the source and target cells indicates horizontal key derivation (e.g., requiring horizontal key derivation), the WTRU can apply horizontal key derivation as described herein to derive the KgNB. If the relationship between the LTM cell groups of the source and target cells indicates vertical key derivation (e.g., requiring vertical key derivation), the WTRU can apply vertical key derivation as described herein to derive the KgNB. The WTRU can (e.g., if the above derivation is not applicable, the WTRU can use other methods) apply AMF-based key derivation as described herein to derive the KgNB.

[0080] If no cell grouping is configured, the WTRU may perform the following operations. If the security key update relationship between the source and target cells is indicated as "no security update," the WTRU may maintain the current security key (e.g., not request a security key update). If the relationship between the two cells indicates horizontal key derivation, for example, if the above examples are not met (e.g., not indicating "no update" and not indicating "vertical handover"), the WTRU may apply horizontal key derivation as described herein to derive the KgNB.

[0081] If the relationship between two cells indicates vertical key derivation, then the WTRU can apply vertical key derivation as described in this article to derive the KgNB.

[0082] WTRU can (for example, if none of the above applies) use AMF key-based derivation as described herein to derive KgNB.

[0083] WTRU can derive user plane and control plane (one or more) encryption and integrity protection keys based on the derived KgNB.

[0084] The WTRU can send an indication to the target cell that the cell handover is complete (e.g., the indication may include an HO complete message (e.g., an HO complete message may indicate that a cell handover has been performed), which may be encrypted and / or protected for integrity using a derived KgNB).

[0085] The terms CU and gNB are used interchangeably. The terms cryptography and encryption are used interchangeably. The terms WTRU and ME are used interchangeably. The terms LTM and L1 / L2 triggered mobility are used interchangeably.

[0086] The features described in this article can be associated with switching (e.g., switching processes). Figure 2 The example switching process is illustrated.

[0087] At location 0, the WTRU context within the source gNB can include information about roaming and access restrictions, which is provided either when the connection is established or during the last TA (Timed Advance) update.

[0088] At point 1, the source gNB can configure the WTRU measurement process, and the WTRU can report based on the measurement configuration.

[0089] At point 2, the source gNB can decide to switch the WTRU based on the received measurements.

[0090] At point 3, the source gNB can send a handover request message to the target gNB, passing a transparent RRC container with (e.g., necessary) information to prepare for handover on the target side. This information may include at least one or more of the following: target cell ID, KgNB*, C-RNTI of the WTRU in the source gNB, RRM configuration including WTRU inactivity time, basic AS configuration including antenna information and DL carrier frequency, current QoS flow-to-DRB mapping rules applied to the WTRU, SIB1 from the source gNB, WTRU capabilities for different RATs, or PDU session-related information, and may include measurement information reported by the WTRU, including beam-related information (if available).

[0091] At point 4, access control can be performed by the target gNB.

[0092] At point 5, if the WTRU can be admitted, the target gNB can prepare for L1 / L2 handover and send a HANDOVER REQUEST ACKNOWLEDGE to the source gNB, which includes a transparent container to be sent to the WTRU as an RRC message to perform the handover.

[0093] At point 6, the source gNB can trigger a Uu handover by sending an RRCReconfiguration message to the WTRU. This message includes information required for accessing the target cell: at least the target cell ID, the new C-RNTI, and the target gNB security algorithm identifier for the selected security algorithm. It may also include a set of dedicated RACH resources, associations between RACH resources and one or more SSBs, associations between RACH resources and one or more WTRU-specific CSI-RS configurations, public RACH resources, and system information for the target cell.

[0094] At point 7, the source gNB can send an SN STATUS TRANSFER message to the target gNB to convey the uplink PDCP SN receiver status and downlink PDCP SN transmitter status of the DRB (e.g., RLC AM) to which PDCP status preservation applies.

[0095] At point 8, the WTRU can synchronize with the target cell and complete the RRC handover process by sending an RRCReconfigurationComplete message to the target gNB.

[0096] At point 9, the target gNB can send a PATH SWITCH REQUEST message to the AMF to trigger the 5GC to switch the DL data path toward the target gNB and establish an NG-C interface instance toward the target gNB.

[0097] At point 10, 5GC can switch the DL data path toward the target gNB. UPF can send one or more "end marker" packets per PDU session / tunnel to the source gNB on the old path and can release U-plane / TNL resources toward the source gNB.

[0098] At point 11, AMF can use the PATH SWITCH REQUEST ACKNOWLEDGE message to acknowledge the PATH SWITCH REQUEST message.

[0099] At point 12, upon receiving a PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB can send a WTRU CONTEXT RELEASE to notify the source gNB of a successful handover. The source gNB can then release the radio and C-plane resources associated with the WTRU context. Ongoing data forwarding can continue.

[0100] NR can be associated with security. In NR, SRB (Signaling Radio Bearer) can be protected and encrypted for integrity, and DRB (Data Radio Bearer) can be encrypted and protected for integrity.

[0101] WTRU can use one or more of four different security keys to operate on SRB and DRB data (e.g., for integrity protection or authentication, for encryption or decryption): integrity protection for RRC signaling (KRRCint); cryptography (also known as encryption) of RRC signaling (KRRCenc); integrity protection for user data (KUPint); or encryption of user data (KUPenc). Any key described herein can be derived from a KgNB key.

[0102] Figure 3 The diagram illustrates key hierarchy generation (e.g., in 5GS). Figure 3 The diagram illustrates the generation of key hierarchies. Figure 3 In this context, the term ME can be considered to refer to WTRU.

[0103] The key hierarchy can include the following keys: KAUSF, KSEAF, KAMF, KNASint, KNASenc, KN3IWF, KgNB, KRRCint, KRRCenc, KUPint, and KUPenc. The keys described herein can be associated with the access layer.

[0104] Keys can be associated with NG-RAN. KgNB is a key derived from KAMF by the ME and AMF. When performing horizontal or vertical key derivation, KgNB can be derived from the ME and the source gNB. KgNB can be used as a KeNB between the ME and ng-eNB. Keys can be associated with UP traffic. KUPenc is a key derived from KgNB by the ME and gNB, and can be used to protect UP traffic using specific encryption algorithms. KUPint is a key derived from KgNB by the ME and gNB, and can be used to protect UP traffic between the ME and gNB using specific integrity algorithms.

[0105] Keys can be associated with RRC signaling. KRRCint is a key derived from KgNB by the ME and gNB, and can be used to protect RRC signaling using a specific integrity algorithm. KRRCenc is a key derived from KgNB by the ME and gNB, and can be used to protect RRC signaling using a specific encryption algorithm. Intermediate keys can be associated with one or more of the following: NH can be a key derived from the ME and AMF to provide forward security. KgNb* can be a key derived by the ME and gNB when performing horizontal or vertical key derivation.

[0106] As described in this article, the RRC reconfiguration message received by the WTRU (e.g., during a handover) may include masterKeyUpdate.

[0107] If keySetChangeIndicator is set to true, WTRU can derive or update KgNB based on the KAMF key.

[0108] If keySetChangeIndicator is set to false, WTRU can derive or update KgNB based on the current KgNB and according to the nextHopChainingCount value (e.g., called NCC).

[0109] If the NCC value received by the WTRU is equal to the NCC value associated with the currently active KgNB (e.g., the NCC received in a previous masterKeyUpdate), the WTRU can derive the KgNB from the currently active KgNB and the target PCI and its frequency using the key derivation function as described herein.

[0110] If the NCC value received by the WTRU differs from the NCC value associated with the currently active KgNB, the WTRU can first synchronize the locally held NH parameters by calculating the NH derivation function as described herein (and increment the NCC value until it matches the received NCC value). When the NCC values ​​match, the WTRU can calculate the KgNB from the synchronized NH parameters and the target PCI and its frequency ARFCN-DL / EARFCN-DL using the function as described herein.

[0111] After the WTRU has derived the KgNB key according to one of the above, it can update the DRB's UP security key (e.g., KUPenc and KUPint) and CP security key (e.g., KRRCint and KRRCenc).

[0112] Based on the initial AS security context established between the WTRU and gNB (e.g., as required), the AMF and WTRU can derive the KgNB and next-hop parameter (NH). The KgNB and NH can be derived from the KAMF. The NH chain counter (NCC) can be associated with the KgNB and NH parameters. The KgNB can be associated with the NCC corresponding to the NH value derived from it. During initial setup, the KgNB can be directly derived from the KAMF and can be considered associated with a virtual NH parameter with an NCC value equal to zero. During initial setup, the derived NH value can be associated with an NCC value of 1. During handover, the basis of the KgNB to be used between the WTRU and the target gNB, called KgNB*, can be derived from the currently active KgNB or from one or more of the NH parameters. If KgNB* is derived from the currently active KgNB, this can be called horizontal key derivation and can be indicated to the WTRU using an NCC increment. If KgNB* is derived from the NH parameter, the derivation can be called vertical key derivation and can be indicated to the WTRU using an NCC increment. KRRCint, KRRCenc, KUPint, and KUPenc can be derived from KgNB after a new KgNB is derived.

[0113] Using such key derivation, a gNB that knows the KgNB shared with the WTRU may not be able to compute a previous KgNB that has already been used between the same WTRU and the previous gNB, thus providing backward security. A gNB that knows the KgNB shared with the WTRU may not be able to predict any future KgNB that will be used between the same WTRU and another gNB after n or more handovers (because the NH parameter can only be computed by the WTRU and AMF).

[0114] In a handover with vertical key derivation, NH can be bound to the target PCI and its frequency ARFCN-DL before it is used as the KgNB in ​​the target gNB. In a handover with horizontal key derivation, the currently active KgNB can be bound to the target PCI and its frequency ARFCN-DL before it is used as the KgNB in ​​the target gNB. When deriving a KgNB, the PCI and ARFCN (e.g., the absolute frequency of the target cell's SSB) can be used as inputs to the secure key derivation function (KDF).

[0115] Figure 4The diagram illustrates horizontal key derivation (HKD) and vertical key derivation (VKD). During Xn switching, if the source gNB has an unused {NH, NCC} pair, it can perform vertical key derivation. The source gNB can calculate KgNB* from the target PCI, its frequency ARFCN-DL / EARFCN-DL, and, in the case of horizontal key derivation, from the currently active KgNB, or, in the case of vertical key derivation, from NH.

[0116] The source gNB can forward the {KgNB*, NCC} pair to the target gNB. The target gNB can directly use the received KgNB* as the KgNB to be used with the WTRU. The target gNB can associate the NCC value received from the source gNB with the KgNB. The target gNB can include the received NCC in a prepared HO command message, which can be sent back to the source gNB in ​​a transparent container and forwarded by the source gNB to the WTRU.

[0117] When the target gNB has completed the handover signaling with the WTRU, it can send an NGAP PATH SWITCH REQUEST message to the AMF. Upon receiving the NGAP PATH SWITCH REQUEST, the AMF can increment its locally held NCC value by 1 and calculate the new fresh NH from its stored data. The AMF can use the KAMF from the currently active 5GNAS security context to calculate the new fresh NH. The AMF can send the newly calculated {NH, NCC} pair to the target gNB in ​​an NGAP PATH SWITCH REQUESTACKNOWLEDGE message. The target gNB can store the received {NH, NCC} pair for further handover and remove any other existing unused stored {NH, NCC} pairs (if any).

[0118] The features described in this paper can be associated with inter-cell L1 / 2 mobility. In the CA example, inter-cell L1 / 2 mobility can be associated with beamforming.

[0119] NR mobility modifications can be associated with L1 / L2-based inter-cell mobility mechanisms and processes used for mobility latency reduction.

[0120] Mechanisms and processes for L1 / L2-based inter-cell mobility for mobility latency reduction may include one or more of the following: configuration and maintenance of multiple candidate cells to allow for rapid application of candidate cell configurations; dynamic handover mechanisms between candidate serving cells (including SpCell and SCell) for potentially applicable scenarios based on L1 / L2 signaling; L1 modifications for inter-cell beam management, including L1 measurements and reporting, and beam indications (e.g., the possibility of early engagement, including further clarification of the interactions described herein); advance timing management; or CU-DU interface signaling to support L1 / L2 mobility (if needed).

[0121] FR2-specific modifications may not be excluded. The L1 / L2-based inter-cell mobility process can be applied to one or more of the following: independent, CA, and NR-DC scenarios with serving cell changes within a CG; intra-DU and intra-CU / inter-DU scenarios (applicable to independent and CA: RAN interface may not be expected); both intra-frequency and inter-frequency; both FR1 and FR2; source and target cells can be synchronous or asynchronous; inter-CU scenarios may not be included. L1 / 2 inter-cell mobility can be associated with modified handover delays; for regular or conditional L3 handovers, the WTRU can first send a measurement report using RRC signaling. In response, the network can provide further measurement configurations and potential conditional handover configurations. For handovers, the network can provide the target cell configuration after the WTRU reports that the cell meets the configured radio quality criteria using RRC signaling. For conditional handovers, to reduce the handover failure rate due to delays in sending measurement reports and then receiving RRC reconfiguration, the network provides the target cell configuration in advance and determines when the WTRU should trigger one or more measurement conditions for CHO configuration. The L3 method can be associated with a certain amount of latency, for example, due to sending measurement reports and receiving target configurations during unconditional handover.

[0122] LTM can be associated with configurations that allow for the rapid application of candidate cells, including dynamic handovers between SCells and handovers between PCells (e.g., switching roles between SCells and PCells) without performing RRC signaling. Inter-CU scenarios may not be included in the R18 work because this may require repositioning the PDCP anchor point and could be excluded from the work items. At least an RRC-based approach may be required to support inter-CU handovers. L1 / L2 can be associated with allowing immediate activation of CA operations when the serving cell changes.

[0123] Figure 5 The illustration shows an example L1 / 2 inter-cell mobility using CA. Figure 5The illustration shows an example of LTM operation, where candidate cell groups are configured by RRC and dynamic handover between PCell and SCell is achieved using L1 / 2 signaling.

[0124] In LTM, the gNB can receive one or more L1 measurement reports from the WTRU, and based on these reports, the gNB can change the WTRU's serving cell via a cell handover command signaled via the MAC CE. The cell handover command can indicate an LTM candidate configuration previously prepared by the gNB and provided to the WTRU via RRC signaling. The WTRU can then switch to the target configuration based on the cell handover command. The LTM process can be used to reduce mobility latency.

[0125] When configured by the network, it may be possible to activate the TCI state of one or more cells that are different from the currently serving cell. For example, the TCI state of these cells may be activated in advance before any of the LTM candidate cells (e.g., any one of these cells) become the serving cell. This allows the WTRU to perform DL synchronization with those cells, thereby facilitating a faster handover to one of those cells when a handover is triggered.

[0126] When configured by the network, it may be possible to initiate an UL TA acquisition (referred to as early TA) procedure for one or more cells different from the current serving cell. If a cell has the same NTA as the current serving cell or NTA=0, an early TA acquisition procedure may not be required. The network may request the WTRU to perform early TA acquisition for candidate cells before cell handover. The early TA acquisition procedure can be triggered by a PDCCH command or implemented via WTRU-based TA measurement, as configured by RRC. In the example, the gNB to which the candidate cell belongs can calculate the TA value and send it to the gNB to which the serving cell belongs. When an LTM cell handover is triggered, the serving cell can send the TA value in the LTM cell handover command MAC CE. In the latter case, the WTRU can perform TA measurement on the candidate cell after configuration by RRC, and the exact time the WTRU performs the TA measurement can depend on the WTRU implementation. The WTRU can apply the TA value measured by itself and can perform RACH-less LTM upon receiving a cell handover command. The network can send the TA value in the LTM cell handover command MAC CE without early TA acquisition.

[0127] Depending on the availability of a valid TA value, the WTRU can perform LTM cell handover without RACH or LTM cell handover based on RACH. If a TA value is provided in the cell handover command, the WTRU can apply the TA value as instructed by the network. If WTRU-based TA measurement is configured and no TA value is provided in the cell handover command, the WTRU can apply the TA value itself (if available). Simultaneously, the WTRU can perform LTM cell handover without RACH upon receiving a cell handover command. If no valid TA value is available, the WTRU can perform LTM cell handover based on RACH.

[0128] Regardless of whether the WTRU is configured for WTRU-based TA measurements in a candidate cell, it can still follow the PDCCH sequence, which includes requesting a random access procedure toward the candidate cell. This can be applied to candidate cells for which the WTRU can derive its TA value itself. Regardless of whether the WTRU has already performed a random access procedure toward the candidate cell, it can follow the WTRU-based measurement configuration (if configured by the network).

[0129] For RACH-less LTM, the WTRU can use either configuration grant or dynamic grant to access the target cell. Configuration grant can be provided in the LTM candidate configuration, and the WTRU can choose the timing of the configuration grant associated with the beam indicated in the cell handover command. When initiating an LTM cell handover to the target cell, the WTRU can begin monitoring the PDCCH on the target cell for dynamic scheduling. If the WTRU does not have a valid PUCCH resource for triggering the SR before the RACH-less LTM procedure is complete, it may not trigger the random access procedure.

[0130] One or more of the following principles may be applied to LTM: maintaining the security key during LTM cell handover; or supporting subsequent LTM.

[0131] LTM may support mobility within a gNB-DU and between gNB-DUs within a gNB-CU. LTM may support intra-frequency and inter-frequency mobility, including mobility to inter-frequency cells that are not the current serving cell. LTM may (e.g., only) support licensed spectrum. It may support the following: PCell changes in non-CA and non-DC scenarios; PCell and(one or more) SCell changes in CA scenarios; or dual-connectivity scenarios (e.g., PCell and(one or more) MCG SCell changes and PSCell and(one or more) SCG SCell changes within the SN, without involving the MN).

[0132] When the WTRU has stored LTM candidate configurations, the WTRU can execute L3 switch commands sent by the network (e.g., any).

[0133] Figure 6 The example LTM process is illustrated.

[0134] The LTM process may include the following: At point 1, the WTRU can send a MeasurementReport message to the gNB. The gNB may then decide to configure LTM and initiate LTM preparation.

[0135] At point 2, the gNB can transmit an RRCReconfiguration message, including LTM candidate configurations, to the WTRU.

[0136] At point 3, the WTRU can store LTM candidate configurations and transmit the RRCReconfigurationComplete message to the gNB.

[0137] At point 4a, the WTRU can perform DL synchronization with one or more candidate cells before receiving a cell handover command.

[0138] At 4b, when WTRU-based TA measurement is configured, the WTRU can acquire TA values ​​of one or more candidate cells through measurement. As described herein, before receiving a cell handover command, the WTRU can perform early TA acquisition of one or more candidate cells as requested by the network. This can be accomplished via CFRA triggered by a PDCCH command from the source cell, after which the WTRU sends a preamble toward the indicated candidate cell. To minimize data interruption to the source cell due to CFRA toward one or more candidate cells, the WTRU may not receive a random access response from the network for the purpose of acquiring TA values, and may indicate the TA values ​​of the candidate cells in the cell handover command. The WTRU may not maintain TA timers for the candidate cells and can rely on the network implementation to guarantee TA validity.

[0139] At point 5, the WTRU can perform L1 measurements on the configured candidate cell(s) and transmit L1 measurement reports to the gNB. L1 measurements can be performed as long as the RRC reconfiguration (step 2) is applicable.

[0140] At point 6, the gNB can decide to perform a cell handover to the target cell and transmit the MAC CE that triggers the handover via a candidate configuration index that includes the target cell. The WTRU can switch to the target cell and apply the configuration indicated by the candidate configuration index (e.g., the configuration can be applied to the target cell).

[0141] At point 7, as described in this article, if the WTRU does not have a valid TA for the target cell, the WTRU can perform a random access procedure toward the target cell.

[0142] At point 8, the WTRU can complete the LTM cell handover process by sending an RRCReconfigurationComplete message to the target cell. If the WTRU has already performed the RA procedure at point 7, then the WTRU can consider the LTM cell handover to be successfully completed when the random access procedure is successfully completed. For LTM without RACH, the WTRU can consider the LTM cell handover to be successfully completed when it determines that the network has successfully received its first UL data.

[0143] The LTM candidate configurations provided in section 2 can be used to execute 4-8 multiple times for subsequent LTMs.

[0144] From the perspective of RRC signaling, this document describes process and information elements (IEs). Some (e.g., advanced) descriptions of relevant IEs are given below: .

[0145] ltm-Config can include LTM-related configurations. LTM-Config Information elements .

[0146] LTM-Config may include a list of LTM candidates and a reference RRC configuration (as well as IEs not shown here, such as PHY layer parameters).

[0147] The LTM candidate configuration includes the candidate ID, the candidate PCI, and the RRC reconfiguration (ltm-CandidateConfig-r18) that the WTRU must apply when receiving an LTM MACCE indicating a handover to the candidate cell. If the candidate configuration does not include ltm-ConfigComplete IE, the WTRU can assume the reference configuration in the LTM configuration as the current WTRU configuration when handing over to that cell, and can apply the ltm candidate configuration on top of it. Otherwise (including ltm-configComplete), the WTRU can directly apply the ltm candidate configuration on top of the current WTRU configuration (e.g., without considering the reference configuration).

[0148] Figure 7 The diagram illustrates an example LTM cell handover command, MAC CE. Figure 7The LTM cell handover command is signaled to the WTRU using the MAC CE, as follows: R: Reserved bit, set to 0; Target configuration ID (e.g., target cell identification information) can indicate the index of the candidate target configuration to be applied to the LTM cell handover, corresponding to ltm-CandidateId minus 1. The length of this field can be 3 bits.

[0149] The timing advance command can indicate whether the TA is valid for the LTM target cell (e.g., corresponding to the SpCell of the target configuration indicated by the Target Configuration ID field). If the value of this field is set to FFF, the field can indicate that no valid timing adjustment is available for the PTAG of the LTM target cell; the field can also indicate the index value TA, which is used to control the amount of timing adjustment that the MAC entity must apply, and the WTRU can skip the random access procedure for handover to that LTM cell. The length of this field can be 12 bits.

[0150] The TCI State ID indicates and activates the TCI state of the LTM target cell (e.g., the SpCell of the target configuration indicated by the Target Configuration ID field). The TCI state can be identified by the TCI-StateId in ltm-DL-OrJointTCI-StateToAddModList. This field can be used for the joint TCI state if the value of unifiedTCI-StateType in the configuration indicated by the Target Configuration ID field is joint. This field can also be used for the downlink TCI state. The length of this field can be 7 bits.

[0151] The UL TCI State ID indicates and activates the uplink TCI state of the LTM target cell (e.g., the SpCell of the target configuration indicated by the Target Configuration ID field). The most significant bit of the UL TCI State ID is treated as a reserved bit, and the remaining 6 bits indicate the TCI-UL-StateId in ltm-UL-TCI-StatesToAddModList, as specified. This field is included if the value of unifiedTCI-StateType in the configuration indicated by the Target Configuration ID field is separate. This field is 8 bits long.

[0152] C indicates the presence of the contention-free random access resource field. If the value of this field is set to 1, the following fields exist: the random access preamble index field, the S / U field, the SS / PBCH index field, and the PRACH mask index field. If the value of this field is set to 0, the random access preamble index field, the SS / PBCH index field, and the PRACH mask index field do not exist, and the S / U field is considered a reserved field.

[0153] The S / U indicates which UL carrier transmits a contention-free random access resource (PRACH). If the value of this field is set to 1, SUL can be used. NUL can be used (e.g., in other ways). The length of this field can be 1 bit.

[0154] The random access preamble index indicates the random access preamble index of a contention-free random access resource. This field can be 6 bits long.

[0155] The SS / PBCH index can indicate the SS / PBCH that will be used to determine the timing of RACH transmissions for contention-free random access resources. This field can be 6 bits long.

[0156] The PRACH mask index can indicate the timing of one or more RACHs associated with the SS / PBCH indicated by the "SS / PBCH index" for PRACH transmissions on contention-free random access resources, referring to the rach-ConfigDedicated field in the UL BWP configuration of firstActiveUplinkBWP-Id (or otherwise refer to rach-ConfigCommon if not provided). The length of this field can be 4 bits.

[0157] The features described in this document can be associated with LTM modifications. This document can describe support for Layer 2 Mobility (LTM) between CUs. An example can be associated with a CU acting as an MN when no DC is configured. In the example, an NR-DC can be configured, and the CU can act as an SN. The MCG can remain unchanged. An NR-DC can be configured. The CU can act as an MN. The SCG can remain unchanged. The SCG can be released. In the example, subsequent LTM mobility procedures can be designed to avoid RRC configuration between cell handovers. Inter-CU support can be added.

[0158] For the purpose of supporting LTM, the features described herein can be associated with measurement-related modifications. Measurement-related modifications can be applied to both intra-CU MCG / SCG LTM and inter-CU MCG / SCG LTM. This document may describe components that support event-triggered L1 measurement reporting.

[0159] The features described herein can be associated with support for CSI-RS measurements during the LTM process and with the implementation of CSI-RS-based beam management and / or (e.g., necessary) physical layer operations on candidate cells prior to LTM.

[0160] The features described in this paper can be associated with support for conditional LTM. WTRU can evaluate the conditions used to trigger LTM. The features described in this paper can be associated with conditional LTM that includes subsequent LTMs. Intra-CU LTM can be preferred. RRM requirements can be associated with the examples described in this paper. During LTM, inter-CU can be associated with (e.g., new) security key processing mechanisms. The PDCP termination point on the network side can be changed, and when the PDCP termination point changes, the security architecture may enforce key updates. Subsequent inter-CU LTM can be supported.

[0161] The features described in this paper can be associated with the implementation of secure processing for subsequent inter-CU LTM without requiring RRC reconfiguration after (e.g., each) inter-CU LTM.

[0162] As described in this article, horizontal key derivation and horizontal switching can be used interchangeably. As described in this article, vertical key derivation and vertical switching can be used interchangeably.

[0163] Reserved bits in the MAC CE (e.g., LTM) can be used to pass security update-related configurations to the WTRU. The LTMMAC CE can be used to pass inter-CU related LTMs. Security update-related information / configurations can be provided to the WTRU via signaling other than the MAC CE or RRC (e.g., signaling provided to the WTRU before the LTM command (e.g., the actual LTM command, such as the PDCCH command used for early TA acquisition, etc.)).

[0164] In the example, the derivation of the KgNB can be described in this document. After the WTRU has derived the KgNB of the target, the WTRU can update the UP security key (e.g., KUPenc and KUPint) and CP security key (e.g., KRRCint and KRRCenc) of the DRB, and can use the new keys to communicate with the target (e.g., starting from the HO completion message sent after performing LTM cell handover).

[0165] Security updates can be performed during inter-CU LTM. The network can update security in intra-CU LTM without cell handover. (For example, a new) MAC CE can be used to trigger a security key update without cell handover. The WTRU can receive LTM MAC CEs with candidate cells that are the same as the current PCell (e.g., security update commands that are considered to have no cell handover, etc.).

[0166] Inter-CU handover can occur between CUs controlled by the same AMF. The keySetChangeIndicator in the key configuration can be set to zero. Inter-AMF LTM can be supported by extending the mechanism for indicating horizontal or vertical handover described below by using one of the reserved keys in the MAC CE (e.g., using additional bits in the LTM MAC CE, an additional IE in the LTM configuration indicating the key derivation relationship between cells or cell groups, or a more fine-grained IE, etc.).

[0167] The examples described herein can be associated with signaling. The examples described herein can be associated with signaling mechanisms in which the WTRU is configured to understand the security-related configurations it (e.g., the WTRU) will apply when switching from a source cell to a target cell due to an LTM cell handover command (e.g., a pre-configured security update relationship between a cell or a cell group to which two cells belong, as explicitly indicated in the LTM MAC CE).

[0168] Explicit indications in the LTM MAC CE can signal a security key update. In some examples, the WTRU can receive an LTM MAC CE that includes flags indicating that a security key update is about to be performed.

[0169] In some examples, the security key update flag can be (e.g., a simple) Boolean (e.g., one of the reserved bits can be used for the security flag), and a value of 0 can mean that no security key update is performed. A value of 1 can mean that a security key update is to be performed.

[0170] A value of 1 could mean that the horizontal key derivation will be performed by the WTRU (e.g., the WTRU can derive the KgNB of the target cell based on the KgNB currently in use at the source (e.g., using a key derivation function as described herein, with the PCI and frequency of the target cell as input)).

[0171] A value of 1 could mean that vertical key derivation will be performed by the WTRU, and that the NCC value is 1 greater than the NCC value currently stored at the WTRU. The WTRU can derive a new NH value based on the NH key derivation function as described herein (e.g., using the initial NH being computed as input, or using the current NH as input). The target KgNB can be derived using the newly derived NH along with the target cell's PCI and frequency as input.

[0172] The 2-bit field can be used to indicate a security key update (e.g., 00 for no security update, 01 for horizontal key derivation, 10 for vertical key derivation, 11 for KAMF-based key update, e.g., equivalent to receiving the keySetChangeIndicator in RRC as described herein).

[0173] The WTRU can be explicitly provided with the NCC value to be applied in the MAC CE (e.g., using the three reserved bits of the LTM MAC CE). The WTRU can apply the same behavior as in the (e.g., legacy) security key update process (e.g., using horizontal key derivation to derive the target KgNB if the NCC is the same as the current NCC stored in the WTRU (e.g., the last NCC used)) and vertical key derivation (e.g., synchronizing / deriving a new NH value until the signaling NCC value is reached, and then deriving the KgNB from the NH and PCI of the target cell as well as the frequency).

[0174] It can protect the network from exposure. Since the MAC CE is not securely protected, when the network instructs the WTRU to apply a security key update, an intruder who eavesdrops on the communication between the WTRU and the DU / gNB can use this information to learn about the network deployment, such as which cells belong to the same CU.

[0175] The WTRU (e.g., via dedicated signaling and LTM candidate configuration) can be configured to determine whether a 0 or 1 in the LTM MAC CE security update field corresponds to a security update. One WTRU can be configured to treat 0 as an indication of a security update, while another WTRU can be configured to treat 1 as an indication of a security update. An intruder might not be able to determine whether the WTRU is performing a security key update during LTM cell handover simply by looking at the LTM MAC CE command.

[0176] A WTRU can be configured to consider a specific configuration regarding how to use 2-bit signaling for security updates, which may indicate whether horizontal or vertical key derivation should be applied. For example, one WTRU can be configured to consider 00 for no security update, 01 for horizontal key derivation, 10 for vertical key derivation, or 11 for KAMF-based key update. Another WTRU can be configured to treat 00 as horizontal key derivation, 01 as vertical key derivation, 10 as KAMF-based key update, and 11 as vertical key derivation.

[0177] WTRUs can be configured using a mapping between actual NCC values ​​and signaled NCC values ​​(e.g., via dedicated signaling and LTM candidate configuration). For example, one WTRU can be configured with a mapping table of signaled NCC values ​​to NCC values ​​(e.g., in LTM MAC CE, signaled NCC value 1 corresponds to actual NCC value 6, etc.), while another WTRU can be configured with a different mapping (e.g., in LTM MAC CE, signaled NCC value 1 corresponds to actual NCC value 3, etc.).

[0178] WTRUs can be pre-configured using mappings of NCC values ​​exceeding 3 bits to further obfuscate security-related communications in MAC CEs. For example, instead of 3 bits for 8 possible NCC values, 4 bits can be used to indicate the NCC. WTRUs can be configured on mappings where NCC values ​​are considered equivalent. The configuration can be part of the LTM configuration received in RRC. Examples of such mappings are shown in Table 1 below. If a WTRU receives an LTM MAC CE containing an NCC value of 1 or 8, the WTRU can assume the actual NCC value is 0. If the WTRU receives an NCC value of 3 or 10, the WTRU can assume the actual NCC value is 1, and so on. Because the mapping table is configured via RRC (which intruders cannot decrypt), note that a signaled change in the NCC value in an LTM MAC CE may not necessarily mean the actual NCC value is changing. Table 1 Signaled NCC value 1 Signaled NCC value 2 Actual NCC value 1 8 0 3 10 1 2 11 2 5 9 3 7 15 4 6 13 5 4 12 6 0 14 7 .

[0179] Implicit configuration can be associated with security key updates (e.g., when a security update is required).

[0180] The WTRU can be configured with LTM candidate cell groups and configured to apply a security key update if the LTM cell handover is for a candidate cell that belongs to a different cell group than the source cell (e.g., and no security update when the source and target belong to the same LTM cell group).

[0181] The following describes an example ASN.1 structure used to signal LTM candidate packets to the WTRU.

[0182] The example ASN.1 structure can define a new LTM-CandidateGroup IE that includes a list of candidate IDs belonging to that group (e.g., all of them) instead of including the group ID in the LTM candidate configuration as shown above.

[0183] The WTRU can be configured with associations between LTM cell groups, indicating whether the WTRU should apply vertical or horizontal key derivation. Below is an example ASN.1 structure (e.g., one) for configuring the WTRU with such cell group associations / relationships: .

[0184] If the WTRU receives an LTM MAC CE to switch to the target cell, the WTRU can perform the following: If the target candidate cell belongs to the same LTM cell group as the source cell, the current security key can be maintained (e.g., no security key update is required).

[0185] If the candidate relationship between the LTM cell groups of the source and target candidate cells indicates vertical handover, then vertical key derivation can be applied to derive the KgNB, as described herein. Conversely, if, for example, the above conditions are not met (e.g., no "no update" and no "vertical handover" are not indicated), then horizontal key derivation can be applied to derive the KgNB, as described herein.

[0186] If the WTRU determines that the source and target cells belong to different LTM cell groups and no association is configured between the two LTM cell groups, the WTRU can consider the handover between the two cells as a vertical handover. The WTRU can treat such a handover as a horizontal handover. The WTRU may consider not performing a security key update.

[0187] During a handover, the WTRU can (e.g., instead of, or in addition to, LTM cell group and cell group associations) directly receive associations between candidate cells. An example ASN.1 structure for this scenario is shown below: .

[0188] The WTRU may behave as follows. When the WTRU receives an LTM MAC CE to handover to the target cell, the WTRU may perform the following: If the candidate relationship between the source and target candidate cells indicates vertical handover, vertical key derivation can be applied to derive the KgNB as described herein. For example, if the above conditions are not met (e.g., no "no update" and no "vertical handover" are not indicated), horizontal key derivation can be applied to derive the KgNB as described herein.

[0189] If the WTRU determines that the source and target cells are not associated in the candidate relationship configuration, the WTRU may assume that no security key update is performed during cell handover between the two cells. In some examples, the WTRU may consider the handover to be a horizontal handover. In some examples, the WTRU may treat such a handover as a vertical handover.

[0190] Key derivation rules can be symmetric. If a key update is required when switching from cell A to cell B, a key update may also be required when switching from B to A. In the candidate relationship table above, there may be two entries for cells A and B, where in (e.g., one) entry, cell A is the first candidate, and in (e.g., one) entry, cell A is the second candidate, and so on.

[0191] In example candidate cell relationships (e.g., instead of a Boolean value indicating to the WTRU whether to apply horizontal or vertical key derivation), information (e.g., more granular information) can be provided (e.g., as provided below). The AMF can indicate that key derivation should be performed from the KAMF. `noSecurityUpdate` might mean that this is an intra-CU switchover without security updates, and so on.

[0192] Behaviors (e.g., similar behaviors) can be configured at the group level (e.g., in the group relationship example above). For example, there can be two CUs (e.g., CU_1 and CU_2), each comprising two DUs (e.g., DUs A and B under CU_1, and DUs C and D under CU_2). WTRUs can be configured with four LTM groups, corresponding to (e.g., cells of each) DU. An example of a WTRU configuration for security updates is described below.

[0193] A WTRU can be configured not to apply security updates when it (e.g., the WTRU) is handing over between cells within the same CU (e.g., cells within the same CU may belong to different DUs). The WTRU can receive one or more of the following relationship tables indicating: Group A and Group B, no security updates required; Group C and Group D, no security updates required; Group A and Group C, security updates required (e.g., vertical, horizontal, AMF, etc.); Group A and Group D, security updates required (e.g., vertical, horizontal, AMF, etc.); Group B and Group C, security updates required (e.g., vertical, horizontal, AMF, etc.); or Group B and Group D, security updates required (e.g., vertical, horizontal, AMF, etc.).

[0194] As described in this paper between group A and group B, the network can be configured to update security (e.g., level) because (e.g., even if it is not required to perform a security update, since the PDCP termination point has not changed), the network implementation can decide to perform a security update.

[0195] In the example hierarchical grouping scheme, there can be CU-level cell grouping and DU-level cell grouping. When a CU is changed, security-related configurations can be applied, and when a DU within the same CU is changed, or when a handover is performed using a DU, other behaviors can be applicable (e.g., when handover is performed between cells of a given DU, maintain lower-level configurations and states, such as protocol variables and states, and buffered data; or when handover is performed between cells of different DUs belonging to the same CU, refresh buffered data or reset / restart protocol variables / states, etc.).

[0196] WTRU can be configured with LTM candidate configurations, where each LTM candidate configuration is associated with a list of security update configurations (e.g., masterKeyUpdate IE).

[0197] The example ASN.1 of the signaling is shown below: .

[0198] The masterKeyUpdate IE can be, for example, an IE as described herein (e.g., an older IE). The masterKeyUpdate IE can be, for example, an IE that includes NCC (e.g., a newer IE), or an IE that includes additional parameters / IEs related to LTM, etc.

[0199] If the LTM MAC CE includes an indication that a security key update will be performed (e.g., via boolean bits in the MAC CE, as described herein), then the WTRU can apply the first Update associated with the candidate ID of the target cell in the list.

[0200] In the example, the LTM MAC CE may include an index of the security key configuration to be applied by the WTRU.

[0201] In the example, the security key configuration may include an association between a source cell and a target cell. That is, for example, ltm-masterKeyUpdate as described herein can be described as follows, where (e.g., each) candidate cell may be associated with a list of keys for each source cell. The WTRU can perform the selection of the masterKey to apply based on the source cell (e.g., selecting a list of key configurations associated with the target cell and selecting the key associated with the source cell from that list). As described herein, the LTM MAC CE may explicitly include an index of the security key configuration to be applied by the WTRU (e.g., the WTRU may first select a list of keys associated with the target cell, and among these keys, the WTRU may select a key indicated by the index).

[0202] The examples described herein of using a list of security key update configurations to be applied to LTM toward (e.g., each) candidate cells can be applied to situations where LTM candidates are grouped together into LTM candidate groups. For example, the WTRU can be configured with a list of masterKeyUpdate configurations associated with a cell group (e.g., instead of association with candidate cells as described above), and the WTRU can use rules for cell-level association (e.g., similar rules) (e.g., when switching from a cell outside the cell group to that group, the WTRU can apply the first configuration in the list, or the WTRU can apply the configuration whose index is indicated in the LTMMAC CE command, etc.). Like cell-level configurations, group-level configurations can depend on the source cell group (e.g., the security configuration to be applied can depend on the target and source, and the associated list of security configurations related to the source and target cell groups, etc.).

[0203] WTRU can be configured to remove security key configurations that it has already applied from the list of security key configurations.

[0204] WTRU can be configured to increase / decrease the index of the security key configuration (e.g., increase / decrease by 1 or other pre-configured amount) and use the key associated with that index during the next security update of LTM (e.g., in cases where the index is not included in LTMMAC CE).

[0205] If the WTRU is configured to remove a security key configuration that it has already applied (e.g., just applied) from the security configuration list associated with the target cell or the LTM cell group to which the target belongs, it can send an error message to the network upon receiving an LTM MAC CE instead of performing this action if the WTRU has determined that there is no longer a security configuration. In a variant, in the case of encountering an empty security configuration list, the WTRU can simply assume that no security update will be performed in the next LTM toward the relevant target cell or the target cell belonging to the relevant LTM cell group (e.g., the network is responsible for keeping synchronized about ongoing security key updates and repopulating the security configuration list if it wants the WTRU to continue applying security key updates).

[0206] Although the above features and elements are described in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0207] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, although the features described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the features described herein are not limited to this scenario and may also be applicable to other wireless systems.

[0208] The above processes can be implemented in computer programs, software, and / or firmware incorporated in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as optical disc (CD)-ROMs and / or digital versatile discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver used in WTRUs, terminals, base stations, RNCs, and / or any host.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive configuration information, which indicates one or more of the following: a first group of candidate cells, a second group of candidate cells, or security key relationship information associated with the first and second groups; When operating in the source cell, receive a cell handover command indicating a switch from the source cell to the target cell, wherein the cell handover command indicates one or more of the following: target cell identification information or security key update indication; The determination that a security key update is required is based on: Security key relationship information indicating that the target cell belongs to a different group than the source cell; or Security key update instruction that requires security key update; The updated security key is determined based on the requirement to update the security key. Perform a cell handover from the source cell to the target cell; as well as Send the transmission to the target cell, where the updated security key is used to secure the transmission.

2. The WTRU of claim 1, wherein the security key relationship information indicates that the updated security key will be determined based on one of the following: horizontal key derivation, vertical key derivation, or based on the Access and Mobility Management Function (AMF) key.

3. The WTRU according to claim 2, wherein, The processor is further configured to require horizontal key derivation based on the determined security key relationship information, and to determine the updated security key by performing horizontal key derivation.

4. The WTRU according to claim 2, wherein, The processor is further configured to require vertical key derivation based on the determined security key relationship information, and to determine the updated security key by performing vertical key derivation.

5. The WTRU according to claim 2, wherein, The processor is further configured to indicate a request for an AMF-based security key update based on determined security key relationship information, and to derive the updated security key based on the AMF key.

6. The WTRU according to claim 1, wherein, Performing a cell handover from the source cell to the target cell involves applying configuration information to the target cell.

7. The WTRU according to claim 1, wherein, The transmission includes an indication that a cell handover has been performed.

8. A method for a wireless transmit-receive unit (WTRU), the method comprising: Receive configuration information, which indicates one or more of the following: a first group of candidate cells, a second group of candidate cells, or security key relationship information associated with the first and second groups; When operating in the source cell, receive a cell handover command indicating a switch from the source cell to the target cell, wherein the cell handover command indicates one or more of the following: target cell identification information or security key update indication; The determination that a security key update is required is based on: Security key relationship information indicating that the target cell belongs to a different group than the source cell; or Security key update instruction that requires security key update; The updated security key is determined based on the requirement to update the security key. Perform a cell handover from the source cell to the target cell; as well as Send a transmission to the target cell, where the updated security key is used to secure the transmission.

9. The method of claim 8, wherein the security key relationship information indicates that the updated security key will be determined based on one of the following: horizontal key derivation, vertical key derivation, or based on the Access and Mobility Management Function (AMF) key.

10. The method of claim 9, wherein the method further comprises determining an updated security key by performing a horizontal key derivation based on a determination of security key relationship information indicating a requirement for horizontal key derivation.

11. The method of claim 9, wherein the method further comprises determining an updated security key by performing vertical key derivation based on a determination of security key relationship information indicating a requirement for vertical key derivation.

12. The method of claim 9, wherein the method further comprises indicating a request for a security key update based on an AMF-based security key based on determined security key relationship information, and deriving the updated security key based on the AMF key.

13. The method according to claim 8, wherein, Performing a cell handover from the source cell to the target cell involves applying configuration information to the target cell.

14. The method according to claim 8, wherein, The transmission includes an indication that a cell handover has been performed.

Images