Group-based network access

Abstract

Described herein are systems, methods, and instrumentalities associated with group-based network access, such as initial access to a network by a WTRU group. A description of a group-based initial access procedure is provided, and messages / signals that may be transmitted or received by a WTRU during the group-based initial access procedure, and ways for allocating resources in the group for transmitting the messages / signals are also described. The group-based initial access procedure may be performed based on detection of a trigger event or condition, and measurements may be performed to implement the group-based initial access procedure.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of Provisional U.S. Patent Application No. 63 / 335,421 filed on April 27, 2022, Provisional U.S. Patent Application No. 63 / 395,600 filed on August 5, 2022, and Provisional U.S. Patent Application No. 63 / 421,688 filed on November 2, 2022, the disclosures of which are incorporated herein by reference in their entirety. Background Art

[0003] A wireless transmit / receive unit (WTRU) may obtain access to a network (e.g., initial access), for example, through a random access procedure. If each WTRU in a cooperating group handles the access procedure individually, the group (e.g., as a whole) may suffer from collisions, for example, due to additional delays that may be caused by contention resolution. Summary of the invention

[0004] Disclosed herein are systems, methods, and means associated with group-based network access, such as initial access to a network by a WTRU group. A wireless transmit / receive unit (WTRU) (e.g., an anchor WTRU) may include a processor configured to send a first message to a network device, wherein the first message may include information about a group-based random access procedure associated with a WTRU group (e.g., the anchor WTRU may be a part of the group). The processor may be further configured to receive a response from the network device, the response may indicate one or more resources for the group-based random access procedure. The processor may be further configured to: determine an allocation of one or more resources indicated by the response to a WTRU group associated with the group-based random access procedure; and transmit an indication to the WTRU group, the indication may indicate an allocation of one or more resources to the WTRU group, wherein the indication may be transmitted via one or more sidelink messages.

[0005] The processor of the WTRU may be configured to autonomously (e.g., without additional instructions from a network device) determine an allocation of one or more resources to a WTRU group. The processor of the WTRU may be further configured to determine that the one or more resources are insufficient to accommodate a WTRU group associated with a group-based random access procedure. Based on this determination, the processor may be configured to allocate one or more resources to the WTRU group based on a corresponding transmission priority or a corresponding transmission time constraint associated with the WTRU group.

[0006] The one or more resources described herein may be associated with contention-free access to a network device by a WTRU group. A response received from the network device may include information indicating how the one or more resources may be allocated to the WTRU group, and a processor of the WTRU may be configured to determine the allocation of the one or more resources to the WTRU group based on the information included in the response. A first message sent 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 the number of WTRUs associated with the group-based random access procedure.

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

[0008] A member WTRU (e.g., one or more other WTRUs described above) associated with a group-based random access procedure may be configured to send a message to an anchor WTRU via a side link, wherein the message may indicate a request by the WTRU to perform a random access procedure. The member WTRU may receive a response from the anchor WTRU, wherein the response may indicate one or more resources for the member WTRU to perform the random access procedure. The member WTRU may then use the one or more resources indicated by the anchor WTRU to perform a random access procedure with a network device. In various embodiments, the message sent by the member WTRU to the anchor WTRU may also indicate a transmission priority or a transmission time constraint associated with the member WTRU. In various embodiments, the member WTRU may use the one or more resources indicated by the anchor WTRU to perform a random access procedure in a contention-free manner. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0010] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system.

[0011] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within the illustrated communication system.

[0012] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of yet another example RAN and yet another example CN for use within the illustrated communication system.

[0013] Figure 2A is a diagram illustrating an example of group-based initial access.

[0014] Figure 2B This is an example of Figure 2A The diagram shows an example of the content transmitted by Msg1.

[0015] Figure 2C This is an example of Figure 2A The diagram shows an example of the content transmitted by Msg2.

[0016] Figure 3 is a diagram illustrating an example of a random access type.

[0017] Figure 4 is a diagram illustrating an example of a collaborative extended reality (XR) system. DETAILED DESCRIPTION

[0018] Figure 1A 1 is a schematic diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0019] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should 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 may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, 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 device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

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

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

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

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

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

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

[0028] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a microcell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

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

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

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

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

[0033] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0037] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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).

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

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

[0040] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (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, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

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

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

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

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

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

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

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

[0050] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communication interface with a communication network.

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

[0052] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Direct link establishment (DLS) may be used to transmit point-to-point traffic between the source STA and the target STA (e.g., directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0053] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may listen to the primary channel. If the primary channel is listened / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0054] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0055] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0056] 802.11af and 802.11ah support operating modes below 1 GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

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

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

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

[0060] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple 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 an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0061] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).

[0062] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as an evolved Node-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0063] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0064] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0065] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

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

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

[0069] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0070] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0071] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0072] Disclosed herein are systems, methods, and means associated with group-based network access, such as initial access to a network by a WTRU group. A wireless transmit / receive unit (WTRU) (e.g., an anchor WTRU in a WTRU group) may include a processor configured to send a first message to a network device, wherein the first message may include information about a group-based random access procedure associated with the WTRU and one or more other WTRUs (e.g., in the WTRU group). The processor may be further configured to receive a response from the network device, the response may indicate one or more resources for the group-based random access procedure. The processor may be further configured to: determine an allocation of at least a portion of the one or more resources indicated by the response to one or more other WTRUs associated with the group-based random access procedure; and transmit an indication to the one or more other WTRUs, the indication indicating the allocation of at least the portion of the one or more resources to the one or more other WTRUs, wherein the indication may be transmitted via one or more sidelink messages.

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

[0074] The one or more resources described herein may be associated with contention-free access to the network device. In various embodiments, the response received from the network device may also indicate how the one or more resources may be allocated to one or more other WTRUs, and the processor of the WTRU may be configured to determine the allocation of at least the portion of the one or more resources to the one or more other WTRUs based on information included in the response. In various embodiments, a first message sent 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 the number of WTRUs associated with the group-based random access procedure.

[0075] The processor of the WTRU may be further configured to identify one or more other WTRUs associated with the group-based random access procedure based on sidelink communications between the WTRU and the one or more other WTRUs, and the group-based random access procedure may be performed through an access network interface (e.g., a Uu interface) between the one or more other WTRUs and the network device. In various embodiments, the processor of the WTRU may be further configured to send a second message to the network device, wherein the second message may indicate an allocation of at least the portion of the one or more resources to the one or more other WTRUs.

[0076] A member WTRU (e.g., one or more other WTRUs described above) associated with a group-based random access procedure may be configured to send a message to an anchor WTRU via a side link, wherein the message may indicate a request by the WTRU to perform a random access procedure. The member WTRU may receive a response from the anchor WTRU, wherein the response may indicate one or more resources for the member WTRU to perform the random access procedure. The member WTRU may then use the one or more resources indicated by the anchor WTRU to perform a random access procedure with a network device. In various embodiments, the message sent by the member WTRU to the anchor WTRU may also indicate a transmission priority or a transmission time constraint associated with the member WTRU. In various embodiments, the member WTRU may use the one or more resources indicated by the anchor WTRU to perform a random access procedure in a contention-free manner.

[0077] As described herein, an anchor WTRU in a WTRU group (such as a collaborative WTRU group formed based on an extended reality (XR) application) may determine, for example, based on sidelink (SL) communications (e.g., data exchange) between the members, the number of WTRUs in the group (e.g., member WTRUs including the anchor WTRU) and / or further determine a time constraint (e.g., a maximum time constraint) for performing initial access to a network for one or more (e.g., all) of the WTRUs in the group (e.g., the time constraint may be determined based on application layer information). The anchor WTRU may select a RACH resource 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 transmitted, for example, in a Msg1 associated with a random access and / or based on the selected resource. The anchor WTRU may determine (e.g., based on a response received from a network device) an allocation of one or more RACH resources (e.g., one or more preambles, one or more random access opportunities (ROs), etc.) to a WTRU associated with a random access request (e.g., to one or more member WTRUs in the group). The anchor WTRU may determine the resource allocation, for example, based on group-based RACH resources (e.g., assigned 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, the resource allocation to the member WTRUs may be performed autonomously by the anchor WTRU (e.g., the anchor WTRU may determine for itself which network-authorized resource goes to which member WTRU and may inform the member WTRU of the determination). The resource allocation may also be indicated in a response received from a network device (e.g., the network device may not only provide the resources but also indicate which resource goes to which member WTRU and the anchor WTRU may inform the member WTRU of the indicated allocation).

[0078] In various embodiments, a WTRU (e.g., an anchor WTRU as described herein) may receive (e.g., via RRC signaling) an application from a higher layer message, and / or a member WTRU may receive (e.g., via a sidelink (SL) message) information from a higher layer message regarding a time duration (e.g., a maximum time duration) for a WTRU group (e.g., a member of a WTRU group) to establish connectivity (e.g., initial access) with a network, a priority (e.g., a transmit priority) of (e.g., each) member WTRU, a transmit time constraint of (e.g., each) member WTRU, a NAS ID of (e.g., each) member WTRU, etc. The WTRU (e.g., an anchor WTRU as described herein) may receive (e.g., in a SIB (such as SIB 1 or an XR-specific SIB)) a RACH preamble (e.g., a RACH preamble ID) and / or association information between the RACH preamble and the number of WTRUs in the WTRU group. The WTRU may transmit (e.g., in Msg1) a RACH preamble corresponding to the number of WTRUs in the WTRU group (e.g., n WTRUs). The WTRU may receive (e.g., in a response such as Msg2) a reservation indication which may indicate RACH resources (e.g., contention-free RACH preambles, m ROs, etc.) for a plurality (e.g., m) WTRUs (e.g., m may be less than or equal to n) in a WTRU group. The WTRU may receive in response a timing advance (TA), an UL grant (e.g., for this WTRU or another WTRU), a group temporary cell RNTI (TC-RNTI), etc.

[0079] A WTRU (e.g., an anchor WTRU as described herein) may determine an 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) in a WTRU group based on one or more of the following: a time constraint or duration for the WTRU group to establish connectivity to the network, a priority (e.g., a transmit priority) of the member WTRUs, a transmit time constraint associated with the member WTRUs, and / or a resource assignment or reservation indication provided by the network for the WTRU. The WTRU (e.g., an anchor WTRU) may inform one or more WTRUs of the resource allocation (e.g., a portion of the resources may be allocated for the anchor WTRU itself). For example, the WTRU may transmit information about 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 a unicast and / or multicast message over an SL interface).

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

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

