3GPP TSG-RAN WG2 #100
`Reno, USA, 27th November – 1st December 2017
`
`R2-1713697
`resubmission of R2-1711389
`
`: 10.4.1.6.6
`Agenda Item
`: LG Electronics Inc.
`Source
`: Remaining issues on on-demand SI request procedure
`Title
`Document for : Discussion and Decision
`
`Introduction
`In RAN2 NR AH#2, RAN2 made the following agreements:
`
`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 document, we further discuss on-demand SI delivery procedure.
`
`General aspects for SI request
`RAN2 agreed in RAN2#98 that on-demand SI request will maximise commonality with the RACH procedure. Assuming that
`RACH procedure is a function of the NR MAC, we think that on-demand SI request should be a function of the NR MAC.
`Meanwhile, as captured in TR38.804, broadcast of system information is a function of RRC layer. Thus, we assume that NR RRC
`perform system information acquisition procedure. Then, it should be NR RRC that triggers SI request because NR RRC would
`monitor system information and should determine whether on-demand SI request is needed or not.
`
`Considering RAN2 agreements and conventional modelling of RRC/MAC, we propose that when NR RRC triggers RACH
`procedure for SI request to NR MAC, NR MAC performs RACH procedure for SI request. We propose to define the RRC SI
`Request procedure which triggers MAC RACH procedure.
`Proposal 1: When the RRC SI Request procedure is initiated, NR RRC triggers RACH procedure to NR MAC. If
`triggered, NR MAC performs RACH procedure for the RRC SI Request procedure.
`
`Page 1
`
`Ex.1017
`APPLE INC. / Page 1 of 4
`
`

`

`In our view, it is not necessary that NR RRC suspends monitoring system information while NR MAC performs RACH procedure
`for any purpose, i.e. regardless of whether RACH procedure is triggered for SI request or not. Even while UE MAC performs
`RACH procedure for SI request, UE RRC may check if the requested SI message begins to be scheduled or not.
`
`If RACH procedure for SI request cannot end quickly e.g. due to power ramping or collision, it may happen that during ongoing
`RACH procedure for SI request, UE RRC receives the SI message that may be also requested by another UE. If it is the case, it is
`desirable that UE stops RACH procedure for SI request if the requested SI message is to be scheduled or already received.
`However, it is not required that UE MAC checks if the requested SI message is to be scheduled or already received before re-
`transmitting RACH preamble for SI request.
`
`Proposal 2: UE is not required to check if the requested SI message is to be scheduled or even already received before re-
`transmitting RACH preamble for SI request. Nevertheless, UE stops ongoing RACH procedure for SI request if UE RRC
`recognizes that the requested SI message is to be scheduled or already received.
`
`RACH failure for SI request
`RAN2 agreed that Msg1 for SI request re-transmission is continued until reaching max preamble transmissions. Thereafter, a
`Random Access problem to upper layers is indicated. RAN2 should further discuss upper layer actions when MAC reports
`Random Access problem. We assume that upon receiving the indication(s) of the RACH problem, UE RRC declares failure of the
`RRC SI Request procedure. Then, it should be further discussed how UE RRC finally handles this RACH failure for SI request.
`
`Proposal 3: Upon receiving the indication(s) of RACH problem, UE declares failure of the RRC SI Request procedure.
`
`One alternative is to treat the cell as barred. We think that if essential SIBs are missing at a cell, UE shall consider the cell as
`barred. However, we wonder if Other SI is really essential. Assuming that Other SI is not essential, it is not likely that UE
`considers the cell as barred due to no acquisition of Other SI. There seems no reason that UE considers the cell as barred even
`though minimum SI has been received for the cell. If UE sees only that cell where the requested SI is not received, it seems not
`desirable that UE considers that cell as barred.
`Proposal 4: If minimum SI has been received for a cell, UE does not considers the cell as barred regardless of whether
`Other SI is received or not.
`In case of RRC Connection Establishment procedure in LTE, if T300 has expired a consecutive connEstFailCount times on the
`same cell, UE shall use connEstFailOffset for the parameter Qoffsettemp for the concerned cell when performing cell selection
`and reselection for a period as indicated by connEstFailOffsetValidity.
`
`From our perspective, applying such offset based approach is useful, so that UE may reselect to another cell from the cell where
`the requested SI is not received. This approach does not lead to cell barring while allowing nomadic/stationary UEs to camp on
`other cells where UEs may receive requested SIs. Thus, UE may increase possibility of leaving the cell where the requested SI is
`not received. Nevertheless, UE could possibly camp on the cell in which UE may establish a RRC connection without acquisition
`of the Other SI. Such case is undesirable, but it would rarely happen.
`
`Proposal 5: If the RRC SI Request procedure fails and the requested SI has been not received at a cell, UE applies minus
`offset for the concerned cell when cell selection and reselection.
`Meanwhile, UE may continue to camp on the same cell after RACH procedure for SI request is unsuccessfully completed. It
`seems undesirable that UE insistently camping on the same cell cannot acquire Other SI any more, after one RACH procedure for
`SI request was unsuccessfully completed. Rather, UE should be allowed to insistently request SI delivery to the same cell multiple
`times unless the cell finally broadcasts the requested SI or RACH is not overloaded. The number of SI request at the same cell
`could be limited to a certain number. gNB could configure the number of SI request per cell e.g. depending on RACH resources.
`
`In addition, gNB should control RACH overload due to SI request. Thus, a prohibit timer for SI request could be introduced and
`configured by gNB. In our view, upon receiving the indication of RACH problem from UE MAC at a cell, NR RRC starts a
`prohibit timer. While the timer is running, UE RRC shall not request SI delivery to the cell. After the timer is expired, UE RRC
`sends SI request to the cell again, up to the configured number.
`Proposal 6: 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.
`Proposal 7: UE RRC is allowed to trigger RACH procedure at the cell up to N times. N is configured by the cell.
`
`Page 2
`
`Ex.1017
`APPLE INC. / Page 2 of 4
`
`

