Techniques associated with switching between layer 1 / layer 2-based connection resumption and radio resource control (RRC)-based connection resumption

Abstract

Systems, methods, and instrumentalities are disclosed herein for switching between Layer 1 / Layer 2-based connection resumption and radio resource control (RRC)-based connection resumption. A device may, while operating in a first activity level, receive, from a network, information associated with operations in a second activity level, wherein the information indicates first configuration information associated with a first radio access network (RAN) area and second configuration information associated with a second RAN area; transition to operating in the second activity level; based on a connection resumption condition being satisfied, determine to transition from operating in the second activity level to operating in the first activity level; determine signaling to use in a connection resumption procedure based on whether the device resumes a connection in a cell within the first RAN area or within the second RAN area; and perform the connection resumption procedure using the determined signaling.

Description

TECHNIQUES ASSOCIATED WITH SWITCHING BETWEEN LAYER 1 / LAYER 2-BASED CONNECTION RESUMPTION AND RADIO RESOURCE CONTROL (RRC)-BASED CONNECTION RESUMPTIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 445,531 , filed February 14, 2023, 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, devices, and instrumentalities are described herein related to switching between Layer 1 / Layer 2-based connection resumption and radio resource control (RRC)-based connection resumption.

[0004] A device (e.g., a wireless transmit / receive unit (WTRU)) may be configured to, while operating in a first activity level, receive, from a network, information associated with operations in a second activity level. The information may indicate first configuration information associated with a first radio access network (RAN) area and second configuration information associated with a second RAN area. The device may transition to operating in the second activity level. Based on a connection resumption condition being satisfied, the device may determine to transition from operating in the second activity level to operating in the first activity level. The device may determine signaling to use in a connection resumption procedure. The signaling may be determined based on the received information and whether the WTRU resumes a connection in a cell within the first RAN area or within the second RAN area. The device may perform the connection resumption procedure using the determined signaling. Performing the connection resumption procedure may include a transition from operating in the second activity level to operating in the first activity level.

[0005] On a condition that the device determines to resume the connection in the cell within the first RAN area, the device determine to use Layer 1 / Layer 2 (L1 / L2) signaling in the connection resumptionprocedure. On a condition that the device determines to resume the connection in the cell within the second RAN area, the device may determine to use radio resource control (RRC) signaling in the connection resumption procedure.

[0006] The device may determine whether to resume the connection in the cell within the first RAN area or within the second RAN area. The first RAN area may have priority over the second RAN area or the second RAN area may have priority over the first RAN area. The device may determine whether to resume the connection in the cell within the first RAN area or within the second RAN area based on the priority.

[0007] The device may receive a random access response from a network entity. The device may send identification information to the network entity, wherein the identification information indicates at least one of: a WTRU identifier of the WTRU, or a cell identifier of the cell in which the WTRU determines to resume the connection.

[0008] The connection resumption condition may be satisfied if the WTRU receives at least one of: uplink data or a paging indication associated with downlink data arrival. The first configuration information associated with the first RAN area may include a first list of cells within the first RAN area, and the second configuration information associated with the second RAN area may include a second list of cells within the second RAN area.

[0009] The device may receive an activity level indication from a network entity. The determination to transition to operating in the second activity level may be based on the activity level indication. Transitioning to operating in the second activity level may include applying the information.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0011] 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.

[0012] 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.

[0013] 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.

[0014] FIG. 2 illustrates an example of RRC connection establishment / setup.

[0015] FIG. 3 illustrates an example of a technique to resume a connection.

[0016] FIG. 4 illustrates an example of RRC states and the transitions between RRC states.

[0017] FIG. 5 illustrates an example L1 / L2 triggered mobility (LTM) using carrier aggregation (CA).

[0018] FIG. 6 illustrates an example LTM baseline procedure.DETAILED DESCRIPTION

[0019] 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.

[0020] 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.

[0021] 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 communicationnetworks, 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.

[0022] 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, i.e., 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.

[0023] 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).

[0024] 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).

[0025] 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 airinterface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0026] 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).

[0027] 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).

[0028] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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 Specific Integrated 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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 118may 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).

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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 transmission and 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)).

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

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

[0053] 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.

[0054] 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 the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 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 / ordetermined 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.

[0055] 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.

[0056] 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).

[0057] 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).

[0058] 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 isbusy, 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.

[0059] 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.

[0060] 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.

[0061] 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).

[0062] 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).

[0063] 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 otherRANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of 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.

[0064] 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.

[0065] 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.

[0066] The AMF 182a, 182b may be connected to one or more of the 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.

[0067] 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 UE 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, Ethernetbased, and the like.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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 devices may 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 performing testing using over-the-air wireless communications.

[0072] 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.

[0073] Feature(s) associated with RRC connection states and state transitions are provided herein.

