Method and apparatus for enabling WTRU cooperation and aggregation for plmn selection and cell selection and reselection

Abstract

The first WTRU may be part of a group of a plurality of WTRUs. The first WTRU may receive capability and configuration information associated with the measurement cooperation from another WTRU in the group. The first WTRU may select the second WTRU to perform measurement cooperation. The first WTRU may send a request for measurement cooperation for cell selection or reselection to the second WTRU. The request may be sent using a sidechain RRC message. The first WTRU may receive measurements for a set of cells from the second WTRU, including RSRP and RSRQ for each cell. The first WTRU may select a cell based on a cell selection criterion. The cell selection criterion may include a group offset offset associated with the cell. The group offset offset for a given cell may be based on the number of WTRUs in the group served by the cell.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 506,250, filed June 5, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] When the Radio Transmitter Receiver Unit (WTRU) is powered on, it can search for a Public Land Mobile Network (PLMN). PLMN selection is performed at the WTRU's Non-Access Stratum (NAS) layer. Once a PLMN is selected, the WTRU can perform initial cell selection and search for suitable cells within the selected PLMN. Cell selection is performed by the WTRU's Access Stratum (AS) layer. When the WTRU AS layer selects a cell, the WTRU can camp on the selected cell. The WTRU can register its presence through the NAS registration process.

[0003] When in idle or inactive mode, the WTRU can perform received signal strength measurements on the selected cell and neighboring cells. Based on cell reselection criteria, if the WTRU finds a more suitable cell, it can reselect to that cell and camp on it. The WTRU can also periodically search for higher-priority PLMNs. If the WTRU NAS layer selects a new PLMN, the WTRU AS layer can search for a suitable cell within the newly selected PLMN, reselect to that cell, and camp on it.

[0004] While camped on a cell, the WTRU can monitor the cell's control channels, for example, to obtain system information and receive paging messages. To be discovered by the network for paging purposes, the WTRU can notify the network of its current location. When reselected to another cell, the WTRU can perform a location update based on changes in the tracking area or RAN notification area to which the new cell belongs. Summary of the Invention

[0005] The WTRU spends most of its time in RRC IDLE / INACTIVE mode, and therefore, the power consumption associated with IDLE and INACTIVE mode operation can have a significant impact on the WTRU's battery life. Active sensing operations during IDLE and INACTIVE modes, such as scanning radio channels for PLMN and cell selection and reselection, are likely among the key power consumption factors in these operating modes. Scanning all capable frequencies and RAT is also time-consuming, which can further impact the WTRU as it may cause delays during PLMN and cell selection and reselection processes.

[0006] This enables a wide variety of devices and applications. Some devices (e.g., WTRUs and / or Personal IoT Network (PIN) elements) may be limited by their capabilities, power, energy, or connectivity to the network. Deploying systems where devices can collaborate and assist each other can improve device performance. In collaborative communication, one device (“assisting WTRU”) can utilize its resources, time, or processing power to assist another device (“assisted WTRU”). The devices can coordinate their processes and communications to enhance each other’s performance. In one example, the assisted WTRU can offload some tasks to a more powerful WTRU or share collected information to reduce sensing requirements.

[0007] In one scenario, the WTRU may use sidechain connections of its services and applications for grouping, and may preferably keep its main Uu radio module off as much as possible to conserve power. If a relay device is present in the group, the WTRU may prefer to communicate with the network via the relay while keeping its main Uu radio module off.

[0008] During cell selection or reselection processes, WTRUs within a group of WTRUs may consider information associated with that group, such as the group's serving frequency, serving cells, or frequency priority. Details regarding the processing of measurements for cell selection and reselection, as well as PLMN selection, by WTRUs within the group are discussed in detail. Criteria for cell selection, cell reselection, and PLMN selection to be used by WTRUs within the WTRU group are described in detail. Biases are introduced into the processes and criteria based on information associated with the WTRU group. Attached Figure Description

[0009] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, wherein the same reference numerals in the drawings indicate the same elements, and wherein: Figure 1A This is a diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B This is a system diagram illustrating an example WTRU; Figure 1C This is a system diagram illustrating the RAN and CN according to an embodiment; Figure 1D This is a system diagram illustrating the RAN and CN according to an embodiment; Figure 2 An example of a measurement model is illustrated; Figure 3 The illustration shows an example of a network that includes multiple Personal IoT Networks (PINs) and PIN elements; Figure 4 This diagram illustrates an example of direct communication between WTRUs; Figure 5 An example of a role in a WTRU group is illustrated; Figure 6 The diagram illustrates an example of a control plane protocol stack with a collaboration layer; Figure 7 This diagram illustrates an example of centralized collaboration functionality in WTRU; Figure 8 This diagram illustrates an example of distributed collaboration functionality in WTRU; Figure 9 The diagram illustrates an example of a control plane protocol stack used for communication and collaboration with the AS and NAS layers of the WTRU via the PC5 interface. Figure 10 The diagram illustrates an example of a control plane protocol stack for inter-WTRU cooperation, where one AS entity can be controlled by multiple NAS entities; Figure 11 The diagram illustrates an example of a control plane protocol stack for inter-WTRU cooperation, where one NAS entity can control multiple WTRU entities; Figure 12 An example of a logical interface used for collaboration is illustrated; Figure 13 The diagram illustrates the call flow of an example of network-based coordinator WTRU selection; Figure 14 The diagram illustrates the call flow of an example of WTRU-based coordinator WTRU selection; Figure 15 The diagram illustrates an example call flow for the cooperative cell selection process of a WTRU with the assistance of other WTRUs; Figure 16 The diagram illustrates an example call flow for the cooperative cell selection process of a WTRU using a coordinator WTRU. Figure 17 The diagram illustrates an example call flow for the packet and cooperative cell selection process using the coordinator WTRU; Figure 18 The diagram illustrates an example call flow for the collaborative PLMN selection process of WTRUs with the assistance of other WTRUs; Figure 19 The diagram illustrates an example call flow for a cooperative PLMN selection process initiated by a WTRU (Coordinator WTRU). Figure 20 The diagram illustrates an example call flow for grouping and cooperating PLMN selection using the coordinator WTRU; Figure 21 The diagram illustrates a flowchart of an example method for performing cooperative cell / PLMN selection; Figure 22The diagram illustrates an example of a control plane protocol stack implementation that collaborates via the Uu interface; Figure 23 The diagram illustrates an example of a control plane protocol stack implementation that collaborates via the PC5 interface; Figure 24 An embodiment of the cooperative cell selection process for the first WTRU is illustrated; Figure 25 The flowchart illustrates an example of cell selection and reselection measurements performed by WTRUs in a group; Figure 26 The diagram illustrates an example of cell selection and reselection criteria used by WTRUs within a group based on a bias associated with the group; and Figure 27 An embodiment of the described solution is illustrated. Detailed Implementation

[0010] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the 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 Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0011] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any one of which may be referred to as a Station (STA)) may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0012] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b can be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (such as gNodeBs (gNBs), new radio (NR) NodeBs), site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

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

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

[0015] More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interface 116. 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 ​​Uplink (UL) Packet Access (HSUPA).

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

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

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

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

[0020] Figure 1ABase station 114b can be, for example, a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106.

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

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

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

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

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

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

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

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

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

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

[0031] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via 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 understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

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

[0033] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (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 through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0034] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

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

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

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

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

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

[0040] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

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

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

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

[0044] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or interfaces to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or leaves the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneling DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode in this document.

[0045] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

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

[0047] The Very High Throughput (VHT) STA can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing are performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

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

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

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

[0051] Figure 1D The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

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

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

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

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

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

[0057] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., processing different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and the like. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. AMF 182a and 182b can provide control plane functions for handover between RAN 104 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.

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

[0059] UPF 184a and 184b can be connected via an N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 104. This N3 interface can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and so on.

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

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

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

[0063] One or more emulation 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, emulation devices can be used in test scenarios within test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices can be test devices. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0064] Abbreviations and Acronyms AP access point AS Access Layer CA carrier aggregation CAG Closed Access Group CE control elements CN core network (e.g., NR or LTE packet core) CPN User Site Network DCI Downlink Control Information DL downlink EPC Evolution Group Core eRG Evolved Residential Gateway EHPLMN is equivalent to HPLMN HPLMN Home PLMN MAC Media Access Control MIMO (Multiple Input Multiple Output) MTC Machine Type Communication NAS Non-Access Layer NR New Radio (5G from 3GPP Rel-15) NTN non-terrestrial networks PIN Personal IoT Network PINE PIN components PLMN Public Land Mobile Network PRAS Local Radio Access Station P2P PINE to PINE P2N PINE to network PHY physical layer PLMN Public Land Mobile Network PO paging opportunity RAT Radio Access Technology RedCap's ability to reduce RF radio front end RNA-based notification region RRC Radio Resource Control RSRP reference signal received power RSRQ reference signal reception quality RSSI Received Signal Strength Indicator SCI sidechain control information SIB System Information Block SL sidechain SNPN (Standard Non-Public Network) SS synchronization signal U2N User to Network UE User Equipment UL uplink URLLC Ultra-Reliable Low-Latency Communication WTRU Wireless Transmit / Receive Unit WTRUs implementing 3GPP Radio Access Technologies (RATs) (including 2G, 3G, 4G, and / or 5G RATs) can perform PLMN selection, cell selection / reselection, and location registration in RRC_IDLE or RRC_INACTIVE mode, including tracking area update procedures. 5G devices can also support RAN notification area (RNA) updates and operations in RRC_INACTIVE state.

[0065] When the WTRU is activated, it selects the PLMN. For the selected PLMN, one or more associated RATs can be configured. Using cell selection, the WTRU can search for suitable cells within the selected PLMN, select that cell to provide available service, and monitor its control channels. The WTRU can register its presence in the tracking area of ​​the selected cell through the NAS registration process.

[0066] When in RRC_IDLE, the WTRU can perform received signal strength measurements on serving and / or neighboring cells. The WTRU can find a more suitable cell based on cell reselection criteria, reselect to that cell, and remain camped on it. If the new cell does not belong to at least one tracking area to which the WTRU has registered, the WTRU can initiate a location registration process. The WTRU can search for higher-priority PLMNs at regular time intervals. If a different PLMN is selected by the WTRU's NAS layer, the WTRU can search for a suitable cell in the new PLMN.

[0067] If the WTRU loses coverage of the registered PLMN, it can automatically select a new PLMN. Alternatively, the WTRU can indicate available PLMNs to the user, allowing the user to perform a manual selection. For the network, various control mechanisms exist to prioritize cell selection on certain RATs, control the rate at which low, medium, or high mobility WTRUs perform cell reselection, and prevent WTRUs from reselecting selected tracking areas.

[0068] When a WTRU camps on a cell in RRC_IDLE or RRC_INACTIVE state, it can receive system information from the PLMN, establish or resume suspended RRC connections, and receive notifications from the Earthquake and Tsunami Warning System (ETWS) or the Commercial Mobile Alert System (CMAS). Furthermore, if the network needs to send control messages or deliver data to a registered WTRU, in most cases, the network "knows" the set of tracking areas where the WTRU camps. Paging messages can be sent to the WTRU on the control channels of all cells within the corresponding set of tracking areas. The WTRU can receive and respond to the paging messages.

[0069] The WTRU can scan all RF channels in the NR band to find available PLMNs and available CAGs. On each carrier, the WTRU typically searches for the strongest cell and reads its system information to determine which PLMN(s) the cell belongs to and any associated Cell Access Groups (CAGs). For operations using shared spectrum channels, the WTRU can also read the system information of multiple strongest cells. If the WTRU can read one or more PLMN identifiers from the strongest cells, or, in the case of operations using shared spectrum channels, one or more identifiers from multiple strongest cells, each discovered PLMN can be reported to the NAS as a high-quality PLMN (but without an RSRP value) and any associated CAG-ID, provided the following high-quality criteria are met: for NR cells, the measured Reference Signal Received Power (RSRP) value is greater than or equal to -110 dBm.

[0070] If a PLMN that does not meet the high-quality criteria is found but whose PLMN identifier can be read by the WTRU, the PLMN, along with its corresponding RSRP value and any associated CAG-ID, should be reported to the NAS. For each PLMN found in a cell, the quality measurements reported by the WTRU to the NAS should be identical.

[0071] The search for the PLMN can be stopped upon request from the NAS. The WTRU can improve or even optimize the PLMN search by using stored information, such as frequency and optionally information about cell parameters from previously received measurement control information elements.

[0072] After the WTRU has selected a PLMN, a cell selection process can be performed to select a suitable cell for the PLMN for the WTRU to camp on.

[0073] Attribution PLMN: This is a PLMN in which the MCC and MNC identified by the PLMN are matched with the MCC and MNC of the IMSI according to known matching criteria.

[0074] EHPLMN: Any PLMN entry contained in the equivalent HPLMN list.

[0075] Equivalent HPLMN List: To allow the provision of multiple HPLMN codes, the PLMN codes present in this list replace the HPLMN codes derived from the IMSI for PLMN selection purposes. This list is stored on the USIM and is referred to as the EHPLMN list. The EHPLMN list may also contain HPLMN codes derived from the IMSI. If an HPLMN code derived from the IMSI does not exist in the EHPLMN list, it is considered a visited PLMN for PLMN selection purposes.

[0076] Visiting PLMN: This is a PLMN that is different from HPLMN (if the EHPLMN list does not exist or is empty) or different from EHPLMN (if the EHPLMN list exists).

[0077] A WTRU typically operates on its home PLMN (HPLMN) or equivalent home PLMN (EHPLMN). However, for example, if the WTRU loses coverage, it can choose to visit a PLMN (VPLMN). There are two modes for PLMN selection: In automatic mode, the WTRU can utilize a list of PLMN / access technology combinations in priority order, selecting the highest priority PLMN / access technology combination available and permissible. In manual mode, the WTRU can indicate to the user which PLMNs are available. The WTRU only attempts to obtain normal service on a VPLMN when the user makes a manual selection.

[0078] Cell selection can be an initial cell selection (e.g., without prior knowledge of which RF channels are NR frequencies) or a cell selection that utilizes existing information.

[0079] During initial cell selection, the WTRU can scan all RF channels in the NR band according to its capabilities to find a suitable cell. At each frequency, the WTRU can search for the strongest cell (except for operations using shared spectrum channels, where the WTRU can search for the next (or more) strongest cells). Once the WTRU finds a suitable cell, it can select that cell.

[0080] In cell selection using stored information, the WTRU uses stored frequency information, and optionally information about cell parameters from previously received measurement control information elements or from previously detected cells. Once the WTRU finds a suitable cell, it can select that cell. If no suitable cell is found, the initial cell selection process can begin.

[0081] The NAS can control one or more RATs in which cell selection should be performed, for example by instructing one or more RATs associated with the selected PLMN, and by maintaining one or more lists of disabled registered areas and equivalent PLMNs.

[0082] The WTRU can perform measurements for cell selection and reselection purposes. The WTRU can select an appropriate cell based on RRC_IDLE or RRC_INACTIVE state measurements and cell selection (reselection) criteria.

[0083] For cell reselection, in order to limit the number of measurements that the WTRU needs to perform, the WTRU first verifies whether certain conditions are met. If the conditions are met, the WTRU can begin performing measurements in neighboring cells.

[0084] When evaluating the Srxlev and Squal of a non-serving cell for cell reselection assessment purposes, the WTRU can use parameters provided by the serving cell. For the final check of cell reselection criteria, the WTRU can use parameters provided by the target cell.

[0085] While stationary on a cell, the WTRU can periodically search for a better cell based on cell reselection criteria. If a better cell is found, the WTRU can reselect to that cell. A change in cell may mean a change in the RAT (Regional Access Threshold).

[0086] As an example, cell selection criterion S can be satisfied under the following conditions: Srxlev>0 and Squal>0, where: in: Srxlev is the cell-selected RX level value (in dB) and is determined as follows: Srxlev = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) – Pcompensation – Qoffsettemp; where: Qrxlevmeas: Cell RX level (Reference Signal Received Power RSRP). Measured by WTRU.

[0087] Qrxlevmin: The minimum required RX level (dBm) in the cell. Configured by RRC.

[0088] Qrxlevminoffset: The offset used when residing in a VPLMN and searching for higher-priority PLMNs. Configured by RRC.

[0089] Pcompensation: For FR1: Depends on the WTRU power rating and is configured by RRC. For FR2 = 0.

[0090] Qoffsettemp: Temporarily applied offset for the cell. Configured by RRC.

[0091] Qrxlevminoffset: The offset used when residing in a VPLMN and searching for higher-priority PLMNs. Configured by RRC.

[0092] Qrxlevminoffsetcell: Cell-specific offset added to the corresponding Qrxlevmin to achieve the minimum RX level required in the relevant cell. Configured by RRC.

[0093] Squal is the cell selection quality value (in dB) and is determined as follows: Squal = Qqualmeas – (Qqualmin + Qqualminoffset) – Qoffsettemp Qqualmeas: Cell quality value (Reference Signal Received Quality RSRQ). Measured by WTRU.

[0094] Qqualmin: The minimum quality level (dB) required in the cell. Configured by RRC.

[0095] Qqualminoffset: The offset used when residing in a VPLMN and searching for higher-priority PLMNs. Configured by RRC.

