Method and apparatus for implementing WTRU cooperation and pre-processing measurement result aggregation

Abstract

The first WTRU may receive measurement configuration information and a request for reporting the pre-processed measurement results from the second WTRU. The first WTRU may determine one or more pre-processed measurement results based on the measurement configuration information. The pre-processed measurement may include at least one of a Layer 1 filtered Reference Signal Received Power (RSRP) and a Layer 1 filtered Reference Signal Received Quality (RSRQ). The first WTRU may select at least one of the one or more pre-processed measurements for transmission to the second WTRU. The first WTRU may receive an aggregated measurement result from the second WTRU in response to transmitting the pre-processed measurement result. The aggregated measurement may be a result of applying a layer 3 filter to the pre-processed measurement determined by at least the first WTRU. Layer 3 aggregation filter coefficients may be configured by RRC.

Description

Cross Reference to Related Applications

[0001] This application claims the benefit of U.S. Provisional Application 63 / 506,262, filed June 5, 2023, the contents of which are incorporated herein by reference. BACKGROUND

[0002] When a wireless transmit receive unit (WTRU) is turned on, it can search for a public land mobile network (PLMN). PLMN selection is performed at the non-access stratum (NAS) layer of the WTRU. Once a PLMN is selected, the WTRU can perform initial cell selection and search for a suitable cell in the selected PLMN. Cell selection is performed by the WTRU 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 a NAS registration procedure.

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

[0004] While camped on a cell, the WTRU can monitor the cell’s control channels to, for example, acquire system information and receive paging messages. To be discovered by the network for paging purposes, the WTRU can inform the network of its current location. When reselecting to another cell, the WTRU can perform location updating based on a change of tracking area or RAN notification area to which the new cell belongs. SUMMARY

[0005] WTRUs spend most of their time in RRC idle (IDLE) / inactive (INACTIVE) mode states, and thus, power consumption associated with IDLE and INACTIVE mode operations can have a significant impact on the WTRU’s battery life. Active sensing operations (e.g., scanning radio channels for PLMN and cell selection and reselection) during IDLE and INACTIVE modes can be one of the key sources of power consumption in these operational modes. Scanning all supported frequencies and RATs is also time consuming, which can further impact the WTRU as it can cause delays in performing PLMN and cell selection and reselection procedures.

[0006] To enable a wide variety of devices and uses, some devices (e.g., WTRUs and / or Personal IoT Network (PIN) elements) can be limited by the device’s capabilities, power, energy, or connectivity to a network. Deploying systems in which devices can cooperate and assist each other can improve the performance of the devices. These devices can form a group of interconnected WTRUs that can share their processing capabilities and communicate directly (often using wireless communications such as NR sidelink). The devices can coordinate their processes and communications to enhance each other’s performance by aggregating their capabilities (e.g., processing, power, time, functionality) and assist each other in performing tasks and processes.

[0007] One example use case can include wearable connected objects such as in extended reality (XR) and / or augmented reality (AR) / virtual reality (VR) scenarios, in which a device can offload a portion of processing (e.g., audio or video processing) to another more capable device. Another example use case can be that a WTRU can be inclined to keep its primary Uu radio link closed for a certain period of time to save power consumption. In this example, if a relay device is present in the group, the WTRU can prefer to communicate with the network via the relay while keeping its primary Uu radio link closed.

[0008] Performing measurements (including collecting measurement samples and then processing the samples) can be power consuming processes. To save power consumption, devices can utilize and perform aggregation of measurements from each other. In one example, a WTRU can perform measurement aggregation for performing cell selection, cell reselection, and / or PLMN selection. A first WTRU can be configured with parameters for measurement pre-processing, and can obtain measurement results according to the configuration with pre-processing steps. The first WTRU can share the pre-processed measurement results with a second WTRU. The second WTRU can aggregate the measurement results, for example, by summing the signal strengths of the received measurement results. BRIEF DESCRIPTION OF DRAWINGS

[0009] The application can be understood in more detail with reference to the following description and drawings wherein: Figure 1A is a diagram illustrating an example communications system, in which one or more disclosed embodiments can be implemented; Figure 1B is a system diagram illustrating an example WTRU; Figure 1C is a system diagram illustrating a RAN and CN according to an embodiment; Figure 1D is a system diagram illustrating a RAN and CN according to an embodiment; Figure 2An example of a measurement model is shown; Figure 4 An example of direct communication between WTRUs is shown; Figure 5 An example of a role in a WTRU group is shown; Figure 6 An example of a control plane protocol stack with a collaboration layer is shown; Figure 7 An example of a control plane protocol stack for collaboration using the PC5 interface is shown; Figure 8 A schematic diagram of an example control plane protocol stack for inter-WTRU assistance is shown, in which one WTRU can be controlled by two independent NAS entities; Figure 9 A schematic diagram of an example control plane protocol stack for inter-WTRU assistance is shown, in which one NAS entity can control AS entities of multiple WTRUs; Figure 10 An example of a logical interface that can be used by a technical solution is shown; Figure 11 The call flow is shown as an example of network-based WTRU coordinator selection; Figure 12 The call flow is shown as an example of coordinator selection based on WTRU; Figure 13 An example call flow for network-based aggregated WTRU selection is shown; Figure 14 The call flow is shown as an example of autonomous aggregation WTRU selection; Figure 15 An example call flow for a multi-WTRU aggregated measurement process is shown; Figure 16 The call flow is shown as an example of low-level aggregation for cell (re)selection performed by the anchor WTRU; Figure 17 The example call flow for low-level aggregation for cell (re)selection, performed by the aggregation WTRU, is shown. Figure 18 The example call flow for low-level aggregation for PLMN selection, performed by the aggregated WTRU, is shown. Figure 19 A flowchart illustrating an example of the cell / PLMN (re)selection process using estimated aggregated measurement results is shown. Figure 20 A flowchart illustrating an example of a method for low-level PHY aggregation measurement for anchor point WTRUs; Figure 21A flowchart illustrating an example of a method for low-level PHY aggregation measurement for aggregation WTRUs; Figure 22 A flowchart illustrating an example of a cell selection method using low-layer PHY measurement aggregation estimation for anchor point WTRUs is shown; and Figure 23 A flowchart illustrating an example of a measurement polymerization process is shown. 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 that provides 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 by sharing 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 DTF-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[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 should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Any of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any 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 MiFi 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 industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the wireless transmission / reception units 102a, 102b, 102c, and 102d may be interchangeably referred to as UEs.

[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 connect to at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (e.g., gNodeBs (gNBs), new radio (NR) NodeBs), site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0013] Base station 114a may be part of RAN 104, and may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. 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 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 per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use 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.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0015] More specifically, as described above, the 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, etc. 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 the air interface / 116. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0016] In one 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 LTE-A Advanced (LTE-A) and / or LTE-A Pro Advanced (LTE-A Pro) to establish air interface 116.

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

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

[0019] In other embodiments, base station 114a and wireless transmission / reception units 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA 2000, CDMA 2000 1X, CDMA 2000 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), etc.

[0020] Figure 1ABase station 114b can be, for example, a wireless router, a home NodeB, a home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. 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 one 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, CDMA 2000, GSM, 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 may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions (such as user authentication). Although in Figure 1A Although not shown, it should be understood that 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 the communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers to communicate 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 use cellular-based radio technology, and with base station 114b, which can use IEEE 802 radio technology.

[0024] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 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, etc. It is understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[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, etc. Processor 118 may perform signal decoding, 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 transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it should 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 one 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 and optical signals. It should 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 described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may use MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving 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 transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode 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 may be coupled to a speaker / microphone 124, a keyboard 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 may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from any suitable type of memory and store data in said memory, such as non-removable memory 130 and / or removable memory 132. 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 user identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 and store data in said memory (e.g., located on a server or home computer (not shown)).

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

[0031] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or alternatively to, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more neighboring base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0032] The processor 118 may also be 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, etc. 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, etc.

[0033] WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., signals associated with a specific subframe for 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 to reduce and / or substantially eliminate self-interference through hardware (e.g., chokes) or through signal processing by a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., signals associated with a specific subframe for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

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

[0035] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit 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 UL and / or DL, etc. 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 should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0038] The MME 162 can connect to each of the eNodes B162a, 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, etc. 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 handover between eNode Bs, triggering paging when DL data is available to WTRUs 102a, 102B, and 102c, managing and storing the context of WTRUs 102a, 102B, and 102c, etc.

[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 WTRU 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRU 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) or can communicate with an IP gateway that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 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] Although WTRU is Figures 1A-1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use a wired communication interface with a communication network (e.g., temporary or permanent).

[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 access or connect to a Distribution System (DS) or another type of wired / wireless network carrying traffic entering and / or leaving the BSS. Traffic originating outside the BSS destined for a STA can 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 peer-to-peer traffic. This peer-to-peer traffic can be sent between the source and destination STAs (e.g., directly between the source and destination STAs) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode cannot have access points (APs), 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 the "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 bandwidth) or dynamically configured. 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 particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[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] Very High Throughput (VHT) STAs 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; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segmented parser that divides the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0048] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may 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 support for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0049] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. 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 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment 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, then the entire available band can be considered busy even if most of the available band remains idle.

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

[0051] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR wireless technology. RAN 104 can also communicate with CN 106.

[0052] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c includes 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 one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated 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 Scalable Digital Numerology (SDN). For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for 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 varying lengths or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying lengths of absolute time).

[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 needing to access other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize 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 / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate essentially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 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 fragmentation support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, and routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. 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 data networks (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0057] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act 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., handling 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 so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 182a and 182b can provide control plane functions for handover between RAN104 and other RANs (not shown) employing 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 them to route traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

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

[0060] CN 106 can facilitate communication with other networks. For example, CN 106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 106 and PSTN 108. Furthermore, 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 may be connected to DN 185a and 185b via the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local DN 185a and 185b.

[0061] Given Figures 1A-1D and Figures 1A-1D As described herein, one or more of the functions described with respect to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can 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 laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more 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. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0063] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., tested) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices can be test equipment. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0064] When in RRC_IDLE or RRC_INACTIVE mode, a WTRU implementing 3GPP Radio Access Technologies (RATs) (including 2G, 3G, 4G, and / or 5G RATs) can perform PLMN selection, cell selection / reselection, and location registration, including tracking area update procedures. 5G equipment can also support RAN notification area (RNA) updates and operations in the RRC_INACTIVE state.

[0065] When the WTRU is activated, it selects the PLMN. For the selected PLMN, an associated RAT can be configured. Through cell selection, the WTRU can search for suitable cells within the selected PLMN, choose cells that provide available service, and monitor their control channels. The WTRU can register its presence using a NAS registration process within the tracking area of ​​the selected cell.

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

[0067] If the WTRU loses coverage of its registered PLMN, it can automatically select a new PLMN. Alternatively, the WTRU can provide the user with an indication of available PLMNs so that the user can perform a manual selection. Various control mechanisms exist in the network to prioritize cell selection to certain RATs, control the rate at which low, medium, or high mobility WTRUs perform cell reselection, and prohibit the WTRU from reselecting a selected tracking area.

[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 Earthquake and Tsunami Warning System (ETWS) or Commercial Mobile Alert System (CMAS) notifications. Furthermore, if the network needs to send control messages or transmit 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 for the WTRU on the control channels of all cells in the corresponding tracking area set. The WTRU can receive and respond to the paging messages.

[0069] The WTRU can scan all RF channels in the NR band to discover available PLMNs and 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 CAGs. For operations using shared spectrum channel access, 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 shared spectrum channel access operations, one or more PLMN identifiers from multiple strongest cells, it can report each discovered PLMN as a high-quality PLMN (but without RSRP values) and any associated CAG-IDs to the NAS, 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] Any PLMNs that do not meet high-quality standards but whose PLMN identifier can be read by the WTRU are reported to the NAS along with their corresponding RSRP value and any associated CAG-ID. The quality measurements reported to the NAS by the WTRU should be identical for each PLMN found within a cell.

