Cell / PLMN selection

Abstract

Systems, methods, and instrumentalities are described herein for stored selection information based on wireless transmit / receive unit (WTRU) aggregation for cell selection and public land mobile network (PLMN) selection. Cell selection may be performed using stored selection information from the aggregation device. The PLMN selection may be performed using the stored selection information from the aggregation device. The WTRU may aggregate its stored selection information for cell selection sharing and / or PLMN selection sharing, e.g., to enhance cell selection procedures and / or reduce scanning operations. The aggregated and / or anchor user may verify the validity of the stored selection information. The coordinator WTRU may concentrate and / or manage the aggregated stored selection information.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 425,596, filed November 15, 2022, the contents of which are incorporated herein by reference. Background Art

[0003] Mobile communications using wireless communications continue to evolve. The fifth generation may be referred to as 5G. The previous (legacy) generation of mobile communications may be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0004] This document describes systems, methods, and means for cell selection and public land mobile network (PLMN) selection based on stored information aggregated by wireless transmit / receive units (WTRUs). Cell selection may be performed using stored selection information from an aggregating device. PLMN selection may be performed using stored selection information from an aggregating device. WTRUs may aggregate their stored selection information for cell selection sharing, e.g., to improve cell selection procedures and / or reduce scanning operations. WTRUs may aggregate their stored selection information for PLMN selection sharing, e.g., to improve cell selection procedures and / or reduce scanning operations. Aggregating users and / or anchor users may verify the validity of the stored selection information. A coordinator WTRU may centralize and / or manage the aggregated stored selection information.

[0005] A first device (e.g., a first WTRU) may include a processor configured to perform one or more actions. The first device may determine that a condition has been met. The first device may send a request to a second device (e.g., a second WTRU). The request may be for stored information (e.g., stored information associated with cell selection (reselection)). The first device may receive information including the stored information from the second device. The first device may determine whether the stored information is valid. For example, if the first device determines that the stored information is valid, the first device may perform cell selection (reselection) using the stored information.

[0006] The first device may determine to perform cell selection. The conditions may include a failed cell selection attempt and / or the first device having no locally stored information associated with cell (re)selection.

[0007] The stored information may include one or more of cell ID, cell frequency, synchronization signal block (SSB), or synchronization timing.

[0008] The information may indicate a location of the second device.Determining whether the stored information is valid may be based on whether a distance threshold from the first device to the second device is met.

[0009] The information may indicate a measurement time associated with the information.Determining whether the stored information is valid may be based on whether a delay threshold from the measurement time is met.

[0010] The first device may receive an indication of (one or more) validity conditions. The (one or more) validity conditions may include one or more of supported frequencies, channels, valid cell IDs, PLMNs, a time associated with the measurement, or a location of the measurement. Determining whether the stored information is valid may be based on whether one or more of the validity conditions are met.

[0011] The first device may update the locally stored information with the information, eg, based on a determination that the stored information is valid.

[0012] A first device (e.g., a WTRU) may include a processor configured to perform one or more actions. The first device may receive a request, for example, from a second device (e.g., a WTRU). The request may be for stored information (e.g., stored information associated with cell selection (or reselection)). The stored information may be stored (e.g., locally) by the first device. The first device may send information to the second device, which may include the stored information.

[0013] The first device may determine whether the stored information is valid. If the first device determines that the stored information is valid, the first device may send the information. For example, if the first device determines that the stored information is invalid, the first device may not send the stored information. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1B is a diagram according to one embodiment that can be Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown in FIG.

[0016] Figure 1C is a diagram according to one embodiment that can be Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) for use within a communication system shown in FIG.

[0017] Figure 1D is a diagram according to one embodiment that can be Figure 1A A system diagram of an additional example RAN and an additional example CN for use within the communication system shown in FIG.

[0018] Figure 2 An example of a home automation personal IoT network (PIN) is illustrated.

[0019] Figure 3 An example of a wearable PIN is illustrated.

[0020] Figure 4A An example of two WTRUs communicating directly without network coverage is illustrated.

[0021] Figure 4B An example of two WTRUs communicating directly with network coverage is shown.

[0022] Figure 5 An example of a control plane protocol stack for collaboration messages is illustrated.

[0023] Figure 6 An example of an exchange between two WTRU control plane protocol stacks with inter-WTRU cooperation is illustrated.

[0024] Figure 7 An example of a control plane protocol stack for inter-WTRU assistance is illustrated.

[0025] Figure 8 An example of a collaborative architecture with a (eg, one) non-access stratum (NAS) entity controlling multiple WTRUs is illustrated.

[0026] Figure 9A An example of a WTRU coordinator connected to other WTRUs in the presence of direct inter-WTRU connections is illustrated.

[0027] Figure 9B An example of a WTRU coordinator connected to other WTRUs without direct inter-WTRU connections is illustrated.

[0028] Figure 10 An example of selection information stored for cell selection aggregation is illustrated.

[0029] Figure 11 An example of aggregated stored selection information with transport-side verification is illustrated.

[0030] Figure 12 An example of requesting / using stored selection information for cell selection is illustrated.

[0031] Figure 13 An example is shown in which the coordinator aggregates stored selection information for cell selection.

[0032] Figure 14 An example of using aggregated stored selection information for public land mobile network (PLMN) selection is illustrated.

[0033] Figure 15An example of PLMN selection with aggregated stored selection information and Tx-side verification is illustrated.

[0034] Figure 16 An example of PLMN selection with aggregated stored selection information on the receiver side is illustrated.

[0035] Figure 17 An example of PLMN selection is illustrated where the coordinator WTRU has aggregated stored selection information. DETAILED DESCRIPTION

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

[0037] like Figure 1AAs shown in FIG, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0039] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. 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 referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, 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 for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0041] 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, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

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

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

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

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

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

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

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

[0050] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B , the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0051] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. 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, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0058] 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, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, an FM radio unit, a digital music player, a media player, an electronic game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

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

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

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

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

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

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

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

[0068] Even though the WTRU Figure 1A-Figure 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communication interface with a communication network.

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

[0070] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or be connected to a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS destined for a STA may reach the AP and may be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. For example, traffic between STAs within a BSS may be sent through the AP, where the source STA may send traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or 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 the source STA and the destination STA) using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

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

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

[0073] Very High Throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining adjacent 20MHz channels. A 160MHz channel can be formed by combining 8 adjacent 20MHz channels, or by combining two non-adjacent 80MHz channels - this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing separately. These streams can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

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

[0075] 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 a primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA that supports (e.g., only supports) a 1 MHz mode (e.g., an MTC-type device), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network assignment vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports the 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy, even if most of the frequency band remains idle and can be used.

[0076] 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 6 MHz to 26 MHz, depending on the country code.

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

[0078] The RAN 113 may include gNBs 180a, 180b, and 180c, although it should be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0079] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing a different number of OFDM symbols and / or lasting for a different length of absolute time).

[0080] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing another RAN (e.g., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for the serving WTRUs 102a, 102b, 102c.

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

[0082] Figure 1DThe CN 115 shown in FIG may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one session management function (SMF) 183 a, 183 b, and possibly a data network (DN) 185 a, 185 b. While each of the aforementioned elements is depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0083] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of service being utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 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.

[0084] The SMFs 183a and 183b may connect to the AMFs 182a and 182b in the CN 115 via the N11 interface. The SMFs 183a and 183b may also connect to the UPFs 184a and 184b in the CN 115 via the N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure traffic routing through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. The PDU session type may be IP-based, non-IP-based, Ethernet-based, and the like.

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

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

[0087] Given that Figure 1A-Figure 1D and Figure 1A-Figure 1D As described herein, one or more or all of the functionality described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functionality.

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

[0089] One or more emulated devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulated devices can be used in test scenarios in a test lab and / or in a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more emulated devices can be test devices. The emulated devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0090] Idle mode operation may be performed, for example, in 3GPP. A WTRU implementing a radio access technology (RAT) (such as one or more of 2G, 3G, 4G, and / or 5G RATs) may perform public land mobile network (PLMN) selection, cell selection / reselection, and / or location registration (e.g., including tracking area update procedures), for example, while in RRC_IDLE mode and / or RRC_INACTIVE mode. A device (e.g., a 5G device) may (e.g., also) support RAN Notification Area (RNA) updates and / or operation in the RRC_INACTIVE state.

[0091] The PLMN may be selected by the WTRU. For example, in response to the WTRU being turned on, the WTRU may select a PLMN. Associated RAT(s) may be set for the selected PLMN. The WTRU may search (e.g., for cell selection) for (e.g., suitable) cells of the selected PLMN. The WTRU may select (e.g., suitable) cells to provide available services. The WTRU may monitor a control channel of the selected cell. The WTRU may register its presence, for example, based on (e.g., by means of) a NAS registration procedure in the tracking area of ​​the selected cell.