[0096] Qoffsettemp: Temporarily applied offset for the cell. Configured by RRC.

[0097] The absolute priority of different NR frequencies or inter-RAT frequencies can be provided to the WTRU in the system information, in the RRC release message, or by inheritance from another RAT during inter-RAT cell selection (reselection). In the case of system information, NR frequencies or inter-RAT frequencies can be listed without providing priority (i.e., the cellReselectionPriority field does not exist for that frequency).

[0098] Different rules can apply to different priorities. In one example, if the serving cell does not satisfy Srxlev > SIntraSearchP and Squal > SIntraSearchQ, the WTRU can perform intra-frequency measurements. In another example, for inter-NR frequencies or inter-RAT frequencies with a reselection priority higher than the current NR frequency, the WTRU can perform measurements on the higher-priority inter-NR frequency or inter-RAT frequency. In yet another example, for inter-NR frequencies with a reselection priority equal to or lower than the current NR frequency, and for inter-RAT frequencies with a reselection priority lower than the current NR frequency, if the serving cell does not satisfy Srxlev > SnonIntraSearchP and Squal > SnonIntraSearchQ, the WTRU can perform measurements on inter-NR frequency cells with equal or lower priorities or inter-RAT frequency cells with lower priorities.

[0099] If threshServingLowQ is broadcast in the system information and more than 1 second has elapsed since the WTRU camped on the current serving cell, then if during the time interval TreselectionRAT, a cell of a higher priority NR or EUTRAN RAT / frequency satisfies Squal > Thresh_(X, HighQ), then cell reselection to a cell on a NR frequency or an inter-RAT frequency of higher priority than the serving frequency is performed. Otherwise, if during the time interval TreselectionRAT and more than 1 second has elapsed since the WTRU camped on the current serving cell, a cell of a higher priority RAT / frequency satisfies Srxlev > Thresh_(X, HighP), then cell reselection to a cell on a NR frequency or an inter-RAT frequency of higher priority than the serving frequency is performed.

[0100] Cell reselection to a cell on a NR frequency of equal priority is based on the ranking of intra-frequency cell reselection.

[0101] If threshServingLowQ is broadcast in the system information and more than 1 second has elapsed since the WTRU camped on the current serving cell, then if during the time interval TreselectionRAT, the serving cell satisfies Squal < Thresh_(Serving, LowQ), and a cell X of a lower priority NR or E-UTRAN RAT / frequency satisfies Squal > Thresh_(X, LowQ), then cell reselection to a cell on a NR frequency or an inter-RAT frequency of lower priority than the serving frequency may be performed. Otherwise, if during the time interval TreselectionRAT and more than 1 second has elapsed since the WTRU camped on the current serving cell, the serving cell satisfies Srxlev < Thresh_(Serving, LowP), and a cell X of a lower priority RAT / frequency satisfies Srxlev > Thresh_(X, LowP), then cell reselection to a cell on a NR frequency or an inter-RAT frequency of lower priority than the serving frequency is performed.

[0102] Regarding measurements for RRC_IDLE and INACTIVE modes, the WTRU may perform measurements for cell selection and reselection purposes.

[0103] When evaluating Srxlev and Squal of non-serving cells for reselection evaluation purposes, the WTRU uses the parameters provided by the serving cell. For the final check regarding cell reselection criteria, the WTRU may use the parameters provided by the target cell for cell reselection.

[0104] Equipment (such as WTRU) can measure the reference signal received power (RSRP) and reference signal received quality (RSRQ) of a cell based on the cell definition (CD) SSB, namely SS-RSRP and SS-RSRQ.

[0105] The Received Power of the Synchronization Signal (SS) Reference Signal (SS-RSRP) is defined as the linear average of the power contribution (in [W]) of the resource element carrying the auxiliary synchronization signal.

[0106] SS-RSRP can only be measured in reference signals corresponding to SS / PBCH blocks with the same SS / PBCH block index and the same physical layer cell identifier. If SS-RSRP is not used for L1-RSRP, and a higher layer indicates that certain SS / PBCH blocks are used to perform SS-RSRP measurements, then SS-RSRP is measured only from the indicated set (or more) of SS / PBCH blocks.

[0107] In multi-beam operation, cell quality can be derived from the beams corresponding to the same cell.

[0108] The Received Quality of the Auxiliary Synchronization Reference Signal (SS-RSRQ) is defined as the ratio of N × SS-RSRP / NR carrier Received Signal Strength Indicator (RSSI), where N is the number of resource blocks in the NR carrier RSSI measurement bandwidth. Measurements of the numerator and denominator should be performed on the same set of resource blocks.

[0109] Figure 2 An example of a measurement model is illustrated. For example... Figure 2 As shown, a beam-specific sample (A) can represent a measurement within physical layer 201. The beam-specific sample (A) can be the input to layer 1 filter 202. Precise filtering may vary depending on the implementation choice. The procedures used to physically perform the measurement can differ (e.g., input A and layer 1 filter can be implementation-specific).

[0110] The output A1 203 of the layer 1 filter can be reported from layer 1 to layer 3 211.

[0111] Beamforming and selection 204 can be used to integrate beam-specific measurements to derive cell quality 205. The behavior of beamforming / selection 204 can be standardized, and the configuration of this module can be provided by RRC signaling. Cell quality B 205 can be derived from beam-specific measurements reported to Layer 3 after beamforming / selection 205. The reporting period at B 205 can be equal to one measurement period at A1 203.

[0112] Further Layer 3 filtering 206 for cell quality 205 can be performed on the measurements provided at point B 205. The behavior of the Layer 3 filter can be standardized, and the configuration of the Layer 3 filter can be provided by RRC signaling. The filtering reporting cycle at C 207 can be equal to one measurement cycle at B 205.

[0113] The results of the measurement after processing by the layer 3 filter are Figure 2 The "C" in 207 indicates that the reporting rate can be the same as the reporting rate at point B 205. This measurement can be used as input for one or more evaluations of reporting criterion 208.

[0114] The evaluation of reporting criterion 208 can be a process of verifying the necessity of measurement reporting at point D 209. This evaluation can be based on more than one measurement stream at reference point C 207, for example, to compare different measurements. This is illustrated by inputs C207 and C1 210. The WTRU can evaluate the reporting criterion at least each time a new measurement result is reported at point C 207 or C1 210. The reporting criterion can be standardized, and the configuration can be provided by RRC signaling (e.g., WTRU measurement reporting configuration).

[0115] like Figure 2 As shown, D 209 represents measurement report information transmitted on the radio interface (e.g., on a message).

[0116] L3 beam filtering 211 can be performed on measurements provided at point A1 203 (e.g., on beam-specific measurements). The behavior of the beam filter can be normalized, and the configuration of the beam filter can be provided by RRC signaling. The filtering reporting cycle at E can be equal to one measurement cycle at A1.

[0117] E 212 represents the measurement processed in L3 beam filter 211 (e.g., beam-specific measurement). Those measurements are associated with K beams 215. The reporting rate can be the same as the reporting rate at point A1 203.

[0118] The beam selection process 213 can result in the selection of X beams 214 from the K beam 215 measurements provided at point E 212, thereby resulting in the measurement at point F 216. The beam selection behavior can be standardized, and the configuration of this module can be provided by RRC signaling.

[0119] F 216 indicates beam measurement information included in measurement reports (e.g., transmitted) on the radio interface.

[0120] Layer 1 filtering can employ a degree of measurement averaging. How and when the WTRU precisely performs the required measurements can be implementation-specific and can be based on some predetermined performance requirements of the output at B 205. Ideally, Layer 3 filtering for cell quality 206 and associated parameters should not introduce any delay in sample availability between B 205 and C 207. C1 210 is the input used in the event assessment of reporting criterion 208. Ideally, L3 beam filtering 211 and associated parameters should not introduce any delay in sample availability between E 212 and F 216.

[0121] The measured values ​​are subject to accuracy considerations, where the accuracy requirements for the absolute and relative measurements of RSRP and RSRQ are known for different scenarios, such as depending on the frequency range, operating mode and / or temperature.

[0122] The described use case utilizes various connections between WTRUs (including NR sidechains on licensed or unlicensed frequency bands) and WTRUs connected via a network (including NR Uu). Furthermore, devices such as WTRUs can have multiple radio modules, one dedicated to direct communication between WTRUs (e.g., sidechains) and one dedicated to the network (Uu). WTRU groups can be formed using sidechain connections between users, where only a subset of the users in the group may have activated their Uu radio modules.

[0123] Personal IoT Networks (PINs) and Customer Premises Networks (CPNs) provide local connectivity between WTRUs and / or non-3GPP devices. Access to 5G network services can be provided to WTRUs and / or non-3GPP devices on the CPN or PIN via an eRG or via a PIN element with gateway capabilities. A common feature of CPNs and PINs is that they are typically owned, installed, and / or (at least partially) configured by users of public network operators.

[0124] A Customer Premises Network (CPN) is a network located within a specific premises (e.g., a residence, office, and / or shop). The CPN can provide connectivity to the 5G network via an evolved Residential Gateway (eRG). The eRG can connect to the 5G core network via wired, wireless, or hybrid access. A Premises Radio Access Station (PRAS) is a base station installed within the CPN. Through the PRAS, the WTRU gains access to CPN and / or 5G network services. The PRAS can be configured to use licensed, unlicensed frequency bands, or both. Connections between the eRG and the WTRU, non-3GPP equipment, or the PRAS can use any suitable 3GPP or non-3GPP technology (e.g., Ethernet, optical, WLAN).

[0125] A Personal IoT Network (PIN) comprises PIN elements that communicate using direct PIN connections or direct network connections and are managed locally (using PIN elements with management capabilities). A PIN includes at least one PIN element with gateway capabilities and at least one PIN element with management capabilities. Examples of PINs include networks of wearable devices and smart home / smart office devices.

[0126] A PIN element can access 5G network services via a PIN element with gateway capabilities. Using a PIN element with gateway capabilities, the PIN element can communicate with other PIN elements that may not be within the range of direct PIN connections.

[0127] A PIN with administrative capabilities is a PIN that provides authorized administrators with the means to configure and manage PINs.

[0128] Figure 3 The illustration shows an example of a network that includes multiple Personal IoT Networks (PINs) and PIN elements.

[0129] In applications such as extended reality (XR) and / or augmented reality (AR) / virtual reality (VR), use cases may include wearable connected objects where the device can offload some processing (e.g., audio, video) to a more capable device. These devices can form interconnected groups of WTRUs, which can share their processing power and require communication, typically wireless communication such as NR sidechains. Industrial networks and Industrial IoT (IIoT) use cases can leverage WTRU collaboration / aggregation frameworks, where devices such as sensors can interconnect, for example, for redundancy or reliability.

[0130] WTRUs can be grouped to assist each other and improve equipment performance. Typically, a higher-capacity device can assist a lower-capacity device in performing some processes or relaying signals from a higher-capacity device. Motivations can range from equipment hardware (small form factor, low-cost device, limited hardware) to energy considerations (low-power or low-energy devices may reduce their energy-saving capabilities), or even assistance in improving coverage and reliability.

[0131] WTRU aggregation refers to a relay solution with specific multipath attributes. This multipath relay solution can be used for WTRU aggregation, where a WTRU is connected to the network via two links: via a direct path and via another WTRU using a proprietary (non-standardized) WTRU-WTRU interconnect. WTRU aggregation is designed to provide high UL bit rates for applications on 5G terminals, in case ordinary WTRUs are too limited by the UL WTRU transmission power to achieve the required bit rates, especially at cell edges. Furthermore, WTRU aggregation can improve service reliability and stability, and reduce service latency. If a terminal's channel conditions deteriorate, another terminal is used to compensate for the instability in service performance caused by changes in channel conditions.

[0132] In the context of aggregation, an anchor WTRU is a WTRU that serves as the source or destination for service and payload data, and can use an aggregated WTRU as a relay. An anchor WTRU may or may not have a direct connection to the network. An aggregated WTRU is a WTRU that assists / helps the anchor WTRU access the network. In the context of NR sidechain (SL) relay, an anchor WTRU can correspond to a remote WTRU, while an aggregated WTRU can correspond to a relay WTRU.

[0133] WTRU aggregation may involve scenarios where WTRU collaboration is expected to enable functionality beyond that of a relay. WTRUs can aggregate their capabilities (processing, power, time, functions) and assist each other in performing tasks and processes.

[0134] In the following description, the terms “aggregate WTRU” and “assist WTRU” are used interchangeably; the terms “anchor WTRU” and “assisted WTRU” are used interchangeably.

[0135] Examples of processes, signaling, and configurations for enabling collaboration and measurement aggregation between WTRUs in RRC IDLE or INACTIVE modes are described, including: enabling collaborative / distributed measurements by offloading some measurements to other devices; processing and evaluating received measurements for cell and PLMN selection (reselection); enabling cell reselection for groups and adapting priorities and evaluation criteria to reorganize WTRUs in the same cell while avoiding ping-pong reselection effects.

[0136] A group serving cell can refer to a cell of a WTRU within a serving group, or a cell of at least a minimum number of WTRUs within a serving group, or a cell serving at least a minimum percentage of the WTRU group. Multiple cells may serve the group (e.g., if they are scattered in space). A group serving frequency is a frequency used in the cells within a group serving cell.

[0137] As a high-level view of the embodiment, WTRUs can be configured to assist each other in performing measurements for PLMN selection, cell selection, and cell reselection. Measurements from WTRUs and their assisting / aggregating WTRUs can be used in the evaluation and selection process, which has specific biases to account for the fact that some measurements are not performed locally.

[0138] One or more of the examples could be an application scenario where the WTRU is equipped with multiple radio modules, such as NR SL + NR Uu, and the sidechain is already used for aggregation / grouping purposes (e.g., application / user requirements). In this case, cooperation can be used to avoid turning on the main Uu radio module and save WTRU energy.

[0139] An assisting WTRU can perform measurements on behalf of the assisted WTRU, reducing the number of measurements and processing required for the assisted WTRU, and allowing it to benefit from the assisting WTRU's capabilities. The assisting WTRU can offload some frequency scans required for PLMN and cell selection (reselection) to other devices. These other devices can scan and return relevant information to the assisted WTRU, enabling it to complete PLMN and cell selection (reselection) using scan results from other devices (as well as its own). With WTRU cooperation for PLMN and cell selection (reselection), the assisted WTRU does not need to scan all the RATs and frequencies it can scan, thus reducing its power consumption and increasing its battery life. Furthermore, by offloading some scans to other devices, different scans can be performed simultaneously, which can reduce the time required to complete a scan, potentially reducing overall PLMN and cell selection (reselection) latency.

[0140] Cell and PLMN selection processes can be performed when the WTRU is not camped or attached to a cell and may not have a network configuration. In this scenario, the proposed embodiments may use an NR sidechain in an unlicensed frequency band, where the WTRU can perform communications without network configuration or coverage (e.g., using autonomous resource allocation (e.g., mode 2)). An NR sidechain using licensed spectrum can be used in conjunction with a network configuration when performing measurements for cell reselection or when cooperating for a PLMN after a higher-priority PLMN has already been selected. Cell selection can also be triggered by state transitions, such as receiving an RRRCRelease message that may contain network information.

[0141] In variations of the embodiments, non-3GPP communication such as Wi-Fi or Bluetooth can be used for WTRU inter-communication.

[0142] The solution can be described using an example of aggregation between two WTRUs. The same solution applies to similar aggregations with more WTRUs.

[0143] Regarding the architecture and topology of collaboration and aggregation, WTRU aggregation can be performed using inter-WTRU connections, such as PC5 (sidechain) or any other communication system, standardized or non-standardized, 3GPP or non-3GPP, such as Wi-Fi, Bluetooth, or wired connections. An example using an NR sidechain can be used to describe the solution, but other inter-WTRU interfaces can also be used.

[0144] WTRUs may or may not be within the network's coverage area, and the connection to the network is not always necessary to perform direct WTRU aggregation.

[0145] Figure 4 An example of direct communication between WTRUs is illustrated.

[0146] As shown, the WTRU can be within network coverage 401 or outside network coverage 402.

[0147] In some scenarios, such as in personal IoT networks (PINs), tethered devices (e.g., XR, wearables), industrial IoT devices, or interactive services, devices may need to communicate with each other for services or applications of interest. Device groups can be formed based on services or applications, where devices can communicate with each other and may also have network connectivity. In application- or service-oriented groups, the WTRUs within the group can be selected and managed by services / applications at higher layers. Group formation communication exchanges can be configured during the PC5 connection establishment phase, or after a connection is established using, for example, the newly defined PC5-Collab interface, or using signaling of the PC5 signaling (PC5-S) type, communicating at the RRC level (PC5-RRC) using, for example, RRC messages, at the MAC level (PC5-MAC) using, for example, MAC control units (MAC CEs), and at the PHY level (PC5-PHY) using, for example, sidechain control information (SCIs).

[0148] WTRU groups can be static (e.g., fixed size and devices in the group) or dynamic, where WTRUs can be added and removed based on, for example, deployments, devices, and services.

[0149] Depending on the purpose of the group, certain requirements can be configured, such as performance requirements and connectivity between WTRUs in the group.

