Connection Establishment for UE-to-UE Relay

A method of connection establishment for UE-to-UE relay in a cellular communication system is proposed. A sidelink interface is used for two remote UEs to communicate directly with a relay UE, and in which the relay UE forwards communications between the remote UEs to allow end-to-end communication between the remote UEs. In one embodiment, a first remote UE initiates a single Direct Communication (DC) Request that triggers the establishment of multiple connections between the first remote UE and the relay UE, and between a second remote UE and the relay UE, such that end-to-end relayed transport is available between the first and second remote UE, with hop-by-hop security. The first and second remote UE can make use of the end-to-end relayed transport to authenticate and establish end-to-end secured connection.

TECHNICAL FIELD

The disclosed embodiments relate generally to wireless network communications, and, more particularly, to UE-to-UE sidelink relaying in 5G new radio (NR) wireless communications systems.

BACKGROUND

In 3GPP LTE cellular networks, an evolved universal terrestrial radio access network (E-UTRAN) includes a plurality of base stations, e.g., evolved Node-Bs (eNodeBs or eNBs) communicating with a plurality of mobile stations referred as user equipment (UEs). New technologies in 5G new radio (NR) allow cellular devices to connect directly to one another using a technique called sidelink communications. Sidelink is the new communication paradigm in which cellular devices are able to communicate without their data via the network. The sidelink interface may also be referred to as a PC5 interface. A variety of applications may rely on communication over the sidelink interface, such as vehicle-to-everything (V2X) communication, public safety (PS) communication, direct file transfer between user devices, and so on.

In a sidelink UE-to-network relaying architecture, a relay UE is served directly by a network node such as an eNB (LTE) or a gNB (NR), and the relay UE offers service over a sidelink interface to one or more remote UEs. In some other cases, however, there may be a need for two UEs to communicate when they do not have direct visibility to each other over the sidelink interface (for example, due to being out of range with one another, or due to the intervention of an obstacle to radio frequency propagation). In these cases it may be beneficial for a third UE to provide relayed communication between the first and second UEs. In this situation, the third UE may be referred to as a relay UE, and the first and second UEs as remote UEs, endpoint UEs, etc. Such an arrangement may be described as a UE-to-UE relay (contrasted with a UE-to-network relay, in which a relay UE provides relaying of traffic between a remote UE and network infrastructure).

For UE-to-UE relay, there is a need for a procedure that allows the remote UEs to initially establish communication with the relay UE, followed by using the connectivity through the relay UE to establish a logical connection that allows direct communication between the remote UEs.

SUMMARY

A method of connection establishment for UE-to-UE relay in a cellular communication system is proposed. A sidelink interface is used for two remote UEs to communicate directly with a relay UE, and in which the relay UE forwards communications between the remote UEs to allow end-to-end communication between the remote UEs. The methods described are applicable to both layer 2 (L2) and layer 3 (L3) relaying architectures, in which the traffic to be relayed is carried at either L2 or L3 of a protocol stack. In one embodiment, a first remote UE initiates a single Direct Communication (DC) Request that triggers the establishment of multiple connections between the first remote UE and the relay UE, and between a second remote UE and the relay UE, such that end-to-end relayed transport is available between the first and second remote UE, with hop-by-hop security (that is, security applied separately to the “first hop” between the first remote UE and the relay UE and the “second hop” between the second remote UE and the relay UE). The first and second remote UE can make use of the end-to-end relayed transport to authenticate and establish end-to-end secured connection.

DETAILED DESCRIPTION

FIG. 1illustrates a wireless cellular communications system100supporting UE-to-UE relay in accordance with a novel aspect. 5G new radio (NR) mobile communication network100comprises a 5G core (5GC) network and a radio access network (not shown) that may provide cellular service for a plurality of user equipments (UEs) including UE101, UE102, and UE103. Alternatively, one or more of UEs101,102, and103may be out of coverage of a cellular system. Various cellular systems, including both 4G/LTE and 5G/NR systems, may provide a facility known as a sidelink interface, which allows UEs in the system to communicate directly, without the use of any network infrastructure. The sidelink interface may also be referred to as a PC5 interface. A variety of applications may rely on communication over the sidelink interface, such as vehicle-to-everything (V2X) communication, public safety (PS) communication, direct file transfer between user devices, and so on.

