`
`3GPP TSG RAN WG1 NR Meeting# 90
`Prague, Czech Republic, 21st – 26th August 2017
`
`Agenda item:
`6.1.3.5
`Source:
`Samsung
`Title:
`Wider Bandwidth Operations
`Document for: Discussion and decision
`
`
`
`R1-1713654
`
`1 Introduction
`RAN1 concluded from NR SI that maximum channel bandwidth per NR carrier is 400 MHz in Rel-15 and the maximum
`number of NR carriers for CA and DC is 16 from RAN1 specification perspective. In the context of NR wider bandwidth
`operation, two aspects are considered; 1) UE RF bandwidth adaptation, 2) Coexistence among narrow band UEs (NB
`UEs), CA UEs and wideband UEs (WB UEs) within a wideband NR carrier. The primary benefit for UE RF bandwidth
`adaptation is UE power saving [1]. Supporting multiple UE types/categories within a wideband NR carrier allows
`implementation flexibility. RAN1 introduced bandwidth part (BWP) to support NR wider bandwidth operation. A BWP
`consists of a group of contiguous PRBs and is associated with a specific numerology (sub-carrier spacing, CP type).
`
`2 Default BWP
`Default BWP (or anchor BWP) is the BWP whether the UE has detected the SS block and can be reconfigured after initial
`access. The default BWP would enable following operation:
`
`–
`
`fallback operations if the indication of active DL/UL BW part is missed by a UE and/or DCI-based indications
`are missed by the UE
`
`– DRX operation or IDLE mode operation, e.g. UE monitors PDCCH or paging messages over it
`
`The size of the default BWP can be same as the minimum channel BW supported by all NR UEs. Default BWP can be
`UE specific such that load balancing can be achieved. For FDD, default DL and UL BWPs may be independent.
`
`For the case of initial access, no indication of BWP is necessary. The CORESET location for the RMSI scheudling can
`be indicated by PBCH as an offset from the SS block center (in terms of RB’s or absolute frequency location); the
`frequency resource for PDSCH conveying RMSI is scheduled by PDCCH mapped on the CORESET. The RACH
`configuration indicates the time/frequency resources where the UE can perform RACH and these can be indicated again
`as an offset from the RMSI location or from the SS block locations. For each step of the RACH procedure, the locations
`for RAR (can be same as RMSI CORESET), Msg4, etc can be indicated via previous steps in initial access. Hence, we
`believe that no special indications for the BWP is needed during the initial access stages.
`
`Proposal 1: Support UE specific default/anchor BWP.
`
`Proposal 2: No indication regarding BWP (or default BWP) is needed in PBCH and during initial access phase.
`
`Proposal 3: The size of the default BWP can be same as the minimum channel BW supported by all NR UEs.
`
`3 BWP Activation
`Following options were identified for the indication of active DL/UL bandwidth part(s) apart from the RRC-based
`indication which is already agreed to be supported
`- Option #1: DCI (explicitly and/or implicitly) or MAC CE
`- Option #2: Timer-based
`- Option #3: Time pattern (e.g. DRX like)
`
` Ex. 1021
`APPLE INC. / Page 1 of 9
`
`

`

`
`
`
`
`For Option#1, explicit DCI can indicate the center frequency or starting RB of the configured BWP to be activated.
`Implicit method can work when the UE falls back, e.g., by associating resource allocation filed in scheduling assignment.
`In order to avoid any potential misunderstanding between the UE and gNB, explicit DCI signaling is preferable.
`
`For DCI based indication and MAC CE signaling, there is a tradeoff in terms of fast signaling and reliability. DCi based
`indication is fast and supports fast BW adaption. On the other hand, MAC CE signaling is slower but is more reliable.
`Hence to allow for dynamic BW adaption, to get full benefits of this flexible BW, to allow for forward compatibility, it
`is preferred to support DCI-based BWP activation for NR. When a UE misses the DCI indicating to switch to a wider
`BWP, after a timer expiry, the UE can monitor the previously monitored narrow BWP and after a second timer expiry it
`can move to the default BWP. Such mechanisms may be defined for the UE to allow for fallback modes of operations.
`
`Proposal 4: Support DCI-based activation mechanisms for BWP along with timer-based mechanisms to allow for
`fallback mode operations.
`
`Time-pattern based mechanisms such as SPS-like or DRX-like may also be used. Such time-pattern mechanisms can ease
`the signaling overhead between gNB and UE. However, UE power consumption caused by un-necessary retuning of the
`wider BWP for a long time duration should be taken care of. Further, some UE behavior should be specified if the UE
`receives a DCI based activation while it is following the previously indicated timer-based mechanism.
`
`Observation 1: UE behavior should be specified in case that a DCI based BWP related command is received when UE
`is following the timer.
`
`Proposal 5: NR supports time pattern-based BWP activation.
`
`Regardless of above options, upon gNB indication of active BWP(s), UE confirmation would be needed in order to avoid
`any potential misalignment between gNB and UE.
`
`In order to accommodate the transition time for UE bandwidth adaptation/BWP activation, the timing gap between UE
`reception of the indication and its application should be wide enough. The minimum required timing gap would depend
`on specific operation scenario. For example, as RAN4 pointed out, the total transition time should include AGC settling
`time in case of multiple-carrier operation. Flexible timing control can be supported via timing indication in the DCI (both
`same-slot and cross-slot scheduling).
`
`Further, slot format may impact the timing. For instance, when slot n contains both DL and UL part and UE receives the
`indication of bandwidth adaptation at slot n, the UE may need to suspend the bandwidth adaptation until the end of UL
`part for potential UL transmission.
`
`3.1 DCI Design for dynamic BWP Activation
`Regarding DCI design for dynamic BWP activation, following two ways can be considered.
`
`Alt 1) Separate DCI design for switching
`
`Alt 2) Joint DCI design for switching and scheduling
`
`For Alt 1, a new DCI format should be introduced for dynamic BWP indication which is separately designed with
`scheduling DCI. A UE configured by multiple BWPs allowing dynamic BWP activation has to keep monitoring the DCI
`format corresponding to BWP switching. In order to minimize or maintain the number of blind decoding, several solutions
`can be considered. As Alt 1-1, a sequence-based DCI indicating BWP switching can be transmitted in the fixed or pre-
`configured time and frequency resources. The computational complexity is reduced for sequence-based DCI compared
`to channel coding-based DCI. Further, very tiny bits such as 1 or 2-bit will be enough to indicate BWP activation. For
`this small size bits, sequence-based DCI can outperform the channel coding-based DCI in terms of BLER performance.
`However, there is inherent problem of false alarm due to absence of CRC. As Alt 1-2, DCI for BWP switching can be
`transmitted in the fixed location within a given search space with a fixed aggregation level. Then, a UE does not need to
`blindly search a number of PDCCH candidates for detecting the DCI format corresponding to BWP switching. However,
`using fixed location can degrade the detection performance of the DCI. Also, too much overhead of CRC compared to
`
` Ex. 1021
`APPLE INC. / Page 2 of 9
`
`

`