[0150] For example, one possible connectivity aspect is that a group (or part of a group) is served by the same cell, the same gNB, or the same PLMN. This requirement might be useful for devices that support multipath (Uu and SL) but not WTRU relays not served by the same cell. It could also be a network requirement to facilitate management and communication with the WTRU in the absence of inter-gNB or roaming switching.

[0151] Figure 5 The diagram illustrates an example of roles within a WTRU group. Within a group, WTRUs can have different roles depending on their hierarchy. In one example, a WTRU could be considered a peer in group 501. In this case, no user might manage other users. Collaboration within a group involves sharing information, requesting assistance, or forwarding data or control information to each other.

[0152] Another example is connecting the master WTRU 502 to other WTRUs 503. The master WTRU can be a coordinator WTRU 502, which can act as a manager, coordinator, or controller for other devices 503.

[0153] In the solution described in this article, the master WTRU can be referred to as the coordinator WTRU.

[0154] A coordinating WTRU can be connected to other devices and can centralize information distribution among WTRUs. The coordinating WTRU can centralize decisions and information within a group and be used to offload tasks or processes. The coordinating WTRU can facilitate cooperation between other WTRUs or their own cooperation with other WTRUs. When a coordinating WTRU is present, a direct WTRU cooperation link between the two WTRUs performing cooperation may be an unnecessary 504 error.

[0155] Within a WTRU group, one WTRU can act as a coordinating WTRU. This device is responsible for coordinating the WTRUs in the group to perform tasks collaboratively or on behalf of other WTRUs in the group. The coordinating WTRU can also provide connectivity to the network for the WTRUs in the group (e.g., acting as a relay or gateway). The coordinating WTRU may need to have the ability to perform collaboration, including strong connections with other WTRUs in the group.

[0156] WTRU information shared among WTRUs in a group can be transmitted through the coordinating WTRU, especially when there is no direct connection between the WTRUs performing the cooperation. This information can also be shared via a network (e.g., through a Uu interface, such as via RRC or higher-level signaling).

[0157] The coordinator WTRU can receive cooperation information from other WTRUs and transmit it to the appropriate destination. The coordinator WTRU can also store cooperation information for later sharing with users upon request. WTRUs can request information corresponding to a specific WTRU or information associated with that group from the coordinator WTRU.

[0158] Collaboration between WTRUs requires specific processes and implementation capabilities. Some devices can implement the necessary characteristics to act as group coordinators, and these characteristics can be represented by specific WTRU categories or classes.

[0159] Figure 6 The diagram illustrates an example of a control plane protocol stack with a collaboration layer.

[0160] In this example, the WTRU's collaboration layer 601 communicates via a direct PC5 communication interface.

[0161] The WTRU's collaboration layer can communicate using PC5 interface 602. In one example, the collaboration layer can utilize the existing PC5-RRC interface 603 and communicate using, for example, SL RRC messages. In another example, the collaboration layer can utilize the existing PC5-MAC interface 604 and communicate using, for example, MAC control elements (MAC-CE). In yet another example, the collaboration layer can utilize the existing PC5-PHY interface 605 and communicate using, for example, sidechain control information (SCI). In yet another example, communication between collaboration layers can be performed using a newly defined PC5-Collab interface 606. PC5-Collab 606 can be a dedicated interface, optionally with dedicated SRBs for exchanging collaboration information.

[0162] In the solutions described in the following paragraphs, the term PC5-Collab or PC5-Collab interface may be used to refer to any of such alternative implementations, such as PC5-S, PC5-RRC, PC5-MAC, PC5-PHY, or the newly defined PC5-Collab interface.

[0163] One of the purposes of the cooperation layer is to enable cooperation and communication between the protocol stack layers that implement the non-access layer (NAS) and access layer (AS) control planes of different WTRUs. Each layer performs its own tasks of connection, data transmission, and data reception. The cooperation capabilities added to the WTRU can be used as inputs for tasks, processes, and decisions performed in each layer of the WTRU.

[0164] Figure 7An example of centralized collaboration functionality in a WTRU is illustrated. In this example, the collaboration functionality can be implemented in a centralized manner, for example, with each WTRU having its own collaboration layer 701. Collaboration layers of different WTRUs can communicate with each other 702 and share collaboration information. The collaboration layer can then communicate internally with other layers of the WTRU to share information received from other WTRUs. Each layer may be interested in different types of information. In one example, each layer can subscribe to the types of information they are interested in 703. In another example, each layer can request information from the collaboration layer 704 and, in response, receive a report 705 containing the requested information (e.g., the information can be provided by the collaboration layer based on demand). This request can be a one-time report, or it can trigger periodic or non-periodic reports. Each layer can also report information to the collaboration layer, such that the information can be shared 702 with collaboration layers 701 of other WTRUs. This report can be a one-time report, or it can trigger periodic or non-periodic reports.

[0165] Figure 8 The illustration shows an example of distributed collaboration functionality in a WTRU. In this example, collaboration functionality is distributed across the various layers of the WTRU (e.g., PHY, MAC, RLC, PDCP, RRC, and NAS layers). Each layer of the protocol stack in one WTRU 801 communicates independently with its peer layer in another WTRU 802.

[0166] Figure 9 The diagram illustrates an example of a control plane protocol stack used for communication and collaboration with the AS and NAS layers of the WTRU via the PC5 interface.

[0167] In this example, using the 3GPP architecture and a sidechain for WTRU inter-communication, the WTRU's Uu AS 901 and NAS 902 can communicate and exchange messages with each other via the PC5 interface, and optionally via the newly defined PC5-Collab interface 903. At the Uu AS level, WTRU inter-communication can be performed between any Uu layer (such as PHY, MAC, RLC, PDCP, or RRC), directly between AS layers, or via the cooperation layer 903. For intra-WTRU communication, the cooperation layer can communicate internally with all Uu AS layers directly or indirectly (e.g., via the ASNAS layer). Alternatively, as discussed previously, a more distributed approach can be used.

[0168] In one example, WTRU1 can offload one or more tasks to the Uu AS of WTRU2, or WTRU1 can divide a task into subtasks and offload the subtasks to the AS of WTRU2. Using input from the Uu layer, the offloading decision can be made at the WTRU1NAS or WTRU1 AS, or at the WTRU collaboration layer. And although the AS of WTRU2 can be used to perform some tasks on behalf of WTRU1, it can still operate and execute its own processes (e.g., processes associated with WTRU2), but in this case, those processes can be commanded by its own NAS.

[0169] Figure 10 The illustration shows an example of a control plane protocol stack for inter-WTRU cooperation, where one AS entity can be controlled by multiple NAS entities.

[0170] exist Figure 10 The example uses a 3GPP sidechain WTRU inter-connection, where WTRU1's NAS 1001 can use two different WTRUs 1002 and 1003's Uu ASs to perform tasks. The NAS layer in WTRU1 1002 can offload tasks to WTRU2's Uu AS, or WTRU1 can divide tasks into subtasks and offload the subtasks to WTRU2's AS. Offloading decisions can be made at WTRU1's NAS, WTRU1's AS, or both via the WTRU cooperation layer. WTRU2's Uu AS can still operate and execute its own processes (e.g., processes associated with WTRU2), and in this case, it can be commanded by its own NAS for those processes.

[0171] Figure 11 The diagram illustrates an example of a control plane protocol stack for inter-WTRU cooperation, where one NAS entity can control multiple WTRU AS entities.

[0172] In this example, a single NAS entity 1101 directly controls AS entities 1102 of WTRU1 and 1103 of WTRU2. This can be extended to multiple WTRUs, as two WTRUs are used as an example for illustrative purposes. The NAS entity can reside in one of the controlled WTRUs or in the other. Communication between the collocated NAS and AS layers is performed using inter-WTRU collaboration, such as the PC5-Collab interface or other inter-WTRU interfaces.

[0173] Before performing the collaboration process, WTRUs can exchange information for configuration (e.g., how they coordinate), information about their capabilities, and information about their communication channels.

[0174] Cooperative configuration may include information such as available RATs; supported frequency bands / carriers; interface capabilities (e.g., Uu and SL capabilities); WTRU profiles (WTRU type, power profile); and WTRU cooperative capabilities (e.g., which processes are supported for coordination, and which information requests or sharing are supported).

[0175] WTRU can use PC5 to send direct transmissions to users in its group, including unicast, multicast, or broadcast transmissions. Transmissions can be event-based, periodic, or aperiodic. The frequency may depend on the content of the transmission.

[0176] Cooperative configuration may include the scheduling or timing of expected WTRU transmission or reception of cooperative signaling (e.g., using periodic or dynamic scheduling).

[0177] A WTRU can request information from another WTRU. The WTRU can send requests via the PC5-Collab interface and also receive responses / reports at the corresponding layer on the PC5-Collab interface. In the example, the request could be a layer 1 measurement of a reference signal exchanged between the PHY layers of the WTRUs; or an L3 measurement of a reference signal exchanged between the RRC layers of the WTRUs. It can also be at the MAC layer level, for example, using MAC CE.

[0178] The request can be for a one-time report or can trigger periodic / non-periodic reporting (i.e., subscribing to collaborative content). When a WTRU receives a request, it can respond with the information to be reported (if available) (and possibly after performing some related processes). The WTRU can report to the WTRU that transmitted the request. When a WTRU is registered for specific periodic collaboration, the WTRU can be triggered periodically or by an information update report to the requesting / registered WTRU.

[0179] As a complement to the previous architecture, a WTRU can also request another WTRU to perform a selected task on its behalf.

[0180] In one example, a coordinating WTRU can first coordinate its NAS and AS configurations, such as available RATs, supported frequencies, and processes.

[0181] Figure 12 An example of a logical interface used for collaboration is illustrated.

[0182] In terms of logical functionality, the NAS (NAS1) of WTRU1 can communicate with the AS (AS2) of WTRU2 via an interface. To perform this communication, the PC5 interface is used: NAS1 1201 can send commands to AS2 1202 via the logical interface NAS1-AS2 1203 through PC5-Collab 1204. WTRU2 can then execute the requested procedure or task, and after completing the procedure or task, WTRU2 can report the output to NAS1 via the logical interface NAS1-AS2 1203 through PC5-Collab 1204. The content of the reports and commands can remain similar to typical inter-layer communication within a single WTRU, but the interface can be changed (e.g., the destination can be changed to an upper (or lower) layer of another WTRU), and the information is encapsulated for transmission to the peer WTRU.

