Route identifier allocation for multi-hop user equipment to network relays

Abstract

In one aspect, a UE may obtain a first route ID for a first route between a first UE and a second UE. The UE may receive a data packet from a second UE originating from a third UE, the data packet indicating a first routing ID. The UE may identify a third UE based on the first routing ID indicated in the data packet. In another aspect, a network node may obtain a route ID for at least one first route between the network node and a first UE. A network node may receive an indication that a data packet received by the network node is received via a multi-hop route. The network node may receive a data packet originating from the second UE from the first UE based on the routing ID and the indication.

Description

Technical Field

[0001] This disclosure relates generally to communication systems, and more specifically to wireless communication utilizing multi-hops. Background Technology

[0002] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple access technologies include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Time Division Synchronous Code Division Multiple Access (TD-SCDMA) systems.

[0003] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol that enables different wireless devices to communicate at the city, national, regional, and even global levels. An example telecommunications standard is 5G New Radio (NR). 5G NR is part of the Continuous Evolution of Mobile Broadband (CEM) program issued by the 3rd Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with the Internet of Things (IoT),) and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLC). Some aspects of 5G NR can be based on the 4G Long Term Evolution (LTE) standard. Further improvements to 5G NR technology are needed. Furthermore, these improvements can also be applied to other multiple access technologies and telecommunications standards that adopt these technologies. Summary of the Invention

[0004] The following is a simplified summary of one or more aspects to provide a basic understanding of these aspects. This summary is not a comprehensive overview of all conceived aspects. It neither identifies key or essential elements of all aspects nor describes the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed descriptions that follow.

[0005] In one aspect of this disclosure, a method, computer-readable medium, and apparatus are provided at a first user equipment (UE). The apparatus may include at least one memory and at least one processor coupled to the at least one memory. The at least one processor may be configured, individually or in any combination and at least in part based on information stored in the at least one memory, to: obtain a first route identifier (ID) for a first route between the first UE and a second UE; receive a data packet originating from a third UE from the second UE, the data packet indicating the first route ID; and identify the third UE based on the first route ID indicated in the data packet.

[0006] In another aspect of this disclosure, methods, computer-readable media, and apparatuses at a network node are provided. The apparatus may include at least one memory and at least one processor coupled to the at least one memory. The at least one processor may be configured, individually or in any combination and at least in part based on information stored in the at least one memory, to: obtain a route ID for at least one first route between the network node and a first UE; receive an indication that data packets received by the network node were received via a multi-hop route; and receive data packets originating from a second UE from the first UE based on the route ID and the indication.

[0007] To achieve the foregoing and related objectives, one or more aspects may include the features fully described below and specifically pointed out in the claims. The following description and drawings set forth some exemplary features of one or more aspects in detail. However, these features indicate only a few of the various ways in which the principles of the various aspects may be employed. Attached Figure Description

[0008] Figure 1 This is a diagram illustrating an example of a wireless communication system and an access network.

[0009] Figure 2A This is an illustration of an example of the first frame according to various aspects of this disclosure.

[0010] Figure 2B This is a diagram illustrating examples of downlink (DL) channels within a subframe according to various aspects of this disclosure.

[0011] Figure 2C This is an illustration of an example of a second frame according to various aspects of this disclosure.

[0012] Figure 2D This is a diagram illustrating examples of uplink (UL) channels within a subframe according to various aspects of this disclosure.

[0013] Figure 3 This is a diagram illustrating examples of base stations and user equipment (UEs) in an access network.

[0014] Figure 4 This is a diagram illustrating a single-hop relay.

[0015] Figure 5 This is a diagram illustrating a multi-hop relay.

[0016] Figure 6 This is a diagram illustrating various interfaces that connect the UE and the network in a communicative manner.

[0017] Figure 7 This is a diagram illustrating the access layer protocol stack of the control plane used for radio resource control signaling.

[0018] Figure 8 This is a diagram illustrating the access layer protocol stack for the control plane used in PC5 signaling.

[0019] Figure 9A This is a diagram illustrating the control plane used for Layer 2 UE to network (U2N) relay.

[0020] Figure 9B This is a diagram illustrating the user plane used in Layer 2 U2N relays.

[0021] Figure 10 This is a diagram illustrating the format of an SRAP data packet data unit (PDU) with a Side Link Relay Adaptation Protocol (SRAP) header.

[0022] Figure 11 This is an example of a call flowchart illustrating a multi-hop relay using a unique per-hop identifier for a remote UE, according to various aspects of this disclosure.

[0023] Figure 12 This is a call flowchart illustrating various aspects of this disclosure of a multi-hop trunk utilizing a unique end-to-end (E2E) identifier for a remote UE.

[0024] Figure 13 This is a call flowchart illustrating various aspects of this disclosure of a multi-hop trunking call using a unique E2E identifier assigned by the network for a remote UE.

[0025] Figure 14 This is a call flowchart illustrating various aspects of wireless communication methods according to this disclosure.

[0026] Figure 15 This is a call flowchart illustrating various aspects of wireless communication methods according to this disclosure.

[0027] Figure 16 This is a call flowchart illustrating various aspects of wireless communication methods according to this disclosure.

[0028] Figure 17This is a flowchart illustrating various aspects of wireless communication methods according to this disclosure.

[0029] Figure 18 This is a flowchart illustrating various aspects of wireless communication methods according to this disclosure.

[0030] Figure 19 These are illustrations illustrating specific hardware implementations used for example devices and / or network entities.

[0031] Figure 20 This is a diagram illustrating an example of a hardware implementation used for an example network entity. Detailed Implementation

[0032] Referring to the accompanying drawings, various aspects of this disclosure relate generally to communication systems. Some aspects relate more specifically to multi-hop UE-to-network (U2N) relay. In some examples, a UE (e.g., a remote UE and / or a relay UE) may assign one or more routing identifiers (IDs) to one or more routes (or hops) via which the UE sends data to and / or receives data from another UE. Such routing IDs may be associated with a remote UE and may be indicated in data packets received by the UE. Thus, the UE may use the routing ID to determine whether a data packet originates from a remote UE or to determine whether the remote UE is the intended destination of the data packet. The routing ID may be unique for each hop in a multi-hop relay. Alternatively, the same routing ID may be used for each hop. In another example, a network node may assign a routing ID for each hop instead of the UE.

[0033] Specific aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. In some examples, by assigning a routing ID to a hop in a multi-hop relay and associating such a routing ID with a remote UE, the remote UE can be correctly identified by other UEs in the multi-hop relay. Therefore, the relay UE can be able to route the services of the remote UE to its correct destination (e.g., a network node), thereby enabling network coverage to extend to remote UEs outside the network's coverage area.

[0034] The detailed descriptions following, illustrated with reference to the accompanying drawings, describe various configurations and do not represent the only configurations in which the concepts described herein can be practiced. To provide a thorough understanding of the various concepts, the detailed descriptions include specific details. However, these concepts can be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring these concepts.

[0035] Various apparatuses and methods are presented with reference to several aspects of a telecommunications system. These apparatuses and methods are described in detail below and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively, “elements”). These elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole.

[0036] As an example, an element, any part of an element, or any combination of elements may be implemented as a "processing system" including one or more processors. When multiple processors are implemented, the multiple processors may perform functions individually or in combination. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, system-on-a-chip (SoCs), baseband processors, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionalities described throughout this disclosure. One or more processors in a processing system may execute software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or other terms, software should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, or any combination thereof.

[0037] Therefore, in one or more example aspects, specific implementations, and / or use cases, the described functionality may be implemented in hardware, software, or any combination thereof. If implemented in software, the functionality may be stored or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media. Storage media can be any available medium that can be accessed by a computer. By way of example, such computer-readable media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disc storage devices, magnetic disk storage devices, other magnetic storage devices, combinations of these types of computer-readable media, or any other medium that can be used to store computer-executable code in the form of instructions or data structures accessible by a computer.

[0038] While aspects, implementations, and / or use cases are described herein by way of example, additional or different aspects, implementations, and / or use cases may arise in many different arrangements and scenarios. The aspects, implementations, and / or use cases described herein can be implemented across many different platform types, devices, systems, shapes, sizes, and package arrangements. For example, aspects, implementations, and / or use cases may arise via integrated chip implementations and other devices based on non-modular components (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, AI-enabled devices, etc.). While some examples may or may not be specific to a use case or application, the described examples may exhibit broad applicability. Aspects, implementations, and / or use cases can range from chip-level or modular components to non-modular, non-chip-level implementations, and further to aggregated, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more of the technologies described herein. In some practical settings, devices incorporating the described aspects and features may also include additional components and features for implementing and practicing the claimed and described aspects. For example, the transmission and reception of wireless signals necessarily involve multiple components for analog and digital purposes (e.g., hardware components including antennas, RF chains, power amplifiers, modulators, buffers, processors, interleavers, adders / summers, etc.). The techniques described herein can be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, aggregated or decomposed components, end-user equipment, etc., of various sizes, shapes, and configurations.

[0039] Communication systems, such as 5G NR systems, can be deployed in various ways with a variety of components or parts. In a 5G NR system or network, network nodes, network entities, network mobility elements, radio access network (RAN) nodes, core network nodes, network elements or network equipment (such as base stations (BS)) or one or more units (or components) performing base station functions can be implemented in aggregated or decomposed architectures. For example, BSs (such as Node B (NB), evolved NB (eNB), NR BS, 5G NB, access point (AP), transmit / receive point (TRP), or cell, etc.) can be implemented as aggregated base stations (also known as standalone BS or monolithic BS) or decomposed base stations.

[0040] Aggregated base stations can be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node. Decentralized base stations can be configured to utilize a protocol stack that is physically or logically distributed across two or more units, such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs) (i.e., central or distributed units). In some respects, the CU may be implemented within a RAN node, and one or more DUs may co-located with the CU, or alternatively, may be geographically or virtually distributed across one or more other RAN nodes. DUs may be implemented to communicate with one or more RUs. Each of the CU, DU, and RU may be implemented as a virtual unit, namely a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).

[0041] Base station operation or network design can take into account the aggregation characteristics of base station functionality. For example, decomposed base stations can be utilized in Integrated Access Backhaul (IAB) networks, Open Radio Access Networks (O-RAN (such as network configurations initiated by the O-RAN Alliance)), or Virtualized Radio Access Networks (vRAN, also known as Cloud Radio Access Networks (C-RAN)). Decomposition can include distributing functionality across two or more units in various physical locations, as well as virtually distributing the functionality of at least one unit, which enables flexibility in network design. The various units of a decomposed base station or decomposed RAN architecture can be configured to communicate wirelessly with at least one other unit.

[0042] Figure 1 Figure 100 illustrates an example of a wireless communication system and access network. The illustrated wireless communication system includes a decomposed base station architecture. The decomposed base station architecture may include one or more CUs 110, which may communicate directly with the core network 120 via a backhaul link, or indirectly with the core network 120 via one or more decomposed base station units, such as a near real-time (near-RT) RAN Intelligent Controller (RIC) 125 via an E2 link, or a non-real-time (non-RT) RIC 115 associated with a Service Management and Orchestration (SMO) framework 105, or both. CUs 110 may communicate with one or more DUs 130 via a corresponding midhaul link (such as an F1 interface). DUs 130 may communicate with one or more RUs 140 via a corresponding fronthaul link. RUs 140 may communicate with a corresponding UE 104 via one or more radio frequency (RF) access links. In some implementations, a UE 104 may be served simultaneously by multiple RUs 140.

[0043] Each of the units (i.e., CU 110, DU 130, RU 140, and near-RT RIC 125, non-RT RIC 115, and SMO frame 105) may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via wired or wireless transmission media. Each of the units, or an associated processor or controller providing instructions to the communication interfaces of these units, may be configured to communicate with one or more other units via transmission media. For example, these units may include wired interfaces configured to receive signals or transmit signals to one or more other units via wired transmission media. Additionally, these units may include wireless interfaces that may include receivers, transmitters, or transceivers (such as RF transceivers) configured to receive and / or transmit signals to one or more other units via wireless transmission media.

[0044] In some aspects, the CU 110 can host one or more higher-level control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Serving Data Adaptation Protocol (SDAP), etc. Each control function can be implemented using an interface configured to signal to other control functions hosted by the CU 110. The CU 110 can be configured to handle user plane functionality (i.e., Central Unit-User Plane (CU-UP)), control plane functionality (i.e., Central Unit-Control Plane (CU-CP)), or a combination thereof. In some implementations, the CU 110 can be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units can communicate bidirectionally with the CU-CP units via an interface such as an E1 interface. The CU 110 can be implemented to communicate with the DU 130 for network control and signaling, as needed.

[0045] DU 130 may correspond to a logic unit that includes one or more base station functions for controlling the operation of one or more RU 140s. In some aspects, DU 130 may at least partially host one or more of the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) according to functional splits (such as those defined by 3GPP). In some aspects, DU 130 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signaling with other layers (and modules) hosted by DU 130 or with control functions hosted by CU 110.

[0046] Lower-layer functionality can be implemented by one or more RU 140s. In some deployments, an RU140 controlled by a DU 130 may correspond to a logical node that hosts RF processing functions or low-PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, or both, based at least in part on functional decomposition (such as lower-layer functional decomposition). In this architecture, the RU 140 may be implemented to handle over-the-air (OTA) communications with one or more UEs 104. In some specific implementations, the real-time and non-real-time aspects of control plane and user plane communications with the RU 140 may be controlled by the corresponding DU 130. In some scenarios, this configuration enables the implementation of the DU 130 and CU 110 in a cloud-based RAN architecture (such as a vRAN architecture).

[0047] SMO framework 105 can be configured to support RAN deployment and provisioning of both non-virtualized and virtualized network elements. For non-virtualized network elements, SMO framework 105 can be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via operation and maintenance interfaces such as the O1 interface. For virtualized network elements, SMO framework 105 can be configured to interact with a cloud computing platform such as Open Cloud (O-Cloud) 190 to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface such as the O2 interface. Such virtualized network elements may include, but are not limited to, CU 110, DU 130, RU 140, and near-RT RIC 125. In some implementations, SMO framework 105 can communicate with hardware aspects of the 4G RAN, such as Open eNB (O-eNB) 111, via the O1 interface. Additionally, in some implementations, SMO framework 105 can communicate directly with one or more RU 140s via the O1 interface. SMO framework 105 may also include a non-RT RIC 115 configured to support the functionality of SMO framework 105.

