3GPP TSG-RAN WG2 #99 Meeting
`Berlin, Germany, 21 – 25 August, 2017
`
`R2-1708072
`Revision of R2-1706768
`
`Source:
`Title:
`Agenda Item:
`Document for:
`
`Huawei, HiSilicon
`On demand SI acquisition and failure handling
`10.4.1.5.5
`Discussion and decision
`
`1 Introduction
`In RAN 2 NR Ad-hoc#1 meeting, there is highlighted FFS on whether there is a need for an additional indication that
`an on-demand SI is being broadcast or not.
`
`Agreements related to SI provided by broadcast
`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.
`
`The last RAN2 Ad hoc meeting, the following agreements are achieved for MSG1 and MSG3 based on-demand SI
`request:
`Agreements for Msg1 based SI request method:
`1: RAPID is included in Msg2.
`2: Fields Timing Alignment Information, UL grant and Temporary C-RNTI are not included in
`Msg2.
`3: RACH procedure for SI requests is considered successful when Msg2 containing a RAPID
`corresponding to the transmitted preamble is received.
`4: Msg2 reception uses RA-RNTI that corresponds to the Msg1 transmitted by the UE (details
`of RA-RNTI selection left to UP discussion)
`5: UE retransmits RACH preamble according to NR RACH power ramping
`6: Msg1 for SI request re-transmission is continued until reaching max preamble transmissions.
`Thereafter, a Random Access problem to upper layers is indicated. (depending on the NR
`RACH procedure design)
`FFS: Upper layer actions when MAC reports Random Access problem. To be discussed in CP
`session.
`7: Back off is applicable for Msg1 based SI requests but no special Back off subheader/
`procedure is required.
`
`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
`
`However, some issues still need to be addressed for MSG1 and MSG3 based SI request. This paper further discusses
`issues related to other SI request.
`
`3GPP
`
`Ex.1013
`APPLE INC. / Page 1 of 8
`
`

`

`2 Indication for other SI
`Before UE sends SI request, the UE needs to check the indication in minimum SI. This section further discusses the
`solutions of indication of other SI in minimum SI.
`
`Two design options for the indication were discussed in previous papers [1] [2]:
`
`Option a): a single bit that is dynamically changed to indicate a SIB is periodically broadcasted or provided on demand;
`
`Option b): two bits are configured per other SI in scheduling information: the first indicator indicates whether the other
`SI is periodically broadcasted or provided on demand while the second one indicates whether the on-demand other SI is
`actually being temporarily broadcasted.
`
`According to [3], the scheduling information in minimum SI includes an indicator whether the concerned SI-block is
`periodically broadcasted or provided on demand. If minimum SI indicates that a SIB is not broadcasted, then UE does
`not assume that this SIB is a periodically broadcasted in its SI-window at every SI periodicity. For the UE needs to acquire
`the SIB, it can send an SI request to receive this SIB if it is not acquired.
`
`For option a, when the network broadcasts the requested other SI, it can change the related indicator to indicate that the
`SIB is broadcasted. For a later UE (e.g. entering the cell after the SI has started to be broadcast), if it wants the SIB and
`checks the indicator, it finds that the wanted SIB is being broadcasted. As a result, unnecessary SI requests will be avoided.
`
`For option b, the network will keep the first indicator and change the second one if the requested on demand other SI is
`being broadcasted. For a later UE, it checks the second indicator and will not trigger SI request.
`
`Based on the above discussion, it is worth noting that a single indicator can prevent the unnecessary SI requests from
`other UEs for a SIB while the SIB is being broadcasted due to one UE’s request. There is no need for an additional
`indication for this purpose. In addition, option b) introduces extra overhead.
`
`There are two solutions to signal the explicit indicator for option a):
`
`Solution 1): the indicator is included in each scheduling information IE of corresponding SIB as one bit indication;
`
`Solution 2): the indicator is formed as a bitmap, in a separate IE to the scheduling information sub-item of the other
`SIB.
`
`For solution 2), the UE doesn’t need to check each of the specific contents of scheduling information of the other SIB
`for detecting whether it is broadcast or not. It can determine the information just by checking the bitmap IE. And as it is
`a relatively independent IE, the change operation can be decoupled with the specific content of scheduling information
`of the other SIB rather than waiting for a modification period boundary it can be updated immediately. Furthermore, if
`the bitmap is signaled in a fixed SIB sequence (i.e. each bit in the bitmap always refers to the same SIB), regardless of
`whether the gNB broadcasts that SIB or not, the UE may directly be aware of whether to send a SI request or not
`without further having to refer e.g. to the order of SIBs in the scheduling information. Therefore, it is proposed:
`Proposal 1: Signal a single bit per SIB that is dynamically changed for indication of whether one on-demand SI
`is broadcast or not, and the indication is broadcast in the form of bitmap in a separate IE.
`Additionally, the change frequency of the indication depends on that of the UE’s SI request. And the requested UE needs
`not to know the indication change triggered by itself. Therefore, the UE is not required to update the bitmap all the time.
`Conversely, it is beneficial for the UE only to update the bitmap before initiating the related Other SI request.
`Proposal 2: The UE is only required to check the latest bitmap before initiating the Other SI request.
`For the UE, after sending the OSI request, it will not wait to check whether the bitmap changes. To help the UE acquire
`the requested OSI as soon as possible, it is desirable that the network can deliver the requested OSI in the nearest SI
`window no matter whether the bitmap changes. From a network perspective, the SI can be delivered as soon as possible
`without waiting for some specific transmission window, e.g. modification period.
`Proposal 3: If SI is requested, it can be delivered at any time, i.e. SI delivery is not restricted to some modification
`period.
`Proposal 4: After sending SI request, the UE can check immediately whether the requested SI is broadcast or
`not, even if the bitmap is not changed in minimum SI.
`
`
`
`3GPP
`
`Ex.1013
`APPLE INC. / Page 2 of 8
`
`