[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 where the MCC and MNC identified by the PLMN are matched with the IMSI's MCC and MNC according to known matching criteria.

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

[0075] Equivalent HPLMN List: To allow for the provision of multiple HPLMN codes, PLMN codes existing 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 treated as an access to the PLMN for PLMN selection purposes.

[0076] Access PLMN: This is a PLMN that is different from HPLMN (if the EHPLMN list does not exist or is empty) or a PLMN that is 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 access a PLMN (VPLMN). There are two PLMN selection modes: In automatic mode, the WTRU can use a list of PLMN / access technology combinations in priority order, selecting the highest priority available and permissible PLMN / access technology combination. In manual mode, the WTRU can indicate to the user which PLMNs are available. The WTRU only attempts to obtain regular service on a VPLMN when the user makes a manual selection.

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

[0079] During initial cell selection, the WTRU can scan all RF channels in the NR band to discover suitable cells, based on its capabilities. At each frequency, the WTRU can search for the strongest cell (except for operations using shared spectrum channels, where the WTRU can search for one or more of the next strongest cells). Once the WTRU discovers a suitable cell, that cell can be selected.

[0080] In cell selection using stored information, the WTRU uses stored information about the frequency, 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 the RAT that should perform cell selection, for example by instructing the RAT associated with the selected PLMN, and by maintaining a list of prohibited registration areas (one or more) and a list of equivalent PLMNs.

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

[0083] For cell reselection, to limit the number of measurements the WTRU needs to perform, the WTRU first verifies that 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 reselection 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 residing in a cell, the WTRU can periodically search for better cells based on cell reselection criteria. If a better cell is found, the WTRU can reselect to that cell. A change of cell may mean a change of RAT.

[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 selection RX level (in dB) and is defined as follows: Srxlev = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) – Pcompensation – Qoffsettemp; where: Qrxlevmeas: Cell RX level (Reference Signal Received Power RSRP). Measured by WTRU.

[0087] Qrxlevmin: 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 level configured by RRC. For FR2 = 0.

[0090] Qoffsettemp: The offset temporarily applied to 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: A cell-specific offset added to the corresponding Qrxlevmin to achieve the required minimum RX level in the relevant cell. Configured by RRC.

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

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

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

[0096] Qoffsettemp: The offset temporarily applied to the cell. Configured by RRC.

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

[0098] Different rules can be applied to different priorities. In one example, if the serving cell does not satisfy Srxlev > SintraSearchP and Squal > SIntraSearchQ, the WTRU can perform in-frequency measurements. In another example, for NR inter-frequency or inter-RAT frequencies with a higher reselection priority than the current NR frequency, the WTRU can perform measurements for the higher-priority NR inter-frequency or inter-RAT frequency. In yet another example, for NR inter-frequency frequencies with a reselection priority equal to or lower than the current NR frequency, and for inter-RAT frequencies with a lower reselection priority than the current NR frequency, if the serving cell does not satisfy Srxlev > SnonIntraSearchP and Squal > SnonIntraSearchQ, the WTRU can perform measurements for NR inter-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 one second has elapsed since the WTRU camped on the current serving cell, then if a cell with higher priority NR or EUTRAN RAT / frequency satisfies `Squal > Thresh_(X, HighQ)` during the TreselectonRAT interval, cell reselection is performed on an NR frequency with higher priority than the serving frequency or on a different RAT frequency. Otherwise, if a cell with higher priority RAT / frequency satisfies `Srxlev > Thresh_(X, HighP)` during the TreselectonRAT interval, and more than one second has elapsed since the WTRU camped on the current serving cell, cell reselection is performed on an NR frequency with higher priority than the serving frequency or on a different RAT frequency.

[0100] Cell reselection to cells on NR frequencies of equal priority is based on the order of reselection of cells on the same frequency.

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

[0102] Regarding measurements used in RRC_IDLE and INACTIVE modes, WTRU can perform measurements for cell selection and reselection.

[0103] When evaluating the Srxlev and Squal of a non-serving cell for reselection purposes, the WTRU uses parameters provided by the serving cell. For the final check of cell selection criteria, the WTRU can use 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 (i.e., 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 secondary synchronization signal.

[0106] SS-RSRP can be measured only 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 certain SS / PBCH blocks for performing SS-RSRP measurements, then SS-RSRP is measured only from the set of indicated SS / PBCH blocks (one or more).

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

[0108] The secondary synchronization reference signal reception quality (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 in both the numerator and denominator will be performed on the same set of resource blocks.

[0109] Figure 2 An example of a measurement model is shown.

[0110] For measurement data processing, two types of filters can be involved: layer 1 filters and layer 3 filters. Layer 1 and layer 3 filters are applied sequentially, as described in this paper. Figure 2 As shown.

[0111] Layer 1 (L1) filtering involves processing the raw measurement samples. The type of processing can differ between devices (i.e., it is not standardized). The type of processing may include averaging samples acquired over a time period, averaging a given number of samples, or performing a moving average, etc. This filtering is performed directly on the measurement samples collected at the physical layer (i.e., Layer 1) within the device. The result is referred to as the Layer 1 filtered measurement result.

[0112] Layer 3 (L3) filtering involves processing measurement results that have been filtered by Layer 1. The device can apply Layer 3 filtering using Layer 3 filter coefficients provided by the network via RRC signaling. These coefficients can be used in equations / functions applied to the Layer 1 filtered measurement results. This result is referred to as the Layer 3 filtered measurement result. The device can report the Layer 3 filtered measurement result to the network.

[0113] Layer 3 filters can also be called RRC configuration filters.

[0114] like Figure 2 As shown, a beam-specific sample (A) can represent measurement data within physical layer 201. The beam-specific sample (A) can be the input to layer 1 filter 202. The precision of the filtering can vary depending on the implementation choice. The procedures used to perform measurements in the physical layer can vary (e.g., the input A and the layer 1 filter can be implementation-specific).

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

[0116] Beam combining / selection 204 can be used to combine beam-specific measurement data to derive cell quality 205. The behavior of beam combining / 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 the beam-specific measurement data reported to Layer 3 after beam combining / selection 205. The reporting period at B 205 can be equal to one measurement period at A1 203.

[0117] Further layer 3 filtering 206 targeting cell quality 205 can be performed on the measurement data provided at point B 205. The behavior of the layer 3 filter can be normalized, and the configuration of the layer 3 filter can be provided by RRC signaling. The filtering reporting period at C 207 can be equal to one measurement period at B 205.

[0118] The result after the measurement data is processed by the layer 3 filter is... Figure 2 C 207 in the figure represents the reporting rate, which can be the same as the reporting rate at point B 205. This measurement result can be used as input for one or more evaluations 208 of the reporting criteria.

[0119] The evaluation of the reporting criteria 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 measurement data. This is illustrated by inputs C 207 and C1 210. The WTRU can evaluate the reporting criteria at least each time a new measurement result is reported at point C 207 or C1 210. The reporting criteria can be standardized, and this configuration can be provided by RRC signaling (e.g., WTRU measurement reporting configuration).

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

[0121] L3 beam filtering 211 can be performed on the measurement data (e.g., beam-specific measurement data) provided at point A1 203. 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 period at E can be equal to one measurement period at A1.

[0122] E 212 represents the measurement data (e.g., beam-specific measurement data) after processing in the L3 beam filter 211. This measurement data is associated with K beams 215. The reporting rate can be the same as the reporting rate at point A1203.

[0123] The beam selection process 213 selects X beams 214 from the K beams 215 measurement data provided at point E 212, thereby generating measurement data for point F 216. The beam selection behavior can be standardized, and the configuration of this module can be provided by RRC signaling.

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

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

[0126] As is known, measurement data must comply with accuracy requirements, which are defined for absolute and relative measurements of RSRP and RSRQ, for different scenarios (such as depending on frequency range, operating mode, and / or temperature).

[0127] The described use cases can utilize various connection lines between WTRUs, including NR sidelinks on licensed or unlicensed frequency bands, and WTRU connections via a network (including NR Uu). Furthermore, devices (such as WTRUs) can have multiple radio links, one dedicated to direct communication between WTRUs (e.g., a sidelink) and one dedicated to the network (Uu). WTRU groups can be formed using sidelink connections between users, with only a subset of users in the group needing to maintain an active Uu radio link.

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

[0129] A Customer Premises Network (CPN) is a network located within a 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 can access CPN and / or 5G network services. The PRAS can be configured to use licensed, unlicensed, or both frequency bands. Connectivity between the eRG and the WTRU, non-3GPP equipment, or the PRAS can utilize any suitable 3GPP or non-3GPP technology (e.g., Ethernet, optical communications, WLAN).

[0130] A Personal IoT Network (PIN) comprises PIN elements that communicate using direct PIN connection or direct network connection and are locally managed (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 wearable networks and smart home / smart office devices.

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

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

[0133] Figure 3 An example of a network including multiple Personal IoT Networks (PINs) and PIN elements is shown; Use cases can include wearable connected objects such as those in extended reality (XR) and / or augmented reality (AR) / virtual reality (VR) scenarios, where devices can offload a portion of processing (e.g., audio, video) to more capable devices. These devices can form interconnected WTRU groups that share their processing power and require communication (typically wireless, such as NR sidelinks). Industrial networks and Industrial IoT (IIoT) use cases can leverage WTRU collaboration / aggregation frameworks, where devices such as sensors can interconnect, for example, to achieve redundancy or reliability.

[0134] WTRUs can be grouped to assist each other and enhance device 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 device hardware (small form factor, low-cost device, limited hardware) to energy considerations (low-power or low-energy devices can reduce their capacity to save power) or even providing assistance to extend coverage and improve reliability.

[0135] WTRU aggregation refers to a relay technology scheme with specific multipath attributes. This multipath relay scheme 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 aims to provide applications requiring high UL bit rates on 5G terminals when conventional WTRUs are too limited by UL WTRU transmission power to achieve the required bit rate (especially at the cell edge). Additionally, WTRU aggregation can improve reliability and stability, and reduce service latency if channel conditions at a terminal deteriorate, with another terminal used to compensate for service performance instability caused by changes in channel conditions.

[0136] In an aggregation context, an anchor WTRU is a WTRU that serves as the source or destination for traffic and payload data, and it 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-side link (SL) relay, an anchor WTRU can correspond to a remote WTRU, and an aggregated WTRU can correspond to a relay WTRU. To assist the anchor WTRU, the aggregated WTRU may need to camp on / connect to the anchor WTRU's serving cell, which may be different from its own serving cell.

[0137] Remote WTRUs may be outside network coverage. Relay WTRUs, on the other hand, can be within network coverage and can relay traffic to / from the network and to / from remote WTRUs.

[0138] WTRU aggregation can involve situations where WTRU collaboration is expected to achieve functions beyond relaying. WTRUs can aggregate their capabilities (processing, power, time, functions) and assist each other in performing tasks and procedures.

[0139] In the following description, the terms “aggregate WTRU” and “auxiliary WTRU” are used interchangeably; the terms “anchor WTRU” and “auxiliary WTRU” are used interchangeably.

[0140] Examples of procedures, signaling, and configurations for measurement collaboration and aggregation between WTRUs in RRCIDLE or INACTIVE modes are described, including: enabling low-level aggregation of measurements for aggregating joint signal processing between WTRUs, and how to process and evaluate received measurement data for cell and PLMN (re)selection; and enabling low-level aggregation-based cell and PLMN selection without measurement feedback by estimating the aggregation gain with respect to measurements.

[0141] WTRUs can be configured to assist each other in performing measurements for PLMN selection, cell selection, and cell reselection. Measurements from the WTRU and its auxiliary / aggregated WTRUs can then be used in the evaluation and selection process, where specific biases need to be introduced to account for the fact that some measurements are not performed locally.

[0142] An example of the application of the described technical solution is that the WTRU is equipped with multiple radio links (e.g., NR SL+ NR Uu), and the side links are already used for aggregation / packetization (e.g., application / user needs), and cooperation can be used to avoid activating the main Uu radio link as much as possible to save WTRU energy.

[0143] As described, both the auxiliary WTRU and the assisted WTRU perform measurements, and the measurement results can be combined / aggregated (e.g., using joint signal processing) to obtain improved signal strength and utilize the auxiliary WTRU's capabilities. Typically, the anchor / assisted WTRU can request the aggregating WTRU to perform a measurement. The aggregating WTRU can take the measurement and forward the result to the anchor WTRU. The anchor WTRU can aggregate the measurement results (possibly using dedicated processing steps) and use the aggregated measurement results to perform the requested procedure (e.g., PLMN or cell (re)selection). Signal aggregation can improve signal quality, enabling the anchor WTRU to increase its coverage area and reduce the time required to find suitable cells.

[0144] Measurement Result Aggregation: Measurement result aggregation can be performed in various ways, such as summing the original measurement samples, summing the absolute power values ​​of the original measurement samples, summing filtered measurement results, or summing the absolute power values ​​of filtered measurement samples. As an example, RSRP values ​​in the linear domain can be summed. In another example, RSRP and RSSI values ​​can first be combined / summed, and then the RSRQ value can be determined based on the combined RSRP and RSSI.

[0145] WTRU can aggregate measurement results received from different WTRUs.

[0146] WTRU can include its own measurements in an aggregated manner.

[0147] Aggregating measurement results can allow for diversity gain. For example, an assisted WTRU can aggregate its own measurements with those received from auxiliary WTRUs. Assuming similar channel conditions for the two WTRUs, a gain of approximately 3 dB can be observed in this case. If the assisted WTRU aggregates measurements with those from more auxiliary WTRUs, the gain can be even higher: for similar channel conditions, a gain of approximately 6 dB can be observed for four WTRUs. These are merely theoretical examples to illustrate the concept; since channel conditions cannot be identical.

[0148] Depending on the process, the described technical solutions can be applied on licensed or unlicensed spectrum. When the WTRU is not yet camped or attached to a cell, and therefore may not have network configuration, it can perform the cell and PLMN selection process. An example is the case of an NR-side walkway in an unlicensed band, where the WTRU can perform communication without network configuration or coverage (e.g., using autonomous resource allocation, such as mode 2). For NR-side walkways using licensed spectrum, the network can be configured to perform measurements for cell reselection or to cooperate with the PLMN when searching for a higher-priority PLMN after one has already been selected. Cell selection can also be triggered by state transitions (e.g., receiving an RRC release message that may contain network information).

[0149] Examples using 3GPP technologies (such as 5G NR) are provided. In a variation of the technical approach, WTRU inter-communication can be performed using non-3GPP communication methods such as Wi-Fi or Bluetooth.

[0150] An example of aggregation between two WTRUs is provided. Similar aggregations involving more WTRUs can be anticipated using the same methods and procedures.

[0151] WTRU aggregation can be performed using inter-WTRU connections, such as PC5 (side link) or any other communication system (e.g., Wi-Fi, Bluetooth, wired connection). The concept is illustrated using an NR side link as an example, but any other inter-WTRU interface can be used.

[0152] WTRUs may or may not be within the network's coverage area, and a connection to the network may not be necessary for performing direct aggregation between WTRUs.

[0153] Figure 4 A schematic diagram illustrating direct communication between WTRUs is shown. As shown, the WTRUs can be within network coverage 401 or outside network coverage 402.

[0154] In some scenarios, such as in personal IoT networks (PINs), tethered devices (e.g., XR, wearables), industrial IoT devices, or interactive services, these devices may need to communicate with each other to obtain 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 the service / application at a higher layer. Group formation for communication exchange can be configured during the PC5 connection establishment phase, or after a connection has been established using signaling of PC5-RRC or PC5-Signaling (PC5-S).

[0155] WTRU groups can be static (e.g., fixed size and devices in the group) or dynamic, where WTRUs can be added and removed, depending on factors such as deployment, device, and service.

[0156] Depending on the purpose of the group, specific requirements (such as performance requirements) can be configured to connect to WTRUs within the group.

[0157] For example, a connectivity aspect that might be required is being served by the same cell, the same gNB, or the same PLMN serving group (or part of a group). This requirement is useful for devices that support multipath (Uu and SL) but not WTRU relays not served by the same cell. It could also be a requirement for network management and communication with WTRUs without inter-gNB or roaming switching.

[0158] Figure 5 An example of roles within a WTRU group is shown. Within a group, WTRUs can have different roles, depending on the hierarchical structure between them. In one example, a WTRU could be considered a peer device in group 501. In this case, there may be no user managing the others. Collaboration within a group involves sharing information, requesting assistance, or forwarding data or control information to each other.

[0159] In another example 502, a WTRU coordinator 503 is connected to other WTRUs 504. The coordinator 503 device can act as a manager, coordinator, or controller for the other devices 504. The coordinator WTRU can be connected to other devices and can centralize the distribution of information among WTRUs. The WTRU coordinator can centralize decisions and information in a group and be used to offload tasks or processes. The WTRU coordinator can facilitate cooperation between other WTRUs or its own cooperation with other WTRUs. When a coordinator WTRU is present, a direct WTRU cooperation link 505 between the two WTRUs performing cooperation may not be necessary 506.

[0160] In 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 jointly or on behalf of other WTRUs in the group. The coordinating WTRU can also provide network connectivity to the WTRUs in the group (e.g., acting as a relay or gateway). The coordinating WTRU may need to have the ability to perform cooperation, including strong connections with other WTRUs in the group.

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

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

[0163] Collaboration between WTRUs requires specific processes and capabilities. Some devices can perform the necessary functions to act as group coordinators, and these functions can be represented by specific WTRU categories or WTRU levels.

[0164] Figure 6 An example of a control plane protocol stack with a cooperation layer is shown. In this example, the WTRU's cooperation layer 601 communicates via direct PC5 communication.

[0165] The PC5 Collaboration (PC5-Collab) interface can be a dedicated interface, possibly with dedicated SRBs for exchanging collaboration information. Alternatively, PC5 Collaboration can use PC5 Signaling (PC5-S) or SL RRC messages (PC5-RRC), which are interchangeable.

[0166] One purpose of the cooperation layer is to enable cooperation and communication between layers of the protocol stack used in the non-access stratum (NAS) and access stratum (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 serve as input for tasks, processes, and decisions performed in each layer of the WTRU.

[0167] Figure 7 An example of a control plane protocol stack using a PC5 interface for collaboration is shown. In this example, WTRU communication is performed using a 3GPP architecture and a sidelink, where the Uu AS 701 and NAS 702 of the WTRU can communicate and exchange messages with each other via the PC5-Collab / sidelink 703. At the Uu AS level, WTRU communication can be performed between any Uu layer (e.g., PHY, MAC, RLC, PDCP, or RRC) through the collaboration layer 703. Within a given WTRU, the collaboration layer can communicate directly or indirectly (e.g., via the NAS layer) with all Uu AS layers. Alternatively, as previously described, a more distributed approach can be used.

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

[0169] Before executing the cooperation procedure, WTRUs can exchange signaling to configure how they can coordinate, their respective capabilities, and communication channels.

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

[0171] WTRU can use PC5, unicast, multicast, or broadcast transmissions to send direct transmissions to users in its group. Transmissions can be periodic or aperiodic, depending on the content being transmitted.

[0172] Cooperative configuration may include scheduling or timing, where the WTRU is expected to use, for example, periodic or dynamic scheduling or signaling to transmit or receive cooperative signaling.

[0173] A WTRU can request information from another WTRU by sending the request via PC5-Collab and receiving a response / report at the corresponding layer of the collaboration via PC5-Collab. In one example, the request could be Layer 1 measurement data of a reference signal exchanged between the PHY layers of the WTRUs; or L3 measurement data of a reference signal exchanged between the RRC layers of the WTRUs.

[0174] The request can be a one-time report or it can trigger periodic / non-periodic reports (i.e., subscription to collaborative content). When a WTRU receives a request, it can report that information as a response if it is available (and possibly after performing some related processes). WTRUs can report to the requesting WTRU. When a WTRU is registered for collaboration in a specific period, it can report periodically or triggered by information updates to the requesting / registered WTRUs.

[0175] Figure 8 A diagram illustrating an example control plane protocol stack for inter-WTRU assistance is shown, where one WTRU can be controlled using two independent NAS entities.Figure 8 The example demonstrates the use of 3GPP-side crosslinks to implement inter-WTRU connectivity, where the NAS of WTRU 1 801 can perform tasks using Uu ASs from two different WTRUs 802 and 803. The NAS layer in WTRU 1 801 can offload tasks to Uu AS 803 of WTRU 2, or WTRU 1 can divide tasks into subtasks and offload the subtasks to AS 803 of WTRU 2. Offloading decisions can be made at WTRU 1 NAS 801, WTRU 1 AS 802, or both, through the WTRU cooperation layer.

[0176] Compared to the previously described architecture, in Figure 7 In this context, a WTRU can also request another WTRU to perform a selected task on its behalf. Consider an example of a 3GPP-side walkway used for inter-WTRU connectivity, where the NAS of WTRU 1 uses the ASs of two different WTRUs to perform a task or uses the AS of another user to perform (partial) a task.

[0177] Similar operations can be applied to different layers of AS. Although AS 803 of WTRU 2 is used to perform some tasks on behalf of WTRU 1, WTRU 2 can still operate its own tasks and processes and is controlled by its own NAS 804.

[0178] A coordinating WTRU can first coordinate its NAS and AS configurations, such as available RATs, supported frequencies, and processes. WTRU 1's NAS can use PC5-Collab to send commands to WTRU 2's AS, and WTRU 2 can execute the requested process or task. After completing the process or task, WTRU 2 can report the output to WTRU 1's NAS. In one example, the content of the reports and commands can remain similar to typical inter-layer communication within a single WTRU, but the destination is changed to the upper (or lower) layer of another WTRU.

[0179] In an alternative implementation, the NAS of WTRU 1 801 can also perform tasks using the AS of WTRU 2, but through communication of the NAS layer 804 of WTRU 2, the NAS layer 804 of WTRU 2 forwards the task to its AS 803, either by forwarding transparently or by controlling the behavior of the AS to be compatible with the rest of the WTRU task.

[0180] Figure 9This illustrates an example of a control plane protocol stack for inter-WTRU assistance, where one NAS entity controls multiple AS entities of WTRUs. In this example, a single NAS entity 901 directly controls AS entity 902 of WTRU 1 and AS entity 903 of WTRU 2. While two WTRUs are used as an example for illustrative purposes, this can be extended to multiple WTRUs. The NAS entity can reside in one of the controlled WTRUs or another WTRU. Inter-WTRU cooperation is used to perform communication between the non-coordinated NAS and AS layers, such as PC5-Collab or other inter-WTRU links.

[0181] like Figure 9 As shown, a single NAS entity can directly control multiple WTRU AS entities, conceptually similar to dual connectivity. The NAS entity can reside in either the controlled WTRU or another WTRU. Inter-WTRU cooperation, such as PC5-Collab or other inter-WTRU links, can be used to perform communication between non-co-located NAS and AS layers.

[0182] A coordinating WTRU can first coordinate its NAS and AS configurations, such as available RATs, supported frequencies, and processes. WTRU 1's NAS can use PC5-Collab to send commands to WTRU 2's AS, and WTRU 2 can execute the requested process or task. After completing the process or task, WTRU 2 can report the output to WTRU 1's NAS. With minimal interface and specification changes, the content of the reports and commands can remain similar to typical inter-layer communication within a single WTRU, except that the destination is changed to the upper (or lower) layer of another WTRU.

[0183] To enable collaboration among a group of WTRUs, information can be shared so that the WTRUs are aware of 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 may include, for example: 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 searches on the SSB.

[0184] WTRU category, for example, whether the WTRU is a special type of WTRU (e.g., NTN, RedCap, URLLC, coordinator).

[0185] WTRU stored information. This indicates what the WTRU has previously discovered and can be quickly discovered when performing cell selection based on this stored information.

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

[0187] WTRU location. Spatial information (e.g., absolute or relative positioning, orientation, velocity) can be used to determine the proximity between devices, and thus the redundancy of their measurements.

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

[0189] WTRU collaboration capabilities, such as the ability to join groups or act as a coordinator, or the ability to distribute or offload which functions and processes.

[0190] WTRU service types and QoS requirements, such as the types of services that need to be supported for this user in this group and the types of assistance that the WTRUs in this group expect to receive.

[0191] The connection status of the WTRU to the network (if any, within or outside coverage, RRC mode, cell / PLMN ID, etc.).

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

[0193] Regarding the user selection of the master device or coordinator, within a WTRU group, a WTRU can act as a coordinator (or manager, or master) WTRU. This user device is responsible for coordinating the WTRUs in the group to jointly perform tasks or to perform tasks on behalf of other WTRUs in the group. Therefore, the coordinator WTRU may need to have the ability to perform collaboration and strong connectivity with the WTRUs in the group.

[0194] Note that the coordinator WTRU can also provide network connectivity to other WTRUs in the group (e.g., as a relay or gateway), but this is not mandatory.

[0195] The embodiments described below include methods and structures for selecting a coordinator WTRU within a group to select the WTRU best suited to coordinate the group.

[0196] Several embodiments for selecting a group coordinator are described.

[0197] In one implementation, some devices may be dedicated to WTRU collaboration and may be hard-coded or (pre-)configured as coordinating WTRUs. Therefore, when included in a group or when connected to other WTRUs, these devices are automatically assumed (or selected) as coordinators. For example, during capability exchange, such WTRUs may declare their capabilities and roles when establishing a connection in the SL.

[0198] This type of WTRU can be placed in selected locations where certain service requirements are difficult to meet using conventional non-cooperative WTRUs. For example, in dense WTRU scenarios, this type of WTRU assists the WTRU and the network in providing the required services and QoS.

[0199] In one example, when a user group is configured in a collaborative communication group, the secondary WTRU becomes the coordinator / master WTRU, while the secondary WTRU (one or more) is the slave WTRU.

[0200] In another example, the service or application used for the group is configured by an application layer that designates a device as a coordinator—for example, the device that initiates the service or a more capable device. The group's configuration includes coordinator configuration and is shared among users.

[0201] Figure 10 An example of a logical interface that can be used by the technical solution is shown. In terms of logical function, NAS1 1001 can communicate with AS2 1002 via an interface. To perform this communication, the PC5 interface is used: NAS1 1001 can send commands to AS2 1002 via the logical interface NAS1-AS2 1003 through PC5-Collab 1004. WTRU2 can then execute the requested process or task, and after completing the process or task, WTRU2 can report the output to NAS1 1001 via the logical interface NAS1-AS2 1003 through PC5-Collab 1004. The content of the reports and commands can remain similar to typical inter-layer communication in a single WTRU, but the interface can be changed (e.g., the destination can be changed to a higher (or lower) layer of another WTRU), and the information is encapsulated for transmission to the peer WTRU.

[0202] In an alternative implementation, NAS1 1001 can use AS2 1002 but perform tasks via NAS2 1005. NAS1 1001 can send requests to NAS2 1005, and NAS2 1005 can send task requests to AS2 1002 (e.g., transparently or by controlling the behavior of AS2 to ensure compatibility and coordination with the rest of the WTRU task).

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

[0204] Figure 11 The call flow is shown as an example of network-based WTRU coordinator selection.

[0205] In another example, the network performs the selection of a coordinator WTRU for the 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.

[0206] refer to Figure 11 The network can request information or updates about the group and WTRU1101 in the group. The WTRU in the group can report its information to the network 1102.

[0207] Various information can be used to select the coordinator WTRU. Specifically, this includes the WTRU's ability to perform cooperative tasks, its Uu (Universal) capacity, SL (Self) capacity, 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.

[0208] Information snippets regarding WTRU configuration and establishment can be exchanged during connection establishment or via RRC. Dynamic information such as RSRP or connection status can be obtained from reports (such as WTRU CSI reports) or based on network requests.

[0209] The network selects the coordinator WTRU 1103 based on the WTRU information reported in the report.

[0210] This option can be based on WTRU capabilities that support inter-WTRU collaboration.

[0211] WTRUs can be ranked based on a score calculated for each WTRU. This score / priority can be based on the WTRU Information Standard, 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. The score can be shared by the network or among WTRUs to discover the WTRU with the highest score.

[0212] In one example, the score is based on the Uu RSRP strongest WTRU becoming the WTRU coordinator to ensure reliable communication between the network and the coordinator.

[0213] In another example, the score could be based on a criterion that maximizes link quality and minimizes the number of hops between users in order to maximize reliability between WTRUs and minimize latency.

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

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

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

[0217] The network can send instructions to the selected WTRU to notify its coordinator role 1104. The network can assign cooperative tasks and configurations to the coordinator.

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

[0219] Figure 12 The call flow is shown as an example of coordinator selection based on WTRU.

[0220] In this example, a coordinator WTRU is autonomously selected among the WTRUs. Communication between WTRUs can be conducted, for example, via PC5-Collab (e.g., at the RRC level).

[0221] A WTRU (WTRU B) can request WTRU information or updates on WTRU information from other WTRUs in the group 1201. WTRUs in the group report their information to the network. Similar information can also be exchanged between WTRUs 1202 and between WTRUs and the network in the above-mentioned options.

[0222] Some aspects of WTRU information can be exchanged during WTRU direct communication establishment or packet establishment (e.g., capabilities); or they can be exchanged more dynamically (e.g., link conditions).

[0223] In parallel, WTRU selects coordinator WTRU 1203 based on the reported WTRU information. A similar ordering as previously described may also be used in this document.

[0224] WTRUs can share results with each other, indicating the selected WTRU and / or sorting results 1204. The selected WTRU can also indicate itself as a coordinator using additional cooperative configurations 1205.

[0225] When establishing the ordering of potential coordinators, WTRUs can base their computation on the same information input from other users, which can produce 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 as coordinators. 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 perform limited ordering comparisons to filter for the final coordinator. The result of this convergent selection will be shared with the WTRUs in the group (similar to 1204).

[0226] While embodiments of the technical solution focus on selecting a coordinator for a group, it is also possible for a group to have multiple coordinators. Different coordinators in a group may handle different management tasks or handle a subset of the WTRUs in the group. An example is the case of a group of WTRUs used for services or applications, where the WTRUs belong to different operators or are not nearby and are associated with different cells, and there may be a single coordinator defined, for example, by PLMN, by cell, or based on geographical proximity.

[0227] Regarding low-level aggregation of multiple WTRUs for IDLE / INACTIVE measurements, in some examples, some devices (e.g., conventional devices) may be limited by their capabilities, power, energy, or connectivity to the access network. To improve the performance of these WTRUs, they can be "aggregated," with one "aggregated" WTRU assisting another "anchor."

[0228] Aggregated WTRUs can assist anchor WTRUs in performing joint signal reception by sharing their hardware and processing, such as in cases where measurements or sensing are jointly performed at the lower layer (PHY-MAC) of the WTRU.

[0229] This disclosure discloses measurements for RRC IDLE and INACTIVE modes. For cell (re)selection and PLMN selection, the WTRU measures the cell's SS-RSRP on the SSB's secondary synchronization signal.

[0230] Through the aggregation link, WTRUs can exchange their measurement data and evaluate the received RSRP / RSRQ through aggregation / joint processing. Depending on the data being exchanged, the exchange of measurement data can be performed between the WTRU's Uu stack at the PHY, MAC, or RRC layer levels, and in cases where the cell uses multiple beams, the exchange of measurement data can be beam-specific. The aggregation configuration can include which measurement data is shared between WTRUs and how this measurement data is processed (e.g., via network configuration or via SL configuration).

[0231] This describes the technical approach used to select the aggregated WTRU. This selection can be performed independently of cell or PLMN selection. The anchor point can select the aggregated WTRU. In one example, the aggregator role can be static, such as based on provisioning, network configuration, hardware, or deployment selection.

[0232] Some devices can be dedicated to WTRU aggregation and are hard-coded or (pre-)configured to aggregate WTRUs (at least for specific anchor WTRUs). These devices can be automatically assumed (or selected) as aggregators when connected to other WTRUs. For example, during capability exchange, once a connection is established in the SL, such a WTRU can declare its capabilities and role. There are prior agreements that allow devices with these capabilities to act as aggregators. Selection itself is not required.

[0233] In one example, a static WTRU aggregator can be placed in a selected location where specific service requirements are difficult to meet with a regular non-aggregated WTRU, such as for edge coverage.

[0234] In another example, a static WTRU aggregator can be located where multiple devices are used for a given application, such as VR / XR, installed multi-sensor devices, or Personal Internet of Things (PIoT) devices. In this case, a more capable device (e.g., a smartphone) can assist a given user's auxiliary device (e.g., glasses, wearables, cameras, etc.). When a group of users is aggregated in an aggregation / anchor relationship, the aggregating WTRU can become the coordinator / master WTRU, while the anchor WTRU is the secondary WTRU. Optionally, the network can assign aggregators, for example, to improve the performance of the anchor WTRU.

[0235] Figure 13 The call flow is shown as an example of network-based aggregated WTRU selection.

[0236] refer to Figure 13 The network can perform the selection of aggregated WTRUs for anchor WTRUs. For example, this aggregation, managed by the network, can be triggered when a WTRU moves out of coverage or when coverage may limit its intended service. The aggregated WTRU can be assigned to assist.

[0237] The network can request information or updates about the group and WTRU 1301 in the group. The WTRU in the group reports its information to the network 1302.

[0238] For example, as described in the preceding paragraphs, various types of information can be used to select aggregated WTRUs. This information specifically includes the WTRU's ability to perform aggregation tasks, its Uu capabilities, SL capabilities, Uu link quality (e.g., Uu CSI or 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.

[0239] Information regarding WTRU configuration and establishment can be exchanged during connection establishment or via RRC. Dynamic information (such as RSRP or connection status) can be obtained from reports (such as WTRU CSI reports) or based on network requests.

[0240] The network can select aggregated WTRUs (one or more) 1303 for anchor WTRUs based on the reported WTRU information.

[0241] This selection can be based on supporting the ability to aggregate WTRUs, but other criteria can also be utilized. WTRUs can be ranked according to a score calculated for each WTRU. This score / priority can be based on WTRU information standards that can be calculated by the network. The WTRU with the highest ranking / score / priority can be selected as the aggregated WTRU. The score can be shared by the network or shared among WTRUs to discover the WTRU with the highest score.

[0242] In one example, the score could be based on targeting the WTRU with the strongest Uu RSRP to ensure reliable communication between the network and the aggregated WTRU.

[0243] In another example, the score could be based on the WTRU with the strongest SL RSRP with the anchor WTRU, or on the type of communication interface between WTRUs.

[0244] In another example, the score can be based on geographic location (absolute or relative location) and optionally on device speed.

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

[0246] Scores can also be a combination of many of these exemplary measures.

[0247] The network can indicate its role to the aggregated WTRU and provide configuration 1304, such as the anchor WTRU ID, and may schedule resources for communication with other WTRUs or with the network, and aggregate tasks (such as assisting cell and PLMN selection or acting as a relay).

[0248] The network can also indicate the selected aggregated WTRU and its configuration 1305 to the anchor WTRU. In another example, the WTRU can autonomously select based on the received information.

[0249] Figure 14 The call flow for an example of aggregated WTRU autonomous selection is shown.

[0250] Communication between WTRUs can be achieved via, for example, PC5-Collab (e.g., at the RRC level). Multiple WTRUs can communicate simultaneously or sequentially through anchor WTRUs, and the anchor can perform selection in the reported responses.

[0251] An anchor WTRU can request WTRU information 1401 from a potential aggregate WTRU to request updated information (such as Uu connectivity and status (e.g., Uu RSRP, cell ID)) and its capabilities. This request may also include anchor WTRU information, which includes information that can be used to filter reports from aggregate WTRUs. An anchor WTRU may include its own information.

[0252] A potential aggregation WTRU is a WTRU capable of performing aggregation functions. A potential aggregation WTRU can be a specific WTRU in a group or a group / all WTRUs. As part of the configuration, the anchor WTRU can know the priority of the potential aggregation WTRU. Alternatively, the potential aggregation WTRU can be determined during the discovery phase.

[0253] Potential aggregated WTRUs can report their status and update information upon request (1402).

[0254] Some types of WTRU information can be exchanged during WTRU direct communication establishment or packet establishment, such as capabilities; or they can be exchanged more dynamically, such as link conditions.

[0255] Anchor WTRUs can select their aggregate WTRU 1403 based on reported WTRU information. A similar sorting model as previously described can also be used. Anchor WTRUs can then report this selection to aggregate WTRU 1404.

[0256] Anchor WTRUs can share results with each other to indicate the selected WTRU and / or sorting results, as well as the aggregation configuration. Configuration parameters may include one or more of the following: anchor WTRU ID, potential cell ID, coordinator WTRU ID, scheduling resources to communicate with each other, and aggregation tasks (such as auxiliary measurements, auxiliary cell and PLMN selection, or auxiliary as a relay).

[0257] WTRU can initiate (or activate) its role in the aggregation, namely as an anchor and aggregation WTRU 1405.

[0258] Although the described technical solution focuses on selecting a single aggregated WTRU for an anchor point, an anchor point may also have multiple aggregated WTRUs.

[0259] Regarding the configuration and aggregation measurement process, the measurement follows a series of processes from signal sampling to Layer 3 values. In a typical embodiment, the two devices in the aggregation can exchange their measurement data for joint processing at different stages. This means that the first WTRU can use a portion of the normally required processing to preprocess the received signal, transmit the preprocessed signal to the second WTRU, and the second WTRU can complete the processing using its own received signal and the preprocessed signal. The processing stages for transmitting measurement signals to other devices can be configured, and different options are possible.

[0260] Figure 15 The call flow for an example of a multi-WTRU aggregated measurement process is shown. Without loss of generality, two WTRUs are used in this example.

[0261] WTRU A and WTRU B can be interchangeably anchor WTRUs or aggregate WTRUs, depending on which WTRU triggers the measurement and / or which WTRU performs the process / decision associated with that measurement.

[0262] Although this example is described for two WTRUs, WTRU behavior can be replicated / parallelized to have aggregation of multiple WTRU measurements.

[0263] In the first step, the WTRU in the aggregation can exchange its configuration 1501 for aggregation measurement.

[0264] This configuration can include the supported aggregate measurements and capabilities, such as what types of measurements and processes (RSRP, RSRQ, RSSI, etc.) can be performed on the aggregate, RS, and which processes.

[0265] This configuration can include the content of the exchanged data, such as at which processing step the measurement data is exchanged.

[0266] This configuration may include processing requirements prior to the exchange, including parameters and methods for the preprocessing step or performance requirements for the preprocessing step.

[0267] This configuration can include the measurement objects to be considered, such as which reference signals to measure, and for which metric and process.

[0268] Configuration can include the configuration of aggregated measurements, such as whether they are dynamic (on demand) or periodic.

[0269] This configuration can include the measurements to be reported, including, for example, the original measurement sample ( Figure 2 The measurement results after layer 1 filtering (A 201) Figure 2 "A1" 203 in the text), beam measurement results after L3 filtering ( Figure 2 The “E” in 212), community quality ( Figure 2 The “B” in 205), the filtered cell quality ( Figure 2 The “C” in 207) or RSRP ( Figure 2 (D 209 in the text). This information can also be sent in the request to perform aggregate measurements (1502), allowing for a more dynamic selection of the reported measurement quantities.

[0270] WTRU B can receive a request 1502 for performing aggregated measurements. This request can be received from another WTRU in the aggregate, or from the coordinating WTRU or the network. Alternatively, the measurement can be triggered internally by the WTRU itself, for example, if configured periodic / semi-static measurements are being performed.

[0271] The request may include or refer to the configured measurement to be performed (e.g., the object being measured or the received signal (RS)); as well as the timing, reporting schedule, and conditions of the measurement.

[0272] The WTRU can perform its measurements 1503 according to its configuration, such as on an SSS corresponding to a configured timing. Sampling timing can be used to synchronize measurements between devices to enable joint reception calculations. The configuration / request can instruct the WTRU which SSS to report so that the WTRU can synchronize and perform measurements based on the same samples. If the network uses beam-based SSSs, the measurements can be beam-specific.

[0273] WTRU can obtain its input for measurement processing, corresponding to Figure 2 The “A” in the data refers to measurement data, such as A: measurement data within the physical layer (beam-specific sample).

[0274] The WTRU can perform configured processing on measurement data 1504. Although the processing methods or parameters may differ (depending on the WTRU implementation, the measurement being performed, and the configuration), the WTRU can be configured to perform the same measurement steps.

[0275] In one embodiment, the WTRU may not perform measurement-related processing on the measurement sample.

[0276] In another embodiment, the WTRU may perform layer 1 filtering only on the measurement samples.

[0277] In another embodiment, the WTRU may perform some of the processing in the Layer 3 (RRC configuration) processing on the measurement sample, such as beam combining, beam selection, or L3 beam filtering.

[0278] The WTRU can still perform the remaining measurement processing in parallel with the following steps, such as with a complete measurement on its own, or be able to perform a refined (pre-processed) evaluation of the measurement results.

[0279] WTRU B can transmit preprocessed measurement results to WTRU A 1505 according to the configured reporting steps and using the configured schedule / resources.

[0280] Depending on the configuration, WTRU B can report the raw measurement samples ( Figure 2 The measurement results after layer 1 filtering (A 201) Figure 2 The “A 1” 203 in the text), beam measurement results after L3 filtering ( Figure 2 The “E” in 212), community quality ( Figure 2 The “B” in 205), the filtered cell quality ( Figure 2 The “C” in 207) or RSRP ( Figure 2 The “D” in 209).

[0281] When measuring multiple signal sources, WTRU B can perform secondary filtering to determine which measurement data to report, removing signals with too low an intensity. Signal requirements can be configured (e.g., RSRP threshold or signals selected via beamforming), and the threshold can be set differently for different aggregation methods.

[0282] WTRU A can combine its own preprocessed measurement results with the received measurement results 1506.

[0283] In one embodiment, WTRU A can combine measurement samples by directly summing the samples or by summing the absolute power contribution values ​​of each sample 1506.

[0284] In another embodiment, WTRU A can measure sample combination 1506 by directly summing the filtered samples or by summing the absolute power contribution of each sample.

[0285] In another embodiment, WTRU A can combine the measurement results (in the linear domain) for example by summing the RSRP values ​​together; for the RSRQ value, the RSRP and RSSI values ​​can be combined separately first, and then the combined RSRQ1506 can be calculated based on the combined RSRP and RSSI values.

[0286] If so, WTRU A can recover the processing of the measurement results 1507.

[0287] In one embodiment, WTRU A can recover and perform layer 1 filtering and RRC processing.

[0288] In another embodiment, WTRU A can resume and perform all RRC processes.

[0289] In yet another embodiment, WTRU A can resume and perform the remaining RRC processing.

[0290] WTRU A can report the aggregated measurement results to the corresponding layer or entity based on the initiated request. The measurement results include the aggregate configuration or the aggregated WTRU 1508 that participated in the measurement results.

[0291] WTRU A can report measurement results to WTRU B, including aggregate configurations or aggregated WTRU1509s involved in the measurement results.

[0292] Regarding an embodiment of the device receiving an aggregation measurement request, the WTRU can exchange configurations and capabilities (e.g., processing L1-filtered measurement results) with another WTRU to measure the RSRP of the cell. When triggered to perform a measurement, the WTRU can, for example, use SL to transmit an aggregation measurement request to another WTRU in the aggregation, the aggregation measurement request including the object to be measured, as well as timing and preprocessing. The WTRU can perform its measurement and preprocessing steps according to the configuration and receive the preprocessed measurement results from the other WTRU. The WTRU can aggregate the measurement results, for example, by summing the signal strengths of the received signal and the measured signal. The WTRU can resume processing to complete the measurement. The WTRU can send a measurement report to the entity requesting the measurement and the devices participating in the measurement.

[0293] Regarding an embodiment of the device transmitting requests for aggregation measurements, the WTRU can exchange configurations and capabilities (e.g., processing L1-filtered measurement results) with another WTRU to measure the RSRP of a cell. Upon receiving a request to perform a measurement or triggering a measurement (e.g., due to a periodic measurement configuration), the WTRU can perform the requested measurement and preprocessing steps according to that configuration. The WTRU can perform secondary filtering of a portion of the measurement results used for reporting. This selection can be based on the measured signal strength and a configured threshold. The WTRU can transmit preprocessed measurement results from another WTRU based on the configuration. The WTRU also receives aggregated measurement results from the aggregation device.

[0294] The processing steps and parameters used to measure the polymerization are described.

[0295] In cases where measurement data is exchanged after a layer 1 filter, the filter can provide more stable measurements of the SSS, although neither the filter itself nor the measurement input is constrained, and the filter itself and the measurement input may differ between different devices.

[0296] One embodiment includes adding a normalized Layer 1 filter in the case of aggregated / exchanged measurement results, or having a Layer 1 filter that can be configured by the network during the aggregation configuration phase or between WTRUs. This filter configuration may, for example, be a list of coefficients to be applied to L1 samples in the frequency and time domains. In the case of aggregated measurement results, this configured / normalized filter can be used instead of implementing a specific L1 filter 1504.

[0297] In one embodiment, the WTRU is configured with a Layer 1 filtering method and parameters (e.g., filter coefficients) applicable to aggregate measurements. When an aggregate measurement is triggered by or requested by the WTRU, the WTRU can use the configured Layer 1 filter based on the configuration (and / or upon request). The WTRU can then transmit the Layer 1 filtered measurement result to another WTRU.

[0298] When processing aggregated measurement samples, the device can continue with Layer 3 processing, WTRU beam combining / selection, Layer 3 beam filtering, Layer 3 cell quality filtering, reporting beam selection, and reporting standard evaluation. RRC parameters typically correspond to typical measurement scenarios and may not be ideal for aggregated measurements.

[0299] In one example, a dedicated set of RRC parameters is provided to the device for aggregation scenarios. This set of parameters can be configured by the network or between WTRUs (e.g., using PC5-RRC).

[0300] For example, in the case of aggregation, a dedicated standard that can be added to the RRC parameters, or an offset parameter that can be added to the original standard, can be used to adapt the thresholds used in the standards, selection, and reporting standards for beam combining.

[0301] Layer 3 Aggregation Filter Coefficients: As another example, for the corresponding measurement of the i-th quantity in the quantityConfigNR list, the Layer 3 filter is typically configured using filterCoefficient, FilterCoefficientRSRP, or FilterCoefficientRSRQ, and i is indicated by the quantityConfigIndex in MeasObjectNR; a new and similar parameter, the Layer 3 Aggregation Filter Coefficient, can be jointly configured in QuantityConfigNR for measurement aggregation. Alternatively, when using aggregation, filterCoefficientAggregationOffset can be configured and applied to the filter coefficients.

[0302] For the layer 3 aggregation filter coefficients, an example of the aggregation IE in RRC is as follows (using ASN.1 encoding): Aggregation-QuantityConfigRS::= SEQUENCE { ssb-FilterConfig Aggregation-FilterConfig, csi-RS-FilterConfig Aggregation-FilterConfig } Aggregation-FilterConfig::= SEQUENCE { Aggregation-filterCoefficientRSRP FilterCoefficient, Aggregation-filterCoefficientRSRQ FilterCoefficient, Aggregation-filterCoefficientRS-SINR FilterCoefficient }

[0303] In one implementation, the WTRU may be configured (by the network or by another WTRU) with an aggregation-specific set of configurations (e.g., filter coefficients) for the layer 3 filters. When the WTRU performs an aggregation measurement, it can use the layer 3 filters configured for aggregation. The WTRU can then resume the remaining processing steps.

[0304] Regarding accuracy adaptation, another element to consider during the aggregation process of jointly processing measurement results performed at different devices is the accuracy of the measurement results. In this embodiment, when a measurement result is received, the device can apply an offset to the measurement result to account for some potential accuracy issues.

[0305] As an example, the NR specification stipulates that, under normal conditions, the accuracy requirement for SS-RSRP measurements in the same frequency band of FR1 is ±4.5 dB, and the accuracy requirement for SS-RSRQ is ±2.5 dB. This requirement can vary depending on the carrier, frequency band, operating mode (e.g., CA / DC), whether the measurement is in the same or different frequency bands, etc. Furthermore, as is known, when the equipment is under “extreme conditions” (i.e., when the temperature is outside the +15°C to +35°C range), the requirements for a given configuration may differ, where the accuracy reaches ±9 dB for SS-RSRP and ±4 dB for SS-RSRQ.

[0306] Therefore, a device that receives measurement results from another WTRU can know its configuration and status to correctly adapt to the determined accuracy.

[0307] In one embodiment, the required accuracy for aggregation can be specified as an independent configuration, such as an independent configuration that the WTRU can use during aggregation; or, for example, as a configuration requirement in an aggregation configuration between WTRUs during a connection configuration or RRC configuration. This configuration can be measurement-specific and, for example, dynamically indicated during a measurement request. The WTRU can use the configured accuracy requirements to determine which processing to use, for example, determining whether to apply an L1 filter or an L3 filter from a pre-configured set of filters.

[0308] In one embodiment, the WTRU can be configured to perform measurements for aggregation. The WTRU can receive a measurement configuration from another WTRU, which includes indications related to accuracy requirements. The WTRU can select and apply preprocessing methods (e.g., L1 and L3 filters) from a list of configured methods, the selected methods corresponding to the configured accuracy requirements. The WTRU can report the preprocessed measurement results, optionally including the method or accuracy requirements applied to it.

[0309] In another option, the WTRU reporting measurement results can report the accuracy of the measurement results by reporting an absolute accuracy value (based on a specification table or based on device implementation knowledge); or by indicating the configuration for completing the measurement (i.e., same-frequency vs. different-frequency measurements, frequency range, normal vs. extreme conditions, etc.), and the receiving device determines the corresponding accuracy based on a known specification table.

[0310] Based on the expected accuracy of the measurement, the device can apply an offset to the received measurement results. As an example, the offset can be set to half of the accuracy value (e.g., if the accuracy requirement is ±4dB, a -2dB offset can be applied to the measurement results).

[0311] In one embodiment, the WTRU can be configured to receive (pre)processed measurement results for aggregation. The WTRU can receive measurement results from another WTRU along with an indication related to the accuracy requirements followed by the other WTRU. This indication may be, for example, whether the measurement was performed under extreme or normal conditions; or explicitly, the indication is an accuracy range. The WTRU can determine and apply an offset to the received measurement results based on the accuracy indication.

[0312] In another embodiment, regarding low-level information sharing, users can share information about low-level processing to assist each other in detecting and processing relevant signals. Instead of (or in addition to) exchanging measurement results, users can exchange information, for example, to aid in synchronization on selected cells / frequencies.

[0313] In one example, after performing some spectral measurements, the WTRU can transmit frequency and timing indications to the requesting WTRU to help identify and synchronize with a synchronization signal. For one or more beam scenarios, this information includes absolute or relative timing indications for detecting the synchronization signal, relevant PIC information, and the timing and frequency location of SSB bursts. This information can be used by the assisted WTRU to more effectively detect cells and can reduce radio monitoring and processing time to only the necessary limits.

[0314] Measurements are performed using low-level aggregation in IDLE and INACTIVE modes.

[0315] To support cell selection or reselection using low-level aggregation, the aggregation may be pre-established and active, and the cell selection process can be performed against the anchor WTRU. This decision can be made at the anchor itself or at the aggregation WTRU.

[0316] In the second embodiment, cell (re)selection can be performed in conjunction with aggregation selection. Aggregation-based cell reselection may be required. For example, the cell (re)selection process can be adapted so that the selection criteria and ranking take into account measurements that the WTRU may be using in the aggregation.

[0317] Regarding cell (re)selection of aggregated WTRUs, the following embodiment discloses how to perform a cell (re)selection process using lower-level aggregated WTRUs. This document assumes that the anchor WTRU and the aggregated WTRUs have already been grouped together.

[0318] This article presents two scenarios in which the choice is made to be executed on the anchor WTRU side or the aggregate WTRU side.

[0319] Figure 16 The example call flow for low-level aggregation for cell (re)selection, performed by the anchor WTRU, is shown.

[0320] In the event of cell (re)selection on the anchor WTRU side, the anchor WTRU can initiate a cell selection process and receive measurement information from the aggregation WTRU(s) to evaluate cell quality under low-level aggregation. The anchor WTRU initiating the cell selection process can apply cell selection procedures and criteria, wherein, as described above, the criteria can be applicable to aggregation-based standards.

[0321] Although this process is described for a single aggregated WTRU, it can also be applied to multiple aggregated WTRUs, repeatedly executing the exchange process.

[0322] The anchor WTRU and aggregation WTRU can be interchanged for cell selection targeting lower-layer aggregation 1601.

[0323] This configuration can be pre-configured, and / or exchanged between WTRUs, for example, during aggregation or packet establishment configuration and / or during SL connection configuration. The configuration can be transmitted using SL discovery establishment signaling and / or PC5-Collab or SL RRC signaling. Alternatively, the configuration can be obtained over the network via system information, for example, using a new dedicated SIB to obtain the aggregation configuration.

[0324] This configuration may include a set of parameters that can replace the parameters of the regular cell selection process, and this set of parameters is applied when aggregation is used to perform cell selection.

[0325] This configuration can be WTRU-specific and / or service-specific, allowing the standard to be adapted to the device and its use.

[0326] This configuration can include the timing of processes (e.g., requests and responses). For example, a request can be transmitted on a selected resource or time to be monitored by WTRUs in a group that are configured and support cooperative cell selection. Scan reports can also be configured to be transmitted on the selected resource or time and configured with a maximum timing requirement to send their reports after a request is received.

[0327] This configuration may include the necessary measurement data performed by the aggregated WTRU (i.e., RSRP and RSRQ based on the SSS), as well as the time validity of the measurement data. In one embodiment, measurement and reporting may be configured as a one-time request / report. In another embodiment, measurements may be activated and reported periodically, periodically, or based on events.

[0328] This configuration may include the aggregation cell selection criteria and the calculation methods and parameters / offset values ​​required for measurement, for use by the WTRU in subsequent steps.

[0329] Anchor WTRUs and aggregate WTRUs can exchange WTRU information (1602). Some information can be exchanged during aggregation configuration, and some can be updated periodically. (1601) and (1602) can be executed simultaneously using different messages, or together using the same message, or in reverse order.

[0330] Cell (re)selection can be triggered by the anchor WTRU (1603). The anchor WTRU can verify that it is configured to perform lower-layer aggregation cell (re)selection, and with which (or which) WTRUs it is selecting.

[0331] For example, the anchor WTRU may request cooperative cell (re)selection when its battery level is below a configured threshold; or when the WTRU is at the cell edge or 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 auxiliary WTRU), after (cooperative) PLMN selection, after the primary radio receiver is turned on, etc. The cell (re)selection process may also be triggered by the establishment of an aggregation group, or by the aggregation WTRU.

[0332] Anchor WTRUs can request aggregated WTRU reports for cell selection auxiliary measurements 1604. This request may include the desired frequency, carrier, PLMN, and a set of pre-selected cells (e.g., based on stored knowledge).

[0333] Anchor WTRUs and aggregation WTRUs can perform cell selection measurements 1605 based on their configuration and the requested aggregation measurements. If the aggregation WTRU has already performed cell selection auxiliary measurements within a given configuration time window, it may not be required to perform such measurements. For each measurement frequency, the WTRU can search for more than just the strongest cells, for example, by collecting measurement results for the maximum or minimum number of cells configured, so that multiple options are available later when combining anchor and aggregation WTRU measurement results. The WTRU can restrict the cell selection search to frequencies supported only by the aggregation WTRU. The aggregation WTRU can perform measurements on the requested frequency / carrier obtained from the request and / or configuration.

[0334] WTRU can apply configured preprocessing 1606. The preprocessing steps and measurement data collected for aggregation (e.g., L1 measurement data, RSRP, RSRQ, etc.) can be configuration-based. For example, information element aggregation (measConfig IE) can be set to one or more of the following: L1 samples ( Figure 2 A 201 in the middle), filtered samples ( Figure 2 (A1 203), RSRP, or RSRQ. RSRP and RSRQ can be based on L1 / L2 measurements and reports ( Figure 2 D 209) or L3 measurement and reporting ( Figure 2 (F 216 in the text).

[0335] The aggregated WTRU can report its partially preprocessed measurement results 1607 to the anchor WTRU based on the configured processing steps.

[0336] Measurement results can be filtered to include only cells with signal quality exceeding a configured threshold (e.g., RSRP or RSRQ). The RSRP or RSRQ threshold can be set in the aggregated RRC configuration, for example, to an RSRP range type (AggregationCellSelection-RSRP-Thresh, AggregationCellSelection-RSRQ-Thresh, RSRP range, or RSRQ range). These thresholds can be aggregation report-specific (e.g., one threshold for L1 reporting and one for RSRP reporting), or they can be set to a given value based on the configured aggregation report type.

[0337] The measurement results can be filtered to include only cells that are not restricted or prohibited for anchor WTRUs, for example, by checking that the anchor WTRU type is not prohibited or the cell is not restricted for anchor WTRUs based on the exchanged WTRU information.

[0338] Measurement results can be filtered to include only cells suitable for (re)selection by the aggregated WTRU, such as those that meet the signal quality criteria used for cell selection and are not banned or retained for the aggregated WTRU.

[0339] Measurement results can be filtered to include only (e.g., explicitly indicated in system information) cells that support aggregated WTRUs or cells for which aggregation is not restricted / prohibited.

[0340] When the aggregated WTRU is camped in or served by a cell, the aggregated WTRU can be configured to report only signal information from that cell. The aggregated WTRU can also be configured to report only cells suitable for reselection, making reselection to that cell by the aggregated WTRU possible if the cell is selected by an anchor point.

[0341] The anchor point WTRU can receive and aggregate partially preprocessed measurement results. The anchor point WTRU can recover the measurement processing according to the configured steps (e.g., applying bias based on the accuracy of the received measurement results or using aggregation-specific filters)1608.

[0342] The anchor WTRU can determine the aggregated RSRP and RSRQ1609 based on its measurements and reported measurements. The anchor WTRU can then select cells based on the aggregated measurements.

[0343] To verify the suitability of a cell as a set of WTRUs, the anchor WTRU verifies the suitability of the WTRU aggregation. Criteria are defined in the (pre)configuration or aggregation (e.g., according to specifications or obtained from the exchange in step 1).

[0344] To assess cell signal strength, WTRU can determine the RSRP and RSRQ of aggregated signals and apply new standards for aggregated measurements.

[0345] In one embodiment, based on the configuration and measurements received from the aggregated WTRU, the anchor WTRU can estimate RSRP and RSRQ based on the aggregated signal. The aggregated RSRP / RSRQ can be used to evaluate cell selection criteria. RSRP and RSRQ can be used as values ​​Qrxlevmeas and Qqualmeas, respectively, in cell (re)selection.

[0346] The S-standards for evaluating cells' RSRP and RSRQ, used for cell reselection, can be modified for aggregation. The offsets (e.g., Qqualminioffset, Qrxlevminoffset) and minimum requirements (Qrxlevmin and Qqualmin) used in the standard can be configured individually for aggregation, for example via SIB, RRC or sidelinks, or dedicated RRC signaling.

[0347] When Srxlev > 0 and Squal > 0, the cell selection criterion S can be satisfied, where: Srxlev is the cell selection RX level (in dB) and is defined as follows: Srxlev = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) – Pcompensation – Qoffsettemp; where: Qrxlevmeas: Cell RX level (Reference Signal Received Power RSRP). Measured by WTRU.

[0348] Qrxlevmin: Minimum required RX level (dBm) in the cell. Configured by RRC.

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

[0350] Pcompensation: For FR1: Depends on the WTRU power level configured by RRC. For FR2 = 0.

[0351] Qoffsettemp: The offset temporarily applied to the cell. Configured by RRC.

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

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

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

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

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

[0357] Qoffsettemp: The offset temporarily applied to the cell. Configured by RRC.

[0358] The anchor WTRU can receive RSRP and RSRQ from the aggregation WTRU and use the parameters transmitted in the anchor's current serving cell to determine the Squal value. When the measurement is performed by another WTRU, the anchor WTRU can compensate for any differences in the measurement results. Additional offsets (e.g., QlevOffsetAggregation and QqualOffsetAggregation) specifically for this aggregation can be added to the calculations of Srxlev and Squal. When determining the values ​​of Srxlev and Squal, the anchor WTRU will add or subtract the offsets: Srxlev = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) – Pcompensation –Qoffsettemp ± QlevOffsetAggregation Squal = Qqualmeas – (Qqualmin + Qqualminoffset) – Qoffsettemp±QqualOffsetAggregation.

[0359] Adding a positive offset increases the probability that cell reselection criteria S can be met (e.g., Srxlev > 0 and Squal > 0). Furthermore, since the offset alters the Srxlev / Squal values, and the criteria require these values ​​to be greater than zero, subtracting a positive value makes the criteria harder to satisfy.

[0360] Offset determination can be pre-provided, configured, sent in the system information of the current serving cell, or sent in a dedicated RRC message. Optionally, offset determination can be received from other WTRUs.

[0361] Offset can be distance-based. This offset is determined based on the distance between cooperating WTRUs. Several offset values ​​can be configured and selected based on configured distance thresholds. As an example, a 0dB offset may be applicable if WTRUs are co-located, 3dB may be applicable when the distance between WTRUs is below a first distance threshold, 5dB may be applicable when the distance between WTRUs is between the first and second distance thresholds, and so on. Note that this distance metric can be replaced by evaluating the path loss between WTRUs. Connectivity can be used to estimate the co-location / distance aspect, for example, in long-range wireless systems, ultra-short-range wireless / wired systems.

[0362] Offsets can be capability-based. This offset can be determined based on differences in the selected set of capabilities between WTRUs. For example, if the auxiliary WTRU supports four RX antennas for beamforming, while the WTRU supported by the auxiliary WTRU only supports two RX antennas for beamforming, the offset can be configured to 3 dB. Possible combinations of beamforming capability / antenna number can be configured and then selected by the WTRU based on exchanged WTRU information. For example, due to WTRU capability limitations, the measurements performed by the WTRU for cell selection may not reflect the actual cell quality perceived by the WTRU in connected mode. In this case, the offset can be used to compensate for WTRUs with higher capabilities. For example, the cell selection measurement processing of the anchor WTRU relies on two RX antennas. The aggregation WTRU can report the measurements of the two RX antennas to combine them, and the aggregation WTRU can later use four RX antennas and obtain a stronger signal. The offset can be used to compensate for the shortcomings of the anchor WTRU in processing compared to the aggregation UE.

[0363] Offsets can be role-based. For example, if the WTRU is a coordinator or relay / gateway, the offset can be determined based on the aggregated WTRU's role in the group. This offset can be set to facilitate grouping WTRUs with cooperating WTRUs.

[0364] Specific parameters and offset values ​​can be set for different aggregation types or aggregation sizes based on the number of WTRUs. These parameters and offset values ​​can be part of the configuration. For example, the offset of an aggregation with 2 WTRUs can be different from the offset of an aggregation with 3 or more WTRUs.

[0365] In the context of cell reselection, offsets can be applied to Srxlev and Squal during the evaluation of cells from the same or different frequencies. In another example, offsets can be applied to the thresholds used for evaluation of cells from the same or different frequencies, while keeping the measurements unchanged. The offset value can be further added to cells serving WTRUs in the aggregation group (e.g., cells serving the aggregated WTRU) to bias the reselection towards common cells.

[0366] For example: When using aggregated measurement results, if a cell on a higher priority frequency satisfies the conditions Squal>ThreshX、HighQ + QqualOffsetAggregation_highQ or Srxlev>ThreshX、HighQ +QlevOffsetAggregation_highP, then the cell on that higher priority frequency can be selected.

[0367] When using aggregated measurement results, if a cell on a lower priority frequency satisfies the conditions Squal>ThreshX、LowQ + QqualOffsetAggregation_lowQ or Srxlev>ThreshX、LowQ +QlevOffsetAggregation_lowP, then the cell on that lower priority frequency can be selected.

[0368] For cells that are on the same frequency or have the same priority as the serving cell, the following formula can be used to bias the order of cells serving that group: If the serving cell is serving an aggregated WTRU (one or more), Rs = Qmeas,s + Qhyst – Qoffsettemp + QoffsetAggregation; If another cell is serving aggregated WTRUs (one or more), Rn = Qmeas,n -Qoffset –Qoffsettemp + QoffsetAggregation.

[0369] To become a suitable cell, the anchor WTRU can also verify cell status and restrictions. For example, a cell can prevent certain WTRUs from selecting it. This indication is sent in the system information along with the cellBarred and cellReserved flags. The WTRUs being aggregated, the prohibited, and the restricted verifications can be different.

[0370] In one embodiment, if the anchor WTRU or the aggregated WTRU is disabled, the cell can be considered disabled for the anchor WTRU. This means that at least one WTRU in the aggregated WTRU is not authorized to reside in or be served by the cell. To determine the restriction on the aggregation side, the anchor WTRU can receive the disabled status from a report (previous step) or based on aggregated WTRU information (e.g., WTRU type) and use the aggregated WTRU information to assess the disabled status. For example, if the aggregated WTRU is a RedCap device with one Rx antenna, and the cell is indicated as cellBarredRedCap1Rx = “barred”, then the aggregated WTRU is disabled, and therefore the anchor WTRU can determine that the cell is also disabled for itself.

[0371] In another embodiment, if the anchor WTRU is disabled, the cell can be considered disabled for the anchor WTRU even if the aggregate WTRU is not disabled. In this case, the aggregate WTRU can assist the anchor WTRU, but may not consider reselecting to the disabled cell, and the anchor can select the cell without affecting the aggregated cell.

[0372] In an alternative embodiment, if only the aggregated WTRU is prohibited, the cell can be considered prohibited from serving the anchor WTRU even if the anchor WTRU is not prohibited. In this way, the aggregated WTRU has sufficient capability to be served by the cell and assist the anchor WTRU, thus allowing the anchor WTRU to select the cell.

[0373] New “cellBarred” indications (e.g., “cellBarredAggregation” IE type: “Barred” or “Not Barred”) can be defined and signaled in the MIB or SIB1, where the barred indication targets the aggregated user. When present and set to “Barred”, the WTRU configured in the aggregation group can treat the cell as barred.

[0374] The anchor WTRU can notify the aggregation WTRU of the selected cell 1610. After selecting a cell, the anchor WTRU can report the selected cell to the aggregation WTRU. This report may include measurement information, such as the aggregated RSRP, RSRQ, or SINR obtained through measurements by the aggregation WTRU. The report may include any necessary cell or WTRU information required for the aggregation WTRU to camp on the cell, such as the cell ID, its frequency / carrier, cell-specific SI, and WTRU-specific parameters (e.g., paging timing, DRX parameters, etc.). The anchor WTRU may also report the selected cell to the network, for example, during the location registration process (at the NAS level). The anchor WTRU may also indicate that the selection has been performed using cooperative selection, allowing the network to track cooperation between users, send cooperation-specific parameters (e.g., via SIB), and update user configurations based on the cooperation. For example, the network may configure the WTRU's paging timing in the cooperation, send cooperation-specific parameters to the assisted WTRU and the assisting WTRU, and so on.

[0375] Paging can be sent to a cooperating group. Each group can be identified by a cooperating group ID. The cooperating group ID can be cell-specific and unique within the cell. Alternatively, the cooperating group ID can be location / registration area-specific and unique within that area. Or, the cooperating group ID can be RAN notification area-specific. Therefore, the core network or base station can trigger paging of the cooperating group based on the cooperating group ID.

[0376] Once camped on the selected cell, the WTRU can monitor the control channel to receive SIB and paging messages.

[0377] An anchor WTRU can camp on the selected cell 1611. The aggregation WTRU can camp as an aggregation WTRU and begin monitoring signals configured for aggregation (e.g., the anchor WTRU's DCI and paging timing) 1612. Note that if the cell is not the cell on which the aggregation WTRU is camping, the aggregation WTRU can be asked to change its camping cell, for example, by reselecting or directly (re)selecting the anchor cell.

[0378] When an aggregated WTRU can be associated with an anchor WTRU, in addition to its own cell, the aggregated WTRU can also monitor paging timing and DCI targeting the anchor's serving cell. An aggregated WTRU can be associated with multiple WTRUs, which can be connected to different cells. In this case, the aggregated WTRU can camp on (e.g., monitor DCI, paging timing) these cells to assist the corresponding anchor WTRU.

[0379] WTRU A can, for example, report the selected cell to network 1613 during the (NAS) location registration process to indicate that the selection has been performed using PHY aggregation selection (along with associated parameters and cooperating WTRU ID / information). Optionally, the aggregated WTRU can report the cell selected by the anchor point to the network.

[0380] The network can track collaborations between users, send collaboration-specific parameters (e.g., via SIB), and update user configurations based on the collaborations. For example, the network can configure paging timing for WTRUs within a collaboration, send collaboration-specific parameters to both the assisted and auxiliary WTRUs, and so on.

[0381] Figure 17 The example call flow for low-level aggregation for cell (re)selection, performed by the aggregation WTRU, is shown.

[0382] Regarding cell (re)selection on the aggregation WTRU side, in an alternative embodiment, the aggregation WTRU may perform cell selection on behalf of the anchor based on measurements reported by the anchor to the aggregation WTRU and its own measurements.

[0383] Figure 17 The 1701 and 1702 in the text are similar to Figure 16 In cases 1601 and 1602, the configuration may also include information that the aggregated WTRU can perform cell (re)selection for the anchor WTRU.

[0384] Figure 17 The 1703 in the middle is similar to Figure 16 1603 in the example. Alternatively, cell selection for the anchor WTRU can be triggered on the aggregation WTRU side, and an indication can be sent from the aggregation WTRU to the anchor WTRU to trigger cell selection.

[0385] An anchor WTRU can request cell selection from the aggregation WTRU (if it is not triggered by the aggregation WTRU itself) 1704. This request may include the desired frequency / carrier, PLMN, and RAT supported by the anchor WTRU.

[0386] Figure 17 The 1705 and 1706 in the text are similar to Figure 16 1605 and 1606 in the middle. Figure 17 The period from 1707 to 1713 is similar to Figure 16 In 1607 to 1613, the roles of anchor WTRU and aggregate WTRU were interchanged.

[0387] The technical solutions described in this article so far assume that the aggregation group has been pre-established.

[0388] The technical solution is described in the case where there is no pre-defined aggregation group and the aggregation group can be determined simultaneously. In this case, one difference is that the anchor WTRU can evaluate multiple aggregation options and the corresponding (estimated) measurements for cell selection.

[0389] In this scenario, the anchor WTRU can "know" the set of potential WTRUs that can be used as the aggregate WTRU. This can be learned from the SL discovery phase and / or from the WTRU group configuration. The aggregation can also be pre-configured and may need to be activated in the anchor.

[0390] The process for joint cell and aggregation selection can be similar to the cell selection process, but it can be performed in parallel with multiple potential aggregation WTRUs. Signal determination may include comparing signals from different aggregation combinations, and the optimal combination can serve as the basis for selecting that aggregation and its corresponding cell. The optimal combination could be, for example, the cell with the strongest RSRP (Resolution to Resolution) and at least N aggregation WTRUs (where N is the number of determined / configured cells). The anchor WTRU can report the selected cell and aggregation selection to the other WTRUs.

[0391] In one alternative approach, the anchor WTRU can iteratively perform the cell selection process using different aggregation groups (or without aggregation) and select the aggregation that best meets the cell selection criteria.

[0392] For example, the anchor WTRU can perform cell selection first without aggregation. If no cell is suitable, or if the WTRU cannot camp properly on a cell, it can attempt cell selection with the aggregation WTRU and repeat until cell selection is successful.

[0393] Figure 18 The example call flow for low-level aggregation for PLMN selection is shown, performed by the aggregated WTRU.

[0394] exist Figure 18 In this configuration, the aggregated WTRU auxiliary anchor WTRU performs the measurement for PLMN selection. The initial configuration 1801 can include parameters for PLMN selection. For example, parameter values ​​for a high-quality PLMN standard. This standard can be changed for a specific purpose of using the aggregated WTRU for PLMN selection, or the offset can be applied to a typical -110dBm standard.

[0395] Figure 18 1802 and Figure 16 Similar to 1602 in the text.

[0396] An anchor WTRU can be triggered to perform PLMN selection 1803. For example, the anchor WTRU may request cooperative PLMN selection when its battery is low; 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 auxiliary WTRU). Triggers for PLMN selection may include when the anchor WTRU activates its Uu radio link, or when the selected PLMN is not the highest priority PLMN and new selection attempts are performed periodically. Cooperative selection can be activated periodically (e.g., periodically measured) or as a one-time event. Periodic cooperative selection can be stopped when the WTRU successfully selects its highest priority PLMN.

[0397] Figure 18 1804 and Figure 16 Similar to 1604, but this request can indicate PLMN selection parameters, such as supported frequencies and carriers, supported or preferred PLMNs. (Depending on the request or configuration) The measurement requested for PLMN selection is the cell's RSRP.

[0398] Figure 18 The 1805 and 1806 in the text are similar Figure 16 1605 and 1606. WTRUs can perform measurements to assist in the selection of PLMNs on configured or required frequencies and carriers. Aggregating WTRUs and anchor WTRUs can restrict measurements by other WTRUs on frequencies and carriers of PLMNs supported by the anchor WTRU and / or aggregated WTRUs. WTRUs may support only some of the available carriers and / or PLMNs, and one WTRU may have different support / capabilities than another. WTRUs can indicate to each other which carriers / PLMNs they support to avoid unnecessary measurements and reporting during the collaboration process.

[0399] Figure 18 The 1807 in the middle is similar to Figure 16 The report in section 1607 is for PLMN measurements and is based on (pre)configuration. For each frequency, the report may include the PLMN, the corresponding cell ID, frequency information, measurement location, CQI, and CSI. The report can be filtered to remove measurement results from PLMNs that do not meet the aggregation high-quality criteria.

[0400] Figure 18 1808 and 1809 in Figure 16 Similar to 1608 and 1609. For aggregation, the processing and determination of RSRP-specific parameters and offset values ​​can be (pre-)configured for PLMN selection.

[0401] The anchor WTRU AS layer can evaluate the PLMN RSRP and report a high-quality RSRP 1810 to the NAS. The criteria used for a high-quality RSRP can be based on (pre)configuration. WTRU can also report the aggregated configuration used to obtain the RSRP to the NAS, so that the NAS can use the aggregated information as input for PLMN selection. The NAS can perform PLMN selection and report it to the WTRU AS layer.

[0402] The NAS in the anchor WTRU can report the selected PLMN, and if necessary, can report the selected aggregate 1811 to the aggregate WTRU.

[0403] Anchor point WTRUs can, for example, report aggregation-based PLMN selections to network 1812 during NAS registration. Anchor point WTRUs can also indicate aggregation configurations and group memberships to the network.

[0404] In an alternative embodiment, in order to jointly select the aggregation scheme and PLMN, the anchor WTRU can be executed in parallel with different potential aggregation WTRUs from step 1801 to 1809.

[0405] In one example, the anchor WTRU AS layer can report multiple PLMN values ​​and WTRU aggregation schemes to the NAS 1810. The NAS can then select the optimal combination of PLMNs and aggregations at once. In another example, the WTRU anchor AS layer can report the optimal aggregation scheme for each frequency to the NAS, and the NAS can select a PLMN regardless of the aggregation. Alternatively, the WTRU anchor AS layer can report the optimal aggregation for each frequency to the NAS, and the NAS can select a PLMN regardless of the aggregation. After reporting the PLMN to the AS layer, the anchor WTRU's AS layer selects the aggregation corresponding to the selected and reported PLMN.

[0406] In an alternative embodiment, PLMN selection is performed iteratively, where WTRU can first obtain a high-quality PLMN without aggregation, and if not, it retryes with different aggregation options until a high-quality PLMNRSRP is estimated.

[0407] In an alternative implementation, the PLMN selection of the anchor WTRU can be performed on the aggregate WTRU side instead of on the anchor side (as described in the preceding paragraphs).

[0408] In cases where WTRUs can exchange measurement results, the results can be aggregated, and the output reflects the actual joint processing signal quality or strength. However, exchanging measurement results may require active sidelink transmissions and may introduce latency while waiting for feedback from other WTRUs. In another example, cell / PLMN (re)selection for the aggregating WTRUs can be performed without sharing measurement results. The WTRU evaluates the criteria for cell selection based on its own measurements and an estimate of the aggregated signal. Compared to other embodiments, this embodiment may reduce the accuracy of the aggregated measurements but can improve access latency and reduce the need for active communication.

[0409] Figure 19 A flowchart illustrating an example of a cell / PLMN (re)selection process using estimated aggregated measurement results is shown.

[0410] Anchor WTRUs and aggregation WTRUs can exchange configurations for low-level aggregation used for cell selection (1901). WTRUs can be configured to perform estimations of aggregation measurements (rather than exchanging on-demand measurements). Some WTRU information (such as WTRU location, WTRU-selected cells (if any), WTRU measurements, and SL measurements) may need to be exchanged periodically (e.g., periodically or based on change triggers) to assist anchor WTRUs in performing estimations.

[0411] Information can be exchanged periodically to keep WTRU updated to 1902. This can be based on (pre)configuration.

[0412] The WTRU can check its configured operating mode (which may estimate aggregated WTRU measurements or receive measurement reports from aggregated WTRUs) to perform aggregation-based cell selection. The following assumes that the WTRU is configured to perform selection based on estimated measurements (rather than on-demand measurements).

[0413] Cell selection 1903 can be triggered. The anchor WTRU can perform cell selection measurement 1904 as needed for its cell selection process.

[0414] Anchor WTRUs can evaluate and perform cell selection 1905 based on their measurement results and aggregated WTRU information.

[0415] In one embodiment, when evaluating the S criterion (and subcriterions Srxlev > 0 and Squal > 0), the anchor WTRU can apply an offset to account for an estimated gain in signal strength due to (potential) aggregation. In two different implementations, the offset can be applied to defining the criteria (e.g., Srxlev and Squal) or the measurements themselves (e.g., Qrxlevmeas and Qqualmeas).

[0416] As an example, the offset Qoffset_aggregation can be defined (e.g., set to the RRC parameter for cases with 2 WTRUs in the aggregation, or set to +3dB in the SL aggregation configuration) and used to modify the calculation of Srxlev as follows: Srxlev = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset ) – Pcompensation –Qoffsettemp + Qoffsetaggregation Specific parameters and offset values ​​can be set for different aggregation types or sizes, as well as a portion of the (pre)configured settings. For example, the offset for aggregation of 2 WTRUs can differ from the offset for aggregation of 3 or more WTRUs. The expected signal quality from aggregation with more WTRUs should be better than aggregation with a single aggregation WTRU, so the offset can reflect the expected gain. For example: 1 aggregation WTRU -> +3dB, 2 aggregation WTRUs: +6dB, etc. As another example, parameters and offsets can vary depending on the connection between WTRUs, such as whether the WTRUs use 3GPP NR SL, or other radio or non-radio technologies. Aggregated signal processing can depend on the quality of the inter-UE link (ideal, high bit rate, low bit rate, etc.), and it may potentially affect the gain of the combined signal. Similar principles apply to RSRP and RSRQ evaluations. For example, the expected signal quality from aggregation with more WTRUs may be more accurate than aggregation with a single aggregation WTRU, so the offset can reflect the expected gain. For example, for one aggregated WTRU, the offset can be 3dB, for two aggregated WTRUs, the offset can be 6dB, and so on.

[0417] When the anchor WTRU is aware of the WTRU aggregation conditions, it is preferable to apply an offset to the measurement itself, i.e., modify Qrxlevmeas or include the offset in the measurement processing in a previous step. The offset applied to the measurement can also be cell- and aggregation WTRU-specific.

[0418] For example, the anchor WTRU may have already received an indication of the location of the aggregate WTRU and estimate that the two WTRUs are close to each other (e.g., based on WTRU location / distance or based on SL signal strength or WTRU interconnection pattern); the WTRU may anticipate similar signal strength on its side and thus apply a +3dB gain to its own signal.

[0419] As another example, the anchor WTRU may have already received instructions regarding the serving cells (or selected set of cells) of the aggregation WTRU, and may apply the offset gain only to the measurements of those cells. For instance, if the aggregation WTRU is in a given serving cell, it may be advantageous for the anchor WTRU to select the same serving cell. In this case, an offset that favors the selection of the same cell can be utilized.

[0420] Offset can also include the power level and radio / processing capabilities of the aggregated WTRU, or the difference in power and capability. For example, if the aggregated WTRU has a maximum power that is 6dB higher than the anchor WTRU's maximum power, the anchor WTRU can apply a 6dB gain to its signal.

[0421] For example, an aggregated WTRU can relay its signal or combine its signal with that of an anchor WTRU. If the aggregated WTRU has strong transmit power, its UL signal may be better for relaying or combining signals to selected cells, thus the WTRU can expect a significant signal boost, and therefore the offset used to lower the criterion threshold for cell admission may be beneficial.

[0422] Anchor point WTRUs can perform their cell selection based on (modified) measurement cells and (modified) criteria.

[0423] The anchor point can notify the aggregate WTRU of the selected cell 1906, and the anchor WTRU can reside in cell 1907 as the aggregate WTRU. The aggregate WTRU can reside in the selected cell 1908 as the aggregate WTRU.

[0424] The anchor WTRU can report this selection to the network, while indicating the aggregation configuration and the aggregation WTRU ID 1909.

[0425] In estimating the measurement results of the aggregation used for PLMN selection, a similar process can be applied, where the offset of the criteria in step 5 is now applied to the threshold of the high-quality criteria, i.e., the requirements are lowered so that PLMNs with lower RSRP can be considered.

[0426] If the cell or PLMN is selected to be performed on the aggregated WTRU side, the process can be modified according to the same principle as 16, that is, steps 4 and 5 are performed on the aggregated WTRU side, and the measurement results of the aggregated WTRU are used as a baseline or reference.

[0427] Figure 20 A flowchart illustrating an example of a method for low-level PHY aggregation measurement for anchor point WTRUs is shown.

[0428] In embodiments related to low-level PHY aggregation of measurements, the anchor WTRU can be configured to request, collect, and aggregate measurement results from another WTRU. The anchor WTRU can receive WTRU information and configuration 2001 from the aggregating WTRU. WTRU information and status may include, for example, WTRU capabilities, location, battery level information, interconnection capabilities such as PC5 radio interfaces, radio conditions, PC5 resource availability, measurement accuracy, etc. Configuration may include aggregation triggering (e.g., based on coverage, battery level), processing steps for aggregation (e.g., aggregation after L1 filtering), and aggregation-specific parameters (e.g., L1 and L3 filter weights, accuracy configuration).

[0429] The WTRU can, for example, use SL transmission to transmit to the aggregation WTRU a configuration 2002 for cell / PLMN selection of aggregation measurements. This configuration may include processing steps for aggregation (e.g., transmission after L1 filtering), aggregation-specific parameters (e.g., L1 and L3 filter weights, accuracy configuration).

[0430] The WTRU can transmit an aggregated measurement request 2003 to the aggregated WTRU. This can be triggered by measurements requested during cell selection, cell reselection, or PLMN selection procedures. Measurements may include measurement configurations (e.g., the RS to be measured, processing steps).

[0431] WTRU can perform spectrum measurements and perform preprocessing steps based on configuration (e.g., L1 filters based on configuration and accuracy requirements) 2004.

[0432] The WTRU can receive preprocessed measurement results from the aggregated WTRU, along with indications of the accuracy requirements used (2005).

[0433] WTRU can determine the offset based on the configuration and the received accuracy indication and apply that offset to the received measurement results 2006.

[0434] WTRU can aggregate received measurement results and recover measurement processing 2007. Processing steps for aggregating measurements can be specifically configured (e.g., a specially configured L3 filter).

[0435] WTRU can report aggregated measurement results to the requesting layer / process entity and resume the corresponding process (e.g., cell selection, cell reselection, or PLMN selection) 2008.

[0436] WTRUs can report aggregated measurement results (e.g., aggregated RSRP, selected cell / PLMN) and configuration 2009 to the aggregated WTRU. WTRUs can report aggregated configurations (e.g., aggregated WTRU ID, number of measurements, selected cell / PLMN, and offset parameters) to the network.

[0437] Figure 21 A flowchart illustrating an example of a method for low-level PHY aggregation measurement for aggregation WTRUs is shown.

[0438] The aggregated WTRU can assist the anchor WTRU in performing cell or PLMN selection. The aggregated WTRU can receive measurement requests that include measurement processing configuration and requirements, and report pre-processed measurement results with specific configuration.

[0439] The aggregated WTRU can transmit WTRU information to the anchor WTRU or the network.2101 WTRU information and status may include, for example, WTRU capabilities, location, battery level information, interconnection capabilities such as PC5 radio interfaces, radio conditions, PC5 resource availability, etc.

[0440] The WTRU can receive configuration 2102 for aggregated measurements from the aggregated WTRU (e.g., for cell / PLMN selection) using SL transmission. The configuration may include processing steps for aggregation (e.g., transmission after L1 filtering), aggregation-specific parameters (e.g., L1 and L3 filter weights, accuracy configuration).

[0441] The WTRU can receive an aggregate measurement request from the anchor WTRU, which includes the spectrum 2103 to be scanned.

[0442] The WTRU can perform measurements and apply configured preprocessing / filtering based on the received configuration. Preprocessing (e.g., L1 filter weights) can be based on requests and WTRU capabilities.

[0443] WTRU can perform secondary screening of measurement results based on its signal quality / strength configuration criteria.

[0444] The WTRU can transmit preprocessed measurement results 2105 to the anchor WTRU. The measurement results may include the accuracy of the measurements used. In one implementation, the WTRU sends an indication only if the requested accuracy requirement is not met.

[0445] The WTRU can receive aggregated measurement results and cell / PLMN (re)selection instructions from the anchor WTRU, and optionally change the selected PLMN or the cell 2106 residing thereon.

[0446] Figure 22A flowchart is shown as an example of a cell selection method using low-layer PHY measurement aggregation estimation for anchor point WTRUs.

[0447] Anchor WTRUs can use estimated aggregated measurements to perform cell (re)selection or PLMN selection. Aggregated measurements can be estimated without requesting on-demand measurements, and used to assess the suitability of cell / PLMN selection using specific criteria.

[0448] The anchor WTRU can receive WTRU information and configuration 2201 from the estimated aggregate WTRU. WTRU information and status may include, for example, WTRU capabilities, location, battery level information, interconnection capabilities such as PC5 radio interfaces, radio conditions, PC5 resource availability, etc. The configuration may include estimated aggregation triggers (e.g., based on coverage, battery level), estimated aggregation-specific thresholds, and parameters (e.g., offsets for RSRP / RSRQ).

[0449] The WTRU can perform spectrum measurements for cell (re)selection or PLMN selection processes 2202.

[0450] The WTRU can determine the offset 2203 for measurement evaluation based on the aggregation configuration and WTRU information used for cell / PLMN (re)selection thresholds. In one example, a 3dB offset can be used when the aggregation WTRU is not co-located with the anchor WTRU. In another example, a 3dB offset can be used when the number of antennas of the aggregation WTRU is twice the number of antennas of the anchor WTRU.

[0451] The WTRU can evaluate measurement results and check the cell / PLMN (re)selection criterion 2204. This evaluation can be based on applying the deviation as an offset to the Srxlev / high-quality criterion. Alternatively, an offset (instead of a threshold) can be applied to the measurement results. The WTRU can then verify the suitability of the selected cell and remain in that cell.

[0452] The WTRU can transmit the selected cell (e.g., cell ID, PLMN, frequency, RAT) or PLMN (e.g., PLMN ID, frequency, RAT) to the aggregation WTRU 2205. The WTRU can, for example, transmit the indication and aggregation information of the (re)selected cell / PLMN to the network through a registration process.

[0453] The WTRU can camp on the selected cell and monitor the control channel 2206 of the selected cell, for example, to receive paging / SIB messages.

[0454] Figure 23A flowchart illustrating an example of a measurement aggregation process is shown. A first WTRU can receive WTRU information from a second WTRU, which includes at least one of the following: WTRU capability, WTRU location / positioning, and WTRU battery power information 2301. The first WTRU can receive measurement configuration information 2302 associated with measurement preprocessing from the second WTRU. The measurement configuration information associated with measurement preprocessing may include L1 filter coefficients. The measurement configuration information associated with measurement preprocessing may include information about reference signals to be measured and preprocessed. The measurement configuration information associated with measurement preprocessing may include report timing information, wherein the report timing information includes at least one of the following: one-time report, periodic report, or event-based report.

[0455] The first WTRU may receive a request 2303 from the second WTRU for reporting preprocessed measurement results. The requested preprocessed measurement results may include reference signal received power (RSRP) or reference signal received quality (RSRQ).

[0456] The first WTRU can determine one or more preprocessed measurement results 2304 based at least on measurement configuration information associated with measurement preprocessing. The one or more preprocessed measurement results may include at least one of the following: original measurement samples ( Figure 2 The measurement results after layer 1 filtering (A 201) Figure 2 (A1 203) and beam measurement results after layer 3 filtering ( Figure 2 The “E” in 212), community quality ( Figure 2 The “B” in 205), the filtered cell quality ( Figure 2 The “C” in 207) or RSRP ( Figure 2 (D in 209). The beam measurement results after layer 3 filtering can include one of beam combining, beam selection, and layer 3 beam filtering.

[0457] The first WTRU may send at least one of the one or more preprocessed measurement results 2305 to the second WTRU. The first WTRU may respond to sending at least one of the one or more preprocessed measurement results and receive the aggregated measurement results 2306 from the second WTRU.

[0458] The first WTRU can be a relay WTRU, an aggregated WTRU, or an auxiliary WTRU.

[0459] The second WTRU can be a remote WTRU, an anchor WTRU, or an assisted WTRU.

[0460] 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 any 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 multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method to be performed by a first wireless transmit / receive unit (WTRU), the method comprising: Receive measurement configuration information associated with measurement preprocessing from the second WTRU; At the first WTRU, the preprocessed measurement result is determined at least based on the measurement configuration information; Send one or more preprocessed measurement results to the second WTRU; as well as In response to sending the one or more preprocessed measurement results, aggregated measurement results are received from the second WTRU.

2. The method of claim 1, wherein the measurement configuration information associated with the measurement preprocessing includes information about the reference signal to be measured.

3. The method of claim 1 or 2, wherein the measurement configuration information associated with measurement preprocessing includes report timing information, wherein the report timing information includes at least one of the following: one-time report, periodic report, and event-based report.

4. The method according to any one of claims 1 to 3, wherein the measurement configuration information associated with the measurement preprocessing includes one or more of the following: layer 1 filter coefficients and layer 3 filter coefficients.

5. The method according to any one of claims 1 to 4, wherein the one or more preprocessed measurement results include measurement results filtered by layer 1.

6. The method according to any one of claims 1 to 5, wherein the aggregated measurement results include the results of applying a layer 3 filter at least to the one or more preprocessed measurement results from the first WTRU.

7. The method of claim 6, wherein the layer 3 filter coefficients include one or more layer 3 aggregation filter coefficients, wherein the layer 3 aggregation filter coefficients are configured by the network for measuring aggregation.

8. The method according to any one of claims 1 to 7, further comprising: Receive second WTRU information from the second WTRU, the second WTRU information including at least one of the following: WTRU capability, WTRU location / positioning, and WTRU battery power information.

9. The method according to any one of claims 1 to 8, wherein the first WTRU operates as a relay WTRU and the second WTRU operates as a remote WTRU.

10. The method according to any one of claims 1 to 9, wherein the preprocessed measurement result includes at least one of layer 1 filtered reference signal received power (RSRP) and layer 1 filtered reference signal received quality (RSRQ).

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 the transceiver are configured to: Receive measurement configuration information associated with measurement preprocessing from the second WTRU; At the first WTRU, the preprocessed measurement result is determined at least based on the measurement configuration information; Send one or more preprocessed measurement results to the second WTRU; as well as In response to sending the one or more preprocessed measurement results, aggregated measurement results are received from the second WTRU.

12. The WTRU of claim 11, wherein the measurement configuration information associated with measurement preprocessing includes information about the reference signal to be measured.

13. The WTRU of claim 11 or 12, wherein the measurement configuration information associated with measurement preprocessing includes report timing information, wherein the report timing information includes at least one of the following: one-time report, periodic report, and event-based report.

14. The WTRU according to any one of claims 11 to 13, wherein the measurement configuration information associated with measurement preprocessing includes one or more of the following: layer 1 filter coefficients and layer 3 filter coefficients.

15. The WTRU according to any one of claims 11 to 14, wherein the one or more preprocessed measurements include measurements filtered by layer 1.

16. The WTRU according to any one of claims 11 to 15, wherein the aggregated measurement results include the results of applying a layer 3 filter at least to the one or more preprocessed measurement results from the first WTRU.

17. The WTRU of claim 16, wherein the layer 3 filter coefficients include one or more layer 3 aggregation filter coefficients, wherein the layer 3 aggregation filter coefficients are configured by the network for measurement aggregation.

18. The WTRU according to any one of claims 11 to 17, wherein the at least one processor and transceiver are further configured to receive second WTRU information from the second WTRU, the second WTRU information including at least one of: WTRU capability, WTRU location / positioning, and WTRU battery power information.

19. The WTRU according to any one of claims 11 to 18, wherein the first WTRU operates as a relay WTRU and the second WTRU operates as a remote WTRU.

20. The WTRU according to any one of claims 11 to 19, wherein the preprocessed measurement results include at least one of layer 1 filtered reference signal received power (RSRP) and layer 1 filtered reference signal received quality (RSRQ).

Images