Nr mobility security considerations associated with inter-cu ltm

Abstract

NOT VISIBLE DUE TO STATUS OF PATENT

Description

NR MOBILITY SECURITY CONSIDERATIONS ASSOCIATED WITH INTER-CU LTMCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Patent Application No. 63 / 552,553 filed February 12, 2024, the contents of which are hereby incorporated by reference herein.BACKGROUND

[0002] Mobile communications using wireless communication continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).SUMMARY

[0003] Systems, methods, and instrumentalities are provided that may be associated with security considerations for inter central unit (CU) L1 / L2 triggered mobility (LTM). A WTRU may receive configuration information that indicates one or more of: a first group of candidate cells, a second group of candidate cells, or security key relationship information associated with the first group and the second group. The WTRU may receive, while operating in a source cell, a cell switch command that indicates to switch from the source cell to a target cell. The cell switch command may indicate one or more of target cell identification information or a security key update indication. The WTRU may determine that a security key update is required. The determination that the security key update is needed may be based on one or more of the following: the security key relationship information indicating that the target cell belongs to a different group than the source cell, or the security key update indication indicating that a security key update is required. The WTRU may determine an updated security key based on the determination that the security key update is required. The WTRU may perform a cell switch from the source cell to the target cell. The WTRU may send a transmission to the target cell. The transmission may be security-protected using the updated security key.

[0004] The security key relationship information may indicate that the updated security key is to be determined based on one of the following: horizontal key derivation, vertical key derivation, or an access and mobility management function (AMF) key. The WTRU may determine the updated security key by performing horizontal key derivation based on a determination that the security key relationship information indicates that horizontal key derivation is required. The WTRU may determine the updated security key by performing vertical key derivation based on a determination that the security key relationship information indicates that vertical key derivation is required. The WTRU may derive the updated security key based onan AMF key based on a determination that the security key relationship information indicates that an AMF- based security key update is required. The performance of the cell switch from the source cell to the target cell may include an application of the configuration information to the target cell. The transmission may include an indication that indicates that the cell switch has been performed.

[0005] Systems, methods, and instrumentalities are provided for security considerations for inter central unit (CU) L1 / L2 triggered mobility (LTM). A wireless transmit receive unit (WTRU) may receive configuration information that indicates a first group of candidate cells, a second group of candidate cells, and a security key update relationship between the first group of candidate cells and the second group of candidate cells. The WTRU may receive a handover command to switch from a source cell associated with the first group of candidate cells to a target cell associated with the second group of candidate cells. The WTRU may determine, based on the security key update relationship, that a security key update is to be performed. The WTRU may derive, based on the security key update relationship, an updated key. The updated key may be associated with the target cell. The WTRU may send a transmission to the target cell. The transmission may be associated with the updated key.

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

[0007] The derivation of the updated key may include one of a horizontal derivation, a vertical derivation, or an accessibility and mobility management function (AMF) derivation. The transmission being associated with the updated key may comprise the WTRU having encrypted at least part of the transmission with the updated key. The transmission may include a handover complete message. The handover complete message may be encrypted via the updated key.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0009] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0010] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (ON) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0011] FIG. 1 D is a system diagram illustrating a further example RAN and a further example ON that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0012] FIG. 2 illustrates an example handover procedure.

[0013] FIG. 3 illustrates a key hierarchy generation.

[0014] FIG. 4 illustrates the horizontal key derivation (HKD) and vertical key derivation (VKD).

[0015] FIG. 5 illustrates an example L1 / 2 inter-cell mobility using CA.

[0016] FIG. 6 illustrates an example LTM procedure.

[0017] FIG. 7 illustrates and example LTM cell switch command MAC CE.DETAILED DESCRIPTION

[0018] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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 OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0019] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a ON 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though 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, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “ST A”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

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

[0021] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In an embodiment, the 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 desired spatial directions.

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

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

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

[0025] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).

[0026] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

[0027] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (e.g., Wireless Fidelity (WiFi), IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0028] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0029] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS)requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

[0032] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the 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 source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0033] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0036] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0037] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The 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. The removable memory 132 may include a subscriber identity module (SIM) card,a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0038] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 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 cells, fuel cells, and the like.

[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) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

[0040] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0041] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the 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 either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmissionand reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0042] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0043] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0044] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0045] The CN 106 shown in FIG. 1 C 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 are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0046] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0047] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

[0049] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0050] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

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

[0052] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.

[0053] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with theAP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0054] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0055] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0056] Sub 1 GHz modes of operation are supported by 802.11af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0057] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices)that support (e.g., only support) a 1 MHz mode, 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 sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0058] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0059] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0060] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0061] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0062] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0063] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0064] The CN 115 shown in FIG. 1 D 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 are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0065] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may 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,services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0066] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0067] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may 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, providing mobility anchoring, and the like.

[0068] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0069] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0070] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devicesmay perform the 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 in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may perform testing using over-the-air wireless communications.

[0071] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0072] A WTRU may be configured to apply a security key update upon LTM cell switch, depending on explicit indication in the LTM MAC CE, that may further indicate the type of the security update to be performed (e.g., horizontal, vertical, based on AMF key).

[0073] A WTRU may be configured with mapping of signaled security related parameters / configuration (e.g., NCC) and the actual security related parameter to apply. The WTRU may apply the (e.g., actual) security parameter / configuration that maps to the signaled parameter / configuration upon receiving an indication to apply a security update during LTM.

[0074] A WTRU may be configured with LTM candidate cell grouping. The WTRU may be configured to apply a security update (e.g., or configured to not apply the security update) and / or a kind of update to apply (e.g., vertical versus horizontal), e.g., if performing an LTM cell switch between cells that do not belong to the same group.

[0075] A WTRU may be configured (e.g., in an LTM configuration) to apply (e.g., or in examples to not apply) a security update and / or what kind of update (e.g., vertical vs horizontal) to apply if performing an LTM cell switch between candidate cells (e.g., different candidate cells).