A sidelink interface allows direct device-to-device communication between UEs. When two UEs that want to communicate are not in close enough proximity to use the sidelink directly, or when direct communication between the two UEs is impractical (due to interference, obstructions, or other factors, for example), they may rely on a third “relay UE” to route their communications. In such a situation, the first two UEs may be referred to as remote UEs, endpoint UEs, and so on. Typically, the endpoint UEs in this situation cannot detect one another directly but need to rely on the relay UE to establish communication between them. Thus there is a need for a procedure that allows the remote UEs to initially establish communication with the relay UE, followed by using the connectivity through the relay UE to establish a logical connection that allows direct communication between the remote UEs. It is noted that various protocol architectures to support relaying are possible, and in consequence, the logical connection between the remote UEs may take various forms, such as a radio resource control (RRC) connection, a routing path of an internet protocol (IP), etc.

For a UE-to-UE relay to operate, a communication path must be established between the remote UEs via the relay UE. Such a communication path allows packets of a service to be delivered from one remote UE to the other remote UE, using the relay UE as an intermediary. In either a layer-2 (L2) or layer-3 (L3) UE-to-UE relay architecture, when communication is established between the remote UEs and the relay UE, there is a need to establish radio-level connections (for instance, PC5-RRC connections) between the remote UEs and the relay UE. These radio-level connections allow management of the protocol layers that terminate between the relay UE and the remote UEs. In the example ofFIG. 1, UE101and UE102are two remote UEs, they are also referred to as UE1and UE2; and UE103is a relay UE, which provides UE-to-UE relay service for remote UE1and remote UE2. The PC5-RRC connection110between UE1and the relay UE, and the PC5-RRC connection120between UE2and the relay UE, may be negotiated by direct signalling over the sidelink interface, but the PC5-RRC connection130between UE1and UE2must be negotiated using signalling relayed by the relay UE, since UE1and UE2may not have the ability to communicate directly with one another over the sidelink.

In accordance with one novel aspect, methods of connection establishment for UE-to-UE relay are proposed. A sidelink interface is used for two remote UEs to communicate directly with a relay UE, which forwards communications between the remote UEs, to allow end-to-end communication between the remote UEs. The methods described are applicable to both L2 and L3 relaying architectures, in which the traffic to be relayed is carried at either L2 or L3 of a protocol stack. In a preferred embodiment ofFIG. 1, remote UE1first initiates a single Direct Communication (DC) Request message111, which triggers the establishment of multiple connections between UE1and the relay UE and between remote UE2and the relay UE, such that end-to-end relayed transport is available between UE1and UE2, with hop-by-hop security. Finally, UE1and UE2make use of the end-to-end relayed transport to authenticate and establish an end-to-end secured connection.

FIG. 2is a simplified block diagram of wireless devices201and211in accordance with a novel aspect. For wireless device201(e.g., a relay UE), antennae207and208transmit and receive radio signal. RF transceiver module206, coupled with the antennae, receives RF signals from the antennae, converts them to baseband signals and sends them to processor203. RF transceiver206also converts received baseband signals from the processor, converts them to RF signals, and sends out to antennae207and208. Processor203processes the received baseband signals and invokes different functional modules and circuits to perform features in wireless device201. Memory202stores program instructions and data210to control the operations of device201.

Similarly, for wireless device211(e.g., a remote UE), antennae217and218transmit and receive RF signals. RF transceiver module216, coupled with the antennae, receives RF signals from the antennae, converts them to baseband signals and sends them to processor213. The RF transceiver216also converts received baseband signals from the processor, converts them to RF signals, and sends out to antennae217and218. Processor213processes the received baseband signals and invokes different functional modules and circuits to perform features in wireless device211. Memory212stores program instructions and data220to control the operations of the wireless device211.

