`
`
`
`R2-071911
` (Update of R2-071377)
`
`
`
`
`
`
`
`
`
`
`
`
`
`3GPP TSG-RAN WG2 Meeting #58
`
`Kobe, Japan, 7th-11th May 2007
`Agenda item:
`4.5
`Title:
`System information structure (with TP)
`Source:
`Samsung
`Document for: Discussion and decision
`
`
`
`
`
`
`
`
`
`
`
`1. Introduction
`In this paper we have categorised the most time critical system information, considering the main mobility
`scenarios. This analysis is performed to assist concluding the required BCH periodicity. Furtheremore, based
`on that conclusion, a proposal is included regarding the organisation of the concerned system information
`i.e. what information to divide over separate SIBs.
`
`2. Discussion
`
`2.1 Recap of current status and main BCH structuring criteria
`During the RAN2#57 meeting it was agreed that:
`
` BCCH can be mapped to BCH (often referred to as P-BCH) and to DL-SCH (sometimes referred to as D-
`BCH), while the need for mapping to an S-BCH is FFS
`
` Scheduling information (starting times) is provided for a group SIBs having the same scheduling
`requirements, also referred to as a Scheduling Unit (SU). BCH includes the scheduling information of the
`the most frequently repeated Scheduling Unit (SU-1)
`
` The high level contents of BCH and SU-1 have been identified
`Before summarising the content of BCH and SU-1, we would like to highlight the rationale for including
`information within BCH, SU-1 or a less frequently transmitted SU. Concerning this rationale, our assumptions
`are as follows:
`BCH should include the following type of information:
`
` All parameter necessary to perform handover (i.e. step 1 & 2 in sec. 5.1 )including the parameters
`needed to access the target cell, exept for the parameters that may be provided via dedicated signalling
`e.g. aRACH configuration
`
` All parameters needed to measure and rank cell re-selection candidates (i.e. step 1 in sec. 6.1)
`SU-1 should include the following type of information:
`
` All parameters needed to validate accessibility of the cell re-selection target (i.e. step 2 in sec. 6.1)
`Our assumption is that the other mobility related parameters e.g. common channel configuration information
`(i.e. related to the cell re-selection step 3 in 5.1) may be included in other SUs, scheduled less frequently.
`The following section provides further details on the actual information elements
`
`1
`
`APPLE 1012
`
`