[0183] In an alternative implementation, NAS1 1201 can use AS2 1202 to perform tasks, but via the NAS layer (NAS2) 1205 of WTRU2. NAS1 1201 can send a request for offloading to NAS2 1205, while NAS2 1205 can send task requests to AS2 1202 (e.g., transparently or by controlling the behavior of AS2 to ensure compatibility and cooperation with the rest of the WTRU's tasks).

[0184] Optionally, a collaboration layer can be used to send task requests and reports between WTRUs.

[0185] Regarding WTRU information exchange for collaboration / aggregation, information can be shared to enable collaboration among WTRUs within a group, allowing them to understand each other's capabilities and status. This information can be used for group collaboration management, such as coordinator selection, task assignment, or report sharing. Such information can include: WTRU capabilities, such as band support, RAT support, antenna / beam support, measurement capabilities, etc., are any information related to how the device can perform measurements and cell search on the SSB.

[0186] WTRU category, for example, if the WTRU is a special type of WTRU (e.g., Non-Terrestrial Network (NTN), Reduced Capability (RedCap), Ultra-Reliable and Low-Latency Communications (URLLC), Coordinator).

[0187] The information stored by the WTRU. This indicates what the WTRU has previously found and what it can quickly find when performing cell selection based on stored information.

[0188] WTRU Battery / Energy Status. This indicates whether the device needs to conserve its energy and should avoid performing tasks. For example, whether power-saving mode is activated, power profile, and remaining battery power.

[0189] WTRU location: Spatial information (e.g., absolute or relative location, orientation, velocity) can be useful for determining proximity between devices, and therefore for determining the redundancy of their measurements.

[0190] Interconnection of WTRUs in a group: Interconnected WTRUs can easily and directly share information and update each other. Interconnection capabilities include PC5 radio interface, radio conditions, PC5 resource availability, etc.

[0191] WTRU collaboration capabilities, such as the ability to join a group or become a coordinator, or the ability to distribute or unload certain features and processes.

[0192] WTRU service types and QoS requirements, for example, what types of services need to be supported in this group for this user, and what kinds of requirements the WTRU expects to assist with for this group.

[0193] WTRU connection status with the network (within or outside coverage, RRC mode, cell / PLMN ID, etc., if applicable).

[0194] Depending on the collaboration process, information can be shared directly between users or via a coordinator using the PC5-Collab interface, between ASs (e.g., at the RRC level) or at the NAS level. This can be done during or after the establishment of the PC5 link between devices when exchanging information about device configuration or capabilities. Further information can be shared periodically or on demand between users to keep devices in the group up-to-date, such as battery status and location.

[0195] To determine the primary / coordinator user within a WTRU group, a WTRU can act as a coordinator (or manager, or primary) WTRU. This device can be responsible for coordinating the WTRUs in the group to jointly perform tasks or to perform tasks on behalf of other WTRUs in the group. The coordinator WTRU may need to have the ability to perform collaboration and strong connectivity with the WTRUs in the group.

[0196] The coordinator WTRU can also provide connectivity to the network for the WTRUs in the group (e.g., as a relay or gateway).

[0197] The process for selecting a group coordinator is described.

[0198] In one example, some devices can be dedicated to WTRU collaboration and are supplied, hard-coded, or (pre-)configured as coordinating WTRUs. These devices can be automatically selected as coordinators when included in a group or when connected to other WTRUs. For example, during capability exchange, such WTRUs can announce their capabilities and roles when establishing connections in the SL.

[0199] For example, this type of WTRU can be placed in selected locations where it is difficult for regular non-cooperative WTRUs to meet certain service requirements, such as in dense WTRU scenarios and / or to assist WTRUs and networks in providing the required services and QoS.

[0200] In one example, when a user group is configured in a collaborative communication group, the assisting WTRU can be the coordinator / master WTRU, while one or more of the assisted WTRUs can be one or more auxiliary WTRUs.

[0201] In another example, the services or applications for this group can be configured by the application layer that designates the device as the coordinator, such as the device initiating the service or a more capable device. The configuration for this group can include coordinator configuration and can be shared among users.

[0202] Figure 13 The diagram illustrates the call flow of an example of network-based coordinator WTRU selection. In another example, the network performs the selection of a coordinator WTRU for this group. Note that the WTRU can communicate with the network directly (e.g., via Uu RRC, DCI, or paging messages for IDLE / INACTIVE UEs) or via a relay.

[0203] See Figure 13 The network can request information or updates about groups and WTRUs within those groups 1301. WTRUs within the group can report their information to the network 1302.

[0204] Various information can be used to select the coordinator WTRU. Specifically, this includes the WTRU's capabilities for performing cooperative tasks, its Uu capabilities, SL capabilities, Uu link quality (e.g., Uu RSRP), SL connection status and SL RSRP to other devices in the group, hop count to other devices, services associated with the group and their QoS, the WTRU's cell ID, connection status, or PLMN ID.

[0205] Information snippets regarding WTRU configuration and settings can be obtained during connection setup or via RRC exchange. Dynamic information such as RSRP or connection status can be obtained from reports such as WTRU CSI reports or upon network-based requests.

[0206] The network selects coordinator WTRU 1303 based on the reported WTRU information.

[0207] This choice can be based on WTRU capabilities that support inter-WTRU collaboration.

[0208] WTRUs can be ranked based on a score calculated for each WTRU. The score / priority can be based on WTRU information criteria, which can be calculated directly by the network or autonomously by the WTRUs. The WTRU with the highest ranking / score / priority can be selected as the coordinator. Scores can be shared by the network or among WTRUs to find the WTRU with the highest score.

[0209] In the example, the score is based on the WTRU with the strongest Uu RSRP as the coordinator WTRU to ensure reliable communication between the network and the coordinator.

[0210] In another example, the score could be based on maximizing link quality, and minimizing the number of hops between users could be a criterion to maximize reliability and minimize latency between WTRUs.

[0211] In another example, the score could be based on the energy state of the WTRU, where low-energy devices can be avoided.

[0212] In another example, the score could be based on the number of WTRUs served by the same cell or the same PLMN.

[0213] In another example, the score could be based on the device's geographic location (absolute or relative) or speed.

[0214] The network can send an instruction 1304 to the selected WTRU informing it of its coordinator role. The network can assign cooperative tasks and configurations to the coordinator.

[0215] The network can also indicate the coordinator WTRU 1305 to other WTRUs in the group. Alternatively or additionally, the coordinator WTRU can indicate its status to the WTRUs in the group via WTRU-to-WTRU communication (e.g., using the PC5-Collab interface) 1306.

[0216] Figure 14 The diagram illustrates an example call flow for WTRU-based coordinator WTRU selection.

[0217] In this example, a coordinator WTRU is autonomously selected among the WTRUs. Communication between WTRUs can occur, for example, at the RRC level via PC5-Collab.

[0218] A WTRU (WTRU B) can request WTRU information or updates to WTRU information from other WTRUs in the group 1401. WTRUs in the group report their information to the network. Similar information can also be exchanged between WTRUs 1402 and, in the previous options, between WTRUs and the network.

[0219] During WTRU direct communication setup or packet setup, aspects of WTRU information, such as capabilities, can be exchanged; or more dynamically, such as link conditions, can be exchanged.

[0220] In parallel, WTRU selects coordinator WTRU 1403 based on the reported WTRU information. A similar sorting as previously described can also be used here.

[0221] WTRUs can share results with each other, indicating the selected WTRU and / or sorting results 1404. The selected WTRU (step 4b) can further indicate itself as a coordinator with additional cooperative configuration 1405.

[0222] When establishing the ordering of potential coordinators, WTRUs can base their computation on the same information input from other users, which may result in the same ordering. However, if the shared information is not properly synchronized (e.g., data loss, lack of connectivity, outdated information), the results may differ, and multiple WTRUs may be selected for a coordinator. In this case, and if the group is configured to support only a single coordinator, the selected coordinators can exchange their information with each other, and a limited ordering comparison is performed to select the final coordinator. The result of this convergent selection is shared with the WTRUs in the group (similar to 1404).

[0223] While the implementation of the solution focuses on selecting one coordinator for a group, it is also possible for a group to have multiple coordinators. Different coordinators in a group can handle different management tasks or handle a subset of the WTRUs in the group. An example is the case of a WTRU group for a service or application, where the WTRUs belong to different operators or are not nearby and are associated with different cells, and there may be a coordinator defined, for example, per PLMN, per cell, or based on geographical proximity.

[0224] Collaboration for measurement and cell selection and reselection This describes cooperative cell selection via commissioned measurement and / or with inter-WTRU cooperation, where the cell selection task is distributed across multiple WTRUs.

[0225] After selecting a PLMN (or SNPN), the NAS can provide a list of equivalent PLMNs (if available), which the AS can use for cell selection and cell reselection. With the help of cell selection, the WTRU can search for the strongest suitable cell in the selected PLMN or SNPN and select that cell to provide available service and monitor its control channel; that is, the WTRU can search for the cell to camp on.

[0226] Cooperative cell selection can utilize multiple devices within a group to distribute / offload a portion of the cell selection and channel scanning process. This allows different devices within the group to be responsible for a portion of the scanning work. This parallelizes and accelerates the process, as well as saving energy and processing power within the devices.

[0227] The group can perform cooperative / cooperative cell selection, meaning the entire group can select and reside on a cell; or the group can share its resources to find a suitable cell for a given user (i.e., WTRU offloads a portion of its cell search to other devices).

[0228] The following describes an example of cooperative cell selection between two devices, which can be extended to multiple cooperating devices, and the receiving device can reassemble / aggregate multiple received reports in a similar manner to that presented.

[0229] The following describes an example of the cooperative cell selection process. A similar process can also be applied to the cell reselection process (specific aspects of the cell reselection process as part of a cooperative group are described below).

[0230] Figure 15 The diagram illustrates an example call flow for the cooperative cell selection process of a WTRU with the assistance of other WTRUs.

[0231] In this example, cell selection is intended to be performed by the WTRU with the assistance of one or more WTRUs. WTRU B 1501 is the assisting WTRU and can scan cells and select the best cell for the assisted WTRU (which is WTRU A 1502). The example uses a single WTRU for assistance, but it can be generalized to the case of multiple assisting WTRUs. In one example, the process can be repeated for each WTRU.

[0232] During this process, signaling between WTRUs can be carried via the SL or any established communication interface between WTRUs (such as Wi-Fi or Bluetooth). In the case of the SL interface, cell selection is a step that can be performed before receiving network configuration. WTRUs may be required to use the SL on unlicensed frequency bands, typically using a Mode 2 resource allocation scheme. When using unlicensed frequency bands, communication between WTRUs may experience delays or congestion due to collisions and retransmissions. However, in this embodiment, timing is not necessarily a very sensitive aspect, and the process can resume after a successful transmission.

[0233] according to Figure 15 WTRU groups can exchange signaling to enable and configure cooperative cell selection 1503. WTRUs in the group can share configuration information that enables cooperative cell selection for WTRUs 1504. This configuration can be pre-provided in WTRUs, pre-configured in WTRUs, configured by the network, or through dedicated signaling exchange between WTRUs, or a combination thereof.

[0234] This configuration can include triggers and conditions for requesting cooperative cell selection. For example, the WTRU can request cooperative cell selection when its battery is low; or when the WTRU is at the cell edge; or when the WTRU failed to select a suitable cell in a previous attempt; or when the WTRU changes its cooperative group (e.g., to a new cooperating WTRU).

[0235] This configuration can include report content and criteria for selecting cells to be reported. Specific criteria can be provided so that the cells to be reported can include a set of cells that meet the measurements of the specific criteria.

[0236] Typical cell selection criteria (e.g., criterion S) commonly known in the field can be used directly.

[0237] In one example, the sub-criterions Srxlev (RX level) and Squal (cell selection quality) can be modified, for example, by adding an offset that can be configured in the system information broadcast, or by overriding it with dedicated signaling, or by applying a dedicated offset. These sub-criterions can be relaxed so that the WTRU performing the scan can report more cells (the requesting WTRU can find cells with better quality), or the sub-criterions can be tightened so that the WTRU report can include only cells with strong signals, for example, if the measuring WTRU is expected to be used jointly as an assisting WTRU with the requesting WTRU.

[0238] In another example, if, after the cell selection process, the measuring WTRU acts as the WTRU requesting assistance, then the cell is considered prohibited for use by the measuring WTRU and can be excluded from the reporting list. Even if the cell is prohibited for use by the assisting WTRU, the assisting WTRU can report the cell to the assisted WTRU only for the purpose of assisting with cell selection.

[0239] In another example, if the assistant WTRU also needs to connect to the cell (e.g., for other assistance tasks after cell selection), the assistant WTRU may be unable to report the cell because the cell is blocked.

[0240] In another option, cells deemed prohibited for requesting WTRU can be excluded from the report list.

[0241] The report can be configured to include cell ID, prohibition / reservation information, corresponding PLMN, corresponding frequency and channel, RSRP, RSRQ or RSSI value, SSB information, measurement time and location.

[0242] This configuration can include timing for process requests and responses. For example, requests can be transmitted on selected resources or at selected times for monitoring by WTRUs in a group configured to support cooperative cell selection. Scan reports can also be configured to be transmitted on selected resources or at selected times, and can also be configured to have a maximum timing requirement for sending their reports after a request is received.

[0243] This configuration may include a calculation method and parameter / offset values ​​for the cooperative cell selection criteria, which will be used by the WTRU to select cells from the cooperative cell selection process 1503.

[0244] WTRU exchanges its information and status based on the cooperative cell selection configuration 1504.

[0245] WTRUs can exchange their information during individual WTRU-WTRU connection configurations, group or cooperative configurations, or based on dedicated messages, as described above. Some of this information can be updated periodically or based on state-triggered changes, such as battery status, connectivity updates, or location updates. Therefore, note that steps 1 and 2 do not necessarily have to be performed in this order, and step 2 can be broken down into multiple exchanges.

[0246] WTRU A checks whether it is configured and enabled to perform cooperative cell selection 1505.

[0247] Cooperative cell selection can be initiated based on triggers that can be configured between WTRU and / or networks.

[0248] For example, WTRU A may request cooperative cell selection when its battery level is below a configured threshold; or when the WTRU is at the cell edge; or when it has failed to select a suitable cell in a previous attempt; or when there is a change in the WTRU cooperative group (e.g., a new assisting WTRU); or after the (cooperative) PLMN has been selected; or after the main radio receiver has been turned on.

[0249] WTRU A can determine which WTRUs can assist it and how cell selection scan tasks can be distributed among WTRUs based on the received configuration and WTRU information 1506.

[0250] In one embodiment, determining how to distribute cell selection scan tasks can be based on the available RATs of the devices, where, for example, different devices are configured to monitor different RATs, thereby avoiding having all RATs open on all devices.

[0251] In another embodiment, the determination can be based on the frequency capabilities of the devices to allocate users to their (partial) available frequencies and channels. Cell selection frequency sharing can overlap or not overlap between (or between portions of) the WTRUs in the group. Partially overlapping frequency scans can provide more diversity in scans from different devices, at the cost of increased workload.

[0252] In another embodiment, distribution can be performed based on the location (absolute or relative) of the devices. Proximity to the requesting WTRU can be a criterion for selecting devices to distribute cell scans; for example, devices may have maximum distance or even be required to be side-by-side. Alternatively, the relative distance between two other devices can also be a criterion; for example, two very close other devices may not be selected to scan the same portion of the spectrum, as they would likely be redundant.

[0253] In another embodiment, the amount of processing / monitoring to be performed by users can be prioritized by taking into account the user's processing power, power profile, and battery level (e.g., if the device is using a power-saving mode or has a battery level below a threshold).

[0254] In another embodiment, the connectivity (interface type, hop count) between the requesting WTRU and other WTRUs can be a criterion for prioritizing the distribution of scan tasks to WTRUs with low-latency / reliable connections to the requesting WTRU.

[0255] In another embodiment, the distribution of scans among devices can also be performed in the time domain, where some devices are required to perform certain scan tasks at a given time, for example, using some on / off modes, or only for a specific selected timing. In this way, devices can distribute activity time among themselves, and thus reduce power consumption.

[0256] In another embodiment, the distribution of scans between devices may also depend on the beamforming capabilities of the devices, and the WTRU may distribute the beam or direction to be scanned. For example, if two WTRUs that are nearby or side-by-side have beamforming capabilities, one WTRU may scan using a portion of the beam, while the other WTRU may scan using another portion of the beam.

[0257] The assisted WTRU can determine which other WTRUs will assist it based on the criteria mentioned above, such as WTRU role (coordinator, relay), capability, or location, and also determine the priority of these WTRUs. Prioritization can be further used when reporting conflict measurements.

[0258] Depending on the configuration and including scanning requirements, WTRU A can transmit a cooperative cell selection request 1507 to WTRU B.

[0259] The request may include the RAT, carrier, and channel to be scanned by the device, as determined in step 4.

[0260] The request may include the PLMN selected by WTRU A, and may also include an equivalent PLMN.

[0261] The request may include timing information (if any) of the spectrum scanned by the device.

[0262] The request may include beamforming information (if any) of the spectrum indicated by the device scan.

[0263] This request can indicate the maximum time or timing for the report to be transmitted.

[0264] The WTRU performs a cell scan task 1508 on its requested carrier and channel, time, and beamforming (if any).

[0265] When scanning cells on dedicated spectrum, the WTRU can find only the strongest cell and, if appropriate, select it to camp on. In the case of shared spectrum, it can search for multiple strongest cells.

[0266] Due to different channel conditions, the best cell for one WTRU may not be the best cell for another WTRU. Therefore, WTRUs that perform measurements on both dedicated and shared spectrum can measure and collect information about multiple cells.

[0267] If WTRU B is unable to perform the distributed task and report within the required time, it can send an indication of rejection. Inability can be determined by conflicting requests or processes, conflicts regarding the availability of resources sending reports, or low battery power.

[0268] WTRU B reports its cell scan results 1509 to WTRU A.

[0269] WTRU B can determine the list of cells to report based on the cooperative cell selection configuration (see step 1). As an example, based on information from WTRU A (if available at WTRU B), it reports all cells of the selected PLMN that meet the S criterion and are not prohibited for WTRU A.

[0270] Based on collaborative configuration, the report may include RSRP / RSRQ, L1 measurements, cell ID, PLMN, cell category (e.g., prohibited / reserved information), MIB information, SSB information, frequency, and timing of cell lookup.

[0271] WTRU A can use the received measurements to evaluate cell selection criteria and select cell 1510 to camp on.

[0272] To verify applicability, WTRU can examine the cell selection criteria. In the case of cooperative cell selection, typical criteria can be modified, and these criteria and their parameters can be part of the cooperative cell selection configuration. The WTRU may need to check whether the cell is prohibited from cooperating, which can be obtained from the latest known information provided by the NAS or from information provided by the assisting WTRU. If the cell is prohibited, the WTRU should not consider it appropriate. The WTRU can also check whether the cell is prohibited for the WTRU itself based on the information received.

[0273] Evaluating cell selection criteria for collaboration: When evaluating the S, Srxlev, and Squal criteria based on measurements from another user, biases can be applied by the WTRU to account for potential differences in the measurements the WTRU will experience. These biases can be one or more offsets added to the definitions of Srxlev and Squal. Note that, alternatively, offsets can be applied to the measurements themselves rather than the criteria.

[0274] Offset determination can be based on (pre)configuration, for example, given by the network or exchanged between WTRUs, and can be determined by the WTRUs based on WTRU information exchange and measurement reports, as follows (note that the following are non-limiting and can be applied in combination): Distance-based offset: This offset can be determined based on the distance between cooperating WTRUs. Several offset values ​​can be configured and selected based on a configured distance threshold. Typically, a 0dB offset will apply if the WTRUs are co-located, 3dB may apply when the distance is below a first distance threshold, 5dB may apply when the distance is between the first and second distance thresholds, and so on. These values ​​are non-limiting examples. Note that the distance metric can be replaced by evaluating the path loss between the WTRUs. Connectivity can be used to estimate the co-location / distance aspect, for example, in long-range wireless versus very short-range wireless / wired systems.

[0275] Capability-based offset: This offset can be determined based on the differences in the selected capabilities between the WTRUs. If the assisting WTRU uses beamforming with 4 RX antennas, while the assisted WTRU only has 2 RX antennas for beamforming, the offset can be configured to 3 dB. Possible combinations of beam capabilities / antenna numbers are configured by the WTRUs based on exchanged WTRU information and then selected.

[0276] Role-based offset: This offset can be determined by the role of the cooperating WTRU in the group, such as whether the WTRU is a coordinator, relay / gateway, or master WTRU. This offset can be set to prioritize group WTRUs with that cooperating WTRU.

[0277] Based on measurement delay: This offset can be determined based on the time between the measured value indicated by the measurement report and the evaluation. For example, if the delay is below a first threshold, no offset is applied; if it is between the first and second thresholds, a 3dB offset is applied, and so on.

[0278] If the selected cell has not been scanned by WTRU A (most recent), it can first verify that the cell exists and is suitable before camping on it.

[0279] WTRU A can report the selected cell 1511 to WTRU B. This report can include cell information (cell ID, frequency, RAT, RSRP, etc.). WTRU B may also consider reselecting to that cell as part of cooperation, if it is configured to do so, or based on some reselection trigger. This reporting can be performed if WTRU B is the coordinator, or if WTRU B is configured to receive this report.

[0280] WTRU A can, for example, report the selected cell 1512 to the network during the NAS / location registration process, indicating that a selection has been performed using cooperative selection (along with associated parameters and cooperative WTRU ID / information). This allows the network to keep track of cooperation between users, send cooperation-specific parameters (e.g., via SIB), and update user configurations based on the cooperation. For example, the network can configure paging timing for cooperative WTRUs, send cooperation-specific parameters to both the assisted WTRU and the assisting WTRU, etc.

[0281] Step 10 (1512) can be performed before step 9 (1511).

[0282] The WTRU can camp on the selected cell 1513 and can begin monitoring control channels, such as to receive SIB and paging messages.

[0283] Regarding the processing of measurements from multiple assisting WTRUs, note that even if the steps are described for WTRU B assisting WTRU A, WTRU A may select multiple WTRU Bs for cell scan allocation (e.g., such that each WTRU has a different scan assignment, or multiple WTRUs will perform overlapping assignments to obtain redundancy and reliability of the cooperative results). Steps 5 (1507) through 7 (1509) can be applied to each of these WTRUs. In step 8 (1510), WTRU A may select a cell by comparing the received measurements, or it may determine the cell selection based on grouping criteria.

[0284] When multiple WTRUs report different measurements for a given cell, the assisted WTRU can use a list of determined WTRU priorities to select measurements for evaluation (i.e., using measurements from the highest priority WTRU). Alternatively, it can be (pre-)configured to select their worst, best, or average measurements.

[0285] In one embodiment, the WTRU can evaluate received measurements from cooperating WTRUs and filter out inappropriate measurements or cells; then, for each remaining cell / frequency measurement, including the offset, it can compare which cell is strongest at each frequency based on multiple measurements; it can then select a cell, for example, the cell with the strongest RSRP (with offset) measurement. In cases where multiple measurements are similar (e.g., within a (pre)configured RSRP margin), the WTRU can sort the strongest cells based on a determined WTRU priority list and select the cell measured by the highest priority WTRU.

[0286] In another embodiment, cell selection can be based on group behavior, i.e., not necessarily on the strongest RSRP cell (with bias), but on cells that will help the WTRU as part of a cooperative group. Various approaches to group behavior can be considered.

[0287] As an example, if the cell with the strongest RSRP is one measured by only a single cooperating WTRU, but another cell is deemed suitable by several WTRUs in the group (or, for example, if the cooperating WTRU is already serving that cell), then the WTRUs can select that cell and consider it more reliable as part of the WTRU group. While several criteria can be used to determine which cell to prioritize based on the number of WTRUs, a simple approach is to select the cell with the strongest RSRP value measured by a majority of the WTRUs in the group.

[0288] As another example, a WTRU can select a cell that best satisfies another WTRU in the group. A WTRU can be (pre-)configured to select a cell to follow a specific WTRU's selection / measurement value. The specific WTRU can be a group coordinator, relay / gateway, or master WTRU, and WTRUs in the group can benefit from being served by the same cell. In that case, a WTRU receiving multiple measurements can prioritize the cell with the strongest RSRP value received by that WTRU, for example, when both cell options are satisfied.

[0289] This method of handling multiple received measurements can be applied not only to cell selection, but also to the solutions for PLMN selection and cell reselection processes described in this paper.

[0290] like Figure 15As shown in the example, the assisted WTRU can initiate cooperative cell selection. It can receive cooperative cell selection configuration and information about the capabilities and status of other WTRUs, such as their carrier support, battery level, and location. The WTRU can check its ability to perform cooperative cell selection based on this configuration and its own status. The WTRU can determine how other WTRUs share time, frequency, and channel cell selection scans based on the received WTRU information and configurations (such as their locations). The WTRU can transmit time and frequency information about the carriers and channels it must perform cell scans to other WTRUs. After receiving reports from other WTRUs, the WTRU can select a cell to camp on based on its measurements and the reported measurements, using cell selection criteria regarding biased RSRP / RSRQ measurements and thresholds, evaluated using a bias depending on the location (e.g., if not co-located) and / or capabilities of the assisting WTRU. The WTRU can further report the selected cell to the assisting WTRUs and to the network. Finally, the WTRU can camp on the selected cell.

[0291] like Figure 15 As shown, in one example, the assisting WTRU can perform cooperative cell selection. It can receive cooperative cell selection configuration and information about the requesting WTRU. The WTRU receives a request from another WTRU to perform cooperative cell selection, which specifies the frequency, time, and beam for cell scanning and reporting. If the WTRU is unable to perform the requested task and / or report in a timely manner, it can send a notification of rejection of the request. Otherwise, the WTRU scans the requested time / frequency portion, uses the configuration and request to determine a set of cells to report, e.g., cells with the requested PLMN, and reports it using the configured / indicated resources. As part of the cooperation, the WTRU can receive instructions about the selected cells and store this information.

[0292] Figure 16 The diagram illustrates an example call flow for the cooperative cell selection process of a WTRU utilizing a coordinator WTRU.

[0293] In cases where the WTRU is in a group managed by a coordinator and may be performing cooperative cell selection, the cooperative cell selection process may include a coordinator that receives requests and determines the distribution of tasks.

[0294] 1601 and 1602 are similar to the previous ones. Figure 15 In 1503 and 1504, however, the WTRUs can exchange configuration and WTRU information through a coordinator, which collects information and forwards it to the WTRUs in the group.

[0295] Additional / alternative instructions can be exchanged to configure the coordinator's role, ID, and resources.

[0296] 1603 is similar to Figure 15 1505 in the middle.

[0297] In step 1604, the WTRU sends a request to the coordinator WTRU for the cooperative cell selection process.

[0298] The request may include the desired carrier, RAT, and PLMN to be considered during the process.

[0299] 1605 is similar to Figure 15 1506 in the middle, but executed by the coordinator WTRU.

[0300] 1606 is similar to Figure 15 In the case of WTRU 1507, however, the request is sent from the coordinator WTRU side to other WTRUs in the group. Based on the connection state and collaboration configuration between WTRUs, the task request may include the destination of the report, such as the requested WTRU or coordinator information (ID, resource used for reporting).

[0301] 1607 is similar to Figure 15 1608 in the middle.

[0302] In 1608, the WTRU reports to the requesting WTRU or the coordinator based on the configuration information or WTRU information received in 1606. When a report is received from some WTRUs, the coordinator WRU forwards one or more of the reports to the requesting WTRU.

[0303] 1609 is similar to Figure 15 1510 in the middle.

[0304] 1610 is similar to Figure 15 In cell 1511, WTRU sends the selected cell to the coordinator.

[0305] 1611 is similar to Figure 15 1512 in the middle.

[0306] 1612 is similar to Figure 15 1513 in the middle.

[0307] Alternatively, the coordinating WTRU can be a WTRU that performs the selection decision, and it can report centrally. In 1608, the WTRU can report measurements to the coordinating WTRU. The coordinating WTRU can then perform 1609, 1610 (reporting to the assisted WTRU), and 1611.

[0308] Regarding embodiments of the coordinator, in one embodiment, the coordinator WTRU can receive cooperative cell selection configurations and information about the capabilities and status of other WTRUs, such as their carrier support, battery level, and location. The coordinator WTRU can receive cooperative cell selection requests from WTRUs in the group, which include carriers of interest, RATs, and PLMNs. Based on the received WTRU information and configurations, such as their location and battery status, the coordinator WTRU can select and determine how the WTRUs share cell selection scans in the carrier, frequency, and time domain.

[0309] WTRUs can transmit to selected WTRUs the time and frequency information of the carriers and channels for which they must perform cell scanning, as well as the request WTRU ID for reporting.

[0310] The coordinating WTRU can receive reports from other WTRUs (e.g., those not directly connected to the requesting WTRU). The coordinating WTRU can aggregate the received reports and transmit them to the requesting WTRU. As part of the collaboration, the coordinating WTRU can further receive selected cells. Alternatively, the group can be configured to send its reports to the coordinator before sending them to the requesting WTRU, which aggregates the data and can also perform cell selection.

[0311] Regarding embodiments of the requesting / assisted WTRU, in one embodiment, the WTRU can initiate cooperative cell selection. It first receives a cooperative cell selection configuration and information about the capabilities and status of other WTRUs, such as their carrier support, battery level, and location. The WTRU can then check its ability to perform cooperative cell selection based on this configuration and its own status. The WTRU can then send a cooperative cell selection request to the coordinator, indicating the desired RAT, PLMN, and carrier.

[0312] The WTRU can receive requests from the coordinator WTRU to perform part of the cooperative cell selection process.

[0313] After receiving a report from the coordinator, the WTRU can select a cell to camp on based on its measurements and the reported measurements. It can then further report the selected cell to the coordinator. Alternatively, if the coordinator is configured to perform this decision, the WTRU can receive the cell selection result from the coordinator. The WTRU can then select and camp on the selected cell.

[0314] Cooperative cell selection by a WTRU is a process in which a WTRU can select a cell with the assistance of other WTRUs. In this case, each WTRU in the group can select its own cell. There are occasions where it is desirable for WTRUs in the group to select the same cell (i.e., camp on the same cell). In this case, a single cell can be selected. This is called group cell selection.

[0315] Figure 17 The diagram illustrates an example call flow for the packet and cooperative cell selection process using the coordinator WTRU.

[0316] Grouping and cooperative cell selection can be intended for / performed by a group of WTRUs. As a grouping selection process, this can be centralized within the coordinating WTRU. The coordinating WTRU can be one of the WTRUs within the group itself.

[0317] The coordinator WTRU can request group cell selection, where multiple WTRUs perform group and cooperative cell selection. For example, when a group of WTRUs is configured to be served by the same cell, the coordinator WTRU can be used to perform selection for that group, aggregating measurements to select the best cell for the entire group.

[0318] See Figure 17 WTRU groups can exchange information to enable and configure group and cooperative cell selection 1701.

[0319] In addition, (pre)configuration may include criteria for triggering group cell selection, such as when setting up a coordinating group, when selecting (reselecting) a coordinator, when a WTRU joins or leaves a group, or when triggered by a service / application / higher-level request.

[0320] In addition, the configuration may include grouping and cooperating cell selection criteria and parameters, such as priority criteria or offset criteria (see step 7).

[0321] WTRU can exchange its information and status based on the cooperative cell selection configuration 1702.

[0322] The coordinator WTRU can trigger group cell selection and determine how cell selection should be distributed within the group.

[0323] Triggers can be based on becoming the coordinator of a group that is not connected; the WTRU being selected as the coordinator of a group; or the WTRU joining or leaving a group.

[0324] Group cell selection can be triggered by the WTRU in the requesting coordinator's group to perform (group) cell selection. If the group is configured to use a common cell and both the coordinator and the user are capable of group selection, the coordinator can perform group cell selection; otherwise, it reverts to cooperative cell selection. Figure 16 The process described in the text.

[0325] The coordinator WTRU can use distance and WTRU spatial distribution for group cell selection. For example, when selecting cells for a group, WTRUs may be located in different places. The distance between WTRUs can be considered as having a minimum threshold for selecting WTRUs to scan, thus avoiding duplicate / redundant measurements. For example, co-located WTRUs can orthogonally split the task.

[0326] WTRUs with special roles / capabilities (such as coordinators, relays / gateways, high-power or high-level WTRUs) can be considered to perform more tasks than other WTRUs (such as RedCap, IoT, low-power devices).

[0327] Depending on the configuration and including scanning requirements, the coordinator can transmit a cooperative cell selection request 1704 to the WTRUs in the group.

[0328] WTRU can perform cell scanning task 1705.

[0329] The WTRU can report its cell scan results (1706) to the coordinator. This report can follow the configuration of distributed group cell selection.

[0330] For example, the WTRU can select all suitable cells to report and can further report a list of cells that were measured but not suitable (e.g., due to PBCH decoding failure, or because the cell is prohibited from use by the WTRU).

[0331] The coordinator can aggregate measurements and information from cell reports to select the cell to reside in for the group 1707.

[0332] The coordinator can exclude any cells that are prohibited or disabled from further selection of measurements or reports.

[0333] The prohibited, reserved, or disabled status can be group-specific, for example, using a new "prohibited" indication defined and signaled in the MIB or SIB1 (e.g., "cellBarredGroups" IE type: "prohibited" or "not prohibited"), where the prohibition indication targets collaboration between groups or users. When present and set to "prohibited," the WTRU configured to treat the cell as prohibited in the collaboration group.

[0334] It is prohibited to base decisions on device group ID or type (e.g., redcap devices).

[0335] Based on WTRU information (e.g., category) and reported prohibition / reservation configurations, the prohibition, reservation, or disable status of a group can be considered when verifying whether any WTRU in a group is not allowed on a cell.

[0336] Alternatively, when verifying whether a specific WTRU in a group is not allowed, the prohibited, retained, or disabled status of the group can be considered based on WTRU information (e.g., category) and reported prohibited / retained configurations. For example, the group's coordinator, relay / gateway, or the necessary WTRUs configured.

[0337] The WTRU information received by the coordinator can lead to a downward selection of the PLMN or set of PLMNs for that group. Otherwise, if a PLMN has been selected for that group, the coordinator can use the selected PLMN (and its equivalents).

[0338] The coordinator can exclude cells whose PLMN is not in the selected PLMN or an equivalent PLMN from the selection.

[0339] The coordinator can aggregate reported measurements from WTRUs and examine the cell selection criteria and ranking of groups to select the best cell for that group.

[0340] To assess the cell quality of a link for a WTRU with an unmeasured cell, the coordinator can use measurements from other WTRUs that are close to or co-located with each other and estimate the link quality. For example, a WTRU with an unmeasured cell can be considered as having used measurements from another nearby (or co-located) WTRU, thus adding an offset to account for potential differences in link quality. The offset can be distance-dependent or based on the relationship between other shared measurements of the cells from the two WTRUs.

[0341] The (pre)configuration of the group cell selection criteria can be used to select the cell that best meets the coordinator's requirements. The coordinator is the key WTRU of the group, and its network connectivity is crucial for ensuring communication between the network and the group's management equipment. Therefore, in this configuration, measurements from the coordinator or from devices near the coordinator can be considered to have higher priority. Cells that maximize the coordinator's RSRP / RSRQ or WTRUs located nearby can be selected.

[0342] The (pre)configuration of the cell selection criteria for a group can aim to select the cell that best satisfies the relay's requirements. If present, the relay / gateway to the network is also crucial for group connectivity. In this configuration, measurements from the relay or from devices near the relay can be considered to have higher priority. Cells that maximize the relay's RSRP / RSRQ or its nearest WTRU can be selected.

[0343] The (pre)configuration of grouped cell selection criteria can aim to select the maximum number of cells that best satisfy the WTRUs. The coordinator can select cells that maximize the number of WTRUs satisfying the S criterion. Sub-criters Srxlev (RX level) and Squal (cell selection quality) can also be used with offsets from additional configurations to relax the constraints on cell selection.

[0344] The (pre)configuration of group cell selection criteria can aim to select the cell that best minimizes the number of connection hops to that cell within the group. For example, the coordinator can use WTRU inter-connection information and assume that users will need to meet the S criterion to be served by the cell to select the cell that minimizes the number of hops from the user to the network within the group.

[0345] When selecting cells for a WTRU group, it may be possible that no single cell meets all WTRU or group requirements. This could be in situations where the group is physically dispersed and no single cell covers all users. In such cases, the coordinator may, for example, split the WTRU group into subgroups based on the WTRU's location and attempt to perform group selection for each subgroup.

[0346] The coordinator can report the selected cell 1708 to the group.

[0347] The coordinator can report the results of the cooperative cell selection (including WTRUs in the group) to the network 1709.

[0348] The WTRUs in this group can reside on the selected cell 1710.

[0349] Regarding the coordinator implementation, in one embodiment, the coordinator WTRU may first receive group and cooperative cell selection configurations, as well as information about the capabilities and status of other WTRUs, such as their carrier support, battery level, and location.

[0350] The coordinator WTRU can select and determine how WTRUs share carriers, frequencies, and cell selection scans in the time domain based on received WTRU information and configurations such as their location, battery status, and carrier / RAT capabilities.

[0351] The coordinator WTRU can transmit the PLMN, time, and frequency information of the carrier and channel for which they must perform cell scanning to the selected WTRUs.

[0352] The coordinator WTRU can aggregate received reports and select cells for the group; that is, based on the received reports, it selects the cell that maximizes the number of users who will meet its S criterion. The coordinator can split the group into subgroups and select a cell for each subgroup. The coordinator can send information about the selected cell to the WTRUs in the group.

[0353] The first WTRU can receive capability and configuration information from one or more WTRUs. The first WTRU can select a second WTRU from one or more WTRUs for measurement cooperation. The first WTRU can send a measurement cooperation request to the second WTRU. The first WTRU can receive a measurement report from the second WTRU containing measurement values ​​from one or more cells. The first WTRU can determine the cell quality and suitability of one or more cells. This determination can be based on offset values. The first WTRU can select cells from one or more cells based on the determined cell quality and suitability. The first WTRU can reside on the selected cell.

[0354] Collaborative PLMN solution selection.

[0355] Upon request from the NAS, the AS can perform a search for available PLMNs and report them to the NAS. The WTRU can scan all RF channels in the NR band (considering the 3GPP NR RAT) to find available PLMNs and available CAGs. On each carrier, the WTRU searches for the strongest cell and reads its system information to determine which PLMN(s) that cell belongs to and any associated CAG(s).

[0356] PLMNs of NR cells whose RSRP is measured above a threshold (e.g., -110 dBm) can be reported to NAS as high-quality cells. NR cells whose RSRP is below the threshold but whose PLMN is still decoded from the cell's system information can also be reported, along with their RSRPs.

[0357] PLMN selection can be performed when the WTRU turns on its radio module, but it can also be performed periodically if the selected PLMN is not the highest priority PLMN (e.g., not the home PLMN). If a higher priority PLMN that meets the high-quality criteria is found, the higher priority PLMN can be reselected by the NAS layer. In this context, cooperation between WTRUs using sidechains can be accomplished using unlicensed or licensed frequency bands (because the WTRU has a sidechain network configuration on the attached cell).

[0358] Cooperative PLMN selection can utilize multiple devices within a group to distribute / offload a portion of the PLMN selection and channel scanning process. Different devices within the group can be responsible for a portion of the scanning work. This allows for parallelization and acceleration of the process, as well as savings in energy and device processing power.

[0359] Collaborative PLMN selection can be performed for groups, i.e., a group can select a PLMN and a list of equivalent PLMNs; or WTRUs in a group can share their resources to assist a given user in finding one or more PLMNs (i.e., WTRUs can offload some aspects of their PLMN search to other devices).

[0360] As a non-limiting example, the solution can describe the selection of a collaborative PLMN between two devices. The solution can be extended to multiple collaborating devices, and the receiving device can use a similar process to reassemble / aggregate multiple received reports.

[0361] For WTRUs operating in SNPN access mode, the described solution can also be used to perform SNPN selection.

[0362] Cooperative PLMN selection may be intended to be performed by a group of WTRUs that assist one of the WTRUs in the group in performing the tasks of scanning cells and selecting cells for that WTRU.

[0363] During this process, signaling between WTRUs can be carried through the SL or any established communication interface between WTRUs (such as Wi-Fi or Bluetooth). This is not the case for the SL, because PLMN selection is a step that can be performed before receiving network configuration, so WTRUs may be required to use the SL on unlicensed frequency bands, typically using a Mode 2 resource allocation scheme. When using unlicensed frequency bands, communication between WTRUs may experience delays or congestion due to collisions and retransmissions. However, timing is not necessarily a very sensitive aspect in this process, and the process can resume after a successful transmission.

[0364] In cases where PLMN selection (reselection) is performed as part of a routine check of higher-priority PLMN availability, the WTRU may already have a network configuration and be able to use SL on the licensed frequency band.

[0365] Figure 18 The diagram illustrates an example call flow for the collaborative PLMN selection process of WTRUs with the assistance of other WTRUs.

[0366] WTRU groups can exchange signaling to enable and configure cooperative PLMN selection 1801. WTRUs in the group can share a configuration that enables cooperative PLMN selection for WTRUs. This configuration can be pre-configured or shared using dedicated signaling between WTRUs (e.g., using PC5-Collab).

[0367] The (pre)configuration can include triggers and conditions for requesting cooperative PLMN selection. For example, a WTRU can request cooperative PLMN selection when its battery is low; or when the WTRU is at the cell edge or failed to find a PLMN in a previous attempt; or when there is a change in the WTRU cooperative group (e.g., a new assisting WTRU). The (pre)configuration can include parameters or offsets to be used in the reporting and selection phases. The (pre)configuration can include report content and criteria for selecting the PLMN to be reported. The PLMN to be reported can include a set of high-quality PLMNs and other found PLMNs. The report can be configured to include the PLMN, the corresponding cell ID, the corresponding frequency and channel, RSRP, RSRQ or RSSI values, SSB information, and the time and location of the measurement. Depending on the distance and co-location of the devices, the (pre)configuration can include criteria and parameters for treating the PLMN as high-quality, such as offsets from high-quality measurements from another device.

[0368] WTRUs can exchange their information and status based on the cooperative PLMN selection configuration (1802). WTRUs can exchange their information, for example, during individual WTRU-WTRU connection configurations, group or cooperative configurations, or on dedicated messages. Some of the information can be updated periodically or based on state-triggered changes, such as battery status, connectivity updates, and location updates. (1801 and 1802 do not necessarily follow this order.) Furthermore, (1802) can be split into multiple exchanges.

[0369] WTRU A can verify whether it is configured and enabled to perform cooperative PLMN selection 1803. For example, WTRU A can request cooperative PLMN selection when its battery is low; or when the WTRU is at the cell edge or has failed to find a high-quality PLMN in previous attempts; or when there is a change in the WTRU cooperative group (e.g., a new assisting WTRU). Triggering of PLMN selection may include when the WTRU turns on its Uu radio module, or when the selected PLMN is not the highest priority PLMN, in which case a new selection attempt is periodically performed. Cooperative activation can be requested for periodic (e.g., periodic) cooperative measurements, or as independent cooperative activity. Periodic cooperative activity can be stopped when the WTRU successfully selects its highest priority PLMN.

[0370] WTRU A can select and determine which WTRUs will assist it and how to distribute PLMN selection scan tasks among WTRUs 1804. This determination can be based on received configuration and WTRU information. It can also be based on the available RATs for the devices, where different devices are configured to monitor different RATs, thus avoiding all devices activating all RATs.

[0371] Based on the configuration and including scan requirements, WTRU A can transmit a cooperative PLMN selection request 1805 to WTRU B. This transmission can use the PC5-Collab interface, optionally using a link dedicated to cooperation. Communication between the NAS layers of WTRUs; or between the NAS and AS layers of WTRUs; or between the AS layers of WTRUs, can be performed, for example, via the newly defined PC5-Collab interface or using the existing PC5-S, at the RRC level (PC5-RRC), MAC level (PC5-MAC), or PHY level (PC5-PHY).

[0372] As defined in 1804, the request may include the RAT, carrier, and channel to be scanned by the device. The request may include a list of PLMNs to be considered with higher priority or to be reported. The request may include timing information (if any) of the spectrum indicated by the device scan. The request may include beamforming information (if any) of the spectrum indicated by the device scan. The request may indicate the maximum time or opportunity for the report to be transmitted.

[0373] WTRU B can perform a PLMN scan task 1806 on its requested carrier and channel, time, and beamforming (if applicable). If WTRU B is unable to perform the distributed task and report within the requested time, it can send an indication to reject the request. Inability can be determined by conflicting requests or processes, conflicts regarding the availability of resources for sending reports, or low battery power.

[0374] WTRU B can report discovered PLMNs to WTRU A 1807. This transmission can use the PC5-Collab interface to communicate between WTRUs' NAS layers; or between WTRUs' NAS and AS layers; or directly between AS layers (e.g., at the RRC level). WTRU B can determine the list of PLMNs to report based on a distributed PLMN selection configuration 1801. As an example, a WTRU can be configured to report all PLMNs that meet high-quality criteria, and can also report PLMNs with lower quality along with their corresponding measurements. High-quality PLMNs can also be reported along with their signal strength, so that other WTRUs can have better information to evaluate measurements when WTRUs share discovered PLMNs. The report content can be based on a cooperative PLMN selection configuration, and may include, for example, the PLMN, the corresponding cell ID, the corresponding frequency and channel, RSRP, RSRQ or RSSI values, SSB information, and the time and location of the measurement.

[0375] The WTRU Access Layer (AS) can report measurements to the NAS layer for PLMN selection 1808. The WTRU's AS layer reports detected PLMNs (including high-quality PLMNs and those that are not high-quality but were detected) along with their corresponding measurements to the NAS. The WTRU may have already received reports from other WTRUs at the AS layer and will aggregate them before reporting to the NAS for selection. The WTRU may have already received reports from other WTRUs at the NAS layer and will aggregate them at the NAS before selecting the PLMN.

[0376] The high-quality criteria for measurements reported by the assisted WTRU can be changed for the selected collaborative PLMN. The RSRP of measurements performed by the assisted WTRU for evaluating the high-quality criteria can be modified with bias, for example, based on offsets in WTRU capability, location, and connectivity.

[0377] In one embodiment, a PLMN measured by another WTRU at a frequency not yet scanned by the assisted WTRU can be added to the list of found PLMNs. Additional indication that the measurement originated from another device in the group can be added.

[0378] In one embodiment, if a high-quality PLMN has been found at a frequency that has been scanned by the assisted WTRU, but the assisted WTRU does not measure it as high-quality, or if the assisted WTRU does not find the PLMN, the assisted WTRU may add it to the list of PLMNs with an additional indication that the measurement value comes from another device in the group.

[0379] The decision to select a PLMN can be based on an aggregation of measurements from the device itself and reported measurements. For example, if a nearby WTRU measures a PLMN on a carrier that the WTRU is not scanning, and that PLMN and / or carrier has a higher priority than the PLMN and / or carrier that the WTRU would select without reporting measurements, the WTRU can attempt to select that PLMN, or first verify the link quality using received PLMN information (e.g., frequency, cell ID, timing, etc.) before selecting it.

[0380] WTRU A may report the selected PLMN (including PLMN ID, frequency, RAT) to WTRU B as part of the collaboration 1809.

[0381] For example, during NAS registration, WTRU can report the cooperative PLMN selection to network 1810, indicating the cooperative configuration and group members.

[0382] Note that multiple WTRUs B can be selected by WTRU A for PLMN scan distribution. Steps 1805 to 18077 can then be applied to each of these WTRUs. Step 1808 can involve combining or comparing multiple measurements received from different WTRUs.

[0383] A WTRU can be assisted by another WTRU to perform cooperative PLMN selection. A WTRU can initiate cooperative PLMN selection. It can first receive the cooperative cell selection configuration and information about the capabilities and status of other WTRUs, such as their RAT and carrier support, battery level, and location. The WTRU can check its ability to perform cooperative cell selection based on this configuration and its own status. The WTRU can determine how other users in the group can share RAT, frequency, and channel PLMN selection scans based on received user information (such as WTRU location) and the configuration. The WTRU can transmit the time and frequency information of the carriers and channels for which it must perform cell scans to other WTRUs. After receiving feedback from other WTRUs, the WTRU can select a PLMN based on its measurements and shared measurements, for example, selecting a PLMN scanned by another WTRU scanning different carriers. The WTRU can report the selected PLMN to the assisting WTRU.

[0384] A WTRU can assist another WTRU in performing cooperative PLMN selection. The WTRU may initially receive the cooperative PLMN selection configuration and information about the requesting WTRU. The WTRU may receive a request from the other WTRU to perform cooperative cell selection, specifying the RAT, frequency, time, and beam for PLMN scanning and reporting. If the WTRU is unable to perform the requested task and / or report in a timely manner, it may send a notification of rejection. Otherwise, the WTRU may scan the requested time / frequency portion, use the configuration and request to determine a set of PLMNs to report on, e.g., PLMNs with high-quality measurements, and report on them using the configured / indicated resources. As part of the cooperation, the WTRU may receive the PLMNs selected by the assisted WTRU and may store this information.

[0385] Figure 19 The diagram illustrates an example call flow for a collaborative PLMN selection process initiated by a WTRU (WTRU coordinator).

[0386] In this example, the assisted WTRU (WTRU A) can initiate a cooperative PLMN selection. It can first receive the cooperative PLMN selection configuration from the coordinator 1901. The coordinator can also share information about the capabilities and status of other WTRUs, such as their RAT and carrier support, battery level, and location 1902. This process is similar to that for... Figure 18The process described here, except that information is propagated through the coordinator WTRU, involves the coordinator receiving information and forwarding it to one or more WTRUs within the group. Additional / alternative instructions can be exchanged to configure the coordinator's role, ID, and resources.

[0387] The assisted WTRU can verify its ability to perform cooperative PLMN selection 1903 based on its configuration and its own state. The assisted WTRU can determine how other users in the group can share the PLMN selection scan for RAT, frequency, and channel based on received user information (such as WTRU location) and configuration. The assisted WTRU can transmit a request to the coordinating WTRU to perform cooperative PLMN selection 1904. This request may include the desired RAT, carrier frequency, and channel that can be considered in the process.

[0388] For example, WTRUs can share the time and frequency information of carriers and channels that they must perform cell scans with the coordinating WTRU. This can be shared via the coordinating WTRU when the assisted WTRU sends a request for cooperative PLMN selection to the coordinator.

[0389] The coordinator WTRU can determine task assignment 1905. The coordinator WTRU can schedule the task using WTRUs 1906. All WTRUs, including the coordinator WTRU and assisted WTRUs, can be assigned tasks for cooperative PLMN selection. Task requests can include the destination of the report, for example, requesting WTRU or coordinator information (ID, resources for reporting), which can be based on the connection status and configuration between WTRUs.

[0390] The WTRU can perform the requested task 1907. The WTRU can report the results to the assisted WTRU directly or via the coordinating WTRU 1908. The results may include PLMN information and measurement results from one or more PLMNs.

[0391] Upon receiving feedback from other WTRUs, the assisted WTRU can select PLMN 1909 based on its own measurements and measurements shared from other WTRUs. The assisted WTRU can select a PLMN scanned by another WTRU, which may have scanned different carriers. The assisted WTRU can report the selected PLMN 1910 to the coordinator, which can then report it to the assisted WTRU. The assisted WTRU can also report the selected PLMN 1911 to the network. The assisted WTRU can perform its own cell selection based on the selected PLMN, or it can trigger a cooperative cell selection process.

[0392] Alternatively, the WTRU can be configured to send its measurement reports to the coordinator, and the PLMN selection is performed on the coordinator WTRU side, which can report the selected PLMN to the requesting WTRU.

[0393] The assisting WTRU (which assists the assisted WTRU) can perform cooperative PLMN selection. It can first receive the cooperative PLMN selection configuration and information about the assisted WTRU. The assisting WTRU can receive a request from another WTRU to perform cooperative cell selection, indicating the RAT, frequency, time, and beam for PLMN scanning and reporting. If the assisting WTRU is unable to perform the requested task and / or report in a timely manner, it can send a notification of rejection of the request. Otherwise, the assisting WTRU can scan the channel in the requested time / frequency, use the configuration and request to determine one or more PLMNs to report to, for example, PLMNs with high-quality measurements, and report the PLMN using the configured / indicated resources. This report can be sent directly to the assisted WTRU or via the coordinating WTRU. As part of the cooperation, the assisted WTRU can receive and store the PLMN information selected by the assisted WTRU.

[0394] After the assisted WTRU reports measurement value 1908, as described above, PLMN selection can be performed by the assisted WTRU or by the coordinating WTRU.

[0395] In one embodiment, a WTRU can initiate cooperative PLMN selection. WTRUs in the group may first exchange cooperative PLMN selection configurations with the coordinating WTRU. WTRUs in the group also exchange information with the coordinating WTRU about their capabilities and status, such as their RAT and carrier support, battery level, and location. The coordinating WTRU can receive requests for cooperative cell selection from the assisted WTRUs. Based on the received WTRU information and configurations, such as WTRU location and battery status, the coordinating WTRU can select and determine how WTRUs share PLMN selection scans in the carrier, frequency, and time domain. The coordinating WTRU can send a distributed PLMN selection request to one or more WTRUs in the group, the request including the carrier, RAT, and PLMN of interest.

[0396] WTRUs can transmit to selected WTRUs the RAT, time, and frequency information of the carriers and channels for which they must perform PLMN scans, as well as the request WTRU ID for reporting.

[0397] The coordinating WTRU can receive reports from other WTRUs, such as those not directly connected to the requesting WTRU. The coordinating WTRU can aggregate the received reports and transmit them to the assisted WTRUs. The coordinator can receive and store instructions regarding the PLMN selected by the assisted WTRUs. Alternatively, all WTRUs in the group can be configured to send their reports to the coordinator, which aggregates the data before sending reports to the requesting WTRU and can also perform PLMN selection.

[0398] Similar to cell selection, grouped and cooperative PLMN selection can be used, allowing all WTRUs to select and use the same PLMN. The coordinating WTRU can perform grouped cooperative PLMN selection. The coordinating WTRU can be used to distribute PLMN selection scans to the group, aggregating measurements to select the PLMN for that group.

[0399] For example, when a service requires avoiding roaming or requires the WTRU to be served by the same cell, the group can be configured to select the same PLMN or be located on an equivalent PLMN.

[0400] This can refer to a situation where multiple devices of a given user are grouped together, and that user typically has a network subscription.

[0401] Figure 20 The diagram illustrates an example call flow for grouping and cooperating PLMN selection using the coordinator WTRU.

[0402] WTRU groups can exchange information to enable and configure group collaboration PLMN selection 2001. (Pre-)configuration can include criteria for triggering group PLMN selection, such as when setting up a collaboration group, when selecting (reselecting) a coordinator, when a WTRU joins or leaves a group, or when triggered by a service / application / higher-level request. (Pre-)configuration can include group and collaboration PLMN selection criteria and parameters, such as priority or offset criteria.

[0403] WTRUs can exchange their information and status based on the cooperative PLMN selection configuration. WTRU information may also include a list of preferred PLMNs or PLMN priorities of the WTRU (e.g., a list based on the home PLMN (HPLMN) or equivalent HPLMMN (EHPLMN)).

[0404] The coordinator WTRU can aggregate a list of priorities from PLMNs within the WTRU and determine the priority of PLMNs in that group. The (pre)configuration of grouped PLMN selection criteria can aim to select PLMNs as follows: 1. Best to satisfy the coordinator: The coordinator is the critical WTRU of the group, and its network connectivity is important for ensuring communication between the network and the group's management devices. Therefore, in this configuration, the coordinator's PLMN priority (list) can be used as the group's priority (list).

[0405] 2. Optimize trunking: In one example, the trunks / gateways to the network are also critical to the group's connectivity. Therefore, in this configuration, the PLMN priorities (list) of the trunks / gateways can be used as the priorities (list) for the group.

[0406] 3. The maximum number of WTRUs to be satisfied. In one example, the coordinator can define the PLMN priority of a group, which can be based on the PLMN priority of a user. It uses a sorted PLMN for each user and establishes a new sort. For example, the PLMN with the highest priority is the highest priority PLMN of the users in the group or the PLMN that appears most often among the equivalent PLMNs.

[0407] After determining the list of group priorities, the coordinator can send this priority list to users so they can use it to monitor the PLMN and share it with their NAS.

[0408] The coordinator WTRU can trigger the group PLMN selection and determine how cell selection should be distributed within the group (2003).

[0409] Triggers can be based on becoming the coordinator of a group that is not connected; the WTRU being selected as the coordinator of a group; or the WTRU joining or leaving the group.

[0410] Group PLMN selection can be triggered by WTRUs in a group that can request the coordinator to perform both group and cooperative PLMN selection. If the group is configured to use a common PLMN and both the coordinator and users are able to perform group selection, the coordinator can perform both group and cooperative PLMN selection; otherwise, it can revert to cooperative PLMN selection.

[0411] In addition to the parameters used in cooperative PLMN selection, the coordinator WTRU can use distance and WTRU spatial distribution in different ways for group PLMN selection to select and determine the distribution of WTRUs and PLMN scan tasks for that group. For example, when selecting a PLMN for a group, the WTRUs may be in different locations. The distance between WTRUs can be considered as having a minimum threshold for selecting WTRUs for scanning to avoid duplicate / redundant measurements. For example, juxtaposed WTRUs can orthogonally split the tasks.

[0412] WTRUs with special roles / capabilities (such as coordinators, relays / gateways, high-power or high-level WTRUs) can be considered to perform more tasks than other WTRUs (such as RedCap, IoT, low-power devices).

[0413] Depending on the configuration and including scan requirements, the coordinator can transmit a group and cooperative PLMN selection request 2004 to the WTRUs in the group.

[0414] WTRU can perform PLMN scan tasks 2005.

[0415] Similar to Figure 17 As in step 8, WTRU can report its PLMN scan results to the coordinator.

[0416] The coordinator can aggregate measurements and PLMN reports to select a list of PLMNs and equivalent PLMNs for the group (2007).

[0417] The coordinator can aggregate measurements from reports from WTRU and examine grouped PLMN selection criteria and rankings to select a PLMN and equivalent PLMN for that group.

[0418] To evaluate the PLMN quality criteria of a link for a WTRU without a measured carrier, the coordinator can use measurements from other WTRUs that are close to or co-located with each other and estimate the link quality. For example, a WTRU without a measured PLMN can be considered as having used measurements from another nearby (or co-located) WTRU, thus adding an offset to account for potential differences in link quality. The offset can be distance-dependent or based on the relationship between cells of other common measurements from the two WTRUs.

[0419] The (pre)configuration of grouped PLMN selection criteria can aim to select the following PLMNs: 1. Best to satisfy the coordinator: In this configuration, measurements from the coordinator or from devices near the coordinator can be considered to have higher priority. For example, a PLMN scanned by the coordinator at high quality can be selected with higher priority; or 2. Optimize relay performance: In this configuration, measurements from the relay or from devices near the relay can be considered to have higher priority. For example, a PLMN scanned by the relay with high quality can be selected with higher priority; or 3. Maximum number of WTRUs that meet the high-quality criteria: The coordinator can choose to maximize the number of WTRUs that meet the high-quality criteria and support the PLMN on the carrier where the PLMN is located.

[0420] When selecting a PLMN for a WTRU group, there may not be a single PLMN that meets all WTRU or group requirements. This could be, for example, in situations where some of these devices are carrier-incompatible with other devices. In such cases, the coordinator may, for example, split the WTRU group into subgroups based on the WTRU's location / compatibility and attempt to perform group selection for each subgroup.

[0421] The coordinator can report PLMN selection 2008 to the group.

[0422] The WTRU in the group selects the PLMN and triggers cell selection 2009.

[0423] The coordinator reports the cooperative PLMN selection to the network in 2010.

[0424] The coordinating WTRU can first receive group and cooperative PLMN selection configurations and information, capabilities, and statuses from the assisted WTRUs, such as their RAT, carrier support, battery level, location, and PLMN priority. The coordinating WTRU can receive cooperative PLMN selection requests from WTRUs in the group, which include the carrier, RAT, and PLMN of interest. Alternatively, grouping and cooperative PLMN selection can be initiated by the coordinating WTRU itself (e.g., from an internal request from the NAS, AS, or application layer). Based on the received WTRU information and configurations, such as the WTRU's location and battery status, the coordinating WTRU can select and determine how the WTRUs share the PLMN selection scan across the carrier, frequency, and time domain.

[0425] The assisted WTRU can transmit the RAT, time, and frequency information of the carriers and channels for which it must perform a PLMN scan to the selected WTRU. Optionally, the coordinating WTRU can transmit the RAT, time, and frequency information of the carriers and channels for which it must perform a PLMN scan to the selected WTRU. Optionally, it can be a combination of both, depending on the location of the WTRU and the direct channel quality.

[0426] The coordinator WTRU can aggregate received reports and select a PLMN for the group. For example, it can prioritize PLMNs for the group based on WTRU PLMN priorities and use extrapolated measurements between devices to select the PLMNs that the maximum number of WTRUs would consider high-quality. The coordinator can split the group into subgroups and select a PLMN for each subgroup. The coordinator can then send the selected PLMN to the WTRUs in the group.

[0427] In addition to all the collaboration schemes discussed so far, the configuration and determination of collaboration task distribution can also be performed in a semi-static / periodic manner. In this case, the device can avoid selecting (reselecting) collaboration requests for each PLMN. For example, the device may be required to periodically check for potentially higher PLMN bands available for use.

[0428] This configuration and task distribution can instruct the periodic execution of collaborative and timed instructions (where necessary). This timing can be determined by the requesting / assisted WTRU or based on (pre)configuration, such as following an existing timer that will run simultaneously at all collaborating devices. Other devices can then perform collaborative distributed tasks on behalf of another device without prior requests (e.g., periodically) or activation / trigger requests (e.g., short message instructions). The WTRU then reports its measurements to the device that initially requested them.

[0429] The timing configuration for periodic checks can be distributed across different devices (e.g., different devices can perform measurements corresponding to different scan times; for example, round-robin and / or periodic measurements between devices can be split across different devices for different parts of the spectrum).

[0430] When camped on a cell, the WTRU can perform cell reselection, where the goal may be to change the selected cell to a cell on a higher priority frequency and / or a cell with stronger signal quality.

[0431] Issues related to collaborating with WTRUs for cell reselection and packet reselection may include: How to perform cooperative / aggregated cell reselection and utilize other WTRU measurements.

[0432] How to prioritize cells / frequency in the group so that the group is on the same cell, and also avoid reselecting a cell after selecting one based on cooperation / aggregation (e.g., due to biased criteria).

[0433] Regarding group-specific priority list processing, in this embodiment, reselection is based on frequency / cell priority. Different rules and criteria are applied to measurement and triggering based on the relative priority between the already selected cell frequency and other frequencies.

[0434] The priority list can be modified to prioritize WTRUs in a group (e.g., through collaboration or aggregation) to remain in the same cell / frequency.

[0435] In an embodiment, the WTRU can receive a cell reselection priority list, "cellReselectionPriority," for frequencies from other WTRUs in the group. Alternatively, the priority list can be obtained from the network and can be dedicated to that group or WTRU (e.g., via RRC, the priority list can be the same for all WTRUs in the group). A group-specific frequency priority list can replace, for example, a common priority list received via SI. Using a group-specific priority list allows WTRUs in the group to share a common understanding of priorities and apply the same rules, which can be beneficial for regrouping WTRUs in the group toward the same frequencies. Furthermore, cells that support or are dedicated to that WTRU group can also be considered as the highest priority cells by the WTRU.

[0436] The frequency priority list may include the frequencies that the group should use with the highest priority, such as frequencies that the group supports or that are dedicated to the cells of the WTRU group.

[0437] In another embodiment, using the received frequency priority list as a baseline, the WTRU can update the frequency priority list to treat frequencies reported as selected or reported as high priority by other WTRUs in the group as the highest priority cells.

[0438] Cells that support or are dedicated to this WTRU group can also be considered as the highest priority cells by the WTRU.

[0439] When a WTRU updates its frequency priority list, it can report the list to other WTRUs in the group and to the network, as it receives the list from other WTRUs or includes the frequencies of cells serving the WTRU.

[0440] Group-specific frequency list priorities can be used for cell reselection measurement rules to determine the frequencies on which in-frequency or inter-frequency measurements should be performed.

[0441] Regarding the collaborative triggering of cell reselection, under normal circumstances, the WTRU can perform its own cell reselection measurements and can use the cell reselection measurement rules to evaluate the serving cell.

[0442] In the context of aggregation or collaboration, the measurement of the serving cell of a WTRU can be delegated to other WTRUs.

[0443] In this embodiment, serving cell measurements can be triggered by the assisted WTRU, and the assisted WTRU can receive measurement reports. Serving cell measurements can be requested on demand or configured for periodic measurement. Upon receiving a report, the assisted WTRU can evaluate the reselection rules and resume the reselection process.

[0444] In another embodiment, the WTRU being assisted can delegate its reselection evaluation and triggering to the assisting WTRU. In this case, the assisted WTRU can indicate to the assisting WTRU their current serving cells (e.g., cell ID, frequency, RAT) and their frequency priority list. Then, the assisting WTRU can monitor the serving cells and evaluate the measurement rules for reselection of the frequencies in the priority list for the assisted WTRU. When the serving cell measurement is below the reselection threshold, the assisting WTRU can report the reselection threshold to the assisted WTRU.

[0445] Alternatively, the assisted WTRU can indicate the threshold instead of its priority list, and the assisting WTRU compares the measurement with the threshold to trigger a reselection indication. The threshold can be determined by the assisted WTRU based on its priority list, configuration, and optionally the location of the WTRU.

[0446] The report can include the triggering of reselection and the measurement of the serving cell (e.g., RSRP / RSRQ), and then, the assisted WTRU shall determine the frequencies for performing reselection measurements based on its priority list; The report can include the triggering of reselection, the measurement of the serving cell (e.g., RSRP / RSRQ), and a list of frequencies for which reselection measurements are to be performed, which the assisting WTRU receives based on the priority list.

[0447] The assisted WTRU can perform reselection measurements on the indicated frequencies.

[0448] To determine the list of frequencies to measure for reselection, the WTRU can evaluate its serving cell measurements according to the criteria of different frequency priorities.

[0449] To prioritize users in a group in the same cell or frequency, the WTRU can determine an offset for the comparison of Srxlev with the threshold.

[0450] Different values of the offset can be selected and configured for the WTRU.

[0451] When it is determined that the conditions are met, three offsets can be added to the criteria such that the WTRU can perform intra-frequency measurements.

[0452] When the serving cell of the WTRU is the serving cell of the group, the offset can be used for the intra-frequency criteria. It may be preferred that all WTRUs have the same serving cell. In this case, the offset can be aimed at making the criteria for triggering measurements more difficult to pass. For example, an offset can be added to the Srxlev condition: Srxlev < SintrasearchP - Offset1, where Offset1 is given in the configuration (e.g., 3dB).

[0453] When the serving cell of the WTRU is not the serving cell of the group but the group is served at that frequency, the offset can be used for the intra-frequency criterion. The offset can be designed to make the criterion for triggering reselection easier to pass. For example, Srxlev < SintrasearchP + Offset2, where Offset2 is given in the configuration (e.g., 3 dB).

[0454] The offset can also be used to evaluate the inter-frequency rules for the frequency serving the group. For example, to evaluate, for example, Srxlev < SintersearchP + Offset3, where Offset3 is given in the configuration (e.g., 3 dB). This method can be used when the frequency of the group has not been set to the highest priority.

[0455] The offset can be different or the same. In the case of intra-frequency, an offset can be added to avoid searching / handoff frequencies too frequently. The WTRU can prioritize scanning other cells in its frequency, i.e., attempting to reselect to the same cell. For inter-frequency, the WTRU prioritizes staying on the same frequency and does not scan other frequencies. The network can configure the offset according to system conditions.

[0456] The offset can be based on configuration and can also be based on the cooperation / group status. For example, in cases where independent measurement values, cooperative measurement values, or aggregated measurement values are used to select (reselect) the serving cell, the offset may be different. Different values can be configured and selected by the WTRU, or alternatively, the network provides the offset based on the measurement type reported by the WTRU.

[0457] In the context of reselection, the measurements performed on the serving cell and other potential cells / frequencies can be carried out using a similar process as described above for cooperative or aggregated measurements, and additional measurement thresholds or biases can be considered when determining whether a measurement can be performed.

[0458] Regarding the reselection criteria and ranking for the group, after measuring the cells on the list of frequencies for reselection, the WTRU can select a cell based on the reselection criteria.

[0459] To prioritize users of the group in the same cell or frequency, the WTRU can determine the offsets applicable to different frequencies / cells based on whether the group is served by that frequency / cell. The list of offsets can be based on the configuration received by the WTRU.

[0460] For example: It is known that generally, if the following conditions are met, an adjacent cell on a higher priority frequency can be selected: Squal > Thresh_(X, HighQ) or Srxlev > Thresh_(X, HighQ).

[0461] The criterion with offset can be: Squal > Thresh_(X, HighQ) + OffsetGroup_HighQ or Srxlev > Thresh_(X, HighP) + OffsetGroup_HighP. If a neighboring cell is serving the group, a new criterion can be used.

[0462] It is known that, under normal circumstances, if the conditions Squal > Thresh_(X, LowQ) or Srxlev > Thresh_(X, LowP) are met, cells on lower priority frequencies can be selected. Criteria with offsets can be: Squal > Thresh_(X, LowQ) + OffsetGroup_LowQ or Srxlev > Thresh_(X, LowP) + OffsetGroup_LowP. New criteria can be used to serve cells in this group.

[0463] For cells that are in the same frequency or have the same priority as the serving cell, the order of cells serving this group can be biased using the following formula: Rs = Qmeas,s + Qhyst – Qoffsettemp + Qoffsetgroup, if the serving cell is serving the group.

[0464] Rn = Qmeas,n - Qoffset – Qoffsettemp + Qoffsetgroup, if a neighboring cell is serving this group.

[0465] Rs can be used to rank serving cells, Rn can be used to rank neighboring cells, and Qhyst can be a hysteresis offset, which can be used to avoid changing cells too easily. WTRU can select the cell with the highest ranking R. WTRU can be biased to select one of those cells by adding Qoffsetgroup only to the cells serving that group.

[0466] Offsets can be based on configuration and / or on cooperation / group status. For example, the offset may differ in cases where independent, cooperative, or aggregated measurements are used to select (reselect) the serving cell. Different values ​​can be configured and selected by the WTRU, or alternatively, the network can provide the offset based on the type of measurement reported by the WTRU.

[0467] In the context of reselection, it is possible to perform measurements on the serving cell and other potential cells / frequencys using a process similar to that described above for cooperative or aggregated measurements, and to apply additional measurement / threshold biases to account for measurements not performed locally.

[0468] In one example, for cooperative cell / PLMN selection, the WTRU can use another WTRU measurement to make its cell / PLMN selection. This includes two aspects: Delegating measurements to other WTRUs on their behalf for cell or PLMN selection involves assigning tasks, requesting, receiving, and using measurements from another WTRU.

[0469] The received measurements and criteria may be biased to account for measurement uncertainties and differences between devices.

[0470] Figure 21 The diagram illustrates a flowchart of an example method for performing cooperative cell / PLMN selection.

[0471] The WTRU can be compatible and configured to receive WTRU information from a cooperating WTRU, as well as configuration from a network or from other WTRUs (e.g., using SL unlicensed, Wi-Fi, or Bluetooth)2101.

[0472] WTRU information and status may include, for example, WTRU capabilities, location, battery level information, interconnection capabilities such as PC5 radio interface, radio conditions, PC5 resource availability, etc.

[0473] WTRU configuration can include collaboration triggers (e.g., based on coverage, energy level), collaboration / aggregation-specific thresholds and parameters (e.g., RSRP / RSRQ offsets). WTRU can determine the distribution of measurement tasks (e.g., RATs and frequencies to be scanned) to assisting devices based on WTRU information (e.g., its capabilities) and priorities between assisting devices.2103

[0474] The WTRU can transmit cooperation requests to the appropriate equipment, including distributed measurement information (e.g., RAT, frequency, time, and beam) for cell or PLMN selection. Based on this configuration, transmission timing and format are used, for example, using an unlicensed frequency band 2103.

[0475] The WTRU can receive cooperative measurement reports (e.g., RSRP and cell ID) from other devices. Alternatively, it can receive indications of cooperative failure and readjust distribution.

[0476] The WTRU can be biased to evaluate the received measurement 2105, taking into account accuracy / capability differences and the WTRU's position after self-measurement delay. For example: because the WTRU is not juxtaposed and is configured based on the received offset, a 3dB offset is added; because the WTRU has a lower RX antenna capability than the assisting WTRU, a 3dB offset is added based on the received offset configuration. The WTRU can be configured with an offset, or the accuracy can be estimated and the offset offset determined based on the estimated accuracy.

[0477] WTRU can use the received measurements and, based on collaboration-specific criteria and determined biases, evaluate cell suitability and / or PLMN high-quality criteria 2106.

[0478] The bias can be applied as an offset to Srxlev / Squal or the high-quality threshold. Alternatively, the bias can be applied to the measurement rather than the criterion.

[0479] Based on the information in the report, a WTRU can refuse to use a cell that is prohibited from being used for collaboration or for use by a WTRU being assisted.

[0480] When multiple WTRU measurements are received, the WTRU can use a determined list of assistance priorities to select a cell or PLMN for similar measurements. Alternatively, it can use group selection criteria, such as selecting the cell / PLMN with the strongest measurement for most WTRUs.

[0481] WTRUs can reside in selected cells and validate their applicability through self-measurement and information gathering.

[0482] The WTRU can transmit selected cell information (e.g., cell ID, RAT, frequency) or PLMN (e.g., frequency, PLMN ID, RAT) to the cooperating WTRU (i.e., the requesting WTRU). Measurements can be added to report 2107.

[0483] The WTRU can transmit the selected cell / PLMN indication and cooperation information (e.g., group ID, cooperation WTRUID) to the network, and include offsets / biases used during the evaluation, for example, through the registration process 2108.

[0484] The WTRU can begin monitoring the control channel, for example, to receive paging / SIB messages.

[0485] At any time, a WTRU can receive an indication of collaboration failure from the assisting WTRUs. If there is only one assisting WTRU, or if all assisting WTRUs indicate collaboration failure 2109, the WTRU can restart the process 2110 and select a new WTRU to replace the failed WTRU.

[0486] Regarding cooperative reselection triggering, WTRU can rely on groups (e.g., cooperation) to measure the selected cell and report a reselection trigger when the cell measurement value is below a threshold.

[0487] WTRU can: Transmit a request for cooperative measurements of the serving cell (e.g., including cell ID and frequency) for cooperative cell reselection to another WTRU.

[0488] The received indication requires a report of cell reselection, including measured quantities (e.g., RSRP / RSRQ). Based on the frequency priority list and the received measurements, determine the frequency on which to perform the reselection measurement.

[0489] Offsets can be added to intra-frequency and inter-frequency criteria to account for collaborative measurements.

[0490] Trigger reselection measurements at a defined frequency. Measurements can be obtained by the device itself, performed collaboratively, or aggregated.

[0491] Alternatively, WTRU can: Receive or determine a frequency priority list.

[0492] Transmit a request (e.g., including cell ID and frequency) for cooperative measurements of the serving cell used for cooperative cell reselection to the assisting WTRU, and indicate a cell / frequency priority list to the assisting WTRU.

[0493] The report indicating that reselection is required includes the frequency to be measured and the quantity to be measured (e.g., RSRP / RSRQ), where: This indication can be a list of frequencies, for example, a list of transmission frequency priorities.

[0494] This indication can be a frequency category (e.g., only higher priority frequencies, higher priority + within frequencies, or all frequencies).

[0495] Trigger a reselection measurement at the indicated frequency. The measurement value can be obtained by the device itself, or performed collaboratively, or considered as aggregated.

[0496] The paragraphs above provide examples of implementing collaboration functionality, and in Figures 6 to 12 This is explained in the document. Other implementations are possible.

[0497] Figure 22 The illustration shows an example of a control plane protocol stack implementation that collaborates via the Uu interface.

[0498] In this scenario, the WTRU can communicate with the network using the Uu interface 2201 to send requests and reports supporting the cooperative function; the network can then coordinate the delivery of such requests and reports to the associated WTRUs in the group. This functionality can be implemented as part of the existing RRC layer 2202 or via a new cooperative layer 2203.

[0499] As another example, the collaboration layer of each WTRU can communicate with the collaboration layers of other WTRUs via the side link port (PC5).

[0500] Figure 23 The illustration shows an example of a control plane protocol stack implementation that collaborates via the PC5 interface.

[0501] This example is similar to Figure 7 The model presented in the example shows that the WTRU collaboration layer 2301 can communicate with each other via the PC5-Collab interface through the side link port 2302.

[0502] In one example, the PC5-Collab interface could be a newly defined dedicated interface used to support collaboration functionality. In another example, the collaboration layer could utilize the existing PC5-RRC interface and communicate using, for example, SL RRC messages. In yet another example, the collaboration layer could utilize the existing PC5-MAC interface and communicate using, for example, MAC control elements (MAC-CE). In yet another example, the collaboration layer could utilize the existing PC5-PHY interface and communicate using, for example, sidechain control messages (SCI). In yet another example, communication between collaboration layers could be performed using a newly defined PC5-Collab interface. The PC5-Collab interface could be a dedicated interface with defined dedicated message sending and receiving capabilities. The PC5-Collab interface could have dedicated links and SRBs for exchanging collaboration information.

[0503] Since the cooperation layer 2301 can support processes running in the access layer (AS) 2303 of the WTRU, such as cell selection and cell reselection, the WTRU cooperation layer 2301 can communicate with the WTRU AS 2303, receiving requests from the WTRU AS via internal interface 2304 and providing results to it. The cooperation layer 2301 can obtain the information required by the WTRU AS 2303 from the sidechain stack 2305. The cooperation layer can communicate with the WTRU sidechain via internal interface 2306. Because the cooperation layer 2301 can also support NAS procedures, it can interface with the NAS layer 2307 via internal interface 2308. Then, the WTRU's sidechain interface 2302 can be used to send requests to other WTRUs and receive results from other WTRUs.

[0504] Figure 24 An embodiment of the cooperative cell selection process for a first WTRU is illustrated. The first WTRU can be configured to communicate among a group of multiple WTRUs in close proximity to each other. The first WTRU can receive capability and configuration information associated with measurement cooperation 2401 from one or more WTRUs in the group. The first WTRU can send a measurement cooperation request to a second WTRU 2402. The first WTRU can receive measurement results from a group of cells from the second WTRU, wherein the measurement results for each cell in the group include at least one of Reference Signal Received Power (RSRP) or Reference Signal Received Quality (RSRQ) 2403. The first WTRU can select a cell from the group of cells, wherein the selection is based on cell reselection criteria, and wherein the cell reselection criteria are based at least on the received measurement results and one or more cell reselection offsets 2404. The first WTRU can report the selected cell to the network 2405.

[0505] Regarding cell reselection and group-specific reselection priority handling and measurement rules, WTRU adjusts the frequency priority list based on the group and uses the list to determine the frequencies to be scanned for cell reselection using offsets, and uses offsets to prioritize the frequencies / cells used by the group.

[0506] During cell selection or reselection processes, WTRUs within a WTRU group may consider information associated with that group, such as the group's serving frequency, serving cells, or frequency priority. Details regarding the processing of measurements for cell selection and reselection, as well as PLMN selection, by WTRUs within the group are discussed in detail. Criteria for cell selection, cell reselection, and PLMN selection to be used by WTRUs within a group are described in detail. Bias is introduced into the processes and criteria based on information associated with the WTRU group.

[0507] This includes two aspects: 1) changing the priority list of frequencies used for reselection to prioritize the frequencies selected by the WTRUs in the group, and 2) applying a bias to the measurement rules to determine which frequency should be measured.

[0508] Figure 25 The diagram illustrates an example of cell selection and reselection measurements performed by WTRUs within a group.

[0509] A WTRU can reside on a cell. A WTRU can be part of a group. A WTRU can receive a list of frequency priorities for cell reselection from another WTRU in the group, as well as one or more cells and frequencies (2501) selected by the WTRUs in the group. Alternatively, it can be sent from the network or from the coordinator WTRU.

[0510] The WTRU can update the frequency priority list 2502 used for cell reselection based on the received information. For updating, the WTRU can consider the priority of each frequency to be measured and compare it with the priority of the frequencies in the current (serving) cell. Frequencies that support or are dedicated to the WTRU group can be considered to have a higher priority than the serving frequencies. Frequencies selected by or from the WTRUs in that group can also be considered to have a higher priority than the serving frequencies. All other frequencies can be considered to have a lower priority than the serving frequencies.

[0511] The MIB / SIB may contain indications of whether a cell supports (e.g., is not prohibited from) a group of cooperative WTRUs. Some cells can be dedicated to supporting cooperative WTRUs. When selecting WTRUs for cells, the frequencies of these higher-priority cells can be considered.

[0512] WTRU can report the frequency priority list used to the network and to the WTRUs in the group 2503.

[0513] The WTRU can obtain measurements 2504 of the serving cell. These measurements can be generated by the WTRU itself or received from other WTRUs in the group. Based on the obtained serving cell measurements, the WTRU can evaluate the serving cell measurements 2501 according to intra- and inter-frequency selection criteria and a previously determined list of frequency priorities. Based on this evaluation, the WTRU can select the frequency 2505 on which to perform the measurements for cell reselection purposes.

