(i)
`
`Petitioner's Exhibit 1007
`
`

`
`4G: LTE/LTE-Advanced
`for Mobile Broadband
`
`Second Edition
`
`Erik Dahlman
`
`Stefan Parkvall
`
`Johan Sko¨ ld
`
`AMSTERDAM (cid:129) BOSTON (cid:129) HEIDELBERG (cid:129) LONDON
`NEW YORK (cid:129) OXFORD (cid:129) PARIS (cid:129) SAN DIEGO
`SAN FRANCISCO (cid:129) SINGAPORE (cid:129) SYDNEY (cid:129) TOKYO
`Academic Press is an imprint of Elsevier
`
`
`(ii)
`
`Petitioner's Exhibit 1007
`
`

`
`Academic Press is an imprint of Elsevier
`The Boulevard, Langford Lane, Kidlington, Oxford, OX5 1GB
`225 Wyman Street, Waltham, MA 02451, USA
`
`First published 2011
`Second edition 2014
`
`Copyright Ó 2014, 2011 Erik Dahlman, Stefan Parkvall and Johan Sko¨ld. Published by Elsevier Ltd. All rights reserved.
`
`The rights of Erik Dahlman, Stefan Parkvall and Johan Sko¨ld 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 or transmitted in any form or by any means, electronic or
`mechanical, including photocopying, recording, or any information storage and retrieval system, without
`permission in writing from the publisher. Details on how to seek permission, further information about the
`Publisher’s permissions policies and our arrangement with organizations such as the Copyright Clearance Center
`and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions
`
`This book and the individual contributions contained in it are protected under copyright by the Publisher
`(other than as may be noted herein).
`
`Notices
`Knowledge and best practice in this field are constantly changing. As new research and experience broaden
`our understanding, changes in research methods, professional practices, or medical treatment may become
`necessary.
`
`Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using
`any information, methods, compounds, or experiments described herein. In using such information or methods
`they should be mindful of their own safety and the safety of others, including parties for whom they have
`a professional responsibility.
`
`To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability
`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
`A catalogue record for this book is available from the British Library
`
`Library of Congress Cataloging-in-Publication Data
`A catalog record for this book is available from the Library of Congress
`
`ISBN: 978-0-12-419985-9
`
`For information on all Academic Press publications
`visit our website at store.elsevier.com
`
`Printed and bound in the United Kingdom
`
`14 15 16 17
`
`10 9 8 7 6 5 4 3 2 1
`
`
`(iii)
`
`Petitioner's Exhibit 1007
`
`