The wireless devices201and211also include several functional modules and circuits that can be implemented and configured to perform embodiments of the present invention. In the example ofFIG. 2, wireless device201is a relay UE that includes a protocol stack222, a resource management circuit205for allocating and scheduling sidelink resources, a connection handling circuit204for establishing and managing connections, a traffic relay handling controller209for relaying all or part of control signalling and/or data traffic for remote UEs, and a control and configuration circuit221for providing control and configuration information. Wireless device211is a remote UE that includes a protocol stack232, a relay discovery circuit214for discovering relay UEs, a connection handling circuit219for establishing and managing connections, and a configuration and control circuit231.

The different functional modules and circuits can be implemented and configured by software, firmware, hardware, and any combination thereof. The function modules and circuits, when executed by the processors203and213(e.g., via executing program codes210and220), allow relay UE201and remote UE211to perform embodiments of the present invention accordingly. In one example, a first remote UE sends an initiating message to a relay UE via the connection handling circuit, which triggers multiple connections to be established between the first remote UE and the relay UE and between the relay UE and a second remote UE. Based on the established end-to-end relayed transport, an end-to-end secured connection can be established between the first remote UE and the second remote UE.

FIG. 3illustrates a layer 2 (L2) relaying architecture for UE-to-UE relay. In the first exemplary protocol stack ofFIG. 3, the relaying operation occurs at the Radio Link Control (RLC) sublayer of L2. The lower layers of the protocol stack, including a physical (PHY) layer, a medium access control (MAC) layer, and an RLC layer, are terminated between the relay UE and each remote UE, with service data units (SDUs) of the RLC protocol relayed between the two links at the relay UE. The upper layers of the protocol stack, including a packet data convergence protocol (PDCP) layer, a service data adaptation protocol (SDAP) layer in the case of user plane (UP) operation, and upper layers that may comprise a PC5 radio resource control (PC5-RRC) protocol, a PC5 signalling (PC5-S) protocol, and/or IP, are terminated end-to-end between remote UE1and remote UE2. This protocol stack is applicable to both control and user plane operation, with different upper-layer protocols for the two cases. In particular, the L2 protocol stack allows for control and management of a PC5-RRC connection between the two remote UEs, using the relay UE as a communications intermediary but without any involvement of the relay UE in the actual protocol operations for connection control. For example, remote UE1may send PC5-RRC messages to remote UE2(and vice versa) to configure aspects of a PC5-RRC connection, such as the configuration of the protocol stack, the configuration of sidelink data radio bearers (SLRBs or DRBs), and so on.

FIG. 4illustrates a layer 3 (L3) relaying architecture for UE-to-UE relay. In the second exemplary protocol stack ofFIG. 4, the relaying operation occurs at the IP layer of L3. All the protocol layers (a PHY layer, a MAC layer, an RLC layer, a PDCP layer, an SDAP layer, and an IP layer) are terminated between the relay UE and each remote UE, with IP packets relayed at the relay UE. This allows IP traffic to flow between the remote UEs via the relay UE, while each radio link is managed separately between the relay UE and a remote UE. In some examples, the IP addresses of the remote UEs may be link-local for each of the two radio links and assigned by the relay UE, with the relay UE performing network address translation (NAT) to route IP packets to the remote UEs. In other examples, the IP addresses of the remote UEs may be known to both remote UEs and routable between the remote UEs, with the relay UE serving as an IP router.

In either a L2 or L3 UE-to-UE relay architecture, when communication is established between the remote UEs and the relay UE, there is a need to establish radio-level connections (for instance, PC5-RRC connections) between the remote UEs and the relay UE. These radio-level connections allow management of the protocol layers that terminate between the relay UE and the remote UEs. The PC5-RRC connections between UE1and the relay UE, and between UE2and the relay UE, may be negotiated by direct signalling over the sidelink interface, but the PC5-RRC connection between UE1and UE2must be negotiated using signalling relayed by the relay UE, since UE1and UE2may not have the ability to communicate directly with one another over the sidelink. The basic message flow to setup a PC5-RRC connection follows the existing art, which results in the following steps.

