"LTE-Advanced R10/R11" Chapter 04 Relay (sample) by Leliwa

4 Relay

Chapter 4 Relay Topic

Page

Introduction ................................................................................................... 71 Architecture ................................................................................................... 73 S1 and X2 U-plane aspects ........................................................................... 74 S1 and X2 C-plane aspects ........................................................................... 76 Radio protocol aspects .................................................................................. 79 Signalling procedures ................................................................................... 80 RN start-up procedure ................................................................................. 80 RN attach procedure ................................................................................... 81 E-RAB activation/modification .................................................................. 82 RN reconfiguration ..................................................................................... 83 OAM ............................................................................................................... 84 Physical layer ................................................................................................. 85 Relays Compared to Repeaters.................................................................... 90 References ...................................................................................................... 91

LTE-Advanced

This page is intentionally left blank

4 Relay

Introduction [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.

donor cell

R8+

EPC

DeNB

Uu R8+

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.

LTE-Advanced

Inband (type 1)

f1 RN

Outband (type 1a)

f1 RN

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.

RN inter-cell HO

cascaded RNs

Figure 4-3 Relay limitations (R10, R11)

4 Relay

Architecture [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.

MME/S-GW

MME/S-GW S11 S1

S11 S1

eNB

DeNB

includes S/P-GW for 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).

LTE-Advanced

S1 and X2 U-plane aspects The S1 U-plane protocol stack for supporting RNs is shown in Fig. 4-5.

GTP

UDP

PDCP RLC MAC PHY

L2 L1

S1-U

DeNB

S1-U

S-GW

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).

S-GW

P-GW

PDN

1:1

Figure 4-6 S1 & S5/S8 GTP tunnels The X2 U-plane protocol stack for supporting RNs is shown in Fig. 4-7.

GTP

UDP

PDCP RLC MAC PHY

L2 L1

X2-U

DeNB

X2-U

eNB (other)

Figure 4-7 X2 U-plane protocol stack for supporting RNs 74

4 Relay

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-toone 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.

S-GW

QCI=x

QCI=y QCI=y

X2/S1control

MME

O&M

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).

LTE-Advanced

S1 and X2 C-plane aspects The S1 C-plane protocol stack for supporting RNs is shown in Fig. 4-10.

S1AP

SCTP

PDCP RLC MAC PHY

L2 L1

S1-MME

DeNB

S1-MME

MME

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. DeNB RN

S1AP message

1:1 mapping

MME UE S1AP ID, eNB UE S1AP ID, Transport Layer Address, GTP-TEID (…)

S1AP message

MME UE S1AP ID, eNB UE S1AP ID, Transport Layer Address, GTP-TEID (…)

transparent

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.

MME

4 Relay

DeNB

MME

DeNB

MME

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.

X2AP

SCTP

PDCP RLC MAC PHY

L2 L1

X2-C

DeNB

X2-C

MME

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. 77

LTE-Advanced

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. DeNB RN

X2AP message

eNB X2

1:1 mapping

Old eNB UE X2AP ID, New eNB UE X2AP ID, Transport Layer Address, GTP-TEID (â&#x20AC;Ś)

X2AP message

Old eNB UE X2AP ID, New eNB UE X2AP ID, Transport Layer Address, GTP-TEID (â&#x20AC;Ś)

transparent

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.

eNB RN

DeNB eNB

RN 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).

4 Relay

Radio 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.

NAS

RRC

PDCP

RLC

MAC

PHY

DeNB

MME

Figure 4-16 Un C-plane protocol stack for supporting RNs

LTE-Advanced

PDCP

RLC

MAC

PHY

DeNB

Figure 4-17 Un U-plane protocol stack for supporting RNs

Signalling procedures RN startstart-up 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: Attach 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)

4 Relay

Phase Phase II: Attach for 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â&#x20AC;&#x2122; ECGIs are configured by RN OAM.

Figure 4-19 RN start-up procedure (phase 2)

RN 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: â&#x20AC;˘

The DeNB has been made aware of which MMEs support RN functionality via the S1AP SETUP RESPONSE message earlier received from the MMEs;

LTE-Advanced

• •

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. Includes S/P-GW for the RN

RN MME

HSS

DeNB RRC connection setup NAS Attach, Authentication, Security RRC connection reconfiguration

Authentication, Security

GTP-C Create Session S1AP Context Setup (NAS Attach Accept)

Figure 4-20 RN attach procedure

E-RAB 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.

4 Relay