`

`We should avoid the case that UE performs RACH procedure(s) for SI request endlessly. Thus, if UE RRC triggered RACH
`procedure for SI request N times at a cell, UE RRC shall not trigger RACH procedure for SI request at the cell. As proposed
`above, UE may apply minus offset for the concerned cell when cell selection and reselection, then.
`
`Proposal 8: After UE RRC has triggered RACH procedures N times at a cell for the RRC SI Request procedure, UE RRC
`stops the RRC SI Request procedure. Then, UE RRC shall not re-initiate the RRC SI Request procedure and re-trigger
`RACH procedure for SI request at the cell, while keeping camping on the same cell.
`Furthermore, UE MAC shall not re-transmit RACH preamble if maximum number of preamble transmissions is reached. Thus,
`UE does not perform RACH procedure(s) for SI request endlessly.
`
`Proposal 9: UE MAC shall not re-transmit RACH preamble if maximum number of preamble transmissions is reached.
`
`Delayed state transition caused by SI request
`RAN2 agreed that RRC signalling is used for SI request in Msg3. We assume that on-demand SI request will be used at least by
`UEs in IDLE and UEs in INACTIVE. UE in IDLE or INACTIVE may request or activate a RRC connection by sending a RRC
`message such as a RRC Connection Request or RRC Connection Resume message.
`
`There may be the case that UE RRC triggers RACH procedure for SI request and then UE NAS triggers RRC Connection
`Establishment before completing the RACH procedure for SI request. For example, if the SI request is a RRC message over
`CCCH, the RRC Connection Request message over CCCH can be transmitted only after the SI request is successfully transmitted
`and then UL resource is granted for the second RRC message. Thus, the RACH procedure for SI request would delay state
`transition from IDLE to CONNECTED or from INACTIVE to CONNECTED sometimes.
`Observation 1: Since SI request is a RRC message, when NAS triggers RRC Connection Request/Resume right after RRC
`triggers SI request, RACH procedure for SI request would delay state transition from IDLE to CONNECTED or from
`INACTIVE to CONNECTED.
`
`We think that there are two options to avoid this problem:
`- Option 1: If RRC triggers state transition procedure such as RRC Connection Establishment or RRC Connection
`Resume, UE stops ongoing RACH procedure for SI request.
`- Option 2: RRC Connection Request/Resume message and SI request message use different SRBs. The SRB carrying
`SI request message has a lower priority than the SRB carrying the RRC Connection Request/Resume message
`In Option 1, if RRC triggers state transition procedure such as RRC Connection Establishment or RRC Connection Resume, but if
`RACH procedure for SI request is ongoing, UE stops ongoing RACH procedure for SI request and then triggers new RACH
`procedure for state transition.
`
`In Option 2, RRC Connection Request/Resume message and SI request message use different SRBs. The SRB carrying SI request
`message has a lower priority than the SRB carrying the RRC Connection Request/Resume message. If RRC triggers state
`transition procedure such as RRC Connection Establishment or RRC Connection Resume, but if RACH procedure for SI request
`is ongoing, UE continues to perform RACH procedure. If UE receives UL grant from Msg2, UE constructs MAC PDU based on
`Logical Channel Prioritization. Thus, RRC Connection Request/Resume message with a higher priority will be included in the
`MAC PDU before SI request message with a lower priority.
`
`Accordingly, we propose one of the options above to avoid the problem.
`
`Proposal 10: We propose to consider one of the following options to avoid delayed state transition caused by SI request
`transmission:
`- Option 1: If RRC triggers state transition procedure such as RRC Connection Establishment or RRC Connection
`Resume, UE stops ongoing RACH procedure for SI request.
`- Option 2: RRC Connection Request/Resume message and SI request message use different SRBs. The SRB carrying
`SI request message has a lower priority than the SRB carrying the RRC Connection Request/Resume message
`
`Page 3
`
`Ex.1017
`APPLE INC. / Page 3 of 4
`
`