[0514] For frequency 2506, which has a higher priority than the service frequency, WTRU can select all frequencies with a higher priority than the service frequency to trigger a reselection measurement.

[0515] For frequency 2507 which has a lower priority than the serving frequency, if the serving cell conditions Srxlev < SnonIntraSearchP or Squal < SnonIntraSearchQ 2508 are met, the WTRU may select all frequencies with a lower priority.

[0516] For intra-frequency measurements 2509, if the serving frequency 2510 is not used in the set, then if the serving cell conditions Srxlev < SIntraSearchP or Squal < SIntraSearchQ 2511 are met, the WTRU may select to measure that frequency. If the serving frequency 2512 is being used in the set, the WTRU may apply an offset to bias the measurement conditions for cell reselection based on whether the set is using the same serving cell as the WTRU. In the case where the current cell is also the serving cell of the set, this may bias the WTRU to remain in the current serving cell. In the other case, if the current serving cell is not the serving cell of the set, it may bias the WTRU to consider reselection to another cell.

[0517] If all other WTRUs in the set are not served by the same cell, the conditions may be relaxed to take into account other factors such as the number (or percentage) of WTRUs in the same serving cell, or the distance of other WTRUs from the current WTRU, the WTRU speed, or other factors used to trigger condition determination.

[0518] As an example, as described above, if the set is served by the same serving cell 2513, or if other predefined conditions are met, the WTRU may verify whether the serving cell criteria Srxlev < SIntraSearchP - Offset1 or Squal < SIntraSearchQ – Offset1 are met, where Offset1 is a positive value in dB 2514. If this condition for the serving cell is met, measurements of other cells in the same frequency may be triggered. The new criteria make it less likely for this condition to be met, and correspondingly, it may be more likely that the WTRU will not trigger measurements and will remain in the same cell.