[0092] The WTRU may (e.g., while in RRC_IDLE) perform received signal strength measurements on the serving cell and / or neighbor cells. For example, if the WTRU finds a cell to be a more suitable cell (e.g., based on cell reselection criteria), the WTRU may reselect to that cell and / or may camp on the (e.g., reselected) cell. For example, if the new cell does not belong to at least one tracking area with which the WTRU is registered, a location registration may be performed. The WTRU may (e.g., also) search for a higher priority PLMN, for example, at regular time intervals, and / or search for a (e.g., suitable) cell, for example, based on conditions, such as whether its NAS has already selected another PLMN.

[0093] A WTRU may lose coverage of a registered PLMN. A new PLMN may be selected (e.g., automatically), or an indication of available PLMNs may be provided to the user, for example, so that a manual selection may be performed (e.g., based on loss of coverage of a registered PLMN). The network may prioritize cell selection over certain RATs, control the rate at which low, medium, or high mobility WTRUs perform cell reselection, and / or prohibit selected tracking areas from being reselected by the WTRU.

[0094] A WTRU may receive system information from a PLMN (e.g., if / when the WTRU is camped on a cell in an RRC_IDLE state or in an RRC_INACTIVE state), establish an RRC connection or resume a suspended RRC connection, and / or receive Earthquake and Tsunami Warning System (ETWS) or Commercial Mobile Alert Service (CMAS) notifications. The network may send control messages to a registered WTRU or may deliver data to it. The network may (e.g., in most cases) be aware of the set of tracking areas in which the WTRU is camped. A paging message for the WTRU may be sent on the control channel of one or more (e.g., all) cells in the corresponding set of tracking areas. The WTRU may receive and may respond to paging messages from the network.

[0095] A PLMN search may be performed. For example, based on the WTRU's ability to find available PLMNs and available closed access groups (CAGs), the WTRU may scan one or more (e.g., all) RF channels in the NR band. The WTRU may (e.g., on each carrier) search for (e.g., the strongest) cell and read its system information, for example, to find out which PLMN(s) the cell belongs to and any associated (one or more) CAGs. The WTRU may (e.g., also) read system information of one or more (e.g., many) cells (e.g., the strongest cells), for example, for operation with shared spectrum channel access. The WTRU may (e.g., in the case where the WTRU can read one or several PLMN identities in one or more (strongest) cells) report each discovered PLMN and any associated CAG-ID to the NAS. Based on one or more conditions (such as meeting a high quality criterion), the PLMN may be reported as a high quality PLMN without a reference signal received power (RSRP) value. An example of a high quality criterion may be a measured RSRP value greater than or equal to -110 dBm (e.g., for an NR cell). PLMNs discovered that do not meet high quality criteria (e.g., even though the WTRU has been able to read the PLMN identity) may be reported to the NAS along with their corresponding RSRP values ​​and any associated CAG-IDs. The quality metrics reported by the WTRU to the NAS may be the same for each PLMN discovered in the same cell(s).

[0096] The search for a PLMN may be stopped, for example, based on a request from the non-access stratum (NAS). The WTRU may optimize the PLMN search, for example, by using stored selection information. The stored information may include, for example, frequency and / or information about cell parameters from previously received measurement control information elements.

[0097] The WTRU may select a PLMN. For example, a cell selection procedure may be performed (eg, after PLMN selection) to select a (eg, suitable) cell of the PLMN to camp on.

[0098] The cell selection may be performed by initial cell selection and / or cell selection using stored selection information.

[0099] Initial cell selection may occur without knowing in advance which RF channels are NR frequencies. For example, depending on the capabilities of the WTRU, the WTRU may scan one or more (e.g., all) RF channels in the NR band to find a suitable cell. The WTRU may search (e.g., only) the (one or more) strongest cells (e.g., on each frequency). The WTRU may search for the next (one or more) strongest cells, e.g., for operation with shared spectrum channel access. The WTRU may select the (e.g., suitable) cell found among the searched cells.

[0100] The cell may be selected by utilizing stored selection information. The stored selection information may include, for example, stored information from previously received measurement control information elements and / or from frequencies and / or cell parameters of previously detected cells. The WTRU may find a (e.g., suitable) cell. The WTRU may select the found (e.g., suitable) cell. For example, if no (e.g., suitable) cell is found, an initial cell selection may be performed.

[0101] A WTRU may perform measurements for cell selection and / or reselection purposes (eg, as described herein).

[0102] The WTRU may evaluate the Srxlev and Squal of non-serving cells, for example, for reselection evaluation purposes. The WTRU may use the parameters provided by the serving cell to perform a final check on the cell selection criteria. The WTRU may use the parameters provided by the target cell for cell reselection.

[0103] The NAS may control the RAT(s) in which cell selection may be performed, for example, by indicating the RAT(s) associated with the selected PLMN, by maintaining a list of prohibited registration areas, and / or by maintaining a list of equivalent PLMNs. The WTRU may select a suitable cell based on, for example, RRC_IDLE or RRC_INACTIVE state measurements and / or cell selection criteria.

[0104] For example, the WTRU may use stored information (eg, if available) of one or more (eg, several) RATs to speed up the cell selection process.

[0105] For example, if / when camped on a cell, the WTRU may (e.g., periodically) search for a (e.g., better) cell (e.g., based on cell reselection criteria). For example, if a (e.g., better) cell is found, the (e.g., better) cell may be selected. A change in cell may imply a change in RAT.

[0106] The cell selection criterion S may be satisfied, for example, based on (eg, according to) inequality (Ineq.) (1):

[0107] Srxlev>0 and Squal>0 (1)

[0108] Wherein, Srxlev can be provided, for example, according to equation (2), and Squal can be provided, for example, according to equation (3):

[0109] Srxlev=Q rxlevmeas -(Q rxlevmin +Q rxlevminoffset )-P compensation -Q offsettemp (2)

[0110] Squal=Q qualmeas -(Q qualmin +Q qualminoffset )-Q offsettemp (3)

[0111] SRXlev may be a cell selection RX level value (dB), e.g., as described herein. Squal may be a cell selection quality value (dB), e.g., as described herein.

[0112] A WTRU may participate in WTRU grouping / aggregation.

[0113] A personal IoT network (PIN) and / or a customer premises network (CPN) may provide local connectivity between WTRUs and / or non-3GPP devices. A CPN (e.g., via an evolved residential gateway (eRG)) and / or a PIN element (e.g., via a PIN element with gateway capabilities) may provide access to (e.g., 5G) network services for WTRUs and / or other (e.g., non-3GPP) devices on the CPN or PIN. The CPN and PIN may (e.g., typically) be owned, installed, and / or (e.g., at least partially) configured by a customer of a public network operator.

[0114] A CPN may be a network located within a premises (e.g., a residence, office, or store). The CPN may provide connectivity to a (e.g., 5G) network (e.g., via an eRG). The eRG may be connected to a network (e.g., a 5G core network) via, for example, wired, wireless, or hybrid access. A Resident Radio Access Station (PRAS) is an example of a base station installed in a CPN. A WTRU may access a CPN and / or (e.g., 5G) network service, for example, via a PRAS. The PRAS may be configured to use licensed and / or unlicensed frequency bands. Connections between the eRG and the WTRU, other (e.g., non-3GPP) devices, and / or the PRAS may use other (e.g., non-3GPP) technologies (e.g., Ethernet, optical, WLAN).

[0115] PINs can include PIN elements that communicate using a PIN direct connection and / or a direct network connection. PINs can be managed locally (e.g., using a PIN element with management capabilities). Examples of PINs include networks for wearable devices and / or smart home / smart office devices. PIN elements (e.g., via a PIN element with gateway (GW) capabilities) can access (e.g., 5G) network services and / or can communicate with PIN elements that are not within range using a PIN direct connection. PINs can include at least one PIN element with gateway capabilities and / or at least one PIN element with management capabilities.

[0116] A PIN element with management capabilities may be a PIN element that allows (eg, provides a means for) an authorized administrator to configure and / or manage the PIN.

[0117] Figure 2 An example of a home automation personal IoT network (PIN) is illustrated.

[0118] Figure 3 An example of a wearable PIN is illustrated.

[0119] WTRU aggregation may refer to an enhancement of a network (e.g., NR) sidelink (SL) relay with one or more (e.g., specific) multipath properties. Multipath relaying may (e.g., also) be used for WTRU aggregation. For example, a WTRU may connect to a network via a direct path and / or via another WTRU using a non-standardized WTRU-WTRU interconnect. For example, WTRU aggregation may support (e.g., provide) applications involving high UL bit rates on a network (e.g., 5G) terminal if / when a (e.g., normal) WTRU may be too limited by the UL WTRU transmit power to achieve the (e.g., required) bit rate, e.g., at the cell edge. WTRU aggregation may improve reliability, stability and / or reduce service latency. For example, the channel condition of a terminal may be deteriorating. Another terminal may be used to compensate for the unstable service performance caused by the changing channel condition.

[0120] A WTRU may spend most of its time in an RRC idle / inactive mode state. The power consumption associated with idle and inactive mode operations may have a significant impact on the battery life of the WTRU. Active scanning operations during idle and inactive modes, such as scanning radio channels for PLMN / cell selection (reselection), may utilize / consume power in idle and inactive modes.

[0121] Some devices (e.g., among a wide variety of devices and uses) may be limited in their ability to access the network (e.g., by their capabilities, power, energy, and / or connectivity) (e.g., unlike conventional devices). Applications and / or uses may (e.g., also) cause devices to be grouped to deliver their services.

[0122] For example, device performance can be improved by having another device assist the device (such as by creating a device group or device aggregation). For example, in addition to inter-device communication, devices can be grouped together. The "aggregated" device can assist the "anchor" device with one or more of its resources, time, processing power, etc.

[0123] Devices in a group may be (eg, generally) located near each other and / or may be associated with (eg, have a requirement for) services from a cell and / or network provider, such as being served by a particular cell.

[0124] Aggregation between WTRUs may be enabled and / or supported in cell or PLMN selection. (Each) WTRU may (e.g., individually) perform procedures without input from other WTRUs, which may not utilize one or more relationships to improve cell and / or PLMN selection performance. One or more methods / procedures may be implemented to enable WTRU aggregation and / or procedures performed by WTRUs to support WTRU cooperation. Aggregated WTRUs may utilize their stored selection information across multiple WTRUs to improve performance and / or enhance cell selection and / or PLMN selection processes.

[0125] In RRC idle and / or inactive mode, cooperation may be enabled / implemented between WTRUs. WTRUs (e.g., in RRC idle and / or inactive mode) may cooperate in the enabling, signaling, and / or configuration of WTRU aggregation of stored information shared for cell selection, which may improve the cell selection procedure and / or reduce scanning operations. WTRUs (e.g., in RRC idle and / or inactive mode) may cooperate in the enabling, signaling, and / or configuration of WTRU aggregation of stored information shared for PLMN selection, which may improve the cell selection procedure and / or reduce scanning operations. WTRUs (e.g., in RRC idle and / or inactive mode) may cooperate to verify the validity of information stored by aggregated users and anchor users. WTRUs (e.g., in RRC idle and / or inactive mode) may cooperate in the enabling, signaling, and / or configuration of a coordinator WTRU for centralizing and / or managing aggregated stored information.

[0126] An anchor WTRU may be the source or destination of traffic and payload data. For example, in the context of (e.g., NR) SL relay, a remote WTRU may be an anchor WTRU. An anchor WTRU may or may not be directly connected to the network and / or may (e.g., typically) utilize assistance from other nodes.

[0127] The converged WTRU may assist / help the anchor WTRU access the network. The assistance may be, for example, relaying traffic (e.g., SL relay, such as NR SL relay) and / or offloading one or more (e.g., certain) tasks and / or procedures from the anchor WTRU.

[0128] A coordinator WTRU may manage the coordination within a group of WTRUs. A coordinator WTRU may be used to offload tasks from other WTRUs, receive or send coordination information to other devices, distribute and / or control tasks performed by other WTRUs, etc. A coordinator WTRU may be used interchangeably with a controller, manager, or master WTRU.

[0129] Provides architecture and collaboration. WTRUs may be formed into groups. Communications (e.g., PC5 communications or other inter-WTRU connections) may be established between WTRUs. Groups may be set up for different applications, services, and / or performance purposes, e.g., depending on their configuration. A group may include a coordinator device.

[0130] Various (e.g., several) architectures may be used for inter-WTRU coordination of RRC idle and inactive mode procedures. For example, inter-WTRU coordination may be performed using an inter-WTRU connection such as PC5 (e.g., sidelink) or other communication systems that may be standardized outside of 3GPP or non-standardized such as Wi-Fi, Bluetooth, wired connections, etc. One or more examples are provided using the NR sidelink (e.g., as a default), although other inter-WTRU interfaces may be used interchangeably unless otherwise noted.

[0131] A WTRU may or may not be under the coverage of a network. A connection to a network is not (eg, not always) required to perform direct inter-WTRU cooperation.

[0132] Figure 4A An example of two WTRUs communicating directly without network coverage is illustrated. Figure 4B An example of two WTRUs communicating directly with network coverage is shown.

[0133] An example inter-WTRU communication architecture is provided. In the example architecture, multiple (eg, two) WTRUs may be able to exchange information for aggregation over a PC5 link.

[0134] Figure 5 An example of a control plane protocol stack for collaboration messages is illustrated.

[0135] For example, transmissions (e.g., between WTRUs) may be performed using a PC5 collaboration (PC5-C) interface that may link the collaboration layer in each device via direct PC5 communication, e.g., as described by a user for Figure 5 This is shown in the example of a collaborative protocol stack.

[0136] The PC5 collaboration interface may be a dedicated interface, eg, with a dedicated SRB for collaboration information. PC5 collaboration may be performed (eg, alternatively and interchangeably) using PC5 signaling (PC5-S) or SL RRC messages (PC5-RRC).

[0137] For example, collaboration may be implemented as an actual layer in the sidelink protocol stack and / or by reusing the SL signaling protocol layer or the RRC layer. The collaboration layer may enable collaboration and communication between layers of the protocol stack of different WTRUs (e.g., NAS or NR Uu AS control plane).

[0138] Figure 6 An example of an exchange between two WTRU control plane protocol stacks with inter-WTRU cooperation is shown. Figure 6 An example of a user's control plane is depicted in . Figure 6 An example of a 3GPP sidelink inter-WTRU connection is shown. WTRU1's NAS may exchange messages with WTRU2's NAS via PC5-C. The ASs of different WTRUs may also communicate. The AS and NAS (e.g., for each WTRU) may perform their own tasks for WTRU connections and procedures and may exchange information that may be used as input for decision making.

[0139] The WTRUs may exchange signaling (eg, before performing a coordination procedure) to configure how they may coordinate their respective capabilities and communication channels.

[0140] The collaboration configuration may include information such as one or more of: available RATs; supported bands / carriers; Uu and SL capabilities; WTRU profiles (e.g., WTRU type, power profile); or collaboration capabilities (e.g., which coordination procedures are supported and / or which information requests or sharing are supported).

[0141] A WTRU may send a directed transmission to users within its group using, for example, PC5, unicast, multicast, and / or broadcast transmissions. Transmissions may be periodic or aperiodic (eg, depending on the content of the transmission).

[0142] The cooperation configuration may include scheduling and / or times when the WTRU may (eg, be expected to) transmit or receive cooperation signaling (eg, using periodic scheduling, dynamic scheduling, and / or signaling).

[0143] A WTRU may request information from another WTRU at a layer corresponding to the collaboration. For example, a WTRU may send a request via PC5-C and receive a reply / report on PC5-C. The request may be for a one-time report or may be for (e.g., may be triggered by) periodic / aperiodic reporting (e.g., by subscribing to collaborative content). For example, after performing the relevant procedures, the WTRU may (e.g., in response to receiving the request) reply with the information to be reported (e.g., if available). The WTRU may report to the WTRU that transmitted the request. A WTRU (e.g., registered for a specific periodic collaboration) may report to the requesting / registering WTRU periodically or aperiodically (e.g., based on being triggered by an information update).

[0144] Figure 7 The diagram shows an example of a (e.g., 3GPP) sidelink inter-WTRU connection. WTRU1's NAS may use (e.g., two) different WTRUs' ASs to perform tasks and / or may use another user's AS to perform tasks (e.g., jointly). Similar operations may be applied at different layers of the AS.

[0145] Figure 7 An example of a control plane protocol stack for inter-WTRU assistance is illustrated.

[0146] The collaborating WTRUs may (e.g., first) coordinate their NAS and AS configurations, such as available RATs, supported frequencies, and / or procedures. WTRU1's NAS may (e.g., using PC5-C) send commands to WTRU2's AS. WTRU2 may perform the requested procedure or task. WTRU2 may (e.g., after completing the procedure or task) report the output to WTRU1's NAS. Minimal changes / modifications may be made to the operational interfaces and specifications. For example, the content of the reports and commands may be similar to (e.g., classic) inter-layer communications within a single WTRU. The destination may be changed to an upper layer (e.g., or lower layer) of another WTRU.

[0147] In some (e.g., alternative) examples, WTRU1's NAS may (e.g., also) use WTRU2's AS to perform tasks, for example by communicating through WTRU2's NAS layer, which may forward the tasks to its AS (e.g., transparently and / or by controlling AS behavior to be compatible with the rest of the WTRU's tasks).

[0148] Figure 8An example of a collaborative architecture with a (eg, one) NAS entity controlling multiple WTRUs is illustrated.

[0149] As Figure 8 As shown in the example architecture shown in , a (e.g., single) NAS entity may directly control the AS entities of multiple WTRUs, which is similar to dual connectivity, for example. The NAS entity may be located in one WTRU (e.g., one of the controlled WTRUs) or in another WTRU. Communication between non-colocated NAS and AS layers may be performed using inter-WTRU coordination (e.g., PC5-C and / or other inter-WTRU links).

[0150] Examples of WTRU groups and aggregation are provided. Device groups may be formed by services and / or applications in various scenarios and / or services, such as in a personal IoT network (PIN), a tethered device (e.g., a wearable device), or an interactive service (e.g., NCIS), etc. For example, in addition to potential network connections, the devices in a device group may communicate with each other for their services. The WTRUs in a group (e.g., in an application and / or service-oriented group) may be selected and / or managed by the service / application, for example, in a higher layer. Group formation communication exchanges may be configured, for example, during a PC5 connection establishment phase and / or (e.g., after connection establishment) using PC5-RRC or PC5-S type signaling.

[0151] In some examples, one or more (e.g., some) of the devices may be limited in their ability to access the network, power, energy, and / or connectivity, for example, as other / regular devices may access the network. WTRUs may be "aggregated." An "aggregated" WTRU may, for example, assist another "anchor" WTRU, for example, to improve the performance of the (e.g., limited) WTRU. This assistance may be in the form of task offloading and / or relaying. The RAN may (e.g., in this case) perform grouping of devices, for example, at the WTRU and / or gNB level (e.g., using PC5-C or Uu signaling).

[0152] A WTRU group may be dynamic, for example, where WTRUs may be added and removed, for example, depending on the devices and services.

[0153] One or more (e.g., certain) requirements (e.g., performance requirements) and / or connectivity between the WTRUs in a group may be configured, for example, depending on the purpose of the group. The requirements may be configured when the group is formed (e.g., during group formation). For example, PC5-C and / or Uu (e.g., if they are managed by the network) may be used to transmit information (e.g., related to the requirements).

[0154] For example, the WTRUs in a group may have connectivity requirements such that the WTRUs in the group may ensure that they have direct or indirect connectivity with one or more other WTRUs in the group (eg, a specific WTRU in the group).

[0155] For example, the WTRUs in a group may require that the group (e.g., or a portion of the group) be served by the same cell, the same gNB, and / or the same PLMN. This may be useful for devices that support multipath (e.g., Uu and SL) but do not support relaying for WTRUs that are not served by the same cell (e.g., the expected SL multipath relay feature). This may (e.g., also) be a requirement of the network, for example, to facilitate management and / or communication with the WTRUs without inter-gNB or roaming exchanges.

[0156] A WTRU may be a coordinator / master WTRU. For example, depending on the hierarchy between WTRUs, a WTRU may have multiple (eg, two) relationships in a group.

[0157] In some examples, the WTRUs may be viewed as peers in a group where there may be no users managing other users, and / or where collaboration within the group may be about sharing information, requesting assistance, and / or forwarding data or control information to each other.

[0158] In some examples, there may be a master device and slave devices. The master device can act as a management, coordination, and / or control device for the other devices. The master device can centralize decisions and information within the group and / or can be used to offload tasks or programs.

[0159] Figure 9A An example of a WTRU coordinator connected to other WTRUs in the presence of direct inter-WTRU connections is illustrated. Figure 9B An example of a WTRU coordinator connected to other WTRUs without direct inter-WTRU connections is illustrated.

[0160] For example, Figure 9A and Figure 9B As shown in FIG, a WTRU may (e.g., also) function as a coordinator to facilitate collaboration among other WTRUs (e.g., and itself if necessary). A coordinator WTRU may (e.g., also) connect to other devices and / or may centralize information distribution among WTRUs. For example, if / when a coordinator WTRU is present, direct inter-WTRU collaboration links between the coordinating WTRUs may not (e.g., not always) be necessary.

[0161] For example, if / when there is no direct PC5 connection between the coordinating WTRUs, WTRU information shared between the WTRUs in the group may be transmitted through the coordinator WTRU or through Uu (eg, via RRC or higher layer signaling).

[0162] The coordinator WTRU may receive the collaboration information from the WTRU. The coordinator WTRU may transmit the collaboration information to the corresponding destination. For example, the coordinator WTRU may (e.g., also) store the collaboration information and / or share the collaboration information with the user if / when requested. The WTRU may request (e.g., from the coordinator WTRU) information corresponding to (e.g., a specific) WTRU and / or information for the group.

[0163] Collaboration between WTRUs may involve (e.g., require) one or more (e.g., specific) procedures and / or implementation capabilities. One or more (e.g., some) devices may implement (e.g., required) features to become a group coordinator. The features may represent (e.g., specific) WTRU categories and / or WTRU classes.

[0164] In some examples, a device may (eg, only) support a (sub)set of collaboration features.

[0165] WTRU information may be shared for aggregation. Aggregation may be performed among a group of WTRUs. Information may be shared, for example, so that WTRUs associated with the group are aware of each other's capabilities and / or status. The information may be used for group collaboration management and / or to determine which WTRU may (e.g., be best used) to perform collaboration with another WTRU. The sharable (e.g., shared) information may include, for example, one or more of the following: WTRU capabilities; WTRU stored selection information; WTRU energy / battery status; WTRU location; interconnection of the WTRU(s) in the group; WTRU aggregated capabilities; and / or WTRU service type and QoS requirements.

[0166] WTRU capability information may include, for example, one or more of: frequency band support, RAT support, antenna / beam support, measurement capabilities (e.g., information related to how the device can perform measurements on SSB and cell search), etc.

[0167] The selection information stored by the WTRU may indicate what the WTRU has discovered previously and / or may enable faster discovery when performing cell selection based on the stored selection information.

[0168] The WTRU battery / energy status information may indicate whether the device can (eg, needs to) conserve its energy and / or avoid performing one or more tasks.

[0169] WTRU location information may include spatial information (eg, absolute position, relative position, direction, velocity). Spatial information may be useful for determining proximity between devices, redundancy of device measurements, etc.

[0170] The interconnection of WTRU(s) in a group may indicate interconnected WTRUs that may (eg, easily) directly share information and may update each other.

[0171] The WTRU aggregation capabilities may include the ability to support being in a group, the ability to support being a coordinator, and / or the ability to support which features and / or procedures to coordinate, distribute, and / or offload.

[0172] The WTRU service types and QoS requirements may include the service type(s) to be supported in the group for the users and / or the kind(s) of requirements for which the WTRU may (eg, desire) to be assisted for the group.

[0173] Information can be shared between users directly or indirectly (e.g., via a coordinator), for example, using a PC5-C interface between the AS (e.g., at the RRC level) and / or at the NAS level, e.g., depending on the coordination procedure. Information can be exchanged during and / or after PC5 link establishment between devices and / or when exchanging information about the configuration and / or capabilities of the devices. For example, information can be shared between users (e.g., periodically and / or on demand) to update devices in the group.

[0174] The aggregated stored selection information may be used for PLMN / cell selection enhancement.

[0175] Cell selection may be performed using aggregated stored information. Cell selection may be done in multiple (e.g., two) ways, e.g., depending on whether the WTRU has stored selection information. For example, initial cell selection may scan one or more (e.g., all) RF channels and / or frequency bands that the WTRU is capable of scanning, which may be time-consuming and / or energy-consuming. A WTRU (e.g., with stored selection information for a PLMN / SPMN) may use the stored selection information to perform measurements on known cell configurations, which may speed up the process (e.g., if a suitable cell can be found in this way).

[0176] The WTRUs in the group may (e.g., in the case of aggregated cell selection) share their stored selection information (e.g., with at least other WTRUs in the vicinity), such as Figure 10 WTRUs may (eg, if / when the configuration is compatible and appropriate for the receiving device) use cell selection based on stored selection information (eg, instead of initial cell selection) to accelerate their cell selection.

[0177] For example, if a stored selection information based procedure utilizing stored selection information of other WTRUs does not yield (eg, help find) a suitable cell, the WTRU may perform (eg, fall back to) initial cell selection to perform a full search.

