Relays (RN) and Donor eNode Bs (DeNB)

Relays a.k.a. Relay Node (RN) in standards has been a part of the standards for a while but I don't hear about them often. The only time recently when I heard about them were with Airspan's MagicBox small cells deployed in Sprint (see news here). In fact the article speculates:

LTE UE Relay was specified within 3GPP’s Release 10. There are different types of Relay and it would seem Sprint’s will be Type 2, which sees the Relay Node (or MagicBox) retransmit on the same code as provided by its macro “donor” cell.

While I don't have any further details about it, I am not too sure about it. Type 2 relays are complex and require change in the existing eNodeB's. I should clarify here that we are talking about Layer 3 relays in this post. An earlier presentation from Airspan mentioned that they use Type 1a/1b relay architecture. See here.

The presentation below has some nice simple explanation of the Relay nodes and its workings

In case of Type 2 relays, there is a much more architecture change involved. This architecture change requires modification of the existing eNB to Donor eNB (DeNB).

Going back to 3GPP TS 36.300: E-UTRA and E-UTRAN Overall description; Stage 2 document:

The DeNB hosts the following functions in addition to the eNB functions:
- S1/X2 proxy functionality for supporting RNs;
- S11 termination and S-GW/P-GW functionality for supporting RNs.

Further on, in section 4.7

E-UTRAN supports relaying by having a Relay Node (RN) wirelessly connect to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA radio interface, the modified version being called the Un interface.

The RN supports the eNB functionality meaning it terminates the radio protocols of the E-UTRA radio interface, and the S1 and X2 interfaces. From a specification point of view, functionality defined for eNBs, e.g. RNL and TNL, also applies to RNs unless explicitly specified. RNs do not support NNSF.

In addition to the eNB functionality, the RN also supports a subset of the UE functionality, e.g. physical layer, layer-2, RRC, and NAS functionality, in order to wirelessly connect to the DeNB.

The RN terminates the S1, X2 and Un interfaces. The DeNB provides S1 and X2 proxy functionality between the RN and other network nodes (other eNBs, MMEs and S GWs). The S1 and X2 proxy functionality includes passing UE-dedicated S1 and X2 signalling messages as well as GTP data packets between the S1 and X2 interfaces associated with the RN and the S1 and X2 interfaces associated with other network nodes. Due to the proxy functionality, the DeNB appears as an MME (for S1-MME), an eNB (for X2) and an S-GW (for S1-U) to the RN. 

In phase II of RN operation, the DeNB also embeds and provides the S-GW/P-GW-like functions needed for the RN operation. This includes creating a session for the RN and managing EPS bearers for the RN, as well as terminating the S11 interface towards the MME serving the RN.

The RN and DeNB also perform mapping of signalling and data packets onto EPS bearers that are setup for the RN. The mapping is based on existing QoS mechanisms defined for the UE and the P-GW.

In phase II of RN operation, the P-GW functions in the DeNB allocate an IP address for the RN for the O&M which may be different than the S1 IP address of the DeNB.

Based on the complexity and additional changes required for Type 2 relays, I am not surprised that they are not very popular. If you think otherwise, do let me know.

Thanks to Dr. Kit Kilgour for providing insights into this topic.