[0519] If the group is served by different cells 2515, the WTRU can verify whether the serving cell criteria Srxlev < SIntraSearchP + Offset2 or Squal < SIntraSearchQ + Offset2 are met, where Offset2 is a positive value (in dB) 2516. For example, Offset1 = 3dB, Srxlev < SIntraSearchP + 3; this makes it more likely that the condition is met and, correspondingly, perhaps more likely that the WTRU triggers inter-cell measurements. If this condition for the serving cell is met, measurements on other cells in different frequencies can be triggered.

[0520] The offset value can be configured by RRC or pre-provisioned, or exchanged by the WTRU via the PC5-Collab interface.

[0521] Once the frequency 2517 for reselection measurements is selected, the WTRU can perform reselection measurements 2518 on the selected frequency.

[0522] After performing the measurements, in the case of cell reselection, the WTRU can decide whether to reselect to another cell. The WTRU can use cell selection and reselection criteria as well as cell ranking to determine which cell to camp on.

[0523] Figure 26 A flowchart illustrating an example of cell selection and reselection criteria used by a WTRU in a group.

[0524] The WTRU can receive a configuration that indicates the offsets for inter-frequency (not intra-frequency) and intra-frequency reselection regarding cells in the group.

[0525] The WTRU can receive an indication of the (one or more) cells and (one or more) frequencies that can be selected by the UEs in the group from a WTRU in the group (or from the network).