[0076] A WTRU may be configured with an LTM configuration (e.g., the WTRU may receive configuration information) that includes (e.g., indicates) a grouping of 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 relationship between the groups regarding a security key update (e.g., no security update, horizontal, vertical, from AMF key, etc.,) during LTM cell switching between cells belonging to groups (e.g., different groups). Based on receiving an LTM cell switch command, the WTRU may determine whether toapply a security key update (e.g., whether a security key update is required), and if so, what kind of the security update is to be performed based on comparing the groups that the source and target cell belong to (e.g., the WTRU may determine whether to apply a security key update based on the 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 switching between the cells of the two groups.

[0077] The WTRU may receive configuration information related to LTM that includes (e.g., indicates) one or more of the following: an LTM candidate cell configuration; a grouping of the LTM candidate cells into LTM candidate groups (e.g., one or more of a first group of candidate cells or a second group of candidate cells); or a relationship (e.g., security key relationship information) between candidate cells or cell groups (e.g., the first group and the second group) regarding a security key update during cell switching between candidate cells (or cells belonging to different candidate groups). The relationship may include any of the following: no security key update to be performed; horizontal key derivation to be performed; vertical key derivation to be performed; or key derivation based on an access and mobility management function (AMF) key to be performed.

[0078] The WTRU may receive an LTM cell switch command to switch from a source cell (e.g., the source cell that the WTRU is operating in) to a target cell (e.g., LTM MAC CE). The WTRU may derive the KgNB (e.g., the updated security key) to be used in the target cell according to the following (e.g., based on a determination that a security key update is required).

[0079] If grouping of cells is configured, the following may occur. If the target cell belongs to the same LTM candidate group as the source cell, or the target cell belongs to a different LTM candidate group but the security key update relation between the two groups is indicated to be “no security update,” the WTRU may keep the current security key(s) (e.g., no security key update required). If the relationship between the LTM cell groups of the source and the target cells indicates a horizontal key derivation (e.g., that a horizontal key derivation is required), the WTRU may apply horizontal key derivation as described herein to derive the KgNB. If the relationship between the LTM cell groups of the source and the target cells indicates a vertical key derivation (e.g., that a vertical key derivation is required), the WTRU may apply vertical key derivation as described herein to derive the KgNB. The WTRU may (e.g., the WTRU may otherwise, if the above derivations do not apply) apply AMF key-based derivation as described herein to derive the KgNB.

[0080] If grouping of cells is not configured, the WTRU may do the following. If the security key update relation between the source and target cell is indicated to be “no security update”, the WTRU may keep the current security keys (e.g., no security key update required). If the relationship between the two cells indicates a horizontal key derivation, the WTRU may apply horizontal key derivation as described herein toderive the KgNB, for example, if the above examples are not met (e.g., “no update” is not indicated and “vertical handover” is not indicated).

[0081] If the relationship between the two cells indicates a vertical key derivation, the WTRU may apply vertical key derivation as described herein to derive the KgNB.

[0082] The WTRU may (e.g., if none of the above cases holds) apply AMF key-based derivation as described herein to derive the KgNB.

[0083] The WTRU may derive the user plane and control plane ciphering and integrity protection key(s) based on the derived KgNB.

[0084] The WTRU may send an indication to the target cell about the completion of the cell switching (e.g., the indication may comprise a HO complete message (e.g., the HO complete message may indicate that the cell switch has been performed), which may be encrypted and / or integrity protected with the derived KgNB).

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

[0086] Features described herein may be associated with a handover (e.g., a handover procedure). FIG. 2 illustrates an example handover procedure.

[0087] At 0, the WTRU context within the source gNB may include information regarding roaming and access restrictions which were provided either at connection establishment or at the last TA (Timing Advance) update.

[0088] At 1 , the source gNB may configure the WTRU measurement procedures, and the WTRU may report according to the measurement configuration.

[0089] At 2, the source gNB may decide to hand over the WTRU based on the received measurements.

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

[0091] At 4, admission control may be performed by the target gNB.

[0092] At 5, if the WTRU can be admitted, the target gNB may prepare the handover with L1 / L2 and send the 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 6, the source gNB may trigger the Uu handover by sending an RRCReconfiguration message to the WTRU, including the information required to access the target cell: at least the target cell ID, the new C-RNTI, the target gNB security algorithm identifiers for the selected security algorithms. It may also include a set of dedicated RACH resources, the association between RACH resources and SSB(s), the association between RACH resources and WTRU-specific CSI-RS configuration(s), common RACH resources, and system information of the target cell, etc.

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

[0095] At 8, the WTRU may synchronize to the target cell and complete the RRC handover procedure by sending an RRCReconfigurationComplete message to target gNB.

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

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

[0098] At 11 , the AMF may confirm the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message.

[0099] At 12, upon reception of the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB may send the WTRU CONTEXT RELEASE to inform the source gNB about the success of the handover. The source gNB may release radio and C-plane related resources associated to the WTRU context. Ongoing data forwarding may continue.

[0100] NR may be associated with security. In NR, SRBs (signaling radio bearers) may be integrity protected and encrypted, and DRBs (Data radio bearers) may be encrypted and may be integrity protected.

[0101] The WTRU may use one or more of four different security keys for an operation (e.g., for integrity protecting or verification, for encryption or decryption) of the data of the SRBs and DRBs: integrity protection of RRC signaling (KRRCint); ciphering (also referred to as encryption) of RRC signaling(KRRCenc); integrity protection of user data (KUPint); or ciphering of user data (KUPenc). Any of the keys described herein may be derived from the KgNB key.

[0102] FIG. 3 illustrates a key hierarchy generation (e.g., in 5GS). FIG. 3 illustrates the key hierarchy generation. In FIG. 3, the term ME may be considered to refer to the WTRU.

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

[0104] Keys may be associated with the NG-RAN. KgNB is a key derived by ME and AMF from KAMF. KgNB may be derived by ME and source gNB when performing horizontal or vertical key derivation. The KgNB may be used as KeNB between ME and ng-eNB. Keys may be associated with the for UP traffic. KUPenc is a key derived by ME and gNB from KgNB, which may be used for the protection of UP traffic with a particular encryption algorithm. KUPint is a key derived by ME and gNB from KgNB, which may be used for the protection of UP traffic between ME and gNB with a particular integrity algorithm.

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

[0106] The RRC reconfiguration message the WTRU receives (e.g., during a handover) may include a masterKeyUpdate, as described herein.MasterKeyUpdate : : = SEQUENCE { keySetChangelndi cator BOOLEAN , nextHopChainingCount NextHopChainingCount , nas -Container OCTET STRINGOPTIONAL , — Cond s ecurityNASC }NextHopChainingCount INTEGER ( 0 . . 7 )

[0107] If the keySetChangelndicator is set to True, the WTRU may derive or update the KgNB based on the KAMF key.

[0108] If the keySetChangelndicator is set to False, the WTRU may derive or update the KgNB based on the current KgNB and depending on the nextHopChainingCount value (e.g., referred to as NCC).

[0109] If the NCC value the WTRU received is equal to the NCC value associated with the currently active KgNB (e.g., the NCC received in the previous masterKeyllpdate), the WTRU may 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 the WTRU received is different from the NCC value associated with the currently active KgNB, the WTRU may first synchronize the locally kept NH parameter by computing the NH derivation function as described herein (and increasing the NCC value until it matches the NCC value received). When the NCC values match, the WTRU may compute the KgNB from the synchronized NH parameter 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 may update the UP security keys for DRBs (e.g., KUPenc and KUPint ) and the CP security keys (e.g., KRRCint and KRRCenc).

[0112] Based on an initial AS security context (e.g., needing to be) established between the WTRU and gNB, the AMF and the WTRU may derive a KgNB and a Next Hop parameter (NH). The KgNB and the NH may be derived from the KAMF. A NH Chaining Counter (NCC) may be associated with a KgNB and NH parameter. A KgNB may be associated with the NCC corresponding to the NH value from which it was derived. At initial setup, the KgNB may be derived directly from KAMF and may be considered to be associated with a virtual NH parameter with NCC value equal to zero. At initial setup, the derived NH value may be associated with the NCC value one. On handovers, the basis for the KgNB that will be used between the WTRU and the target gNB, called KgNB*, may be derived from one or more of the currently active KgNB or from the NH parameter. If KgNB* is derived from the currently active KgNB, this may be referred to as a horizontal key derivation and may be indicated to WTRU with an NCC that does not increase. If the KgNB* is derived from the NH parameter, the derivation may be referred to as a vertical key derivation and may be indicated to WTRU with an NCC increase. KRRCint, KRRCenc, KUPint and KUPenc may be derived based on KgNB after a new KgNB is derived.

[0113] With such key derivation, a gNB with knowledge of a KgNB, shared with a WTRU, may be unable to compute a previous KgNB that has been used between the same WTRU and a previous gNB, therefore providing backward security. A gNB with knowledge of a KgNB, shared with a WTRU, may be unable to predict any future KgNB that will be used between the same WTRU and another gNB after n or more handovers (since NH parameters are only computable by the WTRU and the AMF).

[0114] On handovers with vertical key derivation, the NH may be bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the KgNB in the target gNB. On handovers withhorizontal key derivation, the currently active KgNB may be bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the KgNB in the target gNB. When deriving the KgNB, the PCI and the ARFCN (e.g., absolute frequency of SSB of the target cell) may be used as input to the security key derivation function (KDF).

[0115] FIG. 4 illustrates the horizontal key derivation (HKD) and vertical key derivation (VKD). In Xn handovers, the source gNB may perform a vertical key derivation if it has an unused {NH, NCC} pair. The source gNB may compute KgNB* from target PCI, its frequency ARFCN-DL / EARFCN-DL, and either from currently active KgNB in case of horizontal key derivation or from the NH in case of vertical key derivation.

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

[0117] When the target gNB has completed the handover signaling with the WTRU, it may send a NGAP PATH SWITCH REQUEST message to the AMF. Upon reception of the NGAP PATH SWITCH REQUEST, the AMF may increase its locally kept NCC value by one and compute a new fresh NH from its stored data. The AMF may use the KAMF from the currently active 5G NAS security context for the computation of the new fresh NH. The AMF may send the newly computed {NH, NCC} pair to the target gNB in the NGAP PATH SWITCH REQUEST ACKNOWLEDGE message. The target gNB may store the received {NH, NCC} pair for further handovers and remove other existing unused stored {NH, NCC} pairs, if any.

[0118] Features described herein may be associated with inter-cell L1 / 2 mobility. Inter-cell L1 / 2 mobility may be associated with the beams in CA examples.

[0119] NR mobility modifications may be associated with mechanism and procedures of L1 / L2 based inter-cell mobility for mobility latency reduction.

[0120] A mechanism and procedure of L1 / L2 based inter-cell mobility for mobility latency reduction may include one or more of the following: configuration and maintenance for multiple candidate cells to allow fast application of configurations for candidate cells; dynamic switch mechanism among candidate serving cells (including SpCell and SCell) for the potential applicable scenarios based on L1 / L2 signaling; L1 modifications for inter-cell beam management, including L1 measurement and reporting, and beam indication (e.g., early involvement may occur, including the possibility of further clarifying interactions described herein); timing Advance management ; or CU-DU interface signaling to support L1 / L2 mobility, if needed.

[0121] FR2 specific modifications may not be precluded. The procedure of L1 / L2 based inter-cell mobility may be applicable to one or more of following: standalone, CA and NR-DC case with serving cell change within one CG; intra-DU case and intra-CU inter-DU case (applicable for Standalone and CA: RAN interfaces may not be expected); both intra-frequency and inter-frequency; both FR1 and FR2; source and target cells may be synchronized or non-synchronized; inter-CU case may not be included. L1 / 2 inter-cell mobility may be associated with modifying handover latency; with a conventional L3 handover or conditional, the WTRU may first send a measurement report using RRC signaling. In response to this the network may provide a further measurement configuration and potentially a conditional handover configuration. With a handover, the network may provide a configuration for a target cell after the WTRU reports using RRC signaling that the cell meets a configured radio quality criteria. With conditional handover, in order to reduce the handover failure rate due to the delay in sending a measurement report then receiving an RRC reconfiguration the network provides, in advance, a target cell configuration as well as a measurement condition(s) which determines when the WTRU should trigger the CHO configuration. L3 methods may be associated with some amount of delay due to the sending of measurement reports and receiving of target configurations, for example, in a non-conditional handover.

[0122] LTM may be associated with allowing a fast application of configurations for candidate cells, including dynamically switching between SCells and switching of the PCell (e.g. switch the roles between SCell and PCell) without performing RRC signaling. The inter-CU case may not be included in the R18 work, as this may require relocation of the PDCP anchor and may be excluded from the work item. An RRC based approach may be needed at least to support inter-CU handover. L1 / L2 may be associated with allowing CA operation to be enabled instantaneously upon serving cell change.

[0123] FIG. 5 illustrates an example L1 / 2 inter-cell mobility using CA.FIG. 5 illustrates an example of LTM operation, whereby the candidate cell group is configured by RRC and a dynamic switch of PCell and SCell is achieved using L1 / 2 signaling.

[0124] In LTM, a gNB may receive L1 measurement report(s) from a WTRU, and on their basis the gNB may change WTRU serving cell by a cell switch command signaled via a MAC CE. The cell switch command may indicate an LTM candidate configuration that the gNB previously prepared and provided to the WTRU through RRC signaling. The WTRU may switch to the target configuration according to the cell switch command. The LTM procedure may be used to reduce the mobility latency.

[0125] When configured by the network, it may be possible to activate TCI states of one or multiple cells that are different from the current serving cell. For example, the TCI states of the LTM candidate cells may be activated in advance before those cells (e.g., any of those cells) become the serving cell. This may allowthe WTRU to be DL synchronized with those cells, thereby facilitating a faster cell switch to one of those cells when cell switch is triggered.

[0126] When configured by the network, it may be possible to initiate UL TA acquisition (called early TA) procedure of one or multiple cells that are different from the current serving cells. If the cell has the same NTA as the current serving cells or NTA=0, early TA acquisition procedure may not be required. The network may request the WTRU to perform early TA acquisition of a candidate cell before a cell switch. The early TA acquisition procedure may be triggered by PDCCH order or realized through WTRU-based TA measurement as configured by RRC. In examples, the gNB to which the candidate cell belongs may calculate the TA value and send it to the gNB to which the serving cell belongs. The serving cell may send the TA value in the LTM cell switch command MAC CE when triggering LTM cell switch. In the latter case, the WTRU may perform TA measurement for the candidate cells after being configured by RRC, and the exact time the WTRU performs TA measurement may be up to WTRU implementation. The WTRU may apply the TA value measured by itself and may perform RACH-less LTM upon receiving the cell switch command. The network may send a TA value in the LTM cell switch command MAC CE without early TA acquisition.

[0127] Depending on the availability of a valid TA value, the WTRU may perform either a RACH-less LTM or RACH-based LTM cell switch. If the TA value is provided in the cell switch command, the WTRU may apply the TA value as instructed by the network. Where WTRU-based TA measurement is configured, and no TA value is provided in the cell switch command, the WTRU may apply the TA value by itself if available. Meanwhile, the WTRU may perform RACH-less LTM cell switch upon receiving the cell switch command. If no valid TA value is available, the WTRU may perform RACH-based LTM cell switch.

[0128] Regardless of whether the WTRU is configured for WTRU-based TA measurement for a certain candidate cell, it may still follow the PDCCH order, which includes requesting a random-access procedure towards the candidate cells. This may apply to the candidate cells for which the WTRU is capable of deriving TA values by itself. Regardless of whether the WTRU has already performed a random-access procedure towards the candidate cells, it may follow the WTRU-based measurement configuration if configured by the network.

[0129] For RACH-less LTM, the WTRU may access the target cell using either a configured grant or a dynamic grant. The configured grant may be provided in the LTM candidate configuration, and the WTRU may select the configured grant occasion associated with the beam indicated in the cell switch command. Upon initiation of LTM cell switch to the target cell, the WTRU may start to monitor PDCCH on the target cell for dynamic scheduling. Before RACH-less LTM procedure completion, the WTRU may not trigger a random-access procedure if it does not have a valid PUCCH resource for triggered SRs.

[0130] One or more of the following principles may apply to LTM: security key is maintained upon an LTM cell switch; or subsequent LTM is supported.

[0131] LTM may support intra-gNB-DU and intra-gNB-CU inter-gNB-DU mobility. LTM may supports intra-frequency and inter-frequency mobility, including mobility to inter-frequency cell that is not a current serving cell. LTM may be supported (e.g., only) for licensed spectrum. The following may be supported: PCell change in non-CA scenario and non-DC scenario; PCell and SCell(s) change in CA scenario; or dual connectivity scenario (e.g., PCell and MCG SCell(s) change and intra-SN PSCell and SCG SCell(s) change without MN involvement).

[0132] While the WTRU has stored LTM candidate configurations, the WTRU may execute an (e.g. any) L3 handover command sent by the network.

[0133] FIG. 6 illustrates an example LTM procedure.

[0134] The procedure for LTM may include the following:

[0135] At 1 , the WTRU may send a MeasurementReport message to the gNB. The gNB may decide to configure LTM and initiates LTM preparation.

[0136] At 2, the gNB may transmit an RRCReconfiguration message to the WTRU including the LTM candidate configurations.

[0137] At 3, the WTRU may store the LTM candidate configurations and transmit an RRCReconfigurationComplete message to the gNB.

[0138] At 4a, the WTRU may perform DL synchronization with the candidate cell(s) before receiving the cell switch command.

[0139] At 4b, when WTRU-based TA measurement is configured, the WTRU may acquire the TA value(s) of the candidate cell(s) by measurement. The WTRU may perform early TA acquisition with the candidate cell(s) as requested by the network before receiving the cell switch command as described herein. This may be done via CFRA triggered by a PDCCH order from the source cell, following which the WTRU sends preamble towards the indicated candidate cell. In order to minimize the data interruption of the source cell due to CFRA towards the candidate cell (s), the WTRU may not receive a random-access response from the network for the purpose of TA value acquisition, and the TA value of the candidate cell may be indicated in the cell switch command. The WTRU may not maintain the TA timer for the candidate cell and may rely on network implementation to guarantee the TA validity.

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

[0141] At 6. the gNB may decide to execute cell switch to a target cell and transmit a MAC CE triggering cell switch by including the candidate configuration index of the target cell. The WTRU may switch to the target cell and applies the configuration indicated by candidate configuration index (e.g., the configuration may be applied to the target cell).

[0142] At 7, the WTRU may perform the random-access procedure towards the target cell if the WTRU does not have a valid TA of the target cell as described herein.

[0143] At 8, the WTRU may complete the LTM cell switch procedure by sending an RRCReconfigurationComplete message to target cell. If the WTRU has performed an RA procedure at 7, the WTRU may consider that LTM cell switch execution is successfully completed when the randomaccess procedure is successfully completed. For RACH-less LTM, the WTRU may consider that the LTM cell switch execution is successfully completed when the WTRU determines that the network has successfully received its first UL data.

[0144] 4-8 may be performed multiple times for subsequent LTM using the LTM candidate configuration(s) provided in at 2.

[0145] From an RRC signaling point of view, procedures and information elements (lEs) may be described herein. Some (e.g., high level) description of the relevant lEs is given as follows:RRCReconf iguration-vl 8xy-IEs : : = SEQUENCE {Itm-Conf ig-rl 8 SetupRel eas e { LTM-Conf ig-rl 8 }OPTIONAL , — Need M nonCriti calExtens ion SEQUENCE { }OPTIONAL}

[0146] Itm-Config may include the configuration related to LTM.LTM-Config information element— ASN1 START— TAG-LTM-CONFIG-STARTLTM-Conf ig-rl 8 : : = SEQUENCE {Itm-Re f erenceConf iguration-rl 8 SetupRel eas e { Re f erenceConf iguration-rl 8 }OPTIONAL , — Need MItm-CandidateToRel eas eLi st-rl 8 SEQUENCE ( SI ZE ( 1 . . maxNro f LTM-Conf igs -rl 8 ) ) OF LTM-Candidateld-rl 8 OPTIONAL , — Need NItm-CandidateToAddModLi st-rl 8 SEQUENCE ( SI ZE ( 1 . . maxNro f LTM-Conf igs -rl 8 ) ) OF LTM-Candidate-rl 8 OPTIONAL , — Need N[ [ s kipped ] ]}— TAG-LTM-CONFIG-STOP— ASN1 STOP

[0147] LTM-Config may include a list of LTM candidates, and a reference RRC configuration (and lEs that are not shown here, such as PHY layer parameters).— ASN1 START— TAG-LTM-CANDI DATE-STARTLTM-Candidate-rl 8 : : = SEQUENCE {Itm-Candidateld-rl 8 LTM-Candidateld-rl 8 , ltm-Candidate PCI -rl 8 PhysCel l ld ,Itm-CandidateConf ig-rl 8 OCTET STRING ( CONTAINING RRCReconf iguration )OPTIONAL , — Need M ltm-ConfigCompl ete-rl 8 ENUMERATED { true }OPTIONAL , — Need R[ [ s kipped ] ] }TAG-LTM-CANDI DATE-STOPASN1 STOP

[0148] The LTM candidate configuration contains an ID of the candidate, the PCI of the candidate, the RRC reconfiguration the WTRU must apply (ltm-CandidateConfig-r18) when an LTM MAC CE is received indicating the switch to the candidate cell. If the Itm-ConfigComplete IE is not included in the candidate configuration, the WTRU, upon switching to this cell, may assume the Reference configuration in the LTM config to the current WTRU configuration and may apply the Itm candidate configuration on top of that. Otherwise (Itm-configComplete is included), the WTRU may apply the Itm candidate configuration directly on top of the current WTRU configuration (e.g., reference configuration not considered).

[0149] FIG. 7 illustrates and example LTM cell switch command MAC CE. The LTM cell switch command is signaled to the WTRU using a MAC CE, as described in FIG. 7 and as follows: R: Reserved bit, set to 0; Target Configuration ID (e.g., target cell identification information) may indicate the index of candidate target configuration to apply for LTM cell switch, corresponding to Itm-Candidateld minus 1 . The length of the field may be 3 bits.

[0150] Timing Advance Command may indicate whether the TA is valid for the LTM target cell (e.g. the SpCell corresponding to the target configuration indicated by Target Configuration ID field). If the value of this field is set to FFF, this field may indicate that no valid timing adjustment is available for the PTAG of the LTM target cell; this field may indicate the index value TA used to control the amount of timing adjustment that the MAC entity has to apply and that the WTRU can skip the Random-Access procedure for this LTM cell switch. The length of the field may be 12 bits.

[0151] TCI state ID may indicate and activate the TCI state for the LTM target cell (e.g. the SpCell of the target configuration indicated by the Target Configuration ID field). The TCI state may be identified by TCI- Stateld in Itm-DL-OrJointTCI-StateToAddModList. If the value of unifiedTCI-StateType in the configurationindicated by Target Configuration ID field is joint, this field may be for joint TCI state. This field may be for downlink TCI state. The length of the field may be 7 bits.

[0152] UL TCI state ID may indicate and activates the uplink TCI state for the LTM target cell (e.g. the SpCell of the target configuration indicated by the Target Configuration ID field). The most significant bits of UL TCI state ID are considered as reserved bits and the remainder 6 bits indicate the TCI-UL-Stateld in Itm-UL-TCI-StatesToAddModList as specified in. This field is included if the value of unifiedTCI-StateType in the configuration indicated by Target Configuration ID field is separate. The length of the field is 8 bits.

[0153] C may indicate the presence of the contention-free Random Access Resources fields. If the value of this field is set to 1 , the following fields are present, including Random Access Preamble index field, S / U field, SS / PBCH index field and PRACH Mask index field. If the value of this field is set to 0, Random Access Preamble index field, SS / PBCH index field and PRACH Mask index field are absent, and S / U field is considered as Reserved field.

[0154] S / U may indicate which UL carrier to transmit the PRACH of the contention-free Random-Access Resources. If the value of this field is set to 1 , SUL may be used. NUL may be used (e.g., otherwise). The length of the field may be 1 bit.

[0155] Random Access Preamble index may indicate the Random-Access Preamble index of the contention-free Random-Access Resources. The length of the field may be 6 bits.

[0156] SS / PBCH index may indicate the SS / PBCH that is to be used to determine the RACH occasion for the PRACH transmission of the contention-free Random-Access Resources. The length of the field may be 6 bits.

[0157] PRACH Mask index may indicate the RACH occasion(s) associated with the SS / PBCH indicated by "SS / PBCH index" for the PRACH transmission of the contention-free Random-Access Resources, referring to the rach-ConfigDedicated (if not provided otherwise to the rach-ConfigCommon) in the UL BWP configuration of firstActiveUplinkBWP-ld. The length of the field may be 4 bits.

[0158] Features described herein may be associated with LTM modifications. Support for inter-CU Layer 2 Mobility (LTM) may be described herein. Examples may be associated with a CU acting as MN when DC is not configured. In examples, NR-DC may be configured and CU may act as SN. MCG may be unchanged. NR-DC may be configured. CU may act as MN. SCG may be unchanged. SCG may be released. In examples, subsequent LTM mobility procedures may aim to avoid RRC configuration between cell switches. Inter-CU support may be added.

[0159] Features described herein may be associated with measurement-related modifications for the purpose of supporting LTM. Measurement related modifications may be applicable to Intra-CU MCG / SCGLTM and I nter-CU MCG / SCG LTM. Components to support event triggered L1 measurement reporting may be described herein.

[0160] Features described herein may be associated with support for CSI-RS measurements for LTM procedures and enabling CSI-RS based beam management, and / or (e.g., necessary) physical layer operations on candidate cells before LTM.

[0161] Features described herein may be associated with support of conditional LTM A WTRU may evaluate conditions for triggering LTM. Features described herein may be associated with conditional LTM including subsequent LTM. Intra-CU LTM may be prioritized. RRM requirements may be associated with examples described herein. Inter-CU may be associated with (e.g., new) security key handling mechanisms during LTM. The PDCP termination point on the network side may change and security architecture may mandate a key update when a PDCP termination point changes. Subsequent inter-CU LTM may be supported.

[0162] Features described herein may be associated with enabling the security handling of subsequent inter-CU LTM, without the need for RRC reconfiguration after an (e.g., every) inter-CU LTM.

[0163] Horizontal key derivation and horizontal handover may be used interchangeably as described herein. Vertical key derivation and vertical handover may be used interchangeably as described herein.

[0164] Reserved bits in a (e.g., LTM) MAC CE may be used to communicate a security update related configuration to the WTRU. An LTM MAC CE may be used to communicate inter-CU related LTM. The security update related information / configuration may be provided via signaling apart from a MAC CE or RRC (e.g., signaling that is provided to the WTRU before the LTM command (e.g., the actual LTM command, e.g., the PDCCH order to do the early TA acquisition, etc.)).

[0165] In examples, the derivation of the KgNB may be described herein. After the WTRU has derived the KgNB for the target, the WTRU may update the UP security keys for DRBs (e.g., KUPenc and KUPint ) and the CP security keys (e.g., KRRCint and KRRCenc) and may use the new keys to communicate with the target (e.g., starting from the HO complete message that is sent after the LTM cell switching is performed).

[0166] The security update may be performed during an inter-CU LTM. A network may update the security in intra-CU LTM and without a cell switch. A (e.g., new) MAC CE may be used to trigger a security key update without cell switching. The WTRU may receive an LTM MAC CE that has a candidate cell the same as the current PCell (e.g., to be considered as a security update command without cell switching, etc.).

[0167] The inter-CU handover may occur between CUs controlled by the same AMF. The keySetChangelndicator in the key configuration may be set to zero. Inter-AMF LTM may be supported byextending the mechanisms described below for indicating horizontal or vertical handovers (e.g., using additional bits in the LTM MAC CE, additional lEs or more granular lEs in the LTM configurations that indicate key derivation relationship between cell or cell groups, etc.,) by using one of the reserved keys in the MAC CE.

[0168] Examples described herein may be associated with signaling. Examples described herein may be associated with a signaling mechanism where the WTRU is configured to understand the security related configuration it (e.g., the WTRU) is to apply when switching from a source cell to a target cell due to a LTM cell switch command (e.g., explicitly indicated in the LTM MAC CE, pre-configured security update relationship between the cells or the group of cells that the two cells belong to, etc.,).

[0169] An explicit indication in the LTM MAC CE may indicate the security key update. In some examples, the WTRU may receive an LTM MAC CE that includes a flag that indicates a security key update is to be performed.

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

[0171] A value of 1 may mean a horizontal key derivation is to be performed by the WTRU (e.g., the WTRU may derive the KgNB for the target cell based on the KgNB that is currently being used at the source (e.g., using the key derivation function as described herein, using the PCI and frequency of the target cell as an input)).

[0172] A value of 1 may mean a vertical key derivation is to be performed by the WTRU and the NCC value is 1 larger than the NCC value that is currently stored at the WTRU. The WTRU may derive a new NH value according to the NH key derivation function as described herein (e.g., using the as input if it is the initial NH being calculated or using the current NH as input). The KgNB for the target may be derived using as input the newly derived NH, and the PCI and frequency of the target cell).

