Extracted from 3GPP 36.300:
The eNB hosts the following functions:
- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);
- IP header compression and encryption of user data stream;
- Selection of an MME at UE attachment when no routing to an MME can be determined from the information provided by the UE;
- Routing of User Plane data towards Serving Gateway;
- Scheduling and transmission of paging messages (originated from the MME);
- Scheduling and transmission of broadcast information (originated from the MME or O&M);
- Measurement and measurement reporting configuration for mobility and scheduling;
- Scheduling and transmission of PWS (which includes ETWS and CMAS) messages (originated from the MME);
- CSG handling;
- Transport level packet marking in the uplink.
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.
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 architecture for supporting RNs is shown in Figure 4.7.2-1. 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.
For more details see - 3GPP TS 36.300 : Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 10)
3 comments:
Hi
I am trying to understand the implementation of relay networks.
I don't understand the concept of using a Doner eNB in this case.
what the purpose of Doner and why call it a doner?
Question,
1. Why is it that a RN cannot be connected back to a eNB directly?
2. In the published scenario, can other UE in the vicinity of the DeNB still attach to the network or does the DeNB become dedicated for the RN (Un interface)
Some papers that I have read doesn't mention the need for doner so that is why I am confused to the need of a doner and if the doner requires a separate core.
Hi, anybody can help on the question above?
Hi Faisal,
PFB answers to your query:
1. Why is it that a RN cannot be connected back to a eNB directly?
Ans. Because eNB does not have the required capability to support RN. For that purpose only DeNB has been defined.
2. In the published scenario, can other UE in the vicinity of the DeNB still attach to the network or does the DeNB become dedicated for the RN (Un interface)
Ans. DeNB is an eNB with extra functionality so that it can support RN. So yes, DeNB can serve other UEs like a normal eNB.
I hope that helps.
Post a Comment