How to obtain system information between NR relay and multipath WTRU-NW relay

Abstract

The system and method includes a relay WTRU that determines whether to forward SI to a remote WTRU following a request by the remote WTRU based on coverage / capabilities indicated by the remote WTRU and an RRC state of the relay WTRU. The system and method includes the remote WTRU determining whether to request / receive SI from the network or the relay based on UU quality, SI request configuration (MSG1 or MSG3 based), and an indication from the relay following the SI request. The system and method includes a relay that may indicate to the network whether the SIB may be provided by dedicated signaling or broadcast following receipt of a new SIB.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 308,355, filed February 9, 2022, No. 63 / 326,632, filed April 1, 2022, and No. 63 / 421,894, filed November 2, 2022, the contents of which are incorporated by reference herein as if fully set forth. Summary of the Invention [Problem to be solved by the invention]

[0002] Sidelink Relay may be regarded as an evolution of D2D (Device-to-Device) technology developed in LTE (Long Term Evolution), and has a wide range of application scenarios. In order to access Sidelink Relay and other evolved technologies of NR Relay, it is necessary to provide a method and system for acquiring system information between a multipath WTRU (Wireless Transmitter / Receiver Unit) and a NW relay.

[0003] The system and method includes a relay WTRU determining whether to forward SI to a remote WTRU following a request by the remote WTRU based on coverage / capabilities indicated by the remote WTRU and an RRC state of the relay WTRU. The relay WTRU receives capability information from the remote WTRU in a PC5-RRC capability exchange related to whether the remote WTRU supports multiple paths, receives an SI request from the remote WTRU including a coverage indication (IC / OOC), requests the corresponding SI from the network, and if the requesting remote WTRU supports multiple paths and indicates IC in the request, and the relay WTRU is RRC_IDLE / RRC_INACTIVE, the relay WTRU sends an indication to the remote WTRU that it may obtain the requested SI directly over Uu upon receiving an indication that an SI request has been sent; otherwise (legacy remote WTRU, OOC remote WTRU, or relay WTRU in RRC_CONNECTED), the relay WTRU obtains the requested SI and sends it to the remote WTRU (via PC5-RRC).

[0004] The system and method includes a remote WTRU determining whether to request / receive SI from the network or the relay based on Uu quality, SI request configuration (MSG1 or MSG3 based), and an instruction from the relay to follow the SI request. A remote WTRU configured with multiple paths receives a Uu quality threshold for sending an SI request directly over Uu, receives a Uu quality threshold for receiving SI over Uu, receives an SI request configuration from SIB1 indicating an MSG1-based or MSG3-based SI request, sends an SI request over Uu if the Uu quality is above the threshold for sending an SI request and the WTRU is configured for an MSG1-based SI request, receives the requested SI over Uu, calculates an IC / OOC indication based on whether the measured Uu quality is above / below the SI reception threshold, sends an SI request including the calculated IC / OOC indication to the relay WTRU, receives the requested SI over Uu if the relay WTRU instructs to receive SI over Uu, and otherwise receives the requested SI over the relay WTRU.

[0005] The system and method includes a relay that may indicate to the network whether the SIB may be provided by dedicated signaling or broadcast following reception of a new SIB. The relay WTRU receives a PC5-RRC message from a remote WTRU enabling / disabling SI transfer over the SL, and receives an SI request from the remote WTRU when the relay WTRU receives an SI update notification for a new SIB or updated SI required by at least one remote WTRU. For a relay WTRU in RRC_CONNECTED, it sends a dedicatedSIBRequest indicating that the SIB may be broadcast if the relay is configured on BWP without CSS and at least one relay WTRU has SIB transfer disabled over the SL, otherwise it sends a legacy dedicatedSIBRequest. For a relay WTRU in RRC_IDLE / RRC_INACTIVE, it sends an SI request to the network and forwards the SI to the remote WTRU if at least one relay WTRU has SIB transfer enabled over the SL.

[0006] A system and method are disclosed for a WTRU to receive information, the information including a direct path quality threshold for sending a System Information (SI) request via a direct path, a direct path quality threshold for receiving SI via the direct path, and an SI request configuration indicating a configuration of the SI request, measure a quality of the direct path, and determine an indication based on whether the measured direct path quality is greater than or equal to the direct path quality threshold for receiving SI via the direct path based on the measured direct path quality being less than the direct path quality threshold for sending the SI request via the direct path and the SI request configuration indicating an MSG3-based SI request, send the SI request via a relay WTRU, the SI request including the indication, and receive SI via the relay WTRU or via the direct path in response to the indication from the relay WTRU.

[0007] A system and method are disclosed for a WTRU to receive information including a direct path quality threshold for sending a system information (SI) request via a direct path, a direct path quality threshold for receiving SI via the direct path, and an SI request configuration indicating a configuration of the SI request, measure a quality of the direct path, and based on the measured direct path quality being above the direct path quality threshold for sending the SI request via the direct path or the SI request configuration indicating a MSG1-based SI request, send an SI request via the direct path, and receive the requested SI via the direct path. [Brief description of the drawings]

[0008] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numbers indicate similar elements and in which: [Figure 1A] FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] FIG. 1B is a system diagram illustrating an example Wireless Transmit / Receive Unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1C is a system diagram illustrating an example Radio Access Network (RAN) and an example Core Network (CN) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] FIG. 2 shows the user plane radio protocol stack for Layer 2 evolved WTRU-to-network relay (PC5). [Diagram 3] FIG. 3 shows the control plane radio protocol stack for Layer 2 evolved WTRU-to-network relay (PC5). [Figure 4] FIG. 4 is a diagram illustrating a methodology associated with receiving an instruction from a remote WTRU to enable or disable SI transfer. [Diagram 5] FIG. 5 illustrates a methodology associated with an IC remote WTRU and a relay WTRU that request SI providing SI. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The system and method includes a relay WTRU determining whether to forward SI to a remote WTRU following a request by the remote WTRU based on coverage / capabilities indicated by the remote WTRU and an RRC state of the relay WTRU. The relay WTRU receives capability information from the remote WTRU in a PC5-RRC capability exchange related to whether the remote WTRU supports multiple paths, receives an SI request from the remote WTRU including a coverage indication (IC / OOC), requests the corresponding SI from the network, and if the requesting remote WTRU supports multiple paths and indicates IC in the request, and the relay WTRU is RRC_IDLE / RRC_INACTIVE, the relay WTRU sends an indication to the remote WTRU that it may obtain the requested SI directly over Uu upon receiving an indication that an SI request has been sent; otherwise (legacy remote WTRU, OOC remote WTRU, or relay WTRU in RRC_CONNECTED), the relay WTRU obtains the requested SI and sends it to the remote WTRU (via PC5-RRC).

[0010] The system and method includes a remote WTRU determining whether to request / receive SI from the network or the relay based on Uu quality, SI request configuration (MSG1 or MSG3 based), and an instruction from the relay to follow the SI request. A remote WTRU configured with multiple paths receives a Uu quality threshold for sending an SI request directly over Uu, receives a Uu quality threshold for receiving SI over Uu, receives an SI request configuration from SIB1 indicating an MSG1-based or MSG3-based SI request, sends an SI request over Uu if the Uu quality is above the threshold for sending an SI request and the WTRU is configured for an MSG1-based SI request, receives the requested SI over Uu, calculates an IC / OOC indication based on whether the measured Uu quality is above / below the SI reception threshold, sends an SI request including the calculated IC / OOC indication to the relay WTRU, receives the requested SI over Uu if the relay WTRU instructs to receive SI over Uu, and otherwise receives the requested SI over the relay WTRU.

[0011] The system and method includes a relay that may indicate to the network whether the SIB may be provided by dedicated signaling or broadcast following reception of a new SIB. The relay WTRU receives a PC5-RRC message from a remote WTRU enabling / disabling SI transfer over the SL, and receives an SI request from the remote WTRU when the relay WTRU receives an SI update notification for a new SIB or updated SI required by at least one remote WTRU. For a relay WTRU in RRC_CONNECTED, it sends a dedicatedSIBRequest indicating that the SIB may be broadcast if the relay is configured on BWP without CSS and at least one relay WTRU has SIB transfer disabled over the SL, otherwise it sends a legacy dedicatedSIBRequest. For a relay WTRU in RRC_IDLE / RRC_INACTIVE, it sends an SI request to the network and forwards the SI to the remote WTRU if at least one relay WTRU has SIB transfer enabled over the SL.

[0012] A system and method are disclosed for a WTRU to receive information, the information including a direct path quality threshold for sending a system information (SI) request via a direct path, a direct path quality threshold for receiving SI via the direct path, and an SI request configuration indicating a configuration of the SI request, measure a quality of the direct path, and determine an indication based on whether the measured direct path quality is greater than or equal to the direct path quality threshold for receiving SI via the direct path based on the measured direct path quality being less than the direct path quality threshold for sending the SI request via the direct path and the SI request configuration indicating an MSG3-based SI request, send the SI request via a relay WTRU, the SI request including the indication, and receive SI via the relay WTRU or via the direct path in response to the indication from the relay WTRU.

[0013] A system and method are disclosed for a WTRU to receive information including a direct path quality threshold for sending a system information (SI) request via a direct path, a direct path quality threshold for receiving SI via the direct path, and an SI request configuration indicating a configuration of the SI request, measure a quality of the direct path, and based on the measured direct path quality being above the direct path quality threshold for sending the SI request via the direct path or the SI request configuration indicating a MSG1-based SI request, send an SI request via the direct path, and receive the requested SI via the direct path.

[0014] 1A 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, broadcasts, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA), Zero-Tail Unique-Word Discrete Fourier Transform Spread OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0015] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a Radio Access Network (RAN) 104, a Core Network (CN) 106, a Public Switched Telephone Network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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 (STA), may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), mobile stations, landline or mobile subscriber units, subscription-based units, pagers, mobile phones, Personal Digital Assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, Head-Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), home electronic devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0016] 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, the Internet 110, and / or other networks 112. By way of example, the base station 114a, 114b may be a base transceiver station (BTS), a Node B, an eNodeB (eNB), a Home Node B, a Home eNodeB, a next generation Node B such as a gNodeB (gNB), a new radio (NR) Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each illustrated 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.

[0017] The base station 114a may be part of the RAN 104, 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. The base station 114a and / or the 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ Multiple-Input Multiple Output (MIMO) technology and may use multiple transceivers for each sector of the cell, and may use beamforming, for example, to transmit and / or receive signals in a desired spatial direction.

[0018] 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).

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

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

[0021] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c implement a radio technology such as NR radio access, which may use NR to establish the air interface 116.

[0022] 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 jointly implement LTE and NR radio access, e.g., using a Dual Connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to and from multiple types of base stations (e.g., eNBs and gNBs).

[0023] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may employ a wireless 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), or the like.

[0024] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as an office, a home, a vehicle, a canal, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. 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 establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

[0025] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various Quality of Service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] The CN 106 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 providing 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) of 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 use the same RAT as the RAN 104 or a different RAT.

[0027] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114b, which may employ an IEEE 802 wireless technology.

[0028] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 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 source 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0029] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), any other type of Integrated Circuit (IC), a state machine, etc. 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 a transceiver 120, which may be coupled to a transmit / receive element 122. Although FIG. 1B illustrates the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated in an electronic package or chip.

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

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

[0032] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned 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, for example, NR and IEEE 802.11.

[0033] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered 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. It should be noted that 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 a Random-Access Memory (RAM), a Read-Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, etc. 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 on a server or home computer (not shown).

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

[0035] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) 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 way of any suitable location determination method while remaining consistent with an embodiment.

[0036] The processor 118 may further be 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 videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a Frequency Modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality / Augmented Reality (VR / AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors. The sensor may be one or more of 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, a humidity sensor, and the like.

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

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

[0039] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 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 eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using, for example, multiple antennas.

[0040] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG 1C, the eNodeBs 160a, 160b, 160c may communicate with each other via an X2 interface.

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

[0042] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0043] The SGW 164 may be connected to each of the eNodeBs 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-eNodeB handovers, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0044] The SGW 164 may be connected to a 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.

[0045] 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 communicate 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. Note that 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.

[0046] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

[0047] In an exemplary embodiment, the other network 112 may be a WLAN.

[0048] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or outside the BSS. Traffic originating from outside the BSS to the STAs may arrive through the AP and be distributed to the STAs. Traffic originating from the STAs to destinations outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs in the BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, which may distribute the traffic to the destination STA. Traffic between STAs in the BSS may be viewed and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using a Direct Link Setup (DLS). In one representative embodiment, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

[0049] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically configured width. The primary channel may be the operating channel of the BSS, but may also be used by STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. In the case of CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0050] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0051] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining multiple contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The data may be transmitted by the transmitting STA, although the streams may be mapped to two 80 MHz channels. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to the Medium Access Control (MAC).

