Group-based network access

Abstract

This specification describes systems, methods, and means associated with group-based network access, such as initial access to a network by a group of WTRUs. An explanation of group-based initial access procedures is provided, as well as messages / signals that may be sent or received by a WTRU during the group-based initial access procedures, and a method for allocating resources in a group to send the described messages / signals. The group-based initial access procedures may be performed based on the detection of a triggering event or condition, and measurements may be performed to enable the group-based initial access procedures.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 335,421, filed Apr. 27, 2022, U.S. Provisional Patent Application No. 63 / 395,600, filed Aug. 5, 2022, and U.S. Provisional Patent Application No. 63 / 421,688, filed Nov. 2, 2022, the disclosures of which are hereby incorporated by reference in their entireties.

Background Art

[0002] A wireless transmit / receive unit (WTRU) can obtain access to a network (e.g., initial access), for example, through a random access procedure. If each WTRU within a cooperation group processes the access procedure individually, the group (e.g., as a whole) may experience collisions due to additional delays that can be caused, for example, by contention resolution.

Summary of the Invention

[0003] This specification discloses systems, methods, and means associated with group-based network access, such as initial access to a network by a group of wireless transmit / receive units (WTRUs). A wireless transmit / receive unit (WTRU) (e.g., an anchor WTRU) can include a processor configured to send a first message to a network device that can include information regarding a group-based random access procedure associated with a group of WTRUs (e.g., the anchor WTRU can be part of the group). The processor can be further configured to receive from the network device a response that can indicate one or more resources for a group-based random access procedure. The processor can be further configured to determine an allocation of the one or more resources indicated by a response to the group of WTRUs associated with the group-based random access procedure and send an indication that can indicate the allocation of the one or more resources to the group of WTRUs, and the indication can be sent via one or more sidelink messages.

[0004] The processor of the WTRU can be configured to autonomously (e.g., without additional instructions from the network device) determine an allocation of one or more resources to the group of WTRUs. The processor of the WTRU can be further configured to determine that the one or more resources are insufficient to correspond to the group of WTRUs associated with the group-based random access procedure. Based on such a determination, the processor can be configured to allocate one or more resources to the group of WTRUs based on respective transmission priorities or respective transmission time constraints associated with the group of WTRUs.

[0005] One or more resources described herein may be associated with contention - free access to a network device by a group of WTRUs. A response received from the network device may include information indicating how one or more resources may be allocated to the group of WTRUs, and a processor of the WTRU may be configured to determine the allocation of one or more resources to the group of WTRUs based on the information included in the response. A first message transmitted by the WTRU to the network device may include a random access preamble associated with a group - based random access procedure, and the first message may indicate several WTRUs associated with the group - based random access procedure.

[0006] The processor of the WTRU may be further configured to identify a group of WTRUs associated with a group - based random access procedure based on sidelink communication between the WTRU and the group of WTRUs, and the group - based random access procedure may be performed via an access network interface (e.g., Uu interface) between the group of WTRUs and the network device. In an embodiment, the processor of the WTRU may be further configured to transmit a second message to the network device, and the second message may indicate the allocation of one or more resources to the group of WTRUs.

[0007] A member WTRU (e.g., one or more other WTRUs described above) associated with a group-based random access procedure may be configured to transmit, via sidelink, a message to an anchor WTRU that may indicate a request by the WTRU to perform a random access procedure. The member WTRU may receive, from the anchor WTRU, a response that may indicate one or more resources that the member WTRU may use to perform a random access procedure. The member WTRU may then perform a random access procedure with a network device using the one or more resources indicated by the anchor WTRU. In an embodiment, the message transmitted by the member WTRU to the anchor WTRU may further indicate a transmission priority or a transmission time constraint associated with the member WTRU. In an embodiment, the member WTRU may perform the random access procedure in a contention-free manner using the one or more resources indicated by the anchor WTRU.

Brief Description of the Drawings

[0008]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2A

Figure 2B

Figure 2C

Figure 3

Figure 4

[0009] FIG. 1A is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 may use 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), etc.

[0010] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can 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 "STA", can be configured to transmit and / or receive wireless signals and can be user equipment (UE), a mobile station, a fixed subscriber unit or a mobile subscriber unit, a subscriber-based unit, a pager, a cellular phone, 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 (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain context), a home appliance device, a device operating in a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may also be referred to interchangeably as a UE.

[0011] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as CN106 / 115, Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be a Base Transceiver Station (BTS), Node B, eNode B (eNB), Home Node B, Home eNode B, gNode B (gNB), NR Node B, site controller, Access Point (AP), wireless router, etc. Although base stations 114a, 114b are each depicted as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0012] Base station 114a can be part of RAN 104 / 113 and can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b can be configured to transmit and / or receive radio signals at one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell can provide wireless service coverage to a specific geographic area that can be relatively fixed or can change over time. A cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a can include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a can use multiple-input multiple output (MIMO) technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

[0014] More specifically, as described above, the communication system 100 can be a multiple access system, and can use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

[0016] In one embodiment, the base station 114a, and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) technology to establish the air interface 116.

[0017] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interfaces utilized by WTRUs 102a, 102b, 102c may be characterized by transmissions sent between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNBs and gNBs).

[0018] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless 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 communication (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0019] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by a drone, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless 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 can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0020] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video delivery, etc., and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT or a different RAT as RAN 104 / 113. For example, in addition to being connected to a RAN 104 / 113 that can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0021] CN106 / 115 can also function as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 can include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices, where these networks and devices use a common communication protocol such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 can include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 can include another CN connected to one or more RANs that can use the same RAT or a different RAT as the RAN104 / 113.

[0022] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 can include a multimode function (e.g., the WTRU102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A can be configured to communicate with a base station 114a that can use a cellular-based wireless technology and a base station 114b that can use IEEE802 wireless technology.

[0023] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 may include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0024] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrally integrated in an electronic package or chip.

[0025] The transmit / receive element 122 may be configured to transmit or receive signals to / from a base station (e.g., base station 114a) via 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 one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0026] Although the transmit / receive element 122 is depicted in FIG. 1B 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 via the air interface 116.

[0027] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have a multimode function. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

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

[0029] Processor 118 may receive power from power source 134 and may be configured to distribute and / or control power to other components in WTRU 102. Power source 134 may be any suitable device for supplying power to WTRU 102. For example, power source 134 may include one or more dry cells (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0030] Processor 118 may also be coupled to GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of WTRU 102. In addition to, or instead of, information from GPS chipset 136, WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via air interface 116 and / or may determine its location based on the timing of signals received from two or more neighboring base stations. It will be understood that WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with one embodiment.

[0031] Processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), 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. Peripheral devices 138 may include one or more sensors, which 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.

[0032] WTRU102 may include a full-duplex radio in which some or all of the transmission and reception of signals associated with a particular subframe (e.g., for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference either via hardware (e.g., choke) or via signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of any of some or all of the signals (e.g., associated with a particular subframe for either UL (e.g., for transmission) or downlink (e.g., for reception)).

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

[0034] RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that RAN 104 may include any number of eNodeBs while remaining consistent with one embodiment. Each of eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, eNodeB 160a, for example, may transmit and / or receive radio signals from WTRU 102a using multiple antennas.

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

[0036] CN 106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or packet gateway, PGW) 166. Although each of the foregoing elements is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0037] The MME 162 can be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can perform roles such as authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for switching between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0038] The SGW 164 can be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and transfer user data packets between the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0039] The SGW 164 can be connected to the PGW 166, and the PGW 166 can provide access to a packet switched network such as the Internet 110 to the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0040] CN106 may facilitate communication with other networks. For example, CN106 may provide access to a circuit-switched network such as the PSTN108 to the WTRU102a, 102b, 102c in order to facilitate communication between the WTRU102a, 102b, 102c and a conventional landline communication device. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and the PSTN108. In addition, CN106 can provide the WTRU102a, 102b, 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

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

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

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

[0045] A high Throughput (HT) STA may use a 40 MHz wide channel for communication, and this 40 MHz wide channel may be formed, for example, via a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.

[0046] A very High Throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel may be formed by combining a plurality of consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non - consecutive 80 MHz channels, which may be referred to as an 80 + 80 configuration. In the case of the 80 + 80 configuration, after channel encoding, the data may pass through a segment parser that can divide the data into two streams. The Inverse Fast Fourier Transform (IFFT) process and the time - domain process may be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80 + 80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0047] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro communication range area. The MTC device may have limited capabilities, including certain capabilities, such as support for a certain and / or limited bandwidth (e.g., support only for these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0048] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operation mode. In an example of 802.11ah, the primary channel can be 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only this) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting can depend on the status of the primary channel. For example, due to an STA transmitting to an AP (supporting only the 1 MHz operation mode), if the primary channel is busy, the entire available frequency band can be considered busy even if most of the frequency band remains idle and available.

[0049] In the United States, the available frequency band that can be used by 802.11ah is 902 MHz to 928 MHz. In South Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz depending on the country code.

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

[0051] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, gNB 180a may transmit and / or receive radio signals to and from WTRU 102a, for example, using multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit a plurality of component carriers to 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 one embodiment, gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0052] The WTRUs 102a, 102b, and 102c can communicate with the gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, and 102c can communicate with the gNBs 180a, 180b, and 180c using sub-frames or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or having absolute times of various lengths).

[0053] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNodeBs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c may implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNodeBs 160a, 160b, and 160c may function as a mobility anchor for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0054] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decision-making, handover decision-making, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, and routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0055] CN 115 shown in FIG. 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0056] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can play roles such as authentication of users of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of specific SMFs 183a and 183b, management of the registration area, termination of NAS signaling, and mobility management. Network slices can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of service being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF 162 can provide control plane functions for exchange between RAN 113 and other RANs (not shown) that use other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0057] SMF183a and 183b can be connected to AMF182a and 182b within CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b within CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b, and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0058] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N3 interface, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0059] CN115 may facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and the PSTN 108. Additionally, CN115 may provide access to other network 112 for WTRU102a, 102b, 102c, and other network 112 may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DN) 185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0060] Looking at FIGS. 1A - 1D and the corresponding descriptions of FIGS. 1A - 1D, one or more of the functions described herein related to one or more of WTRU102a - d, base stations 114a and b, e - NodeB 160a - c, MME 162, SGW 164, PGW 166, gNB180a - c, AMF182a and b, UPF184a and b, SMF183a and b, DN185a and b, and / or any other device described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0061] An emulation device can be designed to perform one or more tests on one or more other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more emulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. An emulation device can be directly coupled to another device and / or use terrestrial wireless communication for the purpose of conducting tests.

[0062] One or more emulation devices can perform one or more functions, including all, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a non-deployed (e.g., for testing) wired and / or wireless communication network to perform tests on one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which may include one or more antennas) can be used by an emulation device to transmit and / or receive data.

[0063] This specification discloses systems, methods, and means associated with group-based network access, such as initial access to a network by a group of wireless transmit / receive units (WTRUs). A wireless transmit / receive unit (WTRU) (e.g., an anchor WTRU of a WTRU group) may include a processor configured to send a first message to a network device that may include information regarding group-based random access procedures associated with the WTRU and one or more other WTRUs (e.g., of the WTRU group). The processor may be further configured to receive, from the network device, a response that may indicate one or more resources for group-based random access procedures. The processor may be further configured to determine an allocation of at least a portion of the one or more resources indicated by a response to one or more other WTRUs associated with the group-based random access procedures and send an indication of the allocation of at least a portion of the one or more resources to the one or more other WTRUs, the indication being sent via one or more sidelink messages.

[0064] The processor of the WTRU may be configured to autonomously (e.g., without additional instructions from the network device) determine an allocation of at least a portion of the one or more resources to one or more other WTRUs. In embodiments, the one or more other WTRUs may be a subset of the WTRUs associated with the group-based random access procedures, and the processor of the WTRU may determine that the one or more resources are insufficient to correspond to the WTRUs associated with the group-based random access procedures. Based on such a determination, the processor may be configured to allocate at least a portion of the one or more resources to the one or more other WTRUs based on a transmission priority associated with the one or more other WTRUs or based on a transmission time constraint associated with the one or more other WTRUs.

[0065] One or more resources described herein may be associated with contention - free access to a network device. In an embodiment, a response received from a network device may further indicate how one or more resources may be allocated to one or more other WTRUs, and a processor of a WTRU may be configured to determine an allocation of at least a portion of one or more resources to one or more other WTRUs based on information included in the response. In an embodiment, a first message transmitted by a WTRU to a network device may include a random access preamble associated with group - based random access procedures, and the first message may indicate several WTRUs associated with group - based random access procedures.

[0066] The processor of the WTRU may be further configured to identify one or more other WTRUs associated with group - based random access procedures based on sidelink communication between the WTRU and the one or more other WTRUs, and the group - based random access procedures may be performed via an access network interface (e.g., Uu interface) between the one or more other WTRUs and the network device. In an embodiment, the processor of the WTRU may be further configured to transmit a second message to the network device, and the second message may indicate an allocation of at least a portion of one or more resources to one or more other WTRUs.

[0067] A member WTRU (e.g., one or more other WTRUs described above) associated with a group-based random access procedure may be configured to transmit, via sidelink, a message to an anchor WTRU that may indicate a request by the WTRU to perform a random access procedure. The member WTRU may receive, from the anchor WTRU, a response that may indicate one or more resources for the member WTRU to perform a random access procedure. The member WTRU may then perform a random access procedure with a network device using the one or more resources indicated by the anchor WTRU. In an embodiment, the message transmitted by the member WTRU to the anchor WTRU may further indicate a transmission priority or a transmission time constraint associated with the member WTRU. In an embodiment, the member WTRU may perform the random access procedure in a contention-free manner using the one or more resources indicated by the anchor WTRU.

