throbber

`
`
`
`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
`
`SAMSUNG 1012
`
`1
`
`

`

`
`
`
`
`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
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket