Method and apparatus for identifier allocation in a communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Specifically, disclosed is a disclosure related to a method performed by a first user equipment (UE) in wireless communication, the method comprising: identifying a second UE for sidelink communication; allocating an identifier (ID) of the source UE and an ID of the destination UE; and transmitting information related to the ID of the source UE and information related to the ID of the destination UE to the second UE, where the information related to the ID of the source UE and the information related to the ID of the destination UE are used for communicating between the source UE and the destination UE via the first UE.

Description

Technical Field

[0001] Certain examples of this disclosure relate to methods, apparatus, and / or systems for configuring and / or signaling identifiers in a communication system. Specifically, some examples relate to allocating identifiers in a centralized or distributed manner in a UE-to-UE relay. In some examples, identifiers are allocated at each hop or level in the relay to provide a local ID for each hop. According to various examples, the local ID identifies the source (or transmitting) UE and the destination (or receiving) UE at each hop in the relay. Background Technology

[0002] 5G mobile communication technology defines a wide frequency band, enabling high transmission rates and new services. It can be implemented not only in "sub-6GHz" bands such as 3.5GHz, but also in "above 6GHz" bands, including 28GHz and 39GHz, known as millimeter waves (mmWave). Furthermore, 6G mobile communication technology (referred to as "super 5G systems") is being considered for implementation in terahertz bands (e.g., the 95GHz to 3THz band) to achieve transmission rates 50 times faster than 5G and ultra-low latency one-tenth that of 5G.

[0003] In the early stages of 5G mobile communication technology development, to support services and meet performance requirements related to enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC), standardization has been ongoing for the following technologies: beamforming and massive MIMO for reducing radio wave path loss and increasing radio wave transmission distance in millimeter waves; support parameter sets for dynamic operation (e.g., operating multiple subcarrier spacings) for efficient utilization of millimeter wave resources and time slot formats; initial access technologies for supporting multi-beam transmission and broadband; definition and operation of BWP (bandwidth portion); new channel coding methods such as LDPC (low-density parity-check) codes for large-volume data transmission and polar codes for highly reliable transmission of control information; L2 preprocessing; and network slicing for providing dedicated networks for specific services.

[0004] Currently, regarding the services supported by 5G mobile communication technology, the industry is discussing improvements and performance enhancements to the initial 5G mobile communication technology, and physical layer standardization has been completed for technologies such as: V2X (vehicle-to-everything) for assisting autonomous vehicle driving decisions based on information sent by the vehicle about its location and status and for improving user convenience; NR-U (New Radio Unlicensed) designed to comply with various regulatory requirements for system operation in unlicensed frequency bands; NR UE power saving; non-terrestrial networks (NTNs) for direct satellite communication between UEs to ensure coverage in areas where they cannot communicate with terrestrial networks; and positioning.

[0005] Furthermore, standardization of air interface architectures / protocols for technologies such as: Industrial Internet of Things (IIoT) for supporting new services through interoperability and integration with other industries; IAB (Integrated Access and Backhaul) for providing nodes for network service area extension by supporting wireless backhaul and access links in an integrated manner; mobility enhancements including conditional handover and DAPS (Dual Active Stack) handover; and two-step random access (two-step RACH for NR) for simplifying the random access process. Meanwhile, standardization of system architectures / services for technologies such as: 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies; and mobile edge computing (MEC) for receiving services based on UE location.

[0006] With the commercialization of 5G mobile communication systems, an exponential increase in connected devices will be applied to communication networks, thus necessitating enhanced functionality and performance of 5G mobile communication systems as well as integrated operation of connected devices. To this end, new research is planned related to the following technologies: Extended Reality (XR) for efficient support of AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality), etc.; 5G performance improvements and complexity reduction through the utilization of Artificial Intelligence (AI) and Machine Learning (ML); AI service support; Metaverse service support; and drone communication.

[0007] Furthermore, this development of 5G mobile communication systems will not only lay the foundation for the development of technologies such as: new waveforms for providing coverage in the terahertz band of 6G mobile communication technology; multi-antenna transmission technologies such as full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO; metamaterial-based lenses and antennas for improving coverage of terahertz band signals; high-dimensional spatial multiplexing technologies using OAM (orbital angular momentum); and RIS (reconfigurable smart surfaces), but will also lay the foundation for the development of technologies such as: full-duplex technologies for improving the frequency efficiency of 6G mobile communication technology and improving system networks; AI-based communication technologies for achieving system optimization by leveraging satellites and AI (artificial intelligence) from the design stage and internalizing end-to-end AI support functions; and next-generation distributed computing technologies for achieving services with a level of complexity exceeding the operational capabilities of UEs by utilizing ultra-high-performance communication and computing resources.

[0008] Fifth-generation (5G) or new radio (NR) mobile communications has recently gained increasing momentum due to global technological activities from industry and academia regarding various candidate technologies. Key candidate technologies for 5G / NR mobile communications include: massive MIMO technologies, ranging from traditional cellular bands to higher frequencies, for providing beamforming gain and supporting increased capacity; new waveforms for flexibly adapting to various services / applications with different requirements (e.g., new radio access technologies (RATs)); and new multiple access schemes for supporting massive connectivity. Summary of the Invention

[0009] [Technical Issues]

[0010] As communication systems evolve, there is a need for identifier allocation associated with the Sidelink Relay Adaptation Protocol (SRAP).

[0011] The technical topics explored in this disclosure may not be limited to those described above, and other unmentioned technical topics will be clearly understood by those skilled in the art from the following description.

[0012] [Solution to the problem]

[0013] According to an example, a first entity is provided in a communication system, wherein the communication system includes a plurality of entities, the plurality of entities including the first entity, and the first entity includes: a transmitter; and a controller configured to: configure one or more identifiers, each identifier being set to indicate a pair of entities among the plurality of entities; wherein the plurality of entities includes a source SRC end entity, at least one intermediate entity, and a destination DST end entity; wherein each pair of entities includes an SRC entity and a DST entity communicatively connected to the SRC entity, and no pair of entities includes both an SRC end entity and a DST end entity. According to another example, a second entity is provided in a communication system, wherein the communication system includes a plurality of entities, the plurality of entities including the second entity, and the second entity includes: a receiver; a transmitter; and a controller configured to: receive information including a first identifier from the first entity among the plurality of entities, the first identifier indicating a first pair including the first entity and a second entity; receive a packet from the first entity; and transmit the packet to a third entity based on the first identifier; wherein the plurality of entities includes a source SRC end entity, at least one intermediate entity, and a destination DST end entity; and wherein, in the first pair, the third entity is a DST entity, and the second entity is an SRC entity communicatively connected to the DST entity.

[0014] According to embodiments of this disclosure, a method performed by a first user equipment (UE) in a wireless communication system is provided, the method comprising: identifying a second UE for sidelink communication; assigning an identifier (ID) of a source UE and an ID of a destination UE; and sending information relating to the ID of the source UE and information relating to the ID of the destination UE to the second UE, wherein the information relating to the ID of the source UE and the information relating to the ID of the destination UE are used for communication between the source UE and the destination UE via the first UE.

[0015] According to embodiments of this disclosure, the first UE includes a relay UE, and the second UE includes at least one of a source UE or a destination UE.

[0016] According to embodiments of this disclosure, information relating to the ID of the source UE and information relating to the ID of the destination UE are included in the Side Link Relay Adaptation Protocol (SRAP) header.

[0017] According to embodiments of this disclosure, the SRAP header further includes information related to the carried ID.

[0018] According to embodiments of this disclosure, a first user equipment (UE) in a wireless communication system is provided, and the first UE includes: a transceiver; and at least one processor connected to the transceiver and configured to: identify a second UE for sidelink communication, assign an identifier (ID) of a source UE and an ID of a destination UE, and send information related to the ID of the source UE and information related to the ID of the destination UE to the second UE, wherein the information related to the ID of the source UE and the information related to the ID of the destination UE are used for communication between the source UE and the destination UE via the first UE.

[0019] According to embodiments of this disclosure, a second user equipment (UE) in a wireless communication system includes: a transceiver; and at least one processor connected to the transceiver and configured to: receive from a first UE information relating to an identifier (ID) of a source UE and information relating to an ID of a destination UE, wherein the ID of the source UE and the ID of the destination UE are assigned by the first UE, and wherein the information relating to the ID of the source UE and the information relating to the ID of the destination UE are used for communication between the source UE and the destination UE via the first UE.

[0020] According to embodiments of this disclosure, a first entity is provided in a communication system, wherein the communication system includes a plurality of entities, the plurality of entities including the first entity, the first entity including: a transmitter; and a controller configured to: configure one or more identifiers, each identifier being set to indicate a pair of entities among the plurality of entities; wherein the plurality of entities includes a source SRC end entity, at least one intermediate entity, and a destination DST end entity; wherein each pair of entities includes an SRC entity and a DST entity communicatively connected to the SRC entity, and no pair of entities includes both an SRC end entity and a DST end entity.

[0021] According to embodiments of this disclosure, each pair of entities includes: one of an SRC end entity or a DST end entity, and one of at least one intermediate entity; or if multiple entities include at least two intermediate entities, then each pair of entities includes two different intermediate entities among the at least two intermediate entities.

[0022] According to embodiments of this disclosure, the first pair of entities includes an SRC end entity and a first intermediate entity communicatively connected to the SRC entity; and the second pair of entities includes a second intermediate entity and a DST end entity communicatively connected to the second intermediate entity.

[0023] According to embodiments of this disclosure, wherein: if the plurality of entities includes only one intermediate entity, then the first intermediate entity is the second intermediate entity; if the plurality of entities includes at least two intermediate entities, then the second intermediate entity is different from the first intermediate entity, and a third pair of entities includes the first intermediate entity and a second intermediate entity communicatively connected to the first intermediate entity; and / or if the plurality of entities includes at least three intermediate entities, then the second intermediate entity is different from the first intermediate entity, a third pair of entities includes the first intermediate entity and a third intermediate entity communicatively connected to the first intermediate entity, and a fourth pair of entities includes the third intermediate entity and a second intermediate entity communicatively connected to the third intermediate entity.

[0024] According to embodiments of this disclosure, if multiple identifiers are configured, each identifier uniquely corresponds to each pair; or if only one identifier is configured, the first entity is the SRC entity in a pair of entities indicated by the configured indicator.

[0025] According to embodiments of this disclosure, the controller is configured to send one or more identifiers to at least one of a plurality of entities other than the first entity.

[0026] According to embodiments of this disclosure, the controller is configured to obtain information relating to a plurality of entities other than a first entity, and to configure one or more identifiers based on the received information.

[0027] According to embodiments of this disclosure, the controller is configured to send the identifier of the SRC end entity and the identifier of the DST end entity to at least one of a plurality of entities.

[0028] According to embodiments of this disclosure, the controller is configured to send configuration information to at least one entity, the configuration information including one or more identifiers, an identifier of the SRC entity and an identifier of the DST end entity, and information related to the channel between the SRC entity and the DST entity.

[0029] According to embodiments of this disclosure, the channel is a PC5 RLC channel, and the information includes information relating to the egress PC5 RLC channel and / or information relating to the ingress PC5 RLC channel.

[0030] According to embodiments of this disclosure, a shared identifier is used for the identifier of the SRC end entity and the identifier of the DST end entity.

[0031] According to embodiments of this disclosure, a configuration identifier corresponding to a pair of entities further indicates a next entity communicatively connected to the DST entity in the pair of entities.

[0032] According to embodiments of this disclosure, the first entity is one of an SRC end entity, at least one intermediate entity, or a base station; and / or each of the plurality of entities is a different user equipment (UE).

[0033] According to embodiments of this disclosure, the DST entity is communicatively connected to the SRC entity, enabling the SRC entity and the DST entity to communicate directly.

[0034] According to embodiments of this disclosure, a second entity is included in a communication system, wherein the communication system includes a plurality of entities, the plurality of entities including the second entity, the second entity including: a receiver; a transmitter; and a controller configured to: receive information including a first identifier from a first entity among the plurality of entities, the first identifier indicating a first pair including the first entity and the second entity; receive packets from the first entity; and transmit packets to a third entity based on the first identifier; wherein the plurality of entities includes a source SRC end entity, at least one intermediate entity, and a destination DST end entity; and wherein, in the first pair, the third entity is a DST entity, and the second entity is an SRC entity communicatively connected to the DST entity.