`
`
`
`
`payload size is expected (BWP switching indicator will just require only few bits and CRC length would be e.g., 16 bits.).
`As Alt 1-3, the size of DCI format for BWP switching can be designed to be the same with other scheduling DCI format.
`To distinguish between switching DCI and scheduling DCI, additional DCI field can be introduced for DCI format flag.
`Or, CRC bits can be scrambled with different RNTI. However, it is inefficient to fit the very small size of DCI for
`switching into relatively long size of DCI for scheduling i.e., to fit the small contents needed for switching purposes into
`some existing DCI format (for example due to overhead reasons as mentioned above).
`
`For Alt 2, a DCI field indicating BWP switching can be added in the scheduling DCI. At a cost of increment in DCI
`size, the total number of blind decoding are not affected. There are two possible alternatives inserting BWP indicator field
`(BIF) considering relationship with carrier indicator field (CIF) as shown in Figure 1. As Alt 2-1, BIF can be inserted
`independently with CIF. The CIF may indicate one of the CCs where PDSCH is scheduled and the BIF indicates a BWP
`to be activated in that CC. As Alt 2-2, CIF and BIF can be jointly encoded and composed of a combined bit field like
`CBIF (carrier and BWP indicator field) as shown in Figure 1. CBIF can indicate a combination of carrier index and BWP
`index to be scheduled. Alt 2-2 is more flexible and efficient method compared to Alt 2-1 since in Alt 2-2, the contents of
`each bit field conveyed by CBIF can be configured by higher layer signaling reflecting current CA and BWP of each CC
`configuration.
`
`
`
`Figure 1. Example of DCI design for dynamic BWP activation
`To decide DCI design for dynamic BWP activation, we need to consider the PDSCH scheduling for BWP operation.
`When multiple BWPs are configured, a PDCCH and the associated PDSCH can be transmitted in the same BWP
`(corresponds to self-BWP scheduling) or different BWP (corresponds to cross-BWP scheduling). Actually, self-BWP
`scheduling is the baseline operation, and whether or not to support cross-BWP scheduling is still open. In addition, single
`BWP activation is now supported and multiple BWP activation is FFS so far.
`
`Especially for single BWP activation scenario, there are several motivations to support cross-BWP scheduling. First,
`BWP switching is generally triggered when there is a data traffic which should be transmitted via other BWP not the
`current BWP. By using cross-BWP scheduling, fastest data reception is possible since there is no need to monitor the
`PDCCH in the changed BWP. Second, interference of PDCCH can be managed by using cross-BWP scheduling as in CA
`scenario. Third, considering combined operation BWP with CA, cross-BWP scheduling should be naturally supported
`when a UE is configured by cross-carrier scheduling. Lastly, more efficient DCI design can be applied when cross-BWP
`scheduling is supported.
`
`If only self-BWP scheduling is supported, there is no way to evade use of separate DCI design corresponding to Alt 1
`since independent DCI signaling is necessarily required. For example, a UE should detect a switching DCI in BWP-1 at
`first and then the scheduling DCI have to be obtained in BWP-2 if only self-BWP scheduling is supported. Then the UE
`power consumption will increase due to the additional blind decoding for additional DCI format as describe above. On
`the other hand, if cross-BWP scheduling is supported, joint DCI design for switching and scheduling of Alt 2 can be used.
`Then a scheduling DCI for BWP-2 including BWP indicator can be transmitted and detected in the activated BWP-1.
`Without any impacts on UE complexity, dynamic BWP switching can be supported.
`
`Proposal 6: Cross-BWP scheduling is supported.
`
`Proposal 7: BWP indication field is added in the DCI if cross-BWP scheduling is supported and BWP indication field
`is configurable.
`
`
`
`3.2 CORESET configurations across BWP
`The following agreements were made in the last RAN1 meeting –
`
` Ex. 1021
`APPLE INC. / Page 3 of 9
`
`

