3GPP TSG-RAN WG2#101
`Athens, Greece, Feb 26 – Mar 2, 2018
`
`R2-1803366
`resubmission of R2-1801190
`
`
`Agenda Item:
`10.4.1.6.6
`Huawei, HiSilicon
`Source:
`Title:
`Failure handling for on-demand SI acquisition
`Document for: Discussion and decision
`
`1 Introduction
`In RAN2 AH#2 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
`
`
`
`In RAN2 99 meeting, the following agreements are achieved for MSG1 based on-demand SI request:
`Agreements
`1. RRC triggers MAC to initiate Random Access procedure for the purpose of SI-request. For
`the case of msg1-based request procedure RRC indicates to MAC the PRACH
`preamble/resource.
`2. For msg. 1-based SI request MAC indicates to RRC the reception of acknowledgement for SI
`request
`3. The UE is not expected to perform multiple mgs.1-based SI request RA procedures
`simultaneously. A single msg.1-based SI request will be performed at a time.
`4. For msg1-based request procedure, the RACH msg2 contains only the MAC PDU subheader
`for a RAR containing the Random Access Preamble ID field acknowledging the received
`PRACH SI preamble.
`
`
`As shown above, how to send the SI request via MSG1 or MSG and how to receive corresponding SIBs were discussed
`in previous meetings. But how to perform failure handing in case SI has not been discussed yet. So this paper provides
`design for failure handling of SI request especially for MSG3 based SI request.
`
`3GPP
`
`Ex.1018
`APPLE INC. / Page 1 of 2
`
`

`

`2 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, LTE procedure for contention resolution failure can be re-used. Under such procedure, if the maximum SI
`request number is not reached, HARQ buffer for MSG3 is flushed, PREAMBLE_TRANSMISSION_COUNTER is
`incremented by 1 and MSG1 is transmitted to deprive resource for SI request (MSG3). The power ramping can be
`applied according to NR RACH power ramping as MSG1 based mechanism.
`Proposal 1: For MSG3 based SI request, if SI request response (i.e. MSG4) is not received, and the maximum
`SI request number is not reached, re-use LTE procedure for contention resolution failure in order
`to retry Msg3 transmission (i.e. flush HARQ buffer, increment preamble transmission counter,
`etc. ).
`
`
`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 2: A maximum SI request number and monitoring time duration should be included in minimum SI
`for MSG3 based SI request.
`Proposal 3: If SI request reaches the maximum number, the UE can label the SI as not available in the cell or
`trigger cell reselection.
`
`2 Conclusion
`In this paper, we discuss the design for connected mode SI request and have the following proposals:
`Proposal 1: For MSG3 based SI request, if SI request response (i.e. MSG4) is not received, and the maximum
`SI request number is not reached, re-use LTE procedure for contention resolution failure in order
`to retry Msg3 transmission (i.e. flush HARQ buffer, increment preamble transmission counter,
`etc. ).
`Proposal 2: A maximum SI request number and monitoring time duration should be included in minimum SI
`for MSG3 based SI request.
`Proposal 3: If SI request reaches the maximum number, the UE can label the SI as not available in the cell or
`trigger cell reselection.
`
` 3
`
` Reference
`[1] 3GPP RAN2 AH2, Chairman’s note, June, 2017.
`[2] 3GPP RAN2#99, Chairman’s note, August, 2017.
`
`3GPP
`
`Ex.1018
`APPLE INC. / Page 2 of 2
`
`