WO2025233338A1

WO2025233338A1 - Methods and apparatus for managing relay communication in multi-hop relay

Info

Publication number: WO2025233338A1
Application number: PCT/EP2025/062358
Authority: WO
Inventors: Romain Guignard; Pascal Lagrange
Original assignee: Canon Europe Ltd; Canon Inc
Current assignee: Canon Europe Ltd; Canon Inc
Priority date: 2024-05-10
Filing date: 2025-05-06
Publication date: 2025-11-13
Anticipated expiration: 2026-11-10
Also published as: GB202406657D0; GB2640971A

Abstract

Methods and apparatus for managing relay communication in a wireless communication system including a plurality of User Equipment, UE, and a network including a base station are disclosed. The method at a UE of the plurality of UEs includes receiving a request for establishing a connection to the UE for multi-hop communication between a first UE of the plurality of UEs and a second UE of the plurality of UEs, the request including maximum hop information indicating a value associated with a maximum number of hops between the first UE and the second UE supported by the first UE. The method at a relay UE of the plurality of UEs including receiving a request for establishing a connection to the relay UE for multi-hop communication between a first UE of the plurality of UEs and a base station of the network via the relay UE, wherein the request includes network connection information for indicating the first UE requests connection to the network. Methods at the first UE are also disclosed.

Description

METHODS AND APPARATUS FOR MANAGING RELAY COMMUNICATION IN MULTI-HOP RELAY

Field of the Invention

The present invention generally relates to managing relay communication in a wireless communication system supporting relaying. For example, the present invention relates to a multi-hop relaying in a communication system supporting sidelink (SL) relaying. In particular, the present invention relates managing relay communication with integrated discovery in multihop relay.

Background

The 3rd Generation Partnership Project (3GPP) has initiated the development of new radio access technology known as fifth-generation New Radio (5G NR) to respond to requirements related to very high reliability and very low latency. The 5G NR is not referred only to the enhancement of radio access technology but also to address a wide range of new services to be enabled by future mobile communication. Three distinctive categories of use cases are defined in NR from enhanced mobile broadband (eMBB), massive machine typing communication (mMTC) to Ultra-Reliable and Low Latency communication (URLLC).

A first version of Sidelink for 5G, or New Radio (NR) Sidelink, has been developed in 3GPP Release 16 as part of the 5G V2X Work Item, to support advanced vehicle-to-anything (V2X) scenarios and commercial applications and services in addition to complement former basic safety services. NR V2X addresses advanced driving use cases where vehicles are exchanging large amount of data while respecting a low latency requirement. NR Sidelink is designed to provide three basic transmission scenarios: broadcast, groupcast and unicast communications, while considering both out-of-coverage and in-network coverage deployment scenarios.

Based on the NR sidelink technology, 3 GPP introduced the sidelink-based relaying functionality as part of the 3GPP Release 17 framework, where a relay UE may provide User Plane (UP) and Control Plane (CP) data relaying between a set of served remote UEs and the network (UE-to-network, or U2N, relay) or between a source remote UE, or source UE, and a target remote UE, or target UE (UE-to-UE, or U2U relay).

The purpose of the Release 17 sidelink relaying functionality was to both extend sidelink / network coverage and improve power efficiency, while considering a wider range of applications and services, including V2X, Public Safety and commercial applications and services. Some of these new V2X scenarios require ultra-reliability and low latency (URLLC) performance, in order to meet high-speed and high-density constraints, while requiring some network coverage extension, which may be achieved through sidelink relaying.

This first version of the sidelink relaying functionality, as defined in the Release 17 specification, mainly aimed at supporting the UE-to-network (U2N) relaying with basic functionalities and limited features. For better support of the use cases requiring sidelink relay, further enhancements are necessary in order to introduce the potential solutions identified during the Rel-17 study item. The follow-up 3GPP Release 18 work item “NR Sidelink Relay (SLR) Enhancements” has addressed several solutions considered as enhancement areas needed in NR Sidelink Relay system for the V2X, public safety and commercial use cases.

In this respect, the Release 18 introduced some new features aiming at supporting the UE-to-UE (U2U) relaying, while introducing some service continuity enhancements for the UE-to-network (U2N) relaying, while some further enhancements to support multi-hop relaying are foreseen for Release 19.

Among the feature introduced by the Release 18 for supporting UE-to-UE (U2U) relaying, the Direct Communication with integrated discovery allows both to discover and to establish a PC5 connection between two UEs through a relay.

So far, this procedure considered in 3GPP is intended for “direct” relaying and do not support multi-hop relaying scenarios where a UE would be connected to the Network (multihop U2N) or to another UE (multi-hop U2U) through more than one Relay UE.

Therefore, it is desirable to provide solutions to manage or facilitate relay communication in a wireless communication system supporting multi-hop relaying.

Summary

In accordance with an aspect of the present invention, there is provided a method for managing relay communication (or managing relay communication with integrated discovery in multi-hop relay) in a wireless communication system supporting relaying, the wireless communication comprising a plurality of User Equipment, UEs, the method at a UE of the plurality of UEs including: receiving a request, such as a Direct Communication Request or a link modification request, for establishing a connection to the UE for multi-hop communication between a first UE (e.g. source or initiating remote UE) of the plurality of UEs and a second UE (e.g. target UE or target remote UE) of the plurality of UEs, the request including maximum hop information indicating a value associated with a maximum number of hops between the first UE and the second UE supported or allowed by the first UE. In accordance with another aspect of the present invention, there is provided a method for managing relay communication (or managing relay communication with integrated discovery in multi-hop relay) in a wireless communication system supporting relaying, the wireless communication comprising a plurality of User Equipment, UEs, and a network including one or more base stations, the method at a relay UE of the plurality of UEs including: receiving a request, such as a Direct Communication Request or a link modification request, for establishing a connection to the relay UE for multi-hop communication between a first UE (e.g. remote UE) of the plurality of UEs and a base station of the network via the relay UE (which may be an intermediate relay in a multi-hop communication path between the first UE and the base station or a target relay UE, such as a U2N relay UE in coverage of the base station), wherein the request includes network connection information for indicating the first UE requests connection to the network (e.g. the first UE is looking for a connection to the network).

In accordance with another aspect of the present invention, there is provided a method for managing relay communication (or managing relay communication with integrated discovery in multi-hop relay) in a wireless communication system supporting relaying, the wireless communication comprising a plurality of User Equipment, UEs, the method at a first UE (e.g. source or initiating remote UE) of the plurality of UEs including: sending a request, such as a Direct Communication Request or a link modification request, for establishing a connection for multi-hop communication between the first UE and a second UE (e.g. target UE or target remote UE) of the plurality of UEs, the request including maximum hop information indicating a value associated with a maximum number of hops between the first UE and the second UE supported or allowed by the first UE.

In accordance with another aspect of the present invention, there is provided a method for managing relay communication (or managing relay communication with integrated discovery in multi-hop relay) in a wireless communication system supporting relaying, the wireless communication comprising a plurality of User Equipment, UEs, and a network including one or more base stations, the method at a first UE (e.g. remote UE) of the plurality of UEs including: sending a request, such as a Direct Communication Request or a link modification request, for establishing a connection for multi-hop communication between the first UE and a base station of the network, wherein the request includes network connection information for indicating the first UE requests connection to the network (e.g. the first UE is looking for a connection to the network). In accordance with an aspect of the present invention, there is provided an apparatus for a UE as recited in claim 75 of the accompanying claims.

By sending a request including maximum hop information indicating a value associated with a maximum number of hops between the first UE and the second UE supported or allowed by the first UE, the request can be forwarded over multiple hops up to the maximum number of hops facilitating the establishment of connections for U2U multi -hop communication.

By sending a request including network connection information indicating the first UE requests connection to the network, the request can be forwarded over multiple hops to a target relay UE based at least on the network connection information (such as a U2N relay UE in coverage of the base station) facilitating the establishment of connections for U2N multi-hop communication.

The use of a hop count information in the request would also allow optimizing the forwarding of the discovery messages in the network as a relay UE may stop forwarding discovery messages when the number of hops has reached a limit, or maximum number of hops supported by the UE.

The use of a hop count information in the request would also allow optimizing the performance of the UE communications as well as the relay selection process that would result from the discovery process.

For instance, if a UE has some tight latency constraints, it may limit the number of hops to be considered in a multi-hop relaying scheme it is looking for. Similarly, a UE may further select a multi-hop relaying scheme having a low hop count in order to optimize the latency of its communications with a target device (either network or UE).

By sending a request including a RRC container and/or a SetupRequestCommand, the first UE gives information useful for the RRC connection with the target UE and/or with the base station. This allows to optimize the time to achieve the RRC connection and save bandwidth normally used to carry these information in subsequent messages.

Further example features of the invention are described in other independent and dependent claims.

In the following reference will be a UE and other UE. It will however be appreciated that instead the terms first UE and second UE could be used in place of UE and other UE.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus/device/unit aspects, and vice versa. Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program.

Brief Description of the Drawings

Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure l is a schematic diagram illustrating an example wireless communication system in which the present invention may be implemented according to one or more embodiments;

Figure 2 is a schematic diagram illustrating a typical 5G Proximity-based Services (ProSe) Relay reference architecture;

Figure 3 is a schematic diagram illustrating user plane stacks of some protocol layers involved in Sidelink relay operations for UE-to-network (U2N) based relaying;

Figure 4 is a block schematic diagram of an example wireless communication device in accordance with embodiments of the present invention.

Figures 5 to 7 are schematic and simplified diagrams illustrating examples of message flows for managing relay communication with integrated discovery in multi-hop in a wireless communication system in accordance with one or more embodiments of the invention;

Figures 8 to 11 are simplified flowcharts of methods for managing relay communication in multi-hop relay in accordance with one or more embodiments of the present invention.

Detailed Description

Figure 1 represents an example of a wireless communication system 100 capable of supporting relaying between a User Equipment (UE) and a base station, or between two User Equipment (UE) and shows a relay arrangement or system (or network) including a plurality of nodes including one or more relay nodes (e.g., relay User Equipment (UE)) serving one or more remote User Equipment (UE).

In the following description reference is made to a wireless communication system 100 capable of supporting Sidelink Relay where a path between a remote UE and a base station includes a sidelink connection (also known as a PC5 link) between the remote UE and a relay UE and a network connection (also known as a Uu link) between a relay UE and the base station. However, it is not intended that the present invention is limited to a PC5 link between the remote UE and the relay UE and could apply to relaying configurations where the link between the remote UE and the relay UE is via another type of connection (e.g., a non-3GPP connection), such as a WiFi or Bluetooth.

With reference to Figure 1, UE node 111 is served by network node 101 and may operate as a relay UE node relaying data between one of the UE nodes 112, 121 (referred to as remote UE nodes) and the network node 101, hence performing UE-to-network (U2N) relaying. In its turn, UE 112 may operate as a relay UE node relaying data between the UE node 113 and the network node 101 through the other relay node 111. Some multi -hop UE-to-Network relaying (multi -hop U2N) may thus be performed between network node 101 and UE 113 through relay UEs 111 and 112.

In the example of the figure 1, the UE 111 may act as a remote UE and as a relay UE. In an example where the network node 101 is part of a cellular network, the relay UE I l l is served by a cell 101a controlled by the network node 101.

UE node 131 is served by network node 101 and may operate as a relay UE node relaying data between the UE node 132 (referred to as a remote UE node) and the network node 101, hence performing UE-to-network (U2N) relaying. In its turn, UE 132 may operate as a relay UE node relaying data between the UE node 133 or 134 and the network node 101 through the other relay node 131. Some multi -hop UE-to-Network relaying (multi -hop U2N) may thus be performed between network node 101 and UEs 133 or 134 through relay UEs 131 and 132.

In an example where the network node 101 is part of a cellular network, the relay UE 131 is served by cell 101a controlled by the network node 101.

In an example where the network node 101 is part of a cellular network, the relay UE 131 and 132 are served by a cell 101a controlled by the network node 101, while remote UE 133 and 134 are out of coverage (OOC) as they are not served by any cell.

UE node 121 is served by network node 101 and may operate as a relay UE node relaying data between the UE nodes 122 (referred to as remote UE node) and the network node 101, hence performing UE-to-network (U2N) relaying. In its turn, UE 122 may operate as a relay UE node relaying between the UE node 123 and the network node 101 through the other relay node 121. In the example of the figure 1, the UE 121 may act as a remote UE and as a relay UE. In its turn, UE 123 may operate as a relay UE node relaying between the UE node 124 and the network node 101 through the other relay nodes 121 and 122. Some multi-hop UE-to- Network relaying (multi -hop U2N) may thus be performed between network node 101 and UE 123 or 124 through relay UEs 122 and 121 or through relay UEs 123, 122 and 121.