[0173] A 2-bit field may be used to indicate security key update (e.g., 00 for no security update, 01 for horizontal key derivation, 10 for vertical key derivation, 11 for key update based on KAMF, e.g., equivalent to the reception of keySetChangelndicator in RRC as described herein).

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

[0175] Network exposure may be protected. Since the MAC CE is not security-protected, an intruder eavesdropping on the communication between the WTRU and the DU / gNB may get an understanding of the network deployment, such as which cells belong to the same CU, by correlating when the network is instructing the WTRU to apply security key update.

[0176] The WTRU may be configured (e.g., via dedicated signaling, along with the LTM candidate configuration), whether a 0 or 1 in the LTM MAC CE security update field corresponds to security update or not. A WTRU may be configured to consider 0 as an indication for security update, and another WTRU may be configured to consider 1 as an indication for security update. An intruder may not determine whether a security key update is being performed by the WTRU or not upon LTM cell switch by just looking at the LTM MAC CE command.

[0177] The WTRU may be configured to consider a dedicated configuration on how to use the 2-bit signaling for a security update that can indicate whether horizontal or vertical key derivation is to be applied. For example, a (e.g., one) WTRU may be configured to consider 00 for no security update, 01 for horizontal key derivation, 10 for vertical key derivation, or 11 for key update based on KAMF. A (e.g., another) WTRU may be configured to consider 00 for horizontal key derivation, 01 for vertical key derivation, 10 for key update based on KAMF, and 11 for vertical key derivation.