[0082] FIG. 2A to FIG. 2C One or more of the techniques described herein are illustrated. Figure 2A An example of a group-based initial access procedure is illustrated. Figure 2B Examples of what can be included in Figure 2A The content of Msg1 shown, and Figure 2C Examples of what can be included in Figure 2A The content of Msg2 is shown.

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

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

[0085] If the member WTRU receives assistance information (e.g., from the anchor WTRU), the member WTRU may retransmit the RACH message (e.g., MsgA) using the preamble (e.g., indicated by the anchor WTRU). If the member WTRU does not receive assistance information (e.g., from the anchor WTRU), the member WTRU may transmit another RACH message (e.g., Msg1) and may fall back to the legacy RACH procedure.

[0086] The term extended reality (XR) may be used herein 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. When an observer or user moves within the limits defined by the application, the rendering may simulate the visual (e.g., stereoscopic three-dimensional (3D)) and / or auditory sensory stimulation of the real world to the observer or user. Augmented reality (AR) may provide the user with additional information or artificially generated items or content superimposed on the user's current environment. Mixed reality (MR) may include an advanced form of AR, in which some virtual elements may be inserted into a physical scene with the intention of providing the illusion that these elements are part of the real scene. XR may include one or more real and virtual combined environments and / or human-computer interactions generated by computer technology and / or wearable devices.

[0087] The concept of immersion in the context of XR applications or services can refer to the feeling of being surrounded by a virtual environment and the sensation of being physically and spatially located in the virtual environment. The level of virtuality can range from partial sensory input to fully immersive multi-sensory input, resulting in a virtual reality that is virtually indistinguishable from actual reality.

[0088] As described herein, a WTRU may include an XR device capable of providing various degrees of spatial tracking. Such an XR device may be equipped with various sensors to enable spatial tracking. The sensors may include, for example, monocular cameras, stereo cameras, depth cameras, radio beacons, GPS devices, inertial sensors, and the like. Spatial tracking may be performed at different levels, for example, with 3 degrees of freedom (DoF) (e.g., rotational motion along the X-axis, Y-axis, and Z-axis) or 6DoF (e.g., rotational and / or translational motion along the X-axis, Y-axis, and Z-axis). Spatial tracking may result in experiencing some form of interaction with virtual content. A user may perform actions in and / or interact with one or more components within an extended reality. For example, actions and / or interactions may involve movement, gestures, eye tracking, and the like. Spatial tracking may enable an immersive XR experience. For example, some form of head and / or motion tracking may ensure that the visual and auditory components of the simulation from the user's perspective are updated to be consistent with the user's movements. Inaccurate and / or delayed spatial tracking may cause the user to feel uncomfortable and / or motion sickness.

[0089] A WTRU as described herein may include an XR device or XR node that can be implemented in a variety of form factors. A WTRU as described herein (e.g., an XR WTRU) may include, but is not limited to, one or more of the following: one or more head-mounted displays (HMDs), one or more pairs of optical perspective glasses and camera perspective HMDs for AR and MR, one or more mobile devices with position tracking capabilities and cameras, one or more wearable devices, and the like. Different types of XR WTRUs may be provided by the WTRU devices, wearable devices, actuators, controllers, and / or accessories described herein, for example, based on the XR device functionality (e.g., as a display, as a camera, as a sensor, for sensor processing, for wireless connectivity, for XR or media processing, as a power source, and the like). One or more WTRUs (such as one or more XR devices or XR nodes) may be grouped into collaborative groups, for example, to support XR applications, XR experiences, XR services, and the like.

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

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

[0092] The WTRU may select the type of random access when initiating the random access procedure, for example, based on network configuration information. For example, if CFRA resources are not configured, the reference signal received power (RSRP) threshold may be used by the WTRU to select between a 2-step RA type and a 4-step RA type; if CFRA resources for a 4-step RA type are configured, the WTRU may perform a 4-step RA procedure; if CFRA resources for a 2-step RA type are configured, the WTRU may perform a 2-step RA procedure.

[0093] The network may or may not configure CFRA resources for both 4-step and 2-step RA types for a bandwidth part (BWP).2-step CFRA may be supported in handover cases (eg, only for handover cases).

[0094] Msg1 of the 4-step RA type may include a preamble sent on a physical random access channel (PRACH). The WTRU may monitor (e.g., after the Msg1 is sent) for a response from the network within a configured window (e.g., a configured time window). For CFRA, a dedicated preamble for Msg1 transmission may be assigned by the network, and the WTRU may end (e.g., upon receiving a random access response from the network) the random access procedure, such as Figure 3 -(c). For CBRA, the WTRU may transmit (e.g., upon receiving a random access response) a message 3 (Msg3) using the UL grant scheduled in the response, and the WTRU may monitor contention resolution, e.g., as Figure 3 - As shown in (a). If contention resolution is unsuccessful after Msg3 is sent (retransmitted), the WTRU may return to sending Msg1.

[0095] A 2-step RA type MsgA may include a preamble sent on the PRACH and / or a payload on the physical uplink shared channel (PUSCH). The WTRU may monitor (e.g., after the MsgA is sent) for a response from the network within a configured window (e.g., a configured time window). For CFRA, a dedicated preamble and / or PUSCH resources may be configured for MsgA transmission, and the WTRU may end the random access procedure (e.g., upon receiving a network response), such as Figure 3-(d). For CBRA, if the contention resolution is successful upon receiving the network response, the WTRU may end the random access procedure, for example, as Figure 3 -(b). If a fallback indication is received in message B (MsgB), the WTRU may perform Msg3 transmission using the UL grant scheduled in the fallback indication and the WTRU may monitor contention resolution. If contention resolution is unsuccessful after Msg3 transmission (retransmission), the WTRU may return to MsgA. If the random access procedure with 2-step RA type is not completed after multiple MsgA transmissions, the WTRU may be configured to switch to CBRA with 4-step RA type.

[0096] In various examples (e.g., for random access in a cell configured with a supplemental uplink (SUL)), the network may signal (e.g., explicitly) which carrier may be used (e.g., UL carrier or SUL carrier). If no such signal is received from the network, the WTRU may select the SUL carrier (e.g., only if) the measured quality of the DL is below a threshold (e.g., a broadcasted threshold). The WTRU may perform carrier selection before selecting between a 2-step RA type and a 4-step RA type. The threshold (e.g., RSRP threshold) for selecting between a 2-step RA type and a 4-step RA type may be configured (e.g., separately) for the UL and SUL. Once started, one or more (e.g., all) uplink transmissions associated with the random access procedure may remain on the selected carrier.

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

[0098] If each WTRU in the cooperative group handles the random access procedure separately, the random access procedure for the cooperative WTRU group may be subject to, for example, random access collisions. Such random access related contention may occur, for example, in an Internet of Things (IoT) use case that may support access by a large number of IoT devices. These IoT devices (e.g., the number of which may be huge) may or may not have strict latency requirements to be met. For other devices such as XR devices, there may be strict latency requirements (e.g., imposed by XR applications), and random access collisions may result in failure to meet the strict latency requirements, for example, due to additional delays that may be caused by RA contention resolution. Having an anchor WTRU in such a cooperative WTRU group (e.g., which may include multiple XR devices) may enhance the efficiency of the random access procedure, for example, by allowing the anchor WTRU to coordinate the procedure or process the procedure, at least in part, on behalf of one or more other WTRUs (e.g., as well as the anchor WTRU itself). An efficient initial access procedure for a WTRU group may alleviate random access contention and / or reduce initial access latency in the group. Thus, for example, in XR applications, a satisfactory quality of experience (QoE) may be achieved for the user (e.g., by coherently satisfying latency requirements of the XR application for the collaborative XR WTRU group to provide an immersive XR experience to the user).

[0099] Challenges to be addressed regarding initial access to the network may include how to support efficient initial access for a WTRU group (e.g., a collaborative WTRU group) so that the WTRU can perform initial access within strict latency limits, whether and / or how the anchor WTRU can be used to ensure that other WTRUs (e.g., members of the WTRU group including the anchor WTRU itself) can perform random access procedures such as a 2-step RACH procedure with minimal contention probability, how to perform efficient random access procedures for collaborative WTRU groups (e.g., XR devices) within strict time constraints and alleviate contention between WTRUs, how to support (e.g., guarantee) group-based initial access within strict latency limits, how to enable collaborative WTRUs to perform contention-free (e.g., substantially contention-free) RACH procedures within a strict time window, etc.

[0100] Figure 4An example of a collaborative XR system is illustrated. In the embodiments described herein, for example, a network may refer to or include any of a base station (e.g., a gNB, a transmit / receive 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 any of a QoS flow or a data flow (e.g., a flow of data including one or more PDUs or ADUs, which may be associated with one or more QoS requirements related to latency, data rate, reliability, etc.). Different flows (e.g., originating from a common application / experience source and / or intended for a common destination device / WTRU or a group of associated devices / WTRUs) may be referred to as associated flows or related flows. In the embodiments described herein, the forwarding configuration may correspond to or include configuration information associated with any of the following: a radio bearer (e.g., a data radio bearer (DRB) and / or a signaling radio bearer (SRB)), a logical channel (LCH), a logical channel group (LCG), configuration parameters in 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, radio resources associated with a configuration grant, a dynamic grant and / or any other resource grant, or unlicensed resources, etc.)).

[0101] In the embodiments described herein, the term "cooperative XR WTRU" or "cooperative WTRU group" may refer to, but is not limited to, one or more of the following concepts and definitions. XR applications and / or services may be supported, whereby one or more WTRUs may perform at least one XR-related action, thereby providing an XR experience to a user. These experiences may include, for example, enabling a sense of complete or partial immersion in different real and / or virtual environments, providing a user with the ability to interact with real and / or virtual objects including avatars, etc. A WTRU may include one or more of: a separate (e.g., standalone) device or node (e.g., an XR device, a pair of XR glasses, a smartwatch, a wearable device, etc.), a non-standalone device or node (e.g., a device, sensor, wearable device, haptic glove, etc. associated with a WTRU), a device or node controlled by a network (e.g., by a network operator), a device or node that may not be directly associated with and / or connected to a network (e.g., connected to a gNB) but may be a candidate given certain parameters (e.g., such as field of view (FoV) metadata (including size, dimensions, quality, etc. of the FoV), pose information, etc.), a fixed mobile device or node, a static device or node, a moving or mobile 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.

