Method and apparatus for radio link failure and recovery in multi-path sidelink relays

Abstract

The present disclosure relates to methods and apparatus for radio link failure, radio link monitoring, and / or radio link recovery in multipath wireless communications. For example, a method implemented by a first WTRU includes receiving configuration information indicating a first radio link configuration and a second radio link configuration and a first threshold and a second threshold, where the first threshold is greater than the second threshold; determining that the uplink data is pending for transmission on a first transmission to the network entity via the second WTRU, wherein the first transmission is associated with the first communication link; determining a channel condition of a second transmission from the network entity, wherein the second transmission is associated with a second communication link; and performing a first radio link procedure using the first radio link configuration based on the measurement of the channel condition being greater than the second threshold and less than the first threshold.

Description

[0001] This is a divisional application. The parent application is entitled "Method and Apparatus for Radio Link Failure and Recovery in Multipath Side Link Relay", filed on August 2, 2023, with application number 202380063690.2.

[0002] Cross-references to related applications

[0003] This application claims priority and benefit to U.S. Provisional Application No. 63 / 394,783, filed August 3, 2022, and U.S. Provisional Application No. 63 / 421,856, filed November 2, 2022, both of which are incorporated herein by reference in their entirety as if fully set forth herein for all available purposes. Technical Field

[0004] This disclosure relates to wireless communications. For example, one or more embodiments disclosed herein relate to methods and apparatus for radio link failure, radio link monitoring, and / or radio link recovery in wireless transceiver units having dual network connectivity via a direct network connection (e.g., direct connection to a network entity) and / or via a relay wireless transceiver unit to the network. Summary of the Invention

[0005] One or more embodiments disclosed herein relate to methods and apparatus for radio link failure (RLF) and recovery in multipath wireless communication.

[0006] In one embodiment, a method for wireless communication implemented by a WTRU includes: receiving configuration information indicating 1) a first radio link configuration and a second radio link configuration and 2) a first threshold and a second threshold, wherein the first threshold is greater than the second threshold; determining that uplink data is pending for a first transmission to a network entity via a second WTRU, wherein the first transmission is associated with a first communication link; determining channel conditions for a second transmission from the network entity, wherein the second transmission is associated with a second communication link; and performing a first radio link procedure using the first radio link configuration based on a measurement of the channel conditions that is greater than the second threshold and less than the first threshold.

[0007] In one embodiment, a WTRU for wireless communication includes circuitry comprising a transmitter, a receiver, a processor, and a memory. The WTRU is configured to: receive configuration information indicating 1) a first radio link configuration and a second radio link configuration, and 2) a first threshold and a second threshold, wherein the first threshold is greater than the second threshold; determine uplink data pending transmission for a first transmission to a network entity via the second WTRU, wherein the first transmission is associated with a first communication link; determine channel conditions for a second transmission from the network entity, wherein the second transmission is associated with a second communication link; and perform a first radio link procedure using the first radio link configuration based on a measurement of the channel conditions that is greater than the second threshold and less than the first threshold. Attached Figure Description

[0008] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with the accompanying drawings. As with the detailed description, the figures in such drawings are exemplary. Therefore, the drawings and detailed description should not be considered limiting, and other equally valid examples are possible and contemplated. Furthermore, similar reference numerals ("ref.") in the drawings ("Figures") indicate similar elements, and wherein:

[0009] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed implementation schemes may be implemented;

[0010] Figure 1B This is an example of what can be achieved according to the implementation plan. Figure 1A A system diagram of an example wireless transceiver unit (WTRU) used in the illustrated communication system;

[0011] Figure 1C This illustrates that, according to one or more implementation schemes, it is possible to Figure 1A System diagrams of an example radio access network (RAN) and an example core network (CN) used in the illustrated communication system;

[0012] Figure 1D This illustrates that, according to one or more implementation schemes, it is possible to Figure 1A A system diagram of another example RAN and another example CN used in the illustrated communication system;

[0013] Figure 2 This is a diagram showing a protocol view of a split bearer in a dual-connectivity architecture;

[0014] Figure 3 This is a diagram illustrating the RLC configuration in dual-connection when data duplication is used;

[0015] Figure 4 This is a diagram illustrating the protocol stack of the user plane in an L2 U2N relay architecture;

[0016] Figure 5 This is a diagram illustrating the protocol stack of the control plane in an L2 U2N relay architecture;

[0017] Figure 6 This is a diagram illustrating a multipath model at the protocol stack level for WTRU in dual connectivity, where both connectivity paths lead to the same cell;

[0018] Figure 7 This is a diagram illustrating a multipath model at the protocol stack level for WTRUs in dual connectivity, where the two connectivity paths pass through different cells;

[0019] Figure 8 This is a flowchart illustrating RLM / RLF processing for a dual-connected WTRU according to one or more implementation schemes;

[0020] Figure 9 This is a flowchart illustrating radio link reconstruction for a dual-connectivity WTRU according to one or more implementation schemes;

[0021] Figure 10A This is a diagram illustrating an example of multipath wireless communication according to one or more embodiments; and

[0022] Figure 10B This is a flowchart illustrating an example process for RLM and / or RLF detection in multipath communication according to one or more implementations. Detailed Implementation

[0023] introduction

[0024] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively, the “Provided”).

[0025] While this document describes and / or claims various embodiments in which apparatuses, systems, devices, etc. and / or any elements thereof perform operations, processes, algorithms, functions, etc. and / or any part thereof, it should be understood that any embodiment described herein and / or protected by the claims assumes that any apparatuses, systems, devices, etc. and / or any elements thereof are configured to perform any operations, processes, algorithms, functions, etc. and / or any part thereof.

[0026] Example Communication System

[0027] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. Compared to... Figures 1A to 1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network may utilize, perform, be arranged according to, and / or be adapted to and / or configured with respect to the methods, apparatuses and systems provided herein.

[0028] Figure 1A This is a diagram illustrating an example communication system 100 that may implement one or more of the disclosed embodiments. Communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, and Filter Bank Multicarrier (FBMC), etc.

[0029] like Figure 1AAs shown, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, UEs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive radio signals and may include user equipment (WTRU), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as UEs.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0043] 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) circuit, any other type of integrated circuit (IC), and a state machine, etc. Processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0050] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functionality, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0051] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for either uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0052] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

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

[0054] Each of the evolved Nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, evolution nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

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

[0056] MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c. MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0057] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during handover between evolved Nodes B, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0058] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

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

[0060] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0061] In a representative implementation, the other network 112 may be a WLAN.

[0062] A WLAN in Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with that AP. The AP may have an access or interface leading to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be transmitted to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP, for example, where a source STA can transmit traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be transmitted between a source STA and a destination STA (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs within a STA) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

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

[0064] High-throughput (HT) STAs can communicate using a 40MHz wide channel (e.g., via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels) to form a 40MHz wide channel.

[0065] Very High Throughput (VHT) STAs support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be processed by a segment parser that can split the data into two streams. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped to two 80MHz channels, and the data can be transmitted via a transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be transmitted to Media Access Control (MAC).

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

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

[0068] In the United States, the available frequency band for 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 available bandwidth for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0069] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to the implementation scheme. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0070] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while maintaining consistency with the implementation. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In another implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In implementations, gNBs 180a, 180b, and 180c may implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

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

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

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

[0075] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra-Reliable Low Latency (URLLC) access, services relying on Enhanced Mobile Broadband (eMBB) access, and / or services for Machine Type Communication (MTC) access. AMF a82a and 182b can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies, such as WiFi.

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

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

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

[0079] Given Figures 1A to 1D as well as Figures 1A to 1D The functions described herein with respect to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b, and / or any other devices described herein. An emulation device can be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0081] One or more emulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0082] Dual connection

[0083] Split Bearing in Dual Connection

[0084] In Dual Connectivity (DC), the WTRU is served by two nodes, each comprising a group of cells referred to as the Primary Cell Group (MCG) and the Secondary Cell Group (SCG). Bearers can be associated with either the MCG or the SCG, or they can be configured as split bearers. Figure 2 The protocol view of the split bearer is shown, where gNB 1 is in the MCG and gNB 2 is in the SCG.

[0085] As with any bearer, the WTRU will have an associated Packet Data Convergence Protocol (PDCP) entity, and the peer PDCP entity on the network side terminates at one of the gNBs (primary or secondary gNB). In the downlink (DL), the core network (CN) transmits data to the gNB where the PDCP terminates (as described above). Figure 2 In gNB1), the network decides whether to transmit data directly to WTRU via the link between gNB and WTRU, or to forward PDCP PDUs to gNB2 (e.g., via the Xn interface), and gNB2 will transmit data to WTRU via its own link with WTRU.

[0086] In the uplink (UL), the WTRU is configured with the path to the MCG as the primary path and the path to the SGC as the secondary path. A threshold known as the UL split buffer threshold is also configured. If the UL buffer size of the bearer is less than this threshold, the PDCP will only push data to the Radio Link Control (RLC) associated with the primary path. However, if the buffer size becomes greater than the threshold, the WTRU can push data to either path (i.e., it's left to the WTRU's specific implementation).

[0087] Grouping Repeat

[0088] Data duplication is a technique used in fifth-generation cellular systems for ultra-reliable low-latency communication (URLLC). Data duplication requires the use of multiple radio links, each transmitting the same data between the terminal and the network to improve transmission reliability.

[0089] When configuring repetition for a radio bearer via RRC, at least one secondary RLC entity is added to the radio bearer to handle repetitive PDCP packet data units (PDUs), such as... Figure 3 As described, the logical channel (LCH) corresponding to the primary RLC entity is called the primary logical channel, and the logical channel corresponding to the secondary RLC entity is called the secondary logical channel. All RLC entities involved in the repetition have the same RLC pattern. Therefore, repetition in PDCP involves submitting the same PDCP PDU multiple times: once to each active RLC entity of the radio bearer. PDCP control PDUs may not be repeated and can always be submitted to the primary RLC entity. Utilizing multiple independent transmission paths, packet repetition thus increases reliability and reduces latency, and is particularly beneficial for URLLC services.

[0090] When configuring repeating for a Data Radio Bearer (DRB), Radio Resource Control (RRC) also sets the PDCP repeating state (activated or deactivated) during (re)configuration. After configuration, the PDCP repeating state can then be dynamically controlled by means of a Media Access Control (MAC) control element (CE), and in the DC, the WTRU applies MAC CE commands regardless of their source (MCG or SCG).

[0091] When repeat is configured for a Signaling Radio Bearer (SRB), the PDCP repeat state is always active and is not dynamically controlled. When repeat is configured for a DRB with more than one secondary RLC entity, the RRC also sets the state (i.e., active or deactivated) of each of these secondary RLC entities. Subsequently, the MAC CE can be used to dynamically control whether the secondary RLC entities for each DRB configuration should be active or deactivated (i.e., which RLC entities are applied to repeat transmission). The primary RLC entity cannot be deactivated. When the DRB deactivates repeat for a DRB, all secondary RLC entities associated with that DRB are deactivated. When a secondary RLC entity is deactivated, it is not rebuilt, the HARQ buffer is not flushed, and the transmitting PDCP entity should instruct the secondary RLC entities to discard all repeated PDCP PDUs.

[0092] When DRB activation duplicates, the network ensures that at least one serving cell is activated for each logical channel associated with the activated RLC entity of the DRB; and when SCell deactivation does not leave a serving cell activated for the logical channel of the DRB, the network should also ensure that DRB activation duplicates are deactivated for the RLC entity associated with the logical channel.

[0093] When repetition is activated, the original PDCP PDU and the corresponding repetition should not be transmitted on the same carrier. Logical channels with repetition configured for radio bearers may belong to the same MAC entity (referred to as CA repetition) or to different MAC entities (referred to as DC repetition).

[0094] When repetition is configured on more than two RLC entities for radio bearers, CA repetition can also be configured together with DC repetition in either or both of the MAC entities. In CA repetition, logical channel mapping constraints are used in the MAC entity to ensure that different logical channels of the radio bearers in the MAC entity are not transmitted on the same carrier. When CA repetition is configured for an SRB, one of the logical channels associated with the SRB is mapped to the SpCell.

[0095] When deactivating CA repetition for DRB in MAC entity (i.e., none or only one of the RLC entities of DRB in MAC entity remains active), the logical channel mapping restriction of the logical channel of DRB is lifted as long as CA repetition is deactivated for DRB in MAC entity.

[0096] When an RLC entity acknowledges the transmission of a PDCP PDU, the PDCP entity should instruct other RLC entities to discard the PDCP PDU. Furthermore, in the case of CA duplication, when an RLC entity limited to a SCell reaches the maximum number of retransmissions of a PDCP PDU, the WTRU notifies the gNB but does not trigger a radio link failure (RLF).

[0097] RLF and recovery in Uu

[0098] RLF is monitored by the WTRU on the PCell within a single connection. An RLF is triggered when the T310 timer (started after multiple consecutive asynchronous indications from lower layers) expires. Upon detecting an RLF, the WTRU triggers a rebuild. If the WTRU is configured with a Conditional Handover (CHO) and the cell selection performed after the RLF results in a CHO candidate, the WTRU performs a CHO to the candidate cell instead of the previous cell.

[0099] For the WTRU in the DC, the WTRU performs radio link monitoring / radio link failure (RLM / RLF) on the PCell of the MCG and the PSCell of the SCG. RLF is declared for the MCG and SCG respectively.

[0100] If an RLF is detected for the MCG and Fast MCG Link Recovery is configured, the WTRU triggers Fast MCG Link Recovery. Otherwise, the WTRU performs the RRC connection reconstruction procedure. During Fast MCG Link Recovery, the WTRU suspends MCG transmission for all radio bearers and reports the fault to the master node (MN) via an MCG fault information message using the SCG tributary split from SRB1 or SRB3.

[0101] The WTRU includes available measurements in the MCG fault information message based on the current measurement configuration of both the MN (i.e., the node gNB associated with the MCG) and the secondary node (SN) (the node associated with the SCG). Once a fast MCG link recovery is triggered, the WTRU maintains the current measurement configuration from both the MN and SN, and continues measurements based on the configuration from the MN and SN, if possible. If the WTRU does not receive an RRC reconfiguration message, a MobilityFromNRCommand message, a MobilityFromEUTRACommand message, or an RRC release message within a specific time period after initiating a fast MCG link recovery, the WTRU initiates an RRC connection reconstruction procedure.

[0102] Upon receiving an RRC reconfiguration message, a MobilityFromNRCommand message, or a MobilityFromEUTRACommand message, the WTRU resumes MCG transmission for all radio bearers. Upon receiving an RRC release message, the WTRU releases all radio bearers and configurations.

[0103] When an SCG failure occurs, if MCG transmission for a radio bearer is not suspended, the WTRU suspends SCG transmission for all radio bearers and reports the SCG failure information to the MN, instead of triggering a re-establishment. If an SCG failure is detected while MCG transmission for all radio bearers is suspended, the WTRU initiates an RRC connection re-establishment procedure.

[0104] In all SCG failure scenarios, WTRU maintains the current measurement configuration from both MN and SN, and, where possible, continues measurements based on the configuration from MN and SN.

[0105] The WTRU includes the measurement results available based on the current measurement configuration of both MN and SN in the SCG fault information message.

[0106] In the implementation schemes discussed above and below, reconstruction consists of the process by which WTRU 1) performs cell selection and / or sends a reconstruction request RRC message during cell selection.

[0107] Relay in wireless communication networks

[0108] 3GPP Release 17 has specified SL-based UE-to-network relay. It introduces sidelink relay to support 5G ProSe UE-to-network relay (U2N relay) functionality, providing network connectivity for U2N remote WTRUs. Both L2 and L3 U2N relay architectures are supported. Except for controlling sidelink resources, the L3 U2N relay architecture is transparent to the serving RAN of the U2N relay WTRU.

[0109] U2N relay WTRUs should be in the RRC_CONNECTED state to perform unicast data relay.

[0110] For L2 U2N trunk operations, the following RRC state combinations are supported: 1) Both the U2N trunk WTRU and the U2N remote WTRU will be in the RRC CONNECTED state to perform unicast data transmission / reception for the trunk; and 2) The U2N trunk WTRU can be in the RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state as long as all U2N remote WTRUs connected to the U2N trunk WTRU are in the RRC_INACTIVE or RRC_IDLE state. For L2U2N trunks, the U2N remote WTRU can be configured only to use resource allocation mode 2 for the data to be trunked.

[0111] A single unicast link is established between an L2 U2N relay WTRU and an L2 U2N remote WTRU. Traffic to the U2N remote WTRU via a given U2N relay WTRU and traffic to the U2N relay WTRU should be separated in different Uu RLC channels on Uu.

[0112] L2 U2N relay protocol architecture

[0113] The protocol stacks for the user plane and control plane of the L2 U2N relay architecture are respectively located in... Figure 4 and Figure 5 Presented in the diagram. At both the PC5 and Uu interfaces, the Side Link Trunk Adaptation Protocol (SRAP) sublayer is placed above the RLC sublayer used for both the control plane (CP) and user plane (UP). The Uu Service Data Adaptation Protocol (SDAP), PDCP, and RRC terminate between the L2 U2N remote WTRU and the gNB, while SRAP, RLC, MAC, and PHY (physical) terminate at each hop (i.e., the link between the L2 U2N remote WTRU and the L2 U2N trunk WTRU, and the link between the L2 U2N trunk WTRU and the gNB).

[0114] For L2 U2N trunks, the SRAP sublayer on the PC5 hop is used solely for bearer mapping purposes. For relaying L2 U2N remote WTRU messages on the Broadcast Control Channel (BCCH) and / or Paging Control Channel (PCCH), the SRAP sublayer does not exist on the PC5 hop. For L2U2N remote WTRU messages on SRB0, the SRAP sublayer does not exist on the PC5 hop, but it does exist on the Uu hop used for both DL and UL.

[0115] For L2 U2N trunks, specifically for the uplink:

[0116] The Uu SRAP sublayer supports UL bearer mapping between the ingress PC5 trunk RLC channel and the egress Uu trunk RLC channel used for trunking via the L2 U2N trunk WTRU Uu interface. For uplink trunk traffic, different end-to-end RBs (SRBs or DRBs) of the same remote WTRU and / or different remote WTRUs can be multiplexed on the same Uu trunk RLC channel;

[0117] The Uu SRAP sublayer supports L2 U2N remote WTRU identification for UL traffic. Identification information for the L2U2N remote WTRU Uu radio bearer and the local remote WTRU ID are included in the Uu SRAP header at the UL so that the gNB can associate received packets with the specific PDCP entity associated with the correct remote WTRU Uu radio bearer.

[0118] - The PC5 SRAP sublayer at the L2 U2N remote WTRU supports UL bearer mapping between the remote WTRU Uu radio bearer and the outgoing PC5 relay RLC channel.

[0119] For L2 U2N relays, specifically for the downlink:

[0120] The Uu SRAP sublayer supports DL bearer mapping at the gNB to map end-to-end radio bearers (SRBs, DRBs) of remote WTRUs to a Uu relay RLC channel via the relay WTRU Uu interface. The Uu SRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of L2 U2N remote WTRUs and / or different L2 U2N remote WTRUs and a single Uu relay RLC channel via the relay WTRU Uu interface.

[0121] The Uu SRAP sublayer supports remote WTRU identification for DL ​​traffic. The identification information of the remote WTRU Uu radio bearer and the local remote WTRU ID are included in the Uu SRAP header by the gNB at the DL so that the relay WTRU can map packets received from the remote WTRU Uu radio bearer to its associated PC5 relay RLC channel;

[0122] - The PC5 SRAP sublayer at the relay WTRU supports DL bearer mapping between the ingress Uu relay RLC channel and the egress PC5 relay RLC channel;

[0123] - At the remote WTRU, the PC5 SRAP sublayer associates received packets with the specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU based on the identification information included in the Uu SRAP header.

[0124] The local remote WTRU ID is included in both the PC5 SRAP header and the Uu SRAP header. The L2U2N trunk WTRU is configured by the gNB to use the local remote WTRU ID in the SRAP header. The remote WTRU obtains its local remote ID from the gNB via a Uu RRC message that includes RRCSetup, RRCReconfiguration, RRCResume, and RRCReestablishment. In both PC5 and Uu hops, the Uu DRB and Uu SRB are mapped to different PC5 trunk RLC channels and Uu trunk RLC channels.

