36912-c00

3GPP TR 36.912

PAGE 2

3GPP TR 36.912 V12.0.0 (2014-09)Technical Report

3rd Generation Partnership Project;

Technical Specification Group Radio Access Network;

Feasibility study for

Further Advancements for E-UTRA (LTE-Advanced)(Release 12)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.

Keywords

LTE, Radio

3GPP

Postal address

3GPP support office address

650 Route des Lucioles - Sophia Antipolis

Valbonne - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet

http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.

2014, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).

All rights reserved.

UMTS is a Trade Mark of ETSI registered for the benefit of its members

3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational PartnersLTE is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational PartnersGSM and the GSM logo are registered and owned by the GSM Association

Contents

6Foreword

1Scope72References73Definitions, symbols and abbreviations83.1Definitions83.2Symbols83.3Abbreviations84Introduction85Support of wider bandwidth85.1General85.1A Physical layer95.1A.1 DL control signalling95.1A.2UL control signalling95.2User Plane105.2.1Structure105.2.2MAC115.2.3RLC115.2.4PDCP115.3Control plane115.3.1Structure115.3.2RRC procedures125.3.2.1System Information125.3.2.2Connection Control125.3.2.3Measurements125.3.3Idle mode procedures126Uplink transmission scheme126.1Uplink spatial multiplexing126.1AUplink transmit diversity146.1A.1Transmit Diversity for Uplink Control Channel146.2Uplink multiple access146.3Uplink reference signals156.4Uplink power control157Downlink transmission scheme157.0Physical channel mapping157.1Downlink spatial multiplexing157.1.1Feedback in support of downlink spatial multiplexing167.2Downlink reference signals167.3Downlink transmit diversity178Coordinated multiple point transmission and reception178.1Downlink coordinated multi-point transmission178.2Uplink coordinated multi-point reception179Relaying179.1General179.2Architecture189.3Relay-eNodeB link for inband relay189.3.1Resource partitioning for relay-eNodeB link189.3.2Backward compatible backhaul partitioning199.3.3Backhaul resource assignment199.4Relay-eNodeB link for outband relay2010Improvement for latency2010.1Improvement for C-Plane latency2010.2Improvement for U-Plane latency2111Radio transmission and reception2111.1RF scenarios2111.1.1Deployment scenarios2111.2Common requirements for UE and BS2111.2.1Carrier Aggregation2111.2.1.1Bandwidth configuration of component carriers2111.2.1.2Carrier spacing between component carriers2111.2.2Operating bands2211.3UE RF requirements2311.3.1General2311.3.2Transmitter characteristics2311.3.2.1Transmitter architecture2311.3.2.2Transmit power2411.3.2.3Output power dynamics2411.3.2.4Transmit signal quality2511.3.2.5Output RF spectrum emissions2511.3.2.5.1Adjacent Channel Leakage ratio2511.3.2.5.2Spurious emission (UE to UE co-existence)2511.3.2.6Transmit intermodulation2511.3.3Receiver characteristics2511.3.3.1Receiver architecture2611.3.3.2Receiver Sensitivity2611.3.3.3Selectivity2611.3.3.4Blocking performance2711.3.3.5Spurious response275.3.3.6Intermodulation performance2711.3.3.7 Spurious emission2711.4BS RF requirements2711.4.1General2711.4.2Transmitter characteristics2811.4.2.1Base Station output power2811.4.2.2Transmitted signal quality2811.4.2.3Unwanted emissions2811.4.2.4Transmitter spurious emissions2811.4.3Receiver characteristics2911.4.3.1Reference sensitivity level2911.4.3.2Adjacent Channel Selectivity (ACS), narrow-band blocking, Blocking, Receiver intermodulation2911.4.3.3Performance requirements2912Mobility enhancements2913TS 36.133 [17] requirements enhancements3014MBMS Enhancements3015SON Enhancements3016Self-Evaluation Report on "LTE Release 10 and beyond (LTE-Advanced)"3016.1Peak spectral efficiency3116.2C-plane latency3216.2.1Idle to Connected3216.2.2Dormant to Active3316.3U-Plane latency3416.4Spectral efficiency and user throughput3416.4.1Cell spectral efficiency and cell-edge spectral efficiency3416.4.1.1Indoor3416.4.1.2Microcellular3516.4.1.3Base coverage urban3616.4.1.4High speed3716.4.2Number of supported VoIP users3916.4.3Mobility traffic channel link data rates3916.5Handover Performance4016.5.1Intra-frequency handover interruption time4216.5.2Inter-frequency handover interruption time within a spectrum band4216.5.3Inter-frequency handover interruption time between spectrum bands4216.6Spectrum and bandwidth4216.6.1Deployment in IMT bands4216.6.2Bandwidth and channel bandwidth scalability4316.7Services4316.8Conclusions of the Self-Evaluation4316APerformance Evaluation of LTE-Advanced for 3GPP target fulfillment4417Conclusions46Annex A:Simulation model47A.1General assumption47A.2CoMP assumption for evaluation49A.3Detailed simulation results49Annex B:Latency performance of Rel-850B.1C-plane latency50B.1.1 Transition IDLE to CONNECTED50B.1.1.1FDD frame structure50B.1.1.2TDD frame structure51B.1.2 Transition Dormant to Active52B.1.2.1FDD frame structure53B.1.2.1.1Uplink initiated transition, synchronized53B.1.2.1.2Uplink initiated transition, unsynchronized53B.1.2.1.3Downlink initiated transition, synchronized53B.1.2.1.4Downlink initiated transition, unsynchronized53B.1.2.2TDD frame structure54B.1.2.2.1Uplink initiated transition, synchronized54B.1.2.2.2Uplink initiated transition, unsynchronized54B.1.2.2.3Downlink initiated transition, synchronized55B.1.2.2.4Downlink initiated transition, unsynchronized55B.2U-plane latency56B.2.1FDD frame structure56B.2.2TDD frame structure57Annex C:ITU-R Submission Templates60C.1Description template characteristics (4.2.3.2)60C.2Description template link budget (4.2.3.3)60C.3Compliance templates for services (4.2.4.1), for spectrum (4.2.4.2), technical performance (4.2.4.3)60Annex D:Change history61

ForewordThis Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

xthe first digit:

1presented to TSG for information;

2presented to TSG for approval;

3or greater indicates TSG approved document under change control.

ythe second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.

zthe third digit is incremented when editorial only changes have been incorporated in the document.

1Scope

This document is related to the technical report for the study item "Further advancements for E-UTRA" [1]. This activity involves the Radio Access work area of the 3GPP studies and has impacts both on the Mobile Equipment and Access Network of the 3GPP systems.This document is intended to gather all technical outcome of the study item, and draw a conclusion on way forward.In addition this document includes the results of the work supporting the3GPP submission of "LTE Release 10 & beyond (LTE-Advanced)"to the ITU-R as a candidate technology for the IMT-Advanced.2ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or nonspecific.

For a specific reference, subsequent revisions do not apply.

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]Contribution to 3GPP TSG RAN meeting #45 RP-090735: "Revised SID on LTE-Advanced".

[2]3GPP TR 21.905: "Vocabulary for 3GPP Specifications".[3]3GPP TR 36.913: "Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (EUTRAN)".[4]3GPP TS 23.203: "Policy and charging control architecture".

[5]3GPP TS 36.101: "User Equipment (UE) radio transmission and reception".[6]3GPP TS 36.104: "Base Station (BS) radio transmission and reception".[7] Report ITU-R M.2133: "Requirements, evaluation criteria and submission templates for the development of IMT-Advanced" (Approved 2008-11).[8] Report ITU-R M.2134: "Requirements related to technical performance for IMT-Advanced radio interface(s)" (Approved 2008-11).[9] Report ITU-R M.2135: "Guidelines for evaluation of radio interface technologies for IMTAdvanced" (Approved 2008-11).[10]Document ITU-R IMT-ADV/3: "Correction of typographical errors and provision of missing texts of IMT-Advanced channel models in Report ITU-R M.2135" (July 2009).[11]Document ITU-R IMT-ADV/2 Rev 1: "Submission and evaluation process and consensus building" (Approved 2008-10).[12]3GPP TS 36.213: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures"[13]Contribution to 3GPP TSG RAN meeting #45 RP-090744: "TR36.912 Annex A3: Self evaluation results".[14]Contribution to 3GPP TSG RAN meeting #45 RP-090745: "TR36.912 Annex C1: Updated characteristics template".[15]Contribution to 3GPP TSG RAN meeting #45 RP-090746: "TR36.912 Annex C2: Link budget template".[16]Contribution to 3GPP TSG RAN meeting #45 RP-090747: "TR36.912 Annex C3: Compliance template".[17]3GPP TS 36.133: "Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for support of radio resource management".[18]3GPP TR 36.814: " Feasibility study for Further Advancements for E-UTRA (LTE-Advanced)"Note:The RAN meeting contributions referenced above are provided with the present Technical Report. 3Definitions, symbols and abbreviations