Includes S/P-GW for the RN

RN MME DeNB GTP-C Create/Update Bearer Req.

RRC Connection Reconfiguration

S1AP E-RAB Setup/Modification Req. (NAS SM message)

(NAS SM message)

S1AP E-RAB Setup/Modification Rsp.

UL Information Transfer

UL NAS Transport

(NAS SM message)

(NAS SM message) GTP-C Create/Update Bearer Rsp.

Figure 4-21 DeNB-initiated bearer activation/modification procedure

RN 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. rn-SubframeConfigReq

DeNB

RRC Connection Request RRC Connection Setup RRC Connection Complete RRC RN Reconfiguration RRC RN Reconfiguration Complete rn-SystemInfo (SystemInformationBlockType1 / 2), rn-SubframeConfig (subframeConfigPatternFDD / TDD, rpdcch-Config (resourceAllocationType, resourceBlockAssignment), demodulationRS, pdsch-Start, pucch-Config)

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.

LTE-Advanced

OAM 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.

DeNB

S/P-GW

secure connection

RN OAM

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 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. 84

4 Relay

Physical 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.

TDM

f1 RN

f2 TDM

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.

LTE-Advanced

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. radio frame

radio frame

DeNB-to-RN

RN-to-UE 4 ms

“false” MBSFN subframe

RN-to-DeNB

UE-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). Subframe Configuration TDD 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

eNB-RN UL-DL configuration

Subframe number n 0 d d d d d d d d d d d d d d d d d d d

1 s s s s s s s s s s s s s s s s s s s

2 u u u u u U u U u U u u u u u u u u u

3 u U u U U d D d D D D U U U U U U U u

4 D d D D D d d D d D d u u d d d d D U

5 d d d d d d d d d d d d d d d d d d d

6 s s s s s s s s s s d d d d d d d d s

7 u u u u u u U u U u U D D d D d D D u

8 U u U u U D d D d D D d D d d D D D u

9 d D D D D d d d D d D D D D D D D D D

Figure 4-26 Supported configurations for DeNB-RN transmission (TDD)

4 Relay

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. DL-StartSymbol (1, 2, 3)

0 or 1

DeNB DL x RN RN DL x x x x x x x x x x x x x

â&#x20AC;&#x153;falseâ&#x20AC;? MBSFN subframe

Figure 4-27 DeNB-to-RN transmission (OFDMA symbols)

R-PDCCH The Relay Physical Downlink Control Channel (R-PDCCH) carries DCI for RNs to dynamically assign resources to different RNs within the semistatically 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.

LTE-Advanced

subframe slot

slot

VRB 7 VRB 6 VRB 5 VRB 4 VRB 3 VRB 2 VRB 1

PDCCH and other control channels

VRB n

DL assignment

x x

UL grant

R-PDCCH semi-static configuration

x x x

PDSCH (DeNB-RN) dynamic allocation

x x

VRB 0

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).

RN 0 1

Figure 4-29 R-PDCCH and MIMO 2 Demodulation based on USRs is possible only for a single (non-interleaved) R-PDCCH.

4 Relay

PDSCH and PUCCH 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. radio frame

radio frame

PUCCH/PUSCH (HARQ_ACK)

DL R-PDCCH (UL grant) PDSCH

SubframeConfigurationFDD = 01010101

Figure 4-30 PDSCH, R-PDCCH and PUCCH/PUSCH

PUSCH and 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.

LTE-Advanced

adaptive Re-Tx radio frame 4 ms

non-adaptive Re-Tx radio frame

4 ms

Re-Tx

DL PHICH (ACK/NACK) PDCCH (UL grant)

PUSCH

Figure 4-31 R8 UL Uu i/f adaptive and non-adaptive re-Tx adaptive Re-Tx radio frame

radio frame Tx

Re-Tx

DL R-PDCCH (UL grant)

PUSCH

SubframeConfigurationFDD = 01010101

Figure 4-32 R10 UL Un i/f adaptive re-Tx

Relays 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

4 Relay

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. Relay Node

RF Repeater

Decoding and encoding

Yes

No, amplifies RF including interference

Packet scheduling

Yes

Tx-Rx interference avoidance

Yes, in time (inband) or frequency (outband) domain

Requires careful antenna planning

Different transmission speeds in the two links

Yes

Figure 4-33 Relays compared to repeaters

References [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 EUTRA (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

LTE-Advanced

[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 IMTAdvanced. United Kingdom. Wiley-Blackwell