[0178] The WTRU may be configured (e.g., via dedicated signaling, along with the LTM candidate configuration) with a mapping of actual NCC values with signaled NCC values. For example, a (e.g., one) WTRU may be configured with a (e.g., one) mapping table of signaled versus NCC values (e.g., NCC value of 1 signaled in the LTM MAC CE corresponds to actual NCC value of 6, and so on), and a (e.g., another) WTRU can be configured with a different mapping (e.g., NCC value of 1 signaled in the LTM MAC CE corresponds to actual NCC value of 3, and so on).

[0179] The WTRU may be preconfigured with a mapping of the NCC values using more than 3 bits to further obfuscate the security related communication in the MAC CEs. For example, 4 bits may be used to indicate the NCC, instead of the 3 bits for the 8 possible NCC values. The WTRU may be configured on a mapping of which NCC values are considered to be equivalent. The configuration may be part of the LTM configuration received in RRC. An example of such a mapping is shown below in Table 1. If the WTRU receives an LTM MAC CE including an NCC value of 1 or 8, the WTRU may consider the actual NCC value to be 0. If the WTRU receives an NCC value of 3 or 10, the WTRU may consider the actual NCC value to be 1 , and so on. Since the mapping table is configured via RRC (which the intruder cannot decrypt), noticing the NCC value being signaled in the LTM MAC CE is changing may not necessarily mean that the actual NCC value is changing.Table 1