[0125] The gNB is responsible for avoiding conflicts in the use of local and remote WTRU IDs. The gNB can update the local and remote WTRU ID by sending the updated local and remote ID to the relay WTRU via an RRCReconfiguration message. The serving gNB can perform local and remote WTRU ID updates independently of the PC5 unicast link L2 ID update process.

[0126] Scheduling in side links

[0127] The side link supports two scheduling modes: Mode 1 and Mode 2. For WTRUs within the coverage area, the gNB can control whether the WTRU uses Mode 1 or Mode 2 for transmission.

[0128] In Mode 1 scheduling, which is available to a sidelink WTRU in the RRC_CONNECTED state, the WTRU receives SL grants directly from the network in the Downlink Control Information (DCI). In this case, the WTRU reports the buffer status of SL data grouped by destination index (where the destination index corresponds to a unique L2 destination ID, or a source / destination L2 ID pair). If the SL grant is not available for the transmission of pending data, the WTRU may send an SL scheduling request (SR).

[0129] In Mode 2 scheduling, which can be used by a WTRU in any RRC state or when the WTRU is outside coverage, the WTRU is configured with a resource pool from which it performs autonomous resource selection and scheduling. Resources are selected by the WTRU based on information (i.e., sensing results) sent in previous Side Link Control Information (SCI) messages from other WTRUs.

[0130] Multipath operation

[0131] Version 17 of the 3GPPP specification introduced Layer 2 WTRUs into network relays. The primary use case considered was when the remote WTRU was outside the coverage area. However, in version 18, a multipath specification was expected. In multipath, it is assumed that the remote WTRU is within the coverage area, and therefore the remote WTRU can utilize the Uu path, the SL (relay) path, or both. The multipath operation of Rel18 is described as follows [2]:

[0132] Research the benefits and potential solutions of multipath support to enhance reliability and throughput in scenarios [RAN2, RAN3] (e.g., by simultaneously switching or utilizing multiple paths):

[0133] A.WTRU uses a direct path and an indirect path to the network relay via 1) Layer 2 WTRU or 2) via another WTRU (where it is assumed that WTRU-WTRU interconnection is ideal) to connect to the same gNB, where the solution of 1) will be reused for 2), without excluding the possibility of excluding the partial solution that is unnecessary for the operation of 2).

[0134] In multipath operation, the direct link between the remote WTRU and the gNB, as well as the backhaul link between the relay WTRU and the gNB, can be served by the same gNB, or even by the same cell of the same gNB. Furthermore, if Mode 1 is selected for scheduling the SL between the remote WTRU and the relay WTRU, the scheduling of all links (e.g., Uu between the remote WTRU and the gNB, backhaul Uu between the relay WTRU and the gNB, and SL between the remote WTRU and the relay WTRU) is performed by the gNB. Even when using Mode 2 and the gNB pre-configures resource pools for SLs that the remote WTRU can use autonomously, the gNB is still the gNB that determines the resource pool configuration and therefore has control over scheduling on the SLs (even if it is not as real-time as in Mode 1).

[0135] From a protocol architecture perspective, multipath can be modeled similarly to DC (Distributed Carrier Aggregation) because different MAC entities are used for the Uu link and SL, and the same PDCP entity is configured for a given bearer using multipath (e.g., split bearer). However, if the same gNB is serving cells for both Uu and SL, this can be considered similar to the case of CA (Carrier Aggregation). However, in CA, a single MAC entity is utilized, but this is not the case in reality. Even more complexly, Uu and SL can be served by the same cell of a given gNB (i.e., not even CA).

[0136] Figure 6 and Figure 7 An example of how to model multipath at the protocol level is shown. Figure 6 This illustrates multipathing within the same cell, while Figure 7 An example of multipathing to two different cells is shown.

[0137] RLF Faults and Recovery in Multipath Side Links

[0138] Multipathing can involve the same scheduler controlling the Uu and SL paths of a remote WTRU. As a result, bearers (including SRBs) can be configured to use either path. Unlike DC, for multipathing, there is no concept of a master node, and both paths terminate at the same node in the network. Consequently, simultaneously monitoring the radio links on both paths at the remote WTRU may be unnecessary and could lead to unnecessary power consumption. The link that the WTRU should monitor for RLF should also be synchronized with the link available in the network for transmitting RRC signaling. However, the RLM / RLF mechanism to be used may depend on whether multipathing is used to ensure reliability (i.e., both paths are important) or to maintain coverage (i.e., the ability to maintain connectivity via only a single path is required).

[0139] In multipath scenarios where one path is relayed via an SL, Regression Default (RLF) detection is performed based on HARQ feedback instead of normal Regression LM. This mechanism for RLF detection may be unreliable, especially when the amount of data transmitted via the SL path is limited.

[0140] Finally, assuming there is no master node, recovery operations for multipath may also depend on the factors mentioned above and need to be defined for multipath in a different way for DC.

[0141] Multipath communication

[0142] In the implementation discussed herein, a remote WTRU in multipath refers to a WTRU connected to the network via two different paths (a direct Uu path and a path via the SL WTRU to the network relay). The connection via the two paths can lead to the same gNB / scheduler (i.e., the remote WTRU and the relay WTRU are controlled by the same gNB) or to different gNBs / schedulers (i.e., the remote WTRU and the relay WTRU are controlled by different gNBs). However, the implementation discussed herein is equally applicable to multiple paths (more than one path), or to situations where two or more paths via the SL WTRU to the network relay WTRU are maintained by the remote WTRU.

[0143] The WTRU identifies representative processes of inter-gNB changes performed by the relay WTRU.

[0144] Methods for determining whether cells belong to the same / different gNBs

[0145] The implementation scheme described herein for RLM / RLF may depend on the WTRU's knowledge of whether the two cells (e.g., the cell associated with a direct path and the cell associated with an indirect / relay path) belong to the same gNB or different gNBs. Depending on whether the cells are associated with the same gNB or different gNBs, the remote WTRU may perform different procedures as described herein. This information can be determined using any of the following solutions:

[0146] -List of residential communities:

[0147] For example, the network can provide a list of cells associated with a specific cell (e.g., a cell on a direct path). If another cell is in this list, the remote WTRU determines that the cell is part of the same gNB as the specific cell.

[0148] -Identifier broadcast / transmitted by the community

[0149] For example, a cell may send (e.g., in a System Information Block (SIB) or via dedicated RRC signaling) an identifier to determine whether two different cells are associated with the same gNB. For instance, if cells send the same identifier, the WTRU may assume they are part of the same gNB.

[0150] - Explicitly as part of a network-initiated process (e.g., handover (HO), reconfiguration, etc.).

[0151] For example, a remote WTRU can be connected via a multipath method through a direct link to cell 1 and an indirect link via a relay connected to cell 2. Cell 1 and cell 2 may belong to the same gNB. The relay WTRU can receive HO commands from the network and can notify the remote WTRU of these commands. Upon receiving the HO command, the remote WTRU may need to determine whether the target cell (cell 3) is part of the same gNB. This can be directly indicated by the network using markers or indications in the HO command itself. Specifically:

[0152] ■ The relay WTRU can receive an indication in the HO command that will be forwarded to the remote WTRU in a notification message. Specifically, if the indication is transmitted (e.g., a flag is set to true), such a HO can represent an inter-gNB HO at the relay WTRU.

[0153] • Relay WTRUs can include indications or tags in notification messages to remote WTRUs.

[0154] • Remote WTRU

[0155] ● Upon receiving a HO notification indicating that the source cell and target cell are associated with different gNBs, the procedure for associating HOs between gNBs can be performed (as described in this document).

[0156] ● When a HO notification is received that does not indicate whether the source cell and target cell are associated with different gNBs, the procedure associated with the HO within the gNB (as described herein) can be performed (i.e., the indirect path and the direct path are associated with the same gNB).

[0157] Representative processes of RLM / RLF in multipath

[0158] In multipathing, the remote WTRU determines the path on which to monitor RLM / RLF.

[0159] In one solution, the remote WTRU may determine on which path to execute the RLM / RLF based on one or more of the following factors, or any combination thereof. Although not explicitly mentioned in the examples below, similar factors can be used to determine the attributes of the executed RLM / RLF, which may include the configuration used (e.g., whether a first set of parameters, timers, constants, etc., associated with the RLM / RLF determination, a second set of parameters) and / or strength (using normal RLM or loose RLM) and / or other aspects of the RLM / RLF. Furthermore, the remote WTRU may determine whether / how to execute the RLM / RLF on a path (e.g., directly or indirectly) based on conditions associated with another path (indirectly or directly), where such conditions are described in the following factors. When determining whether / how to execute the Uu RLM / RLF and / or whether / how to execute the SL RLF, a combination of the following factors may be considered. In some implementations, a first condition may be used to determine a second condition to be used in the determination. Specifically, these factors may include:

[0160] - Measurement of Uu path quality:

[0161] For example, if the RSRP measured on the Uu path is below a threshold, the WTRU can perform RLM / RLF on the Uu path, and if the RSRP measured on the Uu path is above the threshold, the WTRU can stop performing RLM / RLF on the Uu path. The motivation for this approach is that if the WTRU can assume the existence of a reliable SL path, then when the Uu link has good path quality, the WTRU can assume that RLM / RLF on the Uu path is unnecessary.

[0162] ■ For example, (1) if the RSRP measured on the Uu path is below the first threshold, the WTRU may perform RLM / RLF on the Uu path; (2) if the RSRP measured on the Uu path is between the first and second thresholds, the WTRU may perform a relaxed RLM / RLF on the Uu path; and (3) if the RSRP measured on the Uu path is above the second threshold, the WTRU may not perform any RLM / RLF.

[0163] For example, if the RSRP measured on the Uu path is higher than a threshold, the WTRU can perform RLM / RLF on the Uu path, and the WTRU can only perform RLF on the relay path if the RSRP measured on the Uu path is lower than a threshold. These two thresholds can be the same or different. The motivation for this approach is that for large Uu RSRPs, the network can send RRC signaling on the Uu path, and the WTRU should only monitor RLF based on the Uu path.

[0164] -SL path quality measurement

[0165] For example, if the SL quality (e.g., SL RSRP) is above / below a threshold, WTRU can perform RLM / RLF on the Uu path.

[0166] For example, a combination of Uu and SL quality criteria could be considered to determine on which link RLF should be implemented. For example:

[0167] ● If both the SL RSRP and Uu RSRP are above a threshold, the WTRU may perform RLF only on the SL path. If either the SL RSRP or Uu RSRP is below a threshold, the WTRU may perform RLF on the Uu path, and whether RLF is measured on the SL may depend on other factors discussed herein. The advantage of this approach is that the WTRU can disable Uu RLM monitoring if it ensures that it has a sufficiently good SL link as a backup.

[0168] ● If the SL RSRP is higher than the first threshold and the Uu RSRP is higher than the second threshold, the WTRU may perform an RLF on either the SL path or the Uu path (as determined by the WTRU or configured by the network). Otherwise, the WTRU may perform an RLF on both paths.

[0169] ● If SL RSRP is below the first threshold and Uu RSRP is below the second threshold, the WTRU may perform RLF on both paths. Otherwise, the WTRU may perform RLF on one link (determined by the WTRU or configured by the network).

[0170] -SL-specific measurements, such as CBR

[0171] For example, if the SL channel busy ratio (CBR) is higher than a threshold, the WTRU can perform RLM / RLF on the Uu path. The advantage of this approach is that Uu RLM is maintained even when there is congestion on the SL, regardless of whether Uu RSRP is good.

[0172] - The presence or amount of UL data transmitted in the SL path or Uu path.

[0173] This can be measured based on the amount of data routed by the Packet Data Protocol (PDP), the amount of data in the WTRU's SL RLC buffer, or the channel occupancy (CR) measured on the side link.

[0174] For example, if the SL CR is higher than a threshold, the WTRU can perform RLM / RLF on the Uu path. The advantage of this approach is that the WTRU can ensure that enough data is transmitted by the WTRU via the SL path to ensure a reliable HARQ-based RLF mechanism for monitoring multipath links.

[0175] For example, if the WTRU has data for an SL logical channel with HARQ feedback enabled, the WTRU can perform RLM / RLF on the Uu path.

[0176] - Message received from relay WTRU

[0177] In one implementation, a remote WTRU can modify its RLM / RLF behavior based on receiving a Uu RLF indication from a relay WTRU. Specifically, if a remote WTRU does not monitor an RLM / RLF on the Uu path at a given time and receives a Uu RLM / RLF indication from a relay WTRU, the remote WTRU can notify the network of this situation via Uu, and then initiate / recover an RLM / RLF on the Uu path. The WTRU can continue to perform an RLM / RLF on the Uu path until it is reconfigured with a new relay WTRU, or until an indication (from the network or the relay WTRU) that the Uu link at the relay WTRU has been restored.

[0178] In one implementation, a remote \TRU can modify its RLM / RLF behavior based on a flow control message received from a trunk WTRU. Specifically, the remote WTRU can receive a flow control instruction from the trunk. If the flow control message indicates that the remote WTRU should reduce the data rate via the trunk WTRU, the remote WTRU can perform RLM / RLF via the Uu path. Otherwise, the remote WTRU can perform a lenient RLM / RLF or not perform RLM / RLF at all via the Uu path.

[0179] - QoS / bearer configuration at the remote WTRU

[0180] For example, the conditions for using the SL path for RLF can be further conditional on the WTRU being configured with at least one SL LCH and configured HARQ feedback.

[0181] For example, the use of an SL path for an RLF can be further conditional upon the WTRU being configured with at least one SL RLC channel configured with RLC Acknowledgment Mode (AM).

[0182] For example, the WTRU may be permitted to use the first condition discussed herein to determine the RLF behavior of some QoS flows / bearers, and the second condition discussed herein to determine the RLF behavior of other QoS flows / bearers. For example, some QoS flows / bearers may always require the WTRU to monitor RLM / RLF on the Uu path when they are established and / or when they have available data.

[0183] For example, a remote WTRU can perform RLM / RLF on Uu based on the presence / number of SL LCHs configured with HARQ feedback enabled and / or the amount of data for transmission present in the buffers of such HARQ-enabled LCHs. For example, if all SL LCHs are configured without HARQ feedback enabled, the remote WTRU can monitor Uu RLM / RLF. For example, if the number of SL LCHs configured with HARQ feedback enabled is higher than a threshold, the remote WTRU can monitor Uu RLM / RLF. For example, if the amount of data buffered at a WTRU SL LCH with HARQ feedback enabled is lower than a threshold, the remote WTRU can monitor Uu RLM / RLF. For example, when the cells associated with direct and indirect links are the same and / or the WTRU is configured with a split SRB, the WTRU can use the above determinations to decide whether to monitor Uu RLM / RLF.

[0184] For example, when the number of SL LCHs configured with HARQ feedback enabled and / or the amount of data available for transmission in the buffers of such HARQ-enabled LCHs exceeds a threshold, the remote WTRU can perform a loose RLM / RLF on the Uu. The WTRU can also determine the loosening parameters associated with the loose RLM / RLF based on conditions such as the percentage of reference signals to be monitored, the value of the timer / counter associated with the RLM / RLF, etc.

[0185] - Are the relay station and remote WTRU controlled by the same / different cell / dispatchman / gNB?

[0186] For example, WTRU can use the first rule or condition discussed in this paper in the case of the same cell, and use different rules or conditions in the case of multiple cells.

[0187] For example, a WTRU can always perform RLF on both paths in different cell scenarios, but other conditions discussed in this paper can be used to determine whether to perform RLF on both paths in the same cell scenario.

[0188] - Path configuration for SRB in multipath

[0189] For example, the WTRU can perform RLM / RLF on the Uu path, or if the SRB is configured to be transmitted only on the Uu path, the WTRU has rules that favor RLM / RLF detection on the Uu path; or if the SRB is transmitted only on the SL path, the WTRU has rules that favor RLF detection on the SL path; or if the SRB can be transmitted on both paths, the WTRU has rules that allow it to flexibly determine the path based on the RSRP (as discussed herein).

[0190] - Duplicate configuration of SRB in multipath

[0191] For example, if the SRB is configured to repeat, the WTRU can perform RLF on both the Uu link and the SL link.

[0192] - RRC status of relay WTRU

[0193] For example, the WTRU can be in a multipath state, where the relay WTRU is idle and inactive. In this case, all UL / DL data is routed via Uu. In this scenario, the remote WTRU can always monitor the RLM / RLF via Uu. When the relay WTRU is connected, the remote WTRU can use other rules to determine RLM / RLF monitoring.

[0194] - Does the path correspond to a direct path or an indirect path?

[0195] For example, WTRU can use a first rule (as described in this paper) to determine whether to monitor RLF on the direct path and a second rule (as described in this paper) to determine whether to monitor RLF on the indirect path.

[0196] For example, WTRU can always monitor RLF on the indirect path, and can determine whether to monitor RLF on the direct path based on another rule in this paper.

[0197] - Is the indirect path associated with a 3GPP link (e.g., PC5) or with a non-3GPP link?

[0198] For example, if the indirect path is associated with a 3GPP link (i.e., PC5), the remote WTRU may perform Uu RLM / RLF (or vice versa, i.e., the remote WTRU will perform SL RLM / RLF). Alternatively, if the indirect path is associated with a non-3GPP link, the remote WTRU may not perform Uu RLM / RLF (or vice versa, i.e., the remote WTRU will perform SL RLM / RLF). Alternatively, when the indirect path is associated with a 3GPP link, the remote WTRU may perform a relaxed RLM / RLF on Uu.

[0199] When a link declares an RLF and / or recovers from a failure, the remote WTRU can initiate an RLM / on another link. RLF process

[0200] In one implementation, when a link declares a failure, the remote WTRU can initiate RLM / RLF on another link. Such a failure could be an RLF on that link, a failure to rebuild that link, the transmission of a failure RRC message (e.g., a message similar to SCGFailure or MCGFailure), or any failure associated with the same conditions used to trigger an RLF (e.g., reaching a specific number of consecutive HARQ DTXs on the link). For example, the remote WTRU can be configured to monitor RLFs on both SL and Uu, but at a given time, it can only monitor SL-based RLFs. If the remote WTRU detects an RLF on SL, it can initiate RLM / RLF monitoring on Uu. The remote WTRU can also use such operations only under the condition that such operations are configured for a specific network architecture and / or bearer architecture. Specifically, such operations may be useful when the network is transmitting RRC signaling on one path, and due to an RLF on that path, it is expected that the path used for RRC signaling will be switched to another path. For example, if any one or more of the following conditions apply, WTRU can initiate an RLF on another path after an RLF is detected on one path:

[0201] - Conditions associated with the configuration of one or more bearers (SRBs or DRBs). For example, this behavior can be applied when there are no duplicate split SRBs configured. Specifically, when a split SRB is configured to have duplicates, the WTRU can perform RLM / RLF on both paths. When an SRB is configured on only a single path, the WTRU can perform RLM / RLF only on that path and initiate a rebuild when an RLF is triggered.

[0202] - Conditions associated with the relationship between cells on the direct and indirect paths (e.g., identical cells on both paths, cells belonging to the same gNB, or cells in a configured cell list). This behavior can be applied, for example, when the WTRU has the same cells configured on both the direct and indirect paths. Specifically, when different cells are configured on different paths, an RLF on one path can initiate a fault procedure similar to an MCG, where the remote WTRU reports a fault and awaits further network configuration. On the other hand, when the same cells are configured on both paths, reconfiguring the non-faulty path may not be necessary, and the WTRU can simply initiate fault monitoring on the non-faulty path, expecting to receive RRC messages on the non-faulty path.

[0203] - Conditions associated with whether the WTRU-WTRU (indirect) link is an ideal link. For example, this behavior can be applied when the indirect link between WTRUs is a non-3GPP link. Specifically, when a PC5 link is configured, the remote WTRU can monitor RLF on both links; however, when a non-3GPP link is configured, assuming the link is ideal (and cannot fail), the remote WTRU can rely on the relay WTRU to monitor RLM / RLF on the Uu on its behalf.

[0204] - Conditions associated with whether the path triggering the RLF is a direct or indirect path. For example, this behavior may apply when an RLF is triggered on an indirect path, but not when an RLF is triggered on a direct path. For example, a remote WTRU can always monitor the RLF on the PC5-RRC because RLM monitoring consumes very little additional power compared to Uu.