[0048] The non-RT RIC 115 can be configured to include logical functions enabling non-real-time control and optimization of RAN elements and resources, including artificial intelligence (AI) / machine learning (ML) workflows for model training and updates, or policy-based guidance for applications / features in the near-RT RIC 125. The non-RT RIC 115 can be coupled to or communicate with the near-RT RIC 125, such as via an A1 interface. The near-RT RIC 125 can be configured to include logical functions enabling near real-time control and optimization of RAN elements and resources via data collection and actions through an interface such as an E2 interface, connecting one or more CU 110s, one or more DU 130s, or both, and O-eNBs to the near-RT RIC 125.

[0049] In some implementations, to generate AI / ML models to be deployed in the near-RT RIC 125, the non-RT RIC 115 may receive parameters or external enrichment information from an external server. This information can be utilized by the near-RT RIC 125 and can be received from non-network data sources or network functions at the SMO framework 105 or the non-RT RIC 115. In some examples, the non-RT RIC 115 or the near-RT RIC 125 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 115 may monitor long-term trends and patterns of performance and use AI / ML models to perform corrective actions via the SMO framework 105 (such as reconfiguration via O1) or by creating RAN management policies (such as A1 policies).

[0050] At least one of CU 110, DU 130, and RU 140 may be referred to as base station 102. Therefore, base station 102 may include one or more of CU 110, DU 130, and RU 140 (each component is indicated by a dashed line to indicate that each component may or may not be included in base station 102). Base station 102 provides UE 104 with an access point to core network 120. Base station 102 may include macro cells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Small cells include femtocells, picocells, and microcells. A network that includes both small cells and macro cells may be referred to as a heterogeneous network. A heterogeneous network may also include an evolved home node B (eNB) (HeNB), which can provide service to a restricted group referred to as a closed subscriber group (CSG). The communication link between RU 140 and UE 104 may include uplink (UL) transmission (also known as reverse link) from UE 104 to RU 140 and / or downlink (DL) transmission (also known as forward link) transmission from RU 140 to UE 104. The communication link may utilize multiple-input multiple-output (MIMO) antenna techniques, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may use one or more carriers. For each carrier allocated in a carrier aggregation of up to Yx MHz (x component carriers) for transmission in each direction, base station 102 / UE 104 may use a spectrum with a bandwidth of up to Y MHz (e.g., 5MHz, 10MHz, 15MHz, 20MHz, 100MHz, 400MHz, etc.). Carriers may be adjacent to each other or may not be adjacent to each other. Carrier allocation may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL compared to UL). Component carriers may include primary component carriers and one or more secondary component carriers. The primary component carrier can be referred to as the primary cell (PCell) and the secondary component carrier can be referred to as the secondary cell (SCell).

[0051] Some UEs 104 can communicate with each other using device-to-device (D2D) communication link 158. D2D communication link 158 can use DL / UL wireless wide area network (WWAN) spectrum. D2D communication link 158 can use one or more sidelink channels, such as Physical Sidelink Broadcast Channel (PSBCH), Physical Sidelink Discovery Channel (PSDCH), Physical Sidelink Shared Channel (PSSCH), and Physical Sidelink Control Channel (PSCCH). D2D communication can be performed through various wireless D2D communication systems, such as Bluetooth. ™ (Bluetooth is a trademark of the Bluetooth Special Interest Group (SIG), and is based on the IEEE 802.11 standard for Wi-Fi.) ™(Wi-Fi is a trademark of the Wi-Fi Alliance), LTE, or NR.

[0052] The wireless communication system may also include a Wi-Fi AP 150, which communicates with the UE 104 (also referred to as a Wi-Fi station (STA)) via a communication link 154, for example, in an unlicensed spectrum such as 5 GHz. When communicating in unlicensed spectrum, the UE 104 / AP 150 may perform a free channel assessment (CCA) to determine whether a channel is available before communication.

[0053] The electromagnetic spectrum is typically subdivided into various categories, bands, channels, etc., based on frequency / wavelength. In 5G NR, two initial operating bands have been designated as frequency ranges FR1 (410MHz-7.125GHz) and FR2 (24.25GHz-52.6GHz). Although a portion of FR1 is greater than 6GHz, FR1 is generally (interchangeably) referred to as the "sub-6GHz" band in various documents and articles. Similar naming issues sometimes occur with FR2, which is generally (interchangeably) referred to as the "millimeter wave" band in documents and articles, although this is distinct from the Extremely High Frequency (EHF) band (30GHz to 300GHz) designated as "millimeter wave" by the International Telecommunication Union (ITU).

[0054] The frequencies between FR1 and FR2 are generally referred to as mid-band frequencies. Recent 5G NR studies have identified the operating bands used for these mid-band frequencies as the frequency range designation FR3 (7.125 GHz to 24.25 GHz). Bands falling within FR3 can inherit FR1 and / or FR2 characteristics, and thus can effectively extend the features of FR1 and / or FR2 to mid-band frequencies. Furthermore, higher frequency bands are currently being explored to extend 5G NR operation beyond 52.6 GHz. For example, three higher operating bands have been identified as the frequency range designations FR2-2 (52.6 GHz - 71 GHz), FR4 (71 GHz - 114.25 GHz), and FR5 (114.25 GHz - 300 GHz). Each of these higher frequency bands falls within the EHF band.

[0055] In view of the above, unless otherwise specified, the term "below 6 GHz" as used herein can broadly refer to frequencies less than 6 GHz, within FR1, or including intermediate frequency band frequencies. Furthermore, unless otherwise specified, the term "millimeter wave" as used herein can broadly refer to frequencies that can include intermediate frequency band frequencies, within FR2, FR4, FR2-2 and / or FR5, or within the EHF band.

[0056] Base station 102 and UE 104 may each include multiple antennas (such as antenna elements, antenna panels, and / or antenna arrays) to facilitate beamforming. Base station 102 may transmit beamformed signals 182 to UE 104 in one or more transmit directions. UE 104 may receive beamformed signals from base station 102 in one or more receive directions. UE 104 may also transmit beamformed signals 184 to base station 102 in one or more transmit directions. Base station 102 may receive beamformed signals from UE 104 in one or more receive directions. Base station 102 / UE 104 may perform beamforming training to determine the optimal receive and transmit directions for each of base station 102 / UE 104. The transmit and receive directions of base station 102 may be the same or different. The transmit and receive directions of UE 104 may be the same or different.

[0057] Base station 102 may include and / or be referred to as gNB, Node B, eNB, access point, transceiver base station, radio base station, radio transceiver, transceiver function, Basic Service Set (BSS), Extended Service Set (ESS), TRP, network node, network entity, network equipment, or some other suitable terminology. Base station 102 may be implemented as an integrated access and backhaul (IAB) node, relay node, sidelink node, aggregated (monolithic) base station with baseband units (BBU) (including CU and DU) and RU, or as a decomposed base station including one or more of CU, DU, and / or RU. A collection of base stations that may include decomposed base stations and / or aggregated base stations may be referred to as Next Generation (NG) RAN (NG-RAN).

[0058] The core network 120 may include Access and Mobility Management Function (AMF) 161, Session Management Function (SMF) 162, User Plane Function (UPF) 163, Unified Data Management (UDM) 164, one or more location servers 168, and other functional entities. AMF 161 is the control node that handles signaling between UE 104 and the core network 120. AMF 161 supports registration management, connection management, mobility management, and other functions. SMF 162 supports session management and other functions. UPF 163 supports packet routing, packet forwarding, and other functions. UDM 164 supports authentication and key agreement (AKA) credential generation, user identity processing, access authorization, and subscription management. One or more location servers 168 are exemplified as including a Gateway Mobile Location Center (GMLC) 165 and a Location Management Function (LMF) 166. However, generally, one or more location servers 168 may include one or more location / positioning servers, which may include one or more of GMLC 165, LMF 166, Position Determination Entity (PDE), Serving Mobile Location Center (SMLC), Mobile Location Center (MPC), etc. GMLC 165 and LMF 166 support UE location services. GMLC 165 provides an interface for clients / applications (e.g., emergency services) to access UE location information. LMF 166 receives measurement and auxiliary information from NG-RAN and UE 104 via AMF 161 to calculate the location of UE 104. NG-RAN may use one or more positioning methods to determine the location of UE 104. Positioning UE 104 may involve signal measurement, location estimation, and optional rate calculation based on these measurements. Signal measurement may be performed by UE 104 and / or base station 102 serving UE 104. The measured signals may be based on one or more of the following: Satellite Positioning System (SPS) 170 (e.g., one or more of Global Navigation Satellite System (GNSS), Global Positioning System (GPS), Non-Terrestrial Network (NTN) or other satellite positioning / location systems), LTE signals, Wireless Local Area Network (WLAN) signals, Bluetooth signals, Terrestrial Beacon System (TBS), sensor-based information (e.g., barometric pressure sensor, motion sensor), NR Enhanced Cell ID (NR E-CID) method, NR signals (e.g., multiple round-trip time (multiple RTT), DL departure angle (DL-AoD), DL time difference of arrival (DL-TDOA), UL time difference of arrival (UL-TDOA), and UL angle of arrival (UL-AoA) positioning) and / or other systems / signals / sensors.

[0059] Examples of UE 104 include cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, GPS devices, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablets, smart devices, wearable devices, vehicles, electricity meters, air pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, or any other similarly functional device. Some UEs in UE 104 may be referred to as IoT devices (e.g., parking meters, air pumps, toasters, vehicles, heart monitors, etc.). UE 104 may also be referred to as a station, mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, mobile phone, user agent, mobile client, client, or some other suitable terminology. In some scenarios, the term UE may also be applied to one or more companion devices, such as in a device constellation arrangement. One or more of these devices may access the network together and / or individually.

[0060] Refer again Figure 1 In some aspects, UE 104 may have a multi-hop relay component 198, which may be configured to: obtain a first ID for a first route between a first UE and a second UE; receive data packets originating from a third UE from the second UE, the data packets indicating the first route ID; and identify the third UE based on the first route ID indicated in the data packets. In some aspects, base station 102 may have a multi-hop relay component 199, which may be configured to: obtain a route ID for at least one first route between a network node and a first UE; receive an indication that data packets received by the network node were received via a multi-hop route; and receive data packets originating from the second UE from the first UE based on the route ID and the indication.

[0061] Figure 2A Figure 200 illustrates an example of the first subframe within a 5G NR frame structure. Figure 2B Figure 230 illustrates an example of a DL channel within a 5G NR subframe. Figure 2C Figure 250 is an example of a second subframe within a 5G NR frame structure. Figure 2DFigure 280 illustrates an example of a UL channel within a 5G NR subframe. The 5G NR frame structure can be Frequency Division Duplex (FDD) (where subframes within a specific set of subcarriers (carrier system bandwidth) are dedicated to either DL or UL) or Time Division Duplex (TDD) (where subframes within a specific set of subcarriers (carrier system bandwidth) are dedicated to both DL and UL). Figure 2A , Figure 2C In the provided example, the 5G NR frame structure is assumed to be TDD, where subframe 4 is configured with slot format 28 (most of which are DL), where D is DL, U is UL, and F is flexible and can be used between DL / UL, and subframe 3 is configured with slot format 1 (all of which are UL). Although subframes 3 and 4 are shown as having slot formats 1 and 28 respectively, any particular subframe can be configured with any of the various available slot formats 0-61. Slot formats 0 and 1 are both DL and UL, respectively. Other slot formats 2-61 include a mixture of DL, UL, and flexible symbols. The UE is configured using the slot format via the received Slot Format Indicator (SFI) (dynamically configured via DL Control Information (DCI) or semi-statically / statically configured via Radio Resource Control (RRC) signaling). Note that the following description also applies to the 5G NR frame structure as TDD.

[0062] Figures 2A to 2D The frame structure is illustrated, and aspects of this disclosure are applicable to other wireless communication technologies that may have different frame structures and / or different channels. A frame (10 ms) can be divided into 10 equal-sized subframes (1 ms). Each subframe may include one or more time slots. Subframes may also include micro-time slots, which may include 7, 4, or 2 symbols. Each time slot may include 14 or 12 symbols, depending on whether the cyclic prefix (CP) is normal or extended. For normal CP, each time slot may include 14 symbols, and for extended CP, each time slot may include 12 symbols. Symbols on the DL may be CP Orthogonal Frequency Division Multiplexing (OFDM) (CP-OFDM) symbols. Symbols on the UL may be CP-OFDM symbols (for high-throughput scenarios) or Discrete Fourier Transform (DFT) Extended OFDM (DFT-s-OFDM) symbols (for power-constrained scenarios; limited to single-stream transmission). The number of time slots within a subframe is based on the CP and a parameter set. The parameter set defines the subcarrier spacing (SCS) (see Table 1). Symbol length / duration can be scaled with 1 / SCS.

[0063]

[0064] Table 1: Parameter Set, SCS, and CP

[0065] For a normal CP (14 symbols / slot), different parameter sets µ 0 through 4 allow 1, 2, 4, 8, and 16 slots per subframe, respectively. For an extended CP, parameter set 2 allows 4 slots per subframe. Therefore, for a normal CP and parameter set µ, there are 14 symbols / slot and 2... µ One time slot / subframe. Subcarrier spacing can be equal to ,in The parameter sets are 0 to 4. Therefore, the subcarrier spacing is 15 kHz for parameter set µ=0 and 240 kHz for parameter set µ=4. The symbol length / duration is negatively correlated with the subcarrier spacing. Figures 2A to 2D Examples of a normal frequency division multiplexing (CP) with 14 symbols per time slot and a parameter set of µ=2 with 4 time slots per subframe are provided. The time slot duration is 0.25 ms, the subcarrier spacing is 60 kHz, and the symbol duration is approximately 16.67 μs. Within the frame set, there may be one or more distinct bandwidth portions (BWPs) of frequency division multiplexing (see [link to relevant documentation]). Figure 2B Each BWP can have a specific set of parameters and CP (normal or extended).

[0066] A resource grid can be used to represent the frame structure. Each time slot consists of a resource block (RB) extending for 12 consecutive subcarriers (also known as a physical RB (PRB)). The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

[0067] like Figure 2A As illustrated, some of the REs carry reference (pilot) signals (RS) for the UE. RS may include demodulation RS (DM-RS) (indicated as R for a particular configuration, but other DM-RS configurations are possible) and channel state information reference signals (CSI-RS) for channel estimation at the UE. RS may also include beam measurement RS (BRS), beam refinement RS (BRRS), and phase tracking RS (PT-RS).