[0068] As described herein, an anchor WTRU of a WTRU group, such as a coordinated WTRU group formed based on an extended reality (XR) application, may determine the number of WTRUs in the group (e.g., member WTRUs including the anchor WTRU) based on, for example, sidelink (SL) communication (e.g., data exchange) between members, and / or may further determine time constraints (e.g., maximum time constraints) for one or more (e.g., all) of the WTRUs in the group for performing an initial access to the network (e.g., the time constraints may be determined based on application layer information). The anchor WTRU may select RACH resources, such as a RACH preamble, based on system information (e.g., a system information block (SIB)) received by the anchor WTRU, and may indicate (e.g., explicitly or implicitly) a request for group-based initial access to a network device. The indication of the request may be sent, for example, in Msg1 associated with random access and / or based on the selected resources. The anchor WTRU may determine the allocation of one or more RACH resources (e.g., one or more preambles, one or more random access occasions (ROs), etc.) to a WTRU associated with a random access request (e.g., to one or more member WTRUs of the group) (e.g., based on a response received from the network device). The anchor WTRU may determine resource allocation based on, for example, group-based RACH resources (e.g., allocated by the network device in a random access response, such as in Msg2), based on application layer information, and / or in a contention-free manner. As will be described in more detail below, resource allocation to member WTRUs may be performed autonomously by the anchor WTRU (e.g., the anchor WTRU may itself determine which resources permitted by the network are directed to which member WTRUs and may notify the member WTRUs of that determination).Resource allocation may also be indicated in responses received from network devices (e.g., a network device can not only provide resources, but also indicate which resources are directed to which member WTRUs, and the anchor WTRU can notify the member WTRUs about the indicated allocation).

[0069] In embodiments, a WTRU (e.g., the anchor WTRU described herein) may receive, from upper layer messages (e.g., via RRC signaling), from an application, and / or from a member WTRU (e.g., via sidelink (SL) messages), information regarding the duration (e.g., maximum duration) for which a WTRU group (e.g., members of the WTRU group) establishes connectivity (e.g., initial access) with the network, the priority (e.g., transmission priority) of (e.g., each) member WTRU, the transmission time constraints of (e.g., each) member WTRU, the NAS ID of (e.g., each) member WTRU, etc. The WTRU (e.g., the anchor WTRU described herein) may receive, in a system information block (SIB) (e.g., SIB1 or an XR-specific SIB), RACH preamble and / or associated information between RACH preambles, and the number of WTRUs in the WTRU group. The WTRU may send a RACH preamble corresponding to the number of WTRUs in the WTRU group (e.g., n WTRUs) (e.g., in Msg1). The WTRU may receive a reservation indication (e.g., in a response such as Msg2) indicating RACH resources (e.g., contention-free RACH preambles, m ROs, etc.) for some (e.g., m) WTRUs in the WTRU group (e.g., m may be less than or equal to n). The WTRU may receive, in the response, a timing advance (TA), an UL grant (e.g., for this WTRU or another WTRU), a group temporary cell RNTI (TC-RNTI), etc.

[0070] A WTRU (e.g., an anchor WTRU as described herein) may determine the allocation of RACH resources (e.g., at least a portion of the RACH resources) to one or more member WTRUs (e.g., all n WTRUs including the anchor WTRU) within a WTRU group based on one or more of time constraints or durations for the WTRU group to establish connectivity to the network, based on the priority (e.g., transmission priority) of the member WTRUs, based on transmission time constraints associated with the member WTRUs, and / or based on resource allocation or reservation indications provided by the network for the WTRU. The WTRU (e.g., the anchor WTRU) may notify one or more WTRUs about the resource allocation (e.g., a portion of the resources may be allocated to the anchor WTRU itself). For example, the WTRU may send information regarding the determined RACH resource allocation (e.g., allocation of preambles, ROs, etc.), corresponding NAS IDs, and / or group TC-RNTIs to one or more member WTRUs (e.g., via unicast and / or multicast messages on the SL interface).

[0071] A WTRU (e.g., an anchor WTRU as described herein) may send a confirmation of the RACH resource allocation or assignment to one or more member WTRUs to a network device (e.g., in Msg3 associated with random access). The confirmation message may indicate, for example, whether the RACH resource allocation or assignment was successful, the anchor WTRU NAS ID, the group NAS ID, and / or group RRC requests (e.g., RRC setup requests for one or more WTRUs within the WTRU group).

[0072] A WTRU (e.g., an anchor WTRU as described herein) may receive from a network device a status report indicating whether initial access by one or more (e.g., all) of the WTRUs within the WTRU group (e.g., in Msg4 associated with random access) was successful. If the status report indicates a group NAS ID, the WTRU (e.g., an anchor WTRU as described herein) may assume that initial access by the member WTRUs (which may include the anchor WTRU) was successful. If the status report indicates the NAS ID of the successful member WTRUs (which may include the anchor WTRU) and / or validity information (e.g., in Msg2) indicating the validity of previously received RACH resources, the WTRU (e.g., an anchor WTRU) may assume that initial access by at least one member WTRU (which may be the anchor WTRU) was unsuccessful. The WTRU may determine the member WTRUs that were unsuccessful with respect to the corresponding RACH resources for initial access and / or retransmission (e.g., of the initial access message) based on the status report and / or the validity information. The WTRU may notify the unsuccessful member WTRUs about the determined RACH resources for retransmission (e.g., MsgA or Msg1) (e.g., via the SL interface).

[0073] Figures 2A - 2C illustrate one or more of the techniques described herein. Figure 2A illustrates an example of a group - based initial access procedure, Figure 2B illustrates what may be included in Msg1 shown in Figure 2A, and Figure 2C illustrates what may be included in Msg2 shown in Figure 2A.

[0074] The member WTRU may send auxiliary information for assisting group-based initial access to the anchor WTRU. The member WTRU may perform initial access using group-based contention-free RACH resources (e.g., indicated by the anchor WTRU). The member WTRU may send, for example, the NAS ID, or one or more of the requests for assisting initial access, to the anchor WTRU (e.g., via the Uu link between the member WTRU and the network device). The member WTRU may receive from the anchor WTRU (e.g., via the SL message) one or more RACH resources (e.g., one or more contention-free RACH preambles, one or more ROs, etc.), TA, and / or the group TC-RNTI for use in initial access. The member WTRU may send a RACH message (e.g., including a RACH preamble) (e.g., in MsgA or Msg1) using the contention-free resource received from the anchor WTRU. MsgA or Msg1 described herein may include a preamble and / or the NAS ID (e.g., the cooperating WTRU may encode or scramble the preamble using the NAS ID). The member WTRU (or the anchor WTRU) may start a timer associated with group-based initial access. The member WTRU (or the anchor WTRU) may receive the NAS ID (e.g., in MsgB). The member WTRU (or the anchor WTRU) may use the group TC-RNTI and / or the C-RNTI in subsequent initial access messages. The member WTRU may send an acknowledgment (ACK) indication to the anchor WTRU indicating a successful initial access.

[0075] When the timer associated with the group-based initial access procedure (e.g., the timer shown in Figure 2A) expires and the member WTRU does not receive a NAS ID (e.g., in MsgB) or does not receive any RACH response (e.g., MsgB) at all, the member WTRU may send a negative-acknowledgment (NACK) indication indicating an unsuccessful initial access to the anchor WTRU, and the member WTRU may request auxiliary information (e.g., from the anchor WTRU) for retransmission of the RACH message (e.g., MsgA).

[0076] If the member WTRU receives auxiliary information (e.g., from the anchor WTRU), the member WTRU may resend the RACH message (e.g., MsgA) using the preamble (e.g., indicated by the anchor WTRU). If the member WTRU does not receive auxiliary information (e.g., from the anchor WTRU), the member WTRU may send another RACH message (e.g., Msg1) and may return to the legacy RACH procedure.

[0077] The term "Extended Reality (XR)" may be used in this specification to refer to different types of immersive experiences, including, for example, Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and / or interpolated realities based on these types of immersive experiences. Virtual Reality (VR) may include a rendered version of a delivered visual and / or auditory scene. The rendering may mimic visual (e.g., stereoscopic three-dimensional (3D)) and / or auditory sensory stimuli of the real world to an observer or user as the observer or user moves within the limits defined by the application. Augmented Reality (AR) may provide a user with additional information or artificially generated items or content overlaid on the user's current environment. Mixed Reality (MR) may include an advanced form of AR where some virtual elements may be intentionally inserted into the physical scene to provide the illusion that these elements are part of the real scene. XR may include one or more combined environments of reality and virtuality generated by computer technology and / or wearables and / or human-machine interactions.

[0078] The concept of immersion in the context of an XR application or service may refer to the feeling of being surrounded by a virtual environment and the impression of being physically and spatially located within the virtual environment. The level of virtualization can range from partial sensory input to fully immersive multisensory input leading to a virtual reality that is practically indistinguishable from actual reality.

[0079] The WTRU described herein may include an XR device that may be capable of providing various degrees of spatial tracking. Such XR devices may be equipped with various sensors to enable spatial tracking. The sensors may include, for example, a monocular camera, a stereo camera, a depth camera, a wireless beacon, a GPS device, an inertial sensor, etc. Spatial tracking may be performed at different levels using, for example, 3 degrees of freedom (DoF) (e.g., rotational movement along the X, Y, and Z axes) or 6 DoF (e.g., rotational movement and / or translational movement along the X, Y, and Z axes). Spatial tracking may result in interactions for experiencing some form of virtual content. The user may act within and / or interact with one or more components within the extended reality. For example, the actions and / or interactions may include movement, gestures, eye gaze tracking, etc. Spatial tracking may enable an immersive XR experience. For example, some form of head and / or movement tracking may ensure that the simulated visual and auditory components from the user's perspective are updated to match the user's movement. Inaccurate and / or delayed spatial tracking may result in discomfort and / or a feeling of motion sickness for the user.

[0080] The WTRU described herein may include an XR device or XR node that can be implemented in various form factors. The WTRU described herein (e.g., XR WTRU) may include, but is not limited to, one or more head mounted displays (HMDs), one or more pairs of optical see-through glasses and camera see-through HMDs for AR and MR, one or more mobile devices having position tracking capabilities and cameras, one or more wearable devices, etc. For example, different types of XR WTRUs may be envisioned based on the XR device functions (e.g., as a display, camera, sensor, sensor processing, wireless connection, power source for XR or media processing, etc.) provided by the WTRU devices, wearables, actuators, controllers, and / or accessories described herein. One or more WTRUs, such as one or more XR devices or XR nodes, may be grouped into a cooperative group to support, for example, XR applications, XR experiences, XR services, etc.

[0081] The terms "initial access" and "random access" may be used interchangeably herein to refer to one or more operations or procedures associated with establishing connectivity between a WTRU and a network. Random access procedures may be triggered for a WTRU by one or more of the following events: initial access from the RRC idle state, RRC connection reestablishment procedure, downlink (DL) or uplink (UL) data arrival in the RRC_CONNECTED state (e.g., when the UL synchronization status is "asynchronous"), UL data arrival in the RRC_CONNECTED state (e.g., when PUCCH resources for a scheduling request (SR) are not available), SR failure, RRC request during synchronization reconfiguration (e.g., handover), RRC connection resume procedure from the RRC_INACTIVE state, establishment of time alignment for a secondary timing advance group (TAG), request for system information (SI), beam failure recovery, and consistent UL listen-before-talk (LBT) failure on a cell such as a special cell (SpCell).

[0082] For example, multiple (e.g., two or more) types of random access (RA) procedures can be supported, including a 4-step RA type using Message 1 (Msg1 or Msg1), Message 2 (Msg2 or Msg2), Message 3 (Msg3 or Msg3), and Message 4 (Msg4 or Msg4), and a 2-step RA type using Message A (MsgA or MsgA) and Message B (MsgB or MsgB). One or more types of RA procedures can support contention-based random access (CBRA) and / or contention-free random access (CFRA), as shown, for example, in FIG. 3 illustrating examples of different types of initial access. Additional messages can also be sent and / or received during and / or before and after the RA procedure. For example, in response to receiving Msg4 from a network device, the WTRU can send Msg5, described herein, to the network device (e.g., a base station). The WTRU can include various information in Msg5, such as, for example, a public land mobile network (PLMN) ID and / or other dedicated NAS information.

[0083] The WTRU can select the type of random access at the start of the random access procedure, for example, based on network configuration information. For example, if CFRA resources are not configured, a reference signal receive power (RSRP) threshold can be used by the WTRU to select between the 2-step RA type and the 4-step RA type. If CFRA resources are configured for the 4-step RA type, the WTRU can perform the 4-step RA procedure. If CFRA resources are configured for the 2-step RA type, the WTRU can perform the 2-step RA procedure.

[0084] The network may or may not simultaneously configure CFRA resources for 4-step and 2-step RA types for a bandwidth part (BWP). 2-step CFRA may be supported in a handover situation (e.g., only for handover situations).

[0085] The Msg1 of the 4-step RA type may include a preamble transmitted on the physical random access channel (PRACH). The WTRU may monitor for a response from the network within a configured window (e.g., a configured time window) (e.g., after Msg1 transmission). In the case of CFRA, for example, as shown in Figure 3-(c), a dedicated preamble for Msg1 transmission may be assigned by the network, and the WTRU may terminate the random access procedure (e.g., when receiving a random access response from the network). In the case of CBRA, the WTRU may, for example, as shown in Figure 3-(a), send a message 3 (Msg3) (e.g., upon receiving a random access response) using a UL grant scheduled in the response, and the WTRU may monitor for contention resolution. If contention resolution is not successful after Msg3 (re)transmission, the WTRU may return to Msg1 transmission.

[0086] The 2-step RA type MsgA may include a preamble transmitted on the PRACH and / or a payload on the PUSCH (physical uplink shared channel). The WTRU may monitor for a response from the network within a configured window (e.g., a configured time window) (e.g., after MsgA transmission). In the case of CFRA, for example, as shown in Figure 3-(d), dedicated preamble and / or PUSCH resources may be configured for MsgA transmission, and the WTRU may terminate the random access procedure (e.g., when a network response is received). In the case of CBRA, for example, as shown in Figure 3-(b), if contention resolution is successful upon receipt of a network response, the WTRU may terminate the random access procedure. If a fallback indication is received in message B (message B, MsgB), the WTRU may perform Msg3 transmission using the UL grant scheduled in the fallback indication, and the WTRU may monitor for contention resolution. If contention resolution is not successful after Msg3 (re)transmission, the WTRU may return to MsgA transmission. If the random access procedure using the 2-step RA type does not complete after several MsgA transmissions, the WTRU may be configured to switch to CBRA using the 4-step RA type.

[0087] In an example (e.g., for random access in a cell configured using a supplemental uplink (SUL)), the network may (e.g., explicitly) signal which carrier can be used (e.g., a UL carrier or an SUL carrier). If such a signal is not received from the network, the WTRU may select the SUL carrier if the measured quality of the DL is lower than a threshold (e.g., a broadcast threshold) (e.g., only in that case). The WTRU may perform carrier selection before selecting between a 2-step RA type and a 4-step RA type. The thresholds (e.g., an RSRP threshold) for selecting between the 2-step and 4-step RA types may be configured (e.g., separately) for UL and SUL. Once initiated, one or more (e.g., all) uplink transmissions associated with the random access procedure may stay on the selected carrier.

[0088] In an example (e.g., when carrier aggregation (CA) is configured), the random access procedure using the two-step RA type can be performed on the primary cell (PCell) (e.g., only on the PCell), but contention resolution can be cross-scheduled by the PCell. In an example (e.g., when CA is configured), for the four-step RA type random access procedure, the first three steps of the CBRA procedure can be performed on the PCell (e.g., always performed), but contention resolution (e.g., contention resolution as step 4) can be cross-scheduled by the PCell. The first three steps of the four-step CFRA procedure that may have been started on the PCell can remain on the PCell. The CFRA procedure on the SCell can be started by the base station (e.g., gNB) (e.g., only be started) to establish, for example, the timing advance for the secondary TAG. For example, the procedure can be started by the gNB using a PDCCH command (e.g., as step 0) that can be sent on the scheduling cell of the activated SCell of the secondary TAG. The preamble transmission (e.g., in step 1) can be performed on the indicated SCell, and the random access response (e.g., in step 2) can be performed on the PCell.

[0089] When each WTRU within a coordination group processes the random access procedure individually, the random access process for the WTRU's coordination group may, for example, experience a random access collision. Such contention related to random access may occur, for example, in an IoT use case where access by a large number of Internet of Things (IoT) devices can be supported. These IoT devices (for example, the number of which can be huge) may or may not have strict latency requirements to meet. In the case of other devices such as XR devices, there may be strict latency requirements (for example, imposed by an XR application), and random access collisions may, for example, fail to meet the strict latency requirements due to additional delays caused by RA contention resolution. Having an anchor WTRU within such a coordinated WTRU group (for example, which may comprise multiple XR devices) may, for example, enhance the efficiency of the random access procedure by enabling the anchor WTRU to coordinate or process the procedure, at least in part, on behalf of one or more other WTRUs (for example, and the anchor WTRU itself). An efficient initial access process for a group of WTRUs may mitigate random access contention and / or reduce the initial access latency in the group. As a result, a satisfactory quality of experience (QoE) may be achieved for the user, for example, in an XR application (for example, by coherently meeting the latency requirements of an XR application for a coordinated group of XR WTRUs to provide an immersive XR experience to the user).

[0090] The issues to be addressed regarding initial access to the network may include how to support efficient initial access of a group of WTRUs (e.g., a coordinated WTRU group) to enable the WTRU to perform initial access within a strict latency range, whether an anchor WTRU can be used and / or how it can be used to ensure that other WTRUs (e.g., members of a WTRU group including the anchor WTRU itself) can perform random access procedures such as a two-step RACH procedure with a minimized probability of contention, how to perform efficient random access procedures of a coordinated group of WTRUs (e.g., XR devices) within strict time constraints and mitigate contention between WTRUs, how to support (e.g., guarantee) group-based initial access within a strict latency range, and how to enable a coordinated WTRU to perform a contention-free (e.g., substantially contention-free) RACH procedure within a strict time window, etc.

[0091] FIG. 4 illustrates an example of a cooperative XR system. In the embodiments described herein, the network may refer to or include any one of, for example, a base station (e.g., a transmission reception point (TRP), a RAN node, an access node, etc.), a core network function (e.g., an AMF), and / or an application function (e.g., an edge server function, a remote server function). In the embodiments described herein, a flow may correspond to or include either a QoS flow or a data flow (a flow of data including one or more PDUs or ADUs that may be associated with one or more QoS requirements related to latency, data rate, reliability, etc.). Different flows (flows that originate from a common application / experience source and / or target different destination devices / WTRUs or a group of associated devices / WTRUs) may sometimes be referred to as associated flows or correlated flows.In the embodiments described in this specification, the transfer configuration may correspond to or include configuration information associated with radio bearers (e.g., data radio bearers (DRBs) and / or signaling radio bearers (SRBs)), logical channels (LCHs), logical channel groups (LCGs), configuration parameters within individual layers of the AS protocol stack (e.g., service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), RLC protocol layer, MAC protocol layer, PHY protocol layer, and / or other protocol layers), parameters associated with logical channel prioritization (LCP) (e.g., priority, prioritized bit rate (PBR), bucket size duration (BSD)), etc.), BWP, carrier, radio link or interface (e.g., Uu link, SL, etc.), and / or radio resources (e.g., a set of one or more frequency / time / space resources such as time slots, subcarriers, or beams, configured grants, dynamic grants, and / or radio resources associated with any other resource grant, or grant-free resources, etc.).

[0092] In the embodiments described herein, a "cooperative XR WTRU" or "cooperative WTRU group" may refer to one or more of the following concepts and definitions, but is not limited thereto. XR applications and / or services may be supported, whereby one or more WTRUs may perform at least one action related to XR, and as a result, an XR experience may be provided to a user. These experiences may include, for example, enabling a user to perceive a feeling of full or partial immersion into different real and / or virtual environments, providing the user with a function of interacting with real and / or virtual objects including avatars, etc. A WTRU may include one or more of an independent (e.g., stand-alone) device or node (e.g., an XR device, a pair of XR glasses, a smart watch, a wearable device, etc.), a non-stand-alone device or node (e.g., a device, a sensor, a wearable device, a haptic glove, etc. associated with the WTRU), a device or node controlled by a network (e.g., by a network operator), a device or node not directly associated with and / or connected to a network (e.g., a gNB), but which may be a candidate if given certain parameters (e.g., FoV metadata including the size, dimensions, quality, etc. of the field of view (FoV), pose information, etc.), a stationary mobile device or node, a fixed device or node, a mobile or movable device or node, etc. In the embodiments described herein, the terms corresponding to any of a WTRU, a node, or a device may be used interchangeably and may refer to any type of device described herein.

[0093] The coordinating group may include one or more WTRUs, where the WTRU may be designated as an anchor WTRU and one or more other WTRUs may be designated as coordinating WTRUs or member WTRUs (e.g., the anchor WTUR may also perform the functions of a member WTRU). In an example, the anchor WTRU (e.g., in the context of coordinated XR) may host an application function (e.g., an XR application) that may receive a request for an XR action (e.g., any XR action), receive a request for an XR action from an application function located within the network (e.g., on an edge server or a remote server), initiate a discovery procedure to determine other WTRUs (e.g., devices or nodes in proximity to the anchor WTRU) that may be involved in performing an (e.g., any) XR action in the coordinating group, establish connectivity and / or a session (e.g., an XR session, a PDU session, an application session, etc.) by sending and / or receiving a request for session establishment, and / or operate as a primary anchor point for communicating with an access network (e.g., RAN) function or node (e.g., gNB, etc.), a core network function or node, and / or an application function. These operations may include, for example, sending and / or receiving session-related messages (e.g., capability transfer, auxiliary information transfer, configuration transfer, measurement information, XR action status information, session activation / deactivation, session release, etc.). The interface between the anchor WTRU (or member WTRU) and the network (e.g., gNB) may be referred to as the Uu link (e.g., the primary Uu link) when supporting a connection to the network.

[0094] The terms "cooperating WTRU" or "member WTRU" may be used interchangeably herein, for example, in the context of cooperative XR, to initiate discovery procedures and / or receive requests to make a WTRU discoverable (e.g., via sidelink or through the network) for performing (e.g., any) XR actions (e.g., the interface between a cooperating WTRU and a network such as a gNB may be referred to as a secondary Uu link when supporting a connection to the network), to send information related to XR actions (e.g., pose information, FoV parameters including the direction and / or width of the FoV, other FoV metadata, data including captured or mapped FoV content, media or video frames, auxiliary information, status information, etc.) directly to the network (e.g., gNB, CN function, application function, etc.) and / or indirectly to an anchor WTRU, to receive information (e.g., RRC configuration information, application configuration information, etc.) that may be used to determine (e.g., any) XR actions and / or an anchor WTRU, and to send messages or reports related to XR actions to the anchor WTRU and / or the network via the network and / or sidelink interface (e.g., via sidelink, Bluetooth connection, WiFi connection, etc.) (e.g., the message or report may include measurements or estimates of pose and / or FoV). A cooperating WTRU may be associated with multiple cooperating groups and an anchor WTRU.

[0095] When referred to herein, the XR experience may include the overall end - user experience that can result from the coordinated transmission of data to and / or reception of data from end - devices in a reliable and timely manner. Terms associated with "multimodality" may refer to the association (e.g., any association) between multiple flows and / or between multiple WTRUs. The flows and / or WTRUs may be associated with a coordinated WTRU group and / or may be associated with supporting an application or service common to one or more WTRUs.

[0096] "Anchor WTRU" or "coordinated WTRU" are non - limiting examples of terms that may be used in connection with the embodiments described herein. Other terms that may be used when referring to an anchor WTRU may include "central WTRU", "primary WTRU", "main WTRU", "initiating - side WTRU", etc. Other terms that may be used when referring to a coordinated WTRU may include "member WTRU", "auxiliary - side WTRU", "support - side WTRU", "secondary WTRU", etc. Entities or objects described herein, including a coordinated group, an anchor WTRU, a coordinated WTRU, and / or an XR action, may be associated with respective (e.g., different) identifiers (IDs) such as a coordinated group ID, an anchor WTRU ID per group, a coordinated WTRU ID per group, an XR action ID, etc. Each identifier or ID associated with coordinated XR may be assigned or configured, for example, by any of a WTRU, a network, or an application function. A tertiary WTRU, when referred to herein, may be a type of WTRU that may be associated with a role and functional capabilities (e.g., similar to those of a secondary WTRU) in a coordinated group. A tertiary WTRU may participate in XR actions for shorter durations and / or smaller subtasks. A tertiary WTRU may be configured based on partial configuration information. A tertiary WTRU may complete or perform XR actions with less time and / or less overhead.

[0097] Identifiers may be used to associate WTRUs within a coordinated WTRU group (which may also be referred to herein as a WTRU group for simplicity). An anchor WTRU and coordinated WTRUs (which may also be referred to herein as member WTRUs for simplicity) may be associated at a level that can change, for example, from one XR experience to another, and / or may be associated within the same XR experience. The association between WTRUs within a coordinated WTRU group may be initiated, for example, by an application (e.g., following a request for the application to provide an XR experience). The association between WTRUs within a coordinated WTRU group may spread or migrate to other layers within the communication framework (e.g., NAS, RRC, SDAP, PDCP, RLC, MAC, PHY, or any layer of the AS protocol stack).

[0098] An initial ID associated with an application may be maintained through multiple layers, or there may be different IDs generated at different layers, and the association may be made between corresponding IDs within each layer (e.g.,). The ID may remain the same throughout an XR experience, or may remain the same from one XR session to another. The ID may change from one XR experience to another, or from one XR session to another. The management and storage of IDs between WTRUs within a coordinated WTRU group may be performed by a CN, base station, application, and / or WTRU involved in the XR experience.

[0099] The service ID and the XR action ID can be matched. For example, the anchor WTRU may send one or more of the following IDs to the member WTRU, namely, the application / service / session ID, the WTRU ID, the coordination group ID, the XR action ID (e.g., for identifying an XR action supported by the WTRU and / or required to be performed by another WTRU). The member WTRU may send an instruction in response to detecting that the service ID or the XR action ID (e.g., in a discovery, request, or indication message received from the anchor WTRU) matches a pre-configured or available service ID or XR action ID for the member WTRU. IDs associated with one or more WTRUs within a coordinated WTRU group (e.g., the WTRU ID, C-RNTI, etc.) and / or IDs associated with the coordinated WTRU group (e.g., the group RNTI) may be used in (e.g., any) user plane (UP) or control plane (CP) procedures (e.g., scheduling procedures). For example, the ID may be used when sending an RRC message, SR / BSR, UCI, UL MAC CE, PUCCH transmission, PUSCH transmission, WTRU auxiliary data, etc., and / or when receiving an RRC signaling or RRC message, resource grant, configured grant, DCI, DL MAC CE, PDCCH transmission, PDSCH transmission, etc.

[0100] The WTRU may indicate its matching ability. For example, a coordinated WTRU may send an instruction when it determines that one or more capabilities currently supported by or within the capabilities supported by the WTRU (e.g., XR capabilities and / or connection capabilities) match the capabilities indicated by the anchor WTRU (e.g., in a discovery, request, or indication message).

