Commented [H1]: Document numbers are allocated by the
`Working Group Secretary.
`
`3GPP TSG-RAN2 Meeting #58
`Kobe, Japan, 7th-11th May 2007
`Agenda Item: 4.5
`Souce:
`
`
` Samsung
`Title:
`Draft text proposal capturing agreements on system information
`Document for: Discussion and decision
`
`Tdoc R2-072205
`
`Introduction
`This paper includes a draft text proposal aiming to capture the agreements on system information reached
`during the RAN2#58 meeting.
`
`Summary of agreements
`The text proposal aims to capture the agreements listed in the following, as extracted from the draft minutes.
`Decision: The P-BCH is sent every 40ms (working assumption). If later studies show that this is too long,
`this will be revisited towards 20ms. The PLMN list is sent on D-BCH every 80ms. This will be captured in the
`stage 2
`
`Furthermore:
`
` SU1 is sent on the D-BCH
` No need for secondary BCH
` Periodicity of SU-1 is 80ms; it contains the PLMN list.
` SU1 contains a scheduling block providing the periodicity for all the SU-n>1.
` SU1 contains the mapping of SIBs into SUs, dynamic, or mapping of SIBs into SUs is fixed in the
`standard. This is FFS.
` SU1 contains a value tag for each individual SU or (MIB or SU1) contains a value tag for all the SUs
`(FFS which of the solutions is selected).
` SU-1 is in the following sub-frame of P-BCH.
` Unicast DL-SCH transmissions can take place in parallel to SUs transmission, using L1/L2 control
`channel.
` Maximum D-BCH rate = minimum UE capability; Maximum D-BCH rate has to be studied. => RAN1
` SUs can be segmented, in which case each segment is sent in the next sub-frame as the previous
`one i.e. continuous time transmission (RB can vary using L1/L2 control channel)
` Whether SUs are contiguous (in a row) is FFS (benefit of continuous transmission is UE battery
`saving)
` Can eNB send different SUs is the same sub-frame? We need to ask RAN1
`Information on P-BCH is called MIB
`
`
`Furthermore, the attached text proposal captures the RAN1 assumptions regarding the physical layer
`parameters transmitted on (P-)BCH as included in R2-072105.
`
`Conclusion & recommendation
`RAN2 is requested to endorse the text proposal attached at the end of this document.
`
`ERICSSON EXHIBIT 2003
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 1
`
`

`

`3GPP TSG-??? Meeting #nn
`Location, Country, Date
`
`R2-072205
`
`Commented [H2]: Document numbers are allocated by the
`Working Group Secretary.
`
`
`
`CHANGE REQUEST
`-  Current version: x.y.z 
`36.300 CR CRNum rev
`For HELP on using this form look at the pop-up text over the  symbols. Comprehensive instructions on
`how to use this form can be found at http://www.3gpp.org/specs/CR.htm.
`
`CR-Form-v9.2
`
`Proposed change affects: UICC apps
`
`ME
`
`Radio Access Network
`
`Core Network
`
`Title:
` Draft text proposal capturing agreements on System Information
`Source to WG:  Samsung
`Source to TSG: 
`Work item code: 
`Category:
`
`
`Use one of the following categories:
`F (correction)
`A (corresponds to a correction in an earlier release)
`B (addition of feature),
`C (functional modification of feature)
`D (editorial modification)
`Detailed explanations of the above categories can
`be found in 3GPP TR 21.900.
`
`Date:  dd/mm/yyyy
`Release: 
`Use one of the following releases:
`R97
`(Release 1997)
`R98
`(Release 1998)
`R99
`(Release 1999)
`Rel-4
`(Release 4)
`Rel-5
`(Release 5)
`Rel-6
`(Release 6)
`Rel-7
`(Release 7)
`Rel-8
`(Release 8)
`
`Reason for change: 
`Summary of change: 
`Consequences if 
`not approved:
`Clauses affected: 
`
`Other specs
`affected:
`
`Y N
`
`
`
`Other comments: 
`
` Other core specifications
` Test specifications
` O&M Specifications
`
`
`
`Commented [H3]: Enter the specification number in this box.
`For example, 04.08 or 31.102. Do not prefix the number with
`anything . i.e. do not use "TS", "GSM" or "3GPP" etc.
`Commented [H4]: Enter the CR number here. This number is
`allocated by the 3GPP support team. It consists of at least three
`digits, padded with leading zeros if necessary.
`Commented [H5]: Enter the revision number of the CR here. If
`it is the first version, use a "-".
`Commented [H6]: Enter the version of the specification here.
`This number is the version of the specification to which the CR was
`written and (normally) to which it will be applied if it is approved.
`Make sure that the latest version of the specification (of the relevant
`release) is used when creating the CR. If unsure what the latest
`version is, go to http://www.3gpp.org/specs/specs.htm.
`Commented [H7]: For help on how to fill out a field, place the
`mouse pointer over the special symbol closest to the field in
`question.
`Commented [H8]: Mark one or more of the boxes with an X.
`Commented [H9]: SIM / USIM / ISIM applications.
`Commented [H10]: Enter a concise description of the subject
`matter of the CR. It should be no longer than one line. Do not use
`redundant information such as "Change Request number xxx to
`3GPP TS xx.xxx".
`Commented [H11]: One or more organizations (3GPP
`Individual Members) which drafted the CR and are presenting it to
`the Working Group.
`Commented [H12]: For CRs agreed at Working Group level,
`the identity of the WG. Use the format "x WGn" where
`x = "CT" for TSG CT, "RAN" for TSG RAN, "SA" for TSG SA,
`SA, "GERAN" for TSG GERAN;
`n = digit identifying the Working Group; for CRs drafted during
`the TSG meeting itself, use "TSG x".
`Examples: "CT WG4", "RAN WG5", "GERAN WG3", "TSG SA".
`Commented [H13]: Enter the acronym for the work item which
`is applicable to the change. This field is mandatory for category F, B
`& C CRs for release 4 and later. A list of work item acronyms can be
`found in the 3GPP work plan. See
`http://www.3gpp.org/ftp/information/work_plan/ .
`Commented [H14]: Enter the date on which the CR was last
`revised. Format to be interpretable by English version of MS
`Windows ® applications, e.g. 19/02/2002.
`Commented [H15]: Enter a single letter corresponding to the
`most appropriate category listed below. For more detailed help on
`interpreting these categories, see the Technical Report 21.900 "TSG
`working methods".
`Commented [H16]: Enter a single release code from the list
`below.
`Commented [H17]: Enter text which explains why the change
`is necessary.
`Commented [H18]: Enter text which describes the most
`important components of the change. i.e. How the change is made.
`Commented [H19]: Enter here the consequences if this CR
`were to be rejected. It is mandatory necessary to complete this ... [1]
`Commented [H20]: Enter the number of each clause which
`contains changes.
`Commented [H21]: Tick "yes" box if any other specifications
`are affected by this change. Else tick "no". You MUST fill in one
`... [2]
`Commented [H22]: List here the specifications which are
`affected or the CRs which are linked.
`Commented [H23]: Enter any other information which may be
`needed by the group being requested to approve the CR. This could
`... [3]
`
`ERICSSON EXHIBIT 2003
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 2
`
`

