3GPP TSG RAN WG2 Meeting #101
`Athens, Greece, 26th February – 2nd March 2018
`
`R2-1802094
` (Resubmission of R2-1800875)
`
`vivo
`Source:
`Remaining issues of on demand SI
`Title:
`10.4.1.6.6
`Agenda Item:
`Document for: Discussion and Decision
`
`1. Introduction & Background
`During the last few RAN2 meetings, details of on demand SI acquisition mechnism were discussed and some
`progress was made. However, there are still some remaining issues to be addressed.
`In this paper, we fouce on the following issues:
`- Need of additional SI transmission indication;
`- Granularity of SI requested;
`- Msg3/Msg4 contents for Msg3 based SI request approach.
`
`2. Discussion
`2.1. Need of additional SI transmission Indication
`In the January 2017 RAN2 adhoc meeting, one issue of additional SI transmission Indication is identified as
`following:
`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 additional indicator intends to depress the redundant SI request from one UE if the broadcast of the
`concerned SI has already been triggered by another UE. Obviously, the indicator reduces the load of RACH and
`UE power consumption. However, it has the drawback that the UE is required to read the additional indicator
`before sending the SI request. But please note that doesn’t mean UE always has to perform extra SI reading for
`the indicator before sending SI request. In most cases, UE attempts to obtain all the interested SI when it enters a
`new cell, i.e. UE obtains the scheduling information in RMSI first, and then decide whether to send SI request
`according to additional indicator in the scheduling information. Since UE anyway needs to obtain the RMSI
`while entering a new cell, the acquisition of the additional indicator leads almost no impact to UE.
`Hence, we think the advantages of the additional indicator outweigh the disadvantages. We prefer to introduce
`the additional indication. Given the minimum granularity of SI broadcasting is one SI message, we propose:
`Proposal 1: There is one additional indication per on demand SI message, which indicates whether the SI
`message is actually being broadcast at this instant in time or not, in the scheduling information.
`
`Clearly, the change of the above additional indication doesn’t mean the content of the corresponding SI message
`is modified. Therefore, the change of indication, which may be frequent, should not trigger UEs to re-acquire SI.
`Proposal 2: The change of the additional indication should not trigger system information modification
`procedure, i.e. paging.
`
`2.2. Granularity of SI requested
`In RAN2#98 meeting, it was agreed that for MSG1 based SI request, the minimum granularity of requested SI is
`one SI message, since the minimum granularity of network broadcasting is one SI message. In our understanding,
`the minimum granularity of requested SI for MSG3 based SI request method can also be one SI message for the
`same reason.
`Proposal 3: For MSG3 based SI request, the minimum granularity of requested SI is one SI message.
`
`Ex.1008
`APPLE INC. / Page 1 of 3
`
`

