Methods and apparatus for identifier allocation in a communication system

Abstract

First entity in a communication system, comprising a plurality of entities including a source (SRC) end entity (e.g. a source UE), at least one intermediate entity (e.g. a UE-to-UE relay) and a destin

Description

BACKGROUND Field

[0001] Certain examples of the present disclosure relate to methods, apparatus and / or systems for configuring and / or signalling identifiers in a communication system. In particular, certain examples relate to allocating identifiers in a centralized or decentralised manner in a UE-to-UE relay. In some examples, identifiers are assigned at each hop or stage in the relay, to provide a local ID for each hop. According to various examples, the local ID identifies a source (or transmitting) UE and a destination (or receiving) UE for each hop in the relay. Description of Related Art

[0002] The content of the following documents is referred to below and / or their content provides background information that the following disclosure should be considered in the context of: [1] 3GPP TR 38.836 - Study on NR sidelink relay, (e.g. v17.0.0). [2] 3GPP TS 38.351 - NR; Sidelink Relay Adaptation Protocol (SRAP) Specification, (e.g. V17.5.0). [3] 3GPP TS 38.331 - NR; Radio Resource Control (RRC); Protocol specification, (e.g. V17.5.0). Note: the indicated version numbers are provided for illustrative purposes, other (including future) versions of these documents are considered also.

[0003] Wireless or mobile (cellular) communications networks in which a mobile terminal (e.g., user equipment (UE), such as a mobile handset) communicates via a radio link with a network of base stations, or other wireless access points or nodes, have undergone rapid development through a number of generations. The 3rd Generation Partnership Project (3GPP) design, specify and standardise 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 being considered.

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

[0005] In 5G systems a new air interface has been developed, which may be referred to as 5G New Radio (5G NR) or simply NR. NR is designed to support the wide variety of services and use case scenarios envisaged for 5G networks, though builds upon established LTE technologies. B5G systems, such as 6G, are currently being considered and developed, and are expected to at least partly build on 5G systems.

[0006] New frameworks and architectures are being developed as part of 5G network (and beyond, such as 6G networks) in order to increase the range of functionality and use cases available through 5G networks.

[0007] As part of this, sidelink UE to UE communications are provided so as to facilitate communication directly between UEs without relying on a connection via base stations and the core network.

[0008] The Rel-17 3GPP RAN Study Item “Study on NR Sidelink Relay”, completed in 2021 and whose outcome is captured in 3GPP TR 38.836 v17.0.0 [1], considered both UE-to-Network Relay and UE-to-UE (U2U) Relay coverage extension. However, subsequent Rel-17 normative work in RAN focused exclusively on UE-to-Network Relay.

[0009] U2U Relay enables the coverage extension of the sidelink (SL) transmissions between two sidelink UEs, without relying on the use of uplink (UL) or downlink (DL). This may be especially important for the partial coverage scenario whereby at least one of the UEs involved in relaying (e.g. at least one of source UE, relay UE, and / or destination UE) is in-coverage, and at least one of the UEs involved in relaying (e.g. at least another one of source (SRC) UE, relay UE, and / or destination (DST) UE) is out-of-coverage. When a relay UE is in-coverage, it can access the network via the Uu link (i.e. between the UE and 5G RAN). Relaying of data between a source UE and a destination UE can occur once a PC5 link is established between the Source UE, UE-to-UE Relay, and Destination UE.

[0010] In some cases, multiple DST remote UEs may be connected to a relay UE for a single SRC remote UE. In other or additional cases, a relay UE may be connected to multiple SRC remote UEs for a single DST remote UE. In some cases, there may also be multiple hops (or links, steps, nodes etc.) between a SRC remote UE and a DST remote UE.

[0011] Figures 1A and 1B respectively show User plane protocol stack 100 and Control plane protocol stack 150 for Layer-2 (L2) U2U Relay, as captured in the 3GPP TR 38.836 v17.0.0 [1], 3GPP agreed to introduce the Adapt layer on the PC5 links, as shown in the above figures in shaded boxes. The Adapt layer is also present on the Uu link, between the Relay UE and the gNB (not shown in above Figures).

[0012] The main agreed functionality of Adapt on the Uu link includes the mapping of UL PC5 bearers onto UL Uu bearers, and performing the inverse process on the DL. The main agreed functionality of Adapt on the PC5 link includes the mapping of bearers onto PC5 RLC channels.

[0013] The Adapt layer was (re)named Sidelink Relay Adaptation Protocol, or SRAP for short (see TS 38.351 [2]), and so these terms may be regarded as synonymous. The following is the basic model and operation of SRAP for Rel-17 U2N SL relaying, as agreed by 3GPP: — On a U2N relay UE, the SRAP sublayer contains one SRAP entity at Uu interface and a separate collocated SRAP entity at the PC5 interface. On a U2N remote UE, the SRAP sublayer contains only one SRAP entity at the PC5 interface. — Each SRAP entity has a transmitting part and a receiving part. Across the PC5 interface, the transmitting part of a SRAP entity at a U2N remote UE has a corresponding receiving part of an SRAP entity at a U2N relay UE, and vice-versa. Across the Uu interface, the transmitting part of a SRAP entity at a U2N relay UE has a corresponding receiving part of a SRAP entity at a gNB, and vice-versa. — At a remote UE, in the UL direction (or on the UL), the SRAP will determine SRAP UE ID and BEARER ID and add a SRAP header. At a / the remote UE, in the DL direction (or on the DL), the SRAP will remove the SRAP header and deliver the packet to higher layers. — At a relay UE, on the UL, the SRAP will map a packet from a PC5 channel to a Uu channel using a SRAP UE ID and BEARER ID contained in the packet itself, and the mapping configuration provided by the network. At a / the relay UE, on the DL, the SRAP will map a packet from a Uu channel to a PC5 channel using SRAP UE ID and BEARER ID contained in the packet itself, and the mapping configuration provided by the network.

[0014] The following agreements were made as part of Rel-18 normative work on U2U SL Relaying at RAN2#122 in May 2023: Agreements: For the possible use of a short ID in U2U relay, RAN2 will downselect between the following options for identifying the source and destination remote UEs at the SRAP layer: a) Single ID, identifying the source and destination remote UEs b) Source ID and Destination ID For the possible use of a short ID in U2U relay, the U2U relay UE performs the ID assignment. FFS if this ID should be assigned hop-by-hop or globally. These agreements do not imply agreement to use a short ID. (“FFS”: “for further study”)

[0015] For L2 UE-to-UE Relay, functionalities of the SRAP layer are still under discussion. In particular, it is unclear how to address the problem of assigning / configuring remote UE’s local SRAP UE ID. SUMMARY

[0016] It is an aim of certain examples of the present disclosure to address, solve and / or mitigate, at least partly, at least one of the problems and / or disadvantages associated with the related art, for example at least one of the problems and / or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.

[0017] The scope of the present invention may be determined according to the independent claims. Various examples of the present invention are outlined in the dependent claims.

[0018] Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Embodiments / examples of the present disclosure are further described hereinafter with reference to the accompanying drawings, in which: Figures 1A and 1B schematically show User plane protocol stack and Control plane protocol stack for Layer-2 (L2) U2U Relay, respectively. Figure 2 is a method flow diagram illustrating examples according to the present disclosure. Figure 3 is a method flow diagram illustrating examples according to the present disclosure. Figure 4 is a block diagram illustrating an example structure of an entity in accordance with certain examples of the present disclosure. DETAILED DESCRIPTION

[0020] The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of certain examples of the present disclosure. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the invention or disclosure.

[0021] The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

[0022] Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure.

[0023] The terms and words used herein are not limited to the bibliographical or standard meanings, but are merely used to enable a clear and consistent understanding of the disclosure.

[0024] Throughout the description of this specification, the words “comprise”, “include” and “contain” and variations of the words, for example “comprising” and “comprises”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof.

[0025] Throughout the description of this specification, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects.

[0026] Throughout the description, the expression “at least one of A, B and / or C” (or the like), the expression “and / or”, and the expression “one or more of A, B and / or C” (or the like) should be seen to separately include all possible combinations, for example: A, B, C, A and B, A and C, A and B and C.

[0027] Throughout the description of this specification, language 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 carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y.

[0028] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof described or disclosed in conjunction with a particular aspect, embodiment or example are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith.

[0029] Certain examples of the present disclosure relate to methods, apparatus and / or systems for configuring and / or signalling identifiers in a communication system. In particular, certain examples relate to allocating identifiers in a centralized or decentralised manner in a UE-to-UE relay. In some examples, identifiers are assigned at each hop or stage in the relay, to provide a local ID for each hop. According to various examples, the local ID identifies a source (or transmitting) UE and a destination (or receiving) UE for each hop in the relay.

[0030] The following examples are applicable to, and use terminology associated with, 3GPP 4G and 5G. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 4G or 5G, and may be applied in any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 4G or 5G NR or any other relevant standard. For example, the functionality of the various entities or network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network. In particular, the following disclosure should be considered at least in relation to 6G also, which is expected to use at least part of the 5G architecture, or equivalent, and to which the present disclosure also relates.