In an example where the network node 101 is part of a cellular network, the relay UE 121, 122 and 123 are served by a cell 101a controlled by the network node 101, while remote UE 124 is out of coverage (OOC) as it is not served by any cell.

UE node 151 is served by network node 102 and may operate as a relay UE node relaying data between one of the UE nodes 152, 153, 141 (referred to as remote UE nodes) and the network node 102, hence performing UE-to-network (U2N) relaying. In its turn, UE 152 may operate as a relay UE node relaying between the UE node 154 and the network node 102 through the other relay node 151. Some multi -hop UE-to-Network relaying (multi -hop U2N) may thus be performed between network node 102 and UE 154 through relay UEs 152, and

151 (and 141).

In the example of the figure 1, the UE 141 may act as a remote UE and/or as a relay UE for UE 151.

In an example where the network node 102 is part of a cellular network, the UEs 151,

152 and 141 are served by a cell 102a controlled by the network node 102, while remote UEs

153 and 154 are out of coverage (OOC) as they are not served by any cell.

The network nodes 101 and 102 may be base stations of a wireless network or network, such as a fifth-generation (5G) New Radio (NR) network or a Long-Term Evolution (LTE) network. Figure 1 only shows the base stations of the wireless network for clarity. Base stations 101 and 102 are interconnected such as through a wired link infrastructure 180, preferably based on optical fiber or any other wired means. As shown in figure 1, the base stations are also connected to a core network 170 through a wired link infrastructure 190, preferably based on optical fiber or any other wired means. For a 5G NR network, the network nodes 101, and 102, are referred to as gNBs and are part of the NG-RAN.

UEs 161, 162, 163 and 164 are not served by any network node. Still, UE node 162 may operate as a relay UE node relaying data between the UE node 161 (referred to as a remote UE node) and the UE node 163, hence performing UE-to-UE (U2U) relaying. In its turn, UE 163 may operate as a relay UE node relaying data between the UE node 164 and the UE node 161 through the other relay node 162. Some multi -hop UE-to-UE relaying (multi -hop U2U) may thus be performed between UE 161 and UE 164 through relay UEs 162 and 163.

Similarly, some multi-hop UE-to-UE relaying (multi-hop U2U) may be performed between UE 121 and UE 124 through relay UEs 122 and 123. In general, the wireless communication system 100 is capable of supporting multi -hop relaying between a remote UE node (or remote UE) and a target or target node. The target node may be a base station of the network in the case of U2N relaying or another UE in the case of U2U relaying.

Some examples of UEs include smartphones/tablets (such as UEs 121, 122, 123, 141 and 161), XR headsets (such as UEs 111, 112, 113), cameras (such as UEs 124 and 153), fixed video cameras (such as UEs 131, 132, 133), mobile/wearable video cameras (such as UEs 134, 162, 163, 164, 152 and 154) or Unmanned Aerial Vehicle (UAV) 151, which may also embed one or more video cameras. In general, the UE may be any portable or handheld or mobile telephone, a smartphone, a tablet, a portable or fixed computer, fixed or mobile camera, portable television, other smart devices or other similar wireless communication device. In the following description, the term UE will be used and it is not intended to limit the description to any particular type of wireless communication device.

In the following, a relay UE node will also be referred to as a relay UE, a remote UE node will also be referred to as a remote UE and a network node will be referred to as a base station or as a gNB. It will however be appreciated that the terms first and second UEs may be used instead of remote UE and relay UE. Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR network, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems supporting sidelink (or peer to peer) relay communications and multi-hop relaying.

In an example shown in Figure 1, in a UE-to-Network (or U2N) scenario with the UE 111 (or UE 131) operating as UE-to-Network relay UE, the UE-to-Network relay UE 111 (or relay UE131) connects the UEs 112 and 121 (or UE 132), operating as remote UEs, to the gNB 101 (or gNB 102). The remote UE 112 is connected to the relay UE 111 via or through a sidelink 112a which may be referred to as a PC5 hop or link or connection or interface 112a. Similarly, remote UE 121, and remote UE 132 have PC5 hops, or links or connections or interfaces 121b, and 132b respectively with the relay UE 111, and relay UE 131. A Uu hop or link or connection or interface I l la connects the relay UE 111 to the gNB 101, while a Uu hop or link or connection or interface 131a and 131b respectively connect the relay UE 131 to the gNB 101 and the UE 131 to the gNB 102. PC5 connections are used for the relayed traffic of the remote UEs (112, 113, 121 and 132) and the non-relayed traffic specific to the relay UE 111, 131, i.e. for the direct communications between relay UE 111, 131 and the other remote UEs (112, 121 and 132). Therefore, the remote UE 112 is connected to the gNB 101 through the relay UE 111 with a PC5 hop 112a and a Uu hop I l la. For uplink communication, the remote UE 112 is the source node (or transmitter node for transmitting data) and the gNB 101 is the destination or target node (or receiver node for receiving data) for a sidelink relay connection established between the remote UE 112 and the gNB 101 with a PC5 hop 112a and a second Uu hop I l la and for downlink communication, the remote UE 112 is the destination or target node (or receiver node) and the gNB 101 is the source node (or transmitter node). Similarly, the remote UE 132 is connected to the gNB 102 through the relay UE 131 with a PC5 hop 132b and a Uu hop 131b. The remote UE 113 for its part is connected to the gNB 101 through the relay UE 112 with a 1^st PC5 hop 113a and then through the relay UE 111 with a 2^nd PC5 hop 112a and a Uu hop I l la. It will be appreciated that the terms first and second could be used in place of source and target.

At some point, the gNB 101 may decide to setup a multi-path to the UE 132. For example, to maintain the QoS despite an increase of the applicative traffic to transmit/receive from/to the UE 132. Then, based on some information such as measurement information received from the different UEs (relay, remote) in, for example, measurement reports and/or measurements made by the gNB 101 itself, the source gNB 101 may decide to add an additional path either a direct path (link 132b) or a new indirect path through the relay UE 111 (links 132a and I l la) so as to set up a multi-path between the remote UE 132 and the network.

At some other point, the gNB 101, acting as a source gNB, may decide to hand over the relay UE 131 to the gNB 102, which would then act as a target gNB. For example, in the case where the radio conditions in the serving cell 101a controlled by the source gNB 101 deteriorate such that the radio conditions in the target cell 102a controlled by the target gNB 102 are better than the serving cell 101a, the source gNB 101 may decide to handover the relay UE 131 to the target gNB 102. In such a case, the relay UE 131 would detach from the source gNB 101, thereby releasing the Uu link 131a to further connect to the target gNB 102 through Uu link 131b established as part of a re-establishment procedure.

As mentioned earlier, the remote and relay UEs are attached to the core network 170 through their serving gNB (101 or 102 in figure 1). Figure 2 represents a typical 5G Proximitybased Services (ProSe) Relay reference architecture and shows the different connections between the core network entities of the 5G core (5GC) such as the Access and Mobility Management Function (AMF) entity, the Session Management Function (SMF) entity and the User Plane Function (UPF) entity, the UEs (5G ProSe Remote and 5G ProSe Relay) and the NG-RAN (i.e. base station or gNB). The 5G ProSe Remote UE and 5G ProSe Relay may be served by the same or different PLMNs (Public Land Mobile Network). If the serving PLMNs of the 5G Remote UE and the 5G ProSe Relay are different then the NG-RAN is shared by the serving PLMNs.

In order to set up a relayed traffic between a first node (remote UE) and a second node (gNB or remote UE), a Sidelink relay architecture may be used, based on the 3GPP TR 38.836. The user plane architecture or protocol stack is shown in Figure 3 and represents the Sidelink Relay adaptation layer called SRAP that is introduced between the PDCP layer and the RLC layer at the extreme nodes and above the RLC layer in the relay UE. This architecture was first documented in the TR 38.836 and finally refined in 3 GPP TS 38.300 while the SRAP layer is defined in 3GPP TS 38.351.

This architecture shown in Figure 3 shows the Sidelink relay architecture 300 for the multi-hop UE-to-Network relay scenario. As shown in Figure 3 illustrating a multi-hop UE-to- Network relay scenario, a remote UE 301, such as remote UE 113 of figure 1, has a PC5 SRAP layer or entity 311 between its Uu PDCP layer 312 and its PC5 RLC layer 313. Similarly, the gNB 304, such as gNB 101 of figure 1, has a Uu SRAP layer or entity 341 between its Uu PDCP layer 342 and its Uu RLC layer 343.

As shown in Figure 3 related to a multi-hop UE-to-Network relay scenario, at the relay UE 303, such as relay UE 111, there are two SRAP layers to interface with the PC5 hop 112a and the Uu hop I l la: the PC5 SRAP layer or entity 331 is connected to the PC5 SRAP 322 of a second relay UE 302 such as relay UE 112 through the PC 5 hop 112a; and the Uu SRAP layer or entity 332 is connected to the Uu SRAP layer 341 at the gNB side 101 through the Uu link I l la. The second relay UE 302 such as relay UE 112 has also two SRAP layers to interface with the PC5 hop 112a and the PC5 hop 113a: the PC5 SRAP layer or entity 322 is connected to the PC5 SRAP 331 of a first relay UE 303 such as relay UE 111 through the PC5 hop 112a; and the PC5 SRAP layer or entity 321 is connected to the PC5 SRAP layer 311 at the remote UE 303, such as remote UE 113 through the PC 5 link 113a.

A remote UE 301/113 establishes End-to-End radio bearers 305 with the gNB 304/101. These radio bearers could be a Signalling Radio Bearer SRB or Data Radio Bearer DRB. Figure 3 shows an E2E Uu DRB/SRB 305 between the remote UE 113 and the gNB 101 by way of example.

The PC5 SRAP layer 331 of the UE-to-Network relay UE 303/111 receives data or packets (traffic data or signalling) over or via ingress PC5 Relay RLC channels 352 through the PC5-RLC layer from remote UE 113 (at PC5 hop 112a) through a UE-to-UE relay UE 302/112 in an uplink direction and transmits the packets to the Uu SRAP entity 332 of the same relay UE 303/111. The Uu SRAP 332 entity will map the corresponding ingress PC5 Relay RLC channels 352 to egress Uu Relay RLC channels 353a and/or 353b at Uu link I l la. Thus, a mapping table is required for uplink and it is configured by gNB 101 at the Uu SRAP entity 332 of the relay UE 303/111.

The mapping table takes at its input an identifier of the remote UE 113 (e.g. L2-ID), an identifier of the E2E radio bearer 305 (e.g. the E2E Uu DRB ID) and an identifier of the ingress PC5 Relay RLC channel (or bearer) 352 and identifies the egress Uu Relay RLC bearer ID where the E2E radio bearers are mapped. For example, the UE E2E bearer ID and remote UE ID can be obtained from the header of a data packet received at the Uu SRAP entity 332 via the PC5-SRAP entity 331. An example of an entry for an uplink mapping table with one entry configured at the Uu SRAP entity 332 is shown in Table 1 below. It will be appreciated that the mapping table will be configured so that it has an entry for each remote UE connected to the relay UE 303/111.

Table 1

At the Uu side or link I l la, different radio bearers of the same remote UE or different remote UEs can be subject to N:1 mapping and data multiplexing over Uu RLC channels 353a and 353b.

In the downlink direction, data or packets transmitted from gNB 101 arrive at the relay UE 303/111 through the Uu link I l la. The Uu SRAP layer 332 of the UE-to-Network relay UE 111 receives data or packets (traffic data or signalling) over or via ingress Uu Relay RLC channels 353a and 353b through the Uu-RLC layer 343 from gNB 101 and transmits the packet to the PC5 SRAP entity 331 of the same relay UE 111. Those ingress Uu Relay RLC channels 353a and 353b will be mapped at the PC5 SRAP entity 331 of the relay UE 111 to the egress PC5 Relay RLC channels 352 at PC5 hop 112a. Thus, a mapping table is required for downlink and it is configured by the gNB 101 at PC5 SRAP entity 331 of the relay UE 111. The mapping table requires at its input the remote UE 113 L2-ID, the End-to-End radio bearer 305 ID and the ingress Uu Relay RLC channel (or bearer) 353a and 353b ID and identifies the egress PC5 Relay RLC channels (or bearer) 352 ID of the PC5 hop 112a. The End-to-End Radio bearer 305 is then mapped at the PC5 hop 112a to the egress PC5 Relay RLC channels 352. For example, the UE E2E bearer ID and remote UE ID can be obtained from the header of a packet received at the PC5 SRAP entity 331 via the Uu SRAP entity 332. An example of a downlink mapping table with one entry configured at the PC5 SRAP entity 331 is shown in Table 2 below. It will be appreciated that the mapping table will be configured so that it has an entry for each remote UE connected to the relay UE 303/111.