3.1Definitions

For the purposes of the present document, the terms and definitions given in TR21.905[2] apply.

3.2Symbols

Void3.3Abbreviations

For the purposes of the present document, the abbreviations defined in 3GPP TS21.905 [2] and the following apply:CoMPCoordinated MultiPointMBMSMultimedia Broadcast/Multicast Service

MU-MIMOMulti User Multiple Input Multiple Output

RITRadio Interface Technology

SONSelf Organising Networks

SRITSet of Radio Interface Technologies

SU-MIMOSingle User Multiple Input Multiple Output

4Introduction

At the 3GPP TSG RAN #39 meeting, the Study Item description on "Further Advancements for E-UTRA (LTE-Advanced)" was approved [1]. The study item covers technology components to be considered for the evolution of E-UTRA, e.g. to fulfil the requirements on IMT-Advanced. This technical report covers all RAN aspects of these technology components.5Support of wider bandwidth

5.1General

LTE-Advanced extends LTE Rel.-8 with support for Carrier Aggregation, where two or more component carriers (CCs) are aggregated in order to support wider transmission bandwidths up to 100MHz and for spectrum aggregation.

It shall be possible to configure all component carriers which are LTE Rel-8 compatible, at least when the aggregated numbers of component carriers in the UL and the DL are the same. Not all component carriers may necessarily be LTE Rel-8 compatible.

A terminal may simultaneously receive or transmit one or multiple component carriers depending on its capabilities:

-An LTE-Advanced terminal with reception and/or transmission capabilities for carrier aggregation can simultaneously receive and/or transmit on multiple component carriers.-An LTE Rel-8 terminal can receive and transmit on a single component carrier only, provided that the structure of the component carrier follows the Rel-8 specifications.

Carrier aggregation is supported for both contiguous and non-contiguous component carriers with each component carrier limited to a maximum of 110 Resource Blocks in the frequency domain using the LTE Rel-8 numerology

It is possible to configure a UE to aggregate a different number of component carriers originating from the same eNB and of possibly different bandwidths in the UL and the DL. In typical TDD deployments, the number of component carriers and the bandwidth of each component carrier in UL and DL will be the same.Component carriers originating from the same eNB need not to provide the same coverage.The spacing between centre frequencies of contiguously aggregated component carriers shall be a multiple of 300 kHz. This is in order to be compatible with the 100 kHz frequency raster of LTE Rel-8 and at the same time preserve orthogonality of the subcarriers with 15 kHz spacing. Depending on the aggregation scenario, the n*300 kHz spacing can be facilitated by insertion of a low number of unused subcarriers between contiguous component carriers.5.1A Physical layer

5.1A.1 DL control signallingThe design principles for downlink control signalling of control region size, uplink and downlink resource assignments, and downlink HARQ ACK/NACK indication are described below.

- Independent control region size is applied for each component carrier. On any carrier with a control region, Rel-8 design (modulation, coding, mapping to resource elements) for PCFICH is reused.

- For signalling of resource assignments for downlink (PDSCH) and uplink (PUSCH) transmission, following mechanisms are supported,- PDCCH on a component carrier assigns PDSCH resources on the same component carrier and PUSCH resources on a single linked UL component carrier. Rel-8 PDCCH structure (same coding, same CCE-based resource mapping) and DCI formats are used on each component carrier.- PDCCH on a component carrier can assign PDSCH or PUSCH resources in one of multiple component carriers using the carrier indicator field, where Rel-8 DCI formats are extended with 1 3 bit carrier indicator field, and Rel-8 PDCCH structure (same coding, same CCE-based resource mapping) is reused.

where the presence of carrier indicator field is semi-statically configured. -For signalling of downlink HARQ ACK/NACK indication, following principles are applied.-PHICH physical transmission aspects from Rel-8 (orthogonal code design, modulation, scrambling sequence, mapping to resource elements) are reused.-PHICH is transmitted only on the downlink component carrier that was used to transmit the UL grant

-At least in case that the number of downlink component carriers are more than or equal to that of uplink component carriers and no carrier indicator field is used, the Rel-8 PHICH resource mapping rule is reused. 5.1A.2UL control signallingThe design principles for uplink control signalling of HARQ ACK/NACK, scheduling request and channel state information (CSI) on PUCCH are described below.

The Rel-10 PUCCH design supports up to five DL component carriers.

For signalling of HARQ ACK/NACK on PUCCH for downlink (PDSCH) transmission, following mechanisms are supported:- All HARQ ACK/NACK for a UE can be transmitted on PUCCH in absence of PUSCH transmission.-In general, transmission of one ACK/NACK for each DL component carrier transport block is supported.

-In case of power limitation, limited transmission of ACK/NACK for the DL component carrier transport blocks is supported.

-The design of the ACK/NACK resource allocation should consider performance and power control aspects, while not aiming to optimise for the case of large number of UEs being simultaneously scheduled on multiple DL component carriers. The scheduling request is transmitted on PUCCH and is semi-statically mapped onto one UE specific UL component carrier. Periodic CSI reporting on PUCCH is supported for up to five DL component carriers. The CSI is semi-statically mapped onto one UE specific UL component carrier and the design follows the Rel-8 principles for CQI/PMI/RI, considering ways to reduce reporting overhead or to extend CSI payload.5.2User Plane5.2.1Structure

Compared to the Layer 2 structure of LTE Rel-8, the multi-carrier nature of the physical layer is only exposed to the MAC layer for which one HARQ entity is required per CC. The Layer 2 structure for the downlink is depicted on Figured 5.2.1-1 below.

Figure 5.2.1-1: Layer 2 Structure for the DL

The Layer 2 structure for the uplink is depicted on Figured 5.2.1-2 below.

Figure 5.2.1-2: Layer 2 Structure for the UL

5.2.2MAC

From a UE perspective, the Layer 2 aspects of HARQ are kept Rel-8 compliant unless modifications provide significant gains. There is one transport block (in absence of spatial multiplexing, up to two transport blocks in case of spatial multiplexing) and one independent hybrid-ARQ entity per scheduled component carrier. Each transport block is mapped to a single component carrier only where all possible HARQ retransmissions also take place. A UE may be scheduled over multiple component carriers simultaneously but at most one random access procedure shall be ongoing at any time.Whenever a UE is configured with only one CC, Rel-9 DRX is the baseline. In other cases, the baseline is that the same DRX operation applies to all configured CCs (i.e. identical active time for PDCCH monitoring). When in active time, any CC may always schedule PDSCH on any other configured (and possibly activated, FFS) CC.5.2.3RLC

The RLC protocol of LTE Rel-8 also applies to carrier aggregation and allows LTE-A to handle data rate up to 1Gbps. Further enhancements (e.g. increased RLC SN size) can be considered.

5.2.4PDCP

The PDCP protocol of LTE Rel-8 also applies to carrier aggregation. Further enhancements (e.g. increased PDCP SN size) can be considered.5.3Control plane

5.3.1Structure

The C-Plane architecture of LTE Rel-8 also applies to carrier aggregation.

5.3.2RRC procedures

5.3.2.1System Information

A cell is identified by a unique ECGI and corresponds to the transmission of system information in one CC. Rel-8 relevant system information and possible extensions for LTE-A are delivered on backward compatible CCs. Each CC provides on BCCH the system information which is specific to it. The handling of system information for extension carriers is FFS.

5.3.2.2Connection Control

As in LTE Rel-8, the UE only has one RRC connection with the network. One cell - the special cell - provides the security input (one ECGI, one PCI and one ARFCN) and the NAS mobility information (e.g. TAI). There is only one special cell per UE in connected mode.

After RRC connection establishment to the special cell, the reconfiguration, addition and removal of CCs can be performed by RRCConnectionReconfiguration including mobilityControlInfo (i.e. intra-cell handover). RRCConnectionReconfiguration without mobilityControlInfo can also be used for the addition of CCs, and for the removal of CCs with the exception of the CC corresponding to the special cell.

