3GPP TSG-RAN WG2 meeting #101
`Athens,Greece, 26 February – 2 March, 2018
`
`R2-1802960
`
`Agenda Item:
`Source:
`
`10.4.1.6.6
`Intel Corporation
`
`Title:
`
`Remaining issues on on-demand System Information
`
`Document for:
`
`Discussion and Decision
`
`1
`Introduction
`In this contribution, the remaining issues related to the on-demand SI are discussed below:
`
`2 Discussion
`2.1 Contents of SIB1 for on demand SI
`It is agreed that that there will be a bit in SI scheduling information whether other SI is periodically
`broadcast or provided on demand. It is FFS on whether there is a need for additional indication
`whether the on demand SI is actually being broadcast at this instant in time:
`
`3: The scheduling information for other SI includes SIB type, validity
`information, periodicity, and SI-window information in minimum SI
`irrespective of whether other SI is periodically broadcasted or provided on
`demand.
`FFS Whether there is an additional indication that an on demand SI is actually
`being broadcast at this instant in time.
`In RAN2 Ad-hoc June 2017, there was an offline on this but no conclusion was made. There were 3
`options on the table:
`
`Option 1: Use the existing bit indicating whether the SI is on-demand or periodic broadcast to also
`indicate whether the on-demand SI is currently being broadcast (i.e. if it is currently being broadcast,
`it will indicate it as periodic broadcast even though it is an on-demand SI)
`
`Option 2: Include an additional indication to specifically indicate whether an on-demand SI is actually
`being broadcast at this instant in time. If the additional indication indicates that an on-demand SI is
`being broadcast, the UE will not perform UE SI request.
`
`Option 3: Use the presence of the Scheduling Information of the on-demand SI to indicate whether it
`is currently being broadcast
`
`The issue we see in (1) is that a UE may enter the cell at any time. With the existing indication being
`dynamically switch between on-demand and periodic broadcast, there will be possibility that a UE
`may not have realised that it needs to request a SI on demand (e.g. during the transient period
`where the network stop the periodic broadcast of the on-demand SI and setting the indication back
`to on-demand). It may result in SI acquisition failure for such UE.
`
`The issue with Option 2 is mainly on the extra overhead of adding an additional bit for each on-
`demand SI. We do not see a need to page UE when this bit is changed. Hence there is no additional
`signalling issue.
`
`Ex.1019
`APPLE INC. / Page 1 of 6
`
`

