Performing indirect-to-direct / indirect lossless switching

Abstract

Methods and apparatus are disclosed for reducing packet loss during a WTRU handover from an indirect link with a source base station to a direct or indirect link with a target base station. After handover to a target base station, a remote wireless transmit receive unit (WTRU) may receive a packet data convergence protocol (PDCP) status report / PDU from the target base station. The WTRU may retransmit PDCP packets in its PDCP buffer indicated as not received in the received PDCP status report, the PDCP packets including packets previously transmitted by the remote WTRU and acknowledged to be received by the source relay WTRU. Additional embodiments are disclosed.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 62 / 494,410, filed April 5, 2023, and U.S. Provisional Application No. 63 / 421,778, filed November 2, 2022, the contents of which are incorporated herein by reference. Background Art

[0002] Vehicle-to-everything (V2X) communication technology with the ability for a wireless transmit receive unit (WTRU) to communicate with other devices is desired. Prose WTRU-to-network relay has been previously introduced to extend network coverage to out-of-coverage WTRUs by using PC5 device-to-device (D2D) communication between the out-of-coverage WTRU and the WTRU-to-network relay. When a remote WTRU performs handover (HO) from an indirect link (i.e., a connection via a SL relay WTRU), there may be some outstanding packets that are acknowledged by the SL relay but are still pending transmission on the backhaul link between the relay WTRU and the gNB. Therefore, packet loss may occur during such a HO because packets that have been acknowledged by lower layers are not retransmitted when PDCP is reestablished after the HO. Therefore, there is a need for improved WTRU-to-network coverage extension and WTRU-to-WTRU coverage extension to ensure that there is no UL or DL packet loss when performing a handover from an indirect link via a source relay WTRU to a target direct or indirect link. Summary of the Invention

[0003] Embodiments of the present invention relate to WTRU relay and handover operations in next-generation wireless networks such as 5G NR. More specifically, embodiments relate to reducing UL and / or DL packet loss when performing a handover from an indirect link via a source relay WTRU to a target direct / indirect link between various network entities including a remote WTRU.

[0004] Embodiments are disclosed for wireless communications in a 5G network with multiple relay configurations that accommodate indirect and direct packet flow switching for various handover (HO) scenarios with reduced packet loss and increased efficiency. In an example downlink transmission from a base station (e.g., a gNB) to a remote wireless transmit and receive unit (WTRU) via an indirect connection / link with a source relay WTRU, the HO flow may involve the source relay WTRU buffering packets and delaying an acknowledgement (ACK) to the gNB until an ACK for the relevant packets has been received from the remote WTRU via a sidelink. Similar buffering and ACK delay may be performed in the uplink. For example, the delayed ACK transmission may be only temporary based on an indicator, a time period before or after the HO, and / or based on a conditional handover (CHO) trigger. Retransmission of the packet may be initiated based on a status PDU received only after the HO from the indirect to direct link.

[0005] According to certain aspects, the relay WTRU, upon receiving an indication (from the network or the remote WTRU), may start delaying sending a radio link control (RLC) ACK to the remote WTRU until an ACK for the corresponding UL RLC packet is received from the gNB over the Uu interface. The relay WTRU, upon receiving an indication (from the network or the remote WTRU), may stop delaying the ACK for the UL RLC packet destined for the remote WTRU.

[0006] In other aspects, the relay WTRU, upon receiving an indication (from the network or the remote WTRU), may start delaying sending RLC ACKs to the gNB until an ACK for the corresponding DL RLC packet is received from the remote WTRU via the sidelink (SL). The relay WTRU, upon receiving an indication (from the network or the remote WTRU), may stop delaying the ACK for the DL RLC packet to the gNB.

[0007] In accordance with further aspects of the embodiment, the remote WTRU may be configured with a condition for sending an indication to the relay WTRU to start delaying the UL / DL RLC ACK (e.g., a trigger condition associated with conditional handover (CHO), which is used to trigger the sending of a delay indication prior to performing a traditional CHO trigger condition for CHO).

[0008] In an additional aspect, a remote WTRU, upon receiving a Packet Data Convergence Protocol (PDCP) Status Packet Data Unit (PDU) (also referred to herein as a PDCP status report) indicating that a particular packet was not received, may immediately begin retransmitting the packet. The remote WTRU is configured to retransmit packets that have been indicated as not received in a PDCP Status PDU received after a HO from an indirect link to a direct / indirect link. The remote WTRU may also be configured to apply this behavior upon receiving a first PDCP Status PDU after a handover (HO) (e.g., within a given time) or a Status PDU with an explicit indication of retransmitted packets. The packets retransmitted by the remote WTRU may include packets in its PDCP buffer that have been sent and acknowledged as received by the source relay WTRU prior to the HO. Additional aspects of the embodiments are disclosed. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding may be obtained from the following description given by way of example with reference to the accompanying drawings, in which like reference numerals represent like elements, and in which:

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

[0011] Figure 1B is a diagram showing that according to one embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0012] Figure 1C is a diagram showing that according to one embodiment, Figure 1A a system diagram of an example radio access network (RAN) and an example core network (CN) used within the illustrated communication system;

[0013] Figure 1D is a diagram showing that according to one embodiment, Figure 1A A system diagram of an additional example RAN and an additional example CN used within the illustrated communication system;

[0014] Figure 2 is an example diagram of a sequence of WTRU / WTRU handovers between network stations;

[0015] Figure 3 is an example representation of a user plane protocol stack for Layer 2 (L2) WTRU to network relay;

[0016] Figure 4 is an example representation of a control plane protocol stack for an L2 WTRU to network relay;

[0017] Figure 5is a sequence diagram illustrating the process of a User Equipment to Network (U2N) remote WTRU handover to a direct Uu cell;

[0018] Figure 6 is an example message sequence for a U2N remote WTRU switching to an indirect path;

[0019] Figure 7 is a functional diagram representing a functional view of the Physical Downlink Convergence Protocol (PDCP) layer between a WTRU and a Next Generation Radio Access Network (NG-RAN);

[0020] Figure 8 This is an example diagram of the entities and related links in an inter-gNB indirect-to-indirect path handover scenario.

[0021] Figure 9 yes Figure 8 An example messaging sequence for the entities depicted in ;

[0022] Figure 10 is an example PDCP buffer at the remote WTRU, where Nx represents the PDCP PDU sequence number;

[0023] Figure 11 is an example flow chart detailing a method for a remote WTRU to perform a lossless handover according to one embodiment; and

[0024] Figure 12 is a message sequence chart detailing message exchanges and operations according to one embodiment. DETAILED DESCRIPTION

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

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

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

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

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

[0030] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may 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 (DL) Packet Access (HSDPA) and / or High Speed Uplink (UL) Packet Access (HSUPA).

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

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

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

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

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

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

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

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

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

[0040] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0047] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, (Bluetooth) module, frequency modulation (FM) radio unit, digital music player, media player, electronic game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a posture sensor, a biometric sensor, a humidity sensor, etc.

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

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

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

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

[0052] Figure 1C The CN 106 shown in FIG may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are described as being 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.

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

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

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

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

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

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

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

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

[0061] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, formed by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

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

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

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

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

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

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

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

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

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

[0071] Figure 1DThe illustrated CN 106 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. While the aforementioned elements are depicted as being 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.