[0031] A particular entity may be implemented as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[0032] The skilled person will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 4G, 5G, B5G or 6G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements, entities and / or messages may be added to the examples disclosed herein. • One or more non-essential elements, entities and / or messages may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed may be modified, if possible, in alternative examples. • The transmission of information between entities is not limited to the specific form, type and / or order of messages described in relation to the examples disclosed herein.

[0033] Certain examples of the present 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 therefor. Such an apparatus / device / network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g., a network) comprising one or more such apparatuses / devices / network entities, and / or a method therefor.

[0034] It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and / or apparatus in accordance with any aspect, example and / or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program.

[0035] As described above, for L2 UE-to-UE (U2U) Relay, functionalities of the SRAP layer are still under discussion. However, it is expected that the SRAP layer will have a bearer mapping function (i.e. mapping of end-to-end (E2E) sidelink bearer(s) between SRC (transmitting, TX / Tx) UE and DST (receiving, RX / Rx) UE onto PC5 channel(s) between SRC (Tx) UE and relay UE, and between relay UE and DST (Rx) UE).

[0036] The E2E sidelink bearers may include one of data radio bearer(s) and signaling radio bearer(s) between SRC (Tx) UE and DST (Rx) UE. The identity information of remote UE end-to-end sidelink Radio Bearer is included in the SRAP layer, while the identity information of SRC remote UE and / or the identity information of DST remote UE and / or identifier of SRC remote UE and DST remote UE pair are candidate information to be included in the SRAP header.

[0037] As mentioned above, there is an issue of how to assign and / or configure remote UEs local SRAP UE ID. The present disclosure provides various examples, embodiments, aspects etc. which aim to address, at least to some extent, this issue. Of course, other advantages may also arise from the examples described herein.

[0038] Herein, a relay may be regarded as including, or being, one or more UEs (or relay UE(s)) between a source (SRC) end UE (also referred to as a source remote end UE) and a destination (DST) end UE (also referred to as a destination remote end UE). Further, in some cases, reference to a / the relay be considered to include the relay UEs and one or more of the SRC remote end UE and the DST remote end UE. In other words, the relay could be considered to include the endpoints, being the SRC end UE and the DST end UE, as well as the UEs in-between, the SRC end remote UE and the DST remote end UE may be regarded, in general, as end UEs. The SRC end UE and the DST end UE are both examples of an end UE.

[0039] Additionally, a relay UE may also be termed a SRC UE in a case where the relay UE is to transmit, or is transmitting, a packet or data to another relay UE or to the DST end UE. Similarly, a relay UE may also be termed a DST UE in a case where the UE is to receive, or receiving, a packet or data from another relay UE or from the SRC end UE. It will be appreciated that a relay UE may therefore also be regarded as a SRC UE and / or a DST relay, depending on a hop in the relay being considered. For example: when considering a hop where a relay UE will be receiving a packet (e.g. Rx UE), the relay UE may be regarded as a DST UE; when considering another hop where the same relay UE will be transmitting a packet (e.g. Tx UE), the relay UE may be regarded as a SRC UE; and when considering another hop relating to other UEs (i.e., where the same relay UE is neither transmitting nor receiving), the relay UE is neither SRC UE nor DST relay but simply regarded as relay UE.

[0040] In some examples, a path may be defined as a selection or subgroup of one or more UEs in a relay comprising a plurality of UEs. The path may be determined for a specific SRC end UE and / or a specific DST end UE, with the one or more UEs being determined according to these endpoints (e.g., where a different one or more UEs would be determined for a different SRC end UE or a different DST end UE). In some examples, a path may include all of the plurality of UEs in the relay, i.e., the path may correspond to the relay itself. Here, the relay may or may not be considered to also include the end UEs (e.g. a SRC end UE and a DST end UE). In the disclosure, reference to a hop or hops in a relay may also be regarded as referring to a hop or hops in a path in a relay; e.g., such as when a path in a relay is determined.

[0041] In various examples, there may exist a plurality of valid paths between SRC end UE and DST end UE. In which case, an entity (e.g., a UE among the end UEs or the relay UEs, a base station (e.g. gNB) or the core network) may determine the plurality of valid paths (e.g., based on validity criteria being met) and / or identify a preferred path from among the plurality of paths, where this entity either also configures or allocates an ID(s) as disclosed in the examples herein or provides details on the path / paths to another entity which configured or allocated an ID(s) as disclosed in the examples found herein.

[0042] According to various example of the present disclosure, an identifier (ID) for a SRC remote end UE and / or an ID for a DST remote end UE (where this may be a single ID, i.e. relating to both the SRC remote end UE and the DST remote end UE, or two separate IDs, i.e., one ID for each UE) may change from hop to hop. For example, such a process may be regarded as a hop-by-hop (HBH) identifier allocation. In accordance with some examples, the ID for the SRC remote end UE and / or the ID for the DST remote end UE may be allocated in a decentralised fashion or manner. For example, a single entity may allocate an ID for the SRC remote end UE and / or an ID for the DST remote end UE at each hop (such that IDs are provided for all hops, on the HBH basis), or a number of entities (such as different entities in the relay, e.g., the UE at each hop) may allocate an ID for the SRC remote end UE and / or an ID for the DST remote end UE at each hop (such that IDs are provided for all hops, on the HBH basis). As will be discussed in examples below, the entity / entities may include either or both of the end UEs and / or one or more of the relay UEs, and may be configured to allocate the ID at each hop (e.g., an ID for the SRC remote end UE and / or an ID for the DST remote end UE corresponding to each hop is allocated).

