1
`
`APPLE 1033
`
`

`
`3G EVOLUTION: IISPA AND LTE FOR MOBILE BROADBAND
`
`2
`
`

`
`3G Evolution
`
`HSPA and LTE for Mobile Broadband
`
`Second edition
`
`Erik Dahlman, Slzfan Parkvall, Johan Skiild and Pct Bcming
`
`AMSTERDAM ' DOST“! ' HEDEJERO ' LONDON" NEW YORK ' OXJVMID
`PARIS - SAN DIRK) ' SAN FIANCIEYJ ' SINGAPORE ~ SYDNEY ' TOKYO
`Academic P.-using Inpdnloflnccviu
`
`3
`
`

`
`Aqnlcrnic Press is in lrlprim of Elsevier
`1..hIaaeHouse,Jon1an Hlll, (mom, 0x2 em
`30 Cnrponle Drive. Bnllingon. MA 01803
`First edition 20:0
`Second edilion2€08
`
`capyxigme zoos. Erik Dahlmln, Stelan Parkvall. Johan sumo -an Per Bemmx.
`Published by Elsevier Lad. All mm: reserved
`The light of Erik Dahlmnn. Stefan Parlmll. Johm sum and Pet Beminz no he
`iaitifiednstheuuhalxoflhix workhnshenlnmedinurudamewimlfn
`Copyright, Designs and Patents Act I988
`No pm ofthis plislicalion may be rupmducad. mm: in a retrieval nylun or
`Innsmitwd in any form or by any means electmnk, mechanicd, pholnoopying,
`rwonling or umemlse without the prior written petmission of the publbhnr
`Permission may be sought dlreclly frum Eeeviefi Scizuw & Technology High:
`Dqumrnent In Oxford. UK: phone (+44) (0) 1865 843830. fax (+44) (0) 1865 853333;
`email; pennissioc:Oe1sevier.com. Alternatively you can submit you! rerpest unline by
`visiting the Elneviar websue at hnprl/wwweloevleuaom/louldpeanissions. and selecting:
`obwmnepumhhnwmwmflmmm
`Notice
`No nwonsibility is swurned by the publiuher io(:uIyin_mry' andlordmage to penons
`0‘, “WWW .5 _ mm 0, Pmum mbm,y_ lemma ammfin 0‘ [mm use
`propenuon 01 any mcmoas, produas. inslrmtions or ideas contained in ma mania! rmin
`Emu. “hm, c_uM_m in mama“ Dm
`30 evo1uliol:HSPA and LTE for mobile bmadlnnd. - 2nd at
`1. Bmunband oommunixanu syslems — Standards
`2. Mobile communication
`systans — sundaxds
`3. Cdlnlar mleplmne systems - Sumdu-da
`ézlyasdfi
`I‘“'"''’' °'C“"""" C°'"“" N°"b‘” 1003931273
`ISBN: mo. I2.374538—5
`
`vim our wgbmg at ¢13¢vi¢;.1im¢,com
`
`Typeset by Charon Tec 1.Ad., A Macmillan Company. (w1lw.maani|lanm|mions.com)
`P‘med_ndmmdhG‘mBflumbyMPGB°°hm~3mnin_CmIwnll
`08091011 in 10987654321
`
`VVorldng together to grow
`lib;-afjes
`oountfics
`u-wucelscviezconi
`I ww-w.bonhid.o|g | www.sd2re.oIg
`I—‘l\'l"‘\-IH-x‘
`‘?‘.’,"*‘-'-’:
`5.-|rr~i":-I:1-§.m«.uu
`
`_.~
`
`.
`V
`;
`
`'
`
`3
`3
`‘
`5
`s
`
`A
`;‘
`‘
`
`U3‘ "f F'8'“‘”
`List of Ihblas
`
`Preface
`
`Acknowledgements
`Li“ of Acronyms
`
`PIN. I: Introduction
`
`1 Backgroundol'3G evolution
`,
`'
`' '
`1'] Hismr} and backgmmd of 3G '
`.
`. . .
`1.1.] Before 3G . . .
`.
`.
`.
`. . .
`.
`. . .
`.
`1.1.2 Early 3G discussio .
`. . . . . .
`1.1.3 Research on 3G .
`.
`. .
`.
`. . . . . . .
`1.1.4
`3G sumdardiuxion starts .
`.
`. . .
`Snmdaxdiufion , , . , _
`_
`_
`_
`_ _ _
`_
`_ _ _
`_
`_
`_
`‘ ' _ V V
`.
`L11
`-"K standardization process _ .~ .
`.
`. .
`.
`.
`.
`.
`.
`. .
`. . .
`.
`.
`. . . .
`.
`. . ,
`. . . .
`. . .
`.
`.
`.
`1.2.3
`IMT-ZOKX) activities in ITU .
`.
`.
`Spectrum for 3G and systems beyond 3G.
`. . .
`.
`
`1.2
`
`1.3
`
`.
`. . .
`.
`. . . . .
`.
`. . . .
`.
`.
`. .
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`I
`.
`.
`.
`
`.
`.
`. . . . .
`.
`.
`. . . . .
`. . . . . . .
`.
`.
`.
`. . .
`.
`
`.
`. . . .
`.
`. . . .
`.
`. . .
`.
`.
`. . . .
`
`. . .
`. . .
`. . .
`. . .
`
`.
`.
`.
`.
`
`I
`.
`.
`
`. I _ '
`. . . .
`.
`.
`.
`,
`
`_
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. _ I
`. . .
`.
`.
`.
`. .
`
`_
`.
`.. 9
`. I]
`13
`
`2
`
`'I‘herrwtivesbehin¢ltIie3GevoIufion. . . . . . . .. . . . . . . ............l5
`2.1 Driving forces .
`.
`.
`. . . . .
`. . . . . .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. . .
`.
`.
`.
`.
`. 15
`2-1-1
`Technology advancements .
`.
`.
`. .
`.
`. .
`. .
`.
`.
`. . .
`. . . .
`.
`.
`.
`.
`. . . 16
`2.1.2
`Services .
`.
`.
`.
`. .
`, _ . _ .
`,
`.
`.
`.
`,
`_
`_
`_
`,
`,
`,
`. _ ,
`_
`_ , , _
`_
`,
`‘ _ _
`_
`,
`.
`_
`. 17
`2.1.3 Cosundperfommnce .
`.
`.
`.
`.
`.
`, .
`.
`. . . . . . . . .
`. . . . . .
`.
`. . .. 20
`3GeV°l“"°":N°R’d‘°A°°°ssN°tw°””PV'°a°h°‘
`and mi evolved core network.
`.
`.
`.
`.
`.
`.
`.
`. . .
`. . . .
`.
`. . . .
`. . . . . .
`.
`. . .
`. 21
`2.2.1 Radio Access Network evotutlon .
`. . . .
`.
`. . . .
`. . . .
`.
`.
`.
`.
`.
`.
`. 21
`2.2.2 An evolved core network: system sxchitedure
`evolution.
`. .
`4 . .
`.
`.
`. . .
`.
`.
`.
`. . .
`. . .
`.
`.
`. .
`.
`.
`. . . . . . .
`
`. . . . 24
`
`. . .
`
`4
`
`

`
`Figure 1.1 The stauilunltzzuion plums and iterative pmcw.
`
`3. Derailcd spccrflcatioru, where every interface is specified in detail.
`4. Terring and venficazion, where the interface specifications um provcn to
`work with real-life equipment.
`
`These phases at: ovcrlapping and itcntive. As an example. requirements can be
`added, changed. or dropped during the later phases if the technical solutions call
`for it. Likcwisc. thc technical solution in the detailed specifications can change
`due to problems found in the testing and verification phme.
`
`Standardization starts with the requirements phase, where the standard: body
`decides what should he achieved with the standard. This phase is usually min-
`tively short.
`
`In the architecture phase, the stand.-trds body decides about the architecture. i.e.
`the principlcs of how to meet the requirements. The architecture phase includes
`decisions about refcrcnce points and interfaces no 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 chnnge decisions done either in the architecture or even in the requirements
`phascn.
`
`Finally. the testing and verification phase starts. it is usually not a part of the
`actual standardiution in the standards bcdics. but takes place in parallel through
`testing by vendors and interoperability mung bctween vmdors. 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 he done also tothe
`architecture or the requirements. To verify the standard, products are needed.
`Hence. the implementation of the produas starts after (or during) the detailed
`specification phase. The testing and verification phase ends when there are
`
`Figure 1.2
`
`JGPP organlaulon
`
`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 pmducts are out on the market. However, if the standard
`is built from scratch, it may trace longer time since there are no stable compo-
`nents to build from.
`
`1.2.2 3GF‘P
`
`The 77u‘rd-Generation Partnznhip Pmjtct (3CrP1’) is the s mg
`body that specifies the 3G UTRA and GSM systcma. 3GP? is a parmership project
`formed by the standards bodies El‘Sl. ARIB. 'I'I‘C. '['l'A, CCSA and ATIS. 3GPP
`consists of several Technical Specifications Groups (T308 ). (see Figure 1.2).
`
`A parallel partnership project called 3Gl’P2 was formed in 1999. It also devel-
`ops 3G specifications. but for odm2000. which is the 3G technology developed
`
`5
`
`