At intra-LTE handover, the RRCConnectionReconfiguration with mobilityControlInfo (i.e. "handover command") can remove, reconfigure or add CCs for usage in the target cell.When adding a new CC, dedicated RRC signalling is used for sending CCs system information which is necessary for CC transmission/reception (similarly as in Rel-8 for handover).

Detection of failure of one CC by the UE does not necessarily trigger a connection re-establishment. RRC connection re-establishment triggers at the UE include:

1)The failure of all CCs on which the UE is configured to receive PDCCH;

NOTE:FFS if re-establishment is triggered under more restrictive conditions (e.g. in case of problems on a smaller subset of CCs).

2)The loss of all UL communication;

NOTE:The conditions under which all UL communications are said to be lost are FFS.

3)The indication from RLC that the maximum number of retransmissions has been reached (as in Rel-8).

5.3.2.3Measurements

UE sees a CC as any other carrier frequency and a measurement object needs to be set up for a CC in order for the UE to measure it. Inter-frequency neighbour measurements (for which no serving cell is defined for measurement purposes) encompass all the carrier frequencies which are not configured as CCs.5.3.3Idle mode procedures

Idle mode mobility procedures of LTE Rel-8 also apply in a network deploying carrier aggregation. It should be possible for a network to configure only a subset of CCs for idle mode camping.6Uplink transmission scheme6.1Uplink spatial multiplexingLTE-Advanced extends LTE Rel-8 with support for uplink spatial multiplexing of up to four layers.In case of uplink single-user spatial multiplexing, up to two transport blocks can be transmitted from a scheduled UE in a subframe per uplink component carrier. Each transport block has its own MCS level. Depending on the number of transmission layers, the modulation symbols associated with each of the transport blocks are mapped onto one or two layers according to the same principle as for LTE Rel-8 downlink spatial multiplexing. The transmission rank can be adapted dynamically. It is possible to configure the uplink single-user spatial-multiplexing transmission with or without the layer shifting. In case of the layer shifting, shifting in time domain is supported. If layer shifting is configured, the HARQ-ACKs for all transport blocks are bundled into a single HARQ-ACK. One-bit ACK is transmitted to the UE if all transport blocks are successfully decoded by the eNodeB. Otherwise, one-bit NACK is transmitted to the UE. If layer shifting is not configured, each transport block has its own HARQ-ACK feedback signalling.

For FDD and TDD, precoding is performed according to a predefined codebook. If layer shifting is not configured, precoding is applied after the layer mapping. If layer shifting is configured, precoding is applied after the layer shifting operation. Application of a single precoding matrix per uplink component carrier is supported. In case of full-rank transmission, only identity precoding matrix is supported. For uplink spatial multiplexing with two transmit antennas, 3-bit precoding codebook as defined in Table 6.1-1 is used.

Table 6.1-1: 3-bit precoding codebook for uplink spatial multiplexing with two transmit antennas

Codebook indexNumber of layers

12

0

1

2

3

-

4

5

For uplink spatial multiplexing with four transmit antennas, 6-bit precoding codebook is used. The subset of the precoding codebook used for 1-layer transmission is defined in Table 6.1-2. The baseline for the subset of the precoding codebook used for 2-layer transmission is defined in Table 6.1-3. For 3-layer transmission, the number of precoding matrices is 20, and only BPSK or QPSK alphabets are used for non-zero elements in precoding matrices.Table 6.1-2: 6-bit precoding codebook for uplink spatial multiplexing with four transmit antennas: precoding matrices for 1-layer transmission.Codebook

Index

0 to 7

Index

8 to 15

Index

16 to 23

Table 6.1-3: 6-bit precoding codebook for uplink spatial multiplexing with four transmit antennas: precoding matrices for 2-layer transmission.

Codebook

Index

0 to 7

Index

8 to 15

6.1AUplink transmit diversityFor UEs with multiple transmit antennas, an uplink Single Antenna Port Mode is defined, where the UE behaviour is same as the one with single antenna from eNodeBs perspective. For a given UE, the uplink Single Antenna Port Mode can be independently configured for its PUCCH, PUSCH and SRS transmissions.

The uplink Single Antenna Port Mode is the default mode before eNodeB is aware of the UE transmit antenna configuration.

6.1A.1Transmit Diversity for Uplink Control ChannelFor uplink control channels with Rel-8 PUCCH format 1/1a/1b, the spatial orthogonal-resource transmit diversity (SORTD) scheme is supported for transmissions with two antenna ports. In this transmit diversity scheme, the same modulation symbol from the uplink channel is transmitted from two antenna ports, on two separate orthogonal resources. For the UE with four transmit antennas, the 2-tx transmit diversity scheme is applied.6.2Uplink multiple access

DFT-precoded OFDM is the transmission scheme used for PUSCH both in absence and presence of spatial multiplexing. In case of multiple component carriers, there is one DFT per component carrier. Both frequency-contiguous and frequency-non-contiguous resource allocation is supported on each component carrier.

Simultaneous transmission of uplink L1/L2 control signalling and data is supported through two mechanisms

-Control signalling is multiplexed with data on PUSCH according to the same principle as in LTE Rel-8-Control signalling is transmitted on PUCCH simultaneously with data on PUSCH6.3Uplink reference signalsLTE Advanced retains the basic uplink reference-signal structure of LTE Rel-8, with two types of uplink reference signals:

-Demodulation reference signal -Sounding reference signalIn case of uplink multi-antenna transmission, the precoding applied for the demodulation reference signal is the same as the one applied for the PUSCH. Cyclic shift separation is the primary multiplexing scheme of the demodulation reference signals.

The baseline for sounding reference signal in LTE-Advanced operation is non-precoded and antenna-specific. For multiplexing of the sounding reference signals, the LTE Rel-8 principles are reused. 6.4Uplink power controlScope of uplink power control in LTE-Advanced is similar to Rel8:-UL power control mainly compensates for slow-varying channel conditions while reducing the interference generated towards neighboring cells

-Fractional path-loss compensation or full path-loss compensation is used on PUSCH and full path-loss compensation on PUCCH

LTE-Advanced supports component carrier specific UL power control for both contiguous and non-contiguous carrier aggregation for closed-loop case, and for open loop at least for the cases that the number of downlink component carriers is more than or equal to that of uplink component carriers.7Downlink transmission scheme7.0Physical channel mappingLTE-Advanced supports the PDSCH to be mapped also to MBSFN (non-control) region of MBSFN subframes that are not used for MBMS-In case of PDSCH mapping to MBSFN subframes, both normal and extended cyclic prefix can be used for control and data region, same CP length is used for control and data-Relation between CP length of normal and MBSFN subframes in the control region is the same as in Rel-87.1Downlink spatial multiplexingLTE-Advanced extends LTE Rel-8 downlink spatial multiplexing with support for up to eight layers spatial multiplexingIn the downlink 8-by-X single user spatial multiplexing, up to two transport blocks can be transmitted to a scheduled UE in a subframe per downlink component carrier. Each transport block is assigned its own modulation and coding scheme. For HARQ ACK/NAK feedback on uplink, one bit is used for each transport block.A transport block is associated with a codeword. For up to four layers, the codeword-to-layer mapping is the same as for LTE Rel-8. For more than four layers as well as the case of mapping one codeword to three or four layers, which is for retransmission of one out of two codewords that were initially transmitted with more than four layers, the layer mapping shall be done according to Table 7.1-1. Complex-valued modulation symbols for code word shall be mapped onto the layers, where is the number of layers and is the number of modulation symbols per layer.

Table 7.1-1: Codeword-to-layer mapping for above four layers and the case of mapping one codeword to three or four layersNumber of layersNumber of code wordsCodeword-to-layer mapping

31

41

52

62

72

82

7.1.1Feedback in support of downlink spatial multiplexingThe baseline for feedback in support of downlink single-cell single-user spatial multiplexing is codebook-based precoding feedback. 7.2Downlink reference signalsLTE-Advanced extends the downlink reference-signal structure of LTE with

-Reference signals targeting PDSCH demodulation-Reference signals targeting CSI estimation (for CQI/PMI/RI/etc reporting when needed)The reference signal structure can be used to support multiple LTE-Advanced features, e.g. CoMP and spatial multiplexing.

The reference signals targeting PDSCH demodulation are:

-UE-specific, i.e, the PDSCH and the demodulation reference signals intended for a specific UE are subject to the same precoding operation. -Present only in resource blocks and layers scheduled by the eNodeB for transmission. -Mutually orthogonal between layers at the eNodeB.The design principle for the reference signals targeting PDSCH modulation is an extension to multiple layers of the concept of Rel-8 UE-specific reference signals used for beamforming. Complementary use of Rel-8 cell-specific reference signals by the UE is not precluded.

Reference signals targeting CSI estimation are

-cell specific-sparse in frequency and time-punctured into the data region of normal/MBSFN subframe.7.3Downlink transmit diversity

For the downlink transmit diversity with more than four transmit antennas applied to PDCCH, and PDSCH in non-MBSFN subframes, the Rel-8 transmit diversity scheme is used. 8Coordinated multiple point transmission and receptionCoordinated multi-point (CoMP) transmission/reception is considered for LTE-Advanced as a tool to improve the coverage of high data rates, the cell-edge throughput and/or to increase system throughput.8.1Downlink coordinated multi-point transmissionDownlink coordinated multi-point transmission (CoMP) is a relatively general term referring to different types of coordination in the downlink transmission from multiple geographically separated transmission points (TP). This includes coordination in the scheduling, including any beam-forming functionality, between geographically separated transmission points and joint transmission from geographically separated transmissions points.8.2Uplink coordinated multi-point reception

Uplink CoMP reception is a relatively general term referring to different types of coordination in the uplink reception at multiple, geographically separated points. This includes coordination in the scheduling, including any beam-forming functionality, between geographically separated reception points.9Relaying9.1General

LTE-Advanced extends LTE Rel-8 with support for relaying as a tool to improve e.g. the coverage of high data rates, group mobility, 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 via the Un interface, and UEs connect to the RN via the Uu interface as shown on Figure 9.1-1 below.

Figure 9.1-1: Relays

With respect to the relay nodes usage of spectrum, its operation can be classified into:

-inband, in which case the eNB-RN link shares the same carrier frequency with RN-UE links. Rel-8 UEs should be able to connect to the donor cell in this case.-outband, in which case the eNB-RN link does not operate in the same carrier frequency as RN-UE links. Rel-8 UEs should be able to connect to the donor cell in this case.For both inband and outband relaying, it shall be possible to operate the eNB-to-relay link on the same carrier frequency as eNB-to-UE links.At least "Type 1" and Type 1a RNs are supported by LTE-Advanced. A "Type 1" RN is an inband RN 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 shall have their own Physical Cell ID (as defined in LTE Rel-8) and transmit their own synchronization 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 shall appear as a Rel-8 eNodeB to Rel-8 UEs (i.e. be backwards compatible) -To LTE-Advanced UEs, it should be possible for a relay node to appear differently than Rel-8 eNodeB to allow for further performance enhancement.

A Type 1a relay node is characterised by the same set of features as the Type 1 relay node above, except Type 1a operates outband. 9.2Architecture

On Uu interface between UE and RN, all AS control plane (RRC) and user plane (PDCP, RLC and MAC) protocols are terminated in RN. On Un interface between RN and eNB, the user plane is based on standardised protocols (PDCP, RLC, MAC). The control plane on Un uses RRC (for the RN in its role as UE).9.3Relay-eNodeB link for inband relay9.3.1Resource partitioning for relay-eNodeB link

In order to allow inband relaying, some resources in the time-frequency space are set aside for the backhaul link (Un) and cannot be used for the access link (Uu). At least the following scheme is supported for this resource partitioning:

Resource partitioning at the RN:

-in the downlink, eNB RN and RN UE links are time division multiplexed in a single carrier frequency (only one is active at any time)-in the uplink, UE RN and RN eNB links are time division multiplexed in a single carrier frequency (only one is active at any time)Multiplexing of backhaul links in FDD:-eNB RN transmissions are done in the DL frequency band-RN eNB transmissions are done in the UL frequency bandMultiplexing of backhaul links in TDD:-eNB RN transmissions are done in the DL subframes of the eNB and RN -RN eNB transmissions are done in the UL subframes of the eNB and RN9.3.2Backward compatible backhaul partitioning Due to the relay transmitter causing interference to its own receiver, simultaneous eNodeB-to-relay and relay-to-UE transmissions on the same frequency resource may not be feasible unless sufficient isolation of the outgoing and incoming signals is provided. Similarly, at the relay it may not be possible to receive UE transmissions simultaneously with the relay transmitting to the eNodeB.

One way to handle the interference problem is to operate the relay such that the relay is not transmitting to terminals when it is supposed to receive data from the donor eNodeB, i.e. to create "gaps" in the relay-to-UE transmission. These "gaps" during which terminals (including Rel-8 terminals) are not supposed to expect any relay transmission can be created by configuring MBSFN subframes as exemplified in Figure 9.1. Relay-to-eNodeB transmissions can be facilitated by not allowing any terminal-to-relay transmissions in some subframes.

Figure 9.1: Example of relay-to-UE communication using normal subframes (left) and eNodeB-to-relay communication using MBSFN subframes (right).9.3.3Backhaul resource assignmentIn case of downlink backhaul in downlink resources, the following is valid

-At the RN, the access link downlink subframe boundary is aligned with the backhaul link downlink subframe boundary, except for possible adjustment to allow for RN transmit/receive switching -The set of downlink backhaul subframes, during which downlink backhaul transmission may occur, is semi-statically assigned. -The set of uplink backhaul subframes, during which uplink backhaul transmission may occur, can be semi-statically assigned, or implicitly derived from the downlink backhaul subframes using the HARQ timing relationship-A new physical control channel (the R-PDCCH) is used to dynamically or semi-persistently assign resources, within the semi-statically assigned sub-frames, for the downlink backhaul data (corresponding to the R-PDSCH physical channel). The R-PDCCH may assign downlink resources in the same and/or in one or more later subframes.-The R-PDCCH is also used to dynamically or semi-persistently assign resources for the uplink backhaul data (the R-PUSCH physical channel). The R-PDCCH may assign uplink resources in one or more later subframes. -Within the PRBs semi-statically assigned for R-PDCCH transmission, a subset of the resources is used for each R-PDCCH. The actual overall set of resources used for R-PDCCH transmission within the above mentioned semi-statically assigned PRBs may vary dynamically between subframes. These resources may correspond to the full set of OFDM symbols available for the backhaul link or be constrained to a subset of these OFDM symbols. The resources that are not used for R-PDCCH within the above mentioned semi-statically assigned PRBs may be used to carry R-PDSCH or PDSCH.-The detailed R-PDCCH transmitter processing (channel coding, interleaving, multiplexing, etc.) should reuse Rel-8 functionality to the extent possible, but allow removing some unnecessary procedure or bandwidth-wasting procedure by considering the relay property.-If the search space approach of Rel-8 is used for the backhaul link, use of common search space, which can be semi-statically configured (and potentially includes entire system bandwidth), is the baseline. If RN-specific search space is configured, it could be implicitly or explicitly known by RN.-The R-PDCCH is transmitted starting from an OFDM symbol within the subframe that is late enough so that the relay can receive it.-R-PDSCH and R-PDCCH can be transmitted within the same PRBs or within separated PRBs.9.4Relay-eNodeB link for outband relayIf relay-eNB and relay-UE links are isolated enough in frequency (possibly with help of additional means such as antenna separation), then there is no interference issue in activating both links simultaneously. Therefore, it becomes possible for relay-eNodeB link to reuse the channels designed for UE-eNodeB link.

10Improvement for latency10.1Improvement for C-Plane latency

In LTE-Advanced, the transition time requirement from Idle mode (with IP address allocated) to Connected mode is less than 50 ms including the establishment of the user plane (excluding the S1 transfer delay). The transition requirement from a "dormant state" in Connected mode is less than 10 ms.

Figure 10.1-1: C-Plane Latency

Although already LTE Rel-8 fulfills the latency requirements of ITU (see Annex B), several mechanisms could be used to further reduce the latency and achieve also the more aggressive LTE-Advanced targets set by 3GPP [3]:

-Combined RRC Connection Request and NAS Service Request: combining allows those two messages to be processed in parallel at the eNB and MME respectively, reducing overall latency from Idle mode to Connected mode by approx. 20ms.

-Reduced processing delays: processing delays in the different nodes form the major part of the delay (around 75% for the transition from Idle to Connected mode assuming a combined request) so any improvement has a large impact on the overall latency.

-Reduced RACH scheduling period: decreasing the RACH scheduling period from 10 ms to 5 ms results in decreasing by 2.5ms the average waiting time for the UE to initiate the procedure to transit from Idle mode to Connected mode.

