3GPP TSG-RAN WG2 NR AH#3
`Vancouver, Canada, 22nd – 26th January 2018
`
`Tdoc R2-1800288
`(resubmission of R2-1712488)
`
`Agenda Item:
`
`10.4.1.6.5
`
`Source:
`
`Ericsson
`
`Title:
`
`Open issues on On-demand SI
`
`Document for: Discussion, Decision
`
`1 Introduction
`RAN2-97bis agreed that on-demand system information may be requested either using random access
`preambles (Msg1) or using a multi-step RA procedure (Msg1, Msg2, Msg3). RAN2 also agreed that the network
`indicates in the minimum SI, which of the two mechanisms the UE shall apply.
`RAN2-98 agreed that for Msg1 based SI request the minimum granularity of requested SI is one SI-Message
`(a set of SIBs as in LTE) and one RACH preamble can be used to request multiple SI-Messages. It was further
`agreed that the on-demand SI request procedure should maximise commonality with the RACH procedure and
`that the network, in the case of Msg1 based SI request, sends an acknowledgement in Msg2 to confirm the SI
`request.
`At the RAN2 Adhoc meeting in Qingdao, the following agreements were reached for on-demand SI:
`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.
`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 contribution we elaborate on:
`-
`conditions for sending SI requests, including discussion on the need for an additional indication that an
`on-demand SI is actually being broadcast at this instant in time;
`
`1/7
`
`Ex.1026
`APPLE INC. / Page 1 of 7
`
`

`