Table 2

Similarly, the UE-to-UE relay UE 302/112 maps the ingress PC5 RLC channel 351 to the egress PC5 RLC channel 352 and vice versa. Thereby, mapping tables is also required to determine the egress RLC channel based on the ingress RLC channel the Bearer ID and the UE ID. The mapping tables at the UE-to-UE relay UE 302/112 may be configured by the network.

It is noted that in case of multi-hop UE-to-Network, the mapping table at the UE-to- Network relay may map the ingress Uu Relay RLC channel to the egress End-to-End PC5 RLC channel used by the UE-to-Network relay UE 303/111 to connect to the remote UE 301/113 through the UE-to-UE relay UE 302/112.

As mentioned in 3GPP TS 38.351, each SRAP entity has a transmitting part and a receiving part. Across the PC5 interface 113a and 112a, the transmitting part of the PC5 SRAP entity 311 at the remote UE 301/113 and the transmitting part of the PC 5 SRAP entity 322 at the relay UE 302/112 has a corresponding receiving part respectively at PC5 SRAP entity 321 at the UE-to-UE relay 302/112 and at PC 5 SRAP entity 331 at the UE-to-Network Relay UE 303/111, and vice-versa. Across the Uu interface I l la, the transmitting part of the Uu SRAP entity 332 at the UE-to-Network Relay UE 303/111 has a corresponding receiving part at Uu SRAP entity 341 at the gNB 304/101, and vice-versa. To summarize, the transmitting part of each SRAP entity at the UE-to-Network Relay UE 111 receives the data packet with its SRAP header from its corresponding receiving part (receiving part of the SRAP entity 332 forwards the data to the transmitting part of the SRAP entity 331 and vice-versa). The transmitting part of each SRAP entity owns a mapping table configured by the gNB 101 which allows the identification of the egress RLC channel (at Uu or PC5 link) based on the ingress RLC channel where the data packet is received and the UE and Bearer IDs carried in the SRAP header. Specific mapping rules may be applied for SRBO and SRB1 as specified in TS38.351 and TS38.331.

In the case of the multi-path with one indirect and one direct path, the remote UE 113 and the gNB 101 may communicate with each other through both paths. Thereby, each node has two protocol stacks: one for the indirect path such as described above and one for the direct path. The split between the direct and/or the indirect path is performed at the PDCP layer of each node. For the direct path, in the downlink direction, data or packets transmitted from gNB 101 through the direct path arrive at the remote UE 113 via ingress Uu Direct Path RLC channel 354 of the Uu link 113b. On the other hand, in the uplink direction, data or packets transmitted from the remote UE 113 through the direct path arrive at the gNB 101 via ingress Uu Direct Path RLC channel 354 of the Uu link 113b.

Figure 4 shows a schematic representation of an example communication device or station, in accordance with one or more example embodiments of the present disclosure.

The communication device 400 may be a device such as a micro-computer, a workstation or a portable or mobile device. The communication device 400 comprises a communication bus 413 to which there are preferably connected: a central processing unit 411, such as a microprocessor, denoted CPU; memory for storing data and computer programs containing instructions for the operation of the communication device 400. The computer programs may contain a number of different program elements or sub-routines containing instructions for a variety of operations and for implementing the invention. For example, the program elements include at least one element for managing multi-path or multi-hop communication as discussed above. The at least one element when executed by the central processing unit 411 configure one or more processing units (e.g. functioning as or part of the CPU 411) to perform the method(s) as described above.

The communication device 400 may further comprise at least one communication interface 402 connected to the radio communication network 403 over which digital data packets or frames or control frames are transmitted, for example a 5G NR wireless communication network. The frames are written from a FIFO sending memory in RAM 412 to the communication interface 402 for transmission or are read from the communication interface 402 for reception and writing into a FIFO receiving memory in RAM 412 under the control of a software application running in the CPU 411.

Each of a UE and base station may comprise such a communication device 400. The central processing unit 411 may be a single processing unit or processor or may comprise two or more processing units or processors carrying out the processing required for the operation of the communication device 400. The number of processing units or processors and the allocation of processing functions to the processing unit(s) is a matter of design choice for a skilled person.

The memory may include: a read only memory 407, denoted ROM, for storing computer programs for implementing methods according to embodiments of the invention; a random-access memory 412, denoted RAM, for storing the executable code of methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the invention.

Optionally, the communication device 400 may also include the following components: a data storage means 404 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention; a disk drive 405 for a disk 406, the disk drive being adapted to read data from the disk 406 or to write data onto said disk; a screen 409 for displaying decoded data and/or serving as a graphical interface with the user, by means of a keyboard 410 or any other user input means.

Preferably the communication bus 413 provides communication and interoperability between the various elements included in the communication device 400 or connected to it. The representation of the bus 413 is not limiting and in particular, the central processing unit is operable to communicate instructions to any element of the communication device 400 directly or by means of another element of the communication device 400.

The disk 406 may optionally be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables a method according to embodiments of the invention to be implemented.

The executable code may optionally be stored either in read only memory 407, on the hard disk 404 or on a removable digital medium such as for example a disk 406 as described previously. According to an optional variant, the executable code of the programs can be received by means of the communication network 403, via the communication interface 402, in order to be stored in one of the storage means of the communication device 400, such as the hard disk 404, before being executed.

The central processing unit 411 is preferably adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 404 or in the read only memory 407, are transferred into the random-access memory 412, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.

In an example implementation, the communication device may be or may include an apparatus comprising one or more processing units or processors for performing or implementing the methods in accordance with one or more embodiments of the invention. In other words, the apparatus is capable of performing one or more functions of the communication device including performing the methods in accordance with one or more embodiments of the invention by means of the one or more processing units. For example, the one or more processing units uses software to implement the one or more embodiments of the invention as described above with reference to the central processing unit 411 of figure 4. Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, a CPU of a microcontroller Unit (MCU), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated (e.g. on an Integrated Circuit) or discrete logic circuitry. In an embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the one or more processing units for performing or implementing the methods in accordance with embodiments of the present invention may be implemented in hardware: for example, in the form of an Application Specific Integrated Circuit or ASIC or other hardware comprising logic element (s). In such a case, logic units or logic elements or means are configured to perform the steps of the method(s) in accordance with the present invention described above. Accordingly, the term “processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein.

Referring now to figure 8 which is a flow chart showing steps of a method 800 for managing or facilitating relay communication (or a method for managing relay communication with integrated discovery in multi-hop relay) in a wireless communication system supporting relaying. The wireless communication system includes a plurality of User Equipment, UE. The method is performed at a UE (e.g. a UE that can operate/act as a relay UE or is a target/end UE for U2U communication) of the plurality of UEs. The wireless communication system may be, for example, the wireless communication system 100 of Figure 1. With respect to the example shown in Figure 1, the UE may be UE 123, 122 or 121 in the case where multi-hop communication is to be established between first UE 124 (source/initiating remote UE) and a second UE 121 (target UE) or the UE could be UE 161 which is in the vicinity of UE 124. The method 800 as shown in and described with respect to figure 8 may be performed by software elements and/or hardware elements. Thus, for example, the method as shown in and described with respect to figure 8 may be performed by an apparatus for the UE comprising one or more processing units configured to carry out the method. The UE may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 8 being performed by one or more processing units, such as the central processing unit 411.

A hop is a link or connection between two UEs in which case the hop is a PC5 hop or between a UE and a base station in which case the hop is a Uu hop.

Briefly, at step 801, the UE, such as UE 123, receives a request, such as a Direct Communication Request 502 or a link modification request, for establishing a connection to the UE 123 for multi-hop communication between a first UE (e.g. source or initiating remote UE), such as UE 124, of the plurality of UEs and a second UE (e.g. target UE or target remote UE) , such as UE 121, of the plurality of UEs. The request includes maximum hop information, such as the maxHop indication discussed below with reference to figures 5 to 7) indicating a value associated with a maximum number of hops between the first UE and the second UE supported or allowed or permitted or accepted by the first UE. The request may be received at the UE from the first UE 124 (e.g. in the case where the UE is UE 123 receiving a request from UE 124 in the examples shown in figures 5 to 7) or from another relay UE (e.g. in the case where the UE is UE 122 receiving a request from UE 123 in the examples shown in figures 5 to 7). In the case where the UE is UE 123, the maximum number of hops received at the UE 123 corresponds to the maximum number of hops supported by the UE 124. In the case where the UE is UE 122, the maximum number of hops received at the UE 122 may corresponds to an updated maximum number of hops (e.g. which has been updated based on the number of hops the request has crossed before being received at the UE 122).

The request may further include at least one of identification information for identifying the second UE (for example, the identification information may be Destination Layer-2 ID of target UE indicating the unicast destination Layer-2 ID of the target UE determined by the source remote UE. It may be set to a default value if the remote UE does not have this information); preference information (such as the multi-hop connection preference as discussed below with reference to figures 5 to 7) for indicating the preference of the remote UE relating to multi-hop communication between the first UE and the second UE; relay indication (e.g. the Relay indication as discussed below with reference to figures 5 to 7) for indicating whether a relay UE can forward the request; hop information (e.g. Hop count as discussed below with reference to figures 5 to 7) for indicating the number of hops crossed or passed (e.g. the number of relay UEs crossed or passed) by the request from the first UE; relay UE information (e.g. RelayUE Info as discussed below with reference to figures 5 to 7) for providing information associated with one or more UEs crossed by the request; security information (e.g. the Security Information discussed below with reference to figures 5 to 7) including information for establishment of security for the next hop link establishment; RRC information (e.g. RRCcontainer as discussed below with reference to figures 5 to 7) for indicating RRC information for establishing a connection for the first UE.

The relay information may include for each UE of the one or more UEs crossed by the request at least one of: identification information for identifying the UE (e.g. L2-ID); link quality of the request received by the UE (e.g. PC5 link quality or ingress link quality/signal strength, such as Reference Signal Received Power, RSRP).

In an example where the UE receiving the request receives the request from the first UE, such as UE 123 or UE 161 receiving the request from first UE or remote UE 124, the UE determines whether the request can be forwarded by the UE (123/161). The UE 123 or 161 may determine whether it can forward the request or not based on the maxHop indication and/or the relay indication when included in the request and/or Hop count when included in the request and/or based on link quality of the PC5 link to the first UE (e.g. ingress link to the UE 123/161). If the maximum number of hops has not been reached and the link quality of the PC5 link is above a threshold (or within a range between a minimum threshold and a maximum threshold), and/or if the request includes the relay indi cation and the link quality of the PC5 link is above a threshold (or within a range between a minimum threshold and a maximum threshold), then the request can be forwarded. In the example discussed below, the UE 123 can forward the request but the UE 161 cannot.

After determining the request can be forwarded by the UE 123 acting as a relay UE, the UE acting as a relay UE may update information in the received request to account for the hop between the first UE 124 and the UE 123 to provide an updated request. The updating may include one or more of: updating the maximum hop information (maxHop info); updating the hop information if included (e.g. the Hop count); removing relay indication if included and the UE is the last hop before the target or second UE (which is the case for UE 122); including identification information for the UE and/or link quality of the request in the received request, such as by updating the relay UE information (e.g. RelayUE Info) if included in the request to include information associated with the UE such as the identifier of the UE 123 and link quality information (e.g. signal strength of the request received at the UE 123). The UE 123 sends or forwards, to each of one or more other UEs (e.g. neighbouring UEs or UEs in the vicinity of the UE, such as UE 122 or 121 for UE 123), the updated request for establishing a connection for multi -hop communication between the first UE and the second UE or target UE.