`

`Conclusion
`In conclusion, we propose the followings for SI request:
`Proposal 1: When the RRC SI Request procedure is initiated, NR RRC triggers RACH procedure to NR MAC. If
`triggered, NR MAC performs RACH procedure for the RRC SI Request procedure.
`Proposal 2: UE is not required to check if the requested SI message is to be scheduled or even already received before re-
`transmitting RACH preamble for SI request. Nevertheless, UE stops ongoing RACH procedure for SI request if UE RRC
`recognizes that the requested SI message is to be scheduled or already received.
`Proposal 3: Upon receiving the indication(s) of RACH problem, UE declares failure of the RRC SI Request procedure.
`Proposal 4: If minimum SI has been received for a cell, UE does not considers the cell as barred regardless of whether
`Other SI is received or not.
`Proposal 5: If the RRC SI Request procedure fails and the requested SI has been not received at a cell, UE applies minus
`offset for the concerned cell when cell selection and reselection.
`Proposal 6: 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.
`Proposal 7: UE RRC is allowed to trigger RACH procedure at the cell up to N times. N is configured by the cell.
`Proposal 8: After UE RRC has triggered RACH procedures N times at a cell for the RRC SI Request procedure, UE RRC
`stops the RRC SI Request procedure. Then, UE RRC shall not re-initiate the RRC SI Request procedure and re-trigger
`RACH procedure for SI request at the cell, while keeping camping on the same cell.
`Proposal 9: UE MAC shall not re-transmit RACH preamble if maximum number of preamble transmissions is reached.
`Observation 1: Since SI request is a RRC message, when NAS triggers RRC Connection Request/Resume right after RRC
`triggers SI request, RACH procedure for SI request would delay state transition from IDLE to CONNECTED or from
`INACTIVE to CONNECTED.
`Proposal 10: We propose to consider one of the following options to avoid delayed state transition caused by SI request
`transmission:
`- Option 1: If RRC triggers state transition procedure such as RRC Connection Establishment or RRC Connection
`Resume, UE stops ongoing RACH procedure for SI request.
`- Option 2: RRC Connection Request/Resume message and SI request message use different SRBs. The SRB carrying
`SI request message has a lower priority than the SRB carrying the RRC Connection Request/Resume message
`
`
`
`Page 4
`
`Ex.1017
`APPLE INC. / Page 4 of 4
`
`