`
`Access Procedures
`
`CHAPTER
`
`14
`
`The previous chapters have described the LTE uplink and downlink transmission schemes.
`However, prior to transmission of data, the terminal needs to connect to the network. This
`chapter describes the procedures necessary for a terminal to be able to access an LTE-based
`network.
`
`14.1 Acquisition and cell search
`Before an LTE terminal can communicate with an LTE network it has to do the following:
`
`(cid:129) Find and acquire synchronization to a cell within the network.
`(cid:129) Receive and decode the information, also referred to as the cell system information,
`needed to communicate with and operate properly within the cell.
`
`The first of these steps, often simply referred to as cell search, is discussed in this section.
`The next section then discusses, in more detail, the means by which the network provides the
`cell system information.
`Once the system information has been correctly decoded, the terminal can access the cell
`by means of the random-access procedure as described in Section 14.3.
`
`14.1.1 Overview of LTE cell search
`A terminal does not only need to carry out cell search at power-updthat is, when initially
`accessing the system. Rather, to support mobility, terminals need to continuously search for,
`synchronize to, and estimate the reception quality of neighboring cells. The reception quality
`of the neighboring cells, in relation to the reception quality of the current cell, is then
`evaluated to conclude if a handover (for terminals in RRC_CONNECTED) or cell reselection
`(for terminals in RRC_IDLE) should be carried out.
`LTE cell search consists of the following basic steps:
`
`(cid:129) Acquisition of frequency and symbol synchronization to a cell.
`(cid:129) Acquisition of frame timing of the celldthat is, determination of the start of the
`downlink frame.
`(cid:129) Determination of the physical-layer cell identity of the cell.
`
`4G: LTE/LTE-Advanced for Mobile Broadband. http://dx.doi.org/10.1016/B978-0-12-419985-9.00014-3
`Copyright Ó 2014 Erik Dahlman, Stefan Parkvall and Johan Sko¨ld. Published by Elsevier Ltd. All rights reserved.
`
`347
`
`Petitioner's Exhibit 1007
`
`

`
`348
`
`CHAPTER 14 Access Procedures
`
`As already mentioned, for example, in Chapter 10, there are 504 different physical-layer
`cell identities defined for LTE. The set of physical-layer cell identities is further divided into
`168 cell-identity groups, with three cell identities within each group.
`To assist the cell search, two special signals are transmitted on each downlink component
`carrier, the Primary Synchronization Signal (PSS) and the Secondary Synchronization Signal
`(SSS). Although having the same detailed structure, the time-domain positions of the syn-
`chronization signals within the frame differ somewhat depending on whether the cell is
`operating in FDD or TDD:
`
`(cid:129)
`
`(cid:129)
`
`In the case of FDD (upper part of Figure 14.1), the PSS is transmitted within the last
`symbol of the first slot of subframes 0 and 5, while the SSS is transmitted within the
`second to last symbol of the same slotdthat is, just prior to the PSS.
`In the case of TDD (lower part of Figure 14.1), the PSS is transmitted within the third
`symbol of subframes 1 and 6dthat is, within the DwPTSdwhile the SSS is transmitted
`in the last symbol of subframes 0 and 5dthat is, three symbols ahead of the PSS.
`
`It should be noted that the difference in PSS/SSS time-domain structure between FDD and
`TDD allows for the terminal to detect the duplex mode of the acquired carrier if this is not
`known in advance.
`Within one cell, the two PSSs within a frame are identical. Furthermore, the PSS of a cell
`can take three different values depending on the physical-layer cell identity of the cell. More
`specifically, the three cell identities within a cell-identity group always correspond to
`different PSS. Thus, once the terminal has detected and identified the PSS of the cell, it has
`found the following:
`
`(cid:129) Five-millisecond timing of the cell and thus also the position of the SSS which has a fixed
`offset relative to the PSS.1
`(cid:129) The cell identity within the cell-identity group. However, the terminal has not yet
`determined the cell-identity group itselfdthat is, the number of possible cell identities
`has been reduced from 504 to 168.
`
`Thus, from the SSS, the position of which is known once the PSS has been detected, the
`terminal should find the following:
`
`(cid:129) Frame timing (two different alternatives given the found position of the PSS).
`(cid:129) The cell-identity group (168 alternatives).
`
`Furthermore, it should be possible for a terminal to do this by the reception of one single
`SSS. The reason is that, for example, in the case when the terminal is searching for cells on
`other carriers, the search window may not be sufficiently large to cover more than one SSS.
`
`1This assumes that the terminal knows if it has acquired an FDD or a TDD carrier. Otherwise the terminal needs
`to try two different hypotheses regarding the SSS position relative to the PSS, thereby also indirectly detecting
`the duplex mode of the acquired carrier.
`
`Petitioner's Exhibit 1007
`
`