Regarding the transition from a "dormant state" in Connected mode, the following mechanism could be used in LTE-Advanced to achieve the requirement:

-Shorter PUCCH cycle: a shorter cycle of PUCCH would reduce the average waiting time for a synchronised UE to request resources in Connected mode.-Contention based uplink: contention based uplink allows UEs to transmit uplink data without having to first transmit Scheduling Request on PUCCH, thus reducing the access time for synchronized UEs in Connected mode.10.2Improvement for U-Plane latencyLTE Rel-8 already benefits from a U-Plane latency below 10ms for synchronised UEs (see Annex B). In situations where the UE does not have a valid scheduling assignment, or when the UE needs to synchronize and obtain a scheduling assignment, a reduced RACH scheduling period, shorter PUCCH cycle, contention based uplink and reduced processing delays as described in subclause 10.1 above could also be used to improve the latency compared to LTE Rel-8.

11Radio transmission and reception11.1RF scenarios11.1.1Deployment scenarios

This section reviews deployment scenarios that were considered for initial investigation in a near term time frame. Scenarios are shown in Table 11.1.1-1.

Table 11.1.1-1: Deployment scenariosScenarioProposed initial deployment scenario for investigation

aSingle band contiguous allocation for FDD (UL:40 MHz, DL: 80 MHz)

bSingle band contiguous allocation for TDD (100 MHz)

cMulti band non-contiguous allocation for FDD (UL:40MHz, DL:40 MHz)

dMulti band non contiguous allocation for TDD (90 MHz)

11.2Common requirements for UE and BS11.2.1Carrier Aggregation

11.2.1.1Bandwidth configuration of component carriers

Radio requirements shall be specified for aggregation of component carriers for both contiguous and non-contiguous aggregation. The allowed channel bandwidths for each component carrier are 1.4 MHz, 3.0 MHz, 5MHz, 10 MHz, 15 MHz and 20 MHz.

11.2.1.2Carrier spacing between component carriers

The carrier spacing between component carriers is a multiple of 300 kHz for contiguous aggregation and non-contiguous aggregation in the same operating band. It shall be possible to configure all component carriers LTE Release 8 compatible, at least when the aggregated numbers of component carriers in the UL and the DL are same. Not all component carriers may necessarily be LTE release 8 compatible.11.2.2Operating bands

Operating bands of LTE-Advanced will involve E-UTRA operating bands as well as possible IMT bands identified by ITU-R. E-UTRA is designed to operate in the operating bands as defined in [5, 6]. E-UTRA operating bands are shown in Table11.2.2-1.Table 11.2.2-1 Operating bands for LTE-Advanced (E-UTRA operating bands):Operating BandUplink (UL) operating bandBS receive/UE transmitDownlink (DL) operating bandBS transmit /UE receiveDuplex Mode

FUL_low FUL_highFDL_low FDL_high

11920 MHz 1980 MHz 2110 MHz 2170 MHzFDD

21850 MHz 1910 MHz1930 MHz 1990 MHzFDD

31710 MHz 1785 MHz1805 MHz 1880 MHzFDD

41710 MHz1755 MHz 2110 MHz 2155 MHzFDD

5824 MHz849 MHz869 MHz 894MHzFDD

6830 MHz-840 MHz-865 MHz875 MHz-FDD

72500 MHz2570 MHz2620 MHz 2690 MHzFDD


91749.9 MHz1784.9 MHz1844.9 MHz 1879.9 MHzFDD


111427.9 MHz 1447.9 MHz1475.9 MHz 1495.9 MHzFDD

12698 MHz716 MHz728 MHz746 MHzFDD



15ReservedReserved-

16ReservedReserved-

17704 MHz 716 MHz734 MHz746 MHzFDD




211447.9 MHz1462.9 MHz1495.9 MHz1510.9 MHzFDD


...

331900 MHz1920 MHz1900 MHz1920 MHzTDD

342010 MHz2025 MHz 2010 MHz 2025 MHzTDD

351850 MHz 1910 MHz1850 MHz 1910 MHzTDD






[41][3400] MHz[3600] MHz[3400] MHz[3600] MHzTDD

Note: Frequency arrangement for certain operating bands in Table 11.2.2-1 may be modified, eg. split into sub-bands, according as the future studies.

Introduction of the following other ITU-R IMT bands are not precluded in the future.

(a) Possible frequency bands in 3.4-3.8GHz band

(b) Possible frequency bands in 3.4-3.6GHz as well as 3.6-4.2GHz

(c) Possible frequency bands in 3.4-3.6GHz band

(d) Possible frequency bands in 450470 MHz band,(e) Possible frequency bands in 698862 MHz band(f) Possible frequency bands in 790862 MHz ban(g) Possible frequency bands in 2.32.4 GHz band(h) Possible frequency bands in 4.4-4.99 GHz band11.3UE RF requirements

11.3.1GeneralLTE-Advanced extends LTE release 8 with support for Carrier Aggregation, where two or more component carriers (CC) are aggregated in order to support wider transmission bandwidths up to 100MHz and for spectrum aggregation. A terminal may simultaneously receive one or multiple component carriers depending on its capabilitiesIt will be possible to aggregate a different number of component carriers of possibly different bandwidths in the UL and the DL. In typical TDD deployments, the number of component carriers and the bandwidth of each component carrier in UL and DL will be the same. Both Intra and Inter band carrier aggregation are considered as potential Tx RF scenarios and parameters and cover both of; Contiguous Component Carrier and non-contiguous Component Carrier aggregation RAN4, RF requirements are specified in terms of a Minimum Requirements11.3.2Transmitter characteristicsRAN4 Tx characteristic would need to support 3 generic aggregation scenarios depending on UE capability;

-Intra band contiguous component carrier (CC) aggregation

-Intra band non - contiguous component carrier (CC) aggregation

-Inter band non-contiguous component carrier (CC) aggregation

11.3.2.1Transmitter architecture

Figure 11.3.2.1-1 illustrates various TX architectures options according to where the component carriers are combined, i.e., at digital baseband, or in analog waveforms before RF mixer, or after mixer but before the PA, or after the PA.

Option A

-In an adjacent contiguous common carrier aggregation scenario, the UE very likely has one PA. Connected to the PA can be a single RF chain (a zero-IF mixer, a wideband DAC, and a wideband IFFT)

Option-B

-Combines analog baseband waveforms from component Carrier first (e.g., via a mixer operating at an IF of roughly the bandwidth of the other component carrier in the example of 2-component carrier aggregation). Then the resulting wideband signal is up-converted to RF.

Option-C

-Does ZIF up-conversion of each component carrier before combining and feeding into a single PA.

Option-D

-Employs multiple RF chains and multiple PAs after which the high-power signals are combined and fed into a single antenna. PA coupling at the UE can be challenging for option-D.

Figure 11.3.2.1-1: Possible UE Architectures in three aggregation scenarios11.3.2.2Transmit power

In order to support backward related to UE maximum output power it is expect that LTE-Advanced UE power class should be a subset of the current EUTRA and UTRA Release 8 power classes. In the case of dual Tx antenna (separate or dual PA) or CPE / Relay products the conducted transmit power may need to be augmented to support these new features.

11.3.2.3Output power dynamics

In REL-8 power control is defined on sub-frame basis for a single component carrier. For LTE-Advanced, the architecture of single or multiple PA can have an impact on the power control dynamics. In the case where the PA supports a component carrier, the CM is not a concern since each component carrier will have a fixed maximum transmit power. But a single PA architecture can potentially impact the power control procedure when its power is shared amongst component carriers

For LTE-Advanced power control would need to consider the following scenarios in the case of; OFF power, minimum power and power tolerance; In this case the transmitter characteristic for output power dynamics could be defined;




-Single or multiple segment power control

11.3.2.4Transmit signal quality

In REL-8 EVM performance is defined on sub-frame basis for a single component carrier.

For LTE-Advanced EVM would need to consider the following scenarios;




11.3.2.5Output RF spectrum emissions

Spurious emissions are emissions which are caused by unwanted transmitter effects such as harmonics emission, parasitic emissions, intermodulation products and frequency conversion products, but exclude out of band emissions.

In REL8 the spectrum emission mask scales in proportion to the channel bandwidth due to PA non-linearity for a single component carrier.

11.3.2.5.1Adjacent Channel Leakage ratio

