Method and apparatus for enabling WTRU coordination and aggregation of pre-processed measurements

Abstract

The first WTRU may receive a request from the second WTRU to report measurement configuration information associated with measurement preprocessing and preprocessed measurement results. The first WTRU may determine one or more preprocessed measurement results based on at least the measurement configuration information associated with measurement preprocessing. The requested preprocessed measurements may include at least one of filtered reference signal received power (RSRP) or filtered reference signal received quality (RSRQ). The first WTRU may send at least one of the one or more preprocessed measurement results to the second WTRU. In response to sending at least one of the one or more preprocessed measurement results, the first WTRU may receive an aggregated measurement result from the second WTRU. The aggregated measurement result may be the result of applying a Layer 3 filter to at least the preprocessed measurement results determined by the first WTRU. The Layer 3 aggregated filter coefficient may be composed of RRC.

Description

Technical Field

[0001] This application relates to methods and apparatuses for enabling coordinated and aggregated pre-processed measurements for WTRUs.

Background Art

[0002] Cross-Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 506,262, filed Jun. 5, 2023, the content of which is incorporated herein by reference.

[0003] When a wireless transmit / receive unit (WTRU) powers on, it may search for a public land mobile network (PLMN). The selection of a PLMN is performed in the non-access stratum (NAS) layer of the WTRU. Once a PLMN is selected, the WTRU may perform an initial cell selection and search for a suitable cell within the selected PLMN. The selection of a cell is performed by the access stratum (AS) layer of the WTRU. When the AS layer of the WTRU selects a cell, the WTRU may camp on the selected cell. The WTRU may register its presence by means of a NAS registration procedure.

[0004] While in idle mode or non-active mode, the WTRU may perform received signal strength measurements on the selected cell and on neighbor cells. If the WTRU discovers a more suitable cell, it may reselect that cell and camp on it according to cell reselection criteria. The WTRU may also periodically search for a higher priority PLMN. When the NAS layer of the WTRU selects a new PLMN, the AS layer of the WTRU may search for a suitable cell within the newly selected PLMN, reselect to that cell, and camp on it.

[0005] While camp-on to a cell, the WTRU may monitor the cell's control channels to obtain system information and receive paging messages, for example. To be discovered by the network for paging purposes, the WTRU may notify the network of its current location. When re-selecting to another cell, the WTRU may perform a location update based on changes in the tracking area or RAN notification area to which the new cell belongs. [Overview of the project]

[0006] The WTRU spends most of its time in RRC idle / inactive mode, and therefore, the power consumption associated with idle and inactive mode operation can have a significant impact on the WTRU's battery life. Active sensing operations during idle and inactive modes, such as scanning radio channels for PLMN and cell selection and reselection, can be one of the major power drains in these operating modes. Scanning all corresponding frequencies and RATs is also time-consuming, which can further impact the WTRU as it can cause delays when performing PLMN and cell selection and reselection procedures.

[0007] As a wide variety of devices and uses become possible, some aspects of a device (e.g., WTRUs and / or Personal IoT Network (PIN) elements) may be limited by its capabilities, power, energy, or network connectivity. Deploying systems in which devices cooperate and support each other can improve device performance. Devices can form groups of interconnected WTRUs that can share their processing power and communicate directly, typically using wireless communications such as NR sidelinks. Devices can coordinate their procedures and communications to augment each other's performance by aggregating their capabilities (e.g., processing, power, time, and functionality) and assist each other in carrying out tasks and procedures.

[0008] One exemplary use case may involve wearable connected objects, such as in Extended Reality (XR) and / or Augmented Reality (AR) / Virtual Reality (VR) applications, where the device may offload parts of the processing (e.g., audio or video processing) to another, more capable device. Another exemplary use case may be when a WTRU may prefer to conserve power by keeping its primary Uu radio off for a certain period of time. In this example, if relay devices are present in the group, the WTRU may prefer to communicate with the network via the relays while keeping their primary Uu radios off.

[0009] Performing measurements, including collecting and then processing the samples, can be a power-consuming process. To conserve power, devices may leverage each other to perform measurement aggregation. For example, a WTRU may perform measurement aggregation for cell selection, cell re-selection, and / or PLMN selection. A first WTRU may consist of parameters for measurement pre-processing and may acquire measurement results that utilize the pre-processing steps according to its configuration. The first WTRU may share the pre-processed measurement results with a second WTRU. The second WTRU may aggregate measurements, for example, by adding the signal intensity of the received measurements. [Brief explanation of the drawing]

[0010] A more detailed understanding can be obtained from the following explanation, given as an example in conjunction with the attached drawings, where similar reference numbers in the drawings indicate similar elements.

[0011] [Figure 1A] This figure shows an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary WTRU. [Figure 1C] This is a system diagram showing RAN and CN according to one embodiment. [Figure 1D]This is a system diagram showing RAN and CN according to one embodiment. [Figure 2] An example of a measurement model is shown. [Figure 3A] This shows an example of a network that includes multiple personal IoT networks (PINs) and PIN elements. [Figure 3B] This shows an example of a network that includes multiple personal IoT networks (PINs) and PIN elements. [Figure 4] An example of direct communication between WTRUs is shown. [Figure 5] Here are some examples of roles within the WTRU group. [Figure 6] An example of a control plane protocol stack using a cooperative layer is shown. [Figure 7] This shows an example of a control plane protocol stack for coordination using the PC5 interface. [Figure 8] The diagram shows an example of a control plane protocol stack for inter-WTRU support, where one WTRU can use two separate NAS entities for control. [Figure 9] This diagram shows an example of a control plane protocol stack for inter-WTRU support, where one NAS entity can control AS entities of multiple WTRUs. [Figure 10] Examples of logical interfaces that may be used by the solution are shown. [Figure 11] This shows an example call flow for network-based WTRU coordinator selection. [Figure 12] This shows an example call flow for WTRU-based coordinator selection. [Figure 13] This shows an example call flow for network-based aggregated WTRU selection. [Figure 14] This shows an example call flow for autonomous aggregated WTRU selection. [Figure 15] This shows an example call flow for a multi-WTRU aggregate measurement procedure. [Figure 16]Shows a call flow example of sub-layer aggregation for (re)-selection of cells performed by an anchor WTRU. [Figure 17] Shows a call flow example of sub-layer aggregation for (re)-selection of cells performed by an aggregated WTRU. [Figure 18] Shows a call flow example of sub-layer aggregation for selection of a PLMN performed by an aggregated WTRU. [Figure 19] Shows a flowchart example of a (re)-selection procedure for a cell / PLMN using estimated aggregated measurements. [Figure 20] Shows a flowchart example of a method for sub-layer PHY aggregation measurements for an anchor WTRU. [Figure 21] Shows a flowchart example of a method for sub-layer PHY aggregation measurements for an aggregated WTRU. [Figure 22] Shows a flowchart example of a method for cell selection for an anchor WTRU using sub-layer PHY measurement aggregation estimation. [Figure 23] Shows a flowchart example of a measurement aggregation procedure.

Best Mode for Carrying Out the Invention

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

[0013] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 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, but it should be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be called a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, 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 an industrial and / or automated processing chain context), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be called a UE.

[0014] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the 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. For example, base stations 114a and 114b may be transceiver base stations (BTS), next-generation node B such as node B, e-node B (eNB), home node B, home e-node B, g-node B (gNB), new radio (NR) node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0015] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown) such as base station controllers (BSCs), radio network controllers (RNCs), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be called cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. Cells may provide coverage for wireless services to a particular geographic area that may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a 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 for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers per sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

[0017] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement radio technologies such as Universal Mobile Telephone Communication System (UMTS) Terrestrial Radio Access (UTRA) which can establish an air interface 116 using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0019] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which can establish an air interface 116 using NR.

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

[0021] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Advanced High Speed ​​Data Rate (EDGE), and GSM EDGE (GERAN).

[0022] In Figure 1A, base station 114b could be, for example, a wireless router, home node B, home enode B, or access point, and could utilize any suitable RAT to facilitate wireless connectivity in localized areas such as workplaces, homes, vehicles, premises, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, base station 114b and WTRU 102c, 102d could implement radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRU 102c, 102d could implement radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRU 102c, 102d could utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106.

[0023] RAN104 may communicate with CN106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or implement high-level security features such as user authentication. Although not shown in Figure 1A, it should be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN104. For example, in addition to connecting to RAN104, which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0024] CN106 may also act as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing simple telephone services (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) within 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 that may employ the same RAT as RAN104 or a different RAT.

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

[0026] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the above elements while remaining consistent with the embodiment.

[0027] The processor 118 may be a general-purpose processor, a dedicated 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. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, and the transceiver 120 may be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0030] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate over multiple RATs, such as NR and IEEE 802.11.

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

[0032] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to 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.), a solar cell, a fuel cell, etc.

[0033] The processor 118 may also be coupled to a GPS chipset 136 which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, 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 nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while remaining consistent with the embodiment.

[0034] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, e-compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripherals 138 may include one or more sensors. The sensors may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biosensor, humidity sensor, etc.

[0035] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of the signal (associated with a particular subframe for both UL (for transmission) and DL (for reception)) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference through signal processing either through hardware (e.g., chokes) or a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of the signal (associated with a particular subframe for either UL (for transmission) or DL ​​(for reception)).

[0036] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0037] RAN104 may include enodes B160a, 160b, and 160c, but it should be understood that RAN104 may include any number of enodes B while remaining consistent with the embodiment. Each of enodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, enodes B160a, 160b, and 160c may implement MIMO technology. Thus, enode B160a may, for example, use multiple antennas to transmit and / or receive wireless signals from WTRU102a.

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

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

[0040] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway for the initial attachment of WTRU102a, 102b, and 102c. The MME162 may also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0041] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions such as anchoring the user plane during handover between e-nodes B, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0042] SGW164 may be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0043] CN106 can facilitate communication with other networks. For example, CN106 can give WTRU102a, 102b, and 102c access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional fixed communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can give WTRU102a, 102b, and 102c access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0044] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in some typical embodiments where such a terminal may be used (for example, temporarily or permanently), wired communication is considered to interface with the communication network.

[0045] In a typical embodiment, the other network 112 may be a WLAN.

[0046] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with a distribution system (DS) or another type of wired / wireless network that carries traffic entering and leaving the BSS. Traffic originating from outside the BSS to an STA may arrive through an AP and be sent to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to an AP for delivery to its respective destination. Traffic between STAs within the BSS may be sent through an AP, for example, here, a source STA may send traffic to an AP, and the AP may send traffic to a destination STA. Traffic between STAs within the BSS is considered and / or sometimes referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (e.g., directly between them) using a Direct Link Setup (DLS). In some typical embodiments, the DLS may be an 802.11e DLS or an 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or using IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to herein as the “ad-hoc” communication mode.

[0047] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by an STA to establish a connection with the AP. In some typical embodiments, Carrier Sensitivity Multiple Access / Collision Avoidance (CSMA / CA) may be implemented in, for example, an 802.11 system. In CSMA / CA, an STA, including the AP (e.g., any STA), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA may backoff. One STA (e.g., just one station) may transmit at a given time in a given BSS.

[0048] A high-throughput (HT) STA may use a 40MHz wide channel for communication via a combination of primary 20MHz channels, for example, with adjacent or non-adjacent 20MHz channels, in order to form a 40MHz wide channel.

[0049] Extremely high throughput (VHT) STAs may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels may be formed by combining consecutive 20 MHz channels. 160 MHz channels may be formed by combining eight consecutive 20 MHz channels, or by combining two discontinuous 80 MHz channels, sometimes referred to as an 80+80 configuration. In an 80+80 configuration, data may be passed through a segment parser that can split the data into two streams after channel coding. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately for each stream. Streams may be mapped onto two 80 MHz channels, and data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be sent to a media access control (MAC).

[0050] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for some and / or limited bandwidths (e.g., support only that much). MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0051] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the primary channel may be 1MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1MHz mode. Carrier detection and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to the AP, all available frequency bands may be considered busy, even if the majority of the available frequency band remains idle.

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

[0053] Figure 1D is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0054] RAN104 may include gNB180a, 180b, and 180c, but it should be understood that RAN104 may include any number of gNBs while remaining consistent with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may utilize beamforming to transmit and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may use multiple antennas to transmit and / or receive wireless signals from, for example, WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0055] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, cells, and / or parts of the wireless transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or lasting for varying lengths of absolute time).

[0056] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with / connect to gNB180a, 180b, and 180c while also communicating with / connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, enodes B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0057] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, interconnection 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. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0058] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. While the above elements are shown as part of CN106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0059] AMF182a and 182b may be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N2 interface and may function as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating non-accessible layer (NAS) signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on High Reliability Low Latency (URLLC) access, services relying on Extended Massive Mobile Broadband (eMBB) access, and services with MTC access. AMF182a, 182b may provide control plane functionality for switching 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.

[0060] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure traffic routing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating IP addresses for UEs, 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.

[0061] UPF184a, 184b may be connected to one or more of the gNB180a, 180b, 180c in RAN104 via an N3 interface that can give WTRU102a, 102b, 102c access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184a, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0062] CN106 can facilitate communication with other networks. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 may grant WTRU102a,102b,102c 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, WTRU102a,102b,102c may be connected to local DN185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b and an N6 interface between UPF184a,184b and DN185a,185b.

[0063] In view of Figures 1A to 1D and the corresponding descriptions of Figures 1A to 1D, one or more or all of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, e-nodes B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0064] Emulation devices may be designed to perform one or more tests on other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one, several, or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communications network to test other devices in a communications network. One or more emulation devices may perform one, several, or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communications network. Emulation devices may be directly coupled to another device to be tested and / or to perform tests using over-the-air wireless communications.

[0065] One or more emulation devices may perform one or more functions, including all of the above, without being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario in a test laboratory and / or an undeployed (e.g., for testing) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. To transmit and / or receive data, the emulation device may use direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas).

[0066] WTRUs implementing 3GPP wireless RATs, including 2G, 3G, 4G, and / or 5G radio access technologies (RATs), may perform location registration, including PLMN selection, cell selection / reselection, and tracking area update procedures, while in RRC_IDLE mode or RRC_INACTIVE mode. 5G devices may also support RAN notification area (RNA) updates and operation in the RRC_INACTIVE state.

[0067] When the WTRU is switched on, the PLMN is selected by the WTRU. For the selected PLMN, the associated RAT may be configured. In cell selection, the WTRU may search for a suitable cell for the selected PLMN, select a cell to provide available services, and monitor its control channels. The WTRU may register the presence of the selected cell by the NAS registration procedure in the tracking area of ​​the selected cell.