First, an initiating UE sends a Direct Communication (DC) Request message of a PC5-S protocol to a target UE. Second, the initiating UE and the target UE exchange messages to authenticate and establish a security association. Third, the target UE sends a Direct Communication Accept message to the initiating UE, completing the setup of a PC5-S connection. Fourth, the initiating and target UEs automatically consider a PC5-RRC connection to be established based on the PC5-S connection. In a relaying environment, where the remote UEs may not have the ability to communicate directly to one another on the sidelink, none of these steps can occur between the remote UEs as described above; to provide connectivity between the remote UEs, the relay UE must become involved in the communications for connection setup.

FIG. 5illustrates a sequence flow of a first embodiment of UE-to-UE relay between relay and remote UEs in accordance with one novel aspect. In step510ofFIG. 5, UE501(which will become one of the remote UEs once a relaying relationship is established) sends an initiating message, such as a Direct Communication Request message of a PC5-S protocol. This initiating message may be sent by broadcast, for example, if an application layer of the initiating UE did not provide an identifier for the target UE. Alternatively, the initiating message may be sent by unicast, that is, addressed specifically to UE502. The initiating message is received by the relay UE503. However, it may not be received by UE502, for instance, because of a lack of radio connectivity on the sidelink interface between UE501and UE502.

It is noted that in the case where the initiating message is sent by unicast (addressed to UE502), the flow ofFIG. 5assumes that the relay UE503knows it should receive and process the initiating message, even though the message is addressed to UE502rather than the relay UE503. This may be achieved in several ways. As one example, the relay UE503may maintain knowledge of other UEs in its radio environment that could be considered as remote UEs, and when it receives the initiating message addressed to UE502, the relay UE503may recognise UE502as a candidate remote UE.

In step520ofFIG. 5, the relay UE503forwards the initiating message to UE502. The forwarded message may maintain the original transmission mode and addressing from step510. That is, if the message in step510is sent by broadcast, then the message in step520may also be sent by broadcast; and if the message in step510was sent by unicast, then the message in step520may also be sent by unicast. Other information in the message in step520may be modified or appended to indicate that the message has been relayed. For instance, an identity of the relay UE503may be included as a source or a secondary source of the message, and in case the said identity of the relay UE503is a secondary source of the message, an identity of the primary source from which the message is relayed i.e. in this case UE501, is also included.

In step530ofFIG. 5, the relay UE503and UE501negotiate authentication and establish a security association. This step may use the same signalling and procedures as used for general sidelink communication. In other words, authentication and establishment of security between the relay UE and UE501may not be affected by the relaying architecture. In step540ofFIG. 5, the relay UE503and UE502negotiate authentication and establish a security association. This step may likewise use the existing signalling and procedures.

In step550ofFIG. 5, after authentication and security establishment are complete, the relay UE503may determine that it accepts the establishment of communication with UE501and transmit a response message, for example, a Direct Communication Accept message of a PC5-S protocol. This step may complete the establishment of a PC5-S connection between the relay UE503and UE501, and the relay UE503and UE501may autonomously consider that a corresponding PC5-RRC connection is established (not shown in the figure).

Similarly, in step560ofFIG. 5, UE502may determine that it accepts the establishment of communication with the relay UE503and transmit a response message, for example, a Direct Communication Accept message of a PC5-S protocol, potentially resulting in the establishment of a PC5-S connection and a corresponding PC5-RRC connection between UE502and the relay UE. This determination may take into account said other information in the message received in step520indicating that the message has been relayed. At this stage, connections are established between UE501and the relay UE503, and between UE502and the relay UE503, meaning that end-to-end relayed transport is available. However, security can only be hop-by-hop, meaning that a communication from UE501to UE502can be secured (for example, ciphered and/or integrity-protected) from UE501to the relay UE503, and from the relay UE503to UE502, but it cannot be secured end-to-end between UE501and UE502. The relay UE503has access to the communication without security protection, meaning that the relay UE503can read the contents of the communication (since it terminates ciphering) and/or modify the contents of the communication (since it terminates integrity).