[0072] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-APro and / or non-3GPP access technologies, such as WiFi.

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

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

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

[0076] Given that Figures 1A-1D as well as Figures 1A-1D

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

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

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

[0079] refer to Figure 2 , shows an example handover process 200 between a WTRU and a network access station, such as a source gNB and a target gNB. In step 0, connection and session management information is exchanged between network nodes and is controlled via the Access and Mobility Management Function (AMF). In a 5G network architecture, the User Plane Function (UPF) is responsible for packet routing and forwarding, packet inspection, QoS processing, and external PDU sessions for interconnecting data networks (DNs) (not shown). In step 1, the source gNB configures the WTRU measurement procedures and WTRU reporting according to the measurement configuration. In step 2, the source gNB decides whether to handover the WTRU based on the received measurement results, and if so, in step 3, the source gNB issues a Handover Request message to the target gNB, delivering a transparent Radio Resource Control (RRC) container with the necessary information to prepare the handover on the target side. This information may include at least the target cell ID, KgNB* (intermediate key for horizontal or vertical security key derivation), the cell radio network temporary identifier (C-RNTI) of the WTRU in the source gNB, the radio resource management (RRM) configuration including the WTRU inactivity time, the basic AS configuration including antenna information and DL carrier frequency, the current QoS flow to data radio bearer (DRB) mapping rules applied to the WTRU, the system information block (SIB1) from the source gNB, the WTRU capabilities of different RATs, PDU session related information, and may include measurement information reported by the WTRU, including beam related information, if available.

[0080] In step 4, admission control may be performed by the target gNB, and if the WTRU may be admitted, then in step 5, the target gNB prepares for handover using L1 / L2 and sends a handover request confirm to the source gNB, which includes a transparent container to be sent as an RRC message to the WTRU to perform the handover.

[0081] In step 6, the source gNB triggers Uu handover by sending an RRC Reconfiguration message to the WTRU, which contains the information required to access the target cell: at least the target cell ID, the new C-RNTI, and the target gNB security algorithm identifier for the selected security algorithm. It may also include a set of dedicated Random Access Control Channel (RACH) resources, the association between RACH resources and SSB(s), the association between RACH resources and WTRU-specific CSI-RS configuration(s), common RACH resources and system information for the target cell, etc. Next, in step 7, the source gNB may send an SN Status Transfer message to the target gNB to convey the uplink Packet Data Convergence Protocol (PDCP) SN receiver status and downlink PDCP SN transmitter status for the DRBs (i.e., RLC AM) to which the PDCP status preservation applies. In step 8, the WTRU may synchronize with the target cell and complete the RRC handover procedure by sending an RRC Reconfiguration Complete message to the target gNB. In step 9, the target gNB may send a Path Switch Request message to the AMF to trigger the 5GC to switch the DL data path to the target gNB and establish the NG-C interface instance towards the target gNB. In step 10, the 5GC switches the DL data path towards the target gNB. The UPF sends one or more “end marker” packets per PDU session / tunnel on the old path to the source gNB and may then release any U-Plane / TNL resources towards the source gNB.

[0082] In step 11, the AMF confirms the Path Switch Request message with a Path Switch Request Confirm message, and in step 12, upon receiving the Path Switch Request Confirm message from the AMF, the target gNB sends a WTRU Context Release to inform the source gNB of the handover success. The source gNB may then release the radio and C-plane related resources associated with the WTRU context. Any ongoing data forwarding may continue.

[0083] refer to Figure 3 and Figure 4 , presenting the corresponding user plane of L2 U2N relay architecture ( Figure 3 ) and the control plane ( Figure 4). The Sidelink Relay Adaptation Protocol (SRAP) sublayer may be placed above the RLC sublayer for both the Control Plane (CP) and User Plane (UP) at both the PC5 interface and the Uu interface. The Uu SDAP, PDCP, and RRC may terminate between the L2 U2N Remote WTRU and the gNB, while the SRAP, RLC, MAC, and PHY may terminate at each hop (i.e., the link between the L2 U2N Remote WTRU and the L2 U2N Relay WTRU and the link between the L2 U2N Relay WTRU and the gNB).

[0084] For L2 U2N relaying, the SRAP sublayer on the PC5 hop is used for bearer mapping purposes. The SRAP sublayer is not present on the PC5 hop and is used to relay messages for the L2 U2N remote WTRU on the Broadcast Control Channel (BCCH) and the Paging Control Channel (PCCH). For messages for the L2 U2N remote WTRU on SRB0, the SRAP sublayer is not present on the PC5 hop, but is present on the Uu hop for both DL and UL.

[0085] For L2 U2N relay, for the uplink, in an example embodiment, the Uu SRAP sublayer supports UL bearer mapping between the ingress PC5 relay RLC channel and the egress Uu relay RLC channel for relaying on the L2 U2N relay WTRU Uu interface. For uplink relay traffic, different end-to-end resource blocks (RBs) (e.g., signaling (SRBs) or data (DRBs)) of the same remote WTRU and / or different remote WTRUs may be multiplexed on the same Uu relay RLC channel.

[0086] The Uu SRAP sublayer may support L2 U2N remote WTRU identification for UL traffic. The identity information of the L2 U2N remote WTRU Uu radio bearer and the local remote WTRU ID may be included in the UL Uu SRAP header so that the gNB can correlate received packets for a specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU. In addition, the PC5 SRAP sublayer at the L2 U2N remote WTRU may support UL bearer mapping between the remote WTRU Uu radio bearer and the egress PC5 relay RLC channel.

[0087] For L2 U2N relay, for the downlink, in an example embodiment, the Uu SRAP sublayer may support DL bearer mapping at the gNB to map the remote WTRU's end-to-end radio bearers (SRBs, DRBs) to the Uu relay RLC channel over the relay WTRU Uu interface. The Uu SRAP sublayer may support DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of an L2 U2N remote WTRU and / or different L2 U2N remote WTRUs and one Uu relay RLC channel over the relay WTRU Uu interface. The Uu SRAP sublayer may support remote WTRU identification for DL traffic. The remote WTRU Uu radio bearer identity information and the local remote WTRU ID may be included in the Uu SRAP header by the gNB in 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. Furthermore, in one example, the PC5 SRAP sublayer at the relay WTRU may support DL bearer mapping between the ingress Uu relay RLC channel and the egress PC5 relay RLC channel. Furthermore, the PC5 SRAP sublayer at the remote WTRU may correlate received packets with a specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU based on the identity information contained in the Uu SRAP header.

[0088] In various embodiments, the local remote WTRU ID may be included in both the PC5 SRAP header and the Uu SRAP header. The L2 U2N relay WTRU is configured by the gNB with the local remote WTRU ID for use in the SRAP header. The remote WTRU may obtain the local remote ID from the gNB via Uu RRC messages including RRC setup, RRC reconfiguration, RRC resume, and RRC establishment. Uu DRB(s) and Uu SRB(s) may be mapped to different PC5 relay RLC channels and Uu relay RLC channels in both the PC5 hop and the Uu hop.

[0089] In various embodiments, the gNB is responsible for avoiding conflicts in the use of Local Remote WTRU IDs. The gNB may update the Local Remote WTRU ID by sending the updated Local Remote ID to the relay WTRU via an RRC reconfiguration message. The serving gNB may perform the Local Remote WTRU ID update independently of the PC5 unicast link L2 ID update procedure.

