`
`ZTE/SAMSU NG 1033-0001
`APPLE 1033
`
`ZTE/SAMSUNG 1033-0001
`
`1
`
`APPLE 1033
`
`

`

`3G EVOLUTION : HSPA AND LTE FOR MOBILE BROADBAND
`
`ZTE/SAMSUNG 1033-0002
`
`2
`
`

`

`3G Evolution
`
`HSPA and LTE for Mobile Broadband
`
`Second edition
`
`Erik Dahlman, Stefan Parkvall, Johan Skold and Per Beming
`
`Academic Press is an imprint of Elsevier
`
`AMSTERDAM 0 BOSTON ' HEIDELBERG ' LONDON ' NEW YORK - OXFORD
`PARIS - SAN DIEGO - SAN FRANCISCO ' SJNGAPORE ' SYDNEY ’ TOKYO
`
`ZTE/SAMSUNG 1033-0003
`
`3
`
`

`

`Academic Press is an imprint of Elsevier
`Linacre House, Jordan Hill,_Oxford, OX2 8DP
`30 Corporate Drive, Burlington, MA 01803
`
`First edition 2007
`Second edition 2008
`
`Copyright © 2008. Erik Dahlman, Stefan Parkvall, Johan Skold and Per Beming.
`Published by Elsevier Ltd. All rights reserved
`
`The right of Erik Dahlman, Stefan Parkvall, Johan Skold and Per Beming to be
`identified as the authors of this work has been asserted in accordance with the
`
`Copyright, Designs and Patents Act 1988
`
`No part of this publication may be reproduced, stored in a retrieval system or
`transmitted in any form or by any means electronic, mechanical, photocopying,
`recording or otherwise without the prior written permission of the publisher
`
`Notice
`
`No responsibility is assumed by the publisher for any injury and/or damage to persons
`or property as a matter of products liability, negligence or otherwise, or from any use
`or operation of any methods, products, instructions or ideas contained in the material herein
`
`British Library Cataloguing in Publication Data
`3G evolution : HSPA and LTE for mobile broadband. — 2nd ed.
`
`2. Mobile communication
`1. Broadband communication systems — Standards
`systems — Standards
`3. Cellular telephone systems — Standards
`1. Dahlman, Erik
`621 .3’8546
`
`Library of Congress Control Number: 2008931278
`
`ISBN: 978-0-12—374538-5
`
`
`For information on all Academic Press publications
`visit our website at elseVierdirect.com
`
`Permission may be sought directly from Elsevier’s Science & Technology Rights
`Department in Oxford, UK: phone (+44) (0) 1865 843830; fax (+44) (0) 1865 853333;
`email: perrnissions@elsevier.com. Alternatively you can submit your request online by
`visiting the Elsevier website at http://www.elsevier.com/locate/permissions, and selecting
`Obtaining permission to use Elscvier material
`
`Sabre Foundation
`
`Typeset by Charon Tec Ltd., A Macmillan Company. (www.macmillansolutionscom)
`
`Printed and bound in Great Britain by MPG Books Ltd, Bodmin, Cornwall
`
`080910111110987654321
`
`
`Working together to grow
`libraries in developing countries
`www.elsevier.com I wwwbookaidorg I www.sabre.org
`
`ELSEVIER
`
`£235,533
`
`ZTE/SAMSUNG 1033-0004
`
`4
`
`