`

`
`
`
`
`2.2 Further analysis of BCH contents and periodicity
`This section summarises our progress in the discussion regarding the transmission requirements for system
`information.
`A. What is needed to measure a neighbouring cell (Cell re-selection)
`
`In summary: To measure neighbouring cells with sufficient performance, it is most important that the UE
`knows the system bandwidth i.e. from a measurement performance perspective it less essential for the UE to
`also know the antenna and the control channel configuration
` Cell identity: Our assumption is that the SCH- based identity needs to be locally unique, since it
`determines the scrambling code and the hopping pattern i.e. if two nearby cells use the same SCH
`based cell id and by accident are time-aligned it will be impossible to measure these cells. In other
`words: from a measurement cell identification perspective, an additional cell identity on BCH is useless
` Cell bandwidth: In our opinion this is the most important parameter from a measurement performance
`perspective. Our assumption is that it should be provided.
` Antenna configuration: RAN1 has not concluded whether the antenna configuration will be signalled via
`SCH. This parameter could improve the measurement performance, but this is not considered essential
`provided that the system bandwidth is known. (Our preference is to not signal this via SCH either, since
`that would increase cell search complexity)
` Control channel configuration (i.e. MBSFN and Ext. CP usage): Our assumption is that when the system
`bandwith is indicated, measurement of the first OFDM symbol may provide sufficient performance.
`Hence, our assumption is that this information is not essential
` RS power boosting: Different cells may apply a different power boosting for the RS. Consequently, if the
`UE is not informed about the power boosting it may select an incorrect cell.
`
`
`B. What is needed to rank a neighbouring cell (Cell re-selection)
`
`In summary: To rank neighbouring cells, the UE needs to know the Qoffset and the Suitability parameters i.e.
`the LTE equivalents of Qqualmin(Ec/No), Qrxlevmin (RSCP) and Maximum allowed UL TX). Only for the for
`the Qoffset parameter it is common to use cell specific values (intra-frequency only)
` Suitability: UTRA includes suitability related parameters i.e. Qqualmin(Ec/No), Qrxlevmin (RSCP) and
`Maximum allowed UL TX power. In general it seems unlikely that a cell that ranks higher than the current
`cell is not suitable. If however a Qoffset applies stimulating re-selection, this may not always be the case.
`Some operators indicated that the suitability parameters are typically common for all neighbouring cells
` Qoffset: There seems consensus that this parameter needs to be provided and that it is common to use
`different values for different intra-frequency neighbouring cells (RAN2 agreed that there is no need for
`cell specific offset for interfrequency neighbours)
`
`
`C. What is needed to report measurements (handover)
`
`In summary: Our assumption is that the UE needs to read the Offset of neighbouring cells for measurement
`reporting (i.e. change of best cell)
` Qoffset: Our assumption is that the UE needs to acquire the Qoffset of neighbouring cells to be able to
`report certain measurement events (in particular: change of best cell)
`
`
`D. What is needed to perform initial access (handover)
`
`In summary: Our assumption is all RACH related information, including UL interference, is provided via
`dedicated signalling, implying that the UE need not know the SFN of the target cell
` System Frame Number (SFN): Firstly, we assume than a RACH will be configured in every radio frame,
`so the UE does not need the SFN to determine in which frame RACH is included. Furthermore, we have
`not identified a clear need to apply frequency hopping for RACH. Hence, our assumption is that the UE
`does not need to acquire the SFN of the target cell before performing initial access.
`o According to our earlier load calculations (R2-070206), for a cell with 10MHz bandwith 6
`aRACHs would be needed to achieve a collision probability of 0.5% when using 1 info bit and
`using dedicated signatures for handover. This would translate to 0.75 aRACH for a cell with 1.25
`MHZ bandwith. If we tolerate higher collision probabilities e.g. 1%, the aRACH would be
`overdimensioned considerably. However, our assumption is that the aRACH resources can be
`utilised for other purposes (UL-SCH transmission) i.e. there is no real drawback in having an
`aRACH in every radio frame
`
`2
`
`

`