In REL-8 the ALCR is defined for each channel bandwidth. For LTE-Advanced, depending on the adjacent channel bandwidth (single or multiple CC) it may be necessary to investigate the impact of ALCR with different number of CC. In this case the transmitter characteristic for ACLR could be defined for;



-Inter band non- contiguous component carrier (CC) aggregation

11.3.2.5.2Spurious emission (UE to UE co-existence)

One aspect relating to the emission spectrum would be UE to UE co-existence.

In this case the following aspects could be defined;

-UE1 (Tx) and U2 (Rx) configuration for UE to UE co-existence analysis

-Generic limit of (-50dBm /1MHz) be applicable for the case of contiguous CC carrier

-In the case of inter band scenario exceptions may need to be defined for harmonic requirements

-Guard band for TDD non synchronized operation

11.3.2.6Transmit intermodulationThe transmit intermodulation performance is a measure of the capability of the transmitter to inhibit the generation of signals in its non linear elements caused by presence of the wanted signal and an interfering signal reaching the transmitter via the antenna.

The current RAN1 assumption assumes in the case of contiguous CC carriers then RB can be freely allocated for the different CC carriers. In this case intermodulation performance this may need to be defined in terms; per RB allocation / per CC carrier / all CC.11.3.3Receiver characteristicsIn order to define the consider the applicable Rx characteristic a number of working assumptions will be needed to ensure the feature is applicable in terms of UE implementation. Current REL8 working assumption has assumed some constraints due to complexity and battery saving One new form factor that could be consider is Customer Premise Equipment (CPE) which would have the ability to initial these new features such as 2 Tx antenna port and 4 Rx antenna port as a baseline work assumption in order to address the Tx characteristics.

Rx characteristic would need to support 3 generic aggregation scenarios depending on UE capability;



-Inter band non-contiguous component carrier (CC) aggregation11.3.3.1Receiver architecture Table 11.3.3-1 illustrates various Rx architectures options for the three scenariosTable 11.3.3.1-1: Possible UE Architecture for the three aggregation scenariosRx Characteristics

Option Description (Rx architecture)Intra Band aggregation Inter Band aggregation

Contiguous (CC) Non contiguous (CC) Non contiguous (CC)

ASingle (RF + FFT + baseband) with BW>20MHzYes

BMultiple (RF + FFT + baseband) with BW20MHzYesYesYes

Option A

-UE may adopt a single wideband-capable (i.e., >20MHz) RF front end (i.e., mixer, AGC, ADC) and a single FFT, or alternatively multiple "legacy" RF front ends ( S1-C)44

12S1-C Transfer delayT_S1T_S1

13MME Processing Delay (including UE context retrieval of 10ms)1515

14S1-C Transfer delayT_S1T_S1

15Processing delay in eNB (S1-C > Uu)44

16Transmission of RRC Security Mode Command and Connection Reconfiguration (+TTI alignment)1.51.5

17Processing delay in UE (L2 and RRC)2020

Total delay [ms]7680

Note 1:The figures included in Steps 12 and 14 are not included in the latency requirement and are outside the scope of RAN WG2, therefore they are not included in the total delay.B.1.1.2TDD frame structure