[0090] Service Continuity with SL Relay: In the context of sidelink (SL) relay, some service continuity support may be supported (within the same gNB). Specifically, in various embodiments, examples of a WTRU switching a communication link (or path) between (i) an indirect link / path to a direct link and / or (ii) from a direct link / path to an indirect link may be supported. For clarification, note that an "indirect" link or path generally refers to a remote WTRU connecting to a gNB using a relay WTRU.

[0091] refer to Figure 5 , a method 500 for WTRU indirect-to-direct link handover is shown. The exchange sequence between entities used by a WTRU to switch a packet flow from an indirect path to a direct path to a gNB is shown and described. For service continuity of L2 U2N relays, the following procedure may be used when a U2N remote WTRU switches to a direct path.

[0092] As shown, at 502, data flows between a remote WTRU and a gNB via an indirect link through a relay WTRU. A Uu measurement configuration and measurement report signaling procedure 504 may be performed to evaluate both relay link measurements and Uu link measurements. When the configured measurement reporting criteria are met, the measurement results from the WTRU to the network (U2N) remote WTRU are reported. The sidelink relay measurement report 504 may include at least the source L2 ID of the U2N relay WTRU, the serving cell ID (i.e., NCGI), and sidelink measurement quantity information. The sidelink measurement quantity may be the sidelink reference signal received power (SL-RSRP) of the serving U2N relay WTRU, and if SL-RSRP is not available, SD-RSRP is used. At 506, the gNB decides to handover the U2N remote WTRU to a direct Uu path. At 508, after receiving the RRC reconfiguration message 508 from the gNB, the gNB sends an RRC reconfiguration message to the U2N remote WTRU, and the U2N remote WTRU may stop UP and CP transmission via the U2N relay WTRU.

[0093] Next, the U2N remote WTRU synchronizes with the gNB and performs random access 510. The WTRU (i.e., the U2N remote WTRU in the previous step) may send an RRC Reconfiguration Complete 512 to the gNB via a direct path using the configuration provided in the RRC Reconfiguration message. From this step on, the WTRU (i.e., the U2N remote WTRU in the previous step) uses an RRC connection via a direct path to the gNB.

[0094] The gNB may send an RRC reconfiguration message 514 to the U2N relay WTRU to reconfigure the connection between the U2N relay WTRU and the gNB. Based on the gNB implementation, the RRC reconfiguration message 514 may be sent to the U2N relay WTRU at any time after step 508 (e.g., to release the Uu and PC5 relay RLC channel configurations for the relay and the bearer mapping configuration between the PC5 RLC and the Uu RLC).

[0095] Next, the U2N relay WTRU or the U2N remote WTRU may initiate a PC5 unicast link release (PC5-S) 516. The timing of performing the link release 516 may depend on the WTRU implementation. The U2N relay WTRU may perform a PC5 connection reconfiguration to release the PC5 relay RLC channel for the relay upon receiving the RRC reconfiguration from the gNB in 514, or the WTRU (i.e., the former U2N remote WTRU) may perform a PC5 connection reconfiguration to release the PC5 relay RLC channel for the relay upon receiving the RRC reconfiguration from the gNB in 508.

[0096] The data path 518 switches from an indirect path to a direct path between the WTRU (i.e., the previous U2N remote WTRU) and the gNB, i.e., without the need for a relay WTRU. DL / UL lossless delivery during the path switch may be performed according to the PDCP data recovery procedure. It should be appreciated that step 518 may be performed at any time after step 510 and, therefore, may be independent of steps 514 and 516.

[0097] refer to Figure 6 , a method 600 for WTRU direct-to-indirect link switching is shown and described, along with an example exchange sequence between entities for a WTRU to switch a packet flow from a direct path to an indirect path to a gNB with service continuity. In various embodiments, the gNB may select a U2N relay WTRU in any RRC state (i.e., RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED) as the target U2N relay WTRU for direct-to-indirect path switching. For service continuity of an L2 U2N remote WTRU, in the event that an L2 U2N remote WTRU switches to an indirect path via a U2N relay WTRU in RRC_CONNECTED, the following process 600 may be used:

[0098] exist Figure 6In the example of FIG. 6 , a WTRU (designated as a remote UE) may send or receive data 602 directly to the gNB. The WTRU may report 604 one or more candidate U2N relay WTRUs and Uu measurements, and thereafter measure / discover the candidate U2N relay WTRU(s). In one embodiment, before reporting 604, the WTRU may filter the appropriate U2N relay WTRU(s) based on, for example, relay selection criteria. For example, the WTRU may report 604 only the U2N relay WTRU candidate(s) that meet certain higher layer criteria. In certain embodiments, the report 604 may include the U2N relay WTRU ID, the serving cell ID of the U2N relay WTRU, and sidelink measurement quantity information. The sidelink measurement quantity may be the SL-RSRP of the candidate U2N relay WTRU, and if SL-RSRP is not available, SD-RSRP may be used.

[0099] Next, the gNB may decide to hand over the direct link with the WTRU to the target U2N relay WTRU 606. If so, the gNB sends an RRC reconfiguration message 608 to the target U2N relay WTRU, which may preferably include the local ID and L2 ID of the remote WTRU, the Uu and PC5 relay RLC channel configuration for the relay, and the bearer mapping configuration.

[0100] The gNB may send an RRC reconfiguration message 610 to the U2N remote WTRU. In one embodiment, the content in the RRC reconfiguration message 610 may include the U2N relay WTRU ID, the PC5 relay RLC channel configuration for relay traffic, and the associated end-to-end radio bearer(s). After receiving the RRC reconfiguration message 610 from the gNB, the U2N remote WTRU may stop UP and CP transmission over the Uu.

[0101] The WTRU may then establish a PC5 / D2D connection with the target U2N relay WTRU 612. The U2N remote WTRU may complete the path switching process by sending an RRC reconfiguration complete message to the gNB via the relay WTRU 614. The data path is switched 616 from a direct path between the U2N remote WTRU and the gNB to an indirect path via the relay WTRU.

[0102] In the case where the selected U2N relay WTRU for direct to indirect path handover is in RRC_IDLE or RRC_INACTIVE mode, upon receiving the path switch command, the U2N remote WTRU establishes a PC5 link with the U2N relay WTRU 612 and sends an RRC reconfiguration complete message 614 via the U2N relay WTRU, which will trigger the U2N relay WTRU to enter the RRC_CONNECTED state. Figure 6The procedure for a U2N remote WTRU to switch to an indirect path may also be applied when the selected U2N relay WTRU for direct to indirect path handover is in RRC_IDLE or RRC_INACTIVE, where step 612 is performed before step 608 if necessary.

[0103] 3GPP has agreed to continue enhancing the NR SL relay specification in Rel-18, which expands the service continuity scenarios. The study items include specifying mechanisms to enhance service continuity for single-hop Layer 2 WTRUs to network relays for the following scenarios for RAN 2 and RAN3 working groups: A.) Inter-gNB indirect to direct path handover (i.e., “Remote WTRU <-> Relay WTRU A <-> gNB X” to “Remote WTRU <-> gNB Y”); B.) Inter-gNB direct to indirect path handover (i.e., “remote WTRU <-> gNB X” to “remote WTRU <-> relay WTRU A <-> gNB Y”); C.) Intra-gNB indirect to indirect path handover (i.e., “Remote WTRU <-> Relay WTRU A <-> gNB X” to “Remote WTRU <-> Relay WTRU B <-> gNB X”); and D.) Inter-gNB indirect to indirect path handover (i.e., “Remote WTRU <-> Relay WTRU A <-> gNB X” to “Remote WTRU <-> Relay WTRU B <-> gNB Y”).