`
`14.1 Acquisition and cell search
`
`349
`
`0
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`One frame (10 ms)
`
`SSS
`
`PSS
`
`One frame (10 ms)
`
`0
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`FDD
`
`TDD
`
`FIGURE 14.1
`
`Time-domain positions of PSS and SSS in case of FDD and TDD
`
`SSS
`
`PSS
`
`To enable this, each SSS can take 168 different values corresponding to the 168 different
`cell-identity groups. Furthermore, the set of values valid for the two SSSs within a frame
`(SSS1 in subframe 0 and SSS2 in subframe 5) are different, implying that, from the detection
`of a single SSS, the terminal can determine whether SSS1 or SSS2 has been detected and thus
`determine frame timing.
`Once the terminal has acquired frame timing and the physical-layer cell identity, it has iden-
`tified the cell-specific reference signal. The behavior is slightly different depending on whether
`it is an initial cell search or cell search for the purpose of neighboring cell measurements:
`
`(cid:129)
`
`(cid:129)
`
`In the case of initial cell searchdthe terminal state is in RRC_IDLE modedthe
`reference signal will be used for channel estimation and subsequent decoding of the BCH
`transport channel to obtain the most basic set of system information.
`In the case of mobility measurementsdthe terminal is in RRC_CONNECTED modedthe
`terminal will measure the received power of the reference signal. If the measurement fulfills
`a configurable condition, it will trigger sending of a reference signal received power (RSRP)
`measurement report to the network. Based on the measurement report, the network will
`conclude whether a handover should take place. The RSRP reports can also be used for
`component carrier management,2 for example whether an additional component carrier
`should be configured or if the primary component carrier should be reconfigured.
`
`14.1.2 PSS structure
`On a more detailed level, the three PSSs are three length-63 Zadoff–Chu (ZC) sequences (see
`Section 11.2) extended with five zeros at the edges and mapped to the center 73 subcarriers
`
`2As discussed in Chapter 9, the specifications use the terms primary and secondary cells instead of primary and
`secondary component carriers.
`
`Petitioner's Exhibit 1007
`
`

`
`350
`
`CHAPTER 14 Access Procedures
`
`62 subcarriers (not including DC carrier)
`
`OFDM
`OFDM
`modulator
`
`
`Cyclic-prefixCyclic-prefix
`
`insertioninsertion
`
`72 subcarriers (not including DC carrier)
`
`0 0
`
`0 0
`
`Length 63
`
`Zadoff-Chu
`
`sequence
`
`Five zeros
`
`PSSX 0
`PSSX1
`
`PSSX 62
`
`Five zeros
`
`FIGURE 14.2
`
`Definition and structure of PSS
`
`SSS1 in
`
`Subframe 0
`
`SSS2 in
`
`Subframe 5
`
`OFDM
`OFDM
`modulator
`modulator
`
`
`Cyclic-prefixCyclic-prefix
`
`insertioninsertion
`
`62 subcarriers (not including DC carrier)
`
`72 subcarriers (not including DC carrier)
`
`0 0
`
`0 0
`
`PSSX1
`Sequence X
`
`Sequence Y
`
`0x
`1x
`
`30x
`
`0y
`1y
`
`30y
`
`FIGURE 14.3
`
`Definition and structure of SSS
`
`(center six resource blocks) as illustrated in Figure 14.2. It should be noted that the center
`subcarrier is actually not transmitted as it coincides with the DC subcarrier. Thus, only 62
`elements of the length-63 ZC sequences are actually transmitted (element XPSS
`is not
`32
`transmitted).
`The PSS thus occupies 72 resource elements (not including the DC carrier) in subframes
`0 and 5 (FDD) and subframes 1 and 6 (TDD). These resource elements are then not available
`for transmission of DL-SCH.
`
`14.1.3 SSS structure
`Similar to PSS, the SSS occupies the center 72 resource elements (not including the DC
`carrier) in subframes 0 and 5 (for both FDD and TDD). As described above, the SSS should be
`designed so that:
`
`(cid:129) The two SSSs (SSS1 in subframe 0 and SSS2 in subframe 5) take their values from sets of
`168 possible values corresponding to the 168 different cell-identity groups.
`(cid:129) The set of values applicable for SSS2 is different from the set of values applicable for
`SSS1 to allow for frame-timing detection from the reception of a single SSS.
`
`Petitioner's Exhibit 1007
`
`