[0035] According to embodiments of this disclosure, a method performed by a first user equipment (UE) is provided, the method comprising: receiving a first message from a second UE, the first message including information relating to an identifier (ID) of a source UE and information relating to an ID of a destination UE; and sending a second message to a third UE, the second message including information relating to the ID of the source UE and information relating to the ID of the destination UE, wherein the information relating to the ID of the source UE and the information relating to the ID of the destination UE are included in a Sidelink Relay Adaptation Protocol (SRAP) header.

[0036] According to embodiments of this disclosure, the first message and the second message further include information related to the carried ID.

[0037] According to embodiments of this disclosure, the method further includes identifying the egress link and the egress radio link control (RLC) channel.

[0038] According to embodiments of this disclosure, the first UE includes a first relay UE, the second UE includes a source UE or a second relay UE, and the third UE includes a destination UE or a third relay UE.

[0039] According to embodiments of this disclosure, a method is provided performed by a second user equipment (UE), the method comprising: sending a first message to a first UE, the first message including information relating to an identifier (ID) of a source user UE and information relating to an ID of a destination UE, wherein sending a second message from the first UE to a third UE, the second message including information relating to the ID of the source UE and information relating to the ID of the destination UE, wherein the information relating to the ID of the source UE and the information relating to the ID of the destination UE are included in a Side Link Relay Adaptation Protocol (SRAP) header.

[0040] According to embodiments of this disclosure, a first user equipment (UE) is provided, and the first UE includes: a transceiver; and at least one processor connected to the transceiver and configured to: receive a first message from a second UE, the first message including information relating to an identifier (ID) of a source UE and information relating to an ID of a destination UE; and send a second message to a third UE, the second message including information relating to an ID of the source UE and information relating to an ID of the destination UE, wherein the information relating to an ID of the source UE and information relating to an ID of the destination UE are included in a Sidelink Relay Adaptation Protocol (SRAP) header.

[0041] According to embodiments of this disclosure, a second user equipment (UE) is provided, and the second UE includes: a transceiver; and at least one processor connected to the transceiver and configured to: send a first message to a first UE, the first message including information relating to an identifier (ID) of a source UE and information relating to an ID of a destination UE, wherein the first UE sends a second message to a third UE, the second message including information relating to the ID of the source UE and information relating to the ID of the destination UE, wherein the information relating to the ID of the source UE and the information relating to the ID of the destination UE are included in a Sidelink Relay Adaptation Protocol (SRAP) header.

[0042] The purpose of certain examples of this disclosure is to at least partially address, resolve, and / or mitigate at least one of the problems and / or disadvantages associated with related technologies, such as at least one of the problems and / or disadvantages described herein. The purpose of certain examples of this disclosure is to provide at least one advantage over related technologies, such as at least one advantage described herein.

[0043] The scope of this invention can be determined according to the independent claims. Various examples of the invention are summarized in the dependent claims.

[0044] Other aspects, advantages, and distinctive features of this disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings.

[0045] [Beneficial Effects]

[0046] This disclosure provides an efficient and effective method for identifier allocation associated with the Sidelink Relay Adaptation Protocol (SRAP). The beneficial effects obtainable from this disclosure are not limited to those described above, and other effects not mentioned will be readily apparent to those skilled in the art to which this disclosure pertains from the following description. Attached Figure Description

[0047] Embodiments / examples of this disclosure will be further described below with reference to the accompanying drawings, in which: Figure 1a and Figure 1b The user plane protocol stack and control plane protocol stack used for Layer 2 (L2) U2U relay are schematically shown respectively.

[0048] Figure 2 This is a flowchart illustrating an example method according to this disclosure.

[0049] Figure 3 This is a flowchart illustrating an example method according to this disclosure.

[0050] Figure 4 This is a block diagram illustrating an example structure of an entity according to certain examples of this disclosure.

[0051] Figure 5 The structure of a terminal in a wireless communication system according to an embodiment of the present disclosure is shown; and

[0052] Figure 6 The structure of a base station in a wireless communication system according to an embodiment of the present disclosure is shown. Detailed Implementation

[0053] The following description, with reference to the accompanying drawings, provides examples of this disclosure to aid in a comprehensive understanding of certain examples. This description includes various specific details to aid understanding, but these details should be considered exemplary only. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the examples described herein without departing from the scope of the invention or this disclosure.

[0054] Identical or similar parts may be indicated by the same or similar reference numerals, although they may be shown in different figures.

[0055] For the sake of clarity and brevity, and to avoid obscuring the subject matter of this disclosure, detailed descriptions of techniques, structures, constructions, functions, or processes known in the art may be omitted.

[0056] The terms and words used herein are not limited to their literal or standard meanings, but are used solely to achieve a clear and consistent understanding of this disclosure.

[0057] Throughout this description, the words “comprise,” “include,” and “contain,” as well as variations thereof such as “comprising” and “comprises,” mean “including, but not limited to,” and are not intended to exclude other features, elements, components, integrals, steps, processes, operations, functions, characteristics, properties, and / or groups thereof.

[0058] Throughout this description, singular forms (such as "a," "an," and "the") include plural forms unless the context requires otherwise. For example, a reference to "an object" includes a reference to one or more such objects.

[0059] Throughout the specification, the expressions “at least one of A, B and / or C” (or similar expressions), the expression “and / or”, and the expression “one or more of A, B and / or C” (or similar expressions) shall be regarded as including all possible combinations, such as: A; B; C; A and B; A and C; A and B and C.

[0060] Throughout this description, the language expressed in the general form of “X for Y” (where Y is some action, process, operation, function, activity or step, and X is some means for performing such action, process, operation, function, activity or step) includes means X specifically, but not necessarily exclusively, adapted to, configured or arranged to perform Y.

[0061] Features, elements, components, integrals, steps, processes, operations, functions, characteristics, attributes, and / or groups thereof described or disclosed in connection with a particular aspect, embodiment, or example shall be understood to be applicable to any other aspect, embodiment, or example described herein, unless incompatible therewith.

[0062] Certain examples of this disclosure relate to methods, apparatus, and / or systems for configuring and / or signaling identifiers in a communication system. Specifically, some examples relate to allocating identifiers in a centralized or distributed manner in a UE-to-UE relay. In some examples, identifiers are allocated at each hop or level in the relay to provide a local ID for each hop. According to various examples, the local ID identifies the source (or transmitting) UE and the destination (or receiving) UE at each hop in the relay.

[0063] The following examples apply to 3GPP 4G and 5G, and use the associated terminology. However, those skilled in the art will understand that the techniques disclosed herein are not limited to these examples or 3GPP 4G or 5G, and can be applied to any suitable system or standard, such as one or more existing and / or next-generation wireless communication systems or standards. Those skilled in the art will understand that the techniques disclosed herein can be applied to any existing or future version of 3GPP 4G or 5G NR or any other relevant standard. For example, the functionality and other features of the various entities or network entities disclosed herein can be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features can be considered as entities or features performing the same or similar roles, functions, operations, or purposes within a network. In particular, the following disclosure should also be considered to be at least related to 6G, which is expected to use at least a portion of the 5G architecture or its equivalents, and this disclosure is also related to 6G.

[0064] A specific entity can be implemented as a network element on dedicated hardware, a software instance running on dedicated hardware, and / or a virtualization function instantiated on a suitable platform (e.g., on cloud infrastructure).

[0065] Those skilled in the art will understand that this disclosure is not limited to the specific examples disclosed herein. For example: ●The technologies disclosed in this article are not limited to 3GPP 4G, 5G, B5G or 6G.

[0066] ● One or more entities in the examples disclosed herein can be replaced by one or more alternative entities that perform equivalent or corresponding functions, procedures, or operations.

[0067] ● One or more messages in the examples disclosed herein can be replaced by one or more alternative messages, signals or other types of information carriers that convey equivalent or corresponding information.

[0068] ● One or more other elements, entities, and / or messages may be added to the examples published in this article.

[0069] ● In some examples, one or more unnecessary elements, entities, and / or messages may be omitted.

[0070] ● The functionality, process, or operation of a specific entity in one example can be divided among two or more separate entities in an alternative example.

[0071] ● The functions, processes, or operations of two or more separate entities in one example can be performed by a single entity in an alternative example.

[0072] ●Information carried by a specific message in one example can be carried by two or more separate messages in alternative examples.

[0073] ●Information carried by two or more separate messages in one example can be carried by a single message in an alternative example.

[0074] ● The order in which operations are performed can be modified in alternative embodiments (if possible).

[0075] ● Information transfer between entities is not limited to the specific form, type, and / or order of messages described in relation to the examples disclosed herein.

[0076] Some examples of this disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or a method for performing such network functions. Such an apparatus / device / network entity may include one or more elements, such as receivers, transmitters, transceivers, processors, controllers, modules, units, etc., each element configured to perform one or more corresponding process, operation, and / or method steps for implementing the techniques described herein. For example, operation / function of X may be performed by a module (or X module) configured to perform X. Some examples of this disclosure may be provided in the form of a system (e.g., a network) including one or more such apparatus / device / network entities and / or a method for such a system.

[0077] It will be understood that the examples of this disclosure may be implemented in hardware, software, or a combination of hardware and software. Certain examples of this disclosure may provide a computer program comprising instructions or code that, when executed, implements a method, system, and / or apparatus according to any aspect, example, and / or embodiment disclosed herein. Certain embodiments of this disclosure provide a machine-readable storage medium for storing such a program.

[0078] The following text references content from the following documents, and / or their content provides background information. The following disclosures should be considered in conjunction with this background information: [1] Research on 3GPP TR 38.836-NR side link relay (e.g. v17.0.0).

[0079] [2] 3GPP TS 38.351-NR; Sidelink Relay Adaptation Protocol (SRAP) specification (e.g., v17.5.0).

[0080] [3] 3GPP TS 38.331-NR; Radio Resource Control (RRC); Protocol Specification (e.g., v17.5.0).

[0081] Note: The version numbers indicated are provided for illustrative purposes only, and other versions of these documents (including future versions) are also taken into consideration.

[0082] Wireless or mobile (cellular) communication networks, which allow mobile terminals (e.g., user equipment, such as mobile handsets) to communicate with base stations or other wireless access points or nodes via wireless links, have undergone rapid development through multiple generations. The Third Generation Partnership Project (3GPP) designs, specifies, and standardizes the technologies for mobile wireless communication networks. Fourth (4th) generation (4G) and fifth generation (5G) systems (5GS) are now widely deployed, while beyond 5G (B5G) and 6G systems are under consideration.

[0083] The 3GPP standards for 4G systems include the Evolved Packet Core (EPC) and Enhanced UTRAN (E-UTRAN: Enhanced Universal Terrestrial Radio Access Network). E-UTRAN uses LTE radio technology. LTE is generally used to refer to the entire system including both EPC and E-UTRAN, and will be used in this sense for the remainder of this document. LTE should also be considered to include LTE enhancements (such as LTE Advanced and LTE Pro), which offer higher data rates compared to LTE.

[0084] In 5G systems, a new air interface has been developed, which can be called 5G New Radio (5G NR) or simply NR. NR is designed to support a variety of services and use cases envisioned for 5G networks, although it is based on established LTE technology. B5G systems (such as 6G) are currently being considered and developed, and are expected to be built at least partially on top of 5G systems.

[0085] As part of 5G networks (and beyond 5G, such as 6G networks), new frameworks and architectures are being developed to expand the range of features and use cases available through 5G networks.

[0086] As part of this, sidelink UE-to-UE communication is provided to facilitate direct communication between UEs without relying on connections via base stations and the core network.

[0087] The Rel-17 3GPP RAN research project “Research on NR-side link relay” was completed in 2021 and its results are documented in 3GPPTR 38.836 v17.0.0 [1], which considered UE-to-network relay and UE-to-UE (U2U) relay coverage extension. However, subsequent Rel-17 standardization work in RAN focused only on UE-to-network relay.

