Patent Description:
In Release <NUM> (Rel-<NUM>) and Release <NUM> (Rel-<NUM>) of the 3rd Generation Partnership Program (3GPP), extensions for device-to-device (D2D) communication were aimed at supporting vehicle-to-everything (V2X) communication, which includes any combination of direct communication between vehicles, pedestrians and infrastructure. V2X communication may take advantage of a network (NW) infrastructure, when available, but at least basic V2X connectivity may be possible even in case of lack of coverage of the NW. Providing a Long Term Evolution (LTE)-based V2X interface may be economically advantageous because of the LTE economies of scale and it may enable tighter integration between communications with the NW infrastructure (vehicle-to-infrastructure, V2I, or vehicle-to-network, V2N), pedestrian (vehicle-to-pedestrian, V2P) and other vehicles (vehicle-to-vehicle, V2V), as compared to using a dedicated V2X technology such as defined by IEEE <NUM>.

V2X communications may carry both non-safety and safety information, where each of the applications and services may be associated with specific requirement sets, e.g., in terms of latency, reliability or data rates.

There are several different use cases for V2X using LTE:.

The 3GPP SA1 working group specified new service requirements for future V2X services in the work item FS_eV2X. In total, <NUM> use cases have been identified for advanced V2X services which will be used in <NUM> (i.e., at least one of LTE and new Radio (NR)). Such use cases are categorized into four use case groups: vehicle platooning, extended sensors, advanced driving and remote driving. Direct unicast transmission over sidelink will be needed in some use cases such as platooning, cooperative driving and dynamic ride sharing. For these advanced applications, the expected requirements to meet the needed data rate, capacity, reliability, latency, communication range and speed are more stringent. The consolidated requirements for each use case group are captured in 3GPP TR <NUM>.

National Security and Public Safety (NSPS) is considered one important use case, which may benefit from NR sidelink features developed in 3GPP Release <NUM>. In some scenarios, such as indoor firefighting, forest firefighting, earthquake rescue, and sea rescue, NSPS services need to operate with partial or without NW coverage, for example because the infrastructure is (e.g., partially) destroyed or not available. Therefore, coverage extension may be advantageous for NSPS, in particular, for both NSPS services communicated between a user Equipment (UE) and a cellular NW and that communicated between UEs over sidelink. Coverage extension for sidelink-based communication, including both UE to NW relay for cellular coverage extension and UE to UE relay for sidelink coverage extension may thus be advantageous.

In a system comprising a UE or another wireless mobile terminal, and a network node (NN), the NN should be informed of capabilities of the UE in order to provide the right configurations so that a connection between the UE and the NN can be established or reconfigured properly. This may lead to coverage extension.

In a sidelink relay scenario, according to current state of the art, a remote communication unit (RMCU) does not have any possibility to report its capabilities to the NN or the network since, generally, there is no direct path or RRC connection between the RMCU and the NN. Therefore, since no capabilities of the RMCU are known on the network side, a relay path connectivity cannot be established or can be established only with a default configuration, and no service requirements can be guaranteed.

Document <CIT> may be construed to disclose a system and method for device-to-device (D2D) communication that includes detecting, by a transmitting user equipment (UE) of a plurality of UEs, a sidelink type of a receiving UE of the plurality of UEs, the sidelink type used by the receiving UE to communicate on a discovery channel, determining, by the transmitting UE, a pool of resources for an air interface supported by the receiving UE and the transmitting UE, selecting, by the transmitting UE, transmission resources from the pool of resources according to the sidelink type of the receiving UE, indicating, by the transmitting UE, the transmission resources to the receiving UE over the discovery channel, and communicating, by the transmitting UE, directly with the receiving UE using the transmission resources.

There is a need for a technique that provides an efficient procedure for capability exchange of a remote communication unit, RMCU, in sidelink relay scenarios.

According to the present disclosure, there are provided methods, an RLCU, an RMCU, an NN and a computer program according to the independent claims. Further developments are set forth in the dependent claims.

According to a first aspect, there is provided a method of informing a network node, NN, of a network about at least one sidelink-related radio access capability of a remote communication unit, RMCU, to enable configuring a relay path between the RMCU and the NN via a relay communication unit, RLCU, connected to the NN. The method is performed by the RLCU and comprises receiving, from the RMCU, first capability information indicative of at least one sidelink-related radio access capability of the RMCU, and transmitting the first capability information to the NN.

For example, the sidelink is based on a PC5 interface of the RMCU. The at least one sidelink-related radio access capability of the RMCU may identify a sidelink interface of the RMCU, for example the PC5 interface of the RMCU. Alternatively or additionally, the at least one sidelink-related radio access capability of the RMCU may comprise a capability of the RMCU for establishing a sidelink connection to the RLCU connected to the NN of the network. The at least one sidelink-related radio access capability of the RMCU for example comprises a capability of the RMCU for establishing a relay path over a sidelink interface (e.g., the PC5 interface) of the RMCU, for example a relay path between the RMCU and the NN via the RLCU. The relay path between the RMCU and the NN via the RLCU may comprise a first connection between the RMCU and the RLCU and a second connection between the RLCU and the NN, wherein the first connection is established over a sidelink interface (e.g., the PC5 interface) of the RMCU and, optionally, over a sidelink interface (e.g., a PC5 interface) of the RLCU.

The method may further comprise transmitting, to the NN, second capability information indicative of at least one relay capability of the RLCU together with the first capability information. The at least one relay capability of the RLCU may comprise a capability of the RLCU to establish a sidelink communication (e.g., via the PC5 interface of the RLCU) to the RMCU. The at least one relay capability of the RLCU may comprise a capability of the RLCU to establish a relay path between the RMCU and the NN via the RLCU, for example using at least one interface chosen from a sidelink interface (e.g., the PC5 interface) of the RMCU and a sidelink interface (e.g., the PC5 interface) of the RLCU.

When it is generally referred to "capability information" herein, it is to be understood that at least one of the first capability information and the second capability information is meant. In one particular variant, only the first capability information is meant whenever it is generally referred to "capability information" herein.

For example, the capability information is transmitted to the NN within at least one RRC message.

In a first variant, the capability information is transmitted to the NN within a single message. Two or more of the at least one capability indicated by the capability information may be included in a same information element of the single message. Alternatively or additionally, two or more of the at least one capability indicated by the capability information may be included in separate information elements of the single message.

In a second variant, the capability information is transmitted to the NN in a plurality of messages, each of the plurality of messages comprising information indicative of only one of the at least one capability indicated by the capability information.

The capability information, before being transmitted to the NN, may be enriched by the RLCU with a first index assigned to the at least one capability indicated by the capability information, the first index associating the at least one capability indicated by the capability information with the communication unit having the at least one capability. For example, the first index is one of generated by the RLCU and obtained from the NN or a core of the network. In one example, the first index is a predefined index.

The RLCU may store a mapping between the at least one capability indicated by the capability information and at least one of a type and a unique identifier of the communication unit having the at least one capability, wherein the method may further comprise determining the first index based on the mapping.

The RLCU may stores a mapping between the at least one capability indicated by the capability information and at least one of a type and a unique identifier of the communication unit having the at least one capability, wherein the method may further comprise transmitting the mapping to the NN.

The method in one example further comprises receiving, from the NN, first configuration information indicative of a first relay path configuration for a relay path between the RMCU and the NN via the RLCU, and transmitting the first configuration information to the RMCU.

The first configuration information may be at least one of received and transmitted by the RLCU in an RRC message.

The method for example further comprises determining, based on a second index comprised in the first configuration information and associating the first relay path configuration with the RMCU, that the first relay path information is intended for the RMCU, wherein the first configuration information may be transmitted to the RMCU only if it is determined that it is intended for the RMCU.