[0052] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. The channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those 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, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support MTC, such as Meter Type Control / Machine-Type Communications (MTC) devices in macro coverage areas. MTC devices may have limited capabilities, including certain capabilities, such as support for (e.g., only for) certain and / or limited bandwidths. The MTC device may include a battery that has a battery life above a threshold (eg, to maintain a very long battery life).

[0053] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, 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 Allocation Vector (NAV) configuration may depend on the status of the primary channel. For example, a STA (that only supports a 1 MHz mode of operation) transmitting to an AP may consider all of the available frequency bands to be busy when the primary channel is busy, even if most of the available frequency bands are idle.

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

[0055] 1D is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

[0057] 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 vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time duration).

[0058] 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 accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may establish a DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, while the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0059] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

[0061] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different Protocol Data Unit (PDU) sessions having different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of Non-Access Stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 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 MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 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.

[0062] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and assigning WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0063] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 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 UPFs 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 DL packets, providing mobility anchoring, etc.

[0064] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate 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. Note that 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. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0065] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-102d, base stations 114a-114b, eNodeBs 160a-160c, MME 162, SGW 164, PGW 166, gNBs 180a-180c, AMFs 182a-182b, UPFs 184a-184b, SMFs 183a-183b, DNs 185a-185b, and / or any other devices 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 functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0066] The emulation device may be designed to perform one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all of the functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all of the functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for the purpose of testing and / or performing tests using over-the-air wireless communication.

[0067] One or more emulation devices may perform one or more functions, including but not limited to, while not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. One or more of the emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0068] The NR sidelink may use both WTRU-network relay and WTRU-WTRU relay based on PC5 (sidelink). The NR sidelink is generally focused on supporting V2X-related road safety services. The design aims to provide support for broadcast, groupcast, and unicast communications in both out-of-coverage and in-network coverage scenarios. Considering a wider range of applications and services, the sidelink-based relay function may include extended sidelink / network coverage and improved power efficiency.

[0069] To further provide coverage extension for sidelink-based communications, in WTRU-to-network coverage extension, Uu coverage reachability is required for a WTRU to reach a server in a PDN network or a corresponding WTRU outside the proximity area. WTRU-to-network relaying may be limited to EUTRA-based technologies and therefore may not be effectively applied to NR-based systems for both NG-RAN and NR-based sidelink communications.

[0070] Inter-WTRU coverage extension: Current proximity reachability is limited to single-hop sidelink links, either via EUTRA-based or NR-based sidelink technologies, however, it may not be sufficient in scenarios where Uu coverage does not exist, given the limited single-hop sidelink coverage.

[0071] Overall, sidelink connectivity may be extended in the NR framework to support enhanced QoS requirements, which may include single-hopping NR sidelink relays. These single-hop NR sidelink relays may have minimal specification impact to support SA requirements for sidelink-based WTRU-to-network relays and WTRU-to-WTRU relays, and may focus on the following aspects (where applicable): Layer 3 relay and Layer 2 relay [RAN2], relay (re)selection criteria and procedures, relay / remote WTRU authorization, QoS for relay function, service continuity, security of relay connections after SA3 provides its conclusions, user plane protocol stack and control plane procedures, e.g., impact on connection management of relayed connections, and mechanisms to support higher layer operation of discovery models / procedures for sidelink relays, assuming no new physical layer channels / signals [RAN2]. The system and method may take into account further inputs from the SA WG, e.g., SA2 and SA3, as well as elements described herein. The WTRU-to-network relay and the WTRU-to-WTRU relay may use the same relay solution. Forward compatibility for multi-hop relay support may be considered. For Layer 2 WTRU-to-network relay, an end-to-end PDCP and hop-by-hop RLC architecture may be defined.

[0072] A relay via ProSe WTRU-network relay may extend network coverage to out-of-coverage WTRUs by using PC5 (D2D) between the out-of-coverage WTRU and the WTRU-network relay. For example, the ProSe WTRU-network relay provides a generic L3 forwarding function that may relay any type of IP traffic between the remote WTRU and the network. One-to-one and one-to-many sidelink communication is used between the remote WTRU and the ProSe WTRU-network relay. Only one single carrier (i.e., Public Safety ProSe carrier) operation may be supported for both the remote WTRU and the relay WTRU (i.e., Uu and PC5 may be the same carrier for the relay / remote WTRU). The remote WTRU may be authorized by higher layers and may be in the coverage of the Public Safety ProSe carrier or out of coverage on any supported carrier including the Public Safety ProSe carrier for WTRU-network relay discovery, (re)selection, and communication. The ProSe WTRU-to-network relay is always within the coverage of the EUTRAN. The ProSe WTRU-to-network relay and the remote WTRU perform sidelink communication and sidelink discovery as described.

[0073] Relay selection / reselection for ProSe WTRU-NW relay is done based on a combination of AS layer quality measurements (RSRP) and higher layer criteria. The eNB controls whether the WTRU can operate as a ProSe WTRU-network relay. ProSe WTRU-network relay operation is supported in a cell if the eNB broadcasts any information associated with ProSe WTRU-network relay operation. The eNB may provide transmission resources for ProSe WTRU-network relay discovery using broadcast signaling for the RRC_IDLE state and dedicated signaling for the RRC_CONNECTED state, and reception resources for ProSe WTRU-network relay discovery using broadcast signals. The eNB may broadcast minimum and / or maximum Uu link quality (RSRP) thresholds that the ProSe WTRU-network relay needs to respect before initiating a WTRU-network relay discovery procedure. In RRC_IDLE, if the eNB broadcasts a transmission resource pool, the WTRU may use the thresholds to autonomously start or stop the WTRU-inter-network relay discovery procedure. In RRC_CONNECTED, the WTRU uses the thresholds to determine whether the WTRU may indicate to the eNB that it is a relay WTRU and wants to initiate ProSe WTRU-inter-network relay discovery. If the eNB does not broadcast a transmission resource pool for ProSe-WTRU-inter-network relay discovery, the WTRU may initiate a request for ProSe-WTRU-inter-network relay discovery resources by dedicated signaling, respecting these broadcasted thresholds. If the ProSe-WTRU-inter-network relay is initiated by broadcast signaling, it may perform ProSe-WTRU-inter-network relay discovery in the RRC_IDLE case.If the ProSe WTRU-network relay is initiated by dedicated signaling, it may perform relay discovery as long as it is in RRC_CONNECTED.

[0074] A ProSe WTRU-network relay performing sidelink communication for ProSe WTRU-network relay operation needs to be in RRC_CONNECTED. After receiving a Layer 2 link establishment request or a TMGI monitoring request (higher layer message) from a remote WTRU, the ProSe WTRU-network relay indicates to the eNB that it is a ProSe WTRU-network relay and intends to perform ProSe WTRU-network relay sidelink communication. The eNB may be provisioned with resources for ProSe WTRU-network relay communication.

[0075] The remote WTRU may determine when to start monitoring for ProSe WTRU-to-network relay discovery. The remote WTRU may send a ProSe WTRU-to-network relay discovery request message while in RRC_IDLE or RRC_CONNECTED depending on the configuration of resources for ProSe WTRU-to-network relay discovery. The eNB may broadcast a threshold value that may be used by the remote WTRU to determine whether it can send a ProSe WTRU-to-network relay discovery request message to connect or communicate with the ProSe WTRU-to-network relay WTRU. The RRC_CONNECTED remote WTRU may use the broadcasted threshold value to determine whether it can indicate to the eNB that it is a remote WTRU and wishes to participate in ProSe WTRU-to-network relay discovery and / or communication. The eNB may provide transmission resources for ProSe WTRU-to-network relay operation using broadcast or dedicated signaling, and may provide reception resources using broadcast signaling. The remote WTRU may stop using ProSe WTRU-to-network relay discovery and communication resources if the RSRP exceeds a broadcasted threshold. The exact time of traffic switching from Uu to PC5 or vice versa may be determined at higher layers.

[0076] The remote WTRU may perform radio measurements on the PC5 interface and may use the measurements together with higher layer criteria for ProSe WTRU-network relay selection and reselection. A ProSe WTRU-network relay may be considered suitable with respect to radio criteria if its PC5 link quality exceeds a configured threshold (preconfigured or provided by the eNB). The remote WTRU may select a ProSe WTRU-network relay that satisfies the higher layer criteria and has the best PC5 link quality among all suitable ProSe WTRU-network relays. The remote WTRU triggers ProSe WTRU-network relay reselection if the PC5 signal strength of the current ProSe WTRU-network relay falls below a configured signal strength threshold. Receive a Layer 2 Link Release message (higher layer message)

[62] from the ProSe WTRU-network relay.

[0077] In an embodiment related to a WTRU-to-Network Relay for wearables, for commercial use cases tailored for wearable IoT devices, the WTRU-to-NW relay may be performed in the RAN. In contrast to a ProSe WTRU-to-NW relay that uses an L3 (IP layer) relay approach, the WTRU-to-NW relay for wearables may be an L2 relay based on the protocol stacks shown below in FIG. 2, which shows a user plane radio protocol stack for a Layer 2 Evolved WTRU-to-Network Relay (PC5), and FIG. 3, which shows a control plane radio protocol stack for a Layer 2 Evolved WTRU-to-Network Relay (PC5).

[0078] 2 shows a user plane radio protocol stack 200 for Layer 2 evolved WTRU-to-network relay (PC5). The stack 200 includes a remote WTRU 210, an L2 relay WTRU 220, an eNB 230, and a CN 240.

[0079] The remote WTRU 210 may include resources for connecting using an IP connection, a PDCP (Uu) connection, and a PC5 connection. The PC5 resources may include RLC (PC5), MAC (PC5), and PHY (PC5). The IP connection may be communicatively coupled to the IP connection via the CN 240. The PDCP (Uu) connection may be communicatively coupled to the PDCP (Uu) connection via the eNB 230. The PC5 connection may be communicatively coupled to the PC5 connection at the L2 relay WTRU 220 utilizing resources such as RLC (PC5), MAC (PC5), and PHY (PC5).

[0080] The L2 relay WTRU 220 may include resources for connecting using a PC5 connection and Uu for the downlink and uplink. The PC5 resources may include RLC(PC5), MAC(PC5), and PHY(PC5). The PC5 connection may be communicatively coupled to a PC5 connection at the remote WTRU 210 using resources such as RLC(PC5), MAC(PC5), and PHY(PC5). The Uu connection may include resources RLC(Uu), MAC(Uu), and PHY(Uu). The Uu connection may be communicatively coupled to a Uu connection at the eNB 230 using resources such as RLC(Uu), MAC(Uu), and PHY(Uu).

[0081] The eNB 230 may include resources for connecting using a PDCP (Uu) connection, Uu for downlink and uplink, and S1-U / S5 / S8 for the remote WTRU 210. The PDCP (Uu) connection may be communicatively coupled to the PDCP (Uu) connection via the remote WTRU 210. The Uu connection may include resources RLC(Uu), MAC(Uu), and PHY(Uu). The Uu connection may be communicatively coupled to the Uu connection at the L2 relay WTRU 220 utilizing resources such as RLC(Uu), MAC(Uu), and PHY(Uu). The S1 connection may be communicatively coupled to the CN 240 via resources GTP-U, UDP / IP, and L1 / L2.

[0082] The CN 240 may include resources for connecting using an IP connection and S1-U / S5 / S8 for the remote WTRU 210. The IP connection may be communicatively coupled to the IP connection via the remote WTRU 210. The S1 connection may be communicatively coupled to the eNB 230 via resources GTP-U, UDP / IP, and L1 / L2.

[0083] FIG. 3 shows a control plane radio protocol stack 300 for a Layer 2 evolved WTRU-to-network relay (PC5), which includes a remote WTRU 310, an L2 relay WTRU 20, an eNB 230, and a CN 240.

[0084] The remote WTRU 310 may include resources for connecting using a NAS connection, a Uu connection, and a PC5 connection. The Uu connection may include RRC (Uu) and PDCP (Uu) resources. The PC5 resources may include RLC (PC5), MAC (PC5), and PHY (PC5). The NAS connection may be communicatively coupled to the NAS connection via the CN 340. The Uu connection may be communicatively coupled to the Uu connection via the eNB 330 using resources RRC (Uu) and PDCP (Uu). The PC5 connection may be communicatively coupled to the PC5 connection at the L2 relay WTRU 220 using resources such as RLC (PC5), MAC (PC5), and PHY (PC5).

[0085] The L2 relay WTRU 320 may include resources for connecting using a PC5 connection and Uu for the downlink and uplink. The PC5 resources may include RLC(PC5), MAC(PC5), and PHY(PC5). The PC5 connection may be communicatively coupled to a PC5 connection at the remote WTRU 310 using resources such as RLC(PC5), MAC(PC5), and PHY(PC5). The Uu connection may include resources RLC(Uu), MAC(Uu), and PHY(Uu). The Uu connection may be communicatively coupled to a Uu connection at the eNB 330 using resources such as RLC(Uu), MAC(Uu), and PHY(Uu).

[0086] The eNB 330 may include a Uu connection, Uu for downlink and uplink, and resources for connecting using S1-MME (Uu). The Uu connection may be communicatively coupled to the Uu connection via the remote WTRU 310 using resources RRC(Uu) and PDCP(Uu). The Uu connection may include resources RLC(Uu), MAC(Uu), and PHY(Uu). The Uu connection may be communicatively coupled to the Uu connection at the L2 relay WTRU 320 using resources such as RLC(Uu), MAC(Uu), and PHY(Uu). The S1-MME connection may be communicatively coupled to the CN 340 via resources S1-AP, SCTP, IP, and L1 / L2.

[0087] The CN 340 may include resources for connecting using a NAS connection and an S1-MME. The NAS connection may be communicatively coupled to the NAS connection via a remote WTRU 310. The S1 connection may be communicatively coupled to the eNB 330 via resources S1-AP, SCTP, IP, and L1 / L2.

[0088] Further details regarding the various connections shown in Figures 2 and 3 are described below. In an embodiment involving connection establishment for unicast links in NR V2X, relay solutions in previous solutions were based on a one-to-one communication link established at higher layers (ProSe layer) between two WTRUs (remote WTRU and WTRU-to-NW relay). Such a connection may be transparent to the AS layer, and connection management signaling and procedures performed at higher layers are carried by the AS layer data channel. Thus, the AS layer may not be aware of such a one-to-one connection.

[0089] This has evolved to the AS layer supporting unicast links between two WTRUs. Such unicast links are initiated by higher layers (as in ProSe one-to-one connections). The AS layer may be informed of the existence of such unicast links and any data transmitted in a unicast manner between peer WTRUs. With such knowledge, the AS layer may support HARQ feedback, CQI feedback, and unicast-specific power control schemes. Unicast links at the AS layer may be supported via PC5-RRC connections. A PC5-RRC connection may be defined as a logical connection between a pair of source Layer 2 ID and destination Layer 2 ID within an AS. One PC5-RRC connection corresponds to one PC5 unicast link. PC5-RRC signaling as specified herein may be initiated after the corresponding PC5 unicast link is established. The PC5-RRC connection and the corresponding sidelink SRBs and sidelink DRBs are released when the PC5 unicast link is released as indicated by higher layers.

[0090] For each unicast PC5-RRC connection, one sidelink SRB is used to transmit PC5-S messages before PC5-S security is established. One sidelink SRB is used to transmit PC5-S messages to establish PC5-S security. One sidelink SRB is used to transmit PC5-S messages after PC5-S security is established and protected. One sidelink SRB is used to transmit PC5-RRC signaling, which is protected and transmitted only after PC5-S security is established.

[0091] PC5-RRC signaling includes a sidelink configuration message (RRCReconfigurationSidelink) in which one WTRU configures RX-related parameters of each SLRB in a peer WTRU. Such a reconfiguration message may configure parameters for each protocol in the L2 stack (SDAP, PDCP, etc.). The receiving WTRU may confirm or reject such a configuration depending on whether it can support the configuration proposed by the peer WTRU.

[0092] In case of system information from NR WTRUs to NW relays, the remote WTRU may receive system information from the relay WTRU if PC5-RRC is connected to the relay WTRU. This mechanism is based on the following remote WTRU and relay WTRU behavior: In case of SI request: A remote WTRU in IDLE / INACTIVE may send an SI request to the relay WTRU using a PC5-RRC message (where the relay WTRU knows the requested SI), the relay WTRU may request / obtain SI from the network using legacy mechanism if it does not have the latest SI requested by the remote WTRU, and a remote WTRU in CONNECTED may send a dedicatedSIBRequest to the network via the relay WTRU. This Uu RRC message is sent transparently to the relay WTRU. The network may transparently send the requested SIB to the relay via the relay WTRU. Regarding SI acquisition: part of SIB1 (e.g., access control parameters) may be acquired by the remote WTRU before PC5-RRC connection establishment, other SI may be acquired after the remote WTRU establishes a PC5-RRC connection with the relay, the relay WTRU sends SI to the remote WTRU following a request by the remote WTRU, the relay WTRU sends SI to the remote WTRU following any SI updates previously requested by the remote WTRU via the SI request, and upon receipt of an SI modification by the relay WTRU, the relay sends the updated SI to all remote WTRUs that are in IDLE / INACTIVE.

[0093] The following provides an overview of the RRC states and the corresponding WTRU behavior. A WTRU may be characterized by its RRC state as being either RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE. The WTRU behavior associated with these states is as follows:

[0094] RRC_IDLE: PLMN selection, Broadcasting system information, Cell reselection mobility, Mobile terminated data paging will be initiated by 5GC, DRX for CN paging configured by the NAS.

[0095] RRC_INACTIVE: PLMN selection, Broadcasting system information, Cell reselection mobility, Paging is initiated by the NG-RAN (RAN paging), The RAN-based Notification Region (RNA) is managed by NG-RAN. DRX for RAN paging configured by NG-RAN, A 5GC-NG-RAN connection (both C / U planes) is established for the WTRU; The WTRU AS context is stored in the NG-RAN and the WTRU. NG-RAN is known to be the RNA to which WTRUs belong.

[0096] RRC_CONNECTED: A 5GC-NG-RAN connection (both C / U planes) is established for the WTRU; The WTRU AS context is stored in the NG-RAN and the WTRU. The NG-RAN knows the cell in which the WTRU resides. Forwarding unicast data to / from the WTRU; Network controlled mobility including measurements.

[0097] The SL WTRU-to-NW relay may focus on the OOC remote WTRU. The remote WTRU may operate on multiple paths when in coverage (one path directly on Uu, another path via the relay from the SL WTRU to the NW). This allows more flexible request and acquisition of system information by the remote WTRU. For example, the remote WTRU may request SI via the relay WTRU and receive it directly via Uu (considering that UL transmission is more expensive from power consumption and SI distribution may rely on broadcast if performed by the network). It also distributes SI requests over different paths to avoid congestion on each path separately.

[0098] Including the multi-path case and allowing path flexibility also introduces additional issues. For example, a relay WTRU needs to handle both remote WTRUs that support multi-path and remote WTRUs that do not support multi-path. To ensure diversity in the path selection (and to avoid one path being congested with SI requests compared to the other), some specified rules for path selection may be needed. Essentially, there may be cases where it is more efficient to request / receive SI on one path than another, but these may also depend on the preferences of the relay that needs to perform the forwarding. The SI request / delivery mechanism may depend on the RRC state of the relay / remote WTRU. New RRC state combinations for multiple paths (i.e., relay is IDLE / INACTIVE while remote WTRU is CONNECTED) may need to be addressed in the multi-path case. SI requests may be different for RRC_IDLE / RRC_INACTIVE compared to RRC_CONNECTED, but such differences may need to be taken into account when the remote and relay WTRUs are in different RRC states but have requested / received SI via the network. Furthermore, there may be benefits to avoid SI being sent by the relay WTRU to the remote WTRU, for example, when the remote WTRU may also acquire SI over Uu. Race conditions may be possible, for example, when the remote WTRU receives an SI correction from one path and actual SI from another path, but such race conditions may be addressed to avoid unnecessary WTRU power consumption or unsynchronized SI at the remote WTRU.

[0099] The system and method includes a relay WTRU determining whether to forward SI to a remote WTRU following a request by the remote WTRU based on coverage / capabilities indicated by the remote WTRU and an RRC state of the relay WTRU. The relay WTRU receives capability information from the remote WTRU in a PC5-RRC capability exchange related to whether the remote WTRU supports multiple paths, receives an SI request from the remote WTRU including a coverage indication (IC / OOC), requests the corresponding SI from the network, and if the requesting remote WTRU supports multiple paths and indicates IC in the request, and the relay WTRU is RRC_IDLE / RRC_INACTIVE, the relay WTRU sends an indication to the remote WTRU that it may obtain the requested SI directly over Uu upon receiving an indication that an SI request has been sent; otherwise (legacy remote WTRU, OOC remote WTRU, or relay WTRU in RRC_CONNECTED), the relay WTRU obtains the requested SI and sends it to the remote WTRU (via PC5-RRC).

[0100] The system and method, including possible corresponding remote WTRU behaviors, may determine whether the remote WTRU requests / receives SI from the network or relay based on Uu quality, SI request configuration (MSG1 or MSG3 based), and an indication from the relay following the SI request. A multi-path configured remote WTRU receives a Uu quality threshold for sending an SI request directly over Uu, receives a Uu quality threshold for receiving SI over Uu, receives an SI request configuration from SIB1 indicating an MSG1-based or MSG3-based SI request, sends an SI request over Uu if the Uu quality is above the threshold for sending an SI request and the WTRU is configured for an MSG1-based SI request, receives the requested SI over Uu, calculates an IC / OOC indication based on whether the measured Uu quality is above / below the SI reception threshold, sends an SI request including the calculated IC / OOC indication to the relay WTRU, receives the requested SI over Uu if the relay WTRU has instructed it to receive SI over Uu, and otherwise receives the requested SI via the relay WTRU.

[0101] The system and method, such as a new dedicatedSIBRequest usable by the relay, includes that following reception of a new SIB, the relay may indicate to the network whether the SIB may be provided in dedicated signaling or broadcast. The relay WTRU receives a PC5-RRC message from the remote WTRU enabling / disabling SI transfer over the SL, and receives an SI request from the remote WTRU when the relay WTRU receives an SI update notification for a new SIB or updated SI required by at least one remote WTRU. For a relay WTRU in RRC_CONNECTED, it sends a dedicatedSIBRequest indicating that the SIB may be broadcast if the relay is configured on BWP without CSS and at least one relay WTRU has SIB transfer disabled over the SL, otherwise it sends a legacy dedicatedSIBRequest. For a relay WTRU in RRC_IDLE / RRC_INACTIVE, it sends an SI request to the network and forwards the SI to the remote WTRU if at least one relay WTRU has SIB transfer enabled over the SL.

[0102] The system and method described herein provide for system information request and reception from a multi-path WTRU to a NW relay. A remote WTRU in a multi-path refers to a remote WTRU served by a network node (gNB) or by another WTRU (in case of V2X), and the remote WTRU may transmit received data to its destination via multiple paths. When the remote WTRU is in coverage, one such path may be a direct Uu path (if it is served by a gNB). Another such path may be via a SL relay. For simplicity, the description generally focuses on a remote WTRU served by a gNB via a single Uu path and a single SL relay path. The description also applies, with obvious extensions, to additional cases, such as multiple (more than two) paths, either direct and / or relay, multiple paths that are only direct, multiple paths that are only relay, and paths where the relay path is a multi-hop path.

[0103] Furthermore, although this disclosure addresses system information request and distribution in the multipath case, this disclosure may be equally applied to other control information distribution such as RRC messages, paging messages, and the like.

[0104] The route determination for SI request / SI reception may be performed when a remote WTRU in multiple paths determines which route to send an SI request or receive SI on, a remote WTRU in multiple paths determines which route to receive SI on, the remote WTRU indicates a requested or desired route to the relay WTRU / gNB, the relay WTRU decides whether to send SI to the remote WTRU, the relay WTRU decides whether to send SI to the remote WTRU, the relay WTRU performs the SI request without SI acquisition, the relay WTRU indicates a preference for SI transmission by the network, and the relay WTRU is configured with a forwarding behavior for SI and the content of the SI request from the remote WTRU to the relay WTRU.

[0105] When a remote WTRU in multiple paths determines which path to send an SI request or receive SI, a remote WTRU in coverage that needs SI not broadcast by the network may request such SI. A remote WTRU may be in multiple paths and may send an SI request to receive SI information. Such a remote WTRU may determine which path to use to send an SI request and / or receive SI based on one or a combination of the following factors: RRC state of the remote and / or relay WTRU may be used for the determination.

[0106] The remote WTRU may determine the SI request path based on the RRC state of the remote WTRU. For example, a remote WTRU in RRC_CONNECTED may always request SI via the relay, and a remote WTRU in RRC_IDLE / RRC_INACTIVE may always request SI via Uu. Alternatively, a remote WTRU in RRC_CONNECTED may request SI via any path based on the solution herein, and a remote WTRU in RRC_IDLE / INACTIVE may request SI only via Uu.

[0107] The remote WTRU may determine the SI request path based on the RRC state of the relay WTRU. For example, if the relay WTRU is in RRC_CONNECTED, the remote WTRU may send the SI request via the relay / direct, and if the relay WTRU is in RRC_IDLE / RRC_INACTIVE, the remote WTRU may send the SI request via the direct / relay path. The remote WTRU may determine the RRC state of the relay WTRU based on explicit messaging from the relay (e.g., in a discovery message or a PC5-RRC message sent by the relay). Alternatively, the remote WTRU may implicitly determine the RRC state of the relay WTRU based on other information / indications sent by the relay WTRU as described herein. For example, the RRC state of the relay WTRU may be learned implicitly by the remote WTRU. For example, the relay WTRU may send a PC5-RRC message when the state of the relay WTRU changes, which lets the remote WTRU decide its behavior regarding the SI request (enable / disable SI request via the relay WTRU).