[0180] An implicit configuration may be associated with a security key update (e.g., the need for a security update).

[0181] The WTRU may be configured with an LTM candidate cell grouping and configured to apply a security key update if the LTM cell switch is to a candidate cell that belongs to a cell group different from the source cell (e.g., and no security update when the source and target belong to the same LTM cell group).

[0182] An example ASN.1 structure to signal the LTM candidate grouping to the WTRU is described below.— ASN1 START— TAG-LTM-CANDI DATE-STARTLTM-Candidate-rl 8 : : = SEQUENCE {Itm-Candidateld-rl 8 LTM-Candidateld-rl 8 , ltm-Candidate PCI -rl 8 PhysCel l ld , 1 tm-Candidat eConf ig-rl 8 OCTET STRING ( CONTAINING RRCReconf iguration )OPTIONAL , — Need MItm-Conf igCompl ete-rl 8 ENUMERATED { true }OPTIONAL , — Need R[ [ s kipped ] ]Ltm-CandidateGroupI D-rl 9 LTM-CandidateGroupId-rl 9 OPTIONAL }LTM-CandidateGroupId-rl 9 : : = INTEGER ( 1 . . maxNro fLTM-Groups -rl 9 )— TAG-LTM-CANDI DATE-STOP— ASN1 STOP