`

`Broadcast of system information
`
`Broadcast Channel
`5.4.1.2
`The BCH transport channel is characterized by a fixed pre-defined transport format. The TTI (repetition rate) of the
`BCH is FFS40ms. In case problems are discovered, e.g. w.r.t. the reading of BCH from neighbouring cells, a TTI of
`20ms will be used. The BCH physical-layer model is described based on the corresponding BCH physical-layer-
`processing chain, see Figure 5.4.1.2:
`- Higher-layer data passed to/from the physical layer
`
`- A single (fixed-size) transport block per TTI.
`- CRC and transport-block-error indication
`
`- Transport-block-error indication delivered to higher layers.
`- FEC and rate matching
`
`- Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and
`resource assignment;
`
`- No BCH Hybrid ARQ, i.e. no higher-layer control of redundancy version.
`Interleaving
`
`-
`
`- No control of interleaving by higher layers.
`- Data modulation
`
`- Fixed modulation scheme (QPSK), i.e. not higher-layer control.
`- Mapping to resource blocks
`
`- Fixed pre-determined transport format and resource allocation, i.e. no higher-layer control.
`- Physical-layer processing Step 6: Multi-antenna processing
`
`Fixed pre-determined processing, i.e. no higher-layer control.
`-
`- Support for Hybrid-ARQ-related signalling
`
`- No Hybrid ARQ.
`
`ERICSSON EXHIBIT 2003
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 3
`
`

`