[0178] While the example describes aggregation of stored selection information for two devices, aggregation may be extended to multiple aggregated devices sharing their stored selection information, such as an anchor device aggregating multiple values. For example, if the (e.g., first) requested stored selection information does not provide useful stored selection information, multiple aggregated WTRUs may be contacted in parallel (e.g., simultaneously) or sequentially.

[0179] Figure 10 An example of selection information stored for cell selection aggregation is illustrated.

[0180] like Figure 10 As shown in FIG, at 1, a WTRU may be configured and / or enabled to aggregate its stored information for cell selection. The configuration may include conditions and / or parameters for sharing and / or selecting the information to be shared. For example, the parameter may be the validity of the stored information over time, such as a timer between measurement and expiration. The time may be subject to the mobility of the device (e.g., speed). For example, the parameter may be the maximum distance between WTRUs to share their information.

[0181] At 2, the WTRU may perform measurement(s) for cell selection or reselection and update its stored selection information.

[0182] At step 3, the WTRU may request another WTRU to share available stored information. The request may include, for example, one or more of the following: the desired PLMN, RAT, carrier or frequency to share, conditions for the validity of the shared measurements (e.g., time and distance validity of the measurements), etc.

[0183] At 4, the WTRU may (e.g., upon updating its stored information or upon being triggered by a request) transmit its cell selection stored selection information to another WTRU. The stored selection information shared between the WTRUs may be frequency and / or information about cell parameters (e.g., from a previously received measurement control information element). The stored information may (e.g., also) include, for example, the measured WTRU spatial location and / or the time / age of the measurement so that the other WTRU may determine its validity. The stored selection information may (e.g., also) indicate the corresponding PLMN, cell ID, and / or measured RSRP / RSRQ of the cell. The stored selection information may indicate timing indications about the cell, such as absolute or relative timing (e.g., based on beam ID or direction) about the SSB and / or SSB of interest. For example, the WTRU's stored selection information may be useful (e.g., relevant) if / when the WTRUs are in close proximity to each other (such as in PIN, IoT, and / or converged devices).

[0184] In some examples, the received stored selection information may not be valid. For example, if the received stored selection information is not valid, the WTRU may request other WTRUs in the group (e.g., and return to Figure 10 3) in the above.

[0185] At 5, the receiving WTRU may use the received stored selection information to perform a cell selection procedure based on the stored selection information.

[0186] A WTRU (e.g., an aggregation WTRU side, transfers its stored information to another WTRU, such as Figure 10 The WTRU A) in the group may transmit it to other users of the group (e.g., after completing the cell selection (reselection) procedure), for example, using a PC5-C interface between the users' ASs (e.g., at the RRC level). The transmission may be limited to newly discovered cells (e.g., as an incremental update).

[0187] In some examples, the sharing of stored selection information may be triggered by a request. The destination may be a WTRU in a group that has requested sharing of stored selection information for cell selection. The request and / or aggregation configuration may include the type of stored selection information to be shared (e.g., cell frequency, SSB timing, and / or associated PLMN).

[0188] The WTRU may filter the requested information, for example, to select (eg, only) cell information corresponding to the requested PLMN, carrier, and / or RAT from the requesting WTRU.

[0189] In some examples, the destination of the stored selection information may be a WTRU that manages collaboration among the WTRUs in the group.

[0190] In some examples, transmissions may be performed using (e.g., 3GPP) sidelink communications toward other WTRUs (e.g., using (one or more) broadcast, multicast, and / or unicast transmissions). Multicast transmissions may set a distance, for example, up to which the transmission is valid.

[0191] Figure 11 An example of aggregated stored selection information with TX-side verification is illustrated.

[0192] In some examples (e.g., Figure 11 ), a WTRU receiving a stored selection information request may (e.g., first) verify the stored selection information. For example, the stored selection information may be considered expired if the delay or distance since the measurement exceeds a configured threshold and / or if a timer expires. The timing and / or distance thresholds may be configured in the collaboration configuration and / or in the stored information sharing request. The WTRU may perform new measurements on the expired information. The WTRU may update its stored selection information before transmitting it to the requesting WTRU.

[0193] The WTRU may be on the anchor WTRU side, which receives and uses the stored selection information of another WTRU.

[0194] In some examples (e.g., Figure 12 ), the WTRU may be configured in a user group, for example where shared stored selection information may be enabled for cell selection.

[0195] The WTRU may (e.g., if / when a cell selection procedure is performed or initiated) check its stored selection information. The WTRU may (e.g., if no shared information exists) transmit a request to share the stored information to other members of the group and / or to the coordinator WTRU. The request and / or aggregation configuration may include the type of stored selection information to be shared (e.g., cell frequency, SSB timing, and / or associated PLMN) and / or the desired scope of the information (e.g., the RAT, carrier, and / or PLMN selected for cell selection).

[0196] The WTRU may check the validity of the stored selection information (eg, if / when stored selection information is received from a user in the group) and / or may store / update valid stored selection information.

[0197] The validity of the stored selection information may be determined based on, for example, the date and / or time of the measurement (e.g., to account for temporal validity) and / or the location of the measurement (e.g., to avoid considering information from distant / remote locations). The validity criteria and / or parameters may be included in the coordinated configuration exchange. A WTRU receiving the stored selection information may discard the received invalid stored selection information and / or may perform / resume initial cell selection.

[0198] The WTRU may (eg, also) filter and retain (eg, only) relevant stored selection information related to its cell selection, such as supported frequencies, channels, valid cell IDs, and / or PLMNs.

[0199] For example, if (eg, part or all of) the received stored selection information is not valid, the WTRU may request the stored selection information from the other device.

[0200] For example, if the WTRU has (eg, appropriate) stored selection information, the WTRU may perform cell selection based on the stored selection information. Otherwise, the WTRU may perform initial cell selection.

[0201] The WTRU may update the stored selection information (e.g., received from users in the group during the cell selection procedure) and receive compatible (e.g., suitable) stored selection information. The WTRU may continue cell selection with the new (e.g., updated) information.

[0202] The WTRU may select one or more other WTRUs to send a stored information sharing request, for example based on the location of the WTRU(s) (e.g., if the distance between the WTRUs is below (or equal to) a configured threshold) and / or the inter-WTRU connectivity (e.g., (only) selecting the WTRU with the (strongest) inter-WTRU link).

[0203] Figure 12 An example of requesting / using stored selection information for cell selection is illustrated. The stored information may include frequency and / or information about cell parameters (e.g., from a previous measurement control information element). The stored information may include the measured WTRU spatial location and the time / age of the measurement (e.g., so that other WTRUs can determine its validity). The stored information may indicate the corresponding PLMN, cell ID and / or measured RSRP / RSRQ of the cell. The stored information may indicate timing indications about the cell, such as absolute or relative timing about SSBs (e.g., SSBs of interest, such as based on beam ID or direction). The stored information may be shared between WTRUs. The stored information of the WTRUs may be particularly relevant if the WTRUs are in close proximity to each other, such as in a PIN, IoT, or converged device.

[0204] The first WTRU may be configured to perform cell selection (e.g., aggregate cell selection) using stored information, for example. The first WTRU may determine to perform cell selection (or reselection). The first WTRU may determine whether it has stored information (e.g., for faster cell selection), such as Figure 12 If the first WTRU has stored information, it may perform cell selection based on the stored information.

[0205] For example, if the first WTRU does not have the stored information and / or the cell selection attempt of the first WTRU fails, the first WTRU may request the stored information from the second WTRU (e.g., see Figure 12 ).

[0206] As described herein, a request for stored information may include the type of stored information to be shared (e.g., cell frequency, SSB timing, associated PLMN) and / or the desired scope of the information (e.g., RAT, carrier, PLMN selected for cell selection). For example, the request may include conditions and / or parameters for sharing or selecting the information to be shared. The parameter may be the time validity of the stored information (e.g., a timer between measurement and expiration). The time may be subject to the mobility of the device (e.g., speed). The parameter may be the maximum distance between the first WTRU and the second WTRU over which their information is shared.

[0207] In an example, condition(s) may be satisfied before the first WTRU requests the stored information (e.g., the stored information may be requested if the condition(s) are satisfied). The condition(s) may include no stored information and / or a failed cell selection attempt.

[0208] like Figure 12 As shown in , a first WTRU may receive stored information, for example, from a second WTRU.

[0209] The first WTRU may determine that the received stored information is valid. The validity of the received stored information may be based on the delay and / or distance since the measurement associated with the stored information. If the delay and / or distance exceeds a configured threshold (e.g., a timer expires), the stored information may be considered expired and / or invalid. The timing and distance thresholds may be configured in the collaboration configuration and / or in the stored information request.