`

`• At least one of configured DL BWPs includes one CORESET with common search space at least in primary
`component carrier
`• Each configured DL BWP includes at least one CORESET with UE-specific search space for the case of single
`active BWP at a given time
`•
`In case of single active BWP at a given time, if active DL BWP does not include common search
`space, then UE is not required to monitor the common search space
`
`
`
`
`
`
`
`Issue 1: CORESET configuration
`
`In these cases, one open question is whether the CORESET configurations i.e., CORESET parameters such as CORESET
`duration, REG bundling size, REG interleaving, number of blind decoding operations, REG bundle size, transmission
`type, across BWPs are same or not. At least for the sake of simplicity and to reduce RRC signaling which configures the
`USS and its CORESET in every configured BWP for the UE, a UE can assume that the same parameters are valid across
`different BWPs, at least on the ones which have same numerology.
`
`Proposal 8: A UE can assume same CORESET configuration parameters, at least for user specific search, across
`different configured BWPs with same numerology.
`
`For the case of group common control and the common control channels, since they are configured for all UE’s or for a
`group of UEs, this CORESET may be configured in the BW region which may be common across the various BWPs of
`different UEs. It is not clear how this will be handled if different UE’s have BWP with different numerology and this CSS
`is present in the overlapping region as shown in figure below –
`
`
`Figure 2. Example of CSS CORESET configuration
`
`
`Hence, it is preferred that the UE be explicitly signaled via RRC about the CSS and group-common control signaling
`parameters.
`
`Proposal 9: NR UE will be UE specifically signaled about the CSS and group common control parameters per BWP.
`
`Issue 2: Receiving common DCI
`
`Based on the agreement, at least one of the configured BWPs should have a CORESET for CSS. However, the BWP
`having a CORESET for CSS can be deactivated and instead, the other BWP having a CORESET configured by only USS
`can be activated. In this case, the UE is not required to monitor the CSS. Then the issue is how to receive common DCI
`for the UE. In LTE, CSS is always monitored by the UE to receive various common DCIs for receiving/updating system
`information, RACH and paging procedure, transmit power control, etc. Therefore, it should be ensured to receive the
`common DCI by the UE even for the case that there is no CSS CORESET within the activated BWP. Several alternatives
`can be considered as follows:
`
`Alt 1) The gNB transmits the common DCI through the USS in the activated BWP to the UE if the currently active BWP
`does not include CSS and there is a common DCI which should be received by the UE at a given time. The UE performs
`additionally blind decoding for the expected common DCI format for the USS. Alt 1 corresponds to common DCI
`transmission in the UE-specific manner. The common DCI can be freely transmitted in any of PDCCH candidates in the
`given USS. Or fixed/pre-configured a set of PDCCH candidates such as specific aggregation levels in the USS can be
`used for common DCI transmission.
`
`Alt 2) The gNB can configure a monitoring periodicity for CSS to the UE. The UE is forced to follow the configuration
`for the CSS monitoring regardless of which BWP is activated at a given time. For example, let assume that BWP-1 has
`CSS (also USS) and BWP-2 has USS only. If BWP-2 is now activated and the next slot is configured to monitor CSS in
`BWP-1, then the BWP-1 is automatically activated in the next slot and the UE can monitor CSS in BWP-1 according to
`pre-configured monitoring periodicity.
`
` Ex. 1021
`APPLE INC. / Page 4 of 9
`
`

`

