One of the biggest problem in LTE would be that the performance at cell edge would not be as good as those in CDMA/WCDMA. So understandably, one of the biggest feature of LTE advanced would be to come out with a wise compensation measure. On top of it, this compensation measure should be very economic.
One of the most popular idea (or real implemetation) for this would be to add various relay node (RN) as illustrated below.
Two names for the same kind of radio link. The hop from the donor to a relay is a backhaul link and carries the label Un. Every hop that ends at a UE is an access link and carries the label Uu.
UE A has no relay in its path : its access link runs straight to the DeNB, so the drawing shows the unrelayed case and the relayed one side by side.Un is the new interface : the link between the DeNB and each relay node is the only one labelled Backhaul link, and the only one labelled Un.Uu is reused unchanged : the hop from a relay node to its UE carries the same Uu label as the direct hop from the DeNB to UE A.The four arrow names come in pairs : UE-to-RN and RN-to-eNB point towards the network in blue, eNB-to-RN and RN-to-UE point away from it in red.The centre tower is the donor : 36.216 writes donor eNB, and the drawing labels it DeNB.
Conceptually Relay Node can be implemented in any layer (e.g,RF/L1, L2, L3) as described in DoCoMo Technology Report vol 12-2, but as 3GPP specification gets established as in 36.216, it seems the implementation goes towards L1 and low L2. It means it would do some baseband processing and low MAC scheduling as well.
What a Relay Node is on each of its two interfaces
The drawing above gives a relay node two radio links and two sets of labels. It cannot show that the relay behaves as a different kind of node on each of them. One sentence in 36.216 settles that, and it settles everything the rest of this page describes.
36.216 clause 4 opens with the UE view. From a UE perspective a relay node is part of the radio access network and behaves like an eNB, and a relay node is wirelessly connected to a donor eNB. So a UE camped on a relay runs the ordinary procedures and never learns that its cell is relayed.
The next paragraph gives the other view, and it is the one worth remembering. A relay node includes at least two physical layer entities. One is used for communication with UEs. The other is used for communication with the donor eNB, and 36.216 says it corresponds to UE functionality.
On Un the relay is therefore a UE. That is why everything below reads as a short list of exceptions rather than as a new physical layer. The relay already has a complete UE receiver, so the specification only has to say where it differs. The clause even says so, calling the differences relay-specific advancements on top of ordinary UE functionality.
The two entities also have to share one radio. A relay cannot transmit to its own UEs and receive from the donor at the same moment on the same band. The next section is entirely about how the specification separates those two jobs in time.
Clause 7 says the same thing again, this time about procedures rather than entities. The relay node acts according to the UE procedures with the exceptions defined in that clause, and DCI shall be transmitted by means of R-PDCCH. One exception is worth noticing straight away: a relay node shall not expect DCI format 3 or 3A, which are the group power control formats an ordinary UE watches for.
The exceptions that follow read like a UE with some of its feedback paths removed. 36.216 clause 7.3 says the relay node shall not expect HARQ feedback on PHICH. An ACK shall be delivered to higher layers for every transport block transmitted on PUSCH. The relay sends uplink data and its own MAC is told the transmission succeeded, because no channel carries the real answer back.
Other UE behaviour survives intact. The relay transmits PUCCH to the donor, and 36.216 clause 7.5.1 adds only that it shall transmit a scheduling request in uplink subframes configured for RN-to-eNB transmission. So the relay asks its donor for uplink resources exactly as a handset asks a cell, and the only restriction is when it may ask.
Even the control channel search is divided by slot. 36.216 clause 7.4.1 has the relay watch the configured resource blocks in the first slot for a downlink assignment, and the same blocks in the second slot for an uplink grant. A downlink assignment and an uplink grant therefore never share a slot.
The number of HARQ processes follows from the subframe pattern as well. 36.216 clause 7.3 derives it for FDD through Table 7.3-1, keyed on the decimal equivalent of the same eight bit SubframeConfigurationFDD bitmap. The processes are then assigned to the RN-to-eNB subframes in order. A relay given one backhaul subframe in eight has fewer processes to work with than a UE has.
An eNB on Uu, a UE on Un : 36.216 clause 4 gives the relay two physical layer entities and says the donor-facing one corresponds to UE functionality.The UE is not told : from a UE perspective the relay is part of the radio access network and behaves like an eNB.The relay is wirelessly connected : there is no wired backhaul in this architecture, which is what the whole feature exists to avoid.The rest of 36.216 is a list of exceptions : a complete UE physical layer is assumed, and only the differences are written down.No PHICH reaches the relay : 36.216 clause 7.3 removes the HARQ feedback channel and has an ACK delivered to higher layers instead.Assignments and grants split by slot : the relay looks for a downlink assignment in the first slot and an uplink grant in the second.DCI format 3 and 3A are not expected : the group power control formats an ordinary UE watches for are excluded by clause 7.1.
Physical Layer aspect
As you see in the illustration above, Relay Node has two radio access interfaces. One is for radio access with UE and the other is for radio access for eNB. According to 36.216, each path is labeled with its own name as shown in the picture (UE-to-RN, RN-to-eNB, eNB-to-RN, RN-to-UE).
Can a Relay Network communicate with eNB at any subframe ?
This was the first question that popped up in my mind and the answer from 36.216 is 'No, they need to communicate only at specific subframe. The reason is the one at the end of the section above. One radio cannot serve the access link and the backhaul link in the same subframe, so the two are separated in time.
In case of FDD, this communication can happen only at the subframe that satisfy the following condition.
The left side of that condition is just the subframe number counted from the start of time. The frame number contributes ten subframes each, and the floor of the slot number halved picks the subframe inside the frame. Taking it modulo 8 gives the position in an eight subframe cycle, and the set on the right holds the positions that belong to the backhaul.
Eight does not divide ten, so the pattern does not line up with the radio frame. 36.331 fixes the phase instead: the radio frame in which the first bit of subframeConfigPatternFDD corresponds to subframe 0 is the one where SFN mod 4 equals 0. Four frames of ten subframes hold exactly five turns of the eight subframe cycle, so the whole arrangement repeats every 40 ms.
36.216 Table 5.2-1 : Downlink subframe configuration for eNB-to-RN transmission
The bitmap is read right to left : the rightmost bit gives offset 7 and the leftmost gives offset 0.An x means either value : the set of offsets is the union of the rows whose marked bit is set.Several bits may be set at once : the set is a union, so a UE can be given more than one backhaul subframe in each cycle.The capture below sets the last bit only : subframeConfigPatternFDD-r10 reads 00000001, which by this table is the single offset 7.
Which of the configuration will be used is determined by RRC message (rnReconfiguration) as shown below.
One line in 36.216 clause 5.2 explains where the relay's listening time comes from. Downlink subframes configured for eNB-to-RN transmission shall be configured as MBSFN subframes by the relay node. The relay announces those subframes to its own UEs as multicast subframes. The UEs stop expecting unicast data in them, and the relay can then turn its receiver towards the donor.
That borrowed mechanism also sets the limit. A downlink subframe which cannot be configured as an MBSFN subframe in the relay node cell shall not be configured for eNB-to-RN transmission. The subframes carrying synchronisation and system information are therefore unavailable, whatever the bitmap says.
The uplink half needs no bitmap of its own. 36.216 pairs each RN-to-eNB subframe with an earlier eNB-to-RN subframe at a fixed distance, so configuring the downlink configures the uplink with it. That is the same timing relationship an ordinary UE uses, which follows from the relay being a UE on this interface.
In case of TDD, this communication can happen only at the subframe
36.216 Table 5.2-2 : Supported Configurations for eNB-RN transmission
Nineteen rows, five uplink-downlink configurations : the second column groups SubframeConfigurationTDD 0 to 18 under eNB-RN uplink-downlink configurations 1, 2, 3, 4 and 6.Two of the seven configurations never appear : configuration 0 and configuration 5 have no row in the table at all.Four subframe numbers are never used : columns 0, 1, 5 and 6 are blank in every one of the nineteen rows, which follows from the MBSFN restriction.D and U are both in the table : unlike the FDD case, one TDD row fixes the downlink and the uplink subframes together.
Which of the configuration will be used is determined by RRC message (rnReconfiguration) as shown below.
Following is based on
RN-SubframeConfig-r10 ::= SEQUENCE {
subframeConfigPattern-r10 CHOICE {
subframeConfigPatternFDD-r10 BIT STRING (SIZE(8)),
subframeConfigPatternTDD-r10 INTEGER (0..31)
} OPTIONAL, -- Need ON
rpdcch-Config-r10 SEQUENCE {
resourceAllocationType-r10 ENUMERATED {type0, type1, type2Localized, type2Distributed,
spare4, spare3, spare2, spare1},
resourceBlockAssignment-r10 CHOICE {
type01-r10 CHOICE {
nrb6-r10 BIT STRING (SIZE(6)),
nrb15-r10 BIT STRING (SIZE(8)),
nrb25-r10 BIT STRING (SIZE(13)),
nrb50-r10 BIT STRING (SIZE(17)),
nrb75-r10 BIT STRING (SIZE(19)),
nrb100-r10 BIT STRING (SIZE(25))
},
type2-r10 CHOICE {
nrb6-r10 BIT STRING (SIZE(5)),
nrb15-r10 BIT STRING (SIZE(7)),
nrb25-r10 BIT STRING (SIZE(9)),
nrb50-r10 BIT STRING (SIZE(11)),
nrb75-r10 BIT STRING (SIZE(12)),
nrb100-r10 BIT STRING (SIZE(13))
},
...
},
demodulationRS-r10 CHOICE {
interleaving-r10 ENUMERATED {crs},
noInterleaving-r10 ENUMERATED {crs, dmrs}
},
pdsch-Start-r10 INTEGER (1..3),
pucch-Config-r10 CHOICE {
tdd CHOICE {
channelSelectionMultiplexingBundling SEQUENCE {
n1PUCCH-AN-List-r10 SEQUENCE (SIZE (1..4)) OF INTEGER (0..2047)
},
fallbackForFormat3 SEQUENCE {
n1PUCCH-AN-P0-r10 INTEGER (0..2047),
n1PUCCH-AN-P1-r10 INTEGER (0..2047) OPTIONAL -- Need OR
}
},
fdd SEQUENCE {
n1PUCCH-AN-P0-r10 INTEGER (0..2047),
n1PUCCH-AN-P1-r10 INTEGER (0..2047) OPTIONAL -- Need OR
}
},
...
} OPTIONAL, -- Need ON
...
}
Both captures decode the same structure, and it is short enough to read whole. 36.331 puts the two patterns in one CHOICE, so a relay gets the FDD bitmap or the TDD index and never both.
Three of the field types are worth checking against the tables above. subframeConfigPatternFDD-r10 is a BIT STRING of size 8, which is the eight bit pattern of Table 5.2-1. subframeConfigPatternTDD-r10 is an INTEGER from 0 to 31, which is wider than Table 5.2-2 needs: the table stops at 18, so the top thirteen values have nothing behind them. pdsch-Start-r10 is an INTEGER from 1 to 3, and 36.331 describes it as the DL-StartSymbol parameter of 36.216 Table 5.4-1.
The other half of the element is the R-PDCCH configuration, which the section below is about. resourceAllocationType-r10 offers type 0, type 1 and the two forms of type 2. demodulationRS-r10 chooses between the two multiplexing modes: interleaving-r10 accepts only crs, and noInterleaving-r10 accepts crs or dmrs.
One CHOICE, two duplex modes : a relay is configured with the FDD bitmap or the TDD index, never with both.The FDD field is a bit string of 8 : it matches Table 5.2-1 exactly.The TDD field has unused range : INTEGER (0..31) against a table that stops at 18.pdsch-Start is DL-StartSymbol : 36.331 names the 36.216 parameter it carries, and its range of 1 to 3 is the three rows of Table 5.4-1.
Can a Relay Network communicate with eNB at any OFDMA Symbol ?
The answer from 36.216 is 'No' as well in this case. The usuable symbol differs between the first and second symbol as well. This symbol allocation is also defined in 36.216 as shown below.
36.216 Table 5.4-1 : OFDM Symbols for eNB-to-RN transmission in the first slot
36.216 Table 5.4-2 : OFDM Symbols for eNB-to-RN transmission in the second slot
Both tables are for normal cyclic prefix : the captions in 36.216 say so, and the page's copies leave that off.The first slot varies only at the start : the three configurations give DL-StartSymbol 1, 2 and 3, and every one of them ends at symbol 6.The second slot varies only at the end : both configurations start at symbol 0, and they end at symbol 6 or symbol 5.The start symbol is the relay's own control region : the first one, two or three symbols belong to the relay's cell before it can listen to the donor.
Which Symbols can be used is determined by RRC message as shown below.
The highlighted field is pdsch-Start-r10 and it reads 1. 36.331 describes that field as DL-StartSymbol, so by Table 5.4-1 this relay is on configuration 0 and reads the donor from symbol 1 to symbol 6 of the first slot.
Those tables also decide where the control channel of the backhaul can sit. 36.216 clause 5.6.1 puts R-PDCCH on configuration 2 of Table 5.4-1, or on configuration 0 or 1 of Table 5.4-2. R-PDCCH in the first slot therefore always starts at symbol 3, whatever DL-StartSymbol the PDSCH was given.
pdsch-Start-r10 reads 1 in the capture : that is configuration 0 of Table 5.4-1, symbols 1 to 6.R-PDCCH uses one fixed first-slot configuration : 36.216 clause 5.6.1 names configuration 2 of Table 5.4-1, so the control channel starts at symbol 3.The second slot gives R-PDCCH both of its rows : configuration 0 or configuration 1 of Table 5.4-2 applies there.
Does eNB/RN use the same type of DCI and Control Channel as in eNB/UE communication
DCI would be the same type as in eNB/UE, but the control channel that carries the DCI is different. eNB-to-RN transmission we use a special control channel called R-PDCCH.
There are differences between R-PDCCH and conventional PDCCH as well. Whereas PDCCH is carried by the special control symbols (symbo 0-2 depending on CFI setting), R-PDCCH is carried outside of the conventional PDCCH region. More specifically, R-PDCCH is carried in Configuration 2 in 36.216 Table 5.4-1 or Configuration 0 or 1 in 36.216 Table 5.4-2. If R-PDCCH is carried by the first slot, PDSCH cannot be allocated in that slot.
For further details, refer to 5.6 of 36.216
36.216 clause 5.6 splits R-PDCCH two ways, and the split matters because it changes what the relay demodulates against. Without cross interleaving an R-PDCCH occupies one or several physical resource blocks on its own. With cross interleaving several R-PDCCHs are interleaved together across the same blocks.
The two modes do not offer the same reference signals. 36.331 carries the choice as demodulationRS, and the cross interleaving branch accepts only cell-specific reference signals, while the branch without it accepts cell-specific or UE-specific ones. The capture further up this page shows interleaving-r10 with crs.
The specification carries the same rule the paragraph above states. 36.216 clause 5.5 forbids the PDSCH any resource element in the first slot of a resource block pair, on any antenna port, when that slot carries R-PDCCH. The exclusion is per resource block pair rather than per subframe.
The blocks themselves are configured rather than fixed. Higher layers configure a set of virtual resource blocks for potential R-PDCCH transmission. They use resource allocation type 0, 1 or 2, which is the resourceAllocationType field in the tile above.
R-PDCCH carries DCI for relay nodes : 36.216 clause 5.6.1 states its job in one sentence.Two multiplexing modes : one R-PDCCH alone in its resource blocks, or several interleaved across them.The mode picks the reference signal : cross interleaving allows cell-specific reference signals only.The PDSCH exclusion is per block pair : a first slot used for R-PDCCH removes that block pair from the PDSCH, not the whole subframe.The candidate blocks are configured : higher layers give the relay a set of virtual resource blocks using resource allocation type 0, 1 or 2.
Does eNB use the same downlink reference signal as in eNB-to-UE Communication
The answer is Yes with a little bit of exception as follows : Both exceptions are narrow, and both follow from the relay reading only part of each subframe rather than all of it.
- The reference signal sequence of antenna port 7,8,9,10 shall only be mapped to resource elements in the first slot of a PRB pair if the configuration 1 in Table 5.4-2 is used.
- Antenna ports 11 to 14 shall not be used for eNB-to-RN transmission
The first exception is tied to one row of one table. 36.216 clause 5.7.1 restricts antenna ports 7 to 10 to the first slot of a resource block pair, and only when configuration 1 of Table 5.4-2 is used. That configuration is the one ending the second slot at symbol 5 rather than 6. The reference signals that would have sat in the missing symbol have nowhere to go.
The second exception is flat. Antenna ports 11 to 14 shall not be used for eNB-to-RN transmission at all, and no configuration restores them.
Everything else is unchanged. The clause opens by saying eNB-to-RN transmissions use the same reference signals as an ordinary downlink. That is the pattern every section above has followed: a UE receiver, with a short list of exceptions written against it.
Ports 7 to 10 are limited by configuration, not always : the restriction applies when configuration 1 of Table 5.4-2 is in use.Ports 11 to 14 are barred outright : 36.216 clause 5.7.1 allows no exception to that one.The rest is the ordinary downlink : the clause says so before listing either exception.
Reference
One specification defines every table, every symbol limit and every exception quoted above, and a second carries the RRC element that selects among them. The third entry is the report the introduction links to.
- [1] 36.216 : 3GPP - E-UTRA; Physical layer for relaying operation, v19.0.0. Clause 4 defines the two physical layer entities, clause 5.2 holds Tables 5.2-1 and 5.2-2, and clause 5.4 holds Tables 5.4-1 and 5.4-2.
- [2] 36.331 : 3GPP - E-UTRA; Radio Resource Control, v19.3.0. RN-SubframeConfig-r10 is quoted above.
- [3] DoCoMo Technology Report vol 12-2 : the report on relay layers that the introduction above points at.