[0210] The first WTRU may receive an indication of validity condition(s) that may be used to determine whether the stored information is valid (e.g., the stored information may be determined to be valid if the validity condition is satisfied, multiple validity conditions are satisfied, etc.). The validity condition may include one or more of supported frequencies, channels, valid cell IDs, PLMNs, a time associated with the measurement, or a location of the measurement. In an example, the stored information may include the validity condition.

[0211] If the first WTRU determines that the received stored information is valid, the first WTRU may perform cell selection based on the received stored information (e.g., as shown in FIG. Figure 12 ). The WTRU may filter and / or maintain relevant stored information (e.g., supported frequencies, channels, valid cell IDs, PLMNs) for its cell selection, for example, by updating locally stored information. If the stored information based procedure utilizing the stored information of the second WTRU does not result in finding a suitable cell, the first WTRU may perform an initial cell selection (e.g., perform a full search).

[0212] If the first WTRU determines that the received stored information is invalid, the first WTRU may perform initial cell selection (eg, perform a full search).

[0213] In an example, multiple aggregated WTRUs may share their stored information. The multiple aggregated WTRUs may be contacted in parallel (e.g., simultaneously) or sequentially (e.g., if the first request for stored information does not provide useful stored information). If the stored information is invalid, the first WTRU may select another WTRU (e.g., a third WTRU) to send the stored information request. The third WTRU may be selected based on the WTRU's location (e.g., the distance between the first WTRU and the third WTRU is below a configured threshold) and / or inter-WTRU connectivity (e.g., only WTRUs with strong inter-WTRU links are selected).

[0214] Stored information associated with cell (re)selection may be shared between WTRUs. A first WTRU may be configured, for example, to use the stored information to perform cell selection (e.g., aggregated cell selection). The first WTRU may receive a request for the stored information (e.g., a request for faster cell selection from a second WTRU). The request for the stored information may include the type of stored information to be shared (e.g., cell frequency, SSB timing, associated PLMN) and / or the desired scope of the information (e.g., RAT, carrier, PLMN selected for cell selection).

[0215] If the first WTRU has stored information, it may send the stored information.In an example, the first WTRU may be configured to identify the stored information to be shared.

[0216] The first WTRU may determine (e.g., before sending the stored information) whether its stored information is valid. The validity of the received stored information may be based on the delay and / or distance since the measurement associated with the stored information. If the delay and / or distance exceeds a configured threshold (e.g., a timer expires), the stored information may be considered expired and / or invalid. The timing and distance thresholds may be configured in the cooperative configuration and / or in the stored information request from the second WTRU.

[0217] In an example, the request may include an indication of a validity condition that may be used to determine whether the stored information is valid. The validity condition may include one or more of supported frequencies, channels, valid cell IDs, PLMNs, a time associated with the measurement, or a location of the measurement. In an example, the stored information may include the validity condition.

[0218] If the first WTRU determines that the received stored information is valid, the first WTRU may send / report the stored information to the second WTRU.

[0219] If the first WTRU determines that the received stored information is invalid, the first WTRU may not send / report the stored information to the second WTRU.

[0220] If the first WTRU determines that its stored information is expired, the first WTRU may perform new measurements on expired cells that are outdated in the stored information and / or update its stored information before transmitting it to the second WTRU.

[0221] A WTRU (e.g., having stored selection information) may (e.g., first) attempt to perform cell selection based on the stored selection information. For example, if the WTRU fails to find a suitable cell to camp on, the WTRU may request stored selection information of other WTRUs.

[0222] Figure 13 An example is shown in which the coordinator aggregates stored selection information for cell selection.

[0223] The coordinator may use the aggregated stored selection information to perform cell selection. The coordinator WTRU may aggregate the stored selection information received from other WTRUs. The coordinator WTRU may send (e.g., return) the aggregated information to the members of the group. For example, Figure 13 As shown in , a centralized approach may allow for better efficiency in information sharing among WTRUs.

[0224] As Figure 13 As shown in the example of FIG, at 1, the WTRU may be configured and / or enabled to aggregate its stored selection information with the coordinator for cell selection. Configuration related to the coordinator and / or messages may (eg, also) be exchanged.

[0225] At 2, the WTRU may perform measurements for cell selection or reselection and / or update its stored selection information.

[0226] At step 3, the WTRU may transmit its stored selection information for cell selection to the coordinator (e.g., after updating its stored selection information and / or based on being triggered by the coordinator). The coordinator WTRU may send requests to other WTRUs to perform selected measurements, for example, to maintain an updated list of stored selection information. The selection of cells and / or WTRUs to perform measurements may be based on the WTRU location and / or the expiration of the stored (e.g., known) selection information.

[0227] At 4, the coordinator may receive and / or may aggregate stored selection information from other WTRUs in the group. For example, the coordinator WTRU may receive stored selection information about cells that may be considered suitable, while previously stored selection information (e.g., which may or may not be suitable) may have been measured by another WTRU. This aggregation (e.g., by the coordinator WTRU) may update the stored selection information with the most recent value and / or with the most optimistic value. The coordinator WTRU may (e.g., also) track the value and / or may associate the value with the time and / or location of the measurement.

[0228] The WTRU may request the coordinator WTRU to provide the stored information at 5. The request and / or aggregation configuration may include the type(s) of stored selection information to be shared (e.g., cell frequency, SSB timing, associated PLMN, and / or validity).

[0229] At 6, the coordinator WTRU may select the stored selection information that best matches the user, for example based on the requested information, proximity, and / or timing.

[0230] At 7, the coordinator WTRU may report the selected stored selection information to the requesting WTRU.

[0231] At 8, the receiving WTRU may use the received stored selection information to perform a cell selection procedure based on the stored selection information.

[0232] PLMN selection may be performed using the aggregated stored selection information. The WTRU may optimize the PLMN search, for example, by using the stored selection information (e.g., frequency and / or information about cell parameters from previously received measurement control information elements), which may speed up the search for PLMNs across different carriers.

[0233] The WTRUs in the group may share their stored selection information (e.g., in the case of collaborative PLMN selection), e.g., with at least other WTRUs in the vicinity. Receiving devices may (e.g., if the configuration is compatible and appropriate for the receiving device) use the stored selection information to speed up their PLMN search selection, e.g., instead of scanning one or more (e.g., all) RF channels of the supported frequency bands.

[0234] The stored selection information shared between WTRUs may include frequency, information on cell parameters from previously received measurement control information elements, the WTRU spatial location of the measurement, and / or the time / age of the measurement.

[0235] While the following example describes aggregation of stored selection information of two devices, the example may be extended to multiple aggregated devices sharing their stored selection information, e.g., where the anchor device may aggregate multiple values. Multiple aggregated WTRUs may be contacted in parallel (e.g., simultaneously) and / or sequentially (e.g., in the event that the (first) requested stored selection information does not provide useful stored selection information).

[0236] Figure 14 An example of PLMN selection using aggregated stored selection information is illustrated.

[0237] like Figure 14 As shown in FIG, at 1, a WTRU may be configured and / or enabled to aggregate its stored selection information for PLMN selection. The configuration may include conditions and / or parameters for sharing and / or selecting the information to be shared. For example, the parameter may be the validity of the stored selection information over time, such as a timer between measurement and expiration. The time may be subject to the mobility of the device (e.g., speed). For example, the parameter may be the maximum distance between WTRUs at which their information is shared.

[0238] At 2, the WTRU may perform measurements on PLMN selection and / or update its stored selection information for PLMN selection.

[0239] At step 3, the WTRU may request another WTRU to share its available stored selection information for PLMN selection. The request may include, for example, the desired RAT, carrier, and / or frequency to be shared, and / or conditions for the validity of the shared measurements (e.g., time validity and / or distance validity of the measurements).

[0240] At 4, the WTRU may (e.g., upon updating its stored selection information or triggered by a request) transmit its cell selection stored selection information to another WTRU. The stored selection information shared between WTRUs may include, for example, frequency, information about cell parameters from a previously received measurement control information element, the measured WTRU spatial location, and / or the time / age of the measurement (e.g., so that the other WTRU can determine the validity of the measurement). The stored selection information may (e.g., also) indicate the corresponding PLMN, cell ID, and / or measured RSRP / RSRQ. The stored selection information may indicate timing indications about the cell, such as absolute or relative timing (e.g., based on beam ID or direction) about the SSB and / or SSB of interest. For example, the WTRU's stored selection information may be relevant if / when the WTRUs are in close proximity to each other (such as in PIN, IoT, and / or converged devices).