[0205] - Conditions associated with the type of SL RLF that can be triggered. Specifically, this behavior may be applied only to certain cases of SL failure, such as only when an SL RLF based on HARQ DTX is triggered, only when an SL RLF based on T400 expiration is triggered, only when an SL RLF based on receiving a Uu RLF indication from a relay WTRU is triggered, etc.

[0206] In the relevant implementation scheme, the WTRU can perform a relaxed RLM on one path and can initiate a normal RLM / RLF when an RLF (or similar failure event) occurs on another path.

[0207] Remote WTRU routes data via SL path based on conditions associated with RLM / RLF.

[0208] In one implementation, the WTRU may modify the routing rules for UL data on split bearers based on the SRB configuration and / or other factors that may define its RLF behavior / requirements. Specifically, based on other rules discussed herein, the WTRU may need to monitor RLFs on the SL. If the WTRU has such a requirement, it may perform routing via the SL path such that sufficient data is delivered via the SL path for the UL split bearer. For example, the WTRU may be configured to route a certain percentage of data (possibly for each split bearer) via the SL path, and this percentage may be ensured to be met whenever other conditions (as described herein) require the WTRU to monitor RLFs on the SL. For example, the WTRU may be configured with different split bearer thresholds (e.g., a value of 0), and the WTRU may apply this split bearer threshold based on conditions discussed herein (e.g., Uu and / or SL quality).

[0209] Figure 8This is a flowchart illustrating a process for performing RLM / RLF in a DC WTRU according to an exemplary embodiment. In step 801, the WTRU determines whether the RSRP is higher than a first threshold. If so, the process proceeds to step 803, where the WTRU determines whether there is pending data for the relay path. If so, the WTRU performs RLF only on the SL relay path (step 805). On the other hand, if there is no pending data for the SL relay path, the WTRU performs RLM on the SL relay path and performs a relaxed RLM on the Uu path (step 813).

[0210] Returning to step 801, if the Uu RSRP is below a first threshold, the process proceeds to step 807, where it is determined whether the Uu RSRP is above a second threshold, which is lower than the first threshold. If yes, the process proceeds to step 809, where the WTRU determines whether it has pending UL data for the SL trunk path. If yes, the WTRU performs RLM on the SL trunk path and performs a lenient RLM on the Uu path (step 811). If no, the WTRU performs RLM on both paths (step 813).

[0211] Although not depicted in the flowchart, in the implementation, if and only if an RLF is triggered on one of the two paths, recovery (e.g., a procedure similar to SGCFailure) can be performed on the other of the two links. If an RLF is triggered on both links, radio link reconstruction is performed.

[0212] Representative process of recovery in multipath

[0213] Remote WTRU determines the recovery process using a multipath approach.

[0214] When a problem is detected on one or both links (e.g., an RLF detection or indication from a relay WTRU), the remote WTRU may execute one or more recovery procedures within a set of recovery procedures. The remote WTRU may execute any or several (e.g., sequentially or simultaneously) recovery procedures, including:

[0215] -Execute the reconstruction process

[0216] - Perform multipath reconstruction type 1

[0217] - Perform multipath reconstruction type 2

[0218] -Execute the CHO process

[0219] - Send Uu RRC messages, such as fault messages similar to MCGFailure or SCGFailure messages.

[0220] - Perform operations similar to MCGFailure

[0221] For example, an RRC error message is sent and a timer is started. If the timer expires and the network has not received a reconfiguration, a rebuild message is initiated.

[0222] - Perform operations similar to SCGFailure

[0223] For example, an RRC error message is sent, but the timer is not started. Normal operation can continue on the still-operational link.

[0224] For example, WTRU can send different RRC messages depending on whether it initiates a process similar to SCGFailure or MCGFailure.

[0225] - Performing the relay reselection process may provide the reselection results to the network.

[0226] - A Conditional Handover (CHO), HO, or similar CHO procedure is performed whereby the WTRU uses the configuration provided to it to change the PCcell, potentially to a different path, such as a path associated with an established or developing multipath. For example, a cell addition received by the WTRU can initiate a similar HO or CHO procedure, where, as a result of some fault during the addition process, the WTRU performs a Pcell change for that cell, as described herein.

[0227] - Only trigger measurement reports for available / measured relays, only trigger measurement reports for available / measured cells, trigger measurement reports for both relays and cells.

[0228] Specifically, the conditions discussed in this article can be used to determine which measurement report to transmit.

[0229] -Release PC5-RRC connection

[0230] Specifically, the conditions discussed in this article can be used to determine whether to maintain or release the PC5-RRC connection.

[0231] -Release multipath connections / configuration

[0232] Specifically, the conditions discussed in this paper can be used to determine whether to release multipath connections / configurations at a remote WTRU, and depend on a single path connection.

[0233] - Indicate the reason for the RLF (e.g., SL-RLF detected or Uu RLF received from a relay WTRU).

[0234] Specifically, the conditions in this article can be used to determine whether the reason for including the RRC message transmitted to the network is, such as detecting SL-RLF, receiving Uu RLF, triggering HARQ-based SL RLF, triggering RLC-based SL RLF, triggering T400-based SL RLF, etc.

[0235] - Pause one of the paths associated with the multipath configuration (i.e., pause all transmissions performed on the bearer associated with that path).

[0236] Remote WTRUs determine the message type / content / SRB type of recovery messages (e.g., RRC messages) using a multipath approach.

[0237] Remote WTRUs may include different content in recovery messages (e.g., messages similar to MCGFailure, messages similar to SCGFailure) or may use different RRC messages on different SRBs (SRB0 or ​​SRB1). For example, depending on the conditions of this document, WTRUs may include or exclude specific parameters in messages. Specifically, remote WTRUs may include one or more of the following data in such failure messages:

[0238] - Carrier frequency associated with the fault path

[0239] Measurements of other relay WTRUs

[0240] - An indication of whether the measurement results are correlated with measurements from other relays, and whether they are correlated with the Sidelink Discovery Reference Received Power (SD-RSRP) or the Sidelink Reference Received Power (SL-RSRP).

[0241] - Indicators that may be associated with measurements from other relay stations, and whether measurement results are associated with a remote WTRU that has a PC5-RRC connection.

[0242] - Indicators that may be associated with measurements from other relays, and whether the measurement results are related to a relay WTRU in RRC_CONNECTED state (or the status of the relay WTRU).

[0243] - Fault type, fault indication, or similar information that may indicate any of the following:

[0244] ○ The RLF of the trunk WTRU, or the RLF fault type of the trunk WTRU (e.g., T310 expired, randomAccess Problem, etc.).

[0245] ○SL RLF detected by remote WTRU

[0246] ○ HO of remote WTRU

[0247] ○ Cell reselection performed by remote WTRU

[0248] ○ Remote WTRU failed to establish RRC connection

[0249] - Indications of failures occurring during the processing of the add / change procedure (see Rebuild Type 2 in this document)

[0250] The type / content of the set of actions (e.g., procedures) and / or messages performed by the remote WTRU may depend on any of the conditions discussed in the previous section. Specifically, the WTRU may perform one or more sets of actions, rather than one or another set of actions, based on conditions associated with any one or a combination of the following factors:

[0251] Measurement of Uu path quality

[0252] -SL path quality measurement

[0253] -SL-specific measurements, such as CBR or CR

[0254] - Messages received from the relay WTRU (i.e., specific messages or instructions being transmitted).

[0255] - QoS / bearer configuration at the remote WTRU

[0256] - Are the relay station and remote WTRU controlled by the same / different cell / dispatchman / gNB?

[0257] For example, a remote WTRU may be configured with methods for determining whether a second cell is part of the same gNB as the first cell (e.g., whether the cell list, a subset of bits in the cell ID is common, the area ID or similar information broadcast by the two cells is the same, etc.).

[0258] - Path configuration for SRB in multipath

[0259] - Duplicate configuration of SRB in multipath

[0260] - RRC status of relay WTRU

[0261] - The path on which the RLF is triggered (Uu / direct or SL / indirect or both)

[0262] -RLF monitoring behavior (e.g., whether WTRU is monitoring Uu RLF, SL RLF, or whether WTRU is performing loose Uu RLF monitoring)

[0263] -RLF fault type itself

[0264] - Is the WTRU-WTRU connection of the indirect path a 3GPP link (e.g., PC5) or a non-3GPP link (e.g., an ideal link)?

[0265] Which paths failed (directly or indirectly)?

[0266] -Which path corresponds to the Pcell of the WTRU, and relative to which path fault?

[0267] Representative procedures for the recovery process and message content

[0268] In one example implementation, a WTRU that individually triggers a Uu RLF can determine whether to perform a process similar to MCGFailure or SCGFailure via the SL path based on whether the WTRU is transmitting UL via a relay path or has pending data for transmission via a relay path. For example, the WTRU can be configured with a threshold data amount associated with SL LCHs that enable HARQ feedback. If the data amount in the buffers of all SL LCHs with HARQ feedback enabled exceeds the threshold, the WTRU can perform a recovery process similar to SCGFailure. Otherwise, the WTRU can perform a recovery process similar to MCGFailure.

[0269] In another example implementation, the WTRU detecting the SL RLF can determine whether to perform an SCGFailure-like procedure, an MCGFailure-like procedure, or a reconstruction based on the measured Uu RSRP, which may be associated with the last measurement reported to the network or with the last measurement performed at the WTRU. For example, if the measured Uu RSRP is above a first threshold, the WTRU may perform an SCGFailure-like procedure. If the measured Uu RSRP is between the first threshold and a second threshold below the first threshold, the WTRU may perform an MCGFailure-like procedure. If the Uu RSRP is below the second threshold, the WTRU may perform a reconstruction procedure.

[0270] In another example implementation, the WTRU that triggers an RLF on the SL path (or receives a Uu RLF indication from a relay WTRU) can determine whether to perform an SCGFailure-like procedure, an MCGFailure-like procedure, or a rebuild based on the Uu RLM / RLF monitored by the WTRU during the SL RLF. Specifically, if the WTRU is performing a Uu RLM / RLF, the WTRU may perform an MCGFailure-like procedure. If the WTRU is performing a loose RLM on the Uu path, the WTRU may perform an MCGFailure-like procedure. If the WTRU is not performing a Uu RLM, the WTRU may perform an MCGFailure-like procedure or a rebuild, depending on other factors (e.g., Uu RSRP).