[0068] While in RRC_IDLE, the WTRU can perform received signal strength measurements against serving and / or neighbor cells. The WTRU may discover a more suitable cell according to cell reselection criteria, reselect that cell, and camp on to it. If this new cell does not belong to at least one tracking area to which the WTRU is registered, the WTRU may initiate a location registration procedure. The WTRU may search for higher-priority PLMNs at regular time intervals. If different PLMNs are selected by the WTRU's NAS layer, the WTRU may search for a suitable cell among the new PLMNs.

[0069] If a WTRU loses coverage of a registered PLMN, a new PLMN may be automatically selected by the WTRU. Optionally, a display of available PLMNs may be provided to the user via the WTRU so that the user can perform a manual selection. For the network, there are control mechanisms to prioritize cell selection to specific RATs, mechanisms to control the frequency with which low-mobility, medium-mobility, or high-mobility WTRUs perform cell re-selection, and mechanisms to prohibit WTRU re-selection to specific tracking areas.

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

[0071] The WTRU can scan all RF channels in the NR band according to its capabilities to discover available PLMNs and available CAGs. On each carrier, the WTRU generally searches for the strongest cell, reads the cell's system information to discover which PLMN the cell belongs to and any associated cell access group (CAG). When operating with shared spectral channel access, the WTRU can also read system information for multiple strongest cells. If the WTRU can read one or more PLMN identification information in the strongest cell, or in multiple strongest cells when operating with shared spectral channel access, each discovered PLMN may be reported to the NAS as a high-quality PLMN (without an RSRP value), provided that the following high-quality criteria are met, and any associated CAG-ID may be reported. For NR cells, the measured Reference Signal Received Power (RSRP) value is -110 dBm or higher.

[0072] PLMNs found that do not meet the high-quality standards but whose PLMN identification information the WTRU was able to read are reported to the NAS along with their corresponding RSRP values ​​and any associated CAG-IDs. The quality metric reported to the NAS by the WTRU will be the same for each PLMN found in a single cell.

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

[0074] After the WTRU has selected a PLMN, a cell selection procedure may be performed to allow the WTRU to select a suitable cell in that PLMN for camp-on.

[0075] Home PLMN: This is a PLMN whose MCC and MNC in the PLMN identification information match the MCC and MNC of the IMSI according to known matching criteria.

[0076] EHPLMN: Any of the PLMN entries included in the Equivalent HPLMN list.

[0077] Equivalent HPLMN List: To enable the provision of multiple HPLMN codes, PLMN codes present in this list replace HPLMN codes derived from IMSI for the purpose of PLMN selection. This list is stored on USIM and is known as the EHPLMN list. The EHPLMN list may also contain HPLMN codes derived from IMSI. If an HPLMN code derived from IMSI does not exist in the EHPLMN list, it is treated as the destination PLMN for the purpose of PLMN selection.

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

[0079] A WTRU typically operates on its home PLMN (HPLMN) or equivalent home PLMN (EHPLMN). However, if, for example, the WTRU loses coverage, a destination PLMN (VPLMN) may be selected. There are two modes for PLMN selection. In automatic mode, the WTRU may have access to a list of PLMN / access technology combinations in order of priority. The highest priority PLMN / access technology combination that is available and acceptable is selected. In manual mode, the WTRU may show the user which PLMNs are available. Only when the user makes a manual selection will the WTRU attempt to obtain normal service on the VPLMN.

[0080] Cell selection can be either initial cell selection (for example, without prior knowledge of which RF channels are NR frequencies) or cell selection that leverages existing information.

[0081] During initial cell selection, the WTRU may scan all RF channels in the NR band according to its capabilities to find a suitable cell. On each frequency, the WTRU may search for the strongest cell (except when using shared spectral channel access, which allows the WTRU to search for the next strongest cell). Once the WTRU finds a suitable cell, it may be selected.

[0082] In cell selection using stored information, the WTRU uses stored frequency information and, optionally, cell parameter information from previously received measurement control information elements or from previously detected cells. If the WTRU finds a suitable cell, that cell may be selected. If no suitable cell is found, the initial cell selection procedure may be initiated.

[0083] The NAS can control the RATs under which cell selection must be performed, for example, by indicating the RAT associated with the selected PLMN, and by maintaining a list of prohibited registration areas and a list of equivalent PLMNs.

[0084] WTRU may perform measurements for the purpose of cell selection and reselection. WTRU may select a suitable cell based on RRC_IDLE or RRC_INACTIVE status measurements and cell (re)selection criteria.

[0085] In the case of cell reselection, to limit the number of measurements required of the WTRU, the WTRU first verifies whether several conditions are met. If the conditions are met, the WTRU may begin performing measurements in the neighbor cell.

[0086] When evaluating the Srxlev and Squal of a non-serving cell for reselection evaluation purposes, the WTRU may use the parameters provided by the serving cell. In the final check of the cell reselection criteria, the WTRU may use the parameters provided by the target cell.

[0087] When camped on to a cell, the WTRU may periodically search for a better cell according to the cell reselection criteria. If a better cell is found, the WTRU may reselect that cell. A change in cell may imply a change in RAT.

[0088] For example, the cell selection criterion S may be satisfied in the following cases:

[0089] Srxlev > 0 and Squal > 0, where,

[0090] Here,

[0091] Srxlev is the RX level value (in dB) for cell selection and is determined as follows:

[0092] Srxlev = Qrxlevmeas - (Qrxlevmin + Qrxlevminoffset) - Pcompensation - Qoffsettemp, where,

[0093] Qrxlevmeas: The RX level value of the cell (reference signal received power, RSRP). Measured by WTRU.

[0094] Qrxlevmin: The minimum required RX level (dBm) within a cell. Composed of RRC.

[0095] Qrxlevminoffset: The offset used when camping in a VPLMN and searching for a higher-priority PLMN. Consists of RRC.

[0096] Pcompensation: If FR1: Depends on the power class of the WTRU and is composed by RRC. If FR2=0.

[0097] Qoffsettemp: An offset temporarily applied to a cell. Consists of RRC.

[0098] Qrxlevminoffset: The offset used when camping in a VPLMN and searching for a higher-priority PLMN. Consists of RRC.

[0099] Qrxlevminoffsetcell: A cell-specific offset added to the corresponding Qrxlevmin to achieve the minimum required RX level in the cells involved. It is composed of RRC.

[0100] Squal is the quality value (in dB) of cell selection and is determined as follows:

[0101] Squal=Qqualmeas-(Qqualmin+Qqualminoffset)-Qoffsettemp

[0102] Qqualmeas: Cell quality value (reference signal reception quality, RSRQ). Measured by WTRU.

[0103] Qqualmin: The minimum required quality level (dB) within a cell. It is composed of RRCs.

[0104] Qqualminoffset: The offset used when camping in a VPLMN and searching for a higher-priority PLMN. Consists of RRC.

[0105] Qoffsettemp: An offset temporarily applied to a cell. Consists of RRC.

[0106] The absolute priority of different NR frequencies or inter-RAT frequencies can be given to the WTRU in system information, in RRC release messages, or by inheriting from another RAT during (re)selection of cells between RATs. In the case of system information, NR frequencies or inter-RAT frequencies can be listed without assigning priority (i.e., the field cellReselectionPriority is not present for those frequencies).

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

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

[0109] Cell reselection on NR frequencies of equal priority is based on the ranking for cell reselection within the frequency.

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

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

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

[0113] A device, e.g., the WTRU, may 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.

[0114] The synchronization signal (SS) reference signal received power (SS-RSRP) is defined as the linear average over the power contribution ([W] unit) of the resource elements carrying the secondary synchronization signal.

[0115] SS-RSRP can only be measured with reference signals corresponding to SS / PBCH blocks that have the same SS / PBCH block index and the same physical layer cell identification information. If SS-RSRP is not used for L1-RSRP and the upper layer indicates several SS / PBCH blocks for performing SS-RSRP measurements, SS-RSRP will only be measured from the indicated set of SS / PBCH blocks.

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

[0117] The Second-Order Synchronization-Referenced Signal Received Quality (SS-RSRQ) is defined as the ratio N × SS-RSRP / NR Carrier Received Signal Strength Indicator (RSSI), where N is the number of resource blocks in the RSSI measurement bandwidth of the NR carrier. The measurements in the numerator and denominator are performed over the same set of resource blocks.

[0118] Figure 2 shows an example of a measurement model.

[0119] For measurement processing, two types of filters may be involved: a Layer 1 filter and a Layer 3 filter. These are described herein and applied during the sequence as shown in Figure 2.

[0120] Layer 1 (L1) filtering involves processing the raw measurement sample. The type of processing can vary between devices (i.e., it is not standardized). This may involve averaging samples taken over a certain time period, averaging a given number of samples, or performing a moving average. This filtering is performed directly on the measurement sample collected by the physical layer (i.e., Layer 1) within the device. The results are referred to as Layer 1 filtered measurement results.

[0121] Layer 3 (L3) filtering involves processing Layer 1 filtered measurement results. A device may apply Layer 3 filtering using Layer 3 filtering coefficients provided by the network via RRC signaling. These Layer 3 filtering coefficients may be coefficients used in the formula / function applied to the Layer 1 filtered measurement results. The result is called the Layer 3 filtered measurement result. The device may report the Layer 3 filtered measurement result to the network.

[0122] Layer 3 filters are sometimes called RRC-configured filters.

[0123] As shown in Figure 2, beam-specific sample (A) may represent a measurement inside physical layer 201. Beam-specific sample (A) may be an input to layer 1 filtering 202. The exact filtering may vary depending on the chosen implementation. The processing used to perform the physical measurement may vary (for example, input A and layer 1 filtering may be implementation-specific).

[0124] The output A1 203 of the Layer 1 filtering can be reported to Layer 3 211 by Layer 1.

[0125] Beam integration / selection 204 may be used to integrate beam-specific measurements to derive cell quality 205. The behavior of beam integration / selection 204 may be standardized, and the configuration of this module may be given by RRC signaling. Cell quality B 205 may be derived from beam-specific measurements reported to layer 3 after beam integration / selection 205. The reporting period in B 205 may be equal to one measurement period in A1 203.

[0126] Further layer 3 filtering 206 for cell quality 205 may be performed for the measurement given at point B 205. The behavior of the layer 3 filter may be standardized, and the configuration of the layer 3 filter may be given by RRC signaling. The filtering reporting period at C 207 may be equal to one measurement period at B 205.

[0127] After measurement, the results are processed by a Layer 3 filter represented by C 207 in Figure 2. The reported rate may be the same as the reported rate at point B 205. This measurement can be used as input for one or more evaluations of reporting criterion 208.

[0128] The evaluation of reporting criterion 208 may be a process of verifying whether a measurement report is required at point D 209. The evaluation may be based, for example, on a flow of two or more measurements at reference point C 207 for comparison between different measurements. This is indicated by inputs C 207 and C1 210. WTRU may evaluate the reporting criterion each time a new measurement result is reported at least at point C 207 or C1 210. The reporting criterion may be standardized, and its configuration may be given by RRC signaling (e.g., WTRU measurement reporting configuration).

[0129] D209, shown in Figure 2, represents measurement report information sent over the wireless interface (for example, via message).

[0130] L3 beam filtering 211 may be performed for measurements given at point A1 203 (for example, for beam-specific measurements). The beam filter behavior may be standardized, and the beam filter configuration may be given by RRC signaling. The filtering reporting period at E may be equal to one measurement period at A1.

[0131] E 212 represents measurements after processing in the L3 beam filter 211 (e.g., beam-specific measurements). These measurements are associated with K beams 215. The reporting rate may be the same as the reporting rate at point A1 203.

[0132] The beam selection process 213 may result in the selection of X beams 214 from among K beams 215 given at point E 212, and a measurement at point F 216. The beam selection behavior can be standardized, and the configuration of this module can be given by RRC signaling.

[0133] F 216 represents beam measurement information included in the measurement report (for example, sent) over the wireless interface.

[0134] Layer 1 filtering may employ averaging of a certain level of measurements. Exactly how and when the required measurements for WTRU are performed is specific to the implementation and may be based on several predetermined performance requirements for the output in B 205. The Layer 3 filtering and associated parameters for cell quality 206 ideally do not introduce any delay in sample availability between B 205 and C 207. C1 210 is the input used in event evaluation for reporting criteria 208. The L3 beam filtering and associated parameters ideally do not introduce any delay in sample availability between E 212 and F 216.

[0135] Measurements are subject to accuracy considerations, as is well known, where accuracy requirements are defined for absolute and relative measurements of RSRP and RSRQ for different scenarios, such as depending on the frequency range, operating mode, and / or temperature.

[0136] The described use cases can utilize various connectivitys between WTRUs, including NR sidelinks via licensed or unlicensed bands, and WTRUs connected through a network including an NR Uu. Furthermore, a device such as a WTRU may have multiple radios, one dedicated to direct connections between WTRUs (e.g., sidelinks) and another dedicated to the network (Uu). A group of WTRUs may be formed using sidelink connections between users, while only a portion of the group's users may activate the Uu radio.

[0137] Personal IoT Networks (PINs) and Customer Home Networks (CPNs) provide local connectivity between WTRUs and / or non-3GPP devices. A PIN element via an eRG or a PIN element with gateway capabilities can provide access to 5G network services to WTRUs and / or non-3GPP devices on a CPN or PIN. CPNs and PINs generally share the characteristic of being owned, installed, and / or (at least partially) configured by customers of a public network operator.

[0138] A customer premises network (CPN) is a network located within a premises (e.g., a residence, office, and / or store). A CPN may be provided with connectivity to a 5G network via an advanced residential gateway (eRG). The eRG may be connected to the 5G core network via wireline, wireless, or hybrid access. A premises radio access station (PRAS) is a base station installed within the CPN. Through the PRAS, a work-to-use unit (WTRU) can gain access to the CPN and / or 5G network services. The PRAS may be configured to use licensed, unlicensed, or both frequency bands. Connectivity between the eRG and WTRU, non-3GPP devices, or the PRAS may use any suitable 3GPP or non-3GPP technology (e.g., Ethernet, optical, WLAN).

[0139] A personal IoT network (PIN) includes PIN elements that communicate using direct PIN connectivity or direct network connectivity and is managed locally (using a PIN element with management capabilities). A PIN includes at least one PIN element with gateway capabilities and at least one PIN element with management capabilities. Examples of PINs include networks of wearable and smart home / smart office devices.