[0101] WTRU group-based initial access may be supported. In an embodiment, a plurality of WTRUs within a cooperative WTRU group (e.g., including at least an anchor WTRU and member WTRUs) may cooperate within the group to perform initial access procedures on a group basis. Group-based initial access, as referred to herein, may refer to any procedure and / or function performed by the anchor WTRU and / or one or more member WTRUs to achieve initial access. Such procedures and / or functions may include the transmission and / or reception of (e.g., any) initial access messages (e.g., Msg1, Msg2, etc.), and / or the determination of corresponding actions (e.g., actions performed individually or per group) by one or more WTRUs during the initial access procedure.

[0102] The initial access signals described herein may include any of one or more RACH preambles, one or more sequences, and / or one or more partitions and / or resources that may be transmitted by a WTRU during a time opportunity (e.g., a RACH opportunity), an indication, message, or flag (e.g., a request for group-based initial access) associated with performing group-based initial access procedures, one or more UL resource grants or channels for sending the same, etc.

[0103] A WTRU (e.g., an anchor WTRU and / or a member WTRU) may transmit or receive instructions, signals (e.g., control signals and / or data signals), messages, and / or configurations via one or more combinations of broadcast signaling, RRC signaling, MAC CE, initial access messages, L1 channel transmissions, etc. while performing group-based initial access. For example, the WTRU may access or obtain information for performing group-based initial access via any of SIB, position SIB (posSIB), and / or SSB. The WTRU may transmit and / or receive request messages, response messages, and / or configuration messages related to positioning and / or initial access via RRC messages. The WTRU may transmit and / or receive request messages, response messages, configuration messages, and / or activation / deactivation instructions related to positioning and / or initial access in one or more MAC CE. In the UL, a MAC CE (e.g., carrying a request or response message) may be multiplexed in the PUSCH when transmitting, for example, Msg3 or MsgA. In the DL, the MAC CE may be multiplexed in the PDSCH when receiving, for example, Msg2, Msg4, or MsgB. The initial access messages described herein may include Msg1, Msg2, Msg3, Msg4, Msg5, MsgA, and / or MsgB. The L1 channel transmissions described herein may include PUCCH transmission, PUSCH transmission, PDCCH transmission, and / or PDSCH transmission.

[0104] The WTRU may transmit one or more messages and / or signals during group-based initial access procedures. The messages and / or signals may include a random access preamble, which may also be referred to herein as a preamble. The random access preamble may include a conventional preamble that may be sent in Msg1 and / or MsgA. The random access preamble may include a preamble selected by the WTRU in a contention-based manner and / or a dedicated preamble designated by the network in a contention-free manner.

[0105] The random access preamble may be transmitted as part of conventional random access procedures (e.g., 4-step CBRA, 2-step CBRA, 4-step CFRA type, 2-step CFRA, etc.), without limitation. The random access preamble may be sent in MSG1, Msg3, Msg5, and / or MSGA. The random access preamble (e.g., dedicated or common) may correspond to one WTRU and / or a group of WTRUs (e.g., a coordinated WTRU group). At least in the case of contention-free random access procedures, the preamble may be dedicated or designated by the network for the WTRU and / or WTRU group. The designation of the preamble for the WTRU and / or WTRU group may be performed by a WTRU such as an anchor WTRU.

[0106] The network may provide a list of contention - free preambles to a WTRU and / or WTRU group for performing random access. The contention - free preambles and contention - based preambles may correspond to the same set of resources or different sets of resources (e.g., one or more RACH opportunities in the time domain, one or more PRACH opportunities in the frequency domain, one or more SSBs corresponding to one or more beams in the spatial domain, etc.). The random access preamble may be encoded using the NAS ID of the WTRU and / or WTRU group, for example, through scrambling. For example, the NAS ID may include an ID that can uniquely identify the WTRU within the scope of any of a WTRU group, a cell, a cell group (e.g., one or more cells), a session (e.g., a PDU session), and / or a network (e.g., a PLMN or a RAN). In an example, a member WTRU may encode the preamble indicated by an anchor WTRU for group - based initial access using the NAS ID of the member WTRU and may send the encoded preamble to the network, for example, in Msg1, MsgA, and / or Msg3. The network may descramble the preamble and obtain the NAS ID of the member WTRU.

[0107] The association between a preamble (e.g., a RACH preamble) and a service type (e.g., a game, industrial robot control, etc.) can be established (e.g., through a mapping relationship) such that a WTRU (e.g., an anchor WTRU, a member WTRU, or a stand-alone WTRU) can access a set of preambles (e.g., a selected set) based on the type of service associated with an application executed on the WTRU. A network device can perform contention resolution based on the service type associated with a WTRU or WTRU group (e.g., by prioritizing one WTRU over another and / or one WTRU group over another WTRU group) (e.g., when the network device receives the same preamble from two or more WTRUs and / or WTRU groups).

[0108] The random access preamble may carry additional information regarding the WTRU group. In an example, contention-based preambles and / or contention-free preambles may be used or reserved for initial access by the WTRU group (e.g., which may be referred to interchangeably herein as group initial access). These preambles may implicitly notify the network about group-based initial access. In an example, the preambles for group initial access may be specifically indicated to the WTRU by the network in, for example, a SIB (e.g., SIB1, subsequent periodic SIBs, subsequent requested SIBs, and / or XR-specific SIBs). In an example, the designation of the preamble for group initial access may be explicit (e.g., by adding one or more extra bits in a configuration message). An indication such as a flag may be used to indicate initial access (e.g., individual) or group access for each WTRU. The indication may indicate the number and / or type of WTRUs within the group. In an example, some preambles may be reserved or allocated for WTRU groups having a specific number of WTRUs (e.g., within a range of numbers). For example, preamble A may be allocated to a WTRU group having 2 to 4 WTRUs, and preamble B may be allocated to a WTRU group having 4 to 6 WTRUs. The anchor WTRU may select the preamble corresponding to the number of WTRUs within that WTRU group. In an example, the designation of the preamble for group initial access may be implicit. For example, there may be a common understanding between the WTRU and the network regarding the preamble used for group initial access (e.g., the third preamble at every RACH opportunity on odd-numbered SSBs on every other resource block). In an example, this common understanding may be cell-specific or base station-specific and may be obtained by the WTRU, for example, when the WTRU first connects to the cell or gNB.

[0109] When transmitting a preamble, the WTRU may start a timer (T300 or another timer) to wait for a response message from the network (e.g., Msg2 or Msg4). In the case of group-based initial access, the length of this timer (which may be set by the WTRU) may be different from the length of the timer set for WTRU-based initial access. The length of the timer may depend on any one or more of the following parameters. The length of the timer may depend on the delay acceptable by the XR application. For example, in the case of a critical XR application that may be able to tolerate a strict delay budget, the length of the timer may be shorter than in the case of an XR application that may be able to maintain QoE using a larger delay budget. The length of the timer may be a function of the number of WTRUs in the WTRU group (e.g., in the case of group initial access). For example, the more WTRUs there are in the WTRU group, the longer the timer may be.

[0110] The anchor WTRU may send an indication of the RACH resources (e.g., preamble and / or RACH opportunity) that the member WTRUs may use to send a message related to RACH (e.g., Msg1 or MsgA) to the network. In an example, the anchor WTRU may indicate a common preamble for one or more (e.g., all) member WTRUs in the group to use at different specified RACH opportunities in the time domain. In an example, the anchor WTRU may be able to specify or allocate different preambles for each member WTRU to use. The preamble specified or allocated to the member WTRUs by the anchor WTRU may be contention-based and / or contention-free (e.g., for individual or group-based initial access).