The RLCU may store a mapping between the at least one capability indicated by the capability information and at least one of a type and a unique identifier of the communication unit having the at least one capability, and determine that the first relay path is intended for the RMCU further based on the mapping.

The method may further comprise receiving, from the NN, rejection information indicative of the NN not determining a first relay path configuration for a relay path between the RMCU and the NN via the RLCU, and transmitting the rejection information to the RMCU. The rejection information is for example at least one of received and transmitted by the RLCU in an RRC message.

The method in one example further comprises determining, based on a second index comprised in the rejection information and associating the rejection information to the RMCU, that the rejection information is intended for the RMCU, wherein the rejection information may be transmitted to the RMCU only if it is determined that it is intended for the RMCU.

The RLCU may store a mapping between the at least one capability indicated by the capability information and at least one of a type and a unique identifier of the communication unit having the at least one capability, and determine that the rejection information is intended for the RMCU further based on the mapping.

The method may further comprise obtaining, from the RMCU, the type of the RMCU.

The mapping in one example further correlates a (e.g., the) unique identifier of the RMCU and at least one of the RMCU and a (e.g., the) type of the RMCU.

According to a second aspect, there is provided a method of informing a network node, NN, of a network about at least one sidelink-related radio access capability of a remote communication unit, RMCU, to enable configuring a relay path between the RMCU and the NN via a relay communication unit, RLCU, connected to the NN. The method is performed by the RMCU and comprises transmitting, to the RLCU, first capability information indicative of at least one sidelink-related radio access capability of the RMCU for configuring the RLCU to transmit the first capability information to the NN.

The RLCU may be configured (e.g., at least one of programmed, reconfigured and triggered) to transmit the first capability information to the NN by the first capability information transmitted by the RMCU or by an instruction comprised in a message transmitted from the RMCU to the RLCU, the message further comprising the first capability information. In one variant, the RLCU is pre-set to transmit the first capability information received from the RMCU (or, e.g., received from any remote communication unit) to the NN. In this variant, the RLCU is also configured by the first capability information transmitted from the RMCU, as the first capability information needs to be transmitted to the RLCU for the RLCU to be able to transmit the first capability information to the NN.

The sidelink may be based on a PC5 interface of the RMCU. The at least one sidelink-related radio access capability of the RMCU may identify a sidelink interface of the RMCU, for example the PC5 interface of the RMCU. Alternatively or additionally, the at least one sidelink-related radio access capability of the RMCU may comprise a capability of the RMCU for establishing a sidelink connection to the RLCU connected to the NN of the network. The at least one sidelink-related radio access capability of the RMCU for example comprises a capability of the RMCU for establishing a relay path over a sidelink interface (e.g., the PC5 interface) of the RMCU, for example a relay path between the RMCU and the NN via the RLCU. The relay path between the RMCU and the NN via the RLCU may comprise a first connection between the RMCU and the RLCU and a second connection between the RLCU and the NN, wherein the first connection is established over a sidelink interface (e.g., the PC5 interface) of the RMCU and, optionally, over a sidelink interface (e.g., a PC5 interface) of the RLCU.

The first capability information is in one variant transmitted to the RLCU in a PC5-S message. The PC5-S message may be a Relay communication accept message.

The first capability information is in another variant transmitted in a PC5-RRC message. The first capability information may be transmitted during or after a sidelink unicast connection between the RMCU and the RLCU is or has been established. The first capability information may be transmitted in one of an RRCReconfigurationSidelink message, a UECapabilityEnquirySidelink message and an RRC message designated specifically for transmitting the first capability information from the RMCU to the RLCU.

In one example, the method further comprises receiving, from the RLCU, first configuration information indicative of a first relay path configuration for a relay path between the RMCU and the NN via the RLCU, and configuring a sidelink connection from the RMCU to the RLCU based on the first relay path configuration to establish the relay path between the RMCU and the NN via the RLCU.

According to a third aspect, there is provided a method of informing a network node, NN, of a network about at least one sidelink-related radio access capability of a remote communication unit, RMCU, to enable configuring a relay path between the RMCU and the NN via a relay communication unit, RLCU, connected to the NN. The method is performed by the NN and comprises receiving, from the RLCU, first capability information indicative of at least one sidelink-related radio access capability of the RMCU.

The method may further comprise receiving, from the RLCU, second capability information indicative of at least one relay capability of the RLCU together with the first capability information. The at least one relay capability of the RLCU may comprise a capability of the RLCU to establish a sidelink communication (e.g., via the PC5 interface of the RLCU) to the RMCU. The at least one relay capability of the RLCU may comprise a capability of the RLCU to establish a relay path between the RMCU and the NN via the RLCU, for example using at least one interface chosen from a sidelink interface (e.g., the PC5 interface) of the RMCU and a sidelink interface (e.g., the PC5 interface) of the RLCU.

The method in one example further comprises determining, based on the received capability information, a first relay path configuration for a relay path between the RMCU and the NN via the RLCU.

For example, the method further comprises transmitting, to the RLCU, first configuration information indicative of the first relay path configuration.

The method may further comprise receiving, from the RLCU, a mapping between the at least one capability indicated by the capability information and at least one of a type and a unique identifier of the communication unit having the at least one capability, and determining, based on the mapping, a second index associating the first relay path configuration with the RMCU, wherein the first configuration information transmitted to the RLCU may further comprise the second index.

For example, the received capability information has been enriched with a first index assigned to the at least one capability indicated by the capability information, the first index associating the at least one capability indicated by the capability information with the communication unit having the at least one capability, wherein the method further may comprise determining, based on the first index, a second index associating the first relay path configuration with the RMCU, wherein the first configuration information for example further comprises the second index.

The method may further comprise receiving, from a second RMCU, via the RLCU, property information indicative of at least one sidelink-related radio access capability of the second RMCU, determining, based on at least the property information, a second relay path configuration for a relay path between the second RMCU and the NN via the RLCU, and transmitting, to the RLCU, second configuration information indicative of the second relay path configuration. In this case, the sidelink may be based on a PC5 interface of the second RMCU. The at least one sidelink-related radio access capability of the second RMCU may identify a sidelink interface of the second RMCU, for example the PC5 interface of the second RMCU. Alternatively or additionally, the at least one sidelink-related radio access capability of the second RMCU may comprise a capability of the second RMCU for establishing a sidelink connection to the RLCU connected to the NN of the network. The at least one sidelink-related radio access capability of the second RMCU for example comprises a capability of the second RMCU for establishing a relay path over a sidelink interface (e.g., the PC5 interface) of the second RMCU, for example a relay path between the second RMCU and the NN via the RLCU. The relay path between the second RMCU and the NN via the RLCU may comprise a third connection between the second RMCU and the RLCU and a fourth connection between the RLCU and the NN, wherein the third connection is established over a sidelink interface (e.g., the PC5 interface) of the second RMCU and, optionally, over a sidelink interface (e.g., a PC5 interface) of the RLCU.

In a first variant, the first configuration information and the second configuration information are transmitted in a same message. For example, the same message is an RRC message.

In a second variant, each of the first configuration information and the second configuration information is transmitted in a different message. The first configuration information and the second configuration information may be transmitted to the RLCU in the same order as the first capability information and the property information have been received by the NN. Alternatively or additionally, each of the different messages is an RRC message.

For example, the first configuration information comprises more than one second index, the more than one second index associating the first relay path configuration with both the RMCU and the second RMCU.

The method may further comprise determining, based on the received capability information, that a relay path between the RMCU and the NN via the RLCU cannot be configured, and transmitting, to the RMCU and via the RLCU, rejection information indicative of the NN not determining a first relay path configuration for a relay path between the RMCU and the NN via the RLCU. The rejection information may be transmitted in an RRC message.