[0104] The last scenario (D) can be supported by using solutions from other scenarios without specific optimizations.

[0105] In various embodiments, the PDCP layer provides its services to the RRC (in the CP) or SDAP (in the UP) layer. PDCP can provide the following functions: - Transmission of data (user plane or control plane); - Maintain PDCP Sequence Number (SN); - Header compression and decompression - Security (encryption and integrity protection during transmission and decryption and integrity verification during reception) -Timer-based SDU discard; -repeat; - Reordering and in-sequence delivery; - Unordered delivery; -Duplicate discard.

[0106] refer to Figure 7, shows a logical diagram 700 of PDCP entities for a relay WTRU. In certain embodiments, there may be a PDCP entity 710, 750 associated with each radio bearer (SRB or DRB) and having a transmitting entity 710 and a receiving entity 750.

[0107] The PDCP entity associated with the DRB may be configured with a discard timer (discardTimer) or some other means of measuring the discard period. This timer specifies the maximum amount of time a packet is stored in the transmit buffer. That is, each time a new packet is received from an upper layer, a new period with a value equal to the discardTimer is started. When the discard period for a PDCP service data unit (SDU) expires, or when successful delivery of the PDCP SDU is confirmed by receipt of a PDCP status report, the transmitting PDCP entity 710 discards the PDCP SDU along with the corresponding PDCP data PDU.

[0108] Therefore, even after the PDCP SDU is passed to the RLC for transmission, the packet may be stored in the PDCP transmit buffer 712. This is useful for failure recovery situations, such as re-establishment after a radio link failure (RLF). In this case, the WTRU may re-establish the PDCP entity, which may result in the transmission of the SDUs still in the PDCP transmit buffer 712.

[0109] When upper layers request the PDCP entity to re-establish, for UM DRB and AM DRB, the transmitting PDCP entity 710 will reset the uplink Robust Header Compression (ROHC) protocol and start with the IR state in U mode if dRB-ContinueROHC is not configured.

[0110] During HO, the WTRU may receive an indication to re-establish PDCP for one or more of its bearers. This is indicated to the WTRU in the RRC reconfiguration message (i.e., HO command) by including a Re-establish PDCP IE (Information Element) for each relevant DRB or SRB configuration (e.g., in the DRB-ToAddMod or SRB-ToAddMod IE included in the RadioBearerConfig).

[0111] Consider indirect to indirect path switching between gNBs, as shown in the reference Figure 8-10 . Figure 8 An example network architecture 800 is shown showing a remote WTRU 805 performing a handover from a relay WTRU 810 to a target relay WTRU 815 (i.e., switching from an indirect link with a source gNB 820 to an indirect link with a target gNB 825). Figure 9 A corresponding method 900 for an indirect link to indirect link handover is shown. Initially, a remote WTRU communicates with a source gNB via an indirect link via a source relay WTRU 902. After measuring and reporting 904, the source gNB may determine 906 that a handover should be performed to a target gNB via a target relay WTRU. The source gNB and target gNB confirm the handover using a HO request message 908 and a confirmation message 910. The RRC of the target relay WTRU is updated via messaging 912, and the RRC of the source relay WTRU and the remote WTRU are updated for the HO via messaging 914. The handover to the target relay WTRU and target gNB is completed via messaging 916-922.

[0112] refer to Figure 10 , shows an example buffer 1000 for the remote WTRU. Assume that by the time the HO command is received at the remote WTRU (i.e., Figure 9 914), the PDCP buffer at the remote WTRU looks like Figure 10 The example buffer 1000 shown in FIG. 1000 (where N(x), where x=1-6, represents the PDCP PDU sequence number). Figure 10 Assume the following: (i) some or all RLC packets corresponding to N6 are pending transmission between the remote WTRU and the source relay WTRU, (ii) all RLC packets corresponding to packets N1 to N5 are received at the source relay WTRU, (iii) all RLC packets corresponding to packets N1 to N3 are received at the source gNB, and (iv) some or all RLC packets corresponding to N4 and N5 are not received at the source gNB (i.e., pending transmission between the source relay WTRU and the source gNB).

[0113] From the remote WTRU's perspective, packets N1 to N5 have been successfully transmitted because they were all acknowledged at the RLC level by the source relay WTRU. Therefore, when the remote WTRU receives the HO command, which typically contains an indication to re-establish the PDCP bearer, the remote WTRU will not see the difference in the status of packets N1-N3 and N4-N5 and will only retransmit N6 to the target because this is the only packet that was not acknowledged at the RLC level by the source relay WTRU.

[0114] If the source relay WTRU and the source gNB still have good connectivity to each other, the RLC packets corresponding to N4 and N5 will eventually be received by the source gNB, which can then forward them to the target gNB. However, this may not be possible or desirable for several reasons, for example, (i) the HO of the remote WTRU may be triggered due to problems on the Uu link between the source relay WTRU and the source gNB (e.g., RLF, congestion, very low signal level, etc.); (ii) by the time the packets are received at the source gNB, the source gNB may have released the WTRU context or may have released the Xn tunnel towards the target gNB to forward the packets (i.e., the source gNB considers the HO complete); (iii) even if forwarding is possible, the packets may be received out of order (e.g., N6 may have been received earlier at the target gNB), which may cause performance issues at the application layer (e.g., TCP may trigger a send / receive window reduction and therefore a throughput penalty because it may assume that out-of-order reception is an indication of packet loss); and / or (iv) if in-order delivery is configured on the gNB side, UL data may be interrupted while the target gNB waits for the missing packets.

[0115] The scenario is similar in the DL direction. That is, the RLC packets corresponding to the PDCP packets sent by the source gNB may have been acknowledged by the source relay WTRU, but they may be pending transmission to the remote WTRU via the sidelink. The network can address this issue to some extent through implementation. For example, in one embodiment, the source gNB holds the packets in its transmit buffer for an extended period of time (e.g., setting a longer discard timer). Alternatively or additionally, when the target gNB obtains a PDCP status report from the WTRU during the HO (triggered by the WTRU when it receives a PDCP re-establishment indication in the HO command), it will identify the missing packets. In addition, the target gNB may request the source gNB to send these missing packets.

