UE-to-Network Relay User Equipment

Description

The U2N Relay UE (UE-to-Network Relay User Equipment) is a key component of 5G NR sidelink relay architecture, introduced in Release 17. It is a UE that provides functionality to support connectivity to the network for one or more U2N Remote UEs. In essence, it acts as a relay node, forwarding traffic between the remote UE and the network (gNB) over the air interface. This enables coverage extension and service continuity for UEs that are outside direct network coverage or experiencing poor link quality.

The U2N Relay UE operates using sidelink (PC5) communication with the remote UE and Uu interface with the gNB. The relay functionality can be transparent or non-transparent. In transparent mode, the remote UE may not be aware of the relay's presence, and the relay simply forwards packets at the IP level. In non-transparent mode, the remote UE is aware of the relay and may establish a direct connection with it. The relay UE can be in coverage or out of coverage itself; if out of coverage, it may use another relay to reach the network, forming a multi-hop chain.

The architecture involves several key procedures: relay discovery, relay selection, connection establishment, and data forwarding. The remote UE discovers candidate relay UEs using sidelink discovery procedures. Once selected, the remote UE establishes a PC5 connection with the relay UE. The relay UE then establishes or uses an existing Uu connection to the gNB to forward the remote UE's traffic. The relay UE may need to manage multiple remote UEs and allocate resources accordingly. The gNB controls the relay operation, including authorization, resource allocation, and mobility management.

The U2N Relay UE is specified in 3GPP TS 38.304 (UE procedures in idle and inactive mode), TS 38.401 (NG-RAN architecture), TS 38.470 (F1 general aspects), and TS 38.473 (F1AP). These specifications define the procedures for relay selection, authorization, and data forwarding. The relay UE must support specific capabilities, such as sidelink communication, relay functionality, and the ability to handle multiple connections. The network can control whether a UE is allowed to act as a relay and under what conditions.

In Release 18, the definition remained unchanged, but enhancements were made to support more advanced features like relay selection with multiple hops and improved QoS handling. In Release 19, the definition was simplified to refer to TS 38.300 for the detailed description, indicating that the concept is now well-established and integrated into the overall NR architecture. The U2N Relay UE is a crucial enabler for extending 5G coverage to areas where direct network deployment is challenging, such as indoors, underground, or remote locations.

Purpose & Motivation

The U2N Relay UE was introduced to address the need for coverage extension and service continuity in 5G networks. Direct network coverage may be limited in certain scenarios, such as indoor environments, rural areas, or during disasters. Deploying additional base stations may be costly or impractical. The relay UE leverages the capabilities of advanced UEs to act as relays, providing connectivity to nearby remote UEs without additional infrastructure. This is particularly useful for public safety, industrial IoT, and consumer applications where coverage holes exist.

The concept also solves the problem of battery life and complexity for remote UEs. A remote UE can use a relay UE to access the network with lower power consumption, as the relay may be closer and the link budget more favorable. Additionally, the relay can aggregate traffic from multiple remote UEs, improving efficiency. The U2N Relay UE architecture builds on the sidelink framework introduced in earlier releases for V2X, extending it to general UE-to-network relaying.

Historically, relay concepts existed in earlier cellular systems (e.g., LTE relays), but they were typically fixed relay nodes. The U2N Relay UE is unique in that it is a regular UE that can move and be dynamically selected. This flexibility allows for on-demand coverage extension. The Release 17 specifications laid the foundation, and subsequent releases have refined the procedures and added features like multi-hop relaying and QoS support.