The following features may be part of one or more of the methods according to the first, the second and the third aspect.

In a first variant, the RMCU has no end-to-end connection to the network node when the first capability information is transmitted or received. The first capability information may be transmitted in a message triggering establishment of a relay path between the RMCU and the NN via the RLCU.

In a second variant, the RMCU has an established end-to-end connection to the network node when the first capability information is transmitted or received. The end-to-end connection may be established based on a predetermined relay path configuration. In one example, the end-to-end connection is established irrespective of the at least one sidelink-related radio access capability of the RMCU indicated by the first capability information. The first capability information may be transmitted via an Uu interface of the RMCU. The first capability information may be transmitted within a message triggering reconfiguration of the end-to-end connection between the RMCU and the NN as a relay path between the RMCU and the NN via the RLCU (e.g., using a sidelink interface of the RMCU).

The first index may represented by at least one of the following parameters:.

In one example, the first index assigns, to the at least one capability, a unique identifier of the communication unit having the at least one capability. Alternatively, the first index may be a unique identifier of the communication unit having the at least one capability.

For example, the first index is represented by an User Equipment, UE, Radio Capability identifier, ID, identifying a set of capabilities of the communication unit having the at least one capability.

The first capability information is in one example transmitted only after having been enriched, by one of the RLCU and the RMCU, with only the UE Radio Capability ID identifying a set of capabilities of the RMCU.

For example, the first capability information is transmitted only after having been enriched, by one of the RLCU and the RMCU, with both the unique identifier of the RMCU and the UE Radio Capability ID identifying a set of capabilities of the RMCU.

According to a fourth aspect, there is provided a relay communication unit, RLCU, configured for informing a network node, NN, of a network about at least one sidelink-related radio access capability of a remote communication unit, RMCU, to enable configuring a relay path between the RMCU and the NN via the RLCU connected to the NN. The RLCU comprises an interface configured to receive, from the RMCU, first capability information indicative of at least one sidelink-related radio access capability of the RMCU, and at least one processor configured to trigger transmission of the first capability information to the NN, wherein the interface is further configured to transmit the first capability information to the NN.

The RLCU may be configured to perform the method of the first aspect.

According to a fifth aspect, there is provided a remote communication unit, RMCU, configured for informing a network node, NN, of a network about at least one sidelink-related radio access capability of the RMCU, to enable configuring a relay path between the RMCU and the NN via a relay communication unit, RLCU, connected to the NN. The RMCU comprises at least one processor configured to trigger transmission, to the RLCU, of first capability information indicative of at least one sidelink-related radio access capability of the RMCU so as to configure the RLCU for transmission of the first capability information to the NN, and an interface configured to transmit the first capability information to the RLCU.

The RMCU may be configured to perform the method of the second aspect.

According to a sixth aspect, there is provided a network node, NN, of a network, configured for being informed about at least one sidelink-related radio access capability of a remote communication unit, RMCU, to enable configuring a relay path between the RMCU and the NN via a relay communication unit, RLCU, connected to the NN. The NN comprises an interface configured to receive, from the RLCU, first capability information indicative of at least one sidelink-related radio access capability of the RMCU.

The NN may be configured to perform the method of the third aspect.

According to a seventh aspect, there is provided a system comprising at least two components chosen from the relay communication unit of the fourth aspect, the remote communication unit of the fifth aspect, and the network node of the sixth aspect.

According to an eighth aspect, there is provided a computer program comprising instructions which, when the program is executed by a processor, cause the processor to carry out the method of one of the first, the second and the third aspect. There may be provided a computer program product comprising instructions which, when the program is executed by a processor, cause the processor to carry out the method of one of the first, the second and the third aspect.

According to a ninth aspect, there is provided a computer-readable data carrier having stored thereon the computer program of the eighth aspect. The computer-readable data carrier may be a data carrier signal, a signal wave or a (e.g., non-transitory) storage medium.

Further aspects, details and advantages of the present disclosure will become apparent from the detailed description of exemplary embodiments below and from the drawings, wherein:.

While, for example, some embodiments of the following description may focus on an exemplary network configuration in accordance with <NUM> specifications, the present disclosure is not limited in this regard. The present disclosure could be implemented in cellular or non-cellular wireless communication networks complying for example with Long Term Evolution (LTE) or New Radio (NR) specifications.

Those skilled in the art will further appreciate that the steps, services and functions explained herein may be implemented using individual hardware circuits, using software functioning in conjunction with a programmed microprocessor or general purpose computer, using one or more application specific integrated circuits (ASICs) and/or using one or more digital signal processors (DSP). It will also be appreciated that when the present disclosure is described in terms of a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more computer programs that perform the steps, services and functions disclosed herein when executed by one or more processors.

In the following description of exemplary embodiments, the same reference numerals denote the same or similar components.

<FIG> illustrates an exemplary use scenario in accordance with the present disclosure. Vehicles <NUM> and <NUM>, a pedestrian <NUM> carrying a User Equipment (UE), and a UE <NUM> are within a range of coverage <NUM> of a network node (NN) <NUM>. Meanwhile, another vehicle <NUM> is situated outside the range of coverage <NUM>. The NN <NUM> may provide a Long Term Evolution (LTE)-based connection to a network (not shown), of which the NN is part. Of course, the NN may alternatively provide a New Radio (NR)-based network connection or a network connection of another Radio Access Technology (RAT).

In the given example, only the vehicles <NUM> and <NUM> and the UE <NUM> can establish an end-to-end connection to the NN <NUM>. The vehicle <NUM> can perform device-to-device (D2D) communication with the vehicle <NUM>. This case of D2D is commonly referred to as vehicle-to-vehicle (V2V) communication. The vehicle <NUM> can also perform V2V communication with the vehicle <NUM>. Each of the vehicles <NUM> and <NUM> can perform vehicle-to-pedestrian (V2P) communication with the UE carried by the pedestrian <NUM>.

It may therefore be advantageous to provide the vehicle <NUM> or the pedestrian <NUM> with a connection to the network using a relay path. In the shown example, the vehicle <NUM> or the pedestrian <NUM> may each be connected to the network using a relay path via the vehicle <NUM> or a relay path via the vehicle <NUM>. Note that each of the vehicles <NUM>, <NUM>, <NUM>, the UE <NUM> and the UE carried by the pedestrian <NUM> may be referred to as communication units. In the field of relay communication, the intermediate communication unit providing the link between a remote communication unit and the network or NN can be referred to as "relay communication unit". For example, in case of a relay path between the vehicle <NUM> and the NN <NUM> via the vehicle <NUM>, the vehicle <NUM> corresponds to a remote communication unit (RMCU) and the vehicle <NUM> corresponds to a relay communication unit (RLCU).

<FIG> illustrates an exemplary system <NUM>, in which the techniques in accordance with the present disclosure can be implemented. The system <NUM> comprises a relay communication unit (RLCU) <NUM>, a remote communication unit (RMCU) <NUM> and a network node (NN) <NUM> of a network <NUM>. The RLCU <NUM> is connected to the NN <NUM> by a communication connection (CC) <NUM> and can communicate with the NN over the CC <NUM>. The CC <NUM> may be an LTE connection, a NR-based connection or the like.

As can be seen, the RMCU <NUM> comprises an interface <NUM>, the RLCU comprises a first interface <NUM> and a second interface <NUM>, and the NN <NUM> comprises an interface <NUM>. Note that the first and the second interface <NUM>, <NUM> of the RLCU <NUM> may be comprised in an interface <NUM> of the RLCU (not shown). The interface <NUM> may comprise a sidelink interface of the RMCU <NUM>, for example a PC5 interface. Similarly, the interface <NUM> may comprise a sidelink interface of the RLCU <NUM>, for example a PC5 interface. The arrows indicate signaling paths between the interface <NUM> of the RMCU <NUM> and the interface <NUM> of the RLCU <NUM>, and between the interface <NUM> of the RLCU <NUM> and the interface <NUM> of the NN <NUM>, respectively.

Note that data or information may be transmitted in the direction of one or more of the arrows wirelessly. That is, the RMCU <NUM>, the RLCU <NUM> and the NN <NUM> may be wireless communication units. The NN <NUM> may provide a wireless communication network such as a mobile (e.g., a cellular) communication network. For example, the NN <NUM> is an eNB or a gNB. At least one of the RMCU and the RLCU may be a User Equipment (UE). The RLCU may be an intermediate NN or a mobile terminal such as a UE.

Referring back to the use scenario described above with reference to <FIG>, the RMCU <NUM> may not have or not be able to establish, to the NN <NUM>, a direct end-to-end connection having a required Quality-of-Service (QoS). Thus, a relay path may be established or configured between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>. As described above, In accordance with the present disclosure, the NN <NUM> may be informed about at least one sidelink-related capability of the RMCU <NUM>. This may enable or improve configuring the relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>. The relay path may comprise a sidelink connection between the RMCU <NUM> and the RLCU <NUM> and further comprise or use the connection <NUM> between the RLCU <NUM> and the NN <NUM>.

Sidelink transmissions may be associated with a source layer-<NUM> (L1) / layer-<NUM> (L2) identifier (ID) and a destination L1/L2 ID. For sidelink unicast, source L1/L2 ID may represent the service type and/or transmitter UE ID, which may become the destination L1/L2 ID of the peer UE (in the current example, the RLCU <NUM>). A sidelink unicast link may be identified by the combination of source L1/L2 ID and destination L1/L2 ID. For sidelink groupcast, source L1/L2 ID may represent the transmitter UE ID, and destination L1/L2 ID may represents a group identifier provided by an upper layer or a service type. For sidelink broadcast, source L1/L2 ID may represent the transmitter UE ID, and destination L1/L2 ID may represent the service type. A connected UE (e.g., the RMCU <NUM> or the RLCU <NUM>) may report the destination L2 ID to its serving cell or NN (e.g., the NN <NUM>).

Some sidelink Access Stratum (AS)-level information, such as UE capabilities and AS-layer configurations, may be exchanged between UEs performing sidelink unicast, e.g., between the RMCU <NUM> and the RLCU <NUM>. The AS-level information could be exchanged over sidelink using RRC signaling, e.g., a PC5-RRC message. The PC5 message may be sent over a PC5 sidelink interface of the RMCU <NUM> to the RLCU <NUM>. The PC5-RRC message may be sent during or after a sidelink unicast link setup between the RMCU <NUM> and the RLCU <NUM>.

In case the RMCU <NUM> is RRC connected to the RLCU <NUM>, some sidelink AS-level information (e.g. supported sidelink RATs, QoS-related information and configurations) may be exchanged between the NN <NUM> and the RLCU <NUM> and/or the RMCU <NUM> over an Uu interface.

With reference to <FIG>, different methods in accordance with the present disclosure for exchanging first capability information between the RMCU <NUM> and the RLCU <NUM> will be described, wherein the first capability information is indicative of at least one sidelink-related radio access capability of the RMCU <NUM>.

As shown in <FIG>, PC5-RRC based UE capability transfer can be done in a one-way manner. In the one-way case, the RMCU <NUM> that wants to transmit the first capability information directly initiates the transmission to the peer UE (the RLCU <NUM> in <FIG>) and transmits the first capability information to the RLCU <NUM>, for example over a sidelink between the RMCU <NUM> and the RLCU <NUM>.

<FIG> shows a two-way transfer of capability information, wherein the RLCU <NUM> first sends a capability enquiry message to request capability information transfer from the RMCU <NUM>, and then the RMCU <NUM> sends the first capability information to the RMCU <NUM>, for example over a sidelink between the RMCU <NUM> and the RLCU <NUM>, based on the received capability enquiry.

The method of <FIG> and <FIG> are suitable for uni-directional cases, where the capability information of a UE (e.g., the first capability information of the RMCU <NUM>) is only transferred in one direction (e.g., from the RMCU <NUM> to the RLCU <NUM>). On the other hand, in some cases, for example when there is bi-directional sidelink traffic between the RMCU <NUM> and the RLCU <NUM>, a bi-directional procedure may be needed. In this case, not only the RMCU <NUM> may transmit the first capability information to the RLCU <NUM>, but the RLCU <NUM> may also transmit second capability information to RMCU <NUM>, the second capability information indicative of at least one capability of the RLCU <NUM> (e.g., a relay capability or a sidelink-related capability).

<FIG> shows such a bi-directional procedure for a one-way UE capability information transfer, whereas <FIG> shows the bi-directional procedure for a two-way UE capability information transfer. Note that the sequence of steps is exemplary and may be changed.

Referring to <FIG>, it will be described how the RMCU <NUM> compiles and transfers the first capability information for unicast to the RLCU <NUM>.

The RMCU <NUM> may initiate the procedure for transferring the first capability information upon indication from the upper layer when it needs (additional, e.g. radio access) capability information from the RLCU <NUM>. As can be seen, the RMCU <NUM> transmits an UECapabilityEnquirySidelink message to the RLCU <NUM>. The UECapabilityEnquirySidelink message may comprise the first capability information comprising for example UE radio access capabilities for sidelink of the RMCU <NUM>. The first capability information may be included within a message field or section "ueCapabilityInformationSidelink" of the UECapabilityEnquirySidelink message. The RMCU <NUM> may set a message field or section "frequencyBandListFilterSidelink" of the UECapabilityEnquirySidelink message to include frequency bands for which the peer UE (i.e., the RLCU <NUM>) is requested to provide supported bands and band combinations. The RMCU <NUM> may submit the UECapabilityEnquirySidelink message to lower layers for transmission. Note that it is up to RMCU <NUM> to decide whether the "ueCapabilityInformationSidelink" should be included in the UECapabilityEnquirySidelink message.

As shown in <FIG>, the RLCU <NUM> transmits a UECapabilityInformationSidelink message to the RMCU <NUM>. The UECapabilityInformationSidelink message may comprise at least one of the first capability information and the second capability information described herein. The UECapabilityInformationSidelink message may comprise UE radio access capabilities for sidelink of the RLCU <NUM>. Some or all of the aforementioned information may be included within a message field or section "ueCapabilityInformationSidelink" of the UECapabilityInformationSidelink message. The RLCU <NUM> may compile a list of candidate band combinations, only consisting of bands included in a message field or section "frequencyBandListFilter" (e.g., of an UECapabilityEnquiry message), and prioritized in the order of the "frequencyBandListFilterSidelink" message field or section of the UECapabilityEnquirySidelink message (e.g., first include band combinations containing the first-listed band, then include remaining band combinations containing the second-listed band, and so on). The RLCU <NUM> may include into a "supportedBandCombinationListSidelink" message field or section of the UECapabilityInformationSidelink message as many band combinations as possible from the list of candidate band combinations, starting from the first entry. The RLCU <NUM> may submit the UECapabilityInformationSidelink message to lower layers for transmission.

Note that in another variant, the RMCU <NUM> takes the role of the RLCU <NUM> described with reference to <FIG>, and the RLCU <NUM> takes the role of the RMCU <NUM> described with reference to <FIG>. In this case, the RMCU <NUM> may transmit the first capability information to the RLCU <NUM> within the UECapabilityInformationSidelink message.

<FIG> illustrates a schematic view of the RLCU <NUM>. The RLCU <NUM> comprises a processor <NUM>, a memory <NUM> and an interface <NUM>. The memory <NUM> comprises instructions which, when executed by the processor <NUM>, cause the processor <NUM> to perform one or more of the methods described herein. As understood herein, a processor, such as the processor <NUM>, may be implemented using any processing circuitry and is not limited to, for example, a single processing core but may also have a distributed topology. The RLCU <NUM> is configured for informing the NN <NUM> of the network <NUM> about the at least one sidelink-related radio access capability of the RMCU <NUM>, to enable configuring a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM> connected to the NN <NUM>. The interface <NUM> is configured to receive, from the RMCU <NUM>, the first capability information indicative of the at least one sidelink-related radio access capability of the RMCU <NUM>. The processor <NUM> is configured to trigger transmission of the first capability information to the NN <NUM>. The interface <NUM> is further configured to transmit the first capability information to the NN <NUM>.

<FIG> illustrates a schematic view of the RMCU <NUM>. The RMCU <NUM> comprises a processor <NUM>, a memory <NUM> and an interface <NUM>. The memory <NUM> comprises instructions which, when executed by the processor <NUM>, cause the processor <NUM> to perform one or more of the methods described herein. The RMCU <NUM> is configured for informing the NN <NUM> of the network <NUM> about the at least one sidelink-related radio access capability of the RMCU <NUM>, to enable configuring a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM> connected to the NN <NUM>. The processor <NUM> is configured to trigger transmission, to the RLCU <NUM>, of the first capability information indicative of the at least one sidelink-related radio access capability of the RMCU <NUM> so as to configure the RLCU <NUM> for transmission of the first capability information to the NN <NUM>. The interface <NUM> is configured to transmit the first capability information to the RLCU <NUM>.

<FIG> illustrates a schematic view of the NN <NUM>. The NN <NUM> comprises a processor <NUM>, a memory <NUM> and an interface <NUM>. The memory <NUM> comprises instructions which, when executed by the processor <NUM>, cause the processor <NUM> to perform one or more of the methods described herein. The NN <NUM> of the network <NUM> is configured for being informed about the at least one sidelink-related radio access capability of the RMCU <NUM> to enable configuring a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM> connected to the NN <NUM>. The interface <NUM> is configured to receive, from the RLCU <NUM>, the first capability information indicative of the at least one sidelink-related radio access capability of the RMCU <NUM>.

<FIG> illustrates an exemplary method embodiment in accordance with the present disclosure. The method shown in <FIG> may be performed by the RLCU <NUM>. In a step <NUM>, the RLCU <NUM> receives, from the RMCU <NUM>, the first capability information indicative of the at least one sidelink-related radio access capability of the RMCU <NUM>. In a step <NUM>, the RLCU <NUM> transmits the first capability information to the NN <NUM>.

For example, the sidelink is based on a PC5 interface of the RMCU <NUM>. The at least one sidelink-related radio access capability of the RMCU <NUM> may identify a sidelink interface of the RMCU <NUM>, for example the PC5 interface of the RMCU <NUM>. Alternatively or additionally, the at least one sidelink-related radio access capability of the RMCU <NUM> may comprise a capability of the RMCU <NUM> for establishing a sidelink connection to the RLCU <NUM> connected to the NN <NUM> of the network <NUM>. The at least one sidelink-related radio access capability of the RMCU <NUM> for example comprises a capability of the RMCU <NUM> for establishing a relay path over a sidelink interface (e.g., the PC5 interface) of the RMCU <NUM>, for example a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>. The relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM> may comprise a first connection between the RMCU <NUM> and the RLCU <NUM> and a second connection between the RLCU <NUM> and the NN <NUM>, wherein the first connection is established over a sidelink interface (e.g., the PC5 interface) of the RMCU <NUM> and, optionally, over a sidelink interface (e.g., a PC5 interface) of the RLCU <NUM>.

The method may further comprise transmitting, to the NN <NUM>, the second capability information indicative of at least one relay capability of the RLCU <NUM>, together with the first capability information. For example, the (e.g., at least one of first and second) capability information is transmitted to the NN <NUM> within at least one RRC message.

In a first variant, the (e.g., at least one of first and second) capability information is transmitted to the NN <NUM> within a single message. Two or more of the at least one capability indicated by the (e.g., at least one of first and second) capability information may be included in a same information element of the single message. Alternatively or additionally, two or more of the at least one capability indicated by the (e.g., at least one of first and second) capability information may be included in separate information elements of the single message.

In a second variant, the (e.g., at least one of first and second) capability information is transmitted to the NN <NUM> in a plurality of messages, each of the plurality of messages comprising information indicative of only one of the at least one capability indicated by the (e.g., at least one of first and second) capability information.

The (e.g., at least one of first and second) capability information, before being transmitted to the NN <NUM>, may be enriched by the RLCU <NUM> with a first index assigned to the at least one capability indicated by the (e.g., at least one of first and second) capability information, the first index associating the at least one capability indicated by the (e.g., at least one of first and second) capability information with the communication unit having the at least one capability. For example, the first capability information may be enriched with the first index assigned to the at least one sidelink-related radio access capability of the RMCU <NUM> and associates the at least one sidelink-related radio access capability of the RMCU <NUM> to the RMCU <NUM>. For example, the first index is one of generated by the RLCU <NUM> and obtained from the NN <NUM> or a core of the network <NUM>. In one example, the first index is a predefined index. The first index may be written into the first capability information to enrich the first capability information. Alternatively or additionally, the first index may be written into the second capability information to enrich the second capability information.

The RLCU <NUM> may store a mapping between the at least one capability indicated by the (e.g., at least one of first and second) capability information and at least one of a type and a unique identifier of the communication unit (e.g., the RMCU <NUM> or the RLCU <NUM>) having the at least one capability indicated by the same capability information, wherein the method may further comprise determining the first index based on the mapping. For example, the mapping is between the at least one sidelink-related radio access capability of the RMCU <NUM> and the type of the RMCU <NUM>.

The method may further comprise transmitting the mapping to the NN <NUM>.

The method in one example further comprises receiving, from the NN <NUM>, first configuration information indicative of a first relay path configuration for a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>, and transmitting the first configuration information to the RMCU <NUM>.

The first configuration information may be at least one of received and transmitted by the RLCU <NUM> in an RRC message.

The method for example further comprises determining, based on a second index comprised in the first configuration information and associating the first relay path configuration with the RMCU <NUM>, that the first relay path information is intended for the RMCU <NUM>, wherein the first configuration information may be transmitted to the RMCU <NUM> only if it is determined that it is intended for the RMCU <NUM>.

The method may comprise determining that the first relay path is intended for the RMCU <NUM> further based on the mapping.

The method may further comprise receiving, from the NN <NUM>, rejection information indicative of the NN <NUM> not determining a first relay path configuration for a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>, and transmitting the rejection information to the RMCU <NUM>. The rejection information is for example at least one of received and transmitted by the RLCU <NUM> in an RRC message.

The method in one example further comprises determining, based on a second index comprised in the rejection information and associating the rejection information to the RMCU <NUM>, that the rejection information is intended for the RMCU <NUM>, wherein the rejection information may be transmitted to the RMCU <NUM> only if it is determined that it is intended for the RMCU <NUM>.

The RLCU <NUM> may determine that the rejection information is intended for the RMCU <NUM> further based on the mapping.

The method may further comprise obtaining, from the RMCU <NUM>, the type or unique ID of the RMCU <NUM>.

The mapping in one example further correlates the unique ID of the RMCU <NUM> and at least one of the RMCU <NUM> and a type of the RMCU <NUM>.

<FIG> illustrates an exemplary method embodiment in accordance with the present disclosure. The method shown in <FIG> may be performed by the RMCU <NUM>. In a step <NUM>, the RMCU <NUM> transmits, to the RLCU <NUM>, the first capability information indicative of the at least one sidelink-related radio access capability of the RMCU <NUM> for configuring the RLCU <NUM> to transmit the first capability information to the NN <NUM>.