[0074] A wireless transmit / receive unit (WTRU) (e.g., a WTRU in new radio (NR)) may be in one of the following three RRC states: RRC_CONNECTED (also sometimes referred to as “CONNECTED mode”); RRCJNACTIVE (also sometimes referred to as "INACTIVE mode”); or RRCJDLE (also sometimes referred to as “IDLE mode”).

[0075] In RRC_CONNECTED, the WTRU may be actively connected to the network, with signaling and data radio bearers (SRB and DRBs) established. In RRC_CONNECTED, the WTRU may be able to receive downlink (DL) data from the network in a unicast fashion and may be able to send uplink (UL) data to the network. The mobility of the WTRU from one cell / node to another may be controlled by the network. The network may configure the WTRU to send measurement reports periodically or if certain conditions are fulfilled (e.g., a neighbor cell becomes better than a serving cell by more than a certain threshold). Based on these reports, the network may send the WTRU a handover command to move the WTRU to another cell / node. The network may configure a conditional handover (CHO), in which case the WTRU may execute a preconfigured handover command if certain conditions are fulfilled (e.g., instead of sending a measurement report). The network may send the WTRU a HO command without receiving a measurement report (e.g., based on implementation, such as the determination of current location).

[0076] Keeping the WTRU in CONNECTED mode may be power-intensive for the WTRU (e.g., the WTRU needs to continuously monitor the PDCCH of the serving cell, for example, for determining the arrival of DL data, for UL data scheduling, etc.), and a certain cell / gNB may be able to accommodate a certain number of WTRUs in CONNECTED mode (e.g., due to resource limitations). As such, when there is no activity in the UL or DL for a certain duration (e.g., based on an inactivity timer kept at the network), the network may send the WTRU to the RRCJNACTIVE or RRCJDLE state.

[0077] If the network expects the WTRU to become active for a long duration, the network may send the WTRU to RRCJDLE state. While in RRCJDLE, the WTRU may camp at a cell (e.g., the best cell, for example, the cell with the best signal level at the highest priority RAT and highest priority frequency within that RAT), that will facilitate the WTRU establishing the connection via that cell if a need arises for the WTRU to transition back to the CONNECTED state. The WTRU may monitor the downlink paging channel to detect for DL data arrival. The WTRU may initiate the connection setup / establishment procedure if the WTRU detects a paging from the network indicating an arrival of a DL data or if the WTRU needs to send an UL data.

[0078] During connection setup or resume, the WTRU may (e.g., may first) perform a random access (RA) procedure (also sometimes referred to as Random Access Channel, RACH, procedure) before sending the RRCSetupRequest or the RRCResumeRequest message. The RA procedure may serve one or more (e.g., two) purposes: get UL synchronization between the WTRU and the network (e.g., gNB); and obtain the resources that are to be used for the sending of the request message.

[0079] During the RA procedures, the WTRU may send a message on the RACH (sometimes referred to as msg1), that includes a Preamble and an RA-RNTI (Random Access - Radio Network Temporary Identifier) to the gNB. In the case of contention-based random access (CBRA), the preamble may be randomly selected out of a set of possible preamble values (e.g., there could be a contention if another WTRU initiates a random access procedure using the same preamble value). In the case of contention-free random access (CFRA), a specific preamble may be provided to the WTRU beforehand (e.g., when the WTRU was in CONNECTED state, during the transition to the I DLE / I NACTIVE state, etc.). The RA-RNTI may be calculated based on the PRACH (physical RACH) occasion at which the random access message is to be sent to the network.

[0080] The gNB (e.g., upon receiving msg1) may respond with msg2, which may include a Random Access Response (RAR). For the WTRU to get the RAR, the network may send a DCI (Downlink Control Indicator) in the PDCCH that is scrambled with the RA-RNTI, which may be used by the WTRU to determine the resources (i.e., time and frequency) one which the RAR (and other related information) is provided to the WTRU. The WTRU may try to detect the DCI within a period of time after sending the preamble (sometimes referred to as the RAR-window). If the DCI is not received, the WTRU may retransmit the preamble again. If the DCI is received, the WTRU may get the RAR at the indicated time and frequency resources in the PDSCH. In the RAR and associated information, the WTRU may be provided with the timing advance (TA) to apply for sending UL data, the TC-RNTI (temporary Cell RNTI), and the UL resources to send the setup / resume request message.

[0081] The WTRU may receive detailed information / configuration regarding the usage of the random access channel (e.g., such as RACH occasion, random access response window, etc.) via a dedicated configuration while in the CONNECTED state, upon transitioning during an IDLE / INACTIVE state, or from system information broadcast (SIB).

[0082] FIG. 2 illustrates an example RRC connection establishment / setup. FIG. 3 illustrates an example technique for resuming a connection.

[0083] The term msg3 may refer to RRCResumeRequest or RRCSetupRequest. The term msg4 may refer to RRCResume or RRCSetup. The term msg5 may refer to RRCResumeComplete or RRCSetupComplete.

[0084] If the WTRU resumes the connection in the same gNB, messages 2, 3, and 6 to 9 may not be required. As such, the WTRU may resume the connection without involving the Core Network (CN).

[0085] As illustrated in FIG. 2, the RRC connection setup may require several round trip times to complete and involves the CN. This is because when the WTRU goes to IDLE mode, the WTRU’s RRC context is released, and as such the WTRU is not known at the RAN level, and the RAN has to get the WTRU context from the CN. Security may have to be re-established and the WTRU may be reconfigured with the DRBs and SRBs, before UL / DL data transmission / reception could occur.

[0086] The setup procedure may not be compatible with low latency services. An intermediate state between the CONNECTED and IDLE state, known as the INACTIVE state may be used for low latency services. This state has most of the power saving advantages of the IDLE state (e.g., WTRU does not need to continuously monitor the PDCCH, which is one of the most power-consuming procedures in the CONNECTED state), but at the same time, the RAN may keep the WTRU’s RRC / security context. If the WTRU transitions to the CONNECTED mode (e.g., due to the arrival of UL data or the reception of a paging indicating the arrival of DL data), the connection may be resumed (e.g., quickly), without involving the CN, re-establishing the WTRU’s security context, and reconfiguring the radio bearers.

[0087] FIG. 4 illustrates the different RRC states and the transitions between the RRC states.

[0088] If the WTRU performs the connection setup / establishment or resume procedure, the WTRU may include (e.g., in the RRCSetupRequest or RRCResumeRequest) the establishment or resume cause. For example, the following causes may be defined.ResumeCause ::=ENtJ ERATEi {emergency, highPriorityAccess, mt-Access, mo-Signalling,mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, rna-Update, mps-PriorityAccess,mcs-PriorityAccess,sparel, spare2, spares,

[0089] For example, if the connection is being setup / resume due to a voice call or video call originating from the WTRU, the WTRU may set the establishment / resume cause to mo-VoiceCall (mobile originated voice call) or mo-VideoCall (mobile originated video call). If the connection is being setup / resumed due to downlink paging indicating DL data, the WTRU may set the establishment / resume cause to one of mt- Access (mobile terminated access), highPriorityAccess, mps-PriorityAccess, or mcs-PriorityAccess (e.g., depending on the access category of the WTRU).

[0090] If the WTRU is sent to INACTIVE state, the network may include in the RRCRelease message a suspendConfig. The SuspendConfig may include information such as, for example, the resumeidentity to be used by the WTRU (e.g., a short identity, shortl-RNTI, a long identity, full-RNTI, and / or the like). The WTRU may determine which identity to use based on the system information broadcast in the target cell (e.g., if useFullResumelD is indicated in the SIB, use the long identity, otherwise, use the short identity).

[0091] The SuspendConfig may include information such as, for example, the RAN paging area (e.g., list of cells. The RAN paging area is the RAN area where the WTRU can be paged at RAN level. If the WTRU performs cell reselection to a cell outside the RAN area, WTRU may perform a RAN area update procedure. This procedure may sometimes be referred to as a 2-step resume procedure, where the WTRU sends an RRC Resume request including a cause value of “rna-Update” and the network responding with an RRC Release message including a new RAN area.

[0092] The SuspendConfig may include information such as, for example, nextHopChaining count. The nextHopChaining count may be used for deriving the security context (e.g., encryption / integrity protection keys) upon resuming the connection. The SuspendConfig may include information such as, for example, inter-cell L1 / L2 triggered mobility (LTM).

[0093] Inter-cell beam management may be used to manage the beams in the case of CA, but no cell change / add may be supported.

[0094] Feature(s) associated with L1 / L2-based inter-cell mobility for mobility latency reduction are provided herein.

[0095] Configuration and maintenance for one or more candidate cells may allow fast application of configurations for candidate cells [RAN2, RAN3].

[0096] Dynamic switching among candidate serving cells (including SpCell and SCell) may be based on L1 / L2 signaling [RAN2, RAN1],

[0097] Feature(s) associated with L1 enhancements for inter-cell beam management (e.g., including L1 measurement and reporting) and beam indication [RAN1 , RAN2] are provided herein.

[0098] Feature(s) associated with timing advance management [RAN1 , RAN2] are provided herein.

[0099] Feature(s) associated with CU-DU interface signaling to support L1 / L2 mobility, if needed [RAN3] are provided herein.

[0100] Feature(s) associated with FR2 specific enhancements are provided herein.

[0101] L1 / L2-based inter-cell mobility may be applicable to one or more of the following scenarios: Standalone, CA and NR-DC case with serving cell change within one CG; intra-DU case and intra-CU inter- DU case (e.g., applicable for Standalone and CA: no new RAN interfaces are expected); intra-frequency and inter-frequency; frequency 1 (FR1) and frequency 2 (FR2); and / or source and target cells may be synchronized or non-synchronized.

[0102] L1 / L2-based mobility and inter-cell beam management may be applicable to intra-DU and intra- frequency scenarios. The serving cell may remain unchanged (e.g., there may be no possibility to change the serving cell using L1 / L2 based mobility). In FR2 deployments, CA may be used to exploit the available bandwidth (e.g. to aggregate multiple CCs in one band). These CCs may be transmitted with the same analog beam pair (e.g., gNB beam and WTRU beam). The WTRU may be configured with TCI states (e.g., a large number of TCI states, for example, 64) for reception of PDCCH and PDSCH. Each TCI state may include an RS or SSB that the WTRU may refer to for setting its beam. The SSB may be associated with a non-serving PCI. MAC signaling (e.g., “TCI state indication for WTRU-specific PDCCH MAC CE”) may activate the TCI state for a Coreset / PDCCH. Reception of PDCCH from a non-serving cell may be supported by a MAC CE indicating a TCI state associated to non-serving PCI. MAC signaling (e.g., “TCI States Activation / Deactivation for WTRU-specific PDSCH”) may activate a subset of (e.g., up to) 8 TCI states for PDSCH reception. DCI may indicate which of the 8 TCI states. A “unified TCI state” with a different updating mechanism (e.g., DCI-based) may be supported, but may be without multi-TRP. A unified TCI state with multi-TRP may be supported.

[0103] LTM may improve handover latency. A (e.g., conventional) L3 handover or conditional the WTRU may send (e.g., may first send) a measurement report using RRC signaling. In response to the RRC signaling, the network may provide a further measurement configuration and potentially a conditional handover configuration. With a conventional 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, to reduce the handover failure rate due to the delay in sending a measurement report then receiving an RRC reconfiguration, the network may provide (e.g., in advance) a target cell configuration and a measurement criteria which determines if the WTRU should trigger the CHOconfi guration . L3 methods may suffer from some amount of delay due to the sending of measurement reports and receiving of target configurations, particularly in case of the conventional (non-conditional) handover.

[0104] LTM may allow 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, as inter-CU signaling may involve (e.g., require) relocation of the PDCP anchor. An RRC-based approach may be used to support inter-CU handover.

[0105] In L3 handover mechanisms, any currently active SCell(s) may be released before the WTRU moves completes the handover to a target cell in the coverage area of a new site, and may be (e.g., may only be) added back after successful handover, which leads to throughput degradation during handover. L1 / L2 may enable CA operation to be enabled instantaneously upon serving cell change.

[0106] FIG. 5 illustrates an example LTM using CA. The candidate cell group may be configured by RRC and a dynamic switch of PCell and SCell may be achieved using L1 / L2 signaling.

[0107] FIG. 6 illustrates an example LTM baseline procedure.

[0108] LTM may involve one or more of the following actions.

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

[0110] At 2, the gNB may transmit an RRCReconfiguration message to the WTRU including the configuration of one or multiple LTM candidate target cells.

[0111] At 3, the WTRU may store the configuration of LTM candidate target cell(s) and may transmit a RRCReconfigurationComplete message to the gNB.

[0112] At 4, the WTRU may perform DL synchronization and TA acquisition with candidate target cell(s) before receiving the LTM cell switch command. DL synchronization for candidate cell(s) may be performed before the cell switch command (e.g., based on SSB).

[0113] TA acquisition of candidate cell(s) may be performed before LTM cell switch command (e.g., based on PDCCH ordered RACH), where the PDCCH order may be (e.g., may only be) triggered by source cell.

[0114] At 5, the WTRU may perform L1 measurements on the configured LTM candidate target cell(s), and may transmit lower-layer measurement reports to the gNB.

[0115] At 6, the gNB may decide to execute LTM cell switch to a target cell, and may transmit a MAC CE triggering LTM cell switch by including the candidate configuration index of the target cell. The WTRU may switch to the configuration of the LTM candidate target cell.

[0116] At 7, the WTRU may perform random access procedure towards the target cell (e.g., if TA is not available).

[0117] At 8, the WTRU may indicate successful completion of the LTM cell switch towards target cell.

[0118] As described herein, the INACTIVE state may provide the power saving advantages of the IDLE state due to more relaxed measurement requirements and longer DRX. The INACTIVE state may avoid the drawback of high latency for transitioning to the CONNECTED state, as the WTRU context may be known at the RAN level and the CN does not have to be involved.

[0119] If a WTRU supports (and is configured with) L1 / L2 triggered mobility (LTM), the WTRU’s mobility can be controlled without involving the CU / RRC, leading to faster mobility control. Transitioning such a WTRU to the INACTIVE state for power saving (e.g., due to transmission / reception inactivity) and then back to the CONNECTED state (e.g., if there is DL / UL data for the WTRU) may involve the CU / RRC, according to the legacy NR state transition mechanisms (e.g., based on RRC Release and RRC Resume).

[0120] Feature(s) provided herein relate to transitioning the WTRU between INACTIVE and CONNECTED states, without involving (or at least minimizing the involvement of) the Central Unit (CU) and / or RRC.

[0121] Feature(s) provided herein may be applicable to scenarios where a base station is employing a split architecture (e.g., with a CU that terminates the PDCP / RRC protocols, and a Distributed Unit (DU) that terminates the lower layer protocols). Feature(s) provided herein may be applicable to scenarios where a base station is employing a non-split architecture (e.g., all protocols terminated at a centralized unit). In the split CU / DU architecture, some (e.g., most or all) of the functionalities that are related to connection suspension and resumption (e.g., context storing, L1 / L2 indication) may be performed (e.g., quickly) by the DU (e.g., without involving the CU).

[0122] The LTM framework (e.g., in which the WTRU’s mobility in CONNECTED state is controlled via L1 / L2 signaling) may be similar to the L1 / L2-based connection suspension / resumption solutions.Feature(s) provided herein may not use LTM. A WTRU may be capable of (or configured with) L1 / L2-based connection suspension / resumption, but not LTM, or vice versa.

[0123] The connection suspension may be triggered by the reception of an RRC Release message. The resumption may be performed via L1 / L2 signaling (e.g., without involving RRC signaling).

[0124] The connection suspension may be triggered via L1 / L2 signaling. The resumption may be performed via RRC signaling.

[0125] The configurations to be used by the WTRU for the INACTIVE state and when resuming the connection from the INACTIVE state may be provided to the WTRU in a dedicated manner (e.g., using WTRU-specific dedicated signaling) while the WTRU is in the CONNECTED state. One or more configuration(s) may be provided via broadcast (e.g., common to more than one WTRU) signaling. The dedicated and broadcasted information may include one or more comment elements (e.g., the WTRU may be provided with a set of parameters with parameter values in a dedicated manner, and the WTRU may be provided with broadcast information including the same set of parameters with different parameter values). If the dedicated and broadcasted information include one or more comment elements, the WTRU may be configured to use either the parameter values given in dedicated manner or the parameter values provided via broadcast information. Prioritization of the dedicated parameter values or the broadcast parameter values may be specified (e.g., in standard documents, for example, 3GPP RRC specifications).Prioritization of the dedicated parameter values or the broadcast parameter values may be (e.g., explicitly) indicated in L1 / L2 signaling for connection suspension or resumption (e.g., a flag in the indications indicating whether the WTRU prioritizes dedicated configuration or broadcasted configuration).

[0126] The terms INACTIVE state configuration and connection suspension configuration may be used interchangeably. The terms connection resumption configuration and CONNECTED state configuration may be used interchangeably.

[0127] Feature(s) associated with L1 / L2-triggered suspend / resume are provided herein.

[0128] A WTRU may be (pre-)configured with configuration(s) related to connection suspension and resumption. If the WTRU receives an L2 / L1 indication from the network to suspend the connection, the WTRU may transition to the INACTIVE state (e.g., by applying the stored configuration(s) related to connection suspension). If one or more condition(s) for resuming the connection are fulfilled, the WTRU may resume the connection (e.g., by applying the stored resumption related configuration and performing the required signaling via L2 / L1).

[0129] A WTRU may perform one or more of the following actions. While operating in a first activity level (e.g., CONNECTED state), the WTRU may receive a configuration (e.g., configuration information) associated with operations in a second activity level (e.g., INACTIVE state). While operating in a first activity level (e.g., CONNECTED state), the WTRU may receive configurations (e.g., configuration information) related to (e.g., associated with) operations in the first activity level after transitioning from the second activity level to the first activity level.

[0130] The WTRU may store the configuration and continue operating in the first activity level.

[0131] The WTRU may receive an indication to transition from operation in the first activity level to operation in the second activity level from the network (e.g., an L1 / L2 indication instructing the WTRU to transition from operating at the first activity level to operating at the second activity level). The WTRU may determine to transition to operation in the second activity level (e.g., based on the indication).The WTRU may save the configuration(s) that were being used during operations in the first activity level. The WTRU may save the configuration(s) related to transitioning from the second activity level to the first activity level. The WTRU may transition to operating at the second activity level (e.g., by applying the stored second activity level configuration) based on the determination to transition to the second activity level.

[0132] The WTRU may determine to transition to operation in the first activity level. For example, while operating in the second activity level, the WTRU may determine that a transition condition is satisfied (e.g., the WTRU receives at least one of: uplink data or a paging indication of downlink data arrival). Based on the determination that the transition condition is satisfied, the WTRU may send, to the network entity, a request to transition from operation in the second activity level to operation in the first activity level. For example, if a condition for transitioning back to the first activity level is fulfilled (e.g., UL data arrival, paging indicating DL data arrival, etc.), the WTRU may send an L1 / L2 indication to the network requesting a transition back to the first activity level. The WTRU may receive an indication to transition from operation in the second activity level to operation in the first activity level (e.g., an L1 / L2 indication from the network instructing the WTRU to transition back to the first activity level). The WTRU may determine to transition to operation in the first activity level is based on the indication. The WTRU may restore the stored first activity level configuration. The WTRU may apply the configuration information associated with operations in the first activity level after transitioning from the second activity level to the first activity level (e.g., apply the stored configuration related to transitioning from the second activity level to the first activity level). The WTRU may send an indication (e.g., an L1 / L2 indication) to the network indicating the successful transition to the first activity level. The WTRU may start operating at the first activity level.

[0133] Feature(s) associated with reception of an INACTIVE state configuration (e.g., to be applied at a later time) are provided herein.

[0134] A WTRU, while in the CONNECTED state, may receive an INACTIVE state configuration (e.g., similar to the suspendConfig IE included the RRC Release message). The WTRU may store the configuration without applying it.

[0135] The WTRU may receive one or more INACTIVE state configuration (e.g., each INACTIVE state configuration may be identified by a configuration ID). The identification of the INACTIVE state configuration may be implicit (e.g., start with an ID of 0 or 1 for the first configuration, and subsequentlyincrement the ID for each additional configuration). The identification of the INACTIVE state configuration may be explicitly indicated in the configuration.

[0136] The WTRU may receive multiple INACTIVE state configurations in one message (e.g., a set / list of lEs). The WTRU may receive a message indicating that an INACTIVE state configuration is to be added to the current list / set of INACTIVE state configurations.

[0137] The WTRU may receive a message indicating to update (e.g., fully replace, partial / delta update, etc.) one or more stored INACTIVE state configuration(s).

[0138] The WTRU may receive a message that indicates one or more stored INACTIVE state configurations (e.g., all of the stored INACTIVE state configurations) are to be released / deleted.

[0139] The WTRU may receive a message that indicates an INACTIVE state configuration that is to be released / deleted from the current list / set of INACTIVE state configurations (e.g., including the configuration ID).

[0140] The WTRU may receive an INACTIVE state configuration that is to be stored and applied (e.g., at a later time) using the RRC Release message. The RRC Release message may include an indication / IE that indicates that the INACTIVE state configuration is to be stored and applied later (e.g., to differentiate from legacy INACTIVE state configuration that is to be applied immediately).

[0141] The WTRU may receive the INACTIVE state configuration(s) (e.g., that is / are to be stored and applied later) within an RRC reconfiguration message (e.g., in a suspendConfig I E / container / list).

[0142] The WTRU may compile the received INACTIVE state configuration(s) (e.g., test if the INACTIVE state configuration(s) are compatible with WTRU capability, if the INACTIVE state configuration(s) are compatible with the release of the specification that the WTRU is implementing, if the INACTIVE state configuration parameters correspond to a valid configuration / combination, etc.). The WTRU may send a confirmation message acknowledging the reception and successful compilation of the message. If the WTRU fails to compile the received configuration, the WTRU may send a message indicating the failure. The confirmation / failure indication message may be an L1 / L2 indication (e.g., MAC CE, UCI) or an RRC message.

[0143] The failure to compile the INACTIVE state configuration may be interpreted as a radio link failure (RLF). If the WTRU fails to compile the received configuration, the WTRU may trigger a recovery procedure (e.g., re-establishment).

[0144] The WTRU may remain in the CONNECTED state after a failure to compile the INACTIVE state configuration (e.g., the WTRU may not store the concerned INACTIVE state configuration, and may respond by sending the failure indication).

[0145] The WTRU may not compile the RRC Release configuration. The WTRU may store the RRC Release configuration. The WTRU may send a confirmation message acknowledging the message has been received (e.g., an RRC complete message).

[0146] Feature(s) associated with reception of a connection resumption configuration (e.g., to be applied at a later time) are provided herein.

[0147] A WTRU (e.g., while in the CONNECTED state) may receive a connection resumption configuration. The WTRU may store the configuration(s) (e.g., without applying the configuration(s)).

[0148] The WTRU may receive one or more connection resumption configurations (e.g., each identified by a configuration ID).

[0149] The identification of the connection resumption configuration may be implicit (e.g., start with an ID of 0 or 1 for the first connection resumption configuration, and subsequently increment the ID for each additional connection resumption configuration). The identification of the connection resumption configuration may be explicitly indicated (e.g., in the configuration).

[0150] The WTRU may receive one or more connection resumption configurations in a message (e.g., a set / list of lEs in one message).

[0151] The WTRU may receive a message indicating that a connection resumption configuration is to be added to the current list / set of connection resumption configurations. The WTRU may receive a message indicating for the WTRU to update (e.g., fully replace, partial / delta update, etc.) one or more stored connection resumption configuration(s). The WTRU may receive a message that indicates that one or more (e.g., all) of the stored connection resumption configurations are to be released / deleted. The WTRU may receive a message that indicates a connection resumption configuration is to be released / deleted from the current list / set of connection resumption configurations (e.g., including the configuration ID).

[0152] The WTRU may compile the received connection resumption configuration(s) (e.g., test if the connection resumption configuration(s) are compatible with WTRU capability, if the connection resumption configuration(s) are compatible with the release of the specification that the WTRU is implementing, if the connection resumption configuration parameters correspond to a valid configuration / combination, etc.). The WTRU may send a confirmation message acknowledging the reception and successful compilation of the message. If the WTRU fails to compile the received configuration, the WTRU may send a message indicating the failure. The confirmation / failure indication message may be an L1 / L2 indication (e.g., MAC CE, UCI) or an RRC message.

[0153] The failure to compile the connection resumption configuration may be interpreted as an RLF. The WTRU may trigger a recovery procedure (e.g., re-establishment).

[0154] The WTRU may remain in the CONNECTED state after a failure to compile the connection resumption configuration (e.g., the WTRU may not store the concerned connection resumption configuration, and may respond by sending the failure indication).

[0155] The WTRU may not compile the connection resumption configuration (e.g., and may store the connection resumption configuration). The WTRU may send a confirmation message acknowledging the message has been received (e.g., an RRC complete message).

[0156] The connection resumption configuration may be received together with the INACTIVE state configuration (e.g., within the same RRC message, within the same container information element, etc.). The connection resumption configuration may be received separately from the INACTIVE state configuration (e.g., in a separate RRC message).

[0157] For each INACTIVE configuration, the WTRU may be configured with a corresponding connection resumption configuration. The WTRU may be configured with more connection resumption configurations than INACTIVE configurations. The WTRU may be configured with more INACTIVE configurations than connection resumption configurations.

[0158] The WTRU may be configured with a mapping between a resumption configuration and one or more INACTIVE configuration(s) (e.g., resumption configuration 1 to be used when resuming the connection after being suspended with INACTIVE configurations 1 and 2, resumption configuration 2 to be used when resuming the connection after being suspended with INACTIVE configuration 3, etc.).

[0159] The relation between the INACTIVE state configurations and the connection resumption configuration may be implicit (e.g., a WTRU suspended with INACTIVE state configuration with ID x will use connection resumption configuration with ID y, where y=x, etc.)

[0160] Feature(s) associated with contents of the INACTIVE state configuration are provided herein.

[0161] The received INACTIVE state configuration may include one or more WTRU identities (e.g., to be used by the WTRU to identify itself when the connection is resumed).

[0162] The received INACTIVE state configuration may include a paging cycle. The paging cycle may indicate the periodicity (e.g., every x sub frames, or every y milliseconds) at which the WTRU monitors (e.g., needs to monitor) the paging channel (e.g., for checking if any DL data has arrived for the WTRU).

[0163] The received INACTIVE state configuration may include a RAN notification area (e.g., a list of cells, a list of carriers, a list of PLMNs, etc.) that indicates the area in which the INACTIVE state configuration is applicable.

[0164] The received INACTIVE state configuration may include one or more timers related to the WTRU behavior in the INACTIVE state. For example, the received INACTIVE state configuration may include atimer associated with RAN area notification update indicating the periodicity at which the WTRU will send (e.g., needs to send) a RAN area notification update.

[0165] The INACTIVE state configuration(s) may be independent (e.g., separate configurations).

[0166] The INACTIVE state configuration(s) may have a common part and a dedicated part. For example, the received INACTIVE state configuration may be structured as: common parts (e.g., first information element, second information element, etc.), and dedicated parts (e.g., Configuration 1 : ID, first information element, second information element, etc.; Configuration 2: ID, first information element, second information element, etc.; and / or the like).

[0167] Feature(s) associated with contents of the connection resumption configurations are provided herein.

[0168] The one or more connection resumption configurations may contain information (e.g., all or most of the information) that is available in the legacy RRC Resume message (e.g., including information such as radio bearer configuration, measurement configuration, security configuration, cell group configuration, indication to apply full or delta configuration, etc.).

[0169] The connection resumption configuration(s) may be independent (e.g., separate configurations).

[0170] The connection resumption configuration(s) may have a common part and a dedicated part. For example, the received connection resumption configuration may be structured as: common parts (e.g., first information element, second information element, etc.), and dedicated parts (e.g., Configuration 1 : ID, first information element, second information element, etc.; Configuration 2: ID, first information element, second information element, etc.; and / or the like).

[0171] A RAN notification area (e.g., each RAN notification area) may be associated with a connection resumption configuration. The WTRU may be configured with a list of RAN notification area(s) and corresponding configuration(s) to apply for a given RAN notification area.

[0172] Feature(s) associated with reception of an L1 / L2 indication to suspend the connection are provided herein.

[0173] The WTRU may receive an indication to suspend the connection. The indication may be an L2 or an L1 indication (e.g., a MAC CE, DCI, etc.). The WTRU may apply the stored INACTIVE state configuration and transition to the INACTIVE state.

[0174] If the WTRU has been configured and has stored more than one INACTIVE state configuration, the L2 / L1 indication may include an identification of the INACTIVE state configuration for the WTRU to apply if the connection is suspended.

[0175] If the WTRU has been configured and has stored more than one INACTIVE state configuration, and if the WTRU receives an L1 / L2 indication to suspend the connection, the WTRU may determine (e.g., based on a preconfigured association between a current (e.g. CONNECTED) configuration and an INACTIVE state configuration) an identification of the INACTIVE state configuration for the WTRU to apply if the connection is suspended. For example, one or more INACTIVE state configurations (e.g., each stored INACTIVE state configuration) may be associated with one or more cells, bandwidth parts, measurement resources, connected mode DRX cycles, service types or QCI / 5QI values, a number of active radio bearers, an inactivity time, and / or any other part of the WTRU configuration.

[0176] The WTRU may not send a response to the received indication to suspend the connection. For example, lower layer ACK reception for the message from the WTRU may be interpreted by the network to mean that the WTRU has (e.g., properly) applied the configuration.

[0177] The WTRU may send a response (e.g., an explicit response) to the indication to suspend the connection (e.g., before transitioning to the INACTIVE state). For example, the WTRU may send an L1 / L2 indication (e.g., a response MAC CE, or UCI) as a response to the indication to suspend the connection.

[0178] If the WTRU experiences a failure in compiling and / or executing the INACTIVE configuration (e.g., the configuration was not previously compiled / tested when initially received, or the WTRU conditions / configurations have changed since the configuration was initially compiled / tested and the configuration cannot be compiled / executed properly now), the WTRU may respond with a failure indication message (e.g., RRC reconfiguration failure message). The failure indication message may be an L1 / L2 indication (e.g., MAC CE, UCI) or an RRC message.

[0179] The failure to compile / execute the saved INACTIVE configuration may be interpreted as an RLF. The WTRU may trigger a recovery procedure (e.g., re-establishment).

[0180] The WTRU may remain in the CONNECTED state after a failure to compile / execute the saved INACTIVE configuration. The WTRU may release / delete the configuration. The WTRU may inform the network about the failure.

[0181] The WTRU (e.g., upon transitioning to the INACTIVE state) may maintain / save all or part of the WTRU configuration that was being used during the CONNECTED state (e.g., measurement configuration, security configuration, bearer configuration, identities, cell group configurations, PHY / MAC level configurations, etc.). The WTRU configuration that was being used during the CONNECTED state and is saved by the WTRU may be referred to as WTRU INACTIVE state context or saved WTRU CONNECTED state context.

[0182] The WTRU may (e.g., upon transitioning to the INACTIVE state) release / reset one or more buffers that we were used at different protocol layers (e.g., MAC level buffers, RLC buffers, PDCP buffers,etc.). The WTRU may (e.g., upon transitioning to the INACTIVE state) reset the variables / parameters that control the operations of the transmit / receive entities of the different protocol layers (e.g., RLC state variables, PDCP state variables, counters, timers, etc.).

[0183] The WTRU may (e.g., upon transitioning to the INACTIVE state) suspend / pause some of the CONNECTED state activities (e.g., performing RRM measurements, monitoring of PDCCH, etc.). The WTRU may (e.g., upon transitioning to the INACTIVE state) start one or more new INACTIVE state activities (e.g., monitor paging channel, perform measurements for cell reselection, perform idle mode measurements, etc.).

[0184] Feature(s) associated with resumption of the connection are provided herein.

[0185] If the WTRU detects the arrival of UL data while in the INACTIVE state, the WTRU may trigger the resumption of the connection.

[0186] If the WTRU receives an indication from the network (e.g., a paging information signifying the arrival of DL data for the WTRU), the WTRU may trigger the resumption of the connection.

[0187] If the WTRU detects that the WTRU has performed a cell reselection to a cell that is not part of the configured RAN area for the INACTIVE state, the WTRU may trigger the resumption of the connection.

[0188] The WTRU may trigger the resumption of the connection by (e.g., first) initiating a RACH procedure and sending an L1 / L2 connection resume request (e.g., MAC CE, UCI, etc.). The WTRU may trigger the resumption of the connection after reception of a random access response from the network.

[0189] The WTRU may (e.g., implicitly) indicate an L1 / L2 connection resume request by selecting from one or more preambles or random access resources which have been reserved or indicated as being applicable for this purpose (e.g., a set of preambles or resources that, if selected, indicate a WTRU is attempting an L1 / L2 connection resume request).

[0190] The WTRU may be assigned a specific random access preamble and / or PRACH resource to be used to identify the WTRU when attempting a L1 / L2 connection resume request.

[0191] The WTRU may include the cause for the resumption (e.g., UL data arrival, DL data arrival, RAN area update, etc.) in the resume request (e.g., in a 2-bit header in the MAC CE).

[0192] The WTRU may include a WTRU identity in the L1 / L2 connection resume request. The WTRU identity (e.g., included in the L1 / L2 connection resume request) may be the C-RNTI with which the WTRU was configured (e.g., while the WTRU was in CONNECTED mode). The identity (e.g., included in the L1 / L2 connection resume request) may be a WTRU identity that was provided as part of the INACTIVE state configuration that was applied by the WTRU (e.g., upon transitioning to the INACTIVE state).

[0193] The WTRU may include a preferred connection resumption configuration (e.g., a connection resumption configuration identity).

[0194] The WTRU may send the L1 / L2 connection request as part of MsgA in a 2-step RACH procedure.

[0195] The WTRU (e.g., after sending an L1 / L2 connection resume request) may receive L1 / L2 signaling (e.g., MAC CE, DCI, etc.) that indicates for the WTRU to resume the connection. The indication may include an identity of the connection resumption configuration for the WTRU to apply. The WTRU may send an acknowledgement that the WTRU received the L1 / L2 signaling. The acknowledgment may be sent in a PUCCH. One or more PUCCH resource(s) may be (pre)configured. One or more of the configured PUCCH resources may be indicated (e.g., in the L1 / L2 signaling, for example, DCI). One or more PUCCH resource(s) may be (pre)configured and / or specified.

[0196] The WTRU (e.g., after sending an L1 / L2 connection resume request) may receive L1 / L2 signaling (e.g., MAC CE, DCI, etc.) that indicates to the WTRU to resume the connection. The WTRU (e.g., after sending an L1 / L2 connection resume request) may receive an indication indicating for the WTRU to restore the saved connected state WTRU configuration / context upon connection suspension (e.g., not apply a saved connection resumption configuration). The absence of a connection resumption configuration identity in the received indication may be interpreted as an indication to restore the saved connected state WTRU configuration / context.

[0197] The WTRU (e.g., after sending a preamble reserved for indicating an L1 / L2 resume request) may receive a random access response (RAR) indicating for the WTRU to resume the connection. The WTRU (e.g., after sending a preamble reserved for indicating an L1 / L2 resume request) may receive an indication of one or more parameters to apply as part of the RAR.

[0198] The WTRU (e.g., after sending an L1 / L2 connection resume request) may receive L1 / L2 signaling (e.g., MAC CE, DCI, RAR, etc.) that indicates for the WTRU to resume the connection. The WTRU may determine (e.g., implicitly determine) the resume configuration to apply (e.g., using a mapping between the INACTIVE state configuration and resumption configurations that was received while the WTRU was in the CONNECTED state).

[0199] The WTRU may send an L1 / L2 resume request message to the network. The reason for (e.g., cause of) the resume request may be a RAN notification area update (e.g., to a new RAN notification area). The WTRU may receive an indication to apply the configuration corresponding to the new RAN notification area. The indication may be an implicit indication. For example, the indication may be an acknowledgement of the WTRU resume request message and / or a response to the WTRU resume request message.

[0200] If the WTRU indicates a preferred connection resumption configuration in the connection resumption request, the network may (e.g., implicitly) indicate acceptance of the WTRU’s request (e.g., and preferred connection resumption configuration) by not including a connection resumption configuration ID in the connection resume indication.

[0201] If the WTRU indicates a preferred connection resumption configuration in the connection resumption request, the network may (e.g., explicitly) indicate the acceptance of the WTRU’s request by including the concerned (e.g., preferred) connection resumption configuration ID in the connection resume indication. If the WTRU indicates a preferred connection resumption configuration in the connection resumption request, the network may (e.g., explicitly) indicate the acceptance of the WTRU’s request by including an ACK indication in the message (e.g., setting a Boolean field in the MAC CE header to 1).

[0202] The network may reject the WTRU’s request (e.g., for the preferred connection resumption configuration) and may respond with an indication of a different connection resumption configuration identity.

[0203] The WTRU may apply the indicated / determined connection resumption configuration (e.g., in addition to the saved connected state configuration, for example, as in applying any delta configuration).

[0204] The WTRU may apply the indicated / determined connection resumption configuration (e.g., the full configuration, where the saved connected state configuration is released first).

[0205] The WTRU may determine to apply a delta configuration or a full configuration based on an indication / flag in the connection resumption configuration being applied (e.g., apply full configuration if the concerned connection resumption configuration includes a flag that indicates full configuration, apply delta configuration if the connection resumption configuration does not include the full configuration flag, and / or the like).

[0206] The WTRU may determine to apply a delta configuration or a full configuration based on an indication / flag in the L2 / L1 message (e.g., received from the network) that indicated for the WTRU to resume the connection.

[0207] The WTRU (e.g., after restoring the saved connected WTRU configuration and / or applying the indicated / determined connection resumption configuration) may send an L1 / L2 indication that the connection has been resumed.

[0208] The WTRU may restore the saved connected state WTRU context and / or apply a stored connection resumption configuration (e.g., instead of sending a L1 / L2 resume request after the completion of the RACH procedure). The WTRU may send (e.g., directly send) an L1 / L2 message to the network indicating that the connection has been resumed.

[0209] The WTRU may send the L1 / L2 connection resumption confirmation as part of a message (e.g., MsgA) in a 2-step RACH procedure (e.g., if the WTRU performs the resumption without first sending a request to resume the connection as described herein).

[0210] The WTRU (e.g., after sending an L1 / L2 connection resume request) may receive an RRC Resume message (e.g., instead of a L1 / L2 indication). For example, the network may have decided to transition the WTRU to the CONNECTED state using legacy mechanisms (e.g., the network may update the WTRU configuration to be used in the CONNECTED state, and the updated configuration may not have been provided to the WTRU in the stored connection resumption configuration). In this case, the WTRU may follow another (e.g., legacy) procedure to finalize the resumption of the connection (e.g., apply the configuration included in the RRC Resume message, send an RRC Resume complete message, etc.).

[0211] Feature(s) associated with security (e.g., for L1 / L2-based connection suspension and resumption) are provided herein.

[0212] If the WTRU is performing the L1 / L2-based connection suspension and resumption (e.g., based on any of the techniques described herein), the WTRU may not change the security context (e.g., the keys, algorithms, and / or the like that the control plane (CP) or user plane (UP) may have used for integrity protection and encryption before the WTRU got suspended may be reused if the WTRU connection is resumed).

[0213] If the WTRU is performing the L1 / L2-based connection suspension and resumption (e.g., based on any of the techniques described herein), the WTRU may change the security context (e.g., as in legacy RRC-based connection suspension and resumption). For example, the keys that the CP or UP may have used for integrity protection and encryption may be updated upon resumption (e.g., based on information included in the INACTIVE state configuration or connection resumption configuration).

[0214] If the WTRU is performing the L1 / L2-based connection suspension (e.g., based on any of the techniques described herein), the WTRU may not change the security context for the UP while the CP security context is updated. If the WTRU is performing the L1 / L2-based connection suspension (e.g., based on any of the techniques described herein), the WTRU may not change the security context for the CP while the UP security context is updated.

[0215] If the WTRU is performing the L1 / L2-based connection suspension (e.g., based on any of the techniques described herein), the WTRU may not change the security keys related to encryption of data. If the WTRU is performing the L1 / L2-based connection suspension (e.g., based on any of the techniques described herein), the WTRU may update the security keys related to integrity protection.

[0216] If the WTRU is performing the L1 / L2-based connection suspension (e.g., based on any of the techniques described herein), the WTRU may not change the security keys related to integrity protection ofdata. If the WTRU is performing the L1 / L2-based connection suspension (e.g., based on any of the techniques described herein), the WTRU may update the security keys related to encryption.

[0217] Feature(s) associated with switching between L1 / L2-based connection resume and RRC-based connection resume are provided herein.

[0218] A WTRU may be (pre-)configured with an INACTIVE state-related configuration that includes one or more (e.g., two) RAN area configurations. The WTRU may determine to resume the connection using L1 / L2 signaling or RRC signaling based on whether the cell where the WTRU resumes the connection belongs within a first RAN area or a second RAN area.

[0219] A WTRU may perform one or more of the following actions.

[0220] While operating in a first activity level (e.g., CONNECTED state), the WTRU may receive information (e.g., configuration information) associated with operations in a second activity level (e.g., INACTIVE state). The configuration information may include one or more (e.g., two) RAN area configurations (e.g., lists of cells, for example, first configuration information associated with a first RAN area comprising a first list of cells within the first RAN area and second configuration information associated with a second RAN area comprising a second list of cells within the second RAN area). The WTRU may store the configuration information. The WTRU may continue operating in the first activity level.

[0221] The WTRU may receive an indication from a network entity that indicates an activity level (e.g., that indicates an activity level for the WTRU to transition to / operate in). The WTRU may determine to transition to operating in the second activity level based on the activity level indication. For example, the WTRU may receive an L1 or L2 indication from the network indicating (e.g., instructing) the WTRU to transition from operating at the first activity level to operating at the second activity level.

[0222] The WTRU may save the configuration information that were being used during operations in the first activity level.

[0223] The WTRU may transition to operating in the second activity level (e.g., by applying a stored configuration information, for example, associated with one of the RAN area configurations, such as first configuration information associated with a first radio access network (RAN) area or second configuration information associated with a second RAN area).

[0224] If the WTRU performs cell reselection to a cell that does not belong to the first RAN area or the second RAN area, the WTRU may perform a RAN area update procedure (e.g., legacy RAN area update using 2-step resume).

[0225] Based on a connection resumption condition being satisfied, the WTRU may determine to transition from operating in the second activity level to operating in the first activity level. The WTRU maydetermine signaling to use in a connection resumption procedure. The signaling may be determined based on the information (e.g., configuration information) and whether the WTRU is resuming a connection in a cell within the first RAN area or within the second RAN area. For example, if the connection resumption condition (e.g., a condition for transitioning back to the first activity level) is fulfilled / satisfied (e.g., UL data arrival, paging indicating DL data arrival, etc.), and if the WTRU determines to resume the connection in the cell within the first RAN area (e.g., the cell where the WTRU is resuming the connection belongs to the first RAN area), the WTRU may determine to use a first signaling type (e.g., L1 / L2 signaling) in the connection resumption procedure (e.g., perform the resume using L1 / L2 signaling).

[0226] The connection resumption condition may be satisfied if the WTRU: determines that uplink data is available (e.g., uplink data is to be sent) or receives a paging indication associated with downlink data arrival. If the connection resumption condition (e.g., a condition for transitioning back to the first activity level) is fulfilled / satisfied (e.g., UL data arrival, paging indicating DL data arrival, etc.), and if the WTRU determines to resume the connection in the cell within the second RAN area (e.g., the cell where the WTRU is resuming the connection belongs to the second RAN area), the WTRU may determine to use a second signaling type (e.g., RRC signaling) in the connection resumption procedure (e.g., perform the resume using RRC signaling).

[0227] While operating in a first activity level (e.g., operating in the CONNECTED state), a WTRU may receive information associated with operations in a second activity level (e.g., an INACTIVE state configuration, for example,, similar to the suspendConfig IE included in the RRC Release message). The information may indicate first configuration information associated with a first radio access network (RAN) area and second configuration information associated with a second RAN area (e.g., the information may include two RAN area configurations, for example,, lists of cells). The WTRU may store the configuration (e.g., without applying it). The WTRU may transition to operating in the second activity level. For example, if the WTRU receives (e.g., later receives) an L1 / L2 indication from the network (e.g., MAC CE, DCI, etc.) that indicates the suspension of the connection, the WTRU may apply the stored INACTIVE state configuration and may transition to the INACTIVE state. The WTRU may perform the connection resumption procedure (e.g., transition from operating in the second activity level to operating in the first activity level) using the determined signaling.

[0228] The WTRU may determine whether to resume the connection in a cell within the first RAN area or within the second RAN area. If the WTRU resumes the connection while the WTRU is camping in one of the cells that belong to the first RAN area, the WTRU may perform the connection resume request using L1 / L2 signaling. For example, the WTRU may send a MAC CE to request the resume after random access, receive a MAC CE from the network to resume the connection, and / or the like.

[0229] If the WTRU resumes the connection while the WTRU is camping in one of the cells that belong to the second RAN area, the WTRU may perform the connection resume request using a first type of signaling (e.g., legacy RRC signaling). For example, the WTRU may send an RRCResumeRequest message to request the resume after random access, receive an RRCResume message from the network to resume the connection, send an RRCResumeComplete message to confirm the resumption is complete, and / or the like.

[0230] In the INACTIVE state configuration, the WTRU may have different information (e.g., different information elements, different values for some information elements) associated with the first RAN area and the second RAN area. Within the first RAN area, the WTRU may be able to transition between the states using L1 / L2 signaling (e.g., the cells in this first area belong to the same node, DU, distributed unit). Within the second RAN area, the WTRU may not have the L1 / L2 resources / configurations available. In this case, the WTRU may rely on RRC state transitions (e.g., legacy L3 RRC state transitions). The WTRU may use the corresponding information when resuming in a cell belonging to the first RAN area (e.g., as compared to the second RAN area). For example, information that may be used for resuming the connection via a second type of signaling (e.g., L1 / L2 signaling) may be associated with the first RAN area, while information that may be used for resuming the connection via RRC signaling (e.g., resume identity, nextHopChaining count used for updating connected state UP / CP security keys, etc.) may be associated with the second RAN area.

[0231] If the WTRU performs cell reselection to a cell that does not belong to the first RAN area or the second RAN area, the WTRU may perform a RAN area update procedure (e.g., legacy RAN area update, for example, by sending an RRC Resume Request with the cause value set to RAN area update, and receiving an RRC Release message with a new / updated RAN area(s), etc.).

[0232] If the WTRU performs cell reselection to a cell that does not belong to the first RAN area but belongs to the second RAN area, the WTRU may send an L1 / L2 indication indicating that the WTRU is outside the first RAN area.

[0233] The WTRU may send the indication indicating that the WTRU is outside of the first RAN area before performing the concerned cell reselection. For example, the L1 / L2 indication may be sent while the WTRU is still in a cell that belongs to the first RAN area. To allow the WTRU to be able to send the indication before performing the cell reselection, the WTRU may be configured with a signal level threshold. The WTRU may send the indication via the source cell if (e.g., only if) the signal level of the source cell is above the configured threshold.

[0234] The WTRU may send the indication indicating that the WTRU is outside of the first RAN after performing the concerned cell reselection. For example, the indication may be sent if (e.g., when) the WTRU is camping in a cell that does not belong to the first RAN area.

[0235] The WTRU may receive a random access response from a network entity. The WTRU may perform a random access procedure and send the L1 / L2 indication after the reception of the random access response (e.g., regardless of whether the indication is sent before or after the WTRU performs the concerned cell reselection). The WTRU may send identification information to the network entity. For example, the identification information may indicate at least one of: a WTRU identifier of the WTRU (e.g., a WTRU identity, for example, resume identity, C-RNTI, etc.), a cell identifier of the cell in which the WTRU determines to resume the connection (e.g., a cell identity, for example, if the indication is sent before performing the cell reselection, the cell identity of the cell to which the WTRU is performing the cell reselection), and / or the like.

[0236] The WTRU may select a preamble sequence or resource (e.g., from a set of one or more (pre- )configured preamble sequences or resources) to indicate the L1 / L2 resume request and receive a response as part of the random access response (e.g., regardless of whether the indication is sent before or after the WTRU performs the concerned cell reselection).

[0237] The indication that the cell is outside of the first RAN area may help the network optimize the sending of RAN paging signaling. For example, since the network knows the WTRU is outside the first RAN area, the network may page the WTRU within (e.g., only within) the cells of the second RAN area.

[0238] If the WTRU performs cell reselection to a cell belonging to the first RAN area (e.g., after the WTRU has been in a cell outside the first RAN area), the WTRU may send an L1 / L2 indication indicating that the WTRU has returned to the first RAN area.

[0239] The first RAN area may have priority over the second RAN area or the second RAN area may have priority over the first RAN area. The WTRU may determine whether to resume the connection in the cell within the first RAN area or within the second RAN area is based on the priority. For example, the WTRU may be configured to prioritize cell reselection to cells within the first RAN area as compared to other cells (e.g., cells within the second RAN area, cells outside the first and second RAN areas, and / or the like). The WTRU may be configured with an offset to add to the measurements of cells within the first RAN area (e.g., if / when comparing cells for cell reselection). The WTRU may be configured with separate cell reselection priorities for cells within the first RAN area and cells within the second RAN area.

[0240] The WTRU may be configured to prioritize cell reselection to cells within the second RAN area as compared to other cells (e.g., cells outside the first RAN area and second RAN area). The WTRU may be configured with an offset to add to the measurements of cells within the second RAN area (e.g., if / whencomparing cells for cell reselection). The WTRU may be configured with separate cell reselection priorities for cells within the first RAN area, cells within the second RAN area, and cells that are not in the first RAN area or the second RAN area.

[0241] The WTRU may be configured with a first offset (e.g., offsetl) to add to the cell reselection measurements of cells belonging to the first RAN area, and a second offset (e.g., offset2, which may be less than offsetl) to add to the cell reselection measurements of cells belonging to the second RAN area. The WTRU may be configured with a first offset (e.g., offsetl) to add to the cell reselection priority of cells belonging to the first RAN area, and a second offset (e.g., offset2, which may be less than offsetl) to add to the cell reselection priority of cells belonging to the second RAN area.

[0242] Feature(s) associated with security of L1 / L2-based state transitions are provided herein.

[0243] A WTRU may receive configuration information from a network entity. The configuration information may indicate a first parameter value associated with a first message type and a second parameter value associated with a second message type. For example, the WTRU may be configured with one or more (e.g., multiple) parameters or parameter values related to security in a configuration related to connection suspension or resumption. The WTRU may use a first set (e.g., one set) of parameters or parameter values to calculate a security token to integrity protect an L1 / L2 resume request / resume complete indication. The WTRU may use a second set (e.g., another set) of parameters or parameter values to calculate a security token used to integrity verify L1 / L2 suspend / resume messages received from the network.

[0244] A WTRU may perform one or more of the following actions.

[0245] While operating in a first activity level (e.g., CONNECTED state), the WTRU may receive a configuration (e.g., configuration information) associated with operations in a second activity level (e.g., INACTIVE state) and resuming a connection with (e.g., back to) the first activity level. The configuration may include one or more parameters or parameter values related to security. The different parameters or parameter values may be (e.g., implicitly or explicitly) associated with different L1 / L2 messages used to suspend and resume a connection.

[0246] The WTRU may determine, for a first message of a first message type, a first security token based on the first parameter value. The WTRU may send the first message to the network entity. The first message may indicate the first security token. For example, if the WTRU sends an L1 / L2 indication to request a connection resumption or to indicate a connection resumption has been completed successfully, the WTRU may determine / calculate a security token based on the corresponding parameter or parameter value associated with the request message or the connection complete message. The WTRU may include the security token in the L2 / L1 indication (e.g., that the WTRU is sending). For example, the WTRU maysend the connection resumption message to the network, and the connection resumption message may indicate the security token (e.g., a first security token).

[0247] The WTRU may receive a second message of a second message type that indicates a connectivity action and a second security token. The device may determine a third security token based on the second parameter value. For example, if the WTRU receives an L1 / L2 indication from the network to suspend the connection or resume the connection and the indication includes a (e.g., second) security token, the WTRU may determine / calculate a (e.g., third) security token based on the corresponding parameter or parameter value associated with the suspend or resume message.

[0248] On a condition that the second security token is associated with (e.g., matches or can be determined based on) the third security token, the WTRU may perform the connectivity action indicated in the second message. For example, the WTRU may suspend the connection or resume the connection if (e.g., only if) the determined security token matches the received security token. For example, the WTRU may determine a security token (e.g., a second security token) based on a set of parameters (e.g., second set of parameters associated with downlink messages). The WTRU may receive a downlink message (e.g., a connection instruction message) from the network. The connection instruction message may indicate a security token (e.g., a third security token). The WTRU may determine whether to follow instructions in the downlink message based on whether the second security token matches the third security token.

[0249] Transitions of the WTRU between the CONNECTED state and the INACTIVE state may be performed in a secure manner. For example, the transitions may be secure to ensure that a rogue entity (e.g., such as a fake base station) will not be able to cause problems by suspending the connection of WTRUs. Secure transitions may allow the network to prevent a rouge / unauthorized WTRU from establishing a connection with the network (e.g., by pretending to a real / authorized WTRU that is resuming a suspended connection).

[0250] Legacy connection suspension may be performed via an RRC Release message. The RRC Release message may be sent via SRB1 and may be encrypted and integrity protected (e.g., only an entity that has the complete WTRU security context may be able to send such a message to the WTRU for the message to be properly compiled / executed by the WTRU without causing an RLF).

[0251] The RRC Resume Request message may be sent unencrypted via SRB0. The RRC Resume Request message may include an authentication token (e.g., referred to as Resume MAC-I). The authentication token may be calculated by the WTRU based on one or more parameters (e.g., such as the identity of the cell where the connection was suspended, the identity of the cell where the WTRU is resuming the connection, the C-RNTI that was assigned to the WTRU when the WTRU was in CONNECTED state, the integrity protection key and algorithm for the control plane that was used by theWTRU when the WTRU was in CONNECTED state, and / or the like). An entity / device that does not have all of this information will not be able to fake a resume request message that will be properly compiled / executed by the network.

[0252] The network may respond with an RRC Resume message that is encrypted and integrity protected. The WTRU (e.g., upon sending the resume request) may update security keys (e.g., both encryption and integrity protection security keys) based on the security keys / context that the WTRU was using while in the CONNECTED state and a counter (e.g., sometimes referred to as nextHopChaining) provided to the WTRU in the RRC Release message that suspended the WTRU’s connection. The network may protect the Resume message that the network sends in response to the resume request by using the same security keys that the WTRU has now updated (e.g., since the network may also update the keys in the same way as the WTRU). A WTRU (e.g., only a WTRU) that has all of the information required to update the security context (e.g., old WTRU security context, nextHopChaining count, etc.) will be able to properly decrypt and verify integrity of the resume message, and use the resume message to resume the connection.

[0253] Performing connection suspend / resume using L2 / L1 mechanisms may lead to a security risk because the L2 / L1 messages (e.g., such as MAC CE) may not be security protected (e.g., so a rogue base station may send a MAC CE capable of suspending the connection of a WTRU or resuming the connection of a suspended WTRU, and a rogue WTRU may be able to access the network by pretending to be a WTRU resuming a connection by sending a MAC CE).

[0254] Feature(s) associated with securing L2 / L1 -based state transitions are provided herein.

[0255] The WTRU may receive an L1 / L2 indication from the network that indicates for the WTRU to suspend the connection (e.g., an instruction to suspend the connection). The indication may include a first security token that protects the integrity of the indication.

[0256] The WTRU may protect the security integrity of an L1 / L2 indication that the WTRU sends to request a connection resume (e.g., a request to resume a connection) by including a second security token to integrity protect the indication.

[0257] The WTRU may receive an L1 / L2 indication from the network that indicates for the WTRU to resume the connection (e.g., an instruction to resume the connection). The indication from the network may include a third security token that protects the integrity of the indication.

[0258] The WTRU may protect the security integrity of an L1 / L2 indication that the WTRU sends to confirm that the WTRU has resumed the connection (e.g., an indication that a connection has been resumed) by including a fourth security token to integrity protect the indication.

[0259] The security token may be a bit string (e.g., a 2-byte field) that is included in the MAC CE that is being sent or received by the WTRU.

[0260] The WTRU may receive (e.g., in an INACTIVE state configuration, in any RRC configuration received while the WTRU is in the CONNECTED state) values of the different security tokens to be used to integrity protect / verify the different L1 / L2 indications related to connection suspension and resumption. The value of the different security tokens may be fixed.

[0261] The value of the first, second, third, and fourth security tokens may be the same.

[0262] The value of the first, second, third, and fourth security tokens may be (e.g., may all be) different.

[0263] One or more of the security tokens may be the same, while one or more other security tokens may be different (e.g., the second and third security tokens may be the same, while the first and fourth security tokens may be different from each other and / or the second and third security tokens).

[0264] The WTRU may be provided with a value (e.g., an explicit value) for one of the security tokens and information regarding how to derive the other security tokens based on the given security token value. For example, the WTRU may be provided with a value of the first token and a function to generate the other tokens (e.g., the function may involve incrementing the value of the first token by a certain configured amount, and / or the like). For example, the first token may be set to a first value (e.g., valuel), and the WTRU may derive a second value (e.g., value2) as valuel +n, and a third value (e.g., value3) as value3=value2+n, etc. (e.g., where n may be a configured value). In another example, value2 may be equal to valuel +n1 , value3 may be equal to value2+n2, etc. (e.g., where n1 , n2, ...etc., may be configured values).

[0265] The WTRU may receive (e.g., in an INACTIVE state configuration, and / or in an RRC configuration message received while the WTRU is in the CONNECTED state) multiple parameters or parameter values associated with the calculation / determination of the security tokens (e.g., the security tokens to be used to integrity protect or / and verify the L2 / L1 indications used for connection suspension and resumption).

[0266] For example, the security tokens may be calculated based on some specified key derivation protocol (e.g., a key derivation function specified / used in a standard, a function that was explicitly indicated to the WTRU while in the CONNECTED state or within the INACTIVE state configuration, and / or the like). The key derivation protocol may use one or more inputs / parameters (e.g., that may be known by both the WTRU and the network). For example, the inputs / parameters may include one or more of: the WTRU identity that is provided in the INACTIVE state configuration; the WTRU identity that the WTRU was using while in CONNECTED state (e.g., such as the C-RNTI); the identity (e.g., all or part of the PCI) and / or frequency of the cell in which the WTRU is resuming the connection; the identity (e.g. all or part of the PCI)and / or frequency of the cell in which the WTRU transitioned to the INACTIVE state; the security keys that were used by the WTRU in the CONNECTED state; the security algorithms that were used by the WTRU in the CONNECTED state; security keys / algorithms provided to the WTRU in the INACTIVE state configuration; and / or timing information (e.g., such as the time the WTRU got suspended or received the INACTIVE state configuration, etc.); and / or the like.

[0267] The WTRU may be configured with different parameters that may be used to calculate the first, second, third, and fourth security tokens.

[0268] The WTRU may be configured to use one or more of the parameters in calculating one or more security tokens (e.g., but the WTRU may not use those one or more parameters in calculating other security tokens).

[0269] The WTRU may be configured with different parameter values that may be used to calculate the first, second, third, and fourth security tokens.

[0270] For example, the WTRU may be provided with several WTRU resume identities. A first resume identity may be used to derive the first token, a second identity may be used to derive the second token, etc.

[0271] The WTRU may be configured with several counter parameters related to security. For example, the counter parameters may have the values valuel, value2, value3, etc. (e.g., where valuel may be used to calculate the first security token, value2 is used to calculate the second security token, etc.).

[0272] The different parameters, counter parameters, and / or the like that are used to derive the different security tokens may be interrelated. The configuration information may indicate a function with an input and an output. A first security token (e.g., received by the WTRU) may be associated with a second security token (e.g., determined by the WTRU) if use of the first security token as the input of the function generates the second security token as the output of the function. For example, the WTRU may use valuel to calculate the first security token. The WTRU may determine a second value, value2, based on valuel . The second value may be used to calculate the second security token (e.g., based on some function), and so on (e.g., until all of the security tokens are calculated / determined).

[0273] The configuration information may indicate an offset value. A first security token (e.g., received by the WTRU) may be associated with a second security token (e.g., determined by the WTRU) if the second security token is equal to the sum of the first security token and the offset value. For example, the parameter associated with the derivation of the first security token may be set to a first value (e.g., valuel). The WTRU may derive a second value (e.g., value2, which may be used to derive the second security token) as valuel +n. The WTRU may derive a third value (e.g., value3, which may be used to derive the third token) as value2+n, and so on. n may be a configured value. In another example, value2 may be setequal to value 1 +n1 , value3 may be set equal to value2+n2, etc. (e.g., where n1, n2, ...etc., may be configured values and may be different).

[0274] If the WTRU receives an L1 / L2 indication to suspend the connection, the WTRU may derive the security token included in the indication with a first security token that the WTRU calculated (e.g., according to any of the techniques described herein). If the WTRU receives an L1 / L2 indication to suspend the connection, the WTRU may compare the security token included in the indication with the (e.g., explicitly) configured first security token in the INACTIVE configuration. The security tokens may be associated with one another if the security tokens match each other. In this case, the WTRU may transition to the INACTIVE state if (e.g., only if) there is a match between the security token included in the indication and the first security token.

[0275] If the security tokens do not match (e.g., the security token included in the message is different from the security token the WTRU derived or was configured with in the INACTIVE configuration), the WTRU may trigger a radio link failure and start a recovery procedure (e.g., re-establishment).

[0276] On a condition that a first security token (e.g., received by the WTRU) is not associated with a second security token (e.g., determined by the WTRU), the WTRU may perform a radio link failure recovery procedure. For example, if the security tokens do not match, the WTRU may not trigger an RLF recovery procedure. The WTRU may send a report indicating the failure (e.g., a failure report, an RLF report, and / or the like) and remain in the CONNECTED state.

[0277] If the WTRU receives the L1 / L2 indication to resume the connection, the WTRU may derive the security token included in the indication based on a third security token that the WTRU determined / calculated (e.g., according to any of the described herein). If the WTRU receives the L1 / L2 indication to resume the connection, the WTRU may compares the security token included in the indication with the (e.g., explicitly) configured third security token in the INACTIVE configuration, and the WTRU may transition to the CONNECTED state if (e.g., only if) there is a match between the indicated third security token and the third security token.

[0278] If the security tokens do not match (e.g., the third security token included in the message is different from the third security token the WTRU derived or was configured with in the INACTIVE configuration), the WTRU may trigger a radio link failure and start a recovery procedure (e.g., reestablishment).

[0279] If the third security tokens do not match, the WTRU may not trigger an RLF recovery procedure. The WTRU may generate and / or save a report indicating the failure (e.g., a failure report, an RLF report, etc.), remain in the INACTIVE sate, and send the report or an indication of the report (e.g., once the WTRU has transitioned to the CONNECTED state).

[0280] Feature(s) associated with security of CP / UP data after a connection is resumed are provided herein.

[0281] If the connection suspension and resumption is performed via L1 / L2 signaling, the WTRU may not apply the modification of the security context for CP data (e.g., the WTRU may use the same encryption and integrity keys for RRC messages after the connection is resumed as were used before the connection was suspended).

[0282] If the connection suspension and resumption is performed via L1 / L2 signaling, the WTRU may not apply the modification of the security context for UP data (e.g., the WTRU may use the same encryption and integrity keys for UP messages after the connection is resumed as were used before the connection was suspended).

[0283] The WTRU may modify the security context for the CP The WTRU may refrain from modifying the security context for the UP (e.g., CP security keys may be updated upon a transition from the INACTIVE state to the CONNECTED state, and UP security keys from before the connection was suspended may be reused when the connection is resumed).

[0284] The WTRU may modify the security context for the UP. The WTRU may refrain from modifying the security context for the CP (e.g., UP security keys may be updated upon a transition from the INACTIVE state to the CONNECTED state, and CP security keys form before the connection was suspended may be reused when the connection is resumed).

[0285] The WTRU may modify the security context / keys for encryption of the data. The WTRU may reuse the security context / keys for integrity protection of data that was used before the connection was suspended.

[0286] The WTRU may modify the security context / keys for integrity protection of the data. The WTRU may reuse the security context / keys for encryption of data that was used before the connection was suspended.

[0287] The determination of the security tokens used for integrity protection and verification of the L1 / L2 connection suspend / resume signaling (e.g., as described herein) may affect other CP / UP integrity verification algorithms / keys. For example, upon deriving the fourth security token to be included in the L1 / L2 connection resumption confirmation message, the WTRU may update the security keys for the CP or / and UP data (e.g., using a similar parameter values as used for deriving the fourth security token, and / or the like). The update may affect (e.g., may only affect) the integrity keys. The update may affect (e.g., may only affect) the encryption keys. The update may affect (e.g., only affect) the CP. The update may affect (e.g., only the UP). The update may affect (e.g., both) the UP and the CP.

[0288] Feature(s) associated with generalizations to security aspects of L1 / L2-based operations (e.g., such as LTM and RRC based signaling) are provided herein.

[0289] The techniques described herein for securing L1 / L2-based connection suspension and connection resume may be applied to any L1 / L2-based technique (e.g., such as LTM).

[0290] A WTRU (e.g., while in CONNECTED mode) may be configured with a set of different parameters or different values of a given parameter. The WTRU may use the different parameters or parameter values as inputs to a key derivation function for calculating integrity protection / verification and / or encryption / decryption keys for the different sequential L1 / L2 messages (e.g., that the WTRU may send to, or receive from, the network). For example, the first parameter or parameter value to be used in the key derivations may be used for the first L1 / L2 message, the second parameter or parameter value may be used for the second L1 / L2 message, etc.

[0291] The WTRU may use the next unused parameter or parameter value for either receiving an L1 / L2 message (e.g., calculating the keys for integrity verification of the received message) or sending an L1 / L2 message (e.g., calculating the keys for integrity protection of the message being sent).

[0292] The WTRU may be given separate lists / sets of parameters or parameter values. A (e.g., one) list may be used when receiving an L1 / L2 message (e.g., calculating the keys for integrity verification of the received message) and another list may be used for sending an L1 / L2 message (e.g., calculating the keys for integrity protection of the message being sent).

[0293] The WTRU may recycle the parameters or parameter values if the parameters or parameter values in the list have been exhausted. For example, after the last parameter value in the list is used, the WTRU may restart from the beginning (e.g., use the first parameter value for the next message). In another example, instead of recycling the parameters or parameter values from the start of the list, the WTRU may restart using the parameters in a reverse order (e.g., backward, for example, assuming n parameter values, the WTRU may use the (n-1 )th parameter value after using the nth parameter value, then use the (n-2)th parameter value, and so on until reaching the first parameter value, and may then start from the beginning, and so on). The WTRU may restart using a parameter value somewhere in between the first and the last parameter values (e.g., according to a received configuration by the network). The WTRU may progress in either the forward or backward direction while progressing through different messages.

[0294] The WTRU may be provided with (e.g., one) seed value (e.g., a counter set to an integer value, n1) and with a formula / function to determine the next parameter value to use (e.g., increment by a certain amount, multiply by a certain amount, etc.) for each subsequent L1 / L2 message (e.g., instead of the WTRU using a set / list of different parameter values).

[0295] To reduce the processing delay that may result from key calculation with each message reception and sending, the WTRU may pre-calculate (e.g., beforehand) a certain number of the keys (e.g., according to any of the techniques described herein) and use the keys to send / receive messages. For example, the WTRU may calculate the 1st ten keys at the reception of the configuration of the parameter values for key derivation. The WTRU may use the first of the ten keys for the first message, the second of the ten keys for the second message, etc.

[0296] The WTRU may be configured to use any of the techniques described herein when receiving messages at another layer (e.g., RRC level). The WTRU may reuse a different key with every message (e.g., instead of using the same security keys once the security context is setup and the network explicitly reconfiguring the key, for example, key refresh during handover, etc.). The WTRU may protect the network from possible vulnerabilities (e.g., such as quantum computing-based attempts to crack the security context).

[0297] The key derivation (e.g., according to any of the techniques described herein) may (e.g., may only) concern control plane-related signaling.

[0298] The key derivation (e.g., according to any of the techniques described herein) may apply to user plane-related signaling. If the key derivation applies to user plane-related signaling, the WTRU may be configured with constraints related to timing for switching from one key to another (e.g., based on the number of PDUs that have been encrypted / integrity protected with one key, based on a time duration that has elapsed while using one key, and / or the like).

[0299] The key derivation for user plane-related signaling (e.g., according to any of the techniques described herein) may be common to all radio bearers, may affect (e.g., only affect) specific radio bearers, or may be configured differently for each radio bearer.

[0300] 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.

[0301] 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 the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well. For example, while the system has been described with reference to a 3GPP, 5G, and / or NR network layer, the envisioned embodiments extend beyond implementations using a particular network layer technology. Likewise, the potential implementations extend to all types of service layer architectures, systems, and embodiments.The techniques described herein may be applied independently and / or used in combination with other resource configuration techniques.

[0302] The processes described herein 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.

[0303] It is understood that the entities performing the processes described herein may be logical entities that may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of, and executing on a processor of, a mobile device, network node or computer system. That is, the processes may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a mobile device and / or network node, such as the node or computer system, which computer executable instructions, when executed by a processor of the node, perform the processes discussed. It is also understood that any transmitting and receiving processes illustrated in figures may be performed by communication circuitry of the node under control of the processor of the node and the computer-executable instructions (e.g., software) that it executes.

[0304] The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the implementations and apparatus of the subject matter described herein, or certain aspects or portions thereof, may take the form of program code (e.g., instructions) embodied in tangible media including any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the subject matter described herein. In the case where program code is stored on media, it may be the case that the program code in question is stored on one or more media that collectively perform the actions in question, which is to say that the one or more media taken together contain code to perform the actions, but that - in the case where there is more than one single medium - there is no requirement that any particular part of the code be stored on any particular medium. In the case of program code execution on programmable devices, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatilememory and / or storage elements), at least one input device, and at least one output device. One or more programs that may implement or utilize the processes described in connection with the subject matter described herein, e.g., through the use of an API, reusable controls, or the like. Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

[0305] Although example embodiments may refer to utilizing aspects of the subject matter described herein in the context of one or more stand-alone computing systems, the subject matter described herein is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the subject matter described herein may be implemented in or across a plurality of processing chips or devices, and storage may similarly be affected across a plurality of devices. Such devices might include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles and airplanes.

[0306] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

Claims

CLAIMSWhat is Claimed:1 . A wireless transmit / receive unit (WTRU) comprising: a processor configured to: while operating in a first activity level, receive, from a network, information associated with operations in a second activity level, wherein the information indicates first configuration information associated with a first radio access network (RAN) area and second configuration information associated with a second RAN area; transition to operating in the second activity level; based on a connection resumption condition being satisfied, determine to transition from operating in the second activity level to operating in the first activity level; determine signaling to use in a connection resumption procedure, wherein the signaling is determined based on the received information and whether the WTRU resumes a connection in a cell within the first RAN area or within the second RAN area; and perform the connection resumption procedure using the determined signaling, wherein performing the connection resumption procedure comprises a transition from operating in the second activity level to operating in the first activity level.

2. The WTRU of claim 1, wherein the processor being configured to determine the signaling to use in the connection resumption procedure comprises the processor being configured to, on a condition that the WTRU determines to resume the connection in the cell within the first RAN area, determine to use Layer 1 / Layer 2 (L1 / L2) signaling in the connection resumption procedure.

3. The WTRU of claim 1, wherein the processor being configured to determine the signaling to use in the connection resumption procedure comprises the processor being configured to, on a condition that the WTRU determines to resume the connection in the cell within the second RAN area, determine to use radio resource control (RRC) signaling in the connection resumption procedure.

4. The WTRU of any of claims 1 to 3, wherein the processor is further configured to determine whether to resume the connection in the cell within the first RAN area or within the second RAN area, wherein the first RAN area has priority over the second RAN area or the second RAN area has priority over the first RAN area, and the processor being configured to determine whether to resume the connection in the cell within the first RAN area or within the second RAN area is based on the priority.

5. The WTRU of any of claims 1 to 4, wherein the processor being configured to perform the connection resumption procedure comprises the processor being configured to: receive a random access response from a network entity; and send identification information to the network entity, wherein the identification information indicates at least one of: a WTRU identifier of the WTRU, or a cell identifier of the cell in which the WTRU determines to resume the connection.

6. The WTRU of any of claims 1 to 5, wherein the connection resumption condition is satisfied if the WTRU receives at least one of: uplink data or a paging indication associated with downlink data arrival.

7. The WTRU of any of claims 1 to 6, wherein the first configuration information associated with the first RAN area comprises a first list of cells within the first RAN area, and the second configuration information associated with the second RAN area comprises a second list of cells within the second RAN area.

8. The WTRU of any of claims 1 to 7, wherein the processor is further configured to receive an activity level indication from a network entity, and wherein the determination to transition to operating in the second activity level is based on the activity level indication.

9. The WTRU of any of claims 1 to 8, wherein the processor being configured to transition to operating in the second activity level comprises the processor being configured to apply the information.

10. A method, performed by a wireless transmit / receive unit (WTRU), wherein the method comprises: while operating in a first activity level, receiving, from a network, information associated with operations in a second activity level, wherein the information indicates first configuration information associated with a first radio access network (RAN) area and second configuration information associated with a second RAN area; transitioning to operating in the second activity level; based on a connection resumption condition being satisfied, determining to transition from operating in the second activity level to operating in the first activity level; determining signaling to use in a connection resumption procedure, wherein the signaling is determined based on the received information and whether the WTRU resumes a connection in a cell within the first RAN area or within the second RAN area; andperforming the connection resumption procedure using the determined signaling, wherein performing the connection resumption procedure comprises a transition from operating in the second activity level to operating in the first activity level.

11. The method of claim 10, wherein determining the signaling to use in the connection resumption procedure comprises, on a condition that the WTRU determines to resume the connection in the cell within the first RAN area, determining to use Layer 1 / Layer 2 (L1 / L2) signaling in the connection resumption procedure.

12. The method of claim 10, wherein determining the signaling to use in the connection resumption procedure comprises, on a condition that the WTRU determines to resume the connection in the cell within the second RAN area, determining to use radio resource control (RRC) signaling in the connection resumption procedure.

13. The method of any of claims 10 to 12, wherein the method further comprises determining whether to resume the connection in the cell within the first RAN area or within the second RAN area, wherein the first RAN area has priority over the second RAN area or the second RAN area has priority over the first RAN area, and determining whether to resume the connection in the cell within the first RAN area or within the second RAN area is based on the priority.

14. The method of any of claims 10 to 13, wherein performing the connection resumption procedure comprises: receiving a random access response from a network entity; and sending identification information to the network entity, wherein the identification information indicates at least one of: a WTRU identifier of the WTRU, or a cell identifier of the cell in which the WTRU determines to resume the connection.

15. The method of any of claims 10 to 14, wherein the connection resumption condition is satisfied if the WTRU receives at least one of: uplink data or a paging indication associated with downlink data arrival.

16. The method of any of claims 10 to 15, wherein the first configuration information associated with the first RAN area comprises a first list of cells within the first RAN area, and the second configuration information associated with the second RAN area comprises a second list of cells within the second RAN area.

17. The method of any of claims 10 to 16, wherein the method further comprises receiving an activity level indication from a network entity, and wherein determining to transition to operating in the second activity level is based on the activity level indication.

18. The method of any of claims 10 to 17, wherein transitioning to operating in the second activity level comprises applying the information.

Images