`

`3G Evolution: HSPA and LTE for Mobile Broadband
`
`
`
`Detailed
`Testing and
`
`specifications
`verification
`
`Figure 1.1 The standardization phases and iterative process.
`
`specification phase. The testing and verification phase ends when there are
`
`Finally, the testing and verification phase starts. It is usually not a part of the
`actual standardization in the standards bodies, but takes place in parallel through
`testing by vendors and interoperability testing between vendors. This phase is
`the final proof of the standard. During the testing and verification phase, errors
`in the standard may still be found and those errors may change decisions in the
`detailed standard. Albeit not common, changes may need to be done also to the
`
`3. Detailed specifications, where every interface is specified in detail.
`4. Testing and verification, where the interface specifications are proven to
`work with real—life equipment.
`
`These phases are overlapping and iterative. As an example, requirements can be
`added, changed, or dropped during the later phases if the technical solutions call
`for it. Likewise, the technical solution in the detailed specifications can change
`
`due to problems found in the testing and verification phase.
`
`Standardization starts with the requirements phase, where the standards body
`decides what should be achieved with the standard. This phase is usually rela—
`
`tively short.
`
`ln the architecture phase, the standards body decides about the architecture, i.e.
`the principles of how to meet the requirements. The architecture phase includes
`decisions about reference points and interfaces to be standardized. This phase is
`
`usually quite long and may change the requirements.
`
`After the architecture phase, the detailed specification phase starts. It is in this
`phase the details for each of the identified interfaces are specified. During the
`detailed specification of the interfaces, the standards body may find that it has
`to change decisions done either in the architecture or even in the requirements
`
`phases.
`
`architecture or the requirements. To verify the standard, products are needed.
`Hence, the implementation of the products starts after (or during) the detailed
`
`ZTE/SAMSUNG 1033-0005
`
`5
`
`

`

`
`
`
`
`
`
`ops 3G specifications, but for cdma2000, which is the 3G technology developed
`
`1
`W62
`Radio Layer 2 &
`Layer 3 RR
`____l____
`WGB
`lub, luc, lur&
`UTRAN GSM Required
`_____lm
`we4
`Radio Performance
`& Protocol Aspects
`l
`WG5
`Mobile Terminal
`Conformance Test
`
`Figure 1.2
`
`3GPP organization. Iv
`
`stable test specifications that can be used to verify that the equipment is fulfilling
`the standard.
`
`Normally, it takes one to two years from the time when the standard is com—
`pleted until commercial products are out on the market. However, if the standard
`is built from scratch, it may take longer time since there are no stable compo—
`nents to build from.
`
`1.2.2 3GPP
`
`The Third-Generation Partnership Project (3GPP) is the standards—developing
`
`body that specifies the 3G UTRA and GSM systems, 3GPP is a partnership project
`formed by the standards bodies ETSI, ARIB, TTC, TTA, CCSA and ATIS. 3GPP
`consists of several Technical Specifications Groups (TSGs ), (see Figure 1.2).
`
`A parallel partnership project called 3GPP2 was formed in 1999. It also devel—
`
`Background of 3G evolution
`
`
`
`TSG RAN
`(Radio Access Network)
`
`
`
`I
`WGt
`Radio Layer 1
`
`ZTE/SAMSUNG 1033-0006
`
`6
`
`