After steps550and560have completed and secure communication is available between the remote UE501and UE502, further signalling may occur, for example, to configure the radio communication layers between the relay UE and the remote UEs. In one example of a L2 architecture, UE501in step561may send a reconfiguration message of a PC5-RRC protocol to the relay UE to configure the PHY, MAC, and RLC layers of the link between UE501and the relay UE. In another example of a L3 architecture, UE501in step561may send a reconfiguration message of a PC5-RRC protocol to the relay UE to configure the PHY, MAC, RLC, PDCP, and SDAP layers of the link between UE501and the relay UE.

It is noted that steps530/550and steps540/560ofFIG. 5may be asynchronous with one another. In other words, the relay UE may establish connections with UE501and UE502independently. For instance, steps530and540may overlap in time (in this case the relay UE would be establishing security with both UE501and UE502simultaneously). Similarly, step560may occur before step550. Only when both of steps550and560have completed will the end-to-end relayed transport between UE501and UE502be available, however. With the end-to-end relayed transport, remote UE501may send a transmission to the relay UE with addressing/routing information indicating that the transmission is intended for remote UE502; remote UE501may receive a transmission from the relay UE with addressing/routing information indicating that the transmission came from remote UE502.

In step570ofFIG. 5, UE501and UE502make use of the end-to-end relayed transport to authenticate and establish security between them. This step may make use of existing procedures of a protocol such as a PC5-S protocol. It is noted that the establishment of security does not require an end-to-end secure link a priori. Therefore, step570can proceed even though, as noted above, the link between UE501and UE502(through the relay UE) only has hop-by-hop security. The messages in step570are transmitted from a remote UE501to the relay UE, and forwarded by the relay UE to the other remote UE502; however, for purposes of the figure, the relaying is shown as transparent.

In step580ofFIG. 5, UE502may determine that it accepts the establishment of communication and transmit a response message, for instance, a Direct Communication Accept message of a PC5-S protocol. Like the messages in step570, the response message is forwarded by the relay; that is, it is sent first by UE502to the relay UE503, and then forwarded by the relay UE503to UE501. However, for purposes of the figure, the relaying is shown as transparent. After step580has completed, a PC5-S connection is established between UE501and UE502, with end-to-end secured transport available for communication between UE501and UE502. Subsequently, UE501and UE502may autonomously consider that a PC5-RRC connection is established between them, and they may use this PC5-RRC connection for subsequent signalling, such as a reconfiguration message of a PC5-RRC protocol to configure the radio layers of the protocol stack for communication between UE501and UE502. For example, in a L2 relaying architecture, UE501may send a reconfiguration message of a PC5-RRC protocol to UE502to configure the PDCP and SDAP layers of the link between UE501and UE502(step581).

As noted above, configuration of the IP layers of the connections is outside the scope of the PC5-RRC protocol. If configuration of the IP layer is required on any of the three established connections (for example, to allocate IP addresses to the remote UEs), the flow ofFIG. 5could be expanded to include additional signalling of a higher-layer protocol such as a PC5-S protocol. Particularly in a L3 relaying architecture, such additional signalling might be necessary before relayed transport is available. For instance, there might be additional PC5-S signalling between UE501and the relay UE after step550, between UE502and the relay UE after step560, and/or between UE501and UE502after step580.

FIG. 6illustrates a sequence flow of a second embodiment of UE-to-UE relay between relay and remote UEs in accordance with one novel aspect. A disadvantage of the flow shown inFIG. 5is that the relay UE sets up the PC5-S connection with UE501without knowing if it will successfully establish communication with UE502. As a result, error cases are possible in which UE501and the relay UE establish a PC5-S connection successfully and communicate over it, but the relay UE and UE502fail to establish a PC5-S connection (for example, due to a failure of radio connectivity between them, or due to requirements of other services that make it impossible for UE502to allocate resources for the proposed service advertised by UE501). The consequence is a waste of radio resources for the connection setup between UE501and the relay UE, and an inconvenient requirement to tear down the connection between UE501and the relay UE after setting it up. A message flow that achieves a similar end-to-end connection setup without this disadvantage is shown inFIG. 6as an alternative embodiment.