`handling of SI acquisition errors;
`-
`contents of Msg3 and Msg4;
`-
`link adaptations of transmissions of requested SI;
`-
`transmission mechanism for Msg2 at Msg1 based SI request; and
`-
`the scheduling information for on-demand SI, including a proposed basis for the ASN.1 encoding of the
`SchedulingInfo IE.
`
`2 Discussion
`
`2.1 When may the UE send SI requests?
`When a gNB updates SIBs in an SI-Message that is marked as “on-demand”, many UEs in the cell may request
`that SI. A similar but less pronounced effect may occur when a large group of UEs enter a new cell where they
`may all transmit an SI request.
`RAN2 discussed “whether there is an additional indication that an on-demand SI is actually being broadcast
`at this instant in time”.
`With the Msg1-based request the network is able to detect multiple preambles received in the same SI request
`resources. Multiple different preambles are mutually orthogonal and can be distinguished by the network. If
`multiple UEs transmit the same preamble, the network may not be able to distinguish each different
`transmission. This is however not a problem, since the received preamble transmissions will anyway trigger
`the same action from the network, i.e. broadcasting of the requested on-demand SI in the next therefore
`scheduled SI-Window. Secondly, a network may intend to apply beamforming to the delivery of the requested
`SI (note that this is still a broadcast transmission in the sense that it uses the SI-Message and the scheduling
`allocation is scrambled by SI-RNTI). Based on the received preamble the network could determine the
`beamforming characteristics and attempt to send the SI accordingly (still on the broadcast channel). If,
`however, many UEs across the cell area need the SI-Message, the network should be aware of that it should
`not beamform the transmission only into the direction of the first UE having sent the request. If some of the
`UEs interested in the same on-demand SI withhold their request transmissions, the network has no way of
`knowing whether there are more UEs listening for the broadcast than the one(s) transmitting the request.
`The Msg3-based SI-request suffers more from many concurrent requests than the Msg1-based request since
`the network may have to distinguish and respond to the UEs’ preamble transmissions and distinguish and
`decode their subsequent Msg3s. Hence, in particular a network using that mechanism might want to prevent
`too many UE from requesting SI concurrently e.g. upon SI modification.
`However, we do not see a need for any new mechanism since the SchedulingInfo in the Minimum SI can serve
`this purpose. When the network updates the SIB(s) of an on-demand SI-Message, the network may choose to
`temporarily omit the “si-RequestInfo” in the SchedulingInfo, in which it anyway indicates that the SI-Message
`is updated (changed value tag), and temporarily broadcast the updated SI to prevent the otherwise expected
`multiple requests for the updated SI-Message. Another case when the network may temporarily omit the “si-
`RequestInfo” in the SchedulingInfo is when it has received a request to broadcast the concerned on-demand
`SI. When the broadcasting of the concerned SI-Message is finalized, the network may again include the “si-
`RequestInfo” in the SchedulingInfo.
`Observation 1
`The network may use the already agreed indication in SIB1 (whether a SI-Message
`is subject to regular broadcast or only available upon request), to temporarily
`disable requests e.g. when updating SI and hence expecting many subsequent
`accesses or when it has received a request for a certain SI-Message and intend to
`broadcast it.
`A UE sends the SI-request solely based on the information in SIB1 that an SI-
`Message is only provided upon request. After sending the request, the UE attempts
`to acquire the requested SI-Message(s) in the SI-Window configured in SIB1.
`RAN2 does not introduce additional means for prohibiting UEs from sending SI
`requests for SI-Messages that are scheduled as “on-demand”.
`
`Proposal 1
`
`Proposal 2
`
`
`
`
`
`2/7
`
`
`
`Ex.1026
`APPLE INC. / Page 2 of 7
`
`

`

`2.2 Handling SI acquisition errors
`Like in regular SI-broadcast, it may happen that a UE is unable to acquire the SI-Message in the SI-Window
`in which it was announced according to the SchedulingInfo in SIB1. In case of on-demand SI, this may also
`be due to that the request procedure fails, i.e. a Random Access problem. For the Msg1 based method it may
`be due to that the UE’s Msg1 transmission is not received by the gNB or that the UE does not receive the
`Msg2 acknowledgement. Both these error cases look the same to the UE, i.e. it does not receive any Msg2
`acknowledgement. This is similar to a regular random access failure and it is reasonable that the UE behaves
`similarly, i.e. repeat the Msg1 transmission with increased power.
`Observation 2
`If a UE requesting on-demand SI does not receive Msg2, the UE may behave similarly
`as during a regular random access procedure and apply power ramping to Msg1
`retransmissions.
`Another potential cause of failure to acquire the SI-Message is that the UE receives the acknowledging Msg2,
`but does not receive the SI-RNTI of the scheduling allocation of the requested SI-Message in the specified SI-
`Window. And further, yet another potential cause of failure is that the UE receives the scheduling allocation
`addressed to the SI-RNTI, but does not successfully receive the actual SI-Message. In these two latter error
`cases, the UE should retransmit the Msg1 (up to a maximum number of times), but without increasing the
`transmit power, since the acknowledging Msg2 has confirmed that the error is not caused by failure of the
`network to receive the preamble of Msg1. In case the requested SI-Message is broadcast multiple times in
`multiple subsequent occurrences of the SI-Window, and the UE manages to receive the associated scheduling
`allocations on the PDCCH, it is possible (subject to RAN1 decision) that the UE may accumulate energy from
`multiple receptions (or reception attempts) of the SI-Message (like for LTE coverage extension).
`Observation 3
`If a UE requesting on-demand SI receives Msg2, there is no need for the UE to apply
`power ramping if the Msg1 is retransmitted due to later failures.
`If the network broadcasts a requested SI-Message multiple times and the UE
`successfully receives the associated scheduling allocations on the PDCCH, the UE
`may accumulate energy from multiple receptions (or reception attempts) of the SI-
`Message. This is RAN1‘s responsibility to consider.
`With the Msg3 based method, the failure to acquire the SI-Message may have the same causes as in the case
`of the Msg1 based method, and the UE’s behavior should be the same, i.e. retransmission of Msg1 with power
`ramping in case of absence of acknowledging Msg2 and retransmission of Msg1 without power ramping in
`case of failure to receive the scheduling allocation for the SI-Message or the SI-Message itself. In addition to
`these failure causes, with the Msg3 based method the failure may be caused by the failure of the network to
`receive Msg3. If the UE has transmitted Msg3 but does not receive the Msg4 acknowledgement, it should
`retransmit Msg1 (with a new random selection of the preamble) without power ramping (up to a maximum
`number of retransmissions). Similar to the Msg1 based method, the UE may successfully send a Msg3 SI
`request but not successfully receive the requested SI message, i.e. it receives a Msg4 ack but it does not
`receive the requested SI message in the SI window, or even the SI-RNTI of the corresponding scheduling
`allocation. The UE behavior should then be the same as for the Msg1 based method.
`Proposal 3
`RAN2 should assume that if a UE requesting on-demand SI does not receive Msg2,
`the UE retransmits the Msg1 with increased transmit power.
`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.
`Discuss with RAN1 whether a UE may accumulate the SI-Message transmissions
`across several SI-Windows within the Modification Period (as for coverage extension
`in LTE) or whether it shall acquire SI-Messages only from individual SI-Windows.
`
`Observation 4
`
`Proposal 4
`
`Proposal 5
`
`
`
`2.3 Consequences of final failure to acquire an on-demand SI-
`Message
`The content of the SIBs that may be acquired through on-demand requests vary and hence also their
`importance to a UE’s operation. Hence, if a UE fails to acquire a certain on-demand SI-Message (after a
`
`
`
`3/7
`
`
`
`Ex.1026
`APPLE INC. / Page 3 of 7
`
`

`

`maximum number of attempts or because the desired SIB(s) is(are) not available in the cell), the appropriate
`behavior of the UE depends on the content and criticality of the concerned SIB(s). Legacy behavior can be
`reused and there is no reason to specify different UE behaviors depending on whether a certain SIB is
`periodically broadcast or acquired through on-demand request.
`Proposal 6
`The behaviour of the UE upon final failure to acquire a SIB should be independent
`on whether the SIB is periodically broadcast or acquired through on-demand request
`and may be specified per SIB.
`
`
`
`2.4 Msg3 and Msg4 content and link adaptation of transmissions of
`requested SI
`For Msg1 based SI request, it was agreed at RAN2#98 that the minimum granularity of requested SI is one
`SI-Message (a set of SIBs as in LTE). There are no agreements on the content of Msg3 when the Msg3 based
`method for SI request is used, but it is reasonable to assume that the same minimum granularity of the
`requested SI as for Msg1 based request is used, i.e. one SI-Message, since a SI-Message is the smallest
`transmission entity in the SI distribution framework.
`However, the Msg3 provides opportunities to provide other useful information. One such useful information
`would be the channel status information, so that the network can adapt its SI transmission accordingly, when
`it transmits the SI-Message(s) that the UE requests. The network can thus adapt the transmission property to
`achieve a suitable link budget.
`For instance, the network may apply robust modulation and coding to increase the chances of successful
`reception for a UE with poor DL channel conditions or the network may transmit the requested SI-Message(s)
`with reduced power and/or less redundancy, thus reducing the resource consumption and the interference,
`when the requesting UE has good DL channel conditions. It is thus proposed that the UE includes information
`about its perceived DL channel status in the Msg3.
`Regarding UE identity in the Msg3 (and Msg4), no need has been identified. Since the Msg3 SI request method
`triggers broadcast of System Information messages, which are addressed to many UEs using the SI-RNTI,
`and the request does not lead to any state change for the UE, there is no UE specific signalling after the Msg4
`ack message. No contention resolution will thus take place during the procedure and there is no need for any
`UE identity within the Msg3 or Msg4 messages.
`Proposal 7
`The minimum granularity of the requested SI should be the same for the Msg3 based
`SI request method as for the Msg1 based method, i.e. the smallest entity that can be
`requested should be one SI-Message.
`A UE may include DL channel status information in Msg3, during Msg3 based SI
`request, to enable the network to adapt the transmission of the requested SI
`accordingly.
`No contention resolution takes place at the Msg3 based SI request method. The
`Msg3 and Msg4 messages used for the Msg3 based SI request method do not
`contain any UE identity.
`
`Proposal 8
`
`Proposal 9
`
`
`When a gNB receives the SI request in Msg3, it will acknowledge the reception with Msg4 and start
`broadcasting the requested SI message(s). When the UE receives the Msg4 message it can determine that it
`does not need to resend the SI request. Since the Msg4 itself acknowledges the reception of the SI request
`the UE can then assume that the requested SI message(s) will be broadcasted, and thus start monitoring the
`corresponding SI window(s). There is therefore no need to include (within the Msg4 message) any information
`regarding what SI messages that will be broadcasted.
`Proposal 10
`Msg4 does not contain any information about what SI messages that will be
`broadcasted.
`
`
`
`
`
`4/7
`
`
`
`Ex.1026
`APPLE INC. / Page 4 of 7
`
`

`