`
`
`
`
`
`
`Review of previous results
`
`In summary: At present, Qoffset is the prime candidate parameter for BCH. Further analysis shows that from
`a signalling overhead perspective BCH hardly ever ‘beats’ the serving’s NCL. Simplied configuration remains
`as (only) argument for the BCH. Further analysis shows that for the Qoffset parameter, acquisition delays are
`not that critical assuming that the UE needs at least 2 measurements sufficiently apart in time (320ms in
`UTRA)
`In the above, we identified that primarily the following parameters need to be available:
`
`o System bandwidth, often common for the neighbours
`o Qoffset, often different for the intra-frequency neighbours only
`o Suitability, often common for the neighbours
` RAN2 discussed the principle that parameters that are often different should be carried on (P-)BCH
`(approach A) while parameters that are hardly ever different (say only in 5% of the cases) should be in
`the neighbour list of the serving cell (approach B). Accordingly, Qoffset is the only candidate for (P-
`)BCH. The analysis in the intermezzo below however shows that from a signalling perspective BCH
`hardly ever ‘beats’ the serving’s NCL. The simplied configuration that applies for the neighbours BCH is
`assumed to be a somewhat less important factor
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Intermezzo: Overhead comparison between target’s BCH and serving’s neighbour list (NCL)
`
`Assumptions
` Serving’s neighbour list
`o The neighbouring cell info is provided on D-BCH, say every 320- 640ms
`o The info is provided in several neighbours of the target cell, say 12
`o There is additional overhead because the cell identity (9b) needs to be provided
` Target cell’s BCH
`o The information is provided on BCH, say every 10- 20ms
`
`
`Example: Single parameter of 4 bits
` Considering overhead of cell identity
`o Serving’s neighbour list: (4b + 9b) x 12 every 640ms = 0.24 kbps
`o Target cell’s BCH: 4b every 20 ms= 0.20 kbps
` Not considering overhead of cell identity (If there are several parameters, relative overhead of
`this reduces):
`o Serving’s neighbour list: (4b) x 12 every 640ms = 0.07 kbps
`
`
`Final remarks:
` The BCH may include parameters relevant for mobility and parameters not relevant for mobility
`i.e. with somewhat less stringent delay requirements. In such a case, all parameters need to be
`considered in the overhead comparison since adding the mobility parameters to BCH also
`causes the non mobility parameters to be transmitted more frequently
` Altogether, the analysis shows that BCH hardly ever ‘beats’ the serving’s NCL from a signalling
`overhead perspective
`
`Formatted: Font: (Default) Arial, Italic, (Asian) Japanese
`
` 
`
` Urgency Qoffset: It should be possible to read BCH of intra-frequency neighbouring cells prior to the
`actual re-selection. The ranking of a newly detected cell can only be performed when the Qoffset
`parameter is known. If this parameter is transmitted every 80ms on BCH, it takes on average 40ms for
`the UE to acquire this information. Cell re-selection is normally based on at least 2 measurements that
`are at least a certain amount of time apart (i.e. 320ms for the lower DRX values in UTRA, see 25.133
`Table 4.1). Hence, provided BCH is not scheduled too infrequently, it should be possible to acquire the
`Qoffset parameter prior to the 2nd measurement (i.e. not introducing any re-selection delay). Our
`assumption is that UEs in connected mode also have to acquire the Qoffset from every detected intra-
`frequency neighbouring cell (e.g. to be able to report change of best cell correctly). However, for
`connected mode similar considerations apply
` Reading of BCH from multiple cells: As mentioned before, in case BCH is transmitted every 80ms on
`BCH it takes on average 40ms for the UE to acquire this information. The question is if this acquisition
`
`3
`
`

`

`
`
`
`
`delay also applies in case multiple neighbouring cells need to be read simultaneously. One could
`consider that the UE buffers the information received from different cells and then process the
`information sequentially. In such an implementation scheme, the average delay will not be much higher
`than 40ms in case of 80ms BCH repetition. We have not concluded if this type of implementation is really
`feasible. Especially when cells are not synchronised wrt. BCH transmission, the buffer requirements may
`be excessive. Hence, we are uncertain whether the average delay of 40ms applies in this case
` Scheduling info: If BCH is scheduled every 80ms, the UE will have to read BCH for 80ms before ‘finding’
`it. To reduce UE battery consumption, one could consider providing every 10ms an indication of when
`BCH will be scheduled. This may reduce the average active time with a factor of ~2 (from 4 to 2 frames).
`o A rather rough analysis shows that the BCH reading involves a comparable power consumption
`as used for neighbouring cell measurement i.e. power consumption seems an issue
`
`If the UE measures neighbouring cells once every 1s and re-selects on average once
`per 20s, it measures 20 times while it measures BCH once. If the UE is active 2ms for
`every measurement, both are comparable.
`
`
`Towards a conclusions/ recommendations regarding BCH periodicity
`
`In summary: Our assumption is that the Qoffset parameter of may be rather cell specific. Our analysis shows
`that the only argument for using the BCH to transmit such a parameter is simplified eNB configuration. On
`the other hand, the BCH transmission seems to complicate UE implementation and/ or reduce battery
`lifetime. RAN2 is requested to take these considerations into account when concluding the discussion on
`BCH periodicity and structure.
`
`2.3 Overview of time critical system information
`The following table provides an overview of the most time critical system information. The table showns for
`each type of information the expected periodicity, the assumed contents and an estimate of the expected
`size.
`
`Contents
`Physical layer parameters
` Bandwidth: 3b i.e. (1.25, 2.5, 5, 10, 15, 20)
` Antenna configuration (FFS)
` Control channel configuration (FFS)
` RS power boosting (FFS)
`Primary scheduling information i.e. for the
`urgent system information
`
`System frame number
`SFN (FFS)
`
`Cell measurement and ranking information
`Offset or Cell class/ (5b)
`
`eNB Tx power (5b)
`Cell access related information
`PLMN identity, TA identity, cell identity* (54-
`58b, 22- 24b for every additional PLMN identity)
`Cell barring status (4- 105b)
`Secondary scheduling information i.e. for
`other system information
`(6b MSB of the common OFF, for 5 SUs a 4 bit
`REP and a 2b Value Tag)
`
`Where Size
`
`Comment
`
`BCH
`
`~3b
`
`
`
`
`
`
`
`
`
`10b
`
`12b
`
`
`10b
`
`SU-1
`
`~64-
`290b
`
`SU-1
`
`~36b
`
`Size estimate assumes 6b LSB of the
`common OFF, a 4 bit REP for SU-1.
`For further details, see [1]
`Needed for aRACH access
`(frequency hopping) i.e. handover
`step 3 (HO execution). Alternative
`transmission methods may be
`possible
`
`Needed for every measured cell
`ranking (i.e. cell re-selection step 1)
`Needed to determine pathloss
`Needed for best cell on the
`frequency, to verify accessibility
`As in UMTS
`1- 17b per up to 6 multiple PLMNs
`Needed to verify if a change has
`occured upon return from temporary
`OOS (mainly for the common
`channel configuration)
`
`4
`
`

`

`
`
`
`
`SU-2
`
`~500b
`
`Needed upon actual cell re-selection
`(i.e. step 3).
`For HO this information is provided
`via dedicated signalling
`
`SU-2
`
`~1000b Needed to start UE mobility
`measurements
`
`General configuration parameters for
`common and shared channels
`aRACH configuration info (e.g. PRB allocation,
`power ramping, ‘AICH’ PRB allocation)
`General UL-SCH & DL-SCH configuration
`parameters (as well as about the associated
`control channels)
`Configuration of common channels: PCCH,
`MCCH, full BCCH (i.e. Dyanamic BCH) all of
`which may be mapped on DL-SCCH
`Difficult to estimate at present. Expected to be
`less than in UMTS (4 segments as default i.e.
`~900b)
`Neighbouring cell measurement information
`InterF neighbours
`Inter RAT neighbours (UMTS, GSM)
`i.e. ID, neighbour list, quantity and reporting
`criteria
`Difficult to estimate but assumed to be less than
`in UMTS (up to 32 segments or 7kb with
`SIB11ext)
`
`Tab. 1 Time critical system information, allocation and estimated size
`The above table is mainly provided for reference, considering that the discussions on the system information
`transmission scheme have not entirely concluded. TS 36.300 already provides a description of the contents
`of BCH and SU that is largely in line with the above table.
`
`2.4 Further proposals on use of messages (SIBs)
`In case RAN2 concludes a BCH repetion rate lower than 80s, we propose to conclude that:
`
` There is no need for an S-BCH
`
` The current BCH organisation with a BCH and an SU-1 is beneficial and should remain
`In this case, our proposal is to add some further detail about the organisation of this information. In
`accordance with our previous paper, our proposal is to introduce separate SIB messages for information for
`which it is beneficial for the UE to act even if other information in the same SU has not yet been received.
`Accordingly, our proposal is as follows:
`To introduce a ‘Master Information Block’ message containing the Primary physical layer parameters,
`Primary scheduling information, System frame number and Cell measurement and ranking information i.e.
`the information with periodicity 1 in the above table (aligning with UTRA)
`To introduce a ‘Scheduling Block’ message, containing the Secondary scheduling information
`To introduce a ‘System Information Block 1’ message, containing the Cell access related information
`To introduce a ‘System Information Block 2’ message, containing the Common and shared channel
`configuration information
`To introduce one or more ‘System Information Block n’ message(s), containing the Neighbouring cell
`measurement information
`
` Whether or not to use multiple messages e.g. separate for inter-frequency and inter-RAT neighbours,
`should be decided after the discussions regarding the neighbouring cell lists has concluded.
`The actual numbering of this SIB may be left open for the moment, i.e. to allow for alignement with UTRA
`where possible. The proposal is illustrated in the following figure, that also shows how the system information
`is scheduled when assuming concentrated transmission.
`
`5
`
`

`

`
`
`
`
`SU-1
`
`SIB-1
`
`SB
`
`SU-2
`
`
`
`SIB-3 SIB-n
`
`SIB-2
`
`subframe
`
`(P-)BCH
`
`MIB
`
`DL-SCH (D-BCH)
`
`SU-3
`
`
`
`SIB-x
`
`
`
`SIB-y
`
`
`
`Multi-frame/
`scheduling period
`
`RF
`67
`19
`0
`3
`Fig. 1 System information structure and typical scheduling example
`A text proposal is attached aiming to capture the above proposals in the stage 2 specification.
`In case RAN2 decides to adopt a BCH repetion rate of 80s, we propose to conclude that:
`
` The current BCH organisation with a BCH and an SU-1 is changed i.e. the contents of the SU-1 is
`moved to BCH
`
` There is no need for an S-BCH
`In this case a more extensive change will be needed, that we will be happy to draft along the lines of the
`what is sketched in the above.
`
`
`
`131
`
`3. Conclusion & recommendation
`In this contribution we have provided an overview of the time critical system information. For reference we
`have provided the expected periodicity and size of the different information in this contribution. Our analysis
`lead us to the following conclusions/ recommendations:
`
`1) Our analysis shows that the only argument for using the BCH to transmit such a parameter is simplified
`eNB configuration. On the other hand, the BCH transmission seems to complicate UE implementation
`and/ or reduce battery lifetime. RAN2 is requested to take these considerations into account when
`concluding the discussion on BCH periodicity and structure
`In case RAN2 decides to adopt a BCH repetition period lower than 80ms, we propose to also conclude
`that:
`a) The current BCH organisation with a BCH and an SU-1 is beneficial and should remain
`b) There is no need for an S-BCH
`
`2)
`
`3)
`
`In case RAN2 decides to adopt a BCH repetition period of 80ms, we propose to also conclude that:
`a) The current BCH organisation with a BCH and an SU-1 is changed i.e. the contents of the SU-1 is
`moved to BCH
`b) There is no need for an S-BCH
`Furthermore, this document includes some additional proposals regarding the system information blocks i.e.:
`4) To introduce a MIB to refer to the information provided on BCH
`5) To introduce a Scheduling Block
`
`6
`
`

`