In an example where the UE receiving the request receives the request from each of one or more other UEs, which other UEs are acting as relay UEs, such as from UE 161 in 503 for UE 123, from UE 123 in 504 for UE 122 and UE 121, from UE 122 in 505 for UE121, the UE receiving the request determines whether the request can be forwarded. The UE may determine whether it can forward the request or not based on the maxHop indication and/or the relay indication when included in the request and/or Hop count when included in the request and/or based on link quality of the PC5 link to the first UE (e.g. ingress link to the UE) as discussed above. The UE may also determine whether it can forward the request based on the capability of the UE to act as a U2U or U2U multi-hop and/or whether the UE is authorized to act as a U2U or multi-hop U2U relay.

After determining the request can be forwarded by the UE acting as a relay UE , (e.g. UE 122 decides it can forward the request received from UE 123 in 504), the UE 122 acting as a relay UE may update, for each request received that can be forwarded, information in the request received from the respective other relay UE to account for the hop between the respective other UE and the UE to provide an updated request. The updating of the request in this case can be as discussed above. The UE 122 sends or forwards, to each of one or more additional other UEs (e.g. neighbouring UEs or UEs in the vicinity of the UE, such as UE 121), the updated request for establishing a connection for multi-hop communication between the first UE and the second or target UE. In the example shown in the figures, the UE 122 only receives a request from UE 123 and so only updates this request before sending the updated request to UE 121 in 505.

After the UE 122 sends or forwards, to each of one or more additional other UEs (e.g. neighbouring UEs or UEs in the vicinity of the UE, such as UE 121), the request (e.g. updated request), the UE may receive an accept message from one of the one or more additional other UEs. For example, the UE 123 may receive an accept message (such as the Direct Communication Accept message 512) from UE 121 or may receive an accept message (such as the Direct Communication Accept message 722) from UE 122 in the case where UE 122 had previously received an accept message (such as the Direct Communication Accept message 712) from UE 121. After receiving the accept message, the UE 122 may select (e.g. as per next hop selection step 520 as discussed below) as a next hop, based on the requests received at the UE, one of one or more other relay UEs in the case where the UE has received (e.g. previously received) requests from each of the one or more other relay UEs and the first UE in the case where the UE has received a request from the first UE. The selection may be based on signal strength or link quality of the request received from the one or more other relay UEs (and/or number of hops to the other relay UEs). For example, the UE 122 may select the relay UE for the next hop which had sent a request to the UE 122 with the highest signal strength. The selection may also be based on the connection preference provided by the remote UE 124 through the Direct Communication Request or the Direct Communication Accept.

After the UE 122 sends or forwards, to each of one or more additional other UEs (e.g. neighbouring UEs or UEs in the vicinity of the UE, such as UE 121), the request (e.g. updated request), the UE may receive an accept message from one of the one or more additional other UEs. The accept message (such as the Direct Communication Accept message 512, 522 in figure 6) may include information associated with all node in a communication path (e.g. the one or more relay UEs and the first UE/remote UE in the path) for use in multi-hop communication between the first UE and the second UE. In this case, the UE sends an accept message to the relay UE next in the communication path or the first UE in the case where the UE is the last relay UE in the communication path.

The UE may add user information (such as User Info ID as discussed below) to the accept message before sending the accept message: e.g. the UE may add identification information for identifying the UE.

In an example where the UE receiving the request receives the request from each of one or more other UEs, which other UEs are acting as relay UEs, such as from UE 122 in 505 for UE121, the UE receiving the request determines it is a target UE (e.g. the second UE) based on target identification information (e.g. target ID) included in the request. In this case, the UE (e.g. the target UE 121) stops forwarding the request. The target UE 121 may then select (e.g. relay selection 510, 710 in the figures) one of the one or more other relay UEs based on the requests received from the one or more other relay UEs and send an accept message (such as the Direct Communication Accept message 512) to the selected relay UE. For example, the selection may be based on signal strength or link quality of the request received from the one or more other relay UEs (and/or number of hops to the other relay UEs) as discussed above. In another example, the target UE 121 may then select a communication path (e.g. path selection 610, 710 in the figures) between the first UE 124 and the second UE/target UE 121 based on the requests received from the one or more other relay UEs and send an accept message (such as the Direct Communication Accept message 512) to the relay UE next in the selected communication path. For example, the selection may be based on signal strength or link quality of the request received from the one or more other relay UEs (and/or number of hops to the other relay UEs) as discussed above.

The accept message may include information associated with all nodes in the communication path for use in multi-hop communication between the first UE and the second UE/target UE. The information associated with all nodes may include information indicating the position of each node in the communication path.

The accept message may include identification information (e.g. User Info ID as discussed below) for identifying the second UE/target UE.

Referring now to also to figure 9 which is a flow chart showing steps of a method 900 for managing or facilitating relay communication (or a method for managing relay communication with integrated discovery in multi-hop relay) in a wireless communication system. The wireless communication system includes a plurality of User Equipment, UE and a network including one or more base stations. The method is performed at a relay UE (e.g. a UE that can operate/act as a relay UE or is a target/end relay UE or target U2N relay UE for U2N communication) of the plurality of UEs. The wireless communication system may be, for example, the wireless communication system 100 of Figure 1. With respect to the example shown in Figure 1, the UE may be UE 123, 122 or 121 in the case where multi-hop communication is to be established between first UE 124 (remote UE or source remote UE) and a base station or gNB which may be gNB 101 and where relay UE 121 is the target/end relay UE or target U2N relay UE, or the UE could be UE 161 which is in the vicinity of UE 124 and the base station. The method 900 as shown in and described with respect to figure 9 may be performed by software elements and/or hardware elements. Thus, for example, the method as shown in and described with respect to figure 9 may be performed by an apparatus for the UE comprising one or more processing units configured to carry out the method. The UE may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 9 being performed by one or more processing units, such as the central processing unit 411. Briefly, at step 901, the relay UE, such as relay UE 123, receives a request, such as a Direct Communication Request or a link modification request, for establishing a connection to the relay UE 123 for multi -hop communication between a first UE (e.g. source remote UE), such as UE 124, of the plurality of UEs and a base station, such as gNB 101 (e.g. where a target relay UE or target U2N relay UE, such as UE 121, is in coverage of the base station). The request includes network connection information (e.g. Nw connection indication as discussed below with reference to figures 5 to 7) for indicating the first UE requests or is looking for a connection to the network.

The request may further include at least one of maximum hop information, such as the maxHop indication discussed below with reference to figures 5 to 7) indicating a value associated with a maximum number of hops between the first UE and the base station supported or allowed or permitted or accepted by the first UE; identification information for identifying one or more possible target relay UEs in the coverage of a base station of the network (for example, the identification information may be Destination Layer-2 ID of the target relay UE indicating the unicast destination Layer-2 ID of the target UE determined by the source remote UE. It may be set to a default value if the remote UE does not have this information); preference information (such as the multi-hop connection preference as discussed below with reference to figures 5 to 7) for indicating the preference of the remote UE relating to multi-hop communication between the first UE and the network; relay indication (e.g. the Relay indication as discussed below with reference to figures 5 to 7) for indicating whether a relay UE can forward the request; hop information (e.g. Hop count as discussed below with reference to figures 5 to 7) for indicating the number of hops crossed or passed (e.g. the number of relay UEs crossed or passed) by the request from the first UE; relay UE information (e.g. RelayUE Info as discussed below with reference to figures 5 to 7) for providing information associated with one or more UEs crossed by the request; security information (e.g. the Security Information discussed below with reference to figures 5 to 7) including information for establishment of security for the next hop link establishment; RRC information (e.g. RRCcontainer as discussed below with reference to figures 5 to 7) for indicating RRC information for establishing a connection for the first UE; setup request command (e.g. SetupRequestCommand as discussed below) for initiating RRC connection.

The relay information may include for each UE of the one or more UEs crossed by the request at least one of identification information for identifying the UE (e.g. L2-ID); link quality of the request received by the UE (e.g. PC5 link quality or ingress link quality/signal strength, such as Reference Signal Received Power, RSRP). The steps performed at the relay UE, such as updating, sending, receiving/sending accept message(s), adding user information to the accept message, etc. are substantially the same or similar to the steps performed at the UE as discussed above with respect to figure 8 and will not be repeated here for expediency.

In this case, the target UE is not the second UE but a target relay UE or U2N relay UE. In an example where the UE receiving the request receives the request from each of one or more other UEs, which other UEs are acting as relay UEs, such as from UE 122 in 505 for UE 121, the UE receiving the request determines it is a target relay UE (e.g. a target relay UE or U2N relay UE) based on target identification information (e.g. target ID) included in the request or after determining it is in coverage of a base station or gNB of the network (e.g. gNB 101). In this case, the relay UE (e.g. the target relay UE 121) stops forwarding the request.

After receiving a request from each of one or more other relay UEs and in the case where the relay UE is in a non-connected RRC state and is a target relay UE or U2N relay UE and the relay UE has determined to accept the request to establish multi-hop communication between the first UE and the base station, the relay UE initiates establishing a RRC connection (e.g. the relay UE 121 performs RRC Resume/Setup procedure of step 550 as discussed below) with the base station to enter a connected RRC state based on one of network connection information and setup request command included in the request. More details can be found below with reference to step 550.

The target relay UE 121 may then select (e.g. relay selection 510, 710 in the figures) one of the one or more other relay UEs based on the requests received from the one or more other relay UEs and send an accept message (such as the Direct Communication Accept message 512) to the selected relay UE as discussed above. For example, the selection may be based on signal strength or link quality of the request received from the one or more other relay UEs (and/or number of hops to the other relay UEs) as discussed above. In another example, the target relay UE 121 may then select a communication path (e.g. path selection 610, 710 in the figures) between the first UE 124 and the target relay UE 121 or U2N relay UE 121 based on the requests received from the one or more other relay UEs and send an accept message (such as the Direct Communication Accept message 512) to the relay UE next in the selected communication path. For example, the selection may be based on signal strength or link quality of the request received from the one or more other relay UEs (and/or number of hops to the other relay UEs) as discussed above.

After receiving a request including network connection information, the relay UE 121 may send a reject response indicating the request for establishing a connection for multi -hop communication between the first UE and the base station has been rejected in the case where the relay UE is a target UE (e.g. target relay UE or U2N relay UE) and at least one of the following conditions is met: the target UE does not support UE-to-Network relaying; the target UE does not support multi-hop (e.g. the target UE does not have multi-hop capability); the target UE is out of coverage of the base station; the target UE is not authorised to register in a requested PLMN. The reject response may include cause information for indicating a cause for rejection. For example, the cause information could be carried in the PC5 signalling protocol cause or PC5 signalling protocol cause 2 specified in the TS24.554. The cause could be a generic one such as “Direct Communication to the target UE not allowed” or “Required service not allowed” or it could be more specific like “multi-hop not supported” or “Communication path over Uu is not available” or “PLMN not allowed” or “Maximum Number of Hop reach” if the UE cannot forward the Direct Communication Request due to the limitation of the number of hops. The reject response may be one of a direct communication reject included in a direct communication reject message or a link modification reject included in a link modification reject message as discussed below.

In the case where the relay UE is connected to another relay UE in the coverage of the base station, the relay UE may send a request to the another relay UE for establishing a connection for multi -hop communication between the first UE and the base station. The request may include at least one of information for indicating the request is to add the first UE to an existing connection; identification information for identifying the first UE; information for indicating the relay UE is to act as a UE-to-Network relay. The request may be a link modification request included in a link modification request message as discussed below. The another relay UE may send a link modification accept message in response indicating the request for establishing a connection for multi-hop communication between the first UE and the base station has been accepted.

Referring now to figure 10 which is a flow chart showing steps of a method 1000 for managing or facilitating relay communication (or a method for managing relay communication with integrated discovery in multi-hop relay) in a wireless communication system supporting relaying. The wireless communication system includes a plurality of User Equipment, UE. The method is performed at a first UE (e.g. a remote UE) of the plurality of UEs. The wireless communication system may be, for example, the wireless communication system 100 of Figure 1. With respect to the example shown in Figure 1, the UE may be UE 124 in the case where multi-hop communication is to be established between first UE 124 (source/initiating remote UE) and a second UE 121 (target UE). The method 1000 as shown in and described with respect to figure 10 may be performed by software elements and/or hardware elements. Thus, for example, the method as shown in and described with respect to figure 10 may be performed by an apparatus for the UE comprising one or more processing units configured to carry out the method. The UE may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 10 being performed by one or more processing units, such as the central processing unit 411.