`2.5 Transmission mechanism for Msg2 acknowledgement message
`at Msg1 based SI request
`Msg1 based SI request method, one or many UEs may transmit the same PRACH preamble in the same
`PRACH resource. The gNB will be able to determine the SI request even if there are several UEs transmitting
`the same PRACH preamble and will then transmit the Msg2 acknowledgment message to confirm the
`reception. Depending on the gNB ability to detect the direction of the UE(s) sending the Msg1 request, which
`e.g. may be cumbersome in urban areas with reflection, it might be difficult to determine the DL beam(s) to
`use for successful Msg2 transmission. If the gNB cannot determine the direction of the UE(s) sending the SI
`request, it may need to transmit the Msg2 in a large area, perhaps even using beam sweeping.
`To avoid that beam sweeping thus is needed for transmission of the Msg2 acknowledge message, the gNB
`should be able to determine what beams to use based on the PRACH preamble reception. The needed
`information could be achieved either from the timing of the PRACH preamble, which can be different between
`the beam (SS Block occasion) in the cell, or based on that different PRACH preambles are associated to
`different beams (SS Block occasion), even for the Msg1 SI request. The association of (P)RACH resources to
`different SS Block occasions could then be similar as the one for the normal RACH procedure.
`Proposal 11
`At Msg1 based SI request method, it shall be possible to determine the best DL
`beam(s) for the Msg2 transmission based on the PRACH preamble/PRACH resource
`used for Msg1.
`
`
`
`2.6 SI scheduling information for on-demand SI
`In this section, we show and example ASN.1 structure that supports the agreements taken in earlier meetings.
`Small additions allow the NW to indicate whether an SI-Message is available by regular broadcast or only upon
`request, whether the UE shall use Msg1 or Msg3 and, in case of the former, how to send the Msg1.
`
`
`Table 1: Example ASN.1 structure for the SchedulingInfo in SIB1 to support on-demand SI
`
`
`
`OPTIONAL
`
`SchedulingInfoList ::= SEQUENCE (SIZE (1..maxSI-Message)) OF SchedulingInfo
`
`SchedulingInfo ::= SEQUENCE {
`
`si-Periodicity
`
`ENUMERATED {rf8, rf16, rf32, rf64, rf128, rf256, rf512},
`
`sib-MappingInfo
`
`SIB-MappingInfo,
`
`si-MessageValueTag
`INTEGER (0..3),
`
`si-RequestInfo
`
`SI-RequestInfo
`}
`
`SIB-MappingInfo ::= SEQUENCE (SIZE (0..maxSIB-1)) OF SIB-Type
`
`SIB-Type ::=
`
`
`
`
`
`ENUMERATED {
`
`
`
`
`
`
`
`
`
`
`sibType3, sibType4, sibType5, sibType6,
`
`
`
`
`
`
`
`
`
`
`sibType7, sibType8, sibType9, sibType10,
`
`
`
`
`
`
`
`
`
`
`sibType11, sibType12-v920, sibType13-v920,
`
`
`
`
`
`
`
`
`
`
`sibType14-v1130, sibType15-v1130,
`
`
`
`
`
`
`
`
`
`
`sibType16-v1130, sibType17-v1250, sibType18-v1250,
`
`
`
`
`
`
`
`
`
`
`..., sibType19-v1250, sibType20-v1310, sibType21-v14x0}
`
`SI-RequestInfo ::= SEQUENCE {
`
`msg1-Request SEQUENCE {
`
`
`si-PRACH-Preamble
`
`
`si-PRACH-Config
`
`
`}
`
`
`
`
`
`}
`
`
`The UE is supposed to interpret and use this information as follows:
`-
`If the optional field si-RequestInfo is absent
`
`
`
`
`
`
`
`
`
`INTEGER (0..63)
`PRACH-Config
`
`
`
`
`
`
`
`OPTIONAL,
`OPTIONAL
`OPTIONAL
`
`-
`
`the SI-Message is provided by regular SI broadcast, i.e., the UE shall not request it.
`
`- else, if the si-RequestInfo is present,
`
`
`
`5/7
`
`
`
`Ex.1026
`APPLE INC. / Page 5 of 7
`
`

`