`

`Fig 1 below shows general illustration of the above solutions.
`
`Modification period N
`
`Modification period N+1
`
`Step 1: Bit in bitmap
`indicates that SIBx will be
`delivered on-demand
`
`Broadcast period k for bitmap
`Bitmap is transmitted twice with
`the same content
`
`------.------ D D
`
`,
`
`Broadcast period k+1
`
`Broadcast period k+2
`
`Broadcast period k+3
`
`D
`
`D
`
`D
`
`D
`
`D
`
`SIBx
`
`SIBx
`
`quest
`
`SI re
`I
`
`Step 2: SI request of
`SIBx is sent
`
`Step 3: the nearest SI window is
`earlier than bitmap, the UE
`directly tries to receive the Six
`
`Bitmap changes in K+1 period
`within modification period N
`
`
`
`Fig 1: the procedure of bitmap changes and SI acquisition for UE
`
`
`
`3 SI request
`According to the agreements in the last meeting, after successfully sending the SI request via MSG1 or MSG3, for
`receiving the requested SIB, the UE monitors the SI window of the requested SIB in one or more periods according to the
`SI scheduling information indicated in MSI (Minimum SI). In the following sections, we will give detailed considerations
`on how to design MSG1 and MSG3 based request, acknowledgement transmission after SI request and the error handling
`mechanism.
`3.1 MSG1 based other SI request
`MSG1 based SI request will transmit a preconfigured preamble corresponding to the requested SIB(s) on the
`preconfigured PRACH resource. The number of preambles is limited. If too many preambles are allocated for SI request,
`it will reduce the available preambles for normal RACH and consequently lead to a higher collision probability of RACH.
`In order to avoid the impacts on the normal RACH, we think preambles for SI request should not be reserved on all of
`PRACH resources, i.e. only part of PRACH resources can be used to reserve preambles for on demand SI request. The
`possible solutions can be:
`Solution1: To reserve preambles for SI request on the same PRACH resource. The remaining of preambles can be
`-
`used for normal RACH on this resource.
`Solution 2: To reserve preambles for SI request on different PRACH resources. For example, if 4 preambles are
`reserved for SI request, these 4 preambles can be reserved on different PRACH resources. The preambles reserved
`on different PRACH resource can be the same but for different SI request.
`The mapping of reserved preambles, PRACH resources and corresponding SI should be indicated to UE in Remaining
`Minimum SI.
`
`
`-
`
`
`
`3GPP
`
`Ex.1013
`APPLE INC. / Page 3 of 8
`
`

`