[0108] The remote WTRU may determine the SI request path based on a state combination of the remote WTRU and relay WTRU RRC states. For example, for a state combination of the remote WTRU in RRC_CONNECTED and the relay WTRU in RRC_IDLE / RRC_INACTIVE, the remote WTRU may send the SI request only via the direct path (to avoid the relay WTRU from initiating an RRC connection to send a dedicatedSIBRequest). For other state combinations, the remote WTRU may send the SI request via any path, or may select a path based on other rules herein.

[0109] The Uu measurements of cell quality may be used in the determination. The remote WTRU may determine the SI request path based on the cell quality measured on Uu. For example, the remote WTRU may send an SI request via Uu if the measured Uu RSRP is above a threshold, and may send an SI request via SL otherwise. For example, the remote WTRU may send an SI request via Uu if it is in coverage, and may send an SI request via a relay if it is out of coverage.

[0110] The SL measurements may be used in the determination. The remote WTRU may determine the SI request path based on the measured SL quality. For example, the remote WTRU may send an SI request via SL if the measured SL RSRP is above a threshold, otherwise it may send an SI request via SL. For example, the remote WTRU may send an SI request via Uu if the measured CBR is above a threshold. For example, the remote WTRU may be multi-path connected via multiple SL relays and may send an SI request to the SL relay corresponding to the best SL measurement (e.g., possibly SL RSRP higher than a threshold), or may send an SI request via any of the SL relays with SL RSRP above a threshold. For example, the remote WTRU may send an SI request to multiple WTRUs if the RSRPs of multiple SLs are all below a threshold. For example, the remote WTRU may send an SI request via multiple SL relays if the CBR is above a threshold.

[0111] The SI request configuration may be used in the decision. The remote WTRU may determine the SI request path based on the legacy SI request configuration from the network. Specifically, if the remote WTRU is configured to perform MSG1-based SI requests (via SIB), the remote WTRU may use the Uu path, otherwise the remote WTRU may use the SL path, or may select a path based on other conditions described herein.

[0112] The condition of whether the requested SI is currently being broadcasted may be used in the decision. For example, the remote WTRU may receive SI over Uu if the required SI is currently being broadcasted (and the remote WTRU does not need to perform an SI request). If the requested SI is not currently being broadcasted, the remote WTRU may request and / or receive SI over SL, or may use other conditions herein to determine whether to receive over Uu or SL.

[0113] The new NW configuration may be used in the decision. The remote WTRU may be configured (e.g., in SIB or dedicated signaling) to select or prefer one path over another. Such configuration may be explicit or in the form of rules associated with other factors. For example, the network may configure the scope of Uu RSRP where SI requests may be made over SL / Uu. For example, the WTRU may receive an explicit configuration of whether SI requests may be performed over Uu or SL, possibly applicable to a subset of the conditions herein (e.g., some combination of RRC states).

[0114] The remote WTRU may receive the configuration of SRB1 and may determine a path for the SI request based on the SRB1 configuration. In particular, the remote WTRU may follow the SRB1 configuration to determine a path for sending the dedicatedSIBRequest. If SRB1 is configured on both paths, the remote WTRU may determine the path to use based on other conditions herein.

[0115] The cell ID / area ID of the relay WTRU's connected cell may be used in the determination. The remote WTRU may determine the SI request path based on the identity of the relay WTRU cell (the cell to which the relay WTRU is connected or camped), possibly relative to the cell in which the remote WTRU is in coverage. For example, the remote WTRU may request SI over Uu when the cells are different or when the cells belong to different area IDs.

[0116] The remote WTRU may determine the SI request path based on the cell on which the WTRU is camped or connected. Specifically, the remote WTRU may be in a multipath with a first cell and Uu, and a relay connected to a second cell. The remote WTRU may be camped or connected to one of these two cells while using both paths for data transmission. The remote WTRU may determine the path to request / receive SI based on the path associated with the camped / associated cell. Specifically, the remote WTRU may change the path when performing a mobility procedure from the first cell to the second cell.

[0117] For example, the relay WTRU may request / receive SI from any of the paths (possibly using other conditions herein) as long as the first cell and the second cell are the same (i.e., have the same cell ID), otherwise it may use only a single path.

[0118] For example, the remote WTRU may obtain the SI from either path when the first cell and the second cell are different, as long as the area ID associated with the SI is the same.

[0119] For example, the remote WTRU may request SI only from one path (e.g., the path associated with the PCell) when the cells on both paths of the multipath are different, whereas when the cells associated with the two paths are the same, the remote WTRU may request SI from either / both paths, possibly by selecting a path based on other conditions herein, possibly by requesting SI based on the SRB1 configuration (e.g., sending a dedicatedSIBRequest to the path where SRB1 is configured, sending a dedicatedSIBRequest to the primary path if a split SRB1 is configured, etc.).

[0120] For example, the remote WTRU may enable SI transfer by the relay WTRU (according to the mechanisms described herein, i.e., sending a PC5-RRC message) if the relay WTRU's cell is the same as the remote WTRU's cell, possibly with other conditions (e.g., only if the remote WTRU is IDLE / INACTIVE). Alternatively or additionally, the remote WTRU may disable SI transfer by the relay WTRU (according to the mechanisms described herein, i.e., by sending a PC5-RRC message) if the relay WTRU's cell is different from the remote WTRU's cell. For example, the remote WTRU may change from enabled / disabled based on the above conditions following a direct-path HO or following receipt of an indication from the relay WTRU of a HO / cell change.

[0121] Previous requests and / or failures of such requests may be used in the decision. The remote WTRU may use the results of previous SI requests to determine the route for the current SI request. For example, if a previous SI request over Uu was unsuccessful, the remote WTRU may request SI via both routes or only via SL. The remote WTRU may determine the failure of a request on one route based on any of the following: Expiration of a time period: For example, following an SI request over Uu / SL, if the remote WTRU is unable to acquire the requested SI, the remote WTRU may attempt an SI request on the other route and respond to the SI request. For example, following an SI request over SL, the remote WTRU may receive a response from the relay WTRU indicating that the remote WTRU can attempt an SI request over Uu instead.

[0122] The SI being requested may be used in the decision. The remote WTRU may decide which path to select for the requested SI based on the type of SI or the particular SIB being requested. For example, only one SI may be allowed to be requested via the direct path. For example, the remote WTRU may request positioning SI only from Uu, but may request other SI from either path. For example, the remote WTRU may always receive SI via Uu, but may use another condition to determine whether to request / receive another SI via SL or via Uu. For example, the SI requested / received via the relay may correspond to an SI that is also of interest to the relay WTRU. Specifically, the remote WTRU may learn the SI that is of interest to the relay WTRU (specifically for the relay WTRU, or for any other remote WTRU attached to that relay) through PC5-RRC messaging. The remote WTRU may then request / receive only the SI that is of interest to the relay WTRU.

[0123] The frequency and / or nature of the carrier on Uu and / or SL may be used in the determination. The remote WTRU may determine the route based on the type of carrier or the frequency of the carrier associated with Uu or SL. For example, if one of the carriers (Uu or SL) is unlicensed, the remote WTRU may select a licensed carrier (e.g., to avoid LBT operation). For example, if one of the carriers is FR2, the remote WTRU may select an SI using the other carrier.

[0124] Information / instructions from the relay WTRU may be used in the decision. The remote WTRU may determine the path based on information / instructions received from the relay WTRU. For example, the remote WTRU may receive a message from the relay WTRU to enable / disable SI request via the relayed path. When the remote WTRU is in coverage and SI request is disabled via the relayed path, the remote WTRU may request SI only via Uu. For example, the remote WTRU may receive a period during which SI request via the relayed path is not allowed. For example, the remote WTRU may be allowed to perform SI request via the relayed path as long as it has received any SI request configuration and / or SI request capability (e.g., in PC5-RRC) from the relay WTRU. Methods determined / used by the relay WTRU to send such instructions are described further herein.

[0125] The BWP configuration on Uu at the remote WTRU in RRC_CONNECTED may be used in the decision. The remote WTRU may determine the path for SI request / SI reception based on whether the remote WTRU's BWP is configured with a common search space. Specifically, if the remote WTRU has a BWP configured with a common search space, the remote WTRU may request / receive SI over the Uu link and may disable any SI forwarding by the relay WTRU. If the remote WTRU has a BWP on Uu configured without a common search space, the remote WTRU may request / receive SI over an indirect link, thereby enabling SI forwarding by the relay WTRU (by sending a list of requested SI to the relay WTRU). Such behavior may further be necessary if the remote WTRU is aware that the relay WTRU is in RRC_IDLE / RRC_INACTIVE. On the other hand, if the remote WTRU knows that the relay WTRU is in RRC_CONNECTED, the remote WTRU may send an SI request using a dedicatedSIBRequest to the network rather than by requesting SI in PC5-RRC from the relay WTRU.

[0126] The SL DRX and / or Uu DRX configuration / state of the relay and / or remote WTRU may be used in the decision. The remote WTRU may determine the route based on the Uu and / or SL DRX configuration or state. For example, when an SI request occurs when the relay WTRU is in SL DRX inactive time, the remote WTRU may send an SI request over Uu. For example, when an SI request occurs when the remote WTRU is in Uu DRX, the remote WTRU may send an SI request over SL.

[0127] The number of hops / paths may be used in the decision. For example, the remote WTRU may decide to send an SI request via the direct path if the number of hops on the SL relay path is above a threshold.

[0128] The availability of resources may be used in the decision, for example, the remote WTRU may use the path that has available resources (possibly the path that has the first resources available).

[0129] The bearer configuration may be used in the determination. For example, the remote WTRU may be configured with a bearer that allows / prefers a request for SI over SL / Uu. For example, the remote WTRU may be configured with a bearer configuration such that the remote WTRU may send an SI request over both paths.

[0130] The last active link for data transmission may be used in the determination. The remote WTRU may determine a route based on the last active route for communication. For example, the remote WTRU may be configured with an active route or a primary route while in multi-route (e.g., the primary route may be associated with a particular bearer or may be WTRU specific). For example, the remote WTRU may transition to RRC_INACTIVE and determine a route for the SI request based on the last active / primary route.

[0131] Whether the relay WTRU supports / accepts SI transfer / delivery may be used in the decision. For example, the relay WTRU may support relaying of user plane data but not control plane data. For example, the relay WTRU may support multi-path connections, whereby a primary path (or a concept similar to the primary path in dual connectivity) can go through another path (i.e., directly Uu, or another relay path). The relay WTRU may inform the remote WTRU of such support for SI transfer via discovery or PC5-RRC message. Based on receiving this information from the relay WTRU, the remote WTRU may decide to request / receive SI via the Uu path if the relay does not support SI transfer. If not, the remote WTRU may use either path (or decide based on other criteria herein).

[0132] Following multipath configuration / deconfiguration, whether the multipath is configured by adding a direct path or an indirect path may be used in the decision. For example, a remote WTRU connected via a relay may be configured with multipath by adding a direct path. Following such an addition, the remote WTRU may change from receiving SI via the relay WTRU to receiving SI via Uu. On the other hand, the remote WTRU may be configured with multipath by adding an indirect path. Following such an addition, the remote WTRU may maintain receiving SI via the Uu path. Specifically, when configured with multipath and RRC_CONNECTED, the remote WTRU may always request / receive SI via Uu. When not configured with multipath while in RRC_CONNECTED, the remote WTRU may use the particular path that provides the connection for requesting / receiving SI.

[0133] The remote WTRU may disable SI request via the relay WTRU if SI request via the relay WTRU is enabled, and the remote WTRU decides to request / receive SI via the Uu link instead. Specifically, the conditions that cause the remote WTRU to request / receive SI via Uu may change when previously requesting / receiving via SL. Upon such a change, the remote WTRU may send a PC5-RRC message to disable reception of SI at the relay WTRU on behalf of the remote WTRU. The reverse is also possible. Specifically, when the conditions that cause the remote WTRU to request / receive SI via the relay WTRU change, the remote WTRU may send a PC5-RRC message to indicate all SI that the remote WTRU is intended to receive from the relay WTRU. The remote WTRU may further indicate that the request (via the PC5-RRC message) is simply to re-enable SI change forwarding, and not to actually receive SI. Specifically, upon receiving such an indication, the relay WTRU may include in the RRC message a list of SIs as SIs to be forwarded upon change, but may not immediately forward the SIs to the remote WTRU. If such an indication is not included, the relay WTRU may immediately forward the SIs.

[0134] The relay WTRU may indicate a preference / override the SI request to the remote WTRU (via the relay). In relation to the options described above for the remote WTRU, the relay WTRU may inform the remote WTRU that the SI request may be performed via Uu (or a different path) rather than via the relay itself. Alternatively, the relay WTRU may indicate to the remote WTRU that the SI request is performed via another path (e.g., Uu). The relay WTRU may make such a decision based on one or a combination of the following:

[0135] The decision may be based on the Uu RSRP at the relay WTRU. For example, if the Uu RSRP measured by the relay WTRU is below a threshold, the relay WTRU may inform the remote WTRU that the remote WTRU may use the Uu path.