`

`The issue with Option 3 is that the UE has to read SIB1 after requesting a SI. This results in further
`delay and also extra power consumption for acquiring on-demand SI.
`
`Comparing the 3 options, Option 2 does not have the ambiguity as in Option 1 and is more efficient
`in terms of latency of acquiring on demand SI and less UE power consumption than Option 3. Hence
`it is proposed:
`Proposal#1: Include an additional indication to specifically indicate whether an on-demand SI is
`actually being broadcast at this instant in time, on top of the indication whether the SI is on-demand
`or periodic broadcast. If the additional indication indicates that an on-demand SI is being broadcast,
`the UE does not perform UE SI request.
`
`In order to prevent further need of the UE to acquire the SIB1 before acquiring the on-demand SI, it
`is also proposed that:
`Proposal#2: The scheduling info of the on-demand SI is always present in SIB1.
`Also PRACH configuration (i.e. the preamble mapping to the SI) for Msg1 based request has to be
`included in the Scheduling information of the on-demand SI:
`Proposal#3: The PRACH configuration (i.e. the preamble mapping to the SI) for Msg1 based request
`is included in the Scheduling Information of the on-demand SI.
`2.2 Msg3 based UE request
`The following is agreed for Msg3 based UE request:
`
`Agreements for Msg3 based SI request method:
`1: UE determines successful Msg3 based on reception of Msg4
`FFS Details of the Msg4 content used to confirm successful Msg3. To be
`discussed initially CP.
`2: Preamble(s) for SI request using Msg3 based Method are not reserved.
`3: RRC signalling is used for SI request in Msg3.
`FFS: RRC signalling how to indicate the requested SI/SIB details left to ASN.1
`work.
`5: Temporary C-RNTI received in Msg2 is used for Msg4 reception
`
`
`
`It is agreed that RRC signalling is used for SI request in Msg3. There are 2 ways to request the SIB
`required in Msg3: (1) list/bitmap of SIBs or (2) list/bitmap of SI. Since SIB1 contains the scheduling
`information of SI and the mapping of SIB to SI, it would be difficult to change this on the fly without
`having to change scheduling info of SIB1 and UE having to read SIB1 perform it can read the
`requested SI in the broadcast. Hence it is clear that UE SI request in Msg3 should contain list/bitmap
`of SI requested.
`
`Since this is a contention based PRACH, it is needed to decide on how contention resolution is done
`in Msg4 for SI UE request. There are 2 cases where contention resolution is done in LTE:
`
`Case 1: In the scenarios of initial access, RRC Connection Re-establishment and Resume, UE ID is
`sent in the RRC message and contention resolution is done through sending the UE Contention
`Resolution ID MAC CE in Msg4. The UE Contention Resolution ID MAC CE contains the first 48bits
`of UL CCCH SDU (which normally contains the RRC UE Identity such as S-TMSI, random number,
`Resume ID or the ReestabUEID and some other bits of Msg3). UE ID in Msg3 of the RRC message
`can be used to identify the UE context by the RRC or NAS.
`
`Ex.1019
`APPLE INC. / Page 2 of 6
`
`

`

`Case 2: In the scenarios of contention based handover, UE initiated UL out-of-sync recovery and
`SR transmission, C-RNTI is sent as a MAC CE in Msg3. The contention resolution and UE context
`identification is based on the C-RNTI in the PDCCH in Msg4 which corresponds to the C-RNTI MAC
`CE in Msg3.
`
`Case 2 is not relevant for UE in idle mode. Based on Case 1, one approach to perform contention
`resolution is to also provide UE ID in Msg3. Alternatively, contention resolution can be done just via
`the list/bitmap of SI requested that are sent in Msg3. If it is not needed for the UE to go into
`connected mode for on-demand SI, the latter approach (using the list/bitmap of SI) is sufficient. Also
`including UE ID in Msg3 will not leave space to also carry the requested list/bitmap of SI. On the
`other hand, if the network can decide whether the on-demand SI is to be broadcast or sent via
`dedicated signalling, then the former approach (UE ID) is required. However, for Rel-15, we think
`that a simple approach that the on-demand SI is always broadcast when it is requested should be
`taken and the latter approach using list/bitmap of SI should be adopted.
`
`The contention resolution in Msg4 can be done through sending the UE Contention Resolution ID
`MAC CE in Msg4. In LTE, the UE Contention Resolution ID MAC CE contains the first 48bits of UL
`CCCH SDU (which normally contains the RRC UE Identity such as S-TMSI, random number, Resume ID
`or the ReestabUEID and some other bits of Msg3). The same concept can also be used in this case
`(i.e. the list/bitmap of SI is provided as part of the UE Contention Resolution ID MAC CE for
`contention resolution in Msg4).
`Proposal#4: UE SI request in Msg3 contains list/bitmap of SI requested. The RRC Msg3 size for Msg3
`UE SI request should be made to align with the RRC UE Identity in other Msg3 RRC Message for
`contention resolution.
`Proposal#5: Contention resolution in Msg4 for UE SI request in Msg3 is performed via UE
`Contention Resolution ID MAC CE which contains the first 48 bits of UL CCCH SDU (i.e. UE SI request
`in Msg3).
`2.3
`Initiation of the on-demand SI UE request
`UE will initiate an on-demand SIB request for a particular SI/SIB if the SI scheduling info in SIB 1 for
`this SIB indicates that a UE request is required.
`
`In the case the UE request fails during RACH procedure (MAC indicates a RACH failure to RRC for the
`SI request), the UE RRC should backoff for 1 full BCCH Modification period before attempting again.
`During this period, the UE should monitor SIB1 to find out whether the required SI is being
`broadcast. If so, it can perform SI (re)acquisition procedure for the SI once SIB 1 indicates that the SI
`is broadcast. If not, the UE can attempt again.
`Proposal#6: If MAC indicates to RACH failure for the SI request to RRC, the UE RRC should backoff
`for 1 full BCCH Modification period before attempting UE request again. During the backoff period,
`the UE should monitor SIB 1 to find out whether the required SI will be broadcast.
`Proposal#6_1: During the backoff period, if the SIB 1 indicates the required SI is broadcast, the UE
`can perform SI (re)acquisition procedure
`Proposal#6_2: At the expiry of the backoff period, the UE can attempt the UE request again for the
`required SI.
`
`Ex.1019
`APPLE INC. / Page 3 of 6
`
`

`

`2.4 SI (re)acquisition for on-demand SI
`For the (re)acquisition for on-demand SI message, it is agreed that the UE performs SI acquisition
`once it receives acknowledgement from the network. For Msg1 based SI request, the
`acknowledgement is via receiving Msg2 while for Msg3 based SI request, the acknowledgement is
`via receiving Msg4. However for both cases, it is not yet decided when the UE will start SI
`acquisition, when the UE will decide that SI acquisition failed and how the UE can recover from SI
`acquisition failure.
`2.4.1 When the UE will start SI acquisition
`There are 2 ways where the UE can start SI (re)acquisition of a SI after a UE request:
`a. At the next BCCH modification period
`b.
`Immediately at the next SI window where the SI is scheduled
`To prevent delay in acquiring the SI, it is natural to perform the SI acquisition immediately at the
`next SI window where the SI is scheduled. We do not see a benefit to delay to the next BCCH
`Modification period. If in the same BCCH Modification period, the UE receives via paging that there
`is a change in the SI, it can acquire again the corresponding SI in the next BCCH Modification period
`as normal.
`Proposal#7: Upon successful receiving the acknowledgement of the on-demand SI request, the UE
`performs SI acquisition immediately at the next SI window where the SI is scheduled as indicated in
`SIB1.
`
`As in LTE, it is not specified that the UE is required to soft combine over multiple SI windows as the
`contents of the SI may change from SI window to the next, particularly when 2 SI windows cross a
`BCCH Modification period. In some cases (e.g. cell barring and access class barring etc.), it can also
`occur within BCCH Modification period.
`Proposal#8: The UE soft combines every valid TTI where the SI is PDCCH scheduled within the SI
`window. It is left to UE implementation whether UE soft combine across over multiple SI windows.
`2.4.2 When will the UE decide that SI acquisition fails
`In LTE for the periodic broadcast SI, there is no UE behaviour specified on when the UE will consider
`the SI acquisition as failure. The same can be the case for SI acquisition for on-demand SI (i.e. left to
`UE implementation on when to consider the SI acquisition as failure, e.g. for on-demand, the UE can
`base it on SIB 1 indicating again the SI is on-demand etc.). Alternatively, it can be
`specified/configured number of SI window or BCCH Modification period before the UE decides that
`SI acquisition fails. Regardless which approach is taken, it is preferred that the same approach on
`deciding SI (re)acquisition failure is specified for both the on-demand SI case as well as periodic
`broadcast SI case
`Proposal#9: The same UE approach on deciding SI (re)acquisition failure is specified for both the on-
`demand SI case as well as periodic broadcast SI case.
`
`For on-demand SI which contains only non-essential SIB(s), upon failure to acquire the SI, it is
`possible for the UE to request again the RAN to broadcast SI. Like in the case of RACH failure during
`UE request, the UE can backoff for 1 BCCH Modification period before attempting again. During this
`period, the UE should monitor SIB1 to find out whether the required SI is being broadcast and
`continue to acquire it as long as the requested SI is broadcast. At expiry, if the requested SI is not
`broadcast, the UE can attempt the on-demand request again.
`
`Ex.1019
`APPLE INC. / Page 4 of 6
`
`

`

`Proposal#10: Upon failure to acquire SI which contains only non-essential SIB(s), the UE can backoff
`for 1 BCCH Modification period before attempting again. During this period, the UE should monitor
`SIB1 to find out whether the required SI is being broadcast and continue to acquire it as long as the
`requested SI is broadcast. At expiry, if the requested SI is not broadcast, the UE can attempt the on-
`demand request again.
`2.5 Modification of on-demand SI in Idle Mode
`In idle mode, if there is any change of the on-demand SI, there are 2 ways where the UE can acquire
`the on-demand SI after the gNB notifies the UEs of the SI modification:
`1. UE request for the SI using UE request
`2. UE acquires the SI without UE request
`
`For 1), this may result in many UE requesting for the updated SI. Hence it may not be efficient in
`terms of radio resources to go with this approach. 2) seems to be aligned with the SI change for
`periodic broadcast.
`Proposal#11: In idle mode, UE does not perform UE request for on-demand SI after the gNB notifies
`the SI modification. UE will acquire the on-demand SI as like periodic broadcast SI (i.e. the gNB
`broadcast the on-demand SI when the SI changes).
`2.6 Need of UE request for on-demand SI in Connected mode
`In Rel15, the SIBs contain normal operational SIBs (i.e. SIB that all UEs always need in a serving cell,
`e.g. RMSI (SIB1), cell reselection SIBs (intra-frequency, inter-frequency and inter-RAT to EUTRA cell
`reselection SIB)) and PWS SIB. RMSI is not on-demand and thus do not need to be requested. Cell
`reselection SIBs are not needed in RRC Connected. For PWS SIB, it would require the network to
`push it to the UE, rather than the UE request for it. In the email discussion, it is not concluded
`whether positioning SIB (i.e. SIB16 containing UTC and GPS time) is needed. This may require UE
`request. In the future, SIBs related service type such as MBMS, CSG, V2X etc. may also be supported.
`These SIBs may require UE request. For Rel-15, if it contains only operational SIBs and PWS SIB,
`there is no need for UE request in RRC Connected.
`Proposal#12: For Rel-15, if it contains only operational SIBs(i.e. SIB that all UEs always need in a
`serving cell, e.g. RMSI (SIB1), cell reselection SIBs (intra-frequency, inter-frequency and inter-RAT to
`EUTRA cell reselection SIB)) and PWS SIB, there is no need for UE request in RRC Connected.
`
`3 Conclusion and proposals
`It is requested that RAN 2 discuss and agree on the following proposals:
`Proposal#1: Include an additional indication to specifically indicate whether an on-demand SI is
`actually being broadcast at this instant in time, on top of the indication whether the SI is on-demand
`or periodic broadcast. If the additional indication indicates that an on-demand SI is being broadcast,
`the UE does not perform UE SI request.
`Proposal#2: The scheduling info of the on-demand SI is always present in SIB1.
`Proposal#3: The PRACH configuration (i.e. the preamble mapping to the SI) for Msg1 based request
`is included in the Scheduling Information of the on-demand SI.
`Proposal#4: UE SI request in Msg3 contains list/bitmap of SI requested. The RRC Msg3 size for Msg3
`UE SI request should be made to align with the RRC UE Identity in other Msg3 RRC Message for
`contention resolution.
`
`Ex.1019
`APPLE INC. / Page 5 of 6
`
`

`

`Proposal#5: Contention resolution in Msg4 for UE SI request in Msg3 is performed via UE
`Contention Resolution ID MAC CE which contains the first 48 bits of UL CCCH SDU (i.e. UE SI request
`in Msg3).
`Proposal#6: If MAC indicates to RACH failure for the SI request to RRC, the UE RRC should backoff
`for 1 full BCCH Modification period before attempting UE request again. During the backoff period,
`the UE should monitor SIB 1 to find out whether the required SI will be broadcast.
`Proposal#6_1: During the backoff period, if the SIB 1 indicates the required SI is broadcast, the UE
`can perform SI (re)acquisition procedure
`Proposal#6_2: At the expiry of the backoff period, the UE can attempt the UE request again for the
`required SI.
`Proposal#7: Upon successful receiving the acknowledgement of the on-demand SI request, the UE
`performs SI acquisition immediately at the next SI window where the SI is scheduled as indicated in
`SIB1.
`Proposal#8: The UE soft combines every valid TTI where the SI is PDCCH scheduled within the SI
`window. It is left to UE implementation whether UE soft combine across over multiple SI windows.
`Proposal#9: The same UE approach on deciding SI (re)acquisition failure is specified for both the on-
`demand SI case as well as periodic broadcast SI case.
`Proposal#10: Upon failure to acquire SI which contains only non-essential SIB(s), the UE can backoff
`for 1 BCCH Modification period before attempting again. During this period, the UE should monitor
`SIB1 to find out whether the required SI is being broadcast and continue to acquire it as long as the
`requested SI is broadcast. At expiry, if the requested SI is not broadcast, the UE can attempt the on-
`demand request again.
`Proposal#11: In idle mode, UE does not perform UE request for on-demand SI after the gNB notifies
`the SI modification. UE will acquire the on-demand SI as like periodic broadcast SI (i.e. the gNB
`broadcast the on-demand SI when the SI changes).
`Proposal#12: For Rel-15, if it contains only operational SIBs(i.e. SIB that all UEs always need in a
`serving cell, e.g. RMSI (SIB1), cell reselection SIBs (intra-frequency, inter-frequency and inter-RAT to
`EUTRA cell reselection SIB)) and PWS SIB, there is no need for UE request in RRC Connected.
`
`Ex.1019
`APPLE INC. / Page 6 of 6
`
`