[0241] For example, if the received stored selection information is invalid, the WTRU may request the stored selection information from other WTRUs in the group (e.g., and return to Figure 14 3) in the above.

[0242] At 5, the receiving WTRU may use the received stored selection information to perform a PLMN selection procedure based on the stored information. (For example, when sending a PLMN selection request to another WTRU such as Figure 14 The WTRU A in the group (on the WTRU side) that transmits its stored information may update its stored selection information (e.g., after its PLMN selection procedure or cell selection) and / or transmit the (e.g., current / valid) stored selection information to other users of the group, for example, using the PC5-C interface between the users' ASs (e.g., at the RRC level).

[0243] In some examples, the sharing of stored selection information may be triggered by a request. The stored information may be destined for a WTRU of a group requesting to share the stored selection information for PLMN selection. The results may be filtered (e.g., by the WTRU providing the stored selection information) to match configured or compatible carriers and PLMNs.

[0244] The WTRU (eg, providing stored selection information) may filter the requested information, for example, to select (eg, only) cell information corresponding to the requested PLMN, carrier, and / or RAT from the requesting WTRU.

[0245] In some examples, the destination of the stored selection information may be a WTRU that manages the collaboration among the group of WTRUs.

[0246] In some examples, transmissions may be performed using (e.g., 3GPP) sidelink communications toward other WTRUs (e.g., using (one or more) broadcast, multicast, and / or unicast transmissions). Multicast transmissions may set a distance, for example, up to which the transmission is valid.

[0247] Figure 15 An example of PLMN selection with aggregated stored selection information and Tx-side verification is illustrated.

[0248] In some examples (e.g., Figure 15 ), the WTRU may receive a stored information sharing request. The WTRU may (e.g., first) verify the stored selection information. For example, the stored selection information may be considered expired if the delay and / or distance since the measurement exceeds a configured threshold (e.g., or a timer expires). For example, the timing and distance thresholds may be configured in the collaboration configuration and / or in the stored information sharing request. The WTRU may perform new measurements on the expired information. The WTRU may update its stored selection information (e.g., with new measurements) before transmitting it to the requesting WTRU.

[0249] Figure 16 An example of PLMN selection with aggregated stored selection information on the receiver side is illustrated.

[0250] The WTRU may be an anchor WTRU that receives and / or uses stored selection information of another WTRU. Figure 16 ), WTRUs may be configured in user groups where shared stored selection information may be implemented for PLMN selection.

[0251] The WTRU may (e.g., if / when a PLMN selection procedure is performed or initiated) check its stored selection information. The WTRU may (e.g., if the stored selection information is not present) transmit a request to share the stored information to one or more other members of the group and / or to the coordinator WTRU. The request or aggregation configuration may include the type(s) of stored selection information to be shared (e.g., frequency, SSB timing, and / or associated PLMNs) and / or the desired scope of the information (e.g., the selected RAT, carrier, and / or PLMN for PLMN selection).

[0252] The WTRU may check the validity of the stored selection information (eg, if / when stored selection information is received from a user in the group). The WTRU may (eg, only) store / update valid stored selection information.

[0253] A stored information sharing request may be any messaging suitable for a request for information. For example, a stored information sharing request may include information indicating the type and / or nature of the requested information. A stored information sharing request may include any data selection mechanism suitable for indicating the type and / or nature of the requested information. For example, a stored sharing request may include a data selection mechanism such as one or more data tags, queries, filters, human-readable selection logic, computer-readable selection logic, one or more scopes (e.g., time scope, geographic scope, etc.), and the like. A stored information sharing request may include a general request related to sharable information. For example, a stored information sharing request may include a specific request related to a specific need for sharable information, such as cell and / or PLMN selection. A stored information sharing request may be transmitted in a separate message. A stored information sharing request may be transmitted as part of a larger message.

[0254] The WTRU may update the stored selection information with the received valid stored selection information. The WTRU may, for example, resume PLMN selection using the stored selection information (eg, to accelerate search).

[0255] The validity of the stored selection information may be determined based on the measurement date (e.g., to account for temporal validity) and / or the measurement location (e.g., to avoid considering information from distant / remote locations). The validity criteria and parameters may be included in the coordinated configuration exchange. A WTRU receiving the stored selection information may discard the received stored selection information that is determined to be invalid and / or may perform / resume initial cell selection.

[0256] The WTRU may filter the stored selection information. The WTRU may retain (eg, only) relevant stored selection information related to its cell selection, such as supported frequencies, channels, valid cell IDs, and / or PLMNs.

[0257] In some examples, the WTRU may receive stored selection information from users in the group during the PLMN selection procedure. The WTRU may update the stored selection information with the received appropriate and / or compatible stored selection information. The WTRU may continue PLMN selection with the new information.

[0258] In some examples, a WTRU (e.g., having stored selection information) may (e.g., first) attempt to perform PLMN selection based on the stored selection information. For example, if the WTRU fails to find the desired PLMN, the WTRU may request stored selection information of other WTRUs.

[0259] For example, the WTRU may select a WTRU to which to send the stored information sharing request based on the WTRU's location (eg, if the distance between the WTRUs is below a configured threshold) and / or inter-WTRU connectivity.

[0260] Figure 17 An example of PLMN selection is illustrated where the coordinator WTRU has aggregated stored selection information.

[0261] The coordinator WTRU may aggregate stored selection information for PLMN selection received from one or more other WTRUs. The coordinator WTRU may send (e.g., return) the aggregated information to the members of the group. For example, Figure 17 As shown in , a more centralized approach (eg, using a coordinator WTRU) may allow for better efficiency in information sharing among WTRUs.

[0262] PLMN selection may use aggregated stored selection information with the coordinator.

[0263] like Figure 17 As shown in , at 1 , the WTRU may be configured and / or enabled to aggregate its stored selection information with the coordinator for PLMN selection. Configurations related to the coordinator and messaging may (eg, also) be exchanged.

[0264] The WTRU may perform measurements for PLMN selection (or reselection) at 2. The WTRU may update its stored selection information.

[0265] At 3, the WTRU may transmit the stored selection information of its PLMN selection to the coordinator (eg, after updating its stored selection information or triggered by the coordinator).

[0266] The coordinator WTRU may send requests to other WTRUs to perform selected measurements, for example to maintain an updated list of stored selection information. The selection of PLMNs, RATs, carriers and / or WTRUs to perform measurements may be based on the WTRU location and / or the expiration of known stored selection information.

[0267] At 4, the coordinator WTRU may receive and / or may aggregate stored selection information from other WTRUs in the group. Aggregation (e.g., by the coordinator WTRU) may update its stored selection information with the most recent value and / or may combine reports, for example, to add a list of (e.g., possible) PLMNs. The coordinator WTRU may (e.g., also) track measurements and / or may associate them with the time and / or location of the measurements.

[0268] The WTRU may request the coordinator WTRU to provide the stored information at 5. The request and / or aggregation configuration may include the type(s) of stored selection information to be shared (eg, cell frequency, SSB timing, and / or validity).

[0269] At 6, the coordinator WTRU may select the stored selection information that best matches the user, for example based on the requested information, proximity, and / or timing.

[0270] At 7, the coordinator reports the selected stored selection information to the requesting WTRU.

[0271] At 8, the receiving WTRU may use the received stored selection information to perform a PLMN selection procedure based on the stored selection information.

[0272] An example of aggregated stored selection information for cell selection is provided.

[0273] In some examples (e.g., Figure 12 ), the WTRU may be configured in a user group where shared stored selection information (e.g., cell frequency, SSB timing indication, and / or SSB index) for cell selection may be enabled.

[0274] For example, if / when a cell selection procedure is performed or initiated, the WTRU may check its stored selection information. For example, if the WTRU has stored selection information, the WTRU may perform cell selection based on the stored selection information. For example, if the WTRU fails to find a suitable cell (e.g., during cell selection based on stored selection information), or if the stored selection information does not exist, the WTRU may transmit a stored information sharing request (e.g., which includes the desired PLMN, RAT, and / or carrier supported by the WTRU).

[0275] The request may be sent to a coordinator WTRU that centralizes the stored selection information for the group, and / or to selected WTRUs based on their WTRU information (eg, distance, capabilities, connectivity), for example.

[0276] The WTRU may check the validity of the stored selection information (e.g., check whether the expiration date and / or the distance between the WTRUs is below a configured threshold) (e.g., if / when the stored selection information is received from another WTRU). The WTRU may store / update the valid stored selection information.

[0277] For example, if the WTRU has valid stored selection information, the WTRU may perform cell selection based on the stored selection information. Otherwise (eg, in the case where the stored selection information is invalid), the WTRU may perform initial cell selection.