[0271] In another example implementation, the WTRU that triggers an RLF on a link can determine whether to execute a procedure similar to MCGFailure or SCGFailure based on whether the path corresponds to the same cell or different cells. Specifically, in the case of the same cell, the remote WTRU can execute a procedure similar to SCGFailure, while in the case of different cells, the remote WTRU can execute a procedure similar to MCGFailure. In similar examples, the procedure followed may depend on which cell is configured as the serving cell. Specifically, if the RLF occurs on a path associated with a Pcell, the WTRU can execute a procedure similar to MCGFailure, while if the RLF occurs on a path associated with a cell that is not a Pcell, the WTRU can execute a procedure similar to SCGFailure.

[0272] In another example implementation, the WTRU that triggers an RLF on a link can determine whether to perform an MCGFailure-like procedure or an SCGFailure-like procedure based on whether the indirect path is a PC5 link or a non-3GPP link. Specifically, if the indirect path is a non-3GPP link, the RLF triggered on a link may initiate an MCGFailure-like procedure or not initiate a fault procedure at all (i.e., the remote WTRU does not send any RRC messages to the network). If the indirect path is a PC5 link, the remote WTRU may initiate an SCGFailure-like procedure on the SL RLF and an MCGFailure-like procedure on the Uu RLF.

[0273] In another example implementation, the WTRU can determine the fault procedure steps based on the SRB configuration in a multipath environment. Specifically, if the WTRU detects an RLF on a link not configured to carry an SRB (e.g., the WTRU is only configured with SRB1 on one path) and detects an RLF on a link where no SRB is configured, the remote WTRU can report a fault message to the network, suspend or release transmissions to or from the bearer on the faulty link, and continue operating on the non-faulty links. On the other hand, if the remote WTRU is configured with a split SRB and a fault occurs on the link, the remote WTRU can report the fault, suspend all transmissions, and wait for reconfiguration from the network. If no reconfiguration is received before the timer expires, the remote WTRU can trigger a reconstruction. Conversely, if an RLF occurs on a link where the SRB is not configured to split, the remote WTRU can trigger a reconstruction.

[0274] In one example implementation, when recovery is performed via Uu, the WTRU may include an RLF fault type indication, but when recovery is performed via SL, the WTRU may not include an RLF fault type indication. For example, the remote WTRU may indicate in an error message on Uu that the error was caused by the remote WTRU's SL RLF detection, the relay WTRU's reception of the Uu RLF indication, or the reception of other indication messages (e.g., a handover (HO) indication from the relay WTRU). Specifically, the remote WTRU may include a fault type representing a fault on the SL path.

[0275] In one example implementation, the WTRU can determine the type of measurement to include in the measurement report during a failure (relay only, cell only, or both cell and relay) based on the link that failed. Specifically, if a Uu RLF is triggered, the WTRU may include cell measurements only in the error message transmitted via the relay path. If an SL RLF is triggered, the WTRU may include relay measurements only in the error message transmitted via the Uu path. If the WTRU performs a rebuild, it may include both cell and relay measurements.

[0276] In one example implementation, when the remote WTRU is in a multipath and receives an HO indication from the relay WTRU, the remote WTRU can release the PC5-RRC connection and perform an HO for cells belonging to different gNBs. If a relay HO occurs in a cell belonging to the same gNB, the remote WTRU can simply suspend transmissions via the relay path and / or release the relay path configuration without releasing the PC5-RRC connection.

[0277] In another example, the WTRU can determine the behavior associated with the indirect link (RRC connection) and / or the bearer associated with the indirect link based on the type of fault triggered by a message in the remote WTRU. For example, if the remote WTRU receives a Uu RLF indication from the relay WTRU, the remote WTRU can release / tear down the PC5-RRC connection and / or release the multipath configuration. On the other hand, if the remote WTRU receives an HO indication from the relay WTRU, the remote WTRU can suspend indirect bearers or transmissions via the indirect link, but maintain the PC5-RRC connection and wait for the network to reconfigure the indirect link. The remote WTRU can also wait for a period of time for indirect link reconfiguration, after which, if no indirect link reconfiguration is received from the network, the remote WTRU can release the PC5-RRC connection.

[0278] In another example, the WTRU can determine whether to report an RLF / fault on the indirect path to the network based on the link type (PC5 or non-3GPP link). Specifically, if the WTRU detects or is notified of a link fault from a relay WTRU, it can report the fault to the network if the link is a PC5 link. If the link is a non-3GPP link, the remote WTRU can choose not to report the RLF / fault and instead simply suspend transmissions on the indirect link.

[0279] In another example, the WTRU may determine whether to report an RLF / fault of the indirect path to the network based on the fault type reported by the relay WTRU and / or the cell ID served by the relay. Specifically, the remote WTRU may receive a notification message with an indication type (HO, cell reselection, RRC connection establishment failure, Uu RLF, etc.). In some cases, such as in the case of an RRC connection establishment failure or Uu RLF, the remote WTRU may report the RLF / fault of the indirect path to the network and then potentially suspend multipath / bearer / transmission, as discussed herein. In other cases, such as in the case of cell reselection, the remote WTRU may report the fault to the network without taking any other actions related to its transmission and / or configuration. In yet another case, such as in the case of HO, the remote WTRU may not report the fault to the network and similar actions related to the bearer. Alternatively, whether the remote WTRU triggers a report may depend on whether the cell ID of the relay WTRU is the same as or a different part of the gNB, as determined by the remote WTRU by comparison with a list. Regardless of whether a fault is reported, the remote WTRU may still suspend its bearers associated with the indirect link.

[0280] In one example implementation, both the Uu link and the SL link undergo an WTRU executable reconstruction process for the RLF.

[0281] Measurements of relays in multipath can be limited to relays connected to the same cell.

[0282] In one implementation, the WTRU can filter measurements transmitted to relays to the gNB to limit them to those relays served by the same cell / gNB as the remote WTRU directly serving via multipath. For example, the WTRU can send measurements along with error messages during the recovery process after an SL-RLF, and may include potential relays and their SL-RSRP / SD-RSRP. In doing so, the remote WTRU, which is in multipath at the time of the error, can filter measurements to include only those connected to relays in the same cell / gNB as the remote WTRU. Alternatively, the remote WTRU can prioritize sending measurements connected to relays in the same cell / gNB. Specifically, if the remote WTRU is able to detect relays connected to the same cell (potentially having SL RSRP / SD RSRP above a threshold), the WTRU can only transmit measurements from those relays. Otherwise, the WTRU can transmit measurements from other relays. The advantage of this implementation is that it reduces the overhead of transmitting all relay measurements when multipath is limited to situations where the remote WTRU and the relay WTRU are controlled by the same cell.

[0283] Whether the WTRU filters relay measurements to include only those connected to the same gNB may also depend on other factors discussed herein. For example, during normal operation (e.g., outside of RLF conditions), measurements of potential relays may be filtered only to those connected to the same gNB, provided that the Uu RSRP is above a threshold. Otherwise, the WTRU may include all measurements. The advantage of this implementation is that the WTRU can only provide measurements for other relays (not necessarily controlled by the same cell) if the network might change cells.

[0284] Figure 9This is a flowchart of an exemplary procedure for performing radio link restoration in a DC WTRU upon RLF detection, according to a particular exemplary embodiment. At step 901, if the RLF is triggered only on the Uu path, the procedure proceeds to step 903, where the WTRU determines whether there is pending data for the SL relay path. If yes, the WTRU determines whether the RSRP on another path (in this example, the SL relay path) is higher than a first threshold (step 905). If yes, the WTRU performs a procedure similar to SCGFailure on the SL relay path (e.g., sending an RRC message and continuing operation on that path) (step 907). If no, the procedure proceeds to step 909, where the WTRU determines whether the RSRP on the SL relay path is higher than a second threshold lower than the first threshold. If yes, the procedure proceeds to step 911, where the WTRU performs a procedure similar to MCGFailure on the SL relay path (e.g., sending an RRC message and setting a timer for radio link reconstruction). If no, the procedure proceeds to step 913, where the WTRU performs the radio link reconstruction procedure.

[0285] Return to Figure 9 At the top, on the other hand, if an RLF is triggered only on the SL relay path (step 915), the process proceeds from step 915 to step 917, where the WTRU determines whether it is currently performing an RLM / RLF on the Uu path. If yes, the process proceeds from step 917 to step 919, where the WTRU determines whether the RSRP on the Uu path is higher than a first threshold. If yes, the process proceeds from step 919 to step 921, where the WTRU performs a procedure similar to an SCGFailure on the Uu path. If no, the process proceeds from step 919 to step 923, where the WTRU determines whether the RSRP on the Uu path is higher than a second threshold lower than the first threshold. If yes, the process proceeds from step 923 to step 925, where the WTRU performs a procedure similar to an MCGFailure on the Uu path. If no, the process proceeds from step 923 to step 913, where the WTRU performs a radio link reconstruction procedure.

[0286] Return to Figure 9 At the top, if an RLF is triggered for both paths (step 927), the process proceeds directly to step 913, where the WTRU performs the radio link re-establishment procedure. Note that in... Figure 9 For ease of explanation, step 927 is shown as a decision step in the flowchart. However, since the flowchart assumes that the RLF is triggered, step 927 can also be omitted. Therefore, if the two conditions described in steps 901 and 915 are not met, the condition in step 927 is inherently met.

[0287] Representative procedure - MAC CE that can switch main paths and implicitly initiate RLM / RLF

[0288] In one implementation, the remote WTRU may receive a MAC CE that can initiate or stop RLM / RLF and / or change the strength of the RLF (e.g., loose RLM versus normal RLM). In another implementation, the remote WTRU may receive a MAC CE that changes the suitability of the path used for sending / receiving SRB1. Specifically, the remote WTRU may be configured with a split SRB, but at a given time, it may only send / receive SRB and / or perform RLM / RLF on one path. Although an SRB is configured, SRB sending / receiving may be disabled on another path. Upon receiving a MAC CE, the remote WTRU may enable / disable SRB receiving / sending on the path. Specifically, when a split SRB is configured, the remote WTRU with RRC messages may send RRC messages via the path where only SRB is enabled.

[0289] In another implementation, the same MAC CE can enable / disable RLM / RLF and enable / disable / change SRB transmission / reception on the path.