[0088] U2U relay enables coverage extension for sidelink (SL) transmissions between two sidelink UEs without relying on the use of uplink (UL) or downlink (DL). This is particularly important in partial coverage scenarios, where at least one of the UEs involved in the relay (e.g., at least one of the source UE, relay UE, and / or destination UE) is within coverage, and at least one of the UEs involved in the relay (e.g., at least one of the source (SRC) UE, relay UE, and / or destination (DST) UE) is outside coverage. When the relay UE is within coverage, it can access the network via a Uu link (i.e., between the UE and the 5G RAN). Once a PC5 link is established between the source UE, the UE-to-UE relay, and the destination UE, data relay between the source UE and the destination UE can occur.

[0089] In some cases, multiple DST remote UEs can connect to a trunk UE targeting a single SRC remote UE. In other or additional cases, a trunk UE can connect to multiple SRC remote UEs targeting a single DST remote UE. In some cases, multiple hops (or links, steps, nodes, etc.) may also exist between the SRC remote UE and the DST remote UE.

[0090] Figure 1a and Figure 1b The user plane protocol stack 100 and control plane protocol stack 150 for Layer 2 (L2) U2U relay, as described in 3GPP TR 38.836 v17.0.0 [1], are shown respectively. 3GPP agrees to introduce an adaptation layer on the PC5 link, as shown in the shaded box in the figure above. This adaptation layer also exists on the Uu link between the relay UE and the gNB (not shown in the figure above).

[0091] The primary agreed-upon functions of the Adapt over the Uu link include mapping UL PC5 bearers to UL Uu bearers and performing the reverse process on the DL. The primary agreed-upon functions of the Adapt over the PC5 link include mapping bearers to PC5 RLC channels.

[0092] The Adapt layer has been (re)named Sidelink Relay Adaptation Protocol, or simply SRAP (see TS 38.351[2]), so these terms can be considered synonyms. The following is the basic model and operation of SRAP for Rel-17 U2N SL relays agreed upon by 3GPP: - On a U2N trunk UE, the SRAP sublayer includes one SRAP entity at the Uu interface and a separate co-located SRAP entity at the PC5 interface. On a U2N remote UE, the SRAP sublayer includes only one SRAP entity at the PC5 interface.

[0093] Each SRAP entity has a transmitting section and a receiving section. On the PC5 interface, the transmitting section of the SRAP entity at the U2N remote UE has a corresponding receiving section of the SRAP entity at the U2N relay UE, and vice versa. On the Uu interface, the transmitting section of the SRAP entity at the U2N relay UE has a corresponding receiving section of the SRAP entity at the gNB, and vice versa.

[0094] At the remote UE, in the UL direction (or on the UL), SRAP will determine the SRAP UE ID and BEARER ID and add the SRAP header. At the remote UE, in the DL direction (or on the DL), SRAP will remove the SRAP header and pass the packet to the higher layer.

[0095] At the relay UE, on the UL, SRAP will use the SRAP UE ID and BEARER ID contained in the packet itself, along with the mapping configuration provided by the network, to map the packet from the PC5 channel to the Uu channel. At the relay UE, on the DL, SRAP will use the SRAP UE ID and BEARER ID contained in the packet itself, along with the mapping configuration provided by the network, to map the packet from the Uu channel to the PC5 channel.

[0096] At RAN2#122 in May 2023, as part of the Rel-18 standardization work for U2U SL trunks, the following agreement was reached:

[0097] ("FFS": Further research is needed)

[0098] For L2 UE-to-UE relay, the functionality of the SRAP layer is still under discussion. In particular, how to resolve the issue of allocating / configuring the local SRAP UE ID for remote UEs is unclear.

[0099] As mentioned above, the functionality of the SRAP layer for L2 UE-to-UE (U2U) relay is still under discussion. However, it is expected that the SRAP layer will have bearer mapping functionality (i.e., mapping the end-to-end (E2E) side link bearer between the SRC (transmit, TX / Tx) UE and the DST (receive, RX / Rx) UE to the PC5 channel between the SRC (Tx) UE and the relay UE, and between the relay UE and the DST (Rx) UE).

[0100] E2E sidelink bearers may include either data radio bearers or signaling radio bearers between SRC (Tx) UEs and DST (Rx) UEs. Identification information of the remote UE end-to-end sidelink radio bearers is included in the SRAP layer, while the identification information of the SRC remote UE, and / or the identification information of the DST remote UE, and / or the identification information of the SRC remote UE and DST remote UE pair are candidate information to be included in the SRAP header.

[0101] As mentioned above, there is a problem regarding how to allocate and / or configure the local SRAP UE ID for remote UEs. This disclosure provides various examples, embodiments, aspects, etc., designed to address this problem at least to some extent. Of course, the examples described herein may also yield other advantages.

[0102] In this document, a relay can be considered as one or more UEs (or relay UEs) between a source (SRC) end UE (also known as a source remote UE) and a destination (DST) end UE (also known as a destination remote UE). Furthermore, in some cases, the reference to a relay is considered to include the relay UE as well as one or more of the SRC remote UE and the DST remote UE. In other words, a relay can be considered to include endpoints, namely the SRC end UE and the DST end UE, and UEs in between. Typically, the SRC remote UE and the DST end UE can be considered end UEs. Both the SRC end UE and the DST end UE are examples of end UEs.

[0103] Additionally, a relay UE can also be referred to as an SRC UE when it is sending or is sending packets or data to another relay UE or DST UE. Similarly, a relay UE can also be referred to as a DST UE when it is receiving or is receiving packets or data from another relay UE or SRC UE. It will be understood that a relay UE can therefore also be considered an SRC UE and / or a DST relay, depending on the hop in the relay being considered. For example: when considering a hop in which the relay UE will receive packets (e.g., an Rx UE), the relay UE can be considered a DST UE; when considering another hop in which the same relay UE will send packets (e.g., a Tx UE), the relay UE can be considered an SRC UE; and when considering another hop associated with other UEs (i.e., where the same relay UE neither sends nor receives), the relay UE is neither an SRC UE nor a DST relay, but simply a relay UE.

[0104] In some examples, a path can be defined as a selection or subgroup of one or more UEs in a trunk that includes multiple UEs. A path can be determined for a specific SRC-end UE and / or a specific DST-end UE, where one or more UEs are determined based on these endpoints (e.g., different SRC-end UEs or different DST-end UEs would be determined for different SRC-end UEs or different DST-end UEs). In some examples, a path can include all the multiple UEs in a trunk; that is, the path can correspond to the trunk itself. Here, a trunk may or may not be considered to include end UEs (e.g., SRC-end UEs and DST-end UEs). In this disclosure, references to one or more hops in a trunk can also be considered as references to one or more hops in a path within a trunk; for example, when a path in a trunk is determined.

[0105] In various examples, multiple valid paths may exist between the SRC-end UE and the DST-end UE. In this case, an entity (e.g., a UE in an end UE or relay UE, a base station (e.g., gNB) or core network) may determine multiple valid paths (e.g., based on meeting validity criteria) and / or identify a preferred path from multiple paths, wherein the entity also configures or assigns an ID as disclosed in the examples herein, or provides details about the path to another entity that configures or assigns an ID as disclosed in the examples herein.

[0106] According to various examples of this disclosure, the identifier (ID) of the SRC remote UE and / or the ID of the DST remote UE (wherein it may be a single ID, i.e., associated with both the SRC remote UE and the DST remote UE; or two separate IDs, i.e., one ID for each UE) may vary hop-by-hop. For example, this process may be viewed as hop-by-hop (HBH) identifier allocation. According to some examples, the ID of the SRC remote UE and / or the ID of the DST remote UE may be allocated in a distributed manner or manner. For example, a single entity may allocate an ID for the SRC remote UE and / or an ID for the DST remote UE on each hop (such that IDs are provided for all hops based on HBH), or multiple entities (e.g., different entities in a relay, such as the UEs of each hop) may allocate an ID for the SRC remote UE and / or an ID for the DST remote UE on each hop (such that IDs are provided for all hops based on HBH). As will be discussed in the examples below, an entity / multiple entities may include any one or two of the end UEs and / or one or more of the relay UEs, and may be configured to assign an ID at each hop (e.g., assign the ID of the SRC remote UE and / or the ID of the DST remote UE corresponding to each hop).