[0111] A WTRU, such as an anchor WTRU of a WTRU group, may confirm a resource allocation or assignment. For example, an anchor WTRU of a WTRU group may send a confirmation of a resource allocation or assignment within the WTRU group to a base station following a determination and / or indication of a resource allocation (e.g., preamble, RACH opportunity) to one or more member WTRUs of the WTRU group (e.g., including the anchor WTRU). The confirmation may indicate whether a RACH resource allocation or assignment to one or more member WTRUs (e.g., including the anchor WTRU) was successful. In an example, the confirmation may include a single positive acknowledgment (ACK) indicating that the initial access was successful for one or more (e.g., all) members of the WTRU group. The confirmation may include additional information, such as which RACH resources were allocated to which WTRUs within the group (e.g., preamble #4 in RACH opportunity #2 allocated to member WTRU #2 within the WTRU group). The resource allocation or assignment to a member WTRU may include information regarding the number and / or index of RACH opportunities in the time domain, the number and / or index of RACH opportunities per PRACH slot in the time domain, the number and / or index of PRACH opportunities in the frequency domain, the SSB associated with the aforementioned parameters (e.g., the index of two RACH opportunities associated with the SSB having index #0). The confirmation of the resource allocation or assignment may be reported to the network in the form of a mapping relationship (e.g., a mapping table). For example, the anchor WTRU may send a mapping to the base station that may enumerate the RACH resources (e.g., preamble, preamble ID, RO, RO ID, etc.) allocated to one or more member WTRUs (e.g., identified by their respective WTRU IDs). The confirmation of the resource assignment may include information indicating the anchor WTRU NAS ID, the WTRU group ID, and / or the NAS ID of one or more member WTRUs of the WTRU group.The information can be sent as stand-alone information (e.g., as uplink control information (UCI)) or as part of a status report. In an example (e.g., an anchor WTRU may make a group RRC setup request instead of a WTRU group), the confirmation may be associated with or included in the group RRC request. In these examples, a member WTRU may also make individual RRC requests to the network. The confirmation of resource allocation or assignment may be sent in Msg3, Msg5, and / or MsgA.

[0112] One or more identifiers may be associated with the WTRU group. When transmitting a message, the WTRU may include in the message one or more of the RACH preamble ID (e.g., the ID used in Msg1, MsgA, or Msg3), the WTRU's own ID, the ID of a member WTRU (e.g., NAS WTRU ID, temporary mobile subscriber identity (TMSI), C-RNTI, TC-RNTI, or any other ID that can uniquely identify the WTRU), and / or the ID of the WTRU group (e.g., group TC-RNTI, group C-RNTI, or any other ID that can uniquely identify the WTRU group and / or the association of the WTRU to the WTRU group). The identifier of the WTRU or WTRU group may be signaled by the network. For example, the network may signal a temporary C-RNTI assignment to the WTRU in a random access response message (e.g., Msg2 or MsgB). The anchor WTRU may send its NAS ID and / or the NAS ID of a member WTRU to the network, e.g., in Msg3.

[0113] The anchor WTRU may send an RRC setup request on behalf of the WTRU (e.g., the anchor WTRU itself) and / or a WTRU group. The UL grant allocation included in a random access response (e.g., received in Msg2 or MsgB) may be used to send an RRC setup request and / or a group-based RRC setup request (e.g., in Msg3). In an example, the anchor WTRU may send a group RRC setup request, whereby one or more member WTRUs may not have to send individual RRC setup requests on their own. In an example, the anchor WTRU may send an RRC setup request on its own, and (e.g., each) member WTRU may send its own RRC setup request. In these examples, the anchor WTRU may send a request to the network for additional uplink grants that the anchor WTRU may transfer to the member WTRUs to enable the member WTRUs to make individual RRC setup requests. For example, the request may be explicit or implicit. In an example, in response to receiving a preamble reserved for group initial access from the anchor WTRU, the network may send additional uplink grant resources to the anchor WTRU (e.g., in the random access response). The amount of uplink grant resources that the network may send to the anchor WTRU may depend on the number of WTRUs in the WTRU group, which may have been indicated to the network by the anchor WTRU (e.g., explicitly in a RACH message or implicitly through the selection of a particular preamble). The amount of uplink grant resources that the network may send to the anchor WTRU may be based on a default or average amount allocated by the network for group initial access. The RRC setup request may include a WTRU identifier, a WTRU group identifier, and / or a cause for establishment. The cause for establishment may include, for example, an emergency call, a high-priority access, a WTRU group access, a multimedia priority access, etc.

[0114] A member WTRU of a WTRU group may send location, orientation, and / or positioning information of the member WTRU to an anchor WTRU. The anchor WTRU may use the location, orientation, and / or positioning information of the member WTRU to determine whether the member WTRU may be a valid member of the WTRU group. In an example, the anchor WTRU may receive insufficient resources (e.g., RACH resources) from the network for group-based initial access, and the anchor WTRU may use the location, orientation, and / or positioning information of the member WTRU to determine how to prioritize the member WTRU regarding the allocation of received RACH resources within the WTRU group.

[0115] The transmission of location, orientation, and / or positioning information by a member WTRU to an anchor WTRU can be periodic (e.g., having a periodicity configured by the anchor WTRU, configured by an XR application, and / or configured by the network), semi-periodic (e.g., configured and activated / deactivated via a control message such as a PDCCH control message), and / or event-triggered. Examples of events that can trigger the transmission of location, orientation, and / or positioning information can include one or more of the following. The transmission can be triggered when the member WTRU detects a change in its movement (e.g., a change exceeding a preconfigured threshold), in which case the member WTRU can report the movement (e.g., new location information) to the anchor WTRU. The transmission can be triggered by receipt of an indication from a higher layer or application. For example, the member WTRU can receive a request or indication from an XR application to report the member WTRU's location, orientation, and / or positioning information to the anchor WTRU. The transmission can be triggered by receipt of an indication or request from the anchor WTRU to send location, orientation, and / or positioning information. For example, when the anchor WTRU selects a member WTRU to transfer resources for initial access (e.g., group-based RACH resources provided by the network), the anchor WTRU can send a request to the member WTRU to report the member WTRU's location, orientation, and / or positioning information.

[0116] In an example, in response to a member WTRU sending its location, orientation, and / or positioning information, the anchor WTRU may send an ACK to signal successful reception of the information. Failure to receive the ACK may trigger the member WTRU to re-send the information. The anchor WTRU may send a NACK to the member WTRU if the anchor WTRU has not received the location, orientation, and / or positioning information from the member WTRU or cannot successfully decode it. Receiving a NACK from the anchor WTRU may trigger the member WTRU to re-send the information. In an example, failure to receive a message from the network may trigger the member WTRU to send its location, orientation, and / or positioning information to the anchor WTRU and / or the network. For example, the member WTRU may expect a message (e.g., Msg4) from the network after sending a RACH preamble to the network. The member WTRU may have started a timer after sending the preamble (e.g., in Msg1) to the network, and if the member WTRU has not received a response (e.g., Msg4) from the network by the expiration of the timer, the member WTRU may send its location, orientation, and / or positioning information to the anchor WTRU or the network. In an example, the location, orientation, and / or positioning information of the member WTRU may be sent in response to a request from the network (e.g., either implicitly or explicitly), or the information may be sent as a result of receiving a NACK or as a result of not being able to receive an ACK.

[0117] The network may over-allocate resources to a WTRU group, in which case the anchor WTRU of the WTRU group may send a cancellation indication to the network. This may occur, for example, if the network does not recognize the number of WTRUs in the WTRU group and has determined the resource allocation based on, for example, a default or average configuration for group-based initial access resources or based on a previous request from the anchor WTRU.

[0118] Messages and / or signals associated with group-based initial access can be sent at various opportunities. The WTRU may send one or more of the messages, signals, or information described herein in any of Msg1, Msg3, Msg5, or MsgA. The WTRU may send a preamble in Msg1 (e.g., alone or scrambled using the NAS ID). The anchor WTRU may send a preamble for the anchor WTRU's own initial access and / or group-based initial access to the network. The anchor WTRU may use (e.g., generate or be provided with) an ID to uniquely identify the WTRU group and / or may send the ID to the network (e.g., in Msg3 or Msg5). The anchor WTRU may send the network a confirmation of RACH resource allocation or assignment within the WTRU group (e.g., in Msg3 or Msg5). The anchor WTRU may send the network its NAS ID and / or the NAS ID of the member WTRUs (e.g., in Msg3 or Msg5).

[0119] The WTRU may transmit one or more of the messages, signals, or information described herein in any of Msg1, Msg3, Msg5, or MsgA based on one or more of the following. The WTRU (e.g., an anchor WTRU) may send a group-based RACH preamble (e.g., in Msg1 or MsgA) following an indication from an XR application to initiate group initial access. The WTRU may send a RACH preamble following receipt of a RA preamble assignment from the network (e.g., in a contention-free RA procedure). The WTRU may send a RACH preamble to the network following receipt of an indication from a member WTRU to send a RACH preamble (e.g., an indication received via a sidelink interface). The WTRU may receive an uplink grant (e.g., a RACH resource permitted via a random access response message) and send a request to the network for a larger UL grant (e.g., more RACH resources) in response to determining that the UL grant is insufficient. The UL grant may be considered insufficient if the WTRU (e.g., an anchor WTRU) cannot use the UL grant to convey information regarding group initial access to the network. This may be because the information carried by the WTRU (e.g., in Msg3) may include, for example, confirmation of the assignment, the WTRU ID of the anchor WTRU, the WTRU IDs of individual members, the WTRU group ID, etc., and the content thereof may require a larger UL grant. For example, when the anchor WTRU receives an indication from an application that a number of WTRUs may all perform initial access within a strict time window (e.g., to guarantee the QoE of the user experience), and the anchor WTRU may not be able to accommodate a number of member WTRUs using the UL grant, the UL grant may be considered insufficient.

[0120] The WTRU may receive and / or access resources and / or configuration information associated with initial access in order to enable group-based initial access. One or more of the initial access signals or messages described herein may be transmitted or received by the WTRU during an initial access procedure, for example, in one or more of Msg1, Msg3, Msg5 (e.g., in the case of a 4-step RA type), or MsgA (e.g., in the case of a 2-step RA type), and / or together with them. The RACH resources and / or configuration information used by the WTRU for group-based initial access may include one or more of the following. The RACH resources may include, for example, preambles, sequences, partitions, and / or time and / or frequency resources associated with the RACH procedure. The RACH resources may include one or more RACH opportunities that the WTRU may use to transmit a RACH preamble. The parameters associated with the RACH resources may include start / stop time, transmission duration, periodicity, transmission power, transmission spatial direction, etc. The WTRU may select RACH resources from a set of resources that may be common to multiple WTRUs or may be dedicated to the WTRU. The common or dedicated RACH resources may be indicated via a broadcast channel message or beam (e.g., in SIB, SSB, etc.), via an initial access message (e.g., in Msg2 and / or MsgB), or via a configuration for the WTRU.

[0121] The RACH resources accessible by the WTRU are used for general initial access, specialized for group-based initial access, and / or can be specialized for other services or network slices (e.g., for XR services, for URLLC services, etc.). For example, the WTRU may have access to two sets or partitions of RACH resources, where the first set of RACH resources may be intended for group-based initial access purposes and the second set of RACH resources may be intended for non-group-based initial access purposes. Different resources or resource sets can be associated with respective IDs or indexes that can be received by the WTRU via broadcast or dedicated signaling.

[0122] The WTRU may have access to one or more sets of group-based RACH preambles. The WTRU may randomly select a RACH preamble or select it based on selection criteria. For example, such selection criteria may indicate the selection of a group-based RACH preamble if the RSRP measured on a DL signal related to the RACH procedure (e.g., SIB, DL PRS, DMRS, SSB, TRS, CSI-RS, etc.) exceeds or falls below a threshold.

[0123] The WTRU may implicitly indicate information related to the WTRU group to the network. The WTRU may implicitly indicate information to the network, for example, by transmitting a UL signal using group-based RACH resources. For example, the WTRU may send a specified group-based preamble to the network, and the network may signal group-based initial access.

[0124] Resources, resource sets, and / or configurations (e.g., in whole or in part) associated with group-based initial access (e.g., by sending a RACH indication or request) can be received by the WTRU, for example, prior to or during initial access, in one or more combinations of the following scenarios.

[0125] The WTRU may receive information regarding RACH resources and / or opportunities (e.g., group-based or non-group-based) on a broadcast channel via, for example, SIBs and / or SSBs. Resources, resource sets, and / or configurations that may be used by the WTRU during initial access or after establishing connectivity with the network (e.g., in the RRC_CONNECTED state) may be indicated using IDs and / or index values. In an example, the WTRU may receive information at an opportunity to transmit one or more of the initial access signals that it anticipates the network will receive to process group-based initial access of the WTRU. In an example, the WTRU may receive information (e.g., an ID) regarding parameters associated with UL transmissions (e.g., group-based RACH, PUSCH, etc.). These parameters may include, for example, the transmit power to be applied (e.g., a range of values or transmit power as a maximum value), an offset value relative to a reference frame, numerology, QCL / spatial relationship, TRP / cell ID, beam ID, spatial direction to be applied, etc. The parameters may be used by the WTRU to transmit an initial access signal and / or to make other requests related to initial access (e.g., on-demand requests sent in Msg1, Msg3, or MsgA).

[0126] A WTRU may receive information regarding RACH resources via a paging message. For example, the WTRU may have transitioned to the RRC_IDLE or INACTIVE state (e.g., after a previous connection establishment and / or operation in the RRC_CONNECTED state), and the WTRU may receive information on resources for sending an initial access signal in one or more paging messages. In this case, the one or more paging messages received by the WTRU may include a WTRU ID (e.g., a paging RNTI), and / or resources, configurations, and / or IDs / indexes associated with UL signals (e.g., transmitted on the RACH or PUSCH). By way of example, the WTRU may receive information regarding RACH resources in a conventional paging opportunity, or a positioning-specific paging opportunity.

[0127] The RACH resource can be pre-configured or pre-defined for the WTRU. For example, the WTRU can use a pre-configured (or pre-defined) resource for the WTRU and a resource stored in the WTRU to transmit or receive an initial access signal. The WTRU can receive the pre-configuration, for example, through previous connectivity (e.g., previous PDU session) and / or previous RRC configuration (e.g., received by the WTRU in the RRC_CONNECTED state). In an example, the pre-configured resource for the initial access signal can be received when the WTRU transitions to the RRC_INACTIVE or RRC_IDLE state (e.g., in one or more RRC release messages such as a Suspend Config message, or in one or more RRC reconfiguration messages). In an example, the WTRU can receive validity information, conditions, and / or criteria associated with the pre-configured resource when the WTRU receives a pre-configured resource for the initial access signal. Such validity conditions can include a validity area (e.g., a list of cells), a validity time (e.g., a timer or timer duration), and / or a validity measurement threshold (e.g., a threshold corresponding to the RSRP measurement value of the DL signal associated with the initial access signal). The validity conditions can indicate conditions that are expected to be met to determine whether a pre-configured resource for the initial access signal is valid.

[0128] The WTRU can receive information regarding the RACH resource during the transmission and / or reception of the initial access message. For example, the WTRU can receive a resource for an initial access signal (e.g., transmitted on the RACH or PUSCH) for group-based initial access in one or more of the reception of Msg2 (e.g., a random access response message), Msg4 (e.g., in the case of a 4-step RA type), and / or MsgB (e.g., in the case of a 2-step RA type). The WTRU can receive the resource, for example, when it transmits an explicit or implicit request for a resource for group-based initial access in Msg1, Msg3, or MsgA.

[0129] The WTRU may send an explicit request for resources for group-based initial access by transmitting a RACH indication in Msg1 or MsgA, along with a request indication or flag (e.g., a request indication or flag indicating that the initial access is group-based), and / or by transmitting a RACH signal encoded or scrambled using the request indication. The WTRU may send an implicit request for UL resources when transmitting a RACH preamble or partition that may be associated with a request indication for group-based initial access. The WTRU may send an implicit request for resources by transmitting a RACH preamble during a RACH opportunity that may be associated with, dedicated to, and / or reserved for such a request.

[0130] The WTRU may receive resources for group-based initial access in one or more search spaces associated with a BWP and / or in different BWPs. For example, the WTRU may be configured using an association or mapping relationship between a RACH signal for Msg1 / MsgA and one or more search spaces for monitoring a RAR (e.g., Msg2 or MsgB) or an activation / deactivation indication (e.g., an ID or index for group-based initial access). Such an association or mapping relationship may be received by the WTRU in a broadcast channel message (e.g., SIB) or an RRC message (e.g., an RRC release or RRC reconfiguration message). Such an association or mapping relationship may be preconfigured for the WTRU. If the RACH signal used by the WTRU includes an explicit or implicit indication regarding the activation of a resource or a preconfigured resource, the WTRU may receive an indication of the activation / deactivation of the resource or resources in one or more search spaces associated with the RACH signal.

[0131] The WTRU may identify resources and / or configurations for group-based initial access based on semi-static configuration information between the resources and one or more of service type (e.g., XR or URLLC), cell type, base station type (e.g., gNB, TRP, IAB node), and / or PLMN type (e.g., public or private network). Such semi-static configuration information may be received by the WTRU on a broadcast channel (e.g., via SIB) or in an RRC message, or the semi-static configuration information may be pre-configured for the WTRU. For example, when triggering WTRU group-based initial access (e.g., for an XR service), the WTRU may determine resources for transmitting an initial access signal (e.g., on RACH or PUSCH) based on semi-static configuration information received in an SIB indicating the mapping between the XR service and the resources.

[0132] A WTRU (e.g., an anchor WTRU) may receive an uplink grant as part of a random access response (RAR) message that may be received, for example, in Msg2 or MsgB. The UL grant received by the WTRU may be a UL grant for the WTRU itself and / or for a WTRU group, in which case the WTRU may distribute the grant to members of the WTRU group. The WTRU may use the uplink grant to send an RRC setup request for itself or a group RRC setup request such that members of the WTRU group may not need to send individual RRC setup requests. If the size of the UL grant is not large enough (e.g., to send an indication regarding group initial access and / or for the anchor WTRU to distribute the UL grant to member WTRUs for each respective RRC request of the member WTRUs), the WTRU may send a request for a larger UL grant and may receive such a larger UL grant from the network in one or more subsequent messages (e.g., after receiving the RAR message). Members of the WTRU group may receive UL grants from the anchor WTRU and / or from the network.

[0133] The network may estimate the timing advance for a WTRU or WTRU group based on a preamble received by the network (e.g., in Msg1 or MsgA), and may send the TA value in a RAR message to the WTRU (e.g., the anchor WTRU of the WTRU group). The TA value may be based on a propagation delay that may vary according to the distance between the WTRU and the network (e.g., gNB or transmitter tower). The TA value received by the WTRU from the network may be a function of an indication sent by the WTRU in a previous message. For example, the anchor WTRU may send one or more indications regarding an acceptable delay budget by an application to the base station, and the base station may configure the timing advance for the anchor WTRU or WTRU group based on the indication (e.g., in addition to the propagation delay).

[0134] The anchor WTRU may receive from the network a TA (e.g., a common TA) that may be applicable to a plurality (e.g., all) of the WTRUs within a WTRU group associated with the anchor WTRU (e.g., if the WTRUs are collocated). The TA may be used for group initial access. If the anchor WTRU has received fewer resources (e.g., RACH preamble, random access opportunity (RO), etc.) than requested for group-based initial access procedures, the anchor WTRU may prioritize one or more member WTRUs for the resources and may take into account the TA value indicated by the network when determining which member WTRU should receive the resources. For example, if a member WTRU has indicated to the anchor WTRU a change in its positioning, location, and / or orientation, and as a result, it is determined that the member WTRU is further away (e.g., beyond a pre-defined radius by an application), the anchor WTRU may determine that this member WTRU may not be able to perform initial access within the TA indicated by the network and may lower the priority of the member WTRU.

[0135] The network may signal to the WTRU an identifier associated with the WTRU and / or WTRU group. For example, the network may signal to the WTRU a temporary C-RNTI (TC-RNTI) or group TC-RNTI in a random access response message (e.g., Msg2 or MsgB). As another example, after the anchor WTRU sends an indication of group initial access and / or the number of WTRUs included in the WTRU group to the network (e.g., gNB), one or more member WTRUs of the anchor WTRU and / or WTRU group may receive the group TC-RNTI.

[0136] The RAR message may correspond to Msg2 or MsgB as described herein. The content of the RAR message may include, for example, a timing advance and / or UL grant for the anchor WTRU, a UL grant for the member WTRU, and / or a UL grant for the WTRU group. The time resource, frequency resource, and / or downlink MCS associated with the RAR message may be indicated to the WTRU in DCI (e.g., in PDCCH transmission) to know when and / or how to decode the RAR message. This indication from the network may be scrambled using the receiving WTRU identifier and / or WTRU group identifier.

[0137] A WTRU may receive an RRC setup message from the network (e.g., in Msg4). For example, the anchor WTRU of a WTRU group may receive an RRC setup message (e.g., as a final message) before transitioning to the connected state. DCI scrambled with the WTRU C-RNTI and / or group C-RNTI may indicate the frequency and / or time resources allocated to transmit a transport block containing the RRC setup message, whereby one or more corresponding WTRUs may recognize when to expect or monitor the RRC setup message. The RRC setup message may be designated for the anchor WTRU, the WTRU group, and / or one or more members of the WTRU group. The RRC setup message may be sent to setup signal radio bearers (SRBs) such as SRB1 and / or cells such as the master cell. The RRC setup message may include information elements such as radioBearerConfig and masterCellGroup. The anchor WTRU may stop a timer after receiving the RRC setup message. For example, the anchor WTRU may start a timer (e.g., timer T300) after sending a preamble and may stop the timer after receiving an RRC setup message (e.g., in Msg4 or MsgB).

[0138] A WTRU may receive information regarding QoE maintenance from an application or upper layer. The information may include, for example, the maximum duration for which a WTRU group is to establish connectivity with the network (e.g., the time window for performing initial access), the priority of each member WTRU, the NAS ID of the member WTRU, and / or an ID that uniquely identifies the WTRU to the application.

[0139] The anchor WTRU may receive assistance information from one or more member WTRUs (e.g., of a WTRU group) to enable adjustment of group-based initial access procedures. The assistance information may include an identifier of the member WTRU (e.g., a C-RNTI or NAS ID, or any other ID that may uniquely identify the member WTRU). The assistance information may include connectivity-related capability information, such as information regarding the number and / or type of interfaces supported by the WTRUs in the WTRU group (e.g., NR Uu, NR SL, WiLAN, and / or Bluetooth, etc.). The assistance information may include capability information regarding interfaces that may be supported by the WTRU and / or required or used by the WTRU to support XR actions in other WTRUs. Such information may include any of bandwidth, number of carriers, number of transmit antennas, number of receive antennas, antenna configuration, etc. In an example, the antenna configuration information may implicitly indicate to the anchor WTRU the range of SSBs that the member WTRU may be capable of measuring and / or reporting. At the start of an XR session, static capability information exchange (e.g., static capability information exchange regarding the type of interfaces supported) may occur, while more dynamic capability information exchange may occur when a change is detected (e.g., each time it is detected) (e.g., the member WTRU may send a notification to the anchor WTRU indicating a change in antenna configuration).

[0140] The anchor WTRU may receive from the member WTRU information regarding link failures, disconnections, insufficient channel quality, etc. detected at the member WTRU. In an example, the anchor WTRU may determine that due to a link failure at the member WTRU, the member WTRU may not be able to perform an initial access within the timing advance value indicated by the network (e.g., in a random access response message). In response, the anchor WTRU may decide not to include the member WTRU in the group initial access procedure. In an example, the anchor WTRU may send a group RRC request when the member WTRU is experiencing a temporary insufficient channel condition that may limit the transmission and / or reception of the member WTRU.

[0141] The WTRU may start a timer, for example, when sending Msg1, Msg3, and / or MsgA. The length of the timer may be set based on the acceptable delay budget by the XR application. When the timer expires, the WTRU may expect a status report from the network (e.g., in Msg4 or MsgB). The status report may indicate whether the initial access by a plurality of (e.g., all) access points has been successful. This indication may be done on a per-group basis or on a per-WTRU basis.

[0142] Information (e.g., configuration information) can be exchanged between a WTRU and a network to obtain a common understanding of how to read, decode, or interpret status reports such as RARs. For example, "success" in the context of such a status report can imply success in completing an initial access procedure, and "unsuccessful" in this context can imply failure in completing the initial access procedure. In an example, failure in completing the initial access procedure can result from the member WTRU failing to send Msg1 and / or MsgA, or failing to send the version of Msg1 / MsgA using the specified preamble to the network. In an example, failure in completing the initial access procedure can result from the network failing to receive and / or decode Msg1 and / or MsgA, and / or failing to receive and / or decode the version of Msg1 / MsgA from the member WTRU. In an example, failure in completing the initial access procedure can result from the network failing to decode Msg1 and / or MsgA, and / or failing to decode the version of Msg1 / MsgA from the member WTRU before the time window expires.

[0143] Status reports such as RAR can be designated to an anchor WTRU, a member WTRU, and / or a WTRU group (e.g., including an anchor WTRU and / or member WTRUs) such that (e.g., any) member of the WTRU group can decode the report. For example, if the status report indicates the WTRU group NAS ID, the anchor WTRU may assume that initial access for a plurality (e.g., all) of the members of the WTRU group (e.g., including the anchor WTRU) has been successful. As another example, the status report may explicitly indicate the NAS IDs of the successful WTRUs and the unsuccessful WTRUs. If a member WTRU was unsuccessful in initial access, the anchor WTRU may send auxiliary information to the member WTRU. The anchor WTRU may send an instruction to this member WTRU to retry initial access to the unsuccessful member WTRU, for example, by sending Msg1 or MsgA again using the same RACH resource over another n times (n≥1), using the same power, or using increased power. The anchor WTRU may indicate to the unsuccessful member WTRU that the retried initial access (e.g., the initial access retried by sending Msg1 or MsgA) may use a RACH resource (e.g., preamble) that may have been used by another member WTRU in a successful initial access (e.g., in a RACH opportunity determined by the anchor WTRU). The anchor WTRU may specify a plurality of RACH opportunities for retrying initial access over another n times (n≥1) using the same power or increased power.

[0144] The status report may indicate the NAS ID of the member WTRU that was successful in initial access. Based on such a status report, the anchor WTRU may infer that at least one member WTRU was unsuccessful in initial access and may send (e.g., directly) auxiliary information to the unsuccessful member WTRU. For example, the anchor WTRU may indicate one or more determined RACH resources to the unsuccessful WTRU via a sidelink interface for resending Msg1 or MsgA.

[0145] The status report may indicate one or more solutions for an unsuccessful initial access. For example, the network may send an indication to the WTRU regarding the validity of a previously allocated RACH resource (e.g., preamble, RO, etc.). The anchor WTRU may consider the validity information when designating resources to one or more member WTRUs to retry the initial access following a failed attempt. As another example, the member WTRU may receive and decode the status report (e.g., in Msg4) and use the validity information of the available RACH resources to send a replayed request (e.g., Msg1 or MsgA) to the network. As yet another example, if the anchor WTRU was unsuccessful in its random access procedure, the anchor WTRU may determine that one or more member WTRUs may be successful in their random access procedures (e.g., via direct communication with the member WTRUs via sidelink), and the anchor WTRU may perform a stand-alone RACH procedure (e.g., a two-step RACH procedure) based on the resource validity information indicated by the network.

[0146] The WTRU may transmit an initial access signal associated with group-based initial access based on the detection of a triggering event or condition. The triggering event or condition may include one or more combinations of the following. The triggering event may include the reception of an indication from a higher layer or application. For example, the WTRU may trigger group-based initial access when it receives a higher layer or application request or indication for such initial access. The WTRU may select a group-based RACH preamble and transmit the selected preamble in a RACH opportunity configured for group-based initial access. The triggering event may include the detection of one or more reference locations. For example, the WTRU may trigger group-based initial access when it detects one or more TRPs, one or more base stations, or one or more cells (e.g., via SIB or SSB) that support group-based initial access. In an example, the WTRU may operate in an inactive or idle state and may be preconfigured with an area of validity (e.g., a list of cells) for performing group-based initial access. In response to detecting a cell ID that matches at least one cell within the area of validity, the WTRU may initiate a group-based initial access procedure.

[0147] The triggering event may include a priority associated with group-based initial access. For example, the WTRU may trigger group-based initial access when the priority value associated with group-based initial access is higher than the priority associated with non-group-based initial access. The priority value may be preconfigured in the WTRU, for example, or may be received by the WTRU via an SIB for low latency cooperative XR.

[0148] When the WTRU is operating in an inactive / idle state, the WTRU may trigger group-based initial access in response to determining that the location of one or more WTRUs within the WTRU group has changed beyond a certain threshold, or that the RSRP measurement of a DL signal or channel performed by a WTRU within the WTRU group has exceeded or fallen below a threshold. A WTRU (which may be, for example, an anchor WTRU or a member WTRU within the WTRU group) may be configured to perform group-based initial access periodically, in which case the WTRU may trigger group-based initial access based on the configured periodicity.

[0149] The triggering event may include the detection of a cell that may support group-based initial access. For example, if the WTRU discovers two or more cells and at least one of the discovered cells supports group-based initial access, the WTRU may prioritize the group-based initial access of the cell that supports group-based initial access.

[0150] The triggering event may include the reception of broadcast information that may include information related to positioning. For example, the WTRU may determine to initiate group-based initial access if the SIB or SSB includes information or an indication related to group-based initial access (e.g., an indication for the WTRU to initiate initial access).

[0151] The WTRU may perform measurements to facilitate group-based initial access procedures. In an example, a member WTRU of a WTRU group experiencing a beam blockage may perform beam blockage recovery by performing related beam measurements (e.g., SSB measurements such as SS-RSRP, SS-RSRPB, SS-RSRQ, SS-SINR, etc.) and / or RACH procedures. The anchor WTRU of the WTRU group may assist the member WTRU in the beam recovery process (e.g., when the anchor WTRU is in a connected state) based on beam measurements of the anchor WTRU itself, which may include, for example, SSB beams and / or CSI-RS measurements. While in a connected state, the anchor WTRU may map one or more CSI-RS beams (e.g., narrow CSI-RS beams) to a wider SSB beam based on the QCL state and / or TCI state configuration. The anchor WTRU may indicate a subset of SSB beams to be considered for beam measurements. The subset of SSB beams may be based on, for example, the k strongest beams that may meet a minimum RSRP requirement. The anchor WTRU may indicate this information to the network (e.g., via the Uu link) and / or to the member WTRUs of the WTRU group (e.g., directly via the sidelink).

[0152] In an example, if the anchor WTRU experiences a beam blockage, it may communicate with one or more member WTRUs within the WTRU group to check the status of their connections. The member WTRUs may perform beam measurements (e.g., SSB measurements such as SS-RSRP, SS-RSRPB, SS-RSRQ, SS-SINR, etc.) for a subset of beams or all of the beams and may report the measurement values to the anchor WTRU (e.g., as a response to a notification message from the anchor WTRU indicating a beam blockage).

[0153] In an example, if the measurements by the anchor WTRU indicate a potential Uu beam obstruction and / or the RSRP of the serving beam drops to a value approaching a threshold for continuous use of the beam, the anchor WTRU may choose not to provide a subset of the beams to the member WTRUs, enabling the member WTRUs to perform beam measurements on an SSB beam set (e.g., the entire SSB beam set) or a set of beams that the member WTRUs may consider suitable.

[0154] In an example, the anchor WTRU may recognize other devices within its WTRU group that may have experienced beam obstruction and / or beam recovery. The anchor WTRU may choose to exclude failed SSB beam measurements from the set of measurements that the anchor WTRU may indicate to member WTRUs (e.g., that may have experienced beam obstruction). In an example, the anchor WTRU may choose to indicate a limited set of SSB beam measurements, which may include beams based on the anchor WTRU's own measurements and / or the most recent set (e.g., the latest set) of SSB beams of member WTRUs that may have recovered from beam obstruction.

[0155] In an example, the set of beams that the anchor WTRU may desire for a member WTRU (e.g., a new member to the WTRU group) to consider can include (e.g., consist of only) SSB beams selected by multiple (e.g., all) WTRUs within the group (e.g., by any of the anchor WTRU and / or member WTRUs) or a subset of SSBs selected by existing member WTRUs within the WTRU group (e.g., by any of the anchor WTRU and / or member WTRUs).

[0156] In an example, for beam selection and / or RACH procedures, the state of the WTRUs within a WTRU group may be considered. For example, if a member WTRU is transitioning from the RRC_Idle state to the RRC_Connected state, the member WTRU may perform beam sweeping or beam measurements (e.g., based on an indication by the anchor WTRU) to find the best SSB beam set. In this case, a reduced beam measurement set may not be shown to the member WTRU. Such behavior may be suitable at least when the anchor WTRU decides not to restrict the SSB beam measurement or selection process. The behavior may be suitable in scenarios where, for example, the member WTRU may not be able to be located close to the anchor WTRU or may have moved further away from the anchor WTRU since previous beam measurements. The behavior may be suitable when the anchor WTRU decides that the member WTRU should perform beam measurements that it would perform if it were attempting to recover from RLF (e.g., due to a blockage) and the member WTRU is operating as a stand-alone WTRU (e.g., not part of a WTRU group).

[0157] In an example, if a member WTRU is attempting to transition from the RRC_Inactive state to the RRC_Connected state, it may not be necessary for the member WTRU to perform an exhaustive beam sweep, and the member WTRU may start from a previous SSB beam measurement set and perform additional sweeps or measurements if the link quality of those beams falls below a threshold. The anchor WTRU may provide a beam measurement set to the member WTRU (e.g., via sidelink), and the beam measurement set may be based on the anchor WTRU's own measurements and / or beam measurement information provided by other WTRUs within the WTRU group.

[0158] In an example, a member WTRU may transition from the RRC_Inactive state to the RRC_Connected state, and the member WTRU may decide to start from a previous SSB measurement set and perform measurements on differential beams (e.g., only on differential beams) (e.g., due to the movement of the member WTRU). In an example, SSB measurement values (e.g., RSRP, RSRQ, etc.) may be used as an implicit trigger to determine which RACH process (e.g., 2-step or 4-step) to use. If the WTRU is configured with both 2-step random access resources and 4-step random access resources, the WTRU may check the value of a configuration parameter (e.g., msgA-RSRPthreshold, etc.) to determine whether to perform a 2-step RACH or a 4-step RACH. The decision to perform a 2-step RACH or a 4-step RACH may depend on other parameters including, for example, an indication from an application for the anchor WTRU and the member WTRU (in addition to the value of msgA-RSRPthreshold). For example, even if the WTRU meets the requirements of a 2-step RACH process (e.g., having a high msgA-RSRPthreshold value), the WTRU may receive an indication from the XR application to perform a 4-step RACH (e.g., because UL data is not inherently low latency). An indication of the applicable RACH method may be provided by the anchor WTRU (e.g., via sidelink) when the anchor WTRU is in the RRC_Connected state or the RRC_Inactive state. The anchor WTRU may consider the QoS of one or more WTRUs (e.g., all of the WTRUs) within the WTRU group when providing an indication to the member WTRU. For example, two member WTRUs may be attempting to transition to the RRC_Connected state and may have different application-level latency needs. In such a case, the anchor WTRU may instruct one member WTRU (e.g., having a need for lower latency) to utilize a 2-step RACH and the other member WTRU to utilize a 4-step RACH.

[0159] In an example, the power constraint of the WTRU may be used to determine whether the WTRU should perform a two-step RACH or a four-step RACH. For example, if the WTRU is power-constrained and / or operating under a scenario where it has to perform relatively infrequent small data transmissions, the WTRU may select a two-step RACH.

[0160] In an example, the anchor WTRU may use information from another WTRU group for one or more of the operations described herein (e.g., based on communication between the anchor WTRU and other groups of anchor WTRUs). Two groups of anchor WTRUs may exchange information regarding SSB and / or CSI-RS beam indices that may be used by various member WTRUs within each WTRU group. For example, if two WTRU groups are in proximity, they may be covered by a common SSB beam, and the anchor WTRU may share this information to reduce the number of beam sweeps and / or measurements that may be performed for beam establishment. As another example, if two WTRU groups have overlapping coverage, each group may adjust beam selection and / or measurements across the group (e.g., via adjustment of the anchor WTRU).

[0161] In an example, the anchor WTRU of a WTRU group having n WTRUs may initiate a group-based RACH procedure. The anchor WTRU may receive a set of sufficient RACH resources (e.g., contention-free RACH preambles, ROs, etc., which may be of the same size or different sizes) for a subset of the n WTRUs (e.g., for m WTRUs where m ≤ n). In this situation, the anchor WTRU may allocate or assign the received RACH resources (e.g., which may be referred to herein as m resources) among the n members of the WTRU group based on criteria that may include latency tolerance, reliability requirements, priority, etc. associated with the member WTRUs. For example, the anchor WTRU may allocate the m resources within the WTRU group based on which WTRUs may have latency-critical requirements (e.g., more stringent transmission time constraints) and / or which WTRUs may have a higher priority.

[0162] In an example, the anchor WTRU of a WTRU group may allocate a dedicated RACH preamble to the members of the WTRU group based on the category or type of the members. For example, an XR application experience may be associated with a WTRU group that includes audio and / or video capturing devices, sensors, etc. The anchor WTRU of such a WTRU group may allocate the RACH preamble based on the device category or type of the member WTRUs and / or the priority and / or QoE associated with the XR application. For example, an audio device within the WTRU group may be prioritized as it may have more stringent latency requirements related to user feedback and / or user experience, while a video and / or high data volume device within the WTRU group may be given a lower priority as it may have a higher tolerance for latency.

[0163] In an example, the anchor WTRU of a WTRU group may determine which WTRU within the group should be given a RACH resource (e.g., a dedicated RACH resource) based on the duplication in the user plane data of multiple WTRUs. For example, multiple WTRUs within a WTRU group may have a common FoV and / or overlapping communication ranges that can be recognized by the anchor WTRU (e.g., via information exchange between the WTRUs that may include application layer data based on information received from a base station, etc.). In such a scenario, the anchor WTRU may select a WTRU (e.g., only one) among the multiple WTRUs to receive the RACH resource. As another example, when the FoV is covered by multiple WTRUs in the RRC_Connected state, the anchor WTRU may exclude the WTRUs whose FoV can be covered by multiple WTRUs and may prioritize other WTRUs for the RACH resource (e.g., when the network provides insufficient resources for allocation in the WTRU group).

[0164] In an example, if some WTRUs are also part of an additional WTRU group (which can be inferred or determined, for example, based on communication between the respective anchor WTRUs of the WTRU group or based on information provided by the base station), the anchor WTRUs of these WTRU groups may cooperate regarding which WTRU can be given a higher priority during the allocation of RACH resources. For example, if a WTRU is part of two different WTRU groups and one WTRU group has better channel conditions (e.g., better RSRP / SINR, etc.) compared to the other WTRU group, the network (e.g., the base station) may allocate the RACH resource to the WTRU group with better channel conditions (e.g., when the network does not have sufficient RACH resources to support both WTRU groups).

[0165] The WTRUs within a WTRU group may perform a RACH-less initial access procedure. The RACH-less initial access procedure may refer to a process by which a WTRU can directly send data uplink without completing a random initial access. For example, a member WTRU of a WTRU group may directly send data to the network based on a grant allocated by the network (similar to what the WTRU may receive via Msg2), (similar to sending data via Msg3 in a 4-step RACH procedure).

[0166] A member WTRU of a WTRU group may receive auxiliary information from the anchor WTRU of the group so that, for example, if the anchor WTRU is on the same SSB and / or narrow beam as the member WTRU, the member WTRU can perform the RACH-less initial access procedure. In an example, the anchor WTRU may perform measurements on candidate SSB beams and send information to the member WTRU. The anchor WTRU may request a UL grant from the network on behalf of the member WTRU, receive the UL grant, and transfer the UL grant to the member WTRU. The UL grant may be specified for the anchor WTRU or the member WTRU, or may be part of a grant specified for a WTRU group that the anchor WTRU may have distributed or split among multiple member WTRUs. The member WTRU may use resources provided by the anchor WTRU (e.g., uplink grant, timing advance for synchronization, SSB beam indication or measurement, etc.) to perform the RACH-less initial access procedure (e.g., without transmitting a RACH preamble).

[0167] A member WTRU of a WTRU group may receive an indication of one or more conditions that the member WTRU may meet from the network and / or the anchor WTRU of the WTRU group in order to perform a RACH-less initial access procedure. For example, if the SSB measurements performed by the member WTRU are substantially close to (e.g., within a threshold) the SSB measurements performed by the anchor WTRU, the member WTRU may perform a RACH-less initial access procedure. The member WTRU may perform a RACH-less initial access procedure if the distance between the member WTRU and the anchor WTRU is sufficiently close (e.g., within a threshold). The member WTRU may perform a RACH-less initial access procedure if a configured timer (e.g., a TA timer) associated with the anchor WTRU and / or the member WTRU is running and / or has not expired. The member WTRU may perform a RACH-less initial access procedure if the member WTRU has exited the idle mode while the anchor WTRU is in the connected mode and / or the measurement values on the SSB have been updated.

[0168] The member WTRU may operate in a low power state such as RRC inactive state or RRC idle state, and the anchor WTRU (e.g., within a WTRU group) may be in the RRC connected state. The member WTRU may or may not maintain its configuration information in such a lower power state, and the anchor WTRU may maintain the configuration information for the member WTRU. For example, if the anchor WTRU is a pair of AR glasses and the member WTRU is a pair of haptic gloves (e.g., both may be part of the same XR application, session, or experience), the member WTRU may have reduced capabilities (e.g., with respect to supporting functions or features associated with the role of the member WTRU in the XR experience), and / or may have reduced capabilities (e.g., the member WTRU may conserve battery and / or memory by storing only information related to the XR experience). In this case, the member WTRU (e.g., haptic glove) may or may not maintain its RRC context when entering the RRC inactive state. The member WTRU may obtain (e.g., receive or retrieve) the RRC context from the anchor WTRU (e.g., AR glasses) when the RRC context is required.

[0169] The member WTRU may store its RRC context information with the anchor WTRU (e.g., when the member WTRU transitions to the RRC idle state), and thus, the transition of the member WTRU to the RRC connected state (e.g., from the RRC idle state) may be fast (e.g., without core network signaling). As a notification in this scenario, the anchor WTRU may be configured to send a paging type message to the member WTRU (e.g., via sidelink), and the member WTRU may be configured to monitor for the paging type message from the anchor WTRU along with an indication from the anchor WTRU (e.g., an indication included in the SCI) on the time / frequency resources used to transmit or receive the paging type message.

[0170] A WTRU in a WTRU group (e.g., an XR WTRU) may be configured to send and / or receive paging messages. The WTRU may be configured to monitor paging messages from the network and / or paging messages from an anchor WTRU of the WTRU group (e.g., to determine when to wake up). In an example, when a member WTRU knows that it is in an idle state or mode and its RRC context information is stored in the anchor WTRU, the member WTRU may prioritize paging messages from the anchor WTRU over paging messages from the network. The member WTRU may monitor (e.g., only monitor) paging messages from the anchor WTRU in such a scenario. The member WTRU may receive an instruction from the anchor WTRU to monitor paging messages from the anchor WTRU (e.g., on a specific time-frequency resource) for a period of time (e.g., for the entire duration that the member WTRU is in an idle state or for a specific number of cycles, slots, or transmission opportunities). The member WTRU may receive an instruction or message from the network (e.g., an instruction or message similar to the instruction or message received from the anchor WTRU) to monitor paging messages from the network (e.g., only monitor) for a period of time (e.g., while the member WTRU is in an idle state or for a specific number of cycles, slots, or transmission opportunities while in an idle state).

[0171] The member WTRU may receive competing messages from the network and the anchor WTRU regarding the monitoring of paging messages. The member WTRU may determine which of the network or the anchor WTRU to prioritize regarding paging messages. For example, when the anchor WTRU (e.g., a pair of AR glasses) and the member WTRU (e.g., a pair of haptic gloves) are involved in an XR experience (e.g., when the member WTRU may operate to enhance an XR experience implemented by an application on the anchor WTRU), the member WTRU may choose to monitor paging messages from the anchor WTRU (e.g., only from the anchor WTRU) when the member WTRU is in an idle state. In another example, the member WTRU may be another pair of AR glasses (e.g., the anchor WTRU may be one pair of AR glasses belonging to one user, and the member WTRU may be another pair of AR glasses belonging to a different user). In such an example, the member WTRU may choose to monitor paging messages from the anchor WTRU and the network (e.g., when the member WTRU is in an idle state), and in the case of competing instructions (e.g., competing instructions from the network and the anchor WTRU), the member WTRU may prioritize paging messages from the network.

[0172] In an example (e.g., when the network is notified regarding a WTRU group and / or a group having respective WTRU IDs), the network may send a paging message to a designated anchor WTRU (e.g., only to the anchor WTRU) in order to reduce, for example, the overhead associated with paging message transmission. For example, in existing communication technologies, paging transmission may occur in a cell where the target WTRU may not be located, leading to unnecessary signaling overhead. On the other hand, if the paging message is sent only in the cell where the target WTRU is located, the WTRU may need to notify the network (e.g., to track the WTRU at the cell level) regarding whether and / or when the WTRU moves out of the coverage area of one cell and into the coverage area of another cell. This may also lead to an increase in signaling overhead (e.g., regarding the signaling implemented to notify the network regarding the updated WTRU location). If the network desires to communicate with member WTRUs within a WTRU group, a compromise may be made where the network may utilize the WTRU group to page the designated anchor WTRU (e.g., for paging only), and the anchor WTRU may forward the paging message to the member WTRUs (e.g., the network may avoid paging the member WTRUs individually).

[0173] The member WTRU may verify the ability of the anchor WTRU to store RRC context information of the member WTRU when the anchor WTRU is configured to store the RRC context of the member WTRU (e.g., when the member WTRU is in idle or inactive state). The verification may be performed, for example, before the member WTRU transitions to an inactive or idle state. In an example, the anchor WTRU may be able to store RRC context information for a specific number (e.g., two) of member WTRUs at a given time. When another (e.g., third) member WTRU within the WTRU group transitions to an inactive or idle state, this member WTRU may be configured to wait for a period (e.g., several cycles or slots) before entering the inactive or idle state. The duration of the waiting period (e.g., the number of cycles or slots) may be indicated to the member WTRU (e.g., from the anchor WTRU). In an example, the anchor WTRU may have knowledge of the traffic characteristics of member WTRUs in idle state or mode and may be able to estimate the time it may take for a member WTRU to transition from idle state to connected or inactive state. In an example, the anchor WTRU may send paging messages to one or more of the member WTRUs (e.g., the two WTRUs described above) that can be supported by the anchor WTRU and are currently in idle state to wake up these member WTRUs. Following the transition of these member WTRUs to inactive or connected state, the anchor WTRU may be able to support additional (e.g., third) member WTRUs in idle state. In an example, the anchor WTRU may be able to inform an additional member WTRU (e.g., the third member WTRU) that there is a possibility that the anchor WTRU may not be able to support it in idle state in a subsequent period (e.g., the next several transmission cycles), and the anchor WTRU may be able to send an indication to the network such that the network may store the RRC context of the third member WTRU in idle state.In an example, the anchor WTRU may determine that a member WTRU should leave the WTRU group due to the inability to support additional member WTRUs in the idle state, and the anchor WTRU may send an indication of that determination to the member WTRU.

[0174] The anchor WTRU may be unable to enter the idle state while operating as the designated anchor WTRU for the WTRU group. The anchor WTRU may elevate another member WTRU within the group to the role of the anchor WTRU or transfer the context of the WTRU group to another anchor WTRU (e.g., within the surrounding area) before the designated anchor WTRU transitions to the idle state. The hierarchy of the WTRUs (e.g., the hierarchy for assuming the anchor role) may be defined within the WTRU group such that the newly designated anchor WTRU can assume the anchor role without degrading the XR experience. This hierarchy may be used, for example, when the current anchor WTRU experiences a link failure and seamless and fast handover by the member WTRUs is desired.

[0175] The anchor WTRU can transition from an active state to an inactive state while maintaining its role as the designated anchor WTRU. One or more conditions may be imposed for the anchor WTRU to have this behavior. For example, the anchor WTRU can transition to an inactive state, operate in an inactive state, or remain in an inactive state if one or more (e.g., all) member WTRUs of the WTRU group are in an idle state and the anchor WTRU knows (e.g., via an instruction from an XR application) that none of the member WTRUs can perform a random access procedure during a time window (e.g., a pre-configured duration in the future or a pre-set duration). The anchor WTRU can transition to an inactive state during that time window. As another example, the anchor WTRU can transition to an inactive state in response to receiving an instruction from an XR application regarding the next traffic characteristics associated with the XR application and / or the next traffic characteristics of one or more (e.g., all) member WTRUs within the WTRU group during a time window. The anchor WTRU can transition to an inactive state in response to determining that the anchor WTRU can no longer participate in a request or adjustment action during the aforementioned time window. As yet another example, the anchor WTRU can consider the expected traffic pattern or traffic characteristics via a sidelink interface with one or more (e.g., all) member WTRUs of the WTRU group before sending a request to the network to transition to an inactive state.

[0176] The anchor WTRU and / or the member WTRU may be configured to perform one or more of the following in a fallback scenario. The anchor WTRU may send information (e.g., parameters) to the member WTRU (e.g., via the SL interface) that the member WTRU may use to initiate data transmission (e.g., such that the member WTRU may bypass the RACH procedure). Such information (e.g., parameters) may include, for example, timing advance for synchronization, SSB beam indication or measurements, uplink grant, etc. The anchor WTRU may send information to the network (e.g., gNB) that may be used to facilitate data transmission by the member WTRU (e.g., without performing an initial access procedure). Such information may include, for example, a random access preamble sent to the network by the anchor WTRU on behalf of the member WTRU, an identifier of the member WTRU, location, positioning, and / or orientation information associated with the member WTRU, information regarding the size of the UL payload associated with the member WTRU, etc. In an example, the member WTRU may be configured to use information sent by the anchor WTRU (e.g., via the SL interface) to transmit data in the UL without performing an initial access procedure, for example. In an example, the member WTRU may be configured using conditions that allow the member WTRU to bypass the initial access procedure and / or rely on a fallback mechanism where the member WTRU may perform the initial access procedure independently (e.g., by enabling the anchor WTRU to perform the initial access procedure on behalf of the member WTRU). These conditions (e.g., fallback conditions) may be configured per WTRU for the member WTRU. These conditions (e.g., fallback conditions) may be based on one or more of the following.

[0177] The fallback condition may be based on the collocation situation of the member WTRU. The member WTRU may be configured to rely on a fallback mechanism for the initial access procedure (e.g., perform initial access independently without assistance from the anchor WTRU) when the collocation conditions associated with the member WTRU and the anchor WTRU are not met. Whether the collocation conditions are met may be determined based on one or more of the following. The collocation conditions may be considered not met when the member WTRU is not spatially close to the anchor WTRU, which may be determined based on whether the distance between the member WTRU and the anchor WTRU is less than a threshold configured by the network (e.g., a base station). The member WTRU may periodically measure its spatial or physical distance to the anchor WTRU (e.g., using periodicity configured by the network). The member WTRU may measure its spatial or physical distance in response to a request or trigger from the anchor WTRU to measure the spatial or physical distance to the anchor WTRU. The member WTRU may measure its spatial or physical distance in response to a request or trigger from the network to measure the spatial or physical distance to the anchor WTRU. The member WTRU may measure its spatial or physical distance to the anchor WTRU in response to a change in the position, movement, or orientation of the member WTRU. The member WTRU may receive information regarding the distance or change in distance between the anchor WTRU and the member WTRU from the anchor WTRU. The member WTRU may receive information regarding the distance or change in distance between the anchor WTRU and the member WTRU from the network. The member WTRU may receive information regarding the distance or change in distance between the anchor WTRU and the member WTRU from an XR application (e.g., one or more WTRUs of a WTRU group, the core network, an edge server, a RAN node, etc.) that may reside between the anchor WTRU and the member WTRU.

[0178] The fallback condition may be based on the UL grant size. For example, a member WTRU may be configured to rely on a fallback mechanism for initial access (e.g., perform initial access independently without assistance from an anchor WTRU) when the size of the UL grant transferred, indicated, reserved, or permitted by the anchor WTRU is not large enough to accommodate the UL data that the member WTRU may have for the network (e.g., the UL data in the buffer of the member WTRU may be associated with a set of PDUs, frames, and / or data bursts that may be large in size). The member WTRU may be configured (e.g., by a base station) using a threshold such that when the UL data in the buffer of the WTRU is greater than the threshold, the member WTRU can rely on performing individual initial access (e.g., without assistance from the anchor WTRU).

[0179] The fallback condition may be based on the quality of service (QoS) of the member WTRU, anchor WTRU, and / or network (e.g., latency, data rate, SINR, etc.). For example, a member WTRU may be configured to rely on a fallback mechanism for initial access (e.g., perform initial access independently without assistance from an anchor WTRU) when it determines that it may not meet the QoS requirements for UL data using the UL grant transferred, indicated, reserved, or permitted by the anchor WTRU. The WTRU may determine that it may not be able to transmit a packet within the packet delay budget (PDB) associated with the packet or a set of PDUs within the PDU set delay budget (PSDB) associated with the set of PDUs by using the UL grant indicated by the base station. Thus, the member WTRU may determine to perform the initial access procedure independently.

[0180] The fallback condition may be based on reliability requirements. For example, if the member WTRU determines that it cannot send UL data in accordance with the reliability requirements using the UL grant secured by the anchor WTRU on behalf of the member WTRU, the member WTRU may be configured to rely on a fallback mechanism for initial access (e.g., perform initial access independently without assistance from the anchor WTRU).

[0181] The fallback condition may be based on measurement values such as channel measurement values, SSB measurement values, and / or positioning measurement values. For example, the anchor WTRU may perform channel measurements (e.g., CSI measurements) on its Uu link and send a measurement report regarding the channel measurement values to the member WTRU. The member WTRU may perform channel measurements on its own Uu link. The member WTRU may use a threshold for channel measurement parameters (e.g., PMI, CQI, etc.) to be configured such that when the difference between the channel measurement values of the member WTRU and the channel measurement values of the anchor WTRU is only different by a value greater than a pre-configured threshold, the member WTRU may rely on the fallback mechanism for the initial access procedure (e.g., perform initial access independently without assistance from the anchor WTRU). The member WTRU may perform SSB measurements (e.g., similar to CSI-RS measurements in the previous example). If the SSB measurements performed by the member WTRU relate to a beam different from the SSB measurements performed by the anchor WTRU, the member WTRU may rely on the fallback mechanism for initial access (e.g., perform initial access independently without assistance from the anchor WTRU). The anchor WTRU may receive a reference signal (e.g., a positioning reference signal (PRS)) from the network (e.g., a base station) and perform positioning measurements on the PRS. The anchor WTRU may share its positioning measurement values with the member WTRU (e.g., via a sidelink interface). The network may share the positioning information of the anchor WTRU with the member WTRU. The member WTRU may receive a reference signal (e.g., PRS) from the network and perform positioning measurements. The member WTRU may be configured (e.g., by the network) using a threshold such that when the positioning measurement values of the member WTRU are different from the positioning measurement values of the anchor WTRU by an amount greater than a configured threshold, the member WTRU may rely on the fallback mechanism for the initial access procedure (e.g., perform initial access independently without assistance from the anchor WTRU).

[0182] Individual WTRUs or stand-alone WTRUs (e.g., not associated with a WTRU group or anchor WTRU) may perform stand-alone initial access procedures such as 2-step or 4-step RACH procedures. The WTRU may send a random access preamble for itself to the base station (e.g., based on legacy RACH procedures). The WTRU may send an indication of the size of the data to be transmitted in UL to the base station so that a UL grant sent by the base station to the WTRU (e.g., in a message associated with the RACH procedure such as Msg2, MsgB, or Msg4) may be suitable for the data the WTRU desires to transmit in UL (e.g., in size and / or timing). The WTRU may then use the UL grant to transmit data to the base station (e.g., in a RACH message such as Msg3, MsgA, or any other message associated with the random access procedure).

[0183] The features and elements described above are described in specific combinations, but each feature or element may be used alone without the other features and elements of the preferred embodiments, or may be used in various combinations with or without other features and elements. The implementations described herein may consider 3GPP-specific protocols, but it will be understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G-specific protocols, but it will be understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems.

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

Claims

Claim 1 A wireless transmit / receive unit (WTRU) comprising a processor, the processor configured to: Transmit a first message to a network device, the first message including information regarding a group-based random access procedure associated with a group of WTRUs; Receive, from the network device, a response indicating one or more resources for the group-based random access procedure; Determine an allocation of the one or more resources to the group of WTRUs associated with the group-based random access procedure; and Send an indication of the allocation of the one or more resources to the group of WTRUs via one or more sidelink messages. A wireless transmit / receive unit (WTRU) as claimed in claim 1, wherein the processor is configured to autonomously determine the allocation of the one or more resources to the group of WTRUs. Claim 2 The WTRU of claim 1, wherein the processor is configured to determine the allocation of the one or more resources to the group of WTRUs, including determining that the one or more resources are insufficient for the group of WTRUs for the group-based random access procedure. Claim 3 The WTRU of claim 2, wherein the processor is configured to allocate the one or more resources to the group of WTRUs based on respective transmission priorities associated with the group of WTRUs. Claim 4 The WTRU of claim 2, wherein the processor is configured to allocate the one or more resources to the group of WTRUs based on respective transmission time constraints associated with the group of WTRUs. Claim 5 The WTRU of claim 1, wherein the one or more resources are associated with contention-free access to the network device by the group of WTRUs. Claim 6 Claim 7 ​ The response received from the network device includes information indicating how the one or more resources should be allocated to the group of WTRUs, and the processor is configured to determine the allocation of the one or more resources to the group of WTRUs based on the information included in the response. The WTRU according to claim 1.

8. The first message includes a random access preamble associated with the group-based random access procedure, and indicates several WTRUs associated with the group-based random access procedure. The WTRU according to claim 1.

9. The processor is further configured to identify the group of WTRUs associated with the group-based random access procedure based on sidelink communication between the WTRU and the group of WTRUs. The WTRU according to claim 1.

10. The WTRU is configured to operate as an anchor for the group of WTRUs. The WTRU according to claim 1.

11. The processor is further configured to transmit a second message to the network device, and the second message indicates the allocation of the one or more resources to the group of WTRUs. The WTRU according to claim 1.

12. The one or more resources indicated by the response received from the network device are for implementing the group-based random access procedure via an interface between the network device and the group of WTRUs. The WTRU according to claim 1.

13. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: transmitting a first message to a network device, the first message including information regarding a group-based random access procedure associated with a group of WTRUs; receiving, from the network device, a response indicating one or more resources for the group-based random access procedure; determining an allocation of the one or more resources to the group of WTRUs associated with the group-based random access procedure; A method comprising: sending an instruction indicating the allocation of the one or more resources to the group of WTRUs to the group of WTRUs via one or more sidelink messages.

14. The method according to claim 13, wherein the allocation of the one or more resources to the group of WTRUs is autonomously determined by the WTRUs based on respective transmission priorities or transmission time constraints associated with the group of WTRUs.

15. The method according to claim 13, wherein the one or more resources are associated with contention-free access to the network device by the group of WTRUs.

16. The method according to claim 13, wherein the response received from the network device includes information indicating how the one or more resources should be allocated to the group of WTRUs, and the allocation of the one or more resources to the group of WTRUs is determined based on the information included in the response.

17. The method according to claim 13, further comprising identifying the group of WTRUs associated with the group-based random access procedure based on sidelink communication between the WTRU and the group of WTRUs.

18. The method according to claim 13, wherein the one or more resources indicated by the response received from the network device are for performing the group-based random access procedure via an interface between the network device and the group of WTRUs.

19. A wireless transmit / receive unit (WTRU) comprising: a processor, wherein the processor sends a message indicating a request by the WTRU to perform a random access procedure to an anchor WTRU via a sidelink, receives from the anchor WTRU a response indicating one or more resources for the WTRU to perform the random access procedure, and is configured to perform the random access procedure with the network device using the one or more resources indicated by the response.

20. The WTRU according to claim 19, wherein the message sent to the anchor WTRU further indicates a transmission priority or a transmission time constraint associated with the WTRU.

21. The WTRU according to claim 19, wherein the random access procedure is performed in a contention-free manner.

Images