[0290] Representative process for reconstruction in multipath

[0291] A new method for reconstruction can be used by a remote WTRU in a multipath manner. Specifically, since the WTRU is not currently configured to monitor the SRB on one of the two paths (e.g., for power saving), reconstruction can be triggered by the WTRU in a multipath manner. If an RLF is triggered on the path with the SRB, the WTRU cannot perform a process similar to MCGFailure / SCGFailure and can typically resort to reconstruction. However, the remote WTRU is already running on the other path because this path is being used during multipath operation and is likely functioning correctly (e.g., the remote WTRU is receiving / transmitting data on this path and potentially reporting measurements on this path). Therefore, a full traditional reconstruction process may not be necessary.

[0292] Therefore, in a range of implementations, a remote WTRU can trigger a new RRC procedure, whereby the remote WTRU, which would normally cause a failure in the reconstruction process, initiates / continues a connection on one path in a multipathing process. Potential differences between this new RRC procedure and the traditional reconstruction procedure may include:

[0293] - The remote WTRU does not trigger cell / relay selection; instead, it directly performs the procedure on the cells / relays used in multipath mode.

[0294] - The remote WTRU can (re)use the RRC configuration that is already available at the WTRU, instead of releasing the configuration and triggering a rebuild.

[0295] - Remote WTRUs can avoid rebuilding or resetting one or more protocol layers (e.g., the data buffer is not necessarily flushed), as is the case with rebuilding.

[0296] In one particular implementation of this type, the remote WTRU can apply the procedure using the RRC configuration for a new path that is already available and applied at the WTRU. Specifically, if the WTRU is operating in a multipath mode and performs the procedure on one of two paths, the WTRU can continue to use the multipath-associated configuration for each protocol layer applicable to that path. This type of implementation is most similar to a rebuild that does not require cell / relay selection and does not reset the protocol layers. This procedure may be referred to herein as Multipath Rebuild Type 1.

[0297] In another type of implementation, the remote WTRU may apply the procedure using an RRC configuration received in a message (e.g., path change / path addition) prior to triggering the procedure due to an error. Specifically, the remote WTRU may trigger the procedure as a result of a failure that occurs after the RRC configuration has been received. This type of implementation is most similar to a CHO, where the configuration is received via an RRC message and applied upon triggering a failure. This procedure may be referred to herein as Multipath Reconstruction Type 2.

[0298] The type of RRC messages and / or SRBs transmitted / received may depend on whether SRB1 is configured.

[0299] The reconstruction process for multipaths can be triggered using RRC messages using SRB0 or ​​SRB1.

[0300] For example, if the WTRU triggers a Type 1 procedure, whether SRB0 or ​​SRB1 is used for the initial RRC message depends on whether the path on which the procedure is performed (i.e., the path used for message transmission) was previously configured with SRB1. If SRB1 is configured, the remote WTRU can send an RRC message (e.g., similar to an MCG / SCGFailure message) on SRB1. The remote WTRU can then expect a reconfiguration message. Similar to the MCGFailureInformation procedure in a traditional system, if no reconfiguration is received within a specific time period, the remote WTRU can trigger a rebuild. If SRB1 is not configured, the remote WTRU can send an RRC message (e.g., similar to an RRCReestablishmentRequest) on SRB0. The remote WTRU can wait for a response message (e.g., similar to a rebuild message). In either case, the remote WTRU can continue transmission on the DRB via a non-faulty path and does not perform any reset of the PHY / MAC / RLC layers on either path. Specifically, in the case of SRB0, data transmission can continue using the previous security key. SRB0 can send / receive RRC messages using the specified configuration. Alternatively, sending SRB1 messages can be done using the specified / default configuration of SRB1 (considering that SRB1 has not previously been configured on this path).

[0301] In the uplink RRC message, the remote WTRU can also indicate the cause of the fault (e.g., RLF type or whether it was caused by SL RLF, etc.).

[0302] For example, if the WTRU triggers a Type 2 procedure after receiving an RRC message (but before applying it), whether SRB0 or ​​SRB1 is used for the initial RRC message depends on whether the received message (in the example below, the RRC message added to the execution path) contains a configuration for SRB1. If no configuration is provided, the WTRU can use SRB0 or ​​send an RRC message with a default or specified configuration, while if the received message contains an SRB1 configuration, the remote WTRU can use the configuration in the received message to send an uplink RRC message. Furthermore, the WTRU may not expect any response message, for example, in the case of using SRB1 (i.e., the message may resemble a complete message).

[0303] In the uplink RRC message, the remote WTRU can also indicate that a path addition / change has failed, and the remote WTRU applies the configuration provided in the path addition / change message to perform a rebuild. If multiple configurations may have been provided to the WTRU, the WTRU can further identify the specific configuration.

[0304] In Type 2, data transmission via DRB can be initiated under any of the following conditions:

[0305] - Immediately following the transmission of the uplink RRC message

[0306] - Immediately following the RACH process (if you intend to add a direct path).

[0307] - Immediately following the establishment of the PC5-RRC connection (if you intend to add an indirect path).

[0308] -After receiving the DL confirmation message

[0309] -Depending on whether SRB0 or ​​SRB1 is used (or whether it is part of a configuration associated with type 2)

[0310] For example, if SRB0 is used, the WTRU can wait to receive a response before initiating data transmission.

[0311] For example, if SRB1 is used, the WTRU can perform data transmission immediately after or simultaneously with the transmission of the RRC message. After the transmission of the UL RRC message, the WTRU may not expect any response message.

[0312] As a result of RLF from another path, it can trigger a representative process for multi-path reconstruction type 1.

[0313] In one implementation, as a result of an RLF detected on the second path, a remote WTRU may perform a multipath reconstruction type 1 via a first path, wherein the first and second paths are paths previously configured for the WTRU during multipathing.

[0314] As a result of a failure during path addition / modification, a representative process for multipath reconstruction type 2 can be triggered.

[0315] In one implementation, as a result of a failure during the path addition / change process, the remote WTRU can initiate a multipath reconstruction type 2 process. For example:

[0316] - Indirect path failure during direct path addition: The remote WTRU can receive path addition for adding a direct path via the indirect path. During addition, the remote WTRU can receive notification (e.g., Uu RLF) or triggerable SL RLF from the relay WTRU. Upon receiving the notification, the remote WTRU can perform a type 2 multipath reconstruction to the cell associated with the direct path. Specifically, the remote WTRU can send a full message via the direct path. The remote WTRU can also (e.g., within the full message) indicate that the remote WTRU has performed a type 2 multipath reconstruction procedure, rather than adding due to a failure in the indirect path during that procedure. Specifically, the remote WTRU can include the indication in the full message. The remote WTRU can then operate as a PCell on the direct path (instead of assuming the PCell is on the indirect path). Specifically, the remote WTRU can use the received configuration, thereby assuming that the bearer associated with the indirect path is suspended, and only use the direct path bearer or multiple bearer paths until further reconfiguration.

[0317] - Failure of the direct path during the addition of an indirect path: Similarly, a remote WTRU can add an indirect path by receiving a path addition via the direct path. During the addition, the remote WTRU can trigger a Uu RLF. Upon detecting a Uu RLF, the remote WTRU can perform a Type 2 procedure on the cell associated with the indirect path and indicate the procedure in the full message.

[0318] - Failure of the direct path during indirect path change: The remote WTRU can receive a reconfiguration that changes the indirect path (i.e., to a different relay WTRU) and triggers a Uu RLF during the path change process. As a result, the remote WTRU can initiate a Type 2 procedure via the new indirect path.

[0319] Figure 10A An example of multipath wireless communication is provided. In this example, the remote WTRU is configured to be multipath and performs RLM and RLF detection on Uu based on 1) the radio conditions on Uu and 2) the presence / amount of uplink data sent to the network via the relay link (relay WTRU).

[0320] refer to Figure 10BThis document provides an example procedure for RLM and / or RLF detection in multipath communication. In one embodiment, a WTRU (e.g., a multipath remote WTRU) for wireless communication includes circuitry comprising a transmitter, a receiver, a processor, and a memory. The WTRU is configured to: receive configuration information indicating 1) a first radio link configuration and a second radio link configuration, and 2) a first threshold and a second threshold, wherein the first threshold is greater than the second threshold. The WTRU may determine that uplink data is pending for a first transmission to a network entity via another WTRU (e.g., a relay WTRU), wherein the first transmission is associated with a first communication link. The WTRU may determine the channel conditions for a second transmission from the network entity, wherein the second transmission is associated with a second communication link. The WTRU may perform a first radio link procedure using the first radio link configuration based on a measurement of channel conditions greater than the second threshold and less than the first threshold.

[0321] In one example, the WTRU may perform a radio link failure (RLF) detection procedure on a first communication link based on a measurement of channel conditions exceeding a first threshold. In another example, the WTRU may perform a second radio link procedure using a second radio link configuration based on a measurement of channel conditions falling below a second threshold.

[0322] In various implementations, the first radio link procedure includes radio link failure (RLF) detection, radio link monitoring (RLM), and / or radio link recovery on the second communication link. The second radio link procedure includes radio link failure (RLF) detection, radio link monitoring (RLM), and / or radio link recovery on the second communication link. Each of a first threshold and a second threshold is used to compare channel conditions associated with the second communication link. In some cases, channel conditions include the second transmitted reference signal received power (RSRP). Measurement of channel conditions includes the value of the measured reference signal received power (RSRP) of the second transmitted signal.

[0323] In some examples, the first communication link may be a side link (SL) relay path that communicates with the network entity via a second WTRU, and the second communication link may be a Uu path that communicates with the network entity.

[0324] In some examples, the configuration information indicates the Radio Resource Control (RRC) configuration, and the WTRU can use the RRC configuration for the first or second communication link before detecting an RLF. The WTRU can determine the type of radio link recovery process based on channel conditions, the type of RLF, and / or the transmission of pending uplink data.

[0325] in conclusion

[0326] Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described herein, which are intended as illustrative examples of various aspects. Many modifications and variations may be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly stated otherwise, no element, action, or description used in this specification should be construed as essential or necessary to the invention. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the terms of the appended claims and the full scope of equivalents of such claimed claims. It should be understood that this disclosure is not limited to any particular method or system.