FIG. 6can be seen as a special case ofFIG. 5, in which the signalling between the relay UE and the remote UEs is constrained to occur in a particular order. In step610ofFIG. 6, UE601sends an initiating message (e.g., a Direct Communication Request message of a PC5-S protocol) to the relay UE603, as in step510ofFIG. 5. In step620ofFIG. 6, the relay UE603and UE601perform authentication and establish a security relationship, as in step530ofFIG. 5. In step630ofFIG. 6, the relay UE forwards the initiating message to UE602, as in step520ofFIG. 5. In step640ofFIG. 6, the relay UE603and UE602perform authentication and establish a security relationship, as in step540ofFIG. 5. In step650ofFIG. 6, UE602sends a response message (e.g., a Direct Communication Accept message of a PC5-S protocol) to the relay UE603, as in step560ofFIG. 5.

In step660ofFIG. 6, the flow diverges fromFIG. 5, in that the relay UE603waits to send a response message (for instance, a Direct Communication Accept message of a PC5-S protocol) to UE601until after it has completed the connection establishment with UE602. This dependency addresses the deficiency described above inFIG. 5. If there is a problem in the connection setup procedure with UE602, then the relay UE603will not finish setting up the connection with UE601, since there is no value in doing so. Rather, it may send a rejection message (for example, a Direct Communication Reject message of a PC5-S protocol) to UE601to indicate that the requested connection will not be set up. Assuming the relay UE603sends the response message as shown in step660, steps670and680ofFIG. 6are the same as steps570and580ofFIG. 5: remote UE601and remote UE602perform authentication and establish security, after which remote UE602sends a response message (for instance, a Direct Communication Accept message of a PC5-S protocol) to remote UE601.

As a variation onFIG. 6, it is also possible for step620to be delayed until after step650; that is, the relay UE does not perform authentication and establish security with UE601until the relay UE is sure that it can communicate with UE602. This approach has some benefit in efficiency for the failure case, since if the connection setup with UE602fails, the signalling overhead of step620can be avoided. However, this variation may also expose the relay UE to spurious connection attempts from an unauthorised device in the role of UE601, which could constitute a low-grade denial-of-service attack. There is thus a trade-off between efficiency and the risk of such an attack, and depending on how likely and how significant the attack scenario is considered, either the flow ofFIG. 6or the variation with the delayed step620might be preferable in a real deployment.

FIG. 7is a flow chart of a method of UE-to-UE relay from relay UE perspective in accordance with one novel aspect. In step701, a relay UE receives a first communication request message from a first remote UE. The relay UE offers relay service between the first remote UE and a second remote UE. In step702, the relay UE sends a first response message to the first remote UE and thereby establishing a first connection of a first protocol layer with the first remote UE. In step703, the relay UE sends a second communication request message to a second remote UE in response to the receiving the first communication request message. In step704, the relay UE receives a second response message from the second remote UE and thereby establishes a second connection of the first protocol layer with the second remote UE. In step705, the relay UE receives at least one transmission on the second connection from the second remote UE. In step706, the relay UE forwards the at least one transmission to the first remote UE on the first connection.

FIG. 8is a flow chart of a method of UE-to-UE relay from remote UE perspective in accordance with one novel aspect. In step801, a remote UE sends a first communication request message to a relay UE that offers relay service between the first remote UE and the second remote UE. In step802, the remote UE receives a first response message from the relay UE and thereby establishes a first connection of a first protocol layer with the relay UE. In step803, the remote UE communicates with a second remote UE via the relay UE. In step804, the remote UE receives a second response message from the second remote UE. The second response message is triggered by and in response to the first communication request message via the relay UE. In step805, the remote UE establishes a second connection of the first protocol layer with the second remote UE.