3GPP TSG-RAN WG2 Meeting #101
`Athens, Greece, 26th February - 2nd March 2018
`Source:
`CATT
`Title:
`Remaining issues of on-demand SI
`Agenda Item:
`10.4.1.6.6
`Document for: Discussion and Decision
`
`R2-1801831
` Resubmission of R2-1800140
`
`Introduction
`1.
`In RAN2 Adhoc NR#2 meeting, the email discussion of on-demand SI has been discussed and some agreements
`are achieved as follows.
`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
`In this contribution we analyze the remaining issues for Msg1 and Msg3 based SI request procedures.
`
`2. Discussion
`2.1. Msg1 based SI request procedure
`In [1], when Msg1 for SI request re-transmission is continued until reaching max preamble transmissions, a
`random access problem from MAC is indicated to upper layers. Therefore, what actions the upper layer performs
`are discussed, and 4 possible alternatives are:
` Alternative 1: UE shall treat the cell as barred.
` Alternative 2: Depends on the SI/ SIBs being requested. If these are not the essential SIBs, then UE refrains
`from retrying until a certain time. The prohibit timer, if any, might be specified or be configurable. In case
`of essential SIBs, the UE shall treat the cell as barred.
` Alternative 3: Up to UE implementation – some UEs, who need certain non-essential feature-specific SIBs
`that are important/ critical for its operation, may treat the cell as barred while other UEs may prefer to
`resend SI request after certain prohibit timer.
` Alternative 4: Do nothing – MAC continues Msg1 transmission endlessly.
`
`R2-1801831
`
`1
`
`Ex.1023
`APPLE INC. / Page 1 of 3
`
`

`