`

`10
`
`3G Evolution: HSPA and LTEfor Mobile Broadband
`
`from the 2G CDMA—based standard 18—95. it is also a global project, and the
`
`organizational partners are ARIB, CCSA, TIA, TTA and TTC.
`
`3GPP TSG RAN is the technical specification group that has developed WCDMA,
`its evolution HSPA, as well as LTE, and is in the forefront of the technology. TSG
`
`RAN consists of five working groups (WGs):
`
`which occur 4 times a year. The 3GPP documents are divided into releases, where
`
`and the result of the work is also submitted to lTU. The organizational part~
`ners are obliged to identify regional requirements that may lead to options in the
`standard. Examples are regional frequency bands and special protection require—
`ments local to a region. The specifications are developed with global roaming
`and circulation of terminals in mind. This implies that many regional require—
`ments in essence will be global requirements for all terminals, since a roaming
`terminal has to meet the strictest of all regional requirements. Regional options
`in the specifications are thus more common for base stations than for terminals.
`
`. RAN WGl dealing with the physical layer specifications.
`2. RAN WGZ dealing with the layer 2 and layer 3 radio interface specifications.
`. RAN WG3 dealing with the fixed RAN interfaces, for example interfaces
`between nodes in the RAN, but also the interface between the RAN and the
`core network.
`
`. RAN WG4 dealing with the radio frequency (RF) and radio resource man—
`
`agement (RRM) performance requirements.
`. RAN WG 5 dealing with the terminal conformance testing.
`
`The scope of 3GPP when it was formed in 1998 was to produce global specifi—
`cations for a 3G mobile system based on an evolved GSM core network, including
`the WCDMA-based radio access of the UTRA FDD and the TD—CDMA—based
`
`radio access of the UTRA TDD mode. The task to maintain and develop the
`GSM/EDGE specifications was added to 3GPP at a later stage. The UTRA (and
`GSM/EDGE) Specifications are developed, maintained and approved in 3GPP.
`After approval, the organizational partners transpose them into appropriate deliv-
`erables as standards in each region.
`
`In parallel with the initial 3GPP work, a 3G system based on TD—SCDMA was
`developed in China. TD-SCDMA was eventually merged into Release 4 of the
`3GPP specifications as an additional TDD mode.
`
`The work in 3GPP is carried out with relevant lTU recommendations in mind
`
`The specifications of all releases can be updated after each set of TSG meetings,
`
`ZTE/SAMSUNG 1033-0007
`
`7
`
`

`

`Background ofSG evolution
`
`R99
`December 1999 ,
`
`‘ CS and PS
`' R99 Radio
`Bearers
`. MMS
`- Location
`Services
`etc.
`
`'
`
`«
`t
`
`’
`
`Rel-7
`September 2007
`
`Rel-8,
`
`- HSPA Evolution
`(MIMQ
`DL 64QAM,
`UL 18QAM
`Continuous
`packet
`connectivity) etc.
`
`- LTE
`- SAE
`. DC HSDPA
`eta
`
`4The work on IMT—ZOOO was moved from Working Party 8F to Working Party 5D in 2008.
`
`The present lTU work on 3G takes place in ITU—R Working Party 504 (WPSD),
`Where 3G systems are referred to as IMT—ZOOO. WPSD does not write technical
`
`Figure 1.3 Releases of 3 GPP specifications for UTRA.
`
`each release has a set of features added compared to the previous release. The fea—
`
`tures are defined in Work Items agreed and undertaken by the TSGs. The releases
`
`up to Release 8 and some main features of those are shown in Figure 1.3. The
`
`date shown for each release is the day the content of the release was frozen. For
`
`historical reasons, the first release is numbered by the year it was frozen (1999),
`
`while the following releases are numbered 4, 5, etc.
`
`For the WCDMA Radio Access developed in TSG RAN, Release 99 contains
`
`all features needed to meet the IMT—2000 requirements as defined by ITU.
`There are circuit—switched voice and Video services, and data services over both
`
`packet—switched and circuit-switched bearers. The first major addition of radio
`
`access features to WCDMA is Release 5 with High Speed Downlink Packet
`
`Access (HSDPA) and Release 6 with Enhanced Uplink. These two are together
`referred to as HSPA and are described in more detail in Part III of this book.
`
`With HSPA, UTRA goes beyond the definition of a 3G mobile system and also
`
`encompasses broadband mobile data.
`
`With the inclusion of an Evolved UTRAN (LTE) and the related System
`
`Architecture Evolution (SAE) in Release 8, further steps are taken in terms of
`
`broadband capabilities. The specific solutions chosen for LTE and SAE are
`described in Part IV of this book.
`
`1.2.3 WIT-2000 activities in I TU
`
`ZTE/SAMSUNG 1033-0008
`
`8
`
`

`