`These solutions can be shown in Fig.2 as below.
`
`Resource for SI request, e.g.
`preamble 1-4
`
`f
`
`Resource for SI
`request, e.g.
`preamble 1-2
`
`Resource for SI
`request, e.g.
`preamble 3-4
`
`f
`
`Resource used
`only for RACH
`
`Resource used
`only for RACH
`
`...
`
`...
`
`...
`
`...
`
`(a)
`
`t
`
`(b)
`
`t
`
`
`
`Fig 2: PRACH resource and preamble allocation for MSG1 based other SI request
`For solution 1 as shown in Fig 2(a), all SI requests are initiated on the same resource and it could lead to the simultaneously
`SI transmission. However from configuration point of view, this solution could be simpler than the second one.
`For solution 2 as shown in Fig 2 (b), the SI requests are distributed on multiple slots and the simultaneous SI request can
`be reduced. Although this solution may need more signalling, it is more flexible than solution 1.
`We should avoid reservation on all PRACH resources for all SIs request considering normal RACH should not be
`impacted because of SI request.
`Proposal 5: For MSG1 based method, SI can be requested on different PRACH Time/Frequency resource and
`the same preamble on different T/F resource can be used to request different SI.
`3.2 MSG3 based other SI request
`For MSG3 based SI request, there are still some issues which need to be addressed, and we will discussed one by one in
`the following section.
`1. What’s the granularity of requested SI for MSG3 SI request?
`In RAN2#98 meeting, it was agreed that for MSG1 based SI request, the minimum granularity of requested SI is one SI
`message. However there is no confirmation on the minimum granularity of MSG3 based SI request. In our understanding,
`the minimum granularity of SI request in MSG3 is also one SI message.
`Proposal 6: For MSG3 based method, the minimum granularity of requested SI is one SI message.
`2. What RRC message should be used to request SI for MSG3 based solution?
`It is agreed in the last meeting that RRC signalling is used for SI request in Msg3. But which RRC message is used for
`such request is not clear.
`In LTE, only RRCConnectionRequest and RRCConnectionReestablishmentRequest can initiate service in RRC layer. In
`our understanding, both of them are not suitable for SI request. So, a new type of service request RRCSystemInfoRequest
`can be defined in order to support SI request.
`Proposal 7: A new type of RRC message RRCSystemInfoRequest should be defined to support SI request.
`For the UE in RRC_IDLE, there is no dedicated resource or security activation. The message can only be transmitted via
`CCCH with the signalling radio bearer of SRB0. For inactive state UE, it depends on the detailed design.
`Accordingly, for the UE in RRC_IDLE, the message can only be transmitted via CCCH. The RLC Mode can only be TM
`mode. For inactive state UE, it depends on the detailed design.
`Proposal 8: For the UE in RRC_IDLE state, the SI request is sent via CCCH with the signalling radio bearer of
`SRB0, and the RLC Mode for SI request can only be TM mode. Inactive state UE needs further
`discussion.
`In the last meeting, bitmap based RRC message was discussed, but how to indicate the requested SI/SIB details of the
`RRC was left to ASN.1 work. Our understanding is that the basic principle shall be defined and we propose the following
`table of RRC content for MSG3 based SI request message for the two states:
`
`3GPP
`
`Ex.1013
`APPLE INC. / Page 4 of 8
`
`