[0140] A PIN element may have access to 5G network services via a PIN element with gateway capabilities. Using a PIN element with gateway capabilities, a PIN element may be able to communicate with other PIN elements that are not within the scope of using a direct PIN connection.

[0141] A PIN element with management capabilities is a PIN element that provides an authenticated administrator with a means to configure and manage PINs.

[0142] Figure 3 shows an example of a network comprising multiple personal IoT networks (PINs) and PIN elements.

[0143] Use cases may include wearable connected objects in Extended Reality (XR) and / or Augmented Reality (AR) / Virtual Reality (VR) applications, where devices may offload processing (e.g., audio, video) to more capable devices. Devices may form a group of interconnected WTRUs that can share their processing power and may require communication, generally as wireless communication such as NR sidelinks. Industrial network and Industrial IoT (IIoT) use cases may leverage a framework of WTRU coordination / aggregation, where devices such as sensors may be interconnected for redundancy or reliability, for example.

[0144] WTRUs can be grouped together to support each other and improve device performance. Generally, higher-capacity devices can help lower-capacity devices perform some steps or relay signals from higher-capacity devices. Motivations can range from device hardware (smaller form factor, lower cost devices, limited hardware) to energy considerations (low-power or low-battery devices may reduce their capacity to conserve power) or even to support improvements in coverage and reliability.

[0145] WTRU aggregation can refer to a relay solution with specific multipath properties. This multipath relay solution can be used for WTRU aggregation, where a WTRU connects to the network via two links: via a direct path and via another WTRU using a prolietary (non-standard) WTRU-to-WTRU interconnect. WTRU aggregation aims to provide applications where high UL bitrates are required on 5G terminals, particularly when a normal WTRU is too limited by UL WTRU transmit power to achieve the bitrate required at the edge of the cell. Furthermore, WTRU aggregation can improve reliability and stability and reduce service latency. If the channel state of a terminal is degraded, another terminal may be used to compensate for the instability in traffic performance caused by the fluctuations in channel state.

[0146] In an aggregation context, the anchor WTRU is a WTRU that is the source or destination of traffic and payload data that can use the aggregation WTRU as a relay. The anchor WTRU may or may not have a direct connection to the network. The aggregation WTRU is a WTRU that assists / helps the anchor WTRU access the network. In the context of NR sidelink (SL) relay, the anchor WTRU may correspond to a remote WTRU, and the aggregation WTRU may correspond to a relay WTRU. To support the anchor WTRU, the aggregation WTRU may need to camp / connect to the anchor WTRU's serving cell, which may not be the same as its own serving cell.

[0147] A remote WTRU can be outside of network coverage. A relay WTRU can be within network coverage and may be capable of relaying traffic between the network and the remote WTRU.

[0148] The aggregation of WTRUs may involve scenarios where WTRU coordination enables functionality beyond simple relaying. WTRUs can aggregate their capabilities (processing, power, time, and functionality) to help each other perform tasks and procedures.

[0149] In the following detailed explanation, the terms “aggregated WTRU” and “supporting WTRU” may be used interchangeably, and the terms “anchor WTRU” and “supported WTRU” may be used interchangeably.

[0150] Embodiments including procedures, signaling, and configurations for coordinating and aggregating measurements between WTRUs in RRC idle or INACTIVE mode describe how to enable lower-layer aggregation of measurements for joint signal processing between aggregated WTRUs, how to process and evaluate received measurements for (re)selection of cells and PLMNs, and how to enable lower-layer aggregation-based cell and PLMN selection without measurement feedback by estimating the aggregation gain for the measurements.

[0151] WTRUs can be configured to assist each other in conducting measurements for PLMN selection, cell selection, and cell reselection. Measurements from WTRUs and their supporting / aggregated WTRUs can then be used for evaluation and selection procedures, along with certain biases to account for the fact that some measurements are not performed locally.

[0152] One example of the application of the described solution is when a WTRU is equipped with multiple radios, e.g., NR SL + NR Uu, and sidelinks are already in use for aggregation / grouping purposes (e.g., application / user needs), while coordination can be used to conserve energy in the WTRU by avoiding turning on the primary Uu radio whenever possible.

[0153] As described, both the supporting WTRU and the supported WTRU perform measurements, and these measurements can be combined / aggregated (e.g., using joint signal processing) to obtain improved signal strength and leverage the capabilities of the supporting WTRU. In a typical case, the anchor / supported WTRU may request the aggregating WTRU to perform measurements. The aggregating WTRU may perform the measurements and transfer them to the anchor WTRU. The anchor WTRU may, in some cases, aggregate the measurements using a dedicated processing step and use the aggregated measurements to perform the requested procedure, e.g., PLMN or cell (re)selection. Signal aggregation can improve signal quality, allow the anchor WTRU to increase its coverage, and reduce the time required to find a suitable cell.

[0154] Measurement aggregation: Measurement aggregation can be performed in various ways, for example, by adding raw measurement samples, adding the absolute power values ​​of raw measurement samples, adding filtered measurement results, or adding the absolute power values ​​of filtered measurement samples. As an example, RSRP values ​​in the linear region may be added. In other examples, RSRP and RSSI values ​​may first be combined / added, and then the RSRQ value may be determined based on the combined RSRP and RSSI.

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

[0156] WTRU may include its own measurement results during aggregation.

[0157] By aggregating measurements, diversity gain can be achieved. For example, a supported WTRU can aggregate measurements received from a supporting WTRU with its own measurements. Assuming similar channel states for both WTRUs, a gain of approximately 3 dB may be observed in this case. If the supported WTRU aggregates with more measurements from the supporting WTRU, the gain can be higher, and with similar channel states, a gain of approximately 6 dB may be observed for four WTRUs. Since it is unlikely that the channel states will be the same, these are merely theoretical examples to illustrate the concept.

[0158] The solutions described may be applied via either the authorized or unauthorized spectrum, depending on the procedure. Cell and PLMN selection procedures may be performed when the WTRU has not yet camped or connected to a cell and therefore may not have a network configuration. One example is the case of an NR sidelink in the unauthorized band, where the WTRU may communicate without network configuration or coverage (e.g., using autonomous resource allocation, e.g., Mode 2). In the case of an NR sidelink using the authorized spectrum, the network may configure when measurements may be performed in the case of a cell reselection or when coordination may be used for a PLMN when searching for a higher-priority PLMN after a PLMN has already been selected. Cell selection may also be triggered by a state transition, e.g., the reception of an RRC release message which may contain network information.

[0159] An example using 3GPP technology (e.g., 5G NR) is given. In a variant of the solution, communication between WTRUs may be carried out using non-3GPP communication such as Wi-Fi or Bluetooth.

[0160] An example of aggregation between two WTRUs is given. Similar aggregation with more WTRUs is also assumed using the same methods and procedures described.

[0161] WTRU aggregation can be carried out using inter-WTRU connections such as PC5 (Sidelink) or any other communication system such as Wi-Fi, Bluetooth, or wired connections. NR Sidelink is used to help illustrate the concept, but any other inter-WTRU interface may be used.

[0162] WTRUs may or may not be within network coverage, and network connectivity may not require direct WTRU aggregation.

[0163] Figure 4 shows an example of direct communication between WTRUs. As shown in the figure, the WTRU can be either within network coverage 401 or outside network coverage 402.

[0164] In some cases, such as in personal IoT networks (PINs), tethered devices (e.g., XR, wearables), industrial IoT devices, or interactive services, devices may need to communicate with each other about services or applications they are interested in. Groups of devices may be formed based on services or applications, where devices may communicate with each other and may also have network connectivity. In application or service-oriented groups, WTRUs within the group may be selected and managed by the service / application in higher layers. Group formation communication exchange may be configured during the PC5 connection establishment phase or after a connection has been established using PC5-RRC or PC5-signaling (PC5-S) type signaling.

[0165] A group of WTRUs can be static (e.g., fixed size and devices within the group) or dynamic, where WTRUs can be added and removed depending on deployment, devices, and services.

[0166] Depending on the purpose of the group, several requirements, such as performance requirements and connectivity between WTRUs within the group, may be configured.

[0167] For example, one possible connectivity requirement is that a group (or part of a group) can be served by the same cell, the same gNB, or the same PLMN. This requirement may be useful for devices that support multipath (Uu and SL) but do not support being relayed by WTRUs that are not served by the same cell. This may also be a network requirement to facilitate the management and communication of WTRUs between gNBs or without roaming exchanges.

[0168] Figure 5 illustrates an example of a WTRU's role within a group. Within a group, WTRUs can have different roles depending on the hierarchy between them. In one example, a WTRU might be considered a peer within group 501. In this case, there would be no user managing other users. Cooperation within a group involves sharing information, requesting assistance, or transferring data or control information to each other.

[0169] In another example 502, a WTRU coordinator 503 is connected to another WTRU 504. The device of coordinator 503 may take on the role of manager, coordinator, or controller for the other device 504. A coordinator WTRU may be connected to other devices and may centralize information distribution among WTRUs. A WTRU coordinator may be used to centralize decisions and information within a group and to offload tasks or procedures. A WTRU coordinator can facilitate coordination among other WTRUs and coordination of itself with other WTRUs. When a coordinator WTRU is present, a direct WTRU-to-WTRU coordination link 505 between the two WTRUs performing coordination may not be necessary 506.

[0170] Within a group of WTRUs, one WTRU may take on the role of a Coordinator WTRU. This device is responsible for coordinating the group's WTRUs to perform tasks jointly or on behalf of the other WTRUs in the group. The Coordinator WTRU may also provide network connectivity to the group's WTRUs (for example, as a relay or gateway). The Coordinator WTRU may need to have the ability to implement coordination, including strong connectivity with the other WTRUs in the group.

[0171] In particular, when there is no direct connection between the WTRUs performing the coordination, WTRU information to be shared among the group of WTRUs may be transmitted through a coordinator WTRU. Information may also be shared over the network (for example, through the Uu interface, or through RRC or higher-layer signaling).

[0172] A coordinating WTRU may receive coordination information from WTRUs and transmit it to the corresponding destination. A coordinating WTRU may also store coordination information to share with users later upon request. WTRUs may request information from a coordinating WTRU regarding a specific WTRU associated with a group or information corresponding to that information.

[0173] Coordination between WTRUs requires specific procedures and implementation capabilities. Some devices may implement the necessary features to act as group coordinators, and these features may be represented by specific WTRU categories or WTRU classes.

[0174] Figure 6 shows an example of a control plane protocol stack using a coordinating layer. In this example, the WTRU's coordinating layer 601 communicates directly via PC5 communication.

[0175] The PC5-Collab interface may, in some cases, be a dedicated interface with a dedicated SRB for exchanging coordination information. Alternatively and compatible, PC5-Collab may use PC5 signaling (PC5-S) or SL RRC messages (PC5-RRC).

[0176] One of the purposes of the coordinating layer is to enable coordination and communication between layers of the protocol stack for both the non-access layer (NAS) and access layer (AS) control planes of different WTRUs. Each layer performs its own tasks regarding connectivity, data transmission, and data reception. The coordinating capabilities added to the WTRU can act as inputs that will be used in the tasks, procedures, and decisions performed by each layer of the WTRU.

[0177] Figure 7 shows an example of a control plane protocol stack for coordination using the PC5 interface. In this example, using the 3GPP architecture and sidelinks for communication between WTRUs, both the Uu AS 701 and NAS 702 of the WTRU may communicate and exchange messages with each other via the PC5-Collab / sidelink 703. At the Uu AS level, communication between WTRUs can take place between any Uu layers such as PHY, MAC, RLC, PDCP, or RRC through the coordination layer 703. The coordination layer can communicate internally (e.g., via the NAS layer) directly or indirectly with all Uu AS layers within a given WTRU. Optionally, more distributed methods may be used, as discussed previously.

[0178] For example, WTRU1 may offload one or more tasks to the Uu AS of WTRU2, or WTRU1 may divide a task into subtasks and offload the subtasks to the AS of WTRU2. The offload decision may be made in the WTRU1 NAS or WTRU1 AS, or in the WTRU cooperation layer, using input from the Uu layer. Alternatively, the AS of WTRU2 may be used to perform several tasks on behalf of WTRU1, while it can still operate and perform its own procedures (e.g., procedures associated with WTRU2), in which case it may be directed by its own NAS for those procedures.

[0179] Before implementing coordinated procedures, WTRUs may exchange signaling to configure how they can coordinate their respective capabilities and communication channels.

[0180] The coordinating configuration may include information such as available RATs, supported bandwidth / carriers, Uu and SL capabilities, WTRU profiles (WTRU type, power profile), and coordinating capabilities, i.e., which procedures are supported to coordinate, and which information requests or sharing are supported.

[0181] A WTRU can use PC5 to send transmissions directly to users in its group using unicast, groupcast, or broadcast transmissions. Transmissions can be periodic or aperiodic depending on the content of the transmission.

[0182] The coordinating configuration may include scheduling or opportunities in which the WTRU is expected to send or receive coordinating signaling, for example, using periodic or dynamic scheduling or signaling.

[0183] One WTRU can request information from another WTRU, and in the corresponding layer of the coordination, it can send the request via PC5-Collab and receive a response / report on the same PC5-Collab. For example, the request could be a Layer 1 measurement of a reference signal exchanged between the PHY layers of WTRUs or a Layer 3 measurement of a reference signal exchanged between the RRC layers of WTRUs.

[0184] A request may be for a one-time report or may be able to trigger periodic / aperiodic reporting (i.e., subscribing to collaborative content). Upon receiving a request, a WTRU may respond with information to report, if available (and possibly after performing some relevant steps). A WTRU may report to the requesting WTRU. When a WTRU is registered for a particular periodic collaboration, the WTRU may report to the requesting / registered WTRU periodically or triggered by information updates.

[0185] Figure 8 shows an example of a control plane protocol stack for inter-WTRU support, where one WTRU may use two separate NAS entities for control. Figure 8 uses an example of a 3GPP sidelink inter-WTRU connection, where the NAS of WTRU1 801 may use two different Uu ASs in WTRU2 803 to perform a task. The NAS layer in WTRU1 801 may offload the task to the Uu AS803 of WTRU2, or WTRU1 may divide the task into subtasks and offload the subtasks to the AS803 of WTRU2. The offload decision may be made through the WTRU coordination layer by WTRU1 NAS 801, WTRU1 AS802, or both.