[0043] In various examples, a per-hop local ID (that is, a local ID allocated at each hop in a relay) may identify a SRC ID of the individual link (e.g. corresponding to the Tx UE, being the UE at a hop which is transmitting a packet, data, information, signals etc.) and a DST ID of the same individual link (e.g. corresponding to the Rx UE, being the UE at the hop which is receiving from the Tx UE). In other words, the local ID may identify the link corresponding to a single hop (or identify a hop itself) between a pair of a SRC and a DST UE (which, for example, may correspond to a pair of an end UE and a relay UE, or a pair of relay UEs). To give an example, such a pair may be one of: (SRC remote end UE, relay UE #1), (relay UE #1, relay UE #2),..., (relay UE #n, DST remote end UE); where a “relay UE” is a UE between the SRC remote end UE and the DST remote end UE.

[0044] In other examples, a per-hop local ID may identify the pair of SRC remote end UE and DST remote end UE on each of the hops, and this ID may or may not vary from hop to hop. In other words, in various examples implementing the per-hop local ID method, in addition to, or instead of, a local ID identifying a pair of a SRC UE and a DST UE for each hop (‘per-hop’), an ID is also configured for the pair of end UEs (SRC remote end UE, DST remote end UE) and this ID may be fixed between hops or may change between hops. Accordingly, a local ID for each hop may be considered to include both the local ID for the pair of SRC and DST UEs for the corresponding hop and the ID for the pair of end UEs.

[0045] Both sets of examples (referring to the examples where a per-hop local ID may identify a SRC ID of an individual link and a DST ID of the same individual link, and the examples where a per-hop local ID may identify the pair of SRC remote end UE and DST remote end UE on each hop) are applicable to the multi-hop extension (that is, a case where there are multiple hops in the relay), and, optionally, the ID (e.g., the local ID or the ID for the pair of end UEs) may be allocated in a decentralized fashion in each case. The feature of the ID not varying (e.g., being maintained or fixed) from hop-to-hop may lend itself more easily than the feature of varying the local ID from hop-to-hop to examples where there is a globally assigned local ID (e.g., unique for the U2U relaying network ora subnetwork), that is, to examples when the assignment is done in a centralized manner. That is: for both sets of examples (as identified at the beginning of this paragraph), the ID may vary from hop to hop; and, for the examples where a per-hop local ID may identify the pair of SRC remote end UE and DST remote end UE on each hop, the ID may not vary from hop to hop. Regarding the latter, it will also be appreciated that, for the examples where a per-hop local ID may identify a SRC ID of an individual link and a DST ID of the same individual link, in some cases the ID may not vary from hop to hop, for example in cases where local IDs are re-used for different hops.

[0046] The (per-hop) local ID may be the ID used in the SRAP layer. The assignment of such a SRAP ID can be done by any of the relay UEs in the chain, or SRC / DST remote end UEs. In other words, any one or more of the UEs in the relay, including the SRC remote end UE and / or the DST remote end UE, may be configured to assign (e.g., allocate, provide, configure, process etc.) a SRAP ID based on the local ID (e.g. assigning the local ID as the SRAP ID). For example, in a centralized method, the SRC remote end UE may assign local IDs corresponding to each hop; whereas, in a decentralised method, each UE of two or more UEs from among the end UEs and the relay UE(s) may assign a local ID for a different hop.

[0047] Further, the assigned SRAP ID may be sent to other relay UEs or remote end UEs as needed. That is, the UE which assigns the SRAP ID, or another UE having knowledge of the SRAP ID, may transmit the SRAP ID to another UE in the relay. In certain examples, if a single ID is used for the pair (e.g., the pair of SRC and DST end UEs), this may be the PC5 link ID for the link (e.g., the PC5 link between the SRC remote end UE and the DST remote end UE). As may be evident from the examples above, the “pair” may refer to the pair of SRC remote end UE and DST remote end UE, or a pair of the Tx UE (e.g. SRC UE) and Rx UE (e.g. DST UE) on each hop.

[0048] HBH identifier allocation (e.g. an ID allocation method whereby local ID changes or is changed from link to link (hop to hop) or subnetwork to subnetwork) may result in a smaller SRAP header (e.g., fewer bits needed in the SRAP header for a pair ID (e.g., the ID for a pair such as defined above), since the pair ID is a local ID such as defined herein), and / or may mean less signalling is needed than would be needed to allocate, maintain and transmit unique global pair IDs. That is, in various examples, a local ID will require fewer bits, or otherwise require less memory or storage, that a global ID. However, some examples of HBH identifier allocation may result in higher signalling to configure mapping tables (as will be discussed later), and larger mapping tables being stored at Relay UEs.

[0049] Various examples of the present disclosure provide for assigning or configuring per-hop local ID, assigning or configuring global “local” ID (e.g., local ID is assigned globally or centrally), SRAP configuration, local ID assignment procedure, and / or SRAP header format / SRAP header processing.

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

[0051] In various examples of the present disclosure, the DST remote end UE’s address, or an identifier for the pair of (SRC remote end UE, DST remote end UE), may not be included in the SRAP header itself but rather an Rx relay UE on a hop (that receives the packet) uses a related local ID to decide the next hop. In one example, each relay UE obtains one or more of SRC remote end UE info (e.g., information on the SRC end UE), DST remote end UE info (e.g., information on the DST end UE), and, if a next relay UE exists, next relay UE info (e.g., information on a next relay UE). This / these information may be obtained for each direction during the discovery procedure between SRC remote end UE and DST remote end UE. In some examples, the path may be decided (e.g., determined, identified, detected etc.) during the discovery procedure, while in other examples, the path may also be decided dynamically (or ‘on the fly’), as covered below. Herein, the path refers to, or includes, each relay UE per hop from SRC remote end UE to DST remote end UE. Accordingly, in various examples the relay UEs between SRC remote end UE and DST remote end UE are determined during the discovery procedure, while in other examples these relay UEs are determined dynamically (e.g. during packet transmission from SRC end UE to DST end UE). There may be a plurality of paths between SRC end UE and DST end UE. In examples disclosed herein, during discovery procedure, a path may be obtained / determined (e.g., by an entity such as an end UE or a relay UE) together with SRC remote end UE information, DST remote end UE information and information on a next relay UE (if there is one -e.g. if the next hop is not to the DST remote end UE). In other examples, a path may be determined / obtained from hop to hop.

[0052] According to various examples, one or more (e.g. each) relay UE may perform a mapping (or mapping process) analogous to the following: incoming local ID —► [OPTIONAL: (SRC remote end UE, DST remote end UE) global info] -► {outgoing local ID, next hop relay}

[0053] In some cases (SRC remote end UE, DST remote end UE) global info may not be needed at intermediate relay UE(s) (e.g., these being the relay UE(s) between the relay UEs in direct communication with the SRC remote end UE and the DST remote end UE, or all relay UEs between the SRC remote end UE and the DST remote end UE). This is because the intermediate UE(s) may only need to know which local ID to use for the next hop (i.e. for the next relay UE or Rx UE), and where to send the (potentially modified) packet (e.g., said modification being via SRAP header rewriting). However, even in such a case, an entity may need to configure these tables (e.g., one or more configuration table(s) showing mapping(s) between input and output channels including information on UEs and / or E2E bearer(s)) and that entity may also need to have (e.g., be provided or configured with) a global mapping. Further, this entity may also assign outgoing local ID for each incoming local ID. Note that the “global mapping” may refer to knowledge, at the entity, of the entire path (e.g., between SRC end UE and DST end UE, where this path or details thereof may have been determined or obtained by the entity) or of a plurality of valid paths (e.g., between SRC end UE and DST end UE, where these paths or details thereof may have been determined or obtained by the entity). Potentially, if an entity has a global mapping such as described above, the relay nodes or other relay nodes (if the entity is a relay node) may not have knowledge of the entire path or the plurality of valid paths, but may instead know details of a next hop and, optionally, details of a hop after the next hop.

[0054] In other, potentially alternative examples, outgoing local ID may be assigned by a / the relay UE itself. However, the relay UE may then need (SRC Remote end UE, DST Remote end UE) global info or, alternatively, at least two-hop knowledge of where the packet needs to go (i.e., knowledge of the destination of the packet for the hop after the next hop in the relay; e.g., if the relay UE assigning the outgoing local ID is node #1, the UE of the next hop is node #2 and the UE of the next-to-next hop is node #3, node #1 would require knowledge that the packet is to go to node #3). The latter alternative is discussed further in various examples below.

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

[0056] In various examples of the present disclosure, we define “SRAP configuration”, “local ID configuration” and “SRAP header” separately, as below. • In SRAP configuration, there is included or provided: E2E bearer ID for a pair of SRC remote end UE and DST remote end UE, local ID, and PC5 RLC channel (e.g. egress / ingress channels). It will be appreciated that, optionally, other information may be included in SRAP configuration. Furthermore, in some examples, PC5 RLC egress and / or ingress channel information may be omitted. • In local ID configuration, there is included or provided: local ID, SRC ID, DST ID. o In some examples, SRC ID corresponds to an ID for SRC remote end UE (‘SRC remote end UE ID’) and DST ID corresponds to an ID for DST remote end UE (‘DST remote end UE ID’). o In other examples, SRC ID and DST ID correspond to the ID for SRC UE and the ID for DST UE of each individual hop, respectively; e.g., in a one-hop relay scenario, local ID at one hop may include SRC ID and DST ID which correspond to the ID for SRC remote end UE and the ID for relay UE#1, respectively, while local ID at another hop may include SRC ID and DST ID which correspond to the ID for relay UE#1 and the ID for DST remote end UE, respectively. • In the SRAP header, there are E2E bearer ID for a pair of SRC remote end UE and DST remote end UE, local ID. It will be appreciated that, optionally, other information may be included in SRAP header.

[0057] Various examples of the present disclosure further include UE (e.g. end UE and relay UE) behaviours to handle SRAP header processing and / or SRAP configuration processing with per-hop local ID. In some examples, such configuration / behaviours may be defined in a future technical specification, such as in an update to 3GPP TS 38.351 [2] and / or 3GPP TS 38.331 [3],

[0058] As an example, for a one-hop relay scenario with (e.g. implementing, configuring etc.) HBH local ID, two local IDs are assigned / configured for the pair defined by (SRC remote end UE ID, DST remote end UE ID). The assignment may be done by SRC remote end UE, a relay UE or DST remote end UE for the direction {SRC remote end UE —► DST remote end UE}. In an example: SRAP configuration at a relay UE may be, or include, E2E bearer ID for the pair of SRC remote end UE and DST remote end UE, local ID1, PC5 RLC channel ingress, local ID 2, and PC5 RLC channel egress; SRAP configuration at SRC remote end UE may be, or include, E2E bearer ID for the pair of SRC remote end UE and DST remote end UE, local ID1, and PC5 RLC channel egress; and / or SRAP configuration at DST remote end UE may be, or include, E2E bearer ID for the pair of SRC remote end UE and DST remote end UE, local ID2, and PC5 RLC channel ingress. Of course, other SRAP configurations may be provided / configured.

[0059] In another example, for an N-hop relay scenario N+1 local IDs may be assigned / configured for the pair of SRC remote end UE ID and DST remote end UE ID. Assuming that the path (which, as indicated above, may include or is defined by each relay UE per hop from SRC remote end UE to DST remote end UE) is decided / determined, the SRAP configuration at the i-th relay UE (where i = 1, ..., N) may be E2E bearer ID for the pair of SRC remote end UE and DST remote end UE, local ID_i, PC5 RLC channel ingress, local IDJ+1, and PC5 RLC channel egress. Optionally, the SRAP configuration at the Nth relay UE may not include local ID_i+1; however, it may be necessary for the Nth relay UE to have information on where to forward / transmit a packet, in which case if the Nth relay UE does not include local IDJ+1 it may require other configuration for forwarding a transmission to DST end UE. It is noted that, in some examples, DST end UE may compare a local ID included in a packet header (e.g., in SRAP header of a received packet, such as may be received from the Nth relay UE) and its own SRAP ID (or may use a mapping between this local ID and SRAP ID) and infer that it (the DST end UE) is the intended destination of the packet, in which case the packet is passed to higher layers at the DST end UE instead of being forwarded on. It is noted that, in some examples, a relay UE may itself be the destination of a packet, in which case DST end UE may not be the intended destination of a packet but may instead forward the packet on, e.g. to another relay UE or the intended destination relay UE.

[0060] The header rewriting may be done at relay UE of each hop based on the SRAP configuration of incoming packet (which then becomes the outgoing packet). For example, packet header (e.g., SRAP header) may be rewritten at each relay UE such that a next relay UE may decode the packet header to identify or infer a nexthop for the packet.

[0061] In various examples, the HBH local ID may be assigned per SRC ID and DST ID, and, if the SRC ID is source layer-2 ID for SRC UE (orTx UE) and DST ID is source layer-2 ID for DST UE (or Rx UE), the local ID assignment can be performed according to UE’s source layer-2 ID update procedure. These examples include the cases where ‘SRC UE’ refers to SRC remote end UE and cases where ‘SRC UE’ refers SRC UE for each individual link or hop (e.g., SRC end UE and relay UEs which act as a SRC UE by transmitting the packet to another relay UE (which then acts as a DST UE)), and includes cases where ‘DST UE’ refers to DST remote end UE and cases where ‘DST UE’ refers to DST UE for each individual link or hop (e.g., DST end UE and relay UEs which act as a DST UE by receiving the packet or being to receive the packet).

[0062] Further understanding of the examples / cases described above may be gained through consideration of the following examples, which may show variations to the above.

[0063] In an example, SRAP configuration may include: E2E bearer ID for a pair of SRC remote end UE and DST remote end UE, local ID, and egress PC5 RLC channel. Ingress PC5 RLC channel may or may not be included also. For example, if a mapping is provided in which a combination of bearer ID for a pair of SRC remote end UE and DST remote end UE and local ID (i.e., the bearer ID and the local ID are used in conjunction with one another) is mapped to egress PC5 RLC channel, then ingress PC5 RLC channel may be omitted from SRAP configuration. In another example, a combination of ingress PC5 RLC channel and local ID may be mapped to egress PC5 RLC channel. Here, local ID is only needed if it is intended, as is the case in various examples of the present disclosure, to allow for multiplexing of data for multiple (SRC and / or DST) remote UE pairs (e.g., multiple SRC and / or DST UE pairs) onto a single PC5 RLC channel.

[0064] In an example, local ID configuration may include (or be implemented as a) locally assigned identifier for a SRC and DST pair (e.g., a {SRC, DST} pair, to use notation found herein). This may be per SRC remote end UE and DST remote end UE; and / or per SRC UE and DST UE of each individual link (or hop).

[0065] In another example, local ID configuration may include (or be implemented as a) globally assigned identifier for a SRC and DST pair (e.g., a {SRC, DST} pair). This may be per SRC remote end UE and DST remote end UE; per SRC UE and DST UE of each individual link (or hop); and / or per subnet.

[0066] In an example, SRAP header may include E2E bearer ID for a pair of SRC remote end UE and DST remote end UE, and local ID. In some cases, E2E bearer ID for a pair of SRC remote end UE and DST remote end UE may be included only for the purpose of sending different bearers for the same local ID via different PC5 RLC channels. As a result, such cases may provide better QoS management, at the expense of higher overhead. In other cases, SRAP header omits E2E bearer ID for a pair of SRC remote end UE and DST remote end UE.

[0067] Further examples of the present disclosure include signalling to configure SRAP (e.g., signalling to configure per-hop local ID, signalling for SRAP configuration, signalling a combination thereof etc.), and / or define an entity which performs the assignment (e.g., assignment of local IDs).

[0068] For example, with regards to the signalling to configure SRAP, if SRC remote end UE is an / the entity which configures the local ID(s) on each / all of the hops (or individual links), an exchange may be required between SRC remote end UE and each relay UE (e.g., each intermediate UE between SRC remote end UE and DST remote end UE) and between SRC remote end UE and DST remote end UE. Such exchange(s) may need to be performed before the local ID(s) is assigned. In various examples, the SRC remote end UE is configured to perform such exchange(s), as may be required. To this end, a permanent or global addressing may be provided to be used for the signalling configuration (e.g., the signalling to configure SRAP). In some examples, this permanent or global addressing may be performed (e.g., by the entity, such as the SRC remote end UE) before the SRAP layer is configured.

[0069] According to various examples (e.g., including a first set of examples), a method of signalling of local ID assignment (e.g., per-hop local ID assignment) may include, After a path (via one or more relays) from SRC remote end UE to DST remote end UE is discovered (e.g., determined, identified etc.), PC5 unicast link establishment is performed for each hop (e.g. SRC remote end UE to a relay UE, a relay UE to a next relay UE, the next relay UE to DST remote end UE, and vice versa for the other direction). During the PC5 unicast link establishment (which may be performed using PC5 RRC message) or just after the PC5 unicast link establishment (e.g., within a predetermined time period following PC5 unicast link establishment, or responsive to PC5 unicast link establishment being completed; and / or where the link establishment may be performed using PC5 RRC message), per-hop local ID assignment configuration may be performed over, or for, each link. In various examples, a similar arrangement (e.g., method) may be used for the case of global (or centralised) local ID assignment, except the parameter itself is different (e.g. the local ID itself s different). Methods according to these examples may apply both to the case of assignment by SRC UE / DST UE for each hop individually, and the assignment by SRC / DST remote end UE (for instance referring to the examples given above for these different cases of local ID configuration). It will be appreciated that there may be a difference in parameter details depending on the entity (e.g., SRC remote end UE or DST remote end UE) that assigns the local ID.

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

[0071] Accordingly, further to these examples, SRAP configuration signalling may be needed for bearers to be configured in a dedicated fashion. In a case of following legacy Rel-16 principle, then Tx UE (e.g., SRC UE) of each PC5 link decides the configuration depending on its RRC states (e.g. RRC signaling from gNB, gNB’s SIB, and / or UE’s pre-configuration) and sends the configuration to Rx UE (e.g., DST UE) of the PC5 link via PC5 RRC message. Even though less gNB involvement is considered for U2U relaying (than for the U2N relaying case), various examples of the present disclosure maintain, e.g., re-use, gNB’s SIB based or UE’s pre-configuration as methods for to provide SRAP configuration for U2U relaying to Tx UE of each PC5 link.

[0072] According to various examples disclosed herein, with regards to one-hop relaying, a relay UE may be configured in the role of SRAP configuration assignment (e.g., a / the relay UE is configured to be an / the entity assigning SRAP configuration for one or more other UEs, which may include itself) for each link (e.g. a link between SRC remote end UE and a relay UE, a link between DST remote end UE and relay UE). How the relay UE obtains or determines the SRAP configuration may follow the above Tx UE based approach. For example, a relay UE may, in the role of performing SRAP configuration assignment, decide / determine the SRAP configuration depending on its RRC states (e.g. based on or depending on RRC signaling from gNB, gNB’s SIB, and / or UE’s pre-configuration) and send the configuration to next relay UE of the PC5 link via PC5 RRC message.

[0073] It will be appreciated that this arrangement of a designated (i.e. one) relay UE’s SRAP configuration may be less efficient in the case of more than one hop (i.e., if the or a similar arrangement is extended to a two-or-more hop relay / system). Accordingly, various examples, with regards to two-or-more hop relaying, consider and provide that each relay UE of each link can take the role of SRAP configuration assignment for one direction; e.g., relay UE1: SRC remote end UE to relay UE 1, relay UE 2: relay UE1 to relay UE2, etc in the direction of SRC remote end UE to DST remote end UE. It will be appreciated that such an arrangement becomes similar to TX UE based approach. In other words: a first relay UE performs SRAP configuration assignment for the hop from SRC remote end UE to the first relay UE; a second relay UE performs SRAP configuration assignment for the hop from the first relay UE to the second relay UE; a third relay UE performs SRAP configuration assignment for the hop from the second relay UE to the third relay UE; and so on until the last relay UE (e.g., in the relay) which performs RAP configuration assignment for the hop from itself to the DST remote end UE. In some examples, each relay UE may, in the role of performing SRAP configuration assignment, decide / determine the SRAP configuration depending on its RRC states (e.g. RRC signaling from gNB, gNB’s SIB, and / or UE’s pre-configuration) and send the configuration to next relay UE of the PC5 link via PC5 RRC message.

[0074] According to various examples, a method of signalling local ID assignment configuration (e.g. for per-hop local ID) and SRAP configuration may include or provide a feature / detail that, according to the above individual example methods given for each signalling (e.g., referring to the first set of examples and the second set of examples mentioned above), the per-link (or per-hop) signalling by Tx UE or relay UE of each individual hop is appropriate for carrying both local ID and SRAP configuration together.

[0075] In other words, in various examples, the per-hop local ID and SRAP configuration are signalled via the same signalling. For instance, PC5 RRC message may be used. Alternatively, separate procedures can be used for each configuration, i.e., local ID configuration and SRAP configuration.

[0076] In various examples, if SRC L2ID (layer-2 ID) is updated for some privacy / security reason, the mapping of local ID and SRC L2ID may be updated. SRC L2ID update may be applied for E2E (e.g., SRC remote end UE to DST remote end UE) and / or for HBH (e.g. remote end 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 end remote UE ID) then the mapping between global local ID and SRC remote end UE ID may be maintained at all UEs (remote end UEs and relay UEs). In various examples, if a per-hop local ID is used or implemented based on E2E (e.g. SRC remote end UE ID) then the mapping between per-hop local ID and SRC remote end UE ID may be maintained at all UEs (remote end UEs and relay UEs). In various examples, if per-hop local ID is used or implemented based on HBH (e.g. SRC UE ID of each individual hop) then the mapping between per-hop local ID and SRC UE ID of each individual hop may be maintained at the corresponding two UEs of the hop. It will be appreciated that the HBH case may need more SRC UE ID update (e.g., performing of more updates) and so it may increase the local ID (re)mapping overhead in the case of multiple hops.

[0077] As mentioned above, it is possible to have a per-hop assignment, meaning that the Tx UE on each hop assigns the local ID, and not necessarily the case that the SRC (or DST) remote end UE assigning local IDs for all hops.

[0078] In other words, the assignor (e.g., of local ID) may be Tx UE of each hop (which may be regarded as SRC UE of each (or any) individual hop, where this does not mean only a SRC remote end UE), each (or any) relay UE toward DST remote end UE, each (or any) relay UE toward SRC remote end UE, Rx UE of each (or any) hop (which may be regarded as DST UE of each individual hop, where this does not mean only a DST remote end UE). For various of these examples, PC5 RRC message with local ID assignment configuration may be exchanged over the corresponding link.

[0079] In other examples, the assigner may be (a) SRC remote end UE or (b) DST remote end UE. In which case: for (a), SRC remote end UE may send each hop’s local ID to relay UE and DST remote end UE for a one-hop scenario, or, for (2), DST remote end UE may send each hop’s local ID to relay UE and SRC remote end UE for a one-hop scenario. For a one-hop scenario, the signalling overhead may be acceptable since it is not expected to be much different from the case of global ID assignment by SRC remote end UE or DST remote end UE. But for scenarios with more than one hop, the signalling may become greater when it is intended to deliver each hop’s local ID parameter over multiple hops (e.g., as may be performed in the case of per-hop local ID assignment).

[0080] An issue to consider for such examples is the link (if any) between local per-hop IDs on adjacent hops. The Rx UE of one hop becomes Tx UE for the next hop. On the next hop, the identifier(s) of the SRC remote end UE and DST remote end UE (e.g., {SRC remote end UE id, DST remote end UE id} may be different. This may not cause any issues / problems if each node has a mapping between: incoming ID, the identifier(s) of the SRC remote end UE and DST remote end UE (e.g. {SRC remote end UE, DST remote end UE} id), and outgoing ID. The savings in signaling (e.g., reduction in resource usage, such as network resources or computational resources) in this case would be smaller than for other examples discloses herein; being mainly reflected by (e.g. arising from) a smaller SRAP header, since the per-hop local ID can be quite small compared to an overall {end Remote SRC, end Remote DST} id.

[0081] Greater savings in signaling (e.g. reduction in resource usage for signalling) may arise from scenarios described further below, where it may not necessary to know or be aware of (e.g., for a given entity or entities, such as each or any relay UEs) the identifier(s) of the SRC remote end UE and DST remote end UE (e.g. {SRC remote end UE, DST remote end UE} id), but only necessary to know (e.g., be configured with, or have stored etc.) a mapping of incoming ID (e.g., local ID) to next hop UE (and, optionally, also the hop after the next hop), so that an appropriate outgoing ID (e.g., local ID) can be assigned (e.g., by a relay UE). This may save on configuration signalling since the identifier(s) of the SRC remote end UE and DST remote end UE (e.g. {SRC remote end UE, DST remote end UE} id) may not need to be known to each intermediate relay UE.

[0082] Accordingly, the intermediate Relay UE may not have to maintain “End Remote SRC UE L2 ID, End Remote DST UE L2 ID” (or the like) if a local ID and / or other information indicates the next hop information towards DST remote end UE and / or from SRC remote end UE.

[0083] Therefore, a Tx relay UE (or SRC remote end UE, and the very start of the chain (e.g., the first relay UE in the relay or path (i.e., the chain)) may store a table showing a next hop for a specific local ID (for example, this may be a single ID of the SRC / DST pair, such as the SRC / DST pair for the next hop).

[0084] For this, according to various examples of the disclosure, each Tx UE (e.g., each relay UE) may store a mapping between a local ID on the incoming hop and the hop after next the next hop - in other words, each Tx UE may identify (or consider) two hops in advance, not just one (assuming local configuration rather than centralized). As such, in one example, the SRC remote end UE may be configured with a table that shows identity of relay UE #2 for a given DST remote end UE (e.g., for a given path to the DST remote end UE). The SRC remote end UE chooses (e.g., selects, determines, identifies etc.) a local ID for the SRC remote end UE —► relay UE #1, where the chosen local ID will allow relay UE #1 to infer (e.g. from its own configuration table) that the next hop is to relay UE #2. Relay UE #1 may know (e.g., from its configuration table or from other stored information) that relay UE #3 is the following hop (after relay UE #2), so as to configure the local ID on the relay UE #1 -> relay UE #2. In other words, relay UE#1 may configure the local ID such that relay UE #2 will be able to infer that relay UE #3 is the following hop.

[0085] In a HBH scenario using a local ID which may change from hop to hop, each UE (remote end UE or relay UE) may, in some examples, take a role to assign local ID towards the next hop. Each such UE may store a mapping table (e.g., such as a configuration table described above) for routing. Such an HBH scenario relies on the following mapping: {incoming local ID, hop after next} —► {outgoing local ID, next hop relay}

[0086] According to various examples, one implementation is as follows: • SRC remote end UE has a mapping (e.g., in a stored mapping table or configuration table) between each DST (including DST remote end UE), and a local ID for the first hop. • Each relay UE has a mapping (e.g., in a stored mapping table or configuration table) between a local ID for the incoming hop, and the local ID for the upcoming hop, and may rewrite the SRAP header accordingly. o It will be appreciated that this may be a large table, and it may be simplified as follows: ■ All packets with the same hop after next use the same local ID; and ■ Incoming RLC channel indicates implicitly the hop after next. • The above approach may require some centralized configuration of mapping tables. • In some cases, configuration may be performed for smaller portions of network(s), and gateway nodes, which are essentially the destination address for the smaller network, may be provided or included. • In various examples, to allow for an entity (e.g., SRC remote end UE, relay UE etc.) to know / identify two hops in advance, a ‘sliding window’ may be implemented. By ‘sliding window’, reference is made to a method whereby each relay UE may identify (e.g., is aware of or knows) the next hop and the hop after next, where knowledge of the hop after the next hop may allow 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 will then enable the Rx relay UE on the first hop to know which relay UE should be the Rx relay UE on a next hop (e.g. a second hop). As will be appreciated, the Rx relay UE on the first hop becomes the Tx relay UE on the second hop - e.g., the ‘window’ slides or moves.

[0087] After assigning the local ID, the assignor may inform the local ID information (e.g., local ID and, optionally, its associated PC5 RLC channel and / or E2E bearer ID if needed) to the peer UE (for example, a UE to which the local ID relates, or a UE of the next hop). In some examples, different local IDs may be used on two adjacent hops, to identify the same (SRC, DST) pair. As such, the Rx relay UE (e.g. DST relay UE) may need to be able to interpret the local ID used by the Tx relay UE (e.g., SRC relay UE), and then may assign possibly a new local ID (e.g., for a next hop, for which the Rx relay UE will be the Tx UE relay), and may rewrite the SRAP header (if needed), so that the next relay UE (e.g., in the chain of UEs) can understand which (SRC, DST) pair the local ID refers to (as the next relay UE may have a different mapping between (SRC, DST) and local ID).

[0088] According to various examples of the present disclosure, a Tx UE may be inferred based on PC5 RLC channel. For instance, as mentioned above, part of information could be inferred based on ingress PC5 RLC channel. For example, ingress PC5 RLC channel may allow for SRC UE (e.g. Tx UE) identity, or a sub-network where the packet originates from or needs to go to, to be inferred. In another example, a specific (e.g. default, dedicated, specified etc.) ingress channel may be reserved for data coming from only one SRC (e.g., only one SRC UE), in which case it will be appreciated how information on the SRC (such as an identity of the SRC itself) may be inferred or determined based on the ingress channel. The specific ingress channel may also be associated with a specific E2E bearer, in which case it will be appreciated how information on the specific E2E bearer (such as an identity of the E2E bearer itself) may be determined or inferred based on the ingress channel. The specific ingress channel may also be mapped to only one egress channel, in which case it will be appreciated how the egress channel may be determined or inferred based on the ingress channel. In various examples, a number of PC5 RLC channels are provided to allow for a one-to-one mapping between PC5 RLC channels (on each hop) and each (SRC, DST) pair.

[0089] According to various examples of the present disclosure, if DST address (e.g., address of DST remote end UE, or address of a DST relay UE) is included in the SRAP header, it may be necessary to include more bits in the header (e.g., increase a size of a header) but the header may not need to be rewritten (e.g., perhop). The use of local ID, according to an example described herein, allows for a smaller number of bits, because not all (SRC, DST) pairs will be sent via all links or sub-networks so the applicable number of pairs is lower than at the level of the entire U2U network. However, header rewriting may be needed when local ID is implemented. In various examples, header rewriting may not be required on every hop; some local IDs may be shared within sub-networks (e.g. for packets pertaining to different (SRC, DST) pairs but which traverse at least in part the same route and could therefore share the same local ID).

[0090] Figure 2 illustrates a method according to various examples of the present disclosure.

[0091] The method may be performed by an entity - e.g., a first entity - which is included in a communications network that includes a plurality of entities, which may in turn include the first entity. The plurality of entities may also include a SRC end entity, at least one intermediate entity and a DST end entity.

[0092] It will be appreciated that, in various examples, the SRC end entity is a SRC end UE, the DST end entity is a DST end UE, and the at least one intermediate entity are each a different relay UE (or intermediate UE). Further, the first entity may be any of the SRC end entity, the DST end entity or one of the at least one intermediate entity, or may be another entity (such as a base station (e.g., gNB) or a part of a network - e.g., a core network to which one of the SRC end UE, the DST end entity is a DST end UE, and the at least one intermediate entity is connected).

[0093] In operation 201, the first entity may obtain information on the plurality of entities. In a case where the information is obtained by receiving the information, it will be understood that information is not received from the first entity of the plurality of entities. The information may be received from each of the plurality of entities (excluding the first entity), or may be received from one or a subset of entities from the plurality of entities (excluding the first entity) such as an entity in direct communication with the first entity, or may be received from an entity outside of the plurality of entities (such as a base station, or network).

[0094] As described in various examples herein, the obtaining of this information may correspond to (e.g., be part of or associated with) a discovery procedure. For example, the information may be obtained for a direction from the SRC end entity to the DST end entity and for a direction from the DST end entity to the SRC end entity, where the information may include details or information on each entity between the end entities. The information may also include an indication of a path (e.g., obtained by the first entity by determining, based on another part of the information obtained in operation 201, a path from SRC end entity to DST end entity or a path from DST end entity to SRC end entity). Again, details of such a path may correspond to those given in other examples disclosed herein.

[0095] In operation 203, the first entity configures (or allocates, assigns, processes, generates, identifies, determines etc.) one or more identifier(s), where each identifier (or, if only one identifier is configured, the identifier) indicates a pair of entities from among the plurality of entities.

[0096] It will be appreciated that this operation may, in various examples, be according to (e.g., share feature(s) with) any of the examples disclosed herein in relation to allocating, configuring, generating etc. an ID or local ID for a pair of entities (e.g., UEs, such as a SRC UE and an end UE, or a Tx UE and a Rx UE).

[0097] For example, each pair of entities includes a SRC entity and a DST entity for a hop in the communication network. That is, if a path includes a number of hops from the SRC end entity to the DST end entity, a pair of entities corresponding to each hop will include a SRC entity (e.g. a Tx entity that transmits a packet) and a DST entity (e.g. a Rx entity that receives the packet). In the case of a one-hop scenario, there may be one intermediate entity and the path may include two hops - a first hop corresponding to SRC end entity (as SRC entity) and the one intermediate entity (As DST entity), and a second hop corresponding to the one intermediate entity (as SRC entity) and the DST end entity (as DST entity). In a case of a N-hop scenario (where N is two or more), there may be N intermediate entities and the path may include N hops - a first hop corresponding to the SRC end entity (as SRC entity) and a first intermediate entity (as DST entity), a second hop corresponding to the first intermediate entity (as SRC entity) and a second intermediate entity (as DST entity) etc. up to an (N-1)th hop corresponding to the (N-1)th intermediate entity (as SRC entity) and the Nth intermediate entity (as DST entity), and an Nth hop corresponding to the Nth intermediate entity (as SRC entity) and the DST end entity (as DST entity). In some cases, no pair (i.e., none of the pairs) of entities may include both SRC end entity and DST end entity - a path will include at least one intermediate entity between SRC end entity and DST end entity. However, in other cases, a path may proceed from SRC end entity to DST end entity and then from DST end entity to an intermediate entity, in which case a pair may include SRC end entity and DST end entity.

[0098] In various examples, the at least one intermediate entity may be arranged between the SRC end entity and the DST end entity, in the sense of each entity being communicably connected (e.g., in direct connection, as in may directly transmit to and receive from) at least one other entity. In some cases, the SRC end entity and the DST end entity are not communicably connected (e.g., not capable of direct communication with one another at a current time or in a current location) and so communications between the SRC end entity and the DST end entity are via the at least one intermediate entity (or a subset thereof corresponding to a path between the end entities). Similarly, each intermediate entity may not be communicably connected with every other intermediate entity but instead are may only be communicably connected to a subset of the at least one intermediate entities, meaning communication between two intermediate entities not communicably connected is via one or more other intermediate entities.

[0099] In various examples, the configuring may relate to configuring a SRAP configuration, a local ID or a SRAP header. In some examples, the configuring may comprise configuring a local ID on a per-hop basis for each hop from the SRC end entity to / from the DST end entity. In further examples, a configured local ID may be included in a header of a packet for sending to a next entity (e.g., corresponding to a next hop). Again, reference is made to the discussion / examples given herein regarding SRAP configuration, local ID configuration and SRAP header configuration, and to the signalling thereof.

[00100] In operation 205, the first entity may transmit or provide at least one of the one or more configured identifier(s) to at least one of the plurality of entities. It will be appreciated that this excludes the first entity as the first entity already has knowledge of the one or more identifies.

[00101] This operation may, in various examples, be according to (e.g., share feature(s) with) any of the examples disclosed herein in relation to signalling, such as the signalling of SRAP configuration, SRAP header, and / or local ID etc. For example, after a path from SRC end entity to DST end entity is discovered, PC5 unicast link establishment is performed for each hop (e.g. SRC end entity to an intermediate entity, an intermediate entity to a next intermediate entity, the next intermediate entity to DST end entity, and vice versa for the other direction). In such examples, during the PC5 unicast link establishment (which may be performed using PC5 RRC message) or just after the PC5 unicast link establishment (e.g., within a predetermined time period following PC5 unicast link establishment, or responsive to PC5 unicast link establishment being completed; and / or where the link establishment may be performed using PC5 RRC message), per-hop local ID assignment configuration may be performed over, or for, each link, where the one or more identifiers (e.g., local ID) are signalled to the other entities of the plurality of entities (or to a subset thereof).

[00102] It will be appreciated that examples of the present disclosure also include methods in which one or more of operations 201, 203, 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.

[00103] Figure 3 illustrates a method according to various examples of the present disclosure.

[00104] The method may be performed by an entity - e.g., a second entity - which is included in a communications network that includes a plurality of entities, which may in turn include the second entity. The plurality of entities may also include a SRC end entity, at least one intermediate entity and a DST end entity.

[00105] It will be appreciated that, in various examples, the SRC end entity is a SRC end UE, the DST end entity is a DST end UE, and the at least one intermediate entity are each a different relay UE (or intermediate UE). Further, the second entity may be any of the SRC end entity, the DST end entity or one of the at least one intermediate entity.

[00106] Further, a path in the communications network from SRC end entity to DST end entity may include a number of hops from the SRC end entity to the DST end entity, where a pair of entities corresponding to each hop will include a SRC entity (e.g. a Tx entity that transmits a packet) and a DST entity (e.g. a Rx entity that receives the packet). In the case of a one-hop scenario, there may be one intermediate entity and the path may include two hops - a first hop corresponding to SRC end entity (as SRC entity) and the one intermediate entity (As DST entity), and a second hop corresponding to the one intermediate entity (as SRC entity) and the DST end entity (as DST entity). In a case of a N-hop scenario (where N is two or more), there may be N intermediate entities and the path may include N hops -a first hop corresponding to the SRC end entity (as SRC entity) and a first intermediate entity (as DST entity), a second hop corresponding to the first intermediate entity (as SRC entity) and a second intermediate entity (as DST entity) etc. up to an (N-1)th hop corresponding to the (N-1)th intermediate entity (as SRC entity) and the Nth intermediate entity (as DST entity), and an Nth hop corresponding to the Nth intermediate entity (as SRC entity) and the DST end entity (as DST entity). In some cases, no pair (i.e., none of the pairs) of entities may include both SRC end entity and DST end entity - a path will include at least one intermediate entity between SRC end entity and DST end entity. However, in other cases, a path may proceed from SRC end entity to DST end entity and then from DST end entity to an intermediate entity, in which case a pair may include SRC end entity and DST end entity.

[00107] In operation 301, the second entity may receive, from a first entity included in the plurality of entities, information including a first identifier indicating a first pair comprising the first entity and the second entity.

[00108] This operation may, in various examples, be according to (e.g., share feature(s) with) any of the examples disclosed herein in relation to signalling, or in relation to SRAP header, SRAP configuration and / or local ID. For example, the information may be included in a SRAP header, where the first identifier may be a local ID corresponding to the first entity and the second entity. The first identifier may have been configured by the first entity or another entity. The information may further include information allowing the second entity to identify or determine a next entity to transmit to.

[00109] In operation 303, the second entity may receive a packet from the first entity. In some examples, the receiving of the information is together with the receiving of the packet, in that the information may be included in the packet or in part of the transmission comprising the packet. For example, the information may be included in a SRAP header of the packet. The packet may include data or information being sent from the entity at the beginning of the path (e.g. ,SRC end entity) to the entity at the end of the path (e.g. DST end entity).

[00110] In operation 305, the second entity may transmit the packet to a third entity based on the first identifier and / or the information (that is, other information included in the information). For example, based on the 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, the information may indicate an entity (e.g., a fourth entity) to receive the packet in a hop after the next hop. From this, the second entity may infer that the third entity is the DST entity of the next hop such that the third entity may then forward the packet to the fourth entity in the hop after the next hop.

[00111] It will be appreciated that operation 305 various examples, be according to (e.g., share feature(s) with) any of the examples disclosed herein in relation to one entity (e.g., a relay UE) forwarding on a packet and / or local ID information to a next entity in the path (e.g., another relay UE, being DST or Rx relay). For example, the one entity may be provided with knowledge of the destination of the packet for a hop after the next hop, allowing for the destination of the next hop to be inferred. For example, the second entity may rewrite a SRAP header of the received packet prior to transmitting the packet with the rewritten SRAP header to the third entity, where the rewritten SRAP header will provide the third entity with information on where the forward the packet (or, if the third entity is the intended destination for the packet (e.g., DST end entity), the rewritten SRAP header may inform the third entity that it is the destination and so to pass the packet to higher layers). Such features may be supported through the use of configuration table(s) or mapping table(s) (e.g., stored at the second entity and / or third (or other) entity / entities).

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

[00113] It will be appreciated that examples of the present disclosure also include methods in which one or more of operations 301, 303, 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.

[00114] Figure 4 is a block diagram of an exemplary apparatus, or entity, that may be used in examples of the present disclosure. The skilled person will appreciate said entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and / or as a virtualised function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[00115] The entity 1000 comprises a processor (or controller) 1001, a transmitter 1003 and a receiver 1005. The receiver 1005 is configured for receiving one or more messages from one or more other entities, for example as described above. The transmitter 1003 is configured for transmitting one or more messages to one or more other entities, for example as described above. The processor 1001 is configured for performing one or more operations, for example according to the operations as described above.

[00116] In accordance with a first aspect of the present disclosure, there is provided a first entity in a communication system, wherein the communication system comprises a plurality of entities including the first entity, and the first entity comprises: a transmitter; and a controller configured to: configure one or more identifier(s) each arranged to indicate a pair of entities from among the plurality of entities; wherein the plurality of entities comprises a source, SRC, end entity, at least one intermediate entity and a destination, DST, end entity; wherein each pair of entities includes a SRC entity and a DST entity communicably connected with the SRC entity, and no pair of entities includes both SRC end entity and DST end entity.

[00117] According to various examples, each pair of entities comprises either: one of the SRC end entity or the DST end entity, and one of the at least one intermediate entity; or if the plurality of entities comprises at least two intermediate entities, a different two of the at least two intermediate entities.

[00118] According to various examples, a first pair of entities comprises the SRC end entity and a first intermediate entity communicably connected with the SRC entity; and a second pair of entities comprises a second intermediate entity and the DST end entity communicably connected with the second intermediate entity.

[00119] According to various examples, if the plurality of entities comprises only one intermediate entity, the first intermediate entity is the second intermediate entity; if the plurality of entities comprises at least two intermediate entities, the second intermediate entity is different from the first intermediate entity, and a third pair of entities comprises the first intermediate entity and the second intermediate entity communicably connected with the first intermediate entity; and / or if the plurality of entities comprises at least three intermediate entities, the second intermediate entity is different from the first intermediate entity, a third pair of entities comprises the first intermediate entity and a third intermediate entity communicably connected with the first intermediate entity, and a fourth pair of entities comprises the third intermediate entity and the second intermediate entity communicably connected with the third intermediate entity.

[00120] According to various examples, if a plurality of 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 the pair of entities indicated by the configured indicator.

[00121] According to various examples, wherein the controller is configured to: transmit the one or more identifier to at least one of the plurality of entities excluding the first entity.

[00122] According to various examples, the controller is configured to obtain information on the plurality of entities excluding the first entity, and configure the one or more identifier based on the received information.

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

[00124] According to various examples, the controller is configured to transmit, to the at least one entity, configuration information including the one or more identifier, the identifier of the SRC entity and the identifier of the DST end entity, and information on a channel between the SRC entity and the DST entity.

[00125] According to various examples, the channel is a PC5 RLC channel, and the information comprises information on egress PC5 RLC channel and / or information on ingress PC5 RLC channel.

[00126] According to various examples, a shared identifier is used for the identifier of the SRC end entity and the identifier of the DST end entity.

[00127] According to various examples, a configured identifier corresponding to a pair of entities further indicates a next entity communicably connected with the DST entity of the pair of entities.

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

[00129] According to various examples, the DST entity is communicably connected to the SRC entity such the SRC entity and the DST entity are in direct communication.

[00130] In accordance with a second aspect of the present disclosure, there is provided a second entity in a communication system, wherein the communication system comprises a plurality of entities including the second entity, and the second entity comprises: a receiver; a transmitter; and a controller configured to: receive, from a first entity among the plurality of entities, information including a first identifier indicating a first pair comprising the first entity and the second entity; receive, from the first entity, a packet; and transmit the packet to a third entity based on the first identifier; wherein the plurality of entities comprises 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 a SRC entity communicably connected with the DST entity.

[00131] According to various examples, the information includes a second identifier indicating the SRC end entity and the DST end entity.

[00132] According to various examples, the controller is configured to: configure a third identifier indicating a second pair comprising the second entity and the third entity based on the information; and transmit the third identifier to the third entity.

[00133] According to various examples, the information includes an indication of a fourth entity configured to receive a transmission from the 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.

[00134] According to various examples, the first identifier and the second identifier are received in a 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 on a channel between the second entity and the third entity, and transmit the rewritten header as the third identifier.

[00135] According to various examples, the channel is a PC5 RLC channel, and the information comprises information on egress PC5 RLC channel and / or information on ingress PC5 RLC channel.

[00136] According to various examples, the header is a sidelink relay adaptation protocol, SRAP, header processed by a SRAP layer at the second entity; and / or wherein the information is included in a header of the packet.

[00137] According to various examples, the controller is configured to: receive, from the first entity, a third identifier indicating a second pair comprising the second entity and the third entity; and transmit the third identifier to the third entity.

[00138] According to various examples, the second entity is one of the 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.

[00139] In accordance with a third aspect of the present disclosure, there is provided a method of a first entity in a communication system, wherein the communication system comprises a plurality of entities including the first entity, and the method comprising: configuring one or more identifier(s) each arranged to indicate a pair of entities from among the plurality of entities; wherein the plurality of entities comprises a source, SRC, end entity, at least one intermediate entity and a destination, DST, end entity; and wherein each pair of entities includes a SRC entity and a DST entity communicably connected with the SRC entity, and no pair of entities includes both SRC end entity and DST end entity.

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

[00141] According to a fourth aspect of the present disclosure, there is provided a method of a second entity in a communication system, wherein the communication system comprises a plurality of entities including the second entity, the method comprising: receiving, from a first entity among the plurality of entities, information including a first identifier indicating a first pair comprising the first entity and the second entity; receiving, from the first entity, a packet; and transmitting the packet to a third entity based on the first identifier; wherein the plurality of entities comprises 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 a SRC entity communicably connected with the DST entity.

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

[00143] Additionally, it will be appreciated that the present disclosure includes examples whereby the first entity described above (according to the first aspect and associated various examples above) is further configured to perform any one or more operation, feature etc. disclosed herein in relation to configuring and / or signalling a SRAP header, SRAP configuration and / or local ID. That is, the present disclosure also includes examples in which the first entity according to the first aspect is configured in the role of per-hop (or otherwise, e.g. global) local ID allocator such as described elsewhere herein.

[00144] Similarly, it will be appreciated that the present disclosure includes examples whereby the second entity described above (according to the second aspect and associated various examples above) is further configured to perform any one or more operation, feature etc. disclosed herein in relation to receiving, configuring and / or signalling a SRAP header, SRAP configuration and / or local ID. That is, the present disclosure also includes examples in which the second entity according to the second aspect is configured in the role of per-hop (or otherwise, e.g. global) local ID allocator such as described elsewhere herein, or is configured to rewrite a header of a received packet to include ID (e.g., local ID) for the next hop (and / or a hop after the next hop) to allow the DST (Rx) entity for the next hop to identify a destination for the packet etc.

[00145] It will be appreciated that, in each example / embodiment / aspect etc. described above, one or more features or operations may be omitted, modified or moved (e.g., to change the order of the features or the operations), if desired and appropriate. Additionally, one or more features or operations from any example / embodiment may be combined with features or operations from any other example / embodiment. In particular, regardless of whether or not a pointer towards a combination of features / examples is found herein, the present 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.

[00146] The techniques described herein may be implemented using any suitably configured apparatus and / or system. Such an apparatus and / or system may be configured to perform a method according to any aspect, embodiment or example disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and / or method steps for implementing the techniques described herein. For example, an operation / function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software.

[00147] It will be appreciated that examples of the present disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like.

[00148] It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment and / or aspect disclosed herein, and / or a machine-readable storage storing such a program. Still further, such programs may 5 be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection.

[00149] While the present disclosure has been shown, illustrated and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the 10 scope of the disclosure.

[00150] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. 15 Acronyms and Definitions (as may be used herein) 3GPP 3rd Generation Partnership Project NTN Non-Terrestrial Network 5G 5th Generation NW Network 5GC 5G Core NWDAF Network Data Analytics Function 5QI 5G QoS Identifier QAM Operations, Administration and 5GS 5G System Maintenance 5GSM 5G System Session Management PCF Policy Control Function 5GMM 5G System Mobility Management PCC Policy and Charging Control AF Application Function PCO Protocol Configuration Options Al Artificial Intelligence PDR Packet Detection Rule AIML Artificial Intelligence / Machine PDU Protocol Data Unit Learning PMF Performance Measurement Function AM Acknowledged Mode PSA PDU session anchor AMF Access and Mobility Management QFI QoS Flow Identifier (ID) Function QoE Quality of Experience AS Application Server QoS Quality of Service ASP Application Service Provider RA Registration Area ATSSS Access Traffic Steering Switching RACH Random Access Channel & Splitting RAN Radio Access Network CDRX Connected Mode Discontinuous RAT Radio Access Technology Reception RLC-AM Radio Link Control Acknowledge CSI Channel Status Information Mode DCAF Data Collection Application RLC-UM Radio Link Control Unacknowledge Function Mode DNN Data Network Name RRC Radio Resource Control DNS Domain Name Server SA Standalone DRB Data Radio Bearer SBA Service-Based Architecture DRX Discontinuous Reception SBI Service-Based Interface eNB Evolved Node B SCEF Service Capability Exposure Function EPS Evolved Packet System SCP Service-Based Communication Proxy FQDN Fully Qualified Domain Name SCTP Stream Control Transmission GBR Guaranteed Bit Rate Protocol gNB Next generation Node B SDAP Service Data Adaptation Protocol GNSS Global Navigation Satellite System SDU Service Data Unit GPSI Generic Public Subscription SIM Subscriber Identity Module Identifier SLA Service Level Agreement Hbh Hop-by-hop SM Session Management IAB Integrated Access and Backhaul SMF Session Management Function ID Identity / ldentifier SN Secondary Node loT Internet of Things S-NSSAI Single Network Slice Selection IMEI International Mobile Equipment Assistance Information Identities SSB Synchronization Signal Block IP Internet Protocol SSC Session and Service Continuity l-SMF Intermediate SMF SUPI Subscription Permanent Identifier LMF Location Management Function TA Tracking Area MA-PDU Multiple Access PDU TAI Tracking Area Identity ML Machine Learning TE Terminal Equipment MME Mobility Management Entity TM Transparent Mode MN Master Node TS Technical Specification MNO Mobile Network Operator UDM Unified Data Manager MT Mobile Termination UDR Unified Data Repository NAS Non-Access Stratum UE User Equipment NB Narrowband UL Uplink NRF Network Repository Function UM Unacknowledged Mode NG-RAN Next Generation Radio Access UP User Plane Network UPF User Plane Function NG-eNB Next Generation eNB URLLC Ultra-Reliable and Low-Latency NSA Non-Standalone Communication NS-AoS Network Slice Area of Service URSP UE Route Selection Policy NSSAI Network Slice Selection Assistance Information

Claims

1. A first entity in a communication system, wherein the communication system comprises a plurality of entities including the first entity, the first entity comprising:a transmitter; anda controller configured to:configure one or more identifier(s) each arranged to indicate a pair of entities from among the plurality of entities;wherein the plurality of entities comprises a source, SRC, end entity, at least one intermediate entity and a destination, DST, end entity;wherein each pair of entities includes a SRC entity and a DST entity communicably connected with the SRC entity, and no pair of entities includes both SRC end entity and DST end entity.

2. The first entity of claim 1, wherein each pair of entities comprises either:one of the SRC end entity or the DST end entity, and one of the at least one intermediate entity; orif the plurality of entities comprises at least two intermediate entities, a different two of the at least two intermediate entities.

3. The first entity of claim 1 or 2, wherein:a first pair of entities comprises the SRC end entity and a first intermediate entity communicably connected with the SRC entity; anda second pair of entities comprises a second intermediate entity and the DST end entity communicably connected with the second intermediate entity.

4. The first entity of claim 3, wherein:if the plurality of entities comprises only one intermediate entity, the first intermediate entity is the second intermediate entity;if the plurality of entities comprises at least two intermediate entities, the second intermediate entity is different from the first intermediate entity, and a third pair of entities comprises the first intermediate entity and the second intermediate entity communicably connected with the first intermediate entity; and / orif the plurality of entities comprises at least three intermediate entities, the second intermediate entity is different from the first intermediate entity, a third pair of entities comprises the first intermediate entity and a third intermediate entity communicably connected with the first intermediate entity, and a fourth pair of entities comprises the third intermediate entity and the second intermediate entity communicably connected with the third intermediate entity.

5. The first entity of any previous claim, wherein:if a plurality of identifiers are configured, each identifier uniquely corresponds to each pair; orif only one identifier is configured, the first entity is the SRC entity in the pair of entities indicated by the configured indicator.

6. The first entity of any previous claim, wherein the controller is configured to: transmit the one or more identifier to at least one of the plurality of entities excluding the first entity.

7. The first entity of any previous claim, wherein the controller is configured to obtain information on the plurality of entities excluding the first entity, and configure the one or more identifier based on the received information.

8. The first entity of any previous claim, wherein the controller is configured to transmit an identifier of the SRC end entity and an identifier of the DST end entity to at least one entity in the plurality of entities.

9. The first entity of claim 8, wherein the controller is configured to transmit, to the at least one entity, configuration information including the one or more identifier, the identifier of the SRC entity and the identifier of the DST end entity, and information on a channel between the SRC entity and the DST entity.

10. The first entity of claim 9, wherein the channel is a PC5 RLC channel, and the information comprises information on egress PC5 RLC channel and / or information on ingress PC5 RLC channel.

11. The first entity of any of claims 8 to 10, wherein a shared identifier is used for the identifier of the SRC end entity and the identifier of the DST end entity.

12. The first entity of any previous claim, wherein a configured identifier corresponding to a pair of entities further indicates a next entity communicably connected with the DST entity of the pair of entities.

13. The first entity of any previous claim, wherein the first entity is the SRC end entity, one of the at least one intermediate entities or a base station; and / orwherein each of the plurality of entities is a different user equipment, UE.

14. The first entity of any previous claim, wherein the DST entity is communicably connected to the SRC entity such the SRC entity and the DST entity are in direct communication.

15. A second entity in a communication system, wherein the communication system comprises a plurality of entities including the second entity, the second entity comprising:a receiver;a transmitter; anda controller configured to:receive, from a first entity among the plurality of entities, information including a first identifier indicating a first pair comprising the first entity and the second entity;receive, from the first entity, a packet; andtransmit the packet to a third entity based on the first identifier;wherein the plurality of entities comprises a source, SRC, end entity, at least one intermediate entity and a destination, DST, end entity; andwherein, in the first pair, the third entity is a DST entity and the second entity is a SRC entity communicably connected with the DST entity.

16. The second entity of claim 15, wherein the information includes a second identifier indicating the SRC end entity and the DST end entity.

17. The second entity of claim 16, wherein the controller is configured to:configure a third identifier indicating a second pair comprising the second entity and the third entity based on the information; andtransmit the third identifier to the third entity.

18. The second entity of claim 17, wherein the information includes an indication of a fourth entity configured to receive a transmission from the third entity; andwherein the controller is configured to configure the third identifier based on the first identifier, the second identifier and the indication of the fourth entity.

19. The second entity of claim 18, wherein the first identifier and the second identifier are received in a header; andthe controller is configured to rewrite the header to configure the third identifier, based on the first identifier, the second identifier and information on a channel between the second entity and the third entity, and transmit the rewritten header as the third identifier.

20. The second entity of claim 19, wherein the channel is a PC5 RLC channel, and the information comprises information on egress PC5 RLC channel and / or information on ingress PC5 RLC channel.

21. The second entity of claim 19 or claim 20, wherein the header is a sidelink relay adaptation protocol, SRAP, header processed by a SRAP layer at the second entity; and / orwherein the information is included in a header of the packet.

22. The second entity of claim 15 or claim 16, wherein the controller is configured to:receive, from the first entity, a third identifier indicating a second pair comprising the second entity and the third entity; andtransmit the third identifier to the third entity.

23. The second entity of any of claims 15 to 22, wherein the second entity is one of the at least one intermediate entity;wherein each of the plurality of entities is a different user equipment, UE; and / orwherein each intermediate entity is a different relay UE.

24. A method of a first entity in a communication system, wherein the communication system comprises a plurality of entities including the first entity, the method comprising:configuring one or more identifier(s) each arranged to indicate a pair of entities from among the plurality of entities;wherein the plurality of entities comprises a source, SRC, end entity, at least one intermediate entity and a destination, DST, end entity; andwherein each pair of entities includes a SRC entity and a DST entity communicably connected with the SRC entity, and no pair of entities includes both SRC end entity and DST end entity.

25. A method of a second entity in a communication system, wherein the communication system comprises a plurality of entities including the second entity, the method comprising:receiving, from a first entity among the plurality of entities, information including a first identifier indicating a first pair comprising the first entity and the second entity;receiving, from the first entity, a packet; andtransmitting the packet to a third entity based on the first identifier;wherein the plurality of entities comprises a source, SRC, end entity, at least one intermediate entity and a destination, DST, end entity; andwherein, in the first pair, the third entity is a DST entity and the second entity is a SRC entity communicably connected with the DST entity.

Images