`-
`
`-
`
`the SI-Message is only delivered upon request
`
`If the optional field msg1-Request is present,
`
`-
`
`the UE request this SI by sending only a Msg1 (Msg1 based request) in accordance with the
`parameters si-PRACH-Preamble and/or si-PRACH-Config
`
`- else, (the field msg1-Request is not present)
`
`- the UE request this SI by a RA procedure (Msg3 based request) using a preamble randomly
`selected from the cell’s regular set of preambles.
`
`The fields “si-PRACH-Preamble” and “si-PRACH-Config” allow configuring specific preambles and/or specific
`RA time/frequency resources to be used for requesting an SI-Message in accordance with the previous
`agreement (“If the PRACH preamble and/or PRACH resource specific to each SIB or set of SIBs …”). Whether
`the “si-PRACH-Config” has the same format as the regular PRACH configuration should be decided later
`together with RAN1. As discussed in section 2.5 the PRACH parameters may need to be configurable per
`beam(s)/SS Block(s).
`Proposal 12
`The information necessary to request an SI-Message (e.g. PRACH preamble, PRACH
`configuration) is included in an optional field in the SchedulingInfo IE of that SI-
`Message.
`The ASN.1 structure of Table 1 should form the basis for further RAN2 work on the
`ASN.1 specification of the SchedulingInfo IE.
`
`Proposal 13
`
` 3
`
` Conclusion
`In section 2 we made the following observations:
`
`Observation 1
`
`Observation 2
`
`Observation 3
`
`Observation 4
`
`The network may use the already agreed indication in SIB1 (whether a SI-Message
`is subject to regular broadcast or only available upon request), to temporarily
`disable requests e.g. when updating SI and hence expecting many subsequent
`accesses or when it has received a request for a certain SI-Message and intend to
`broadcast it.
`If a UE requesting on-demand SI does not receive Msg2, the UE may behave
`similarly as during a regular random access procedure and apply power ramping to
`Msg1 retransmissions.
`If a UE requesting on-demand SI receives Msg2, there is no need for the UE to
`apply power ramping if the Msg1 is retransmitted due to later failures.
`If the network broadcasts a requested SI-Message multiple times and the UE
`successfully receives the associated scheduling allocations on the PDCCH, the UE
`may accumulate energy from multiple receptions (or reception attempts) of the SI-
`Message. This is RAN1‘s responsibility to consider.
`
`
`Based on the discussion in section 2 we propose the following:
`
`
`
`6/7
`
`
`
`Ex.1026
`APPLE INC. / Page 6 of 7
`
`

`

`Proposal 1
`
`Proposal 2
`
`Proposal 3
`
`Proposal 4
`
`Proposal 5
`
`Proposal 6
`
`Proposal 7
`
`Proposal 8
`
`Proposal 9
`
`Proposal 10
`
`Proposal 11
`
`Proposal 12
`
`Proposal 13
`
`
`
`
`
`
`A UE sends the SI-request solely based on the information in SIB1 that an SI-
`Message is only provided upon request. After sending the request, the UE attempts
`to acquire the requested SI-Message(s) in the SI-Window configured in SIB1.
`RAN2 does not introduce additional means for prohibiting UEs from sending SI
`requests for SI-Messages that are scheduled as “on-demand”.
`RAN2 should assume that if a UE requesting on-demand SI does not receive Msg2,
`the UE retransmits the Msg1 with increased transmit power.
`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.
`Discuss with RAN1 whether a UE may accumulate the SI-Message transmissions
`across several SI-Windows within the Modification Period (as for coverage
`extension in LTE) or whether it shall acquire SI-Messages only from individual SI-
`Windows.
`The behaviour of the UE upon final failure to acquire a SIB should be independent
`on whether the SIB is periodically broadcast or acquired through on-demand
`request and may be specified per SIB.
`The minimum granularity of the requested SI should be the same for the Msg3
`based SI request method as for the Msg1 based method, i.e. the smallest entity that
`can be requested should be one SI-Message.
`A UE may include DL channel status information in Msg3, during Msg3 based SI
`request, to enable the network to adapt the transmission of the requested SI
`accordingly.
`No contention resolution takes place at the Msg3 based SI request method. The
`Msg3 and Msg4 messages used for the Msg3 based SI request method do not
`contain any UE identity.
`Msg4 does not contain any information about what SI messages that will be
`broadcasted.
`At Msg1 based SI request method, it shall be possible to determine the best DL
`beam(s) for the Msg2 transmission based on the PRACH preamble/PRACH
`resource used for Msg1.
`The information necessary to request an SI-Message (e.g. PRACH preamble,
`PRACH configuration) is included in an optional field in the SchedulingInfo IE of
`that SI-Message.
`The ASN.1 structure of Table 1 should form the basis for further RAN2 work on the
`ASN.1 specification of the SchedulingInfo IE.
`
`7/7
`
`
`
`Ex.1026
`APPLE INC. / Page 7 of 7
`
`