[0107] In various examples, the per-hop local ID (i.e., the local ID assigned to each hop in a relay) can identify the SRC ID of a single link (e.g., corresponding to a Tx UE, the UE that transmits packets, data, information, signals, etc. in a hop) and the DST ID of the same single link (e.g., corresponding to an Rx UE, the UE that receives data from a Tx UE in that hop). In other words, the local ID can identify the link (or the hop itself) corresponding to a single hop between a pair of SRC and DST UEs (e.g., it can correspond to a pair of end UEs and relay UEs, or a pair of relay UEs). For example, such a pair can be one of the following: (SRC remote UE, relay UE#1), (relay UE#1, relay UE#2), ..., (relay UE#n, DST remote UE); where "relay UE" is the UE between the SRC remote UE and the DST remote UE.

[0108] In other examples, the per-hop local ID can identify the pair of SRC remote UEs and DST remote UEs on each of the hops, and this ID may or may not change hop-by-hop. In other words, in various examples of implementing the per-hop local ID method, in addition to or instead of the local ID identifying the pair of SRC UEs and DST UEs on each hop (“each hop”), an ID is also configured for the end UEs (SRC remote UE, DST remote UE) of the pair, and this ID may be fixed between hops or may change between hops. Therefore, the local ID of each hop can be considered as including the local ID for the pair of SRC UEs and DST UEs on the corresponding hop and the ID for the pair of end UEs.

[0109] Two sets of examples (referring to examples where the local ID per hop can identify the SRC ID and the DST ID of a single link, and examples where the local ID per hop can identify a pair of SRC remote UEs and DST remote UEs on each hop) are applicable to multi-hop extensions (i.e., cases where there are multiple hops in the trunk), and optionally, in each case, the IDs can be allocated in a distributed manner (e.g., local IDs or IDs for a pair of end UEs). The characteristic of IDs not changing hop-by-hop (e.g., being maintained or fixed) may be more applicable to examples where there are globally allocated local IDs (e.g., unique for a U2U trunk network or subnet), i.e., more applicable to examples where allocation is done in a centralized manner, compared to the characteristic of local IDs changing hop-by-hop. That is: for the two sets of examples (as described at the beginning of this paragraph), the IDs can change hop-by-hop; and for the example where the local ID per hop can identify a pair of SRC remote UEs and DST remote UEs on each hop, the IDs may not change hop-by-hop. Regarding the latter, it will also be understood that, for an example where the local ID per hop can identify both the SRC ID of a single link and the DST ID of the same single link, in some cases, the ID may not change hop-by-hop, such as when the local ID is reused for different hops.

[0110] The (per-hop) local ID can be an ID used in the SRAP layer. This SRAP ID allocation can be performed by any of the relay UEs in the chain or the SRC / DST remote UE. In other words, any one or more UEs in the relay, including the SRC remote UE and / or the DST remote UE, can be configured to allocate (e.g., dispatch, provide, configure, process, etc.) SRAP IDs based on the local ID (e.g., assign the local ID as the SRAP ID). For example, in a centralized approach, the SRC remote UE can allocate a local ID corresponding to each hop; however, in a distributed approach, each of two or more UEs from the end UE and relay UEs can allocate a local ID for different hops.

[0111] Furthermore, the assigned SRAP ID can be sent to other relay UEs or remote UEs as needed. That is, the UE that assigned the SRAP ID, or another UE that knows the SRAP ID, can send the SRAP ID to another UE in the relay. In some examples, if a single ID is used for a pair of UEs (e.g., a pair of SRC and DST end UEs), then this could be the PC5 link ID of that link (e.g., a PC5 link between the SRC remote UE and the DST remote UE). It is clear from the examples above that a "pair" can refer to a pair of SRC remote UEs and DST remote UEs, or a pair of Tx UEs (e.g., SRC UEs) and Rx UEs (e.g., DST UEs) on each hop.

[0112] HBH identifier allocation (e.g., ID allocation methods where the local ID varies with the link (hop-by-hop) or with the subnet) can result in smaller SRAP headers (e.g., fewer bits required in the SRAP header for IDs such as the IDs of a pair as defined above, since the pair IDs are local IDs as defined herein), and / or can mean that less signaling is needed than is required to allocate, maintain, and send unique global pair IDs. That is, in various examples, the local ID requires fewer bits than the global ID, or requires less memory or storage than the global ID. However, some examples of HBH identifier allocation can lead to increased signaling for configuring the mapping table (as discussed later), and larger mapping tables stored at the relay UE.

[0113] Various examples disclosed herein provide for allocating or configuring per-hop local IDs, allocating or configuring global "local" IDs (e.g., local IDs are allocated globally or centrally), SRAP configuration, local ID allocation procedures, and / or SRAP header formatting / SRAP header processing.

[0114] When a packet or data is sent from the SRC remote UE to the DST remote UE (e.g., from the SRC remote UE to relay UE #1... to relay UE #n to the DST remote UE), each relay UE needs to know where to forward the packet.

[0115] In various examples of this disclosure, the address of the DST remote UE or the identifier of the (SRC remote UE, DST remote UE) pair may not be included in the SRAP header itself. Instead, the Rx relay UE that hops on (its receiving packets) uses the associated local ID to determine the next hop. In one example, each relay UE obtains one or more of the following: SRC remote UE information (e.g., information related to the SRC remote UE); DST remote UE information (e.g., information related to the DST remote UE); and, if a next relay UE exists, next relay UE information (e.g., information related to the next relay UE). This / this information can be obtained for each direction during the discovery process between the SRC remote UE and the DST remote UE. In some examples, the path can be determined during the discovery process (e.g., determined, identified, detected, etc.), while in other examples, the path can be determined dynamically (or "as it happens"), as covered below. In this document, the path refers to or includes each relay UE in each hop from the SRC remote UE to the DST remote UE. Therefore, in various examples, relay UEs between the SRC remote UE and the DST remote UE are determined during the discovery process, while in other examples, these relay UEs are determined dynamically (e.g., during packet transmissions from the SRC end UE to the DST end UE). Multiple paths can exist between the SRC end UE and the DST end UE. In the examples disclosed herein, during the discovery process, the path can be obtained / determined along with SRC remote UE information, DST remote UE information, and information relating to the next relay UE (if it exists, e.g., if the next hop is not to the DST remote UE) (e.g., by an entity such as the end UE or the relay UE). In other examples, the path can be determined / obtained hop-by-hop.

[0116] Based on various examples, one or more (e.g., each) relay UEs can perform a mapping (or mapping process) similar to the following:

[0117] Incoming local ID → [Optional: (SRC remote UE, DST remote UE) global information] → {Outgoing local ID, next-hop relay}

[0118] In some cases, global information (SRC remote UE, DST remote UE) may not be required at intermediate relay UEs (e.g., relay UEs between relay UEs that communicate directly with the SRC remote UE and the DST remote UE, or all relay UEs between the SRC remote UE and the DST remote UE). This is because the intermediate UE may only need to know which local ID is used for the next hop (i.e., for the next relay UE or Rx UE) and where to send (potentially modified) packets (e.g., the modification is via SRAP header rewriting). However, even in this case, the entity may need to configure these tables (e.g., one or more configuration tables showing the mapping between input and output channels including information related to the UE and / or E2E bearer), and the entity may also need to have (e.g., be provided or configured with) global mappings. Furthermore, the entity may assign an outgoing local ID for each incoming local ID. Note that "global mapping" can refer to knowledge of the entire path at an entity (e.g., between the SRC-side UE and the DST-side UE, where the path or its details may have been determined or obtained by the entity) or multiple valid paths (e.g., between the SRC-side UE and the DST-side UE, where these paths or their details may have been determined or obtained by the entity). Potentially, if an entity has a global mapping as described above, a relay node or other relay node (if the entity is a relay node) may not know the entire path or multiple valid paths, but may know the details of the next hop and optionally the details of the hop after that.

[0119] In other potential alternatives, the outgoing local ID can be assigned by the relay UE itself. However, the relay UE may require global information (SRC remote UE, DST remote UE), or alternatively, knowledge of at least two hops where the packet needs to go (i.e., knowing the packet's destination in the next-next hop within the relay; for example, if the relay UE assigning the outgoing local ID is node #1, the next-hop UE is node #2, and the next-next hop UE is node #3, then node #1 needs to know that the packet will go to node #3). The latter alternative will be discussed further in the various examples below.

[0120] The mapping described above can be implemented in several different ways. For example, in a single table or multiple tables, and / or in a single configuration message or multiple configuration messages.

[0121] In the various examples disclosed herein, we define “SRAP Configuration”, “Local ID Configuration”, and “SRAP Header” as described below.

[0122] ● The SRAP configuration includes or provides: E2E bearer ID, local ID, and PC5 RLC channels (e.g., egress / ingress channels) for a pair of SRC remote UEs and DST remote UEs. It will be understood that, optionally, other information may be included in the SRAP configuration. Furthermore, in some examples, the PC5 RLC egress and / or ingress channel information may be omitted.

[0123] ●In the local ID configuration, the following may be included or provided: local ID, SRC ID, and DST ID.

[0124] ○ In some examples, the SRC ID corresponds to the ID of the SRC remote UE ('SRC remote UE ID'), and the DST ID corresponds to the ID of the DST remote UE ('DST remote UE ID').

[0125] In other examples, the SRC ID and DST ID correspond to the ID of the SRC UE and the DST UE, respectively, for each individual hop; for example, in a single-hop relay scenario, the local ID at one hop may include the SRC ID and DST ID corresponding to the ID of the SRC remote UE and the ID of the relay UE#1, respectively, while the local ID at another hop may include the SRC ID and DST ID corresponding to the ID of the relay UE#1 and the ID of the DST remote UE, respectively.

[0126] ● The SRAP header contains the E2E bearer ID and local ID for a pair of SRC remote UEs and DST remote UEs. It will be understood that, optionally, other information may be included in the SRAP header.

[0127] Various examples of this disclosure further include UE (e.g., terminal UE and relay UE) behavior to handle SRAP header processing with per-hop local ID and / or SRAP configuration processing. In some examples, these configurations / behaviors may be defined in future technical specifications, such as in updates to 3GPP TS 38.351 [2] and / or 3GPP TS 38.331 [3].

[0128] For example, in a single-hop relay scenario with (e.g., implementation, configuration, etc.) HBH local IDs, two local IDs are assigned / configured for the pair defined by (SRC remote UEID, DST remote UEID). This assignment can be performed by the SRC remote UE, the relay UE, or the DST remote UE in the direction {SRC remote UE → DST remote UE}. In one instance: the SRAP configuration at the relay UE may be or includes the E2E bearer ID, local ID1, PC5 RLC channel ingress, local ID2, and PC5 RLC channel egress for the pair of SRC remote UEs and DST remote UEs; the SRAP configuration at the SRC remote UE may be or includes the E2E bearer ID, local ID1, and PC5 RLC channel egress for the pair of SRC remote UEs and DST remote UEs; and / or the SRAP configuration at the DST remote UE may be or includes the E2E bearer ID, local ID2, and PC5 RLC channel ingress for the pair of SRC remote UEs and DST remote UEs. Of course, other SRAP configurations can be provided / configured.

[0129] In another example, for an N-hop relay scenario, N+1 local IDs can be assigned / configured for the pair of SRC remote UE IDs and DST remote UE IDs. Assuming the path is determined / defined (as described above, this can include each relay UE in each hop from the SRC remote UE to the DST remote UE, or defined by each relay UE in each hop from the SRC remote UE to the DST remote UE), the SRAP configuration at the i-th relay UE (where i = 1, ..., N) can be the E2E bearer ID, local ID_i, PC5 RLC channel ingress, local ID_i+1, and PC5 RLC channel egress for the pair of SRC and DST remote UEs. Optionally, the SRAP configuration at the N-th relay UE may not include local ID_i+1; however, the N-th relay UE may need information about where to forward / send packets, in which case, if the N-th relay UE does not include local ID_i+1, it may need other configurations for forwarding transmissions to the DST UE. It should be noted that in some examples, the DST UE can compare its local ID (e.g., in the SRAP header of a received packet, such as "can be received from the Nth relay UE") with its own SRAP ID (or use a mapping between the local ID and the SRAP ID) and infer that it (the DST UE) is the intended destination of the packet. In this case, the packet is passed to a higher layer at the DST UE instead of being forwarded. It should also be noted that in some examples, the relay UE itself can be the destination of the packet. In this case, the DST UE may not be the intended destination of the packet, but can forward the packet to, for example, another relay UE or the intended destination relay UE.

[0130] Header rewriting can be performed at each relay UE based on the SRAP configuration of the incoming packet (which subsequently becomes the outgoing packet). For example, the packet header (e.g., the SRAP header) can be rewritten at each relay UE so that the next relay UE can decode the packet header to identify or infer the next hop of the packet.

[0131] In various examples, HBH local IDs can be assigned per SRC ID and DST ID, and if the SRC ID is the source layer 2 ID of the SRC UE (or Tx UE) and the DST ID is the source layer 2 ID of the DST UE (or Rx UE), local ID allocation can be performed according to the UE's source layer 2 ID update procedure. These examples include cases where "SRC UE" refers to the SRC remote UE and cases where "SRC UE" refers to the SRC UE for each individual link or hop (e.g., an SRC end UE and a relay UE that acts as an SRC UE by sending packets to another relay UE (which acts as a DST UE), and cases where "DST UE" refers to the DST remote UE and cases where "DST UE" refers to the DST UE for each individual link or hop (e.g., a DST end UE and a relay UE that acts as a DST UE by receiving packets or about to receive packets).

[0132] A further understanding of the above examples / situations can be obtained by considering the following examples, which illustrate variations of the above content.

[0133] In the examples, the SRAP configuration may include: an E2E bearer ID, a local ID, and an outgoing PC5 RLC channel for a pair of SRC remote UEs and DST remote UEs. An ingoing PC5 RLC channel may or may not be included. For example, if a mapping is provided where a combination of the bearer ID and local ID for a pair of SRC remote UEs and DST remote UEs (i.e., the bearer ID and local ID are used together) is mapped to an outgoing PC5 RLC channel, the ingoing PC5 RLC channel can be omitted from the SRAP configuration. In another example, a combination of the ingoing PC5 RLC channel and the local ID may be mapped to an outgoing PC5 RLC channel. Here, the local ID is only needed if the aim is to allow data from multiple (SRC and / or DST) remote UE pairs (e.g., multiple SRC and / or DST UE pairs) to be multiplexed onto a single PC5 RLC channel (as shown in the various examples of this disclosure).

[0134] In the example, the local ID configuration may include (or be implemented as) locally assigned identifiers for SRC and DST pairs (e.g., denoted as {SRC, DST} pairs using the notation described herein). This may be for each SRC remote UE and DST remote UE; and / or for each SRC UE and DST UE for each individual link (or hop).

[0135] In another example, the local ID configuration may include (or be implemented as) globally assigned identifiers for SRC and DST pairs (e.g., {SRC, DST} pairs). This could be for each SRC remote UE and DST remote UE; for each SRC UE and DST UE for each individual link (or hop); and / or for each subnet.

[0136] In the example, the SRAP header may include the E2E bearer ID for a pair of SRC remote UEs and DST remote UEs, as well as a local ID. In some cases, the E2E bearer ID for a pair of SRC remote UEs and DST remote UEs may be included solely for the purpose of sending different bearers for the same local ID via different PC5 RLC channels. As a result, this can provide better QoS management at the cost of higher overhead. In other cases, the E2E bearer ID for a pair of SRC remote UEs and DST remote UEs is omitted from the SRAP header.

[0137] Additionally, examples of this disclosure include signaling for configuring SRAP (e.g., signaling for configuring per-hop local IDs, signaling for SRAP configuration, combinations of the above signaling, etc.), and / or defining entities for performing assignments (e.g., assignment of local IDs).

[0138] For example, regarding signaling used to configure SRAP, if the SRC remote UE is the entity configuring the local ID on each or all of each hop (single link), it may be necessary to exchange information between the SRC remote UE and each relay UE (e.g., each intermediate UE between the SRC remote UE and the DST remote UE) and between the SRC remote UE and the DST remote UE. This exchange may need to be performed before the local ID is assigned. In various examples, the SRC remote UE is configured to perform this exchange as needed. For this purpose, permanent or global addressing can be provided for signaling configuration (e.g., signaling for configuring SRAP). In one example, this permanent or global addressing may be performed before the SRAP layer is configured (e.g., performed by an entity such as the SRC remote UE).

[0139] Based on various examples (e.g., including the first set of examples), methods for signaling local ID allocation (e.g., per-hop local ID allocation) may include: after discovering (e.g., determining, identifying, etc.) a path from the SRC remote UE to the DST remote UE (via one or more relays), performing PC5 unicast link establishment for each hop (e.g., SRC remote UE to relay UE, relay UE to the next relay UE, next relay UE to the DST remote UE, and vice versa for the other direction). During PC5 unicast link establishment (which can be performed using PC5 RRC messages) or immediately after PC5 unicast link establishment (e.g., within a predetermined time period after PC5 unicast link establishment, or in response to completion of PC5 unicast link establishment; and / or where link establishment can be performed using PC5 RRC messages), per-hop local ID allocation configuration may be performed on each link or for each link. In various examples, similar arrangements (e.g., methods) may be used for global (or centralized) local ID allocation, except that the parameters themselves are different (e.g., the local IDs themselves are different). The methods described in these examples can be applied to cases where the local ID is assigned individually for each hop by the SRC UE / DST UE, as well as cases where it is assigned by the SRC / DST remote UE (e.g., refer to the examples given above for these different cases of local ID configuration). It will be understood that there may be differences in parameter details depending on the entity assigning the local ID (e.g., the SRC remote UE or the DST remote UE).

[0140] According to various examples (e.g., including the second set of examples), methods for signaling SRAP configuration may include: specifying the SRAP configuration according to a predetermined configuration (e.g., a new SRAP configuration provided in a technical specification prepared by 3GPP) for signaling bearers; and, for data bearers, the SRAP configuration may be dedicated via signaling between a base station (e.g., gNB) and a UE or between UEs (e.g., an entity such as a gNB or a UE may signal a dedicated SRAP configuration to another entity such as another UE). In other examples, both the signaling bearer and data bearer SRAP configurations may be dedicated via signaling between a base station (e.g., gNB) and a UE or between individual UEs.

[0141] Therefore, in addition to these examples, SRAP configuration signaling may be necessary for bearers configured in a dedicated manner. Following the conventional Rel-16 principle, each PC5 link's Tx UE (e.g., an SRC UE) determines its configuration based on its RRC state (e.g., RRC signaling from the gNB, the gNB's SIB, and / or the UE's pre-configuration) and sends this configuration to the PC5 link's Rx UE (e.g., a DST UE) via a PC5 RRC message. Even though less gNB involvement is considered for U2U trunking (compared to the U2N trunking case), the various examples of this disclosure maintain (e.g., reuse) gNB-based SIBs or UE pre-configurations as a method for providing SRAP configuration for U2U trunking to each PC5 link's Tx UE.

[0142] Based on the various examples disclosed herein, regarding single-hop relays, a relay UE can be configured to assume the role of allocating SRAP configurations for each link (e.g., the link between the SRC remote UE and the relay UE, the link between the DST remote UE and the relay UE). (For example, the relay UE may be configured as an entity that allocates SRAP configurations to one or more other UEs, which may include the relay UE itself.) How the relay UE obtains or determines the SRAP configuration can follow the Tx UE-based approach described above. For instance, the relay UE assuming the role of performing SRAP configuration allocation can determine / specify the SRAP configuration based on its RRC state (e.g., based on or dependent on RRC signaling from the gNB, the gNB's SIB, and / or the UE's pre-configuration) and send that configuration to the next relay UE on the PC5 link via a PC5 RRC message.

[0143] It will be understood that in cases with more than one hop (i.e., if this configuration or similar configuration is extended to two-hop or multi-hop trunks / systems), this arrangement of specifying (i.e., one) SRAP configuration for a trunk UE may be inefficient. Therefore, for two-hop or multi-hop trunks, various examples are considered and each trunk UE on each link can assume a role assigned to the SRAP configuration for one direction; for example, in the direction from the SRC remote UE to the DST remote UE, trunk UE1: SRC remote UE to trunk UE 1, trunk UE2: trunk UE1 to trunk UE2, etc. It will be understood that this configuration becomes similar to a TX UE-based approach. In other words: the first relay UE performs SRAP configuration allocation for hops from the SRC remote UE to the first relay UE; the second relay UE performs SRAP configuration allocation for hops from the first relay UE to the second relay UE; the third relay UE performs SRAP configuration allocation for hops from the second relay UE to the third relay UE; and so on, until the last relay UE (e.g., in a relay) performs RAP configuration allocation for hops from itself to the DST remote UE. In some examples, each relay UE that assumes the role of performing SRAP configuration allocation can determine / determine the SRAP configuration based on its RRC status (e.g., RRC signaling from the gNB, the gNB's SIB, and / or the UE's pre-configuration) and send that configuration to the next relay UE on the PC5 link via a PC5 RRC message.

[0144] According to various examples, the method of signaling local ID allocation configuration (e.g., for per-hop local ID) and SRAP configuration may include or provide features / details, namely, that, according to the various example methods given above for each signaling (e.g., referring to the first set of examples and the second set of examples above), per-link (or per-hop) signaling sent by each individual hop Tx UE or relay UE is suitable to carry local ID and SRAP configuration together.

[0145] In other words, in various examples, each hop's local ID and SRAP configuration are signaled via the same signaling. For example, a PC5 RRC message can be used. Alternatively, a separate procedure can be used for each configuration (i.e., the local ID configuration and the SRAP configuration).

[0146] In various examples, if the SRC L2ID (Layer 2 ID) is updated for some privacy / security reason, the mapping between the local ID and the SRC L2ID can be updated. SRC L2ID updates can be applied to E2E (e.g., SRC remote UE to DST remote UE) and / or HBH (e.g., remote UE to relay UE, relay UE to relay UE). In various examples, if a global local ID is used or implemented based on E2E (e.g., SRC remote UE ID), the mapping between the global local ID and the SRC remote UE ID can be maintained at all UEs (remote UE and relay UE). In various examples, if a per-hop local ID is used or implemented based on E2E (e.g., SRC remote UE ID), the mapping between the per-hop local ID and the SRC remote UE ID can be maintained at all UEs (remote UE and relay UE). In various examples, if per-hop local IDs are used or implemented based on HBH (e.g., SRC UE IDs for each individual hop), the mapping between the per-hop local ID and the SRC UE ID can be maintained at the corresponding two UEs for each individual hop. It will be understood that the HBH case may require more SRC UE ID updates (e.g., performing more updates), and therefore may increase the local ID (re)mapping overhead in the multi-hop case.

[0147] As mentioned above, per-hop allocation is possible, which means that the Tx UE on each hop is assigned a local ID, rather than the case where the SRC (or DST) remote UE assigns a local ID for all hops.

[0148] In other words, the allocator (e.g., for the local ID) could be a Tx UE per hop (which can be considered as an SRC UE for each (or any) individual hop, where this does not only mean the SRC remote UE), a relay UE toward the DST remote UE, a relay UE toward the SRC remote UE, or an Rx UE for each (or any) hop (which can be considered as a DST UE for each individual hop, where this does not only mean the DST remote UE). For the various examples in these examples, PC5 RRC messages with local ID allocation configuration can be exchanged on the corresponding links.

[0149] In other examples, the allocator can be (a) the SRC remote UE or (b) the DST remote UE. In this case: for (a), for a single-hop scenario, the SRC remote UE can send the local ID for each hop to both the relay UE and the DST remote UE, or for (2), for a single-hop scenario, the DST remote UE can send the local ID for each hop to both the relay UE and the SRC remote UE. For a single-hop scenario, the signaling overhead is likely acceptable, as it is not expected to differ significantly from the case where a global ID is allocated by either the SRC remote UE or the DST remote UE. However, for scenarios with more than one hop, the signaling overhead can become significantly larger when the local ID parameter for each hop needs to be transmitted over multiple hops (e.g., in the case of per-hop local ID allocation).

[0150] For such examples, the issue to consider is the link (if any) between local per-hop IDs on adjacent hops. The Rx UE of one hop becomes the Tx UE for the next hop. On the next hop, the identifiers of the SRC remote UE and the DST remote UE (e.g., {SRC remote UE id, DST remote UE id}) can be different. This may not cause any problems / difficulties if each node has a mapping between the incoming ID, the identifiers of the SRC remote UE and DST remote UE (e.g., {SRC remote UE, DST remote UE}id), and the outgoing ID. In this case, the signaling savings (e.g., reduced resource usage such as network or computational resources) will be smaller than in other examples disclosed herein; this is primarily reflected by the smaller SRAP header (e.g., due to the smaller SRAP header), as the per-hop local ID may be considerably smaller compared to the overall {end-remote SRC, end-remote DST}id.

[0151] Further savings in signaling (e.g., reduced signaling resource usage) may arise from scenarios further described below, where it may not be necessary to know or be aware of (e.g., for one or more given entities, such as each or any relay UE) the identifiers of the SRC remote UE and DST remote UE (e.g., {SRC remote UE, DST remote UE} id), but only need to know (e.g., configured or already stored, etc.) the mapping of incoming IDs (e.g., local IDs) to the next-hop UE (and, optionally, the next-next-hop) so that appropriate output IDs (e.g., local IDs) can be assigned (e.g., by the relay UE). This can save on configuration signaling because the identifiers of the SRC remote UE and DST remote UE (e.g., {SRC remote UE, DST remote UE} id) may not need to be known for each intermediate relay UE.

[0152] Therefore, if the local ID and / or other information indicates that the next-hop information is directed toward the DST remote UE and / or from the SRC remote UE, the intermediate relay UE does not need to maintain "end remote SRC UE L2 ID, end remote DST UE L2 ID" (or a similar ID).

[0153] Therefore, the Tx relay UE (or SRC remote UE), as well as the very beginning of the chain (e.g., the first relay UE in the relay or path (i.e., the chain)) can store a table showing the next hop for a specific local ID (e.g., which can be a single ID of an SRC / DST pair such as the next hop SRC / DST pair).

[0154] To this end, according to various examples of this disclosure, each Tx UE (e.g., each relay UE) can store a mapping between the local ID on the incoming hop and the next-next hop. In other words, each Tx UE can pre-identify (or consider) two hops, not just one (assuming local configuration rather than centralized configuration). Thus, in one example, the SRC remote UE can be configured with a table showing the identifier of relay UE#2 for a given DST remote UE (e.g., for a given path to the DST remote UE). The SRC remote UE selects (e.g., selects, determines, identifies, etc.) the local ID for SRC remote UE → relay UE#1, where the selected local ID will allow relay UE#1 to infer (e.g., according to its own configuration table) that the next hop is to relay UE#2. Relay UE#1 can know (e.g., according to its configuration table or according to other stored information) that relay UE#3 is the next hop (after relay UE#2) in order to configure the local ID on relay UE#1 → relay UE#2. In other words, relay UE#1 can be configured with a local ID, enabling relay UE#2 to infer that relay UE#3 is the next hop.

[0155] In HBH scenarios using hop-by-hop local IDs, in some examples, each UE (remote UE or relay UE) can assume the role of assigning a local ID to the next hop. Each such UE can store a mapping table for routing (e.g., a configuration table as described above). This HBH scenario relies on the following mapping: {Pass in local ID, next hop} → {Pass out local ID, next hop relay} Based on various examples, one implementation is as follows: ●The SRC remote UE has a mapping between each DST (including the DST remote UE) and the local ID used for the first hop (e.g., in a stored mapping table or configuration table).

[0156] ● Each relay UE has a mapping between the local ID for the incoming hop and the local ID for the upcoming hop (e.g., in a stored mapping table or configuration table), and can rewrite the SRAP header accordingly.

[0157] ○ This can be understood as a large table, and can be simplified as follows: ■ All packets with the same next hop use the same local ID; and ■ The incoming RLC channel implicitly indicates the next hop.

[0158] ●The above method may require some centralized configuration of the mapping table.

[0159] ● In some cases, configuration can be performed on a smaller portion of the network, and gateway nodes that are essentially destination addresses for the smaller network can be provided or included.

[0160] ● In various examples, a "sliding window" can be implemented to allow entities (e.g., SRC remote UE, relay UE, etc.) to know / identify the two hops in advance. The "sliding window" references a method where each relay UE can identify (e.g., know or be aware of) the next hop and the hop after that, where knowing the hop after that allows the Tx relay UE on the first hop (i.e., the "next hop") to use (e.g., configure, process, identify, etc.) a local ID, which then enables the Rx relay UE on the first hop to know which relay UE should be the Rx relay UE on the next hop (e.g., the second hop). As will be understood, the Rx relay UE on the first hop becomes the Tx relay UE on the second hop, for example, as the "window" slides or moves.

[0161] After allocating a local ID, the allocator can notify the peer UE (e.g., the UE associated with the local ID, or the next-hop UE) of the local ID information (e.g., the local ID itself, and optionally, its associated PC5 RLC channel and / or E2E bearer ID, if needed). In some examples, different local IDs can be used on two adjacent hops to identify the same (SRC, DST) pair. Thus, an Rx relay UE (e.g., a DST relay UE) may need to be able to resolve the local ID used by a Tx relay UE (e.g., an SRC relay UE), and may then allocate a new local ID (e.g., for the next hop that would be referred to as the Tx UE relay for the Rx relay UE), and may rewrite the SRAP header (if needed) so that the next relay UE (e.g., in the UE chain) can understand which (SRC, DST) pair the local ID refers to (because the next relay UE may have a different mapping between (SRC, DST) and local ID).

[0162] According to various examples of this disclosure, a Tx UE can be inferred based on a PC5 RLC channel. For example, as described above, partial information can be inferred based on an ingress PC5 RLC channel. For example, an ingress PC5 RLC channel can allow the inference of the SRC UE (e.g., Tx UE) identifier, or the subnet from which a packet originates or is destined. In another example, a specific (e.g., default, dedicated, designated, etc.) ingress channel can be reserved for data from only one SRC (e.g., only one SRC UE), in which case it will be understood how information related to the SRC (such as the identifier of the SRC itself) can be inferred or determined based on the ingress channel. A specific ingress channel can also be associated with a specific E2E bearer, in which case it will be understood how information related to the specific E2E bearer (such as the identifier of the E2E bearer itself) can be determined or inferred based on the ingress channel. A specific ingress channel can also be mapped to only one egress channel, in which case it will be understood how the egress channel can be determined or inferred based on the ingress channel. In various examples, multiple PC5 RLC channels are provided to allow a one-to-one mapping between (per-hop) PC5 RLC channels and each (SRC, DST) pair.

[0163] According to various examples in this disclosure, if the DST address (e.g., the address of the DST remote UE or the address of the DST relay UE) is included in the SRAP header, it may be necessary to include more bits in the header (e.g., increase the header size), but the header may not need to be rewritten (e.g., per hop). According to the examples described herein, using a local ID allows for a smaller number of bits, and since not all (SRC, DST) pairs will be transmitted via all links or subnets, the number of applicable pairs is lower than at the level of the entire U2U network. However, when implementing local IDs, header rewriting may be necessary. In various examples, header rewriting may not be required at every hop; some local IDs may be shared within a subnet (e.g., for packets belonging to different (SRC, DST) pairs but which at least partially traverse the same route and therefore can share the same local ID).

[0164] Figure 2 Methods according to various examples of this disclosure are shown.

[0165] This method can be performed by an entity (e.g., a first entity) included in a communication network, which includes multiple entities, which in turn may include the first entity. The multiple entities may also include an SRC end entity, at least one intermediate entity, and a DST end entity.

[0166] It will be understood that, in various examples, the SRC end entity is the SRC end UE, the DST end entity is the DST end UE, and at least one intermediate entity is a distinct relay UE (or intermediate UE). Furthermore, the first entity can be any of the following: the SRC end entity, the DST end entity, or one of at least one intermediate entity, or it can be another entity (such as a base station (e.g., gNB) or part of a network (e.g., the core network to which the SRC end UE, the DST end entity as a DST end UE, and at least one intermediate entity are connected)).

[0167] In operation 201, the first entity may obtain information relating to multiple entities. In the case of obtaining information by receiving information, it will be understood that the information is not received from the first entity among the multiple entities. The information may be received from each of the multiple entities (excluding the first entity), or from one entity or a subset of entities (such as an entity communicating directly with the first entity), or from an entity outside the multiple entities (such as a base station or network).

[0168] As described in the various examples herein, obtaining this information may correspond to a discovery process (e.g., as part of or associated with a discovery process). For example, this information may be obtained for both directions from the SRC end entity to the DST end entity and from the DST end entity to the SRC end entity, where the information may include details or information relating to each entity between the respective end entities. The information may also include indications of paths (e.g., obtained by the first entity by determining the path from the SRC end entity to the DST end entity or from the DST end entity to the SRC end entity based on another portion of the information obtained in operation 201). Similarly, such path details may correspond to those given in other examples disclosed herein.

[0169] In operation 203, the first entity configures (or dispatches, assigns, processes, generates, identifies, determines, etc.) one or more identifiers, wherein each identifier (or, if only one identifier is configured, that identifier) ​​indicates a pair of entities among a plurality of entities.

[0170] It will be understood that, in various examples, the operation may be based on any of the examples disclosed herein relating to the ID or local ID of a pair of entities (e.g., UEs, such as SRC UE and end UE, or Tx UE and Rx UE) or sharing one or more features with them.

[0171] For example, each pair of entities includes an SRC entity and a DST entity for hops in the communication network. That is, if the path includes multiple hops from the SRC end entity to the DST end entity, then the pair of entities corresponding to each hop will include an SRC entity (e.g., a Tx entity for sending packets) and a DST entity (e.g., an Rx entity for receiving packets). In a single-hop scenario, there may be an intermediate entity, and the path may include two hops—a first hop corresponding to the SRC end entity (as the SRC entity) and an intermediate entity (as the DST entity), and a second hop corresponding to the intermediate entity (as the SRC entity) and the DST end entity (as the DST entity). In an N-hop scenario (where N is two or more), there can be N intermediate entities, and the path can include N hops – the first hop corresponding to the SRC end entity (as an SRC entity) and the first intermediate entity (as a DST entity), the second hop corresponding to the first intermediate entity (as an SRC entity) and the second intermediate entity (as a DST entity), and so on, up to the (N-1)th hop (as a DST entity) corresponding to the (N-1)th intermediate entity (as an SRC entity) and the Nth intermediate entity, and the Nth hop corresponding to the Nth intermediate entity (as an SRC entity) and the DST end entity (as a DST entity). In some cases, no entity pair (i.e., no single entity pair) can include both the SRC end entity and the DST end entity, and the path will include at least one intermediate entity between the SRC end entity and the DST end entity. However, in other cases, the path can proceed from the SRC end entity to the DST end entity and then from the DST end entity to an intermediate entity, in which case a single entity pair can include both the SRC end entity and the DST end entity.

[0172] In various examples, at least one intermediate entity may be positioned between the SRC end entity and the DST end entity, meaning that each entity is communicatively connected to at least one other entity (e.g., a direct connection, i.e., able to send to or receive directly from at least one other entity). In some cases, the SRC end entity and the DST end entity are not communicatively connected (e.g., cannot communicate directly with each other at the current time or current location), so communication between the SRC end entity and the DST end entity is via at least one intermediate entity (or a subset of the paths between the end entities). Similarly, each intermediate entity may not be communicatively connected to every other intermediate entity, but may be communicatively connected only to a subset of at least one intermediate entity, meaning that communication between two non-communicably connected intermediate entities is via one or more other intermediate entities.

[0173] In various examples, configuration may involve configuring SRAP configuration, local ID, or SRAP header. In some examples, configuration may include configuring a local ID on a per-hop basis for each hop from the SRC end entity to the DST end entity / from the DST end entity to the SRC end entity. In further examples, the configured local ID may be included in the header of the packet sent to the next entity (e.g., corresponding to the next hop). Refer again to the discussion / examples of SRAP configuration, local ID configuration, and SRAP header configuration, and their signaling, given in this document.

[0174] In operation 205, the first entity may send or provide at least one of one or more configured identifiers to at least one of a plurality of entities. It will be understood that this excludes the first entity, since the first entity already knows one or more identifiers.

[0175] In various examples, this operation may be based on any of the examples disclosed herein related to signaling (such as SRAP configuration, SRAP headers, and / or local IDs, etc.) (e.g., sharing one or more characteristics). For example, after discovering a path from the SRC end entity to the DST end entity, a PC5 unicast link establishment is performed for each hop (e.g., SRC end entity to intermediate entity, intermediate entity to next intermediate entity, next intermediate entity to DST end entity; and vice versa for the other direction). In such examples, during PC5 unicast link establishment (which can be performed using PC5 RRC messages) or exactly after PC5 unicast link establishment (e.g., within a predetermined time period after PC5 unicast link establishment; or in response to completion of PC5 unicast link establishment; and / or where link establishment can be performed using PC5 RRC messages), a per-hop local ID allocation configuration may be performed on each link or for each link, wherein one or more identifiers (e.g., local IDs) are signaled to other entities (or subsets of entities) among a plurality of entities.

[0176] It will be understood that the examples of this disclosure also include methods in which one or more of operations 201, 203, and 205 are omitted. That is, example methods may include: operation 201; operation 203; operation 205; operation 201 and operation 203; operation 203 and operation 205; operation 201 and operation 205; and operation 201, operation 203, and operation 205.

[0177] Figure 3 Methods according to various examples of this disclosure are shown.

[0178] This method can be performed by an entity (e.g., a second entity) included in a communication network, which includes multiple entities, which in turn may include the second entity. The multiple entities may also include an SRC end entity, at least one intermediate entity, and a DST end entity.

[0179] It will be understood that, in various examples, the SRC end entity is the SRC end UE, the DST end entity is the DST end UE, and at least one intermediate entity is a distinct relay UE (or intermediate UE). Furthermore, the second entity can be any of the following: the SRC end entity, the DST end entity, or at least one intermediate entity.

[0180] Furthermore, the path from the SRC end entity to the DST end entity in the communication network can include multiple hops from the SRC end entity to the DST end entity, where a pair of entities corresponding to each hop will include the SRC entity (e.g., a Tx entity that transmits packets) and the DST entity (e.g., an Rx entity that receives packets). In a single-hop scenario, there may be an intermediate entity, and the path may include two hops - a first hop corresponding to the SRC end entity (as the SRC entity) and an intermediate entity (as the DST entity), and a second hop corresponding to the intermediate entity (as the SRC entity) and the DST end entity (as the DST entity). In an N-hop scenario (where N is two or more), there can be N intermediate entities, and the path can include N hops – a first hop corresponding to the SRC end entity (as an SRC entity) and the first intermediate entity (as a DST entity), a second hop corresponding to the first intermediate entity (as an SRC entity) and the second intermediate entity (as a DST entity), and so on, up to the (N-1)th hop corresponding to the (N-1)th intermediate entity (as an SRC entity) and the Nth intermediate entity (as a DST entity), and the Nth hop corresponding to the Nth intermediate entity (as an SRC entity) and the DST end entity (as a DST entity). In some cases, no entity pair (i.e., no single entity pair) can include both the SRC end entity and the DST end entity, and the path will include at least one intermediate entity between the SRC end entity and the DST end entity. However, in other cases, the path can proceed from the SRC end entity to the DST end entity and then from the DST end entity to an intermediate entity, in which case a single entity pair can include both the SRC end entity and the DST end entity.

[0181] In operation 301, the second entity may receive information including a first identifier from the first entity, which is included among a plurality of entities, indicating a first pair including the first entity and the second entity.

[0182] In various examples, the operation may be based on any of the examples disclosed herein related to signaling, or related to the SRAP header, SRAP configuration, and / or local ID (e.g., sharing one or more characteristics). For example, the information may be included in the SRAP header, where the first identifier may be a local ID corresponding to both a first entity and a second entity. The first identifier may be configured by either the first entity or the other entity. The information may further include information that allows the second entity to identify or determine the next entity to which it should be sent.

[0183] In operation 303, the second entity may receive packets from the first entity. In some examples, the reception of information occurs concurrently with the reception of packets, as information may be included in the packets or as part of a transmission that includes the packets. For example, the information may be included in the SRAP header of the packets. Packets may include data or information sent from an entity at the beginning of the path (e.g., an SRC end entity) to an entity at the end of the path (e.g., a DST end entity).

[0184] In operation 305, the second entity may send packets to the third entity based on a first identifier and / or information (i.e., other information included in the information). For example, based on this information, the second entity may identify that the third entity corresponds to the next hop, for which the SRC entity will be the second entity and the third entity will be the DST entity. In another example, this information may instruct an entity (e.g., a fourth entity) to receive packets in the next-next hop. Thus, the second entity can infer that the third entity is the DST entity of the next hop, such that the third entity can subsequently forward packets to the fourth entity in the next-next hop.

[0185] It will be understood that, in various examples, Operation 305 is any of the examples disclosed herein relating to an entity (e.g., a relay UE) forwarding packets and / or local ID information to the next entity in the path (e.g., another relay UE acting as a DST or Rx relay) (e.g., sharing one or more features with it). For example, an entity may be provided with knowledge of the purpose of a packet in the next-next hop, allowing inference of the next hop's purpose. For example, a second entity may rewrite the SRAP header of a received packet before sending it to a third entity with a rewritten SRAP header, wherein the rewritten SRAP header will provide the third entity with information relating to the purpose of the packet forwarding (or, if the third entity is the intended destination of the packet (e.g., a DST-end entity), the rewritten SRAP header can inform the third entity that it is the destination, thereby passing the packet to a higher layer). These features may be supported by using configuration tables or mapping tables (e.g., stored in the second entity and / or the third (or other) entities).

[0186] In some examples, the information may further include an identifier corresponding to a pair of SRC end entities and DST end entities, where the identifier is also used to determine the third entity as the next destination of the packet (i.e., the DST entity as the next hop).

[0187] It will be understood that the examples in this disclosure also include methods in which one or more of operations 301, 303, and 305 are omitted. That is, example methods may include: operation 301; operation 303; operation 305; operation 301 and operation 303; operation 303 and operation 305; operation 301 and operation 305; and operation 301, operation 303, and operation 305.

[0188] Figure 4 This is a block diagram of an exemplary device or entity that may be used in the examples of this disclosure. Those skilled in the art will understand that the entity may be implemented as, for example, a network element on dedicated hardware, a software instance running on dedicated hardware, and / or a virtualization function instantiated on a suitable platform (e.g., on cloud infrastructure).

[0189] Entity 1000 includes a processor (or controller) 1001, a transmitter 1003, and a receiver 1005. Receiver 1005 is configured to receive one or more messages from one or more other entities, as described above. Transmitter 1003 is configured to send one or more messages to one or more other entities, as described above. Processor 1001 is configured to perform one or more operations, for example, according to the operations described above.

[0190] According to a first aspect of this disclosure, a first entity is provided in a communication system, wherein the communication system includes a plurality of entities, the plurality of entities including the first entity, and the first entity includes: a transmitter; and a controller configured to: configure one or more identifiers, each identifier being set to indicate a pair of entities among the plurality of entities; wherein the plurality of entities includes a source SRC end entity, at least one intermediate entity, and a destination DST end entity; wherein each pair of entities includes an SRC entity and a DST entity communicatively connected to the SRC entity, and no pair of entities includes both an SRC end entity and a DST end entity.

[0191] According to various examples, each pair of entities includes: one of the SRC end entity or the DST end entity, and at least one of the intermediate entities; or if multiple entities include at least two intermediate entities, then each pair of entities includes two different intermediate entities of at least two intermediate entities.

[0192] According to various examples, the first pair of entities includes an SRC end entity and a first intermediate entity communicatively connected to the SRC entity; and the second pair of entities includes a second intermediate entity and a DST end entity communicatively connected to the second intermediate entity.

[0193] According to various examples, if multiple entities include only one intermediate entity, then the first intermediate entity is the second intermediate entity; if multiple entities include at least two intermediate entities, then the second intermediate entity is different from the first intermediate entity, and a third pair of entities includes the first intermediate entity and the second intermediate entity communicatively connected to the first intermediate entity; and / or if multiple entities include at least three intermediate entities, then the second intermediate entity is different from the first intermediate entity, the third pair of entities includes the first intermediate entity and the third intermediate entity communicatively connected to the first intermediate entity, and a fourth pair of entities includes the third intermediate entity and the second intermediate entity communicatively connected to the third intermediate entity.

[0194] Depending on the examples, if multiple identifiers are configured, each identifier uniquely corresponds to each pair; or if only one identifier is configured, the first entity is the SRC entity in a pair of entities indicated by the configured indicator.

[0195] According to various examples, the controller is configured to send one or more identifiers to at least one of a plurality of entities other than the first entity.

[0196] According to various examples, the controller is configured to obtain information about multiple entities other than the first entity, and to configure one or more identifiers based on the received information.

[0197] According to various examples, the controller is configured to send the identifier of the SRC end entity and the identifier of the DST end entity to at least one of the plurality of entities.

[0198] According to various examples, the controller is configured to send configuration information to at least one entity, which includes one or more identifiers, the identifier of the SRC entity and the identifier of the DST end entity, and information related to the channel between the SRC entity and the DST entity.

[0199] According to various examples, the channel is a PC5 RLC channel, and the information includes information related to the outgoing PC5 RLC channel and / or information related to the incoming PC5 RLC channel.

[0200] According to embodiments of this disclosure, the shared identifier is used for the identifier of the SRC end entity and the identifier of the DST end entity.

[0201] According to various examples, the configured identifier corresponding to a pair of entities further indicates the next entity that can be communicatively connected to the DST entity in the pair of entities.

[0202] According to various examples, the first entity is one of the SRC end entities, at least one intermediate entity, or a base station; and / or each of the multiple entities is a different user equipment (UE).

[0203] Based on various examples, DST entities can communicatively connect to SRC entities, enabling direct communication between the SRC and DST entities.

[0204] According to a second aspect of this disclosure, a second entity is provided in a communication system, wherein the communication system includes a plurality of entities, the plurality of entities including the second entity, and the second entity includes: a receiver; a transmitter; and a controller configured to: receive information including a first identifier from a first entity among the plurality of entities, the first identifier indicating a first pair including the first entity and the second entity; receive packets from the first entity; and transmit packets to a third entity based on the first identifier; wherein the plurality of entities includes a source SRC end entity, at least one intermediate entity, and a destination DST end entity; and wherein, in the first pair, the third entity is a DST entity, and the second entity is an SRC entity communicatively connected to the DST entity.

[0205] Depending on the examples, this information includes a second identifier that indicates the SRC end entity and the DST end entity.

[0206] According to various examples, the controller is configured to: configure a third identifier based on the information to indicate a second pair including the second entity and the third entity; and send the third identifier to the third entity.

[0207] According to various examples, the information includes an indication of a fourth entity configured to receive transmissions from a third entity; and wherein the controller is configured to configure the third identifier based on the first identifier, the second identifier, and the indication of the fourth entity.

[0208] According to various examples, the first identifier and the second identifier are received in the header; and the controller is configured to rewrite the header to configure the third identifier based on the first identifier, the second identifier and information related to the channel between the second entity and the third entity, and send the rewritten header as the third identifier.

[0209] According to various examples, the channel is a PC5 RLC channel, and the information includes information related to the outgoing PC5 RLC channel and / or information related to the incoming PC5 RLC channel.

[0210] According to various examples, the header is a Side Link Relay Adaptor Protocol (SRAP) header processed by the SRAP layer at the second entity; and / or wherein this information is included in the header of the packet.

[0211] According to various examples, the controller is configured to: receive from the first entity a third identifier indicating a second pair including the second and third entities; and send the third identifier to the third entity.

[0212] According to various examples, the second entity is one of at least one intermediate entity; wherein each of the plurality of entities is a different user equipment (UE); and / or wherein each intermediate entity is a different relay UE.

[0213] According to a third aspect of this disclosure, a method is provided for a first entity in a communication system, wherein the communication system includes a plurality of entities, the plurality of entities including the first entity, and the method includes: configuring one or more identifiers, each identifier being configured to indicate a pair of entities among the plurality of entities; wherein the plurality of entities includes a source SRC end entity, at least one intermediate entity, and a destination DST end entity; and wherein each pair of entities includes an SRC entity and a DST entity communicatively connected to the SRC entity, and no pair of entities includes both an SRC end entity and a DST end entity.

[0214] According to various examples, the method of the third aspect further includes one or more operations and / or features related to (e.g., performed by the first entity) the first entity described in the first aspect and the various associated examples above.

[0215] According to a fourth aspect of this disclosure, a method for a second entity in a communication system is provided, wherein the communication system includes a plurality of entities, the plurality of entities including the second entity, the method comprising: receiving information including a first identifier from a first entity among the plurality of entities, the first identifier indicating a first pair including the first entity and the second entity; receiving a packet from the first entity; and transmitting the packet to a third entity based on the first identifier; wherein the plurality of entities includes a source SRC end entity, at least one intermediate entity, and a destination DST end entity; and wherein, in the first pair, the third entity is a DST entity, and the second entity is an SRC entity communicatively connected to the DST entity.

[0216] According to various examples, the method of the fourth aspect further includes one or more operations and / or features related to (e.g., performed by the second entity) the second entity described in the second aspect above and the various examples associated therewith.

[0217] Furthermore, it will be understood that this disclosure includes examples whereby the aforementioned first entity (according to the first aspect above and various associated examples) is further configured to perform any one or more operations, features, etc., disclosed herein in relation to configuring and / or signaling SRAP headers, SRAP configuration, and / or local IDs. That is, this disclosure also includes examples where the first entity according to the first aspect is configured to assume the role of a per-hop (or otherwise, e.g., global) local ID allocator (as described in other parts of this document).

[0218] Similarly, it will be understood that this disclosure includes examples whereby the aforementioned second entity (according to the second aspect above and various associated examples) is further configured to perform any one or more operations, features, etc., disclosed herein in relation to receiving, configuring, and / or signaling SRAP headers, SRAP configuration, and / or local IDs. That is, this disclosure also includes examples where the second entity according to the second aspect is configured to assume the role of a per-hop (or otherwise, e.g., global) local ID allocator (as described elsewhere herein), or is configured to rewrite the header of received packets to include an ID (e.g., a local ID) for the next hop (and / or the next-next hop) to allow the next-hop's DST(Rx) entity to identify the packet for this purpose, etc.

[0219] It will be understood that in each of the examples / embodiments / aspects above, one or more features or operations may be omitted, modified, or changed (e.g., the order of features or operations may be changed) if necessary and appropriate. Furthermore, one or more features or operations from any example / embodiment may be combined with features or operations from any other example / embodiment. Specifically, regardless of whether guidance on combinations of features / examples is found herein, this disclosure should be considered to include all combinations of two or more of the embodiments, examples, etc., disclosed herein, and all combinations of two or more of the features disclosed herein.

[0220] The techniques described herein can be implemented using any suitably configured apparatus and / or system. Such apparatus and / or system can be configured to perform methods according to any aspect, embodiment, or example disclosed herein. Such apparatus may include one or more elements, such as receivers, transmitters, transceivers, processors, controllers, modules, units, etc., each element configured to perform one or more corresponding process, operational, and / or method steps for implementing the techniques described herein. For example, operation / function of X can be performed by a module (or X module) configured to perform X. One or more elements can be implemented in hardware, software, or any combination of hardware and software.

[0221] It will be understood that the examples of this disclosure can be implemented in the form of hardware, software, or any combination of hardware and software. Any such software can be stored in the form of volatile or non-volatile memory, such as a storage device like ROM (whether erasable or rewritable); or in the form of memory, such as, for example, RAM, memory chips, devices, or integrated circuits; or stored on an optically or magnetically readable medium, such as, for example, CDs, DVDs, disks, or magnetic tapes.

[0222] It will be understood that storage devices and storage media are embodiments of machine-readable storage media adapted to store one or more programs comprising instructions that, when executed, implement certain examples of this disclosure. Thus, certain examples provide a program comprising code for implementing methods, apparatus, or systems according to any examples, embodiments, and / or aspects disclosed herein, and / or a machine-readable storage medium for storing such a program. Furthermore, such a program can be transmitted electronically via any medium, such as communication signals carried by a wired or wireless connection.

[0223] Although this disclosure has been shown, illustrated and described with reference to certain examples, those skilled in the art will understand that various changes in form and detail may be made therein without departing from the scope of this disclosure.

[0224] Readers should note all documents and files relating to this application that are submitted concurrently with or prior to this specification and are publicly available together with this specification, and the contents of all such documents and files are incorporated herein by reference.

[0225] Figure 5 An example of the structure of a terminal according to an embodiment of this disclosure is shown.

[0226] refer to Figure 5 According to embodiments of the present disclosure, the terminal 500 may include a controller 501, a transceiver 502, and a memory 503. In this disclosure, the controller 501 of the terminal 500 may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0227] The controller 501 can control the overall operation of the terminal 500 according to the embodiments provided in this disclosure. For example, the controller 501 can control the signal flow between the various blocks to perform operations according to the above-described drawings (or sequence diagrams or flowcharts).

[0228] Transceiver 502 can send and receive signals. For example, according to embodiments of this disclosure, transceiver 502 can send signals to a node or base station and receive signals from a node or base station.

[0229] The memory 503 can store at least one of the information sent and received by the transceiver 502 and the information generated by the controller 501. Furthermore, the memory 503 can be defined as a storage device.

[0230] Figure 6 The structure of a base station to which this disclosure can be applied is shown.

[0231] refer to Figure 6 According to embodiments of the present disclosure, the base station 600 may include a controller 601, a transceiver 602, and a memory 603. In this disclosure, the controller 601 of the base station 600 may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

[0232] The controller 601 can control the overall operation according to the embodiments provided in this disclosure. For example, the controller 601 can control the signal flow between the various blocks to perform operations according to the above figures (or sequence diagrams or flowcharts).

[0233] Transceiver 602 can send and receive signals. For example, according to embodiments of this disclosure, transceiver 602 can send signals to a terminal or node and receive signals from a terminal or node.

[0234] The memory 603 can store at least one of the information transmitted and received by the transceiver 602 and the information generated by the controller 601. Furthermore, the memory 603 can be defined as a storage device.

[0235] The methods disclosed in the claims and / or the methods according to the embodiments described in this disclosure may be implemented by hardware, software, or a combination of hardware and software.

[0236] When the method is implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). The one or more programs stored in the computer-readable storage medium may be configured to be executed by one or more processors within an electronic device. The at least one program may include instructions that cause the electronic device to perform the method as defined in the appended claims and / or as described in various embodiments of this disclosure herein.

[0237] These programs (software modules or software) can be stored in non-volatile memory, including random access memory and flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), disk storage devices, optical disc ROM (CD-ROM), digital versatile optical disc (DVD), or other types of optical storage devices, or magnetic tape. Alternatively, any combination of some or all of these can form a memory in which programs are stored. Furthermore, multiple such memories can be included in an electronic device.

[0238] Furthermore, the program can be stored on a connectable storage device that can be accessed by the electronic device via a communication network such as the Internet, intranet, local area network (LAN), wide area network (WLAN), and storage area network (SAN), or a combination thereof. This storage device can also be accessed via an external port.

[0239] In addition, separate storage devices on communication networks can access portable electronic devices.

[0240] In the detailed embodiments described above, elements included in this disclosure are represented in a singular or plural form according to the presented embodiments. However, for ease of description, the singular or plural form is suitably chosen for the presented situation, and this disclosure is not limited to elements represented in a singular or plural form. Thus, an element represented in a plural form may also include a single element, or an element represented in a singular form may include multiple elements.

[0241] The embodiments of this disclosure described and illustrated in the specification and accompanying drawings are merely specific examples presented to facilitate the explanation of the technical content of the embodiments of this disclosure and to aid in the understanding of the embodiments of this disclosure, and are not intended to limit the scope of the embodiments of this disclosure. That is to say, it will be apparent to those skilled in the art that other modifications based on the technical concept of this disclosure can be implemented.

[0242] Furthermore, the above embodiments can be used in combination as needed.

[0243] In the accompanying drawings describing the methods of this disclosure, the order of description does not always correspond to the order in which the steps of each method are performed, and the order of the steps may be changed or the steps may be performed in parallel.

[0244] In the accompanying drawings describing the methods of this disclosure, the order of description does not always correspond to the order in which the steps of each method are performed, and the order of the steps may be changed or the steps may be performed in parallel.

[0245] Furthermore, in the methods of this disclosure, some or all of the contents of each embodiment may be combined without departing from the basic spirit and scope of this disclosure.

[0246] The embodiments of this disclosure described and illustrated in the specification and accompanying drawings are merely specific examples presented to facilitate the explanation of the technical content of the embodiments of this disclosure and to aid in the understanding of the embodiments of this disclosure, and are not intended to limit the scope of the embodiments of this disclosure. That is, it will be apparent to those skilled in the art that other variations based on the technical concepts of this disclosure can be implemented. Furthermore, the various embodiments described above can be combined as needed. For example, all embodiments of this disclosure can be partially combined to operate a base station and a terminal.

[0247] Although this disclosure has been described with reference to various embodiments, various changes and modifications can be made by those skilled in the art. This disclosure is intended to include such changes and modifications that fall within the scope of the appended claims.

[0248] Abbreviations and definitions (as used in this article)

[0249] 3GPP - Third Generation Partnership Project

[0250] 5G—Fifth Generation

[0251] 5GC—5G Core Network

[0252] 5QI—5G QoS Identifier

[0253] 5GS—5G System

[0254] 5GSM—5G System Session Management

[0255] 5GMM—5G System Mobility Management

[0256] AF—Application Functions

[0257] AI—Artificial Intelligence

[0258] AIML—Artificial Intelligence / Machine Learning

[0259] AM - Confirmation Mode

[0260] AMF—Access and Mobility Management Function

[0261] AS—Application Server

[0262] ASP—Application Service Provider

[0263] ATSSS—Access Traffic Guidance, Switching, and Offloading

[0264] CDRX—Connected Mode Discontinuous Receiver

[0265] CSI—Channel State Information

[0266] DCAF—Data Acquisition Application Functions

[0267] DNN—Data Network Name

[0268] DNS — Domain Name Server

[0269] DRB—Data Radio Bearer

[0270] DRX—Discontinuous Reception

[0271] eNB—Evolved Node B

[0272] EPS—Evolved Packet System

[0273] FQDN—Fully Qualified Domain Name

[0274] GBR—Guaranteed Bit Rate

[0275] gNB—Next Generation Node B

[0276] GNSS—Global Navigation Satellite System

[0277] GPSI—General Public Contract Identifier

[0278] Hbh — Jumping

[0279] IAB—Integrated Access and Backhaul

[0280] ID — Identifier