`
`
`Node BNode B
`
`
`Single Transport blocksSingle Transport blocks
`
`(fixed size S)(fixed size S)
`
`
`
`UEUE
`
`
`ErrorError
`
`indicationindication
`
`
`
`CRC CRC
`
`
`
`Coding + RMCoding + RM
`
`
`
`InterleavingInterleaving
`
`
`
`Data modulationData modulation
`
`
`
`QPSK onlyQPSK only
`
`
`
`Resource mappingResource mapping
`
`
`
`Antenna mappingAntenna mapping
`
`
`
`CRC CRC
`
`
`
`Decoding + RMDecoding + RM
`
`
`
`DeinterleavingDeinterleaving
`
`
`
`Data demodulationData demodulation
`
`
`
`Resource demappingResource demapping
`
`
`
`Antenna demappingAntenna demapping
`
`Figure 5.4.1.2: BCH physical-layer model
`
`It is FFS whether the BCH needs to be extended, in which case the BCH would comprise a primary and a secondary
`BCH.
`
`NOTE
`
`In case the BCH is extended, the characteristics of the primary BCH (P-BCH) would be as defined in the
`above. The P-BCH would carry scheduling information of the secondary BCH (S-BCH). The S-BCH
`would apply a fixed coding while its carrier bandwidth may be limited
`
`ERICSSON EXHIBIT 2003
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 4
`
`

`

`Formatted: Indent: Left: 0.39"
`
`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 or fixed in the specification (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 following system information is carried on the BCH:
`
`- Physical layer parameters:
`
`- Downlink system (e.g. bandwidth )[4b];
`
`- Number of transmit antennas [1..2b];
`
`- Reference-Signal transmit power [0..6b];
`
`- MBSFN-related parameters [0..9b].
`
`- System Frame Number (SFN [10b], unless provided otherwise);
`
`- Scheduling information of the most frequently repeated Scheduling Unit (SU-1);
`
`- Cell re-selection and handover related parameters:
`
`- Offset [6b].
`
`- Value tag(s) (FFS).
`
`The system information carried on BCH is contained in a System Information Block called the Master Information
`Block (MIB).
`
`The following system information is carried within the most frequently repeated Scheduling Unit (SU-1):
`
`- One or more PLMN identities;
`
`- Tracking Area Code;
`
`- Cell identity;
`
`- Cell barring status;
`
`- Scheduling information i.e. the periodicity of the other Scheduling Units (other than SU-1);
`
`- SIB mapping information i.e. indication in which SU the SIBs is included (FFS).
`
`The scheduling information within SU-1 is contained in a System Information Block called the Scheduling Block (SB).
`SU-1 should include all access restriction related parameters. SU-1 is carried on the DL-SCH and uses a fixed schedule
`with a periodicity of 80 ms, unless the BCH is extended. In the latter case, S-BCH may carry (part of) the SU-1
`information.
`
`It is FFS whether the SB includes a value tag for each SU, whether a common value tag is used. The common value tag
`could either be carried in the MIB or in the SB.
`
`An SU may be segmented, in which case segments are scheduled in subsequent consequtive subframes. In this case,
`PDCCH is used for each segment i.e. each segement may use different PRBs. SU-1 is scheduled in the subframe
`following the one carrying BCH. It is FFS if further SUs are scheduled in subsequent consequtive subframes. The eNB
`may schedule DL-SCH transmissions concerning logical channels other than BCCH in the same subframe as used for
`BCCH. The minimum UE capability restricts the BCCH mapped to DL-SCH e.g. regarding the maximum rate. It is FFS
`if the eNB may schedule more than one SU in a subframe.
`
`ERICSSON EXHIBIT 2003
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 5
`
`

`

`The following figure illustrates System information structure and also shows typical example of how the BCCH
`mapped to DL-SCH may be scheduled.
`
`DL-SCH (D-BCH)
`
`SU-3
`
`SIB-d
`
`SIB-e
`
`SU-1
`
`SIB-a
`
`SB
`
`SU-2
`
`SIB-c
`
`SIB-b
`
`subframe
`
`RF
`67
`19
`0
`3
`Fig. x System information structure and typical scheduling example
`
`131
`
`(P-)BCH
`
`MIB
`
`Multi-frame/
`scheduling period
`
`System information may also be provided to the UE by means of dedicated signalling e.g. upon handover.
`
`ERICSSON EXHIBIT 2003
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 6
`
`

`

`Page 2: [1] Commented [H19] Explanation of field 8/10/2006 10:03:00 AM
` Enter here the consequences if this CR were to be rejected. It is mandatory necessary to complete this section only
`if the CR is of category "F" (i.e. correction), though it may well be useful for other categories.
`
`Page 2: [2] Commented [H21] Explanation of field
` Tick "yes" box if any other specifications are affected by this change. Else tick "no". You MUST fill in one or the
`other.
`
`Page 2: [3] Commented [H23] Explanation of field
` Enter any other information which may be needed by the group being requested to approve the CR. This could
`include special conditions for it's approval which are not listed anywhere else above.
`
`ERICSSON EXHIBIT 2003
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 7
`
`