[0136] This decision may be based on the BWP configuration of the relay WTRU in RRC_CONNECTED. For example, when the relay WTRU is in RRC_CONNECTED and configured with a bandwidth portion without a common search space, the relay WTRU may indicate to the remote WTRU to request / receive SI over the Uu link.

[0137] The decision may be based on the RRC state of the relay WTRU. As described herein, the relay WTRU may disable sending a preference for SI requests over the relayed path based on the RRC state of the relay WTRU.

[0138] This decision may be based on whether the SI is broadcast by the cell. For example, if the SI is not broadcast in the cell, the relay WTRU may indicate to the remote WTRU that the SI may be requested over Uu.

[0139] The decision may be based on NW configuration, for example, a relay WTRU may be configured by the NW as to whether to inform a remote WTRU to disable SI requests via the relay.

[0140] The decision may be based on the SI request configuration, for example, if the relay WTRU is configured with MSG1-based SI requests versus MSG3-based SI requests.

[0141] The decision may be based on the load at the relay WTRU. For example, the relay WTRU may disable SI requests by remote WTRUs to the relay based on the relay load, which may be measured in terms of SL traffic, relay traffic, the number of remote WTRUs connected to the relay, etc.

[0142] The decision may be based on the DRX state of the relay WTRU. For example, the relay WTRU may transmit a period during which the remote WTRU may perform a direct SI request over Uu (e.g., corresponding to a DRX off period at the relay WTRU).

[0143] The remote WTRU may decide whether to request SI directly via the relay WTRU or via the network as instructed by the relay WTRU. Alternatively, the remote WTRU may use other conditions herein. For example, if the relay WTRU recommends that SI be sent over Uu, the remote WTRU may use one condition to route the SI request. If the relay WTRU does not recommend this, the remote WTRU may route the SI request via another condition.

[0144] Combinations of criteria are also possible and may be used in the decision. The combination may be to select the first route if the first condition and / or the second condition is met, and to select the second route if not. The combination may include selecting the first route under the first condition and selecting either the first route or the second route based on a combination of other conditions. The combination may include selecting the first route or the second route based on a combination (e.g., comparison) of two different criteria (e.g., SL quality and Uu quality). The combination may include using the first condition to determine whether to use the second condition or whether to use the third condition when deciding whether to use Uu or SL. Other examples of combinations are also contemplated and are not excluded.

[0145] Without loss of generality, the solutions herein for determining whether a remote WTRU requests / receives SI over Uu and / or SL may be extended to the reception / transmission of any control or data exchange with the network, such as paging. In one embodiment (partially shown in FIG. 5), the remote WTRU may receive an SI request transmission threshold from the network. The remote WTRU may further receive an SI request configuration (i.e., MSG1 configuration) in SIB1. The remote WTRU may measure Uu quality. If the Uu quality falls below a threshold and the WTRU is configured to use MSG3-based SI request over Uu, the remote WTRU may request SI over the SL relay. Otherwise, the WTRU may request SI over the Uu path.

[0146] In one embodiment, the remote WTRU may determine a path for SI request and / or SI acquisition based on a combination of the remote WTRU's RRC state, SI support by the relay WTRU, and other conditions described herein. For example, the remote WTRU may receive an indication from the relay WTRU (e.g., in a discovery or PC5-RRC message) that the relay WTRU does not support SI acquisition on behalf of the remote WTRU. However, the remote WTRU may still rely on transparent forwarding of its SI via the relay WTRU. Specifically, under conditions where the relay WTRU indicates to the remote WTRU that it does not support SI request / acquisition on behalf of the relay:

[0147] When the remote WTRU is in RRC_IDLE / RRC_INACTIVE, the remote WTRU requests and acquires SI directly over the Uu link. The remote WTRU may monitor SIB1 on Uu to determine if any SI has changed and acquire the changed SI.

[0148] When the remote WTRU is in RRC_CONNECTED, the remote WTRU may request SI via any path (Uu direct or relay path) and may obtain SI via any path (possibly regardless of the requested path). For example, the remote WTRU may determine the path for the SI request based on the NW configuration for the SRB path or the SI request path. For example, the remote WTRU may determine the path for the SI request based on Uu and / or SL RSRP and / or SL CBR.

[0149] Provided that the relay WTRU indicates to the remote WTRU that it supports SI request / acquisition, the path selection for the SI request may be independent of the RRC state and may depend on other factors herein. Alternatively, the WTRU may use a first criterion and / or factor of determination for path selection in RRC_CONNECTED and a second criterion and / or factor of determination for path selection in RRC_IDLE / RRC_INACTIVE.

[0150] The remote WTRU may determine the method for SI request to the relay based on the RRC state of the relay. A remote WTRU in RRC_CONNECTED may determine the method / RRC protocol stack / RRC message for SI request (e.g., using an SI request to the relay WTRU via PC5-RRC or using a dedicatedSIBRequest sent to the network via the relay). In particular, when the relay WTRU is in RRC_CONNECTED, the remote WTRU may request SI via the relay WTRU using a dedicatedSIBRequest (Uu RRC message). Alternatively, when the relay WTRU is in RRC_IDLE / RRC_INACTIVE, the remote WTRU may request SI via a PC5-RRC message. The remote WTRU may know the RRC state of the relay WTRU explicitly from the relay WTRU (e.g., in a PC5-RRC message or MAC CE), explicitly from the network (e.g., in a Uu RRC Reconfiguration or similar Uu RRC message), or implicitly based on other configuration, the remote WTRU may be configured with the behavior to send an SI request to the relay WTRU based on an indication (e.g., a flag) received from the network in an RRC message.

[0151] A remote WTRU in multiple paths may determine whether to duplicate an SI request. In one solution, a remote WTRU in multiple paths may determine whether to send an SI request using duplication. Such a decision may be based on one or a combination of the following criteria:

[0152] The RRC state of the remote WTRU may be used. For example, the remote WTRU may use different rules to determine whether to replicate the SI request depending on the RRC state of the remote WTRU. For example, the remote WTRU may be allowed to replicate the SI request only if it is in RRC_CONNECTED.

[0153] Whether the cell IDs of the paths are the same or not may be used.

[0154] Uu and / or SL RSRP may be used. For example, the remote WTRU may replicate SI if the Uu RSRP is below a first threshold or the SL RSRP is below a second threshold. For example, the remote WTRU may replicate SI if the RSRP on the link on which the remote WTRU has determined (based on the terms herein) to send an SI request is below a threshold.

[0155] For example, the remote WTRU may duplicate SI requests while in RRC_CONNECTED based on the SRB1 configuration (i.e., when configured with split / duplicate SRB1) without checking RSRP and / or cell ID, whereas when the remote WTRU is in RRC_IDLE / RRC_INACTIVE, the remote WTRU may duplicate SI requests (i.e., send SI requests on both links for the same SI) only when the Cell ID is the same on both paths and based on the conditions regarding Uu and / or SL RSRP, as described above.

[0156] For example, the remote WTRU may duplicate the SI request while in RRC_IDLE / RRC_INACTIVE only if the cells associated with the direct and indirect links are the same.

[0157] The relay WTRU may release the requested SI list associated with the remote WTRU following a cell change. In one solution, the relay WTRU may release the requested SI list received from the remote WTRU (i.e., in PC5-RRC) following a cell change at the relay WTRU, such as a HO at the relay WTRU or a reselection by the relay WTRU. Such release may be required since the remote WTRU may no longer be able to receive SI from the relay WTRU, given that the relay WTRU may move from the same cell as the remote WTRU (where SI may be transferred) to a different cell (where SI may not be transferred). Specifically, following a cell change at the relay WTRU, the relay WTRU may not send updated SI to the remote WTRU based on the requested SI list.

[0158] In an embodiment where a remote WTRU in multiple paths determines on which path to receive SI, the remote WTRU may determine / determine the path on which to receive SI while in multiple paths. The conditions for determining whether to receive SI on Uu and / or SL may be the same as those described herein for determining whether to send an SI request to Uu or SL, and are not repeated here for brevity. It should be noted that determining whether to receive SI from SL or Uu may affect the WTRU's Uu / SL monitoring behavior. For example, a remote WTRU that determines to receive SI on Uu may be expected to monitor the Uu PDCCH for a period of time if possible. A remote WTRU that determines to receive SI over SL may stop monitoring the Uu PDCCH for SI updates or SI (e.g., perform Uu DRX during SI broadcast schedule).

[0159] In one embodiment, the remote WTRU may determine an SI request path based on a first condition and may determine a path for receiving the requested SI based on a second condition. Specifically, the remote WTRU may request SI and receive SI over the same or different paths (based on independent determinations). For example (partially shown in FIG. 5), the remote WTRU may be configured with a first Uu threshold for SI request and a second Uu threshold for SI response. The remote WTRU may determine a path for requesting SI based on a comparison of the Uu RSRP to the first threshold. Note that the remote WTRU may determine a path for receiving SI and / or determine whether to enable / disable reception of SI from the relay WTRU based on a comparison of the Uu RSRP to the second threshold, possibly in combination with another condition (e.g., an instruction from the remote WTRU).

[0160] In another embodiment, the remote WTRU may determine the route over which to receive SI based on the route used to request SI, and in particular may assume that the route will always be the same.

[0161] In another embodiment, the remote WTRU may determine the path to receive the SI based on whether the SI of interest is currently being broadcast by the network. Specifically, the remote WTRU may determine from SIB1 whether the SI is being broadcast. If the SI is being broadcast, the remote WTRU may receive it via Uu. If it is not being broadcast, the remote WTRU may also request it via the SL relay path and receive it via the SL.

[0162] The decision on the path to request / receive SI may be specific to the SI itself. Specifically, different rules / conditions may be defined based on the above that are specific to the SI or SIB. For example, the preference or override of the SI request by the relay WTRU to be sent to the remote WTRU may be signaled per SI or SIB.

[0163] In an embodiment where the remote WTRU indicates a requested / desired path to the relay WTRU / gNB, the remote WTRU may indicate to the relay WTRU the requested / desired path for SI reception and / or whether SI may be forwarded by the relay WTRU over the SL. Specifically, the remote WTRU may determine a path for SI reception based on the conditions herein. Following such a determination, the remote WTRU may indicate the selected path to the relay WTRU. Alternatively, if the remote WTRU determines a Uu path, the remote WTRU may request the relay WTRU not to provide SI over the SL, or vice versa. Such an indication may be in a PC5-RRC message (to the relay WTRU) or in a Uu RRC message (if the indication is to the gNB). Such an indication may be sent together with the SI request. Such an indication may be in the form of an enable / disable signal. Specifically, such an indication may turn on or off SI forwarding by the relay WTRU over the SL. If SI forwarding was last turned on, the remote WTRU may receive SI directly from the relay WTRU. If SI forwarding is turned off, the remote WTRU may receive SI from the network over Uu.

[0164] The remote WTRU may determine whether / what instructions to send to the relay WTRU based on a combination of conditions described herein. For example, the remote WTRU may turn on SI forwarding (by sending SI forwarding enable / request) via the relay WTRU if the remote WTRU is OOC and in either RRC_IDLE / RRC_INACTIVE or if the remote WTRU is in coverage and in either RRC_IDLE / RRC_INACTIVE, otherwise (remote WTRU in RRC_CONNECTED or in coverage), the remote WTRU may turn off SI forwarding (by sending SI forwarding disable). For example, the relay WTRU may turn on SI forwarding if the Uu RSRP is below a threshold (even if the remote WTRU is in coverage).

[0165] Once a relay WTRU has requested a desired path for SI reception, it may accept or reject such request. Specifically, the relay WTRU may send an acceptance or may simply send the SI. For example, the relay WTRU may send a rejection if it decides to send SI via a different path. The relay WTRU may make such a decision based on conditions (described further herein) to determine whether the relay WTRU may forward the SI to the remote WTRU or whether it may have the network send the SI (i.e., in some cases, not have the remote WTRU send any information).

[0166] Such an embodiment may be extended to a request by the remote WTRU to the network. Specifically, the remote WTRU may indicate to the network the desired path (via Uu or SL relay) for receiving SI. Specifically, the remote WTRU may include a field in the dedicatedSIBRequest indicating whether SI may be transmitted via Uu or via a relayed path. Alternatively, the remote WTRU may be configured with dedicated RACH (random access channel) resources, dedicated resource timing, or a request type (MSG1 / MSG3) that implicitly indicates the desired path for SI reception.

[0167] In embodiments in which a relay WTRU determines whether to transmit SI to a remote WTRU, the relay WTRU may determine whether to transmit SI to the remote WTRU. Such a determination may be made following an SI request by that remote WTRU. Such a determination may be made following a determination by the relay WTRU that the SI has changed (e.g., following receipt of an SI modification or following a determination of a change in the value tag of the SI). If the relay WTRU decides to transmit SI, it may transmit the SI at some point following the SI request or SI update. If the relay WTRU may decide not to transmit SI, it may refrain from transmitting SI. Alternatively, it may transmit an indication to the remote WTRU that SI will not be transmitted. Such an indication may be used by the remote WTRU to monitor SI over Uu.