`

`
`
`Content
`
`Table 1 a profile of the SI request message for the two states
`RRC_Idle
`RRC_Inactive
`
`requested
`information
`
`requested
`information
`
`SI
`
`mandatory
`
`mandatory
`
`UE
`
`mandatory
`
`mandatory
`
`The Signalling radio bearer
`
`The RLC Mode
`
`CCCH
`
`TM mode
`
`FFS
`
`FFS
`
`Based on the above table, we provide ASN.1 of the SI request message:
`–
`SIRequest
`The SIRequest message is used to request the other SI.
`
`Signalling radio bearer: SRB0
`
`RLC-SAP: TM
`
`Logical channel: CCCH
`
`Direction: UE to NR
`
`RRCSystemInfoRequest message
`
`-- ASN1START
`
`RRCSystemInfoRequest-r15 ::= SEQUENCE {
`
`criticalExtensions
`
`
`
`CHOICE {
`
`
`RRCSystemInfoRequest-r15
`
`
`RRCSystemInfoRequest-r15-IEs,
`
`
`criticalExtensionsFuture
`
`
`SEQUENCE {}
`
`}
`}
`
`RRCSystemInfoRequest-r15-IEs ::= SEQUENCE {
`
`request-SIType-List
`
`
`BIT STRING (SIZE (40)),
`
`spare
`
`
`
`
`
`
`BIT STRING (SIZE (8))
`}
`
`-- ASN1STOP
`
`Proposal 9: Use the ASN.1 above as baseline for MSG3 based RRC message. Each bit of the bitmap corresponds
`to one SI in the same order as appeared in the scheduling information.
`3. What’s the content of MSG4?
`In the last meeting, it was agreed that UE determines successful MSG3 based on reception of MSG4. But as for the content
`of MSG4 used to confirm successful MSG3, it was left for FFS.
`As discussed above, it’s possible that multiple UEs may use the same preamble to initiate RACH at the same time. In this
`case, contention will happen and there are at least two cases should be considered:
`Case 1: the contention is between a normal RACH UE and the UE for SI request or two UEs request different SIs.
`Case 2: the contention is between UEs request for the same SIs;
`For the first case, network can only send one acknowledgement with contention resolution ID to one of them if legacy
`RACH procedure is followed. The legacy contention resolution method makes sure the following allocated radio
`resources can be used for one certain UE. But from the UE(s) sending SI request perspective, it has no data which needs
`to be transmitted and it only cares whether SI request for specific SI is received by the network In this case, one possible
`solution is that network indicates SI requests received for SI based request. This indication can be one bit, a bitmap
`corresponding to SIs, or something else. This indication is not used for contention resolution, and it is just regarded as the
`acknowledgement of MSG3 SI request. If UE receives this indication, it ignores the contention resolution ID and to
`receive SI for some duration, if the SI is not what it requested, it will request again.
`
`3GPP
`
`Ex.1013
`APPLE INC. / Page 5 of 8
`
`

`

`For the second case, if the MSG4 from network has no corresponding contention resolution ID for the UE, the contention
`resolution will fail for this UE even though they are requesting for the same SIs if legacy contention resolution is used.
`The same method as described for case 1 also can be used. Another possible solution is to make the UEs request for the
`same SI have same UE ID for resolution.
`For both cases, after sending SI request in MSG3, UE can check whether the requested SI is broadcast or not, as well as
`the acknowledgement for MSG3 during the widnow of contention resolution. If the requested SI is broadcast, the UE can
`read the SI and ignore the acknowledgement.
`Proposal 10: An indication in MSG4 is used to indicate SI request is received by the network. If this indication
`indicates SI request has been received, the UE skips checking contention resolution ID and proceeds
`to receive SI.
`If considering the UE only sends SI request, as per proposal 7, a new RRC message type is used for SI request. Then, the
`indication with a bitmap can be used to replace contention resolution ID using UE ID or a random value in LTE because
`a bitmap indicates which SI will be broadcast due to SI request is enough for the UE to receive SI.
`For example UE1 requests SI1, SI2, and UE2 requests SI1, SI2, SI3. If the network indicates SI1, SI2, SI3 will be
`broadcast, both UEs should consider SI request is successful. If the network indicates SI1 and SI2 will be broadcast, UE2
`considers its SI request is failed. In this case, the UE should check whether the SIs that the network will broadcast include
`the SIs it requests.
`Proposal 11: Instead of contention resolution MSG4 includes a bitmap to allow multiple UEs requesting SI
`messages using same PRACH resource (time/frequency/preamble resource) to check the requested
`SI is included in the bitmap or not.
`
`4. RRC response is needed or not?
`When the UE sends SI request, it will receive the response from network. If the RACH procedure using for SI request
`failed, UE will send indication to RRC. Otherwise, UE will receive SI based on the request from RRC. So, there is no
`need for the network to send RRC response to UE after MSG4.
`Proposal 12: RRC response message is not needed for MSG3 based SI request.
`3.3 Connected mode SI request
`Connected mode SI request has not been discussed yet. Compared with idle/inactive mode SI request, it would be easier
`for connected mode to request SI.
`For connected state UE with valid TA, UE can request only the SIBs that are necessary in order to save signalling overhead.
`On the other hand, one UE can request multiple SIBs in one request. A new RRC message with a bitmap for each SIB
`shall be used for connected mode UE to request SI.
`While for connected state UE without valid TA, according to the agreement in RAN2#96 meeting that for UEs in
`connected, dedicated RRC signalling can be used for the request and delivery of other SI, UE shall initiate the RACH
`procedure to synchronize to the network and then acquire the SI using RRC message. However, the content of the RRC
`message for connected UEs was not discussed yet. In our understanding, the content of the RRC message for connected
`UE is based on a bitmap for each SIB because the granularity for connected mode UE can be different from idle/inactive
`mode UEs.
`Proposal 13: RRC message with bitmap for each SIB shall be used for connected mode SI request.
`Proposal 14: For connected state with valid TA, the minimum granularity of requested system information is SIB
`in order to save the signalling overhead and one request procedure can request one or multiple SIBs.
`Proposal 15: For connected state without valid TA, the UE initiates RACH procedure to synchronize to the
`network and uses dedicate RRC SI request to acquire on-demand SI.
`
`
`
`
`
`
`3GPP
`
`Ex.1013
`APPLE INC. / Page 6 of 8
`
`

`

`3.4 Failure handing in case SI is not received
`It was previously agreed to use retransmissions in the case of MSG1 transmission failure. But for MSG3 based SI request,
`if the corresponding SI request response (i.e. MSG4) is not received during configured monitoring time, how to handle it
`was not discussed yet.
`In this case, UE shall initiate another round of SI request based on back off indication(if included in the received RAR)
`until the maximum request number is reached. The power ramping can be applied according to NR RACH power ramping
`as MSG1 based mechanism.
`Proposal 16: For MSG3 based SI request, if SI request response (i.e. MSG4) is not received, and the maximum SI
`request number is not reached, another RACH procedure shall be started in order to retry Msg3
`transmission.
`For each SI request, a maximum SI request number should be defined. For MSG1 based request, the maximum SI request
`number can follow the normal RACH procedure. For MSG3 based SI request the maximum SI request number for MSG3
`based SI request should be configured in minimum SI. If SI request reaches the maximum number, the on-demand SI
`request shall be considered failed, the UE behaviour of failure of on-demand SI request may be different depending on
`whether the requested SI impacts the service or not. If the requested on-demand SI doesn’t prevent the UE from using
`regular services, UE can just label the SI as not available in the cell and mark the function as unavailable. Otherwise, cell
`reselection can be triggered when the request of SI reaches the maximum number.
`Proposal 17: A maximum SI request number and monitoring time duration should be included in minimum SI for
`MSG3 based SI request.
`Proposal 18: If SI request reaches the maximum number, the UE can label the SI as not available in the cell or
`trigger cell reselection.
`
`4 Conclusion
`In this paper we discuss the design for MSG 1 based request and failure handling, and have the following proposals:
`Proposal 1: Signal a single bit per SIB that is dynamically changed for indication of whether one on-demand SI
`is broadcast or not, and the indication is broadcast in the form of bitmap in a separate IE.
`Proposal 2: The UE is only required to check the latest bitmap before initiating the Other SI request.
`Proposal 3: If SI is requested, it can be delivered at any time, i.e. SI delivery is not restricted to some modification
`period.
`Proposal 4: After sending SI request, the UE can check immediately whether the requested SI is broadcast or
`not, even if the bitmap changing in minimum SI is not acquired.
`Proposal 5: For MSG1 based method, SI can be requested on different PRACH Time/Frequency resource and
`the same preamble on different T/F resource can be used to request different SI.
`Proposal 6: For MSG3 based method, the minimum granularity of requested SI is one SI message.
`Proposal 7: A new type of RRC message RRCSystemInfoRequest should be defined to support SI request.
`Proposal 8: For the UE in RRC_IDLE state, the SI request is sent via CCCH with the signalling radio bearer of
`SRB0, and the RLC Mode for SI request can only be TM mode. Inactive state UE needs further
`discussion.
`Proposal 9: Use the ASN.1 above as baseline for MSG3 based RRC message. Each bit of the bitmap corresponds
`to one SI in the same order as appeared in the scheduling information.
`Proposal 10: An indication in MSG4 is used to indicate SI request is received by the network. If this indication
`indicates SI request has been received, the UE skips checking contention resolution ID and proceeds
`to receive SI.
`Proposal 11: Instead of contention resolution MSG4 includes a bitmap to allow multiple UEs requesting SI
`messages using same PRACH resource (time/frequency/preamble resource) to check the requested
`SI is included in the bitmap or not.
`Proposal 12: RRC response message is not needed for MSG3 based SI request.
`Proposal 13: RRC message with bitmap for each SIB shall be used for connected mode SI request.
`
`3GPP
`
`Ex.1013
`APPLE INC. / Page 7 of 8
`
`

`

`Proposal 14: For connected state with valid TA, the minimum granularity of requested system information is SIB
`in order to save the signalling overhead and one request procedure can request one or multiple SIBs.
`Proposal 15: For connected state without valid TA, the UE initiates RACH procedure to synchronize to the
`network and uses dedicate RRC SI request to acquire on-demand SI.
`Proposal 16: For MSG3 based SI request, if SI request response (i.e. MSG4) is not received, and the maximum SI
`request number is not reached, another RACH procedure shall be started in order to retry Msg3
`transmission.
`Proposal 17: A maximum SI request number and monitoring time duration should be included in minimum SI for
`MSG3 based SI request.
`Proposal 18: If SI request reaches the maximum number, the UE can label the SI as not available in the cell or
`trigger cell reselection.
`
` 5
`
` Reference
`Indication for On-Demand SI Broadcast Nokia, Alcatel-Lucent Shanghai Bell
`[1] R2-1706822
`[2] R2-1706768 On demand SI acquisition and failure handling Huawei, HiSilicon
`[3] TS 38.304 e.0.0
`[4] 3GPP RAN2#97bis, Chairman’s note, April, 2017.
`[5] 3GPP RAN2#AH, Chairman’s note, January, 2017.
`[6] Samsung, “On Demand SI Request TX”, R2-1702970, Spokane, USA, April 3 - 7 2017.
`[7] LG Electronics Inc, “SI request procedure using MSG3”, R2-1703602, Spokane, USA, April 3 - 7 2017.
`[8] Samsung, “On Demand SI Delivery: Signaling Aspects”, R2-1700011, Spokane, USA, January 17- 19
`2017.
`[9] 3GPP RAN2#98, Chairman’s note, May, 2017.
`
`
`3GPP
`
`Ex.1013
`APPLE INC. / Page 8 of 8
`
`