`

`
`For RRC_CONNECTED UE, things are different. It was agreed that the requested SI is delivered to
`RRC_CONNECTED UE via dedicated signaling. This means it is possible for the network to deliver only the
`SIBs exactly needed by the UE. Obviously, delivering SIBs is more radio resource efficient than delivering the
`whole SI message if not all the SIBs in the SI message are requested. It makes sense to take one SIB as the
`minimum granularity of the requested SI for RRC_CONNECTED UE.
`Proposal 4: For SI request sent from the RRC_CONNECTED UE, the minimum granularity of requested
`SI is one SIB.
`
`2.3. Msg3/Msg4 contents for Msg3 based SI request approach
`In the June 2017 RAN2 adhoc meeting, some agreements for Msg3 based SI request method were reached:
`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
`Even though the detailed format of MSG3 is left to ASN.1, the content in MSG3 still needs to be agreed first.
`In our understanding, MSG3 based SI request procedure is contention tolerate and requires no full contention
`resolution. For example, two UEs send the same preamble on the same RACH occasion to initiate the MSG3
`based SI request, and the same SI messages are requested. According to the traditional understanding, this is a
`typical RACH collision, and can be solved by including unique UE ID in MSG3, the ID of the UE which wins
`the contention resolution is sent back in MSG4 to enable UE to check whether it is the winner. But in MSG3
`based SI request method, we have a better choice: make both UEs’ SI request procedure success, since both UEs
`can obtain the requested SI messages which are broadcasted and the network doesn't need to know by which UE
`the SI request is sent. With this in mind, the unique UE ID needs not to be included in the MSG3. With no
`unique UE ID in MSG3, one UE cannot decide whether received MSG4 carrying part information from MSG3 is
`the response to its request or to the other UE’s. But one UE can confirm the SI requested by it will be
`broadcasted if the received MSG4 matches the MSG3 sent. Hence, we say the contention is not fully resolved.
`Hence, we propose
`Proposal 5: Only the list of requested SI messages is included in the SI request RRC message for msg3
`based SI approach, i.e. unique UE id is not included.
`
`In the previous email discussion [1], most companies prefer to apply bitmap to indicate the requested SI
`messages list, since the size of MSG3 is limited. The details of the bitmap, e.g. the mapping between bit position
`and SI message requested can be discussed later.
`Proposal 6: A BITMAP where each bit indicates whether one SI message is requested or not is included
`in the MSG3, given the size limitation of MSG3. Details of the BITMAP are left to ASN.1 work.
`
`In LTE, a common MAC CE(i.e. UE Contention Resolution Identity MAC CE carring the first 6 bytes of MAC
`SDU in MSG3) is included in RACH MSG4 if the UE has no valid C-RNIT, no matter which RRC message is
`carried in MSG3. This design enables the UE MAC to identify whether it is responded by the network without
`understanding the high layer message. In NR, we propose to reuse the design principle, i.e. a common MSG4
`format is defined to response MSG3 for UEs with no valid C-RNIT, no matter which RRC message (RRC SI
`request message or RRCConnectionRequest etc.) is carried in MSG3. Therefore, the details of the Msg4 content
`for Msg3 based SI request approach can be decided in RACH procedure, and we think reuse the format of UE
`Contention Resolution Identity MAC CE is a possible way.
`Proposal 7: A common MSG4 format is defined to response MSG3 for UEs with no valid C-RNIT, no
`matter which RRC message (RRC SI request message or RRCConnectionRequest etc.) is carried in
`MSG3. Details of the Msg4 content for Msg3 based SI request approach can be decided in RACH
`procedure.
`
`3. Conclusion
`In this contribution, we discuss the remaining issues of the on demand SI and propose:
`Proposal 1: There is one additional indication per on demand SI message, which indicates whether the SI
`message is actually being broadcast at this instant in time or not, in the scheduling information.
`
`Ex.1008
`APPLE INC. / Page 2 of 3
`
`

`

`
`Proposal 2: The change of the additional indication should not trigger system information modification
`procedure, i.e. paging.
`Proposal 3: For MSG3 based SI request, the minimum granularity of requested SI is one SI message.
`Proposal 4: For SI request sent from the RRC_CONNECTED UE, the minimum granularity of requested
`SI is one SIB.
`Proposal 5: Only the list of requested SI messages is included in the SI request RRC message for msg3
`based SI approach, i.e. unique UE id is not included.
`Proposal 6: A BITMAP where each bit indicates whether one SI message is requested or not is included
`in the MSG3, given the size limitation of MSG3. Details of the BITMAP are left to ASN.1 work.
`Proposal 7: A common MSG4 format is defined to response MSG3 for UEs with no valid C-RNIT, no
`matter which RRC message (RRC SI request message or RRCConnectionRequest etc.) is carried in
`MSG3. Details of the Msg4 content for Msg3 based SI request approach can be decided in RACH
`procedure.
`
`References
`[1] R2-1707090 Summary of [98#34][NR] On demand SI (Lenovo) Lenovo, Motorola Mobility
`[2] R2-1705511 SI Request and Delivery using Msg 3 Approach Nokia, Alcatel-Lucent Shanghai Bell
`
`
`
`Ex.1008
`APPLE INC. / Page 3 of 3
`
`