[0281] IoT (Internet of Things)

[0282] IMEI—International Mobile Equipment Identity

[0283] IP—Internet Protocol

[0284] I-SMF—Intermediate SMF

[0285] LMF—Location Management Function

[0286] MA-PDU—Multi-access PDU

[0287] ML—Machine Learning

[0288] MME—Mobility Management Entity

[0289] MN—Master Node

[0290] MNO—Mobile Network Operator

[0291] MT—Mobile Terminal

[0292] NAS (Non-Access Layer)

[0293] NB—Narrowband

[0294] NRF—Network Repository Function

[0295] NG-RAN—Next Generation Radio Access Network

[0296] NG-eNB—Next Generation eNB

[0297] NSA - Non-Standalone Networking

[0298] NS-AoS—Network Slicing Service Area

[0299] NSSAI—Network Slice Selection Auxiliary Information

[0300] NTN—Non-terrestrial network

[0301] NW—Network

[0302] NWDAF—Network Data Analysis Function

[0303] OAM—Operation, Management and Maintenance

[0304] PCF—Policy Control Function

[0305] PCC—Policy and Charging Control

[0306] PCO—Protocol Configuration Options

[0307] PDR—Group Detection Rules

[0308] PDU—Protocol Data Unit

[0309] PMF—Performance Measurement Function

[0310] PSA—PDU Session Anchor Point

[0311] QFI—QoS Flow Identifier (ID)

[0312] QoE—Quality of Experience

[0313] QoS—Quality of Service

[0314] RA—Registered Area

[0315] RACH—Random Access Channel

[0316] RAN—Radio Access Network

[0317] RAT—Wireless Access Technology

[0318] RLC-AM—Radio Link Control Confirmation Mode

[0319] RLC-UM—Radio Link Control Unacknowledged Mode

[0320] RRC—Radio Resource Control

[0321] SA—Standalone Network

[0322] SBA—Service-Based Architecture

[0323] SBI—Service-Based Interface

[0324] SCEF—Service Capability Exposure Function

[0325] SCP—Service-Based Communication Agent

[0326] SCTP—Stream Control Transmission Protocol

[0327] SDAP—Service Data Adaptation Protocol

[0328] SDU—Service Data Unit

[0329] SIM—Subscriber Identity Module

[0330] SLA—Service Level Agreement

[0331] SM—Session Management

[0332] SMF—Session Management Function

[0333] SN—Secondary Node

[0334] S-NSSAI—Single Network Slice Selection Auxiliary Information

[0335] SSB—Synchronization Signal Block

[0336] SSC—Session and Service Continuity

[0337] SUPI—Contract Permanent Identifier

[0338] TA—Tracking Area

[0339] TAI—Tracking Area Identifier

[0340] TE—Terminal Equipment

[0341] TM—Transparent Mode

[0342] TS - Technical Specification

[0343] UDM—Unified Data Manager

[0344] UDR—Unified Data Repository

[0345] UE—User Equipment

[0346] UL—Uplink

[0347] UM—Unacknowledged mode

[0348] UP—User Interface

[0349] UPF—User Face Function

[0350] URLLC—Ultra-Reliable Low-Latency Communication

[0351] URSP—UE routing strategy

Claims

1. A method performed by a first user equipment (UE) in a wireless communication system, the method comprising: Identify the second UE used for sidelink communication; Assign the source UE's identifier ID and the destination UE's ID; as well as Send information related to the ID of the source UE and information related to the ID of the destination UE to the second UE. The information related to the ID of the source UE and the information related to the ID of the destination UE are used to communicate between the source UE and the destination UE via the first UE.

2. The method according to claim 1, in, The first UE includes a relay UE, and The second UE includes at least one of the source UE or the destination UE.

3. The method according to claim 1, in, Information relating to the ID of the source UE and information relating to the ID of the destination UE are included in the Sidelink Relay Adaptation Protocol (SRAP) header.

4. The method according to claim 3, in, The SRAP header further includes information related to the bearer's ID.

5. A method performed by a second user equipment (UE) in a wireless communication system, the method comprising: Receive information related to the source UE's identifier ID and information related to the destination UE's ID from the first UE. Wherein, the ID of the source UE and the ID of the destination UE are assigned by the first UE, and The information related to the ID of the source UE and the information related to the ID of the destination UE are used to communicate between the source UE and the destination UE via the first UE.

6. The method according to claim 5, in, The first UE includes a relay UE, and The second UE includes at least one of the source UE or the destination UE.

7. The method according to claim 5, in, Information related to the source UE's ID and information related to the destination UE's ID are included in the Sidelink Relay Adaptation Protocol (SRAP) header, and The SRAP header further includes information related to the bearer's ID.

8. A first user equipment (UE) in a wireless communication system, the first UE comprising: transceiver; as well as At least one processor, connected to the transceiver and configured to: Identify the second UE used for sidelink communication; Assign the source UE's identifier ID and the destination UE's ID; and Send information related to the ID of the source UE and information related to the ID of the destination UE to the second UE. The information related to the ID of the source UE and the information related to the ID of the destination UE are used to communicate between the source UE and the destination UE via the first UE.

9. The first UE according to claim 8, in, The first UE includes a relay UE, and The second UE includes at least one of the source UE or the destination UE.

10. The first UE according to claim 8, in, Information relating to the ID of the source UE and information relating to the ID of the destination UE are included in the Sidelink Relay Adaptation Protocol (SRAP) header.

11. The first UE according to claim 10, in, The SRAP header further includes information related to the bearer's ID.

12. A second user equipment (UE) in a wireless communication system, the second UE comprising: transceiver; as well as At least one processor, connected to the transceiver and configured to: Receive information related to the source UE's identifier ID and information related to the destination UE's ID from the first UE. Wherein, the ID of the source UE and the ID of the destination UE are assigned by the first UE, and The information related to the ID of the source UE and the information related to the ID of the destination UE are used to communicate between the source UE and the destination UE via the first UE.

13. The second UE according to claim 12, in, The first UE includes a relay UE, and The second UE includes at least one of the source UE or the destination UE.

14. The second UE according to claim 12, in, Information relating to the ID of the source UE and information relating to the ID of the destination UE are included in the Sidelink Relay Adaptation Protocol (SRAP) header.

15. The second UE according to claim 14, in, The SRAP header further includes information related to the bearer's ID.

Images