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:
`
`
`
` System information scheduling and change notification
`Document for: Discussion and decision
`
`Tdoc R2-071912
`(re-submission of R2-071337)
`
`1 Introduction
`During the previous RAN2 meeting the following was agreed:
`
`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). BCH incudes ‘Scheduling information of the most frequently repeated
`Scheduling Unit (SU-1)’, while SU-1 includes the ‘Scheduling information of the other Scheduling Units
`(other than SU-1)’.
`
`This paper mainly discusses the further details of the scheduling information including what information is
`provided via the PDCCH. Furthermore, this paper analyses the different options for indicating system
`information changes.
`
`2 Discussion
`
`2.1 Scheduling information
`This section discusses the further details of the scheduling information as included in BCH and SU-1
`including the use of PDCCH.
`
`BCCH mapped to BCH
`
`The scheduling is fixed in all details i.e. PDCCH is not used.
`
`BCCH mapped to DL-SCH
`
`In order to limit its size, our proposal is that the Scheduling information indicates the Radio Frame (RF) in
`which the transmission of the concerned SU starts i.e. the UE starts reading the PDCCH control channel
`from the first sub-frame of the indicated RF (i.e. UTRAN has some scheduling flexibility, but this comes at the
`cost of decreased UE battery lifetime).
`
`Note In the back of this document (see 5.1), we have shown that use of a common offset can help to reduce
`the scheduling information (resulting in 9b of scheduling info on BCH and 10b + NSU * 4b of scheduling
`info within SU-1, with NSU being the number of SUs that are scheduled and assuming the standard
`allows up to 16 SU).
`
`It is assumed that roughly 10 bits of the PDCCH are not relevant for the case of BCCH mapped to DL-SCH.
`Our proposal is to introduce a special format, including a field for indicating the SU.
`
`Especially for low bandwith systems, it seems desirable to introduce some scheduling flexibility. Hence, it is
`proposed that the UE only considers that transmission of an SU is finised when detecting the absence of the
`SU on PDCCH for N consequtive subframes. Considering that the eNB has the option to use a reduced
`number of resources for BCH, the value of N could probably be low (and fixed in the standard).
`Summary of proposals
`1.
`‘Scheduling information’ indicates the Radio Frame (RF) in which the transmission of the concerned SU
`starts
`
`Page 1
`
`ERICSSON EXHIBIT 2004
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 1
`
`

`