`
`14.2 System information
`
`351
`
`The structure of the two SSSs is illustrated in Figure 14.3. SSS1 is based on the frequency
`interleaving of two length-31 m-sequences X and Y, each of which can take 31 different
`values (actually 31 different shifts of the same m-sequence). Within a cell, SSS2 is based on
`exactly the same two sequences as SSS1. However, the two sequences have been swapped in
`the frequency domain, as outlined in Figure 14.3. The set of valid combinations of X and Y
`for SSS1 has then been selected so that a swapping of the two sequences in the frequency
`domain is not a valid combination for SSS1. Thus, the above requirements are fulfilled:
`
`(cid:129) The set of valid combinations of X and Y for SSS1 (as well as for SSS2) are 168,
`allowing for detection of the physical-layer cell identity.
`(cid:129) As the sequences X and Y are swapped between SSS1 and SSS2, frame timing can be
`found.
`
`14.2 System information
`By means of the basic cell-search procedure described in Section 14.1, a terminal synchronizes
`to a cell, acquires the physical-layer identity of the cell, and detects the cell frame timing.
`Once this has been achieved, the terminal has to acquire the cell system information. This is
`information that is repeatedly broadcast by the network and which needs to be acquired by
`terminals in order for them to be able to access and, in general, operate properly within the
`network and within a specific cell. The system information includes, among other things,
`information about the downlink and uplink cell bandwidths, the uplink/downlink configura-
`tion in the case of TDD, detailed parameters related to random-access transmission, etc.
`In LTE, system information is delivered by two different mechanisms relying on two
`different transport channels:
`
`(cid:129) A limited amount of system information, corresponding to the so-called Master-
`Information Block (MIB), is transmitted using the BCH.
`(cid:129) The main part of the system information, corresponding to different so-called System-
`Information Blocks (SIBs), is transmitted using the downlink shared channel (DL-SCH).
`
`It should be noted that system information in both the MIB and the SIBs corresponds to the
`BCCH logical channel. Thus, as also illustrated in Figure 8.7, BCCH can be mapped to both
`BCH and DL-SCH depending on the exact BCCH information.
`
`14.2.1 Master information block and BCH transmission
`As mentioned above, the MIB transmitted using BCH consists of a very limited amount of
`system information, mainly such information that is absolutely needed for a terminal to be
`
`Petitioner's Exhibit 1007
`
`