The RLCU <NUM> may be configured (i.e., at least one of programmed, reconfigured and triggered) by the transmitted first capability information or by an indication comprised in a message transmitted from the RMCU <NUM> to the RLCU <NUM>, the message further comprising the first capability information. In one variant, the RLCU <NUM> is pre-set to transmit any first capability information received from the RMCU <NUM> (or, e.g., received from any other RMCU) to the NN <NUM>. In this variant, the first capability information needs to be transmitted to the RLCU <NUM> to configure to RLCU <NUM> to transmit the first capability information to the NN <NUM>, as the RLCU <NUM> does not know the first capability information otherwise and then cannot transmit it to the NN <NUM>.

The first capability information is in another variant transmitted in a PC5-RRC message. The first capability information may be transmitted during or after a sidelink unicast connection between the RMCU <NUM> and the RLCU <NUM> is or has been established. The first capability information may be transmitted in one of an RRCReconfigurationSidelink message, a UECapabilityEnquirySidelink message and an RRC message designated specifically for transmitting the first capability information from the RMCU <NUM> to the RLCU <NUM>.

In one example, the method further comprises receiving, from the RLCU <NUM>, the first configuration information indicative of the first relay path configuration for the relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>, and configuring a sidelink connection from the RMCU <NUM> to the RLCU <NUM> based on the first relay path configuration to establish the relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>.

<FIG> illustrates an exemplary method embodiment in accordance with the present disclosure. The method shown in <FIG> may be performed by the NN <NUM>. In a step <NUM>, the NN <NUM> receives, from the RLCU <NUM>, the first capability information indicative of the at least one sidelink-related radio access capability of the RMCU <NUM>.

The method may further comprise receiving, from the RLCU <NUM>, the second capability information indicative of the at least one relay capability of the RLCU <NUM> together with the first capability information. The at least one relay capability of the RLCU <NUM> may be a capability of the RLCU <NUM> to establish a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>, for example using at least one interface chosen from a sidelink interface (e.g., the PC5 interface) of the RMCU <NUM> and a sidelink interface (e.g., the PC5 interface) of the RLCU <NUM>.

The method in one example further comprises determining, based on the received (e.g., at least one of first and second) capability information, the first relay path configuration for the relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>.

For example, the method further comprises transmitting, to the RLCU <NUM>, the first configuration information indicative of the first relay path configuration.

The method may further comprise receiving, from the RLCU <NUM>, the mapping stored by the RLCU <NUM>, and determining, based on the mapping, a second index associating the first relay path configuration with the RMCU <NUM>, wherein the first configuration information transmitted to the RLCU <NUM> may further comprise the second index. For example, the NN <NUM> receives, from the RLCU <NUM>, the mapping between the at least one sidelink-related radio access capability of the RMCU <NUM> and the type (or, alternatively, the unique ID) of the RMCU <NUM> and determines the second index based on the mapping.

For example, the received (e.g., at least one of first and second) capability information has been enriched (e.g., by the RLCU <NUM>) with the first index assigned to the at least one capability indicated by the (e.g., at least one of first and second) capability information. As noted above, the first index associates the at least one capability indicated by the (e.g., at least one of first and second) capability information with the communication unit having the at least one capability (e.g., the RMCU <NUM> or the RLCU) indicated by the same capability information. The method may further comprise determining, based on the first index, the second index associating the first relay path configuration with the RMCU <NUM>, wherein the first configuration information for example further comprises the second index.

The method may further comprise receiving, from a second RMCU (not shown), via the RLCU <NUM>, property information indicative of at least one sidelink-related radio access capability of the second RMCU, determining, based on at least the property information, a second relay path configuration for a relay path between the second RMCU and the NN <NUM> via the RLCU <NUM>, and transmitting, to the RLCU <NUM>, second configuration information indicative of the second relay path configuration.

In a second variant, each of the first configuration information and the second configuration information is transmitted in a different message. The first configuration information and the second configuration information may be transmitted to the RLCU <NUM> in the same order as the first capability information and the property information have been received by the NN <NUM>. Alternatively or additionally, each of the different messages is an RRC message.

For example, the first configuration information comprises more than one second index, the more than one second index associating the first relay path configuration with both the RMCU <NUM> and the second RMCU.

The method may further comprise determining, based on the received (e.g., at least one of first and second) capability information, that a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM> cannot be configured, and transmitting, to the RMCU <NUM> and via the RLCU <NUM>, the rejection information indicative of the NN <NUM> not determining the first relay path configuration for the relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>. The rejection information may be transmitted in an RRC message.

The following may apply to any of the methods described herein, irrespective of which entity (e.g., the RMCU <NUM>, the RLCU <NUM> or the NN <NUM>) performs the method.

In a first variant, the RMCU <NUM> has no end-to-end connection to the NN <NUM> when the first capability information is transmitted or received. The first capability information may be transmitted in a message triggering establishment of a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>, the relay path for example using or extending over a sidelink interface (e.g., the PC5 interface) of the RMCU <NUM>.

In a second variant, the RMCU <NUM> has an established end-to-end connection to the NN <NUM> when the first capability information is transmitted or received, for example an end-to-end connection via the RLCU <NUM>. The end-to-end connection may be established based on a predetermined relay path configuration. In one example, the end-to-end connection is established irrespective of the at least one sidelink-related radio access capability of the RMCU <NUM> indicated by the first capability information. The first capability information in this case may be transmitted via an Uu interface of the RMCU <NUM>. The first capability information may be transmitted within a message triggering reconfiguration of the end-to-end connection between the RMCU <NUM> and the NN <NUM> as a relay path between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM>, the relay path for example using or extending over a sidelink interface (e.g., the PC5 interface) of the RMCU <NUM>.

In one example, the first index assigns, to the at least one capability indicated by the capability information, a unique ID of the communication unit having the at least one capability indicated by the same capability information. Alternatively, the first index may comprise or be a unique ID of the communication unit (e.g., the RMCU <NUM> or the RLCU <NUM>) having the at least one capability indicated by the capability information.

For example, the first index is represented by an User Equipment, UE, Radio Capability identifier, ID, identifying a set of capabilities of the communication unit (e.g., the RMCU <NUM> or the RLCU <NUM>) having the at least one capability indicated by the capability information.

The first capability information is in one example transmitted only after having been enriched, by one of the RLCU <NUM> and the RMCU <NUM>, with only the UE Radio Capability ID identifying a set of capabilities of the RMCU <NUM>.

For example, the first capability information is transmitted only after having been enriched, by one of the RLCU <NUM> and the RMCU <NUM>, with both the unique identifier of the RMCU <NUM> and the UE Radio Capability ID identifying a set of capabilities of the RMCU <NUM>.

<FIG> illustrates an exemplary method embodiment in accordance with the present disclosure. The method shown in <FIG> may be performed by the system <NUM>. In step <NUM>, the RMCU <NUM> transmits a PC5-S Relay Communication Request message to the RLCU <NUM>. The PC5-S Relay Communication Request message may indicate the relay service type (i.e., the type of traffic (e.g., Ultra-Reliable and Low Latency Communication (URLCC) or enhanced Mobile Broadband (eMBB)) for which the relay path shall be established). Further information comprised in the Relay Communication Request message may be, e.g., a QoS profile or an indication of certain QoS requirements. In step <NUM>, the RLCU <NUM> transmits a PC5-S Relay Communication Response message to the RMCU <NUM>. In step <NUM>, the RMCU <NUM> selects the RLCU <NUM>, for example from a plurality of available RLCUs, based on the information comprised in the PC5-S Relay Communication Response message. In step <NUM>, the RMCU <NUM> transmits a PC5-S Relay Communication Accept message to the RLCU <NUM>. In step <NUM>, a PC5-RRC connection may be established between the RMCU <NUM> and the RLCU <NUM> based on the information exchanged in one or more of steps <NUM> to <NUM>.