`2. PDCCH control channel is used to indicate the SU and the corresponding detailed time/ frequency
`resource allocation
`
`3. UEs only consider transmission of an SU to be finised when detecting the absence of the SU on PDCCH
`for N consequtive subframes
`
`2.2 Indication of system information change
`
`2.2.1 Use of paging/ notification and value tags
`UMTS includes the following mechanism to indicate a system information change
`
` UTRAN can notify UEs by signalling the “BCCH modification info” (MIB Value tag & BCCH modification
`time), using the PAGING TYPE1 message (UEs in IDLE & _PCH) and the SYSTEM INFORMATION
`CHANGE INDICATION message (CELL_FACH)
`
` The MIB includes a general 4b value tag. For all other SIBs a value tag is provided together with the
`scheduling information (i.e. within the MIB or one of the Scheduling blocks). For most SIBs a 2b cell
`value tag is used
`
`Most system information changes rather infrequently, say once per day (the only exception may be UL
`interference info i.e. SIB7 alike). Hence, a ‘paging/ notification mechanism’ is much ‘cheaper’ than
`transmitting value tags every few radio frames (RF). Hence our proposal is to indicate System information
`changes by means of a ‘paging/ notification mechanism’.
`
`Nearly all system information is cell specific. Consequently, if a paging/ notification mechanism is used, the
`main remaining purpose of using value tags on BCCH is to avoid BCH acquisition upon return from a
`temporary Out Of Service (OOS). For this case, the value tags help not only to improve UE battery lifetime
`but more importantly to reduce the ‘service interruption’ (related to acquisition of SIBs including the common
`channel configurations e.g. paging, aRACH). Although OOS should be infrequent, our assumption is that
`value tags are probably needed for this purpose. Our proposal is that BCH does not include an overall value
`tag (indicating changes in all system information). Instead, it is proposed that the most frequently repeated
`Scheduling Unit (SU-1) includes a value tag for each of the SUs. This means that upon returning from OOS
`the UE acquires SU-1 and, depending on the value tags, other SUs
`
`SUs should be designed to include a limited number of SIBs corresponding with independent functionality.
`Considering the infrequent changes, the additional ‘cost’ of acquiring the entire SU is marginal especially
`when concentrated transmission is used for D-BCH. Hence our proposal is that if one System Information
`Block changes, the UE acquires the entire Scheduling Unit in which it is contained (implying that changes are
`indicated at the level of an SU)
`Summary of main proposals
`4. System information changes are indicated by means of a ‘paging/ notification mechanism’
`
`5. BCH does not include an overall value tag (indicating changes in all system information). The most
`frequently repeated Scheduling Unit (SU-1) includes a value tag for each of the SUs
`o Upon returning from OOS the UE acquires SU-1 and, depending on the value tags, other SUs
`If one System Information Block changes, the UE acquires the entire Scheduling Unit in which it is
`contained (implying that changes are indicated at the level of an SU)
`
`6.
`
`2.2.2 Paging/ notification information
`BCCH modification time
`
`Optional, needed to support synchronous reconfiguration of e.g. common channel information
`
`The modification time needs to cover a range corresponding with the longest Paging/ DRX cycle. It does not
`seem essential to use all frames as possible start of a BCCH modification i.e. to save bits we could limit the
`
`Page 2
`
`ERICSSON EXHIBIT 2004
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 2
`
`

`

`modification time to frames corresponding with SFN MOD 16, in which case 6b would be needed for a range
`of 60s.
`
`Note 1
`
`In UMTS, there does not seem to be an explicit statement that the UE shall refrain from using the
`‘old configuration’ after the modification time
`
`Overall value tag
`Inclusion of a value tag allows time flexibility between the paging/ notification and the (asynchronous) BCCH
`modification i.e. if the MIB value tag is not set to the indicated value, the UE knows the modification has not
`occurred yet and will re-read BCH at the next ‘value tag occurance’.
`Time flexibility is not needed to accommodate varying transport network delays (since BCCH and PCCH are
`terminated in the eNB). Time flexibility could be desirable since UEs in DRX receive the notification at
`different points in time (due to different paging cycles and occasions). However, it seems preferable to
`perform (asynchronous) BCCH moficication prior to the paging/ notification to avoid that UEs have to acquire
`system information multiple times. In such a case, the only purpose of the value tag information is to avoid
`multiple BCH reading due to repeatition of the paging/ notification (as well as the useless BCH reading for
`UEs that have already aquired the new BCH information). This purpose could equally well be achieved by a
`2b ‘Transaction identity’.
`Based on the above, there does not seem to be a strong need for including value tag information in the
`BCCH modification information.
`
`Scheduling information of changed SU
`
`One could consider including the scheduling information of the changed SUs. However, it is assumed that
`the scheduling information is quite stable and normally does not change even if there is a change in SU-2,
`SU-3 or SU-4. Hence, there does not seem to be a strong need for including this in the BCCH modification
`information.
`
`Further signalling aspects
`
`The paging/ notification can be provided in a number of ways:
`
`1: PDCCH only: A special RNTI value is used for the PDCCH CRC, indicating ‘BCCH Modification’. The
`BCCH modification information is carried on PDDCH, using a special format.
`
`2: PDCCH+PCH: The ‘paging RNTI’ is used for the PDCCH CRC. The BCCH modification information is
`carried on PCH i.e. using an optional BCCH Modification IE within the Paging message
`
`3: BCH: The UE is required to verify the value tag of each SU periodically e.g. at least once per 5s
`
`Approach 3 is bad for the UE battery lifetime unless there is system information that the UE anyhow needs to
`acquire frequently. Considering the conclusion of the UTRA SIB7 discussions (the information is not very
`dynamic i.e. may be valid for 40s), this does not seem the way to go.
`
`Approach 1 implies that at every Paging/ DRX wakeup the UE has to verify an additional C-RNTI value which
`may somewhat affect UE battery lifetime as well as UE complexity. This approach also implies that the
`BCCH modification info has to be limited to around 10 bits.
`
`Approach 2 means that there will be an additional overhead in every ‘Paging’ message (i.e. a ‘presence’ bit
`for the IE BCCH Modification info). Moreover, this approach probably implies that some kind of ‘Paging/
`notification’ message has to be introduced for connected mode (i.e. separate, somewhat different,
`mechanisms for idle and connected). On the positive, there is only additional UE processing in the infrequent
`case of a BCCH mofication.
`
`We request RAN2 to consider approach 1 and 2. Both approaches are able to provide the essential BCCH
`modification information i.e. the modification time and a ‘transaction identity’. In case approach 2 is adopted,
`some more information may be included e.g. an indication of the changed SU, possibly including the value
`tag.
`
`In case there is no significant difference in UE power consumption between approach 1 and 2 i.e. between
`
`1) Checking PDCCH with an additional RNTI, at every paging cycle/ DRX wakeup and
`
`Page 3
`
`ERICSSON EXHIBIT 2004
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 3
`
`

`

`2) Reading an additional Paging message when detecting “PCH RNTI” on PDCCH, due to a BCCH
`modification (occurring once a day)
`
`then approach 1 seems most attractive, since it can be used for both modes. Then, to avoid the continuous
`additional RNTI-processing for active connected mode UEs, it seems attractive to adopt a scheme in which:
`
`
`
`
`
`Idle mode and ‘inactive’ connected mode UEs (DRX above a threshold) apply approach 1, while
`
`‘Active’ connected UEs periodically verify if ‘BCCH modification’ is indicated on PDCCH i.e. apply
`approach 1 e.g. once every 2s.
`
`This seems an acceptable mechanism, but it may be appropriate to ask RAN1 for confirmation.
`Note 2 As mentioned before, most system information changes infrequently i.e. once per day. Hence, a 2
`bit value tag as used in UTRA would seem sufficient.
`Summary of main proposals
`7. RAN2 is requested to first decide how the BCCH modification is provided i.e. either:
`o 1: PDCCH only: Using a special RNTI value and a special PDCCH format
`o 2: PDCCH+PCH: The ‘paging RNTI’ and the Paging message is used. If needed, a similar
`mechanism can be developed for connected mode UEs
`
`8. The BCCH modification information is decided depending on the above:
`o Approach 1: Modification time and the transaction identity
`o Approach 2: Modification time and transaction identity. In this case additional information could
`be considered e.g. an indication of the changed SU, possibly including the value tag.
`
` These additions are not considered to be really needed
`
`2.2.3 Dynamic system information i.e. SIB-7
`In UTRA, there is one rather dynamic SIB, namely SIB 7. This SIB includes the UL interference level and the
`dynamic persistence information, both of which are relevant for initial RACH access. UTRA SIB 7 applies an
`expiry timer. In our understanding, the latest discussions on SIB-7 concluded that the information is less
`dynamic than earlier anticipated i.e. the final recommendation was to repeat the information regularly i.e.
`every 160ms and to set the expiration time to 256 repetitions i.e. 40s.
`
`The previous suggests that it may be possible to apply a value tag for this type of information also i.e. it could
`be specifed that the UE re-reads the SIB after having been OOS for a period typically corresponding with the
`value tag wrap around. However, it is not attractive to perform a paging/ notification frequently e.g. every 5
`sec. Hence, our proposal is to apply an expiration time for system information that changes frequently.
`Summary of main proposals
`9. Apply an expiration time for system information that is changing frequently
`
`3 Conclusion & recommendation
`In this contribution we have discussed the further details of the scheduling information including what
`information is provided via the PDCCH. Furthermore, this paper analysed the different options for indicating
`system information changes. Based on our analysis, RAN2 is requested to consider the following proposals:
`1.
`‘Scheduling information’ indicates the Radio Frame (RF) in which the transmission of the concerned SU
`starts
`
`2. PDCCH control channel is used to indicate the SU and the corresponding detailed time/ frequency
`resource allocation
`
`Page 4
`
`ERICSSON EXHIBIT 2004
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 4
`
`

`

`3. UEs only consider transmission of an SU to be finised when detecting the absence of the SU on PDCCH
`for N consequtive subframes
`
`4. System information changes are indicated by means of a ‘paging/ notification mechanism’
`
`5. BCH does not include an overall value tag (indicating changes in all system information). The most
`frequently repeated Scheduling Unit (SU-1) includes a value tag for each of the SUs
`o Upon returning from OOS the UE acquires SU-1 and, depending on the value tags, other SUs
`If one System Information Block changes, the UE acquires the entire Scheduling Unit in which it is
`contained (implying that changes are indicated at the level of an SU)
`
`6.
`
`7. RAN2 is requested to first decide how the BCCH modification is provided i.e. either:
`o 1: PDCCH only: Using a special RNTI value and a special PDCCH format
`o 2: PDCCH+PCH: The ‘paging RNTI’ and the Paging message is used. If needed, a similar
`mechanism can be developed for connected mode UEs
`
`8. The BCCH modification information is decided depending on the above:
`o Approach 1: Modification time and the transaction identity
`o Approach 2: Modification time and transaction identity or further detailed information e.g. an
`indication of the changed SU, possibly including the value tag
`
`9. Apply an expiration time for system information that is changing frequently
`
`4 References
`[1] RP-070136 TS 36.300 E-UTRA and E-UTRAN Overall description; Stage 2 (Release 8)
`
`Page 5
`
`ERICSSON EXHIBIT 2004
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 5
`
`

`

`5 Further information (Annex)
`
`5.1 Scheduling information signalling details
`Our assumption is that E-UTRA applies the same repetition values as used in UTRA i.e: 4, 8, 16, 32, 64,
`128, 256, 512, 1024, 2048, 4096. Our proposal is to limit the possible repetition rates for SU-1 to: 4, 8, 16,
`32, 64 (i.e. 3b).
`
`Furthermore, we assume that system information is transmitted in consequtive subframes (i.e. ‘concentrated’
`transmission scheme), meaning that it is possible to use a ‘common’ offset applies for all SUs. Our proposal
`is that the least significant bits of this common offset are be provided on BCH (i.e. 6 bits, needed to cover the
`highest repetition rate value) while the remaining MSBs are provided in SU-1.
`
`Example: The following transmission scheme
`
`SU
`SU-1
`SU-2
`SU-3
`
`REP
`16
`64
`128
`
`OFF
`7 (119 MOD 16)
`55 (119 MOD 64)
`119
`
`Results in the following scheduling information parameters
`
`Where
`
`BCH
`
`SU-1
`
`IE
`
`Size
`
`Value
`
`LSB common
`OFF
`REP of SU-1
`MSB common
`OFF
`REP of SU-2
`REP of SU-3
`
`6b
`
`3b
`6b
`
`4b
`4b
`
`55
`
`16
`1
`
`64
`128
`
`Note 1
`
`Note 2
`
`In case of lower bandwiths system information may occupy up to 50 subframes. In this case, it
`seems desirable to allow BCH transmission to be interrupted somewhat. Nevertheless, a common
`offset may still be used assuming that system information changes are rather infrequent.
`It may be possible to further reduce the Scheduling information provided on BCH by limiting the
`scheduling flexibility i.e. it may be possible to define a limited number of default configurations.
`Although there does not seem to be a need for a lot of flexibility, it may be desirable to apply a
`somewhat different S-BCH schedule in adjacent cells i.e. 8 default configurations may be sufficient.
`
`With the above optimization, the size of the scheduling information becomes as follows:
`
` BCH: 9b
`
` SU-1: 10b + NSU * 4b
`
`With NSU being the number of SUs that are scheduled
`
`Assuming the standard allows up to 16 SU
`
`Page 6
`
`ERICSSON EXHIBIT 2004
`Apple, Inc. v. Telefonaktiebolaget LM Ericsson
`IPR2022-00338, Page 6
`
`