[0327] For simplicity, the aforementioned embodiments are discussed with reference to the terminology and structure of infrared-capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0328] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or the term “image” may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. Similarly, when referred to herein, the term “user equipment” and its abbreviation “UE,” the term “remote” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device configured with some or all of the structural and functional aspects of a WTRU that has wireless and / or wired (e.g., tetherable) capabilities; (iii) a device configured with fewer than all the structural and functional aspects of a WTRU that has wireless and / or wired capabilities; or (iv) etc. Figures 1A to 1DDetails of example WTRUs representative of any WTRU described herein are provided. For instance, various disclosed embodiments herein are described as utilizing head-mounted displays. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of the embodiments disclosed herein and various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted realistic experience.

[0329] Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) 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 optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0330] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the various applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) that provides any suitable voltage.

[0331] Furthermore, the embodiments provided above specify processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”

[0332] Those skilled in the art will recognize that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. The electrical system represents data bits, which can lead to the final transformation or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the CPU's operation and performing other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the implementation is not limited to the platform or CPU described above, and other platforms and CPUs may also support the provided methods.

[0333] Data bits may also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (“RAM”)) or non-volatile (e.g., read-only memory (“ROM”)) mass storage system. The computer-readable medium may include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the implementation is not limited to the aforementioned memory, and other platforms and memories may also support the provided methods.

[0334] In exemplary embodiments, any of the operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0335] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software typically (but not always, as the choice between hardware and software can become important in certain contexts) represents a design choice that weighs cost against efficiency. Various media (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary depending on the context of deployment. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0336] The specific embodiments described above have illustrated various implementations of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof. In embodiments, certain portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, either wholly or partially, as one or more computer programs (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuits and / or writing code for software and / or firmware according to this disclosure will be entirely within the scope of the skills of those skilled in the art. Furthermore, those skilled in the art will recognize that the mechanisms of the subject matter described herein can be distributed as program products in various forms, and the exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media (such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.); and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0337] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and subsequently to use engineering practice to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally includes one or more of the following: a system unit enclosure; a video display device; memory, such as volatile and non-volatile memory; a processor, such as a microprocessor and a digital signal processor; computing entities, such as an operating system, drivers, a graphical user interface, and applications; one or more interactive devices, such as a touchpad or screen; and / or a control system, including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). Typical data processing systems can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0338] The topics described herein sometimes illustrate different components included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can in fact achieve the same functionality. Conceptually, any arrangement of components achieving the same functionality is effectively “associated” to enable the desired functionality. Therefore, any two components combined herein to achieve a particular functionality can be considered “associated” with each other to enable the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operably coupled components include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or logically interact and / or logically interact.

[0339] Regarding virtually any plural and / or singular terms used herein, those skilled in the art can appropriately convert them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0340] Those skilled in the art will understand that, in general, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is typically intended as “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if it is intended to specify a particular number of introduced claim subjects, such intention will be explicitly stated in the claims, and if no such claim subject is present, such intention will not exist. For example, the term “single” or similar language may be used where only one item is anticipated. To aid understanding, the appended claims and / or the description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claim subjects. However, the use of such phrases should not be construed as implying that any particular claim including such introduced claim subject matter is limited to an embodiment including only one such claim subject matter by using the indefinite articles "a" or "an," even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim subject matter. Furthermore, even when a specific number of introduced claim subject matter is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the stated number (e.g., a bare statement of "two subject matter" in the absence of other modifiers means at least two subject matter or two or more subject matter). Furthermore, in instances where the convention of "at least one of A, B, and C" is used, generally speaking, such a construction implies that a person skilled in the art would understand the convention (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C). In instances where the convention of "at least one of A, B, or C" is used, generally speaking, such a construction implies that a person skilled in the art would understand the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C). Those skilled in the art should also understand that, in fact, any separate words and / or phrases presenting two or more alternative terms in the specification, claims, or drawings should be understood to imply the possibility of including one of the terms, any one of the terms, or both of the terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Additionally, as used herein, the term “any one of…” followed by a list of multiple items and / or multiple item categories is intended to include items and / or item categories “any one of…”, “any combination of,” “any multiple of,” and / or “any combination of multiples of”, whether alone or in combination with other items and / or other item categories. Furthermore, as used herein, the term “group” is intended to include any number of items, including zero. Additionally, as used herein, the term “quantity” is intended to include any quantity, including zero. And, as used herein, the term “many” is intended to be synonymous with “multiple.”

[0341] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup of the Markush Group.

[0342] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” and “less than,” etc., includes the referenced number and refers to a scope that can subsequently be divided into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1 to 3 units means a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units means a group having 1, 2, 3, 4, or 5 units, etc.

[0343] Furthermore, unless otherwise stated, the claims should not be construed as being limited to the order or elements provided. Additionally, the use of the term "part for..." in any claim is intended to invoke 35 U.S.SC §112. 6. Claims in the form of a component plus function, and any claim without the term "component for..." is not intended to be so.

[0344] Suitable processors include (by way of example) general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate arrays (FPGAs), any other type of integrated circuit (IC) and / or state machines.

[0345] WTRU can be used in conjunction with modules and can be implemented in hardware and / or software including: Software-defined radio (SDR) and other components such as cameras, video camera modules, videophones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keypads, etc. Modules, FM radio units, Near Field Communication (NFC) modules, Liquid Crystal Display (LCD) units, Organic Light Emitting Diode (OLED) units, Digital Music Players, Media Players, Video Game Players, Internet Browsers, and / or any Wireless Local Area Network (WLAN) or Ultra-Wideband (UWB) modules.

[0346] Although various implementation schemes have been described based on the communication system, it is conceivable that the system can be implemented in software on a microprocessor / general-purpose computer (not shown). In some implementations, one or more functions of the various components can be implemented in software that controls the general-purpose computer.

[0347] Furthermore, while the invention has been illustrated and described herein with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications may be made to the details within the scope and domain of equivalents of the claims without departing from the invention.

Claims

1. A wireless transceiver unit (WTRU), the wireless transceiver unit (WTRU) comprising: Processor, the processor being configured to: Establish a direct communication path with the network and an indirect communication path with the network, wherein the indirect communication path includes a first path between the WTRU and the relay WTRU and a second path between the relay WTRU and the network; Receive a message from the relay WTRU indicating that the second path has failed; The fault of the indirect communication path is determined based on the message received from the relay WTRU; as well as A fault message is transmitted to the network via a direct communication path, wherein the fault message indicates that the fault of the indirect communication path has occurred on the second path between the relay WTRU and the network.

2. The WTRU of claim 1, wherein the fault message includes a measurement based on whether the indirect communication path is a 3GPP communication path or a non-3GPP communication path.

3. The WTRU according to claim 2, wherein the measured value is the reference signal received power (RSRP) value.

4. The WTRU of claim 1, wherein the processor is configured to: In response to the detection of the fault in the indirect communication path, transmission on the indirect communication path is suspended.

5. The WTRU of claim 1, wherein the first path includes a side link between the WTRU and the relay WTRU, and the second path includes a Uu link between the relay WTRU and the network.

6. The WTRU according to claim 1, wherein the direct communication path is a direct Uu communication path between the WTRU and the network.

7. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Establish a direct communication path with the network and an indirect communication path with the network, wherein the indirect communication path includes a first path between the WTRU and the relay WTRU and a second path between the relay WTRU and the network; Receive a message from the relay WTRU indicating that the second path has failed; The fault of the indirect communication path is determined based on the message received from the relay WTRU; as well as A fault message is transmitted to the network via a direct communication path, wherein the fault message indicates that the fault of the indirect communication path has occurred on the second path between the relay WTRU and the network.

8. The method of claim 7, wherein the fault message includes a measurement based on whether the indirect communication path is a 3GPP communication path or a non-3GPP communication path.

9. The method of claim 8, wherein the measured value is a reference signal received power (RSRP) value.

10. The method of claim 7, wherein the method further comprises: In response to the detection of the fault in the indirect communication path, transmission on the indirect communication path is suspended.

11. The method of claim 7, wherein the first path includes a side link between the WTRU and the relay WTRU, and the second path includes a Uu link between the relay WTRU and the network.

12. The method of claim 7, wherein the direct communication path is a direct Uu communication path between the WTRU and the network.

13. A wireless transceiver unit (WTRU), the wireless transceiver unit (WTRU) comprising: Processor, the processor being configured to: Establish a direct communication path with the network and an indirect communication path with the network, wherein the indirect communication path includes a first path between the WTRU and the relay WTRU and a second path between the relay WTRU and the network; Detect side link radio link failure (SL RLF) on the first path; The fault in the indirect communication path is determined based on the detection of SL RLF on the first path; as well as A fault message is sent to the network via a direct communication path, wherein the fault message indicates that the fault of the indirect communication path has occurred on the first path between the WTRU and the relay WTRU.

14. The WTRU of claim 13, wherein the fault message includes a marker indicating that the fault of the indirect communication path has occurred on the first path.

15. The WTRU of claim 13, wherein the fault message includes a measurement based on whether the indirect communication path is a 3GPP communication path or a non-3GPP communication path.

16. The WTRU of claim 13, wherein the processor is configured to: In response to the detection of the fault in the indirect communication path, transmission on the indirect communication path is suspended.

17. The WTRU of claim 13, wherein the first path includes a side link between the WTRU and the relay WTRU, and the second path includes a Uu link between the relay WTRU and the network.

18. The WTRU of claim 13, wherein the direct communication path is a direct Uu communication path between the WTRU and the network.

19. A wireless transceiver unit (WTRU), the wireless transceiver unit (WTRU) comprising: Processor, the processor being configured to: Receive configuration information from the network, the configuration information including information associated with multipath operation, wherein the first path of the multipath operation is via Uu and the second path is via a side link (SL) relay; Detect radio link failure (RLF) on the first path or the second path; Perform a recovery process, wherein the recovery process is a primary cell group (MCG) fault recovery process; Send a Radio Resource Control (RRC) message indicating the fault to the network.

20. The WTRU of claim 19, wherein the MCG fault recovery process includes the processor being further configured to: Send an RRC message to the network; and Set a timer for rebuilding.

21. The WTRU of claim 19, wherein the recovery process is a secondary cell group (SCG) fault recovery process.

22. The WTRU of claim 21, wherein the SCG fault recovery process includes the processor being further configured to: Send an RRC message to the network; and Continue operating on the first or second path.

Images