[0102] A collaborative group may include one or more WTRUs, one of which may be designated as an anchor WTRU and one or more other WTRUs may be designated as collaborative WTRUs or member WTRUs (e.g., the anchor WTRU may also perform the functions of a member WTRU). In various examples, an anchor WTRU (e.g., in the context of collaborative XR) may refer to a WTRU configured to perform one or more of the following functions: hosting an application function (e.g., an XR application) from which a request for an XR action (e.g., any XR action) may be received; receiving a request for an XR action from an application function located in a network (e.g., on an edge server or a remote server); initiating a discovery process for determining other WTRUs in a collaborative group that may be involved in performing (e.g., any) XR actions (e.g., devices or nodes in the vicinity of the anchor WTRU); establishing connectivity and / or sessions (e.g., XR sessions, PDU sessions, application sessions, etc.) by transmitting and / or receiving requests for session establishment and / or operating as a primary anchor point for communicating with an access network (e.g., RAN) function or node (e.g., such as a gNB), a core network function or node, and / or an application function. These operations may include, for example, transmitting and / or receiving session-related messages (e.g., capability transfer, assistance information transfer, configuration transfer, measurement information, XR action state information, session activation / deactivation, session release, etc.). When supporting connection to a network, the interface between the anchor WTRU (or member WTRU) and the network (e.g., gNB) may be referred to as a Uu link (e.g., primary Uu link).

[0103] The terms “collaborative WTRU” or “member WTRU” may be used interchangeably herein (e.g., in the context of collaborative XR) and may refer to (e.g., any) WTRU that is involved in performing one or more of the following: initiating a discovery process and / or receiving a request to make the WTRU discoverable (e.g., via a side link or through the network) for performing (e.g., any) XR action (e.g., when a connection to a network is supported, the interface between the collaborating WTRU and the network (such as a gNB) may be referred to as an auxiliary Uu link); transmitting information related to the XR action directly to the network (e.g., gNB, CN function, application function, etc.) and / or indirectly to the anchor WTRU; The collaborative WTRU may be associated with multiple collaborative groups and anchor WTRUs.

[0104] As referred to herein, an XR experience may include an overall experience for an end user that may result from coordinated transmission and / or reception of data to and from an end device in a reliable and timely manner. Terms related to "multimodal" may refer to (e.g., any) association between multiple streams and / or multiple WTRUs. Streams and / or WTRUs may be associated with a collaborative WTRU group and / or support applications or services that are common to one or more WTRUs.

[0105] "Anchor WTRU" or "collaborative WTRU" are non-limiting examples of terms that may be used in association with the embodiments described herein. Other terms that may be used when referring to an anchor WTRU may include "center WTRU", "master WTRU", "primary WTRU", "initiating WTRU", etc. Other terms that may be used when referring to a collaborative WTRU may include "member WTRU", "auxiliary WTRU", "supporting WTRU", "auxiliary WTRU", etc. The entities or objects described herein (including collaborative groups, anchor WTRUs, collaborative WTRUs and / or XR actions) may be associated with corresponding (e.g., different) identifiers (IDs) (such as collaborative group IDs, anchor WTRU IDs by group, collaborative WTRU IDs by group, XR action IDs, etc.). The corresponding identifiers or IDs associated with collaborative XR may be assigned or configured, for example, by a WTRU, a network or an application function. When referred to herein, a level 3 WTRU may be a type of WTRU (e.g., similar to a secondary WTRU) that may be associated with a role in a collaborative group and a functional capability. A level 3 WTRU may involve a shorter duration and / or a smaller portion of a task in an XR action. A level 3 WTRU may be configured based on partial configuration information. A Level 3 WTRU may take less time and / or less overhead to complete or perform an XR action.

[0106] The identifier may be used to associate WTRUs in a cooperating WTRU group (e.g., which may also be referred to herein as a WTRU group). The anchor WTRU and the cooperating WTRUs (e.g., which may also be referred to herein as member WTRUs) may be associated, for example, at a level that may vary for different XR experiences and / or within the same XR experience. The association between the WTRUs in a cooperating 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 the WTRUs in a cooperating WTRU group may permeate or translate to other layers in the communication framework (e.g., any layer of the NAS, RRC, SDAP, PDCP, RLC, MAC, PHY, or AS protocol stack).

[0107] The initial ID associated with the application may be retained in multiple layers, or there may be different IDs generated in different layers and the corresponding IDs within (e.g., each) layer may be associated. The ID may remain the same throughout the XR experience or between XR sessions. The ID may change between XR experiences or between XR sessions. The management and storage of IDs between WTRUs in a cooperating WTRU group may be performed by the CN, base station, application, and / or WTRUs involved in the XR experience.

[0108] The service ID and the XR action ID may match. For example, the anchor WTRU may transmit one or more of the following IDs to the member WTRU: application / service / session ID, WTRU ID, collaboration group ID, XR action ID (e.g., used to identify XR actions supported by the WTRU and / or requested to be performed by other WTRUs), etc. The member WTRU may transmit the indication in response to detecting that the service ID or XR action ID (e.g., in a discovery, solicitation, or indication message received from the anchor WTRU) matches a service ID or XR action ID pre-configured for or available at the member WTRU. IDs associated with one or more WTRUs in a collaborative WTRU group (e.g., WTRU ID, C-RNTI, etc.) and / or an ID associated with a collaborative WTRU group (e.g., group RNTI) may be used in (e.g., any) user plane (UP) or control plane (CP) process (e.g., scheduling process). For example, the ID can be used when transmitting RRC messages, SR / BSR, UCI, ULMAC CE, PUCCH transmission, PUSCH transmission, WTRU assistance data, etc. and / or when receiving RRC signaling or RRC messages, resource grants, configuration grants, DCI, DL MAC CE, PDCCH transmission, PDSCH transmission, etc.

[0109] The WTRU may indicate its matching capabilities. For example, upon determining that one or more capabilities (XR capabilities and / or connectivity capabilities) are currently supported by the WTRU's capabilities or are within the WTRU's capabilities to support matching those capabilities indicated by the anchor WTRU (e.g., in a discovery, solicitation, or indication message), the cooperating WTRU may transmit an indication.

[0110] WTRU group-based initial access may be supported. In various embodiments, multiple WTRUs (e.g., including at least an anchor WTRU and a member WTRU) in a collaborative WTRU group may coordinate within the group to perform an initial access procedure on a group basis. When referred to herein, group-based initial access may refer to any process and / or functionality performed by an anchor WTRU and / or one or more member WTRUs to complete initial access. Such processes and / or functionality may include sending and / or receiving (e.g., any) initial access message (e.g., Msg1, Msg2, etc.) and / or determining any of the corresponding actions performed by one or more WTRUs (e.g., individually or on a group basis) during the initial access procedure.

[0111] The initial access signal as described herein may include any of the following: one or more RACH preambles, one or more sequences and / or one or more partitions and / or resources that may be sent by the WTRU during a time opportunity (e.g., a RACH opportunity); one or more UL resource grants or channels for transmitting indications, messages, or flags that may be associated with performing a group-based initial access procedure (e.g., a request for group initial access); and the like.

[0112] When performing group-based initial access, the WTRU (e.g., anchor WTRU and / or member WTRU) may send or receive indications, signals (e.g., control and / or data signals), messages and / or configurations via a combination of one or more of the following: broadcast signaling, RRC signaling, MAC CE, initial access message, L1 channel transmission, etc. For example, the WTRU may access or obtain information for performing group-based initial access via any of the SIB, position SIB (posSIB) and / or SSB. The WTRU may send and / or receive request messages, response messages and / or configuration messages associated with positioning and / or initial access via RRC messages. The WTRU may send and / or receive request messages, response messages, configuration messages and / or activation / deactivation indications associated with positioning and / or initial access in one or more MAC CEs. For example, in the UL, when Msg3 or MsgA is sent, the MAC CE (e.g., carrying a request or response message) may be multiplexed in the PUSCH. For example, in DL, when receiving Msg2, Msg4 or Msg B, MAC CE may be multiplexed in PDSCH. The initial access message described herein may include Msg1, Msg2, Msg3, Msg4, Msg5, MsgA and / or MsgB. The L1 channel transmission described herein may include PUCCH transmission, PUSCH transmission, PDCCH transmission and / or PDSCH transmission.

[0113] The WTRU may send one or more messages and / or signals during a group-based initial access procedure. These 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 transmitted in Msg1 and / or MsgA. The random access preamble may include a preamble that may be selected by the WTRU in a contention-based manner and / or a dedicated preamble that may be assigned by the network in a contention-free manner.

[0114] The random access preamble may be sent as part of (but not limited to) a conventional random access procedure (e.g., 4-step CBRA, 2-step CBRA, 4-step CFRA type, 2-step CFRA, etc.). The random access preamble may be transmitted in MSG1, Msg3, Msg5, and / or MSGA. The random access preamble (e.g., dedicated or shared) may correspond to one WTRU and / or a group of WTRUs (e.g., a cooperating WTRU group). For at least a contention-free random access procedure, the preamble may be dedicated or designated by the network for a WTRU and / or a group of WTRUs. Designating the preamble for a WTRU and / or a group of WTRUs may be performed by a WTRU, such as an anchor WTRU.