[0278] In some examples (e.g., Figure 11 ), a WTRU may be configured to share its stored selection information with another WTRU for cell selection. The configuration may include a time validity and / or a distance validity over which the stored selection information may be shared. The WTRU may receive a request to share stored information, for example, for one or more RATs, carriers, and / or PLMNs. The WTRU may verify the validity of the stored selection information for the request. The WTRU may perform measurements on outdated cells. The WTRU may update its stored selection information (e.g., based on new measurements). The WTRU may transmit a report to the requesting WTRU. The WTRU may (e.g., before transmitting the report) filter carriers, RATs, and / or PLMNs, for example, based on configuration information to be shared, information supported and / or desired by the requesting WTRU.

[0279] In some examples (e.g., Figure 13 ), a coordinator WTRU may be configured to aggregate stored selection information for cell selection from WTRUs in the group, which may include timing and / or spatial validity of the stored selection information. The coordinator WTRU may request other WTRUs to perform measurements on one or more (e.g., specific) cells, for example, to validate and / or update the aggregated stored selection information, for example, based on their previous reporting, time, and / or location. The coordinator WTRU may receive stored selection information from the WTRUs for cell selection. The coordinator WTRU may aggregate the stored selection information. For example, a first WTRU may report that a given cell is suitable, while previously stored selection information may have been measured and / or indicated as unsuitable by a second WTRU. The aggregation (e.g., by the coordinator WTRU) may update the stored selection information with the most recent value and / or with the most optimistic value. The aggregation (e.g., by the coordinator WTRU) may update or remove information, for example, based on a validity configuration. The coordinator WTRU may track multiple values ​​and / or may associate these values ​​with the time and / or location of the measurements. The coordinator WTRU may receive requests from one or more WTRUs to send the aggregated stored selection information. The coordinator WTRU may (e.g., if / when the coordinator WTRU transmits the stored selection information to the WTRU) select the stored selection information that best matches the user, for example, based on proximity and / or timing. The coordinator WTRU may filter the results of carriers, RATs, and / or PLMNs, for example, based on configuration information to be shared, supported, and / or desired by the requesting WTRU.

[0280] An example of aggregated stored selection information for PLMN selection is provided.

[0281] In some examples (e.g., Figure 14 ), the WTRU may be configured in a user group where shared stored selection information may be enabled for PLMN selection.

[0282] For example, if / when a PLMN selection procedure is performed or initiated, the WTRU may check its stored selection information. For example, if the WTRU has stored selection information, the WTRU may perform PLMN selection based on the stored selection information. For example, if the WTRU fails to select a suitable PLMN (e.g., during PLMN selection based on stored selection information) or if the stored selection information does not exist, the WTRU may transmit a stored information sharing request, which may include the desired PLMN, RAT, and / or carrier supported by the WTRU.

[0283] The request may be sent to a coordinator WTRU that centralizes the stored selection information for the group, and / or to selected WTRUs based on their WTRU information (eg, distance, capabilities, and / or connectivity), for example.

[0284] The WTRU may check the validity of the stored selection information (e.g., by checking whether the expiration date and / or the distance between the WTRUs is below a configured threshold) (e.g., if / when the stored selection information is received from another WTRU). The WTRU may store / update the valid stored selection information.

[0285] A WTRU that receives the stored selection information may perform a PLMN selection based on the stored selection information, for example, if the WTRU has valid stored selection information. Otherwise, the WTRU may perform a full PLMN selection.

[0286] In some examples (e.g., Figure 15 ), a WTRU may be configured to share its stored selection information with another WTRU for PLMN selection. The configuration may include a time validity and / or a distance validity over which the stored selection information may be shared. The WTRU may receive a request to share stored information for one or more (e.g., some) RATs, carriers, and / or PLMNs. The WTRU may verify the validity of the stored selection information for the request. The WTRU may perform measurements on outdated cells. The WTRU may update its stored selection information, for example, based on the new measurement(s). The WTRU may transmit a report to the requesting WTRU. The WTRU may (e.g., before transmitting the report) filter carriers, RATs, and / or PLMNs, for example, based on configuration information to be shared, information supported and / or desired by the requesting WTRU.

[0287] In some examples (e.g., Figure 17), a coordinator WTRU may be configured to aggregate stored selection information for PLMN selection from WTRUs in the group, which may include timing validity and / or spatial validity of the stored selection information. The coordinator WTRU may request other WTRUs to perform measurements on one or more (e.g., specific) PLMNs, RATs, and / or carriers, for example, to validate and / or update the aggregated stored selection information, for example, based on their previous reporting, time, and / or location. The coordinator WTRU may receive stored selection information from WTRUs for PLMN selection. The coordinator WTRU may aggregate the stored selection information. For example, a first WTRU may report that a PLMN is present in a carrier with high quality, while a previous record may not indicate presence or may indicate presence but does not meet high quality criteria. The coordinator WTRU may update its stored selection information with the most recent value and / or with the most optimistic value. The coordinator WTRU may update or remove information, for example, based on a validity configuration. The coordinator WTRU may track multiple values ​​and / or may associate these values ​​with the time and / or location of (one or more) measurements. The coordinator WTRU may receive requests from one or more WTRUs to send aggregated stored selection information. The coordinator WTRU may (e.g., if / when transmitting the stored selection information to the WTRU) select the stored selection information that best matches the user, for example, based on proximity and / or timing. The coordinator WTRU may filter the results by carrier, RAT, and / or PLMN, for example, based on the configuration information to be shared, supported, and / or desired by the requesting WTRU.

[0288] Although the above features and elements are described in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without the other features and elements.

[0289] Although the implementation described herein may consider 3GPP specific protocols, it should be understood that the implementation described herein is not limited to this scenario and may be applicable to other wireless systems. For example, although the solution described herein considers LTE, LTE-A, New Radio (NR), or 5G specific protocols, it should be understood that the solution described herein is not limited to this scenario and may be applicable to other wireless systems.

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

Claims

1. A first wireless transmit / receive unit (WTRU), comprising: A processor configured to: Make sure the conditions have been met; sending a request to a second WTRU, wherein the request is for stored information associated with cell selection; receiving stored information, wherein the stored information includes a parameter associated with a location of the second WTRU or a measurement time associated with the stored information; determining whether the stored information is valid based on whether the parameter satisfies a threshold; and A cell is selected based on whether the stored information is valid, wherein the selecting of the cell includes performing an initial cell selection or performing cell selection (reselection) using the stored information.

2. The first WTRU of claim 1 , wherein the condition comprises a failed cell selection attempt.

3. The first WTRU of claim 1 , wherein the condition comprises the first WTRU not having locally stored information associated with (re)selection of a cell.

4. The first WTRU of claim 1 , wherein when the stored information is valid, selecting the cell comprises performing (re)selection of the cell using the stored information.

5. The first WTRU of claim 1 , wherein when the stored information is invalid, selecting a cell comprises performing an initial cell selection.

6. The first WTRU of claim 1 , wherein the stored information comprises at least one of a cell ID, a cell frequency, a synchronization signal block (SSB), or synchronization timing.

7. The first WTRU of claim 1 , wherein the threshold is a distance threshold from the first WTRU to the second WTRU.

8. The first WTRU of claim 1 , wherein the threshold is a delay threshold from a measurement time.

9. The first WTRU of claim 1 , wherein the processor is further configured to: receiving an indication of at least one validity condition, wherein determining whether the stored information is valid is further based on the at least one validity condition, and wherein the at least one validity condition comprises: Supported frequencies, channels, valid cell IDs, PLMNs, times associated with the measurements, or locations of measurements.

10. The first WTRU of claim 1 , wherein the processor is further configured to: Based on a determination that the stored information is valid, locally stored information associated with (re)selection of a cell is updated using the stored information.

11. A method implemented by a first WTRU, comprising: Make sure the conditions have been met; sending a request to a second WTRU, wherein the request is for stored information associated with cell selection; receiving stored information, wherein the stored information includes a parameter associated with a location of a second WTRU or a measurement time associated with the information; determining whether the stored information is valid based on whether the parameter satisfies a threshold; and A cell is selected based on whether the stored information is valid, wherein selecting the cell includes performing an initial cell selection or performing cell selection (reselection) using the stored information.

12. The method of claim 11, wherein the condition comprises based on a failed cell selection attempt.

13. The method of claim 11, wherein the condition comprises the first WTRU not having locally stored information associated with (re)selection of a cell.

14. The method of claim 11, wherein the threshold is a delay threshold from a measurement time being met, or a distance threshold being met from the first WTRU to the second WTRU.

15. The method of claim 11, wherein based on determining that the stored information is valid, selecting a cell comprises performing (re)selection of a cell based on the stored information.

Images