[0068] Figure 2BExamples of various DL channels within a subframe of a frame are illustrated. The Physical Downlink Control Channel (PDCCH) carries the DCI within one or more Control Channel Elements (CCEs) (e.g., 1, 2, 4, 8, or 16 CCEs), each CCE comprising six RE Groups (REGs), each REG comprising 12 consecutive REs in the OFDM symbol of the RB. A PDCCH within a BWP can be referred to as a Control Resource Set (CORESET). The UE is configured to monitor PDCCH candidates in the PDCCH search space (e.g., the common search space, the UE-specific search space) during PDCCH monitoring timing on the CORESET, where the PDCCH candidates have different DCI formats and different aggregation levels. Additional BWPs may be located at higher and / or lower frequencies on the channel bandwidth. The Primary Synchronization Signal (PSS) may be located within symbol 2 of a specific subframe of the frame. The PSS is used by the UE 104 to determine subframe / symbol timing and physical layer identification. The Secondary Synchronization Signal (SSS) may be located within symbol 4 of a specific subframe of the frame. The SSS is used by the UE to determine the Physical Layer Cell Identifier Group Number and radio frame timing. Based on the Physical Layer Identifier and the Physical Layer Cell Identifier Group Number, the UE can determine the Physical Cell Identifier (PCI). Based on the PCI, the UE can determine the location of the DM-RS. The Physical Broadcast Channel (PBCH), carrying the Master Information Block (MIB), can be logically grouped with the PSS and SSS to form a Synchronization Signal (SS) / PBCH block (also known as an SS block (SSB)). The MIB provides the System Frame Number (SFN) and the number of Restricted Frames (RBs) in the system bandwidth. The Physical Downlink Shared Channel (PDSCH) carries user data, broadcast system information not transmitted via the PBCH (such as System Information Blocks (SIBs)), and paging messages.

[0069] like Figure 2C As illustrated, some REs in the REs carry DM-RS (indicated as R for one particular configuration, but other DM-RS configurations are possible) for channel estimation at the base station. The UE can transmit DM-RS for the Physical Uplink Control Channel (PUCCH) and DM-RS for the Physical Uplink Shared Channel (PUSCH). The PUSCH DM-RS can be transmitted in the first or first two symbols of the PUSCH. Depending on whether a short or long PUCCH is transmitted and depending on the specific PUCCH format used, the PUCCH DM-RS can be transmitted in different configurations. The UE can transmit a Sounding Reference Signal (SRS). The SRS can be transmitted in the last symbol of a subframe. The SRS can have a comb structure, and the UE can transmit the SRS on one of the comb teeth. The SRS can be used by the base station for channel quality estimation to enable frequency-dependent scheduling of the UL.

[0070] Figure 2DExamples of various UL channels within a subframe of a frame are illustrated. The PUCCH may be located as indicated in one configuration. The PUCCH carries uplink control information (UCI), such as scheduling requests, channel quality indicators (CQI), pre-decoding matrix indicators (PMI), rank indicators (RI), and hybrid automatic repeat request (HARQ) acknowledgment (ACK) (HARQ-ACK) feedback (i.e., one or more HARQ ACK bits indicating one or more ACKs and / or negative ACKs (NACKs)). The PUCCH carries data and may additionally be used to carry buffer status reports (BSR), power clearance reports (PHR), and / or UCIs.

[0071] Figure 3 This is a block diagram illustrating communication between base station 310 and UE 350 in the access network. In the DL, Internet Protocol (IP) packets can be provided to controller / processor 375. Controller / processor 375 implements Layer 3 and Layer 2 functionality. Layer 3 includes the Radio Resource Control (RRC) layer, and Layer 2 includes the Service Data Adaptation Protocol (SDAP) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, and Media Access Control (MAC) layer. The controller / processor 375 provides RRC layer functionality associated with broadcasting system information (e.g., MIB, SIB), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-Radio Access Technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functionality associated with the delivery of upper-layer packet data units (PDUs), error correction via ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel priority ordering.

[0072] Transmit (TX) processor 316 and receive (RX) processor 370 implement Layer 1 functionality associated with various signal processing functions. Layer 1 (which includes the physical (PHY) layer) may include error detection on the transport channel, forward error correction (FEC) decoding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. TX processor 316 processes the mapping to the signal constellation based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-order phase shift keying (M-PSK), M-order quadrature amplitude modulation (M-QAM)). The decoded and modulated symbols can then be divided into parallel streams. Each stream can then be mapped to OFDM subcarriers, multiplexed with a reference signal (e.g., a pilot) in the time and / or frequency domains, and then combined using inverse fast Fourier transform (IFFT) to produce a physical channel carrying a stream of time-domain OFDM symbols. The OFDM stream undergoes spatial pre-decoding to generate multiple spatial streams. A channel estimate from channel estimator 374 can be used to determine the decoding and modulation scheme, as well as for spatial processing. This channel estimate can be derived from a reference signal transmitted by UE 350 and / or channel condition feedback. Each spatial stream can then be provided to a different antenna 320 via a separate transmitter 318Tx. Each transmitter 318Tx can utilize the corresponding spatial stream to modulate a radio frequency (RF) carrier for transmission.

[0073] At UE 350, each receiver 354Rx receives signals via its corresponding antenna 352. Each receiver 354Rx recovers the information modulated onto the RF carrier and provides that information to the receive (RX) processor 356. The TX processor 368 and RX processor 356 implement Layer 1 functionality associated with various signal processing functions. The RX processor 356 can perform spatial processing on the information to recover any spatial stream destined for UE 350. If multiple spatial streams are destined for UE 350, the RX processor 356 can combine them into a single OFDM symbol stream. The RX processor 356 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal consists of a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, along with the reference signal, are recovered and demodulated by determining the most probable signal constellation points transmitted by base station 310. These soft decisions can be based on a channel estimate calculated by channel estimator 358. The soft decision is then decoded and deinterleaved to recover the data and control signals originally transmitted by base station 310 on the physical channel. The data and control signals are then provided to controller / processor 359, which implements layer 3 and layer 2 functionality.

[0074] The controller / processor 359 may be associated with at least one memory 360 storing program code and data. The at least one memory 360 may be referred to as a computer-readable medium. In the UL, the controller / processor 359 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between transport and logical channels to recover IP packets. The controller / processor 359 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0075] Similar to the functionality described in conjunction with DL transmission performed by base station 310, controller / processor 359 provides RRC layer functionality associated with system information (e.g., MIB, SIB) acquisition, RRC connectivity, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functionality associated with upper-layer PDU delivery, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel priority ordering.

[0076] The TX processor 368 can use the reference signal transmitted from the base station 310 or the channel estimate derived from feedback by the channel estimator 358 to select an appropriate decoding and modulation scheme and facilitate spatial processing. The spatial stream generated by the TX processor 368 can be provided to different antennas 352 via individual transmitters 354Tx. Each transmitter 354Tx can use the corresponding spatial stream to modulate an RF carrier for transmission.

[0077] UL transmission is processed at base station 310 in a manner similar to that described in conjunction with the receiver function at UE 350. Each receiver 318Rx receives signals via its corresponding antenna 320. Each receiver 318Rx recovers the information modulated onto the RF carrier and provides that information to RX processor 370.

[0078] The controller / processor 375 may be associated with at least one memory 376 storing program code and data. The at least one memory 376 may be referred to as a computer-readable medium. In the UL, the controller / processor 375 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets between transport and logical channels. The controller / processor 375 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0079] At least one of the TX processor 368, RX processor 356, and controller / processor 359 can be configured to perform and Figure 1 The multi-hop relay component 198 combines various aspects.

[0080] At least one of the TX processor 316, RX processor 370, and controller / processor 375 can be configured to perform and Figure 1 The multi-hop relay component 199 combines various aspects.

[0081] UE-to-network (U2N) relay can be used to extend network coverage to certain UEs, such as remote UEs outside network coverage or experiencing coverage issues. U2N effectively extends network coverage by utilizing one or more relay UEs that relay data between the network and remote UEs. Utilizing a single relay UE to relay various aspects of data can be referred to as single-hop relay. For example, Figure 4 This is an example of a single-hop relay, illustrated in Figure 400. A hop can refer to a route or connection between two UEs or between a UE and the network. For example... Figure 4 As shown in Figure 400, a network node 402 (or network), a remote UE 404, and a relay UE 406. The relay UE 406 can be directly connected to both the network node 402 and the remote UE 404, and the remote UE 404 can be indirectly connected to the network node 402 via the relay UE 406. To provide data to the network node 402, the remote UE 404 can send data to the relay UE 406, and the relay UE 406 can relay the data to the network node 402. Similarly, to provide data to the remote UE 404, the network node 402 can provide data to the relay UE 406, and the relay UE 406 can relay the data to the remote UE 404.

[0082] Using more than one relay UE to relay various aspects of data can be called multi-hop relay. For example, Figure 5 This is an example of a multi-hop relay, shown in diagram 500. Figure 5As shown in Figure 500, a network node 502 (e.g., a network), a remote UE 504, and multiple relay UEs 506a, 506b, 506c, 506d, 506e, and 506f (506a-506f). One or more of the relay UEs 506a-506f can be directly connected to the network node 402. One or more of the relay UEs 506a-506e can also be directly connected to the remote UE 404. The remote UE 504 can be indirectly connected to the network node 402 via one or more of the relay UEs 506a-506e. To provide data to network node 502, remote UE 504 may send data to one or more of relay UEs 506 (e.g., relay UEs 506a and / or 506b), and the relay UEs may relay the data to network node 502 via other relay UEs (e.g., relay UEs 506c, 506d, 506e, and / or 506f). Similarly, to provide data to remote UE 504, network node 502 may provide data to one or more relay UEs (e.g., relay UE 506f), and the relay UEs may relay the data to remote UE 504 via other relay UEs (e.g., relay UEs 506a, 506b, 506c, 506d, and / or 506e). Multi-hop relay can extend both the network coverage (e.g., 5G coverage) and sidelink coverage of the remote UE via the relay UEs.

[0083] Various interfaces can be used for communication between UEs and between a specific UE and the network. For example, Figure 6 Figure 600 illustrates various interfaces that communicatively couple the UE and the network. For example... Figure 6 As shown in Figure 600, a first network node (e.g., gNB) 602a, a second network node 602b, a first relay UE 606a, a second relay UE 606b, and a remote UE 604. The first network node 602a and the second network node 602b can provide a RAN (e.g., NR RAN). The first relay UE 606a and the second relay UE 606b are within the coverage area of ​​the RAN. The remote UE 604 is outside the coverage area of ​​the RAN. When a UE is within the coverage area of ​​the RAN (e.g., the first relay UE 606a and the second relay UE 606b), sidelink transmission and reception between UEs can be performed via a sidelink interface (e.g., a PC5 interface), regardless of the UE's RRC state. The PC5 interface can also be used for sidelink transmission and reception between a UE within the RAN coverage area and a UE outside the RAN coverage area (e.g., the remote UE 604).

[0084] Figure 7 This is Figure 700, illustrating the access layer (AS) protocol stack of the control plane used for the side link control channel (SCCH) of RRC signaling. (See Figure 700.) Figure 7 As shown, the AS protocol stack for RRC SSCH in the PC5 interface of the first UE 702A may include RRC sublayer 704A, PDCP sublayer 706A, RLC sublayer 708A, MAC sublayer 710A, and PHY sublayer 712A. The AS protocol stack for RRC SSCH in the PC5 interface of the second UE 702B may include RRC sublayer 704B, PDCP sublayer 706B, RLC sublayer 708B, MAC sublayer 710B, and PHY sublayer 712B.

[0085] Figure 8 This is Figure 800, illustrating the access layer (AS) protocol stack of the control plane for the sidelink control channel (SCCH) used in PC5 signaling (PC5-S). Figure 8 As shown, the AS protocol stack for SSCH of the PC5-S interface used by the first UE 702A may include PC5-S sublayer 804A, PDCP sublayer 806A, RLC sublayer 808A, MAC sublayer 810A, and PHY sublayer 812A. The AS protocol stack for SSCH of the PC5-S interface used by the second UE 802B may include PC5-S sublayer 804B, PDCP sublayer 806B, RLC sublayer 808B, MAC sublayer 810B, and PHY sublayer 812B. PC5-S sublayer 804A may be located above PDCP sublayer 806A, RLC sublayer 808A, and MAC sublayer 810A in the control plane protocol stack of the SCCH used by PC5-S. PC5-S sublayer 804B may be located above PDCP sublayer 806B, RLC sublayer 808B, and MAC sublayer 810B in the control plane protocol stack of the SCCH used by PC5-S.

[0086] Figure 9A and Figure 9B This is a diagram illustrating the Layer 2 U2N relay protocol stack. Specifically, Figure 9A This is a diagram 900 illustrating the control plane used for Layer 2 U2N relays. Figure 9B This is an example diagram 910 illustrating the user plane used in Layer 2 U2N relays. For example... Figure 9A and Figure 9B As shown, a PC5 adaptation layer 902, different from the UE-UTRAN (Uu) adaptation layer, is introduced. Note that a PC5-S / PC5-RRC connection (not shown) may exist between the remote UE and the relay UE.

[0087] The local remote UE identifier (ID) can be included in the PC5 sidelink trunk adaptation protocol (SRAP) header and the Uu SRAP header. L2 U2N trunk UEs can be configured with a local remote UE ID to be used in the SRAP header by the network node (e.g., gNB). L2 U2N remote UEs can obtain their local remote ID from the network node via Uu RRC messages, which include RRCSetup, RRCReconfiguration, RRCResume, and RRCEsume.

[0088] For example, Figure 10 This is illustration 1000, showing the format of an SRAP data PDU with an SRAP header. For example... Figure 10 As shown, an SRAP data PDU may include a first octet (Oct 1), a second octet (Oct 2), and a third octet (Oct 3). The first octet may include a bearer ID field 1002, two reserved (R) fields 1004A and 1004B, and a data / control (D / C) field 1006. The bearer ID field 1002 indicates the Uu radio bearer identity used for a U2N remote UE. The D / C field indicates whether the corresponding SRAP PDU is an SRAP data PDU or an SRAP control PDU. The second octet may include a UE ID field 1008. The UE ID field 1008 indicates the local identity of the U2N remote UE. The third octet may include a data field 1010. The data field 1010 may include an SRAP SDU (e.g., a PDCP PDU or an RRC PDU).

