3GPP TSG-RAN WG2 Meeting #95bis
`Kaohsiung, 10th – 14th October 2016
`
`R2-166120
`
`CATT
`Source:
`On-demand system information delivery mechanism
`Title:
`9.2.2.2
`Agenda Item:
`Document for: Discussion and Decision
`
`Introduction
`1
`This contribution is a resubmission of [1]. In the context of SI delivery for NR, many companies propose to
`reduce the amount of “always-on” broadcast of system information [2]~[11]. The part of system information
`which is not always broadcasted (called on demand SI in the paper) can be delivered to particular UE based on
`the UE’s trigger. Several approaches are proposed for how the UE explicitly requests on demand SI [2]. In the
`email discussion triggered in [12] on system information, the rapporteur listed these possible options for
`discussion, but no agreement was reached. In this contribution, we first give the generic procedure of on demand
`SI delivery, and then further analyze and compare these approaches in view of the observations in [2] and give
`our preference.
`
`2 Discussion
`2.1 Generic procedure of on demand SI delivery
`On demand SI delivery mechanism enables the network to send certain part of system information only after
`triggered by UE. As a result, the procedure consists of two essential steps at least. The basic procedure is
`illustrated in Figure 1.
`
`Figure 1: generic procedure of on demand SI delivery
`Step 0 is optional and reflects a potential trigger from the network e.g. any indication of some SI update in any
`manner. It however indicates that the trigger at the origin of the on-demand SI is not necessarily only coming
`from the UE itself, but can also be the network.
`In Step 1, the UE initiates on demand SI delivery procedure by sending the SI Request to the NR eNB. In the SI
`Request, some information which can help NR eNB to identify the SIBs UE is interested in may be included.
`The information may be the indexes of requested SIBs, UE capabilities etc.
`Upon receiving the SI request, the NR eNB can send the SIBs in the SI Response (Step 2). SI Response can be
`dedicated signaling, groupcast (e.g. one UE requests and then the SI is delivered to a group of UEs via group SI-
`RNTI), or non-periodic broadcast.
`
`Proposal 1: RAN2 should adopt the generic procedure in Figure 1 as a starting point for on demand SI
`delivery mechanism study.
`
`In [2], several approaches for on demand SI delivery with different forms of the generic procedure in Figure 1
`(omitting the optional network trigger) are discussed. We evaluate them in the following sections.
`
`2.2 Evaluation criteria
`In the email discussion [12], most companies agree that the observations listed in [3] need to be taken into
`account when RAN2 designs on demand SI acquisition mechanism.
`
`R2-166120
`
`1
`
`IPR2022-00468
`Apple EX1009 Page 1
`
`

`

`Observations from [3]
`Observation 1: On-demand SI delivery will reduce signalling overhead in the network side.
`Observation 2: On-demand SI delivery will increase the number of uplink access and can cause uplink
`congestion when essential SI changes or when many UEs enter the same cell.
`Observation 3: The congestion caused by on-demand SI delivery can delay other uplink access which might be
`more important than SI request
`Observation 4: On-demand SI delivery may delay acquisition of updated system information so that could cause
`mismatched configuration between the network and the UE.
`Observation 5: On-demand SI delivery will increase UE batter consumption when UE frequently changes a cell.
`Observation 6: The uplink message requesting SI delivery may need to include some UE capability information.
`Thus, the size of the initial uplink message would increase whenever NR introduces a new feature introducing a
`new SIB.
`
`The observations can be summarized as following concerns:
`(cid:190) UL congestion: On-demand SI delivery will increase the number of uplink access and can cause uplink
`congestion when SI changes or when many UEs enter the same cell. The congestion caused by on-demand
`SI delivery can delay other uplink access which might be more important than SI request.
`(cid:190) Delay of system information acquisition: On-demand SI delivery may delay acquisition of updated
`system information leading to potential mismatched configuration between the network and the UE.
`(cid:190) UE power consumption: On-demand SI delivery will increase UE power consumption when UE
`frequently changes cell.
`(cid:190) Future Extensibility: The uplink message requesting SI delivery may need to include some UE capability
`information. Thus, the size of the initial uplink message would increase whenever NR introduces a new
`feature also introducing a new SIB.
`
`Therefore, we propose:
`Proposal 2: The potential on demand SI acquisition mechanisms can be carefully evaluated with respect to
`the following aspects: UL congestion, delay of system information acquisition, UE power consumption and
`Future Extensibility.
`
`2.3 Evaluation
`In this section, we evaluate the proposed approaches according to the aspects listed in proposal 2. The UL
`congestion is evaluated by the number of UL messages of each approach. More UL messages will cause more
`UL congestion. Delay of system information acquisition is evaluated by the number of total UL/DL messages
`when UE receives the interested system information. In addition, possible RACH collision is also taken into
`account as it will increase the delay of SI acquisition. UE power consumption is evaluated by the number of UL
`and DL messages of each approach; we assume UL transmission will consume more power than DL reception.
`Future Extensibility is evaluated by ease of introducing new information elements accessible through on
`demand SI.
`
`Idle/inactive UE [2]
`a)
`For idle/inactive UE, UE can use one of the following approaches to acquire the on demand SI:
`
`Approach #1 (Figure 2): Request on demand SI after establishing RRC connection.
`In this approach, an idle/inactive UE needs to perform RRC connection establishment/resume procedure to enter
`RRC_CONNECTED state first. Then the UE can request the system information by sending SI request message
`to the gNB, with indicator of the interested system information in the request message. gNB sends back the
`requested system information to the UE in SI response message, and then it may release the RRC connection of
`the UE.
`Different from legacy LTE system, we assume the RRC establishment procedure is optimized in NR by omitting
`the
`following DRB establishment and security activation procedure
`if
`the purpose of entering
`RRC_CONNECTED state is SI acquisition only.
`If preamble collision occurs in the first step, the UE may fail to enter the RRC_CONNECTED state. In this case,
`the failed UE needs to restart the whole procedure.
`
`R2-166120
`
`2
`
`IPR2022-00468
`Apple EX1009 Page 2
`
`

`

`(cid:56)(cid:40)
`
`(cid:74)(cid:49)(cid:37)
`
`(cid:51)(cid:85)(cid:72)(cid:68)(cid:80)(cid:69)(cid:79)(cid:72)
`
`(cid:53)(cid:68)(cid:81)(cid:71)(cid:82)(cid:80)(cid:3)(cid:36)(cid:70)(cid:70)(cid:72)(cid:86)(cid:86)(cid:3)(cid:53)(cid:72)(cid:86)(cid:83)(cid:82)(cid:81)(cid:86)(cid:72)
`
`(cid:53)(cid:53)(cid:38)(cid:3)(cid:38)(cid:82)(cid:81)(cid:81)(cid:72)(cid:70)(cid:87)(cid:76)(cid:82)(cid:81)(cid:3)(cid:86)(cid:72)(cid:87)(cid:88)(cid:83)(cid:3)(cid:53)(cid:72)(cid:84)(cid:88)(cid:72)(cid:86)(cid:87)
`
`(cid:53)(cid:53)(cid:38)(cid:3)(cid:70)(cid:82)(cid:81)(cid:81)(cid:72)(cid:70)(cid:87)(cid:76)(cid:82)(cid:81)(cid:3)(cid:86)(cid:72)(cid:87)(cid:88)(cid:83)
`
`(cid:53)(cid:53)(cid:38)(cid:3)(cid:70)(cid:82)(cid:81)(cid:81)(cid:72)(cid:70)(cid:87)(cid:76)(cid:82)(cid:81)(cid:3)(cid:86)(cid:72)(cid:87)(cid:88)(cid:83)(cid:3)(cid:70)(cid:82)(cid:80)(cid:83)(cid:79)(cid:72)(cid:87)(cid:72)
`
`(cid:49)(cid:82)(cid:3)(cid:53)(cid:53)(cid:38)(cid:3)(cid:85)(cid:72)(cid:70)(cid:82)(cid:81)(cid:73)(cid:76)(cid:74)(cid:88)(cid:85)(cid:68)(cid:87)(cid:76)(cid:82)(cid:81)(cid:3)(cid:73)(cid:82)(cid:85)(cid:3)(cid:39)(cid:53)(cid:37)(cid:3)(cid:86)(cid:72)(cid:87)(cid:88)(cid:83)(cid:15)(cid:3)(cid:81)(cid:82)(cid:3)
`(cid:86)(cid:72)(cid:70)(cid:88)(cid:85)(cid:76)(cid:87)(cid:92)(cid:3)(cid:68)(cid:70)(cid:87)(cid:76)(cid:89)(cid:68)(cid:87)(cid:76)(cid:82)(cid:81)(cid:3)
`
`(cid:54)(cid:44)(cid:3)(cid:53)(cid:72)(cid:84)(cid:88)(cid:72)(cid:86)(cid:87)
`
`(cid:54)(cid:44)(cid:3)(cid:53)(cid:72)(cid:86)(cid:83)(cid:82)(cid:81)(cid:86)(cid:72)
`
`(cid:53)(cid:53)(cid:38)(cid:3)(cid:53)(cid:72)(cid:79)(cid:72)(cid:68)(cid:86)(cid:72)
`
`Figure 2
`
`Approach #2 (Figure 3): Request other system information as part of system access procedure.
`In this approach, UE reuses the LTE RACH procedure. In the MSG3, UE sends SI request instead. And the gNB
`sends SI response in MSG4.
`Similar to approach#1, approach#2 also has a risk of preamble collision. If collision occurs, UE needs to restart
`the whole procedure.
`
`Figure 3
`
`Approach #3 (Figure 4): Request other system information based on preamble transmission associated with
`requested information.
`In this approach, the network needs to reserve some preambles for on demand SI acquisition, each reserved
`preamble is mapped to a set of system information. And the mapping relationship between preambles and system
`information block groups is informed to UE before UE starts the procedure. When UE wants to acquire the
`system information, it sends the corresponding preambles to the gNB. Within UE’s UL power limit, UE could
`send several (different) preambles in one UL transmission to require system information in more than one group.
`Compared with the above two approaches, approach #3 has better performance in some preamble collision cases,
`since it performs no contention resolution. For example, if more than one UE send the same preamble on the
`same RACH occurrence, as long as at least one is correctly detected by gNB, then all the UEs can receive the SI
`response from the gNB. Hence, collision risk is alleviated in approach#3.
`
`R2-166120
`
`3
`
`IPR2022-00468
`Apple EX1009 Page 3
`
`

`

`Figure 4
`Approach #4 (Figure 5): Request common system information based on preamble transmission and further
`requests other system information.
`
`Figure 5
`This approach is the combination of approaches #2 and #3, UE reuses the LTE RACH procedure. UE starts the
`procedure by sending the reserved preamble. In random access response, the gNB sends a subset of on demand
`SI (i.e. common on demand SI, FFS what information in common on demand) and UL grant to UE. If the UE
`only needs the common on demand SI, the procedure is over. Otherwise, the UE can further send the SI request
`according to the UL grant in RAR. And the gNB sends SI response in MSG4.
`In this approach, there is no collision risk for common on demand SI. But for other on demand SI, there is
`collision risk. If collision occurs, UE needs to restart the whole procedure.
`Table 1 Comparison of the different approaches (idle UE)
`Approach 2
`Approach 3
`Approach 1
`4((cid:47)(cid:47))
`2((cid:47))
`1((cid:45)(cid:45))
`
`Approach 4
`1 or 2((cid:45))
`
`UL congestion
`(Number of UL messages)
`Delay of
`Total
`system
`number of
`information
`UL/DL
`acquisition
`messages
`before UE
`receives
`the SI of
`interest
`collision
`risk
`
`UE power consumption
`(number of UL/DL
`messages)
`Future Extensibility
`(ease of introducing new
`on demand SI)
`
`7((cid:47)(cid:47))
`
`4((cid:47))
`
`2((cid:45)(cid:45))
`
`2 or 4((cid:45))
`
`Yes((cid:47))
`
`Yes((cid:47))
`
`NO((cid:45))
`
`4/4((cid:47)(cid:47))
`
`2/2((cid:47))
`
`1/1((cid:45)(cid:45))
`
`NO for common
`on demand SI
`Yes for other on
`demand SI
`((cid:46))
`1/1 or 2/2((cid:45))
`
`Extend the SI
`request
`command((cid:45))
`
`Extend the SI
`request
`command((cid:45))
`
`Reserve more
`preambles
`((cid:47))
`
`Extend the SI
`request
`command((cid:45))
`
`R2-166120
`
`4
`
`IPR2022-00468
`Apple EX1009 Page 4
`
`

`

`In the four approaches, only approach 1 requires idle/inactive UE to leave idle/inactive state to acquire on
`demand SI. From the above table, we can see that approach 1 involves a long procedure and leads to the worst
`performance in all the aspects except future extensibility. Hence, we propose:
`
`Proposal 3: It is not mandatory for an idle/inactive UE to leave current state to acquire on demand SI.
`
`From the above table, we can see that among approaches 2/3/4, approach 3 has the best performance in all the
`aspects except future extensibility. The main drawback of approach 3 is it requires reserving some preambles.
`This will increase the collision probability of RACH procedure used for other purposes than on demand SI
`acquisition. However, we don't think it is a big problem if we can group the on demand SI properly and only
`reserve several preambles for demand SI acquisition.
`
`Proposal 4: Approach 3 can be supported for idle/inactive UE to acquire on demand SI.
`
`b) Connected UE
`In Connected state, the UE may or may not have an UL grant. If it has an UL grant, it can directly use the
`generic procedure of Figure 1 where the SI request is sent over UL SCH. This provides flexibility in requesting
`some specific SI, similar to approaches 1/2/4 above. As a result, we propose:
`
`Proposal 5: The generic procedure of Figure 1 can be directly used for Connected UEs with an UL grant,
`where the SI request is transmitted on granted resources.
`
`For Connected UE without an UL grant, the UE may use either a scheduling request or the RACH procedure if it
`does not have scheduling request resource. These latter aspects are very much based on the legacy LTE though
`and we don’t know yet what will exactly be the differences between SR and RACH procedures in NR. However,
`a preliminary observation is that approach 3 could be reused as well in that case. Given both approach 3 and the
`generic procedure are two steps procedures they have almost the same performance with regard to UL
`congestion, delay of system information acquisition, UE power consumption. As a result we suggest capturing
`the following as a starting point for Connected UEs without an UL grant:
`
`Proposal 6: Approach 3 can be reused for Connected UEs without UL grant to acquire on demand SI.
`
`3 Conclusion
`In this paper, we evaluated the four potential approaches of on demand SI acquisition presented in [2] and [12].
`And give the following proposals:
`Proposal 1: RAN2 should adopt the generic procedure in Figure 1 as a starting point for on demand SI
`delivery mechanism study.
`Proposal 2: The potential on demand SI acquisition mechanisms can be carefully evaluated with the
`following aspects: UL congestion, delay of system information acquisition, UE power consumption and
`Future Extensibility.
`Proposal 3: It is not mandatory for an idle/inactive UE to leave current state to acquire on demand SI.
`Proposal 4: Approach 3 can be supported for idle/inactive UE to acquire on demand SI.
`Proposal 5: The generic procedure of Figure 1 can be directly used for Connected UEs with an UL grant,
`where the SI request is transmitted on granted resources.
`Proposal 6: Approach 3 can be reused for Connected UEs without UL grant to acquire on demand SI.
`
`4 References
`[1] R2-164811 On-demand System Information Delivery Mechanism CATT
`[2] R2-163371 System Information Signalling Design in NR Samsung
`[3] R2-164078 Observations about on-demand SI delivery mechanism LG
`[4] R2-163977 System Information Enhancements for NR Sony
`[5] R2-163470 System information in NR CATT
`[6] R2-163586 System information for standalone NR deployment Intel
`[7] R2-163853 System information handling in NR ETRI
`
`R2-166120
`
`5
`
`IPR2022-00468
`Apple EX1009 Page 5
`
`

`

`[8] R2-163980 System information on demand in standalone NR NEC
`[9] R2-164088 System Information Acquisition for New Radio Access INTERDIGITAL
`[10] R2-164127 System information design Huawei, HiSilicon
`[11] R2-163997 Solution principles for system information distribution Ericsson
`[12] R2-165210 Report of email discussion on [94#40][NR] System information
`
`R2-166120
`
`6
`
`IPR2022-00468
`Apple EX1009 Page 6
`
`