`
`
`
`
`Alt 3) The gNB can transmit an indicator to activate the BWP having CSS to the UE if the currently activated BWP does
`not include CSS and there is a common DCI which should be received by the UE. If the UE receives the indication to
`activate the BWP having CSS, the UE changes the BWP and monitors the CSS. In Alt 3, the BWP switching can be
`occurred only for the purpose of receiving common DCI without data reception. Therefore, there need some additional
`mechanism to distinguish whether this BWP switching is for common DCI reception or for data reception or for both to
`efficiently control the UE blind decoding.
`
`Among above alternatives, Alt 2 and Alt 3 can cause frequent BWP switching for CSS monitoring according to
`circumstances. This is not desirable to the UE in terms of power consumption. Therefore, Alt 1 is slightly preferred for
`the solution of common DCI reception.
`
`Observation 2: A mechanism how to receive common DCI when active DL BWP does not include common search
`space should be further studied.
`
`4 PRB grid alignment within a wideband NR carrier
`As per RAN1#89, same PRB grid structure for a given numerology is assumed for NB UEs, CA UEs and WB UEs within
`a wideband NR carrier. This is crucial for WB and NB UEs co-existence with multiplexing efficiency, for instance to
`support MU-MIMO. The issue becomes more prominent for multiple numerologies used by WB and NB UEs. However
`it is not clear if any more new issues arise due to wideband operation as compared to the normal PRB grid alignment
`issue being discussed in NR. Figure 1 illustrates two potential alternatives and can be used for wideband as well. Since a
`NB UE may not know the WB UE operations and the system BW, it seems more flexible to support Alt.2 for PRB grid
`alignment.
`
`Proposal 10: Support Alt 2 for PRB grid alignment in wideband system design.
`
`Alt 1: Aligned at end of frequency
`
`Alt 2: Aligned at center of frequency
`
`Figure 3: Alternatives for PRB grid alignment
`
`
`
`
`
`5 Other issues
`Retransmission across BWPs
`The following agreements was made in last RAN1 meeting:
`Agreements:
`- One TB is mapped to one DL/UL carrier.
`- Re-transmission of a TB cannot take place on different carrier than the initial transmission.
`- Working assumption:
`o Re-transmission of a TB cannot take place on different numerology than the initial transmission in Rel. 15.
`Agreements:
`For HARQ,
`-
`o The retransmissions can occupy a different frequency allocation than the initial transmission (Note, this is
`supported in LTE)
`o For downlink, the transmission durations for a given TB may not be the same in some cases.
` Among initial transmission and retransmissions for a data having fixed DMRS position relative to
`the start of the slot
`
` Ex. 1021
`APPLE INC. / Page 5 of 9
`
`