In step <NUM>, the RMCU <NUM> transmits the first capability information indicating the at least one sidelink-related radio access capability of the RMCU <NUM> to the RLCU <NUM> within a PC5-RRC message. In step <NUM>, the RLCU <NUM> transmits the first capability information to the NN <NUM>. In the shown example, the RLCU <NUM> transmits the first capability information received from the RMCU <NUM> to the NN <NUM> in a RRC RelayRequest message reflecting the relay service containing the at least one sidelink-related radio access capability of the RMCU <NUM>. In step <NUM>, the NN <NUM> transmits to the RLCU <NUM> an RRCReconfiguration message as an RRC message. The RRCReconfiguration message may include or indicate a configuration for an adaptation layer and/or a sidelink radio bearer (SLRB) configuration. In step <NUM>, the RLCU <NUM> transmits, to the NN <NUM>, an RRCReconfigComplete message as an RRC message. In step <NUM>, the RLCU <NUM> transmits, to the RMCU <NUM>, a Relay Communication Confirm message over PC5-S. In step <NUM>, the RMCU <NUM> transmits an RRC Setup Request message to the NN <NUM> that is relayed via the RLCU <NUM>. The NN <NUM> in step <NUM> establishes an adaptation layer ("Adapt Layer" in <FIG>) in accordance with the RRC Setup Request message received from the RMCU <NUM>. In step <NUM>, the NN <NUM> transmits, to the RMCU <NUM>, a RRC Setup message that is relayed via the RLCU <NUM>. In step <NUM>, the RMCU <NUM> transmits, to the NN <NUM>, a RRC Setup complete message that may comprise a Non-Access Stratum (NAS) Registration Request. In step <NUM>, a connection between the RMCU <NUM> and the NN <NUM> via the RLCU <NUM> is secured. The resulting connection may be referred to as an end-to-end connection between the RMCU <NUM> and the NN <NUM>.

<FIG> illustrates an exemplary method embodiment in accordance with the present disclosure. The method shown in <FIG> may be performed by the system <NUM>. In step <NUM>, the RMCU <NUM> selects a relay path (e.g., selects the RLCU <NUM> from a plurality of available RLCUs), and the RLCU <NUM> enters RRC_CONNECTED mode if it its status is different from CONNECTED (e.g., if its status is RRC_IDLE or RRC_INACTIVE). In one example, the status of the RLCU <NUM> is CONNECTED if it is selected by the RMCU <NUM>. The RMCU <NUM> may only select the RLCU <NUM> if its status is CONNECTED. The NN <NUM> admits the relay path access, a connection between the RMCU <NUM> and the NN <NUM> is secured ("<NUM> security setup" in <FIG>) and an adaptation layer is established. Optionally, the PC5-RRC connection may be established between the RMCU <NUM> and the RLCU <NUM>. In step <NUM>, the RMCU <NUM> transmits, to the NN <NUM>, an RRC Setup Request message that is relayed via the RLCU <NUM>. In step <NUM>, the NN <NUM> transmits, to the RMCU <NUM>, a RRC Setup message that is relayed via the RLCU <NUM>. In step <NUM>, the RMCU <NUM> transmits, to the NN <NUM>, a RRC Setup complete message that may comprise a Non-Access Stratum (NAS) Registration Request. In step <NUM>, a connection between the RMCU <NUM> and the NN <NUM> is secured, resulting in a secured relay path forming an end-to-end connection. In step <NUM>, the first capability information is transmitted from the RMCU <NUM> to NN <NUM> via the RLCU <NUM> using the secured relay path.

Note that in the example of <FIG>, the end-to-end connection may be established based on a predetermined relay path configuration. This may be a basic capability set that is hard coded in the RMCU <NUM> or the RLCU <NUM> (e.g., in the memory of the respective communication unit or in a SIM card inserted in the respective communication unit).

In LTE and NR there is a UE capability signaling optimization feature that is called Resource and Admission Control Subsystem (RACS). The RACS is designed to allow user devices to request and reserve resources in an access network, essentially providing subscribers with the correct QoS for the service they are attempting to initiate. RACS provides an efficient approach to signal UE Radio Access Capability information over a radio interface and other network interfaces. RACS works by assigning an identifier to represent a set of UE radio capabilities. This identifier is called UE Radio Capability ID. A UE Radio Capability ID can be either manufacturer-assigned or PLMN-assigned, as specified e.g., in clause <NUM>. <NUM> of 3GPP TS <NUM>. The UE Radio Capability ID is an alternative to the signalling of the radio capabilities container over the radio interface, within E-UTRAN, from E-UTRAN to NG-RAN, from MME to E-UTRAN and between CN nodes supporting RACS. The UE Radio Capability ID may correspond to, be comprised in, or be represented by the first index described herein.

The techniques disclosed herein may refer to the NR RAT, but may be applied also to LTE RAT and any other RAT enabling the transmission on two nearby devices. In the following, instead of to an RMCU <NUM>, it may be referred to an "RM UE" or a "remote UE" that may need to transmit or receive a data packet from or to the NN <NUM> (e.g., a gNB) via the RLCU <NUM>. Instead of to an RLCU <NUM>, it may be referred to an "intermediate network node", a "mobile terminal" or an "RL UE". Also, it may be referred to a "network" which is to be understood as the NN <NUM> or an entity comprised in the network <NUM>. In the following, it will be referred to a transmission of capabilities. It is to be understood that this may comprise or correspond to a transmission of the capability information or of an indication of at least one of the capabilities. One example of such a capability is the sidelink-related radio access capability of the RMCU <NUM> described herein.

In one embodiment, after selecting a RL UE (e.g., the RLCU <NUM>), the RM UE (e.g., the RMCU <NUM>) sends a PC5-S message to the RL UE (e.g., Relay communication accept) for establishing a relay path and within this message it includes its capabilities (e.g., the first capability information). Alternatively, after selecting a RL UE, the RM UE establishes a PC5-RRC link with the RL UE and then sends its own capabilities (e.g., the first capability information) within a PC5-RRC message. In one embodiment the PC5-RRC message is the RRCReconfigurationSidelink. In another embodiment, the PC5-RRC message is the UECapabilityEnquirySidelink. Yet, in another embodiment, the PC5-RRC is a new RRC message. Note that in these embodiments, it may be assumed that no end-to-end connection between the RM UE and the network (e.g., the NN <NUM> or the network <NUM>) is yet in place (e.g., there is only a connection between the RM UE and the RL UE - see also <FIG>).

In one embodiment, upon receiving the capabilities (e.g., the first capability information) from one or more RM UE(s), the RL UE (e.g., the RLCU <NUM>) sends the capabilities from the RM UE(s) optionally together with its own capabilities (e.g., the second capability information) to the network in the same RRC message. In another embodiment, upon receiving the capabilities from one or more RM UE(s), the RL UE sends one RRC message for each capability that needs to be sent to the network.

In another embodiment, if the RL UE sends all the capabilities (the ones from the RM UE(s) and potentially also its own capabilities) in one RRC message, the RL UE includes all the capabilities in the same information element. Yet, in one embodiment, if the RL UE sends all the capabilities (the ones from the RM UE(s) and potentially also its own capabilities) in one RRC message, the RL includes each capability in a separate information element.

In one embodiment, when sending the capabilities to the network, the RL UE includes a first index for each capability so that each capability can be associated to the correct (e.g., type of) UE (e.g., RL UE or one or more RM UEs). In another embodiment, the first index is represented by one or more than one of the following parameters/fields:.