Briefly, at step 1001, the first UE, such as UE 124, sends a request, such as a Direct Communication Request 502 or a link modification request, for establishing a connection for multi-hop communication between the first UE (e.g. source or initiating remote UE), such as UE 124, and a second UE (e.g. target UE or target remote UE), such as UE 121, of the plurality of UEs. The request includes maximum hop information, such as the maxHop indication discussed below with reference to figures 5 to 7) indicating a value associated with a maximum number of hops between the first UE and the second UE supported or allowed or permitted or accepted by the first UE. The request may be sent to each of one or more UEs of the plurality of UEs (e.g. those UEs in the vicinity of or neighbouring the first UE 124), such as UEs 123 and 161 in the examples shown in figures 5 to 7).

A first value for the maximum number of hops may be configured at the first UE 124 by a network of the wireless communication system. The maximum hop information included in the request may indicate the first value or may indicate a second value set or selected by the first UE, where the second value is less than the first value. The first UE 124 may set the second value based on at least one of requirements of an application of the remote UE; level of Quality of Service, QoS, required. For example, as discussed below with reference to figures 5-7, the first UE may want to minimise the number of hops if an application (e.g. requiring the multihop communication) is latency dependent, and quality is not high. If low latency is not required and a high level of QoS is desired or required, e.g. a low packet error rate is required/desired, having a higher max number of hops may be desired.

The first UE 124 may receive an accept message for indicating the request sent by the first UE has been accepted for a communication path between the first UE and the second UE including at least two relay UEs (e.g. Direct Communication Accept message 522, 732).

The first UE 124 may receive two or more accept messages indicating the request sent by the first UE has been accepted for two or more communication paths. In this case, the first UE 124 selects one of the two or more communication paths and sends a release message to release the other of the two or more communication paths so that only one path is kept and the other paths are released (e.g. including all of the nodes in the communication path). The release message may include information associated with all nodes involved in the other of the two or more communication paths so that these nodes may be released.

After receiving an accept message indicating the request sent by the first UE 124 has been accepted or after selecting one of the two or more communication paths, the first UE 124 establishes an end-to-end connection (e.g. as per step 530 as discussed below) with the second UE 121.

Referring now to also to figure 11 which is a flow chart showing steps of a method 1100 for managing or facilitating relay communication (or a method for managing relay communication with integrated discovery in multi-hop relay) in a wireless communication system supporting relaying. The wireless communication system includes a plurality of User Equipment, UE and a network including one or more base stations. The method is performed at a first UE (e.g. a remote UE) of the plurality of UEs. The wireless communication system may be, for example, the wireless communication system 100 of Figure 1. With respect to the example shown in Figure 1, the UE may be UE 124 in the case where multi-hop communication is to be established between first UE 124 (remote UE or source remote UE) and a base station or gNB which may be gNB 101 and where relay UE 121 is the target/end relay UE or target U2N relay UE. The method 1100 as shown in and described with respect to figure 11 may be performed by software elements and/or hardware elements. Thus, for example, the method as shown in and described with respect to figure 11 may be performed by an apparatus for the UE comprising one or more processing units configured to carry out the method. The UE may be implemented in a communication device 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 11 being performed by one or more processing units, such as the central processing unit 411.

Briefly, at step 1101, the first UE, such as UE 124, sends a request, such as a Direct Communication Request or a link modification request, for establishing a connection for multihop communication between the first UE (e.g. source remote UE), such as UE 124, and a base station, such as gNB 101 (e.g. where a target relay UE or target U2N relay UE, such as UE 121, is in coverage of the base station). The request includes network connection information (e.g. Nw connection indication as discussed below with reference to figures 5 to 7) for indicating the first UE requests or is looking for a connection to the network.

The request may further include additional information such as that discussed above with respect to figure 9.

The steps performed at the first UE, such as receiving accept message(s), selecting, sending a release message, establishing end-to-end connection (e.g. as per step 530) adding user information to the accept message, setting a value for the maximum number of hops, etc. are substantially the same or similar to the steps performed at the UE as discussed above with respect to figure 10 and will not be repeated here for expediency.

Referring now to Figures 5, 6 and 7 which are a schematic and simplified diagram illustrating an example of message flows for managing a UE-to-UE Relay communication with integrated discovery in a wireless communication system, such as that shown in figure 1, for managing an End to end connection establishment between a remote UE and a target UE involving several Relay UEs, in accordance with one or more embodiments of the invention.

Figure 5 illustrates one embodiment of the invention wherein the target UE, such as UE 121 of figure 1, and each intermediate relay UE(s), such as relay UEs 123, 122, perform a selection of the next hop destination. In the case shown in figure 5, there are two PC5 hops between the remote UE 124 and the target UE 121. UE-to-UE Relay communication for both U2U and U2N multi-hop communication will be described.

Figure 6 illustrates one embodiment of the invention wherein the target UE performs a path selection: that is to say the target UE selects all the intermediate relay UE(s) to connect the source remote UE, such as UE 124 of figure 1 to the target UE, such as UE 121 of figure 1. In the case shown in figure 6, there are two PC5 hops between the remote UE and the target UE. UE-to-UE Relay communication for both U2U and U2N multi-hop communication will be described.

Figure 7 illustrates one embodiment of the invention wherein the target UE performs a relay selection (as in figure 5) or a path selection (as in figure 6): that is to say the target UE selects all the intermediate relay UE(s) to connect the source remote UE, such as UE 124 of figure 1 to the target UE, such as UE 121 of figure 1. In the case shown in figure 7, there are three PC5 hops between the remote UE and the target UE. UE-to-UE Relay communication for both U2U and U2N multi-hop communication will be described.

The same elements (e.g. steps, messages, frames, entities, nodes, etc.) in figures 6 and 7 as those in figure 5 are referenced by the same reference numbers. The description of elements in figure 5 can be applied to the same elements shown in figures 6 and 7 and will not be repeated for these figures 6 and 7. Any differences between the figures are highlighted by different reference numerals and are discussed below.

For UE-to-UE Relay Communication with integrated Discovery in accordance with one or more embodiments of the present invention, when a UE (e.g. a first UE such as UE 124 of figures 5-7) allows a UE-to-UE relay to be involved in the Direct Communication Request to another UE (e.g. a second UE or target UE such as UE 121) for multi -hop communication (e.g. U2U multi -hop communication), the UE 124 indicates it by, for example, including a relay indication in the broadcasted Direct Communication Request message. Additionally or alternatively to the relay indication, the UE 124 includes a hop indication (e.g. maxHop indication, maxHop indication + hop count) which aims at limiting the number of relays or relay UEs the Direct Communication Request can go through.

When a UE-to-UE relay, such as one or more of relay UEs 161, 123, 122 of figures 5-7, receives a Direct Communication Request (e.g. including a relay indication), it decides whether to forward the message according to or based on a maxHop indication. The UE-to- UE relay may also decide whether to forward the message based on one or more of the following information: Relay Service Code if there is any, Application ID, operator policy per Relay Service Code, signal strength, link quality, and local policy. Such information can indicate requirements, such as one or more of latency, Quality of Service (QoS), packet delay budget, packet error rate, link quality required for the multi -hop communication requested. The decision can therefore be based on the capability of the UE-to-UE relay to meet the requirements. The decision can also be based on the capability of the UE to act as a relay for multi-hop (U2U or U2N) or if it is authorized to act as a relay.

In another aspect, when the UE-to-UE Relay Communication with integrated discovery is used by a UE (e.g. a first UE such as UE 124 of figures 5-7) to establish a connection with the network (e.g. gNB such as gNB 101) for multi -hop communication or a UE-to-Network multi-hop, the UE indicates that the communication aims to connect to a gNB by including a nw connection indication (e.g. Nw connection indication or network connection information) in the broadcasted Direct Communication Request message. This indication may be used in complement of the maxHop indication or independently. In the latter case when the nw connection indication is included in the message and not the maxHop indication, when a UE receives a Direct Communication Request including a nw connection indication, it decides to stop forwarding the message if it can act as a U2N relay UE or in other words if it can offer a connection to the network, either as it is already connected to a gNB or if it is in coverage of a gNB. For example, when UE 121 is in coverage of gNB 101, UE 121 can act as a U2N relay UE, and in such a case on receipt of a message including a Nw_connection_indication, the U2N relay UE 121 can decide to stop forwarding the message (irrespective of the hop count). If the U2N relay UE 121 is in a non-connected RRC state (e.g. idle or inactive), the receipt of the Direct Communication Request may act as a trigger for the U2N relay UE 121 to enter the RRC connected state.

In one example, a remote UE (or first UE), like remote UE 124, wants to establish a communication with the target UE (or second UE), like the UE 121 and broadcasts a Direct Communication Request 502. For example, the remote UE 124 wants to establish multi-hop communication between the remote UE 124 of first UE 124 and a target UE or second UE. It is noted that for U2U multi-hop communication, the remote UE (or first UE), such as UE 124, may be referred to as source/initiating UE or source/initiating remote UE and the target UE (or second UE), like UE 121 is the target UE.

In one aspect, the Direct Communication Request includes all or part of the following information elements or information:

- Relay indication indicates whether the relay can forward the Direct Communication Request message or not. It is also used to limit the number of hops of the relay by removing relay indication in the Direct Communication Request message from the relay. maxHop indication indicates the maximum number of hops that the Direct Communication Request could be forwarded. The value of this maximum hop information could be set according to the gNB configuration and/or constraints of the remote UE. For instance, the remote UE constraints may relate to QoS such as the latency; the remote UE may limit the maximum number of hops to achieve requirements of a low latency application. In one aspect, this value may be decremented by one by the relay UE when it forwards the Direct Communication Request. In that case, the hop count could be optional.

- Hop count indicates the number of hops (relay UEs) crossed by the Direct Communication Request. This value is incremented by the relay UE when it forwards the Direct Communication Request. In an example, this indication may be present only when relay indication is present.

- RelayUE Info contains a list of the relay UEs crossed by the Direct Communication Request. This list contains the UE ID of the different relay UEs and the PC5 signal strength (ingress link quality) of the respective Direct Communication Request received by the relay UE identified by the UE ID. This information element is populated by the different relay UEs.

- Nw connection indication indicates that the remote UE is looking for a connection to the network. This information may also be included through a Target Service Code (similar to the Relay Service Code for the relay) which indicates the connectivity service (e.g. U2N) provided by the Target UE as requested by the source remote UE.

Security Information contains the information for the establishment of security for the next hop PC5 link establishment (this security information includes the nonce of the UE transmitting the Direct Communication Request).

User Info ID of the remote UE for identifying the remote UE. This information is obtained from the application or from the ProSe application server that allocates it.

- User Info ID of the target UE for identifying the target UE. This information may be obtained from the upper layer (application) or from discovery or former connection or from the ProSe application server that allocates it.

- Destination Layer-2 ID of target UE indicates the unicast destination Layer-2 ID of the target UE determined by the source remote UE. May be set to a default value if the remote UE does not have this information.

- Multi-hop connection preferences. This information indicates the preferences of the remote UE for the multi -hop connection. For example, the preference could be set to the value latency or quality, meaning the connection would minimize the number of hops for latency sensitive application or try to improve the overall link quality to minimize the Error Rate. The preference could also include information to specify the preferred maximum number of hops that could be equal or different from the maxHop indication, the Packet Delay Budget, the Packet Error Rate (PER) and so on. These information could be used by the target UE to set the QoS information in Direct Communication Accept message.

RRCcontainer: This information indicates RRC information received from RRC layer. The information may include element(s) to help the target UE to establish a connection to its serving gNB for the remote UE. This container may include part or all the element of RemoteUEInformationSidelink defined in TS38.331.

SetupRequestCommand: This information may be used by the target UE (acting as a U2N) to transfer the RRCSetupRequest (as defined in TS38.331) command as generated by the remote UE to the gNB to initiate the RRC connection.

The Direct Communication Request 502 broadcasted as a Direct Communication Request message by the remote UE (e.g. first UE such as UE 124) is received by the UE(s) in its vicinity. In the example of the figure 1, the UEs 161 and 123 (e.g. Relay UE1 161 and relay UE2 123 in figures 5-7), receive the Direct Communication Request message 502. When receiving the Direct Communication Request with relay indication from remote UE 124, each of the UEs (i.e. Relay UE1 161 and RelayUE2 123) may decide to participate in the procedure and broadcast a Direct Communication Request message in its proximity. To participate in the procedure, each of the UEs 161 and 123 checks whether it supports U2U relaying function (reuse of the Release 18 capability), or multi -hop U2U (new capability) capabilities, and whether it is authorized to act as a U2U or multi-hop U2U relay. This authorization may be provided by the network during the step 501. For example, step 501 is a service authorization and parameter provisioning procedure such as that described in 3GPP TS23.304 clause 6.2. After determining the UE can support U2U or multi-hop U2U relaying (e.g. it can operate/act as a relay UE), then, to know whether the Direct Communication Request message to be sent from the relay UE should also include the relay indication, the relay evaluates the remaining hops based on the maxHop indication and the hop count from the received Direct Communication Request message. When the hop count becomes equal to the value of the maxHop indication -1, the relay UE broadcasts a Direct Communication Request without relay indication otherwise if the hop count is lower than the maxHop indication -1, the relay UE broadcasts a Direct Communication Request with relay indication. The relay UE includes an updated value (incremented by one) of the hop count in its Direct Communication Request message. In a variant, the maxHop indication is used alone to evaluate the remaining hops. In that case, the maxHop indication directly represents the remaining allowed hops. Thus, when the maxHop indication value is equal to 1, the relay UE broadcasts a Direct Communication Request without relay indication otherwise if the maxHop indication is higher than the value 1, the relay UE broadcasts a Direct Communication Request with relay indication. The relay UE includes an updated value (decremented by one) of the maxHop indication in its Direct Communication Request message.

In another variant, the RelayUE Info is finite (i.e. the list has a predefined number of UE) and when a relay UE fills the last position of the list, it means that the next hop is the last hop and the Direct Communication Request is sent without the relay-indication.

Even if there is no limitation on the maximum number of hops, it could be useful to include information (e.g. hop information) relative to the hop count as a criterion for the relay selection (or path selection as illustrated by the figure 6). Besides, this hop count may also be useful for the QoS breakdown and more specifically for the sharing of the overall Packet Delay Budget through the different hops.

The relay UE also updates the RelayUE Info by adding its UE ID and optionally the PC5 signal strength linked to the received Direct Communication Request message (i.e. an information about the ingress link quality with the emitter (e.g. UE 124 or relay UE 123 when the relay UE 122 receives a Direct Communication request from the relay UE 123) of the Direct Communication Request message). The Relay UE also evaluates the ingress link quality to know whether it can forward the Direct Communication Request message or not. Thereby, if the ingress link quality threshold for the discovery is not configured, or if the link quality (SL- RSRP) of the Direct Communication Request message with integrated Discovery received from the Source Remote UE is available and is above the configured threshold (if configured), the relay UE can forward the Direct Communication Request message.

After the evaluation of the ingress link quality and the remaining hop, both the relay UE1 161 and the relay UE2 123 decide as shown in the example of figure 5 to forward the Direct Communication Request message with relay indi cation as Direct Communication requests (respectively 503 and 504). For example, the Direct Communication requests 503 and 504 include the Direct Communication request received from the remote UE 124 updated as indicated above.

When receiving the Direct Communication Request message 503 from the relay UE1 161, the relay UE2 123 decides not to forward it as the ingress link quality of the message 503 was below the ingress link quality threshold for the discovery as explained above. When receiving the Direct Communication Request message 504 from the relay UE2 123, the relay UE3 122 in its turn evaluates the ingress link quality i.e. the PC5 signal strength of the Direct Communication Request message received from the relay UE2 and the remaining hop. As the ingress link quality satisfies the configured threshold, the relay UE3 122 can forward the Direct Communication Request message. However, as the remaining hop is equal to the value 1 (e.g. in the case shown in the examples of figures 5 and 6 where the maximum hop count is 3), the relay UE 122 forwards the Direct Communication Request message 505 without the relay indication. It also updates RelayUE info by adding its UE ID and optionally the PC5 signal strength linked to the received Direct Communication Request message.

When the target UE 121 receives a Direct Communication Request from one or multiple Relays (e.g. relay UEs) including its identity as target UE, target UE stops to forward the Direct Communication Request and selects a Relay UE to which target UE 121 will respond. Thus, in step 510, the target UE 121 may select the Relay UE to which the target UE 121 will respond according to the signal strength of the Direct Communication Request message received from the multiple relays. In the case of the path selection as illustrated by the figure 6, the target UE 121 may also use the RelayUE info included in the different received Direct Communication Request to select a path (i.e. all relays used to connect the target UE to the source UE) suitable for the application requirements. For instance, minimizing the number of hops to minimize the latency or maximizing the overall signal or link quality (select the better quality for each hop) to minimize the Packet Error Rate etc..

Once the target has selected a suitable relay (relay UE2 123 in the examples of the figures 5 and 6), it may establish the security 511 with the selected relay for this link, if needed.

Target UE 121 replies Direct Communication Accept message 512 to the selected relay UE e.g. relay UE2 123. The Direct Communication Accept message 512 includes the User Info ID of the target UE 121. In the example of the path selection illustrated by the figure 6, the Direct Communication Accept message contains all the relays to be used to connect the target UE 121 to the remote UE 124. The list may contain the relay UEs sorted in order or with a field indicating the position of the relay in the path (e.g. in the communication path). For example, the accept message sent by the target UE 121 includes information associated with all the relay UEs in the communication path which are to be used to connect the target UE 121 to the remote UE 124.

Then, the relay UE receiving the Direct Communication Accept message 512 in its turn, selects the next hop addressee (520), either another relay UE or the source remote UE, in order for direct communication to be established. As, at the target UE, the relay selection or more generally next hop selection is performed according to the signal strength of the Direct Communication Request message received from the multiple nodes (relays and/or remote UE). Once the relay has selected a suitable node for the next hop selection (remote UE 124 in the example of the figure), it may establish the security 521 with the selected node for this link, if needed. In the variant of the path selection illustrated by the figure 6, the Direct Communication Accept message carries the list of the relay UE(s), therefore, the Next Hop selection is performed by retrieving the next destination node from the message.

Relay UE2 123 responds with Direct Communication Accept message 522 to the remote UE 124. The Direct Communication Accept message 522 includes the User Info ID of the relay UE in addition to the User Info ID for the target UE (received in the Direct Communication Accept from the target UE). It is noted that each new relay UE add its User Info ID in the Direct Communication Accept in order for the remote UE to know the full path. The User Info ID of the relays may be carried in an information element like the RelayUE Info included in the Direct Communication Request.

When receiving the Direct Communication Accept message 522, the remote UE (e.g. UE 124) establishes an end-to-end connection with the target UE through the intermediate relay UE(s), for instance relay UE2 123 in the examples of the figures 5 and 6. For the end-to-end connection, the PC5-S messages (such as Direct Communication Request or Direct Communication Accept) use Signalling Radio Bearer dedicated to the relay operation. Those SRBs are subject to the mapping table as described with reference to the figure 3 which allows the mapping from the ingress to the egress RLC channel in the relay UE.

It is worth noting that if a UE is already connected with the target UE, for instance, the Relay UE2 123 has an active PC5 connection with the target UE 121, the UEs 123 and 121 may use the link modification procedure to support the connection with the remote UE (e.g. UE 124). To do so, the Relay UE2 123 sends a Link Modification Request message to the target UE (rather than a Direct Communication Request). This message includes a Link Modification operation code to indicate that this link modification is to add a new UE (e.g. remote UE 124) to the existing direct link and the identity of the new UE (e.g. the identity of the remote UE 124) via the Source end UE info Information Element. The target UE (e.g. UE 121) responds to this Link Modification Request message with a Direct Link Modification Accept message. In addition, the Link Modification Request message may include all or parts of the information listed for the Direct Communication Request. In another example, a remote UE, like remote UE 124, wants to establish a communication with the network. For example, the remote UE 124 wants to establish multihop communication between the remote UE 124 and a base station or gNB (such as gNB 101) of the network. As the remote UE is not in the coverage of any gNB i.e. it does not receive any signal from a gNB (see for example UE 124 in figure 1), it decides to broadcast a Direct Communication Request with integrated discovery (i.e. including the Nw connection indication and may also include the relay indication as discussed above): this Direct Communication Request message may include the identity of a U2N relay UE 121 (e.g. the identity of the target relay UE 121). The identity of the U2N relay UE could be provided by the upper layers (application) or through a discovery protocol or a former connection. Otherwise, the message may include a default identity and when a UE capable to act as a UE to Network Relay (to offer a connection to a gNB and so to the network) receives a Direct Communication Request including the Nw connection indication, it will stop forwarding the Direct Communication Request and responds with a Direct Communication Accept as described above.

Back to the example of the figure 5 and in the case where the remote UE 124 wants to establish a communication with the network, the remote UE 124 broadcasts a Direct Communication Request message 502 including the Direct Communication request, the Direct Communication Request includes all or part of the following information elements or information:

- Nw connection indication indicates that the remote UE is looking for a connection to the network. This information may also be included through a Target Service Code (similar to the Relay Service Code for the relay) which indicates the connectivity service provided by the Target UE as requested by the source remote UE.

User Info ID of the remote UE for identifying the remote UE. This information is obtained from the application or from the ProSe application server that allocates it..

- User Info ID of the target UE. This information may be obtained from the upper layer (application) or from discovery or former connection or from the ProSe application server that allocates it.

RRCcontainer: This information indicates RRC information received from RRC layer. The information may include element to help the target UE to establish a connection to its serving gNB for the remote UE. This container may include part or all element of RemoteUEInformationSideilink defined in TS38.331.

SetupRequestCommand: This information may be used by the target UE (acting as a U2N) to transfer the SetupRequest command as generated by the remote UE to the gNB to initiate the RRC connection.

The Direct Communication Request 502 broadcasted in a Direct Communication Request message by the remote UE (e.g. first UE such as UE 124) is received by the UE(s) in its vicinity. In the example of the figure 1, the UEs 161 and 123 (e.g. Relay UE1 161 and relay UE2 123 in figures 5-7) receive the Direct Communication Request message 502. When receiving Direct Communication Request with relay indication and nw connection indication from remote UE 124, each of the UEs (i.e. Relay UE1 161 and RelayUE2 123) may decide to participate in the procedure and broadcast a Direct Communication Request message in its proximity. To do so, the relay assesses whether it can act as a UE to Network Relay i.e. if it supports U2N (reuse of the Release 17 capability), or multi -hop U2N (new capability) capabilities, if it is authorized to act as a U2N or multi-hop U2N relay and if it is in coverage of a gNB (e.g. gNB 101). This authorization may be provided by the network during the step 501.

As the relay UE 161 is out of coverage, but may act as a UE to UE relay, it forwards the Direct Communication Request as described above, if the ingress link quality (e.g. SL-RSRP of the received Direct Communication Request) is above a threshold. Thus, in the example of the figure 5, both the relay UEs (UE1 161 and the relay UE2 123) decide to forward the Direct Communication Request message with relay indi cation as Direct Communication requests (respectively 503 and 504). For example, the Direct Communication requests 503 and 504 include the Direct Communication request received from the remote UE 124 updated as discussed above.

When receiving the Direct Communication Request message 503 from the relay UE1 161, the relay UE2 123 decides not to forward it as the ingress link quality of the message 503 was below the ingress link quality threshold for the discovery.

When receiving the Direct Communication Request message 504 from the relay UE2 123, the relay UE3 122 in its turn evaluates the ingress link quality, i.e. the PC5 signal strength of the Direct Communication Request message received from the relay UE2 123, the remaining hop(s) to the network, its different capabilities and whether it is in coverage. Similar to the relay UE1 161, the relay UE3 122 is out if coverage of a gNB (e.g. gNB 101) but may act as a UE to UE relay. Consequently, it forwards the Direct Communication Request message 505.

The relay UE 121 is in coverage of gNB 101 and so is a UE-to-Network relay UE. When the UE-to-Network relay UE 121 receives a Direct Communication Request from one or multiple Relays or relay UEs including its identity as target UE, UE-to-Network relay UE 121 stops forwarding the Direct Communication Request and selects a Relay UE to which UE-to- Network relay UE 121 will respond.

In a variant, the Direct Communication Request includes a wildcard for the target UE identity (default value) and the nw connection indication. Thus, as the UE-to-Network relay UE 121 is able to offer a connection to the remote UE 124 to reach the network (it owns the capability, the authorization and it is in coverage), the UE-to-Network relay UE 121 stops forwarding the Direct Communication Request and selects a Relay UE to which UE-to- Network relay UE 121 will respond.