[0089] Avoiding conflicts when using local remote UE IDs may be the responsibility of the network node. The network node can update the local remote UE ID by sending the updated local remote UE ID via an RRCReconfiguration message. The serving network node can perform local remote UE ID updates independently of the PC5 unicast link L2 ID update process.

[0090] Current implementations do not provide mechanisms for identifying and routing services for remote UEs in multi-hop networks. Various aspects of this disclosure provide and implement UE ID and route ID allocation in multi-hop U2N trunk networks. For example, in one aspect, a unique per-hop identifier (e.g., a route ID) may be used for a remote UE. The route ID can be unique on each hop. A UE (e.g., a trunk UE) can identify a remote UE based on the route ID in received packets and determine the route ID to use in the next hop. In another aspect, a unique end-to-end (E2E) ID may be used for a remote UE. The route ID can be the same on each hop. A UE (e.g., a trunk UE) can identify a remote UE based on the route ID in received packets. In yet another aspect, the unique end-to-end (E2E) ID may be assigned by the network. For example, network nodes may assign a single unique E2E ID used on each hop and may configure (e.g., provide) a unique E2E ID for each UE. Various aspects of this disclosure provide solutions for multi-hop U2N trunk route IDs. For example, a relay UE (e.g., an intermediate relay UE (R-UE) or a donor R-UE) can assign a route ID to a remote UE on each sidelink (e.g., PC5) hop. A network node (e.g., gNB) can provide the donor R-UE with the route ID used on the Uu interface. In another example, the UE can decide (e.g., determine) a unique E2E remote UE ID to use at the SRAP layer (including the PC5 and Uu interfaces) on each hop. In yet another example, the network node can assign a unique E2E ID to use on each hop and can configure the unique E2E ID to each UE in a multi-hop relay. As used herein, a route ID can be an alphanumeric or numeric string associated with a specific route (or hop).

[0091] Figure 11 This is an example of a call flowchart 1100 illustrating multi-hop relay using a unique per-hop identifier for a remote UE, according to various aspects of this disclosure. Figure 11As shown, call flowchart 1100 includes network node 1102, remote UE 1104, trunk UE 1106A, trunk UE 1106B, and trunk UE 1106C. Each of trunk UE 1106A and trunk UE 1106B may be referred to herein as an intermediate trunk UE. Trunk UE 1106C may be referred to herein as a donor trunk UE. Remote UE 1104 may be an example of UE 104, UE 350, remote UE 404, remote UE 504, remote UE 604, first UE 702A, second UE 702B, first UE 802A, or second UE 802B. Each of relay UE 1106A, relay UE 1106B, and relay UE 1106C may be an example of UE 104, UE 350, relay UE 406, relay UE 506a-506f, first relay UE 606a, second relay UE 606b, first UE 702A, second UE 702B, first UE 802A, or second UE 802B. Network node 1102 may be an example of base station 102, base station 310, network node 402, network node 502, first network node 602a, or second network node 602b. Although aspects are described with respect to network node 1102, these aspects may be performed by network node 1102 in the aggregation and / or by one or more components of network node 1102 (e.g., such as CU 110, DU 130, and / or RU 140).

[0092] At 1108, remote UE 1104, relay UE 1106A, relay UE 1106B, and relay UE 1106C can perform a discovery procedure, in which these UEs discover each other and / or determine which UEs will become part of a multi-hop relay session. At 1110, each of remote UE 1104, relay UE 1106A, relay UE 1106B, and / or relay UE 1106C can perform per-hop unicast link establishment or modification to assign a route ID to at least one of its associated previous (or ingress) hop or next (or egress) hop. An ingress hop can be a hop through which the UE receives data, and an egress hop can be a hop through which the UE transmits data or forwards data received via an ingress hop. The hop assigned the corresponding route ID can be a PC5-based hop. Per-hop unicast link establishment or modification can be based on a UE-to-UE (U2U) relay mechanism.

[0093] Each of the remote UE 1104, relay UE 1106A, relay UE 1106B, and / or relay UE 1106C may be assigned a route ID such that each route ID for a particular hop is unique. That is, the route ID is unique on each hop between the two UEs. For example, the hop between the remote UE 1104 and the relay UE 1106A (by either the remote UE 1104 or the relay UE 1106A) may be assigned a first route ID, the hop between the relay UE 1106A and the relay UE 1106B (by either the relay UE 1106A or the relay UE 1106B) may be assigned a second route ID, and the hop between the relay UE 1106B and the relay UE 1106C (by either the relay UE 1106B or the relay UE 1106C) may be assigned a third route ID. Each of relay UEs 1106A, 1106B, and 1106C can identify remote UE 1104 based on the route ID indicated in the packets received by it, respectively. Each of relay UEs 1106A, 1106B, and 1106C can also determine the route ID used in the next hop (e.g., when forwarding data via the next hop). A specific UE that assigns a route ID to a specific hop can notify another UE of the route ID using PC5-S-based signaling or PC5-RRC-based signaling. For each remote UE (e.g., remote UE 1104), each of relay UEs 1106A, 1106B, and 1106C can maintain a mapping between the route ID of its corresponding ingress hop and the route ID of its corresponding egress hop.

[0094] At 1112, remote UE 1104 can provide an RRC setup request message (e.g., an RRCSsetupRequest message) intended for use with network node 1102. The RRC setup request message can be used to request the establishment of an RRC connection between remote UE 1104 and network node 1102. Figure 11As shown, remote UE 1104 provides an RRC establishment request message to relay UE 1106A. The RRC establishment request message may indicate the route ID of the hop used to provide the RRC establishment request message. Relay UE 1106A may identify remote UE 1104 based on the route ID, and may use the mapping maintained therefrom to determine the route ID of the hop used to forward the RRC establishment request message to relay UE 1106B, and may forward the RRC establishment request message via the hop identified by the route ID. The forwarded RRC establishment request message may indicate the route ID of the hop used to forward the RRC establishment request message to relay UE 1106B. Relay UE 1106B may identify remote UE 1104 based on the route ID, and may use the mapping maintained therefrom to determine the route ID of the hop used to forward the RRC establishment request message to relay UE 1106C, and may forward the RRC establishment request message via the hop identified by the route ID. The forwarded RRC establishment request message may indicate the route ID of the hop used to forward the RRC establishment request message to the relay UE1106C.

[0095] At 1114, relay UE 1106C may provide network node 1102 with a sidelink UE information (SUI) message including a multi-hop indication. The multi-hop indication may indicate to network node 1102 that the multi-hop relay is being used to provide data to and / or from a remote UE (e.g., remote UE 1104). The multi-hop indication may cause network node 1102 to suppress (e.g., avoid) providing messages to remote UE 1104 including the local routing ID (or local identity) of remote UE 1104. The local routing ID may be an ID locally determined by network node 1102 for remote UE 1104.

[0096] At 1116, network node 1102 may provide relay UE 1106C with an RRC reconfiguration message (e.g., an RRCReconfiguration message). The RRC reconfiguration message may indicate the routing ID for the hop between network node 1102 and relay UE 1106C. The hop assigned such a routing ID may be a Uu-based hop. Relay UE 1106C may maintain a mapping between the Uu routing ID (assigned by network node 1102) and the PC5 routing ID of remote UE 1104 (e.g., the routing ID assigned to the hop between relay UE 1106B and relay UE 1106C, via which data originating from remote UE 1104 is sent and / or received).

[0097] At 1118, network node 1102 may provide an RRC establishment message (e.g., an RRCSetup message) to relay UE 1106C. The RRC establishment message may indicate the Uu route ID of the hop used to provide the RRC establishment message to relay UE 1106C. Relay UE 1106C may use the thus maintained mapping to identify the PC5 route ID associated with remote UE 1104 based on the Uu route ID, use the thus maintained mapping to determine the route ID of the hop used to forward the RRC establishment message to relay UE 1106B, and may forward the RRC establishment message via the hop identified by the route ID. The forwarded RRC establishment message may indicate the route ID of the hop used to forward the RRC establishment message to relay UE 1106B. Relay UE 1106B can identify remote UE 1104 based on a route ID. It can utilize the mapping maintained therefrom to determine the route ID of the hop used to forward RRC establishment messages to relay UE 1106A, and can forward RRC establishment messages via the hop identified by the route ID. The forwarded RRC establishment message can indicate the route ID of the hop used to forward RRC establishment request messages to relay UE 1106A. Relay UE 1106A can identify remote UE 1104 based on a route ID. It can utilize the mapping maintained therefrom to determine the route ID of the hop used to forward RRC establishment messages to remote UE 1104, and can forward RRC establishment messages via the hop identified by the route ID.

[0098] At 1120, remote UE 1104 may provide relay UE 1106A with an RRC setup complete message (e.g., an RRCSetupComplete message). The RRC setup complete message may indicate the PC5 route ID of the hop used to provide the RRC setup complete message to relay UE 1106A. Relay UE 1106A may use the thus maintained mapping to identify remote UE 1104 based on the PC4 route ID, use the thus maintained mapping to determine the route ID of the hop used to forward the RRC setup complete message to relay UE 1106B, and may forward the RRC setup message via the hop identified by the route ID. The forwarded RRC setup complete message may indicate the route ID of the hop used to forward the RRC setup complete message to relay UE 1106B. Relay UE 1106B can identify remote UE 1104 based on a route ID, and can use the mapping maintained therefrom to determine the route ID of the hop used to forward the RRC establishment complete message to relay UE 1106C, and can forward the RRC establishment complete message via the hop identified by the route ID. The forwarded RRC establishment complete message can indicate the route ID of the hop used to forward the RRC establishment complete request message to relay UE 1106C. Relay UE 1106C can identify remote UE 1104 based on a route ID, and can use the mapping maintained therefrom to determine the Uu route ID of the hop used to forward the RRC establishment complete message to network node 1102, and can forward the RRC establishment complete message via the hop identified by the Uu route ID.

[0099] In some respects, the Proximity Service (ProSe) layer of each intermediate trunk UE (e.g., trunk UE 1106A or 1106B) provides a mapping of ingress route IDs and egress route IDs to the access (AS) layer of the intermediate trunk UE. The ProSe layer of a particular UE provides trunk functionality to support UE connectivity to the network that provides proximity-based services. The AS layer can be used to configure and activate sidelink radio bearers on the ProSE layer.

[0100] In some respects, the ProSe layer of the donor relay UE (e.g., relay UE 1106C) can provide the AS layer of the donor relay UE with the PC5 route ID of the hop between the donor relay UE and another relay UE (i.e., the route ID on PC5 SRAP), and the AS layer can maintain a mapping between the route ID on PC5 SRAP and the route ID of the hop between the donor relay UE and network node 1102 (i.e., the route ID on Uu SRAP).

[0101] Figure 12 This is an example of a call flowchart 1200 illustrating multi-hop trunking utilizing a unique E2E identifier for a remote UE, according to various aspects of this disclosure. Figure 12As shown, call flowchart 1200 includes network node 1202, remote UE 1204, trunk UE 1206A, trunk UE 1206B, and trunk UE 1206C. Each of trunk UE 1206A and trunk UE 1206B may be referred to herein as an intermediate trunk UE. Trunk UE 1206C may be referred to herein as a donor trunk UE. Remote UE 1204 may be an example of UE 104, UE 350, remote UE 404, remote UE 504, remote UE 604, first UE 702A, second UE 702B, first UE 802A, second UE 802B, or remote UE 1104. Each of relay UE 1206A, relay UE 1206B, and relay UE 1206C can be an example of UE 104, UE 350, relay UE 406, relay UE 506a-506f, first relay UE 606a, second relay UE 606b, first UE 702A, second UE 702B, first UE 802A, second UE 802B, or relay UE 1106A, 1106B, or 1106C. Network node 1202 can be an example of base station 102, base station 310, network node 402, network node 502, first network node 602a, second network node 602b, or network node 1102. Although aspects are described for network node 1202, these aspects may be performed by network node 1202 in the aggregation and / or by one or more components of network node 1202 (e.g., such as CU 110, DU 130 and / or RU 140).

[0102] At 1208, remote UE 1204, relay UE 1206A, relay UE 1206B, and relay UE 1206C can perform a discovery process, whereby these UEs discover each other and / or determine which UEs will become part of a multi-hop relay session. At 1210, each of remote UE 1204, relay UE 1206A, relay UE 1206B, and / or relay UE 1206C can perform per-hop unicast link establishment or modification, where remote UE 1204 shares its ID (e.g., a routing ID) with relay UE 1206A, relay UE 1206B, and relay UE 1206C. This ID of remote UE 1204 can be used for each hop between the relay UE and / or relay UE 1206C and network node 1202. That is, the same unique E2E remote UE (or route) ID can be used for each hop in a multi-hop relay (both PC5-based hops and Uu-based hops).

[0103] At 1212, remote UE 1204 can provide an RRC setup request message (e.g., an RRCSsetupRequest message) intended for use with network node 1202. The RRC setup request message can be used to request the establishment of an RRC connection between remote UE 1204 and network node 1202. Figure 12 As shown, remote UE 1204 provides an RRC establishment request message to relay UE 1206A. The RRC establishment request message may indicate the E2E remote UE ID of remote UE 1204. Relay UE 1206A may identify remote UE 1204 based on its E2E remote UE ID and may forward the RRC establishment request message to relay UE 1206B. The forwarded RRC establishment request message may indicate the E2E remote UE ID of remote UE 1204. Relay UE 1206B may identify remote UE 1204 based on its E2E remote UE ID and may forward the RRC establishment request message to relay UE 1206C. The forwarded RRC establishment request message may indicate the E2E remote UE ID of remote UE 1204.

[0104] At 1214, relay UE 1206C may provide network node 1202 with a SUI message indicating the E2E remote UE ID of remote UE 1204 to be used on the Uu interface. The SUI message may be provided using an RRC message. Alternatively, remote UE 1204 may use an RRC message to indicate to network node 1202 its unique E2E remote UE ID to be used on the Uu interface.

[0105] At 1216, network node 1202 can provide an RRC establishment message (e.g., an RRCSetup message) to relay UE 1206C via the Uu interface. The RRC establishment message may indicate the E2E remote UE ID of remote UE 1204. Relay UE 1206C can identify remote UE 1204 based on the E2E remote UE ID and can forward the RRC establishment message to relay UE 1206B via the PC5 interface. The forwarded RRC establishment message may include the E2E remote UE ID of remote UE 1204. Relay UE 1206B can identify remote UE 1204 based on the E2E remote UE ID and can forward the RRC establishment message to relay UE 1206A via the PC5 interface. The forwarded RRC establishment message may include the E2E remote UE ID of remote UE 1204. The relay UE 1206A can identify the remote UE 1204 based on the E2E remote UE ID and can forward the RRC establishment message to the remote UE 1204 via the PC5 interface.