`
`
`
`
`6) To introduce separate SIBs for Cell access related information, for Common and shared channel
`configuration information and one or more SIBs for the Neighbouring cell measurement information.
`We request RAN2 to consider the above proposal, and if agreeable, to reflect this in the E-UTRA
`specifications. We also request RAN2 to take into account the estimated system information contents, size
`and repetition rates when designing the system information procedures and messages.
`
`4. References
`[1] R2-070168 Scheduling and organisation of flexible system information (Samsung)
`[2] R2-063412 P-BCH Scheduling ( Motorola)
`[3] R2-070399: (R1-070606, to RAN2). Reply LS (to R2-063657) on Primary BCH Transmission
`
`7
`
`

`

`
`
`5. Text proposal
`
`
`
`System Information
`7.4
`Scheduling information (indicating starting times) is provided for a group of system information blocks (SIBs) that have
`the same scheduling requirements (i.e. periodicity). Such a group of SIBs is referred to as a Scheduling Unit (SU). An
`SU may cover multiple subframes. It is expected that typically 3 or 4 SUs will be used. The mapping of SIBs on to SUs
`may be configurable (FFS).
`
`NOTE
`
`The possibility to schedule segments of an SU into non-contiguous subframes (e.g. for very large SIBs
`without strong delay requirements) is FFS.
`
`The system information carried on the BCH is contained in a Master Information Block, which includes the following:
`
`- Physical layer parameters (e.g. bandwidth);
`
`- System Frame Number (SFN, unless provided otherwise);
`
`- Scheduling information of the most frequently repeated Scheduling Unit (SU-1);
`
`- Value tag(s) (FFS).
`
`The most frequently repeated Scheduling Unit (SU-1) contains a System Information Block type 1 (SIB-1) that
`includes the following system information:- One or more PLMN identities;
`
`- Tracking Area Code;
`
`- Cell identity;
`
`- Cell barring status;
`
`SIB-1 should include all access restriction related parameters. SU-1 also contains a Scheduling Block that includes the
`following system information:
`
`- Scheduling information of the other Scheduling Units (other than SU-1);
`
`- SIB mapping information i.e. indication in which SU the SIBs is included (FFS).
`
`SU-1 is carried on the DL-SCH, unless the BCH is extended. In the latter case, S-BCH may carry (part of) the SU-1
`information.
`
`SU-2 is repeated less frequently than SU-1 and contains SIB 2, which includes the following information:
`
`- Common channel configuration parameters e.g. for aRACH, for logical channels mapped to DL-SCH (PCCH,
`MCCH, BCCH)
`
`- Shared channel configuration parameters i.e. for UL-SCH, DL-SCH as well as about the associated control
`channels
`
`SU-2 also contains SIB n, that includes the following system information:
`
`- Information related to the measurement of intra-frequency, inter-frequency and inter-RAT neighbouring cells
`
`The following figure illustrates System information structure and also shows typical example of how the BCCH
`mapped to DL-SCH may be scheduled.
`
`8
`
`