`3 G Evolution: HSPA and LTE for Mobile Broadband
`
`
`
`Interactive iile
`down/upload
`
`.®
`
`gaming
`
`In essence, the operators need fewer base stations and sites to provide the service.
`
`that enables new services can also be utilized to provide better mobile—communi—
`cation systems using more advanced technical features. Here lP technology is not
`only a key enabler to allow for new services to pop up, but also a way of reduc—
`ing cost of new services. The reason is that IP as a bearer of new services can be
`used to introduce new services as they come, not requiring an extensive special
`design of the system. Of course, this requires that the devices used in the mobile—
`communication system can be programmed by third—party providers and that the
`operators allow third—party service providers to use their network for communication.
`
`
`
`Backgroundtiledown/upload
`
`Low
`
`High
`
`Delay
`
`Figure 2.2 The bit rate - delay service space that is important to cover when designing a new
`cellular system.
`
`of the mobile-communication systems need to stop at a reasonable level, a level
`that the technology available at the time of standardization can provide.
`
`2. 1.3 Cost and performance
`
`There is another important driving factor for future mobile-communication sys—
`tems and that is the cost of the service provisioning. The technology advancement
`
`Another important factor is that operators need to provide the services to all the
`users. Not only one user needs to get the low delay, high data rate, etc. that its
`service needs, but all the users with theirdifferent service needs should be served
`
`efficiently. The processing capacity evolution and Moore’s law help also for this
`problem. New techniques are enabled by the higher processing power in the
`devices — techniques that delivers more bits of data per hertz. Furthermore, the
`coverage is increased with more advanced antennas and receivers. This enables
`the operators to deliver the services to more users from one base station, thus
`requiring fewer sites. Fewer sites imply lower operational and capitalization costs.
`
`ZTE/SAMSUNG 1033-0009
`
`9
`
`

`

`The motives behind the 3G evolution
`
`21
`
`if they were provided with the
`Obviously, all services would be ‘happy’
`highest data rate, lowest delay, and lowest jitter that the system can provide.
`Unfortunately, this is unattainable in practice and contradictory to the operator
`goal of an efficient system: in other words, the more delay a service can handle
`the more efficient the system can be. Thus, the cost of providing lowest possi—
`ble delay, jitter and call setup time is somewhat in conflict with the need of the
`
`mobile—network operator to provide it to all the users. Hence, there is a trade—off
`between user experience and system performance. The better the system per—
`formance is, the lower the cost of the network. However, the end users also need
`
`to get adequate performance which often is in conflict with the system perform-
`ance, thus the operator cannot only optimize for system performance.
`
`did not stop working on LTE when the first version of the specifications was
`
`The result of the LTE workshop was that a study item in 3GPP TSG RAN
`was created in December 2004. The first 6 months were spent on defining the
`requirements, or design targets, for LTE. These were documented in a 3GPP
`technical report [86] and approved in June 2005. Chapter 13 will go through
`the requirements in more detail. Most notable are the requirements on high data
`rate at the cell edge and the importance of low delay, in addition to the normal
`capacity and peak data rate requirements. Furthermore, spectrum flexibility and
`maximum commonality between FDD and TDD solutions are pronounced.
`
`2.2 3G evolution:Two Radio Access Network approaches
`and an evolved core network
`
`2.2.1 Radio Access Network evolution
`
`TSG RAN organized a workshop on 3GPP long—term Evolution in the fall of
`2004. The workshop was the starting point of the development of the Long—
`Terrn Evolution (LTE) radio interface. After the initial requirement phase in the
`spring of 2005, where the targets and objectives of LTE were settled, the techni—
`
`cal specification group TSG SA launched a corresponding work on the System
`Architecture Evolution, since it was felt that the LTE radio interface needed a
`
`suitable evolved system architecture.
`
`During the fall 2005, 3GPP TSG RAN WGl made extensive studies of different
`
`basic physical layer technologies and in December 2005 the TSG RAN plenary
`decided that the LTE radio access should be based on OFDM in the downlink
`
`and single carrier FDMA in the uplink.
`
`TSG RAN and its working groups then worked on the LTE specifications and
`the specifications were approved in December 2007. However, 3GPP TSG RAN
`
`ZTE/SAMSUNG 1033-0010
`
`10
`
`