`

`
`
`
`
` Among initial transmission and retransmissions for a data having fixed DMRS position relative to
`the start of the data
` FFS: other cases
`o For uplink at least scheduled by a UL grant, the transmission durations for a given TB may not be the
`same in some cases.
`
`
`
`Considering this, retransmission across BWPs with different numerologies is also not allowed. Since the transmission
`duration of a TB may or may not be same across retransmissions, this may be possible to support via BWP adaption i.e.,
`for the first transmission a UE may be configured with smaller BWP while for retransmission the UE may be configured
`with a wider BWP. Hence, this confirms that the retransmission across BWP with same numerology is still allowed.
`
`Observation 3: Retransmission across BWPs is allowed only if the BWPs are configured with the same numerology.
`CSI-RS Mapping
`CSI-RS mapping should be specified both on wideband and narrow band manner. A CSI-RS transmission can be over the
`full DL BW (except for potential reserved resources) and a UE can measure CSI over a BWP when the UE retunes to the
`BWP (both are supported in NR). A CSI-RS transmission can also be only over the BWP where the UE is retuning. From
`the UE perspective, if CSI-RS measurements are configured to occur only within the BWP, the two approaches are
`equivalent and can be handled by implementation. A narrow band UE may secure only sub-band measurements of a
`wideband RS and a CA UE may not make full use of wideband RS depending on the BWP configuration. While the sub-
`band measurements may be degraded when considering one-shot measurements, the measurement accuracy can be
`improved by obtaining measurements for a longer period of time.
`
`Proposal 11: Support both narrowband and wideband CSI-RS mapping.
`
`PRB Bundling
`As per last meeting agreements, the PRG size may depend on RBG size, or other values based on bandwidth part, and/or
`scheduled bandwidth and/or UE capability. In LTE, the PRG size was defined based on the RBG sizes as it was more
`appropriate to define the pre-coding vectors. A similar design may be followed in NR. Since the RBG size may depend
`on the configured BWP sizes (as indicated earlier and may be indicated via DCI), the PRG size may directly or indirectly
`depend on the configured BWP size. Of course it should be taken care to consider the case of multiple BWP configuration.
`Furthermore, when a WB and NB UE are multiplexed for MU-MIMO purposes, the PRG sizes may be defined commonly
`for both these UEs and be indicated via UE specific signaling. For instance, in LTE when the RBG size was 3, the PRG
`size 3 was chosen over 2 to have scheduling flexibility. Similarly, the PRG sizes of both WB and NB UE should be taken
`into account and the appropriate PRG size may be chosen and indicated.
`
`Proposal 12: PRG and RBG sizes may be chosen based on the WB and NB UE multiplexing and indicated to the WB
`UE if constrained by the NB UE behavior.
`
`BWP configuration considering RBG grid alignment
`
`RBG misalignment across users can cause that frequency resource may not be fully utilized from gNB perspective. There
`are two scenarios where RBG grid is not aligned. In case of that RBG size is same but RBG grid is different as shown in
`Figure 4, if one RBG is allocated to UE 1, then two RBGs for UE 2 cannot be used for scheduling unless RBG grid is
`aligned. The larger RBG size is used, the more PRBs are wasted compared to the case with RBG grid alignment. Likewise,
`in case of that both RBG size and grid are different as shown in Figure 5, if 1 RBG-8 is allocated for UE 1, then 3 RBG-
`4s cannot be used for UE 2. If the candidates of RBG sizes are decided as 2 to the power of N such as 2, 4, 8, and 16, the
`nested-RBG structure can be possible so that better scheduling degree of freedom may be provided to gNB. Furthermore,
`considering that PRG size may depend on RBG size in NR, RBG grid alignment with the nested-RBG structure is
`beneficial to support MU-MIMO between different UEs.
`
` Ex. 1021
`APPLE INC. / Page 6 of 9
`
`

`