[0183] An example ASN.1 structure may be to define a new LTM-CandidateGroup IE that includes a list of (e.g., all) the candidate IDs that belong to the group (e.g., instead of including the group ID in the LTM candidate configuration as shown above).

[0184] The WTRU may be configured with an association between the LTM cell groups, indicating whether the WTRU is to apply vertical or horizontal key derivation. An (e.g., one) example ASN.1 structure to configure the WTRU with such an association / relation of the cell groups is shown below:LTM-Conf ig-rl 8 : : = SEQUENCE {Itm-Re f erenceConf iguration-rl 8 SetupRel eas e { Re f erenceConf iguration-rl 8 }OPTIONAL , — Need MItm-CandidateToRel eas eLi st-rl 8 SEQUENCE ( SI ZE ( 1 . . maxNro f LTM-Conf igs -rl 8 ) ) OF LTM-Candidateld-rl 8 OPTIONAL , — Need NItm-CandidateToAddModLi st-rl 8 SEQUENCE ( SI ZE ( 1 . . maxNro f LTM-Conf igs -rl 8 ) ) OF LTM-Candidate-rl 8 OPTIONAL , — Need N[ [ s kipped ] ][ [Ltm-CandidateGroupRel ations -rl 9 LTM-CandidateGroupRel ations -rl 9 OPTIONAL[ [}LTM-CandidateGroupRel ations -rl 9 : : = SEQUENCE ( SI ZE ( 1 . . maxNro fLTM-CandidateGroupRel ations -rl 9 ) )OF LTM-Candi ateGroupRel ation-rl 9LTM-CandidateGroupRel ation-rl 9 : : = SEQUENCE {Itm- Fi rstCandidateGroupId-rl 9 LTM-CandidateGroupId-rl 9 ,Itm-SecondCandidateGroupId-rl 9 LTM-CandidateGroupId-rl 9 , verti cal Handover BOOLEAN ,

[0185] If the WTRU receives an LTM MAC CE to switch to a target cell, the WTRU may perform the following. If the target candidate cell belongs to the same LTM cell group as the source cell, the current security keys (e.g., no security key update required) may be kept.

[0186] If the candidate relationship between the LTM cell groups of the source and the target candidate cells indicates a vertical handover, a vertical key derivation may be applied, as described herein, to derive the KgNB. The horizontal key derivation may be applied, as described herein, to derive the KgNB, for example, if the above cases are not met (e.g., “no update” is not indicated and “vertical handover” is not indicated) .

[0187] If the WTRU determines that the source and target cell belongs to different LTM cell groups, and no association between the two LTM cell groups is configured, the WTRU may consider the handover between the two cells is a vertical handover. The WTRU may consider the handover in such a case to be a horizontal handover. The WTRU may consider no security key update is to be performed.

[0188] The WTRU may (e.g., instead of or in addition to LTM cell groups and cell group associations) receive the association between candidate cells directly when it comes to handover. An example ASN.1 structure for this is shown below:LTM-Conf ig-rl 8 : : = SEQUENCE {Itm-Re f erenceConf iguration-rl 8 SetupRel eas e { Re f erenceConf iguration-rl 8 }OPTIONAL , — Need MItm-CandidateToRel eas eLi st-rl S SEQUENCE ( SI ZE ( 1 . . maxNro f LTM-Conf igs -rl 8 ) ) OF LTM-Candidateld-rl 8 OPTIONAL , — Need NItm-CandidateToAddModLi st-rl S SEQUENCE ( SI ZE ( 1 . . maxNro f LTM-Conf igs -rl 8 ) ) OF LTM-Candidate-rl 8 OPTIONAL , — Need N[ [ s kipped ] ] [ [Ltm-CandidateCel lRel ations -rl 9 LTM-CandidateCel lRel ations -rl 9 OPTIONAL[ [ }LTM-CandidateCel lRel ations -rl 9 SEQUENCE ( SI ZE ( 1 . . maxNro fLTM-CandidateCel lRel ations -rl 9 ) ) OFLTM-CandidateCel lRel ation-rl 9LTM-CandidateCel lRel ation-rl 9 : : = SEQUENCE {Itm- Fi rstCandidateld-rl 9 LTM-Candidateld-rl 8 ,Itm-SecondCandidateld-rl 9 LTM-Candidateld-rl 8 , verti cal Handover BOOLEAN ,

[0189] The WTRU behavior may be as follows. When the WTRU receives an LTM MAC CE to switch to a target cell, the WTRU may perform the following. If the candidate relationship between the source and the target candidate cells indicates a vertical handover, a vertical key derivation may be applied as described herein, to derive the KgNB. A horizontal key derivation may be applied as described herein to derive the KgNB, for example, if the above cases are not met (e.g., “no update” is not indicated and “vertical handover” is not indicated) .

[0190] If the WTRU determines that the source and target cell do not have an association in the candidate relations configuration, the WTRU may consider that no security key update is to be performed when performing cell switching between the two cells. In some examples, the WTRU may consider the handover to be a horizontal handover. In some examples, the WTRU may consider that handover in such a case to be a vertical handover.

[0191] The key derivation rules may be symmetrical. If a key update is required on switching from cell A to cell B, a key update may be required on switching from B to A. In the candidate relationship tables above, there may be 2 entries for cells A and B, where in an (e.g., one) entry cell A is the first candidate and in an (e.g., one) entry cell A is the second candidate, etc.,).

[0192] In example candidate cell relationships (e.g., instead of having a BOOLEAN to indicate to the WTRU to apply horizontal or vertical key derivation), information (e.g., more granular information) may be provided (e.g., as provided below). An AMF may indicate key derivation is to be made from the KAMF. noSecurityUpdate may mean this is an intra-CU switch with no security update, etc.LTM-CandidateCel lRel ation-rl 9 : : = SEQUENCE (Itm- Fi rstCandidateld-rl 9 LTM-Candidateld-rl 8 ,Itm-SecondCandidateld-rl 9 LTM-Candidateld-rl 8 , handover Type ENUMERATED { noSecurityUpdate , hori zontal , verti cal , amf ] ,}

[0193] Behavior (e.g., similar behavior) may be configured at the group level (e.g., in group relations examples described above). For example, there may be two CUs (e.g., CU_1 and CU_2) including 2 DUs (e.g., DUs A and B under CU_1 , and DUs C and D under CU_2). The WTRU may be configured with 4 LTM groups, corresponding to the cells of a (e.g., each) DU. Examples of WTRU configuration regarding security update are described as follows.

[0194] A WTRU may be configured to apply no security update when it (e.g., the WTRU) is switching between the cells of the same CU (e.g., the cells of the same CU may belong to different DUs). The WTRU may receive a relationship table indicating one or more of the following: Group A and Group B, no security update needed; Group C and Group D, no security update needed; Group A and Group C, security update needed (e.g., vertical, horizontal, AMF, etc.); Group A and Group D, security update needed (e.g., vertical, horizontal, AMF, etc.); Group B and Group C, security update needed (e.g., vertical, horizontal, AMF, etc.); or Group B and Group D, security update needed (e.g., vertical, horizontal, AMF, etc.).

[0195] As described herein between group A and B, the network may configure the WTRU to update security (e.g., horizontal) because (e.g., even though it is not mandated to do a security update as the PDCP termination point is not changing), a network implementation may decide to perform the security update.

[0196] In an example layered grouping scheme, there may be a CU layer grouping of cells and a DU level grouping of cells. Security related configurations may be applied when changing CUs, and other behavior may be applicable when changing DUs within the same CU, or when doing the switching with a DU (e.g., keeping lower layer configurations and states when doing the switching between cells of a given DU, such as protocol variables and states and buffered data; or, when doing the switching between cells of different DUs that belong to the same CU, flushing the buffered data or resetting / restarting protocol variables / states., etc.)

[0197] The WTRU may be configured with an LTM candidate configuration, where each LTM candidate configuration is associated with a list of security update configurations (e.g., masterKeyUpdate lEs).

[0198] An example ASN.1 for signaling is shown below:LTM-Candidate-rl 8 : : = SEQUENCE {Itm-Candidateld-rl 8 LTM-Candidateld-rl 8 , ltm-Candidate PCI -rl 8 PhysCel l ld ,1 tm-Candidat eConf ig-rl 8 OCTET STRING ( CONTAINING RRCReconf iguration )OPTIONAL , — Need MItm-Conf igCompl ete-rl 8 ENUMERATED { true }OPTIONAL , — Need R[ [ s kipped ] ]1 tm-Candidat eSecui rtyconf ig- index INTEGER ( 1 . . maxNro fXXXX-rl 9 ) OPTIONAL }LTM- s ecurity- conf ig-rl 9 SEQUENCE s e cur i t y- con f ig- index- rl 9 INTEGER ( 1 . . maxNro fXXXX-rl 9 )Itm-masterKeyUpdate-rl 9 SEQUENCE ( SI ZE ( 1 . . maxNrXXX-rl 9 ) ) OF MasterKeyUpdate ,}— TAG-LTM-CANDI DATE-STOP— ASN1 STOP

[0199] The MasterKeyllpdate IE may be an IE (e.g., legacy IE), for example as described herein. The MasterKeyllpdate IE may be an IE (e.g., a new IE), for example, including the NCC, including extra parameters / IEs that are relevant to LTM, etc.).

[0200] If the LTM MAC CE includes an indication that the security key update is to be performed (e.g., by a Boolean bit in the MAC CE, e.g., as described herein), the WTRU may apply the first masterKeyUpdate in the list that is associated with the candidate ID of the target cell.

[0201] In examples, the LTM MAC CE may include the index of the security key configuration the WTRU is to apply.

[0202] In examples, the security key configuration may include an association between source and target cells. That is, for example, the Itm-masterKeyUpdate as described herein may be described as follows, wherein a (e.g., each) candidate cell may be associated with a list of Keys for each source cell. The WTRU may perform the selection of the masterKey to apply depending on the source cell (e.g., choose the list of key configurations that are associated with the target cell, and from this list, choose a key associated with the source cell). As described herein, the LTM MAC CE may explicitly include the index of the security key configuration the WTRU is to apply (e.g., the WTRU may first choose the list of keys associated with the target cell, and among those keys, the WTRU may choose the one indicated by the index).LTM-Candidate-rl 8 : : = SEQUENCE {Itm-Candidateld-rl 8 LTM-Candidateld-rl 8 , ltm-Candidate PCI -rl 8 PhysCel l ld ,Itm-Candidat eConf ig-rl 8 OCTET STRING ( CONTAINING RRCReconf iguration )OPTIONAL , — Need MItm-Conf igCompl ete-rl 8 ENUMERATED { true }OPTIONAL , — Need R[ [ s kipped ] ]Itm-CandidateSecui rtyconf ig- index INTEGER ( 1 . . maxNro fXXXX-rl 9 ) OPTIONAL }LTM- s ecurity- conf ig-rl 9 SEQUENCE s e cur i t y- con f ig- index- rl 9 INTEGER ( 1 . . maxNro fXXXX-rl 9 )Itm-masterKeyUpdate-rl 9 SEQUENCE ( SI ZE ( 1 . . maxNrXXX-rl 9 ) ) OFMas terKeyUpdateConf igs -rl 9 ,LTM-Mas terKeyUpdateConf igs -rl 9 : : = SEQUENCE {Itm-SourceCel l l D-rl 9 LTM-Candidateld-rl 8 , masterKeyUpdate-rl 9 SEQUENCE ( SI ZE ( 1 . . maxNrXXX-rl 9 ) ) OF MasterKeyUpdate-rl 8 ,TAG-LTM-CANDI DATE-STOPASN1 STOP

[0203] Examples described herein for using lists of security key update configurations to be applied for LTM towards a (e.g., each) candidate cell may be applied where the LTM candidates are grouped together in LTM candidate groups. For example, the WTRU may be configured with a list of masterKeyUpdate configurations that are associated with a cell group (e.g., instead of the association with a candidate cell as discussed above), and the WTRU may use a (e.g., similar) rule for the cell level association (e.g., the WTRU may apply the first configuration in the list when switching from a cell outside the cell group to the group, or the WTRU may apply the configuration whose index is indicated in the LTM MAC CE command, etc.). Like the cell level configuration, a group level configuration may be dependent on the source cell group (e.g., the security configuration to apply may depend on the target and the source and the associated list of security configurations that relate the source and target cell groups, etc.,)

[0204] The WTRU may be configured to remove the security key configuration that it has applied from the list of security key configurations.

[0205] The WTRU may be configured to increase / decrease the index of the security key configuration (e.g., by 1 or other pre-configured amount) and use the key that is associated with that index during the next security update due to LTM (e.g., in case no index was included in the LTM MAC CE).

[0206] If the WTRU was configured to remove the security key configuration that it has applied (e.g., just applied) from the list of security configuration associated with the target cell or the LTM cell group that the target belongs to, if the WTRU has determined that there is no more security configuration left, it may send an error message to the network on receiving an LTM MAC CE instead of executing it. In a variant, in such a case of encountering an empty security configuration list, the WTRU may simply consider that no security update is to be performed in the next LTM towards the concerned target cell or a target cell belonging to the concerned LTM cell group (e.g., it is network’s responsibility to keep in sync regarding security keys updates being made and repopulating the list of security configurations if it wants the WTRU to keep applying security key updates.)

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

[0208] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although features described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the features described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0209] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random-access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

CLAIMSWhat is Claimed:1 . A wireless transmit receive unit (WTRU) comprising: a processor configured to: receive configuration information that indicates one or more of: a first group of candidate cells, a second group of candidate cells, or security key relationship information associated with the first group and the second group; receive, while operating in a source cell, a cell switch command that indicates to switch from the source cell to a target cell, wherein the cell switch command indicates one or more of: target cell identification information or a security key update indication; determine that a security key update is required, wherein the determination that the security key update is needed is based on: the security key relationship information indicating that the target cell belongs to a different group than the source cell; or the security key update indication indicating that a security key update is required; determine an updated security key based on the determination that the security key update is required; perform a cell switch from the source cell to the target cell; and send a transmission to the target cell, wherein the transmission is security-protected using the updated security key.

2. The WTRU of claim 1 , wherein the security key relationship information indicates that the updated security key is to be determined based on one of the following: horizontal key derivation, vertical key derivation, or based on an access and mobility management function (AMF) key.

3. The WTRU of claim 2, wherein the processor is further configured to determine the updated security key by performing horizontal key derivation based on a determination that the security key relationship information indicates that horizontal key derivation is required.

4. The WTRU of claim 2, wherein the processor is further configured to determine the updated security key by performing vertical key derivation based on a determination that the security key relationship information indicates that vertical key derivation is required.

5. The WTRU of claim 2, wherein the processor is further configured to derive the updated security key based on an AMF key based on a determination that the security key relationship information indicates that an AMF-based security key update is required.

6. The WTRU of claim 1 , wherein the performance of the cell switch from the source cell to the target cell comprises application of the configuration information to the target cell.

7. The WTRU of claim 1 , wherein the transmission comprises an indication that indicates that the cell switch has been performed.

8. A method for a wireless transmit receive unit (WTRU), the method comprising: receiving configuration information that indicates one or more of: a first group of candidate cells, a second group of candidate cells, or security key relationship information associated with the first group and the second group; receiving, while operating in a source cell, a cell switch command that indicates to switch from the source cell to a target cell, wherein the cell switch command indicates one or more of: target cell identification information or a security key update indication; determining that a security key update is required, wherein the determination that the security key update is needed is based on: the security key relationship information indicating that the target cell belongs to a different group than the source cell; or the security key update indication indicating that a security key update is required; determining an updated security key based on the determination that the security key update is required; performing a cell switch from the source cell to the target cell; and sending a transmission to the target cell, wherein the transmission is security-protected using the updated security key.

9. The method of claim 8, wherein the security key relationship information indicates that the updated security key is to be determined based on one of the following: horizontal key derivation, vertical key derivation, or based on an access and mobility management function (AMF) key.

10. The method of claim 9, wherein the method further comprises determining the updated security key by performing horizontal key derivation based on a determination that the security key relationship information indicates that horizontal key derivation is required.11 . The method of claim 9, wherein the method further comprises determining the updated security key by performing vertical key derivation based on a determination that the security key relationship information indicates that vertical key derivation is required.

12. The method of claim 9, wherein the method further comprises deriving the updated security key based on an AMF key based on a determination that the security key relationship information indicates that an AMF-based security key update is required.

13. The method of claim 8, wherein the performance of the cell switch from the source cell to the target cell comprises application of the configuration information to the target cell.

14. The method of claim 8, wherein the transmission comprises an indication that indicates that the cell switch has been performed.