`
`l0
`
`-
`
`30 balutloru HSPA and LTl:‘faI Mobile Blbadnnd
`
`from the 2G CDMA-bmcd standard IS-95. It is also a global project. and the
`organizational partner: are ARIB. CCSA, TIA, ’I'I‘A nnd’ITC.
`'
`
`SGPP 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 (W68):
`
`. RAN WGl dealing with the physical layer specifications.
`. RAN WG2 dealing with the layer 2 and layer 3 radio interface q)ecificntion.s.
`. RAN WG3 dealing with the listed RAN interfncm, for example interfaces
`betweennodeaintlte RAN,bu:also theinterfnce betweentheRANandt.he
`core network.
`. RAN WG4 dealing with the radiofrequency (RF) and radio resource man-
`agemen! (RRM) performance requirements.
`. RAN WG S dealing with tho terminal oonfonnnnw testing.
`
`The scope of 361’? when it was formed in [998 was to produce global specifi-
`cations for a 3G mobile rystem based on an evolved GSM core networlr. including
`the WCDMA-based radio access of the UFRA FDD and the TD-CDMA-based
`radioaooessoftiieUTRATDDmodeTheta:ktomaintainanddeveloptlie
`GSM/EDGE specifications was added to BGPP at a later stage. The UTRA (and
`GSM/EDGE) specifications are developed, maintained and approved in 2-GPP.
`After approval, the organizmional partners transpose tkmm into (appropriate deliv-
`erablcs as standards ineach region.
`
`In parallel with the initial 3GPP work, a 3G sysmm based on TD—SCDMA was
`developed in China. TD-SCDMA was eventually merged into Release 4 of the
`SGPP specifications as an additional TDD mode.
`
`The work in 3GPP is carried out with relevant ITU recommendations in mind
`and the result of the work is also submitted to ITU. 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 wanting
`and circulation of terminals in mind. This implies that many regional require-
`ments in eesence will be global requirements for all terminals, since A roaming
`terminal has to meet the stdctest of all regional requiremrs. Regional options
`in the specifications are thus more common for base stations than for terminals.
`
`The specifications of all releases can be updated after each set of TSG meetings,
`which occur 4 times a year. The SGPP documents are divided into releases, where
`
`Flgtlw L3 Rllmau o]3GPP xplcijicatiaurfur UTIM.
`
`each releasehas aset offeanmzs added compared to theprevious release. The fea-
`tures are defined in Work Item; agreed and undenaken by the TSGS. The releases
`up to Release 8 and some main femunes of those are shown in Figure 1.3. The
`date shown for each release is t.he day the content of the release was frozen. For
`historical remain. the first release is numbered by the year it was fravat (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 I'lU.
`There are circuit-switched voice and video services, and data services over both
`packet-switched and circuirswlnched bearers. The'i'int major addition of radio
`access features to WCDMA is Release 5 with High Speed Downlink Packet
`Access (HSDPA) and Release 6 with Erilrw-wed Uplink These two are together
`refen-ed 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 when in terms of
`broadband capabilities. The specific solutions chosen for LTE and SAE are
`described in Part IV of this book.
`«
`
`1.2.3 IMT-2000 activities in ITU
`
`The present rru work on so takes place in ITU-R Working Party 50‘ (wpsn),
`where 3G systems are referred to as IM'I‘-2000. WPSD does not write technical
`
`"De war): on [MT-21m wax nmedlrnmwoildng Puty 8FInWurklnghrty5D inzoon
`
`6
`
`

`
`36 Evaluubit: HSPA and LTEfurMabt'l¢ Broadband
`
`The motives behind the 36 evolution
`
`21
`
`Flxunzl Thabirmu dalayrarvlcespacethal lr Inportanrtocaverwhendaslgningartsw
`nellrdauystenn
`
`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 andperformance
`There is nnotlter important driving factor for future mobile—corn1n1InicaIi0n sys-
`tems and that is the cost of the service provisioning. The technology advancement
`thatenables new services can also be utilimd to pmvide better mobile-oommunh
`cation systems using more advanced technical features. Here [P technology is not
`onlyya key enabler to allow for new services to pop up. but also a way of reduc-
`ing coat of new services. The reason is that IP as a bearer of new services can be
`used to intmduce new services as they come. not requiring an extensive special
`design of the system Of course. this requires that rhcdevices used in the mobile-
`connnunicalion system can be programmed by third-party providers and that the
`operators allow third—party service provides to use their network for communication.
`
`Another important factor ‘n that operators need to provide the services to all the
`users. Not only one user needs to get the low delay, high data rule, etc. that its
`service needs. but all the users with their,dt'fl'erent service needs should be served
`efficiently. The proomsing capmity evolution and Moore‘: 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 advmoed antemas aml receivers. This enables
`the operators to deliver Lhc services to more users from one base stIl.ion._ thus
`requiring fewer sites. Fewer sites imply lower operational and capitalization costs.
`In essence. the operators need fewer bme stations and sites to provide the service.
`
`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 efficicnt system: in other words, the more delay tr service can lundle
`the more eflicient the system can be. This, 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 die users. Hence, there is a trade-off
`between mar experience and system perfomtance. The better the syaern per-
`fonnance is, the lower the costof 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 perfurrnance.
`
`2.2 3G evolution: Two Radio Access Network approaches
`and an evolved core network
`2.2. 1 Fladio Access Network evolution
`
`TSG RAN organized a workshop on JGPP long—te.rm Evolution in the fall of
`2004. The workshop was the starting point of the development of the Long-
`Term Evolution (LTE) radio interface. Afler the initial requirement phase In the
`spring of 2005, where me 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.
`.
`
`The result of the LTE workshop was that a study item in 3GPP TSG RAN
`was created in December 2(X)4. Ihe first 6 months were spent on defming the
`requirements. or design targets. for LTE. These were documented in a 3GPP
`technical report [86] and approved in June 2005. Chapter I3 will go through
`the requirements in more detail. Most notable are the requirements on highdatza
`rate at the cell edge and the importance of low delay. in addition no the normal
`capacity and peak data rate requirements. Furthermore. spectrum flexibility and
`maximum commonality between PDD and TDD solutions are pronounced.
`
`During the fall 2005, 3GPP TSG RAN WGI made extensive studies of different
`basic physical layer technologies and in December 2005 the TSG RAN plcnary
`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. 3GPl’ TSG RAN
`did not stop working on LTE when the fi.|‘8l version of the specifications was
`
`7
`
`

`
`437.
`
`3G Evnludnn: HSPA and LTEjor Mobile Broaaand
`
`In case of a relatively small 31 and a relatively large system bandwidth, a sin-
`gle subfr-arrte may he suflicicnt for the transmission of the SI. In other cuu,
`multiple subfmmes may be needed for the transmission of a single S]. In the
`latter case, instead of segmenting each SI into sufficiently small blocks tint
`are separately channel coded and transmitted in separate subfiamcs. the com-
`plete S1 is channel coded and mapped to multiple, not necessarily consecutive
`subfraines.
`
`Sirnflar to the case of the BCH, terminals that are experiencing good channel
`conditions may then be able decode the complete SI afler receiving only a sub-
`set of the subframes to which the coded S1 is mapped, while terminals in bad
`positions need to receive more subfrarncs for proper decoding of the 51. This
`approach has two benefits:
`
`0 Similar to BCH decoding, terminals in good position: need to receive fewer
`subframes. implying the possibility for reduced terrninal power consumptiort
`0 The use of larger code blocks in combination with 'l\rrho coding leads to
`improved channel-coding gain.
`
`18.3 Random access
`
`A fundamental reqiiircrnent for any cellular system is the pomhility for the ter-
`minal to request a connection setup, commonly referred to as randnm accnrs. ln
`LTE, random access is used for several purposes, including:
`
`for initial access when establishing a radio link (moving from RRCJDLB to
`RRC_C()NNECTED: see Chapter l5 for a discussion on different terminal
`states)‘,
`to re-establish a radio link after radio link failure;
`for handover when uplirtk 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_CONN'ECTED and the nplink is not synchronized;
`as a scheduling request if no dedicated scheduling-request resources haw
`been configured on PUCCH (see Chapter 19 for a discussion on uplink
`scheduling procedures).
`
`Establishment of uplink syncll-onization is the main objective for all the cases
`above: when establishing an
`radio link (i.e.. when moving from RRC_
`IDLE to RRC_CONNECI'ED).
`the random-access procedure also serves the
`purpose of-assigning a unique identity, the C-RNTI. to the terminal.
`
`l‘'-?
`.v'-:_.‘
`.635
`
`1Syndwrivc to
`nmmnz Imru
`(ham urn -eaten)
`5tqa1—Rendcmacc0ecptoambtn
`stop?-Rancornaccassrvsmnso
`
`Atirrauaiilrtinmn
`
`5993-RRC*'fl"‘|'09
`
`Orfiyifufilsnatltnnvwrthaflcdsfi
`tlnlnl random access)
`
`Figure Iltll Oturview ofrlu nmdanr-acce.r.t pmccdure
`
`The basis for random access is a contention-based procedure. illustrated in
`Figure 18.8, andconsiscs of four steps:
`
`1. The flrst step consists of tnnsrnission of a rarxiorh-access preamble, allowing
`the eNodeB to estimate the transmission timing of the terminal. Uplink synchro-
`nimtion 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 tint step. In addition to establishing trplinlt synchronization, the second
`step also assigns uplink resources to the temtinal to be used in the third step
`in the random-accent procedure.
`. The third step consists of tmnsmission of the l'l10bll9r‘CInliI'Ibl identity to
`the network using the UL-SCH similar to nom1al scheduled data. The exact
`content of this signaling depends on the state of the terminal. in particular
`whether it is previously lcnown 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
`using the same rmdom—acccss resource.
`
`Only the first step uses physical-layer processing specifically designed for ran-
`dom access The lmt three steps utilize the same physical-layer processing as
`
`8
`
`

`
`434
`
`3G Evoblawl: HSPA and LIFf0rM0bI'le Bmadbald
`
`LTEasters’procedure:
`
`435
`
`used for normal uplink and downlink dam transmision. In the following, each
`of those steps is dwcribcd in more detail.
`
`step. Hence. from the preamble the temiinal used, the cNodeB, will get some
`guidance on the amount of uplink resources to be granted to the terminal.
`
`Additionally. for handover purposes it is possible to use the randorn—access
`mechanism in a contentioo—free manner as described further below. in this case
`only the firsl two steps of the procedure are used as there is no need for conten-
`tion resolution in a contention-fi'ee scheme.
`
`18.3. 1 Step 1: Random-access preamble transmission
`The first step in the rmdorn—aocess procedure is the tmnsntission of at random-
`acoem preamble. The main purpose of the preamble transmission is to indicate
`to the base station the presence of a rmdormaooefi 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 tinting.
`
`The time-frequency resource on which the random-access preamble is transmit-
`md upon is known as the Plrfirioal Random Accu: Clraruul (PRACH). The net-
`work broadcasts information to all terminals in which time-frequency resources
`rnndom—acwes prcamblc transmission is allowed (i.e.. the PRACH resources, in
`SIB-2). As part of the first step of the random-acce procedure, the terminal
`selects one prcarnble to transmit on the PRACH.
`
`In each cell, there are 64 preamble sequences available. 'I\v‘o 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 lnformaflon. 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 horn is given by the amount of data
`the terminal would like to transmit on the UL-SCH in the third random-access
`
`PIOQMDIO OM DD
`
`PGOBFIWIQ *l .1
`
`F07 oontnntlcn-tree ICCBOQ
`
`64 Pnnmbtos In ouch col
`
`Figure 18.9 Preamble subsets
`
`If the terminal has been requested to perform a contention-ftcc random access,
`for example, for handover to a new cell. the preamble In use is explicitly indi-
`cated from the eNodeB. To avoid collisions, the eNodcB should preferably
`select theconlention-free preamble from sequences outside the two subsets used
`for contention-based random: access.
`
`18.3.1.1 PFIACH time-frequency resources
`In the frequency domain, the PRACH resource. illustrated in Figure 18.10,
`has a bandwidth corresponding to six resource blocks (l.08MHz). This nicely
`rnatdres the smallest uplink cell bandwidth of six resource block: 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 suMrames.
`
`Typically. the eNodeB avoids scheduling any uplink transmissions in the time-
`frequency resources uxd for random access. This avoids interference between
`UL-SCH transmissions and random-access attempt:
`from difiemnt
`termi-
`nals. The random-access preamble is said to be orthogonal to user data, unlike
`WCDMA where uplinlt data nnrtsrrtisaion and random-access attempts share the
`same resources. However. from a specification perspective. nothing prevents the
`uplink scheduler to schedule rnrnsrniuions in the mntbm-access region. Hybrid-
`ARQ retransmissions are an example of this: synchronous non-adaptive hybrid-
`ARQ retransmissions may overlap with the random—ar>oeas region and it is up to
`the implementation to handle this. either by moving the retrat-emissions in the
`frequency tkarnain as diswssod in Chapter [9 or by handling the interference at
`the eNodeB receiver
`
`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
`attempt can be initialized. For TDD. multiple randon1—access regions can be
`
`9