E-UTRAN R10 / LTE-Advanced Delta course focuses on differences between E-UTRAN R8/R9 and E-UTRAN R10 also known as LTE-Advanced. The training covers a functional description of all major R10 enhancements together with the required signalling protocols modifications.
3. 4 Relay
71
IntroductionIntroductionIntroductionIntroduction
[1, 3GPP 36.912] LTE-Advanced extends LTE R8 with support for relaying
as a tool to improve e.g. the coverage of high data rates, temporary network
deployment, the cell-edge throughput and/or to provide coverage in new
areas.
The Relay Node (RN) is wirelessly connected to a donor cell of a donor eNB
(DeNB) via the Un interface, and UEs connect to the RN via the Uu interface.
R8 UEs is able to connect to the donor cell as well as to the RN cell.
Figure 4-1 Relaying
With respect to the relay node’s usage of spectrum, its operation can be
classified into:
• Inband (RN Type 1), in which case the DeNB-RN link shares the
same carrier frequency with RN-UE links.
• Outband (RN Type 1a), in which case the DeNB-RN link does not
operate in the same carrier frequency as RN-UE links.
The RN is characterized by the following:
• It controls cells, each of which appears to a UE as a separate cell
distinct from the donor cell
• The cells have their own Physical Cell ID (PCI) and transmit their
own synchronisation channels, reference symbols, …
• In the context of single-cell operation, the UE receives scheduling
information and HARQ feedback directly from the RN and sends its
control channels (SR/CQI/ACK) to the RN.
• It appears as a R8 eNB to R8 UEs (i.e. is backwards compatible).
• To LTE-Advanced UEs, it is possible for a RN to appear differently
than R8 eNB to allow for further performance enhancement.
EPCUnUu S1RN
donor cell
R8+
R8+
DeNB
Uu
4. LTE-Advanced
72
Figure 4-2 Inband and outband relay
Via proper deploying of the relay, both the backhaul link and the access link
can be made with better propagation condition compared with the direct link,
and hence the end-to-end performance can be improved compared to the case
without relay.
[2, 3GPP 36.300] In R10 and R11 inter-cell handover of the RN is not
supported. A Study on Mobile Relay for E-UTRA is part of R12 [3, 3GPP
36.836].
An RN may not use another RN as its DeNB.
Figure 4-3 Relay limitations (R10, R11)
f4
f3
RN
RN
f2
f1f1
f2
f2
f1
Inband (type 1)
Outband (type 1a)
RNRN
RN
RN
inter-cell
HO
cascaded RNs
5. 4 Relay
73
ArchitectureArchitectureArchitectureArchitecture
[2, 3GPP 36.300] The architecture for supporting RNs is shown in Fig. 4-4.
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.
Figure 4-4 E-UTRAN architecture supporting RNs
In phase II of RN operation, the DeNB also embeds and provides the
S/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.
If the RN address is not routable to the RN O&M domain, it shall be
reachable from the RN O&M domain (e.g. via NAT).
S1
MME/S-GW MME/S-GW
RN
DeNBeNB
S11
S1
S1 S1
S11
X2
X2S1
Un
includes
S/P-GW
for the RN
6. LTE-Advanced
74
S1 and X2S1 and X2S1 and X2S1 and X2 UUUU----plane aspectsplane aspectsplane aspectsplane aspects
The S1 U-plane protocol stack for supporting RNs is shown in Fig. 4-5.
Figure 4-5 S1 U-plane protocol stack for supporting RNs
There is a GTP tunnel associated with each UE EPS bearer, spanning from the
S-GW associated with the UE to the DeNB, which is switched to another GTP
tunnel in the DeNB, going from the DeNB to the RN (one-to-one mapping).
Figure 4-6 S1 & S5/S8 GTP tunnels
The X2 U-plane protocol stack for supporting RNs is shown in Fig. 4-7.
Figure 4-7 X2 U-plane protocol stack for supporting RNs
GTP GTPGTP GTP
UDP UDP UDP UDP
IP IP IP IP
PDCP
RLC
MAC
PHY
PDCP
RLC
MAC
PHY
L2
L1
L2
L1
RN S1-U DeNB S1-U S-GW
S-GW P-GW
PDN
1:1
RN
GTP GTPGTP GTP
UDP UDP UDP UDP
IP IP IP IP
PDCP
RLC
MAC
PHY
PDCP
RLC
MAC
PHY
L2
L1
L2
L1
RN X2-U DeNB X2-U
eNB
(other)
7. 4 Relay
75
There is a GTP forwarding tunnel associated with each UE EPS bearer subject
to forwarding, spanning from the other eNB to the DeNB, which is switched
to another GTP tunnel in the DeNB, going from the DeNB to the RN (one-to-
one mapping).
Figure 4-8 X2 GTP tunnels
The S1 and X2 U-plane packets are mapped to Radio Bearers (RBs) over the
Un interface. The mapping can be based on the QCI associated with the UE
EPS bearers. UE EPS bearer with similar QoS can be mapped to the same Un
RB.
Figure 4-9 Mapping of S1/X2 U-plane packets to RB on Un interface
RN OAM provides the appropriate support to configure a QCI-to-DSCP
mapping function at the RN which is used to control the mapping in UL of Uu
bearer(s) of different QCI(s) to Un bearer(s).
S-GW
O&M
X2/S1control
RN
MME
O&M
QCI=x
QCI=y
QCI=y
8. LTE-Advanced
76
S1 and X2S1 and X2S1 and X2S1 and X2 CCCC----plane aspectsplane aspectsplane aspectsplane aspects
The S1 C-plane protocol stack for supporting RNs is shown in Fig. 4-10.
Figure 4-10 S1 C-plane protocol stack for supporting RNs
There is a single S1 interface relation between each RN and its DeNB, and
there is one S1 interface relation between the DeNB and each MME in the
MME pool. The DeNB processes and forwards all S1 messages between the
RN and the MMEs for all UE-dedicated procedures.
Figure 4-11 S1AP message processing at DeNB (UE dedicated)
The processing of S1AP messages includes modifying S1AP UE IDs,
Transport Layer address and GTP TEIDs but leaves other parts of the
message unchanged.
S1AP S1APS1AP S1AP
SCTP SCTP SCTP SCTP
IP IP IP IP
PDCP
RLC
MAC
PHY
PDCP
RLC
MAC
PHY
L2
L1
L2
L1
RN S1-MME DeNB S1-MME MME
S1AP message
RN MME
S1AP message
DeNB
MME UE S1AP ID, eNB UE S1AP ID,
Transport Layer Address, GTP-TEID
(…)
S1 S1
MME UE S1AP ID, eNB UE S1AP ID,
Transport Layer Address, GTP-TEID
(…)
1:1 mapping
transparent
9. 4 Relay
77
Figure 4-12 S1AP message processing at eNB (non-UE dedicated)
All non-UE-dedicated S1AP procedures are terminated at the DeNB, and
handled locally between the RN and the DeNB, and between the DeNB and
the MME(s). Upon reception of an S1 non-UE-dedicated message from an
MME, the DeNB may trigger corresponding S1 non-UE-dedicated
procedure(s) to the RN(s). If more than one RN is involved, the DeNB may
wait and aggregate the response messages from all involved RNs before
responding to the MME. Upon reception of an S1 non-UE-dedicated message
from an RN, the DeNB may trigger associated S1 non-UE-dedicated
procedure(s) to the MME(s). Upon reception of a S1AP PAGING message,
the DeNB sends the S1AP PAGING message toward the RN(s) which support
any TA(s) indicated in the list of TAIs. Upon reception of an S1 MME
overload message, the DeNB sends the MME overload message towards the
RN(s), including in the message the identities of the affected CN node. Upon
reception of the GUMMEI from a UE, the RN shall include it in the INITIAL
UE MESSAGE message; upon reception of the GUMMEI Type from the UE,
the RN shall also include it in the message.
The X2 C-plane protocol stack for supporting RNs is shown in Fig. 4-13.
Figure 4-13 X2 C-plane protocol stack for supporting RNs
There is a single X2 interface relation between each RN and its DeNB. In
addition, the DeNB may have X2 interface relations to neighbouring eNBs.
MME
DeNB
MME
RN
MME
DeNB
MME
RN
RN
RN
X2AP X2APX2AP X2AP
SCTP SCTP SCTP SCTP
IP IP IP IP
PDCP
RLC
MAC
PHY
PDCP
RLC
MAC
PHY
L2
L1
L2
L1
RN X2-C DeNB X2-C MME
10. LTE-Advanced
78
The DeNB processes and forwards all X2 messages between the RN and other
eNBs for all UE-dedicated procedures. The processing of X2-AP messages
includes modifying S1/X2-AP UE IDs, Transport Layer address and GTP
TEIDs but leaves other parts of the message unchanged.
Figure 4-14 X2AP message processing at DeNB (UE dedicated)
All non-UE-dedicated X2-AP procedures are terminated at the DeNB, and
handled locally between the RN and the DeNB, and between the DeNB and
other eNBs. Upon reception of an X2 non-cell related non-UE-associated
message from RN or neighbour eNB, the DeNB may trigger associated
non-UE-dedicated X2-AP procedure(s) to the neighbour eNB or RN(s). Upon
reception of an X2 cell related non-UE-dedicated message from RN or
neighbour eNB, the DeNB may pass associated information to the neighbour
eNB or RN(s) based on the included cell information. If one or more RN(s)
are involved, the DeNB may wait and aggregate the response messages from
all involved nodes to respond to the originating node. Further, parallel Cell
Activation procedures are not allowed on each X2 interface instance. The
processing of Resource Status Reporting Initiation/ Resource Status Reporting
messages includes modification of measurement ID.
Figure 4-15 X2AP message processing at DeNB (non-UE dedicated)
The S1 and X2 interface signalling packets are mapped to RBs over the Un
interface (see Fig. 4-9).
X2AP message
RN
X2AP message
DeNB
Old eNB UE X2AP ID,
New eNB UE X2AP ID,
Transport Layer Address, GTP-TEID
(…)
X2 X2
Old eNB UE X2AP ID,
New eNB UE X2AP ID,
Transport Layer Address, GTP-TEID
(…)
1:1 mapping
transparent
eNB
RN
DeNBRN
eNB
eNB
11. 4 Relay
79
Radio protocol aspectsRadio protocol aspectsRadio protocol aspectsRadio protocol aspects
The RN connects to the DeNB via the Un interface using the same radio
protocols and procedures as a UE connecting to an eNB. The C-plane protocol
stack is shown in Fig. 4-16 and the U-plane protocol stack is shown in
Fig. 4-17.
The following relay-specific functionalities are supported:
• the RRC layer of the Un interface has functionality to configure and
reconfigure an RN subframe configuration through the RN
reconfiguration procedure (e.g. DL subframe configuration and an
RN-specific control channel) for transmissions between an RN and a
DeNB. The RN may request such a configuration from the DeNB
during the RRC connection establishment, and the DeNB may initiate
the RRC signalling for such configuration;
• the RRC layer of the Un interface has functionality to send updated
system information in a dedicated message to an RN with an RN
subframe configuration. The RN applies the received system
information immediately;
• the PDCP layer of the Un interface has functionality to provide
integrity protection for the U-plane. The integrity protection is
configured per DRB.
To support PWS towards UEs, the RN receives the relevant information over
S1. The RN should hence ignore DeNB system information relating to PWS.
Figure 4-16 Un C-plane protocol stack for supporting RNs
NAS NAS
RRC RRC
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY
RN Un DeNB MME
12. LTE-Advanced
80
Figure 4-17 Un U-plane protocol stack for supporting RNs
Signalling proceduresSignalling proceduresSignalling proceduresSignalling procedures
RN startRN startRN startRN start----up procedureup procedureup procedureup procedure
Fig. 4-18 and Fig. 4-19 shows a simplified version of the start-up procedure
for the RN. The procedure is based on the normal UE attach procedure and it
consists of the following two phases:
Phase I:Phase I:Phase I:Phase I: Attach for RN preconfigurationAttach for RN preconfigurationAttach for RN preconfigurationAttach for RN preconfiguration
The RN attaches to the E-UTRAN/EPC as a UE at power-up and retrieves
initial configuration parameters, including the list of DeNB cells, from RN
OAM. After this operation is complete, the RN detaches from the network as
a UE and triggers Phase II. The MME performs the S-GW and P-GW
selection for the RN as a normal UE.
Figure 4-18 RN start-up procedure (phase 1)
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY
RN Un DeNB
13. 4 Relay
81
PhPhPhPhase II: Attachase II: Attachase II: Attachase II: Attach for RN operationfor RN operationfor RN operationfor RN operation
The RN connects to a DeNB selected from the list acquired during Phase I to
start relay operations. For this purpose, the normal RN attach procedure
described earlier. After the DeNB initiates setup of bearer for S1/X2, the RN
initiates the setup of S1 and X2 associations with the DeNB. In addition, the
DeNB may initiate an RN reconfiguration procedure via RRC signalling for
RN-specific parameters.
After the S1 setup, the DeNB performs the S1 eNB Configuration Update
procedure(s), if the configuration data for the DeNB is updated due to the RN
attach. After the X2 setup, the DeNB performs the X2 eNB Configuration
Update procedure(s) to update the cell information.
In this phase the RN cells’ ECGIs are configured by RN OAM.
Figure 4-19 RN start-up procedure (phase 2)
RN attach procedureRN attach procedureRN attach procedureRN attach procedure
Fig. 4-20 shows a simplified version of the attach procedure for the RN. The
procedure is the same as the normal UE attach procedure with the exception
that:
• The DeNB has been made aware of which MMEs support RN
functionality via the S1AP SETUP RESPONSE message earlier
received from the MMEs;
14. LTE-Advanced
82
• The RN sends an RN indication to the DeNB during RRC connection
establishment (rn-SubframeConfigReq parameter in RRC
CONNECTION COMPLETE message [4, 3GPP 36.331]);
• After receiving the RN indication from the RN, the DeNB sends the
RN indicator and the IP address of the S-GW/P-GW function
embedded in the DeNB, within the S1AP INITIAL UE MESSAGE
message, to an MME supporting RN functionality;
• MME selects S-GW/P-GW for the RN based on the IP address
included in the S1AP INITIAL UE MESSAGE message;
• During the attach procedure, the EPC checks if the RN is authorised
for relay operation; only if the RN is authorised, the EPC accepts the
attach and sets up a context with the DeNB; otherwise the EPC rejects
the attach.
The RN is preconfigured with information about which cells (DeNBs) it is
allowed to access.
Figure 4-20 RN attach procedure
EEEE----RAB activation/modificationRAB activation/modificationRAB activation/modificationRAB activation/modification
Fig. 4-21 shows a simplified version of the DeNB-initiated bearer
activation/modification procedure. This procedure can be used by the DeNB
to change the EPS bearer allocation for the RN. The procedure is the same as
the normal network-initiated bearer activation/modification procedure with
the exception that the S/P-GW functionality is performed by the DeNB.
RN MMERN
DeNB
HSS
RRC connection setup
NAS Attach, Authentication, Security Authentication, Security
GTP-C Create Session
S1AP Context Setup
(NAS Attach Accept)
RRC connection
reconfiguration
Includes S/P-GW
for the RN
15. 4 Relay
83
Figure 4-21 DeNB-initiated bearer activation/modification procedure
RN reconfigurationRN reconfigurationRN reconfigurationRN reconfiguration
The purpose of this procedure is to configure/reconfigure the RN subframe
configuration and/or to update the system information relevant for the RN in
RRC CONNECTED state.
Figure 4-22 RN reconfiguration
E-UTRAN may initiate the RN reconfiguration procedure to an RN in RRC
CONNECTED when AS security has been activated.
RRC Connection Reconfiguration
(NAS SM message)
GTP-C Create/Update Bearer Req.
S1AP E-RAB Setup/Modification Req.
(NAS SM message)
S1AP E-RAB Setup/Modification Rsp.
UL Information Transfer
(NAS SM message)
UL NAS Transport
(NAS SM message)
GTP-C Create/Update Bearer Rsp.
RN MMERN
DeNB
Includes S/P-GW
for the RN
rn-SubframeConfigReq
rn-SystemInfo (SystemInformationBlockType1 / 2),
rn-SubframeConfig (subframeConfigPatternFDD / TDD,
rpdcch-Config (resourceAllocationType, resourceBlockAssignment),
demodulationRS, pdsch-Start, pucch-Config)
RRC RN Reconfiguration Complete
RRC RN Reconfiguration
RRC Connection Request
RRC Connection Setup
RRC Connection Complete
DeNB
RN
16. LTE-Advanced
84
OAMOAMOAMOAM
Each RN sends alarms and traffic counter information to its OAM system,
from which it receives commands, configuration data and software downloads
(e.g. for equipment software upgrades). This transport connection between
each RN and its OAM, using IP, is provided by the DeNB.
Figure 4-23 RN OAM architecture
RN OAM traffic is transported over the Un interface, and it shares resources
with the rest of the traffic, including UEs attached to the DeNB. The secure
connection between the RN and its OAM may be direct or hop-by-hop, i.e.
involving intermediate hops trusted by the operator for this purpose.
OAM Traffic QoS RequirementsOAM Traffic QoS RequirementsOAM Traffic QoS RequirementsOAM Traffic QoS Requirements
Alarms in the RN generate bursts of high-priority traffic, to be transported in
real time. Traffic counters generate bursts of traffic, but their transport need
not be real-time. Configuration messages from OAM to the RN will also
generate small bursts of traffic, possibly with lower priority than alarms but
still delay-sensitive: when a configuration is committed on the OAM, the time
interval between the commitment and the effect on the equipment shall be
small.
Alarm messages and commands should be transported on a high-priority
bearer, while counters may be transported on a lower priority bearer. There is
no need to specify a new QCI value other than those already standardised.
Alarm messages and commands may be mapped over a dedicated bearer or
over the same bearer that carries S1 and/or X2 messages between the RN and
the DeNB.
OAM software download to the RN may generate larger amounts of data, but
both the required data rate and the priority of this kind of traffic are much
lower than in the case of alarms, commands and counters. OAM software
downloads may be mapped to a dedicated, non-GBR bearer, or transported
together with the user plane traffic.
S/P-GWRN
RN OAM
Un
DeNB
secure connection
17. 4 Relay
85
Physical layerPhysical layerPhysical layerPhysical layer
[5, 3GPP 36.216] From a UE perspective a RN is part of the RAN and
behaves like an eNB. A RN is wirelessly connected to a DeNB.
A RN includes at least two physical layer entities. One entity is used for
communication with UEs. Another physical layer entity is used for
communication with the DeNB.
In case of inband (type 1) relay, time-frequency resources shall be set aside
for DeNB-RN transmissions by time multiplexing DeNB-RN and RN-UE
transmissions. Subframes during which DeNB-RN transmission may take
place are configured by higher layers (RRC). DL subframes configured for
DeNB-to-RN transmission shall be configured as MBSFN subframes by the
RN (RRC SIB2 MBSFN-SubframeConfig parameter) and accept the 1 or 2
OFDM symbol long control region of the subframe, shall not be transmitted
by the RN.
Figure 4-24 Uu/Un time multiplexing (inband relay)
For frame structure type 1, DeNB-to-RN and RN-to-UE transmissions occur
in the DL frequency band, while RN-to-DeNB and UE-to-RN transmissions
occur in the UL frequency band.
For frame structure type 1 (i.e. for FDD), a subframes configured for
DeNB-to-RN transmission are given by the SubframeConfigurationFDD
parameter send by the DeNB to RN as a part of the RRC RN Reconfiguration
procedure. A subframe n is configured for RN-to-DeNB transmission if
subframe n-4 is configured for DeNB-to-RN transmission. If the RN requires
this subframe to be idle from UE-to-RN transmission, the RN does not
allocate any PDSCH or PUCCH resources on that subframe.
RN
f2
f1 f1
f2
TDM
TDM
18. LTE-Advanced
86
The subframes number 0, 4, 5, 9 that due to collision with PSS, SSS,
PBCH/BCH and/or PCH cannot be configured by RN-to-UE as MBSFN
subframes, also cannot be configured for DeNB-to-RN.
Figure 4-25 SubframeConfigurationFDD = 01010101 (example)
For frame structure type 2 (i.e. TDD) the subframes that can be configured for
DeNB-RN transmission are listed in Fig. 4-26 where, for each subframe in a
radio frame, “D” denotes the subframe is configured for DL DeNB-to-RN
transmissions, “U” denotes the subframe is configured for UL RN-to-DeNB
transmissions. The parameter SubframeConfigurationTDD is configured by
higher layers (RRC).
Figure 4-26 Supported configurations for DeNB-RN transmission (TDD)
radio frame radio frame
4 ms
“false” MBSFN subframe
DeNB-to-RN
RN-to-UE
RN-to-DeNB
UE-to-RN
Subframe
Configuration
TDD
eNB-RN
UL-DL
configuration
Subframe number n
0 1 2 3 4 5 6 7 8 9
0
1
d s u u D d s u U d
1 d s u U d d s u u D
2 d s u u D d s u U D
3 d s u U D d s u u D
4 d s u U D d s u U D
5
2
d s U d d d s u D d
6 d s u D d d s U d d
7 d s U d D d s u D d
8 d s u D d d s U d D
9 d s U D D d s u D d
10 d s u D d d d U D D
11
3
d s u U u d d D d D
12 d s u U u d d D D D
13
4
d s u U d d d d d D
14 d s u U d d d D d D
15 d s u U d d d d D D
16 d s u U d d d D D D
17 d s u U D d d D D D
18 6 d s u u U d s u u D
19. 4 Relay
87
DeNB-to-RN transmissions is restricted to a subset of the OFDM symbols in
a slot. The starting OFDM symbol in the first slot of the subframe is given by
the parameter DL-StartSymbol (symbol number 1 ,2 or 3) configured by
higher layers (RRC). If DL subframes are transmitted with time aligned
subframe boundaries by the DeNB and the RN, the ending OFDMA symbol
in the second slot of the subframe is symbol number 6, and symbol number 5
otherwise.
Figure 4-27 DeNB-to-RN transmission (OFDMA symbols)
RRRR----PDCCHPDCCHPDCCHPDCCH
The Relay Physical Downlink Control Channel (R-PDCCH) carries DCI for
RNs to dynamically assign resources to different RNs within the semi-
statically assigned sub-frames for DeNB-RN and RN-DeNB PDSCH
transmission. An R-PDCCH is transmitted starting from OFDMA symbol 3 of
the first slot of the subframe up to OFDMA symbol 6 ( if DL subframes are
transmitted with time aligned subframe boundaries by the DeNB and the RN)
or 51.
In the frequency domain, a set of VRBs is configured for potential
R-PDCCH transmission by higher layers (RRC) using resource allocation
types 0, 1, or 2.
An R-PDCCH can be transmitted on one or several PRBs without being
cross-interleaved with other R-PDCCHs. Alternatively, multiple R-PDCCHs
can be cross-interleaved in one or several PRBs.
1 This new channel type is needed because the RN may miss the first part of the subframe where PDCCH is
transmitted as the RN is still transmitting the PDCCH of the MBSFN subframe to its UEs.
DeNB DL
x
RN DL
x x x x x x x x x x x x x
RN
DL-StartSymbol (1, 2, 3) 0 or 1
“false” MBSFN subframe
20. LTE-Advanced
88
Figure 4-28 R-PDCCH and PDSCH
The RN shall monitor the set of configured VRBs in the first slot for an
R-PDCCH containing a DL assignment and it shall monitor the set of
configured VRBs in the second slot for an R-PDCCH containing an UL grant.
If the RN receives a resource allocation which overlaps a PRB pair in which a
DL assignment is detected in the first slot, the RN shall assume that there is
PDSCH transmission for it in the second slot of that PRB pair.
The R-PDCCH is demodulated based on Cell-specific Reference Signals
(CRSs) transmitted on one set of antenna ports {0},{0,1},{0,1,2,3}, or based
on UE-specific Reference Signals (URSs) transmitted on antenna port 72; the
type of RSs signals is configured by higher layers (RRC).
Figure 4-29 R-PDCCH and MIMO
2 Demodulation based on USRs is possible only for a single (non-interleaved) R-PDCCH.
VRB n
VRB 7
VRB 6
VRB 5 x x
VRB 4 x x
VRB 3 x
VRB 2 x
VRB 1 x
VRB 0
slotslot
subframe
PDCCH
andothercontrolchannels
R-PDCCH
semi-static configuration
PDSCH (DeNB-RN)
dynamic allocation
DL assignment UL grant
0
7
1
2
3
RN
RN
RN
RN
21. 4 Relay
89
PDSCH andPDSCH andPDSCH andPDSCH and PUCCHPUCCHPUCCHPUCCH
The PDSCH DeNB-to-RN transmissions is processed and mapped to REs as
in case of “regular” transmission with the following exceptions:
• the PDSCH is mapped only to REs in OFDM symbols configured for
DeNB-to-RN transmission (see Fig. 4-28);
• the PDSCH is not mapped to any RE in the first slot of an RB pair on
any antenna port when the first slot of the RB pair is used for
R-PDCCH transmission on any antenna port.
The HARQ feedback on PUCCH/PUSCH is also processed as in case of
regular transmission.
Figure 4-30 PDSCH, R-PDCCH and PUCCH/PUSCH
PUSCHPUSCHPUSCHPUSCH and PHICHand PHICHand PHICHand PHICH
The RN node shall not expect HARQ feedback on PHICH, as the PHICH
channel is located in the “control channel region” of the subframe that is not
listen by the RN. ACK shall be delivered to higher layers for each transport
block transmitted on PUSCH.
The lack of PHICH feedback means that the non-adaptive UL
re-transmissions are not possible on Un interface. However, the DeNB still
can order adaptive re-transmission by signalling UL grant on R-PDCCH with
the same New Data Indicator (NDI) value as used previously for the same
HARQ process.
At the RN the number of HARQ processes depends on the subframes
configured for DeNB-RN transmissions.
radio frame radio frame
SubframeConfigurationFDD = 01010101
UL
DL
R-PDCCH (UL grant)
PDSCH
PUCCH/PUSCH (HARQ_ACK)
22. LTE-Advanced
90
Figure 4-31 R8 UL Uu i/f adaptive and non-adaptive re-Tx
Figure 4-32 R10 UL Un i/f adaptive re-Tx
Relays Compared to RepeatersRelays Compared to RepeatersRelays Compared to RepeatersRelays Compared to Repeaters
[6] RF repeaters have been used in mobile networks for a long time. RF
repeaters amplify the whole RF bandwidth without any decoding or encoding
functionality. RF repeaters have been useful for providing coverage for isolate
locations, for example covering underground locations. There are more
challenges with RF repeaters when used outdoors since RF repeaters amplify
also interference.
The RN first decodes the message from DeNB and then again encodes the
transmission towards UE using optimised packet scheduling. The RN only
sends necessary messages, making sure that interference is not unnecessarily
amplified. Another benefit of the RN is that the transmission between DeNB
and RN can use higher transmission speeds than the transmission between RN
and UE. The resources at DeNB can be quickly reallocated to serve other UEs
or other RN. The same transmission data rate must be used in both links in
radio frame radio frame
Tx Re-Tx Re-Tx
PHICH (ACK/NACK)
PDCCH (UL grant)
adaptive Re-Tx non-adaptive Re-Tx
4 ms 4 ms
UL
DL
PUSCH
radio frame radio frame
Tx Re-Tx
SubframeConfigurationFDD = 01010101
UL
DL
R-PDCCH (UL grant) PUSCH
adaptive Re-Tx
23. 4 Relay
91
case of RF repeaters. The RN has also the benefit that there are no
interference issues between its own transmission and reception because the
different directions are separated in time (inband relay) or in frequency
(outband relay) domain. The RF repeaters require careful planning and
isolation of the antennas to avoid interference problems.
Figure 4-33 Relays compared to repeaters
ReferencesReferencesReferencesReferences
[1, 3GPP 36.912] 3GPP TR 36.912 V11.0.0 (2012-09); Technical Report; 3rd
Generation Partnership Project; Technical Specification Group Radio
Access Network; Feasibility study for Further Advancements for E-
UTRA (LTE-Advanced)
[2, 3GPP 36.300] 3GPP TS 36.300 V11.4.0 (2012-12); Technical
Specification; 3rd Generation Partnership Project; Technical
Specification Group Radio Access Network; Evolved Universal
Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial
Radio Access Network (E-UTRAN); Overall description; Stage 2
[3, 3GPP 36.836] 3GPP TR 36.836 V2.0.1 (2012-10); Technical Report; 3rd
Generation Partnership Project; Technical Specification Group Radio
Access Network; Mobile Relay for Evolved Universal Terrestrial Radio
Access (E-UTRA) (LTE-Advanced)
[4, 3GPP 36.331] 3GPP TS 36.331 V11.3.0 (2013-03); Technical
Specification; 3rd Generation Partnership Project; Technical
Specification Group Radio Access Network; Evolved Universal
Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC);
Protocol specification
Relay Node RF Repeater
Decoding and
encoding
Yes
No, amplifies RF
including interference
Packet scheduling Yes No
Tx-Rx interference
avoidance
Yes, in time (inband) or
frequency (outband)
domain
Requires careful
antenna planning
Different
transmission speeds
in the two links
Yes No
24. LTE-Advanced
92
[5, 3GPP 36.216] 3GPP TS 36.216 V11.0.0 (2012-09); Technical
Specification; 3rd Generation Partnership Project; Technical
Specification Group Radio Access Network; Evolved Universal
Terrestrial Radio Access (E-UTRA); Physical layer for relaying
operation
[6] Holma, H., Toskala, A. (2012). LTE Advanced: 3GPP Solution for IMT-
Advanced. United Kingdom. Wiley-Blackwell