Table B.1.1.2-1 provides a timing analysis, assuming TDD frame structure (UL/DL configuration #1), of the flow depicted in Figure B.1.1-1 The analysis illustrates that the state transition from IDLE to CONNECTED can be achieved within a minimum of 82.6ms, with 3ms msg2 window and maximum PRACH density in time domain (e.g. PRACH configuration Index = 12). Considering more reasonable settings (5ms msg2 window and 5ms PRACH cycle), a 84.6ms transition time is achieved.Table B.1.1.2-1: C-plane latency analysis for Rel-8 (based on the procedure depicted in B.1.1-1)

ComponentDescriptionRel-8Rel-8Rel-8

Minimum(ms)

PRACH in subframe#2/ #3/ #7/ #8Average [ms]

PRACH in subframe#1/ #6

Msg1 in subframe#2 or #7

(probability=0.8)Msg1 in subframe#3 or #8

(probability =0.2)Msg1 in subframe#1 or #6

1Average delay due to RACH scheduling period20.52.5

2RACH Preamble111

3-4Preamble detection and transmission of RA response (Time between the end RACH transmission and UEs reception of scheduling grant and timing adjustment) + delay for nearest DL subframe335

5UE Processing Delay (decoding of scheduling grant, timing alignment and C-RNTI assignment + L1 encoding of RRC Connection Request) + delay for nearest UL subframe655

6Transmission of RRC Connection Request111

7Processing delay in eNB (L2 and RRC) + delay for nearest DL subframe666

8Transmission of RRC Connection Set-up (and UL grant)111

9Processing delay in the UE (L2 and RRC) + delay for nearest UL subframe171717

10Transmission of RRC Connection Set-up complete (including NAS Service Request)111

11Processing delay in eNB (Uu > S1-C)444

12S1-C Transfer delayT_S1T_S1T_S1

13MME Processing Delay (including UE context retrieval of 10ms)151515

14S1-C Transfer delayT_S1T_S1T_S1

15Processing delay in eNB (S1-C > Uu)444

16Transmission of RRC Security Mode Command and Connection Reconfiguration (+TTI alignment)2.12.12.1

17Processing delay in UE (L2 and RRC)202020

Total delay [ms]83.180.684.6

Averaged Total delay [ms] (considering the probability of Msg1 transmission location)83.1*0.8+ 80.6*0.2=82.6N/A

Note 2:The figures included in Steps 12 and 14 are not included in the latency requirement and are outside the scope of RAN WG2, therefore they are not included in the total delay.B.1.2 Transition Dormant to Active

In the dormant state, the UE has an established RRC connection and radio bearers; it is thus known at cell level but may be in DRX to save power during temporary inactivity. The UE may be either synchronized or unsynchronized. For the purpose of the analysis presented in this section, error free transmission of data and signalling is assumed, and the DRX cycle is not considered.B.1.2.1FDD frame structure

B.1.2.1.1Uplink initiated transition, synchronized

Table B.1.2.1.1-1 provides a timing analysis, assuming FDD frame structure and a PUCCH allocation for scheduling request of 5ms, of the uplink state transition for a UE with uplink synchronization. The analysis illustrates that the uplink transition from dormant to active for a synchronized UE can be achieved within 11.5ms.Table B.1.2.1.1-1: Uplink initiated dormant to active transition for synchronized UE (error free)

ComponentDescriptionTime [ms]

1Average delay to next SR opportunity (5ms PUCCH cycle)2.5

2UE sends Scheduling Request1

3eNB decodes Scheduling Request and generates the Scheduling Grant3

4Transmission of Scheduling Grant1

5UE Processing Delay (decoding of scheduling grant + L1 encoding of UL data)3

6Transmission of UL data1

Total delay11.5

B.1.2.1.2Uplink initiated transition, unsynchronized

Table B.1.2.1.2-1 provides a timing analysis of the uplink state transition for a UE without uplink synchronization. The analysis illustrates that the uplink transition from dormant to active for an unsynchronized UE can be achieved within a minimum of 10.5ms, with 1ms PRACH cycle and a 3ms msg2 window.Table B.1.2.1.2-1: Uplink initiated dormant to active transition for unsynchronized UE (error free)

ComponentDescriptionMinimum [ms]Average [ms]


2RACH Preamble11

3Preamble detection and transmission of RA response (Time between the end of RACH transmission and UEs reception of scheduling grant and timing adj.)35

4UE Processing Delay (decoding of scheduling grant and timing alignment + L1 encoding of UL data)55


Total delay10.514.5

B.1.2.1.3Downlink initiated transition, synchronizedA UE with uplink synchronization monitors PDCCH during the on-duration time of the DRX cycle, and there is thus no additional delay component apart from the DRX cycle when compared to the case of the uplink initiated for a synchronized UE.B.1.2.1.4Downlink initiated transition, unsynchronizedTable B.1.2.1.4-1 provides a timing analysis, assuming FDD frame structure, of the downlink state transition for a UE without uplink synchronization. For the downlink initiated transition, a dedicated preamble is assumed and no contention resolution is needed. The analysis illustrates that the downlink transition from dormant to active for an unsynchronized UE can be achieved within a minimum of 13.5ms, with 1ms PRACH cycle and a 3ms msg2 window.Table B.1.2.1.4-1: Downlink initiated dormant to active transition (error free)

ComponentDescriptionMinimum [ms]Average [ms]

1UE receives dedicated preamble on PDCCH and prepares UL Tx and cannot select a PRACH occasion before n+666


3RACH Preamble11

4Preamble detection and transmission of RA response (Time between the end RACH transmission and UEs reception of the timing adjustment)35

5Node B needs to wait 2 subframes before DL Tx to allow UE to adapt UL response according to the time alignment22

6Transmission of DL data11

Total delay [ms]13.517.5

B.1.2.2TDD frame structure

B.1.2.2.1Uplink initiated transition, synchronized

Table B.1.2.2.1-1 provides a timing analysis, assuming TDD frame structure (UL/DL configuration#1) and a PUCCH allocation for scheduling request of 5ms, of the uplink state transition for a UE with uplink synchronization. The analysis illustrates that the uplink transition from dormant to active for a synchronized UE can be achieved within 13.5ms.Table B.1.2.2.1-1: Uplink initiated dormant to active transition for synchronized UE (error free)

ComponentDescriptionTime [ms]Time [ms]

SR in subframe#2 or #7SR in subframe#3 or #8

1Average delay to next SR opportunity (5ms PUCCH cycle)2.52.5

2UE sends Scheduling Request11

3eNB decodes Scheduling Request and generates the Scheduling Grant + delay for nearest DL subframe35

4Transmission of Scheduling Grant11

5UE Processing Delay (decoding of scheduling grant + L1 encoding of UL data)53

6Transmission of UL data + delay for nearest UL subframe11

Total delay13.513.5

B.1.2.2.2Uplink initiated transition, unsynchronized

Table B.1.2.2.2-1 provides a timing analysis, assuming TDD frame structure (UL/DL configuration#1) and RACH cycle of 10ms, of the uplink state transition for a UE without uplink synchronization. The analysis illustrates that the uplink transition from dormant to active for an unsynchronized UE can be achieved within a minimum of 12.5ms, with 3ms msg2 window and maximum PRACH density in time domain (e.g. PRACH configuration Index=12).Table B1.2.2.2-1: Uplink initiated dormant to active transition for unsynchronized UE (error free)

ComponentDescriptionMinimum(ms)

PRACH in subframe#2/ #3/ #7/ #8Average [ms]


Msg1 in subframe#2 or #7




2RACH Preamble111

3Preamble detection and transmission of RA response (Time between the end of RACH transmission and UEs reception of scheduling grant and timing adj.) + delay for nearest DL subframe335

4UE Processing Delay (decoding of scheduling grant and timing alignment + L1 encoding of UL data) + delay for nearest UL subframe655


Total delay1310.514.5

Averaged Total delay [ms] (considering the probability of Msg1 transmission location)12.5N/A

B.1.2.2.3Downlink initiated transition, synchronized

A UE with uplink synchronization monitors PDCCH during the on-duration time of the DRX cycle, and there is thus no additional delay component apart from the DRX cycle when compared to the case of the uplink initiated for a synchronized UE.B.1.2.2.4Downlink initiated transition, unsynchronized

Tables B.1.2.2.4-1a and B.1.2.2.4-1b provide a timing analysis, assuming TDD frame structure (UL/DL configuration#1), of the downlink state transition for a UE without uplink synchronization. For the downlink initiated transition, a dedicated preamble is assumed and no contention resolution is needed. The analysis illustrates that the downlink transition from dormant to active for an unsynchronized UE can be achieved within a minimum of 16.5ms, with 3ms msg2 window and maximum PRACH density in time domain (e.g. PRACH configuration Index=12).Table B.1.2.2.4-1a: Downlink initiated dormant to active transition (error free)

ComponentDescriptionMinimum(ms)

PRACH in subframe#2/ #3/ #7/ #8

PDCCH in subframe#0 or #5

(probability=0.2)PDCCH in subframe#1 or #6


(probability=0.6)

1Average delay due to PDCCH transmission0.50.51.5

2UE receives dedicated preamble on PDCCH and prepares UL Tx+ delay for nearest PRACH768

3RACH Preamble111

4Preamble detection and transmission of RA response (Time between the end RACH transmission and UEs reception of the timing adjustment) + delay for nearest DL subframe333

5Node B needs to wait 2 subframes before DL Tx to allow UE to adapt UL response according to the time alignment+ delay for nearest DL subframe333



Averaged Total delay [ms] (considering the probability of PDCCH transmission location)16.5

Table B.1.2.2.4-1b: Downlink initiated dormant to active transition (error free)

ComponentDescriptionAverage [ms]


PDCCH in subframe#0 or #5



(probability=0.6)

1Average delay due to PDCCH transmission0.50.51.5

2UE receives dedicated preamble on PDCCH and prepares UL Tx+ delay for nearest PRACH6107

3RACH Preamble111

4Preamble detection and transmission of RA response (Time between the end RACH transmission and UEs reception of the timing adjustment) + delay for nearest DL subframe555

5Node B needs to wait 2 subframes before DL Tx to allow UE to adapt UL response according to the time alignment+ delay for nearest DL subframe222



Averaged Total delay [ms] (considering the probability of PDCCH transmission location)17.5

B.2U-plane latencyB.2.1FDD frame structure

The LTE U-plane one way latency for a scheduled UE consists of the fixed node processing delays (which includes radio frame alignment) and 1ms TTI duration for FDD as shown in Figure B.2.1-1. Considering that the number of HARQ processes is fixed to 8 for FDD, the one-way latency can calculated as:

DUP [ms] = 1.5 + 1 + 1.5+ n*8 = 4 + n*8,

where n is the number of HARQ retransmissions. Considering a typical case where there would be 0 or 1 retransmission, the approximate average U-plane latency is given by

DUP,typical [ms] = 4 + p*8,where p is the error probability of the first HARQ retransmission. The minimum latency is achieved for a 0% BLER, but a more reasonable setting is 10% HARQ BLER.

DUP,0%HARQ_BLER [ms] = 4 (0% HARQ BLER)

DUP,10%HARQ_BLER [ms] = 4.8 (10% HARQ BLER)

Figure B.2.1-1: User plane latency components for FDDB.2.2TDD frame structure

The LTE U-plane one way latency for a scheduled UE consists of the fixed node processing delays, radio frame alignment and TTI duration for TDD as shown in Figure B.2.2-1.

(a) Downlink

(b) Uplink

Figure B.2.2-1: User plane latency components for TDD

Where:

a)The total one-way processing time is 2.5ms.

b)

is radio frame alignment and depends on the frame structure.

c)The TTI duration is 1ms.

Based on the assumptions above, the LTE U-plane latency is given by:

DUP [ms] = 1 + + 1 + 1.5 + n*

where is the average HARQ RTT and n is the number of HARQ retransmissions. In typical cases there would be 0 or 1 re-transmissions yielding an approximate average U-plane latency of

DUP,typical [ms] = 3.5 + + p*

where p is the error probability of the first HARQ transmission. Tables B.2.2-2a and B.2.2-2b show the U-plane latency in downlink and uplink, respectively, for different TDD UL/DL configuration when 0% HARQ BLER is assumed.

Table B.2.2-2a: U-plane latency analysis with 0% HARQ BLER (average in downlink)StepDescriptionUL/DL configuration

0123456

1eNB Processing Delay1ms1ms1ms1ms1ms1ms1ms

2Frame Alignment1.7ms1.1ms0.7ms1.1ms0.8ms0.6ms1.4ms

3TTI duration1ms1ms1ms1ms1ms1ms1ms

4UE Processing Delay1.5ms1.5ms1.5ms1.5ms1.5ms1.5ms1.5ms

Total one way delay5.2ms4.6ms4.2ms4.6ms4.3ms4.1ms4.9ms

Table B.2.2-2b: U-plane latency analysis with 0% HARQ BLER (average in uplink)StepDescription UL/DL configuration

0123456

1UE Processing Delay1ms1ms1ms1ms1ms1ms1ms

2Frame Alignment1.1ms1.7ms2.5ms3.3ms4.1ms5ms1.4ms


4eNB Processing Delay1.5ms1.5ms1.5ms1.5ms1.5ms1.5ms1.5ms

Total one way delay4.6ms5.2ms6ms6.8ms7.6ms8.5ms4.9ms

Tables B.2.2-3a and B.2.2-3b show the U-plane latency in downlink and uplink, respectively, for different TDD UL/DL configuration when 10% HARQ BLER is assumed.Table B.2.2-3a: U-plane latency analysis with 10% HARQ BLER (average in downlink)StepDescriptionUL/DL configuration

0123456

1eNB Processing Delay1ms1ms1ms1ms1ms1ms1ms

2Frame Alignment1.7ms1.1ms0.7ms1.1ms0.8ms0.6ms1.4ms


4UE Processing Delay1.5ms1.5ms1.5ms1.5ms1.5ms1.5ms1.5ms

5HARQ Retransmission0.1*10ms0.1*10.2ms0.1*9.8ms0.1*10.5ms0.1*11.6ms0.1*12.4ms0.1*11.2ms

Total one way delay6.2ms5.62ms5.18ms5.65ms5.46ms5.34ms6.02ms

Table B.2.2-3b: U-plane latency analysis with 10% HARQ BLER (average in uplink)StepDescriptionUL/DL configuration

0123456

1UE Processing Delay1ms1ms1ms1ms1ms1ms1ms

2Frame Alignment1.1ms1.7ms2.5ms3.3ms4.1ms5ms1.4ms


4eNB Processing Delay1.5ms1.5ms1.5ms1.5ms1.5ms1.5ms1.5ms

5HARQ Retransmission0.1*11.6ms0.1*10ms0.1*10ms0.1*10ms0.1*10ms0.1*10ms0.1*11.5ms

Total one way delay5.76ms6.2ms7ms7.8ms8.6ms9.5ms6.05ms

Note:The analysis shows that the 5ms U-plane latency requirement can be simultaneously satisfied in TDD for both uplink and downlink using the UL/DL configuration #6 when 0% HARQ BLER is assumed.Annex C:ITU-R Submission Templates

The submission of the 3GPP "LTE Release 10 & beyond (LTE-Advanced)" to the ITU-R as a candidate technology for the IMT-Advanced must include completed templates according to Report ITU-R M.2133 [7].C.1Description template characteristics (4.2.3.2)

The 3GPP description template characteristics (4.2.3.2) for both the FDD and the TDD component is found in RP-090745 [14].

C.2Description template link budget (4.2.3.3)

The 3GPP description template link budget (4.2.3.3) for both the FDD and the TDD component is found in RP-090746 [15].

C.3Compliance templates for services (4.2.4.1), for spectrum (4.2.4.2), technical performance (4.2.4.3)

The 3GPP compliance templates for services (4.2.4.1), for spectrum (4.2.4.2), technical performance (4.2.4.3) for both the FDD and the TDD component is found in RP-090747 [16].

Annex D:Change historyChange history

DateTSG#TSG Doc.CRRevSubject/CommentOldNew

2009/03R1#56bisR1-091661Skeleton TR is endorsed0.0.00.1.0

2009/08R1#58R1-093685Capture the agreement in RAN1#57bis, RAN2#66 and #66bis0.1.20.2.0

2009/08R1#58R1-093716Capture the agreement in RAN1#58, RAN2#67 and RAN4#520.2.00.2.1

2009/08R1#58R1-093736Version 0.2.1 was endorsed to v2.0.00.2.12.0.0

2009/08Correction by RAN1. Some editorial corrections by ITU ad hoc2.0.02.1.1

Editorial corrections by editor2.1.12.1.2

2009/09RAN_45RP-090737Submit to RAN for approval2.2.0

2009/09RAN_45RP-090743Version 2.2.0 was approved to v9.0.02.2.09.0.0

01/12/09RAN_46RP-0911730001-Editorial correction on TR36.9129.0.09.1.0

01/12/09RAN_46RP-0911730002-Updates on TR36.9129.0.09.1.0

01/12/09RAN_46RP-0911730003-RAN2 agreements on Carrier aggregations, PDCP and Contention based uplink9.0.09.1.0

16/03/10RAN_47RP-1002120004-Conclusion of TR36.9129.1.09.2.0

16/03/10RAN_47RP-1002120005-Type 1 Relay definition9.1.09.2.0

16/03/10RAN_47RP-1002120006-Performance evaluation of LTE-A technologies against 3GPP targets9.1.09.2.0

16/03/10RAN_47RP-10021200071U-Plane interruption for TDD RIT9.1.09.2.0

03/06/10RAN_48RP-1005740009-Clarification of operating band for LTE-A9.2.09.3.0

21/03/11SP_51---Upgrade to Rel-10 following decision made at SP_519.3.010.0.0

2012-09SP_57---Update to Rel-11 version (MCC)10.0.011.0.0

2014-09SP_65---Update to Rel-12 version (MCC)11.0.012.0.0

_1316334702.unknown

_1316334829.unknown

_1316336312.unknown

_1316336351.unknown

_1316336357.unknown

_1316336371.unknown

_1316336384.unknown

_1316336361.unknown

_1316336365.unknown

_1316336359.unknown

_1316336353.unknown

_1316336355.unknown

_1316336343.unknown

_1316336345.unknown

_1316336347.unknown

_1316336336.unknown

_1316336333.unknown

_1316334895.unknown

_1316334928.unknown

_1316335018.unknown

_1316336293.unknown

_1316334916.unknown

_1316334874.unknown

_1316334878.unknown

_1316334857.unknown

_1316334765.unknown

_1316334798.unknown

_1316334820.unknown

_1316334781.unknown

_1316334732.unknown

_1316334753.unknown

_1316334722.unknown

_1303656723.unknown

_1316334579.unknown

_1316334630.unknown

_1316334669.unknown

_1316334693.unknown

_1316334640.unknown

_1316334602.unknown

_1316334613.unknown

_1316334590.unknown

_1303656825.unknown

_1307339856.vsdText

Segm.ARQ etc

Multiplexing UE1

Segm.ARQ etc

...

...

HARQ

Multiplexing UEn

HARQ

HARQ

Scheduling / Priority Handling

Logical Channels

Transport Channels

MAC

RLC

Segm.ARQ etc

Segm.ARQ etc

PDCP

ROHC

ROHC

ROHC

ROHC

Radio Bearers

Security

Security

Security

Security

...

...

CC1

CCx

HARQ

...

CC1

CCy

...

_1308450934.vsd

_1312028672.vsd

_1312890606.vsdUE

eNB

MME

3. Processing

1. RACH Waiting

4. Grant

5. Processing

6. RRC + NAS Request

7. RRC Processing11. NAS Processing

12. NAS Request

13. Processing

14. NAS Setup

15. Processing

8. RRC Setup

9. Processing

10. Connection Complete

16. NAS Setup

18. Setup Complete

17. Processing

2. Preamble

_1312017376.vsd

_1307340078.vsdText

Multiplexing

...

HARQ

Scheduling / Priority Handling

Transport Channels

MAC

RLC

PDCP

Segm.ARQ etc

Segm.ARQ etc

Logical Channels

ROHC

ROHC

Radio Bearers

Security

Security

HARQ

...

CC1

CCx

...

_1303656927.unknown

_1303656993.unknown

_1303656885.unknown

_1303656773.unknown

_1303656787.unknown

_1303656755.unknown

_1303656045.unknown

_1303656609.unknown

_1303656611.unknown

_1303656699.unknown

_1303656610.unknown

_1303656261.unknown

_1303656329.unknown

_1303656092.unknown

_1282131821.vsdUE

eNode B

MME

1. Delay for RACH Scheduling Period

3. Processing delay in eNode B

2. Rach Preamble

4. TA + Scheduling Grant

5. Processing delay in UE

6. RRC Connection Request

12. Connection Request



14. Connection Request

13. Processing delay in MME

14. Connection Set-up


16. Security Mode Command + RRC Connection Reconfiguration


18. Security Mode Complete + RRC Connection Reconfiguration Complete

8. RRC Connection Setup


10. RRC Connection Setup Complete + NAS Service Request


_1302111628.doc

UE

eNB

1 ms

1ms+ EMBED Equation.3

TTI

1.5ms

_1301147831.unknown

_1303651155.unknown

_1303651178.unknown

_1302111645.doc

UE

eNB

1 ms

1.5ms

1ms+ EMBED Equation.3

TTI

_1301148056.unknown

_1300541355.doc

UE

eNB

1 ms

1 ms

HARQ RTT

8 ms

1.5 ms

1.5 ms

1.5 ms

TTI

1.5 ms

_1301322990.unknown

_1301323020.unknown

_1301323069.unknown

_1301147683.unknown

_1294748004.doc

_1239608372.unknown

_1249738306.unknown

_1249738358.unknown

_1246175189.unknown

_1239097950.unknown

_1239097977.unknown

_1239098000.unknown

_1231828362.unknown

_1232264300.unknown

_1239097925.unknown

_1232264273.unknown

_1231777243.unknown

Documents

36912-c00