`
`
`Since Alt4 is not advantageous for UE power consumption, we preferred to exclude it. For Alt1 and Alt2,
`something needs to be specified for upper layers while Alt3 is up to UE implementation. For Alt2 and Alt3, on-
`demand SIs are divided into essential SIBs and no-essential SIBs while Alt1 is the unified solution for all on-
`demand SIs.
`It is agreed that scheduling information in minimum SI includes an indicator whether the concerned SI-block is
`periodically broadcasted or provided on demand. So UE knows what on-demand SIs there are and requests what
`it is needed. If network is provisioning some SIs while UE cannot acquire them, then there is radio link quality
`problem to the cell.
`For connected mode, upon radio link quality problem, UE can receive PBCH but no dedicated data in case that
`UE is downlink synchronized but not uplink synchronized to the cell. Then UE does not treat the cell as barred,
`but perform RRC connection reestablishment. For idle mode, UE does not have a specified procedure. And RRC
`connection reestablishment cannot work for on-demand SI random access (RA) problem. This is why a new
`procedure is required.
`If on-demand SI request is failed and there is RA problem, UE cannot obtain the desired SIs. We prefer to
`specify the unified upper layers actions for all on-demand SIs without additional complexity in categorizing on-
`demand SIs into essential SIBs and no-essential SIBs. Thus, we propose Alt1 that UE shall treat the cell as
`barred and perform cell re-selection, when MAC reports random access problem to upper layer for Msg1 based
`SI request procedure.
`Proposal1: UE shall treat the cell as barred and perform cell re-selection, when MAC reports random
`access problem to upper layer for Msg1 based SI request procedure.
`
`2.2. Msg3 based SI request procedure
`It is agreed that RRC signalling is used for SI request in Msg3, and RRC signalling how to indicate the requested
`SI/SIB details is left to ASN.1 work. Here we’d like to clarify what RRC message is used for SI request in Msg3,
`and there are 2 cases as below.
` Case1: reuse LTE RRC message, such as RRCConnectionRequest, and a requested SI/SIB indication is
`included
` Case2: specify a new RRC message, such as RRCSystemInfoRequest, and a requested SI/SIB indication is
`included
`To reuse the LTE RRC message needs to extend the legacy RRC message with additional SI/SIB bitmap, which
`may introduce confusions to the legacy procedures (e.g. RRC connection establishment procedure). And the
`network may confuse whether it is for on-demand SI request or for both RRC connection establishment and on-
`demand SI request. In addition, the reused LTE RRC message for SI request can only be used by idle/inactive
`UEs. For UEs in connected mode, a new RRC message is anyway needed for SI request.
`To specify a new RRC message can avoid confusions between the legacy procedures (e.g. RRC connection
`establishment procedure) and on-demand SI request procedure, and the new RRC message is specified for
`different purpose. In addition, it is beneficial for specification simplification that the RRC message for SI request
`can be used by UEs in both connected mode and idle/inactive mode. And RRC signalling design should be
`considered such as signalling formats, contents and logical channel, etc.
`Proposal2: a new RRC message (RRCSystemInfoRequest) is specified for SI request in Msg3 and it can
`also be used for UEs in RRC_CONNECTED.
`It is agreed that for MSG1 based SI request, the minimum granularity of requested SI is one SI message (a set of
`SIBs as in LTE). [2] Similar with the agreement, we propose:
`Proposal3: for MSG3 based SI request, the minimum granularity of requested SI is one SI message (a set
`of SIBs as in LTE).
`Therefore, a requested SI message indication is included in the RRCSystemInfoRequest message. And we
`suggest it could be a requested SI message bitmap.
`Proposal4: a requested SI message indication is included in the RRCSystemInfoRequest message, e.g. a
`requested SI message bitmap.
`It is agreed that UE determines successful Msg3 based on reception of Msg4, and details of the Msg4 content
`used to confirm successful Msg3 is FFS. According to the previous agreements, only progress on the two agreed
`approaches for delivering on-demand system information (via dedicated signalling to RRC_CONNECTED UEs;
`via SI-Message broadcast to RRC_IDLE and RRC_INACTIVE UEs) and refrain from introducing additional
`
`R2-1801831
`
`2
`
`Ex.1023
`APPLE INC. / Page 2 of 3
`
`

`

`
`
`solution variants, which means Msg4 should not contain the required SIs. So Msg4 is only the response for Msg3,
`and there are 2 cases as below.
` Case1: Msg4 may only contain MAC CE including the CCCH SDU transmitted in Msg3 and no RRC
`message is needed.
` Case2: Msg4 may contain MAC CE and a new specified RRC message, such as RRCSystemInfoResponse.
`For UEs in connected, dedicated RRC signalling can be used for the request and delivery of other SI. Thus,
`Msg1 and Msg3 based SI request procedures are used for idle/inactive UEs. In normal RA procedure for
`idle/inactive UEs, Msg4 containing UE Contention Resolution Identity MAC CE can be transmitted with or
`without RRC message at the same time. Thus, there is commonality between normal RA and on-demand SI RA
`in both cases. In addition, a new specified RRC message will increase the specification complexity. Therefore,
`we propose that Msg4 may only contain MAC CE including the CCCH SDU transmitted in Msg3 for Msg3
`based SI request procedure, which has commonality to normal RA procedure. [3]
`Proposal5: Msg4 may only contain MAC CE including the CCCH SDU transmitted in Msg3 for Msg3
`based SI request procedure, which has commonality to normal RA procedure.
`
`
`3. Conclusion
`According to the analysis in section 2, we propose for Msg1 and Msg3 based SI request procedures:
`Proposal1: UE shall treat the cell as barred and perform cell re-selection, when MAC reports random
`access problem to upper layer for Msg1 based SI request procedure.
`Proposal2: a new RRC message (RRCSystemInfoRequest) is specified for SI request in Msg3 and it can
`also be used for UEs in RRC_CONNECTED.
`Proposal3: for MSG3 based SI request, the minimum granularity of requested SI is one SI message (a set
`of SIBs as in LTE).
`Proposal4: a requested SI message indication is included in the RRCSystemInfoRequest message, e.g. a
`requested SI message bitmap.
`Proposal5: Msg4 may only contain MAC CE including the CCCH SDU transmitted in Msg3 for Msg3
`based SI request procedure, which has commonality to normal RA procedure.
`
`4. Reference
`[1] R2-1707090 Summary of [98#34][NR] On demand SI (Lenovo) Lenovo, Motorola Mobility
`[2] 3GPP RAN2 #98 Chairman’s note, May, 2017
`[3] R2-1800161 RA procedure for Msg3 based SI request CATT
`
`R2-1801831
`
`3
`
`Ex.1023
`APPLE INC. / Page 3 of 3
`
`