`
`
`
`
`
`
`UE 1
`
`UE 2
`
`UE 1
`
`UE 2
`
`UE 1
`
`UE 2
`
`UE 1
`
`UE 2
`
`RBG
`
`RBG
`
`(a) RBG misalignment
`
`(b) RBG alignment
`
`
`
`Figure 4. RBG size is same but RBG grid is different
`
`RBG-8
`
`(a) RBG misalignment
`
`RBG-8
`
`RBG-4
`
`(b) RBG alignment
`
`RBG-4
`
`
`
`Figure 5. Both RBG size and grid are different
`
`RBG-2
`
`RBG-4
`
`RBG-8
`
`RBG-16
`
`Figure 6. Nested-RBG structure
`
`
`
`Proposal 13: If RBG size candidates are decided as 2 to the power of N such as 2, 4, 8, and 16, the nested-RBG structure
`should be supported in NR to provide better degree-of-freedom for scheduling. In addition, NR supports RBG grid
`alignment between different UEs.
`
`To support the RBG grid alignment, following two options can be considered.
`
`• Option-1: RBG grid is decided based on wideband CC and then BWP is configured irrespective of this grid.
`
`• Option-2: RBG grid is generated based on the activated BWP irrespective of the location of BWP within the
`WB CC. But BWP configuration is performed in terms of max RBG size.
`
` Ex. 1021
`APPLE INC. / Page 7 of 9
`
`

`

`
`
`
`
`Figure 7 is provided to show both options. Option-1 have flexibility to configure BWP since any size and location of the
`BWP is possible while offset to indicate start location of the max RBG size may be informed to UE implicitly or explicitly.
`On the contrary, Option-2 restricts BWP configuration while it is beneficial that the nested-RBG structure is always fit
`into the BWP. In addition, due to coarse granularity, signaling overhead can be reduced to configure BWP.
`
`
`
`BWP
`
`granularity
`
`BWP
`
`Max RBG
`
`BWP
`
`Max RBG
`
`Option-2
`
`Option-1
`
`1R
`B
`
`1R
`B
`
`
`
`Figure 7. Two options to support RBG grid alignment
`
`Proposal 14: Consider following options to support RBG grid alignment. Other options are not precluded.
`
`Option-1: RBG grid is decided based on wideband CC and then BWP is configured irrespective of this grid.
`
`Option-2: RBG grid is generated based on the activated BWP irrespective of the location of BWP within
`the WB CC. But BWP configuration is performed in terms of max RBG size.
`Impact of carrier without SS block
`
`In the last RAN1 meeting, it was agreed to support carrier without SS block for some UEs as follows –
`
`Agreements:
`
`Usage scenario #4 in R1-1711795 is supported in the context of non-contiguous intra-band carrier aggregation
` Carrier without SS block can be configured for some UEs
`Send LS to RAN2/4 to tell above agreement/observation in R1-1711824
`
`•
`
`•
`
`
`This carrier is not a standalone carrier and will be activated only via the Pcell. Measurements on this carrier only happen
`via CSI-RS configurations on this carrier. The timing information for the CSI-RS on this carrier can be taken from the SS
`blocks of the Pcell.
`
`6 RRC Parameters
`The following RRC parameters are identified for the wideband operations:
`
`• BWP configuration
`o Additionally, active BWP among the configured BWP can be indicated via DCI/MAC CE/Time pattern
`(e.g., DRX).
`
`• Parameters of the SS block(s) [2]:
`o
`
`It can be indicated via RRC signaling in the connected mode. The indication allows a UE to rate match
`around the SS block locations. A narrow band UE may be informed of the other SS block locations for its
`RRM measurements by providing retuning gaps. The indication of default SS block (and default BW part)
`would be needed for idle mode and fallback mode operation.
`
`• RS for RRM measurements:
`o NB (or WB) SS blocks (i.e., 1 or multiple SS blocks) along with NB (or WB) CSI-RS combinations
`
` Ex. 1021
`APPLE INC. / Page 8 of 9
`
`