[0106] At 1218, remote UE 1204 may provide relay UE 1206A with an RRC setup completion message (e.g., an RRCSetupComplete message). The RRC setup message may indicate the E2E remote UE ID of remote UE 1204. Relay UE 1206A may identify remote UE 1204 based on the E2E remote UE ID and may forward the RRC setup message to relay UE 1206B via the PC5 interface. The forwarded RRC setup message may include the E2E remote UE ID of remote UE 1204. Relay UE 1206B may identify remote UE 1204 based on the E2E remote UE ID and may forward the RRC setup message to relay UE 1206C via the PC5 interface. The forwarded RRC setup message may include the E2E remote UE ID of remote UE 1204. Relay UE 1206C can identify remote UE 1204 based on E2E remote UE ID and can forward RRC establishment messages to network node 1202 via Uu interface.

[0107] In some respects, a unique E2E remote UE ID can be used at the SRAP layer on each hop, including the PC5 interface or the Uu interface. For example, the unique E2E remote UE ID of remote UE 1204 can be used at the SRAP layer on PC5-based hops between remote UE 1204 and relay UE 1206A, between relay UE 1206A and relay UE 1206B, and between relay UE 1206B and relay UE 1206C. The unique E2E remote UE ID of remote UE 1204 can also be used at the SRAP layer on Uu-based hops between relay UE 1206C and network node 1202.

[0108] In some respects, a unique E2E remote UE ID can have various formats. For example, a unique E2E remote UE ID can be a ProSe user information ID (e.g., a 48-bit string that can be used to identify user information to be discovered for public safety use cases). The value of the 48-bit string can be assigned by the operator or a third-party public safety provider's application server. In another example, a unique E2E remote UE ID can be derived based on a remote user information ID (e.g., a ProSe user information ID or another ID) and a hash function (e.g., a function configured to map data of arbitrary size to a fixed-size value or a value of varying length). For example, a hash function can be used to input a remote user information ID and output a hash value based on the remote user information ID. The hash value can be a unique E2E remote UE ID. The hash function can be executed in the RRC layer or the ProSe layer. In another example, a unique E2E remote UE ID can be the Layer 2 (L2) ID of a remote UE 1204.

[0109] Figure 13 This is an example of a multi-hop trunk call flowchart 1300 illustrating various aspects of this disclosure, utilizing a unique E2E identifier assigned by the network for a remote UE. (See diagram 1300 for details.) Figure 13 As shown, call flowchart 1300 includes network node 1302, remote UE 1304, trunk UE 1306A, trunk UE 1306B, trunk UE 1306C, and operation, management, and maintenance server (OAM) 1307. Each of trunk UE 1306A and trunk UE 1306B may be referred to herein as an intermediate trunk UE. Trunk UE 1306C may be referred to herein as a donor trunk UE. Remote UE 1304 may be an example of UE 104, UE 350, remote UE 404, remote UE 504, remote UE 604, first UE 702A, second UE 702B, first UE 802A, second UE 802B, remote UE 1104, or remote UE 1204. Each of relay UE 1306A, relay UE 1306B, and relay UE 1306C can be an example of UE 104, UE 350, relay UE 406, relay UE 506a-506f, first relay UE 606a, second relay UE 606b, first UE 702A, second UE 702B, first UE 802A, second UE 802B, relay UE 1106A, 1106B, or 1106C, or relay UE 1206A, 1206B, or 1206C. Network node 1302 can be an example of base station 102, base station 310, network node 402, network node 502, first network node 602a, second network node 602b, network node 1102, or network node 1202. OAM server 1307 can be managed by a cellular service provider. OAM server 1307 may include processes, activities, tools, and standards for operating, implementing, managing, and maintaining IAB nodes. Although aspects are described for network node 1302, these aspects may be performed by network node 1302 in the aggregation and / or by one or more components of network node 1302 (e.g., such as CU110, DU 130, and / or RU 140).

[0110] according to Figure 13 Network node 1302 can assign a unique E2E ID to be used on each hop and configure that ID to each UE in the multi-hop relay.

[0111] At 1308, remote UE 1304, relay UE 1306A, relay UE 1306B, and relay UE 1306C can perform a discovery process, in which these UEs discover each other and / or determine which UEs will become part of a multi-hop relay session. At 1310, each of remote UE 1304, relay UE 1306A, relay UE 1306B, and / or relay UE 1306C can, for example, perform per-hop unicast link establishment or modification based on a U2U relay mechanism.

[0112] At 1312, remote UE 1304 can provide an RRC setup request message (e.g., an RRCSsetupRequest message) intended for use with network node 1302. The RRC setup request message can be used to request the establishment of an RRC connection between remote UE 1304 and network node 1302. Figure 13 As shown, remote UE 1304 provides an RRC establishment request message to relay UE 1306A, which can forward the RRC establishment request message to relay UE 1306B. Relay UE 1306B can then forward the RRC establishment request message to relay UE 1306C.

[0113] At 1314, when relay UE 1306C (i.e., donor relay UE) receives a service (e.g., an RRC establishment request message) originating from remote UE 1304, relay UE 1306C may provide network node 1302 with a SUI message including a multi-hop indication. The multi-hop indication may indicate to network node 1302 that the multi-hop relay is being used to provide data to and / or from the remote UE (e.g., remote UE 1304), and / or may indicate hop count information (e.g., the number of hops in the multi-hop relay).

[0114] At 1316, network node 1302 may provide OAM server 1307 with a request for the allocation of a routing ID (e.g., a unique E2E remote ID) for remote UE 1304. In response, OAM server 1307 may provide the routing ID to network node 1302. Alternatively, network node 1302 may allocate the routing ID for remote UE 1304 locally. That is, network node 1302 may determine and allocate the routing ID (without the assistance of OAM server 1307). The unique E2E remote ID assigned to remote UE 1304 can be used in each hop of a multi-hop relay.

[0115] At 1318, network node 1302 can provide the routing ID of the remote UE to the relay UE via a Uu-based hop between the remote UE 1304 and the relay UE 1306C. Network node 1302 can also provide the routing ID to the relay UE 1306C via an RRC reconfiguration message (e.g., an RRCReconfiguration message).

[0116] At 1320, network node 1302 can configure remote UE 1304 with its route ID via an RRC setup message (e.g., an RRCSetup message). The RRC setup message can indicate the route ID. For example, network node 1302 can provide the RRC setup message to relay UE 1206C via a Uu-based interface. Relay UE 1306C can forward the RRC setup message to relay UE 1306B via a PC5-based interface. Relay UE 1306B can forward the RRC setup message to relay UE 1306A via a PC5-based interface. Relay UE 1306A can forward the RRC setup message to remote UE 1304 via a PC5-based interface. Accordingly, at 1318 and 1320, network node 1302 can configure the route ID for relay UE 1306C (i.e., the donor relay UE) and remote UE 1304.

[0117] At 1322, remote UE 1304 can provide an RRC setup completion message (e.g., an RRCSetupComplete message) intended for use by network node 1302. For example, remote UE 1304 can provide the RRC setup completion message to relay UE 1206A via the PC5 interface. Relay UE 1306A forwards the RRC setup completion message to relay UE 1306B via the PC5 interface. Relay UE 1306B can forward the RRC setup completion message to relay UE 1306C via the PC5 interface. Relay UE 1306C can forward the RRC setup completion message to network node 1202 via the Uu interface.

[0118] At 1324, relay UE 1306C and / or remote UE 1304 can use PC5-S or PC5-RRC messages (e.g., PC5-S-based signaling or PC5-RRC-based signaling) to notify other relay UEs (e.g., relay UE 1306A and relay UE 1306B) of the routing ID.

[0119] Figure 14 This is an example of a call flowchart 1400 illustrating multi-hop relay using a unique per-hop identifier for a remote UE, according to various aspects of this disclosure. Figure 14As shown, call flowchart 1400 includes network node 1402, remote UE 1404, trunk UE 1406A, trunk UE 1406B, and trunk UE 1406C. Each of trunk UE 1406A and trunk UE 1406B may be referred to herein as an intermediate trunk UE. Trunk UE 1406C may be referred to herein as a donor trunk UE. Remote UE 1404 may be an example of UE 104, UE 350, remote UE 404, remote UE 504, remote UE 604, first UE 702A, second UE 702B, first UE 802A, second UE 802B, or remote UE 1104. Each of relay UE 1406A, relay UE 1406B, and relay UE 1406C can be an example of UE 104, UE 350, relay UE 406, relay UE 506a-506f, first relay UE 606a, second relay UE 606b, first UE 702A, second UE 702B, first UE 802A, second UE 802B, or relay UE 1106A, relay UE 1106B, or relay UE 1106C. Network node 1402 can be an example of base station 102, base station 310, network node 402, network node 502, first network node 602a, second network node 602b, or network node 1102. Although aspects are described for network node 1402, these aspects may be performed by network node 1402 in the aggregation and / or by one or more components of network node 1102 (e.g., such as CU 110, DU 130 and / or RU 140).

[0120] At point 1408, remote UE 1404, relay UE 1406A, relay UE 1406B, and / or relay UE 1406C can obtain and / or assign routing IDs for multi-hop relays. For example, remote UE 1404 can determine a unique routing ID for the hop between remote UE 1404 and relay UE 1406A. Remote UE 1404 can store and / or retrieve the unique routing ID in its memory or cache. Relay UE 1406A can determine a unique routing ID for the hop between remote UE 1404 and relay UE 1406A and / or the hop between relay UE 1406A and relay UE 1406B. Relay UE 1406A can store and / or retrieve the unique routing ID in its memory or cache. Relay UE 1406B can determine a unique route ID for hops between Relay UE 1406A and Relay UE 1406B and / or between Relay UE 1406B and Relay UE 1406C. Relay UE 1406B can store and / or retrieve the unique route ID in its memory or cache. Relay UE 1406C can determine a unique route ID for hops between Relay UE 1406B and Relay UE 1404C. Relay UE 1406C can store and / or retrieve the unique route ID in its memory or cache.

[0121] At point 1408, remote UE 1404 and / or relay UEs 1406A, 1406B and / or 1406C can share routing IDs determined by each other. For example, remote UE 1404 can receive a routing ID determined by relay UE 1406A from relay UE 1406A via the PC5 interface. Relay UE 1406A can receive routing IDs determined by remote UE 1404 and / or relay UE 1406B from remote UE 1404 and / or relay UE 1406B via the PC5 interface. Relay UE 1406B can receive routing IDs determined by relay UE 1406A and / or relay UE 1406C via the PC5 interface. Relay UE 1406C can receive a routing ID determined by relay UE 1406B from relay UE 1406B via the PC5 interface.

[0122] At 1410, relay UE 1406C may provide a SUI message to network node 1402. The SUI message may include a multi-hop indication. The multi-hop indication may indicate to network node 1402 that a multi-hop relay is being used to provide data to and / or from a remote UE (e.g., remote UE 1404). At 1412, the multi-hop indication may cause network node 1402 to suppress (e.g., avoid) providing a message to remote UE 1404 including a local routing ID for remote UE 1404.

[0123] At 1414, network node 1402 can provide relay UE 1406C with a routing ID for the hop between network node 1402 and relay UE 1406C. The hop assigned such a routing ID can be a Uu-based hop. Therefore, network node 1402 can provide the routing ID to relay UE 1406C via the Uu interface.

[0124] At position 1416, relay UE 1406A, relay UE 1406B, and / or relay UE 1406C can maintain a mapping of route IDs between corresponding hops. For example, relay UE 1406A can maintain a mapping between route IDs for hops between remote UE 1404 and relay UE 1406A and route IDs for hops between relay UE 1406A and relay UE 1406B. Relay UE 1406B can maintain a mapping between route IDs for hops between relay UE 1406A and relay UE 1406B and route IDs for hops between relay UE 1406B and relay UE 1406C. Relay UE 1406C can maintain a mapping between route IDs for hops between relay UE 1406B and relay UE 1406C and route IDs for hops between relay UE 1406C and network node 1402.

[0125] In some respects, at 1416, the ProSe layer of relay UE 1406A can provide a mapping to the AS layer of relay UE 1406A, the ProSe layer of relay UE 1406B can provide a mapping to the AS layer of relay UE 1406B, and the ProSe layer of relay UE 1406C can provide a mapping to the AS layer of relay UE 1406C. The AS layer of relay UE 1406C can maintain a mapping between PC5-based routing IDs (for hops between relay UE 1406B and relay UE 1406C) and Uu-based routing IDs (for hops between relay UE 1406C and network node 1402).

[0126] At 1418, remote UE 1404 may send data packets intended for use with network node 1402 to relay UE 1406A. The data packets may indicate the routing ID of the hop between remote UE 1404 and relay UE 1406A. Data packets (also called network packets) may be formatted units of data that can be sent via the network.

[0127] At 1420, relay UE 1406A can identify remote UE 1404 based on the route ID indicated in the data packet and determine the route ID for the next hop based on the mapping.

[0128] At 1422, relay UE 1406A can forward data packets to relay UE 1406B based on the route ID determined for the next hop. The data packet can indicate the route ID of the hop between relay UE 1406A and relay UE 1406B.

[0129] At 1424, relay UE 1406B can identify remote UE 1404 based on the route ID indicated in the data packet and determine the route ID for the next hop based on the mapping.

[0130] At position 1426, relay UE 1406B can forward data packets to relay UE 1406C based on the route ID determined for the next hop. The data packet can indicate the route ID of the hop between relay UE 1406B and relay UE 1406C.

[0131] At 1428, relay UE 1406C can identify remote UE 1404 based on the route ID indicated in the data packet and determine the route ID for the next hop (e.g., a Uu-based hop) based on the mapping.

[0132] At 1426, relay UE 1406B can forward data packets to network node 1402 based on the route ID determined for the next hop. The data packet can indicate the route ID of the hop between relay UE 1406C and network node 1402.

