E-UTRAN R10/LTE-Advanced Delta

553 views

Published on

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.

Published in: Technology
  • can you give me this slide, it's very importan for me. thanks in advance
    mail: longgiangdtht@gmail.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

E-UTRAN R10/LTE-Advanced Delta

  1. 1. 4 Relay 69 ChapterChapterChapterChapter 4444 RelayRelayRelayRelay TopicTopicTopicTopic PagePagePagePage 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
  2. 2. LTE-Advanced 70 This page is intentionally left blank
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×