`R2-1802093
`
`3GPP TSG RAN WG2 Meeting #101
`Athens, Greece, 26th February – 2nd March 2018 (Resubmission of R2-1800874)
`
`vivo
`Source:
`Failure Handling for On Demand SI Acquisition Procedure
`Title:
`10.4.1.6.6
`Agenda Item:
`Document for: Discussion and Decision
`
`1. Introduction
`In the RAN2#97bis meeting, the following FFS has been identified：FFS Error handing in case SI is not
`received. In this paper, we discuss how to handle the on demand SI acquisition procedure failure and give our
`preference.
`
`2. Discussion
`2.1. Detection of SI acquisition procedure failure
`It was agreed that the network broadcasts the requested SI messages after MSG1/3 based SI request is received.
`Hence one UE may receive the concerned SI messages even it fails to send the SI request, since the network may
`be triggered by other UEs to broadcast the SI messages. Therefore, the failure of RACH (e.g. the maximum
`number of preamble transmission is reached) during SI request transmission doesn’t always lead to the SI
`acquisition procedure failure.
`On the other hand, there is a certain probability that the UE fails to acquire the requested the SI messages, even
`after the reception of the SI request is acknowledged by the network, e.g. UE moves into a coverage hole while
`the network is broadcasting the requested SI messages. Hence,
`Observation: For MSG1/3 based SI request methods, whether the SI acquisition procedure is successful
`can’t be deduced from whether the SI request is acknowledged.
`
`Therefore, we propose to use a straightforward way to detect the SI acquisition procedure failure in RRC, i.e.
`introduce a SI acquisition timer. The timer is started when RRC triggers MAC to initiate SI request transmission.
`If all the requested SI messages are received before the timer expires, the SI acquisition procedure is regarded as
`success. Otherwise, the SI acquisition procedure fails.
`Proposal 1: For MSG1/MSG3 based SI request procedure, SI acquisition timer is introduced. If all the
`requested SI messages are received by UE RRC before the timer expires, the SI acquisition procedure is
`completed successfully; otherwise, the procedure fails.
`
`Although the above discussion is based on MSG1/3 based SI request methods, we find no reason to prevent
`RRC_CONNECTED UE from applying the timer during on demand SI acquisition procedure. Given uniform
`operation between RRC_IDLE and RRC_CONNECTED UEs is also simplifying the protocol, we propose:
`Proposal 2: The SI acquisition timer is also applied for on demand SI acquisition procedure initiated by
`RRC_CONNECTED UEs.
`
`For the length of SI window and the repetition period of each SI message can be various from one cell to another,
`it may take one UE different time to acquire certain SI message in different cells. Hence it is reasonable to
`enable different cell to apply differnet length for the SI acquisition timer.
`Clearly, the length of the timer should be signalled before one UE initiates SI request procedure, hence the
`length of the timer should be signalled in the minimum SI.
`Proposal 3: The length of the SI acquisition timer is configurable and should be signalled in the minimum
`SI.
`
`2.2. RRC re-initiate the SI request procedure
`In the last RAN2 meeting, some papers proposed that the RRC can re-initiate the SI request procedure when the
`MSG1/MSG3 based SI request procedure is failure. The identified use cases and proposed solutions in the
`papers are following:
` Case1：After receiving the indication of RACH problem from UE MAC[1]
`
`Ex.1016
`APPLE INC. / Page 1 of 2
`
`

`

`
`Proposed solution: Upon receiving the indication of RACH problem from UE MAC at a cell, UE RRC starts a
`prohibit timer. While the timer is running, UE RRC shall not trigger RACH procedure for SI request at the cell.
`After the timer is expired, if SI is still requested, UE RRC re-triggers RACH procedure for SI request at the cell.
`UE RRC is allowed to trigger RACH procedure at the cell up to N times. N is configured by the cell.
`
` Case2：UE fails to acquire the requested SI-Message, after receiving SI response[2]
`Proposed solution: If a UE requesting on-demand SI receives Msg2, but still fails to acquire the requested SI-
`Message, the UE should re-initiate the request procedure (up to a maximum number of times) without applying
`power ramping to the Msg1 transmission.
`
`The models of both the above solutions seem a little complex. Both solutions involves specify retransmission in
`two layers, i.e. MAC layer handles RACH MSG1/3 retransmission and RRC layer handles SI request procedure
`re-initiation. The maximum number of SI request procedure re-initiation times needs to be signaled to UE.
`In our understanding, it takes a long time for the UE RRC to re-initiation the SI request procedure up to N times.
`In the duration, UE may want to give up the SI acquisition procedure if the SI requested is not needed any longer.
`Hence, it seems the UE rather than the network is more suitable to decide how many times the SI request
`procedure should be re-initiated. Hence, we propose when and how the SI request procedure is re-initiated is left
`to UE implementation.
`Proposal 4: UE RRC can decide whether to re-initiate the SI request procedure after the SI acquisition
`procedure fails (i.e. the SI acquisition timer expires) by itself. How many times RRC can re-initiate the SI
`request procedure is left to UE implementation.
`
`2.3. Handling of SI missing
`For the SI which is provided on demand, the SI can be considered as missing if one UE fails to obtain the SI
`before the UE decides to not re-initiate SI acquisition procedure any more. Then, need we specify how to handle
`the missing of the SI which is provided on demand?
`In LTE, how to handle the missing of essential SI is specified, while how to handle the missing of non-essential
`SI (equivalent to other SI in NR) is left to UE implementation. In another word, whether a specified solution to
`handle SI missing is need or not is mainly decided by how important the missing SI is. As the principle works
`well in LTE, we prefer to follow the same principle in NR. Hence, we propose.
`Proposal 5: How to handle the missing of other SI for NR is left to UE implementation, no matter the
`related SI is provided via broadcasted periodically or on demand.
`
` 
`
`3. Conclusion
`In this contribution, how to handle the on demand SI acquisition procedure failure is discussed and we propose:
`Proposal 1: For MSG1/MSG3 based SI request procedure, SI acquisition timer is introduced. If all the
`requested SI messages are received by UE RRC before the timer expires, the SI acquisition procedure is
`completed successfully; otherwise, the procedure fails.
`Proposal 2: The SI acquisition timer is also applied for on demand SI acquisition procedure initiated by
`RRC_CONNECTED UEs.
`Proposal 3: The length of the SI acquisition timer is configurable and should be signalled in the minimum
`SI.
`Proposal 4: UE RRC can decide whether to re-initiate the SI request procedure after the SI acquisition
`procedure fails (i.e. the SI acquisition timer expires) by itself. How many times RRC can re-initiate the SI
`request procedure is left to UE implementation.
`Proposal 5: How to handle the missing of other SI for NR is left to UE implementation, no matter the
`related SI is provided via broadcasted periodically or on demand.
`
`References
`[1] R2-1713697 Remaining issues on on-demand SI request procedure LG Electronics Inc.
`
`[2] R2-1712488 Open issues on On-demand SI Ericsson
`
`Ex.1016
`APPLE INC. / Page 2 of 2
`
`