[0133] Figure 15 This is an example of a call flowchart 1500 illustrating multi-hop trunking utilizing a unique E2E identifier for a remote UE, according to various aspects of this disclosure. Figure 15As shown, call flowchart 1500 includes network node 1502, remote UE 1504, trunk UE 1506A, trunk UE 1506B, and trunk UE 1506C. Each of trunk UE 1506A and trunk UE 1506B may be referred to herein as an intermediate trunk UE. Trunk UE 1506C may be referred to herein as a donor trunk UE. Remote UE 1504 may be an example of UE 104, UE 350, remote UE 404, remote UE 504, remote UE 604, first UE 702A, second UE 702B, first UE 802A, second UE 802B, or remote UE 1204. Each of relay UE 1506A, relay UE 1506B, and relay UE 1506C can be an example of UE 104, UE 350, relay UE 406, relay UE 506a-506f, first relay UE 606a, second relay UE 606b, first UE 702A, second UE 702B, first UE 802A, second UE 802B, or relay UE 1206A, 1206B, or 1206C. Network node 1502 can be an example of base station 102, base station 310, network node 402, network node 502, first network node 602a, second network node 602b, or network node 1202. Although aspects are described for network node 1502, these aspects may be performed by network node 1502 in the aggregation and / or by one or more components of network node 1502 (e.g., such as CU 110, DU 130 and / or RU 140).

[0134] At point 1508, remote UE 1504, relay UE 1506A, relay UE 1506B, and / or relay UE 1506C can obtain and / or be assigned routing IDs for multi-hop relays. For example, remote UE 1504 can determine a unique E2E remote ID to use for each hop. That is, the same unique E2E remote ID is used for each hop. At point 1508, remote UE 1504 can share the determined unique E2E remote ID with relay UE 1506A, relay UE 1506B, and / or relay UE 1506C.

[0135] In some respects, a unique E2E remote ID includes at least one of the following: a ProSE layer user information ID associated with the remote UE 1504, a hash-based ID based on the remote UE 1504's ID and hash function, or the remote UE 1504's L2 ID.

[0136] At 1510, relay UE 1506C may provide network node 1202 with a SUI message indicating the E2E remote UEID of remote UE 1204. The SUI message may be provided using an RRC message. Alternatively, remote UE 1204 may use an RRC message to indicate to network node 1202 the unique E2E remote UE ID it wishes to utilize on the Uu interface.

[0137] At 1512, remote UE 1504 may send data packets intended for use by network node 1502 to relay UE 1506A. The data packets may indicate the routing ID of remote UE 1504 (e.g., a unique E2E remote ID).

[0138] At 1514, relay UE 1506A can identify remote UE 1504 based on the route ID indicated in the data packet, and at 1516, it can forward the data packet to relay UE 1506B. The forwarded data packet can indicate the route ID of remote UE 1504.

[0139] At 1518, relay UE 1506B can identify remote UE 1504 based on the route ID indicated in the data packet, and at 1520, it can forward the data packet to relay UE 1506C. The forwarded data packet can indicate the route ID of remote UE 1504.

[0140] At 1522, relay UE 1506C can identify remote UE 1504 based on the routing ID indicated in the data packet, and at 1524, it can forward the data packet to network node 1502. The forwarded data packet can indicate the routing ID of remote UE 1504.

[0141] Figure 16 This is an example of a call flowchart 1600 illustrating a multi-hop trunking call using a unique E2E identifier assigned by the network for a remote UE, according to various aspects of this disclosure. Figure 16As shown, call flowchart 1600 includes network node 1602, remote UE 1604, trunk UE 1606A, trunk UE 1606B, trunk UE 1606C, and OAM server 1607. Each of trunk UE 1606A and trunk UE 1606B may be referred to herein as an intermediate trunk UE. Trunk UE 1606C may be referred to herein as a donor trunk UE. Remote UE 1604 may be an example of UE 104, UE 350, remote UE 404, remote UE 504, remote UE 604, first UE 702A, second UE 702B, first UE 802A, second UE 802B, remote UE 1104, or remote UE 1304. Each of relay UE 1606A, relay UE 1606B, and relay UE 1606C can be an example of UE 104, UE 350, relay UE 406, relay UE 506a-506f, first relay UE 606a, second relay UE 606b, first UE 702A, second UE 702B, first UE 802A, second UE 802B, or relay UE 1306A, 1306B, or 1306C. Network node 1602 can be an example of base station 102, base station 310, network node 402, network node 502, first network node 602a, second network node 602b, or network node 1302. OAM server 1607 can be managed by a cellular service provider. OAM server 1607 may include processes, activities, tools, and standards for operating, implementing, managing, and maintaining IAB nodes. Although aspects are described for network node 1602, these aspects may be performed by network node 1602 in the aggregation and / or by one or more components of network node 1302 (e.g., such as CU 110, DU 130 and / or RU 140).

[0142] At 1608, relay UE 1606C may provide network node 1602 with a SUI message including a multi-hop indication. The multi-hop indication may indicate to network node 1602 that the multi-hop relay is being used to provide data to and / or from a remote UE (e.g., remote UE 1604), and / or may indicate hop count information (e.g., the number of hops in the multi-hop relay).

[0143] At 1610, network node 1602 can obtain a routing ID for UE 1604. The routing ID can be an E2E remote ID for each hop of the remote UE 1604 in a multi-hop relay. That is, the same E2E remote ID can be used for each hop. In some aspects, network node 1602 can retrieve the routing ID from its own memory or cache. In other aspects, at 1612, network node 1602 can request a routing ID from OAM server 1607. In response, OAM server 1607 can provide the routing ID to network node 1602.

[0144] At 1614, network node 1302 can configure remote UE 1604 with its routing ID, for example, via an RRC establishment message. The RRC establishment message can indicate the routing ID. For example, network node 1602 can provide the RRC establishment message to relay UE 1606C via a Uu-based interface. Relay UE 1606C can forward the RRC establishment message to relay UE 1606B via a PC5-based interface. Relay UE 1606B can forward the RRC establishment message to relay UE 1606A via a PC5-based interface. Relay UE 1606A can forward the RRC establishment message to remote UE 1604 via a PC5-based interface.

[0145] In some aspects, at 1614, relay UE 1606C and / or remote UE 1604 may use PC5-S or PC5-RRC messages to notify other relay UEs (e.g., relay UE 1606A and relay UE 1606B) of the routing ID. In some aspects, if an RRC connection exists between network node 1602 and each of relay UE 1606A, relay UE 1606B, and / or relay UE 1606C, network node 1602 may use RRC messages to configure the routing ID to each relay UE.

[0146] At 1616, remote UE 1604 may send data packets intended for use by network node 1602 to relay UE 1606A. The data packets may indicate the routing ID of remote UE 1604 (e.g., a unique E2E remote ID assigned by network node 1602).

[0147] At 1618, relay UE 1606A can identify remote UE 1604 based on the route ID indicated in the data packet, and at 1620, it can forward the data packet to relay UE 1606B. The forwarded data packet can indicate the route ID of remote UE 1604.

[0148] At 1622, relay UE 1606B can identify remote UE 1604 based on the route ID indicated in the data packet, and at 1624, it can forward the data packet to relay UE 1606C. The forwarded data packet can indicate the route ID of remote UE 1604.

[0149] At 1626, relay UE 1606C can identify remote UE 1604 based on the routing ID indicated in the data packet, and at 1628, it can forward the data packet to network node 1602. The forwarded data packet can indicate the routing ID of remote UE 1604.

[0150] Figure 17 This is a flowchart 1700 illustrating a method for wireless communication at a first UE according to various aspects of this disclosure. The method can be performed by the UE. The UE can be UE 104, UE 350, relay UE 406, relay UE 506a-506f, first UE 702A, second UE 702B, first UE 802A, second UE 802B, relay UE 1106A, 1106B or 1106C, relay UE 1206A, 1206B or 1206C, relay UE 1306A, 1306B or 1306C, relay UE 1406A, 1406B or 1406C, relay UE 1506A, 1506B or 1506C, relay UE 1606A, 1606B or 1606C, or... Figure 19 Device 1904 in the hardware implementation.

[0151] At 1702, the first UE can obtain a first route ID for the first route between the first UE and the second UE. For example, refer to Figure 14 At 1408, relay UE 1406B can obtain a route ID for the route (or hop) between relay UE 1406A and relay UE 1406B, and relay UE 1406C can obtain a route ID for the route between relay UE 1406B and relay UE 1406C. In one aspect, 1702 can be performed by multi-hop relay component 198.

[0152] In some respects, the first UE can retrieve the first route ID from its memory or cache and assign the first route ID to the first route. For example, refer to Figure 14At 1408, relay UE 1406B can retrieve the route ID from its memory or cache and assign the route ID to the hop between relay UE 1406A and relay UE 1406B, and relay UE 1406C can retrieve the route ID from its memory or cache and assign the route ID to the hop between relay UE 1406B and relay UE 1406C.

[0153] At 1704, the first UE can receive data packets originating from the third UE from the second UE, and these data packets indicate the first routing ID. For example, refer to... Figure 14 At 1422, relay UE 1406B can receive data packets originating from remote UE 1404 from relay UE 1406A. At 1426, relay UE 1406C can receive data packets originating from remote UE 1404 from relay UE 1406B. In one aspect, 1704 can be performed by multi-hop relay component 198.

[0154] At 1706, the first UE can identify the third UE based on the first routing ID indicated in the data packet. For example, refer to Figure 14 At 1424, relay UE 1406B can identify remote UE 1404 based on the route ID indicated in the data packet received at 1422. At 1428, relay UE 1406C can identify remote UE 1404 based on the route ID indicated in the data packet received at 1426. In one aspect, 1706 can be performed by multi-hop relay component 198.

[0155] In some aspects, the first UE may assign a second route ID to the second route between the first UE and the fourth UE and forward data packets to the fourth UE via the second route, wherein the forwarded data packets indicate the second route ID. For example, refer to Figure 14 At 1408, relay UE 1406A can assign a route ID to the route between relay UE 1406A and relay UE 1406B, and at 1422, forward data packets originating from remote UE 1404 to relay UE 1406B via this route. At 1408, relay UE 1406B can assign a route ID to the route between relay UE 1406B and relay UE 1406B, and at 1426, forward data packets originating from remote UE 1404 to relay UE 1406C via this route.

[0156] In some respects, the first UE is a donor UE communicatively coupled to the network node, and the third UE is a remote UE. The first UE (i.e., the donor UE) may send an indication to the network node to avoid providing the local routing ID to the remote UE. For example, refer to Figure 14At 1410, relay UE 1406C may provide a SUI message to network node 1402, which includes an indication for network node 1402 to suppress the provision of a local routing ID to remote UE 1404.

[0157] In some aspects, the first UE may receive a second route ID for a second route between the first UE and a network node and forward data packets to the network via the second route. For example, see reference. Figure 14 At 1414, relay UE 1406C can receive a route ID for routing between relay UE 1406C and network node 1402, and at 1430, it can forward data packets received at 1426 via this route.

[0158] In some aspects, the first UE can maintain a mapping between a first route ID and a second route ID, wherein forwarding data packets includes forwarding data packets based on the mapping. For example, refer to Figure 14 At 1416, relay UE 1406C can maintain a mapping between the route ID used for routing between relay UE 1406B and relay UE 1406C and the route ID used for routing between relay UE 1406C and network node 1402. At 1430, relay UE 1406C can forward data packets based on the mapping.

[0159] In some respects, the first UE can provide a mapping from the ProSe layer of the first UE to the AS layer of the first UE. For example, refer to Figure 14 At 1416, the relay UE 1406C can provide a mapping from the ProSe layer of the relay UE 1406C to the AS layer of the relay UE 1406C.

[0160] In some aspects, the first UE can receive the first route ID via the PC5 interface. The first UE can receive the second route ID via the Uu interface. The first UE can provide the first route ID to the donor UE's AS layer via the donor UE's ProSe layer, and the mapping between the first route ID and the second route ID can be maintained via the AS layer. For example, refer to... Figure 14At 1408, relay UE 1406C (i.e., donor UE) can receive a route ID for the route between relay UE 1406B and relay UE 1406C via the PC5 interface from relay UE 1406B. At 1414, relay UE 1406C can receive a route ID for the route between relay UE 1406C and network node 1402 via the Uu interface. At 1416, relay UE 1406C can provide the route ID for the route between relay UE 1406B and relay UE 1406C to the AS layer of relay UE 1406C via the ProSe layer of relay UE 1406C. At 1416, relay UE 1406C can maintain a mapping between the route ID for the route between relay UE 1406B and relay UE 1406C and the route ID for the route between relay UE 1406C and network node 1402 via the AS layer.

[0161] In some respects, the first UE may send the first route ID to the network node after obtaining it. For example, refer to Figure 15 At 1510, relay UE 1506C can provide a SUI message indicating the route ID after obtaining the route ID between relay UE 1506B and relay UE 1506C.

[0162] In some respects, the third UE is a remote UE, and the first routing ID corresponds to the ID of the remote UE. For example, see reference... Figure 15 The routing ID obtained by relay UE 1506C at 1508 can correspond to the ID of remote UE 1504 (e.g., the unique E2E remote ID of remote UE 1504).

[0163] In some respects, the ID of a remote UE may include at least one of the following: a ProSe service layer user information ID associated with the remote UE, a hash-based ID based on the remote UE's ID and a hash function, or the L2 ID of the remote UE. For example, refer to Figure 15 The routing ID obtained by relay UE 1506C may include at least one of the following: the ProSe service layer user information ID associated with remote UE 1504, a hash-based ID based on the ID and hash function of remote UE 1504, or the L2 ID of remote UE 1504.

[0164] In some respects, the first UE can obtain the first route ID by receiving the first route ID from the network node. For example, refer to Figure 16 At 1614, relay UE 1606C can receive a routing ID (e.g., the E2E remote ID of remote UE 1604) from network node 1602.

[0165] In some respects, the first UE may send the first route ID to the second UE via at least one of a PC5-S-based message or a PC5-RRC-based message, based on obtaining the first route ID. For example, refer to Figure 16 At 1614, relay UE1606C can send the route ID to relay UE1606A and / or relay UE1606B via at least one of a PC5-S-based message or a PC5-RRC-based message, based on the obtained route ID.

[0166] In some respects, the first UE may send a SUI message to the network node based on receiving data packets originating from a third UE. The SUI message may indicate that the data packets are based on multi-hop relay and / or hop count information. For example, refer to... Figure 16 At point 1608, UE 1606C can send a SUI message to network node 1602. The SUI message can indicate that data packets are based on multi-hop relay and / or hop count information. In some respects, data packets are included in an RRC establishment request message, as referenced above. Figure 13 As described in 1312.