[0186] Compared to the architecture described earlier, in Figure 7, one WTRU can also request other WTRUs to perform a selected task on its behalf. Considering an example of a 3GPP sidelink for the connection between WTRUs, here, the NAS of WTRU1 is using the ASs of two different WTRUs to perform the task, or using the AS of another user to perform (part of) the task.

[0187] Similar operations can be applied to different layers of the AS. The AS of WTRU2 803 is used to perform some tasks on behalf of WTRU1, but it still operates its own tasks and procedures and can be directed by its own NAS804.

[0188] Collaborating WTRUs can first coordinate their NAS and AS configurations, such as available RATs, supported frequencies, and procedures. WTRU1's NAS can send commands to WTRU2's AS using PC5-Collab, and WTRU2 can perform the requested procedure or task. After completing the procedure or task, WTRU2 can report the output to WTRU1's NAS. In one example, the content of reports and commands may be similar to classic inter-layer communication within a single WTRU, but the destination is changed to a higher (or lower) layer of another WTRU.

[0189] In an alternative implementation, the NAS of WTRU1 801 may also perform tasks using the AS of WTRU2, but this can be done via communication through the NAS layer of WTRU2 804, which would transparently or in accordance with the AS's behavior regarding compatibility with the rest of the WTRU's tasks and then transfer the tasks to its AS 803.

[0190] Figure 9 shows an example of a control plane protocol stack for inter-WTRU support, where one NAS entity can control AS entities in multiple WTRUs. In this example, a single NAS entity 901 directly controls AS entity 902 in WTRU1 and AS entity 903 in WTRU2. Since two WTRUs are used as an example for illustrative purposes, this can be extended to multiple WTRUs. The NAS entity may reside within one of the controlled WTRUs or within another WTRU. Communication between the uncollocated NAS layer and AS layer is carried out using inter-WTRU coordination, such as PC5-Collab or other inter-WTRU links.

[0191] As shown in Figure 9, a single NAS entity may directly control AS entities of multiple WTRUs, conceptually similar to dual connectivity. The NAS entity may reside within one of the controlled WTRUs or within another WTRU. Communication between the uncollocated NAS layer and AS layer may be achieved using WTRU coordination, such as PC5-Collab or other WTRU links.

[0192] Collaborating WTRUs can first coordinate their NAS and AS configurations, such as available RATs, supported frequencies, and procedures. WTRU1's NAS can send commands to WTRU2's AS using PC5-Collab, and WTRU2 can perform the requested procedure or task. After completing the procedure or task, WTRU2 can report the output to WTRU1's NAS. With minimal interface and specification changes, the content of reports and commands can be kept similar to classic inter-layer communication within a single WTRU, except the destination is changed to a higher (or lower) layer of another WTRU.

[0193] To facilitate coordination among group WTRUs, certain information may be shared so that WTRUs are aware of each other's capabilities and status. This information may be used for coordinating group activities such as selecting coordinators, distributing tasks, or sharing reports. For example, such information may include:

[0194] The capabilities of the WTRU, including frequency band support, RAT support, antenna / beam support, and measurement capabilities, i.e., all information regarding how the device can perform measurements and cell exploration for SSB.

[0195] For example, a WTRU category when a WTRU is a special type of WTRU (e.g., NTN, RedCap, URLLC, Coordinator).

[0196] Information stored in the WTRU. This indicates what the WTRU has already discovered in the past, which can be quickly discovered when performing stored information-based cell selection.

[0197] WTRU battery / energy status. This indicates whether the device needs to conserve its energy and should avoid performing tasks. For example, whether power saving mode is activated, the power profile, and the remaining battery level.

[0198] Location of the WTRU. Spatial information (e.g., absolute or relative position, direction, velocity) can be useful in determining the proximity between devices and, therefore, the redundancy of their measurements.

[0199] WTRU interoperability within a group: Interconnected WTRUs can easily share and update information directly with each other. Interoperability includes PC5 wireless interface, wireless status, and PC5 resource availability.

[0200] What are the collaborative capabilities of the WTRU, for example, the ability to be supported in order to be in a group or to act as a coordinator, or which characteristics or procedures can be distributed or offloaded?

[0201] What are the service types and QoS requirements of the WTRU? For example, what types of services need to be supported within the group for this user, and what kinds of requirements does the WTRU expect to be supported for this group?

[0202] WTRU connection to network status (if any, coverage inside / outside, RRC mode, cell / PLMN ID, etc.).

[0203] Such information can be shared among users, directly or through a coordinator, using the PC5-Collab interface, between ASs (e.g., at the RRC level), or at the NAS level, according to a coordinated procedure. Such information can be exchanged when exchanging configurations or capabilities regarding devices during or after the establishment of PC5 links between devices. Some of this information, such as battery status and location, can be further shared among users periodically or on demand to keep the devices in the group up-to-date.

[0204] Regarding the selection of primary or coordinating users, in a group of WTRUs, one WTRU may take on the role of coordinator (or manager or primary) WTRU. The user device may be responsible for coordinating the group's WTRUs to perform tasks collaboratively or on behalf of other WTRUs in the group. Therefore, the coordinating WTRU may need to possess the ability to implement coordination and strong connectivity with the WTRUs in the group.

[0205] It should be noted that a coordinator WTRU can also provide network connectivity to the group's WTRUs (for example, as a relay or gateway), but this is not required.

[0206] Embodiments including methods and structures for enabling the selection of a coordinator WTRU within a group to select the WTRU most likely to coordinate the group are described below.

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

[0208] In one embodiment, several devices may be specialized for WTRU coordination and hardcoded or (pre)configured to become a coordinator WTRU. Thus, when included in a group or connecting with other WTRUs, these devices are automatically assumed (or selected) to be coordinators. Such WTRUs can announce their capabilities and roles during capability exchange, for example, when establishing a connection in a SL.

[0209] This type of WTRU can be deployed, for example, in selected locations where certain service requirements are difficult to meet using conventional, non-cooperative WTRUs, such as in high-density WTRU scenarios, to help the WTRU and network provide the required services and QoS.

[0210] For example, when a group of users is configured within a cooperative communication group, the supporting WTRU becomes the coordinator / primary WTRU, while the supported WTRU becomes the secondary WTRU.

[0211] In another example, the service or application for this group consists of an application layer that designates a coordinating device, such as a device that initiates the service or a more capable device. The group configuration, including the coordinator configuration, is shared among users.

[0212] Figure 10 shows an example of a logical interface that may be used by the solution. In terms of logical function, NAS1 1001 can communicate with AS2 1002 via an interface. The PC5 interface is used to perform this communication. NAS1 1001 can send commands to AS2 1002 using the logical interface NAS1-AS2 1003 via PC5-Collab1004. WTRU2 can then perform the requested procedure or task, and after completing the procedure or task, WTRU2 can report output to NAS1 1001 using the logical interface NAS1-AS2 1003 via PC5-Collab1004. The content of reports and commands can be preserved as in typical interlayer communication within a single WTRU, where the interface can be changed (for example, the destination can be changed to a higher (or lower) layer of another WTRU), and the information can be encapsulated and sent to the peer WTRU.