`

`
`
`
`
`SU-1
`
`SIB-1
`
`SB
`
`SU-2
`
`
`
`SIB-3 SIB-n
`
`SIB-2
`
`subframe
`
`(P-)BCH
`
`MIB
`
`DL-SCH (D-BCH)
`
`SU-3
`
`
`
`SIB-x
`
`
`
`SIB-y
`
`
`
`Multi-frame/
`scheduling period
`
`RF
`67
`19
`0
`3
`Fig. x System information structure and typical scheduling example
`System information may also be provided to the UE by means of dedicated signalling e.g. upon handover.
`
`
`
`131
`
`9
`
`

`

`
`
`
`
`6. Background information
`
`6.1 UE mobility procedures steps
`Handover
`Handover is considered to be the scenario with the most stringent delay requirements. Handover can be
`considered to include two steps, requiring different information about the candidate/ target cell:
`
` Step 1: Measurement reporting of the candidate cell
`o A locally unique cell identity, to include in the measurement report. The ‘Measurement cell
`identification’ that is derived from SCH is assumed to be sufficient in most scenarios
`o eNB transmit power, needed when reporting pathloss (FFS)
` Step 2: Initial access in the target cell and transmission of the handover complete message (TBC),
`possibly followed by further signalling e.g. transmission of status report, updating of measurement
`configuration
`o SFN, needed for aRACH access (frequency hopping) and in case of synchronous handover
`o aRACH configuration info (e.g. PRB allocation, power ramping, ‘AICH’ PRB allocation), needed
`for the initial access [Possibly full configuration, if fallback to aRACH-cs is used]
`o General UL-SCH & DL-SCH configuration info including associated control channels, possibly
`required for further signalling e.g. handover complete and the subsequent data transfer
`Step 1 is considered most critical, since it also applies more often i.e. not every report is assumed to result in
`an actual handover is performed. In a later section, there is further discussion about the cell identification and
`about the possible use of dedicated signalling for the aRACH and UL/ DL-SCH configuration information.
`Cell reselection
`
`Cell re-selection is assumed to have less stringent requirements, since the UE is not actively transmitting.
`The main issue is to limit/ avoid inabilities w.r.t. receiving paging and w.r.t. initiating connection
`establishment. Cell re-selection can be considered to include three steps, requiring different information
`about the candidate/ target cell:
`
` Step 1: Measuring and ranking
`o A locally unique cell identity, to relate subsequent measurements. The ‘Measurement cell
`identification’ that is derived from SCH is assumed to be sufficient in most scenarios
`
` Step 2: Verification of accessibility
`o A locally unique cell identity, needed to validate that the detected cell is applicable in case the
`serving cell provides the identities of (not) applicable neighbouring cells
`o PLMN identity, needed to validate that the cell belongs to an (equivalent) PLMN when the
`serving cell does not provide a locally unique cell identity
`o TA identity, needed to validate that the detected cell does not belong to a forbidden TA
`o Cell barring status, needed to validate if the cell is barred
` Step 3: Actual re-selection i.e. acquisition of the configuration information needed to camp
`o Paging channel (and MBMS notification) configuration, needed to receive paging and notification
`information
`o aRACH as well as UL-SCH & DL-SCH configuration info, needed to initiate connection
`establishment
`
`10
`
`

`