[0167] Figure 18 This is a flowchart 1800 illustrating a method for wireless communication at a network node according to various aspects of this disclosure. The method can be performed by a network node. The network node can be... Figure 1 The base station or base station component in the access network, or core network component (e.g., base station 102, 310; CU 110, DU 130; RU 140; network node 402, network node 502, first network node 602a, second network node 602b, network node 1102, network node 1202, network node 1302, network node 1402, network node 1502 or network node 1602; or Figure 20 The network entity in the specific hardware implementation (2002).

[0168] At 1802, the network node can obtain a route ID for at least one first route between the network node and the first UE. For example, refer to Figure 14 At 1414, network node 1402 can obtain a route ID for at least one first route between network node 1402 and relay UE 1406C. In another example, refer to... Figure 16 At 1610, network node 1602 can obtain a route ID for at least one first route between network node 1602 and relay UE 1606C. In one aspect, 1802 can be performed by multi-hop relay component 199.

[0169] At 1804, a network node can receive an indication that data packets received by the network node were received via a multi-hop route. For example, refer to... Figure 14 At 1410, network node 1402 can receive an indication that data packets received by network node 1402 were received via multi-hop routing. In another example, refer to... Figure 16 At 1608, network node 1602 can receive an indication that the data packets received by network node 1602 were received via a multi-hop route.

[0170] In some respects, the indication can be a SUI message. For example, see reference. Figure 14 The instruction received at 1410 can be a SUI message. (See reference) Figure 16 The instruction received at 1608 can be a SUI message.

[0171] In one respect, 1804 can be performed by the multi-hop relay component 199.

[0172] At point 1806, a network node can receive data packets originating from a second UE from a first UE based on the routing ID and indication. For example, refer to... Figure 14 At 1430, network node 1402 can receive data packets originating from remote UE 1404 from relay UE 1406C based on the routing ID and indication received at 1410. In another example, refer to... Figure 16 At 1628, network node 1602 can receive data packets originating from remote UE 1604 from relay UE 1606C based on the routing ID and indication received at 1608. In one aspect, 1806 can be performed by multi-hop relay component 199.

[0173] In some respects, network nodes can avoid providing local routing IDs to third-party UEs. For example, refer to... Figure 14 At 1412, network node 1402 can suppress the provision of local routing IDs to remote UE 1404.

[0174] In some respects, a network node can obtain a first route ID by retrieving the route ID from the network node's memory or cache and / or receiving the route ID from the network entity. For example, refer to Figure 14 At point 1414, network node 1402 can obtain the route ID by retrieving the route ID from its memory or cache. (See reference) Figure 16 At 1610, network node 1602 can obtain the route ID by retrieving the route ID from network node 1602's memory or cache, and / or at 1612, it can receive the route ID from OAM server 1607.

[0175] In some aspects, the network node can determine that an RRC-based connection exists between the network node and at least one of a third or fourth UE communicatively coupled to the first UE, and provide a routing ID to at least one of the third or fourth UEs via the RRC-based connection. For example, refer to Figure 14 At 1414, network node 1402 can determine that an RRC-based connection exists between network node 1402 and relay UE 1406C and provide a routing ID to relay UE 1406C (e.g., using an RRC message sent via the RRC-based connection). (See reference) Figure 16 At 1614, network node 1602 can determine that there is an RRC-based connection between network node 1602 and at least one of relay UE 1606C, relay UE 160B, relay UE 1606A and / or remote UE 1604, and provide a routing ID to at least one of relay UE 1606C, relay UE 1606B, relay UE 1606A and / or remote UE 1604 via the RRC-based connection (e.g., using an RRC message sent via the RRC-based connection).

[0176] In some aspects, network nodes can provide a routing ID by providing the routing ID to at least one of the first UE or the second UE via RRC-based message delivery. For example, refer to Figure 16 At 1614, network node 1602 can provide a route ID by providing a route ID to at least one of relay UE 1606C, relay UE 1606B, relay UE 1606A and / or remote UE 1604 via RRC-based message transmission.

[0177] Figure 19Figure 1900 illustrates an example of a hardware implementation for device 1904. Device 1904 may be a UE, a component of a UE, or implement UE functionality. In some aspects, device 1904 may include at least one cellular baseband processor 1924 (also referred to as a modem) coupled to one or more transceivers 1922 (e.g., cellular RF transceivers). Cellular baseband processor 1924 may include on-chip memory 1924'. In some aspects, device 1904 may also include one or more Subscriber Identity Module (SIM) cards 1920 and at least one application processor 1906 coupled to a Secure Digital Card (SD) card 1908 and a screen 1910. Application processor 1906 may include on-chip memory 1906'. In some aspects, device 1904 may also include a Bluetooth module 1912, a WLAN module 1914, an SPS module 1916 (e.g., a GNSS module), one or more sensor modules 1918 (e.g., a barometric pressure sensor / altimeter; motion sensors such as an inertial measurement unit (IMU), a gyroscope, and / or an accelerometer; light detection and ranging (LIDAR), radio-assisted detection and ranging (RADAR), sound navigation and ranging (SONAR), a magnetometer, audio, and / or other technologies for positioning), an additional memory module 1926, a power source 1930, and / or a camera 1932. Bluetooth module 1912, WLAN module 1914, and SPS module 1916 may include on-chip transceivers (TRX) (or in some cases, only receivers (RX)). Bluetooth module 1912, WLAN module 1914, and SPS module 1916 may include their own dedicated antennas and / or communicate using antenna 1980. Cellular baseband processor 1924 communicates with UE 104 and / or RU associated with network entity 1902 via transceiver 1922 through one or more antennas 1980. Cellular baseband processor 1924 and application processor 1906 may each include computer-readable media / memory 1924', 1906' respectively. Additional memory module 1926 may also be considered as computer-readable media / memory. Each computer-readable media / memory 1924', 1906', 1926 may be non-transitory. Cellular baseband processor 1924 and application processor 1906 are each responsible for general processing, including the execution of software stored on the computer-readable media / memory. When executed by cellular baseband processor 1924 / application processor 1906, the software causes cellular baseband processor 1924 / application processor 1906 to perform the various functions described above. The computer-readable media / memory can also be used to store data manipulated by cellular baseband processor 1924 / application processor 1906 during software execution.Cellular baseband processor 1924 / application processor 1906 may be a component of UE 350 and may include at least one memory 360 and / or at least one of the following: TX processor 368, RX processor 356, and controller / processor 359. In one configuration, device 1904 may be a processor chip (modem and / or application) and may only include cellular baseband processor 1924 and / or application processor 1906, while in another configuration, device 1904 may be the entire UE (see, for example). Figure 3 The UE 350 includes an additional module for device 1904.

[0178] As discussed above, component 198 can be configured to: obtain a first route ID for a first route between the first UE and the second UE; receive a data packet originating from the third UE from the second UE, the data packet indicating the first route ID; and identify the third UE based on the first route ID indicated in the data packet. Component 198 can be configured to perform a combination. Figure 17 The flowchart in the document describes various aspects and / or is composed of Figures 11 to 16 The communication flow includes any of the following aspects performed by relay UEs 1106A, 1106B and / or 1106C, 1206A, 1206B and / or 1206C, 1306A, 1306B and / or 1306C, 1406A, 1406B and / or 1406C, 1506A, 1506B and / or 1506C and / or 1606A, 1606B and / or 1606C. Component 198 may be located within the cellular baseband processor 1924, the application processor 1906, or both the cellular baseband processor 1924 and the application processor 1906. Component 198 may be one or more hardware components specifically configured to perform the stated process / algorithm, implemented by one or more processors configured to execute the stated process / algorithm, stored in a computer-readable medium for implementation by one or more processors, or some combination thereof. When multiple processors are implemented, the multiple processors may execute the stated process / algorithm individually or in combination. As shown, device 1904 may include various components configured for various functions. In one configuration, device 1904 (and specifically cellular baseband processor 1924 and / or application processor 1906) may include: components for obtaining a first route ID for a first route between a first UE and a second UE; components for receiving data packets originating from a third UE from the second UE, the data packets indicating the first route ID; and components for identifying the third UE based on the first route ID indicated in the data packets. The device may also include components for performing a combination Figure 17 The flowchart in the document describes various aspects and / or is composed of Figures 11 to 16 The component is a part of any of the aspects performed by relay UEs 1106A, 1106B and / or 1106C, 1206A, 1206B and / or 1206C, 1306A, 1306B and / or 1306C, 1406A, 1406B and / or 1406C, 1506A, 1506B and / or 1506C and / or 1606A, 1606B and / or 1606C in the communication flow. This component may be a component 198 of device 1904 configured to perform the functions described therein. As described above, device 1904 may include a TX processor 368, an RX processor 356, and a controller / processor 359. Therefore, in one configuration, the component may be a TX processor 368, an RX processor 356, and / or a controller / processor 359 configured to perform the functions described therein.

[0179] Figure 20Figure 2000 illustrates an example of a hardware implementation for network entity 2002. Network entity 2002 may be a BS, a component of a BS, or implement BS functionality. Network entity 2002 may include at least one of CU 2010, DU 2030, or RU 2040. For example, depending on the layer functionality handled by component 199, network entity 2002 may include: CU 2010; both CU 2010 and DU 2030; each of CU 2010, DU 2030, and RU 2040; DU 2030; both DU 2030 and RU 2040; or RU 2040. CU 2010 may include at least one CU processor 2012. CU processor 2012 may include on-chip memory 2012'. In some aspects, CU 2010 may also include an additional memory module 2014 and a communication interface 2018. CU2010 communicates with DU 2030 via a midhaul link, such as an F1 interface. DU 2030 may include at least one DU processor 2032. DU processor 2032 may include on-chip memory 2032'. In some aspects, DU 2030 may also include an additional memory module 2034 and a communication interface 2038. DU 2030 communicates with RU 2040 via a fronthaul link. RU 2040 may include at least one RU processor 2042. RU processor 2042 may include on-chip memory 2042'. In some aspects, RU 2040 may also include an additional memory module 2044, one or more transceivers 2046, an antenna 2080, and a communication interface 2048. RU 2040 communicates with UE 104. On-chip memories 2012', 2032', 2042' and additional memory modules 2014, 2034, 2044 may each be considered as computer-readable media / memory. Each computer-readable medium / memory can be non-transitory. Each of processors 2012, 2032, and 2042 is responsible for general processing, including executing software stored on the computer-readable medium / memory. When executed by the corresponding processor, the software causes that processor to perform the various functions described above. The computer-readable medium / memory can also be used to store data manipulated by the processor while executing the software.

[0180] As discussed above, component 199 can be configured to: obtain a route ID for at least one first route between the network node and the first UE; receive an indication that data packets received by the network node were received via a multi-hop route; and receive data packets originating from the second UE from the first UE based on the route ID and the indication. Component 199 can be configured to perform a combination Figure 18 The flowchart in the document describes various aspects and / or is composed of Figures 11 to 16The communication flow in the network node 1102, network node 1202, network node 1302, network node 1402, network node 1502, and / or network node 1602 executes any of the aspects. Component 199 may reside within one or more processors of one or more of CU 2010, DU 2030, and RU 2040. Component 199 may be one or more hardware components specifically configured to perform the stated process / algorithm, implemented by one or more processors configured to execute the stated process / algorithm, stored in a computer-readable medium for implementation by one or more processors, or some combination thereof. When multiple processors are implemented, the multiple processors may execute the stated process / algorithm individually or in combination. Network entity 2002 may include a variety of components configured for various functions. In one configuration, network entity 2002 may include: components for obtaining a route ID for at least one first route between a network node and a first UE; components for receiving an indication that a data packet received by the network node was received via a multi-hop route; and components for receiving data packets originating from a second UE from the first UE based on the route ID and the indication. The apparatus may also include components for performing a combination. Figure 18 The flowchart in the document describes various aspects and / or is composed of Figures 11 to 16 The component is a part of any of the aspects performed by network nodes 1102, 1202, 1302, 1402, 1502, and / or 1602 in the communication flow. The component may be a component 199 of network entity 2002 configured to perform the functions described therein. As described above, network entity 2002 may include a TX processor 316, an RX processor 370, and a controller / processor 375. Therefore, in one configuration, the component may be the TX processor 316, the RX processor 370, and / or the controller / processor 375 configured to perform the functions described therein.

[0181] Referring to the accompanying drawings, various aspects of this disclosure relate generally to communication systems. Some aspects relate more specifically to multi-hop UE-to-network (U2N) relay. In some examples, a UE (e.g., a remote UE and / or a relay UE) may assign one or more routing identifiers (IDs) to one or more routes (or hops) via which the UE sends data to and / or receives data from another UE. Such routing IDs may be associated with a remote UE and may be indicated in data packets received by the UE. Thus, the UE may use the routing ID to determine whether a data packet originates from a remote UE or to determine whether the remote UE is the intended destination of the data packet. The routing ID may be unique for each hop in a multi-hop relay. Alternatively, the same routing ID may be used for each hop. In another example, a network node may assign a routing ID for each hop instead of the UE.

[0182] Specific aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. In some examples, by assigning a routing ID to a hop in a multi-hop relay and associating such a routing ID with a remote UE, the remote UE can be correctly identified by other UEs in the multi-hop relay. Therefore, the relay UE can be able to route the services of the remote UE to its correct destination (e.g., a network node), thereby enabling network coverage to extend to remote UEs outside the network's coverage area.

[0183] It should be understood that the specific order or hierarchy of the boxes in the disclosed process / flowcharts is merely an example of the exemplary method. It should be understood that the specific order or hierarchy of the boxes in the process / flowcharts may be rearranged based on design preferences. Furthermore, some boxes may be combined or omitted. The appended method claims present the elements of various boxes in a sample order, but are not limited to the given specific order or hierarchy.

[0184] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not limited to the aspects described herein but should be given the full scope consistent with the language of the claims. Unless specifically stated otherwise, references to elements in the singular form do not mean “one and only one” but rather “one or more.” Terms such as “if,” “when,” and “simultaneously” do not imply a direct temporal relationship or reaction. That is, these phrases, such as “when…”, do not imply an immediate action in response to the occurrence of an action or during the occurrence of an action, but simply suggest that if a condition is met, then the action will occur, without requiring a specific or immediate time limit for the occurrence of the action. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or superior to other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" include any combination of A, B, and / or C, and may include multiple A, multiple B, or multiple C. Specifically, combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" may be only A, only B, only C, A and B, A and C, B and C, or A and B and C, wherein any such combination may contain one or more members of A, B, or C. A set should be interpreted as a set of elements in which the number of elements is one or more. Therefore, for a set of X, X will include one or more elements. When at least one processor is configured to execute a set of functions, the at least one processor is configured to execute the set of functions individually or in any combination. Therefore, each of the at least one processor can be configured to perform a specific subset of the set of functions, wherein the subset is the complete set, a suitable subset of the set, or an empty subset of the set. If the first device receives data from or sends data to the second device, data can be received / sent directly between the first and second devices, or indirectly between the first and second devices via a set of devices. A device configured to “output” data (such as transmission, signaling, or a message) can, for example, transmit the data using a transceiver, or can transmit the data to the device that sent the data. A device configured to “receive” data (such as transmission, signaling, or a message) can, for example, receive the data using a transceiver, or can obtain the data from the device that received the data.Information stored in memory includes instructions and / or data. All structural and functional equivalents of the elements throughout the various aspects described herein that are known to or will later be known to a person skilled in the art are expressly incorporated herein by reference and are covered by the claims. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is explicitly recited in the claims. The terms “module,” “mechanism,” “element,” “device,” etc., cannot replace the word “component.” Therefore, no claim element will be construed as a functional component unless the element is explicitly described using the phrase “component for…”.

[0185] As used in this article, the phrase “based on” should not be interpreted as referring to a closed set of information, one or more conditions, one or more factors, etc. In other words, the phrase “based on A” (where “A” can be information, conditions, factors, etc.) should be interpreted as “based on at least A”, unless otherwise stated otherwise.

[0186] The following aspects are merely illustrative and may be combined with other aspects or teachings described herein without limitation.

[0187] Aspect 1 is a method for wireless communication at a first UE, the method comprising: obtaining a first route identifier (ID) for a first route between the first UE and a second UE; receiving a data packet originating from a third UE from the second UE, the data packet indicating the first route ID; and identifying the third UE based on the first route ID indicated in the data packet.

[0188] Aspect 2 is the method according to aspect 1, wherein obtaining the first route ID includes: retrieving the first route ID from the memory or cache of the first UE; and assigning the first route ID to the first route.

[0189] Aspect 3 is the method according to aspect 2, the method further comprising: assigning a second route ID to a second route between the first UE and the fourth UE; and forwarding the data packet to the fourth UE via the second route, wherein the forwarded data packet indicates the second route ID.

[0190] Aspect 4 is a method according to any one of Aspects 1 to 3, wherein the first UE is a donor UE communicatively coupled to a network node, and wherein the third UE is a remote UE, the method further comprising: sending to the network node an indication to avoid providing a local routing ID to the remote UE.

[0191] Aspect 5 is the method according to aspect 4, the method further comprising: receiving a second route ID for a second route between the first UE and the network node; and forwarding the data packet to the network node via the second route.

[0192] Aspect 6 is the method according to aspect 5, the method further comprising: maintaining a mapping between the first route ID and the second route ID, wherein forwarding the data packet includes forwarding the data packet based on the mapping.

[0193] Aspect 7 is the method according to aspect 6, the method further comprising: providing a mapping from the neighbor service layer of the first UE to the access layer of the first UE.

[0194] Aspect 8 is a method according to any one of Aspects 5 to 7, wherein obtaining the first routing ID comprises: receiving the first routing ID via a PC5 interface, and wherein receiving the second routing ID comprises: receiving the second routing ID via a UE-to-Universal Mobile Telecommunications System Terrestrial Radio Access Network (UE-UTRAN) (Uu) interface, the method further comprising: maintaining a mapping between the first routing ID and the second routing ID via the access layer of the donor UE.

[0195] Aspect 9 is the method according to any one of aspects 1 to 8, the method further comprising: sending the first route ID to a network node after obtaining the first route ID.

[0196] Aspect 10 is the method according to aspects 1 to 9, wherein the third UE is a remote UE, and wherein the first routing ID corresponds to the ID of the remote UE.

[0197] Aspect 11 is the method according to aspect 10, wherein the ID of the remote UE includes at least one of the following: a neighboring service layer user information ID associated with the remote UE; a hash-based ID based on the ID of the remote UE and a hash function; or the layer 2 (L2) ID of the remote UE.

[0198] Aspect 12 is the method according to aspect 1, wherein obtaining the first route ID includes: receiving the first route ID from a network node.

[0199] Aspect 13 is a method according to any one of Aspect 1 or 12, the method further comprising: based on obtaining the first routing ID, sending the first routing ID to the second UE via at least one of: a PC5 signaling (PC5-S) message; or a PC5 radio resource control (RRC) message.

[0200] Aspect 14 is a method according to any one of aspects 1, 12 or 13, the method further comprising: sending a sidelink UE information message to a network node based on receiving the data packet originating from the third UE, wherein the sidelink UE information message indicates at least one of the following: the data packet is based on multi-hop relay; or hop count information.

[0201] Aspect 15 is a method for wireless communication at a network node, the method comprising: obtaining a routing identifier (ID) for at least one first route between the network node and a first user equipment (UE); receiving an indication that data packets received by the network node are received via a multi-hop route; and receiving data packets originating from a second UE from the first UE based on the routing ID and the indication.

[0202] Aspect 16 is the method according to aspect 15, the method further comprising: avoiding providing a local routing ID to a third UE.

[0203] Aspect 17 is a method according to any one of Aspects 15 or 16, wherein obtaining the first route ID includes at least one of: retrieving the route ID from the memory or cache of the network node; or receiving the route ID from a network entity.

[0204] Aspect 18 is a method according to any one of aspects 15 to 17, the method further comprising: determining that an RRC-based connection exists between the network node and at least one of a third UE or a fourth UE communicatively coupled to the first UE, and providing the routing ID to the at least one of the third UE or the fourth UE.

[0205] Aspect 19 is the method according to aspect 18, wherein providing the routing ID includes: providing the routing ID to at least one of the first UE or the second UE via radio resource control (RRC) based message transmission.

[0206] Aspect 20 is the method according to any one of aspects 15 to 19, wherein the indication is a side-link UE information message.

[0207] Aspect 21 is an apparatus for wireless communication at a UE. The apparatus includes: at least one memory; and at least one processor coupled to the at least one memory and based at least in part on information stored in the at least one memory, the at least one processor being configured individually or in any combination to implement any one of aspects 1 to 14.

[0208] Aspect 22 is the apparatus according to aspect 21, the apparatus further comprising at least one of a transceiver or an antenna coupled to the at least one processor.

[0209] Aspect 23 is an apparatus for wireless communication at a network node. The apparatus includes: at least one memory; and at least one processor coupled to the at least one memory and based at least in part on information stored in the at least one memory, the at least one processor being configured individually or in any combination to implement any one of aspects 15 to 20.

[0210] Aspect 24 is the apparatus according to aspect 2, the apparatus further comprising at least one of a transceiver or an antenna coupled to the at least one processor.

[0211] Aspect 25 is an apparatus for wireless communication, the apparatus including components for implementing any one of aspects 1 to 14.

[0212] Aspect 26 is an apparatus for wireless communication, the apparatus including components for implementing any one of aspects 15 to 20.

[0213] Aspect 27 is a computer-readable medium (e.g., a non-transitory computer-readable medium) storing computer-executable code, wherein the code, when executed by at least one processor, causes the at least one processor to implement any one of aspects 1 to 14 individually or in any combination.

[0214] Aspect 28 is a computer-readable medium (e.g., a non-transitory computer-readable medium) storing computer-executable code, wherein the code, when executed by at least one processor, causes the at least one processor to implement any one of aspects 15 to 20 individually or in any combination.

Claims

1. An apparatus for performing wireless communication at a first user equipment (UE), the apparatus comprising: At least one memory; and At least one processor, coupled to the at least one memory, and configured individually or in any combination, based at least in part on information stored in the at least one memory, to: Obtain a first route identifier (ID) for the first route between the first UE and the second UE; Receive data packets originating from a third UE from the second UE, the data packets indicating the first routing ID; as well as The third UE is identified based on the first routing ID indicated in the data packet.

2. The apparatus of claim 1, wherein, in order to obtain the first route ID, the at least one processor is configured individually or in any combination to: Retrieve the first route ID from the memory or cache of the first UE; and Assign the first route ID to the first route.

3. The apparatus of claim 2, wherein the at least one processor is further configured, alone or in any combination, to: Assign the second route ID to the second route between the first UE and the fourth UE; and The data packet is forwarded to the fourth UE via the second route, wherein the forwarded data packet indicates the second route ID.

4. The apparatus of claim 1, wherein the first UE is a donor UE communicatively coupled to a network node, and wherein the third UE is a remote UE, wherein the at least one processor is further configured, individually or in any combination, to: Send an instruction to the network node to avoid providing the local routing ID to the remote UE.

5. The apparatus of claim 4, wherein the at least one processor, alone or in any combination, is further configured to: Receive a second route ID for a second route between the first UE and the network node; and The data packets are forwarded to the network node via the second route.

6. The apparatus of claim 5, wherein the at least one processor is further configured, alone or in any combination, to: Maintain a mapping between the first route ID and the second route ID, wherein, in order to forward the data packets, the at least one processor is configured individually or in any combination to: The data packets are forwarded based on the mapping.

7. The apparatus of claim 6, wherein the at least one processor, alone or in any combination, is further configured to: Provides a mapping from the neighbor service layer of the first UE to the access layer of the first UE.

8. The apparatus of claim 5, wherein, in order to obtain the first route ID, the at least one processor is configured individually or in any combination to: The first route ID is received via a PC5 interface, and in order to receive the second route ID, the at least one processor is configured individually or in any combination to: The second routing ID is received via the UE-UTRAN (Uu) interface, wherein the at least one processor is also configured, individually or in any combination, to: The mapping between the first route ID and the second route ID is maintained via the access layer of the donor UE.

9. The apparatus of claim 1, wherein the at least one processor is further configured, alone or in any combination, to: After obtaining the first route ID, send the first route ID to the network node.

10. The apparatus of claim 1, wherein the third UE is a remote UE, and wherein the first routing ID corresponds to the ID of the remote UE.

11. The apparatus of claim 10, wherein the ID of the remote UE comprises at least one of the following: The neighboring service layer user information ID associated with the remote UE; Based on the ID of the remote UE and a hash-based ID derived from a hash function; or The Layer 2 (L2) ID of the remote UE.

12. The apparatus of claim 1, wherein, in order to obtain the first route ID, the at least one processor is configured individually or in any combination to: Receive the first route ID from the network node.

13. The apparatus of claim 1, wherein the at least one processor is further configured, alone or in any combination, to: Based on obtaining the first route ID, the first route ID is sent to the second UE via at least one of the following: Messages based on PC5 signaling (PC5-S); or Messages based on PC5 Radio Resource Control (RRC).

14. The apparatus of claim 1, wherein the at least one processor is further configured, alone or in any combination, to: Based on the received data packet originating from the third UE, a sidelink UE information message is sent to the network node, wherein the sidelink UE information message indicates at least one of the following: The data packets are based on multi-hop relay; or Jump count information.

15. An apparatus for wireless communication at a network node, the apparatus comprising: At least one memory; and At least one processor, coupled to the at least one memory, and configured individually or in any combination, based at least in part on information stored in the at least one memory, to: Obtain a routing identifier (ID) for at least one first route between the network node and the first user equipment (UE); Receive an indication that the data packets received by the network node were received via a multi-hop route; as well as Based on the routing ID and the indication, data packets originating from the second UE are received from the first UE.

16. The apparatus of claim 15, wherein the at least one processor is further configured, alone or in any combination, to: Avoid providing the local routing ID to third-party UEs.

17. The apparatus of claim 15, wherein, in order to obtain the first route ID, the at least one processor is configured, individually or in any combination, to perform at least one of the following: Retrieve the route ID from the network node's memory or cache; or Receive the routing ID from the network entity.

18. The apparatus of claim 15, wherein the at least one processor is further configured, alone or in any combination, to: Determine that a Radio Resource Control (RRC)-based connection exists between the network node and at least one of a third or fourth UE communicatively coupled to the first UE; and The routing ID is provided to at least one of the third UE or the fourth UE via the RRC-based connection.

19. The apparatus of claim 18, wherein, in order to provide the routing ID, the at least one processor is configured individually or in any combination to: The routing ID is provided to at least one of the first UE or the second UE via radio resource control (RRC) based message transmission.

20. The apparatus of claim 15, wherein the indication is a side-link UE information message.

21. A method for wireless communication at a first user equipment (UE), the method comprising: Obtain a first route identifier (ID) for the first route between the first UE and the second UE; Receive data packets originating from a third UE from the second UE, the data packets indicating the first routing ID; as well as The third UE is identified based on the first routing ID indicated in the data packet.

22. The method of claim 21, wherein obtaining the first route ID comprises: Retrieve the first route ID from the memory or cache of the first UE; as well as Assign the first route ID to the first route.

23. The method according to claim 22, further comprising: Assign the second route ID to the second route between the first UE and the fourth UE; as well as The data packet is forwarded to the fourth UE via the second route, wherein the forwarded data packet indicates the second route ID.

24. The method of claim 21, wherein the first UE is a donor UE communicatively coupled to a network node, and wherein the third UE is a remote UE, the method further comprising: Send an instruction to the network node to avoid providing the local routing ID to the remote UE.

25. The method according to claim 24, further comprising: Receive a second route ID for a second route between the first UE and the network node; as well as The data packets are forwarded to the network node via the second route.

26. The method according to claim 25, further comprising: Maintaining a mapping between the first route ID and the second route ID, wherein forwarding the data packets includes: The data packets are forwarded based on the mapping.

27. The method according to claim 26, further comprising: Provides a mapping from the neighbor service layer of the first UE to the access layer of the first UE.

28. The method of claim 25, wherein obtaining the first route ID comprises: Receiving the first route ID via the PC5 interface, wherein receiving the second route ID includes: The method further includes receiving the second routing ID via the UE-UTRAN (Uu) interface of the UE to the Universal Mobile Telecommunications System Terrestrial Radio Access Network (UE-UTRAN). The mapping between the first route ID and the second route ID is maintained via the access layer of the donor UE.

29. The method according to claim 21, further comprising: After obtaining the first route ID, send the first route ID to the network node.

30. A method for wireless communication at a network node, the method comprising: Obtain a routing identifier (ID) for at least one first route between the network node and the first user equipment (UE); Receive an indication that the data packets received by the network node were received via a multi-hop route; as well as Based on the routing ID and the indication, data packets originating from the second UE are received from the first UE.

Images