In one embodiment, the first index is represented by an existing capability ID generally used to identify a set of capability (e.g., the UE Radio Capability ID). In another embodiment, the first index is a new index and is used to assign a unique ID with which the RM UE can be identified by the RM UE itself, the RL UE, the network (e.g., the NN <NUM> such as a NG-RAN node), and the core network.

In another embodiment, the first index is generated by the NG-RAN node (e.g., the NN <NUM>). In another embodiment, the first index is generated by the RL UE. Yet, in another embodiment, the first index is generated by the core network (e.g., a core of the network <NUM>).

In one embodiment, when sending the capabilities to the network, the RL UE includes only the capability ID of the RM UE, if configured previously by the core network. In another embodiment, when sending the capabilities to the network (NW), the RL UE includes the capability ID and the new index in order to identify the RM UE, if the capability ID has been configured previously by the core network (e.g., the core of the NW <NUM>). This latter case may be needed because the capability ID may not be supported by one or more of the RL UE, the NG-RAN node, the RM UE and the core network (those network nodes need to support optimizations on the UE radio capability signaling (e.g., RACS) in order to understand the capability ID).

In one sub-embodiment, no index or a predefined index value is associated with capabilities of the RL UE or UE that is directly communicating with the NW.

In another sub-embodiment, a capability may be associated with more than one first index, for example if multiple (e.g., type of) UEs have the same capability. In another embodiment, the RL UE keeps a mapping between capability and (e.g., type of) RM UE in its memory and guarantees that the right capability is linked to the right (e.g., type of) RM UE when exchanged between the RM UE and the network. Alternatively, in one embodiment the RL UE sends the mapping between capability and (e.g., type of) RM UE to the network so the network is aware about which (e.g., type of) UE the capability belongs to. This may be the case when the capabilities are sent by the RL UE without the first index and it is the network that adds the first index according to the received mapping.

In another embodiment, the RL UE keeps a mapping between RM UE ID and (e.g., type of) RM UE in its memory, and is informed of the UE type by the remote UE.

In another embodiment, the RM UE sends its own capabilities to the network via the RL UE only after an end-to-end connectivity between the RM UE and the network is in place (see <FIG>).

In case the capabilities are exchanged after the relay path is established, the assumption is that the two UEs can use some basic capability (specified in some 3GPP Release or Draft specification) to establish a preliminary relay connection just for the sake of exchanging the capabilities (and, e.g., some other critical information or configuration). Then, after the capabilities are acquired by the network, the relay may be reconfigured with e.g., more functionalities.

In another embodiment, upon receiving the RM UE's capabilities via the RL UE, the network generates a (e.g. first relay path) configuration to enable or establish the relay path for the (e.g., type of) RM UE(s) to which the capabilities belong and sends it to the RL UE. Yet, in one embodiment, if the received capabilities belong to more than one (e.g., type of) RM UEs, the network generates configurations to enable or establish the relay path with each (e.g., type of) RM UE and send all these configurations within one RRC message to the RL UE. The RL UE, after decoding the RRC message, may then forward the right configuration to the right RM UE according to the mapping between the capability and (e.g., type of) RM UE and the mapping between the RM UE ID and (e.g., type of) RM UE. Alternatively, in another embodiment, if the received capabilities belong to more than one (e.g., type of) RM UEs, the network generates configurations to enable or establish the relay path with each (e.g., type of) RM UE and sends one RRC message for each generated configuration to the RL UE. The RL UE, after decoding the RRC message, may then forward the right configuration to the right RM UE according to the mapping between the capability and (e.g., type of) RM UE and the mapping between the RM UE ID and (e.g., type of) RM UE.

In another embodiment, when generating multiple configurations, one for each capability received, the network includes in the configuration an (e.g., second) index to associate the configuration to the right (e.g., type of) RM UE. Alternatively, if the network did not receive any mapping rule from the RL UE, the network (e.g., the NN <NUM>) when sending the configurations to the RL UE, sends these configurations in the same order as the corresponding capabilities have been received. Yet, in one embodiment, if a mapping rule has been received by the RL UE, the network include an (e.g., second) index in each of the configuration according to the mapping rule received by the RL UE. In this latter case, the network may receive from the RL UE the capabilities without any (e.g., first) index and the mapping rule. It may be the network that, when sending the configuration to the RL UE, includes the (e.g., second) index according to the received mapping. On the contrary, if the RL UE sends the capabilities with an (e.g., first) index, the network when sending back the configuration may reuse the same index for indicating to which capability the configuration refers.

In one sub-embodiment, a configuration may be associated with more than one (e.g., second) index, in case e.g. multiple (e.g., types of) UEs are configured with the same configuration.

In one embodiment, upon receiving the capabilities from the RM UE (e.g., via the RL UE), the network generates the configuration for enabling or establishing the relay path and sends it to the RM UE via the RL UE.

In another embodiment, upon receiving the capabilities from the RM UE via the RL UE, the network rejects the request to establish a relay path and sends an RRC message to the RM UE via the RL UE.

Yet in another embodiment, upon receiving the capabilities associated with certain (e.g., type of) RM UE(s) from the RL UE, the network rejects the request to establish a relay path for that (e.g., type of) RM UE(s) and sends an RRC message to the RL UE which further forwards the message to the relevant RM UEs according to the mapping between the capability and (e.g., type of) RM UE and the mapping between the RM UE ID and (e.g., type of) RM UE.

As has become apparent from the above, the technique described herein allows an RM UE to report its own capabilities to the network via an RL UE. In doing this, two variants are provided:.

Claim 1:
A method of informing a network node, NN, (<NUM>, <NUM>) of a network (<NUM>) about at least one sidelink-related radio access capability of a remote communication unit, RMCU, (<NUM>, <NUM>) to enable configuring a relay path between the RMCU (<NUM>, <NUM>) and the NN via a relay communication unit, RLCU, (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) connected to the NN (<NUM>, <NUM>), the method being performed by the RLCU (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) and comprising:
receiving (<NUM>, <NUM>), from the RMCU (<NUM>, <NUM>), first capability information indicative of at least one sidelink-related radio access capability of the RMCU (<NUM>, <NUM>), wherein the first capability information, before being transmitted to the NN (<NUM>), is enriched by the RLCU (<NUM>) with a first index assigned to the at least one capability indicated by the first capability information, the first index associating the at least one capability indicated by the first capability information with the communication unit (<NUM>, <NUM>) having the at least one capability; and
transmitting (<NUM>, <NUM>) the first capability information to the NN (<NUM>, <NUM>);
wherein the method further comprises:
- receiving, from the NN (<NUM>, <NUM>), first configuration information indicative of a first relay path configuration for a relay path between the RMCU (<NUM>, <NUM>) and the NN (<NUM>, <NUM>) via the RLCU (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>);
- determining, based on a second index comprised in the first configuration information and associating the first relay path configuration with the RMCU (<NUM>), that the first relay path information is intended for the RMCU (<NUM>); and
- transmitting the first configuration information to the RMCU (<NUM>, <NUM>) only if it is determined that the first configuration information is intended for the RMCU (<NUM>);
or
- receiving, from the NN (<NUM>, <NUM>), rejection information indicative of the NN (<NUM>, <NUM>) not determining a first relay path configuration for a relay path between the RMCU (<NUM>, <NUM>) and the NN (<NUM>, <NUM>) via the RLCU (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>);
- determining, based on a second index comprised in the rejection information and associating the rejection information to the RMCU (<NUM>, <NUM>), that the rejection information is intended for the RMCU (<NUM>, <NUM>); and
- transmitting the rejection information to the RMCU (<NUM>, <NUM>) only if it is determined that the rejection information is intended for the RMCU (<NUM>, <NUM>).