`

`
`
`
`
`7 Summary
`Based on above discussion for NR wider bandwidth operations, we have following observations and proposals:
`Observations
`
`Observation 1: UE behavior should be specified in case that a DCI based BWP related command is received when UE
`is following the timer.
`
`Observation 2: A mechanism how to receive common DCI when active DL BWP does not include common search
`space should be further studied.
`
`Observation 3: Retransmission across BWPs is allowed only if the BWPs are configured with the same numerology.
`
`Proposals
`
`Proposal 1: Support UE specific default/anchor BWP.
`
`Proposal 2: No indication regarding BWP (or default BWP) is needed in PBCH and during initial access phase.
`
`Proposal 3: The size of the default BWP can be same as the minimum channel BW supported by all NR UEs.
`
`Proposal 4: Support DCI-based activation mechanisms for BWP along with timer-based mechanisms to allow for
`fallback mode operations.
`
`Proposal 5: NR supports time pattern-based BWP activation.
`
`Proposal 6: Cross-BWP scheduling is supported.
`
`Proposal 7: BWP indication field is added in the DCI if cross-BWP scheduling is supported and BWP indication field
`is configurable.
`
`Proposal 8: A UE can assume same CORESET configuration parameters, at least for user specific search, across
`different configured BWPs with same numerology.
`
`Proposal 9: NR UE will be UE specifically signaled about the CSS and group common control parameters per BWP.
`
`Proposal 10: Support Alt 2 for PRB grid alignment in wideband system design.
`
`Proposal 11: Support both narrowband and wideband CSI-RS mapping.
`
`Proposal 12: PRG and RBG sizes may be chosen based on the WB and NB UE multiplexing and indicated to the WB
`UE if constrained by the NB UE behavior.
`
`Proposal 13: If RBG size candidates are decided as 2 to the power of N such as 2, 4, 8, and 16, the nested-RBG structure
`should be supported in NR to provide better degree-of-freedom for scheduling. In addition, NR supports RBG grid
`alignment between different UEs.
`
`Proposal 14: Consider following options to support RBG grid alignment. Other options are not precluded.
`
`Option-1: RBG grid is decided based on wideband CC and then BWP is configured irrespective of this grid.
`
`Option-2: RBG grid is generated based on the activated BWP irrespective of the location of BWP within
`the WB CC. But BWP configuration is performed in terms of max RBG size.
`
`References
`[1] R1-1704179 (R4-1702029), Reply LS on UE RF Bandwidth Adaptation in NR, RAN4
`
`[2] R1-1710626, Remaining details on multiple SS block transmissions in wideband CC, Samsung
`
` Ex. 1021
`APPLE INC. / Page 9 of 9
`
`