When receiving the Direct Communication Request including the nw connection indication, in the case the target UE 121 does not support U2N or multi -hop capability or is out-of-coverage, or is not authorized to register in the requested PLMN, the target UE 121 may respond with a Direct Communication Reject with a status code indicating the reason of the rejection. This cause could be carried in the PC5 signalling protocol cause or PC5 signalling protocol cause 2 specified in the TS24.554. The cause could be a generic one such as “Direct Communication to the target UE not allowed” or “Required service not allowed” or it could be more specific like “multi-hop not supported” or “Communication path over Uu is not available” or “PLMN not allowed” or “Maximum Number of Hop reach” if the UE cannot forward the Direct Communication Request due to the limitation of the number of hops.

Thus, in step 510, the target UE 121 may select the Relay UE to which the target UE 121 will respond according to the signal strength of the Direct Communication Request message received from the multiple relays. In the case of the path selection as illustrated by the figure 6, the target UE 121 may also use the RelayUE info included in the different received Direct Communication Request to select a path (i.e. all relays used to connect the target UE to the source UE) suitable for the application requirements. For instance, minimizing the number of hops to minimize the latency or maximizing the overall signal quality (select the better quality for each hop) to minimize the Packet Error Rate etc..

Once the target has selected a suitable relay (relay UE2 123 in the examples of the figures 5 and 6), it may establish the security 511 with the selected relay for this link, if needed. Target UE 121 replies Direct Communication Accept message 512 to the selected relay UE e.g. relay UE2 123. The Direct Communication Accept message 512 includes the User Info ID of the target UE 121. In the example of the path selection illustrated by the figure 6, the Direct Communication Accept message contains all the relays to be used to connect the target UE 121 to the remote UE 124. The list may contain the relay UEs sorted in order or with a field indicating the position of the relay in the path. (e.g. in the communication path). For example, the accept message sent by the target UE 121 includes information associated with all the relay UEs in the communication path which are to be used to connect the target UE 121 to the remote UE 124.

Then, the relay UE receiving the Direct Communication Accept message 512 in its turn, selects the next hop addressee (520), either another relay UE or the source remote UE, in order the direct communication to be established. As, at the target UE, the relay selection or more generally next hop selection is performed according to the signal strength of the Direct Communication Request message received from the multiple nodes (relays and/or remote UE). Once the relay has selected a suitable node for the next hop selection (remote UE 124 in the example of the figure), it may establish the security 521 with the selected node for this link, if needed. In the variant of the path selection illustrated by the figure 6, the Direct Communication Accept message carries the list of the relay UE(s), therefore, the Next Hop selection is performed by retrieving the next destination node from the message.

Relay UE2 123 responds with Direct Communication Accept message 522 to the remote UE 124. The Direct Communication Accept message 522 includes the User Info ID of the relay UE in addition to the one for the target UE (received in the Direct Communication Accept from the target UE). It is noted that each new relay UE adds its User Info ID in the Direct Communication Accept in order for the remote UE to know the full path. The User Info ID of the relays may be carried in an information element like the RelayUE info included in the Direct Communication Request. The knowledge of the full path may be used by the remote UE to release the complete path with a Direct Communication Release Request. The Direct Communication Release Request may include the RelayUE info and each node involved in the path (included in the RelayUE info) may release their PC5 connection used in the path.

When receiving the Direct Communication Accept message 522, the remote UE (e.g. remote UE 124) establishes an end-to-end connection 530 with the target UE through the intermediate relay UE(s), for instance relay UE2 123 in the examples of the figures 5 and 6. For the end-to-end connection, the PC5-S messages (such as Direct Communication Request or Direct Communication Accept) use Signalling Radio Bearer dedicated to the relay operation. Those SRBs are subject to the mapping table as described with reference to the figure 3 which allows the mapping from the ingress to the egress RLC channel in the relay.

It is worth noting that if a UE is already connected with the target UE. For instance, the Relay UE2 123 has an active PC5 connection with the target UE 121, the UEs 123 and 121 may use the link modification procedure to support the connection with the remote UE 124. To do so, the Relay UE2 123 sends a Link Modification Request message to the target UE 121 (rather than a Direct Communication Request). This message includes a Link Modification operation code to indicate that this link modification is to add a new UE (remote UE) to the existing direct link, the identity of the new UE being provided via the Source end UE info Information Element and that the target UE should act as a UE-to-Network relay. The target UE responds to this Link Modification Request message with a Direct Link Modification Accept message. In addition, the Link Modification Request message may include all or parts of the information listed for the Direct Communication Request.

When receiving the Link Modification Request, in the case the target UE 121 does not support U2N or multi-hop capability or is out-of-coverage, or is not authorized to register in the requested PLMN, the target UE 121 may respond with a Link Modification Reject with a status code indicating the reason of the rejection. This cause could be carried in the PC5 signalling protocol cause or PC5 signalling protocol cause 2 specified in the TS24.554. The cause could be a generic one such as “Direct Communication to the target UE not allowed” or “Required service not allowed” or it could be more specific like “multi-hop not supported” or “Communication path over Uu is not available” or “PLMN not allowed” or “Maximum Number of Hop reach”.

When the UE-to-Network relay UE 121 receives a Direct Communication Request message including a nw connection indication and decides to accept the request by sending a Direct Communication Accept message, the UE-to-Network relay UE in a non-connected RRC state (RRC IDLE or RRC INACTIVE) may start to enter in RRC CONNECTED state. Thereby, the reception of the Direct Communication Request with a nw connection indication is a trigger for the U2N relay to enter in RRC_CONNECTED state. When triggered, the U2N relay UE 121 attempts to establish a RRC connection with the base station 101. To do so, the relay UE 121 follows the RRC Resume or RRC setup procedures as defined in the TS 38.331 respectively clause 5.3.13 and 5.3.3. The RRC Resume/Setup is illustrated by the message or frame exchange 550.

Then, the base station 101 may send to the relay UE 121, that has just entered in RRC CONNNECTED state, a RRC Reconfiguration which includes the Remote UE identifier (Local and L2 ID), the RLC layer configuration (Uu and PC5 RLC channel configuration for relaying) and the SRAP configuration (the bearer mapping configuration) as discussed above with reference to the figure 3. The relay UE 121 configures its different layers according to the RRC Reconfiguration message to enable its relaying functionality. Then, the relay UE 121 sends as a response to the base station 101 a RRC Reconfiguration Complete message.

In a variant, when the UE-to-Network relay UE 121 receives a Direct Communication Request message including a SetupRequest command and decides to accept the request by sending a Direct Communication Accept message, the UE-to-Network relay UE 121 forwards the RRCSetupRequest included in the SetupRequest command (or forward the command itself) to its serving gNB to initiate the connection of the remote UE. If the U2N relay UE 121 is not in RRC CONNECTED, it needs to do its own Uu RRC connection establishment upon reception of a Direct Communication Request included the SetupRequest command. Therefore, the reception of a Direct Communication Request including the SetupRequest command may also trigger a target UE in a non-connected RRC state (RRC IDLE or RRC IN ACTIVE) to enter in RRC CONNECTED state as described above.

In a variant, when the UE-to-UE Relay Communication with integrated discovery is used to establish a connection with the network (e.g. gNB) or a UE-to-Network multi-hop with a limitation of two PC5 hops plus one Uu hop, the Direct Communication Request may only include the relay indication and the nw connection indication. The relay indication is used to limit to two the number of PC5 hops. Thereby, a relay receiving a Direct Communication Request with a relay indication from a remote UE, forwards the Direct Communication Request without the relay indication. And the target UE receiving a Direct Communication Request with a nw connection indi cation will try to establish a Uu connection with its serving gNB and responds to the Direct Communication Request message by a Direct Communication Accept message.

In the case where several U2N relay responds with a Direct Communication Accept to the remote UE or if the remote UE receives Direct Communication Accept for different paths, the remote UE may send a Direct Communication Release Request in order to keep only one path. This message may include a cause to specify that this path or relay UE or target UE is not selected or is no longer needed. This message may also include all the nodes involved in the path in order to release each hop of the path.

The figures 5 and 6 may illustrate the case where the remote UE indicates its preferences to minimize the number of hops by setting for instance Multi-hop connection preferences to the latency value. As a result, the target and the intermediate relay UEs select the path in order to minimize the number of hops. Back to the example of the figure 1, this results by the UE 121 responding directly to the UE 123. In the example of the figure 7, it can be assumed that the remote UE 124 indicates its preferences to minimize the overall link quality by setting for instance Multi-hop connection preferences to the quality value. As a result, the target and the intermediate relay UEs select the path in order to maximize the quality of the multi-hop connection. Back to the example of the figure 1, this results by the UE 121 responding to the UE 122 and the UE 122 to the UE 123. In the examples of the figures 5 and 6, the multi -hop PC5 is limited to 2 hops while the number of PC5 hops is equal to 3 for the figure 7.

While the above description uses an enhanced version of the Direct Communication procedure, we assume that a new signalling achieving the same results could be envisioned. For instance, we could use a new Direct Communication For U2N multi -hop procedure with a Direct Communication For U2N multi -hop Request and a Direct Communication For U2N multi -hop Accept (or Reject). This new procedure dedicated to a network connection would not require for example the nw connection indication.

The above description uses the terms Direct Communication Request, Direct Communication Accept, Link Modification Request and Link Modification Accept, however this could be replaced respectively by the terms Direct Link Establishment Request and Direct Link Establishment Accept, Direct Link Modification Request and Direct Link Modification Accept.

While the present invention has been described with reference to embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.

Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non- transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer- readable medium.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method for managing relay communication in a wireless communication system supporting relaying, the wireless communication comprising a plurality of User Equipment, UEs, the method at a UE of the plurality of UEs including: receiving a request for establishing a connection to the UE for multi-hop communication between a first UE of the plurality of UEs and a second UE of the plurality of UEs, the request including maximum hop information indicating a value associated with a maximum number of hops between the first UE and the second UE supported by the first UE.

2. The method of claim 1, wherein the request further includes at least one of: identification information for identifying the second UE; preference information for indicating the preference of the remote UE relating to multihop communication between the first UE and the second UE; relay indication for indicating whether a relay UE can forward the request; hop information for indicating the number of hops crossed by the request from the first UE; relay UE information for providing information associated with one or more UEs crossed by the request; security information including information for establishment of security for the next hop link establishment;

RRC information for indicating RRC information for establishing a connection for the first UE.

3. The method of claim 2, wherein the relay UE information includes for each UE of the one or more UEs crossed by the request at least one of: identification information for identifying the UE; link quality of the request received by the UE.

4. The method of any one of the preceding claims, wherein receiving a request includes receiving, from the first UE, a request for establishing a connection to the UE for multi-hop communication between the first UE and the second UE.

5. The method of claim 4, further including: after determining the request can be forwarded by the UE acting as a relay UE, updating information in the received request to account for the hop between the first UE and the UE to provide an updated request; sending, to each of one or more other UEs, the updated request for establishing a connection for multi-hop communication between the first UE and the second UE.

6. The method of claim 5, wherein updating the request further includes: including identification information for the UE in the received request.

7. The method of claim 5 or claim 6, wherein updating the request further includes: including link quality of the request received by the UE in the received request.

8. The method of claim 7, wherein including in the received request, comprises including at least the identification information in relay UE information for providing information associated with each relay UE crossed by the request.

9. The method of any one of claims 1 to 3, wherein receiving a request includes receiving, from each of one or more other UEs acting as relay UEs, a request for establishing a connection to the UE for multi-hop communication between the first UE and second UE.

10. The method of claim 9, further including: after determining the request from at least one of the one or more other relay UEs can be forwarded by the UE, for each request received that can be forwarded, updating information in the request received from the respective other relay UE to account for the hop between the respective other UE and the UE to provide an updated request; sending, to each of one or more additional other UEs, the updated request for each request received that can be forwarded for establishing a connection for multi-hop communication between the first UE and the second UE.

11. The method of claim 10, wherein updating the request includes: including identification information for the UE in the received request.

12. The method of claim 10 or claim 11, wherein updating the request includes: including link quality of the request received by the UE in the received request.

13. The method of claim 11 or claim 12, wherein including in the received request, comprises including at least the identification information for the relay UE in relay UE information included in the received request, the relay UE information for providing information associated with each relay UE crossed by the request.

14. The method of any one of claims 10 to 13, wherein in the case where the received request includes a relay indication for indicating whether a relay UE can forward the request, updating the request further includes removing the relay indication from the received request in the case where the next hop is the last hop between the first UE and the second UE.