[0526] As Figure 25 shown, the WTRU can perform measurements for cell reselection. The WTRU can use a selection bias to select a cell.

[0527]

[0527] Based on the measurement results 2601, the WTRU can use the bias to verify the reselection criteria.

[0528] Let F_S be the frequency of the serving cell of the WTRU, and F_G be the frequency of the cell serving the WTRU in the group. Let P_S be the priority of the frequency (F_S) of the serving cell of the WTRU, and P_G be the priority of the frequency (F_G) of the cell serving the WTRU in the group.

[0529] The WTRU is designed to select the measurement cell with the highest priority frequency. Therefore, for each of the measured cells, starting with the measurement cell with the highest priority frequency, the WTRU can verify whether the cell reselection criteria are met.

[0530] WTRU can begin evaluating a cell with the highest priority frequency.

[0531] Starting with the highest priority frequency 2602, the WTRU evaluates all cells in that frequency 2603. The WTRU can then verify whether a measurement cell is serving the WTRU in that group 2604.

[0532] For the measurement cell serving the WTRU in this group, the WTRU can verify whether the measurement cell meets criterion 2605 with bias: Criterion A: Squal>Thresh_(X, HighQ) - OffsetGroup_HighQ or Srxlev>Thresh_(X,HighP) - OffsetGroup_HighP.

[0533] If the criteria are met, the WTRU can select a measurement cell. If more than one measurement cell meets the criteria, the WTRU can rank the measurement cells. Rn = Qmeas,n - Qoffset – Qoffsettemp, and select the cell with the highest sorting, 2606.

[0534] If the measurement cell does not serve a WTRU in the group, the WTRU can verify whether the measurement cell meets the criteria without bias: Criterion B: Squal>Thresh_(X, HighQ) or Srxlev>Thresh_(X, HighP) 2607.

[0535] If so, the cell for measurement meets the reselection criteria, and the WTRU can select that cell. If more than one cell meets the criteria, the WTRU can rank the cells: Rn = Qmeas,n - Qoffset – Qoffsettemp, and select the cell with the highest sorting, 2605.

[0536] WTRU can report selected cells to the group.

[0537] WTRU can report selected cells to the network.

[0538] WTRU can reside on a selected cell (e.g., to monitor and control information, such as broadcast and paging information).

[0539] Figure 27 An embodiment of the described solution is illustrated. A first WTRU may be in a group of WTRUs. The first WTRU may determine one or more frequencies to be measured 2701. The first WTRU may send a request 2702 for a measurement for cell selection or reselection to a second WTRU in the group. The request may include at least one frequency from the one or more frequencies to be measured. The first WTRU may then receive first measurement results from a group of cells from the second WTRU 2703. The measurement results may include the RSRP and RSRQ of each reported cell. The first WTRU may select a cell from the group of cells 2704. This selection may be based on cell selection criteria. The criteria may be based at least on the first measurement results received from the second WTRU and the group offset offset. The selection criteria may also depend on measurement results generated at the first WTRU. The WTRUs in the group may maintain a list of frequencies and their priorities. The WTRUs may periodically or on triggers or requests to exchange the priority list. The WTRUs may update the list based on exchange information they can receive from other WTRUs in the group. The selection criteria may further depend on frequency priorities according to the latest (updated) priority list. The selection criteria may also be based on cell sorting. Cells can be ranked based on ranking criteria, and the cell with the highest priority frequency and the highest-ranked cell within that frequency can be selected. The WTRU can camp on the selected cell and begin monitoring its control channels. Control channels can include broadcast channels and paging channels.

[0540] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and 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 internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROMs and Digital Universal Discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for selecting a cell during a cell selection or reselection procedure, the method performed by a first wireless transmit / receive unit (WTRU), the method comprising: determining, at the first WTRU, one or more frequencies to measure; sending a request for measurements for cell selection or reselection to a second WTRU in a group of WTRUs, wherein the request includes at least one frequency from the one or more frequencies to measure; receiving, from the second WTRU, first measurement results for a set of cells; selecting, at the first WTRU, a first cell from the set of cells, wherein the selection is based on cell selection criteria, wherein the cell selection criteria is based on at least the first measurement results and a first set of bias offsets; camping on the first cell and monitoring a control channel in the first cell. The first set of bias offsets biases the selection of cells operating on a same frequency as a frequency used in one or more cells serving the WTRUs in the group.

2. The method of claim 1, wherein, The one or more frequencies to measure included in the request for measurements is based on at least a second set of bias offsets.

3. The method of claim 1 or 2, wherein, The second set of bias offsets prioritizes one or more frequencies of one or more cells serving the WTRUs in the group.

4. The method of claim 3, wherein, The control channel includes at least a paging channel.

5. The method of any one of claims 1 to 4, wherein, The cell selection criteria is further based on second measurement results, wherein the second measurement results are generated at the first WTRU and include measurement results for one or more cells in at least one frequency from the one or more frequencies to measure.

6. The method of any one of claims 1 to 5, wherein, The cell selection criteria is further based on a cell ranking, wherein the cell ranking is based on at least a third set of bias offsets.

7. The method of any one of claims 1 to 6, wherein, 8. The method of any one of claims 1 to 7, further comprising reporting the first cell to the second WTRU. The first set of bias offsets is configured in the first WTRU based on a received RRC message.

9. The method of any one of claims 1 to 8, wherein, 10. The method of any one of claims 1 to 9, further comprising receiving, from the second WTRU, a first frequency priority, the first frequency priority including one or more frequencies and their associated priorities.

11. A first wireless transmit-receive unit (WTRU), the first WTRU comprising at least one processor and a transceiver, wherein the at least one processor and transceiver are configured to: determine, at the first WTRU, one or more frequencies to measure; send a request for measurements for cell selection or reselection to a second WTRU in a group of WTRUs, wherein the request includes at least one frequency from the one or more frequencies to measure; receive, from the second WTRU, first measurement results for a set of cells; select, at the first WTRU, a first cell from the set of cells, wherein the selection is based on cell selection criteria, wherein the cell selection criteria is based on at least the first measurement results and a first set of bias offsets; camp on the first cell and monitor a control channel in the first cell. The first set of bias offsets biases the selection of cells operating on a same frequency as a frequency used in one or more cells serving the WTRUs in the group. The one or more frequencies to measure included in the request for measurements is based on at least a second set of bias offsets.

12. The WTRU of claim 1, wherein, ​ 13. The WTRU of claims 1 or 2, wherein, ​ 14. The WTRU of claim 3, wherein, The second set of bias offsets prioritizes one or more frequencies of one or more cells in the serving cell.

15. The WTRU of any one of claims 11-14, wherein, The control channel comprises at least a paging channel.

16. The WTRU of any one of claims 1-5, wherein, The cell selection criteria are further based on a second measurement result, wherein the second measurement result is generated at the first WTRU and comprises measurement results of one or more cells in at least one frequency of the one or more frequencies to be measured.

17. The WTRU of any one of claims 1-6, wherein, The cell selection criteria are further based on a cell ranking, wherein the cell ranking is based on at least a third set of bias offsets.

18. The WTRU of any one of claims 1-7, wherein, The at least one processor and the transceiver are further configured to report the first cell to the second WTRU.

19. The WTRU of any one of claims 1-8, wherein, The first set of bias offsets is configured in the first WTRU based on the received RRC message.

20. The WTRU of any one of claims 1-9, wherein, The at least one processor and the transceiver are further configured to receive a first frequency priority from the second WTRU, the first frequency priority comprising one or more frequencies and their associated priorities.

Images