`

`Uplink transmission scheme
`
`389
`
`uplink reference—signal sequences should be a multiple of 12 which is obvi-
`
`ously not a prime number.
`For short sequence lengths, corresponding to narrow uplink transmission
`bandwidths, relatively few reference—signal sequences would be available
`
`even if they were based on prime—length Zadoff—Chu sequences.
`
`Instead, for sequence lengths larger than or equal to 36, corresponding to trans—
`mission bandwidths larger than or equal to three resource blocks, the reference~
`signal sequences are defined as cyclic extensions of Zadoff—Chu sequences of
`length MZC, where MZC is the largest prime number smaller than or equal to
`
`the desired reference—signal sequence length. For example, the largest prime
`
`number less than or equal to 36 is 31, implying that reference—signal sequences
`
`of length 36 are defined as cyclic extensions of Zadoff—Chu sequences of length
`
`31. The number of available sequences is then equal to 30, that is, one less
`
`than the length of the Zadoff—Chu sequence. For larger sequence lengths, more
`
`sequences are available. For example, for a reference-signal sequence length
`equal to 72, there are 70 sequences available.4
`
`For sequence lengths equal to 12 and 24, corresponding to transmission bandwidths
`
`of one and two resource blocks, respectively, special QPSK—based sequences have
`
`instead been found from computer search and are explicitly listed in the LTE speci—
`
`fications. For each of the two sequence lengths, 30 sequences are then available.
`
`17.2.1.2 Phase-rotated reference-signal sequences
`
`domain phase rotation.
`
`In the previous section it was described how different reference—signal sequences
`(a minimum of 30 sequences for each sequence length) can be derived, primarily
`by cyclically extending different prime-length Zadoff—Chu sequences. Additional
`reference-signal sequences can be derived by applying different linear phase rota—
`tions to the same basic reference—signal sequence as illustrated in Figure 17.6, where
`
`the basic reference-signal sequence is defined according to Section 17.2.1.1 above
`
`(cyclically extended Zadoff—Chu sequence for sequence lengths larger than or equal
`
`to 36, special sequences for sequence lengths equal to 12 and 24).
`
`Applying a linear phase rotation in the frequency domain is equivalent to apply—
`
`ing a cyclic shift in the time domain. Thus, although being defined as differ~
`
`in the LTE specification this is often
`ent frequency-domain phase rotations,
`referred to as applying different cyclic shifis5 to the same basic reference—signal
`
`4The largest prime—number smaller than or equal to 72 is 71. The number of sequences is then one less than
`the length of the Zadoff-Chu sequence (i.e., 70).
`5Not to be mixed up with the cyclic extension of Zadol‘l—Chu sequences to generate the basic reference-signal
`sequences. The cyclic shift discussed here would be a time—domain cyclic shift, equivalent to a frequency—
`
`ZTE/SAMSUNG 1033-0011
`
`11
`
`

`