`
`352
`
`CHAPTER 14 Access Procedures
`
`able to read the remaining system information provided using DL-SCH. More specifically,
`the MIB includes the following information:
`
`(cid:129)
`
`(cid:129)
`
`Information about the downlink cell bandwidth. Three bits are available within the MIB
`to indicate the downlink bandwidth. Thus, up to eight different bandwidths, measured in
`number of resource blocks, can be defined for each frequency band.
`Information about the PHICH configuration of the cell. As mentioned in Section 10.4.2,
`the terminal must know the PHICH configuration to be able to receive the L1/L2 control
`signaling on PDCCH. The PDCCH information, in turn, is needed to acquire the
`remaining part of the system information which is carried on the DL-SCH (see further
`below). Thus, information about the PHICH configuration (three bits) is included in the
`MIBdthat is, transmitted using BCH, which can be received and decoded without first
`receiving any PDCCH.
`(cid:129) The System Frame Number (SFN) or, more exactly, all bits except the two least
`significant bits of the SFN are included in the MIB. As described below, the terminal can
`indirectly acquire the two least significant bits of the SFN from the BCH decoding.
`
`BCH physical-layer processing, such as channel coding and resource mapping, differs
`quite substantially from the corresponding processing and mapping for DL-SCH outlined in
`Chapter 10.
`As can be seen in Figure 14.4, one BCH transport block, corresponding to the MIB, is
`transmitted every 40 ms. The BCH Transmissions Time Interval (TTI) thus equals 40 ms.
`The BCH relies on a 16-bit CRC, in contrast to a 24-bit CRC used for all other downlink
`transport channels. The reason for the shorter BCH CRC is to reduce the relative CRC
`overhead, having the very small BCH transport-block size in mind.
`BCH channel coding is based on the same rate-1/3 tail-biting convolutional code as is used
`for the PDCCH control channel. The reason for using convolutional coding for BCH, rather
`than the Turbo code used for all other transport channels, is the small size of the BCH
`transport block. With such small blocks, tail-biting convolutional coding actually out-
`performs Turbo coding. The channel coding is followed by rate matching, in practice repe-
`tition of the coded bits, and bit-level scrambling. QPSK modulation is then applied to the
`coded and scrambled BCH transport block.
`BCH multi-antenna transmission is limited to transmit diversitydthat is, SFBC in the case
`of two antenna ports and combined SFBC/FSTD in the case of four antenna ports. Actually, as
`mentioned in Chapter 10, if two antenna ports are available within the cell, SFBC must be
`used for BCH. Similarly, if four antenna ports are available, combined SFBC/FSTD must be
`used. Thus, by blindly detecting what transmit-diversity scheme is used for BCH, a terminal
`can indirectly determine the number of cell-specific antenna ports within the cell and also the
`transmit-diversity scheme used for the L1/L2 control signaling.
`As can also be seen from Figure 14.4, the coded BCH transport block is mapped to the
`first subframe of each frame in four consecutive frames. However, as can be seen in
`Figure 14.5 and in contrast to other downlink transport channels, the BCH is not mapped on
`
`Petitioner's Exhibit 1007
`
`

`
`14.2 System information
`
`353
`
`One BCH transport block
`
`Next BCH transport block
`
`
`
`CRC insertion CRC insertion
`
`16 bits CRC
`
`
`Channel codingChannel coding
`
`incl. rate matchingincl. rate matching
`
`R=1/3 tail-biting
`convolutiona code
`
`
`
`Scrambling Scrambling
`
`
`
`Modulation Modulation
`
`QPSK
`
`
`
`Antenna mapping SFBC / SFBC+FSTD Antenna mapping
`
`
`
`DemultiplexingDemultiplexing
`
`frame 4×k
`
`frame 4×k+1
`
`frame 4×k+2
`
`frame 4×k+3
`
`frame 4×(k+1)
`
`FIGURE 14.4
`
`40 ms
`
`Channel coding and subframe mapping for the BCH transport channel
`
`a resource-block basis. Instead, the BCH is transmitted within the first four OFDM symbols of
`the second slot of subframe 0 and only over the 72 center subcarriers.3 Thus, in the case of
`FDD, BCH follows immediately after the PSS and SSS in subframe 0. The corresponding
`resource elements are then not available for DL-SCH transmission.
`The reason for limiting the BCH transmission to the 72 center subcarriers, regardless of
`the cell bandwidth, is that a terminal may not know the downlink cell bandwidth when
`receiving BCH. Thus, when first receiving BCH of a cell, the terminal can assume a cell
`bandwidth equal to the minimum possible downlink bandwidthdthat is, six resource blocks
`corresponding to 72 subcarriers. From the decoded MIB, the terminal is then informed about
`the actual downlink cell bandwidth and can adjust the receiver bandwidth accordingly.
`The total number of resource elements to which the coded BCH is mapped is very large
`compared to the size of the BCH transport block, implying extensive repetition coding or,
`equivalently, massive processing gain for the BCH transmission. Such large processing gain
`is needed as it should be possible to receive and correctly decode the BCH also by terminals
`in neighboring cells, implying potentially very low receiver Signal-to-Interference-and-Noise
`
`3Not including the DC carrier.
`
`Petitioner's Exhibit 1007
`
`

`
`354
`
`CHAPTER 14 Access Procedures
`
`One BCH transport block
`
`One frame (10 ms)
`
`BCH
`
`7 2 ce nter su b-carriers
`
`1st slot
`
`2nd slot
`
`FIGURE 14.5
`
`Detailed resource mapping for the BCH transport channel
`
`Ratio (SINR) when decoding the BCH. At the same time, many terminals will receive BCH in
`much better channel conditions. Such terminals then do not need to receive the full set of four
`subframes over which a BCH transport block is transmitted to acquire sufficient energy for
`correct decoding of the transport block. Instead, already by receiving only a few or perhaps
`only a single subframe, the BCH transport block may be decodable.
`From the initial cell search, the terminal has found only the cell frame timing. Thus, when
`receiving BCH, the terminal does not know to what set of four subframes a certain BCH
`transport block is mapped. Instead, a terminal must try to decode the BCH at four possible
`timing positions. Depending on which decoding is successful, indicated by a correct CRC
`check, the terminal can implicitly determine 40 ms timing or, equivalently, the two least
`significant bits of the SFN.4 This is the reason why these bits do not need to be explicitly
`included in the MIB.
`
`14.2.2 System-information blocks
`As already mentioned, the MIB on the BCH only includes a very limited part of the
`system information. The main part of the system information is instead included in different
`System-Information Blocks (SIBs) that are transmitted using the DL-SCH. The presence of
`
`4BCH scrambling is defined with 40 ms periodicity, hence even if the terminal successfully decodes the BCH
`after observing only a single transmission instant, it can determine the 40 ms timing.
`
`Petitioner's Exhibit 1007
`
`

`
`14.2 System information
`
`355
`
`system information on DL-SCH in a subframe is indicated by the transmission of a corre-
`sponding PDCCH marked with a special System-Information RNTI (SI-RNTI). Similar to the
`PDCCH providing the scheduling assignment for “normal” DL-SCH transmission, this
`PDCCH also indicates the transport format and physical resource (set of resource blocks)
`used for the system-information transmission.
`LTE defines a number of different SIBs characterized by the type of information that is
`included within them:
`
`(cid:129) SIB1 includes information mainly related to whether a terminal is allowed to camp on the
`cell. This includes information about the operator/operators of the cell, if there are
`restrictions with regards to what users may access the cell, etc. SIB1 also includes
`information about the allocation of subframes to uplink/downlink and configuration of
`the special subframe in the case of TDD. Finally, SIB1 includes information about the
`time-domain scheduling of the remaining SIBs (SIB2 and beyond).
`(cid:129) SIB2 includes information that terminals need in order to be able to access the cell. This
`includes information about the uplink cell bandwidth, random-access parameters, and
`parameters related to uplink power control.
`(cid:129) SIB3 mainly includes information related to cell reselection.
`(cid:129) SIB4–SIB8 include neighboring-cell-related information, including information related
`to neighboring cells on the same carrier, neighboring cells on different carriers, and
`neighboring non-LTE cells, such as WCDMA/HSPA, GSM, and CDMA2000 cells.
`(cid:129) SIB9 contains the name of the home-eNodeB.
`(cid:129) SIB10–SIB12 contain public warning messages, for example earthquake information.
`(cid:129) SIB13 contains information necessary for MBMS reception (see also Chapter 17).
`(cid:129) SIB14 is used to provide enhanced access barring information, controlling the
`possibilities for terminals to access the cell.
`(cid:129) SIB15 contains information necessary for MBMS reception on neighboring carrier
`frequencies.
`(cid:129) SIB16 contains information related to GPS time and Coordinated Universal Time (UTC).
`
`Not all the SIBs need to be present. For example, SIB9 is not relevant for an operator-
`deployed node and SIB13 is not necessary if MBMS is not provided in the cell.
`Similar to the MIB, the SIBs are broadcasted repeatedly. How often a certain SIB needs to
`be transmitted depends on how quickly terminals need to acquire the corresponding system
`information when entering the cell. In general, a lower-order SIB is more time critical and is
`thus transmitted more often compared to a higher-order SIB. SIB1 is transmitted every 80 ms,
`whereas the transmission period for the higher-order SIBs is flexible and can be different for
`different networks.
`
`Petitioner's Exhibit 1007
`
`

`
`356
`
`CHAPTER 14 Access Procedures
`
`The SIBs represent the basic system information to be transmitted. The different SIBs are
`then mapped to different System-Information messages (SIs), which correspond to the actual
`transport blocks to be transmitted on DL-SCH. SIB1 is always mapped, by itself, on to the
`first system-information message SI-1,5 whereas the remaining SIBs may be group-wise
`multiplexed on to the same SI subject to the following constraints:
`
`(cid:129) The SIBs mapped to the same SI must have the same transmission period. Thus, as an
`example, two SIBs with a transmission period of 320 ms can be mapped to the same SI,
`whereas an SIB with a transmission period of 160 ms must be mapped to a different SI.
`(cid:129) The total number of information bits that is mapped to a single SI must not exceed what
`is possible to transmit within a transport block.
`
`It should be noted that the transmission period for a given SIB might be different in
`different networks. For example, different operators may have different requirements
`concerning the period when different types of neighboring-cell information needs to be
`transmitted. Furthermore, the amount of information that can fit into a single transport
`block very much depends on the exact deployment situation, such as cell bandwidth, cell
`size, and so on.
`Thus, in general, the SIB-to-SI mapping for SIBs beyond SIB1 is flexible and may be
`different for different networks or even within a network. An example of SIB-to-SI mapping
`is illustrated in Figure 14.6. In this case, SIB2 is mapped to SI-2 with a transmission period of
`160 ms. SIB3 and SIB4 are multiplexed into SI-3 with a transmission period of 320 ms,
`whereas SIB5, which also requires a transmission period of 320 ms, is mapped to a separate
`SI (SI-4). Finally, SIB6, SIB7, and SIB8 are multiplexed into SI-5 with a transmission period
`of 640 ms. Information about the detailed SIB-to-SI mapping, as well as the transmission
`period of the different SIs, is provided in SIB1.
`Regarding the more detailed transmission of the different system-information messages,
`there is a difference between the transmission of SI-1, corresponding to SIB1, and the
`transmission of the remaining SIs.
`
`SIB1
`
`SIB2
`
`SIB3
`
`SIB4
`
`SIB5
`
`SIB6
`
`SIB7
`
`SIB8
`
`SI-1
`
`SI-2
`
`SI-3
`
`SI-4
`
`Period:
`
`sm08
`
`160 ms
`
`sm023
`
`320 ms
`
`SI-5
`
`640 ms
`
`FIGURE 14.6
`
`Example of mapping of SIBs to SIs
`
`5Strictly speaking, as SIB1 is not multiplexed with any other SIBs, it is not even said to be mapped to an SI.
`Rather, SIB1 in itself directly corresponds to the transport block.
`
`Petitioner's Exhibit 1007
`
`

