3GPP TSG-RAN WG2#101
`Athens, Greece, 26th February – 2nd March 2018
`
`
`Source:
`Title:
`Agenda Item:
`Document for:
`
`OPPO
`Discussion on SI Request Prohibit Timer
`10.4.1.6.6
`Discussion and decision
`
`R2-1801795
`
`1 Introduction
`For On-demand SI request, there are some agreements in previous meetings. During previous e-mail
`discussion, the issue of upper layer actions upon Random Access problem was discussed but not concluded.
`We have one contribution to discuss this issue[]. Moreover, one option which seems to have majority
`support mentioned the SI prohibit timer as follows:
`
`
` Alternative 2: Depends on the SI/ SIBs being requested. If these are not the essential SIBs (according
`to NR RRC) then UE refrains from retrying until a certain time. The prohibit timer, if any, might be
`specified or be configurable etc. In case of essential SIBs (if not all essential SIBs are ‘regularly’
`broadcasted), the UE shall treat the cell as barred.
`
`In this paper, we discuss the SI prohibit timer for MSG1 and MSG3 based SI request especially for RRC
`Idle/inactive UEs.
`
` Necessity of SI Prohibit Timer
`For MSG1-based SI request, RAN2 has agreed that in MSG2 there will be acknowledge. If RAR is missing
`and lower layer indicates the Random Access problem, we think that UE should not send SI request
`endlessly. Instead, UE should try to read SIB1 to check if the request SI has been available. And,
`because of the SI period, UE should wait for the latest SIB1. If the request SI is still not available, then UE
`can try to send SI request. If after certain time of retrying, SI can still not be acquired, then UE can decide
`whether the cell is barred depends on whether this SI is essential or not. If UE initiate MSG1-based SI
`request without any control, there will be heavy load to RACH.
`
`For MSG1-based SI request for RRC_Idle and RRC_Connected UEs, if Random
`Observation 1
`Access problem is indicated, if UE send SI request before it make clear if the request SI has
`been available due to the request by other UEs, there can be heavy load to RACH.
`For MSG3-based SI request, if MSG3 triggers a random access and random access problem is indicated to
`RRC layer, it also unreasonable if the MSG3 triggers a random access again. In such case, UE should also
`check if SIB1 has been updated and the request SI has become available.
`
`For MSG3-based SI request for RRC_Idle and RRC_Connected UEs, if Random
`Observation 2
`Access problem is indicated, if UE send SI request before it make clear if the request SI has
`been available due to the request by other UEs, there can be heavy load to RACH.
`For RRC-based SI request, usually we think the gNB can send a RRC message, otherwise, there might be
`radio link failure if RRC connection is broken. Similarly, we that that after one SI request, UE should not
`send another one to gNB before it check the latest SIB1 to know if the request SIB has been available.
`
`For RRC-based SI request for RRC_Connected UEs, after UE send one SI request
`Observation 3
`to gNB, it should not send another one before check the latest SIB1 to know if the request SIB
`has been available, otherwise, there can be frequent SI request which is unnecessary.
`Based on the above observations, we think that RAN2 need to introduce SI request prohibit timer in order to
`avoid the UE to generate frequent SI request.
`
` 2
`
`3GPP
`
`Ex.1007
`APPLE INC. / Page 1 of 3
`
`

`

`RAN2 to agree that SI prohibit timer is introduced for MSG1, MSG3 and dedicated
`Proposal 1
`RRC signalling to suppress UE to generate frequent SI request signalling.
`
`3 How SI Prohibit Timer Works?
`Regarding to how SI prohibit timer works, we think there are tow issues. The first issue to be solved is
`which layer should maintain the timer. The second issue is the conditions and triggered event of the timer.
` Which layer maintains the timer?
`Regarding to which layer maintains the timer, there can be two options. Option 1 is MAC layer and Option 2
`is RRC layer. Basically, we think that RRC layer is more proper because RRC is aware of the SI request for
`three SI request approaches. For MSG1 based SI request, RRC layer need to provide the associated
`preamble and/or PRACH resource. For MSG3 and RRC based SI request, RRC layer is charge of SI
`request generation. Meanwhile, we also think it is better to minimize MAC impacts since we RAN2 agreed
`to reuse RACH procedure as much as possible. Thus we propose:
`Proposal 2
`RAN2 to agree that SI prohibit timer is maintained in RRC layer.
` Conditions and action upon expiration
`For the introduced SI prohibit timer, we think RRC need to configure the SI prohibit timer. And, the timer is
`started when SI request is initiated. Regarding to the stop condition, we think there can be at least two
`conditions. The first condition is that UE get the acknowledgement of the SI request. The second
`condition is that UE read the SIB1 and knows the requested SI has been available e.g. due to the request
`from other UEs. When Timer expires, SI request can be triggered UE still need the SI on the concern cell.
`
`The SI prohibit timer is configured by RRC.
`Proposal 3
`The SI prohibit timer is started when SI request is initiated and stopped when the
`Proposal 4
`request SI has been available or the SI request has been acknowledged.
`Proposal 5
`When the timer expires, SI request can be triggered UE still need the SI on the
`concern cell.
`
`
`The following table summarize proposal 4 and proposal 5.
`Timer
`Start
`Stop
`Txxx
`Transmission of SI
`Reception of SI request
`
`request by RRC
`acknowledgement;
`signalling or trigger MAC
`The requested SI has been
`to perform Random
`available in latest SIB1
`Access for SI request
`
`At expiry
`Trigger another SI request if the
`SI is still needed in the concern
`cell
`
`4 Conclusion
`In this contribution, we discuss prohibit timer for On-Demand SI request and we have the following
`observations and proposals.
`
`For MSG1-based SI request for RRC_Idle and RRC_Connected UEs, if Random
`Observation 1
`Access problem is indicated, if UE send SI request before it make clear whether the request SI
`has been available due to the request by other UEs, there can be heavy load to RACH.
`Observation 2
`For MSG3-based SI request for RRC_Idle and RRC_Connected UEs, if Random
`Access problem is indicated, if UE send SI request before it make clear whether the request SI
`has been available due to the request by other UEs, there can be heavy load to RACH.
`Observation 3
`For RRC-based SI request for RRC_Connected UEs, after UE send one SI request
`to gNB, it should not send another one before check the latest SIB1 to know if the request SIB
`has been available, otherwise, there can be frequent SI request which is unnecessary.
`
`
`RAN2 to agree that SI prohibit timer is introduced for MSG1, MSG3 and dedicated
`Proposal 1
`RRC signalling to suppress UE to generate frequent SI request signalling.
`Proposal 2
`RAN2 to agree that SI prohibit timer is maintained in RRC layer.
`Proposal 3
`The SI prohibit timer is configured by RRC.
`Proposal 4
`The SI prohibit timer is started when SI request is initiated and stopped when the
`request SI has been available or the SI request has been acknowledged.
`
`3GPP
`
`Ex.1007
`APPLE INC. / Page 2 of 3
`
`

`

`Proposal 5
`concern cell.
`
`When the timer expires, SI request can be triggered UE still need the SI on the
`
`5 References
`[1] R2-1801780 Clarifications on Upper Layer Actions Upon RACH Problem for SI Request OPPO
`
`3GPP
`
`Ex.1007
`APPLE INC. / Page 3 of 3
`
`