`3G Evolution: HSPA and LTE for Mobile Broadband
`
`,
`Basic
`,
`reference-signal r
`sequence
`,
`
`XM1
`
`,
`
`mOdUlatOr
`
`Cyclic-prefix
`
`insertion
`
`Phase~rotated
`reference-signal
`sequence
`
`Figure 17.6 Generation of aplink reference—signal sequence from linear phase rotation of a
`basic reference-signal sequence.
`
`sequence. Here the more correct term ‘phase rotation’ will be used. However,
`it should then be had in mind that what is here referred to as ‘phase rotation’ is
`
`often, although in some sense somewhat incorrectly, referred to as ‘cyclic shift.’
`
`tions over 12 subarriers, that is, over one resource block.
`
`Reference signals defined from different reference~signal sequences typically
`have relatively low but still non-zero mutual correlation. In contrast, reference
`signals defined from different phase rotations of the same basic reference—signal
`sequence can be made completely orthogonal, thus causing no interference to
`each other, assuming the parameter a in Figure 17.6 takes a value HWY/6 where m
`ranges from O to 11.6 Up to 12 orthogonal reference signals can thus be defined
`from each basic reference—signal sequence.
`
`However, to preserve the orthogonality between these reference signals also at
`the receiver side, the channel should be frequency non—selective over the span of
`12 subcarriers (one resource block). If that is not the case, a subset of the avail—
`
`able values for 04 may be used, for example, only the values {0, 2n/6, 411/6,
`lOtt/6} or perhaps even less values. Limiting the set of values for (1 implies
`orthogonality over a smaller number of subcarriers, that is, less sensitivity to
`
`channel frequency selectivity.
`
`Another prerequisite for orthogonality between reference signals defined from
`different phase rotations of the same basic reference~signal sequence is that the
`reference signals should be received relatively time aligned. A timing misalign-
`ment between the reference signals will, in the frequency domain, appear as a
`
`6The orthogonality is due to the fact that, for a = Inn/6, there will be an integer number of full-circle rota—
`
`ZTE/SAMSUNG 1033-0012
`
`12
`
`

`

`Uplink transmission scheme
`
`391
`
`phase rotation that may counteract the phase rotation applied to separate the ref—
`
`erence—signal sequences. The result may be substantial interference between the
`
`reference-signal transmissions.
`
`In general for LTE, uplink transmissions from different terminals within the
`
`same cell are typically anyway well—time aligned as this is a prerequisite for
`
`retaining the orthogonality between different frequency—multiplexed transmis—
`
`sions. Thus, one possible use of reference signals defined from different phase
`rotations of the same basic reference—signal sequence is for the case when multi—
`
`ple mobile terminals within the same cell simultaneously transmit on the uplink
`using the same frequency resource. As will be seen in Section 17.3, this is, for
`
`example, the case for uplink PUCCH transmissions.
`
`Another possible use of reference signals defined from different phase rotations
`of the same basic reference—signal sequence is for mobile terminals in neighbor
`
`cells belonging to the same eNodeB as such cells are, in practice, often tightly
`
`synchronized to each other and thus uplink transmissions in these cells are, in
`
`practice, relatively well—time aligned. The use of different phase rotations of the
`
`same basic reference—signal sequence for such mobile terminals will reduce the
`interference between the reference—signal transmissions of these terminals. This
`
`is then only applicable to PUSCH transmission as, for PUCCH, the different
`phase rotations are already used within the same cell as mentioned above.
`
`17.2. 1.3 Reference-signal assignment to cells
`
`two sequences per group.
`
`As described above, the design of the LTE reference—signal sequences allows
`for at least 30 sequences of each sequence length. To assign reference-signal
`sequences to cells these sequences are first grouped into 30 sequence groups
`
`where each group consists of:
`
`One reference-signal sequence for each sequence length less than or equal
`to 60, corresponding to a transmission bandwidth of five resource blocks or
`less.
`
`Two reference—signal sequences for each sequence length larger than or equal
`to 72,7 corresponding to a transmission bandwidth of six resource blocks or
`more.
`
`The grouping of reference—signal sequences into sequence groups is illustrated
`
`in Figure 17.7. It can be noted that the sequence groups do not include any
`
`7For sequence lengths larger than or equal to 72 there are more than 60 sequences of each length allowing for
`
`ZTE/SAMSUNG 1033-0013
`
`13
`
`

`

`432
`
`3G Evolution: HSPA and LTEfor Mobile Broadband
`
`In case of a relatively small SI and a relatively large system bandwidth, a sin-
`
`gle subframe may be sufficient for the transmission of the SI. In other cases,
`
`multiple subframes may be needed for the transmission of a single SI. In the
`
`latter case, instead of segmenting each SI into sufficiently small blocks that
`
`are separately channel coded and transmitted in separate subframes, the com—
`
`plete SI is channel coded and mapped to multiple, not necessarily consecutive
`subframes.
`
`Similar to the case of the BCH, terminals that are experiencing good channel
`
`conditions may then be able decode the complete SI after receiving only a sub-
`set of the subframes to which the coded SI is mapped, while terminals in bad
`
`positions need to receive more subframes for proper decoding of the SI. This
`
`approach has two benefits:
`
`0 Similar to BCH decoding, terminals in good positions need to receive fewer
`
`subframes, implying the possibility for reduced terminal power consumption.
`
`0 The use of larger code blocks in combination with Turbo coding leads to
`
`improved channel—coding gain.
`
`purpose of assigning a unique identity, the C—RNTI, to the terminal.
`
`Establishment of uplink synchronization is the main objective for all the cases
`above; when establishing an initial radio link (i.e., when moving from RRC_
`
`18.3 Random access
`
`A fundamental requirement for any cellular system is the possibility for the ter—
`
`minal to request a connection setup, commonly referred to as random access. In
`LTE, random access is used for several purposes, including:
`
`for initial access when establishing a radio link (moving from RRC__IDLE to
`
`RRCwCONNECTED; see Chapter 15 for a discussion on different terminal
`
`states);
`
`to re—establish a radio link after radio link failure;
`
`for handover when uplink synchronization needs to be established to the
`new cell;
`
`to establish uplink synchronization if uplink or downlink data arrives when
`
`the terminal is in RRC_CONNECTED and the uplink is not synchronized;
`
`as a scheduling request if no dedicated scheduling—request resources have
`
`been configured on PUCCH (see Chapter 19 for a discussion on uplink
`
`scheduling procedures).
`
`IDLE to RRC_CONNECTED), the random—access procedure also serves the
`
`ZTE/SAMSUNG 1033-0014
`
`14
`
`

`

`LTE access procedures
`
`Synchronize to
`downlink timing
`(from cell search)
`
`Step 1 — Random access preamble >
`
`4
`Step 2 — Random access response
`
`Adjust uplink timing
`‘
`I
`
`Step 3 ‘ RRC S’gnal'ng
`
`Only if UE is not known in eNodeB
`(initial random access)
`
`
`
`dom access. The last three steps utilize the same physical—layer processing as
`
`nization is necessary as the terminal otherwise cannot transmit any uplink data.
`. The second step consists of the network transmitting a timing advance com~
`mand to adjust the terminal transmit timing, based on the timing estimate in
`the first step. In addition to establishing uplink synchronization, the second
`step also assigns uplink resources to the terminal to be used in the third step
`in the random—access procedure.
`. The third step consists of transmission of the mobile—terminal identity to
`the network using the UL—SCH similar to normal scheduled data. The exact
`content of this signaling depends on the state of the terminal, in particular
`whether it is previously known to the network or not.
`. The fourth and final step consists of transmission of a contention~resolution
`message from the network to the terminal on the DL—SCH. This step also
`resolves any contention due to multiple terminals trying to access the system
`
`
`
`Step 4 — RRC signaling ------------------» -----------------
`
`u .. , ,éigi‘éi 9.??? 'v
`
`Figure 18.8 Overview of the random-access procedure.
`
`The basis for random access is a contention—based procedure,
`
`illustrated in
`
`Figure 18.8, and consists of four steps:
`
`. The first step consists of transmission of a random—access preamble, allowing
`the eNodeB to estimate the transmission timing of the terminal. Uplink synchro—
`
`using the same random—access resource.
`
`Only the first step uses physical—layer processing specifically designed for ran-
`
`ZTE/SAMSUNG 1033-0015
`
`15
`
`

`

`434
`
`3G Evolution: HSPA and LTEfor Mobile Broadband
`
`used for normal uplink and downlink data transmission. In the following, each
`
`of these steps is described in more detail.
`
`Additionally, for handover purposes it is possible to use the random~access
`mechanism in a contention—free manner as described further below. In this case
`
`only the first two steps of the procedure are used as there is no need for conten-
`tion resolution in a contention-free scheme.
`
`Figure 18.9 Preamble subsets.
`
`\ _ _ _ . _ _ _ _ _ _ . _ _ _ _ _ . . _ _ . . . __\ _ _ _ _ _ _ _ . _ _ . _ . . . . . . _ . . _ _ --
`5..O.I...I.0.0;IOOOOOOOOOOOOOJOOOOO
`¥._______—_________w_______—______/
`64 Preambles in each cell
`
`18.3.1 Step 1: Random-access preamble transmission
`
`The first step in the random-access procedure is the transmission of a random-
`
`access preamble. The main purpose of the preamble transmission is to indicate
`
`to the base station the presence of a random—access attempt and to allow the
`base station to estimate the delay between the eNodeB and the terminal. The
`
`delay estimate will be used in the second step to adjust the uplink timing.
`
`The time—frequency resource on which the random—access preamble is transmit—
`
`ted upon is known as the Physical Random Access Channel (PRACH). The net—
`
`work broadcasts information to all terminals in which time—frequency resources
`
`random—access preamble transmission is allowed (i.e., the PRACH resources, in
`
`SIB—2). As part of the first step of the random—access procedure, the terminal
`selects one preamble to transmit on the PRACH.
`
`In each cell, there are 64 preamble sequences available. Two subsets of the 64
`
`sequences are defined as illustrated in Figure 18.9, where the set of sequences
`
`in each subset is signaled as part of the system information. When performing
`a (contention—based) random—access attempt, the terminal at random selects one
`
`sequence in one of the subsets. As long as no other terminal is performing a
`random—access attempt using the same sequence at the same time instant, no
`
`collisions will occur and the attempt will, with a high likelihood, be detected by
`the eNodeB.
`
`The subset to select the preamble sequence from is given by the amount of data
`the terminal would like to transmit on the UL-SCH in the third random~access
`
`Preamble set #0
`
`Preamble set #1
`
`For contention-free access
`
`ZTE/SAMSUNG 1033-0016
`
`16
`
`

`

`LTE access procedures
`
`435
`
`step. Hence, from the preamble the terminal used, the eNodeB, will get some
`guidance on the amount of uplink resources to be granted to the terminal.
`
`If the terminal has been requested to perform a contention—free random access,
`for example, for handover to a new cell, the preamble to use is explicitly indi—
`cated from the eNodeB. To avoid collisions,
`the eNodeB should preferably
`select the contention—free preamble from sequences outside the two subsets used
`for contention-based random access.
`
`attempt can be initialized. For TDD, multiple random-access regions can be
`
`Typically, the eNodeB avoids scheduling any uplink transmissions in the time-
`frequency resources used for random access. This avoids interference between
`UL—SCH transmissions and random—access attempts from different
`termi—
`nals. The random—access preamble is said to be orthogonal to user data, unlike
`WCDMA where uplink data transmission and random-access attempts share the
`same resources. However, from a specification perspective, nothing prevents the
`uplink scheduler to schedule transmissions in the random~access region. Hybrid—
`ARQ retransmissions are an example of this; synchronous non—adaptive hybrid—
`ARQ retransmissions may overlap with the random—access region and it is up to
`the implementation to handle this, either by moving the retransmissions in the
`frequency domain as discussed in Chapter 19 or by handling the interference at
`the eNodeB receiver.
`
`18.3.1.1 PRACH time—frequency resources
`
`the PRACH resource, illustrated in Figure 18.10,
`In the frequency domain,
`has a bandwidth corresponding to six resource blocks (1.08 MHZ). This nicely
`matches the smallest uplink cell bandwidth of six resource blocks in which LTE
`can operate. Hence, the same random—access preamble structure can be used,
`regardless of the transmission bandwidth in the cell.
`
`In the time domain, the length of the preamble region depends on configured
`preamble as will be discussed further below. The basic random—access resource
`is lms in duration, but there is also the possibility to configure longer pream—
`
`bles. Also, note that the eNodeB uplink scheduler in principle can reserve an
`arbitrary long random—access region by simply avoiding scheduling terminals in
`multiple subsequent subframes.
`
`For FDD, there is at most one random—access region per subframe, that is, multi—
`ple random—access attempts are not multiplexed in the frequency domain. From
`a delay perspective, it is better to spread out the random~access opportunities in
`the time domain to minimize the average waiting time before a random—access
`
`ZTE/SAMSUNG 1033-0017
`
`17
`
`

`

`
`
`ZTE/SAMSUNG 1033-0018
`
`ZTE/SAMSUNG 1033-0018
`
`18
`
`