15. The method of any one of claims 10 to 14, the method further including: after sending the updated request to one or more additional other UEs, receiving an accept message from one of the one or more additional other UEs; selecting as a next hop, based on the requests received at the UE, one of one or more other relay UEs in the case where the UE has received requests from each of the one or more other relay UEs and the first UE in the case where the UE has received a request from the first UE; sending an accept message to the selected next hop.

16. The method of any one of claims 10 to 14, the method further including: after sending a request to one or more additional other UEs, receiving an accept message from one of the one or more additional other UEs, the accept message including information associated with all nodes in a communication path for use in multi -hop communication between the first UE and the second UE; sending an accept message to the relay UE next in the communication path or the first UE in the case where the UE is the last relay UE in the communication path.

17. The method of claim 15 or claim 16, the method further including: after receiving an accept message, adding user information identification information for the UE to the accept message to provide an updated accept message; wherein sending an accept message includes sending the updated accept message.

18. The method of claim 9, further including: after receiving a request from each of one or more other relay UEs and in the case where the UE is the second UE, stopping forwarding the request.

19. The method of claim 18, further comprising: selecting one of the one or more other relay UEs based on the requests received from the one or more other relay UEs; sending an accept message to the selected relay UE.

20. The method of claim 18, further comprising: selecting a communication path between the first UE and the second UE based on the requests received from the one or more other relay UEs; sending an accept message to the relay UE next in the selected communication path.

21. The method of claim 20, wherein the accept message includes information associated with all nodes in the communication path for use in multi-hop communication between the first UE and the second UE.

22. The method of claim 16 or claim 21, wherein the information associated with all nodes include information indicating the position of each node in the communication path.

23. The method of any one of claims 15 to 22, wherein the accept message includes user information identification information for the second UE.

24. The method of claim 9, further including: after receiving a request from each of one or more other relay UEs and in the case where the UE is the second UE, sending a reject response indicating the request for establishing a connection for multi-hop communication between the first UE and the second UE has been rejected in the case where the UE is the second UE and at least one of the following conditions is met: the second UE does not support UE-to-UE relaying; the second UE does not support multi-hop.

25. The method of claim 24, wherein the reject response includes cause information for indicating a cause for rejection.

26. A method for managing relay communication in a wireless communication system supporting relaying, the wireless communication comprising a plurality of User Equipment, UEs, and a network including one or more base stations, the method at a relay UE of the plurality of UEs including: receiving a request for establishing a connection to the relay UE for multi-hop communication between a first UE of the plurality of UEs and a base station of the network via the relay UE, wherein the request includes network connection information for indicating the first UE requests connection to the network.

27. The method of claim 26, wherein the request further includes at least one of: maximum hop information indicating a value associated with a maximum number of hops between the first UE and the base station supported by the first UE; identification information for identifying one or more UEs of the plurality of UEs in coverage of a base station of the network; preference information for indicating the preference of the first UE relating to multi-hop communication between the first UE and the network; setup request command for initiating RRC connection; relay indication for indicating whether a relay UE can forward the request; hop information for indicating the number of hops crossed by the request from the first UE; relay UE information for providing information associated with one or more UEs crossed by the request; security information including information for establishment of security for the next hop link establishment;

28. The method of claim 27, wherein the relay UE information includes for each UE of the one or more UEs crossed by the request at least one of: identification information for identifying the UE; link quality of the request received by the UE.

29. The method of any one of claims 26 to 28, wherein receiving a request includes receiving, from the first UE, a request for establishing a connection to the relay UE for multi-hop communication between the first UE and the base station.

30. The method of claim 29, wherein performing an action includes: after determining the request can be forwarded by the relay UE, updating information in the received request to account for the hop between the first UE and the relay UE to provide an updated request; sending, to each of one or more other UEs, the updated request for establishing a connection for multi-hop communication between the first UE and the base station.

31. The method of claim 30, wherein updating the request further includes: including identification information for the relay UE in the received request.

32. The method of claim 30 or claim 31, wherein updating the request further includes: including link quality of the request received by the relay UE in the received request.

33. The method of claim 32, wherein including in the received request, comprises including at least the identification information in relay UE information for providing information associated with each relay UE crossed by the request.

34. The method of any one of claims 26 to 28, wherein receiving a request includes receiving, from each of one or more other relay UEs, a request for establishing a connection to the relay UE for multi-hop communication between the first UE and the base station.

35. The method of claim 34, further including: after determining the request from at least one of the one or more other relay UEs can be forwarded by the relay UE, for each request received that can be forwarded, updating information in the request received from the respective other relay UE to account for the hop between the respective other UE and the relay UE to provide an updated request; sending, to each of one or more additional other UEs, the updated request for each request received that can be forwarded for establishing a connection for multi-hop communication between the first UE and the base station.

36. The method of claim 35, wherein updating the request further includes: including identification information for the relay UE in the received request.

37. The method of claim 35 or claim 36, wherein updating the request further includes: including link quality of the request received by the relay UE in the received request.

38. The method of claim 36 or claim 37, wherein including in the received request, comprises including at least the identification information for the relay UE in relay UE information included in the received request, the relay UE information for providing information associated with each relay UE crossed by the request.

39. The method of any one of claims 35 to 38, wherein in the case where the received request includes a relay indication for indicating whether a relay UE can forward the request, updating the request further includes removing the relay indication from the received request in the case where the next hop is the last hop between the first UE and the base station.

40. The method of any one of claims 35 to 39, further including; after sending a request to one or more additional other UEs, receiving an accept message from one of the one or more additional other UEs; selecting as a next hop, based on the requests received at the UE, one of one or more other relay UEs in the case where the UE has received requests from each of the one or more other relay UEs and the first UE in the case where the UE has received a request from the first UE; sending an accept message to the selected next hop.

41. The method of any one of claims 35 to 39, the method further including: after sending a request to one or more additional other UEs, receiving an accept message from one of the one or more additional other UEs, the accept message including information associated with all nodes in a communication path for use in multi -hop communication between the first UE and the base station; sending an accept message to the relay UE next in the communication path or the first UE in the case where the relay UE is the last relay UE in the communication path.

42. The method of claim 40 or claim 41, the method further including: after receiving an accept message, adding user information identification information for the relay UE to the accept message to provide an updated accept message; wherein sending an accept message includes sending the updated accept message.

43. The method of claim 34, further including: after receiving a request from each of one or more other relay UEs and in the case where the relay UE is a target UE, stopping forwarding the request.

44. The method of claim 34, further including: after receiving a request from each of one or more other relay UEs and in the case where the relay UE is in a non-connected RRC state and is a target UE and determining to accept the request to establish multi-hop communication between the first UE and the base station, initiating establishing a RRC connection with the base station to enter a connected RRC state based on one of network connection information and setup request command included in the request.

45. The method of claim 43 or claim 44, further comprising: selecting one of the one or more other relay UEs based on the requests received from the one or more other relay UEs; sending an accept message to the selected relay UE.

46. The method of claim 43 or claim 44, further comprising: selecting a communication path between the first UE and the target UE based on the requests received from the one or more other relay UEs; sending an accept message to the relay UE next in the selected communication path.

47. The method of claim 46, wherein the accept message includes information associated with all nodes in the communication path for use in multi-hop communication between the first UE and the base station.

48. The method of claim 41 or claim 47, wherein the information associated with all nodes include information indicating the position of each node in the communication path.

49. The method of any one of claims 40 to 48, wherein the accept message includes user information identification information for the target UE.

50. The method of claim 34, wherein after receiving a request including network connection information, sending a reject response indicating the request for establishing a connection for multi -hop communication between the first UE and the base station has been rejected in the case where the relay UE is a target UE and at least one of the following conditions is met: the target UE does not support UE-to-Network relaying; the target UE does not support multi-hop; the target UE is out of coverage of the base station; the target UE is not authorised to register in a requested PLMN.

51. The method of claim 50, wherein the reject response includes cause information for indicating a cause for rejection.

52. The method of claim 50 or claim 51, wherein the reject response is one of a direct communication reject included in a direct communication reject message or a link modification reject included in a link modification reject message.

53. The method of any one of claims 35 to 42, wherein in the case where the relay UE is connected to another relay UE in the coverage of the base station, sending a request includes sending a request to the another relay UE for establishing a connection for multi-hop communication between the first UE and the base station, wherein the request includes at least one of: information for indicating the request is to add the first UE to an existing connection; identification information for identifying the first UE; information for indicating the relay UE is to act as a UE-to-Network relay.

54. The method of claim 53, wherein the request is a link modification request included in a link modification request message.

55. The method of claim 54, after sending a link modification request, receiving from the another relay UE a link modification accept included in a link modification accept message indicating the request for establishing a connection for multi-hop communication between the first UE and the base station has been accepted.

56. A method for managing relay communication in a wireless communication system supporting relaying, the wireless communication comprising a plurality of User Equipment, UEs, the method at a first UE of the plurality of UEs including: sending a request for establishing a connection for multi-hop communication between the first UE and a second UE of the plurality of UEs, wherein the request includes maximum hop information for indicating a value for a maximum number of hops between the first UE and the second UE supported by the first UE.

57. The method of claim 56, wherein the request further includes at least one of: identification information for identifying the second UE; preference information for indicating the preference of the first UE relating to multi-hop communication between the first UE and the second UE.

58. The method of claim 56 or claim 57, further including: receiving an accept message for indicating the request sent by the first UE has been accepted for a communication path between the first UE and the second UE including at least two relay UEs.

59. The method of any one of claims 56 to 58, further including: receiving two or more accept messages indicating the request sent by the first UE has been accepted for two or more communication paths; after selecting one of the two or more communication paths, sending a release message to release the other of the two or more communication paths.

60. The method of claim 59, wherein the release message includes information associated with all nodes involved in the other of the two or more communication paths.

61. The method of any one of claims 58 to 60, further including: after receiving an accept message indicating the request sent by the first UE has been accepted or after selecting one of the two or more communication paths, establishing an end- to-end connection with the second UE.

62. A method for managing relay communication in a wireless communication system supporting relaying, the wireless communication comprising a plurality of User Equipment, UEs, and a network including one or more base stations, the method at a first UE of the plurality of UEs including: sending a request for establishing a connection for multi-hop communication between the first UE and a base station of the network, wherein the request includes network connection information for indicating the first UE requests connection to the network.

63. The method of claim 62, wherein the request further includes at least one of: maximum hop information for indicating a value for a maximum number of hops between the first UE and a base station supported by the first UE; identification information for identifying one or more UEs of the plurality of UEs in coverage of a base station of the network; preference information for indicating the preference of the remote UE relating to multihop communication between the first UE and the network.

64. The method of claim 62 or claim 63, further including: receiving an accept message for indicating the request sent by the first UE has been accepted for a communication path between the first UE and the base station including at least two relay UEs.

65. The method of any one of claims 62 to 64, further including: receiving two or more accept messages indicating the request sent by the first UE has been accepted for two or more communication paths; after selecting one of the two or more communication paths, sending a release message to release the other of the two or more communication paths.

66. The method of claim 65, wherein the release message includes information associated with all nodes involved in the other of the two or more communication paths.

67. The method of any one of claims 64 to 66, further including: after receiving an accept message indicating the request sent by the first UE has been accepted or after selecting one of the two or more communication paths, establishing an end- to-end connection with the base station.

68. The method of any one of the claims 56 to 67, wherein the request includes at least one of: relay indication for indicating whether a relay UE can forward the request; hop information for indicating the number of hops crossed by the request from the first UE; security information including information for establishment of security for the next hop link establishment;

RRC information for indicating RRC information for establishing a connection for the first UE; setup request command for initiating RRC connection.

69. The method of any one of claims 56 to 61 or claim 63, wherein the maximum hop information indicates a value for the maximum number of hops, the value being greater than two.

70. The method of any one of claims 56 to 61 or claim 63 or claim 69, wherein the value for the maximum number of hops is configured at the first UE by a network of the wireless communication system.

71. The method of any one of claims 56 to 61 or claim 63 or claim 69, wherein a first value for the maximum number of hops is configured at the first UE by a network of the wireless communication system, wherein the maximum hop information included in the request indicates a second value set by the first UE, the second value being less than the first value.

72. The method of claim 71, wherein the second value is set based on at least one of: requirements of an application of the remote UE; level of Quality of Service, QoS, required.

73. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the control method according to any one of claims 1 to 72.

74. A computer-readable medium carrying a computer program according to claim 73.

75. Apparatus for a User Equipment, UE, for a wireless communication system supporting relaying between a remote UE and a network including a base station, the apparatus comprising: one or more processing units and configured to perform the method as recited in any one of claims 1 to 72.