`
`
`
`
`o Measurement configuration, needed to ensure good mobility
`
`6.2 Dedicated signalling of BCH upon handover (NACC)
`Rather than transmitting the information frequently on BCH, some of the information (e.g. aRACH
`configuration) may be included in the handover command message (i.e. alike NACC).
`According to our previous load calculations, in a loaded cell there would be roughly 50 UEs per second
`performing handover i.e. one UE every 20ms. If provided on BCCH, the information would have to be
`provided every 10 ms since larger acquistion delays seem unacceptable for handover. This means that even
`in loaded cells it is efficient to provide the concerned information via dedicated signalling.
`Note 3 The above conclusion also holds in general for cell specific information e.g. measurement
`configuration information i.e. if the required acquisition delay (or periodicity) is larger than 20ms it is
`cheapest to broadcast information that is applicable to all connected mode UEs. Dedicated
`signalling is most efficient for more urgent information and/ or information applicable to specific
`UEs or groups of UEs and/ or in case of lowly loaded cells
`
`6.3 BCH data transfer capacity
`Based on [2] and [3], the BCH data transfer capacity is assumed to be as follows:
`
`BCH bandwith
`
`Bits
`
`Options
`
`1.25
`
`1.25
`
`1.25
`
`2.5
`
`2.5
`
`2.5
`
`5.0
`
`~45 [3]
`~100 [3]
`~55 (extrapolated)
`~130 [2]
`~90 (extrapolated)
`~200 [3]
`~108 (extrapolated)
`~220 (extrapolated)
`~130 (extrapolated)
`~310 [2]
`~216 (extrapolated)
`~440 (extrapolated)
`~270 (extrapolated)
`~600 [2]
`
`None
`Tx diversity
`None
`Tx diversity?
`None
`Tx diversity
`None
`Tx diversity
`None
`Tx diversity?
`None
`Tx diversity
`None
`Tx diversity?
`Tab. 2 BCH data transfer capacity
`
`BLER & coverage
`
`1% BLER @ 98%
`coverage
`1% BLER @ 95%
`coverage
`10% BLER @ 95%
`coverage
`1% BLER @ 98%
`coverage
`1% BLER @ 95%
`coverage
`10% BLER @ 95%
`coverage
`1% BLER @ 98%
`coverage
`
`11
`
`