[0116] However, these options may be inefficient because they may impose large buffer size requirements at the gNB, and the packet reordering problem described for the UL case may still exist (e.g., the target gNB may have forwarded packets with higher SNs to the remote WTRU before receiving these lost packets, so the WTRU's application layer (e.g., TCP) may have overreacted by reducing the receive window size). Even if the WTRU is configured with in-order delivery, the problem may be alleviated, but at the expense of some service interruption while the WTRU waits for the lost packets, which may actually be futile because these lost packets may never arrive.

[0117] For example, reference Figure 11Examples of other embodiments that provide more desirable results are described. Here, Figure 8 Architecture 800 and Figure 9 Similar to method 900, a HO is performed from an indirect link toward a source gNB to a direct or indirect link toward another gNB. It is worth noting that various solutions may be applicable to other scenarios, such as: inter-gNB indirect to direct HO; intra-gNB indirect to direct HO; intra-gNB indirect to indirect HO; and / or other relay scenarios, such as an integrated access backhaul (IAB) network.

[0118] In the example embodiments below, the term sidelink (SL) is primarily used to refer to the PC5 interface between the relay WTRU and the remote WTRU. However, all solutions are equally applicable to other possible interfaces between the remote WTRU and the relay WTRU, such as proprietary interfaces, wired interfaces, etc. Furthermore, the embodiments are also applicable to the case of conditional handover, where the remote WTRU is pre-configured with a HO command and the command is applied when some triggering condition is met (e.g., the radio conditions towards the target link are better than the source link by a certain threshold / margin).

[0119] This document discusses scenarios where a relay WTRU delays sending an SL RLC acknowledgment until it is received over the backhaul Uu. In one embodiment, the relay WTRU sends an RLC acknowledgment over the SL only when the corresponding RLC packet is acknowledged by the gNB over the backhaul Uu. In a first example embodiment, the relay WTRU applies this behavior to all RLC packets / channels. In another example embodiment, the relay WTRU applies this behavior only to certain RLC channels (e.g., pre-configured by the gNB when setting up an indirect path).

[0120] In yet another example embodiment, the relay WTRU applies this behavior based on the radio link conditions on the backhaul Uu and / or the radio link conditions (or congestion) on the SL towards the remote WTRU. For example, when the backhaul Uu signal level is equal to or above a certain threshold, the relay WTRU may apply the legacy behavior (i.e., send RLC ACKs on the SL without waiting for their reception on the backhaul Uu), and when the backhaul Uu signal level is below the threshold, apply the new behavior (i.e., wait until reception on the backhaul Uu before sending RLC ACKs on the SL). In accordance with these example embodiments, a variant solution may include the relay WTRU being configured to apply different signal level thresholds (e.g., for the backhaul Uu, for the SL, etc.) or congestion thresholds of the SL for different RLC channels.

[0121] In another example embodiment, the relay WTRU may be configured with a maximum time to wait for an ACK on the backhaul Uu before sending an ACK over the SL. For example, if this duration is set to 20ms, then if 20ms has passed after receiving the RLC packet on the SL, the relay WTRU will send an RLC ACK over the SL even if it has not received an ACK for the RLC packet over the backhaul Uu. In a variation of this solution, the relay WTRU may include an additional flag / indication in the RLC ACK that it sends to the remote WTRU upon expiration of the time period, indicating to the remote WTRU that the RLC packet has not been received at the gNB.

[0122] In another example embodiment, the WTRU is configured with one maximum wait time value and it is applied to each RLC packet for each RLC channel. In an alternative embodiment, the WTRU is configured with multiple maximum wait time values (e.g., a specific wait time value for each RLC channel). According to yet another example embodiment, the relay WTRU may apply different maximum wait times based on the backhaul link quality and / or SL condition / congestion or SL type (e.g., if the SL is a PC5 interface, one wait time is applied and if the SL is another proprietary interface, another wait time is applied).

[0123] This document discusses procedures for a relay WTRU to send additional indications of receipt of RLC packets over the backhaul Uu. In one of these embodiments, the relay WTRU may send RLC ACKs on the SL without waiting for their successful transmission over the Uu backhaul (i.e., as in the conventional case), but in addition, it sends another indication to the remote WTRU regarding the receipt of the corresponding RLC packets over the backhaul Uu.

[0124] In one solution, an indication of successful or unsuccessful transmission on the backhaul Uu is sent in an RLC Status PDU. For example, the legacy RLC Status PDU may be enhanced, or a new RLC Status PDU may be specified that implicitly or explicitly indicates that an RLC packet has or has not been received at the gNB. In yet another embodiment, the relay WTRU simply forwards the RLC Status PDU it is receiving on the backhaul Uu from the gNB to the remote WTRU.

[0125] Another example is a relay WTRU that modifies the RLC Status PDU it receives from the gNB over the backhaul Uu before forwarding it to the remote WTRU. For example, the relay WTRU may change the RLC sequence number indicated in the Status PDU from the gNB to the sequence number of the corresponding packet on the SL. This is particularly useful because the sequence numbers of the RLC packets on the SL and the backhaul Uu may be different. One such example is when a relay WTRU relays data for several WTRUs and the RLC channel on the backhaul Uu may multiplex data from several WTRUs.

[0126] In one example solution, an additional indication of the reception of RLC packets over the Uu is sent to the remote WTRU via signaling other than the RLC Status PDU. For example, using a MAC CE, an SRAP Control PDU, in a protocol header associated with data transmitted in the opposite direction, or on a physical channel resource (e.g., PSFCH). In certain embodiments, the relay WTRU applies one or more of the above-described behaviors (sending information about packets received at the gNB) to all RLC packets, or the relay WTRU applies one or more of the above-described behaviors (sending information about packets received at the gNB) only to some RLC channels (e.g., preconfigured by the gNB when setting up an indirect path).

[0127] In an alternative embodiment, the relay WTRU applies one or more of the above indications based on the radio link conditions on the backhaul Uu and / or the radio link conditions (or congestion) on the SL towards the remote WTRU. For example, when the backhaul Uu signal level is equal to or above a certain threshold, the relay WTRU may apply the legacy behavior (i.e., no additional information about the packets sent to the remote WTRU being received at the gNB), and when the backhaul Uu signal level is below the threshold, the new behavior may be applied. In a variation of the above solution, the relay WTRU may be configured to apply different signal level thresholds (e.g., for backhaul Uu, for SL, etc.) or congestion thresholds for the SL for different RLC channels.

[0128] In some embodiments of multi-hop relay, the relay WTRU may send an indication of successful transmission of the RLC PDU only if one of the following conditions is met: (i) the relay WTRU transmits directly to the gNB and the RLC PDU is successfully transmitted; or (ii) the relay WTRU transmits to a second relay WTRU and receives an indication from the second relay WTRU that the RLC PDU is successfully transmitted.

[0129] In some embodiments, the relay WTRU may buffer / store RLC packets received over the SL and delete them only when the corresponding RLC packets are successfully received at the gNB. According to another embodiment, the relay WTRU will determine whether the RLC packet is one of the segments of a certain PDCP packet (e.g., by looking at the segment information and segment offset fields of the RLC packet header), and if so, will keep storing / buffering the SL RLC packet even if the corresponding RLC packet for that particular SL RLC packet is successfully received at the gNB, as long as no other related segments are still received at the gNB. For example, assume that a PDCP packet is segmented into 3 SL RLC packets at the remote WTRU, and 2 of the RLC packets have been successfully received at the gNB. The relay WTRU will save all 3 RLC packets until the 3rd RLC packet is also successfully received at the gNB.

[0130] In another embodiment, in accordance with any of the above solutions, the relay WTRU will keep buffering RLC packets for some configured time period. For example, whenever the relay WTRU receives an RLC packet on the SL, it may start a timer period, and if the time period expires before it has determined that the corresponding RLC packet on the Uu has not been successfully received at the gNB, it will delete the RLC packet. For the case of RLC segments, the relay WTRU may start the time period upon receipt of one of the RLC segments (e.g., the first segment, any intermediate or last segment if there is out-of-order reception), rather than starting the timer for each RLC segment. Alternatively, the relay WTRU may start the time period only upon receipt of all RLC segments for a certain PDCP PDU. In another example, the relay WTRU may adjust the time period duration value for keeping the SL RLC packets buffered based on the radio link conditions on the backhaul Uu and / or the radio link conditions (or congestion) on the SL towards the remote WTRU. In a variation of the foregoing embodiment, the relay WTRU may be configured to apply different signal level thresholds for SL / Uu and / or congestion thresholds and / or latency values for SL for different RLC channels.

[0131] In certain embodiments, according to one of the aforementioned embodiments, the remote WTRU, upon HO and re-establishment of PDCP, shall retransmit PDCP PDUs / SDUs that have not been indicated as received by the gNB (i.e., unlike legacy behavior, as some packets that have been acknowledged on the SL may be retransmitted towards the target).

[0132] In an example embodiment, according to one of the above solutions, upon HO and re-establishment of PDCP, the remote WTRU shall retransmit all PDCP PDUs / SDUs in the transmit buffer (i.e., those for which the discard time has not expired), regardless of the reception status at the source relay WTRU (e.g., SL RLC ACK) or indications regarding the reception status at the gNB.

[0133] In another example, the remote WTRU may adjust the value of the discard time period to be applied to the PDCP packets based on the backhaul Uu radio conditions (e.g., reported from the relay WTRU or gNB to the remote WTRU) and / or the SL radio conditions and / or the SL congestion (e.g., CBR). For example, when the radio conditions on the backhaul are good, the discard timer may be shortened, and when the radio conditions on the backhaul are poor, the discard time period may be extended.

[0134] The remote WTRU may be configured with a new timer (e.g., discard_timer_backhaul) that the WTRU starts running for each PDCP packet upon detecting successful reception at the relay WTRU (e.g., an indication from lower layers or an RLC status PDU from the relay WTRU indicating that all RLC packets corresponding to the PDCP packet have been successfully received at the relay WTRU). If the remote WTRU performs a handover and re-establishes PDCP, it will retransmit all PDCP packets that still have their timers running.

[0135] In one solution, the remote WTRU adjusts the value of this timer based on the backhaul Uu radio conditions (e.g., reported from the relay WTRU or gNB to the remote WTRU) or / and SL radio conditions or / and SL congestion (e.g., CBR). In another solution, if the remote WTRU receives an indication from the relay WTRU that the packet has been correctly received at the gNB according to any of the above solutions (e.g., an indication received from the relay WTRU indicates that all RLC packets corresponding to the PDCP packet have been successfully received at the gNB), it may stop the discard_timer_backhaul. Alternatively or additionally, if the PDCP discard timer expires even before successful reception on the SL is determined, the remote WTRU may discard the packet.

[0136] Various embodiments may include that if the PDCP discard time period has not expired when successful reception on the SL is determined, the remote WTRU may stop the discard timer and start a discard_timer_backhaul for the packet. Another embodiment may set the PDCP discard time period to infinity, or some practical equivalent of infinity, so that the WTRU never deletes the packet until, for example: (i) it has received a status PDU from the gNB indicating correct reception of the packet or (ii) the WTRU has received an indication from the relay WTRU that the packet has been received at the gNB (e.g., an indication received from the relay WTRU that all RLC packets corresponding to the PDCP packet have been successfully received at the gNB); or (iii) the discard_timer_backhaul that was started when the relay WTRU indicated successful reception has expired.

[0137] Another example solution includes the remote WTRU, when performing a HO, sending a request to the relay WTRU instructing it to send any buffered SL RLC packets (e.g., buffered at the relay WTRU according to any of the solutions described above). Upon receiving these RLC packets, the remote WTRU can then extract the PDCP SDUs, re-encrypt and integrity-protect them using the security context associated with the target gNB, and retransmit them to the target.

[0138] In another embodiment, the relay WTRU may proactively send buffered SL RLC packets to the remote WTRU without an explicit request from the remote WTRU. For example, upon detecting a problem on the backhaul Uu link (e.g., RLF) or handover to another gNB, the relay WTRU may send all buffered SL RLC packets to the remote WTRU (e.g., along with an indication of the reason for doing so, such as an indication of HO, RLF, etc.). In one example, when the remote WTRU later performs a HO or connection re-establishment, it may retransmit the PDCP SDUs extracted from these RLC packets (e.g., the relay WTRU's indication of RLF on the backhaul may trigger a CHO or re-establishment at the remote WTRU).

[0139] This document discusses a relay WTRU delaying the transmission of a Uu RLC ACK until it is received over the SL. In one embodiment, the relay WTRU may send an RLC ACK over the Uu only if the corresponding RLC packet is acknowledged by the remote WTRU over the SL. In another embodiment, the relay WTRU applies this behavior to all RLC packets / channels. In another embodiment, the relay WTRU may send an RLC ACK over the Uu only for certain RLC channels (e.g., pre-configured by the gNB when setting up the indirect path).

[0140] In some embodiments, the relay WTRU applies this behavior only to certain remote WTRUs (e.g., preconfigured by the gNB when the indirect path is set up and identified at the SRAP level when the relay WTRU receives the packet). In another solution, the relay WTRU applies the behavior based on the radio link conditions on the backhaul Uu and / or the radio link conditions (or congestion) on the SL towards the remote WTRU. For example, when the SL radio link level is equal to or above a certain threshold, or / and when the SL CBR is below a certain threshold, the relay WTRU may apply the legacy behavior (i.e., send RLC ACKs on Uu without waiting for their reception on SL). And when the SL radio link level is below a certain threshold or / and when the SL CBR is above a certain threshold, the relay WTRU may apply the new behavior (i.e., wait until reception on SL before sending RLC ACKs on Uu). In a variation of these embodiments, the relay WTRU may be configured to apply different signal level thresholds (e.g., for backhaul Uu, for SL, etc.) or CBR thresholds for SL for different RLC channels. In another variation, the relay WTRU may be configured to apply different signal level thresholds (eg, for backhaul Uu, for SL, etc.) or CBR thresholds for SL for processing ACKs for RLC packets destined for different remote WTRUs.

[0141] In some embodiments, the relay WTRU may be configured with a maximum time to wait for an ACK on the SL before sending an RLC ACK over the Uu. For example, if this duration is set to 20ms, the relay WTRU will send an RLC ACK over the Uu even if it has not received an ACK for the RLC packet over the SLu, if 20ms has passed after receiving the packet over the Uu. In a variation of this solution, the relay WTRU may include an additional flag / indication in the RLC ACK, which is sent to the gNB when the timer expires, indicating to the gNB that the RLC packet has not been received at the remote WTRU. In one embodiment, the relay WTRU is configured with one maximum wait time value, and it is applied to each RLC packet for each RLC channel. In another embodiment, the relay WTRU is configured with multiple maximum wait time values (e.g., a specific wait time value for each RLC channel).

[0142] In other embodiments, the wait time value may be remote WTRU specific. In one example, a relay WTRU may be configured with a specific wait time for each remote WTRU it serves (e.g., one specific value for each remote WTRU shared across all SL RLC channels). In another example, a relay WTRU may be configured with multiple wait times for each remote WTRU, each wait time corresponding to a specific RLC channel.

[0143] This document discusses the relay WTRU sending additional indications of RLC packet reception over the SL. According to one embodiment, the relay WTRU may send RLC ACKs over the Uu without waiting for their successful transmission over the SL (i.e., as in legacy), but in addition, it sends another indication to the gNB regarding the reception of the corresponding RLC packets over the SL. In certain embodiments, the indication of successful or unsuccessful transmission over the SL is sent in an RLC Status PDU. For example, the legacy RLC Status PDU may be enhanced, or a new RLC Status PDU may be specified that implicitly or explicitly indicates that the RLC packet has also been received at the remote WTRU or has not yet been received. In other embodiments, the relay WTRU simply forwards the RLC Status PDU it obtained over the SL from the remote WTRU to the gNB.

[0144] In some embodiments, the relay WTRU modifies the RLC Status PDU it is receiving from the remote WTRU over the SL before forwarding it to the gNB. For example, the relay WTRU may change the RLC sequence number indicated in the Status PDU from the WTRU to the sequence number of the corresponding packet on the Uu. This is particularly useful when the sequence numbers of the RLC packets on the Uu and SL Uu may be different. One such example is when the relay WTRU is relaying data for several WTRUs and the RLC channel on the backhaul Uu may multiplex data from several WTRUs.

[0145] According to an example embodiment, an additional indication of the receipt of RLC packets over the SL is sent to the gNB via signaling other than an RLC Status PDU. For example, it may be: (i) a MAC CE; or (ii) an SRAP Control PDU. In various embodiments, the relay WTRU applies one or more of the above-described behaviors (sending information about the receipt of packets at the remote WTRU) to all RLC packets. Alternatively, the relay WTRU applies one or more of the above-described behaviors (sending information about the receipt of packets at the remote WTRU) only to some RLC channels (e.g., pre-configured by the gNB when setting up an indirect path).

[0146] In an example embodiment, the relay WTRU sends information about packets received at the remote WTRU only to some remote WTRUs (e.g., those preconfigured by the gNB when the indirect path is set up and identified at the SRAP level when the relay WTRU receives the packet), as described in the previous example.

[0147] In an example embodiment, a relay WTRU sends information about packet reception at a remote WTRU based on radio link conditions on the backhaul Uu and / or radio link conditions (or congestion) on the SL towards the remote WTRU. For example, when the SL radio link level is equal to or above a certain threshold, or / and when the SL CBR is below a certain threshold, the relay WTRU may apply a conventional behavior (i.e., no additional information about the reception of packets sent to the gNB at the remote WTRU). And when the SL radio link level is below a certain threshold or / and when the SL CBR is above a certain threshold, the relay WTRU may apply a new behavior. In a modified example, the relay WTRU may be configured to send reception information by applying different signal level thresholds (e.g., for backhaul Uu, for SL, etc.) or CBR thresholds for SL for different RLC channels. In other examples, the relay WTRU may be configured to apply different signal level thresholds (e.g., for backhaul Uu, for SL, etc.) or CBR thresholds for SL for different remote WTRUs to determine whether to send additional information about packets received by the remote WTRU.

[0148] For some embodiments of the present disclosure, the relay WTRU will buffer / store RLC packets received over Uu and delete them only when the corresponding RLC packets are successfully received at the remote WTRU. In one example solution, the relay WTRU will determine whether the RLC packet is one of the segments of a certain PDCP packet (e.g., by looking at the segment information and segment offset fields of the RLC packet header), and if so, will keep the Uu RLC packet stored / buffered even if the corresponding RLC packet for that particular RLC packet is successfully received at the remote WTRU, as long as any other related segments have not yet been received at the WTRU. For example, assume that a PDCP packet is segmented into three Uu RLC packets at the gNB, and two of the RLC packets have been successfully received at the remote WTRU. The relay WTRU will save all three RLC packets until the third RLC packet is also successfully received at the remote WTRU.

[0149] In another embodiment, in accordance with any of the above solutions, the relay WTRU will keep buffering RLC packets for a certain configured time. For example, whenever an RLC packet is received over Uu, the relay WTRU may start a timer, and if the timer expires before it has determined that the corresponding RLC packet over SL has not been successfully received at the remote WTRU, it will delete the RLC packet. For the case of RLC segments, the relay WTRU may start a timer upon receiving one of the RLC segments (e.g., the first segment, any intermediate or last segment if there is out-of-order reception), rather than starting a timer for each RLC segment. Alternatively, the relay WTRU may start a timer only upon receiving all RLC segments for a certain PDCP PDU. In a variation of this solution, the relay WTRU may be configured to apply different SL / Uu signal level thresholds and / or SL congestion thresholds and / or wait time values for different RLC channels. In another variation, the relay WTRU may be configured to apply different SL / Uu signal level thresholds and / or SL congestion thresholds and / or wait time values for different remote WTRUs.

[0150] According to one embodiment, the relay WTRU may receive a request from the gNB to send any buffered Uu RLC packets (e.g., buffered at the relay WTRU according to any of the solutions described above) and send them accordingly. In one solution, the request for buffered Uu RLC packets from the gNB may include an indication of the remote WTRU's identity (e.g., WTRU L2 ID), and the relay WTRU sends only those buffered RLC packets associated with the indicated WTRU.

[0151] In additional embodiments, activation / deactivation of relay WTRU behavior is disclosed to prevent UL / DL packet loss during indirect to indirect / direct HO.

[0152] In various embodiments, sending RLC ACK on the SL is delayed until the corresponding RLC packet is successfully received at the gNB (for UL packets), or delaying sending RLC ACK on the Uu is performed until the corresponding RLC packet is successfully received at the remote WTRU (for DL packets) to help ensure that no UL / DL packet loss occurs when performing a HO from an indirect to an indirect / direct communication link. However, doing so generally may have undesirable consequences (e.g., increased RLC E2E latency leading to increased RLC window size requirements and, further, reduced throughput).

[0153] With respect to the embodiments that modify the relay WTRU behavior described above, other drawbacks may exist. For example, in addition to the potential issues with RLC window size and throughput for the RLC ACK delay scenario described above, sending a separate indication to the remote WTRU indicating receipt at the gNB (or vice versa for DL packets) may result in unnecessary signaling during normal operation (i.e., not before / after HO). For embodiments where the relay WTRU temporarily buffers SL RLC packets or Uu RLC packets for possible forwarding after HO, there is an overhead at the relay WTRU of continuously storing already acknowledged packets.

[0154] Therefore, there is a need for embodiments in which the relay WTRU modifies behavior (e.g., delaying RLC acknowledgment, sending a separate indication of receipt of the acknowledgment through the next hop, temporarily storing correctly acknowledged packets for possible forwarding after handover, etc.) only when necessary (e.g., in anticipation of handover).

[0155] The following embodiments are described for this purpose. In the following embodiments, for the sake of brevity, the focus is on the delay of RLC ACK, but all the following embodiments are applicable to all other solutions described herein.

[0156] In one embodiment, the relay WTRU may be configured to start delaying the RLC ACK (in either the UL or DL direction) only upon receiving an indication from the network. For example, the network may send an indication to the relay WTRU to start applying this behavior before the HO command is sent to the remote WTRU (e.g., some time before the network sends the HO command).

[0157] In another embodiment, the relay WTRU may be configured to apply a delay of the RLC ACK (in either the UL or DL direction) only when an indication is received from the remote WTRU. For example, the remote WTRU may be configured with a conditional handover (CHO) trigger condition with two thresholds, a first threshold for triggering the sending of an RLC delay indication to the relay WTRU, and a second threshold for actually triggering the CHO towards the target. For example, if the CHO is based on condA3 (target > source + threshold), the first threshold may be lower than the second threshold (i.e., the relay WTRU behavior is triggered in anticipation of an upcoming CHO trigger).

[0158] For an example embodiment, a relay WTRU that has begun applying delay of RLC ACK upon receiving an indication from the network may be configured to stop applying that behavior upon receiving a subsequent indication from the network or a remote WTRU instructing the relay WTRU to fall back to the traditional operation of sending RLC ACK that relies on only one hop.

[0159] In other embodiments, the relay WTRU may be configured to apply the delay of the RLC ACK only for a configured duration after receiving an indication from the network or the relay WTRU to start the delay, and to stop applying it thereafter (i.e., fall back to the legacy behavior of sending an RLC ACK without waiting for a corresponding ACK from the network). This duration may be included in the indication received from the network or the WTRU, or configured separately.

[0160] refer to Figure 11 , a method 1100 for triggering PDCP retransmission upon receiving a STATUS PDU after HO will be described. The method 1100 may generally begin after performing a handover 1105 of a remote WTRU from an indirect link with a source gNB to an indirect or direct link with a target gNB (e.g., after Figure 9 900 is completed). The remote WTRU receives 1110 a PDCP status PDU from the new gNB via a direct link or an indirect link via another relay WTRU to the new gNB. If 1115 the PDCP status report received from the new gNB is the first PDCP status report from the new gNB (or / and the status report is received within a given duration after the HO), the WTRU shall retransmit 1120 all packets indicated as not received in the PDCP status report, including previously sent packets that have been acknowledged as received from lower layers (e.g., an indication received from the source relay WTRU prior to the HO). If 1115 the PDCP status report received from the new gNB is not the first, e.g., second, third, etc., PDCP status report (or the report is received after a given duration has elapsed after the HO), the WTRU shall retransmit 1125 packets (if any) that were indicated as not received in the PDCP status report, excluding previously sent packets that were acknowledged as received by lower layers.

[0161] The reception of the Status PDU in conventional operation is only used by the WTRU PDCP transmitting entity to determine whether the PDCP SDU is to be discarded, even before the discard timer has expired, and therefore the remote WTRU does not take any transmit action for those PDUs indicated as not received. Therefore, in these embodiments, a retransmission behavior is introduced in PDCP (similar to RLC ARQ), but this is only triggered after HO (e.g., Figure 11 In addition, it should be noted that, similar to some of the above embodiments, as long as the PDCP SDU corresponding to the packet is still available at the transmit buffer (i.e., the discard timer of the packet has not expired), the packet can be discarded even if it is acknowledged at a lower layer ( Figure 11 1120), WTRU also retransmits the packet.

[0162] In a variation of the above embodiment, the WTRU applies the above behavior (i.e., retransmits acknowledged packets in the WTRU's PDCP buffer indicating that no PDCP Status PDU was received from the new eNB) only if the WTRU receives the first PDCP Status PDU after a HO (e.g., handover from an indirect link to a direct / indirect link). In another embodiment, the WTRU applies the above behavior only if the PDCP Status is received within a given configured duration after the HO.

[0163] According to certain embodiments, the WTRU applies the above-described behavior upon receiving a PDCP status with an explicit indication (e.g., a flag in the packet header, a status PDU using a new PDU format, etc.) instructing the WTRU to retransmit packets that were indicated as not received by the network. It should be appreciated that the aforementioned embodiments may also be applied in the DL direction. For example, a remote WTRU may send a PDCP status PDU after a HO to instruct the network to retransmit packets that were indicated as not correctly received.

[0164] Steering Figure 12 , shows a message sequence chart 1200 that describes the relevant embodiments in detail. Figure 12 1204 , the remote WTRU connects 1202 to the source gNB via the source relay WTRU. The remote WTRU sends 1204 a measurement report to the source gNB, which determines that a handover should be performed and sends 1206 a HO command (e.g., a path handover to the target gNB via the target relay WTRU). At 1208, the remote WTRU performs a HO to the target gNB, e.g., by any of the procedures previously discussed. When the remote WTRU sends 1210 a HO complete message to the target gNB via the target relay WTRU, the target gNB sends 1212 a PDCP status report to the remote WTRU. If the PDCP status report 1214 is the first report received after handover from the indirect link with the source relay WTRU, the remote WTRU retransmits 1216 all packets in its buffer that are indicated as not received at the target gNB, even those that are acknowledged at lower layers.

[0165] Although the features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware contained in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over 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 disks (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for a wireless transmit receive unit (WTRU), the method comprising: performing a handover (HO) from an indirect link to a source base station via a source relay WTRU to a direct or indirect link with a target base station, After the handover, receiving a Packet Data Convergence Protocol (PDCP) status report from the target base station; as well as Retransmitting PDCP packets in the WTRU's PDCP buffer that were indicated as not received in the received PDCP status report.

2. The method of claim 1 , wherein the PDCP packets retransmitted in the PDCP buffer of the WTRU include PDCP packets previously sent to the source relay WTRU and acknowledged by it.

3. The method according to claim 1, wherein Retransmitting the PDCP packet is performed only when a first PDCP status report is received from the target base station after the handover, or when the PDCP status report is received within a configured duration after the handover.

4. The method according to claim 1, wherein Retransmission of the PDCP packet is initiated by an explicit indicator present in the received PDCP status report.

5. The method according to claim 1, wherein The handover is to an indirect link with the target base station facilitated by the target relay WTRU.

6. The method according to claim 1, wherein The received PDCP status report includes a PDCP status PDU from the target base station, where the PDCP status PDU is transmitted via a direct link with the target base station or an indirect link between the target relay WTRU and the target base station.

7. The method according to claim 1, further comprising: After handover, one or more discard timers of PDCP packets in the WTRU's PDCP buffer are extended.

8. A wireless transmit receive unit (WTRU), comprising: A transceiver, a PDCP buffer, and a processor in communication with the transceiver and the PDCP buffer, the transceiver and the processor being configured to: performing a handover (HO) from an indirect link with a source relay WTRU to a direct or indirect link with a target base station, After the handover, receiving a Packet Data Convergence Protocol (PDCP) status report from the target base station; as well as The PDCP packets in the PDCP buffer indicated as not received in the received PDCP status report are retransmitted.

9. The WTRU of claim 8, wherein: The PDCP packets in the PDCP buffer of the retransmitting WTRU include PDCP packets previously sent to and acknowledged received by the source relay WTRU.

10. The WTRU of claim 8, wherein: Retransmitting the PDCP packet is performed only when a first PDCP status report is received from the target base station after the handover, or when the PDCP status report is received within a configured duration after the handover.

11. The WTRU of claim 8, wherein: Retransmission of the PDCP packet is initiated by an explicit indicator present in the received PDCP status report.

12. The WTRU of claim 8, wherein: The handover is to an indirect link with the target base station facilitated by the target relay WTRU.

13. The WTRU of claim 8, wherein: The received PDCP status report includes a PDCP status PDU from the target base station, where the PDCP status PDU is transmitted via a direct link with the target base station or an indirect link between the target relay WTRU and the target base station.

14. The WTRU of claim 8, wherein: The processor is further configured to extend one or more discard timers of PDCP packets in a PDCP buffer of the WTRU after the handover.

Images