[0168] In addition to deciding whether to send SI to the remote WTRU, the relay WTRU may still perform an SI request to the network. Specifically, the relay WTRU may decide not to forward SI but still perform an SI request to the network (to allow the remote WTRU to obtain SI from the network).

[0169] The relay WTRU may determine whether to send / forward SI to the remote WTRU and / or whether an SI request is still required based on one or a combination of the following: RRC states of the remote and / or relay WTRU, SL measurements, SL link states, requested SI, information / instructions from the remote WTRU, whether the relay WTRU has the requested SI in the relay or has to request / obtain it, and whether the relay WTRU requests SI for itself.

[0170] For the RRC state of the remote and / or relay WTRU, the relay may determine whether to send SI to the remote WTRU based on the RRC state of the remote WTRU and / or relay WTRU. For example, when an SI update is determined in the relay WTRU, the relay WTRU may send SI to the remote WTRU as long as the remote WTRU is not in RRC_CONNECTED. If the remote WTRU is in RRC_CONNECTED, the relay WTRU may assume that SI can be obtained by the remote WTRU over Uu. The relay WTRU may implicitly know the RRC state of the remote WTRU based on an indication from the remote WTRU, as described further herein.

[0171] The relay WTRU may determine whether to send updated SI to the remote WTRU based on its own RRC state. Specifically, if the relay WTRU is in RRC_CONNECTED and possibly configured with a common search space, the relay WTRU may forward any updated SI to the remote WTRU. Otherwise, the relay WTRU may not forward such updated SI to the remote WTRU even if the updated SI is part of the list of SIs to be provided by the remote WTRU to the relay WTRU.

[0172] In case of SL measurements, the relay WTRU may decide whether to send SI to the remote WTRU based on the SL measurements, such as SL CBR, SL RSRP, etc. For example, the relay WTRU may be configured with an SL CBR threshold for forwarding SI following a SL update decision. The relay WTRU may forward the SI as long as the measured SL CBR is above the threshold, otherwise the SI may not be forwarded.

[0173] In the case of an SL link state, for example, if the relay WTRU determines that an SL RLF has occurred (e.g., by its own decision of the SL RLF or by instruction from a remote WTRU of the SL RLF), it may not forward the SI, potentially following a decision to update the SI.

[0174] When an SI is requested, for example, the relay WTRU may forward one particular SI if it is updated, but not forward another SI if it is updated. For example, the relay WTRU may forward all SIs except positioning SI. For example, the relay WTRU may not forward SIB1 when SIB1 is updated, but may forward other SIs when they are updated. The relay WTRU may decide whether a particular SI is forwarded based on the specification, based on configuration from the network or from higher layers, and based on instructions / requests from the remote WTRU.

[0175] Regarding information / instructions from the remote WTRU, for example, the relay WTRU may send SI if SI transfer has been requested / turned on by the remote WTRU (e.g., in PC5-RRC). Such an indication may be a separate message or may come as part of the SI request itself.

[0176] For example, with regard to whether the relay WTRU has the required SI at the relay or whether the relay WTRU must request / obtain it, the relay WTRU may send the SI to the remote WTRU if it already has SI available, or may assume / instruct the remote WTRU to obtain the SI if the relay WTRU needs to obtain and / or request SI.

[0177] Regarding whether the relay WTRU requires SI for itself, for example, the relay WTRU may decide to send SI to the remote WTRU (following acquisition) if the relay WTRU also requires SI, or may assume / instruct the remote WTRU to acquire SI if the relay WTRU does not require SI.

[0178] The remote WTRU may begin requesting / receiving SI over Uu upon receiving an indication that the relay WTRU is not requesting / receiving SI for the remote WTRU.

[0179] Without loss of generality, the same conditions for determining whether to enable / disable the SI request to the relay (determined at the relay) may be used to determine whether the relay WTRU forwards SI.

[0180] In embodiments in which a relay WTRU may perform an SI request without SI acquisition, a relay WTRU attached to a remote WTRU may perform an SI request without subsequent SI acquisition under several conditions when the remote WTRU indicates to the relay WTRU that the remote WTRU may receive SI directly from Uu. For example, the relay WTRU may perform an SI request without subsequent SI acquisition if one or a combination of the following conditions apply, including: the relay WTRU determines that the SI has changed relative to the SI required by the remote WTRU or receives a request for SI from the remote WTRU, the relay WTRU does not require SI for its own operation, the relay WTRU determines that the requested or modified SI is not currently broadcast by the network, and the relay WTRU determines to forward / not forward SI to the remote WTRU and relies on the remote WTRU to obtain SI directly from Uu.

[0181] The relay WTRU may further inform the remote WTRU of such a decision. For example, after an SI request by the remote WTRU to the relay WTRU, the relay WTRU may respond to the remote WTRU indicating that SI may be acquired by the remote WTRU over Uu.

[0182] In embodiments where the relay WTRU may indicate a preference for SI transmission by the network, the relay WTRU may indicate (e.g., in a dedicatedSIBRequest procedure) whether the network may provide the requested SIBs and / or broadcast them using dedicated RRC signaling to the relay WTRU. The relay WTRU may determine whether to request the network to broadcast SI based on the relay WTRU's CSS configuration and knowledge / determination of the remote WTRU's SI reception path (Uu or SL) as described herein. For example, the relay WTRU may determine (based on mechanisms described herein) that the remote WTRU receives SI directly from Uu. Following an event that requires the remote WTRU to obtain SI (e.g., an SI update for SI requested by the remote WTRU, or an SI request by the remote WTRU), if the relay WTRU is in RRC_CONNECTED and configured in BWP without CSS, the relay WTRU may send a new indication in a dedicatedSIBRequest (instead of or in addition to sending it in dedicated signaling to the relay WTRU) informing the network that the SI may be broadcast by the network. Otherwise (e.g., if the SI to be updated does not pertain to the remote WTRU, or the remote WTRU does not request SI, or the relay WTRU is configured on BWP with CSS), the relay WTRU in RRC_CONNECTED may send a legacy dedicatedSIBRequest.

[0183] In an embodiment where a relay WTRU may be configured with a forwarding behavior for SI, whether the relay WTRU forwards SI to a remote WTRU may be configured by the network for the relay WTRU. For example, the relay WTRU may determine whether and / or which SI to forward to the remote WTRU. For example, the relay WTRU may determine whether to forward SI from the SIB. The relay WTRU may use this configuration in conjunction with other information (e.g., IC / OOC remote WTRU) to determine whether to forward SI. In another embodiment, the relay WTRU may be configured by the network in dedicated RRC signaling whether / which SI to forward, possibly for each particular attached remote WTRU, possibly for a particular RRC state of the relay / remote WTRU, possibly for a given condition or set of conditions as further described herein. The relay WTRU may follow such configuration only in certain RRC states (e.g., RRC_CONNECTED, RRC_INACTIVE) and use other rules / procedures herein for other RRC states. For example, following receipt of a list of SIs of interest from the remote WTRU via PC5-RRC, the relay WTRU may forward or not forward any updated SIs in that list to the relay WTRU based on instructions from the network, which may come to the relay WTRU in dedicated signaling.

[0184] Similarly, the remote WTRU may receive similar configuration on whether to transmit and / or receive SI from the relay WTRU or directly over Uu. For example, the remote WTRU may receive such configuration in dedicated RRC signaling while in RRC_CONNECTED and may also apply the configuration when in RRC_INACTIVE.

[0185] A relay WTRU may indicate its support of multi-path / single connection by (not) forwarding SI. As described herein, a relay WTRU may or may not support or be configured for SI forwarding. For example, a relay WTRU that provides an additional path for data routing for a remote WTRU, where the remote WTRU may be anchored on Uu (or another relay that supports SI), may indicate such to the remote WTRU. A relay WTRU may determine whether it supports SI forwarding based on any or a combination of the following factors:

[0186] Forwarding support may be determined based on NW configuration. For example, the relay WTRU may be configured to support / not support SI forwarding, for example, by dedicated signaling. For example, the relay WTRU may be configured to support SI forwarding if the gNB supports multipath (i.e., based on an indication in the SIB). For example, the relay WTRU may be configured with conditions (i.e., as described herein) on whether to support SI forwarding or not.

[0187] The forwarding support may be determined based on the WTRU capabilities. As described herein, a relay WTRU may or may not be configured with the capability to provide SI forwarding.

[0188] The forwarding support may be determined based on the Uu RSRP, for example, a relay WTRU may be configured with a minimum and / or maximum Uu RSRP that either supports or does not support SI forwarding.

[0189] The forwarding support may be determined based on the relay load. For example, the relay WTRU may measure a load metric based on any of the resources used, the number of remote WTRU connections, the number of bearers used, the overall traffic forwarded, etc. If the measured load of the relay WTRU is below a certain amount, the relay WTRU may support SI forwarding.

[0190] Forwarding support may be determined based on the BWP configuration. For example, if the relay WTRU is configured with a BWP that includes a common search space, the relay WTRU may determine to support SI forwarding.

[0191] The transfer support may be determined based on a power saving preference or configuration in the relay WTRU. For example, whether the relay WTRU supports SI transfer may depend on the value of a DRX configuration parameter (e.g., DRX cycle is greater / less than an offset, the DRX offset has some value for the SI correction period). For example, whether the relay WTRU supports SI transfer may depend on its power consumption characteristics and / or battery life.

[0192] The forwarding support may be determined based on the RRC state of the relay WTRU. For example, whether the relay WTRU supports SI forwarding may be indicated by the RRC state of the relay WTRU.

[0193] Forwarding support may be determined based on services and / or bearers / QoS configured at the relay WTRU. Specifically, whether a relay WTRU supports SI forwarding may be a function of services currently supported by the relay WTRU, bearers configured at the relay WTRU, or QoS of services supported / forwarded by the relay WTRU. For example, a relay WTRU may support SI forwarding as long as the number of bearers configured with a priority higher than a threshold is below another threshold. For example, a relay WTRU may support SI forwarding if one or more relayed RLC channels at the relay WTRU are configured with a property (e.g., explicit or implicit, such as priority) that the relay WTRU is configured to forward SI.

[0194] A relay WTRU that supports SI transfer may indicate such to the remote WTRU. The relay UE may include the SI or some specific SI (e.g., cell access information) in a discovery message sent by the relay WTRU. If the relay WTRU does not support SI transfer, the relay WTRU may not include the cell access information in the discovery message. The relay WTRU may indicate whether it supports SI transfer or not upon receipt of an SI request by the remote WTRU. The relay WTRU may inform the remote WTRU in a PC5-RRC message that it does or does not support SI transfer.

[0195] The relay WTRU may trigger the signaling changes described above when the conditions for supporting SI transfer change.

[0196] As described herein, a remote WTRU PC5-RRC connected to a relay WTRU that does not support SI transfer may request / obtain SI (potentially in RRC_IDLE / RRC_INACTIVE) from the Uu link or from another link when connected via multiple paths. In one example solution, the remote WTRU may (re)select a relay WTRU that supports only SI transfer for initiation of an RRC connection via the relay WTRU.

[0197] In one embodiment, a remote WTRU that is PC5-RRC connected to a relay WTRU may trigger re-establishment when the relay WTRU changes its support of SI forwarding to "not supported" if it is connected via a relay WTRU, or if it is connected via multiple paths and the Uu link experiences RLF.