[0213] In an alternative implementation, NAS1 1001 may perform tasks via NAS2 1005, but using AS2 1002. NAS1 1001 may send requests to NAS2 1005, and NAS2 1005 may send task requests to AS2 1002 (for example, transparently or by controlling AS2's behavior for compatibility and coordination with the remaining WTRU tasks).

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

[0215] Figure 11 shows an example call flow for network-based WTRU coordinator selection.

[0216] In another example, the network performs the selection of a coordinator WTRU for a group. Note that the WTRU may communicate with the network directly (for example, via paging messages for Uu RRC, DCI, or IDLE / INACTIVEUE) or through relay.

[0217] Referring to Figure 11, the network may request information or updates about groups and WTRUs within the groups 1101. WTRUs within the groups may report that information to the network 1102.

[0218] Various pieces of information can be used to select a coordinating WTRU. In particular, the WTRU's ability to perform the collaborative task, Uu capability, SL capability, Uu link quality (e.g., Uu RSRP), SL connection status and SL RSRP to other devices in the group, number of hops to other devices, services associated with the group and their QoS, the WTRU's cell ID, connection status, or PLMN ID.

[0219] Information regarding the configuration and setup of the WTRU can be exchanged during connectivity setup or through RRC. Dynamic information, such as RSRP or connectivity status, can be obtained from reports, such as WTRU CSI reports, or based on network requests.

[0220] The network selects a coordinator WTRU based on the reported WTRU information.

[0221] The choice may be based on the WTRU's ability to support cooperation among WTRUs.

[0222] WTRUs can be ranked according to a score calculated for each WTRU. The score / priority may be based on an information criterion for each WTRU, which can be calculated directly by the network or autonomously by the WTRU. The WTRU with the highest rank / score / priority may be selected to become the coordinator. Scores may be shared by the network or among WTRUs to discover the highest-scoring WTRU.

[0223] For example, the score ensures reliable communication between the network and the coordinator, based on the WTRU with the strongest Uu RSRP to become the WTRU coordinator.

[0224] In another example, the score could be based on maximizing link quality, while minimizing the number of hops between the user and the system could be a criterion for maximizing reliability and minimizing latency during the WTRU.

[0225] In another example, the score is obtained based on the energy status of the WTRU, where low-energy devices may be avoided.

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

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

[0228] The network may send a notification to the selected WTRU regarding its role as coordinator.1104 The network may assign coordinating tasks and configurations to the coordinator.

[0229] The network may also indicate the coordinator WTRU to other WTRUs in the group 1105. Alternatively or supplementally, the coordinator WTRU may indicate its status to WTRUs in the group via inter-WTRU communication, for example using PC5-Collab 1106.

[0230] Figure 12 shows an example call flow for WTRU-based coordinator selection.

[0231] In this example, the coordinator WTRU is autonomously selected among the WTRUs. Communication between WTRUs can take place, for example, via PC5-Collab, or at the RRC level.

[0232] WTRUs, WTRU B may request WTRUs in the group to provide information about WTRUs or updates about information about WTRUs.1201 WTRUs in the group report that information to the network. Similar information may also be exchanged between WTRUs,1202 and, in the former option, between WTRUs and the network.

[0233] Some aspects of WTRU information, such as capabilities, may be exchanged during direct communication setup or grouping setup of WTRUs, or link status may be exchanged more dynamically.

[0234] In parallel, the WTRU selects a Coordinator WTRU based on the reported WTRU information.1203 The same ranking system described earlier may be used here as well.

[0235] WTRUs may share results with each other and indicate selected WTRUs and / or ranking results.1204 Selected WTRUs may further indicate themselves as coordinators with additional cooperative configurations.1205

[0236] When establishing a ranking of potential coordinators, WTRUs base their calculations on the same information input from other users, which can result in the same ranking. However, if the shared information is not perfectly 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, if the group is configured to support only one coordinator, the selected coordinators can exchange their information with each other and perform a limited ranking comparison to narrow down the final coordinator. The result of this convergent selection is shared with the WTRUs in the group (similar to 1204).

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

[0238] Regarding lower-layer aggregation of multi-WTRUs for IDLE / INACTIVE measurements, in some examples, some devices may be limited by their capabilities, power, energy, or connectivity to access the network, just like ordinary devices. To increase the performance of these WTRUs, they can be "aggregated," where one "aggregated" WTRU supports another "anchor."

[0239] An aggregated WTRU can support an anchor WTRU by sharing its hardware and processing to perform joint signal reception, for example, where the lower layers of the WTRU (PHY-MAC) jointly perform measurement or detection.

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

[0241] Through the aggregation link, WTRUs can exchange their measurements, and the RSRP / RSRQ of the received aggregation / joint processing can be evaluated. The exchange of measurements may take place between the WTRU's Uu stacks at the PHY layer, MAC layer, or RRC layer level, depending on the data being exchanged, and may be beam-specific if the cell uses multiple beams. The aggregation configuration may include which measurements are shared among the WTRUs and how they are processed, for example, through a network configuration or through an SL configuration.

[0242] This section describes solutions for selecting an aggregated WTRU. This selection can be made independently of the cell or PLMN selection. The anchor can choose an aggregated WTRU. In one example, the aggregator role may be static, for example, based on provisioning, network configuration, hardware, or deployment choices.

[0243] Some devices may be specialized for WTRU aggregation and hardcoded or (pre)configured to become aggregating WTRUs (at least for certain anchor WTRUs). When connecting with other WTRUs, these devices may be automatically assumed (or selected) to be aggregators. Such WTRUs may announce their capabilities and roles during capability exchange, for example, when establishing connectivity in SL. There is prior agreement that devices with those capabilities can act as aggregators. Selection is not inherently necessary.

[0244] For example, a static WTRU aggregator may be deployed in selected locations where specific service requirements are difficult to achieve using regular, unaggregated WTRUs, such as for the edges of coverage.

[0245] In another example, a static WTRU aggregator could be located in a location where multiple devices are used for a given application, such as VR / XR, onboard multisensor, or personal Internet of Things (PioT) devices. In this case, a more capable device (e.g., a smartphone) may support a given user's secondary device (e.g., glasses, wearables, cameras, etc.). When a group of users are aggregated into an aggregation / anchor relationship, the aggregated WTRU can be the coordinator / primary WTRU, while the anchor WTRU is the secondary WTRU. Optionally, the network may assign an aggregator to improve the performance of the anchor WTRU, for example.

[0246] Figure 13 shows a call flow for an example of network-based aggregated WTRU selection.

[0247] Referring to Figure 13, the network may perform a selection of aggregated WTRUs for an anchor WTRU. For example, this network-managed aggregation may be triggered when a WTRU moves out of coverage or when coverage may limit its expected services. The aggregated WTRU may then be assigned to provide support.

[0248] The network may request information or updates regarding groups and WTRUs within the group 1301. WTRUs within the group report such information to the network 1302.

[0249] Various types of information can be used to select an aggregated WTRU, as described above. In particular, the WTRU's ability to perform the aggregation task, its Uu capability, SL capability, Uu link quality (e.g., Uu CSI or RSRP), SL connection status and SL RSRP to other devices in the group, the number of hops to other devices, the services associated with the group and its QoS, the WTRU's cell ID, connection status, or PLMN ID.

[0250] Information regarding WTRU configuration and setup can be exchanged during connectivity setup or through RRC. Dynamic information, such as RSRP or connectivity status, can be obtained from reports, such as WTRU CSI reports, or based on network requests.

[0251] The network may select an aggregated WTRU to target the anchor WTRU based on the reported WTRU information.1303

[0252] Selection may be based on the WTRU capacity of the supported WTRU aggregation, but other criteria may also be utilized. WTRUs can be ranked according to a score calculated for each WTRU. The score / priority may be based on information criteria for WTRUs that can be calculated by the network. WTRUs with the highest rank / score / priority may be selected to become the aggregated WTRU. Scores may be shared by the network or among WTRUs to discover the WTRU with the highest score.

[0253] For example, the score could guarantee reliable communication between the network and the aggregated WTRU by targeting the WTRU with the strongest Uu RSRP.

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

[0255] In another example, the score could be based on the device's geographical location (absolute or relative) and, optionally, speed.

[0256] In another example, the score is obtained based on the energy status of the WTRU, where low-energy devices should be avoided.

[0257] The score may also be based on multiple combinations of these exemplary metrics.

[0258] The network may indicate its role to the aggregated WTRU and give it aggregation tasks such as configuration, for example, an anchor WTRU ID, scheduling resources for communication with other WTRUs or networks, assisting in the selection of cells and PLMNs or assisting as a relay.1304

[0259] The network may also indicate to the anchor WTRU the selected aggregate WTRU and its configuration.1305 In other examples, the WTRU may be selected autonomously based on the information received.

[0260] Figure 14 shows an example call flow for autonomous aggregated WTRU selection.

[0261] Communication between WTRUs may take place, for example, via PC5-Collab, or at the RRC level. Multiple WTRUs may be contacted simultaneously or sequentially by an anchor WTRU, which may make selections from the reported responses.

[0262] An anchor WTRU may request WTRU information from a potential aggregated WTRU, including updated information such as Uu connectivity and status (e.g., Uu RSRP, cell ID) and its capabilities. The request may also include anchor WTRU information that can be used to filter the aggregated WTRU's report. An anchor WTRU may include its own information.

[0263] A potential aggregated WTRU is a WTRU capable of performing an aggregated function. It can be a specific WTRU within a group or a set / all WTRUs. Its priority may be known by an anchor WTRU as part of the configuration, or it may be determined during the discovery phase.

[0264] Potential aggregated WTRUs can report their status and update information upon request.

[0265] Some types of WTRU information, such as capabilities, can be exchanged during direct communication setup or grouping setup of WTRUs, or link status, for example, can be exchanged more dynamically.

[0266] An anchor WTRU may select its aggregated WTRU based on the reported WTRU information.1403 A similar rank model to the one described earlier may be used here as well. The anchor WTRU may report its selection to the aggregated WTRU.1404

[0267] Anchor WTRUs may share results with each other and indicate the selected WTRUs and / or ranking results and the aggregate configuration. Configuration parameters may include one or more of the following: anchor WTRU ID, potential cell ID, coordinator WTRU ID, scheduling resources for communicating with each other, assisting with measurements, assisting with cell and PLMN selection, or assisting as a relay.

[0268] WTRUs can initiate (or activate) their roles in aggregation as anchor and aggregate WTRUs.

[0269] While the described solution focuses on selecting one aggregated WTRU for the anchor, it is also possible for an anchor to have multiple aggregated WTRUs.

[0270] Regarding the configuration and aggregate measurement procedure, the measurement follows a sequence of processing from signal sampling to Layer 3 values. In a typical embodiment, two devices during aggregation may exchange their measurements for joint processing at different stages. This implies that the first WTRU may preprocess the received signal using the portion of processing typically required and transmit the preprocessed signal to the second WTRU, which may then complete the processing using both its own received signal and the preprocessed signal. Processing stages may be configured in which the measurement signal is transferred to the other device, and different options may be possible.

[0271] Figure 15 shows a call flow of an example of a procedure for multi-WTRU aggregation measurement. Without loss of generality, two WTRUs are used in this example.

[0272] WTRU A and WTRU B can become the anchor WTRU or the aggregation WTRU interchangeably depending on which WTRU triggers the measurement and / or which WTRU performs the procedures / decisions related to this measurement.

[0273] Although the example describes two WTRUs, it is possible to replicate / parallelize the behavior of the WTRUs to have aggregation of measurements of multiple WTRUs.

[0274] In the first step, the WTRUs being aggregated can exchange their configurations for the aggregation measurement 1501.

[0275] The configuration can include the supported aggregation measurements and capabilities, such as what types of measurements and processing can be aggregated (RSRP, RSRQ, RSSI, etc.), for what RS, and for what procedures.

[0276] The configuration can include the exchanged data content, such as at which processing step the measurements are exchanged.

[0277] The configuration can include the pre-processing requirements for the pre-processing step or the parameters and methods for the performance requirements of the pre-processing step.

[0278] The configuration can include the measurement objects to be considered, such as which reference signals are measured for which metrics and procedures.

[0279] The configuration can include the configuration of the aggregation measurement, such as whether they are dynamic (on-demand) or periodic.

[0280] The configuration may include measured quantities to be reported, such as an unprocessed measurement sample ("A", Figure 2, 201), a Layer 1 filtered measurement ("A1", Figure 2, 203), an L3 filtered beam measurement ("E", Figure 2, 212), cell quality ("B", Figure 2, 205), filtered cell quality ("C", Figure 2, 207) or RSRP ("D", Figure 2, 209). This information may also be sent on demand to enable more dynamic selection of the measured quantities to be aggregated and measured at 1502.

[0281] The WTRU B may receive a request to perform an aggregated measurement at 1502. The request may be received from another WTRU during aggregation or from a coordinator WTRU or network. Alternatively, for example, when performing configured periodic / semi-static measurements, the measurement may be internally triggered by the WTRU itself.

[0282] The request may include or refer to the configured measurements to be performed, such as the measurement object or received signal (RS) and the timing, reporting scheduling, and conditions of the measurement.

[0283] The WTRU may perform those measurements according to the configuration for SSS corresponding to a configured timing at 1503. The sample timing may be used to synchronize measurements between devices and may enable the calculation of joint reception. The configuration / request may indicate which SSS the WTRU should report, and thus the WTRU may synchronize and perform measurements on the same sample. When the network uses beam-based SSB, the measurement may be beam-specific.

[0284] The WTRU may obtain those inputs for measurement processing corresponding to the "A" measurement in Figure 2, for example, the A: measurement inside the physical layer (beam-specific samples).

[0285] A WTRU can perform configured processing for a measurement.1504 The processing method or parameters may vary depending on the implementation of the WTRU, the measurement performed, and the configuration, but the WTRU can be configured to perform the same steps of measurement.

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

[0287] In another embodiment, the WTRU may perform a layer 1 filtering process on the measurement sample.

[0288] In another embodiment, the WTRU may perform some of the Layer 3 (RRC configured) processes on the measurement, such as beam integration, beam selection, or L3 beam filtering.

[0289] The WTRU can still perform the remaining measurement processing in parallel with steps such as having completed measurements for itself, or being able to perform evaluations against improved (pre-processed) measurements.

[0290] WTRU B may send preprocessed measurements to WTRU A according to the configured reporting steps and using the configured scheduling / resources.

[0291] Depending on the configuration, WTRU B may report raw measurement sample ("A", Figure 2, 201), Layer 1 filtered measurement ("A1", Figure 2, 203), L3 filtered beam measurement ("E", Figure 2, 212), cell quality ("B", Figure 2, 205), filtered cell quality ("C", Figure 2, 207), or RSRP ("D", Figure 2, 209).

[0292] When measuring signals from multiple sources, WTRU B may sub-select which measurements to report, removing signals with too low an intensity. Signal requirements, such as an RSRP threshold or beam selection, may be configured, and the threshold may be set differently for different aggregation methods.

[0293] WTRU A can combine the received measurement with its own pre-processed measurement.

[0294] In one embodiment, WTRU A can be a combination of measurement samples by directly adding the samples or by adding the absolute power contribution values ​​of each sample.

[0295] In another embodiment, WTRU A may be a combination of measured samples by directly adding the filtered samples or by adding the absolute power contributions of each sample.1506

[0296] In another embodiment, WTRU A may be combined by adding together the RSRP values ​​(in the linear region), and for the RSRQ value, the RSRP and RSSI values ​​may first be combined separately, and then the combined RSRQ may be calculated based on the combined RSRP and RSSI values.1506

[0297] WTRU A, if available, allows for the resumption of measurement processing at 1507.

[0298] In one embodiment, WTRU A may restart and perform the Layer 1 filtering and RRC processing.

[0299] In another embodiment, WTRU A may restart and carry out all RRC processing.

[0300] In another embodiment, WTRU A may resume and carry out the remaining RRC processing.

[0301] WTRU A may report to the corresponding layer or entity an aggregated measurement result including an aggregated configuration or an aggregated WTRU that participates in measurements in response to a transmission request 1508.

[0302] WTRU A may report a measurement result including an aggregated configuration or an aggregated WTRU that participates in measurements to WTRU B 1509.

[0303] Regarding embodiments in which a device receives a measurement request for aggregation, the WTRU may exchange with another WTRU the configuration and capabilities for aggregated measurements, such as processing L1-filtered measurements, to measure the RSRP of a cell. When triggered to perform measurements, the WTRU may transmit, for example, using SL, an aggregated measurement request including the target to be measured by another WTRU during aggregation as well as timing and pre-processing to another WTRU during aggregation. The WTRU may perform its measurement and pre-processing steps according to the configuration and receive pre-processed measurements from other WTRUs. The WTRU may aggregate measurements, for example, by adding the signal strengths of received and measurement signals. The WTRU may resume processing to finalize the measurements. The WTRU may send measurement reports to the entity requesting the measurements and the devices participating in the measurements.

[0304] Regarding embodiments in which a device transmits a measurement request for aggregation, the WTRU may exchange with another WTRU the configuration and capabilities for aggregated measurements, such as processing L1-filtered measurements, to measure the RSRP of a cell. For example, when receiving a request asking to perform measurements according to a periodic measurement configuration or triggering measurements, the WTRU may perform the requested measurement and pre-processing steps according to the configuration. The WTRU may sub-select a part of the measurements for reporting. The selection may be based on the signal strength of the measurements and a configured threshold. The WTRU may transmit pre-processed measurements from other WTRUs based on the configuration. It further receives aggregated measurement results from the aggregation device.

[0305] Describe the processing steps and processing parameters for measurement aggregation.

[0306] If the measurement is replaced after the Layer 1 filter, the filtering process may provide a more stable measurement of the SSS, but the filtering process itself and the measurement input are not constrained and may vary from device to device.

[0307] One embodiment includes adding a standardized Layer 1 filter in the case of aggregated / exchanged measurements, or having a Layer 1 filter that can be configured by the network during the aggregated configuration phase or during the WTRU. This filter configuration may be, for example, a list of coefficients that will be applied to the L1 sample in the frequency and time domains. This configuration / standardized filter can be used in place of the L1 filter specific to the implementation in the case of aggregated measurements.

[0308] In one embodiment, a WTRU may consist of a Layer 1 filtering method and parameters (e.g., filter coefficients) that can be applied to aggregate measurements. When an aggregate measurement is triggered by or requested by a WTRU, the WTRU may use a Layer 1 filter configured based on (and / or from) its configuration. It may then send the Layer 1 filtered measurement to another WTRU.

[0309] When processing aggregated measurement samples, the device can proceed with Layer 3 processing, WTRU beam integration / selection, Layer 3 beam filtering, Layer 3 filtering for cell quality, beam selection for reporting, and evaluation of reporting criteria. RRC parameters generally correspond to classic measurement examples where they are not necessarily ideal for aggregated measurements.

[0310] In one example, a dedicated set of RRC parameters for an aggregated case is provided to the device. This set of parameters can be configured by the network or during the WTRU (e.g., using PC5-RRC).

[0311] For example, thresholds used in the criteria for beam integration, selection, and reporting may be adapted in the case of aggregation using dedicated criteria that can be added to the RRC parameters or using offset parameters that can be added to the original criteria.

[0312] Layer 3 Aggregation Filter Coefficients: As another example, a Layer 3 filter is generally configured using filterCoefficient, FilterCoefficientRSRP, or FilterCoefficientRSRQ for the corresponding quantity of the i-th QuantityConfigNR in quantityConfigNR-List, where i is represented by quantityConfigIndex in MeasObjectNR, and the new and similarly parameterized Layer 3 aggregation filter coefficients Aggregation-filterCoefficient may be co-configured in QuantityConfigNR which will be used for the measurement aggregation. Alternatively, when aggregation is used, the configured filterCoefficientAggregationOffset is configured and applied to the filter coefficients.

[0313] An example of an aggregated IE in RRC might be one for layer 3 aggregated filter coefficients (using ASN.1 encoding).

[0314] Aggregation-QuantityConfigRS::=SEQUENCE {

[0315] ssb-FilterConfig Aggregation-FilterConfig,

[0316] csi-RS-FilterConfig Aggregation-FilterConfig

[0317] }

[0318] Aggregation-FilterConfig::= SEQUENCE {

[0319] Aggregation-filterCoefficientRSRP FilterCoefficient,

[0320] Aggregation-filterCoefficientRSRQ FilterCoefficient,

[0321] Aggregation-filterCoefficientRS-SINR FilterCoefficient

[0322] }

[0323] In one embodiment, a WTRU may be configured (by the network or by another WTRU) with an aggregation-specific set of configurations for a Layer 3 filter (e.g., filter coefficients). When the aggregation measurement is performed by the WTRU, the WTRU may use the Layer 3 filter configured for aggregation. It can then resume the remaining processing steps of the process.

[0324] Regarding accuracy adaptation, another factor to consider in aggregation for collaborative processing based on measurements performed on different devices is the accuracy of the measurements. In one embodiment, when a measurement is received, the device may apply an offset to the measurement to take into account several potential accuracy issues.

[0325] As an example, the NR specification specifies accuracy requirements of ±4.5 dB for SS-RSRP and ±2.5 dB for SS-RSRQ under normal conditions for FR1 in-frequency bandwidth measurements. This requirement may vary depending on the carrier, bandwidth, operating mode (e.g., CA / DC), frequency-to-frequency in-frequency measurements, etc. Furthermore, the requirements for a given configuration may differ when the device is in "extreme conditions," which, as is known, is when the temperature is outside the range of +15°C to +35°C, where the accuracy can reach ±9 dB and ±4 dB for SS-RSRP and SS-RSRQ, respectively.

[0326] Therefore, a device receiving a measurement of another WTRU can know its configuration and status and adapt it precisely with the determined accuracy.

[0327] In one embodiment, the precision required for aggregation may be specified, for example, as an independent configuration that the WTRU can use while aggregation is in progress, or as a configured requirement in the aggregation configuration between WTRUs in a connected configuration or RRC configuration. The configuration is specific to the measurement and may be indicated dynamically, for example, during the measurement request. The configured precision requirement may be used by the WTRU to determine which processing to use, for example, whether to apply an L1 filter or an L3 filter from a pre-configured set of filters.

[0328] In one embodiment, a WTRU may be configured to perform measurements for aggregation. The WTRU may receive measurement configurations from another WTRU, including indications of accuracy requirements. The WTRU may 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 may optionally report the preprocessed measurements along with the methods or accuracy requirements applied thereto.

[0329] Alternatively, the WTRU reporting the measurement may report the accuracy of the measurement by reporting an absolute accuracy value (based on the specification sheet or on knowledge of the device's implementation configuration) or by indicating the configuration in which the measurement was performed (i.e., in-frequency versus-frequency measurement, frequency range, normal versus extreme conditions, etc.), and the receiving device may determine the corresponding accuracy based on the known specification sheet.

[0330] Based on the accuracy expected from the measurement, the device may apply an offset to the received measurement. For example, the offset may be set to half of the accuracy value (for instance, if the accuracy requirement is ±4 dB, an offset of -2 dB may be applied to the measurement).

[0331] In one embodiment, a WTRU may be configured to receive (pre)processed measurements for aggregation. The WTRU may receive measurements from other WTRUs, as well as indications regarding the accuracy requirements that other WTRUs adhere to. The indications may be, for example, whether the measurements are performed under extreme conditions or under normal conditions, or explicitly, an accuracy range. Based on the accuracy indications, the WTRU may determine and apply the offsets to be applied to the received measurements.

[0332] Regarding low-level information sharing, in another embodiment, users may share information about lower-layer processing to help each other discover and process relevant signals. Instead of (or in addition to) exchanging measurements, they may exchange information to help, for example, synchronize on a selected cell / frequency.

[0333] For example, after performing several measurements of the spectrum, a WTRU may transmit to the requesting WTRU a synchronization signal and several frequency and timing indicators to help it synchronize with it. This information may include synchronization signals for one or more beams, correlation pic information, and absolute or relative timing indicators to discover the timing and frequency location of SSB bursts. Such information can be used by the assisted WTRU to discover cells more efficiently, potentially reducing radio monitoring and processing time to only what is necessary.

[0334] Measurements performed by aggregating lower layers in IDLE and INACTIVE modes.

[0335] When supporting cell selection or re-selection in the aggregation of lower layers, the aggregation may already be in place and active, and the cell selection procedure may be performed for the anchor WTRU. The decision may be made in the anchor itself or in the aggregation WTRU.

[0336] In a second embodiment, cell (re)selection may be performed in conjunction with aggregate selection. Aggregate-based cell reselection may be required. For example, the cell (re)selection procedure may be adapted so that the selection criteria and ranking take into account that WTRU may be using aggregate measurements.

[0337] Regarding the (re)selection of cells for already aggregated WTRUs, according to one embodiment, it is disclosed below how the cell (re)selection procedure can be carried out using aggregated WTRUs of lower layers. Here, it is assumed that the anchor WTRU and the aggregated WTRU are already grouped together.

[0338] Here are two examples, where the selection decision is made either on the anchor WTRU side or the aggregate WTRU side.

[0339] Figure 16 shows an example call flow for lower-layer aggregation for cell (re)selection performed by an anchor WTRU.

[0340] In the case of (re)selection of cells on the anchor WTRU side, the anchor WTRU may initiate the cell selection procedure, receive measurement information from the aggregated WTRU, and evaluate the cell quality under the aggregation of lower layers. The anchor WTRU initiating the cell selection procedure may apply the cell selection procedure and criteria, where the criteria may be adapted to aggregation-based criteria as described above.

[0341] The procedure described here is for a single aggregated WTRU, but the exchange can be replicated and applied similarly to multiple aggregated WTRUs.

[0342] Anchor WTRU and aggregated WTRU can swap configurations for the aggregation of lower layers for cell selection 1601.

[0343] The configuration may be a pre-configuration and / or a configuration exchanged with the WTRU during, for example, the aggregation or grouping setup configuration and / or the SL connection configuration. The configuration may be transmitted using SL discovery setup signaling and / or PC5-Collab or SL RRC signaling. The configuration may also be acquired through system information, for example, over the network using a new dedicated SIB for the aggregation configuration.

[0344] The configuration may include a set of parameters that replace the normal cell selection procedure parameters and may be applied when cell selection is performed using aggregation.

[0345] The configuration may be specific to the WTRU and / or the service, and therefore the criteria may be adapted to the devices and their use.

[0346] The configuration may include the timing of procedures (e.g., requests and responses). For example, a request may be sent on a selected resource or opportunity that will be monitored by a WTRU in a group that is configured to select a cooperative cell. Scan reports may also be configured to be sent on a selected resource or opportunity and may consist of a maximum timing requirement for sending those reports after receiving a request.

[0347] The configuration may include required measurements to be performed by aggregated WTRUs based on SSS and the time validity of the measurements, namely RSRP and RSRQ. In one embodiment, the measurements and reporting may be configured to be one-time requests / reports. In another embodiment, the measurements may be activated and reported periodically, periodically, or based on events.

[0348] The configuration may include selection criteria for aggregate cells to be used by the WTRU in subsequent steps, as well as calculation methods and parameter / offset values ​​required for measurement.

[0349] Anchor WTRUs and aggregate WTRUs can exchange WTRU information. Some information may be exchanged when the aggregate is configured, and some may be updated periodically. 1601 and 1602 may be done simultaneously using different messages, together using the same message, or in reverse order.

[0350] Cell (re)selection can be triggered by an anchor WTRU.1603 An anchor WTRU may be configured to perform the (re)selection of aggregated cells with which WTRUs in the lower layers.

[0351] For example, an anchor WTRU may request a (re)selection of a coordinating cell when its battery level falls below a configured threshold, when the WTRU is at the edge of a cell or failed to select a suitable cell in a previous attempt, when there is a change in the WTRU's coordinating group (e.g., a new supporting WTRU), after the selection of a (coordinating) PLMN, or after the primary radio receiver is turned on. The cell (re)selection procedure can also be triggered by the setting of an aggregation group, or by the aggregation WTRU.

[0352] An anchor WTRU may request the aggregate WTRU to report cell selection assist measurements.1604 The request may include (for example, based on stored knowledge) desired frequencies, carriers, PLMNs, and a pre-selected set of cells.

[0353] Anchor and aggregated WTRUs may perform cell selection measurements according to their configuration and the requested aggregated measurements.1605 An aggregated WTRU may not need to perform cell selection assisting measurements if it has already performed such measurements within a given configured time window. For each measured frequency, the WTRU may explore more than the strongest cell and collect measurements for the configured maximum or minimum number of cells, for example, so that multiple options are later available when combining anchor and aggregated WTRU measurements. The WTRU may limit its cell selection search to only the frequencies supported by the aggregated WTRU. The aggregated WTRU may perform measurements for requested frequencies / carriers obtained from the request and / or configuration.

[0354] WTRU can be configured to apply preprocessing steps. The preprocessing steps and measurements to be collected for aggregation (e.g., L1 measurements, RSRP, RSRQ, etc.) can be based on the configuration. For example, the information element Aggregation-measConfig IE can be set to one or more of L1Sample (Figure 2, A in 201), FilteredSample (Figure 2, A1 in 203), RSRP, or RSRQ. RSRP and RSRQ can be L1 / L2-based measurements and reports (Figure 2, D in 209) or L3 measurements and reports (Figure 2, F in 216).

[0355] The aggregated WTRU may report its partially pre-processed measurements to the anchor WTRU based on the configured processing steps.1607

[0356] Measurements can be filtered to include only cells with signal quality exceeding a configured threshold (e.g., RSRP or RSRQ). Thresholds for RSRP or RSRQ can be set during aggregate RRC configuration, for example, as type RSRP-Range or AggregationCellSelection-RSRQ-Thresh or RSRP-Range or RSRQ-Range AggregationCellSelection-RSRP-Thresh. These thresholds may be specific to aggregate reporting (e.g., one threshold for L1 reporting and one for RSRP reporting) or may be set to a given value based on the configured aggregate reporting type.

[0357] The measurements are filtered to include only cells that are not restricted or prohibited for an anchor WTRU, for example, by checking that the type of anchor WTRU is not prohibited or that the cell is not restricted for an anchor WTRU based on the WTRU information to which it was replaced.

[0358] The measurements are suitable for (re)selection of cells in the aggregated WTRU, for example, they can be filtered to include only cells that satisfy signal quality criteria for cell selection and cells that are not prohibited or reserved for the aggregated WTRU.

[0359] The measurements can be filtered, for example, to include only cells that support aggregated WTRUs with explicit instructions in the system information, or cells that are not restricted / prohibited for aggregation.

[0360] If an aggregated WTRU is camped or serviced by a cell, it may be configured to report only signaling information from that cell. It may also be configured to report only cells that are suitable for re-selection, and therefore, if a cell is selected by an anchor, re-selection to that cell by the aggregate is possible.

[0361] The anchor WTRU may receive and aggregate partially pre-processed measurements. The anchor WTRU may restart the measurement processing according to configured steps, for example, by applying a bias based on the accuracy of the received measurements or by using filters specific to the aggregation.1608

[0362] The anchor WTRU can determine the aggregate RSRP and RSRQ based on its measurements and reported measurements.1609 The anchor WTRU can then select cells based on the aggregate measurements.

[0363] To verify the conformity of a cell as a set of WTRUs, the anchor WTRU verifies the conformity of the WTRU aggregate. The criteria are defined during the (pre)configuration or aggregate (e.g., from the specification or replaced in Step 1).

[0364] To evaluate the signal intensity of the cells, the WTRU can determine the RSRP and RSRQ of the aggregated signal and apply new criteria for aggregated measurements.

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

[0366] The S criteria for cell reselection may be modified for aggregation cases to evaluate the RSRP and RSRQ of cells. The offsets (e.g., Qqualminoffset, Qrxlevminoffset) and minimum requirements (Qrxlevmin and Qqualmin) used in the criteria may be configured separately for aggregation, for example, via SIB, RRC, sidelinks, or dedicated RRC signaling.

[0367] The cell selection criterion S can be satisfied when Srxlev > 0 and Squal > 0.

[0368] Srxlev is the RX level value (in dB) for cell selection and is determined as follows:

[0369] Srxlev = Qrxlevmeas - (Qrxlevmin + Qrxlevminoffset) - Pcompensation - Qoffsettemp, where,

[0370] Qrxlevmeas: The RX level value of the cell (reference signal received power, RSRP). Measured by WTRU.

[0371] Qrxlevmin: The minimum required RX level (dBm) within a cell. Composed of RRC.

[0372] Qrxlevminoffset: The offset used when camping in a VPLMN and searching for a higher-priority PLMN. Consists of RRC.

[0373] Pcompensation: If FR1: Depends on the power class of the WTRU and is composed by RRC. If FR2=0.

[0374] Qoffsettemp: An offset temporarily applied to a cell. Consists of RRC.

[0375] Qrxlevminoffset: The offset used when camping in a VPLMN and searching for a higher-priority PLMN. Consists of RRC.

[0376] Qrxlevminoffsetcell: A cell-specific offset added to the corresponding Qrxlevmin to achieve the minimum required RX level in the cells involved. It is composed of RRC.

[0377] Furthermore, Squal is a quality value (in dB) for cell selection and is determined as follows:

[0378] Squal=Qqualmeas-(Qqualmin+Qqualminoffset)-Qoffsettemp

[0379] Qqualmeas: Cell quality value (reference signal reception quality, RSRQ). Measured by WTRU.

[0380] Qqualmin: The minimum required quality level (dB) within a cell. It is composed of RRCs.

[0381] Qqualminoffset: The offset used when camping in a VPLMN and searching for a higher-priority PLMN. Consists of RRC.

[0382] Qoffsettemp: An offset temporarily applied to a cell. Consists of RRC.

[0383] The anchor WTRU receives RSRP and RSRQ from the aggregate WTRU and may determine the Squal value using the parameters sent in the anchor's current serving cell. Since the measurement is performed by another WTRU, the anchor WTRU may compensate for any inconsistencies in the measurement. Additional offsets specific to the aggregate may be added to the calculations of Srxlev and Squal, for example, QlevOffsetAggregation and QqualOffsetAggregation, respectively. When determining the values ​​of Srxlev and Squal, the anchor WTRU will add or subtract the offset.

[0384] Srxlev=Qrxlevmeas-(Qrxlevmin+Qrxlevminoffset)-Pcompensation-Qoffsettemp±QlevOffsetAggregation

[0385] Squal=Qqualmeas-(Qqualmin+Qqualminoffset)-Qoffsettemp±QqualOffsetAggregation

[0386] Adding a positive offset results in a higher probability that the cell reselection criterion S can be met, for example, Srxlev > 0 and Squal > 0. Also, subtracting a positive value makes it more difficult to reach the criterion, since the offset changes the Srxlev / Squal value and the criterion is that these values ​​are greater than 0.

[0387] The offset determination may be pre-provisioned, configured, sent in the current serving cell's system information, or sent in a dedicated RRC message. Optionally, it may be received from other WTRUs.

[0388] The offset can be distance-based. The offset can be determined based on the distance between coordinating WTRUs. Several offset values ​​can be configured and selected based on configured distance thresholds. For example, a 0dB offset may be applied when WTRUs are collated, a 3dB offset may be applied to WTRUs when the distance between them is below a first distance threshold, and a 5dB offset may be applied when the distance is between the first and second distance thresholds. Note that the distance metric can be replaced by evaluating the path loss between WTRUs. The collation / distance configuration can be estimated using connectivity, e.g., long-range wireless vs. very short-range wireless / wired systems.

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

[0390] The offset can be role-based. For example, if a WTRU is a coordinator or relay / gateway, the offset can be determined based on the role of the aggregated WTRU in the group. This offset can be set to favor the grouping WTRU that has that coordinating WTRU.

[0391] Specific parameters and offset values ​​may be set for different aggregation types or sizes within several WTRUs. Parameters and offset values ​​can be part of the configuration. For example, the offset for aggregating two WTRUs may differ from that for aggregating three or more WTRUs.

[0392] In the case of a cell reselection procedure, the offset can be applied to either Srxlev or Squal during the evaluation of cells within or between frequencies. In another example, it can be applied to a threshold used for evaluation between or within frequencies while keeping the measured quantity invariant. The offset value may also be added to the serving WTRU in the aggregated group, for example, to the cell serving the aggregated WTRU, to bias the reselection towards the common cell.

[0393] for example,

[0394] When using aggregated measurements, if it satisfies the conditions Squal>ThreshX, HighQ+QqualOffsetAggregation_highQ, or Srxlev>ThreshX(HighQ+QlevOffsetAggregation_highP), cells on higher priority frequencies may be selected.

[0395] When using aggregated measurements, if it satisfies the conditions Squal>ThreshX, LowQ+QqualOffsetAggregation_lowQ or Srxlev>ThreshX, LowQ+QlevOffsetAggregation_lowP, cells on lower priority frequencies can be selected.

[0396] For cells at the same frequency as a serving cell or at the same priority frequency, the ranking of cells serving a group can be biased using the following:

[0397] If a serving cell is serving an aggregated WTRU, then Rs = Qmeas,s + Qhyst - Qoffsettemp + QoffsetAggregation.

[0398] If other cells are serving the aggregated WTRU, then Rn = Qmeas, n - Qoffset - Qoffsettemp + QoffsetAggregation.

[0399] To be a suitable cell, the anchor WTRU may also verify the cell status and restrictions. For example, a cell may be prohibited from being selected by certain WTRUs. This indication is sent in system information with the cellBarred and cellReserved flags. The aggregated WTRUs, prohibition, and restriction verifications may differ.

[0400] In one embodiment, if an anchor WTRU or aggregate WTRU is prohibited, the cell may be considered prohibited with respect to the anchor WTRU. This means that at least one WTRU of the aggregate is not authorized to camp to or be serviced by the cell. To determine the restriction on the aggregate side, the anchor WTRU may receive a prohibited status from the report (previous step) or based on the WTRU information of the aggregate WTRU (such as the WTRU type), and use the aggregate WTRU information to evaluate the prohibited status. For example, if the aggregate WTRU is a RedCap device with one Rx antenna and a cell indicated as cellBarredRedCap1Rx='barred', the aggregate WTRU is prohibited, and therefore the anchor WTRU may act as if the cell were prohibited with respect to it as well.

[0401] In another embodiment, if an aggregated WTRU is prohibited, but an anchor WTRU is prohibited, the cell may be considered prohibited for the anchor WTRU. In this case, the aggregated WTRU may support the anchor WTRU but may not consider re-selection to the prohibited cell, and the anchor may select that cell without affecting the aggregate.

[0402] In an alternative embodiment, if only the aggregated WTRU is prohibited, even if the anchor WTRU is prohibited, the cell may be considered prohibited with respect to the anchor WTRU. In this way, the aggregated WTRU is served by the cell and is sufficiently capable to support the anchor WTRU, and therefore the anchor may select that cell.

[0403] A new "cellBarred" indication (for example, "cellBarredAggregation" IE type: "barred" or "not barred") may be defined and signaled in the MIB or SIB1, where the barred indication targets aggregate users. When it exists and is set to "barred", WTRUs configured in the aggregate group may consider this cell to be barred.

[0404] An anchor WTRU may notify the aggregate WTRU of the selected cell.1610 After selecting a cell, the anchor WTRU may report the selected cell to the aggregate WTRU. The report may include measurement information such as aggregate RSRP, RSRQ, or SINR obtained by the aggregate WTRU measurement. The report may include any necessary cell or WTRU information required by the aggregate WTRU to camp on to the cell. For example, cell ID, its frequency / carrier, cell-specific SI, paging occasion, WTRU-specific parameters such as DRX parameters, etc. The anchor WTRU may also report the selected cell to the network, for example, during a location registration procedure (at the NAS level). The anchor WTRU may also indicate that the selection was performed using cooperative selection, and therefore the network may track the coordination between users, send parameters specific to the coordination (e.g., via SIB), and update the user configuration based on the coordination. For example, the network may configure a paging occasion for WTRUs in coordination and send parameters specific to the coordination to both the supported and supporting WTRUs, etc.

[0405] Paging can be sent to a coordinating group. Each group can be identified by a coordinating group ID. The coordinating group ID is cell-specific and can be unique within a cell. It is also location / registration area-specific and can be unique within that area. It can also be RAN notification area-specific. Therefore, a core network or base station can trigger paging to a coordinating group based on its coordinating group ID.

[0406] Once camp-on to a selected cell, the WTRU can monitor the control channel and receive SIB and paging messages.

[0407] An anchor WTRU may camp on to a selected cell 1611. An aggregate WTRU may camp as an aggregate WTRU and begin monitoring the signals it has configured for aggregation, such as the DCI and paging occasions of the anchor WTRU 1612. Note that if a cell is not the cell to which the aggregate WTRU has camped, the aggregate WTRU may need to change its camping cell, for example, by re-selecting or directly (re)selecting the anchor cell.

[0408] When an aggregated WTRU can be associated with an anchor WTRU, the aggregated WTRU can monitor paging occasions and DCIs targeting the anchor's serving cell, in addition to its own cell. An aggregated WTRU can be associated with multiple WTRUs that may be connected to different cells. In this case, the aggregated WTRU can camp in these cells (for example, by monitoring DCIs and paging occasions) to support the corresponding anchor WTRU.

[0409] WTRU A may, for example, report the selected cell to the network during the (NAS) location registration procedure, indicating that the selection was performed using PHY aggregate selection (and associated parameters and coordinating WTRU ID / information). Optionally, the aggregated WTRU may report the selected cell of the anchor to the network.

[0410] The network can track coordination between users, send coordination-specific parameters (e.g., via SIB), and update user configurations based on the coordination. For example, the network may configure paging occasions for WTRUs in coordination and send coordination-specific parameters to both the supported and supporting WTRUs.

[0411] Figure 17 shows an example call flow for lower-layer aggregation for cell (re)selection performed by aggregated WTRU.

[0412] With regard to the (re)selection of cells on the aggregated WTRU side, in an alternative embodiment, the aggregated WTRU may perform cell selection on behalf of the anchor based on measurements reported to the aggregated WTRU by the anchor and its own measurements.

[0413] Figures 17-1701 and 1702 are similar to Figures 16-1601 and 1602. In this case, the configuration may also include information that the aggregated WTRU may perform (re)selection of cells for the anchor WTRU.

[0414] 1703 in Figure 17 is similar to 1603 in Figure 16. Alternatively, cell selection for the anchor WTRU can be triggered on the aggregated WTRU side, and the display can be sent from the aggregated WTRU to the anchor WTRU to trigger cell selection.

[0415] The anchor WTRU may request cell selection to the aggregate WTRU (if it was not triggered by the aggregate WTRU itself). The request may include the desired frequency / carrier, PLMN, and RAT supported by the anchor WTRU.

[0416] Figures 1705 and 1706 are similar to Figures 1605 and 1606 in Figure 16. Figures 1707 to 1713 in Figure 17 are similar to Figures 1607 to 1613 in Figure 16, but with the opposite roles of anchor WTRU and aggregated WTRU.

[0417] The solutions described so far in this specification assume that the aggregation group was already in place.

[0418] This section describes a solution for cases where the aggregation group is not preset and can be determined simultaneously. One difference in this case is that the anchor WTRU can evaluate multiple aggregation options and corresponding (estimated) measurements for cell selection.

[0419] In this scenario, the anchor WTRU can "know" a set of potential WTRUs that should act as an aggregate WTRU. This can be known from the SL discovery phase and / or from the group configuration of the WTRUs. The aggregate may be further pre-configured and required to be activated within the anchor.

[0420] The procedure for selecting an integrated cell and an aggregate may be similar to the procedure for selecting a cell, but here the procedure may be carried out in parallel with multiple potential aggregate WTRUs. Signal determination may involve comparing signals from different combinations of aggregates, and the best combination may lead to the selection of that aggregate and its corresponding cell. The best combination may be, for example, the cell with the strongest RSRP with at least N aggregate WTRUs (where N is the number determined / configured). An anchor WTRU may report the selected cell and aggregate selection to other WTRUs.

[0421] In one alternative approach, the anchor WTRU may iteratively perform the cell selection procedure with different aggregation groups (or without aggregation) and select the aggregation that best satisfies the cell selection criteria.

[0422] For example, an anchor WTRU may initially perform cell selection without aggregation. If the cell is unsuitable or the WTRU cannot successfully camp on to the cell, it may attempt cell selection with an aggregated WTRU and repeat until cell selection is successful.

[0423] Figure 18 shows an example call flow for lower-layer aggregation for PLMN selection performed by aggregated WTRU.

[0424] In Figure 18, the aggregated WTRU assists the anchor WTRU in performing the measurement of PLMN selection. The initial configuration 1801 may include parameters for PLMN selection, for example, parameter values ​​for a high-quality PLMN criterion. The criterion may be modified for specific purposes of PLMN selection in the aggregated WTRU, or the offset may be applied to a typical -110 dBm criterion.

[0425] 1802 in Figure 18 is the same as 1602 in Figure 16.

[0426] An anchor WTRU can be triggered to perform PLMN selection.1803 For example, an anchor WTRU may request cooperative PLMN selection when its battery level is low, or when the WTRU is at the edge of a cell or has failed to find a high-quality PLMN in a previous attempt, or when there is a change in the WTRU's cooperative group (e.g., a new supporting WTRU). Triggers for PLMN selection may include when the anchor WTRU turns on its Uu radio or when the selected PLMN is not the highest priority PLMN and a new selection attempt is periodically performed. Coordination may be requested to be activated periodically (e.g., periodic measurement) or as a one-time coordination. Periodic coordination may be stopped when the WTRU has successfully selected its highest priority PLMN.

[0427] Figure 18, part 1804, is similar to Figure 16, part 1604, but the requirements may indicate PLMN selection parameters such as supported frequencies and carriers, and supported or preferred PLMNs. The measurement required for PLMN selection (from the requirements or configuration) is the RSRP of the cell.

[0428] Figures 1805 and 1806 in Figure 18 are similar to Figures 1605 and 1606 in Figure 16. WTRUs may perform measurements to assist in the selection of PLMNs on the configured or requested frequency and carrier. Aggregated and anchor WTRUs may limit the measurements of other WTRUs on the frequency and carrier for PLMNs supported by the anchor and / or aggregated WTRU. WTRUs may support only a subset of the available carriers and / or PLMNs, and support / capacity varies from WTRU to WTRU. WTRUs may indicate to each other which carriers / PLMNs are supported to avoid unnecessary measurements and reporting during coordinated processing.

[0429] Figure 18, item 1807 is similar to Figure 16, item 1607, but here the report is for PLMN measurements based on (pre)configuration. The report may include, for each frequency, the PLMN, corresponding cell ID, frequency information, measurement location, CQI, and CSI. The report may be filtered to remove PLMN measurements that do not meet the aggregated high-quality criteria.

[0430] Figures 1808 and 1809 in Figure 18 are similar to figures 1608 and 1609 in Figure 16. For the aggregation, processing, and determination of RSRPs, specific parameters and offset values ​​may be (pre)configured for the selection of PLMNs.

[0431] The AS layer of the anchor WTRU may evaluate the PLMN RSRP and report a high-quality RSRP to the NAS.1810 The criteria for a high-quality RSRP may be based on the (pre)configuration. The WTRU may further report the aggregated configuration used to obtain this RSRP to the NAS, and therefore the NAS may use the aggregated information as input for PLMN selection. The NAS may perform PLMN selection and report it to the AS layer of the WTRU.

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

[0433] An anchor WTRU can, for example, report the selection of an aggregate-based PLMN to the network during NAS registration.1812 It can show the network the aggregate configuration and the members of the group.

[0434] In alternative embodiments, for the joint selection of the aggregation method and PLMN, the anchor WTRU may perform 1801 to 1809 in parallel using different potential aggregation WTRUs.

[0435] In one example, the AS layer of an anchor WTRU may report multiple PLMN values ​​and WTRU aggregation methods to the NAS. The NAS may simultaneously select the best combination of PLMN and aggregation. In another example, the anchor AS layer of a WTRU may report the best aggregation method for each frequency to the NAS, and the NAS may select a PLMN without considering aggregation. Alternatively, the anchor AS layer of a WTRU may report the best aggregation for each frequency to the NAS, and the NAS may select a PLMN without considering aggregation. After reporting the PLMN to the AS layer, the AS layer of the anchor WTRU selects the aggregation corresponding to the selected and reported PLMN.

[0436] In an alternative embodiment, the selection of PLMNs is performed iteratively, where the WTRU first obtains high-quality PLMNs without aggregation, and if not, may retry with different aggregation options until a high-quality PLMN RSRP is estimated.

[0437] In an alternative embodiment, the selection of the PLMN of the anchor WTRU may be performed on the aggregated WTRU side rather than on the anchor side, as described in the previous paragraph.

[0438] If WTRUs can exchange measurement results, the measurements may be aggregated, and the output may reflect the quality or intensity of the actual jointly processed signal. However, the exchange of measurements may require active sidelink transmission, introducing delays and awaiting feedback from other WTRUs. In another example, (re)selection of a cell / PLMN for an aggregated WTRU may be performed without sharing measurements. The WTRU evaluates the criteria for cell selection based on its own measurements and estimates of the aggregated signal. Compared to other embodiments, this embodiment can reduce the accuracy of aggregated measurements but can improve access delays and reduce the need for active communication.

[0439] Figure 19 shows a flowchart illustrating an example of a cell / PLMN (re)selection procedure using estimated aggregated measurements.

[0440] Anchor WTRUs and aggregated WTRUs can swap configurations for the aggregation of lower layers for cell selection.1901 WTRUs can be configured to perform estimations of aggregated measurements instead of swapping on-demand measurements. Some WTRU information, such as the location of the WTRU, the cells selected by the WTRU if any, the WTRU's measurements, and the SL's measurements, may need to be swapped periodically (e.g., periodically or based on change triggers) to help the anchor WTRU perform estimations.

[0441] Some information may be periodically updated to keep the WTRU up-to-date. This may depend on the (pre)configuration.

[0442] The WTRU may perform aggregate-based cell selection by checking the configured operating mode (whether it can estimate aggregated WTRU measurements or receive measurement reports from aggregated WTRUs). The following assumes that the WTRU is configured to perform selection based on estimated measurements rather than on-demand measurements.

[0443] Cell selection may be triggered 1903. The anchor WTRU may perform the cell selection measurement required by its cell selection procedure 1904.

[0444] Anchor WTRU can be used to evaluate and implement cell selection based on its measurement and aggregated WTRU information.1905

[0445] In one embodiment, the anchor WTRU may apply an offset when evaluating the S criterion (and sub-criteria Srxlev>0 and Squal>0) to account for the gain estimated in the signal intensity by (potential) aggregation. In two different implementations, the offset may be applied to the defining criterion (e.g., Srxlev and Squal) or to the measurement itself (e.g., Qrxlevmeas and Qqualmeas).

[0446] As an example, the offset Qoffset_aggregation is defined (for example, as an RRC parameter or set to +3dB in the SL aggregate configuration if there are two WTRUs during aggregation) and can be used to modify the calculation of Srxlev as follows:

[0447] Srxlev=Qrxlevmeas-(Qrxlevmin+Qrxlevminoffset)-Pcompensation-Qoffsettemp+Qoffsetaggregation

[0448] Specific parameters and offset values ​​may be set for different aggregation types or sizes and (pre)configured parts. For example, the offset for aggregation of two WTRUs may differ from that for aggregation of three or more WTRUs. The expected signal quality from aggregation with more WTRUs should be better than aggregation with a single aggregated WTRU, and therefore the offset may reflect the expected gain. For example, one aggregated WTRU → +3dB, two aggregated WTRUs: +6dB, etc. As another example, the parameters and offset may differ depending on the connection between the WTRUs, e.g., whether the WTRUs use 3GPP NR SL or other wireless or non-wireless technologies. Aggregated signal processing may depend on the quality of the link between UEs (ideal, high bitrate, low bitrate, etc.), which may potentially affect the gain of the composite signal. Similar principles apply to both RSRP and RSRQ evaluations. For example, the expected signal quality from aggregation with more WTRUs may be more accurate than aggregation with a single aggregated WTRU, and therefore the offset may reflect the expected gain. For example, in the case of one aggregated WTRU, the offset could be 3 dB, and in the case of two aggregated WTRUs, the offset could be 6 dB.

[0449] If the anchor WTRU has some knowledge regarding the aggregation conditions of the WTRU, it may be preferable to apply an offset to the measurement itself, i.e., modify the Qrxlevmeas or include the offset in the measurement process in a previous step. The offset applied to the measurement may also be specific to the cell and aggregated WTRU.

[0450] For example, an anchor WTRU may receive an indication of the location of the aggregated WTRU and estimate that the two WTRUs are close to each other (for example, based on the WTRU's position / distance or the strength of the SL signal or the interconnection mode between the WTRUs), and the WTRU may expect similar signal strengths on both sides and therefore apply a +3dB gain to its own signal.

[0451] As another example, an anchor WTRU may receive indications of the aggregated WTRU regarding serving cells (or a selected set of cells), and an offset gain may be applied only to the measurements of these cells. For example, if the aggregated WTRU is in a given serving cell, it may be beneficial for the anchor WTRU to select the same serving cell. In this case, an offset that prioritizes the selection of the same cell may be used.

[0452] The offset can also include the power class and radio / processing capability or power and capability difference of the aggregated WTRU. For example, if the aggregated WTRU has a maximum power of 6 dB higher than the anchor WTRU, the anchor WTRU may apply a gain of 6 dB to its signal.

[0453] For example, an aggregated WTRU may relay its signal or combine it with an anchor WTRU signal. If the aggregated WTRU has stronger transmit power, its UL signal may be good for relaying or combining its signal to a selected cell, and therefore the WTRU may anticipate a significant signal boost, and thus an offset that facilitates the reference path to that cell may be beneficial.

[0454] The anchor WTRU may perform its cell selection based on (modified) measured cells and (modified) criteria.

[0455] The anchor notifies the aggregated WTRU of the selected cell, 1906, and the cell may be camped on as the anchor WTRU, 1907. The aggregated cell may be camped on as the aggregated WTRU, 1908.

[0456] Anchor WTRUs can report their selection to the network and may indicate the aggregated configuration and aggregated WTRU ID.

[0457] In the case of estimating aggregated measures for PLMN selection, a similar procedure can be applied, where the offset to the criterion in step 5 is applied to the threshold for the high-quality criterion, i.e., the requirements are lowered so that PLMN can be considered in lower RSRPs.

[0458] If the selection of cells or PLMNs is performed on the aggregated WTRU side, the procedure can be modified in the same sense with respect to Figure 16, namely, here steps 4 and 5 are performed on the aggregated WTRU side, using the aggregated WTRU measurement as the baseline or reference.

[0459] Figure 20 shows a flowchart of an example method for aggregated lower-layer PHY measurements for anchor WTRUs.

[0460] In embodiments relating to lower-layer PHY aggregation of measurements, an anchor WTRU may be configured to request, collect, and aggregate measurements from another WTRU. The anchor WTRU may receive WTRU information and configuration from the aggregation WTRU. The WTRU information and status may include, for example, the WTRU's capabilities, location, battery level information, interconnection capabilities such as the PC5 radio interface, radio status, PC5 resource availability, and measurement accuracy. The configuration may include aggregation triggers (e.g., based on coverage, battery level), processing steps for aggregation (e.g., aggregate after L1 filtering), and parameters specific to aggregation (e.g., L1 and L3 filter weights, accuracy configuration).

[0461] The WTRU may, for example, use SL transmission to send a configuration for aggregate measurements to the aggregate WTRU for cell / PLMN selection. The configuration may include processing steps for aggregation (e.g., transmitted after L1 filtering) and parameters specific to aggregation (e.g., L1 and L3 filter weights, precision configuration).

[0462] A WTRU may send an aggregated measurement request to an aggregated WTRU. This may be triggered by measurements requested for cell selection, cell re-selection, and PLMN selection procedures. The measurement may include a measurement configuration (e.g., the RS to be measured, processing steps).

[0463] WTRU can perform spectral measurements and perform preprocessing steps based on the configuration (e.g., L1 filter based on configuration and accuracy requirements) 2004.

[0464] WTRU may receive pre-processed measurements and indications of the accuracy requirements used from the aggregated WTRU in 2005.

[0465] WTRU may determine and apply an offset to the received measurement based on the configuration and the received accuracy indication 2006.

[0466] The WTRU aggregates the received measurements and can resume processing the measurements. The processing step can be specifically configured for aggregated measurements, for example, a dedicatedly configured L3 filter.

[0467] WTRU reports aggregated measurements to the requesting layer / procedure entity, which may then restart the corresponding procedure, such as cell selection, cell re-selection, or PLMN selection (as of 2008).

[0468] A WTRU may report aggregated measurement results (e.g., aggregated RSRP, selected cell / PLMN) and configuration to an aggregated WTRU (2009). A WTRU may report aggregated configuration (e.g., aggregated WTRU ID, measurement, selected cell / PLMN, and offset parameters) to the network.

[0469] Figure 21 shows a flowchart of an example of a method for aggregated lower-layer PHY measurements for aggregated WTRU.

[0470] The aggregated WTRU can assist the anchor WTRU in performing cell or PLMN selection. It can receive measurement requests, including the configuration and requirements of the measurement process, and report the measurements using specific configured preprocessing.

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

[0472] The WTRU may, for example, use SL transmission to select cell / PLMN, receive a configuration for aggregate measurements from the aggregate WTRU.2102 The configuration may include processing steps for aggregation (e.g., transmitted after L1 filtering), and parameters specific to aggregation (e.g., L1 and L3 filter weights, precision configuration).

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

[0474] WTRU may perform measurements according to the received configuration and apply configured preprocessing / filtering.2104 Preprocessing (e.g., L1 filter weights) may be applied based on the requirements and WTRU's capabilities.

[0475] WTRU can be partially selected based on configured criteria for those signal quality / intensity.

[0476] The WTRU may transmit pre-processed measurements to the anchor WTRU.2105 The measurements may include the accuracy of the measurements used. In one embodiment, if the required accuracy requirements are not met, the WTRU sends only an indication.

[0477] The WTRU receives aggregated measurement results and a (re)selected display of the cell / PLMN from the anchor WTRU and may optionally change the selected PLMN or the cell to be camped on 2106.

[0478] Figure 22 shows a flowchart illustrating an example of a method for cell selection for anchor WTRU using lower-layer PHY measurement aggregation estimation.

[0479] Anchor WTRUs can perform cell (re)selection or PLMN selection using estimated aggregated measures. Without requiring on-demand measurements, aggregated measures can be estimated and used to assess the suitability of cell / PLMN selection using specific criteria.

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

[0481] WTRU may perform spectral measurements for cell (re)selection or PLMN selection procedures.2202

[0482] The WTRU can be used to determine the aggregated configuration for the (re)selection threshold of the cell / PLMN and the offset for evaluating the measurement based on the WTRU information.2203 In one example, a 3dB offset may be used when the aggregated WTRU is not collated with the anchor WTRU. In another example, a 3dB offset may be used when the aggregated WTRU has twice the number of antennas as the anchor WTRU.

[0483] WTRU can evaluate measurements and examine the (re)selection criteria for cells / PLMNs.2204 The evaluation may be based on applying bias as an offset to the Srxlev / high-quality criteria. Alternatively, the offset may be applied to the measurement instead of the threshold. WTRU can verify the suitability of selected cells and camp on them.

[0484] A WTRU may transmit selected cells (e.g., cell ID, PLMN, frequency, RAT) or PLMNs (e.g., PLMN ID, frequency, RAT) to an aggregated WTRU.2205 A WTRU may transmit aggregated information and a display of (re)selected cells / PLMNs to the network, for example, through a registration procedure.

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

[0486] Figure 23 shows a flowchart of an example of a measurement aggregation procedure. The first WTRU may receive WTRU information from the second WTRU, including at least one of the following: WTRU capability, WTRU location / position, or WTRU battery level information.2301 The first WTRU may receive measurement configuration information associated with measurement preprocessing from the second WTRU.2302 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 a reference signal to be measured and preprocessed. The measurement configuration information associated with measurement preprocessing may include reporting timing information, where reporting timing information includes at least one of single reporting, periodic reporting, or event-based reporting.

[0487] The first WTRU may receive a request from the second WTRU to report pre-processed measurement results.2303 The requested pre-processed measurements may include reference signal received power (RSRP) or reference signal received quality (RSRQ).

[0488] The first WTRU may determine one or more pre-processed measurement results based on at least measurement configuration information associated with the measurement preprocessing.2304 One or more pre-processed measurement results may include at least one of the following: raw measurement sample ("A", Figure 2, 201), Layer 1 filtered measurement ("A1", Figure 2, 203), Layer 3 filtered beam measurement ("E", Figure 2, 212), cell quality ("B", Figure 2, 205), filtered cell quality ("C", Figure 2, 207), or RSRP ("D", Figure 2, 209). The Layer 3 filtered beam measurement may include one of beam integration, beam selection, or filtering of the Layer 3 beam.

[0489] The first WTRU may send at least one of one or more pre-processed measurement results to the second WTRU 2305. The first WTRU may receive aggregated measurement results from the second WTRU in response to sending at least one of one or more pre-processed measurement results 2306.

[0490] The first WTRU may be a relay WTRU, an aggregation WTRU, or a support WTRU.

[0491] The second WTRU may be a remote WTRU, an anchor WTRU, or a supported WTRU.

[0492] While features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in computer programs, software, or firmware embedded in computer-readable media 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-ROM disks and digital multipurpose disks (DVDs). Processors related to software may be used to implement radio frequency transceivers for use in WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

Claims

1. A method performed by a first wireless transceiver unit (WTRU), wherein the method is The second WTRU receives measurement configuration information associated with the measurement preprocessing, In the first WTRU, the pre-processed measurement results are determined based at least on the measurement configuration information, The second WTRU transmits one or more pre-processed measurement results, The second WTRU receives aggregated measurement results in response to the transmission of one or more pre-processed measurement results, Methods that include...

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

3. The method according to claim 1 or 2, wherein the measurement configuration information associated with the preprocessing of the measurement includes reporting timing information, and the reporting timing information includes at least one of a single report, a periodic report, or an event-based report.

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

5. The method according to any one of claims 1 to 4, wherein the one or more pre-processed measurement results include a Layer 1 filtered measurement result.

6. The method according to any one of claims 1 to 5, wherein the aggregated measurement results include the result of applying a Layer 3 filter to at least one of the pre-processed measurement results from the first WTRU.

7. The method according to claim 6, wherein the layer 3 filter coefficients include one or more layer 3 aggregation filter coefficients, and the layer 3 aggregation filter coefficients are configured by a network for use in measurement aggregation.

8. The method according to any one of claims 1 to 7, further comprising receiving second WTRU information from the second WTRU, which includes at least one of the functions of the WTRU, the location / position of the WTRU, or the battery level information of the WTRU.

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) or Layer 1 filtered reference signal received quality (RSRQ).

11. A first wireless transceiver unit (WTRU), wherein the first WTRU comprises at least one processor and transceiver, and the at least one processor and transceiver are From the second WTRU, receive measurement configuration information associated with the measurement preprocessing. In the first WTRU, the pre-processed measurement results are determined based at least on the measurement configuration information. One or more pre-processed measurement results are transmitted to the second WTRU. A first WTRU is configured to receive aggregated measurement results in response to the transmission of one or more pre-processed measurement results from the second WTRU.

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

13. The first WTRU according to claim 11 or 12, wherein the measurement configuration information associated with the preprocessing of the measurement includes reporting timing information, the reporting timing information includes at least one of a single report, a periodic report, or an event-based report.

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

15. The first WTRU according to any one of claims 11 to 14, wherein the one or more pre-processed measurement results include a layer 1 filtered measurement result.

16. The first WTRU according to any one of claims 11 to 15, wherein the aggregated measurement results include the result of applying a Layer 3 filter to at least one of the pre-processed measurement results from the first WTRU.

17. The first WTRU according to claim 16, wherein the layer 3 filter coefficients include one or more layer 3 aggregation filter coefficients, and the layer 3 aggregation filter coefficients are configured by a network for use in measurement aggregation.

18. The first WTRU according to any one of claims 11 to 17, wherein the at least one processor and transceiver is further configured to receive second WTRU information from the second WTRU, including at least one of the functions of the WTRU, the location / position of the WTRU, or the battery level information of the WTRU.

19. The first 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 first WTRU according to any one of claims 11 to 19, wherein the pre-processed measurement result includes at least one of Layer 1 filtered reference signal received power (RSRP) or Layer 1 filtered reference signal received quality (RSRQ).

Images