`
`14.2 System information
`
`357
`
`The transmission of SI-1 has only a limited flexibility. More specifically, SI-1 is always
`transmitted within subframe 5. However, the bandwidth or, in general, the set of resource
`blocks over which SI-1 is transmitted, as well as other aspects of the transport format, may
`vary and is signaled on the associated PDCCH.
`For the remaining SIs, the scheduling on DL-SCH is more flexible in the sense that each SI
`can, in principle, be transmitted in any subframe within time windows with well-defined
`starting points and durations. The starting point and duration of the time window of each
`SI are provided in SIB-1. It should be noted that an SI does not need to be transmitted on
`consecutive subframes within the time window, as is illustrated in Figure 14.7. Within the
`time window, the presence of system information in a subframe is indicated by the SI-RNTI
`on PDCCH, which also provides the frequency-domain scheduling as well as other param-
`eters related to the system-information transmission.
`Different SIs have different non-overlapping time windows. Thus, a terminal knows what
`SI is being received without the need for any specific identifier for each SI.
`In case of a relatively small SI and a relatively large system bandwidth, a single 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 complete 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 to decode the complete SI after receiving only a subset of the subframes to
`which the coded SI is mapped, while terminals in bad positions need to receive more sub-
`frames for proper decoding of the SI. This approach has two benefits:
`
`(cid:129) Similar to BCH decoding, terminals in good positions need to receive fewer subframes,
`implying the possibility for reduced terminal power consumption.
`(cid:129) The use of larger code blocks in combination with Turbo coding leads to improved
`channel-coding gain.
`
`Strictly speaking the single transport block containing the SI is not transmitted over
`multiple subframes. Rather,
`the subsequent SI transmissions are seen as autonomous
`
`Start of transmission window
`
`Duration of transmission window
`
`Repetition period, e.g 160 ms
`
`FIGURE 14.7
`
`Transmission window for the transmission of an SI
`
`Petitioner's Exhibit 1007
`
`

`
`358
`
`CHAPTER 14 Access Procedures
`
`hybrid-ARQ retransmissions of the first SI transmissiondthat is, retransmissions taking place
`without any explicit feedback signaling provided on the uplink.
`For terminals capable of carrier aggregation, the system information for the primary
`component carrier is obtained as described above. For secondary component carriers, the
`terminal does not need to read the system-information blocks but assumes that the infor-
`mation obtained for the primary component carrier also holds for the secondary component
`carriers. System information specific for the secondary component carrier is provided through
`dedicated RRC signaling as part of the procedure to configure an additional secondary
`component carrier. Using dedicated signaling instead of reading the system information on
`the secondary component carrier enables faster activation of secondary component carriers as
`the terminal otherwise would have to wait until the relevant system information had been
`transmitted.
`
`14.3 Random access
`A fundamental requirement for any cellular system is the possibility for the terminal to
`request a connection setup, commonly referred to as random access. In LTE, random access is
`used for several purposes, including:
`
`(cid:129)
`
`(cid:129)
`(cid:129)
`(cid:129)
`
`(cid:129)
`
`(cid:129)
`
`for initial access when establishing a radio link (moving from RRC_IDLE to
`RRC_CONNECTED; see Chapter 8 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;
`for the purpose of positioning using positioning methods based on uplink
`measurements;
`as a scheduling request if no dedicated scheduling-request resources have been
`configured on PUCCH (see Chapter 13 for a discussion on uplink scheduling
`procedures).
`
`Acquisition of uplink timing is a main objective for all the cases above; when establishing
`an initial radio link (that is, when moving from RRC_IDLE to RRC_CONNECTED), the
`random-access procedure also serves the purpose of assigning a unique identity, the C-RNTI,
`to the terminal.
`Either a contention-based or a contention-free scheme can be used, depending on the
`purpose. Contention-based random access can be used for all previously discussed purposes,
`while contention-free random access can only be used for re-establishing uplink synchro-
`nization upon downlink data arrival, uplink synchronization of secondary component carriers,
`
`Petitioner's Exhibit 1007
`
`

`
`14.3 Random access
`
`359
`
`Terminal
`
`Synchronize to
`downlink timing
`(from cell search)
`
`eNodeB
`
`Core Network
`
`Step 1 - random-access preamble
`
`Step 2 - random-access response
`
`Adjust uplink timing
`
`Step 3 - RRC signaling
`
`Only if UE is not known in eNodeB
`
`(initial random access)
`
`Step 4 - RRC signaling
`
`user data
`
`FIGURE 14.8
`
`Overview of the random-access procedure
`
`handover, and positioning. The basis for the random access is the four-step procedure
`illustrated in Figure 14.8, with the following