[0198] In another embodiment, a remote WTRU that is PC5-RRC connected to a relay WTRU may trigger relay (re)selection (possibly immediately, possibly upon the remote UE's next transition to RRC_IDLE / RRC_INACTIVE) if the relay WTRU changes its support of SI transfer to "not supported." Specifically, the remote WTRU may trigger mobility procedures when SI transfer support changes to "not supported" when the remote WTRU is in RRC_IDLE / RRC_INACTIVE.

[0199] In an embodiment of the content of the SI request from the remote WTRU to the relay WTRU, the remote WTRU may send an SI request to the relay WTRU. The remote WTRU may also send an SI forwarding enable / disable message to the relay WTRU to enable / disable the relay WTRU from forwarding SI when an SI update is triggered. The two messages may be implemented in a single message.

[0200] The remote WTRU may include in either the SI request or SI transfer enable / disable message the Uu / SL quality measured by the remote WTRU (either the actual quality, or in the form of a quality level, or an indication of whether the quality is above or below a threshold), an indication of the RRC state of the remote WTRU, an indication of the coverage status (IC / OOC) of the remote WTRU, an indication / request whether SI may be transferred or whether the remote WTRU obtains SI directly over Uu (including that the remote WTRU may instead use other examples of information sent to the relay WTRU to calculate this indication), the cell ID of the cell for which the remote WTRU requires SI, a list of SIs that the remote WTRU requests to be transferred compared to the SI it obtains directly over Uu, an indication / request whether a SI change request by the network may be forwarded by the relay WTRU to the remote WTRU, a validity time period indicating how long it may take for the relay WTRU to forward any changed SI, the area ID or validity tag of the SI currently in the remote WTRU, and the number of hops (if the request is being made by an intermediate node that is also connected to the remote WTRU in a multi-hop architecture).

[0201] In one embodiment, the remote WTRU may use two different indications to the relay WTRU for SI transfer behavior, or may indicate three different SI reception behaviors to be performed by the relay WTRU. Specifically, the remote WTRU may receive all SI corrections (i.e., via paging) and SI over Uu in some cases and may indicate such to the relay WTRU. In another embodiment, the remote WTRU may indicate that it cannot receive SI corrections (i.e., paging) over Uu, and may rely on the relay WTRU to receive updated SI over the network (e.g., through detection of SIB1 after indication by the relay WTRU). In another embodiment, the remote WTRU may indicate that it will receive both SI corrections and updated SI only via the relay WTRU.

[0202] The relay WTRU may perform one or a combination of different actions depending on each of the above three possible cases, indicated by potentially two separate indications from the remote WTRU.

[0203] 4 shows a method 400 for system information acquisition for a multi-path WTRU-to-NW relay. The multi-path WTRU includes the above-mentioned features as required to perform the method 400.

[0204] The method 400 includes receiving an instruction to enable or disable SI transfer from a remote WTRU, at 405. The method 400 includes determining, at 410, whether a relay WTRU connected to one or more remote WTRUs may receive a PC5-RRC message from the remote WTRU to enable or disable SI transfer of SLs for the remote WTRU.

[0205] The method 400 includes, at 420, receiving an SI modification indication for a remote WTRU-associated SI when the relay WTRU is not connected and not configured without CSS. At 430, the method 400 includes acquiring SI from the network. The acquisition may include an SI request, if necessary. At 440, the method 400 includes disabling SI forwarding by the remote WTRU. The disabling enables the remote WTRU to receive SI over the Uu. If SI forwarding is disabled at 440, the method 400 may be completed at 450. If SI forwarding is not disabled at 440, the method 400 includes forwarding the SI to the remote US at 445 before completing the method 400 at 450.

[0206] The method 400 includes, at 415, receiving new SI from the network, e.g., via dedicated signaling, if the relay WTRU is connected and configured without CSS. At 425, the method 400 includes disabling SI forwarding by the remote WTRU. The disabling enables the remote WTRU to receive SI over the Uu. If SI forwarding is disabled at 425, the method 400 sends a new request to the NW indicating to broadcast the SI, at 435. If SI forwarding is not disabled at 425, the method 400 includes forwarding the SI to the remote US, at 445, before completing the method 400 at 450.

[0207] For example, the method 400 may include that the relay WTRU may receive one or more SI requests from the remote WTRUs and may store the target SI for each remote WTRU. Upon receiving a new SIB by the relay WTRU (i.e., in dedicated signaling from the network when the relay WTRU is configured with BWP without CSS and RRC_CONNECTED) or upon receiving an SI modification by the relay WTRU, the relay WTRU may first check whether it needs to act based on whether the modified SI is associated with an SI that is a target for one of the remote WTRUs. The relay WTRU may act if the remote WTRU needs the SI to be modified. The action taken by the relay WTRU may depend on its RRC state. In particular, if the relay WTRU is RRC connected, the relay WTRU may send a dedicatedSIBRequest message to the network if a SIB is needed. If the relay WTRU is configured on BWP without CSS and at least one relay has SIB forwarding disabled via SL, the relay WTRU may send an SI request (e.g., an indication with dedicatedSIBRequest) to request the network to broadcast the SIB; otherwise, an RRC connected relay WTRU may send a legacy dedicatedSIBRequest message (or a message that does not activate the indication). A relay WTRU in IDLE / INACTIVE may send a normal SI request if the relay WTRU may operate. Regardless of the RRC state, the relay WTRU may forward SI to a remote WTRU if the remote WTRU has requested SI forwarding. Without loss of generality, the relay WTRU message to the network to initiate SI broadcast by the network of SI may be any RRC message (not just dedicatedSIBRequest) or any uplink transmission, such as a RACH procedure (similar to a MSG1-based SI request).With such a transmission, the network may transmit an SI that is not currently broadcast. Note that, before transmitting a message as shown in Figure 4, the relay WTRU may first determine whether the updated SI is currently broadcast by the network (by checking the contents of SIB1), and may transmit such a message only if the network is not broadcasting the particular updated SIB.

[0208] In one embodiment, the relay WTRU may determine a unified approach to SI transfer based on individual coverage status and requests from each remote WTRU. For example, if all remote WTRUs are in coverage, the relay WTRU may not perform SI transfer (and may not rely on Uu SI transmission) regardless of requests by some individual WTRUs. Specifically, the relay WTRU may reject requests by remote WTRUs to transfer SI. In one embodiment, if at least one remote WTRU indicates to the relay WTRU that it is OOC, RRC_IDLE, RRC_INACTIVE, the relay WTRU may proceed to transfer SI on the SL for all WTRUs regardless of whether all WTRUs have requested it.

[0209] 5 shows a method 500 for system information acquisition for a multi-path WTRU-to-NW relay. The multi-path WTRU includes the above-mentioned features as required to perform the method 500.

[0210] The method 500 includes two main elements: an IC remote WTRU requests SI at 510, and a relay WTRU provides SI at 550. Within the IC remote WTRU requests SI at 510, the method 500 includes receiving an SI request transmission threshold, an SI acquisition threshold, and an SI request configuration from the network at SIB1. The SI request configuration may include either MSG1 or MSG3. At 525, the Uu quality is compared to the SI request transmission threshold to determine whether the SI request configuration is MSG3. If the result of the comparison or determination at 525 is "no", then at 535, the legacy Uu is followed to request and receive SI over the Uu. If the result of the comparison or determination is "yes", then at 545, an IC / OOC indication is calculated and sent to the relay WTRU along with the SI request.

[0211] Within the relay WTRU providing the SI at 550, the method 500 includes requesting SI on behalf of the remote WTRU at 555. At 565, the method 500 includes determining whether the remote WTRU IC or the relay WTRU is IDLE / INACTIVE. If the result of the determination at 565 is no, then at 575, the legacy SL relay is used to forward the SI to the remote WTRU. If the result of the determination at 565 is yes, then at 585, the remote WTRU is notified that SI is available over Uu.

[0212] Details and modifications related to methods 400, 500 are provided below. For example, the Uu quality measured by the remote WTRU and the RRC state of the relay WTRU may determine the SI transfer / acquisition behavior of the remote and relay WTRUs. Specifically, the remote WTRU may receive an SI request transmission threshold and an SI acquisition threshold in SIB1. The remote WTRU may further receive an SI request configuration (according to legacy) that determines whether the WTRU performs an MSG1-based SI request or an MSG3-based SI request. If the remote WTRU is in coverage and if the Uu quality of the remote WTRU falls below the request threshold and the remote WTRU is configured with an MSG3-based SI request, the remote WTRU may send an SI request to the relay WTRU. Otherwise, the SI request may be sent over Uu. If the SI request is sent over Uu, the remote WTRU may also receive SI over Uu using legacy procedures. When an SI request is sent to the relay over the SL, the remote WTRU may include an IC / OOC indication to the relay WTRU. The IC / OOC indication may be calculated based on the current conditions for the preferred cell. Alternatively, the IC / OOC indication may be calculated by comparing the Uu quality to a new threshold.

[0213] The relay WTRU may request SI on behalf of the remote WTRU if the relay WTRU receives an SI request from the remote WTRU, if the relay WTRU does not currently have a valid version of the SI and the network is not currently broadcasting the requested SI. If the remote WTRU indicates IC and the relay WTRU is IDLE / INACTIVE, the relay WTRU may notify the remote WTRU to receive SI over Uu. Otherwise, the remote WTRU may forward the requested SI (which it has or may have acquired) to the remote WTRU.

[0214] In a modified embodiment of the embodiment shown in Figure 5, the relay WTRU itself may not need the SI requested by the remote WTRU. If the relay WTRU decides to have the remote WTRU acquire the SI itself, the relay WTRU may perform the request without acquiring the SI, as described herein.

[0215] The present system and method deal with SI modification indications and PWS. SI modification indications and PWS indications are described interchangeably since they are sent by the network using a common paging message. It may be understood that the concept applies to networks that send either a paging message indicating that the SI has changed, or a paging message indicating that a PWS is being broadcast, or both. The SI modification indication (i.e., in a paging) may be received by a remote WTRU. The remote WTRU may receive such an indication over Uu, for example, if the remote WTRU is in multipath and monitors paging on Uu. Alternatively, the remote WTRU may receive such an indication in PC5 from a relay WTRU.

[0216] If SI modification indication forwarding may be enabled / disabled in the relay, the remote WTRU may send a request to receive an SI modification indication / PWS indication from the relay WTRU. The conditions for sending such a request may relate to any of the conditions described herein for determining whether the SI request is sent over Uu or PC5, or the conditions under which SI should be received over Uu or PC5. For example, the remote WTRU may request to receive an SI modification indication / PWS indication from the relay WTRU when any or a combination of the following occurs: the measured RSRP on Uu is below a threshold, the measured SL RSRP is above a threshold, and the remote WTRU is within the coverage of the same cell as the cell to which the relay is connected / camped. Alternatively, the relay WTRU may be configured by the network whether to forward SI modifications to a remote WTRU (either a specific remote WTRU or all remote WTRUs) in either dedicated RRC signaling or SIB.

[0217] The systems and methods may operate on remote WTRU actions upon receiving an SI modification indication. Following receipt of the SI modification indication, the remote WTRU may perform any of the following: receive SIB1 from the network, request / receive SIB1 from the relay WTRU, possibly always receive SI over Uu starting at the next modification period, possibly always receive SI over SL starting at the next modification period, request SI from the relay WTRU, possibly decide whether to receive SI over SL or Uu based on decision criteria described herein, decide whether to receive SI over SL or Uu based on criteria described herein, receive SI over SL (or Uu), start receiving SL over Uu (or SL) upon failure of reception on SL (or Uu), and inform the relay WTRU whether to receive SI over SL.

[0218] To receive SIB1 from the network, for example, if the remote WTRU receives an SI modification from Uu, the remote WTRU may receive SIB1 from Uu. The remote WTRU may further determine what subsequent action to take based on the contents of SIB1 (e.g., the modified SIB and / or whether the modified SIB is broadcast).

[0219] When requesting / receiving SIB1 from the relay WTRU, e.g., when the remote WTRU receives an SI modification from Uu, the remote WTRU may request / receive SIB1 from the relay WTRU to determine which SI has changed. The remote WTRU may further determine which subsequent action to take based on the contents of SIB1 (e.g., the modified SIB and / or whether the modified SIB has been broadcast). The remote WTRU may always request SIB1 following receipt of an SI modification. Alternatively, the remote WTRU may assume that the relay WTRU automatically forwards SIB1 following an SI modification. The remote WTRU may wait for an updated SIB1 from the relay WTRU for a period of time and, if not received, may request SIB1 from the relay WTRU.

[0220] The remote WTRU may receive SI over Uu, possibly starting at the next modification period.

[0221] With respect to SI that is always received via SL, possibly starting at the next modification period, e.g., the remote WTRU may always receive / request SI via SL, and the remote WTRU may use Uu only for SI modification instruction reception (e.g., to know when it may start monitoring SL in case of operation such as SL DRX).

[0222] The remote WTRU may request the SI from the relay WTRU.

[0223] The remote WTRU may possibly decide whether to receive SI from SL or Uu based on decision criteria described herein.

[0224] The remote WTRU may determine whether to receive SI over SL or Uu based on the criteria described herein.

[0225] In the case of receiving SI over SL (or Uu) and initiating reception of SL over Uu (or SL) upon failure of reception on SL (or Uu), failure may include any of the following: expiration of a time period while waiting to receive the SI. Specifically, upon receiving an SI modification indication over Uu, the remote WTRU may start a timer and start monitoring SL for SI reception over the sidelink for a period of time. If SI is not received following expiration of the period, the WTRU may start monitoring Uu for updated SI (which may include performing an SI request). In another embodiment, upon receiving an SI change (possibly over Uu), the remote WTRU may start a timer and start monitoring SL for SI reception over the sidelink. If SI is not received before expiration of the time period, the WTRU requests the required SI over either SL or Uu (possibly based on the decision criteria herein).

[0226] To inform the relay WTRU whether or not to receive SI over SL, for example, the remote WTRU may decide to receive SI over Uu (after SI modification) and may indicate such to the relay WTRU, which may consequently avoid forwarding any SI to the remote WTRU as a result of the SI modification.

[0227] In an embodiment in which the remote WTRU determines whether to request SI from a relay following an SI modification, the remote WTRU (e.g., following receipt of an SI modification over Uu) may determine whether to perform a request for SI from the relay WTRU (or simply receive SI from the relay WTRU without a request) based on either or a combination of the type of SI, or the particular SI being modified, and whether the remote WTRU previously performed a request while SI transfer was enabled at the relay WTRU.

[0228] For a type of SI, or for a particular SI that has been changed, for example, the remote WTRU may request the SI from the relay WTRU following receipt of an SI modification instruction, but may not request any other SI following receipt of that instruction. For example, in the case of a PWS, the remote WTRU may not request SI and may wait to receive SI. For other SIBs, the remote WTRU may immediately request SI from the relay WTRU.

[0229] For example, the remote WTRU may send a message to the relay WTRU to enable / disable SI transfer, regarding whether the remote WTRU previously performed a request while SI transfer was enabled at the relay WTRU. Specifically, the remote WTRU may enable SI transfer when it is in RRC_IDLE / RRC_INACTIVE or when it moves out of coverage. The remote WTRU may disable SI transfer when it moves in coverage or when it transitions to RRC_CONNECTED. The remote WTRU may determine whether an SI request is needed from the relay WTRU following an SI modification based on whether the remote WTRU requested SI from the relay WTRU for SI that has been changed by the network since the last time SI transfer was enabled at the relay WTRU. Specifically, if a particular SI / SIB has been changed and that SI / SIB was requested from the relay since the last time SI transfer was enabled, the remote WTRU may not request SI after SI modification. The remote WTRU may wait for the SI to be forwarded by the relay WTRU (such behavior may further depend on the time period, as described herein). On the other hand, if a particular SI / SIB has changed and that SI / SIB has not been requested from the relay since SI forwarding was last enabled by the remote WTRU to the relay, the remote WTRU may immediately request the changed SI / SIB. The remote WTRU may determine which SI / SIBs need to be reacquired as a result of the received SI modification based on SIB1, which may be received from the relay WTRU or directly from Uu.

[0230] The present system and method handles the race condition between the SI modification indication and the updated SI. A relay WTRU in RRC_CONNECTED may receive the updated SI from the network in dedicated signaling and may forward the updated SI to the remote WTRU before the network signals the SI modification via paging. A remote WTRU that may receive the SI modification may unnecessarily trigger a procedure to obtain the same SI twice.

[0231] To handle race conditions between the SI modification indication and the updated SI, the remote WTRU may ignore the SI modification indication in some conditions. For example, the remote WTRU may ignore an SI modification indication received over Uu. Specifically, the WTRU may perform an SI acquisition procedure following receipt of an SI modification indication unless any of the following (or a combination of such) is met, including: the remote WTRU receives an updated SI from the relay WTRU, possibly within a certain period of time, the SI modification indication is for a PWS, and the remote WTRU does not receive an indication to ignore further SI changes.

[0232] For example, if the remote WTRU possibly receives an updated SI from the relay WTRU within a certain period of time, the remote WTRU may ignore any SI modification instructions and not perform any SI acquisition for a period T following receipt of the updated SI from the relay WTRU.

[0233] If the SI modification indication is for a PWS, for example, the remote WTRU may ignore the SI modification indication for a period of time following receipt of an updated SI from the relay, unless the SI modification is for a PWS. In the case of a PWS indication, the remote WTRU may perform SI acquisition following receipt of the SI modification indication if the remote WTRU has not yet received a PWS from the relay WTRU within that same time period.

[0234] If the remote WTRU does not receive an indication to ignore further SI modifications, for example, the remote WTRU may ignore the SI modification indication following receipt of the SI from the relay WTRU unless / unless the remote WTRU receives / receives an indication from the relay WTRU. Similarly, the relay WTRU may / may not send such an indication if it receives updated SI from the network in dedicated RRC signaling (otherwise the relay may / may not send such an indication). The relay WTRU may provide an indication along with the updated SI on the sidelink.

[0235] The remote WTRU may decide to request / receive SI over Uu. For example, the remote WTRU may ignore the SI modification indication following receipt of a paging if the remote WTRU requested / received SI from a relay WTRU (where such a decision may be based on conditions herein). In these cases, the remote WTRU may rely on the relay WTRU to obtain the modified SI.

[0236] The cells to which the remote WTRU and the relay WTRU are connected may be the same, and the PCell is the cell via the relayed path. For example, the remote WTRU may ignore the SI modification indication received via Uu if the cell IDs on the direct and indirect paths are different and the remote WTRU is assumed to receive SI via the indirect path. On the other hand, if the cell IDs are the same or the remote WTRU's PCell is assumed to be a direct path cell, the remote WTRU may initiate an SI request procedure or obtain new SI when the remote WTRU receives an SI modification.

[0237] This may further be conditional on the type of SI. Specifically, in the ETWS / CMAS case, the remote WTRU may receive the SI following receipt of an SI modification indication, regardless of whether the paths correspond to the same / different cells and which paths correspond to the PCell.

[0238] To address a race condition between the SI modification instruction and the updated SI, the relay WTRU may delay forwarding the SI to the remote WTRU. For example, the relay WTRU may delay forwarding an updated SI to the remote WTRU. The remote WTRU may determine the amount of delay and / or whether to delay the SI based on one or a combination of the following factors: how the relay WTRU obtained / received the SI from the network, the instruction / configuration from the network, the modification period of the SI, whether the SI being forwarded was originally broadcast by the network or whether an SI request was required, and the particular SI or SI type (e.g., whether a particular SIB or SI is a PWS, etc.).

[0239] The manner in which the relay WTRU acquired / received SI from the network (e.g., using dedicated signaling, SI request, using broadcast acquisition after receiving SI modification, using MSG1 or MSG3, etc.). For example, the relay WTRU may delay forwarding SI to the remote WTRU if SI was received from the network via dedicated signaling. Otherwise (i.e., the relay received SI following receipt of SI via broadcast signaling or following SI request to the network), the relay WTRU may not delay SI.

[0240] For example, based on instructions / configuration from the network, the relay WTRU may receive instructions in dedicated signaling (possibly with updated SI) to forward the SI to the remote WTRU at a later time. The relay WTRU may also receive directly from the network an amount of time to delay forwarding the SI.

[0241] During an SI modification period, for example, the relay WTRU may determine to delay forwarding any acquired SI from the network to the remote WTRU for a certain amount of time that is a function of the SI modification period of the received SI. For example, the relay WTRU may wait for at least one modification period. For example, the relay WTRU may wait until the time when the next modification period starts.

[0242] It may also include whether the SI being transferred was originally broadcast by the network or whether an SI request was required.

[0243] For a particular SI or SI type (e.g., whether a particular SIB or SI is a PWS), for example, the relay WTRU may determine to delay one SIB / SI and not delay another SIB / SI. Specifically, if a particular SI has been updated based on a modification period (e.g., non-PWS), the relay WTRU may delay the transmission of the SIB.

[0244] To handle race conditions between the SI modification indication and the updated SI, the relay WTRU may indicate to the remote WTRU when to acquire SI over Uu. In one embodiment, in addition to indicating that the remote WTRU may acquire modified SI over Uu, the relay WTRU may inform the remote WTRU when acquisition may begin. In one embodiment, the relay WTRU may indicate whether SI acquisition may begin immediately or at the next SI. For example, if the relay receives an SI modification indication indicating a PWS or another SI that is updated by the network immediately following an SI modification, the relay WTRU may indicate to the remote WTRU that it may acquire SI immediately. If the relay WTRU receives an SI modification indication for an SI that is updated based on a modification period, the relay WTRU may indicate to the remote WTRU to acquire SI at the next modification period. In another embodiment, the relay WTRU may provide an absolute / relative time at which the remote WTRU may acquire updated SI over Uu. For example, the relay WTRU may provide the remote WTRU with the timing of the start of the next modification period if updated SI is provided in the next modification period.

[0245] In another embodiment, the relay WTRU may provide an indication of the time when the network-initiated SI will be broadcast following an SI request by the relay WTRU. Specifically, a request by the remote WTRU to the relay WTRU may trigger an SI request by the relay WTRU to the network. The relay WTRU may inform the remote WTRU when the SI may be broadcast by the network. Specifically, the relay WTRU may wait until the SI request to the network is successful (the requested SI has been broadcast by the network) and send an acknowledgment to the remote WTRU that the SI has been broadcast. Alternatively, the relay WTRU may determine the expected time when it will send the SI request and may provide the remote WTRU with the expected time when the SI broadcast will start (immediately after the remote WTRU's SI request to the relay).

[0246] The remote WTRU may determine when to trigger SI acquisition on Uu according to the instructions received from the relay WTRU.

[0247] Although the features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. It should be noted that the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor in association with software may be used to establish a radio frequency transceiver for use in a UE, a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. 1. A method for a WTRU, comprising: receiving information, the information including a direct path quality threshold for sending a system information (SI) request via a direct path, a direct path quality threshold for receiving SI via the direct path, and an SI request configuration indicating configuration information for the SI request; measuring the quality of the direct path; based on the measured quality of the direct path being below the direct path quality threshold for sending an SI request via the direct path and the SI request configuration indicating a MSG3-based SI request; determining an indication based on whether the measured quality of the direct path is above or below the direct path quality threshold for receiving SI via the direct path; transmitting the SI request via a relay WTRU, the SI request including the indication; receiving SI via the relay WTRU or via the direct path in response to an indication from the relay WTRU; A method comprising:

2. The method of claim 1 , wherein the direct path quality threshold for sending a SI request via the direct path is greater than the direct path quality threshold for receiving SI via the direct path.

3. The method of claim 1 , wherein the direct path quality threshold for sending a SI request via the direct path is substantially equal to the direct path quality threshold for receiving SI via the direct path.

4. The method of claim 1 , wherein the SI request configuration indicating configuration information for the SI request includes MSG1-based messaging.

5. The method of claim 4 , wherein MSG1 includes a RACH in the UL.

6. The method of claim 1 , wherein the SI request configuration indicating configuration information for the SI request includes MSG3-based messaging.

7. The method of claim 6 , wherein MSG3 includes a RACH in an RRC.

8. 1. A method for a WTRU, comprising: receiving information, the information including a direct path quality threshold for sending a system information (SI) request via a direct path, a direct path quality threshold for receiving SI via the direct path, and an SI request configuration indicating configuration information for an SI request; measuring the quality of the direct path; based on the measured quality of the direct path being above the direct path quality threshold for sending an SI request via the direct path or the configuration information of the SI request indicating a MSG1-based SI request. sending the SI request via the direct path; receiving the requested SI via the direct path; A method comprising:

9. The method of claim 8 , wherein the direct path quality threshold for sending a SI request via the direct path is greater than the direct path quality threshold for receiving SI via the direct path.

10. The method of claim 8 , wherein the direct path quality threshold for sending a request for SI via the direct path is substantially equal to the direct path quality threshold for receiving SI via the direct path.

11. The method of claim 8 , wherein the SI request configuration indicating configuration information for the SI request includes MSG1-based messaging.

12. The method of claim 11 , wherein MSG1 includes a RACH in the UL.

13. The method of claim 8 , wherein the SI request configuration indicating configuration information for the SI request includes MSG3-based messaging.

14. The method of claim 13 , wherein MSG3 includes a RACH in an RRC.

15. 1. A WTRU for system information acquisition, comprising: a transceiver for transmitting and receiving signals; a processor operatively coupled to the transceiver; The processor and the transceiver receiving information, the information including a direct path quality threshold for sending a system information (SI) request via a direct path, a direct path quality threshold for receiving SI via the direct path, and an SI request configuration indicating configuration information for the SI request; measuring the quality of the direct path; based on the measured quality of the direct path being below the direct path quality threshold for sending an SI request via the direct path and the SI request configuration indicating a MSG3-based SI request; determining an indication based on whether the measured quality of the direct path is above or below the direct path quality threshold for receiving SI via the direct path; transmitting the SI request via a relay WTRU, the SI request including the indication; receiving SI via the relay WTRU or via the direct path in response to an indication from the relay WTRU; The WTRU operates to perform the following:

16. The WTRU of claim 15, wherein the direct path quality threshold for sending an SI request via the direct path is greater than the direct path quality threshold for receiving SI via the direct path.

17. The WTRU of claim 15, wherein the direct path quality threshold for sending an SI request via the direct path is substantially equal to the direct path quality threshold for receiving SI via the direct path.

18. The WTRU of claim 15, wherein the SI request configuration indicating configuration information for the SI request includes MSG1-based messaging, where MSG1 includes a RACH in an UL.

19. The WTRU of claim 15 , wherein the SI request configuration indicating configuration information for the SI request comprises MSG3-based messaging, wherein MSG3 comprises a RACH in an RRC.

20. 1. A WTRU for system information acquisition, comprising: a transceiver for transmitting and receiving signals; a processor operatively coupled to the transceiver; The processor and the transceiver receiving information, the information including a direct path quality threshold for sending a system information (SI) request via a direct path, a direct path quality threshold for receiving SI via the direct path, and an SI request configuration indicating configuration information for an SI request; measuring the quality of the direct path; based on the measured quality of the direct path being above the direct path quality threshold for sending an SI request via the direct path or the configuration information of the SI request indicating a MSG1-based SI request. sending the SI request via the direct path; receiving the requested SI via the direct path; The WTRU operates to perform the following:

Images