[0115] The network may provide a list of preambles that may be contention-free for a WTRU and / or a group of WTRUs to perform random access. The contention-free preamble and the contention-based preamble may correspond to the same resource set or different resource sets (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 with a NAS ID of the WTRU and / or the group of WTRUs, for example, by scrambling. For example, the NAS ID may include an ID that may uniquely identify a WTRU within the scope of any of the following: a WTRU group, a cell, a group of cells (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 each example, the member WTRU may encode the preamble indicated by the anchor WTRU for group-based initial access with the NASID of the member WTRU and may transmit 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.

[0116] An association between a preamble (e.g., a RACH preamble) and a service type (e.g., gaming, industrial robot control, etc.) may be established (e.g., through a mapping relationship) such that a WTRU (e.g., an anchor WTRU, a member WTRU, or a standalone WTRU) may access a set of preambles (e.g., a selected set of preambles) based on the type of service associated with an application running on the WTRU. A network device may perform contention resolution (e.g., by prioritizing one WTRU over another WTRU and / or one WTRU group over another WTRU group) based on the type of service associated with the WTRU or WTRU group (e.g., if the network device receives the same preamble from more than one WTRU and / or WTRU group).

[0117] The random access preamble may convey additional information about the WTRU group. In various examples, contention-based preambles and / or contention-free preambles may be used or reserved for initial access by a WTRU group (e.g., which may be interchangeably referred to herein as group initial access). These preambles may implicitly inform the network of group-based initial access. In various examples, the preamble used for group initial access may be specifically indicated to the WTRU by the network, for example, in a SIB (e.g., SIB1, a subsequent periodic SIB, a subsequent requested SIB, and / or an XR-specific SIB). In various examples, designating the preamble for group initial access may be explicit (e.g., by adding one or more additional bits in a configuration message). Indications such as flags may be used to indicate initial access per WTRU (e.g., individual) or group access. Indications may indicate the number and / or type of WTRUs in the group. In various examples, some preambles may be reserved or allocated for WTRU groups with a specific number of WTRUs (e.g., within a certain number range). For example, preamble A may be assigned to a WTRU group having 2 to 4 WTRUs, while preamble B may be assigned to a WTRU group having 4 to 6 WTRUs. The anchor WTRU may select a preamble corresponding to the number of WTRUs in its WTRU group. In various examples, the designation of a preamble for group initial access may be implicit. For example, there may be a consensus between the WTRU and the network regarding the preamble to be used for initial access (e.g., the third preamble in every RACH opportunity on an odd-numbered SBS on every other resource block). In various examples, this consensus may be on a per-cell or per-base station basis and may be acquired by the WTRU, for example, when the WTRU first connects to a cell or gNB.

[0118] After sending the preamble, the WTRU may start a timer (e.g., T300 or another timer) to wait for a response message (e.g., Msg2 or Msg4) from the network. For group-based initial access, the length of this timer (e.g., 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 that the XR application can tolerate. For example, the length of the timer may be shorter for critical XR applications that can tolerate a strict delay budget than for XR applications that can preserve QoE with a larger delay budget. The length of the timer may vary with the number of WTRUs in the WTRU group (e.g., in the case of group-initial access). For example, the larger the number of WTRUs in the WTRU group, the longer the timer may be.

[0119] The anchor WTRU may transmit to one or more member WTRUs an indication of RACH resources (e.g., preambles and / or RACH opportunities) that the member WTRUs may use to transmit RACH-related messages (e.g., Msg1 or MsgA) to the network. In various examples, the anchor WTRU may indicate a common preamble for one or more (e.g., all) member WTRUs in the group to use at different designated RACH opportunities in the time domain. In various examples, the anchor WTRU may specify or assign a different preamble for each member WTRU to use. The preambles specified or assigned by the anchor WTRU to the member WTRUs may be contention-based and / or contention-free (e.g., for individual or group-based initial access).

[0120] A WTRU, such as an anchor WTRU in a WTRU group, may confirm an allocation or assignment of resources. For example, an anchor WTRU in a WTRU group may transmit a confirmation of the allocation or assignment of resources in the WTRU group to a base station after determining and / or indicating resource allocations (e.g., preambles, RACH opportunities) to one or more member WTRUs in the WTRU group (e.g., including the anchor WTRU). The confirmation may indicate whether the allocation or assignment of RACH resources to one or more member WTRUs (e.g., including the anchor WTRU) was successful. In various examples, the confirmation may include a single confirmation (ACK) indicating that the initial access was successful to one or more (e.g., all) members in the WTRU group. The confirmation may include additional information, such as, for example, which RACH resource is assigned to which WTRU in the group (e.g., preamble #4 in RACH opportunity #2 is assigned to member WTRU #2 in the WTRU group). The resource allocation or assignment to the member WTRUs may include information about 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 SSBs associated with the aforementioned parameters (e.g., the indexes of two RACH opportunities associated with the SSB with index #0), etc. 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 transmit a mapping to the base station, which may list the RACH resources (e.g., preamble, preamble ID, RO, RO ID, etc.) allocated to one or more member WTRUs (e.g., identified by corresponding 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 in the WTRU group. The information may be sent as independent information (e.g., as uplink control information (UCI)) or as part of a status report. In various examples (e.g., where the anchor WTRU may make a group RRC setup request on behalf of the WTRU group), the confirmation may accompany or include the group RRC request. In these examples, the member WTRUs may not make individual RRC requests to the network. The confirmation of the resource allocation or assignment may be transmitted in Msg3, Msg5 and / or MsgA.

[0121] One or more identifiers may be associated with a WTRU group. When sending a message, the WTRU may include in the message one or more of an ID of the RACH preamble (e.g., used in Msg1, MsgA, or Msg3), an ID of the WTRU itself, an ID of a member WTRU (e.g., a NASWTRU ID, a temporary mobile subscriber identity (TMSI), a C-RNTI, a TC-RNTI, or any other ID that may uniquely identify a WTRU), and / or an ID of a WTRU group (e.g., a group TC-RNTI, a group C-RNTI, or any other ID that may uniquely identify a WTRU group and / or an association of a WTRU with a WTRU group). The identifier of the WTRU or WTRU group may be signaled by the network. For example, the network may signal the temporary C-RNTI assignment to the WTRU in a random access response message (e.g., such as Msg2 or MsgB). The anchor WTRU may transmit its NAS ID and / or the NAS IDs of the member WTRUs to the network, for example, in Msg3.

[0122] The anchor WTRU may transmit an RRC setup request on behalf of a WTRU (e.g., the anchor WTRU itself) and / or a WTRU group. The UL grant allocation included in the 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 various examples, the anchor WTRU may transmit a group RRC setup request so that one or more member WTRUs may not have to transmit individual RRC setup requests themselves. In various examples, the anchor WTRU may transmit its own RRC setup request, and (e.g., each) member WTRU may transmit its own RRC setup request. In these examples, the anchor WTRU may transmit a request for additional uplink grants to the network, which the anchor WTRU may forward to the member WTRUs to enable them to make individual RRC setup requests. The request to the network may be explicit or implicit. In various examples, in response to receiving a preamble reserved for group initial access from the anchor WTRU, the network may transmit additional uplink grant resources to the anchor WTRU (e.g., in a random access response). The amount of uplink grant resources that the network may transmit 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 certain preamble). The amount of uplink grant resources that the network may transmit 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 an establishment cause. The establishment cause may include, for example, emergency call, high priority access, WTRU group access, multimedia priority access, etc.

[0123] A member WTRU in a WTRU group may send the position, orientation and / or location information of the member WTRU to an anchor WTRU. The anchor WTRU may use the position, orientation and / or location information of the member WTRU to determine whether the member WTRU may be a valid member of the WTRU group. In various examples, 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 position, orientation and / or location information of the member WTRU to determine how to prioritize the member WTRUs with respect to allocating the received RACH resources in the WTRU group.

[0124] The sending of position, orientation and / or location information by a member WTRU to an anchor WTRU may be periodic (e.g., with a periodicity configured by the anchor WTRU, by the XR application and / or 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 may trigger the sending of position, orientation and / or location information may include one or more of the following. The sending may be triggered by a member WTRU detecting a change in its movement (e.g., exceeding a pre-configured threshold), in which case the member WTRU may report the movement (e.g., new location information) to the anchor WTRU. The sending may be triggered by receiving an indication from a higher layer or application. For example, a member WTRU may receive a request or indication from an XR application to report the member WTRU's position, orientation and / or location information to the anchor WTRU. The sending may transmit the position, orientation and / or location information by receiving an indication or request from the anchor WTRU to transmit the position, orientation and / or location information. For example, if the anchor WTRU selects a member WTRU to forward a request for resources for initial access (eg, group-based RACH resources provided by the network), the anchor WTRU may transmit a request to the member WTRU to report the member WTRU's position, orientation, and / or location information.

[0125] In various examples, in response to a member WTRU transmitting its position, orientation, and / or location information, the anchor WTRU may transmit an ACK to signal successful receipt of the information. Failure to receive an ACK may trigger the member WTRU to retransmit the information. If the anchor WTRU has not received the position, orientation, and / or location information from the member WTRU or has failed to successfully decode it, the anchor WTRU may transmit a NACK to the member WTRU. Receiving a NACK from the anchor WTRU may trigger the member WTRU to retransmit the information. In various examples, failure to receive a message from the network may trigger the member WTRU to transmit its position, orientation, and / or location information to the anchor WTRU and / or the network. For example, the member WTRU may be expecting a message from the network (e.g., Msg4) after transmitting a RACH preamble to the network. The member WTRU may have started a timer after transmitting a preamble to the network (e.g., in Msg1), and upon expiration of the timer, if the member WTRU has not received a response (e.g., Msg4) from the network, the member WTRU may transmit its position, orientation, and / or location information to the anchor WTRU or the network. In various examples, the position, orientation, and / or location information of a member WTRU may be transmitted in response to a request (eg, implicit or explicit) from the network, or may be transmitted due to receiving a NACK or failing to receive an ACK.

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

[0127] Messages and / or signals associated with group-based initial access may be transmitted at various times. 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 transmit a preamble in Msg1 (e.g., alone or scrambled with a NAS ID). The anchor WTRU may send a preamble for its own initial access and / or for group-based initial access to the network. The anchor WTRU may use (e.g., generate or be given) an ID to uniquely identify the WTRU group and / or may transmit the ID to the network (e.g., in Msg3 or Msg5). The anchor WTRU may transmit a confirmation of the allocation or assignment of RACH resources in the WTRU group to the network (e.g., in Msg3 or Msg5). The anchor WTRU may transmit its NAS ID and / or the NAS ID of the member WTRUs to the network (e.g., in Msg3 or Msg5).

[0128] The WTRU may send 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. A WTRU (e.g., an anchor WTRU) may transmit a group-based RACH preamble (e.g., in Msg1 or MsgA) after an indication from an XR application to initiate group initial access. The WTRU may transmit a RACH preamble after receiving an RA preamble assignment from the network (e.g., in a contention-free RA process). The WTRU may transmit a RACH preamble to the network after receiving an indication from a member WTRU to transmit a RACH preamble (e.g., received via a sidelink interface). The WTRU may transmit a request for a larger UL grant (e.g., more RACH resources) to the network in response to receiving an uplink grant (e.g., RACH resources granted via a random access response message) and determining that the UL grant is insufficient. If a WTRU (e.g., the anchor WTRU) is unable to use the UL grant to transmit information about the group initial access to the network, then the UL grant may be considered insufficient. This may be because the information transmitted 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 the individual members, the WTRU group ID, etc., details of which may require a larger UL grant. The UL grant may be considered insufficient if, for example, the anchor WTRU may not be able to take into account a large number of member WTRUs with UL grants when the anchor WTRU receives an indication from an application indicating that a large number of WTRUs may all perform initial access within a strict time window (e.g., to ensure the QoE of the user experience).

[0129] The WTRU may receive and / or access resources and / or configuration information associated with initial access to implement group-based initial access. One or more of the initial access signals or messages described herein may be sent or received by the WTRU during the initial access process, for example, in one or more of Msg1, Msg3, Msg5 (for example, for 4-step RA type) or MsgA (for example, for 2-step RA type) and / or together with it. The RACH resources and / or configuration information used by the WTRU for group-based initial access may include one or more of the following. RACH resources may include, for example, preambles, sequences, partitions, and / or time and / or frequency resources associated with the RACH process. RACH resources may include one or more RACH opportunities that the WTRU can use to send RACH preambles. Parameters associated with RACH resources may include start / stop time, transmission duration, periodicity, transmission power, transmission spatial direction, etc. The WTRU may select RACH resources from a resource set that can be shared by multiple WTRUs or dedicated to the WTRU. 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.

[0130] The RACH resources accessible by the WTRU may be used for general initial access, dedicated for group-based initial access, and / or dedicated 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 a first set of RACH resources may be intended for group-based initial access purposes and a second set of RACH resources may be intended for non-group-based initial access purposes. Different resources or resource sets may be associated with corresponding IDs or indices that may be received by the WTRU via broadcast or dedicated signaling.

[0131] The WTRU may have access to a set of one or more group-based RACH preambles. The WTRU may select a RACH preamble randomly or based on a selection criterion. For example, such a selection criterion may indicate the selection of a group-based RACH preamble when the RSRP measured on a DL signal (e.g., SIB, DL PRS, DMRS, SSB, TRS, CSI-RS, etc.) associated with the RACH process is above / below a threshold value.

[0132] The WTRU may implicitly indicate information related to the WTRU group to the network. The WTRU may do so, for example, by sending an UL signal using a group-based RACH resource. For example, the WTRU may transmit a designated group-based preamble to the network, which may signal a group-based initial access.

[0133] Resources, resource sets and / or configurations (e.g., as a whole or in part) associated with group-based initial access (e.g., by transmitting a RACH indication or request) may be received by the WTRU, for example, before or during initial access in a combination of one or more of the following scenarios.

[0134] The WTRU may receive information about (e.g., group-based or non-group-based) RACH resources and / or timings on a wide channel (such as via a SIB and / or SSB). Resources, resource sets and / or configurations that may be used by the WTRU during initial access or after connectivity is established with the network (e.g., in the RRC_CONNECTED state) may be indicated by ID and / or index values. In each example, the WTRU may receive information about the timing during which the WTRU may send one or more of the initial access signals that the network may expect to receive for processing an initial access based on a WTRU group. In each example, the WTRU may receive information (e.g., ID) about 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., as a range of values ​​or a maximum value), an offset value relative to a reference frame, a parameter set, a QCL / spatial relationship, a TRP / cell ID, a beam ID, a spatial direction to be applied, etc. These parameters may be used by the WTRU to send an initial access signal and / or make other requests related to initial access (eg, on-demand requests conveyed in Msg1, Msg3, or MsgA).

[0135] The WTRU may receive information about RACH resources via a paging message. For example, the WTRU may transition to an RRC_IDLE or INACTVE state (e.g., after a previous connection establishment and / or operation in an RRC_CONNECTED state), and the WTRU may receive information about resources used to transmit 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., sent on RACH or PUSCH). In each example, the WTRU may receive information about RACH resources in a regular paging occasion or in a paging occasion dedicated to positioning.

[0136] The RACH resources may be preconfigured or predefined for the WTRU. For example, the WTRU may send or receive an initial access signal using resources that are preconfigured (or predefined) for the WTRU and stored in the WTRU. For example, the WTRU may receive the preconfiguration through a previous connectivity (e.g., a previous PDU session) and / or a previous RRC configuration (e.g., received by a WTRU in an RRC_CONNECTED state). In each example, the preconfigured resources for the initial access signal may be received when the WTRU transitions to an RRC_INACTIVE or RRC_IDLE state (e.g., in one or more RRC release messages (such as a suspend configuration message) or one or more RRC reconfiguration messages). In each example, the WTRU may receive validity information, conditions, and / or criteria associated with the preconfigured resources when the WTRU receives the preconfigured resources for the initial access signal. Such validity conditions may include a validity area (e.g., a cell list), a validity time (e.g., a timer or a timer duration), and / or a validity measurement threshold (e.g., a threshold corresponding to an RSRP measurement of a DL signal associated with the initial access signal). The validity condition may indicate a condition that is expected to be satisfied to determine whether the preconfigured resources for the initial access signal are valid.

[0137] The WTRU may receive information about RACH resources during transmission and / or reception of initial access messages. For example, the WTRU may receive resources for an initial access signal (e.g., sent on RACH or PUSCH) for group-based initial access in one or more of Msg2 (e.g., random access response message), Msg4 (e.g., for 4-step RA type), and / or MsgB (e.g., for 2-step RA type). For example, the WTRU may receive resources after sending an explicit or implicit request for resources for group-based initial access in Msg1, Msg3, or MsgA.

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

[0139] 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 with an association or mapping relationship between a RACH signal for Msg1 / MsgA and one or more search spaces to monitor a RAR (e.g., Msg2 or MsgB) or an activation / deactivation indication (e.g., an ID or index for group-based initial access). This 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). This association or mapping relationship may be pre-configured for the WTRU. If the RACH signal used by the WTRU includes an explicit or implicit indication of activation of a resource or a pre-configured resource, the WTRU may receive the resource or an indication of activation / deactivation of the resource in one or more search spaces associated with the RACH signal.

[0140] 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 the following: 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 in a broadcast channel (e.g., via a SIB) or in an RRC message, or the semi-static configuration information may be pre-configured for the WTRU. For example, when a WTRU group-based initial access is triggered (e.g., for an XR service), the WTRU may determine the resources for sending an initial access signal (e.g., on a RACH or PUSCH) based on the semi-static configuration information received in the SIB that may indicate a mapping between the XR service and the resource.

[0141] A WTRU (e.g., an anchor WTRU) may receive an uplink grant, for example, as part of a Random Access Response (RAR) message that may be received in Msg2 or MsgB. The UL grant received by the WTRU may be for 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 transmit an RRC setup request for itself or to transmit a group RRC setup request so that members of the WTRU group may not have to transmit separate RRC setup requests. If the size of the UL grant is not large enough (e.g., for sending an indication regarding group initial access and / or for the anchor WTRU to distribute the UL grant to member WTRUs for transmitting their corresponding RRC requests), the WTRU may transmit 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 the UL grant from the anchor WTRU and / or from the network.

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

[0143] The anchor WTRU may receive a TA (e.g., a common TA) from the network, which may be applicable to multiple (e.g., all) WTRUs associated with the anchor WTRU in the WTRU group (e.g., if the WTRUs are co-located). The TA may be used for group initial access. In the event that the anchor WTRU may have received fewer resources (e.g., RACH preamble, random access opportunity (RO), etc.) than it requested for the group-based initial access procedure, the anchor WTRU may prioritize one or more member WTRUs for these resources and may consider the TA value indicated by the network when determining which member WTRUs should receive these resources. For example, if a member WTRU has indicated to the anchor WTRU a change in its location, position and / or orientation such that the member WTRU is determined to be further away (e.g., beyond a radius predefined by the 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 reduce the priority of the member WTRU.

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

[0145] 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 an anchor WTRU, a UL grant for a member WTRU, and / or a UL grant for a WTRU group. The time resources, frequency resources, and / or downlink MCS associated with the RAR message may be indicated to the WTRU in the DCI (e.g., in a PDCCH transmission) so that the WTRU knows when to expect the RAR message and / or how to decode the RAR message. This indication from the network may be scrambled with the receiving WTRU identifier and / or the WTRU group identifier.

[0146] A WTRU may receive an RRC setup message from the network (e.g., in Msg4). For example, an anchor WTRU in a WTRU group may receive an RRC setup message (e.g., as a final message) before transitioning to a connected state. A DCI scrambled with a WTRU C-RNTI and / or a group C-RNTI may indicate a frequency and / or time resource assigned for sending a transport block containing an RRC setup message so that one or more corresponding WTRUs may know when to expect or monitor for an RRC setup message. The RRC setup message may be designated for an anchor WTRU, a WTRU group, and / or one or more members of a WTRU group. An RRC setup message may be transmitted to set up a signal radio bearer (SRB) (such as SRB 1) and / or a cell (such as a primary cell). The RRC setup message may include information elements such as radioBearerConfig and masterCellGroup. An anchor WTRU may stop a timer after receiving the RRC setup message. For example, an anchor WTRU may start a timer (e.g., timer T300) after transmitting a preamble and may stop the timer after receiving an RRC setup message (e.g., in Msg4 or MsgB).

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

[0148] The anchor WTRU may receive assistance information from one or more member WTRUs (e.g., in a WTRU group) to coordinate a group-based initial access procedure. The assistance information may include an identifier of the member WTRU (e.g., a C-RNTI or a NAS ID or any other ID that may uniquely identify the member WTRU). The assistance information may include capability information associated with connectivity, including, for example, information about interfaces, such as the number of interfaces and / or interface types (e.g., NR Uu, NRSL, WLAN, and / or Bluetooth, etc.) supported by the WTRUs within the WTRU group. The assistance information may include capability information about 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 the following: bandwidth, number of carriers, number of transmit antennas, number of receive antennas, antenna configuration, etc. In each example, the antenna configuration information may implicitly indicate to the anchor WTRU the SSB range that the member WTRU is able to measure and / or report. Static capability information exchange may occur at the start of an XR session (e.g., regarding the types of interfaces supported), while a more dynamic capability information exchange may occur (e.g., each time) a change is detected (e.g., a member WTRU may transmit a notification to an anchor WTRU that may indicate a change in antenna configuration).

[0149] The anchor WTRU may receive information from the member WTRU regarding link failures, congestion, poor channel quality, etc. detected at the member WTRU. In various examples, the anchor WTRU may determine that the member WTRU is unable to perform initial access within a timing advance value indicated by the network (e.g., in a random access response message) due to a link failure at the member WTRU. In response, the anchor WTRU may decide not to include the member WTRU in the group initial access procedure. In various examples, the anchor WTRU may transmit a group RRC request if the member WTRU is experiencing temporary poor channel conditions that may limit transmission and / or reception of the member WTRU.

[0150] The WTRU may, for example, start a timer after transmitting Msg1, Msg3, and / or MsgA. The length of the timer may be set based on the delay budget that the XR application can tolerate. Upon expiration of the timer, 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 multiple (e.g., all) WTRUs in the WTRU group was successful. The indication may be on a group basis or on a per-WTRU basis.

[0151] Information (e.g., configuration information) may be exchanged between the WTRU and the network to gain consensus on a manner for reading, decoding, or interpreting status reports such as RARs. For example, "success" in the context of such a status report may imply successful completion of the initial access procedure, and "unsuccessful" in this context may imply failure to complete the initial access procedure. In various examples, failure to complete the initial access procedure may be due to a member WTRU failing to transmit Msg1 and / or MsgA, or failing to transmit a version of Msg1 / MsgA with a specified preamble to the network. In various examples, failure to complete the initial access procedure may be due to a network failing to receive and / or decode Msg1 and / or MsgA, and / or failing to receive and / or decode a version of Msg1 / MsgA from a member WTRU. In various examples, failure to complete the initial access procedure may be due to a network failing to decode Msg1 and / or MsgA, and / or failing to decode a version of Msg1 / MsgA from a member WTRU before a time window expires.

[0152] A status report such as a RAR may be specified for an anchor WTRU, a member WTRU, and / or a WTRU group so that (e.g., any) member of the WTRU group (e.g., including the anchor WTRU and / or the member WTRU) may decode the report. For example, if the status report indicates the WTRU group NAS ID, the anchor WTRU may assume that the initial access for multiple (e.g., all) members of the WTRU group (e.g., including the anchor WTRU) is successful. As another example, the status report may explicitly indicate the NAS IDs of the successful WTRUs and the unsuccessful WTRUs. If the member WTRU is unsuccessful in initial access, the anchor WTRU may transmit assistance information to the member WTRU. For example, the anchor WTRU may transmit an indication to the unsuccessful member WTRU to cause the member WTRU to retry the initial access by retransmitting Msg1 or MsgA another n times (n≥1) using the same RACH resources, using the same power, or using increased power. The anchor WTRU may indicate to the unsuccessful member WTRU that the reattempted initial access (e.g., by transmitting Msg1 or MsgA) may use RACH resources (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 number of RACH opportunities for retrying the initial access another n times (n≥1) with the same power or with increased power.

[0153] The status report may indicate the NAS ID of the member WTRU that successfully made the initial access. Based on such status report, the anchor WTRU may infer that at least one member WTRU did not successfully make the initial access and may transmit assistance information (e.g., directly) to the unsuccessful member WTRU. For example, the anchor WTRU may indicate one or more determined RACH resources to the unsuccessful WTRU via the sidelink interface for retransmitting Msg1 or MsgA.

[0154] The status report may indicate one or more solutions for the unsuccessful initial access. For example, the network may transmit an indication to the WTRU regarding the validity of previously allocated RACH resources (e.g., preamble, RO, etc.). The anchor WTRU may take the validity information into account when assigning resources to one or more member WTRUs for reattempting initial access after a failed attempt. As another example, the member WTRU may receive and decode the status report (e.g., in Msg4) and may use the validity information of the available RACH resources to transmit an updated request to the network (e.g., Msg1 or MsgA). As yet another example, if the anchor WTRU does not successfully perform its random access procedure, the anchor WTRU may determine that one or more member WTRUs successfully performed their random access procedures (e.g., via direct communication with the member WTRU via a sidelink), and the anchor WTRU may perform an independent RACH procedure (e.g., a 2-step RACH procedure) based on the resource validity information indicated by the network.

[0155] The WTRU may send an initial access signal associated with a group-based initial access based on the detection of a triggering event or condition. The triggering event or condition may include a combination of one or more of the following. The triggering event may include receiving an indication from a higher layer or application. For example, the WTRU may trigger a group-based initial access upon receiving a higher layer or application request or indication for such initial access. The WTRU may select a group-based RACH preamble and send the selected preamble in a RACH opportunity configured for group-based initial access. The triggering event may include detection of one or more reference locations. For example, the WTRU may trigger a group-based initial access upon detecting one or more TRPs, one or more base stations, or one or more cells (e.g., via SIBs or SSBs) that can support group-based initial access. In each example, the WTRU may operate in an INACTIVE or IDLE state and may be pre-configured with a validity region (e.g., a cell list) for performing group-based initial access. In response to detecting a cell ID matching at least one cell in the validity region, the WTRU may start a group-based initial access process.

[0156] The triggering event may include a priority associated with the group-based initial access. For example, if the priority value associated with the group-based initial access is higher than the priority associated with the non-group-based initial access, the WTRU may trigger the group-based initial access. For example, the priority value may be pre-configured in the WTRU or received by the WTRU via the SIB for low-latency collaborative XR.

[0157] If the WTRU is operating in the INACTIVE / IDLE state, the WTRU may trigger a group-based initial access in response to determining that the position of one or more WTRUs in the WTRU group has changed beyond a certain threshold, RSRP measurements of DL signals or channels by the WTRUs in the WTRU group are above or below a threshold, etc. A WTRU (e.g., which may be an anchor WTRU or a member WTRU in a WTRU group) may be configured to perform a group-based initial access periodically, in which case the WTRU may trigger a group-based initial access based on the configured periodicity.

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

[0159] The triggering event may include receiving broadcast information, which may include positioning related information. For example, if the SIB or SSB includes information or an indication related to group-based initial access (e.g., an indication to the WTRU to start initial access), the WTRU may determine to start group-based initial access.

[0160] The WTRU may perform measurements to facilitate a group-based initial access procedure. In various examples, a member WTRU in a WTRU group that experiences a beam failure may perform beam failure recovery by performing relevant beam measurements (e.g., SSB measurements, such as SS-RSRP, SS-RSRPB, SS-RSRQ, SS-SINR, etc.) and / or RACH procedures. An anchor WTRU in a WTRU group may assist the member WTRU in a beam recovery procedure, for example based on the anchor WTRU's own beam measurements, which may include SSB beams and / or CSI-RS measurements (e.g., if the anchor WTRU is in a connected state). When 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 a QCL state and / or TCI state configuration. The anchor WTRU may indicate that a subset of SSB beams is 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 (eg, via a Uu link) and / or to member WTRUs in the WTRU group (eg, directly via a side link).

[0161] In various examples, if the anchor WTRU experiences a beam failure, it may communicate with one or more member WTRUs in 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.) on a subset of beams or all beams and may report the measurements to the anchor WTRU (e.g., in response to a notification message from the anchor WTRU indicating a beam failure).

[0162] In each example, if measurements made by the anchor WTRU indicate a potential Uu beam failure and / or the RSRP of the serving beam drops to a value close to a threshold for continued use of the beam, the anchor WTRU may choose not to provide the beam subset to the member WTRU, and may allow the member WTRU to perform beam measurements on an SSB beam set (e.g., the entire SSB beam set) or a beam set that the member WTRU may deem appropriate.

[0163] In various examples, the anchor WTRU may be aware of other devices in its WTRU group that may have experienced beam failure and / or beam recovery. The anchor WTRU may choose to exclude failed SSB beam measurements from a measurement set that the anchor WTRU may indicate to a member WTRU (e.g., that may have experienced a beam failure). In various examples, the anchor WTRU may choose to indicate a restricted SSB beam measurement set that may include a list of beams based on the anchor WTRU's own measurements and / or a fresh set (e.g., a latest set) of SSB beams for a member WTRU that may have recovered from a beam failure.

[0164] In various examples, the anchor WTRU may want the member WTRU (e.g., a new member in the WTRU group) to consider a beam set that may include (e.g., only include) SSB beams that have been selected by multiple (e.g., all) WTRUs in the group (e.g., by the anchor WTRU and / or any member WTRUs in the member WTRUs) or a subset of SSBs selected by existing member WTRUs in the WTRU group (e.g., by the anchor WTRU and / or any member WTRUs in the member WTRUs).

[0165] In various examples, the states of the WTRUs in a WTRU group may be taken into account for beam selection and / or RACH procedures. For example, if a member WTRU is transitioning from an RRC_Idle state to an RRC_Connected state, the member WTRU may (e.g., based on an indication by an anchor WTRU) perform beam sweeping or beam measurements in order to find the best SSB beam set. In this case, a reduced set of beam measurements may not be indicated for the member WTRU. Such behavior may be appropriate at least when the anchor WTRU decides not to restrict the SSB beam measurement or selection process. For example, these behaviors may be appropriate in scenarios where the member WTRU may not be located near the anchor WTRU or may have moved away from the anchor WTRU since the previous beam measurement. These behaviors may be appropriate if the member WTRU is attempting to recover from an RLF (e.g., due to a blockage) and the anchor WTRU determines that the member WTRU should perform the beam measurements that it would perform if it were operating as an independent WTRU (e.g., not part of a WTRU group).

[0166] In various examples, if a member WTRU is attempting to transition from an RRC_Inactive state to an RRC_Connected state, the member WTRU may not have to perform a thorough beam sweep and the member WTRU may start with a previous SSB beam measurement set and perform additional sweeps or measurements if the link quality of those beams is below a threshold. The anchor WTRU may provide the member WTRU with a beam measurement set (e.g., via a sidelink), which may be based on the anchor WTRU's own measurements and / or beam measurement information provided by other WTRUs in the WTRU group.

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

[0168] In various examples, the power constraint of the WTRU may be used to determine whether the WTRU should perform 2-step RACH or 4-step RACH. For example, if the WTRU has power constraints and / or is operating in a scenario where it must perform relatively infrequent small data transmissions, the WTRU may select 2-step RACH.

[0169] In various examples, an anchor WTRU may use information from another WTRU group (e.g., based on communication between the anchor WTRU and an anchor WTRU in the other group) for one or more of the operations described herein. The anchor WTRUs in the two groups may, for example, exchange information regarding SSB and / or CSI-RS beam indices, which may be used by individual member WTRUs in each WTRU group. For example, if two WTRU groups are in close proximity, they may be covered by a common SSB beam, and the anchor WTRUs 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, the groups may coordinate beam selection and / or measurements across the groups (e.g., via coordination of the anchor WTRU).

[0170] In various examples, an anchor WTRU in a WTRU group having n WTRUs may initiate a group-based RACH procedure. The anchor WTRU may receive a set of RACH resources (e.g., contention-free RACH preambles, ROs, etc., which may be of the same size or different sizes) sufficient for a subset of the n WTRUs (e.g., for m WTRUs, where m≤n). In this case, the anchor WTRU may assign or allocate 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, priorities, etc. associated with the member WTRUs. For example, the anchor WTRU may allocate the m resources within the WTRU group based on which WTRU may have latency-critical requirements (e.g., stricter transmit time constraints) and / or which WTRU may have a higher priority.

[0171] In various examples, an anchor WTRU in a WTRU group may allocate dedicated RACH preambles to members of the WTRU group based on the class or type of the members. For example, an XR application experience may involve a WTRU group that includes audio and / or video capture devices, sensors, and the like. The anchor WTRU in such a WTRU group may allocate RACH preambles based on the device class or type of the member WTRUs and / or the priority and / or QoE associated with the XR application. For example, audio devices in a WTRU group may be prioritized because they may have more stringent latency requirements related to user feedback and / or user experience, while video and / or high data volume devices in the WTRU group may be given a lower priority because they may be more tolerant of delays.

[0172] In various examples, an anchor WTRU in a WTRU group may determine which WTRU(s) in the group should be given RACH resources (e.g., dedicated RACH resources) based on overlap in user plane data of multiple WTRUs. For example, multiple WTRUs in a WTRU group may have a common FoV and / or overlapping communication ranges that the anchor WTRU may know (e.g., via information exchange between 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 one (e.g., only one) of the multiple WTRUs to receive the RACH resources. As another example, if the FoV is covered by multiple WTRUs in the RRC_Connected state, the anchor WTRU may exclude the WTRU whose FoV may be covered by the multiple WTRUs, and may prioritize other WTRUs for RACH resources (e.g., if the network provides insufficient resources for allocation in the WTRU group).

[0173] In various examples, if some WTRUs are also part of additional WTRU groups (e.g., this may be inferred or determined based on communication between corresponding anchor WTRUs in the WTRU groups or based on information provided by the base station), the anchor WTRUs of these WTRU groups may coordinate as to which WTRUs may be given higher priority during allocation of RACH resources. For example, if the WTRUs are part of two different WTRU groups and one of the WTRU groups has better channel conditions (e.g., better RSRP / SINR, etc.) than the other WTRU group in the WTRU groups, the network (e.g., base station) may assign RACH resources to the WTRU group with the better channel condition (e.g., if the network does not have enough RACH resources to take care of both WTRU groups).

[0174] The WTRUs in the WTRU group may perform a RACH-less initial access procedure. The RACH-less initial access procedure may refer to a procedure in which the WTRU is able to directly transmit data in the uplink without completing a random initial access. For example, the member WTRUs in the WTRU group may send data directly to the network (e.g., similar to sending data via Msg3 in a 4-step RACH procedure) based on a grant assigned by the network (e.g., similar to what the WTRU may receive via Msg 2).

[0175] A member WTRU in a WTRU group may receive assistance information from an anchor WTRU in the group, enabling the member WTRU to perform a RACH-free initial access procedure, for example, if the anchor WTRU is on the same SSB and / or narrow beam as the member WTRU. In various examples, the anchor WTRU may perform measurements on candidate SSB beams and may transmit information to the member WTRU. The anchor WTRU may request a UL grant from the network on behalf of the member WTRU, receive a UL grant, and forward the UL grant to the member WTRU. The UL grant may be designated for the anchor WTRU or the member WTRU, or it may be a portion of a grant designated for the WTRU group that the anchor WTRU may distribute or divide among multiple member WTRUs. Using the resources provided by the anchor WTRU (e.g., uplink grant, timing advance for synchronization, SSB beam indication or measurements, etc.), the member WTRU may perform a RACH-free initial access procedure (e.g., without sending a RACH preamble).

[0176] A member WTRU in a WTRU group may receive an indication from the network and / or an anchor WTRU in the WTRU group of one or more conditions that the member WTRU may satisfy in order to perform a RACH-free initial access procedure. For example, if the SSB measurement made by the member WTRU is substantially close (e.g., within a threshold) to the SSB measurement made by the anchor WTRU, the member WTRU may perform a RACH-free 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-free 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-free initial access procedure. If the member WTRU comes out of idle mode while the anchor WTRU is in connected mode and / or has updated measurements on the SSB, the member WTRU may perform a RACH-free initial access procedure.

[0177] The member WTRU may operate in a low power state such as an RRC inactive state or an RRC idle state, while the anchor WTRU (e.g., in a WTRU group) may be in an RRC connected state. The member WTRU may or may not maintain its configuration information in such a low power state, and the anchor WTRU may maintain 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 be less capable (e.g., in terms of supporting functionality or features associated with the member WTRU's role in the XR experience) and / or may have reduced capabilities (e.g., the member WTRU may save battery and / or memory by storing only information related to the XR experience). In this case, the member WTRU (e.g., the haptic glove) may or may not maintain its RRC context when it enters the RRC inactive state. When the RRC context is needed, the member WTRU may obtain (e.g., receive or retrieve) the RRC context from the anchor WTRU (e.g., the AR glasses).

[0178] The member WTRU may store its RRC context information at the anchor WTRU (e.g., when the member WTRU transitions to the RRC idle state) so that the transition by 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 such a scenario, the anchor WTRU may be configured to transmit a paging-type message to the member WTRU (e.g., via a sidelink), and the member WTRU may be configured to monitor for paging-type messages from the anchor WTRU, as well as an indication from the anchor WTRU of time / frequency resources for sending or receiving paging-type messages (e.g., included in the SCI).

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

[0180] A member WTRU may receive conflicting messages from the network and the anchor WTRU regarding monitoring paging messages. The member WTRU may determine whether to prioritize the network or the anchor WTRU with respect to paging messages. For example, if the anchor WTRU (e.g., a pair of AR glasses) and the member WTRU (e.g., a pair of haptic gloves) involve an XR experience (e.g., the member WTRU may be operable to enhance the XR experience run 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), for example, 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 a 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 both the anchor WTRU and the network (e.g., when the member WTRU is in an idle state), and in the event of conflicting instructions (e.g., from the network and the anchor WTRU), the member WTRU may prioritize the paging messages from the network.

[0181] In various examples (e.g., if the network has been notified of the WTRU group and / or group members with corresponding WTRU IDs), the network may send a paging message to a designated anchor WTRU (e.g., only to the anchor WTRU), for example, to reduce overhead associated with the sending of paging messages. For example, with existing communication techniques, paging transmission may occur in a cell where the target WTRU may not be located, resulting in 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 have to inform the network if and / or when the WTRU moves out of the coverage area of ​​one cell and into the coverage area of ​​another cell (e.g., in order to track the WTRU on a cell level). This may also result in increased signaling overhead (e.g., in terms of signaling performed to inform the network of the updated WTRU location). A compromise may be made whereby if the network desires to communicate with a member WTRU in a WTRU group, the network may utilize the WTRU group to page (e.g., only page) a designated anchor WTRU, and the anchor WTRU may forward the paging message to the member WTRUs (e.g., the network may avoid paging the member WTRUs individually).

[0182] If the anchor WTRU is configured to save the RRC context of the member WTRU (e.g., when the member WTRU is in an idle or inactive state), the member WTRU may verify the anchor WTRU's ability to store the RRC context information. The verification may be performed, for example, before the member WTRU transitions to an inactive or idle state. In one example, the anchor WTRU is capable of storing RRC context information for a specific number (e.g., two) of member WTRUs at a given time. If another (e.g., a third) member WTRU in the WTRU group transitions to an inactive or idle state, the member WTRU may be configured to wait for a certain period of time (e.g., a certain number of cycles or time slots) before entering the inactive or idle state. The duration of the waiting period (e.g., a certain number of cycles or time slots) may be indicated to the member WTRU (e.g., from the anchor WTRU). In each example, the anchor WTRU may have knowledge of the traffic characteristics of the member WTRU in the idle state or mode and may be able to estimate the time it may take for the member WTRU to transition from the idle state to the connected or inactive state. In various examples, the anchor WTRU may transmit a paging message to one or more member WTRUs (e.g., the two WTRUs described above) that may be supported by the anchor WTRU and / or that are currently in an idle state to wake up the member WTRUs. After these member WTRUs transition to an inactive or connected state, the anchor WTRU is able to support an additional (e.g., a third) member WTRU in an idle state. In various examples, the anchor WTRU may inform the additional member WTRU (e.g., the third member WTRU) that the anchor WTRU may not be able to support the additional member WTRU in an idle state for a subsequent time period (e.g., the next few transmission cycles), and the anchor WTRU may transmit an indication to the network so that the network may store the RRC context of the third member WTRU in the idle state. In various examples, the anchor WTRU may determine that the member WTRU should leave the WTRU group because it cannot support the additional member WTRU in the idle state, and the anchor WTRU may transmit an indication to the member WTRU indicating the determination.

[0183] An anchor WTRU may not be able to enter the idle state while operating as the designated anchor WTRU of a WTRU group. The anchor WTRU may promote another member WTRU within the group to the role of an anchor WTRU, or may transfer the context of the WTRU group to another anchor WTRU (e.g., in the surrounding area) before the designated anchor WTRU transitions to the idle state. A hierarchy of WTRUs (e.g., for playing the anchor role) may be defined within a WTRU group so that a newly designated anchor WTRU may play the anchor role without degrading the XR experience. This hierarchy may be used, for example, if the current anchor WTRU experiences a link failure and a member WTRU may be desired to take over quickly and seamlessly.

[0184] The anchor WTRU may transition from a connected state to an inactive state while maintaining its role as the designated anchor WTRU. One or more conditions may be imposed on the anchor WTRU to achieve such behavior. For example, if one or more member WTRUs (e.g., all member WTRUs) in a WTRU group are in an idle state and the anchor WTRU knows (e.g., via an indication from an XR application) that no member WTRUs may perform a random access procedure during a time window (e.g., a preconfigured or preset duration in the future), the anchor WTRU may transition to an inactive state, operate in an inactive state, or remain in an inactive state. The anchor WTRU may transition to an inactive state during the time window. As another example, the anchor WTRU may transition to an inactive state within the time window in response to receiving an indication from the XR application regarding an upcoming traffic characteristic associated with the XR application and / or an upcoming traffic characteristic of one or more (e.g., all) member WTRUs in the WTRU group. The anchor WTRU may transition to an inactive state in response to determining that the anchor WTRU is no longer involved in a request or coordination action during the aforementioned time window. As yet another example, before the anchor WTRU transmits a request to the network to transition to an inactive state, the anchor WTRU may consider expected traffic patterns or traffic characteristics on the sidelink interfaces with one or more (eg, all) member WTRUs in the WTRU group.

[0185] The anchor WTRU and / or the member WTRU may be configured to implement one or more of the following in a fallback scenario. The anchor WTRU may transmit (e.g., via the SL interface) information (e.g., parameters) to the member WTRU that the member WTRU may use to initiate data transmission (e.g., so 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 measurement, uplink grant, etc. The anchor WTRU may transmit 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 transmitted by the anchor WTRU to the network on behalf of the member WTRU, an identifier of the member WTRU, location, positioning and / or orientation information associated with the member WTRU, information about the size of the UL payload associated with the member WTRU, etc. In various examples, the member WTRU may be configured to use the information transmitted by the anchor WTRU (e.g., via the SL interface) to transmit data in the UL, for example, without performing an initial access procedure. In various examples, the member WTRUs may be configured with conditions under which the member WTRUs may bypass the initial access procedure (e.g., by allowing the anchor WTRU to perform the initial access procedure on behalf of the member WTRU) and / or with a fallback mechanism with which the member WTRUs may perform the initial access procedure themselves. These conditions (e.g., fallback conditions) may be configured for the member WTRUs on a per-WTRU basis. These conditions (e.g., fallback conditions) may be based on one or more of the following.

[0186] The fallback condition may be based on the co-location of the member WTRUs. If the co-location condition associated with the member WTRU and the anchor WTRU is not met, the member WTRU may be configured to perform the initial access procedure with the aid of a fallback mechanism (e.g., perform the initial access itself without assistance from the anchor WTRU). Whether the co-location condition is met may be determined based on one or more of the following. If 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 co-location condition may be considered not met. The member WTRU may periodically measure its spatial or physical distance from the anchor WTRU (e.g., with a periodicity configured by the network). The member WTRU may measure its spatial or physical distance from the anchor WTRU in response to a request or trigger by the anchor WTRU to do so. The member WTRU may measure its spatial or physical distance from the anchor WTRU in response to a request or trigger by the network to do so. The member WTRU may measure its spatial or physical distance from the anchor WTRU in response to a change in the position, movement, or orientation of the member WTRU. The member WTRU may receive information about the distance or distance change between the anchor WTRU and the member WTRU from the anchor WTRU. The member WTRU may receive information about the distance or distance change between the anchor WTRU and the member WTRU from the network. The member WTRU may receive information about the distance or distance change between the anchor WTRU and the member WTRU from an XR application (e.g., which may reside in one or more WTRUs of the WTRU group, in the core network, in an edge server, in a RAN node, etc.).

[0187] The fallback condition may be based on the UL grant size. For example, if the size of the UL grant forwarded, indicated, reserved or granted by the anchor WTRU is not large enough to take into account the UL data that the member WTRU may have for the network (e.g., the UL data in the member WTRU's buffer may be associated with a PDU set, frame and / or data burst, which may be large in size), the member WTRU may be configured to perform initial access with the help of a fallback mechanism (e.g., perform initial access on its own without assistance from the anchor WTRU). The member WTRU may be configured with a threshold (e.g., by the base station) such that if the UL data in the WTRU's buffer is greater than the threshold, the member WTRU may resort to performing initial access alone (e.g., without assistance from the anchor WTRU).

[0188] The fallback conditions may be based on the quality of service (QoS) (e.g., latency, data rate, SINR, etc.) of the member WTRU, the anchor WTRU, and / or the network. For example, if a member WTRU determines that it may not meet the QoS requirements for UL data using a UL grant forwarded, indicated, reserved, or authorized by the anchor WTRU, the member WTRU may be configured to perform initial access with the aid of a fallback mechanism (e.g., perform the initial access itself without assistance from the anchor WTRU). The WTRU may determine that it cannot send a packet within a packet delay budget (PDB) associated with the packet, or send a PDU set within a PDU set delay budget (PSDB) associated with the PDU set by using a UL grant indicated by the base station. As a result, the member WTRU may determine that it may perform the initial access procedure itself.

[0189] The fallback condition may be based on reliability requirements. For example, if a member WTRU determines that it cannot send UL data using a UL grant protected by an anchor WTRU on behalf of the member WTRU according to the reliability requirements, the member WTRU may be configured to perform initial access with the aid of a fallback mechanism (e.g., perform the initial access itself without assistance from the anchor WTRU).

[0190] The fallback condition may be based on measurements such as channel measurements, SSB measurements, and / or positioning measurements. For example, the anchor WTRU may perform channel measurements (e.g., CSI measurements) on its Uu link and transmit a measurement report on the channel measurements to the member WTRU. The member WTRU may perform channel measurements on its own Uu link. The member WTRU may be configured with thresholds on channel measurement parameters (e.g., PMI, CQI, etc.) such that if the difference between the member WTRU's channel measurement and the anchor WTRU's channel measurement exceeds a pre-configured threshold, the member WTRU may use the fallback mechanism to perform an initial access procedure (e.g., perform initial access itself without assistance from the anchor WTRU). The member WTRU may perform SSB measurements (e.g., similar to the CSI-RS measurements in the previous example). If the SSB measurements performed by the member WTRU belong to a different beam than the SSB measurements performed by the anchor WTRU, the member WTRU may use the fallback mechanism to perform initial access (e.g., perform initial access itself without assistance from the anchor WTRU). The anchor WTRU may receive a reference signal (e.g., a positioning reference signal (PRS)) from a network (e.g., a base station) and perform positioning measurements on the PRS. The anchor WTRU may share its positioning measurements 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., a PRS) from the network and perform positioning measurements. The member WTRU may be configured with a threshold (e.g., by the network) such that if the member WTRU's positioning measurements differ from the anchor WTRU's positioning measurements by an amount greater than the configured threshold, the member WTRU may perform an initial access procedure with the aid of a fallback mechanism (e.g., perform initial access itself without assistance from the anchor WTRU).

[0191] A standalone or independent WTRU (e.g., not associated with a WTRU group or an anchor WTRU) may perform an independent initial access procedure, such as a 2-step or 4-step RACH procedure. The WTRU may transmit a random access preamble for itself to the base station (e.g., based on a legacy RACH procedure). The WTRU may transmit an indication to the base station regarding the size of the data to be sent in the UL so that the UL grant transmitted by the base station to the WTRU (e.g., in a message associated with the RACH procedure, such as in Msg 2, Msg B, or Msg 4) may be appropriate (e.g., in size and / or timing) for the data that the WTRU wants to transmit in the UL. The WTRU may then use the UL grant to send data to the base station (e.g., in a RACH message (such as Msg 3, Msg A) or any other message associated with the random access procedure).

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

[0193] 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 (sent via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, built-in hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disk (CD)-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: A processor, the processor being configured to: sending a first message to a network device, wherein the first message includes information regarding a group-based random access procedure associated with a group of WTRUs; receiving a response from the network device, wherein the response indicates one or more resources to be used 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; as well as An indication is transmitted to the group of WTRUs via one or more sidelink messages, wherein the indication indicates the allocation of the one or more resources to the group of WTRUs.

2. The WTRU of claim 1 , wherein the processor is configured to autonomously determine the allocation of the one or more resources to the WTRU group.

3. A WTRU according to claim 2, wherein the processor is configured to determine that the allocation of the one or more resources to the WTRU group includes the processor being configured to determine that the one or more resources are insufficient to account for the WTRU group for the group-based random access procedure.

4. The WTRU of claim 3, wherein the processor is configured to allocate the one or more resources to the WTRU group based on a transmit priority associated with the WTRU group.

5. The WTRU of claim 3, wherein the processor is configured to allocate the one or more resources to the WTRU group based on corresponding transmission time constraints associated with the WTRU group.

6. 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.

7. A WTRU according to claim 1, wherein the response received from the network device includes information indicating how the one or more resources will be allocated to the WTRU group, and wherein the processor is configured to determine the allocation of the one or more resources to the WTRU group based on the information included in the response.

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

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

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

11. The WTRU of claim 1 , wherein the processor is further configured to send a second message to the network device, the second message indicating the allocation of the one or more resources to the WTRU group.

12. The WTRU of claim 1, wherein the one or more resources indicated by the response received from the network device are used to perform the group-based random access procedure through an interface between the network device and the group of WTRUs.

13. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: sending a first message to a network device, wherein the first message includes information regarding a group-based random access procedure associated with a group of WTRUs; receiving a response from the network device, wherein the response indicates one or more resources to be used 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; as well as An indication is transmitted to the group of WTRUs via one or more sidelink messages, wherein the indication indicates the allocation of the one or more resources to the group of WTRUs.

14. The method of claim 13, wherein the allocation of the one or more resources to the WTRU group is autonomously determined by the WTRU based on a corresponding transmission priority or transmission time constraint associated with the WTRU group.

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

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

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

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

19. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: A processor, the processor being configured to: sending a message to an anchor WTRU via a sidelink, wherein the message indicates a request by the WTRU to perform a random access procedure; receiving a response from the anchor WTRU, wherein the response indicates one or more resources for the WTRU to perform the random access procedure; as well as The random access procedure is performed with a network device using the one or more resources indicated by the response.

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

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

Images