How LTE Stuff Works?

5G NR: Connected Mode DRX

2021-04-27T22:27:00.002+02:00

1. Introduction

Similar to LTE, Discontinuous Reception (DRX) in 5G is of two types, Idle mode DRX and Connected mode DRX. In Idle mode DRX, the UE periodically wakes up to monitor for paging messages and goes back to sleep mode if paging message is not intended for it. NR Connected mode DRX is thoroughly discussed in this post. LTE C-DRX concepts are thoroughly discussed in LTE: Connected Mode DRX.

Without C-DRX in 5G NR or LTE, the UE must be awake all the time in order to decode downlink data, as the data in the downlink may arrive at any time. This means that UE must be monitoring PDCCH in every subframe in order to check if there is PDCCH available. This consumes a lot of the user equipment’s power.

C-DRX in 5G/LTE is introduced to improve UE battery power consumption by allowing the UE to periodically enter ‘sleep’ state (Off duration) during which PDCCH need not be monitored. In order to monitor PDCCH for possible downlink/uplink data, the UE is allowed to wake up periodically and stay ‘awake’ (On duration) for a certain amount of time before going to ‘sleep’ again. Additionally, the UE may be required to wake up occasionally to monitor PDCCH, this is for example to receive a possible re-transmission.

The gNodeB configures UE with a set of C-DRX parameters. These DRX parameters are selected based on the application type such that power and resource savings are maximized. When C-DRX is enabled, the UE battery power consumption is reduced but this will increase latency. This is because, there might be an extended delay in receiving data as, the UE may be in DRX Sleep state at the time of data arrival at the gNodeB, and the gNodeB would have to wait until the UE becomes active. The latency increases with DRX cycle length, i.e., the longer the DRX cycle length, the higher the latency is. So, the DRX parameters must be carefully selected such that the packet delay is minimized, and power saving is maximized.

DRX is also beneficial from the network point of view. Without DRX, the UE would be transmitting periodic CSI or SRS very frequently (based on the configuration). With DRX, during OFF periods, the UE is not allowed to transmit Periodic CSI or SRS, so the gNodeB can assign those resources to the other UEs to maximize resource utilization.

Uplink is usually unaffected by DRX as discontinuous reception is applicable only for the downlink. Whenever data is available in the uplink buffer, the UE can send Scheduling Request (SR) irrespective of active or sleep state i.e., the UE can interrupt the ‘sleep’ state when there is a need to transmit uplink data.

2 C-DRX in detail

During DRX mode, the UE powers down most of its circuitry when there are no packets to be received or transmitted. During this time the UE listens to the downlink PDCCH occasionally which is called active state or DRX ON period, whereas the time during which UE doesn’t listen PDCCH is called DRX Sleep state or DRX OFF period.

Each DRX cycle consists of DRX ON period and OFF period. There are two types of DRX cycles defined; Long DRX Cycle and Short DRX Cycle each of which are explained below in detail.

Case1: Only Long DRX Cycle is configured

Each Long DRX Cycle consists of an ON period and an OFF period. The ON period also referred to as “On Duration” defined in terms of milliseconds is the period in which the UE would stay awake and decode PDCCH. The ON and OFF durations together form a Long DRX duration and repeat once every Long DRX Cycle period which is configured by RRC.

The network can control the start location of the Long DRX Cycle using the RRC parameter drx-LongCycleStartOffset. This offset value is defined in milliseconds i.e., the offset is defined such that the Long DRX Cycle could start at a subframe boundary.

Additionally, the network can configure start of the ‘On Duration’ at slot level granularity within a subframe. The parameter drx-SlotOffset defines the start of ‘On Duration’ relative to the start of subframe boundary.

Once a Long DRX Cycle starts, the UE stays active for a duration of ‘drx-onDurationTimer’ and if there is no PDCCH received during this time, the UE would go to DRX sleep state, until the start of next ‘On Duration’. This simple scenario is illustrated below.

Let’s say that there was some PDCCH activity during ‘On duration’ period, it is highly likely that the device might be scheduled again. If the UE goes to DRX sleep state, it cannot receive the scheduling grants/assignments. So, 3GPP has defined a parameter to keep the UE in active state after being scheduled. This timer is called DRX Inactivity Timer and is configured by RRC as drx-InactivityTimer. The UE starts/restarts this timer every time PDCCH indicates a new UL or DL transmission, and UE stays in active state and keep monitoring for PDCCH until the expiry of drx-InactivityTimer. This scenario is illustrated below.

Case2: Both Long DRX Cycle and Short DRX Cycle are configured

As discussed, Long DRX Cycle is characterized by active state and sleep states, and if there is certain data activity, the device extends the active state by a length of inactivity duration. Long DRX Cycle is not suitable for certain services which require periods of data transmission followed by periods of no activity. In such cases, the gNodeB has the flexibility to configure Long DRX Cycle together with additional DRX cycle which is shorter compared to long cycle. This second cycle is referred to as ‘Short DRX Cycle’.

When the gNodeB has configured Short DRX Cycle, that means both long and short cycles are configured. Configuring Short DRX Cycle is optional and if not configured, the UE follows Long DRX Cycle as usual. Whenever the gNodeB configures Short DRX Cycle, it should ensure that Long DRX Cycle duration is an integer multiple of Short DRX Cycle duration. This means, short cycle duration in general is shorter than long cycle duration.

In case if there is no data activity during ‘On Duration’ of a long cycle, the device simply follows Long DRX Cycle as if Short DRX Cycle is not configured. If there is any data activity, the UE would switch to Short DRX Cycle and follows short cycle for certain amount of time. If there is no data activity during this time, the UE would then switch to Long DRX Cycle and so on. Short DRX Cycles after recent data activity can be useful as the probability of being scheduled again during a certain amount of time after recent activity can be higher.

The Short DRX configuration consists of two parameters:

- drx-ShortCycle: defines the Short DRX Cycle duration.

- drx-ShortCycleTimer: configured as integer which defines number of short cycles the UE should follow after the start of short cycle.

If there is no data activity during the period defined by drx-ShortCycleTimer x drx-ShortCycle, the UE enters long cycle i.e., the UE enters Long DRX Cycle upon the drx-ShortCycleTimer number of short cycles.

Within a Short DRX Cycle, the start of ‘On Duration’ is determined using long cycle parameter drx-StartOffset and drx-SlotOffet which is similar mechanism as long cycle. Basic operation when both Short and Long Cycles are configured is shown below.

3 C-DRX Configuration

The MAC entity is configured by the RRC layer with DRX configuration. Entire DRX configuration is sent in drx-Config IE structure within MAC-CellGroupConfig structure. In 3GPP Release15, this DRX configuration is applicable for all the NR serving cells. In Release 16, an IE structure drx-ConfigSecondaryGroup-r16 is introduced to configure DRX related parameters for the second DRX group (of serving cells).

When there are more than one serving cell, the network may configure DRX in two DRX groups with separate DRX parameters. When RRC does not configure a secondary DRX group, there is only one DRX group and all Serving Cells belong to that one DRX group which is referred to as ‘default DRX group’. When two DRX groups are configured, each Serving Cell is uniquely assigned to either of the two groups.

The IE structure of MAC-CellGroupConfig is given below, observe that default DRX group configuration is provided using drx-Config and secondary DRX group configuration is provided via drx-ConfigSecondaryGroup-r16.

*MAC-CellGroupConfig*
*drx-Config*	SetupRelease { DRX-Config }
. . .
*csi-Mask*	BOOLEAN
. . .
*drx-ConfigSecondaryGroup-r16*	SetupRelease { DRX-ConfigSecondaryGroup }
. . .

The DRX parameters that are separately configured for each DRX group are: drx-onDurationTimer, drx-InactivityTimer. This means that the network has the flexibility to control active time per serving cell. The DRX parameters that are common to the DRX groups (or serving cells) are: drx-SlotOffset, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle (optional), drx-ShortCycleTimer (optional), drx-HARQ-RTT-TimerDL, and drx-HARQ-RTT-TimerUL.

DRX-Config for default DRX group

The gNodeB configures the following RRC parameters for DRX. Each DRX parameter and it’s purpose is explained below. Note that some of the newly introduced (in Rel-16) DRX parameters are discussed in later sections when it is relevant.

*drx-Config*
drx-onDurationTimer	subMilliSeconds	INTEGER (0..31)
drx-onDurationTimer	milliSeconds	ENUMERATED {1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 400, 500, 600, 800, 1000, 1200, 1600}
drx-InactivityTimer	ms	ENUMERATED {0, 1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 500, 750, 1280, 1920, 2560}
drx-HARQ-RTT-TimerDL	symbols	INTEGER (0..56)
drx-HARQ-RTT-TimerUL	symbols	INTEGER (0..56)
drx-RetransmissionTimerDL	slots	ENUMERATED {0, 1, 2, 4, 6, 8, 16, 24, 33, 40, 64, 80, 96, 112, 128, 160, 320}
drx-RetransmissionTimerUL	slots	ENUMERATED {0, 1, 2, 4, 6, 8, 16, 24, 33, 40, 64, 80, 96, 112, 128, 160, 320}
drx-LongCycleStartOffset	Cycle length in ms (offset: 0 to cycle length)	ENUMERATED {10 (0..9), 20 (0..19), 32 (0..31), 40 (0..39), 60 (0..59), 64 (0..63), 70 (0..69), 80 (0..79), 128 (0..127), 160 (0..159), 256 (0..255), 320 (0..319), 512 (0..511), 640 (0..639), 1024 (0..1023), 1280 (0..1279), 2048 (0..2047), 2560 (0..2559), 5120 (0..5119), 10240 (0..10239)}
shortDRX
drx-ShortCycle	ms	ENUMERATED {2, 3, 4, 5, 6, 7, 8, 10, 14, 16, 20, 30, 32, 35, 40, 64, 80, 128, 160, 256, 320, 512, 640}
drx-ShortCycleTimer	num shortCycles	INTEGER (1..16)
drx-SlotOffset	1/32 ms units	INTEGER (0..31)

- drx-onDurationTimer specifies the amount of time at the beginning of each DRX Cycle (DRX ON) todecode PDCCH during every DRX cycle before entering the power saving mode (DRX OFF).

- drx-InactivityTimer specifies the time period for which the UE should be active after successfully decoding a PDCCH indicating a new transmission (UL or DL). This timer is (re-) started upon receiving PDCCH for a new transmission (UL or DL). Upon the expiry of this timer the UE should go to DRX mode(more details in Section 4). The value of this timer is configured in milliseconds (subframe level).

- drx-LongCycleStartOffset configure two parameters drx-LongCycle in ms and drx-StartOffset in multiples of 1 ms. drx-LongCycle defines Long DRX Cycle length and drx-StartOffset is used to determine the starting subframe number within a DRX cycle.

- drx-RetransmissionTimerUL and drx-HARQ-RTT-TimerUL are used in uplink data retransmission handling. Similarly, drx-RetransmissionTimerDL and drx-HARQ-RTT-TimerDL are used in downlink data re-transmission handling. This will be discussed in Section 4.

- drx-ShortCycle is the first type of DRX cycle (if configured) that needs to be followed after certain data activity. This IE indicates the length of the short cycle in ms which include ON time followed by an OFF (sleep) time.

- drx-ShortCycleTimer expressed as multiples of drx-ShortCycle. The timer value can vary from 1 to 16 (short DRX cycles). This timer indicates the number of Short DRX cycles to follow once entering Short DRX cycle and before entering the long DRX cycle.

- drx-SlotOffset defines the start of ‘On Duration’ w.r.t the start of subframe.

Note1: Same onDurationTimer value is applied for both long and short DRX cycles.

Note2: If shortDRX-Cycle is configured, the value of longDRX-Cycle shall be a multiple of the shortDRX-Cycle value.

DRX-Config for Secondary DRX Group

As discussed already, drx-ConfigSecondaryGroup-r16 is introduced in 3GPP In Release 16 to configure DRX related parameters for the second DRX group. The network configures only drx-InactivityTimer and drx-onDurationTimer as part of this configuration. In other words, the network has the flexibility to control ‘On Duration’ and ‘Inactivity time’ per serving cell.

It is important to note that if networks configure drx-config for secondary group, drx-InactivityTimer and drx-onDurationTimer values for the second DRX group are smaller than the respective values configured for the default DRX group in IE DRX-Config.

The IE structure of drx-ConfigSecondaryGroup-r16 is given below.

*DRX-ConfigSecondaryGroup*
drx-onDurationTimer	subMilliSeconds	INTEGER (0..31)
drx-onDurationTimer	milliSeconds	ENUMERATED {1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 400, 500, 600, 800, 1000, 1200, 1600}
drx-InactivityTimer	ms	ENUMERATED {0, 1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 500, 750, 1280, 1920, 2560}

Enabling Secondary Group DRX-Config for a serving cell

If drx-ConfigSecondaryGroup-r16 is configured, the gNodeB may indicate which serving cells belong to the secondary group within SCellConfig IE structure. The field secondaryDRX-GroupConfig-r16 is used to indicate whether the corresponding SCell belongs to the secondary DRX group or not. If this field is not included, that means, the SCell belongs to default DRX group.

*SCellConfig*
sCellIndex	SCellIndex
sCellConfigCommon	ServingCellConfigCommon
sCellConfigDedicated	ServingCellConfig
. . .
drx-ConfigSecondaryGroup-r16	ENUMERATED {true}

All serving cells in the secondary DRX group shall belong to one Frequency Range (FR) and all serving cells in the default DRX group shall belong to another Frequency Range.

4 DRX Operation

The triggering condition (timing) for DRX cycle is as follows:

If Short DRX Cycle is configured, the ‘On Duration’ period starts at a subframe satisfying the below condition…Within the calculated (as below) subframe, the actual ‘On Duration’ starts after a certain slot offset which is determined by drx-SlotOffset.

[(SFN×10) + subframe number] mod (drx-ShortCycle) = (drx-StartOffset) mod (drx-ShortCycle)

Upon the expiry of drx-ShortCycleTimer or if Short DRX Cycle is not configured, the UE uses Long DRX Cycle with the below triggering condition for the start of ‘On Duration’ period. Again, the actual ‘On Duration’ starts after a certain slot offset which is determined by drx-SlotOffset.

[(SFN × 10) + subframe number] mod (drx-LongCycle) = (drx-StartOffset)

As discussed already, during ‘On Duration’ period, the UE monitors PDCCH and if no data activity detected during this period, the UE would switch to sleep mode. Depending upon the kind of data activity one or a combination of below procedures could be triggered.

Reception of PDCCH indicating new transmission (UL or DL)

Whenever UE receives a PDCCH indicating a new transmission (DL or UL) on a Serving Cell of a specific DRX group, it should start or restart drx-InactivityTimer of the corresponding DRX group (default or secondary) in the first symbol after the end of the PDCCH reception.

If there is no new data transmission detected while drx-InactivityTimer was running, this timer gets expired. Upon the expiry of this timer, the UE enters into Short DRX Cycle (if configured) and continues for drx-ShortCycleTimer number of Short DRX Cycles. If Short DRX Cycle is not configured, the UE enters Long DRX Cycle as illustrated below. This procedure ensures that the DRX Cycle pattern is re-started after inactivity timer is expired.

Re-transmission Handling for PDSCH

Similar to LTE, HARQ re-transmissions are asynchronous in 5G NR downlink. When a DL transport block is erroneously received (CRC error), the UE sends a NACK to gNodeB and the gNodeB would then re-transmitthe same packet again. The UE would miss the re-transmission from the gNodeB if it is not in active state at the time of the re-transmission. Being awake all the time until receiving the re-transmitted packet is also not power efficient.

Technically, the network could re-transmit the packet at any time, but it is often as soon as possible. Depending upon network implementation and the HARQ round trip time, the network timing to re-transmit the DL packet may vary. So, the most important thing for the UE to be awake after this time duration. In order for UE to be awake during the time of re-transmission and not before, two timers are defined in 3GPP. The first timer drx-HARQ-RTT-TimerDL (in number of symbols) defines after how long the UE can expect a re-transmission. This way, the UE won’t be in active state beforehand.

Now the UE needs to know the time duration for which it must be awake to receive the re-transmission. Another timer drx-RetransmissionTimerDL (in number of slots) is defined for this purpose. This timer specifies maximum number of slots for which the UE should be monitoring PDCCH when a re-transmission from the gNodeB is expected by the UE.

When a new DL transmission is received by the UE, it should start the drx-HARQ-RTT-TimerDL in the immediate first symbol after transmitting NACK in the UL. Once drx-HARQ-RTT-TimerDL timer is expired, the UE starts drx-RetransmissionTimerDL timer in the next symbol and becomes active for this duration of this timer. As soon as UE detects a DL transmission for the corresponding HARQ process, it should stop the timer drx-RetransmissionTimerDL. This procedure is illustrated below.

Re-transmission Handling for PUSCH

Unlike LTE, HARQ re-transmissions are asynchronous in 5G NR uplink direction. When an UL transport block is erroneously received (CRC error) by the gNodeB, the UE may be asked to re-transmit the same packet. The UE would miss the re-transmission request (grant) from the gNodeB if it is not in active state at the time of re-transmission request. Being awake all the time until receiving the re-transmission request is also not power efficient.

In order for UE to be awake during the time of re-transmission request and not before, two timers are defined in 3GPP. The first timer drx-HARQ-RTT-TimerUL (in number of symbols) defines after how long the UE can expect a grant for uplink re-transmission.

Now the UE needs to know the time duration for which it has to be awake to receive the grant for uplink re-transmission. drx-RetransmissionTimerUL (in number of slots) is defined for this purpose. This timer specifies maximum number of slots for which the UE should be monitoring PDCCH when a grant for uplink re-transmission is expected by the UE.

The UE should start the timer drx-HARQ-RTT-TimerUL in the immediate first symbol after transmitting PUSCH. If PUSCH repetition is configured, then it is after first PUSCH transmission within a bundle. Once drx-HARQ-RTT-TimerUL timer is expired, the UE starts drx-RetransmissionTimerUL timer in the next symbol and becomes active for this duration of this timer. As soon as UE detects an UL transmission for the corresponding HARQ process, drx-RetransmissionTimerUL is stopped. This procedure is illustrated below.

Reception of DRX related MAC Control Element (MAC CE)

When the gNodeB knows that there is no additional data awaiting in the downlink, it can use a MAC CE to force the UE to terminate the ongoing active state and enter inactive state immediately. There is no point in being active when there is not going to be any data, this helps reduce UE’s power consumption. There are two MAC CEs defined in 3GPP MAC specification.

Note: When a DRX related MAC CE is received by the UE, the corresponding procedure (described below) is applied to both default group and secondary group.

1. DRX Command MAC CE

‘DRX Command MAC CE’ forces the UE to terminate the current active time and enter regular DRX cycle routine.

After receiving this MAC CE:

- The UE comes out of ‘active’ state and becomes inactive.

- The UE enters Short DRX Cycle mode if Short DRX Cycle is configured, else, the UE enters Long DRX Cycle mode.

The ‘DRX Command MAC CE’ is identified by a MAC sub-header with LCID: 60. It has a fixed size of zero bits (no payload).

The picture below illustrates the procedure for the case when Short DRX Cycle is configured.

The picture below illustrates the procedure for the case when only Long DRX Cycle is configured.

2. 2. Long DRX Command MAC CE

‘Long DRX Command MAC CE’ is used to force the UE to terminate the current active time and enter Long DRX cycle. In this case, the UE should enter Long DRX Cycle even if the Short DRX Cycle is configured. This is mainly useful if the gNodeB already knows that there is not going to be any data that requires Short DRX Cycle to be used.

After receiving this MAC CE.

- The UE comes out of ‘active’ state and becomes inactive.

- The UE enters Long DRX Cycle mode.

The ‘Long DRX Command MAC CE’ is identified by a MAC sub-header with LCID: 59. It has a fixed size of zero bits (no payload).

The picture below illustrates the procedure for the case when Short DRX Cycle is configured but, the procedure is same even if only Long DRX Cycle is configured; the UE always enters Long DRX Cycle mode.

DRX in conjunction with Semi-Persistent Scheduling

Downlink:

For downlink SPS, PDCCH carrying DCI 1_0 and 1_1 is addressed to Configured Scheduling-RNTI (CS-RNTI). The resource assignment received using CS-RNTI is referred to as Configured Downlink assignment. The Configured DL assignment in NR is given by the gNodeB to the UE, which stores this assignment and uses it according to the pre-configured timing given by the gNodeB.

As configured DL assignment periodically recurs, the UE uses this resource information to decode PDSCH. When the UE receives a MAC PDU using the configured DL assignment, the re-transmission handling is similar to that of regular DL data detection (PDSCH reception with explicit PDCCH DL assignment) as explained below.

If a MAC PDU is received in a configured DL assignment, the UE should start the drx-HARQ-RTT-TimerDL in the immediate first symbol after transmitting NACK in the UL. Once drx-HARQ-RTT-TimerDL timer is expired, the UE starts drx-RetransmissionTimerDL timer in the next symbol and becomes active for this duration of this timer.

Uplink:

For uplink SPS, PDCCH carrying DCI 0_0 and 0_1 is addressed to Configured Scheduling-RNTI (CS-RNTI). The grant received using CS-RNTI is referred to as Configured Grant. The grant can also be configured by RRC. The Configured Grant is given by the gNodeB to the UE, which stores the received grant and uses it according to the pre-configured timing given by the gNodeB.

As configured UL grant periodically recurs, the UE uses this resource information to transmit PUSCH. When the UE transmits MAC PDU using the configured UL grant, the re-transmission handling is similar to that of regular UL data transmission (PUSCH transmission with explicit PDCCH UL grant) as explained below.

If a MAC PDU is transmitted on PUSCH using a configured UL grant, the UE should start the timer drx-HARQ-RTT-TimerUL in the immediate first symbol after transmitting PUSCH. If PUSCH repetition is configured, then it is after first PUSCH transmission within a bundle. Once drx-HARQ-RTT-TimerUL timer is expired, the UE starts drx-RetransmissionTimerUL timer in the next symbol and becomes active for this duration of this timer in order to receive re-transmission request (grant).

5 Various Cases of ‘Active Time’

Active time is the duration that the UE monitors PDCCH. Below is the summary and explanation of all the ‘active time’ cases mentioned in MAC specification:

- drx-onDurationTimer configured for the DRX group is running

- drx-InactivityTimer configured for the DRX group is running

- drx-RetransmissionTimerDL or drx-RetransmissionTimerUL is running on any serving cell in the DRX group (as discussed in section 4)

- ra-ContentionResolutionTimer or msgB-ResponseWindow is running

The UE shall start ra-ContentionResolutionTimer in the first symbol after the end of the Msg3 transmission. Since the UE is waiting for the contention resolution which is via PDCCH reception on C-RNTI (in connected mode), the UE needs to be monitoring PDCCH. So the time duration in which mac-ContentionResolutionTimer is running is also considered as Active Time.

Similarly in a 2-step RA procedure, MsgB reception and contention resolution are important, so the UE needs to be in Active state to receive PDCCH while msgB-ResponseWindow is running.

- a Scheduling Request is sent on PUCCH and is pending

In order to receive the UL grant from the gNodeB, the UE has to be in active state after transmitting SR over the air on PUCCH.

- a PDCCH indicating a new transmission addressed to the C-RNTI has not been received after successful reception of a RAR in non-contention based RA procedure

In a non-contention based RA procedure, after receiving RAR, the UE should be in active state until PDCCH addressed to C-RNTI for a new transmission is received.

6 C-DRX Capabilities in UE Capability Information

The UE informs its C-DRX capabilities in UE Capability Information message to the gNodeB within the IE structure MAC-ParametersXDD-Diff. Summary of UE’s C-DRX capabilities are given below.

- longDRX-Cycle indicates whether UE supports long DRX cycle or not.

- shortDRX-Cycle indicates whether UE supports short DRX cycle or not.

- secondaryDRX-Group-r16 indicates whether UE supports secondary DRX group.

*UE-NR-Capability -> mac-Parameters -> MAC-ParametersXDD-Diff*
longDRX-Cycle	ENUMERATED {supported}
shortDRX-Cycle	ENUMERATED {supported}
. . .
secondaryDRX-Group-r16	ENUMERATED {supported}
. . .

7 Miscellaneous

Regardless of whether the MAC entity is monitoring PDCCH or not on the serving cells in a DRX group, the MAC entity transmits HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS on the Serving Cells in the DRX group when such is expected.

If the UE is not in Active time during an OFDM symbol, it shall not transmit periodic SRS and semi-persistent SRS, not report CSI on PUCCH and semi-persistent CSI configured on PUSCH.

Regardless of whether the UE is monitoring PDCCH or not, it should transmit HARQ feedback, aperiodic CSI on PUSCH, and aperiodic SRS when such is expected.

The UE may be configured with a CSI Mask to limit the transmission of CSI reports to the On-duration period of the DRX cycle. The field csi-Mask under MAC-CellGroupConfig is defined for this purpose.

*MAC-CellGroupConfig*
drx-Config	SetupRelease { DRX-Config }
. . .
*csi-Mask*	BOOLEAN
. . .
drx-ConfigSecondaryGroup-r16	SetupRelease { DRX-ConfigSecondaryGroup }
. . .

8 UE Power Savings Techniques in 3GPP Release-16

C-DRX techniques discussed so far allows UE to save power. However, 3GPP Release-16 introduced a couple of enhancements to existing DRX techniques and these features have proven to have shown substantial power saving gain. These features will be discussed in a separate post. <Link to follow>

Reference: 3GPP TS 38.321, 38.331, 38.306, and 38.300

5G NR: UE capability Information - FeatureSets and FeatureSetCombinations

2020-12-03T10:35:00.002+01:00

1. Introduction

At the time of registration for instance and before the UE would be able to perform data transfer or make/receive voice calls, the network needs to understand UE’s capabilities so that it can configure the UE accordingly.

The network requests for UE capabilities typically during registration procedure and stores it locally. This means that the UE doesn’t need to send UE capabilities every time RRC connection is established or re-established. However, the network can request the UE to send its capabilities at any time during RRC connected state.

Additionally, if the UE changes its radio capabilities, it will initiate a Tracking Area Updating procedure and include the IE UE radio capability information update needed in the TAU REQUEST message. The network would then request for new UE capabilities from the UE.

UE capability Information message size concerns

When LTE was introduced, the size of the UE capability Information message used to be fairly manageable. With the introduction of CA and LTE-Advanced features, the size of this message has grown to enormously, which is mainly due to multiple CA bands and UE capabilities defined per band and per band combination.

With the introduction of 5G NR and with NSA, the LTE UE capability message size would grow further as the UEs have to indicate EN-DC capabilities too.

Several optimisations have been introduced in 3GPP LTE standards to reduce the size of UE capability message (a couple of those are given below).

- Within the UE capability enquiry message, the network may include the IE requestedFrequencyBands to request the supported CA band combinations and non-CA bands specifically for a set of bands.

- Within the UE capability enquiry message, the network may include the maximum number of componentcarriers for which it needs to know the supported CA band combinations and non-CA bands. The IE requestedMaxCCsDL is corresponds to downlink and requestedMaxCCsUL corresponds to uplink.

- For UEs supporting (NG)EN-DC or NE-DC, the network may provide a list of NR and/or E-UTRA frequency bands for which the UE is requested to provide its supported NR CA and/or MR-DC band combinations. The IE requestedFreqBandsNR-MRDC is used for this purpose.

These kinds of optimizations are also proposed and implemented in NR. For instance, the network mandatorily includes frequency band list for which it needs capabilities from the UE. Here, the network needs a filtered UE capability in which the UE is requested to provide supported bands and band combinations. This procedure is optional in LTE.

Another important optimization introduced in NR and LTE Release-15 is the concept of Feature Sets. Feature sets concept is thoroughly discussed in the following section.

2 Concept of Feature Sets and Feature Set Combinations

For UEs supporting (NG) EN-DC or NE-DC, the size of UE capability information would be enormous if the UE has to report capabilities separately per each reported band in the corresponding band combination.

5G NR and LTE (from Release 15) onwards introduced so-called Feature Sets to overcome this problem.

- A Feature Set stores a set of UE capabilities and features.

- An ID is given to each Feature Set.

- Using Feature Set ID, a Feature Set can be linked/associated with one or more bands within the corresponding band combination.

- Using Feature Set ID, a Feature Set can be linked/associated within more than one band combinations.

- The Feature Sets mechanism makes sure that each Feature Set is reported only once to avoid duplication.

- A Feature Set contains a pair of feature sets for UL and DL separately.

- A Feature Set can either be NR feature set or E-UTRA feature set.

Since a set of capabilities/features using Feature Set are reported only once, and any Feature Set can be re-used with any band(s) in each band combination and also with multiple band combinations, the size of the UE capability Information message is drastically reduced.

Feature Set Combination is a two-dimensional matrix containing Feature Set entries. A Feature Set Combination refers to the IDs of the feature set(s) that the UE supports in that Feature Set Combination.

Finally, each Band Combination entry in the Band Combination List is linked/associated with a Feature Set Combination. This is done by indicating the ID of the Feature Set Combination that the UE supports for that band combination.

This is discussed in detail below with an example illustrations.

Step-1: Define Feature Sets

- The IE FeatureSets is used to provide pools of downlink and uplink features sets. The IE structure is given below.

*FeatureSets*
featureSetsDownlink	A list of FeatureSetDownlink for up to 1024 DL FeatureSets
featureSetsDownlinkPerCC	A list of up to 1024 CC-specific DL FeatureSets
featureSetsUplink	A list of FeatureSetDownlink(s) for up to 1024 UL FeatureSets
featureSetsUplinkPerCC	A list of up to 1024 CC-specific UL FeatureSets
. . .

- The IE FeatureSetDownlink or FeatureSetUplink indicates a set of features that the UE supports on the carriers corresponding to one band entry in a band combination. This IE also contains a respective sub-IE structure (featureSetListPerDownlinkCC or featureSetListPerUplinkCC) indicating which features the UE supports on the individual DL/UL carriers of the feature set.

Step-2: Define Feature Set Combination (s)

This is an important step in which the Feature Sets created in Step-1 would be used to create a Feature Set Combination.

The IE FeatureSetCombination is a two-dimensional matrix of FeatureSet entries.

A Feature Set Combination is defined such that each entry could be mapped to a band within the corresponding Band Combination.

- Each entry is referred to as FeatureSetsPerBand which contains a list of feature sets applicable to the carrier(s) of one band entry of the associated Band Combination.

- The number of FeatureSetsPerBands in a Feature Set Combination must have an equal number of band entries in an associated Band Combination. The first FeatureSetPerBand applies to the first band entry of the band combination, and so on.

- In case of NR, the actual feature sets for UL and DL are defined in the FeatureSets IE (discussed in Step-1) and referred to by their ID, i.e., their position in the featureSetsUplink/featureSetsDownlink list in the FeatureSet IE.

- In case of E-UTRA, the feature sets referred to from this list are defined in TS 36.331 and conveyed as part of the UE-EUTRA-Capability container.

FeatureSetCombination IE is structure is shown below.

The following example shows the mapping between a Band Combination and Feature Set Combination.

Step-3: Assigning and ID to a Feature Set Combination

The IE FeatureSetCombinationId identifies a FeatureSetCombination.

The FeatureSetCombinationId of a FeatureSetCombination is the position of the FeatureSetCombination in the featureSetCombinations list (in UE-NR-Capability or UE-MRDC-Capability).

- The FeatureSetCombinationId = 0 refers to the first entry in the featureSetCombinations list (in UE-NR-Capability or UE-MRDC-Capability).

The BandCombination entries in the BandCombinationList then indicate the ID of the FeatureSetCombination that the UE supports for that band combination.

Step-4: Linking a Feature Set Combination to a Band Combination

The Band Combination entries in the Band Combination List indicate the ID of the Feature Set Combinationthat the UE supports for that band combination. As shown in the below BandCombination IE structure, FeatureSetCombinationId is assigned to featureSetCombination IE.

*BandCombination*
bandList	List of BandParameters for all bands in this band combination
featureSetCombination	FeatureSetCombinationId
ca-ParametersEUTRA	CA-ParametersEUTRA
ca-ParametersNR	CA-ParametersNR
mrdc-Parameters	MRDC-Parameters
. . .

Linking of a Feature Set Combination to a Band Combination is illustrated in the below example.

3 UE Radio Capability Size estimation

For LTE, the primary overhead introduced by Rel-15 parameters is FeatureSetsEUTRA-r15. The theoretical overhead of FeatureSetsEUTRA-r15 can exceed 10 kbytes.

In practical deployment, the size of featureSetsEUTRA-r15 is variable depending on the number of DL/UL feature sets per band and the number of DL/UL feature sets per CC, in some cases the size offeatureSetsEUTRA-r15 can be several kbytes, and the total size of UE-EUTRA-Capability can be ~4 kbytes with realistic assumptions.

For NR and EN-DC, based on the newly introduced structure for UE capability in Rel-15, the size of the UE capability is dominated by rf-Parameters, featureSetCombinations and featureSets. The estimated theoretical maximum size of UE radio capabilities for NR or EN-DC (based on the maximum sizes in ASN.1) can approximate to 10000 kbytes,

In practical deployment, the supported bands/band combinations for a device is limited, and the eNB/gNB can for example request the UE to provide UE radio capabilities for a restricted set of band combinations. According to LTE experience and analysis of the NR capability, the estimated practical size of rf-Parametersis about 11~12 kbytes based on ~1024 band combinations and up to 4 bands per band combination.

The size of featureSetCombinations is highly variable depending on the number of feature set combinations and the number of feature sets per band, the size of featureSets is variable depending on the number of DL/UL feature sets per band and the number of DL/UL feature sets per CC. However, in some cases either the size of featureSetCombinations or featureSets can significantly exceed the size limitation of PDCP PDU. For example, with 256 feature set combinations, 8 feature sets per band, and 4 bands per band combination, the feature set combination list occupies ~22 kbytes.

Reference: 3GPP TS 38.331, 36.331, and 37.873

5G NR: DSS - Dynamic Spectrum Sharing

2020-11-24T17:33:00.000+01:00

1. Introduction to DSS

Dynamic Spectrum Sharing widely known as DSS or LTE-NR co-existence.

When introduced, earlier generation technologies such as 3G and LTE took several years to rollout due to all new ingredients like new spectrum, new RF, new underlying physical layer technology, and new antenna technology etc. Same is applicable for 5G deployments in FR1 mid-bands and FR2 (mmWave). In addition, delayed spectrum auctions further delays 5G deployment in many countries. In this case, the operators have no choice but to use existing LTE spectrum to deploy 5G.

Spectrum sharing helps faster 5G rollout by enabling spectrum, RF and antenna sharing between LTE and 5G. The network operators can deploy 5G using their existing LTE lower frequency bands, typically below 1 GHz. Initial 5G deployments using spectrum sharing would use NSA mode with an LTE anchor operating in the mid-band (1GHz - 3GHz).

Another equally important aspect where spectrum sharing is much needed is the coverage. To enjoy higher 5G data rates (eMBB), higher bandwidths are needed. Higher bandwidths are primarily possible with FR1 mid-bands (e.g., n78) and FR2. Operations in such high-frequency spectrum obviously shrinks the coverage.

In order to provide wide-area NR coverage, NR should be operated in low frequency spectrum i.e., providing a coverage layer for NR at lower frequencies. However, most of the lower frequency spectrum is already occupied by existing technologies, mostly LTE. This leads to one and only solution of deploying 5G on existing LTE frequency bands.

- On a side note, re-farming of existing LTE low band spectrum for 5G (with or without spectrum sharing) would enable the operators to smoothly transition towards standalone mode (SA) as lower bands could provide a coverage layer for NR.

By making use of spectrum sharing, operators can upgrade the existing 4G RF units in the field to enable fast rollout of 5G coverage and access to 5G services.

There are two possible solutions to LTE-NR co-existence on low frequency bands which are already used by LTE: Static Spectrum Sharing and Dynamic Spectrum Sharing.

With Static Spectrum Sharing, part of the existing LTE band is allocated to NR as shown below.

Both NR and LTE technologies use different carriers within the same band. This mechanism of spectrum sharing is the most spectrum in-efficient due to the following;

- In the beginning, the 5G device penetration is expected to be low and most of the traffic will still be on LTE. Since part of the spectrum is dedicated to NR, the available spectrum for LTE is reduced and becomes too congested. This means that 4G carrier is fully loaded and 5G carrier is unloaded which leads to low spectrum utilization as shown below.

- Furthermore, neither LTE nor NR can enjoy maximum bandwidth from that specific band hence reduce peak throughput.

With Dynamic Spectrum Sharing mechanism, LTE and NR would be dynamically sharing the spectrum. This allows network operators to dynamically adjust the bandwidth on LTE and NR depending upon the current traffic demand on the corresponding technology, see below picture. Moreover, this mechanism guarantees full bandwidth and therefore maximises peak data rate on each technology.

Note that, existing LTE protocols/users are unaffected by DSS i.e., only 5G devices will be made aware of the fact that DSS is being used on the corresponding NR band i.e., DSS guarantees 100% backward compatibility.

DSS technology is mainly relevant for FDD spectrum (600 – 2600 MHz).

2 How does DSS work?

DSS requires a very tight co-ordination between eNB and gNB to achieve reliable synchronization in time- and frequency-domains.

Based on the current load and traffic demand on each of the technologies, the network decides how much bandwidth should be given to LTE and NR devices. As shown below, the network can change/re-schedule the resource allocation at a Transmission Time Interval (TTI = 1 ms) granularity.

A proper coordination between 5G and 4G packet schedulers would ensure that the same resource is not allocated to both systems at a given time.

It is important to note that both 15 kHz and 30 kHz numerologies are supported with DSS while LTE transmissions using 15 kHz subcarrier spacing. However, initial DSS deployments aim at NR operating at the same SCS as LTE (15 kHz).

2.1 Co-Existence in the Uplink:

Achieving LTE-NR co-existence in the uplink is much simpler and straight forward as compared to downlink.

LTE and NR packet schedulers must co-ordinate and allocate uplink resources in such a way that NR PUSCH and LTE PUSCH transmissions won’t collide. Similar care should be taken when allocating resources for uplink control signalling e.g., PUCCH.

Another aspect when it comes to co-existence of LTE and NR is time synchronization in the uplink i.e., it is important to align the timing advances applied by LTE and NR uplink transmissions.

- The gNB provides the UE with the necessary Timing Advance Offset value using the field n-TimingAdvanceOffset within RRCReconfiguration or SIB1 message. The UE adds this offset to TA command provided by the base station and adjust its uplink accordingly. This field/IE is separately discussed in section 5.

When it comes to frequency domain synchronization in the uplink, the orthogonality between LTE and NR uplink carriers have to be guaranteed.

- The fundamental difference between LTE and NR uplink waveforms is that, LTE doesn’t transmit any data on the DC carrier whereas DC carrier can be used for uplink data in NR. This means that a 7.5 kHz frequency shift is applied on LTE SC-FDMA waveform whereas NR waveform doesn’t have to apply this frequency shift.

- In LTE-NR co-existence situation (DSS), this leads to a frequency difference between NR and LTE uplink subcarrier mapping of 7.5 kHz which will cause inter-carrier interference. To mitigate for the ICI caused by this frequency shift, the gNB can instruct a UE to apply 7.5 kHz frequency shift using the field frequencyShift7p5khz within RRCReconfiguration or SIB1 message. It is mandatory for a DSS supporting UE to support 7.5 kHz frequency shift.

- So, in DSS case, the network makes sure that LTE and NR uplink transmissions are aligned in the frequency domain by configuring the field frequencyShift7p5khz. With this 7.5 kHz frequency shift, LTE and NR can co-exist within the same frequency/RB/RE grid.

2.2 Co-Existence in the Downlink:

For LTE-NR co-existence in the downlink time domain synchronization is needed for radio frame synchronization between LTE and NR. The time domain synchronization between LTE and NR could easily be derived at the base station by making use of GPS for example.

For frequency domain synchronization in the downlink, the base stations can make use of a common frequency reference when generating baseband signal.

As discussed already, LTE doesn’t transmit any data on the DC carrier whereas DC carrier can be used for data in NR. This in general means that LTE and NR RB grids are not aligned. It is the responsibility of the base station scheduler to avoid overlapping RB allocation.

The core requirement for the DSS is that, LTE and NR time and frequency resources are scheduled/shared in such a way that existing LTE “non-scheduled” resources used for PSS/SSS/PBCH and CRS are not affected. To ensure backward compatibility, it is not possible to change the (sort of) fixed allocation defined for these LTE signals.

For DSS in the downlink, the main challenge is that the LTE is transmitting CRS in 4 or 6 non-contiguous OFDM symbols of each subframe (4 OFDM symbols for CRS when using 1 or 2 antenna ports whereas 6 OFDM symbols when using 4 antenna ports). The NR time and frequency allocation in the downlink has to be designed to not collide with CRS to avoid performance degradation to LTE users.

LTE CRS structure when using 2 antenna ports is shown below;

SSB transmission:

- When NR is using 30 kHz SCS, it is straight forward to time multiplex SSB between two CRS symbols. With 30 kHz SCS, a resource element would occupy half the duration to that of LTE’s 15 kHz SCS. This means that just two (LTE) symbols are good enough for SSB transmission (4 NR OFDM symbols) and two consecutive symbols are always available between the two CRS occupied symbols irrespective of number of antenna ports.

- The tricky bit is when using 15 kHz numerology for NR; as can be seen from the above picture, there are only 3 contiguous OFDM symbols without any CRS transmissions but NR SSB requires 4 symbols with 15 kHz SCS. So, it is not possible to transmit SSB. An alternate approach would be for the eNB to use MBSFN subframes.

- In MBSFN subframes, the last 12 OFDM symbols are reserved for eMBMS and these reserved symbols can be used for NR signals instead of eMBMS. This topic is further discussed in section 3.

5G PDSCH Transmission:

- For NR PDSCH channel transmission, rate matching can be used to avoid the REs occupied by LTE CRS.

- In this case, NR PDSCH can be spread around LTE CRS both in time and frequency domain by making use of PDSCH rate matching around REs occupied by LTE CRS.

- In order to be able to properly receive such a rate-matched PDSCH, the gNB provides the UE with required LTE-CRS configuration using the IE RateMatchPatternLTE-CRS (discussed in section 5)

- It is important to note that rate matching around LTE CRS is only possible for the 15kHz SCS.

· For 30 kHz SCS, multiplexing of LTE CRS and NR PDSCH in frequency domain is not possible due to mismatch in bandwidth of subcarriers, hence only time domain multiplexing is possible.

- Rate matching around the LTE PSS/SSS and PBCH can be done by defining reserved resources according to bitmaps which are configured by the network. This rate matching pattern is configured using RRC IE rateMatchPatternToAddModList.

3 LTE MBSFN subframes for NR SSB Transmissions

As discussed already, in LTE-NR co-existence scenario the main challenge with 15 kHz NR numerology is that there are only 3 contiguous OFDM symbols without any CRS transmissions but NR SSB requires 4 OFDM symbols with 15 kHz SCS. Since the initial DSS deployments would use 15 kHz NR SCS, this is a serious issue for DSS.

If NR SSB is transmitted in those LTE OFDM symbols in which LTE CRS is transmitted (around LTE CRS REs), the synchronization based on SSB and downlink measurements might be inaccurate. So, it is important to completely avoid those LTE symbols in which LTE CRS is transmitted.

LTE MBSFN subframes could be used to transmit NR SSB as discussed below in detail;

LTE MBSFN stuff:

LTE MBSFN is used in LTE for evolved Multimedia Broadcast Multicast Services (eMBMS).

As of Release 14, in a radio frame, the network can configure any of subframes #1, #2, #3, #4, #6, #7, #8, and #9 as MBSFN subframes for FDD case, and for TDD case, subframes #3, #4, #7, #8, and #9 can be MBSFN subframes. This configuration is conveyed to the UE using LTE SIB2.

Within MBSFN subframes and depending upon downlink channel bandwidth, starting 1 or 2 OFDM symbols carries information such as PCFICH, PDCCH, CRS, and PHICH. The other symbols within the MBSFN subframe cannot be used for LTE data transmissions and are strictly reserved for eMBMS purpose.

Utilizing LTE MBSFN subframes for SSB transmissions in DSS:

As discussed already, for 15 kHz SCS, in regular LTE subframe, there are only 3 contiguous OFDM symbols without any CRS transmissions but NR SSB requires 4 symbols with 15 kHz SCS. So, it is not possible to transmit SSB in regular LTE subframes.

It is important to note that only the first 1 or 2 OFDM symbols within MBSFN subframes carries LTE CRS. This opens the door for DSS utilizing MBSFN subframes for NR SSB transmissions as there are more than 3 consecutive OFDM symbols without CRS transmissions available in those MBSFN subframes.

In summary, DSS can utilize MBSFN region (except first OFDM symbol) within MBSFN subframe to transmit NR data mainly NR SSBs as SSBs won’t collide with LTE CRS. On the other hand, LTE devices in the cell are unaffected as those devices understand from SIB2 MBSFN configuration that the respective subframe is not meant for regular LTE data transmissions.

However, if a lot of LTE subframes are converted to MBSFN subframes, LTE only users will experience lower throughputs as those subframes are unavailable for LTE data transmissions. Hence a better approach would be to use MBSFN subframes for NR SSB transmissions and non-MBSFN (regular) LTE subframes for NR data by using DSS.

Which SSBs to transmit in MBSFN subframes?

As discussed already, utilizing MBSFN subframes for SSB transmissions is mainly related to 15 kHZ SCS.

As explained in the post NR: SSB and in section 4.1, 38.213; within a 5ms half frame, the starting OFDM symbol index for a candidate SSB within SS burst set depends upon subcarrier spacing (SCS) and carrier frequency/band. With NR carrier frequencies below 3GHz and SCS=15 kHz, the starting OFDM symbol index for SSBs within SS burst set = {2,8,16,22} => only 4 SSBs are possible to be transmitted in symbols 2, 8, 16 and 22.

With 15kHz SCS, one NR slot = one LTE/NR subframe = 1ms. This means in a given half frame (5ms), there are 5 NR slots or 5 NR subframes or 5 LTE subframes. So, SSB#0 and SSB#1 are transmitted in subframe#0 (starting symbol #2 and #8), SSB#2 is transmitted in subframe#1 (starting symbol number = 16 mod 14 (total no. of symbols) = 2) and SSB#3 is transmitted in subframe#1 (starting symbol number = 22 mod 14 (total no. of symbols) = 8).

As discussed already, MBSFN can’t be configured in subframes #0 and #5, this means transmitting SSB #0 and SSB#1 is not possible as they fall in subframe #0 which cannot be configured as an MBSFN subframe. This leaves with only SSB #2 and SSB#3 in subframe #1.

Since default periodicity of SSB is 20ms, configuring one MBSFN subframe is good enough (subframe #1) once in every 20ms.

As an example, a typical network DSS deployment scenario is considered. The network provides the following MBSFN configuration within lte-CRS-ToMatchAround via NR RRCReconfiguration message.

- The parameter subframeAllocation1 = fourFrames is a bitmap indicating MBSFN subframe allocation in four consecutive radio frames; (for FDD) starting from the first radio frame, the allocation applies to subframes #1, #2, #3, #6, #7, and #8 within each radio frame.

- Thus, the given subframe allocation can be split into 6 bits each: 110000 000000 100000 000000 and each 6 bit represents a radio frame. Here, first two subframes #1 and #2 in the 1^st radio frame and subframe #1 in the 3^rd radio frame are MBSFN subframes.

- As illustrated below, this configuration repeats once every 4 radio frames as the configured allocation periodicity = 4 frames (radioframeAllocationPeriod).

Finally, within the MBSFN subframe #1 (1^st and 3^rd radio frames), SSB #2 and/or SSB #3 can be transmitted as shown below. This also aligns with the SSB periodicity of 20ms.

It is worth noting that NR PDSCH, NR DMRS could also be part of this MBSFN subframe.

As discussed above, it is possible to use SSB#2 and/or SSB#3 within MBSFN subframes. However, networks might choose to transmit only one SSB due to the following reasons.

- Beam forming on low DSS bands might not be significant.

- As the initial DSS deployments are based on software upgrade of existing LTE equipment, beam forming might not be supported.

4 UE Capabilities and NR Features required for DSS

LTE CRS rate matching is the key feature for DSS, the UE should know the LTE CRS pattern that it shall rate match around when receiving DL transmissions on a cell sharing LTE and NR.

Other NR UE features to also consider important for an efficient operation of DSS:

- NR PDCCH in symbol 2

- Rate matching pattern to map around LTE PSS/SSS and PBCH

- TRS in symbol 6 and 10

- Flexible CSI-RS placement

- Alternative PDSCH DM-RS pattern when LTE CRS rate matching is configured

- 7.5 kHz UL shift

Some of the above items are discussed in detail below.

NR PDCCH in symbol 2:

- It is important to note that NR PDCCH cannot be transmitted on those symbols where LTE CRS is being transmitted. LTE CRS is present in 1^st OFDM symbol in case of 2 antenna ports and 1^st and 2^nd OFDM symbols in case of 4 antenna ports.

- Since NR allows PDCCH transmission on any symbol, it is possible to transmit PDCCH on any symbol that doesn’t contain LTE CRS. The network can inform the UE about the starting OFDM symbol(s) in which PDCCH is transmitted by making use of the field monitoringSymbolsWithinSlot.

Rate matching pattern to map around LTE PSS/SSS and PBCH

7.5 kHz UL shift

- As discussed already, the fundamental difference between LTE and NR uplink waveforms is that LTE doesn’t transmit any data on the DC carrier whereas DC carrier can be used for uplink data in NR. This means that a 7.5 kHz frequency shift is applied on LTE SC-FDMA waveform whereas NR waveform doesn’t have to apply this frequency shift.

Alternative PDSCH DM-RS pattern when LTE CRS rate matching is configured

- When PDSCH time-domain duration is 13 or 14 OFDM symbols and if only one additional DMRS is configured, the DMRS is located at the 11th OFDM symbol. In the case of DSS, this DMRS symbol coincides with LTE CRS symbol. Hence, for additional DMRS symbol, OFDM symbol 12 is used instead of OFDM symbol 11.

- By including the field additionalDMRS-DL-Alt, the UE indicates its support for using OFDM symbol 12 for additional DMRS. It is applied to 15kHz SCS and one additional DMRS case only.

5 Summary of DSS related IEs/Fields

5.1 UE Capability Information

The following information is conveyed in the UECapabilityInformation message from the UE to the network.

rateMatchingLTE-CRS:

- For NR PDSCH transmission, rate matching can be used to avoid the REs occupied by LTE CRS. In this case, NR PDSCH can be spread around LTE CRS both in time and frequency domain by making use of PDSCH rate matching around REs occupied by LTE CRS.

- The field rateMatchingLTE-CRS indicates whether the UE supports receiving PDSCH with resource mapping that excludes the REs configured by LTE CRS.

- The UE indicates the support individually for each band.

- This is the most important field. Based on the presence of this field, the network can determine whether a UE supports DSS or not.

UE-NR-Capability -> rf-Parameters -> BandNR
. . .

rateMatchingLTE-CRS
ENUMERATED {supported}
. . .

Additionaldmrs-DL-Alt:

As discussed in section 4, this field indicates whether the UE supports the alternative additional DMRS position for co-existence with LTE CRS. It is applied to 15kHz SCS and (only) one additional DMRS case only;

FeatureSetDownlink-v1540
. . .

additionalDMRS-DL-Alt
ENUMERATED {supported}
. . .

5.2 DSS related information in Downlink

lte-CRS-ToMatchAround:

- This IE is used to configure the UE with a pattern to rate match around LTE CRS and is configured as part of RRCReconfiguration or SIB1.

lte-CRS-ToMatchAround = RateMatchPatternLTE-CRS
carrierFreqDL
INTEGER (0..16383)
carrierBandwidthDL
ENUMERATED {n6, n15, n25, n50, n75, n100, spare2, spare1}
mbsfn-SubframeConfigList
EUTRA-MBSFN-SubframeConfigList
nrofCRS-Ports
ENUMERATED {n1, n2, n4}
v-Shift
ENUMERATED {n0, n1, n2, n3, n4, n5}

- Example below;

frequencyShift7p5khz:

- As discussed in section 5, to mitigate for the ICI caused by the underlying LTE and NR waveform frequency shift, the gNB can instruct a UE to apply 7.5 kHz frequency shift using the field frequencyShift7p5khz within RRCReconfiguration or SIB1 message.

- It is mandatory for a DSS supporting UE to support 7.5 kHz frequency shift.

ServingCellConfigCommon or ServingCellConfigCommonSIB
. . .

frequencyShift7p5khz
ENUMERATED {true}
. . .

n-TimingAdvanceOffset:

- When it comes to co-existence of LTE and NR is time synchronization in the uplink i.e., it is important to align the timing advances applied by LTE and NR uplink transmissions.

ServingCellConfigCommon or ServingCellConfigCommonSIB
. . .

n-TimingAdvanceOffset
ENUMERATED {n0, n25600, n39936}
. . .

- This field values are provided in 38.133 table 7.1.2-2 and are presented below.

monitoringSymbolsWithinSlot:

- As discussed already, NR PDCCH cannot be transmitted on those symbols where LTE CRS is being transmitted. LTE CRS is present in 1^st OFDM symbol in case of 2 antenna ports and 1^st and 2^nd OFDM symbols in case of 4 antenna ports.

- Since NR allows PDCCH transmission on any symbol, it is possible to transmit PDCCH on any symbol that doesn’t collide with LTE CRS. The network can inform the UE about the starting OFDM symbol(s) in which PDCCH is transmitted by making use of the field monitoringSymbolsWithinSlot.

- This field is configured as part of PDCCH-Config.

rateMatchPatternToAddModList:

Reference: 3GPP TS 38.331 (v16.2.0), 38.133 (v16.3.0), 38.306 (v16.0.0), and Tdoc RP-182635

5G NR: 2-Step Random Access Procedure (Release-16)

2020-04-26T23:05:00.001+02:00

1. Introduction

As in the case of LTE, the RA procedure can take two distinct forms: Contention-Based Random Access (CBRA) and Contention-Free Random Access (CFRA).

The RA procedure is thoroughly discussed in the post 5G NR: Random Access Procedure. The CBRA procedure adopted in LTE as well as in NR-Release 15 is a 4-step procedure (Msg1, Msg2, Msg3 and Msg4).

With 4-step CBRA procedure, after transmitting PRACH preamble (Msg1), the UE should wait for an RA response (Msg2) from the network and then transmit PUSCH (Msg3). After receiving Msg3, the network resolves the contention in Msg4.

There are two optimization possibilities to reduce the latency involved in 4-step RA procedure:

1. Reduce or completely avoid the time it takes for the UE to receive Msg2.

2. Reduce or completely avoid the time it takes for the network to wait before transmitting Msg4.

3GPP in Release-16, has introduced a new RA type to implement the above said optimizations.

With 2-step CBRA procedure;

1. PRACH (Msg1) and PUSCH (Msg3) are transmitted together and is named as MsgA.

2. RAR (Msg2) and contention resolution (Msg4) transmitted together and is named as MsgB.

The new 2-step RA type not only reduces the latency involved in the overall RA procedure but also reduces the control signalling overhead.

The 3GPP in Release-16 has named legacy RA procedure as 4-step RA type or Type-1 RA procedure and the new 2-step RA procedure as 2-step RA type or Type-2 RA procedure.

One important point to note w.r.t. CFRA in 4-step RA type is that, even though CFRA procedure doesn’t have 4 steps (only steps-0, 1, 2), both CFRA and CBRA procedures fall under single RA type which is 4-step RA type.

Note the following important points w.r.t 2-step RA type:

1. All triggers for 4-step RA type are considered valid for 2-step RA type too and no new trigger is defined for 2-step RA type in Release-16.

2. It is applicable for RRC_INACTIVE , RRC_CONNECTED and RRC_IDLE states.

3. Channel structure of MsgA is such that PRACH preamble and PUSCH carrying payload are transmitted in TDM fashion.

4. The network should provide MCS(s) and time-frequency resource size(s) of PUSCH in MsgA in RRC configuration beforehand.

5. MsgA-PUSCH contents are same as Msg3 contents of 4-step RA type.

6. MsgB contents are similar to that of combined Msg2 and Msg4 contents of 4-step RA type.

7. A new RNTI is defined in Release-16 for MsgB reception - MsgB-RNTI.

Similar to 4-step RA type, both CBRA and CFRA procedures are possible in 2-step RA type too. 4-step RA type is briefly discussed in the next section and 2-step RA type is discussed in Section 3.

2 4-step RA type

4-step RA type is thoroughly discussed in the post 5G NR: Random Access Procedure.

Both CBRA and CFRA procedural flows with 4-step RA type are shown below.

In 4-step RA type CBRA, the UE randomly selects an RA preamble from a pool of preambles shared with other UEs in the cell. If multiple UEs transmit same preamble, all those UEs decode same RA response content and transmit PUSCH on the same UL time/frequency resources. In the last step, the network resolves the contention.

- The RA preamble transmission is known as Msg1.

- The random-access response (RAR) is known as Msg2.

- The PUSCH carrying uplink data using the UL Grant received in Msg2 is known as Msg3.

- The contention resolution is known as Msg4.

In CFRA, the UE uses a dedicated preamble provided by the network specifically to this UE via RRC signaling or PDCCH order.

- The RA preamble transmission is known as Msg1.

- The random-access response (RAR) is known as Msg2.

3 2-step RA Type

In 2-step RA type (shown below), as the name indicates, there are only two steps involved.

Both CBRA and CFRA procedures are defined even in this new RA type.

3.1 CBRA in 2-step RA Type:

- In both CBRA and CFRA procedures, MsgA includes a preamble transmission on PRACH and a payload transmission on PUSCH. In 4-step RA type, the UE never transmits a PUSCH before receiving Msg2 (RAR).

- Note the name ‘MsgA’ is used here instead of ‘Msg1’.

- After MsgA transmission, the UE monitors for a response from the network within a configured window (configured by RRC parameter msgB-ResponseWindow-r16).

- If contention resolution is successful upon receiving the network response, the UE ends the RA procedure as shown in Fig C above.

- In 2-step RA type, the RA response and the contention resolution together are known as MsgB where as Msg2+Msg4 are used in 4-step RA type.

- In some cases, within MsgB, the network may ask the UE to fallback to 4-step RA type. Then the UE performs Msg3 transmission and monitors contention resolution. If contention resolution is not successful after Msg3 (re-)transmission(s), the UE goes back to MsgA transmission i.e., switches back to 2-step RA type.

- If the RA procedure with 2-step RA type is not completed after a number of MsgA transmissions, the UE can be configured to switch to CBRA with 4-step RA type. This is explained in later sections.

3.2 CFRA in 2-step RA Type:

- Note ‘MsgA’ is used here instead of ‘Msg1’.

- After MsgA transmission, the UE monitors for a response from the network within a configured window (msgB-ResponseWindow-r16).

- For CFRA, upon receiving the network response, the UE ends the RA procedure as shown in Fig D above. In this case, the response to MsgA is known as MsgB unlike Msg2 in the case of 4-step RA type.

- If the RA procedure with 2-step RA type is not completed after a number of MsgA transmissions, the UE can be configured to switch to CBRA with 4-step RA type. This is explained in later sections.

4 Selection between 2-step and 4-step RA Types

The UE selects 2-step or 4-step RA type at the initiation of the RA procedure based on network configuration:

CBRA case:

- When both 4-step and 2-step RA types are configured by the network, an RSRP threshold is used by the UE to select between 2-step RA type and 4-step RA type. The RSRP threshold is configured by the field msgA-RSRP-Threshold.

- If the RSRP is above this threshold, the UE select 2-step RA type otherwise, 4-step RA type is chosen.

CFRA case:

- When CFRA resources for 4-step RA type are configured, the UE performs random access with 4-step RA type.

- When CFRA resources for 2-step RA type are configured, UE performs random access with 2-step RA type.

- The network does not configure CFRA resources for both 4-step and 2-step RA types at the same time.

- CFRA with 2-step RA type is only supported for handover.

For random access in a cell configured with Supplementary Uplink (SUL), the network can explicitly signal which carrier to use (UL or SUL). Otherwise, the UE selects the SUL carrier if and only if the measured quality of the DL is lower than a broadcast threshold.

- UE performs carrier (UL or SUL) selection before selecting between 2-step and 4-step RA type. The RSRP threshold (msgA-RSRP-Threshold) for selecting between 2-step and 4-step RA type can be configured separately for UL and SUL.

5 MsgA Transmission

As discussed already, the MsgA transmission consists of PRACH preamble transmission (MsgA-PRACH) and a PUSCH payload transmission (MsgA-PUSCH).

The procedure for selecting PRACH resources is similar to that of 4-step RA type but using the 2-step RA type associated parameters.

The UE transmits PUSCH after the transmission of PRACH (TDM). The transmission of PUSCH is after the PRACH transmission by at least N symbols where the value of N depends upon SCS of the active UL BWP (as given below).

µ	SCS (kHz)	N
0	15	2
1	30	2
2	60	4
3	120	4

The actual time offset between PUSCH and the start of each PRACH slot is configured by msgA-PUSCH-TimeDomainOffset. The first PUSCH occasion (PO) in each slot is defined by SLIV which is configured by startSymbolAndLength-MsgAPO.

Of course, a PUSCH will be transmitted only in UL symbols (per UL-DL configuration).

The time and frequency resource allocation of PRACH and PUSCH will be discussed in a separate post.

Once MsgA is transmitted, the UE should monitor for RA response. The UE uses RA_RNTI in 4-step RA type whereas in 2-step RA type, MsgB-RNTI is used. As can be seen below, the calculation of MsgB-RNTI is almost similar to that of RA-RNTI.

MsgB-RNTI = 1 + s_id + 14×t_id + 14×80×f_id + 14×80×8×ul_carrier_id + 14×80×8×2

where s_id is the index of the first OFDM symbol of the PRACH occasion (0 ≤ s_id < 14), t_id is the index of the first slot of the PRACH occasion (RO) in a system frame (0 ≤ t_id < 80), f_id is the index of the RO in the frequency domain (0 ≤ f_id < 8), and ul_carrier_id is the UL carrier used for RA preamble transmission (0 for NUL carrier, and 1 for SUL carrier).

Contents of MsgA:

The contents of MsgA are similar to the contents of Msg3 when using 4-step RA type. For full details about the contents of Msg3, see here. In a broad sense, the contents of the MsgA/Msg3 are of two types as described below;

1. The UE may already have a C-RNTI (e.g. UE in RRC_CONNECTED) at the time of RA procedure initiation. Ex: RA procedure was initiated by a PDCCH order, during CFRA initiated by synchronous RRC reconfiguration (e.g. handover) etc…

- In this case, the UE would send C-RNTI MAC CE within MsgA/Msg3. Depending upon the scenario in which RA procedure is triggered, the UE may also include additional information such as RRCReconfigurationComplete.

2. The UE didn’t have a C-RNTI at the time of RA procedure initiation, e.g., during RRC connection re-establishment procedure, RRC connection resumption procedure etc…

- In this case, the UE would send CCCH SDU in MsgA/Msg3…e.g., RRCResumeRequest, RRCReestablishmentRequest etc…

6 MsgB Reception and Contention Resolution

After transmission of MsgA (PRACH and PUSCH), the UE needs to monitor for a RA response. Similar to 4-step RA type, an RA response window is defined by the field msgB-ResponseWindow.

The RA response window starts at least one symbol after the last symbol of the PUSCH occasion corresponding to the MsgA-PUSCH transmission and lasts for the duration configured by msgB-ResponseWindow. The window length can be configured to be 1, 2, 4, 8, 10, 20, 40, 80, 160, or 320 slots.

During msgB-ResponseWindow, the UE attempts to detect DCI format 1_0 with CRC scrambled by a corresponding MsgB-RNTI/C-RNTI.

- If C-RNTI MAC CE was included in MsgA, the UE monitors PDCCH on C-RNTI.

- If C-RNTI MAC CE was not included in MsgA, UE monitors PDCCH on MsgB-RNTI.

As shown below in the overall flow diagram, there are two possible scenarios depending upon whether the UE receives MsgB successfully or not.

Scenario1: UE receives MsgB successfully:

The steps that the UE follow after receiving MsgB depends upon the contents of MsgA that the UE has sent to the gNB and there by the RNTI used by the gNB for MsgB.

1. Random Access Response is received on C-RNTI:

If UE has included C-RNTI MAC CE in MsgA, after receiving MsgB, the UE considers that RA procedure is successfully completed. The procedure ends here.

- In this case, the response from the network could be an uplink grant or downlink assignment addressed to C-RNTI. Additionally, if gNB wants to adjust UE’s uplink timing, it may send Absolute Timing Advance Command MAC CE subPDU.

2. Random Access Response is received on MsgB-RNTI:

If UE has not included C-RNTI MAC CE in MsgA, the response from the network (PDCCH) is addressed MsgB-RNTI.

MsgB contents could be fallbackRAR or successRAR or Backoff Indicator (BI). The UE procedure when ‘BI’ is received is same as that of 4-step RA type. If the UE receives fallbackRAR or successRAR, the procedure is explained below in Case1 and Case2 respectively.

Case1 - The gNB is not able decode MsgA-PUSCH correctly (fallbackRAR):

It is possible that the network detects MsgA-PRACH preamble but not able to decode MsgA-PUSCH correctly. In this case, the network would order the UE to fallback to 4-step RA type by transmitting a required grant for transmission Msg3 => This is basically retransmission of MsgA-PUSCH using Msg3 of 4-step RA type.

How the UE would know if the network is ordering the UE to fallback? If the MsgB contains fallbackRAR MAC subPDU (new in Release-16), the UE understands that it has to switch to Msg3 transmission.

It is important to note that if the 2-step RA type was initiated as CFRA procedure, then the UE considers the RA procedure is successful even if it has received fallbackRAR. The RA procedure ends here.

The following sequence diagram illustrates the fallback procedure for CBRA case;

A fallbackRAR consists of a RAPID, an uplink grant to transmit the Msg3, Timing Advance Command and Temporary C-RNTI.

When MsgB is received, the UE first checks if the received RAPID matches the transmitted preamble ID (MsgA-PRACH). If a match is found, the UE processes the TA Command and applies the UL Grant for transmission of Msg3 using the received Temporary C-RNTI.

As shown below, the structure of fallbackRAR MAC subPDU is similar to the one with MAC RAR (4-type RA type).

After Msg3 transmission and possible re-transmission(s), if the contention resolution is still not successful, the UE goes back to MsgA transmission.

Case2 - The gNB successfully decodes MsgA-PUSCH (successRAR):

In this case, the gNB would transmit a successRAR MAC subPDU within MsgB. The successRAR MAC subPDU (new in Release-16) contents are shown below.

- UE Contention Resolution Identity: This field contains the UL CCCH SDU. If the UL CCCH SDU is longer than 48 bits, it contains the first 48 bits of the UL CCCH SDU.

- R: Reserved bit, set to "0".

- TPC (2-bits): The TPC command for the PUCCH resource containing HARQ feedback for MsgB.

- HARQ Feedback Timing Indicator (3-bits): The PDSCH-to-HARQ feedback timing indicator field for MsgB HARQ feedback.

- PUCCH Resource Indicator (4-bits): The PUCCH resource indicator for HARQ feedback for MsgB.

- Timing Advance Command (12-bits): This field indicates the amount of timing adjustment to applied for further UE transmissions.

- C-RNTI (16-bits): C-RNTI to be used by the UE upon completion of Random Access.

After receiving the successRAR MAC subPDU, the UE processes the Timing Advance Command, and PUCCH resource Indicator and HARQ feedback Timing Indicator and used in transmitting MsgB HARQ feedback using PUCCH.

More importantly, the UE checks if the CCCH SDU included in the MsgA and the received Contention Resolution Identity matches. If both are matched, the UE considers the RA procedure is successfully completed. Otherwise, the procedure that the UE follows to retransmit RA preamble is illustrated in the overall flow diagram discussed in the beginning of this section.

The following sequence diagram shows a successful 2-step RA type.

Scenario2: UE did not receive MsgB:

In case if the gNB could not detect UE’s Msg1-PRACH preamble, the UE doesn’t receive any response (MsgB) from the gNB. In this case, the UE would continue to decode until the expiry of msgB-ResponseWindow.

If the UE doesn’t receive a valid response from the network during the msgB-ResponseWindow, the UE either re-transmits MsgA or falls back to 4-step RA type and starts transmitting Msg1.

The field msgA-TransMax defines maximum number of MsgA preamble transmissions performed before switching to 4-step RA type. If this field is configured, the UE retransmits MsgA for msgA-TransMax-1 times and then falls back to 4-step RA type.

Once switched to 4-step RA type, the UE starts to transmit Msg1 and still if no response is received from the network, it would continue to re-transmit Msg1 until total number of preamble transmissions (MsgA+Msg1 attempts) reach the value configured by preambleTransMax.

It is important to note that if the original 2-step RA type is CFRA, when RA type is switched to 4-step RA type, the UE discards the dedicated preamble and switches to CBRA procedure.

The following flow diagram explains the algorithm described above.

7 RRC Configuration for 2-step RA Type

As far as the RRC configuration is concerned, almost all the IEs required for 4-step RA type are required for 2-step RA type too. 3GPP Release 16 has introduced new IE structures for 2-step RA type which are similar to that of 4-step RA type.

In 2-step RA type, PUSCH is transmitted without waiting for a response from the network, hence the UE needs to know PUSCH configuration beforehand. The configuration for PUSCH is given in the IE msgA-PUSCH-Config.

As shown below, a couple of new IEs have been added to BWP-UplinkCommon IE.

*BWP-UplinkCommon*
genericParameters	BWP
rach-ConfigCommon	SetupRelease { RACH-ConfigCommon }
pusch-ConfigCommon	SetupRelease { PUSCH-ConfigCommon }
pucch-ConfigCommon	SetupRelease { PUCCH-ConfigCommon }
rach-ConfigCommonTwoStepRA-r16	SetupRelease { RACH-ConfigCommonTwoStepRA-r16 }
msgA-PUSCH-Config-r16	SetupRelease { MsgA-PUSCH-Config-r16 }

rach-ConfigCommonTwoStepRA

- This IE provides configuration of cell-specific RA parameters which the UE uses for both CBRA and CFRA.

- Moreover, the network configures this IE whenever it configures CFRA with 2-step RA type (for reconfiguration with sync).

- The structure of the IE rach-ConfigCommonTwoStepRA is similar to that of RACH-ConfigCommon IE which is meant for 4-step RA type.

- An important field in this IE is msgA-RSRP-Threshold. The UE selects 2-step RA type based on this threshold.

RACH-ConfigGenericTwoStepRA

- This IE is configured as part of rach-ConfigCommonTwoStepRA and provides generic RA configuration (as shown below). This IE contains information such as PRACH configuration (MsgA), preamble power ramping step size, frequency resources for PRACH, RA response window for MsgB etc…

*RACH-ConfigGenericTwoStepRA*
msgA-PRACH-ConfigurationIndex-r16	INTEGER (0..262)
msgA-RO-FDM-r16	ENUMERATED { one, two, four, eight }
msgA-RO-FrequencyStart-r16	INTEGER (0..274)
msgA-ZeroCorrelationZoneConfig-r16	INTEGER (0..15)
msgA-PreamblePowerRampingStep-r16	ENUMERATED { 0dB, 2dB, 4dB, 6dB }
msgA-PreambleReceivedTargetPower-r16	INTEGER (-202..-60)
msgB-ResponseWindow-r16 (in slots)	ENUMERATED { 1, 2, 4, 8, 10, 20, 40, 80, 160, 320 }
preambleTransMax-r16	ENUMERATED { 3, 4, 5, 6, 7, 8, 10, 20, 50, 100, 200 }
msgA-TransMax-r16	ENUMERATED { 1, 2, 4, 6, 8, 10, 20, 50, 100, 200 }

msgA-PUSCH-Config

- This IE is used to specify the PUSCH allocation for MsgA in 2-step RA type. It provides the UE with all needed configuration for PUSCH transmission such as time/frequency domain resource, DMRS type, MCS, PUSCH Tx power related parameters etc…

- This IE needs to be configured separately for CFRA and CBRA.

- For CBRA, the IE msgA-PUSCH-Config is configured as part of BWP-UplinkCommon IE.

- For CFRA, the IE msgA-PUSCH-Config is configured as part of the IE CFRA-TwoStep (discussed later) within RACH-ConfigDedicated.

- The structure of the IE msgA-PUSCH-Config is given below;

*MsgA-PUSCH-Config-r16*
msgA-PUSCH-ResourceList-r16	SEQUENCE (size(1..2)) OF MsgA-DMRS-Config-r16-r16
msgA-TransmformPrecoder-r16	ENUMERATED { enabled, disabled }
msgA-DataScramblingIndex-r16	INTEGER (0..1023)
msgA-DeltaPreamble-r16	INTEGER (-1..6)
MsgA-PUSCH-Resource-r16
msgA-PUSCH-PreambleGroup-r16	ENUMERATED { groupA, groupB }
msgA-MCS-r16	INTEGER (0..15)
nrofSlotsMsgA-PUSCH-r16	INTEGER (1..4)
nrofMsgA-PO-PerSlot-r16	ENUMERATED { one, two, three, six }
msgA-PUSCH-TimeDomainOffset-r16	INTEGER (1..32)
msgA-PUSCH-TimeDomainAllocation-r16	INTEGER (1..64)
startSymbolAndLengthMsgA-PO-r16	INTEGER (0..127)
mappingTypeMsgA-PUSCH-r16	ENUMERATED { typeA, typeB }
guardPeriodMsgA-PUSCH-r16	INTEGER (0..3)
guardBandMsgA-PUSCH-r16	INTEGER (0..1)
frequencyStartMsgA-PUSCH-r16	INTEGER (0..274)
nrofPRBs-PerMsgA-PO-r16	INTEGER (1..32)
nrofMsgA-PO-FDM-r16	ENUMERATED { one, two, four, eight }
msgA-IntraSlotFrequencyHopping-r16	ENUMERATED { enabled }
msgA-HoppingBits-r16	BIT STRING (SIZE(2))
msgA-DMRS-Config-r16	MsgA-DMRS-Config-r16
*. . .*

CFRA-TwoStep-r16

- This IE is used to specify configuration of CFRA for 2-step RA type and is part of RACH-ConfigDedicated which is provided as part of reconfiguration with sync (e.g. Handover).

Reference: 3GPP TS 38.213 (v16.1.0), 38.321 (v16.1.0), 38.300 (v16.1.0), and 38.331 (v16.0.0)

5G NR: PDSCH Resource Allocation in Frequency-Domain

2020-04-13T21:16:00.002+02:00

1. Introduction

Time Domain Resource Allocation is thoroughly discussed in the post: ‘PDSCH Resource Allocation in Time-Domain’.

Signalling of frequency-domain resources means, informing the UE about resource blocks (RBs) and the corresponding bandwidth part (BWP) on which the intended data to be transmitted/received. Using the allocated frequency resources, the UE transmits/receives the data on PUSCH/PDSCH.

The post, Bandwidth Parts thoroughly discusses about BWP allocation and this post discusses PDSCH resource allocation in frequency domain in detail. For uplink resource allocation, refer to the post: PUSCH Resource Allocation in Frequency-Domain.

Frequency-domain resource allocation concept in NR is almost similar to that of LTE, except for the fact that NR frequency resources are allocated per BWP whereas in LTE, the resource allocation is done over entire carrier bandwidth.

The network informs the UE about the frequency resources to be used for the reception of PDSCH using DCI Formats 1_0, 1_1 or 1_2. Within these DCI Formats, the field ‘Frequency domain resource assignment’ carries the required resource allocation information.

2 PDSCH Frequency-domain Resource Allocation Types

Refer to 5.1.2.2 from 38.214 for more information.

NR supports two types of downlink resource allocation schemes; type 0 and type 1.

When resource allocation is received via fallback DCI Format 1_0, type 0 is always used.

The network informs the UE about which resource allocation scheme to be used via RRC signalling within PDSCH-Config IE;

*PDSCH-Config*
. . .
resourceAllocation	ENUMERATED {resourceAllocationType0, resourceAllocationType1, dynamicSwitch}
resourceAllocationForDCI-Format1-2-r16	ENUMERATED {resourceAllocationType0, resourceAllocationType1, dynamicSwitch}
. . .

The field resourceAllocation refers to resource allocation using DCI format 1_1 and the field resourceAllocationForDCI-Format1-2 refers to DCI format 1_2. The value of these two fields should be interpreted as below;

- resourceAllocationType0 -> resource allocation type 0 should be used.

- resourceAllocationType1 -> resource allocation type 1 should be used.

- dynamicSwitch -> resource allocation type is left flexible, meaning that either type 0 or type 1 shall be used as indicated by DCI. The MSB bit of the field ‘Frequency domain resource assignment’ within the DCI 1_1/1_2 is used to indicate resource allocation type 0 or type 1 (bit value = 0 -> type 0 and bit value = 1 -> type 1).

So far, the discussion has been about the resource allocation using DCI formats 1_1 and 1_2. When using DCI format 1_0, always type 1 is used.

Below table provides summary of DCI format vs resource allocation type.

DCI Format	Downlink Resource Allocation Type
DCI Format 1_0	Type 1
DCI Format 1_1	Type 0, Type 1
DCI Format 1_2	Type 0, Type 1

3 Downlink Resource Allocation Type 0

As discussed in section 2, the network can ask the UE to use type 0 either via RRC signalling (resourceAllocationType0) or via DCI format 1_1/1_2 (dynamicSwitch).

The downlink resource allocation type 0 is a bitmap-based resource allocation scheme. The RB assignment information includes a bitmap indicating the Resource Block Groups (RBGs) that are allocated to the scheduled UE.

An RBG is a set of consecutive Virtual Resource Blocks (VRB). In type 0, non-interleaved VRB-to-PRB mapping is performed, meaning that VRB_n is directly mapped to PRB_n.

The number of RBs within an RBG are derived based on the RRC parameter rbg-size configured by PDSCH-Config and the size of the bandwidth part.

The parameter rbg-Size controls the selection between configuration 1 and configuration 2 for RBG size for PDSCH. This filed is only applicable for downlink resource allocation type 0.

*PDSCH-Config*
. . .
*rbg-Size*	ENUMERATED {config1, config2}
. . .

The following table summarises the relationship between rbg-size configuration and bandwidth part size.

Bandwidth Part Size	RGB Size (P)
Bandwidth Part Size	Configuration 1	Configuration 2
1 – 36	2	4
37 - 72	4	8
73 - 144	8	16
145 - 275	16	16

The bitmap is of size N_RBG bits with each bit within the bitmap represents an RBG such that each RBG within the bandwidth part is addressable.

RBG bitmap is such that RBG#0 to RBG#N_RBG−1 are mapped from MSB to LSB of the bitmap.

As explained with the below equations, the bitmap is of size N_RBG and varies depending upon the size of the bandwidth part and the position of the bandwidth part within the CRB grid, and RBG size (P).

Example1 below illustrates the distribution of RBGs and RBG bitmap when position of bandwidth part within CRB grid starts at an RB value that is an integer multiple of RBG size.

Example2 below illustrates the distribution of RBGs and RBG bitmap when position of bandwidth part within CRB grid starts at an RB value that is not an integer multiple of RBG size.

Finally, let’s look at how RBG allocation is done to individual UEs. As discussed already, the field Frequency domain resource assignment (bitmap) within DCI 1_1/1_2 is used to indicate which RBGs are allocated to the UE.

An RBG is allocated to the UE if the corresponding bit value in the bitmap is 1, the RBG is not allocated to the UE if the bit value is 0.

Consider an example with two UEs and UE1’s resource allocation bitmap = 10011001 and UE2’s bitmap = 01100110, the following figure illustrates which RBs are allocated to UE1 and UE2.

4 Downlink Resource Allocation Type 1

As discussed in Section 3, type 0 relies on RBG bitmap-based allocation scheme whereas in type 1 the network provides the UE with an encoded value of starting resource block number and the length of RBs.

In type 1, the resource block assignment information indicates to a scheduled UE a set of contiguously allocated non-interleaved or interleaved VRBs.

Type 1 supports contiguous allocation of VRB only. With type 1, the number of bits required to represent a set of RBs is less than that of type 0.

As type 1 takes less bits as compared to type 0, fallback DCI format 1_0 uses type 1. For fallback DCI formats, reduced overhead is desirable as compared to scheduling flexibility as a result of non-contiguous RB allocation.

The network can allocate resources for type 1 via ‘Frequency domain resource assignment’ field within DCI formats 1_0, 1_1 and 1_2.

The procedure for deriving the allocated PRBs involves two steps;

- Using RIV method, derive a set of contiguously allocated VRBs (start VRB and length of VRBs).

- Perform VRB-to-PRB mapping: In this step, a set of VRBs (derived from step 1) are mapped onto a set of PRBs using interleaved or non-interleaved mapping procedure.

Step-1: Derive contiguously allocated VRBs:

In general, a downlink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block number (RB_start) and a length in terms of contiguously allocated VRBs (L_RBs).

The RIV value is defined by the following equation;

Let’s consider a couple of examples and derive RIV value;

Downlink Resource Allocation Type 1 when received via DCI format 1_2:

When the downlink assignment is received with DCI format 1_2, the RIV corresponds to starting RBG and length in terms of RBGs. Note RB group here instead of individual RB assignment (DCI format 1_0/1_1).

With this scheme, the total number of bits required to represent all RBs within the bandwidth part are less than that of type 1 RIV scheme used in DCI formats 1_0 and 1_1.

The size of RBG is provided by RRC parameter ResourceAllocationType1-granularity-ForDCIFormat1_2 within PDSCH-Config IE. If this field is not configured, then RBG size should be set to 1. This field configures the scheduling granularity applicable for both the starting point and length indication. The granularity can be 2, 4, 8 or 16 RBs.

*PDSCH-Config*
. . .
*resourceAllocationType1GranularityForDCI-Format1-2-r16*	ENUMERATED {n2, n4, n8, n16}
. . .

The resource allocation field consists of a resource indication value (RIV) corresponding to a starting resource block group RBG_start (0, 1, …, N_RBG-1) and length in terms of virtually contiguously allocated resource block groups L_RBGs(1, 2, …, N_RBG).

In the RIV equation, instead of starting RB and total RBs, starting RBG and total RGBs are used. The RIV value is defined by the following equation;

Let’s consider a couple of examples and derive RIV value;

Step-2: VRB-to-PRB mapping:

For more details, see section 7.3.1.6 from 38.211.

After step 1, the starting VRB number and the number of consecutive VRBs are known. Now, the goal is to derive the actual PRBs required for the reception of PDSCH. To do so, VRB-to-PRB mapping needs to be done.

VRB-to-PRB mapping can be of two types: interleaved and non-interleaved;

Fallback DCI format 1_0 includes a single bit field ‘VRB-to-PRB mapping’ whose interpretation is as given in the below table;

Bit field value	VRB-to-PRB mapping Type
0	Non-interleaved
1	Interleaved

For non-fallback DCI formats 1_1 and 1_2, RRC needs to inform the UE whether or not this bit field is present in the DCI. PDSCH-config IE carries a field called vrb-ToPRB-Interleaver for DCI format 1_1 and vrb-ToPRB-InterleaverForDCI-Format1-2 for DCI format 1_2.

*PDSCH-Config*
. . .
*vrb-ToPRB-Interleaver*	ENUMERATED {n2, n4}
*vrb-ToPRB-InterleaverForDCI-Format1-2*	ENUMERATED {n2, n4}
. . .

- When this field is absent, non-interleaved mapping is used and DCI doesn’t carry ‘VRB-to-PRB mapping’ field.

- Inclusion of this field means; DCI format 1_1/1_2 includes a single bit field ‘VRB-to-PRB mapping’ within the DCI. This bit field can still control (as show in the above table) whether or not interleaved mapping is used -> Bit value 0 indicates non-interleaved and value 1 indicates interleaved mapping.

- When interleaved mapping is indicated, this field also indicates corresponding interleaving unit called Resource Block Bundles (RBB, discussed in the next section). This field can configure RBB as 2 or 4 RBs as shown below;

Type 1: Interleaved VRB-to-PRB mapping

An interleaved VRB-to-PRB uses a concept called Resource Block Bundles (RBB), each RBB is a set of contiguous RBs.

The size of the RBB is provided by PDSCH-Config via vrb-ToPRB-Interleaver for DCI format 1_1 and vrb-ToPRB-InterleaverForDCI-Format1-2 for DCI format 1_2. This field can configure the size of RBB as either 2 RBs or 4 RBs.

When using fallback DCI format 1_0 for interleaved VRB-to-PRB mapping, the RBB size is not configured by RRC but is fixed to be 2 RBs.

Depending upon the size of the bandwidth part and the position of the bandwidth part within the CRB grid, and RBB size (L), the RBB sizes of the first and last RBB could be different to that of RBB size configured by the RRC.

Example1 below illustrates the distribution of RBBs when position of bandwidth part within CRB grid starts at an RB value that is an integer multiple of RBB size.

Example2 below illustrates the distribution of RBBs when position of bandwidth part within CRB grid starts at an RB value that is not an integer multiple of RBB size.

The general procedure of interleaved VRB-to-PRB mapping is as described below;

Let’s consider the same example 2 above and check how mapping is done;

In the above example let’s say that an UE gets an allocation of start VRB = 56 and length = 8 VRBs -> virtual RB bundles 2 and 3. As a result of VRB-to-PRB mapping, the UE gets Physical RB bundles 1 and 5 -> allocated PRBs: 52, 53, 54, 55, 68, 69, 70, and 71

Type 2: Non-interleaved VRB-to-PRB mapping

In non-interleaved VRB-to-PRB mapping, VRB_nis directly mapped on PRB_n as no interleaving procedure is involved.

In the above example let’s say that an UE gets an allocation of start VRB = 56 and length = 8 VRBs -> start PRB = 56 and length = 8 PRBs are allocated to the UE.

As it is obvious, since VRB allocation is contiguous, the resulting PRB allocation is also contiguous as there is no interleaving involved.

Reference: Version 16.1.0 of 3GPP TS 38.211, 38.212, 38.213, 38.214, and 38.331

5G NR: PUSCH Resource Allocation in Frequency-Domain

2020-04-13T21:16:00.000+02:00

1. Introduction

Time Domain Resource Allocation is thoroughly discussed in the post: ‘PUSCH Resource Allocation in Time-Domain’.

The post, Bandwidth Parts thoroughly discusses about BWP allocation and this post discusses PUSCH resource allocation in frequency domain in detail. For downlink resource allocation, refer to the post: PDSCH Resource Allocation in Frequency-Domain.

The network informs the UE about the frequency resources to be used for the transmission of PUSCH using DCI Formats 0_0, 0_1 or 0_2. Within these DCI Formats, the field ‘Frequency domain resource assignment’ carries the required resource allocation information.

2 PUSCH Frequency-domain Resource Allocation Types

Refer to 6.1.2.2 from 38.214 for more information.

NR supports three types of uplink resource allocation schemes; type 0, type 1 and type 2.

The uplink resource allocation scheme type 0 is supported for PUSCH only when transform precoding is disabled. Uplink resource allocation scheme type 1 and type 2 are supported for PUSCH for both cases when transform precoding is enabled or disabled.

The network informs the UE about which resource allocation scheme to be used via RRC signalling. PUSCH-Config IE is used for dynamic resource allocations and ConfiguredGrantConfig IE is used for configured grant (semi-persistent) resource allocations. For example, PUSCH-Config IE is shown below;

*PUSCH-Config*
. . .
resourceAllocation	ENUMERATED {resourceAllocationType0, resourceAllocationType1, dynamicSwitch}
resourceAllocationForDCI-Format0-2-r16	ENUMERATED {resourceAllocationType0, resourceAllocationType1, dynamicSwitch}
. . .

The field resourceAllocation refers to resource allocation using DCI format 0_1 and the field resourceAllocationForDCI-Format0-2 refers to DCI format 0_2. The value of these two fields should be interpreted as below;

- resourceAllocationType0 -> resource allocation type 0 should be used.

- resourceAllocationType1 -> resource allocation type 1 should be used.

- dynamicSwitch -> resource allocation type is left flexible, meaning that either type 0 or type 1 shall be used as indicated by DCI. The MSB bit of the field ‘Frequency domain resource assignment’ within the DCI 0_1/0_2 is used to indicate resource allocation type 0 or type 1 (bit value = 0 -> type 0 and bit value = 1 -> type 1).

In addition, resource allocation type 2 should be used for DCI format 0_1 if the RRC parameter useInterlacePUCCH-PUSCH is set to 'enabled'.

So far, the discussion has been about the resource allocation using DCI formats 0_1 and 0_2. When using DCI format 0_0, uplink resource allocation type 1 is used, except when the RRC parameter useInterlacePUCCH-PUSCH is set to 'enabled' in which case uplink resource allocation type 2 is used.

Below table provides summary of DCI format vs resource allocation type.

DCI Format	Uplink Resource Allocation Type
DCI Format 0_0	Type 1, Type 2
DCI Format 0_1	Type 0, Type 1, Type 2
DCI Format 0_2	Type 0, Type 1

3 Uplink Resource Allocation Type 0

As discussed in section 2, the network can ask the UE to use type 0 either via RRC signalling (resourceAllocationType0) or via DCI format 0_1/0_2 (dynamicSwitch).

Uplink resource allocation type 0 is a bitmap-based resource allocation scheme. The RB assignment information includes a bitmap indicating the Resource Block Groups (RBGs) that are allocated to the scheduled UE.

An RBG is a set of consecutive Virtual Resource Blocks (VRB). In type 0, non-interleaved VRB-to-PRB mapping is performed, meaning that VRB_n is directly mapped to PRB_n.

The number of RBs within an RBG are derived based on the RRC parameter rbg-size configured by PUSCH-Config and the size of the bandwidth part.

The parameter rbg-Size controls the selection between configuration 1 and configuration 2 for RBG size for PUSCH. If this IE is present, then configuration 2 should be used, otherwise, configuration 1 should be used. This filed is only applicable for uplink resource allocation type 0.

*PUSCH-Config*
. . .
*rbg-Size*	ENUMERATED {config2}
. . .

The following table summarizes the relationship between rbg-size configuration and bandwidth part size.

Bandwidth Part Size	RGB Size (P)
Bandwidth Part Size	Configuration 1	Configuration 2
1 – 36	2	4
37 - 72	4	8
73 - 144	8	16
145 - 275	16	16

The bitmap is of size N_RBG bits with each bit within the bitmap represents an RBG such that each RBG within the bandwidth part is addressable.

RBG bitmap is such that RBG#0 to RBG#N_RBG−1 are mapped from MSB to LSB of the bitmap.

Example1 below illustrates the distribution of RBGs and RBG bitmap when position of bandwidth part within CRB grid starts at an RB value that is an integer multiple of RBG size.

Example2 below illustrates the distribution of RBGs and RBG bitmap when position of bandwidth part within CRB grid starts at an RB value that is not an integer multiple of RBG size.

Finally, let’s look at how RBG allocation is done to individual UEs. As discussed already, the field Frequency domain resource assignment (bitmap) within DCI 0_1/0_2 is used to indicate which RBGs are allocated to the UE.

An RBG is allocated to the UE if the corresponding bit value in the bitmap is 1, the RBG is not allocated to the UE if the bit value is 0.

Consider an example with two UEs and UE1’s resource allocation bitmap = 10011001 and UE2’s bitmap = 01100110, the following figure illustrates which RBs are allocated to UE1 and UE2.

4 Uplink Resource Allocation Type 1

As discussed in Section 3, type 0 relies on RBG bitmap-based allocation scheme whereas in type 1 the network provides the UE with an encoded value of starting resource block number and length of RBs.

Type 1 supports contiguous allocation of resource blocks only. With type 1, the number of bits required to represent a set of RBs is less than that of type 0.

As type 1 takes less bits as compared to type 0, fallback DCI format 0_0 uses type 1. For fallback DCI formats, reduced overhead is desirable as compared to scheduling flexibility as a result of non-contiguous RB allocation.

The network can allocate resources for type 1 via ‘Frequency domain resource assignment’ field within DCI formats 0_0, 0_1 and 0_2.

In general, an uplink type 1 resource allocation field consists of a resource indication value (RIV) corresponding to a starting virtual resource block (RB_start) and a length in terms of contiguously allocated RBs (L_RBs).

The RIV value is defined by the following equation;

Let’s consider a couple of examples and derive RIV value;

Uplink Resource Allocation Type 1 when received via DCI format 0_2:

When the scheduling grant is received with DCI format 0_2, the RIV corresponds to starting RBG and length in terms of RBGs. Note RB group here instead of individual RB assignment (DCI format 0_0/0_1).

With this scheme, the total number of bits required to represent all RBs within the bandwidth part are less than that of type 1 RIV scheme used in DCI formats 0_0 and 0_1.

The size of RBG is provided by RRC parameter ResourceAllocationType1-granularity-ForDCIFormat0_2 within PUSCH-Config IE. If this field is not configured, then RBG size should be set to 1. This field configures the scheduling granularity applicable for both the starting point and length indication. The granularity can be 2, 4, 8 or 16 RBs.

*PUSCH-Config*
. . .
*resourceAllocationType1GranularityForDCI-Format0-2-r16*	ENUMERATED {n2, n4, n8, n16}
. . .

The resource allocation field consists of a resource indication value (RIV) corresponding to a starting resource block group RBG_start (= 0, 1, …, N_RBG-1) and length in terms of virtually contiguously allocated resource block groups L_RBGs(1, 2, …, N_RBG).

In the RIV equation, instead of starting RB and total RBs, starting RBG and total RGBs are used. The RIV value is defined by the following equation;

Let’s consider a couple of examples and derive RIV value;

5 Uplink Resource Allocation Type 2

5.1 Introduction to Interlaced Resource Blocks:

See section 4.4.4.6 from 38.211. Multiple interlaces of RBs are defined where an interlace m ∈ {0, 1, ..., M−1} consists of common RBs {m, M+m, 2M+m, 3M+m,...}, with M being the number of interlaces given by the following table;

µ	Number of RB interlaces (M)
0	10
1	5

The relation between Interlaced Resource Block (IRB) number (n_IRB) and Common Resource Block (CRB) number (n_CRB) is given by the following equation;

The following example illustrates the mapping of n_IRB and n_CRB;

5.2 Details of Uplink Resource Allocation Type 2:

The interpretation of the field ‘Frequency domain resource assignment’ within DCI format 0_1 depends upon whether or not useInterlacePUCCH-PUSCH-r16 is configured within BWP-UplinkDedicated.

If the field useInterlacePUCCH-PUSCH is configured, the UE uses uplink frequency domain resource allocation Type 2 for PUSCH.

In type 2 resource allocation, the total number of bits for Frequency domain resource assignment field depends upon subcarrier spacing of the active UL BWP.

SCS = 30 kHz:

- 5+Y bits provide the frequency domain resource allocation

- The 5 MSBs of the resource block assignment information comprise a bitmap indicating the interlaces that are allocated to the scheduled UE.

· As there are a total of 5 (=M) RB interlaces for µ = 1, 5 bits are good enough to indicate allocated interlaces.

· The order of interlace bitmap is such that interlace 0 to interlace 4 are mapped from MSB to LSB of the bitmap.

· An interlace is allocated to the UE if the corresponding bit value in the bitmap is 1; otherwise the interlace is not allocated to the UE

- Y LSBs provide the RB set allocation

SCS = 15 kHz:

- 6+Y bits provide the frequency domain resource allocation

- The 6 MSBs provide the interlace allocation. As there are a total of 10 (=M) RB interlaces for µ = 0, the set of allocated interlaces are indicated using RIV => RIV indicates the starting interlace index and the number of contiguous interlace indices.

- Y LSBs provide the RB set allocation

For both 15 kHz and 30 kHz SCS, the value of Y is determined by Ceil (log₂(N(N+1)/2)), where N the number of RB sets contained in the BWP.

These Y bits indicate to the UE a set of contiguously allocated RB sets for PUSCH i.e., the resource allocation field (Y-LSB bits) consists of a resource index value (RIV). The RIV indicates starting RB set and a number of contiguous RB sets as usual.

Reference: Version 16.1.0 of 3GPP TS 38.211, 38.212, 38.213, 38.214, and 38.331

5G NR: Measurement Configuration

2020-02-10T22:57:00.000+01:00

1 Introduction

The network may configure an RRC_CONNECTED state UE to perform measurements and report them in accordance with the measurement configuration. The measurement configuration is provided by means of dedicated signalling i.e. using the RRCReconfiguration or RRCResume message.

For EN-DC, LTE RRCConnectionReconfiguration carries the required information to help the UE measure NR cell while being served by an LTE cell.

Measurement concept is thoroughly discussed in 38.331 section 5.5. Measurement configuration baseline in NR is similar to that of LTE.

Measurements to be performed by an UE in RRC_CONNECTED are classified in at least three measurement types:

– Intra-frequency NR measurements.

– Inter-frequency NR measurements.

– Inter-RAT measurements of E-UTRA frequencies. As of release-15, 3GPP has not specified inter-RAT measurements for 3G and 2G.

The parameters of the measurement configuration are summarized below:

1. Measurement objects: For each measurement type discussed above, one or several measurement objects can be defined. See section 3.

– In NR, each measurement object indicates frequency/time location as well as subcarrier spacing of the reference signals to be measured.

– For inter-RAT E-UTRA measurements a measurement object is a single E-UTRA carrier frequency.

2. Reporting configurations: A reporting configuration defines the reporting criteria. The reporting criteria are classified as event triggered reporting, periodic reporting, CGI reporting or SFTD reporting. See section 4.

3. Measurement identities: A list of measurement identities where each measurement identity links one measurement object with one reporting configuration. By configuring multiple measurement identities, it is possible to link more than one measurement object to the same reporting configuration, as well as to link more than one reporting configuration to the same measurement object. See section 5.

4. Quantity configurations: The quantity configuration defines the measurement filtering configuration used for measurement event evaluation and related reporting, and for periodical reporting of that measurement. See section 6.

5. Measurement gaps: Periods that the UE may use to perform measurements. Measurement gaps are discussed in the post 5G NR: Measurement GAPs.

A UE in RRC_CONNECTED state;

– Maintains a measurement object list, a reporting configuration list, and a measurement identities list.

– The measurement object list possibly includes NR and inter-RAT measurement object(s).

– Similarly, the reporting configuration list includes NR and inter-RAT reporting configurations.

– Any measurement object can be linked to any reporting configuration of the same RAT type.

– Some reporting configurations may not be linked to a measurement object. Likewise, some measurement objects may not be linked to a reporting configuration.

2 RRC Measurement Configuration

The IE MeasConfig specifies measurements to be performed by the UE, and covers intra-frequency, inter-frequency and inter-RAT mobility as well as configuration of measurement gaps. This IE is part of RRCReconfiguration or RRCResume message. MeasConfig IE contents are shown below and are discussed individually in subsequent sections.

*MeasConfig*
measObjectToRemoveList	SEQUENCE (SIZE (1..64)) OF MeasObjectId
measObjectToAddModList	SEQUENCE (SIZE (1..64)) OF MeasObjectToAddMod
reportConfigToRemoveList	SEQUENCE (SIZE (1..64)) OF ReportConfigId
reportConfigToAddModList	SEQUENCE (SIZE (1..64)) OF ReportConfigToAddMod
measIdToRemoveList	SEQUENCE (SIZE (1..64)) OF MeasId
measIdToAddModList	SEQUENCE (SIZE (1..64)) OF MeasIdToAddMod
s-MeasureConfig
ssb-RSRP	INTEGER (0..127)
csi-RSRP	INTEGER (0..127)
quantityConfig	QuantityConfig
measGapConfig	MeasGapConfig
measGapSharingConfig	MeasGapSharingConfig

After receiving the measurement configuration, the UE shall act in (exactly) the following order. It all depends upon what is included in the measConfig IE:

– In the first step, the UE checks to see if any measurement objects are to be removed. Now, the measObject addition/modification procedure is performed.

– In the next step, the UE first checks to see if any report configurations to be removed. Then, proceed to measurement configuration addition/modification procedure.

– The UE now performs quantity configuration procedure as per quantityConfig.

– Now, the UE first checks to see if any measurement IDs to be removed before proceeding to measurement ID addition/modification.

– Finally, measurement gap and s-measure configuration procedures are performed.

3 Measurement objects

For each measurement type (intra-, inter-frequency, or inter-RAT), one or several measurement objects can be defined.

In NR, measurement objects (MeasObjectNR) are defined for both intra- and inter-frequency. Each measurement object indicates frequency/time location as well as subcarrier spacing of the reference signals to be measured.

– The field ReferenceSignalConfig within each measObjectNR can configure the measurements for SSB, CSI-RS or both. The field rsType within reportConfigNR specifies which measurement resource type to use.

For inter-RAT E-UTRA measurements a measurement object (MeasObjecEUTRA) is a single E-UTRA carrier frequency.

Associated with each measurement object, the network may configure the following;

– A list of cell specific offsets, 'blacklisted' cells and 'whitelisted' cells.

– Blacklisted cells are not applicable in event evaluation or MR.

– Whitelisted cells are the only ones applicable in event evaluation or MR.

The IE MeasObjectToAddMod consists of an ID and an associated measObject configuration. The measObject can be either for NR or for E-UTRA.

3.1 Measurement object for NR

The IE MeasObjectNR provides information applicable for SSB based and/or CSI-RS based intra/inter-frequency measurements.

The following table presents the configuration provided by MeasObjectNR.

*MeasObjectNR*
ssbFrequency	ARFCN-ValueNR - INTEGER (0..3279165)
ssbSubcarrierSpacing	ENUMERATED {kHz15, kHz30, kHz60, kHz120, kHz240}
smtc1	SSB-MTC
smtc2	SSB-MTC2
refFreqCSI-RS	ARFCN-ValueNR - INTEGER (0..3279165)
referenceSignalConfig	Reference signal configuration for SSB and CSI-RS
absThreshSS-BlocksConsolidation	ThresholdNR - INTEGER (0..127)
absThreshCSI-RS-Consolidation	ThresholdNR - INTEGER (0..127)
nrofSS-BlocksToAverage	INTEGER (2..16)
nrofCSI-RS-ResourcesToAverage	INTEGER (2..16)
quantityConfigIndex	INTEGER (1..2)
offsetMO	SSB and CSI-RS offset values (RSRP, RSRQ and SNR)
cellsToRemoveList	A list of PCIs (PCI-List)
cellsToAddModList	List of cells to add/modify -> PCI and Cell-individual offsets
blackCellsToRemoveList	A list of PCI ranges (PCI-RangeIndexList)
blackCellsToAddModList	List of cells to add/modify in the black list of cells
whiteCellsToRemoveList	A list of PCI ranges (PCI-RangeIndexList)
whiteCellsToAddModList	List of cells to add/modify in the white list of cells
freqBandIndicatorNR	INTEGER (1..1024)
measCycleSCell	ENUMERATED {sf160, sf256, sf320, sf512, sf640, sf1024, sf1280}

Some of the important fields within MeasObjectNR are discussed below.

– ssbFrequency Indicates the frequency of the SS associated to this MeasObjectNR. This basically is an ARFCN value of a downlink NR global frequency raster.

– ssbSubcarrierSpacing Subcarrier spacing of the SSB. Only the values 15 kHz or 30 kHz (FR1), and 120 kHz or 240 kHz (FR2) are applicable.

– smtc1 and smtc2 provides primary and secondary measurement timing configurations respectively. periodicity in smtc2 can only be shorter than the periodicity indicated by periodicityAndOffset in smtc1.

– refFreqCSI-RS ‘Point A’ which is used for mapping of CSI-RS to physical resources.

– referenceSignalConfig RS configuration for SSB and CSI-RS.

– absThreshCSI-RS-Consolidation and absThreshSS-BlocksConsolidation Absolute threshold for the consolidation of measurement results per CSI-RS resource(s) and per SSB(s) respectively from L1 filter(s). These fields are used for the derivation of cell measurement results as well as for the reporting of beam measurement information per CSI-RS resource and per SSB index respectively.

– nrofSS-BlocksToAverage and nrofCSI-RS-ResourcesToAverage respectively indicates the maximum number of measurement results per beam based on SSB and CSI-RS resources to be averaged.

– quantityConfigIndex indicates the index of quantityConfigNR-List provided in MeasConfig. As of release 15, maximum number of quantityConfig is set 2, which means that this field indicates one out of two config indexes from the list.

– freqBandIndicatorNR indicates the frequency band in which the SSB and/or CSI-RS indicated in this MeasObjectNR are located.

– measCycleSCell indicates the SCell measurement periodicity when the corresponding SCell is in deactivated state.

3.2 Measurement object for E-UTRA

The IE MeasObjectEUTRA specifies information applicable for E-UTRA cells. The following table presents the configuration provided by MeasObjectEUTRA. This is typical measurement object configuration of LTE.

*MeasObjectEUTRA*
carrierFreq	EARFCN - INTEGER (0..262143)
allowedMeasBandwidth	ENUMERATED {mbw6, mbw15, mbw25, mbw50, mbw75, mbw100}
cellsToRemoveListEUTRAN	SEQUENCE (SIZE (1..32)) OF EUTRA-CellIndex
cellsToAddModListEUTRAN	SEQUENCE (SIZE (1..32)) OF EUTRA-Cell
blackCellsToRemoveListEUTRAN	SEQUENCE (SIZE (1..32)) OF EUTRA-CellIndex
blackCellsToAddModListEUTRAN	SEQUENCE (SIZE (1..32)) OF EUTRA-BlackCell
eutra-PresenceAntennaPort1	When set to true, at least two cell-specific antenna ports are used in all neighbouring cells
eutra-Q-OffsetRange	EUTRA-Q-OffsetRange
widebandRSRQ-Meas	If set to true, the UE shall use wider BW for RSRQ measurements

4 Reporting configurations

For each measurement object (discussed in section 3), one or several reporting configurations can be defined. There can be one or multiple reporting configurations per measurement object. Each reporting configuration consists of the following:

– Reporting criterion: The criterion that triggers the UE to send an MR. This can either be periodical or a single event triggered.

– RS type: The RS that the UE uses for beam and cell measurement results (SSB or CSI-RS).

– Reporting format: The quantities per cell and per beam that the UE includes in the MR (e.g. RSRP) and other associated information such as the maximum number of cells and the maximum number beams per cell to report.

There are two types of reporting configurations; One for NR measurements and the other is for inter-RAT measurements. These are discussed in subsequent sections.

The IE ReportConfigToAddModList concerns a list of reporting configurations to add or modify. Each item (ReportConfigToAddMod) in the list is a reporting configuration to be added or modified.

ReportConfigToAddMod consists of an ID and an associated reportConfig. The reportConfig can be either for NR or for inter-RAT.

4.1 Reporting Configuration - NR

The IE ReportConfigNR specifies criteria for triggering of an NR measurement reporting event. The following table presents the configuration provided by ReportConfigNR.

*ReportConfigNR*
reportType
periodical	PeriodicalReportConfig
eventTriggered	EventTriggerConfig
reportCGI	ReportCGI
reportSFTD	ReportSFTD-NR

The reporting type can be of event triggered reporting, periodic reporting, CGI reporting or SFTD reporting.

4.1.1 Event Triggered Measurement Reporting - NR

Measurement reporting (MR) events are based on cell measurement results, which can either be derived based on SSB or CSI-RS. NR Measurement reporting events are summarized in the below table.

Event	Description
Event A1	Serving becomes better than absolute threshold
Event A2	Serving becomes worse than absolute threshold
Event A3	Neighbour becomes amount of offset better than PCell/PSCell
Event A4	Neighbour becomes better than absolute threshold
Event A5	PCell/PSCell becomes worse than absolute threshold1 AND Neighbour/SCell becomes better than another absolute threshold2
Event A6	Neighbour becomes amount of offset better than SCell

The event triggered reporting configuration could specify the following;

– Measurement reporting event (A1, A2, … A6).

– MR triggering quantity (RSRP, RSRQ or SINR) and the corresponding threshold or offset values, hysteresis, time to trigger etc…

– Reference signal type to be used for MR triggering (SSB or CSI-RS)

– Cell level measurement quantities (RSRP and/or RSRQ and/or SINR) to be included in the MR and the maximum number of cells to be reported in the MR.

– Once MR is triggered, the number of reports to be sent and interval between two reports.

– Flag indicating whether or not beam level measurements to be included in the MR.

The RRC configuration for event triggered reporting is shown below;

*EventTriggerConfig*
eventId
eventAN	This structure is applicable for A1, A2, A3, A4, A5 and A6
Threshold	RSRP, RSRQ or SINR threshold (only for A1, A2, A4, and A5)
Threshold2	RSRP, RSRQ or SINR threshold (only for A5)
Offset	RSRP, RSRQ or SINR offset (only for A3 and A6)
reportOnLeave	BOOLEAN (only for A3, A4, A5, and A6)
hysteresis	INTEGER (0..30)
timeToTrigger	0, 40, 64, 80, … 5120 msec
useWhiteCellList	BOOLEAN
rsType	ENUMERATED {ssb, csi-rs}
reportInterval	120msec, 240msec, … 12min, 30min
reportAmount	ENUMERATED {r1, r2, r4, r8, r16, r32, r64, infinity}
reportQuantityCell	Combination of RSRP, RSRQ or SINR quantities
maxReportCells	INTEGER (1..8)
reportQuantityRS-Indexes	Combination of RSRP, RSRQ or SINR quantities
maxNrofRS-IndexesToReport	INTEGER (1..32)
includeBeamMeasurements	BOOLEAN
reportAddNeighMeas	ENUMERATED {setup}

– eventId Indicates one of the events A1, A2, … A6 and event specific configuration;

– Threshold (1 or 2) Threshold1 is applicable for absolute threshold-based measurements events (A1, A2, A4, and A5) and Threshold2 is applicable for event A5 only. These threshold values are associated to the selected trigger quantity (e.g. RSRP, RSRQ, or SINR) per RS Type (SSB or CSI-RS) to be used in NR measurement report triggering condition.

· For RSRP, the actual value is (IE value – 156) dBm, except for the IE value 127, in which case the actual value is infinity.

· For RSRQ, the actual value is (IE value – 87)/2 dB.

· For SINR, the actual value is (IE value – 46)/2 dB.

– Offset Offset value(s) to be used in NR measurement report triggering condition for event A3 or A6. The actual value is field value * 0.5 dB

– reportOnLeave indicates whether or not the UE shall initiate the MR procedure when the leaving condition is met for a cell in cellsTriggeredList.

– hysteresis is used within the entry and leave condition of an event triggered reporting condition. The actual value is field value * 0.5 dB.

– timeToTrigger Time during which specific criteria for the event needs to be met in order to trigger an MR.

– useWhiteCellList Indicates whether only the cells included in the white-list of the associated measObject are applicable.

– rsType Type of the configured MR and it can either be SSB or CSI-RS.

– reportInterval Indicates the interval between periodical reports. When reportAmount exceeds 1, it indicates periodical event triggered reporting.

– reportQuantityCell The cell measurement quantities to be included in the MR. Either one or all of the quantities (RSRP, RSRQ, SINR) can be configured to be included.

– reportQuantityRS-Indexes Indicates which measurement information per RS index the UE shall include in the MR.

– maxNrofRS-IndexesToReport max number of RS indexes to include in the MR.

– includeBeamMeasurements When set to true, the UE shall include SSB/CSI-RS based measurement results for the quantities in reportQuantityRS-Indexes set to true for each SSB/CSI-RS index.

– reportAddNeighMeas Indicates that the UE shall include the best neighbour cells per serving frequency.

4.1.2 Periodical Measurement Reporting - NR

The contents of periodical reporting configuration are almost similar to that of event triggered (section 4.1.1) reporting configuration except that there is no event specific configuration.

The RRC configuration for periodical reporting is shown below;

*PeriodicalReportConfig*
rsType	ENUMERATED {ssb, csi-rs}
reportInterval	120msec, 240msec, … 12min, 30min
reportAmount	ENUMERATED {r1, r2, r4, r8, r16, r32, r64, infinity}
reportQuantityCell	RSRP, RSRQ or SINR
maxReportCells	INTEGER (1..8)
reportQuantityRS-Indexes	RSRP, RSRQ or SINR
maxNrofRS-IndexesToReport	INTEGER (1..32)
includeBeamMeasurements	BOOLEAN
useWhiteCellList	BOOLEAN

– rsType Type of the configured MR and it can either be SSB or CSI-RS.

– reportInterval Indicates the interval between periodical reports.

– reportQuantityCell The cell measurement quantities to be included in the MR. Either one or all of the quantities (RSRP, RSRQ, SINR) can be configured to be included.

– reportQuantityRS-Indexes Indicates which measurement information per RS index the UE shall include in the MR.

– maxNrofRS-IndexesToReport max number of RS indexes to include in the MR.

– includeBeamMeasurements When set to true, the UE shall include SSB/CSI-RS based measurement results for the quantities in reportQuantityRS-Indexes set to true for each SSB/CSI-RS index.

– useWhiteCellList Indicates whether only the cells included in the white-list of the associated measObject are applicable.

4.1.3 CGI Reporting - NR

For the purpose of ANR (Automatic Neighbour Relations), the network may configure the UE to decode and report Cell Global Identity (CGI) for a set of cells.

As shown below, the field cellForWhichToReportCGI informs the UE about the Physical Cell Identity (PCI) for which CGI to be reported.

*ReportCGI*
cellForWhichToReportCGI	INTEGER (0..1007)

4.1.4 SFTD Reporting - NR

In some cases, the serving cell may not be aware of the target cells’ SSB timing information and the serving and target cells may not be time synchronized. In such cases, SFN and Frame Timing Difference (SFTD) measurements from the UE would help the network to derive the time difference of SFN and frame boundary between serving and target cell. SFTD measurements are particularly useful for EN-DC and NE-DC scenarios.

The IE ReportSFTD-NR carries configuration for SFTD reporting for NR and E-UTRA part is carried by ReportSFTD-EUTRA (section 4.2.4).

*ReportSFTD-NR*
reportSFTD-Meas	BOOLEAN
reportRSRP	BOOLEAN
reportSFTD-NeighMeas	ENUMERATED {true}
drx-SFTD-NeighMeas	ENUMERATED {true}
cellsForWhichToReportSFTD	SEQUENCE (SIZE (1..3)) OF PhysCellId

– reportSFTD-Meas Indicates whether UE is required to perform SFTD measurement between PCell and NR PSCell in NR-DC.

– reportRSRP Indicates whether UE is required to include RSRP result of NR PSCell in SFTD measurement result, derived based on SSB.

– reportSFTD-NeighMeas Indicates whether UE is required to perform SFTD measurement between PCell and NR neighbour cells in NR standalone.

– drx-SFTD-NeighMeas Indicates that the UE shall use available idle periods (i.e. DRX off periods) for the SFTD measurement in NR standalone.

– cellsForWhichToReportSFTD Indicates the target NR neighbour cells for SFTD measurement between PCell and NR neighbour cells.

4.2 Reporting Configuration – Inter-RAT

The IE ReportConfigInterRAT specifies criteria for triggering of an inter-RAT measurement reporting event.

The following table presents the configuration provided by ReportConfigInterRAT.

*ReportConfigInterRAT*
reportType
periodical	PeriodicalReportConfigInterRAT
eventTriggered	EventTriggerConfigInterRAT
reportCGI	ReportCGI-EUTRA
reportSFTD	ReportSFTD-EUTRA

Similar to NR reporting configuration, the reporting type can be of event triggered reporting, periodic reporting, CGI reporting or SFTD reporting. Each of these types are discussed in the subsequent sections. Note that as of release-15, E-UTRA is the only inter-RAT for NR.

4.2.1 Event Triggered Measurement Reporting – Inter-RAT

The inter-RAT measurement reporting events for E-UTRA are B1 and B2 as shown in the below table.

Event	Description
Event B1	Neighbour becomes better than absolute threshold
Event B2	PCell becomes worse than absolute threshold1 AND Neighbour becomes better than another absolute threshold2

The event triggered reporting configuration could specify the following;

– Measurement reporting event (B1 or B2).

– MR triggering quantity for E-UTRA (RSRP, RSRQ or SINR) and the corresponding threshold, hysteresis, time to trigger etc…An additional NR threshold is defined for the purpose of B2 measurement report event triggering.

– Reference signal type to be used for MR triggering (SSB or CSI-RS)

– Measurement quantities (RSRP and/or RSRQ and/or SINR) to be included in the MR.

– Once MR is triggered, the number of reports to be sent and interval between two reports.

The RRC configuration for event triggered reporting is shown below;

*EventTriggerConfigInterRAT*
eventId
eventBN	Events B1 or B2
b2-Threshold1	RSRP, RSRQ or SINR thresholds, only for B2
bn-ThresholdEUTRA	E-UTRA RSRP, RSRQ or SINR threshold (for B1 or B2)
reportOnLeave	BOOLEAN
hysteresis	INTEGER (0..30)
timeToTrigger	0, 40, 64, 80, … 5120 msec
rsType	ENUMERATED {ssb, csi-rs}
reportInterval	120msec, 240msec, … 12min, 30min
reportAmount	ENUMERATED {r1, r2, r4, r8, r16, r32, r64, infinity}
reportQuantity	Combination of RSRP, RSRQ or SINR quantities
maxReportCells	INTEGER (1..8)

4.2.2 Periodical Measurement Reporting – InterRAT

The contents of periodical reporting configuration for inter-RAT are similar to that of NR configuration (see section 4.1.2).

The RRC configuration for periodical reporting is shown below;

*PeriodicalReportConfigInterRAT*
reportInterval	120msec, 240msec, … 12min, 30min
reportAmount	ENUMERATED {r1, r2, r4, r8, r16, r32, r64, infinity}
reportQuantity	RSRP, RSRQ or SINR
maxReportCells	INTEGER (1..8)

4.2.3 CGI Reporting – E-UTRA

For the purpose of ANR (Automatic Neighbour Relations), the network may configure the UE to decode and report Cell Global Identity (CGI) for a set of LTE cells.

As shown below, the field cellForWhichToReportCGI informs the UE about the Physical Cell Identity (PCI) for which CGI to be reported.

*ReportCGI-EUTRA*
cellForWhichToReportCGI	INTEGER (0..503)

4.2.4 SFTD Reporting – E-UTRA

The purpose of SFTD measurements are discussed in section 4.1.4. ReportSFTD-EUTRA carries SFTD reporting configuration for E-UTRA. The following table shows the contents of ReportSFTD-EUTRA.

*ReportSFTD-EUTRA*
reportSFTD-Meas	BOOLEAN
reportRSRP	BOOLEAN

5 Measurement identities

Measurement objects and reporting criteria are discussed in sections 3 and 4 respectively. The association between a measurement object and a reporting configuration is created by a measurement identity.

A measurement identity links together one measurement object and one reporting configuration of the same RAT.

By using several measurement identities (one for each measurement object, reporting configuration pair) it is then possible to:

– Associate several reporting configurations to one measurement object.

– Associate one reporting configuration to several measurement objects.

Below example illustrates how measurement object, reporting configuration and measurement identity linked;

The measurements identity is also used when reporting results of the measurements (within measurement reports).

As shown below, the IE MeasIdToAddModList concerns a list of measurement identities to add or modify. For each entry, measId, the associated measObjectId and the associated reportConfigId are configured.

*MeasIdToAddMod*
measId	INTEGER (1..64)
measObjectId	INTEGER (1..64)
reportConfigId	INTEGER (1..64)

6 Quantity configurations

Measurement quantities are considered separately for each RAT. As shown below, the IE QuantityConfig specifies the measurement quantities and layer 3 filtering coefficients for NR and inter-RAT measurements.

*QuantityConfig*
quantityConfigNR-List	List from 1 up to 2 QuantityConfigNR
quantityConfigEUTRA	FilterConfig
QuantityConfigNR
quantityConfigCell	ssb-FilterConfig and csi-RS-FilterConfig
quantityConfigRS-Index

– quantityConfigCell: Specifies L3 filter configurations for cell measurement results for the configurable RS Types (e.g. SSB and CSI-RS) and the configurable measurement quantities (e.g. RSRP, RSRQ and SINR).

– quantityConfigRS-Index: Specifies L3 filter configurations for measurement results per RS index for the configurable RS Types (e.g. SSB and CSI-RS) and the configurable measurement quantities (e.g. RSRP, RSRQ and SINR).

7 Measurement Configuration for NR from E-UTRA (EN-DC)

For EN-DC, the master RAT (LTE) might add secondary cell (group) either blindly or based on measurements. Measurement-based NR cell addition make sure that the UE can detect, and measure NR cell and success rate of NR cell addition procedure is much better as compare to blind addition.

E-UTRA configures the inter-RAT measurements for NR as per the procedures defined in 36.331.

7.1 EN-DC: Measurement Object Configuration for NR

The IE MeasObjectNR-r15 carries almost same configuration as that of NR measurement object configuration discussed in section 3.1. This is because, for the UE, the target cell is NR cell irrespective of EN-DC or standalone NR.

7.2 EN-DC: Reporting Configuration for NR

For event-based measurement configuration, same inter-RAT events B1 and B2 are used.

Event	Description
Event B1	Neighbour becomes better than absolute threshold
Event B2	PCell becomes worse than absolute threshold1 AND Neighbour becomes better than another absolute threshold2

Two new IEs are added to legacy ReportConfigInterRAT IE structure to provide configuration for NR events B1 and B2.

The IE structure for ReportConfigInterRAT with IEs and fields related to NR are presented below.

*ReportConfigInterRAT*
triggerType	Event or Periodical
event
eventBN	Events B1 or B2
b2-Threshold1	E-UTRA RSRP, RSRQ or SINR thresholds, only for B2
bn-ThresholdNR	NR RSRP, RSRQ or SINR threshold (for B1 or B2)
reportOnLeave	BOOLEAN
hysteresis	INTEGER (0..30)
timeToTrigger	0, 40, 64, 80, … 5120 msec
periodical
purpose	ENUMERATED {reportStrongestCells, reportStrongestCellsForSON, reportCGI}
reportQuantityCellNR	Combination of RSRP, RSRQ or SINR quantities
maxReportRS-Index	INTEGER (0..32)
reportQuantityRS-IndexNR	Combination of RSRP, RSRQ or SINR quantities
reportRS-IndexResultsNR	BOOLEAN
reportSFTD-Meas	ENUMERATED {pSCell, neighborCells}

8 Measurement GAP configuration

Measurement Gaps are thoroughly discussed in the post 5G NR: Measurement GAPs.

Reference: 15.8 version of 3GPP TS 38.331, 36.331, 38.300

5G NR: Measurement GAPs

2020-01-23T21:38:00.000+01:00

1 Introduction

The UE needs measurement gaps to perform measurements when it cannot measure the target carrier frequency while simultaneously transmitting/receiving on the serving cell.

In the case of LTE, the UE needs measurement gaps in order to perform inter-frequency and inter-RAT measurements. Typical LTE gap length is 6 ms which accommodates 5 ms measurement time (PSS and SSS are transmitted once every 5 ms) and RF re-tuning time of 0.5 ms before and after the measurement gap. The measurement gap repeats with a periodicity of either 40 ms or 80 ms.

Similarly, in NR, the measurements that the UE performs can be gap-assisted (network configures measurement gap) or non-gap-assisted.

1.1 Measurements in NR

The need for measurement gap in NR depends on the capability of the UE, the active BWP of the UE and the current operating frequency.

In NR, measurements gaps might be required for intra-frequency, inter-frequency and inter-RAT measurements.

Unlike LTE intra-frequency case, intra-frequency measurements in NR might require a measurement gap in cases for example, if the intra-frequency measurements are to be done outside of the active BWP.

Measurement gap lengths of 1.5, 3, 3.5, 4, 5.5, and 6 ms with measurement gap repetition periodicities of 20, 40, 80, and 160 ms are defined in NR.

In NR, the RF re-tuning time is 0.5 ms for carrier frequency measurements in FR1 range and 0.25 ms for FR2 range. For example, a gap length of 4 ms for FR1 measurements would allow 3 ms for actual measurements and a gap length of 3.5 ms for FR2 measurements would allow 3 ms for actual measurements.

During the measurement gaps, the measurements are to be performed on SSBs of the neighbour cells. The network provides the timing of neighbour cell SSBs using SS/PBCH Block Measurement Timing Configuration (SMTC).

– The measurement gap and SMTC duration are configured such that the UE can identify and measure the SSBs within the SMTC window i.e., the SMTC duration should be sufficient enough to accommodate all SSBs that are being transmitted.

For SSB based intra-frequency measurements, the network always configures measurement gap in the following case:

- If any of the UE configured BWPs do not contain the frequency domain resources of the SSB associated to the initial DL BWP.

For SSB based inter-frequency measurements, the network always configures measurement gap in the following cases:

- If the UE supports per-FR measurement gaps (section 2.1) and if the carrier frequency to be measured is in same frequency range (FR) as any of the serving cells.

- If the UE only supports per-UE measurement gaps. In this case, the measurement object can be configured on any frequency range (FR1 or FR2) but the gap will anyway be configured by the network.

Inter-RAT measurements in NR are limited to E-UTRA. For a UE configured with E-UTRA Inter-RAT measurements, a measurement gap configuration is always provided when:

- The UE only supports per-UE measurement gaps; or

- The UE supports per-FR measurement gaps and at least one of the NR serving cells is in FR1.

1.2 Measurements in MR-DC configurations

For MR-DC configurations, a measurement gap configuration is always provided to the UE in the following cases;

- In EN-DC, NGEN-DC and NE-DC, for UEs configured with E-UTRA inter-frequency measurements.

- In EN-DC and NGEN-DC, for UEs configured with UTRAN and GERAN measurements.

- In NR-DC, for UEs configured with E-UTRAN measurements.

Additionally, in EN-DC, 3GPP release 15 didn’t specify a way (in UE Capability Information) for the UE to inform the E-UTRAN about the measurement gap requirements for individual EN-DC band combinations. So, the E-UTRAN always configures measurement gap for NR measurements.

2 Measurement Gap Configuration

Depending on the UE capability to support independent FR (frequency range) measurement and network preference, there are two types of measurement gaps defined in NR; per-UE and per-FR.

In per-FR gap, two independent gap patterns (i.e. FR1 gap and FR2 gap) are defined for FR1 and FR2 respectively.

Per-UE gap applies to both FR1 (E-UTRA and NR) and FR2 (NR) frequencies.

In the case of MR-DC:

- For per-UE and per-FR1 gap patterns, the MN decides the gap pattern. The MN is also responsible for providing the gap pattern to the UE via MN RRC. This is applicable for EN-DC, NGEN-DC, NE-DC and NR-DC.

- For per-FR2 gap, in EN-DC and NGEN-DC, the SN (NR) decides the FR2 gap pattern. In NE-DC and NR-DC, the MN (NR) decides FR2 gap pattern and the related gap sharing configurations. The node (MN/SN) which decides the gap pattern is also responsible for providing the configuration to the UE.

Node responsible for decision making and providing measurement gap configuration to the UE
MR-DC	Per-UE gap	Per-FR1 gap	Per-FR2 gap
EN-DC NGEN-DC	E-UTRAN (MN)	E-UTRAN (MN)	NR (SN)
NE-DC	NR (MN)	NR (MN)	NR (MN)
NR-DC	NR (MN)	NR (MN)	NR (MN)

2.1 Configuration provided by NR RRC

As discussed already, in the following cases, NR RRC is responsible for providing measurement gap pattern configuration to the UE. This is done using MeasGapConfig IE within the MeasConfig IE and is carried by RRC Reconfiguration message. NR RRC is responsible for the following:

- Configure the UE with either gapUE or gapFR1 in NR standalone operation (with single carrier, NR CA and NR-DC) or in NE-DC configuration.

- Configure the UE with gapFR2 in any configuration i.e., NR standalone operation (with single carrier, NR CA and NR-DC) or EN-DC or NE-DC.

MeasGapConfig IE specifies the measurement gap configuration and controls setup/release of measurement gaps. The details of this IE are given below;

*MeasGapConfig*
gapFR2	SetupRelease { GapConfig }
gapFR1	SetupRelease { GapConfig }
gapUE	SetupRelease { GapConfig }
*GapConfig*
gapOffset	INTEGER (0..159)
mgl	ENUMERATED { 1.5 msec, 3 msec, 3.5 msec, 4 msec, 5.5 msec, 6 msec }
mgrp	ENUMERATED { 20 msec, 40 msec, 80 msec, 160 msec }
mgta	ENUMERATED { 0 msec, 0.25 msec, 0.5 msec }
refServCellIndicator	ENUMERATED { pCell, pSCell, mcg-FR2 }

2.1.1 gapFR1

This field indicates measurement gap configuration that applies to FR1 frequency range only (both E-UTRAN and NR serving cells). gapFR1 cannot be configured together with gapUE.

In MR-DC, gapFR1 can only be setup by measConfig associated with MCG (see below):

- In (NG) EN-DC, gapFR1 cannot be set up by NR RRC i.e. only LTE RRC can configure FR1 measurement gap using LTE RRC Connection Reconfiguration (discussed in section 2.2).

- In NE-DC, gapFR1 can only be set up by NR RRC using NR RRC Reconfiguration (i.e. LTE RRC cannot configure FR1 gap).

- In NR-DC, gapFR1 can only be set up in the measConfig associated with MCG.

2.1.2 gapFR2

This field indicates measurement gap configuration that applies to FR2 only. gapFR2 cannot be configured together with gapUE.

MR-DC:

- In (NG) EN-DC or NE-DC, gapFR2 can only be set up by NR RRC using NR RRC Reconfiguration (i.e. LTE RRC cannot configure FR2 gap).

- In NR-DC, gapFR2 can only be set up in the measConfig associated with MCG.

2.1.3 gapUE

This field indicates measurement gap configuration that applies to all frequency ranges (FR1 and FR2) which are applicable for E-UTRAN and NR serving cells. If gapUE is configured, then neither gapFR1 nor gapFR2 can be configured.

In MR-DC, gapUE can only be setup by measConfig associated with MCG (see below):

- In (NG) EN-DC, gapUE cannot be set up by NR RRC i.e. only LTE RRC can configure FR1 measurement gap using LTE RRC Connection Reconfiguration (discussed in section 2.2).

- In NE-DC, gapUE can only be set up by NR RRC using NR RRC Reconfiguration (i.e. LTE RRC cannot configure per UE gap).

- In NR-DC, gapUE can only be set up in the measConfig associated with MCG.

2.1.4 Other fields within MeasGapConfig provided by NR RRC

mgrp (Measurement Gap Repetition Period) is the periodicity (in ms) at which measurement gap repeats. Periodicities of 20, 40, 80, and 160 ms are defined in NR.

gapOffset is the gap offset of the gap pattern. Not all 160 offset values applicable for all periodicities. As the offset values points to the starting subframe within the period, its value range is from 0 to mgrp-1. For example, if the periodicity is 40 ms, the offset ranges from 0 to 39.

mgl (Measurement Gap Length) is the length of measurement gap in ms. Measurement gap lengths of 1.5, 3, 3.5, 4, 5.5, and 6 ms are defined in NR.

mgta (Measurement Gap Timing Advance) – If this is configured, the UE starts the measurement mgta ms before the gap subframe occurrence i.e., the measurement gap starts at time mgta ms advanced to the end of the latest subframe occurring immediately before the measurement gap. The amount of timing advance can be 0.25 ms (FR2) or 0.5 ms (FR1).

refServCellIndicator indicates the serving cell whose SFN and subframe are used for gap calculation for this gap pattern. Value pCell corresponds to the PCell, pSCell corresponds to the PSCell, and mcg-FR2 corresponds to a serving cell on FR2 frequency in MCG. This field is used only in NE-DC or NR-DC configuration.

2.2 Configuration provided by E-UTRAN RRC (EN-DC)

In the case of EN-DC configuration, E-UTRAN RRC is responsible for configuring the UE with measurement gap using E-UTRAN RRC MeasGapConfig. This is applicable for LTE and NR serving cells on FR1 only.

- In summary, the UE may either be configured with a single (common) gap or with two separate gaps i.e. a first one for FR1 (configured by E-UTRA RRC for measuring E-UTRAN and NR serving sells) and a second one for FR2 (configured by NR RRC).

3GPP release 15 has introduced several new gap configurations within E-UTRAN RRC MeasGapConfig in order to accommodate the EN-DC measurement requirements.

The MeasGapConfig IE configured by E-UTRAN RRC is shown below;

*MeasGapConfig*
*gapOffset*		MGL (msec)
gp0	INTEGER (0..39)	6
gp1	INTEGER (0..79)	6
gp2-r14	INTEGER (0..39)	3
gp3-r14	INTEGER (0..79)	3
gp4-r15	INTEGER (0..19)	6
gp5-r15	INTEGER (0..159)	6
gp6-r15	INTEGER (0..19)	4
gp7-r15	INTEGER (0..39)	4
gp8-r15	INTEGER (0..79)	4
gp9-r15	INTEGER (0..159)	4
gp10-r15	INTEGER (0..19)	3
gp11-r15	INTEGER (0..159)	3

In general, the MeasGapConfig is applicable for all LTE and NR serving cells (including FR2). Hence, this is same as gapUE (per-UE gap) configuration.

The network can limit the use of MeasGapConfig to LTE serving cells and NR serving cells on (only) FR1 by setting the field fr1-Gap (within E-UTRAN RRC MeasConfig) to TRUE. In this case the gap configuration is same as gapFR1 (per-FR1 gap).

Now, the question is how the measurement gap timing advance (mgta) discussed in section 2.1.4 (for NR measurements) is handled when the gap is configured by E-UTRAN RRC. Release 15 version of 36.331 has introduced a field (mgta-r15) for this purpose.

- mgta indicates whether a timing advance value of 0.5 ms is applicable to the measurement gap configuration provided by E-UTRAN. E-UTRAN sets mgta to TRUE only when the UE is configured to perform NR measurements. As E-UTRAN RRC is only responsible for measurement gaps within FR1, only 0.5 ms for mgta is applicable.

The fields mgta and fr1-Gap within MeasConfig (configured by E-UTRAN RRC) are shown below;

*MeasConfig*
*. . .*
fr1-Gap-r15	BOOLEAN
mgta-r15	BOOLEAN
*. . .*

3 Measurement Gap Calculation

After receiving the measurement gap configuration, the first subframe of each gap occurs at an SFN and subframe meeting the following condition:

SFN mod (MGRP/10) = FLOOR (gapOffset/10)

subframe = gapOffset mod 10

The values of MGRP (mgrp) and gapOffset are configured by the network within the corresponding measurement gap configuration of gapFR1/gapFR2/gapUE.

3.1 Determination of SFN and subframe for measGAP calculation

For gapFR2 configuration:

- For the UE in NE-DC or NR-DC, the SFN and subframe of the serving cell indicated by the refServCellIndicator in gapFR2 is used in the gap calculation.

- Otherwise, for UE in NR standalone operation (with single carrier or NR CA) or (NG) EN-DC, the SFN and subframe of a serving cell on FR2 frequency is used in the gap calculation.

For gapFR1 or gapUE configuration:

- For the UE in NE-DC or NR-DC, the SFN and subframe of the serving cell indicated by the refServCellIndicator in corresponding gapFR1 or gapUE is used in the gap calculation.

- Otherwise, for (with single carrier or NR CA) or (NG) EN-DC, the SFN and subframe of the PCell is used in the gap calculation.

4 Measurement Gap Pattern Configurations

As discussed in section 2, NR supports MGRP of 20, 40, 80 and 160 ms and MGL of 1.5, 3, 3.5, 4, 5.5, or 6 ms.

A measurement gap pattern is characterized by MGRP and MGL. There are 24 gap pattern configurations defined in 38.133 to accommodate all the needs for NR and E-UTRAN measurements.

The measurement gap patterns are presented in the table below.

GAP Pattern Id	MGL (msec)	MGRP (msec)	GAP Pattern Id	MGL (msec)	MGRP (msec)
0	6	40	12	5.5	20
1	6	80	13	5.5	40
2	3	40	14	5.5	80
3	3	80	15	5.5	160
4	6	20	16	3.5	20
5	6	160	17	3.5	40
6	4	20	18	3.5	80
7	4	40	19	3.5	160
8	4	80	20	1.5	20
9	4	160	21	1.5	40
10	3	20	22	1.5	80
11	3	160	23	1.5	160

When the measurement gap is configured by NR RRC (section 2.1), the configuration provides all the required fields (mgl, mgrp, mgta and gapOffset) in order for the UE to calculate the measurement gap.

Similarly, when measurement gap is configured by E-UTRAN RRC (section 2.2), the configured gapOffset value provides information such as mgl and mgrp in addition to gapOffset value itself. mgta needs to be explicitly informed to the UE using the filed mgta-r15 (section 2.2).

5 Measurement Gap Timing Advance (MGTA)

As discussed in section 1, RF re-tuning time is required at the beginning and at the end of the measurement gap and the UE uses SMTC information together with measurement gap configuration to perform neighbour cell NR measurements.

In some cases, the SMTC window and the measurement gap start at the same time which leads to overlapping of RF re-tuning time and SMTC window. As the UE cannot perform measurements during RF re-tuning time, it would miss to measure SSBs during the start of SMTC window.

To overcome this problem, 3GPP has introduced Measurement Gap Timing Advance (MGTA). With this mechanism, the start of measurement gap is advanced by an amount of RF re-tuning time i.e., 0.5 ms for measurements in FR1 and 0.25 ms for FR2.

For measurement gap configured by NR RRC (section 2.1.4), the parameter mgta configured within MeasGapConfig informs the UE about the amount of timing advance (0.25 ms or 0.5 ms).

For measurement gap configured by E-UTRAN RRC (EN-DC), the field mgta-r15 is used for this purpose. The presence of this field indicates to the UE whether a timing advance value of 0.5 ms is applicable to the measurement gap configuration provided by E-UTRAN. E-UTRAN sets mgta to TRUE only when the UE is configured to perform NR measurements.

6 Handling of measurement gaps (from MAC perspective)

During a measurement gap, on the Serving Cell(s) in the corresponding frequency range (FR) of the measurement gap, the MAC entity shall;

- not perform the transmission of HARQ feedback, SR, and CSI

- not report SRS

- not transmit on UL-SCH except for Msg3

- not receive on DL-SCH

- not monitor the PDCCH except for the case if the UE is waiting for Msg2 or Msg4 during RA procedure.

7 UE capability

UE conveys its measurement capabilities in UE Capability Information message for standalone NR and MR-DC and NR-DC.

In this case of LTE, the UE indicates its ‘need for gaps’ for every band combination e.g., via interFreqNeedForGaps or interRAT-NeedForGaps.

To configure inter-RAT NR measurements to an LTE UE that is not yet configured with EN-DC, the LTE network needs to know whether the UE needs gaps for such measurements. RAN2 concluded that adding NeedForGap capability to each NR bands into LTE RRC signaling is not supported in Rel-15. The E-UTRAN RRC always configures measurement gap for NR measurements.

7.1 Measurement Gap patterns supported by the UE

Measurement gap patterns are discussed in section 4. The UE need to first inform the network (via UE capability signalling) which gap patterns it supports. The network configures the measurement gap pattern to the UE accordingly.

The gap patterns capabilities are conveyed by the UE as discussed in the below sections.

7.1.1 Gap Patterns 0 and 1

It is mandatory to support gap patterns 0 and 1 for all cases (LTE standalone, EN-DC, NR standalone etc…). So, the UE need not inform the network.

7.1.2 Gap Patterns 2 and 3

In LTE standalone as well as in EN-DC, LTE RRC signalling shortMeasurementGap is used to signal whether UE supports gap patterns 2 and 3.

shortMeasurementGap is part of MeasParameters IE and is introduced in release-14 version of 36.331. The UE includes this field to indicate whether the UE supports shorter measurement gap length (i.e. gp2 and gp3) in LTE standalone and for independent measurement gap configuration on FR1 and per-UE gap in (NG) EN-DC.

MeasParameters-v1430 (36.331)
*. . .*
shortMeasurementGap-r14	ENUMERATED {supported}
*. . .*

In NR (NR SA, NR-DC, and NE-DC), NR RRC signalling supportedGapPattern (22 bits) is used to signal whether UE supports gap patterns 2 to 23.

supportedGapPattern is part of MeasAndMobParameters IE and it indicates measurement gap pattern(s) supported by the UE for NR SA, for NR-DC, for NE-DC and for independent measurement gap configuration on FR2 in (NG) EN-DC.

- The leftmost bit (bit 0) corresponds to the gap pattern 2, the next bit corresponds to the gap pattern 3 and so on.

*MeasAndMobParametersCommon*
supportedGapPattern	BIT STRING ( SIZE (22) )
*. . .*

7.1.3 Gap Patterns 4 to 11

In LTE standalone as well as in EN-DC, LTE RRC signalling measGapPatterns (8 bits) is used to signal whether UE supports gap patterns 4 to 11.

measGapPatterns is part of MeasParameters IE and is introduced in release-15 version of 36.331. The UE includes this field to indicate, whether the UE supports NR gap patterns 4 to 11 in LTE standalone as well as for (NG) EN-DC (per-UE gap and FR1 gap of per-FR gap).

- The leftmost bit (bit 0) corresponds to the gap pattern 4, the next bit corresponds to the gap pattern 5 and so on. Value 1 indicates that the UE supports the concerned gap pattern.

MeasParameters-v1520 (36.331)
measGapPatterns-r15	BIT STRING ( SIZE (8) )

In NR (NR SA, NR-DC, and NE-DC), NR RRC signalling supportedGapPattern (22 bits) is used to signal whether UE supports gap patterns 2 to 23. supportedGapPattern field is explained in the previous section (7.1.2).

- The leftmost bit (bit 0) corresponds to the gap pattern 2, the next bit corresponds to the gap pattern 3 and so on.

7.1.4 Gap Patterns 12 to 23

The gap patterns 12 to 23 are applicable for FR2 only and can only be configured by NR RRC signalling. So, the UE indicates its capability to support these patterns to NR RRC via supportedGapPattern (this field is explained in section 7.1.2).

- The leftmost bit (bit 0) corresponds to the gap pattern 2, the next bit corresponds to the gap pattern 3 and so on.

Note: The UE shall set the bits corresponding to the measurement gap pattern 13 and 14 to 1 if one of the following conditions are satisfied the UE is an NR standalone capable UE that supports at least a band in FR2 or if the UE is an (NG) EN-DC capable UE that supports independentGapConfig and supports at least band in FR2. This implies that if a UE supports at least a band in FR2, it must (mandatorily) support gap patterns 13 and 14.

7.2 UE’s support for Independent Gap Configuration

The field independentGapConfig indicates whether the UE supports two independent measurement gap configurations for FR1 and FR2. This helps the network providing per-FR measurement gap patterns for each frequency range (FR) where UE requires per-FR measurement gap for concurrent monitoring of all frequency layers of each frequency range independently.

- Moreover, this field also indicates whether the UE supports the FR2 inter-RAT measurements without gaps when EN-DC is not (yet) configured i.e., if this LTE UE (not yet configured with EN-DC) has per-FR measurement capability and it is configured to measure FR2 inter-RAT MO only, gapless measurement is possible.

*MeasAndMobParametersCommon* or MeasAndMobParametersMRDC-Common
*. . .*
independentGapConfig	ENUMERATED {supported}
*. . .*

Reference: 3GPP TS 38.133, 38.331, 38.321, 38.912, 38.306, 36.306 and 36.331

5G NR: PUSCH Resource Allocation in Time-Domain

2019-12-03T00:32:00.000+01:00

1. Introduction

As discussed in the post: Time Domain – Slots and Slot Formats, number of slots/symbols available for transmission/reception varies depending upon the network configuration. Therefore, it is important for the network to signal the UE about the timing of data transmission/reception.

Signalling of time-domain resources means, informing the UE about which slots/symbols the data can be transmitted/received. Similar to LTE, NR resource allocation is done either dynamically or in semi-persistent manner.

Dynamic scheduling in the uplink is done using PDCCH DCI. For semi-persistent scheduling, NR defines two mechanisms; one using PDCCH DCI (similar to LTE) and the other one purely via RRC signalling (new in NR).

PDCCH DCI is used for both dynamic and Semi-Persistent Scheduling (SPS) in the downlink (similar to LTE).

Time-domain PDSCH resource allocation is discussed in the post: PDSCH Resource Allocation in Time-Domain. In this post, uplink (PUSCH) resource allocation in time-domain is discussed in detail.

2 PUSCH Resource Allocation in Time-Domain

2.1 Dynamic Scheduling

Refer to section 6.1.2.1 of 38.214 for more details.

In NR, DCI formats 0_0 and 0_1 are used to dynamically allocate time-domain resources for PUSCH. These DCI formats are thoroughly discussed in the post: DCI Formats in 5G NR.

In the case of dynamic scheduling, PDCCH carrying DCI 0_0 and 0_1 are in general addressed to either C-RNTI or MCS-C-RNTI. Temporary C-RNTI is also used during random access procedure.

DCI formats 0_0 and 0_1 carries 4-bit field named ‘time domain resource assignment’ which points to one of the rows of a look-up table. How the UE determines which look-up table to be used is discussed in section 2.1.2.

There can be up to 16 rows in the look-up table and hence only 4-bits are used for the field ‘time domain resource assignment’ and value ‘m’ for this field points to row number ‘m+1’ within the look-up table.

Each row in the look-up table provides the following parameters;

- slots offset K₂. This parameter is used to derive the slot in which PUSCH transmission occurs.

- SLIV (jointly coded Start and Length Indicator Values), or individual values for the start symbol ‘S’ and the allocation length ‘L’.

- ‘PUSCH mapping type’ to be applied on the PUSCH transmission.

The contents of the look-up table are summarised below;

Parameter	Explanation
K₂	Used to derive the slot offset from the slot where DCI is received
S	’S’ is the ‘start symbol’ -> First symbol in the slot in which PUSCH will be transmitted
L	Allocation length in number of OFDM symbols.
*SLIV*	Start and Length values are jointly encoded to produce Start and Length Indicator Value (SLIV)
*PUSCH mapping type*	PUSCH mapping type (Type A or Type B) to be applied in the PUSCH transmission. This helps determining the first DM-RS symbol position.

The following figure illustrates an example with time domain resource assignment field in DCI 0_0/0_1 indicating (based on look-up table) K₂ = 1, S = 4 and L = 6.

In the above illustration, it is assumed that SCS for PUSCH and PDCCH are same.

It is possible that network configures different SCS for PDCCH and PUSCH. Determining slot offset based on just K₂ is not sufficient if SCS for PDCCH and PUSCH are different. In such cases, the slot where the UE shall transmit the PUSCH is calculated according to the below equation;
\[The\:slot\:number\:allocated\:for\:PUSCH\:=\:\Big \lfloor n.\dfrac{2^{\mu_{PUSCH}}}{2^{\mu_{PDCCH}}} \Big\rfloor + K_2\]

where n is the slot with the scheduling DCI, K₂ is based on the numerology of PUSCH, and µ_PUSCH and µ_PDCCH are the subcarrier spacing configurations for PUSCH and PDCCH, respectively.

Considering same example from the above illustration, K₂ = 1, S = 4, L = 6, µ_PUSCH = 2, and µ_PDCCH = 0 => if the DCI is received in slot number 1 (using PDCCH SCS), the PUSCH will be transmitted in the slot number 5 (= 4+1 based on the above equation) using PUSCH SCS. Note that in this example, there are 4 times more number of slots with PUSCH SCS as compared to PDCCH SCS.

2.1.1 Valid ‘S’ and ‘L’ combinations:

Not all start and length values are valid due to the fact that a single time-domain resource allocation must be contained within a slot i.e., the allocation should not cross the slot boundary.

Moreover, the number of symbols in a slot varies with cyclic prefix which will also limit number of allowed start and length combinations => for normal CP, a slot contains 14 OFDM symbols and with extended CP, 12 OFDM symbols form a slot.

The UE shall consider the S and L combinations defined in table below as a valid PUSCH allocations. Note from column ‘S+L’ that the sum of start symbol number and allocation length should not exceed 14 for normal CP and 12 for extended CP.

PUSCH Mapping Type	Normal cyclic prefix			Extended cyclic prefix
PUSCH Mapping Type	S	L	*S+L*	S	L	*S+L*
*Type A*	0	{4,...,14}	{4,...,14}	0	{4,…,12}	{4,…,12}
*Type B*	{0,...,13}	{1,…,14}	{1,…,14}	{0,…,11}	{1,…,12}	{1,…,12}

2.1.2 Which resource allocation table to be used for PUSCH?

There are two types of PUSCH resource allocation tables (look-up tables);

1. “default PUSCH time domain allocation table A”: A predefined table in 38.214, Table 6.1.2.1.1-2 for normal CP and Table 6.1.2.1.1-3 for extended CP.

2. RRC configured table pusch-TimeDomainAllocationList sent in either pusch-ConfigCommon (sent via SIB1 or dedicated RRC signalling) or pusch-Config (sent via dedicated RRC signalling)

The UE will choose appropriate table based on several factors like which of the above tables is configured in the UE, RNTI, search space type etc… Table 6.1.2.1.1-1 in 38.214 specifies the table selection criteria and is presented below for a quick reference.

RNTI	PDCCH search space	*pusch-ConfigCommon* includes TimeDomain AllocationList	*pusch-Config* includes TimeDomain AllocationList	PUSCH time domain resource allocation to apply
PUSCH scheduled by MAC RAR (uplink grant received within RAR)		No	N/A	Default A
		Yes	N/A	pusch-TimeDomainAllocationList from pusch-ConfigCommon
C-RNTI, MCS-C-RNTI, TC-RNTI, CS-RNTI	Any common search space associated with CORESET0	No	N/A	Default A
C-RNTI, MCS-C-RNTI, TC-RNTI, CS-RNTI	Any common search space associated with CORESET0	Yes	N/A	pusch-TimeDomainAllocationList from pusch-ConfigCommon
C-RNTI, MCS-C-RNTI, TC-RNTI, CS-RNTI, SP-CSI-RNTI	Any common search space NOT associated with CORESET0, (or) UE-specific search space	No	No	Default A
		Yes	No	pusch-TimeDomainAllocationList from pusch-ConfigCommon
		No/Yes	Yes	pusch-TimeDomainAllocationList from pusch-Config

Notes from the above table;

- default PUSCH time domain allocation table A is chosen in cases where TimeDomainAllocationList is not configured by either pusch-ConfigCommon or pusch-Config (for applicable cases).

- If available, TimeDomainAllocationList provided by pusch-ConfigCommon is always used except for a case where the same list is also provided by pusch-Config and the concerned search space is either UE-specific or common search space not associated with CORESET0.

- If TimeDomainAllocationList is provided by pusch-Config and the concerned search space is either UE-specific or common search space not associated with CORESET0, then TimeDomainAllocationList is used.

There is an additional slot delay value defined for the first transmission of PUSCH scheduled by the RAR grant. This slot delay increases with SCS. When the UE transmits a PUSCH scheduled by RAR, the ∆ value specific to the PUSCH subcarrier spacing is applied in addition to the K₂ value i.e., total slot offset applied is equal to K₂ + ∆. The additional slot delay (∆) values are as shown below;

SCS	Additional slot delay value ( ∆ )
15 kHz	2
30 kHz	3
60 kHz	4
120 kHz	6

2.1.2.1 Default PUSCH time-domain allocation table A

“Default PUSCH time domain resource allocation table A” is shown below for both normal CP and extended CP. As the number of symbols per slot varies depending upon CP, only length (in symbols) is different in the case of extended CP.

Row index	PUSCH mapping type	K₂	S	L
Row index	PUSCH mapping type	K₂	S	Normal CP	Extended CP
1	Type A	j	0	14	8
2	Type A	j	0	12	12
3	Type A	j	0	10	10
4	Type B	j	2	10	10
5	Type B	j	4	10	4
6	Type B	j	4	8	8
7	Type B	j	4	6	6
8	Type A	j + 1	0	14	8
9	Type A	j + 1	0	12	12
10	Type A	j + 1	0	10	10
11	Type A	j + 2	0	14	6
12	Type A	j + 2	0	12	12
13	Type A	j + 2	0	10	10
14	Type B	j	8	6	4
15	Type A	j + 3	0	14	8
16	Type A	j + 3	0	10	10
j = {1, 1, 2, 3} for SCS = {15 kHz, 30 kHz, 60 kHz, 120 kHz} respectively

Note from the above table, slot offset ‘K₂’ values are always non-zero, meaning that PUSCH transmission never starts in the same slot where allocation is received.

2.1.2.2 TimeDomainAllocationList

TimeDomainAllocationList is configured by either pusch-ConfigCommon or pusch-Config.

The IE PUSCH-TimeDomainResourceAllocation is used to configure a time-domain relation between PDCCH and PUSCH. PUSCH-TimeDomainResourceAllocationList contains one or more (up to 16) of such PUSCH-TimeDomainResourceAllocations.

The UE determines the bit width of the DCI field based on the number of entries in the PUSCH-TimeDomainResourceAllocationList.

The network indicates in the UL grant (DCI) which of the configured time domain allocations the UE shall apply for that UL grant. Value 0 in the DCI field refers to the first element in this list, value 1 in the DCI field refers to the second element in this list, and so on.

PUSCH-TimeDomainResourceAllocationList IE structure is shown below. It contains K₂, PUSCH mapping type, and startSymbolAndLength (SLIV).

*PUSCH-TimeDomainResourceAllocationList*
PUSCH-TimeDomainResourceAllocationList	List from 1 up to 16 PUSCH-TimeDomainResourceAllocation
*PUSCH-TimeDomainResourceAllocation*
k₂	INTEGER (0..32)
mappingType	ENUMERATED {type A, type B}
startSymbolAndLength	INTEGER (0..127)

- The value of K₂ranges from 0 to 32 => unlike default table A, this method of allocation allows for PUSCH transmission within the same slot (K₂ = 0) where the allocation is received. When allocation and PUSCH transmission are contained in the same slot, it is referred to as ‘self-contained’ slot.

- When K₂ field is absent, the UE applies the value 1 when PUSCH SCS is 15/30 kHz; the value 2 when PUSCH SCS is 60 kHz, and the value 3 when PUSCH SCS is 120KHz.

- startSymbolAndLength provides an index giving valid combinations of start symbol and length (jointly encoded) as start and length indicator (SLIV). The network configures the field so that the allocation does not cross the slot boundary.

As can be noted, in this option, the network doesn’t give individual values of starting symbol ‘S’ and length value ‘L’, instead, a jointly encoded value (SLIV) is provided.

The ‘S’ and ‘L’ values allocated for the PUSCH are determined from the SLIV as shown below:

if (L − 1) ≤ 7:

SLIV = 14.(L − 1) + S

else:

SLIV = 14⋅(14 − L + 1) + (14 − 1 − S)

where 0 < L ≤ 14 − S

2.1.3 PUSCH mapping type:

Refer to section 6.4.1.1.3 from 38.211 for more details.

PUSCH mapping type defines the DM-RS configuration of PUSCH transmissions. Depending upon the location of first DM-RS symbol, there are two mapping types defined; type A and type B.

As discussed already, time domain resource assignment field within the DCI points to a row number within the look-up table and each row defines PUSCH mapping type (either type A or type B) to be followed.

PUSCH mapping type A:

In type A, DM-RS is mapped relative to the start of the slot irrespective of which symbol in the slot the PUSCH transmission starts.

When frequency hopping is disabled, the DM-RS position is defined to start relative to the start of the slot boundary and relative to start of each hop in case if frequency hopping is enabled.

The position of the first DM-RS symbol for type A is configured by RRC via either MIB or via ServingCellConfigCommon (SIB1 or dedicated signalling). The field dmrs-TypeA-Position is used for this purpose. This field takes two values pos2 or pos3. First symbol of DM-RS is located at either symbol 2 (pos2) or at symbol 3 (pos3) within the slot.

dmrs-TypeA-Position

ENUMERATED { pos2, pos3 }

PUSCH mapping type B:

In type B, DM-RS is mapped relative to the start of the PUSCH allocation rather than start of the slot boundary.

To be precise, the DM-RS location is the first OFDM symbol where PUSCH transmission starts if frequency hopping is disabled and relative to the start of each hop in case frequency hopping is enabled.

In this case, as the DM-RS start symbol is fixed, the network need not explicitly provide configuration for type B.

Valid S and L combinations:

‘S’ and ‘L’ values are defined separately for each PUSCH mapping type because, not all combinations are valid for a given mapping type.

PUSCH Mapping Type	Normal cyclic prefix			Extended cyclic prefix
PUSCH Mapping Type	S	L	*S+L*	S	L	*S+L*
*Type A*	0	{4,...,14}	{4,...,14}	0	{4,…,12}	{4,…,12}
*Type B*	{0,...,13}	{1,…,14}	{1,…,14}	{0,…,11}	{1,…,12}	{1,…,12}

From the above table, it can be seen that, for PUSCH mapping type A, start symbol ‘S’ is always symbol ‘0’ because it makes sense to start before symbol 2 which can be the first DM-RS location for type A (pos2).

2.2 Semi-Persistent Scheduling

For uplink SPS, PDCCH carrying DCI 0_0 and 0_1 is addressed to Configured Scheduling-RNTI (CS-RNTI). In LTE, SPS-C-RNTI is used for this purpose. The grant received using CS-RNTI is referred to as configured grant.

Similar to uplink SPS in LTE, configured grant is given by the network to the UE who stores the received grant and uses it according to the pre-configured timing given by the network.

Configured grant will be discussed thoroughly in a separate post.

Unlink LTE, NR has two types of configured grants defined. Type 1 and Type 2.

Note that the discussions in section 2.1 above are valid for configured grants as well except for the way the network informs the UE about the time-domain resource allocation.

2.2.1 Time-domain resource allocation in configured grant type 1

In configured grant Type 1, the resource allocation is done using RRC. Only for re-transmissions, PDCCH DCI 0_0 or 0_1 addressed to CS-RNTI is used.

The following table provides part of the RRC configuration for configured grant Type 1. The intention is to highlight how the time-domain resource allocation is done.

*rrc-ConfiguredUplinkGrant*
timeDomainOffset	INTEGER (0..5119)
timeDomainAllocation	INTEGER (0..15)
frequencyDomainAllocation	BIT STRING ( SIZE (15) )
. . .

timeDomainOffset provides an offset relative to SFN = 0. The UE activates the configured grant after the offset configured by this parameter.

Similar to dynamic scheduling, timeDomainAllocation field from above table indicates a combination of start symbol ‘S’ and length ‘L’ and PUSCH mapping type.

A value ‘m’ for the field timeDomainAllocation points to row number ‘m+1’ within the look-up table. The rules to determine which look-up table to be used is exactly same as those discussed in sections 2.1.2 above.

In this type of resource allocation, once the network configures time-domain resource using RRC, the only way to change the allocation is by re-configuring the parameters by sending another RRCReconfiguration message to the UE.

2.2.2 Time-domain resource allocation in configured grant type 2

Configured grant type 2 in NR is similar to that of uplink SPS in LTE.

In configured grant Type 2, the time-domain resource allocation is done using PDCCH DCI (format 0_0 or 0_1) addressed to CS-RNTI. Even for re-transmissions, PDCCH DCI 0_0 or 0_1 addressed to CS-RNTI is used.

Once configured using DCI 0_0 or 0_1, the UE periodically uses same time-domain resources until the configured grant is re-activated (kind of reconfiguration at MAC level).

As the time-domain resource allocation is done using DCI 0_0 or 0_1 (similar to dynamic allocation), all the discussions in section 2.1 are valid for configured grant type 2 as well.

3 Slot Aggregation:

Slot aggregation improves the uplink (cell edge) coverage. In a cell edge scenario, the probability of incorrectly decoding PUSCH is more, so instead of waiting confirmation from the gNB, it would be beneficial to (re-)transmit PUSCH in consecutive slots.

With slot aggregation data transmission can span over multiple slots i.e the UE would transmit same TB across a pre-configured number of consecutive slots.

Same HARQ process is used for each transmission that is part of the same bundle. Within a bundle, HARQ retransmissions are triggered without waiting for feedback from previous transmission.

In the first step, the network configures slot aggregation via RRC signalling;

- pusch-AggregationFactor within PUSCH-Config IE is used for the case of dynamic scheduling. This field can take values of 2, 4 or 8 repetitions as shown below;

pusch-AggregationFactor

ENUMERATED { n2, n4, n8 }

- repK within ConfiguredGrantConfig IE for the case of configured grant. This field is mandatorily present and takes values of 1, 2, 4, and 8. Slot aggregation is activated when repK > 1.

repK

ENUMERATED { n1, n2, n4, n8 }

In the second step, network sends DCI format 0_1 on PDCCH with CRC scrambled with C-RNTI or MCS-C-RNTI for dynamic grant and CS-RNTI with NDI=1 for configured grant.

The UE follows the below procedure considering pusch-AggregationFactor is applicable for dynamic scheduling and repK is applicable for configured uplink grant;

- When the MAC entity is configured with pusch-AggregationFactor > 1 or repK > 1, the parameter pusch-AggregationFactor/repK provides the number of transmissions of the same TB within a bundle.

- After the initial transmission, pusch-AggregationFactor – 1 or repK – 1 HARQ retransmissions follow within a bundle.

- Same HARQ process is used for each transmission that is part of the same bundle.

- The UE shall repeat the TB across the pusch-AggregationFactor/repK consecutive slots applying the same symbol allocation in each slot.

- For dynamic scheduling, the redundancy version to be applied on the n^th transmission occasion of the TB, where n = 0, 1, ... (pusch-AggregationFactor - 1), is determined according to table below.

rv_idindicated by the DCI scheduling the PUSCH	rv_id to be applied to n^th transmission occasion
rv_idindicated by the DCI scheduling the PUSCH	n mod 4 = 0	n mod 4 = 1	n mod 4 = 2	n mod 4 = 3
0	0	2	3	1
2	2	3	1	0
3	3	1	0	2
1	1	0	2	3

- For configured grant, the parameter repK-RV (if configured within configuredGrantConfig IE) is used to derive the redundancy version pattern to be applied to the repetitions. If this parameter repK-RV is not configured, the redundancy version for uplink transmissions shall be set to 0. Refer to section 6.1.2.3 of 38.214 for more details.

repK-RV

ENUMERATED { s1-0231, s2-0303, s3-0000 }

Note that when slot aggregation is active, the PUSCH is limited to a single transmission layer.

The following example illustrates PUSCH slot aggregation;

Reference: 3GPP TS 38.211, 38.212, 38.213, 38.214, and 38.331

5G NR: PDSCH Resource Allocation in Time-Domain

2019-12-02T23:34:00.000+01:00

1. Introduction

PDCCH DCI is used for both dynamic and Semi-Persistent Scheduling (SPS) in the downlink (similar to LTE).

Time-domain PUSCH resource allocation is discussed in the post: PUSCH Resource Allocation in Time-Domain. In this post, downlink (PDSCH) resource allocation in time-domain is discussed in detail.

2 PDSCH Resource Allocation in Time-Domain

2.1 Dynamic Scheduling

For more details on PDSCH time-domain resource allocation, refer to section 5.1.2.1 of 38.214.

In NR, DCI formats 1_0 and 1_1 are used to dynamically allocate time-domain resources for PDSCH. These DCI formats are thoroughly discussed in the post: DCI Formats in 5G NR.

In the case of dynamic scheduling, PDCCH carrying DCI 1_0 and 1_1 are in general addressed to either C-RNTI or MCS-C-RNTI. Other RNTIs such as SI-RNTI, P-RNTI, Temporary C-RNTI, and RA-RNTI are also used for this purpose.

DCI formats 1_0 and 1_1 carries 4-bit field named ‘time domain resource assignment’ which points to one of the rows of a look-up table. How the UE determines which look-up table to be used is discussed in section 2.1.2.

Each row in the look-up table provides the following parameters;

- slots offset K₀. This parameter is used to derive the slot in which PDSCH reception occurs. When K₀ = 0, PDSCH reception is intended within the same slot where DCI is received. When allocation and PDSCH transmission are contained in the same slot, it is referred to as ‘self-contained’ slot.

- SLIV (jointly coded start and length indicator values), or individual values for the start symbol ‘S’ and the allocation length ‘L’.

- ‘PDSCH mapping type’ to be assumed on the PDSCH reception.

The contents of the look-up table are summarised below;

Parameter	Explanation
K₀	Used to derive the slot offset from the slot where DCI is received
S	’S’ is the ‘start symbol’ -> First symbol in the slot in which PDSCH will be received
L	Allocation length in number of OFDM symbols.
*SLIV*	Start and Length values are jointly encoded to produce Start and length Indicator Value (SLIV)
*PDSCH mapping type*	PDSCH mapping type (Type A or Type B) to be assumed in the PDSCH reception.

The following figure illustrates an example with time domain resource assignment field in DCI 1_0/1_1 indicating (based on look-up table) K₀ = 1, S = 4 and L = 7.

In the above illustration, it is assumed that SCS for PDSCH and PDCCH are the same.

It is possible that network configures different SCS for PDCCH and PDSCH. Determining slot offset based on just K₀ is not sufficient if SCS for PDCCH and PDSCH are different. In such cases, the slot where the UE shall receive the PDSCH is calculated according to the below equation;
\[The\:slot\:number\:allocated\:for\:PDSCH\:=\:\Big \lfloor n.\dfrac{2^{\mu_{PDSCH}}}{2^{\mu_{PDCCH}}} \Big\rfloor + K_0\]

where n is the slot with the scheduling DCI, K₀ is based on the numerology of PDSCH, and µ_PDSCH and µ_PDCCH are the subcarrier spacing configurations for PDSCH and PDCCH, respectively.

Considering same example from the above illustration, K₀ = 1, S = 4, L = 7, µ_PDSCH = 2, and µ_PDCCH = 0 => if the DCI is received in slot number 1 (using PDCCH SCS), the PDSCH will be received in the slot number 5 (= 4+1 based on the above equation) using PDSCH SCS. Note that in this example, there are 4 times more number of slots with PDSCH SCS as compared to PDCCH SCS.

2.1.1 Valid ‘S’ and ‘L’ combinations:

Not all start and length values are valid due to the fact that a single time-domain resource allocation must be contained within a slot i.e., the allocation should not cross the slot boundary.

The UE shall consider the S and L combinations defined in table below as a valid PDSCH allocations. Note from column ‘S+L’ that the sum of start symbol number and allocation length should not exceed 14 for normal CP and 12 for extended CP.

PDSCH Mapping Type	Normal cyclic prefix			Extended cyclic prefix
PDSCH Mapping Type	S	L	*S+L*	S	L	*S+L*
*Type A*	{0, 1, 2, 3} (Note1)	{3,…,14}	{3,…,14}	{0, 1, 2, 3} (Note1)	{3,…,12}	{3,…,12}
*Type B*	{0,…,12}	{2, 4, 7}	{2,…,14}	{0,…,10}	{2, 4, 6}	{2,…,12}
*Note1: S = 3 is applicable only if dmrs-TypeA-Position = 3*

2.1.2 Which resource allocation table to be used for PDSCH?

There are two types of PDSCH resource allocation tables (look-up tables);

1. “default PDSCH time domain allocation table”: There are a couple of pre-defined default tables in 38.214, table 5.1.2.1.1-2, 5.1.2.1.1-4, 5.1.2.1.1-5 for normal CP and table 5.1.2.1.1-3 for extended CP.

2. RRC configured table pdsch-TimeDomainAllocationList sent in either pdsch-ConfigCommon (sent via SIB1 or dedicated RRC signalling) or pdsch-Config (sent via dedicated RRC signalling)

The UE will choose appropriate table based on several factors like which of the above tables is configured in the UE, RNTI, SSB and CORESET multiplexing pattern, search space type etc… Table 5.1.2.1.1-1 in 38.214 specifies the table selection criteria and is presented below for a quick reference.

RNTI	PDCCH search space	SS/PBCH block and CORESET multiplexing pattern	*pdsch-ConfigCommon includes pdsch- TimeDomain AllocationList*	**pdsch-Config includes pdsch-TimeDomain AllocationList**	PDSCH time domain resource allocation to apply
SI-RNTI	Type0 common	1	N/A	N/A	Default A for normal CP
		2	N/A	N/A	Default B
		3	N/A	N/A	Default C
SI-RNTI	Type0A common	1	No	N/A	Default A
		2	No	N/A	Default B
		3	No	N/A	Default C
		1,2,3	Yes	N/A	pdsch-TimeDomain AllocationList provided in pdsch-ConfigCommon
RA-RNTI, TC-RNTI	Type1 common	1, 2, 3	No	N/A	Default A
RA-RNTI, TC-RNTI	Type1 common	1, 2, 3	Yes	N/A	pdsch-TimeDomain AllocationList provided in pdsch-ConfigCommon
P-RNTI	Type2 common	1	No	N/A	Default A
		2	No	N/A	Default B
		3	No	N/A	Default C
		1,2,3	Yes	N/A	pdsch-TimeDomain AllocationList provided in pdsch-ConfigCommon
C-RNTI, MCS-C-RNTI, CS-RNTI	Any common search space associated with CORESET 0	1, 2, 3	No	N/A	Default A
C-RNTI, MCS-C-RNTI, CS-RNTI	Any common search space associated with CORESET 0	1, 2, 3	Yes	N/A	pdsch-TimeDomain AllocationList provided in pdsch-ConfigCommon
C-RNTI, MCS-C-RNTI, CS-RNTI	Any common search space not associated with CORESET 0 (or) UE specific search space	1,2,3	No	No	Default A
		1,2,3	Yes	No	pdsch-TimeDomainAllocationList provided in pdsch-ConfigCommon
		1,2,3	No/Yes	Yes	pdsch-TimeDomainAllocationList provided in pdsch-Config

Notes from the above table;

- There are 3 different default PDSCH time domain allocation tables; Default A, Default B and Default C.

- default PDSCH time domain allocation table is chosen in cases where TimeDomainAllocationList is not configured by either pdsch-ConfigCommon or PDSCH-Config (for applicable cases).

- If available, TimeDomainAllocationList provided by pdsch-ConfigCommon is always used except for a case where the same list is also provided by pdsch-Config and the concerned search space is either UE-specific or common search space not associated with CORESET0.

- For P-RNTI and SI-RNTI, the default table type depends upon SSB and CORESET multiplexing pattern. pattern 1 => Default A, pattern 2 => Default B, and for pattern 3 => Default C.

2.1.2.1 Default PDSCH time-domain allocation tables

Default PDSCH time domain resource allocation tables are presented in section 4 in this post.

2.1.2.2 TimeDomainAllocationList

TimeDomainAllocationList is configured by either pdsch-ConfigCommon or pdsch-Config.

The IE pdsch-TimeDomainResourceAllocation is used to configure a time-domain relation between PDCCH and PDSCH. pdsch-TimeDomainResourceAllocationList contains one or more (up to 16) of such pdsch-TimeDomainResourceAllocations.

The network indicates in the DL assignment which of the configured time domain allocations the UE shall apply for that DL assignment. Value 0 in the DCI field refers to the first element in this list, value 1 in the DCI field refers to the second element in this list, and so on.

The bit width of the DCI field is based on the number of entries in the pdsch-TimeDomainResourceAllocationList.

pdsch-TimeDomainResourceAllocationList IE structure is shown below. It contains K₀, PDSCH mapping type, and startSymbolAndLength (SLIV).

*PDSCH-TimeDomainResourceAllocationList*
PDSCH-TimeDomainResourceAllocationList	List from 1 up to 16 PDSCH-TimeDomainResourceAllocation
*PDSCH-TimeDomainResourceAllocation*
k₀	INTEGER (0..32)
mappingType	ENUMERATED {type A, type B}
startSymbolAndLength	INTEGER (0..127)

- The value of K₀ranges from 0 to 32, when K₀is absent, the UE applies the value 0.

As can be noted, in this option, the network doesn’t give individual values of starting symbol ‘S’ and length value ‘L’, instead, a jointly encoded value (SLIV) is provided.

The ‘S’ and ‘L’ values allocated for the PDSCH are determined from the SLIV as shown below:

if (L − 1) ≤ 7:

SLIV = 14.(L − 1) + S

else:

SLIV = 14⋅(14 − L + 1) + (14 − 1 − S)

where 0 < L ≤ 14 − S

2.1.3 PDSCH mapping type:

Refer to section 7.4.1.1.2 from 38.211 for additional details.

PDSCH mapping type defines the DM-RS configuration of PDSCH transmissions. Depending upon the location of first DM-RS symbol, there are two mapping types defined; type A and type B.

As discussed already, time domain resource assignment field within the DCI points to a row number within the look-up table and each row defines PDSCH mapping type (either type A or type B) to be followed.

PDSCH mapping type A:

In type A, DM-RS is mapped relative to the start of the slot irrespective of which symbol in the slot the PDSCH transmission starts.

dmrs-TypeA-Position

ENUMERATED { pos2, pos3 }

PDSCH mapping type B:

In type B, DM-RS is mapped relative to the start of the PDSCH allocation rather than start of the slot boundary. To be precise, the DM-RS location is the first OFDM symbol where PDSCH reception starts.

In this case, as the DM-RS start symbol is fixed, the network need not explicitly provide configuration for type B.

Valid S and L combinations:

‘S’ and ‘L’ values are defined separately for each PDSCH mapping type because, not all combinations are valid for a given mapping type.

PDSCH Mapping Type	Normal cyclic prefix			Extended cyclic prefix
PDSCH Mapping Type	S	L	*S+L*	S	L	*S+L*
*Type A*	{0, 1, 2, 3} (Note1)	{3,…,14}	{3,…,14}	{0, 1, 2, 3} (Note1)	{3,…,12}	{3,…,12}
*Type B*	{0,…,12}	{2, 4, 7}	{2,…,14}	{0,…,10}	{2, 4, 6}	{2,…,12}
*Note1: S = 3 is applicable only if dmrs-TypeA-Position = 3*

2.2 Semi-Persistent Scheduling

For downlink SPS, PDCCH carrying DCI 1_0 and 1_1 is addressed to Configured Scheduling-RNTI (CS-RNTI). In LTE, SPS-C-RNTI is used for this purpose. The assignment received using CS-RNTI is referred to as configured downlink assignment.

Similar to downlink SPS in LTE, configured downlink assignment in NR is given by the network to the UE who stores this assignment and uses it according to the pre-configured timing given by the network.

Configured downlink assignment will be discussed thoroughly in a separate post.

The time-domain resource allocation is done using PDCCH DCI (format 1_0 or 1_1) addressed to CS-RNTI. Even for re-transmissions, PDCCH DCI 1_0 or 1_1 addressed to CS-RNTI is used.

Once configured using DCI 1_0 or 1_1, the UE periodically uses same time-domain resources until the configured downlink assignment is re-activated (kind of reconfiguration at MAC level).

As the time-domain resource allocation is done using DCI 1_0 or 1_1 (similar to dynamic allocation), all the discussions in section 2.1 are valid for downlink SPS as well.

3 Slot Aggregation:

In a cell edge scenario, the probability of incorrectly decoding PDSCH is more, so instead of waiting confirmation from the UE, it would be beneficial to transmit PDSCH in consecutive slots.

With slot aggregation data transmission can span over multiple slots i.e., the network would transmit same TB across a pre-configured number of consecutive slots.

In the first step, the network configures slot aggregation via RRC signalling; pdsch-AggregationFactor within PDSCH-Config IE is used for dynamic and semi-persistent scheduling. This field can take values of 2, 4 or 8 repetitions as shown below;

pdsch-AggregationFactor

ENUMERATED { n2, n4, n8 }

In the second step, network sends DCI format 1_1 on PDCCH with CRC scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI.

Once slot aggregation is activated, the UE follows the below procedure;

- When the MAC entity is configured with pdsch-AggregationFactor > 1, the parameter pdsch-AggregationFactor provides the number of transmissions of a TB within a bundle

- After the initial transmission, pdsch-AggregationFactor – 1 HARQ retransmissions follow within a bundle.

- Same HARQ process is used for each transmission that is part of the same bundle.

- The UE may expect the same symbol allocation across the PDSCH-AggregationFactor consecutive slots i.e., the network shall repeat the same TB across the PDSCH-AggregationFactor consecutive slots applying the same symbol allocation in each slot.

- The redundancy version to be applied on the n^th transmission occasion of the TB, where n = 0, 1, ... (PDSCH-AggregationFactor - 1), is determined according to table below.

rv_idindicated by the DCI scheduling the PDSCH	rv_id to be applied to n^th transmission occasion
rv_idindicated by the DCI scheduling the PDSCH	n mod 4 = 0	n mod 4 = 1	n mod 4 = 2	n mod 4 = 3
0	0	2	3	1
2	2	3	1	0
3	3	1	0	2
1	1	0	2	3

- For the case of SPS, except for activation, there is no PDCCH involved for scheduling PDSCH. In this case, the UE should assume rv_id = 0 for initial transmission (n mod 4) and follow the pattern {0, 2, 3, 1} for retransmissions (1^st row in the above table).

Note that when slot aggregation is active, the PDSCH is limited to a single transmission layer.

The following example illustrates PDSCH slot aggregation;

4 Default PDSCH time-domain allocation tables:

Default PDSCH time domain resource allocation A
Row index	*dmrs-TypeA-Position*	PDSCH mapping type	K₀	Normal CP		Extended CP
Row index	*dmrs-TypeA-Position*	PDSCH mapping type	K₀	S	L	S	L
1	2	Type A	0	2	12	2	6
1	3	Type A	0	3	11	3	5
2	2	Type A	0	2	10	2	10
2	3	Type A	0	3	9	3	9
3	2	Type A	0	2	9	2	9
3	3	Type A	0	3	8	3	8
4	2	Type A	0	2	7	2	7
4	3	Type A	0	3	6	3	6
5	2	Type A	0	2	5	2	5
5	3	Type A	0	3	4	3	4
6	2	Type B	0	9	4	6	4
6	3	Type B	0	10	4	8	2
7	2	Type B	0	4	4	4	4
7	3	Type B	0	6	4	6	4
8	2,3	Type B	0	5	7	5	6
9	2,3	Type B	0	5	2	5	2
10	2,3	Type B	0	9	2	9	2
11	2,3	Type B	0	12	2	10	2
12	2,3	Type A	0	1	13	1	11
13	2,3	Type A	0	1	6	1	6
14	2,3	Type A	0	2	4	2	4
15	2,3	Type B	0	4	7	4	6
16	2,3	Type B	0	8	4	8	4

Default PDSCH time domain resource allocation B
Row index	*dmrs-TypeA-Position*	PDSCH mapping type	K₀	S	L
1	2,3	Type B	0	2	2
2	2,3	Type B	0	4	2
3	2,3	Type B	0	6	2
4	2,3	Type B	0	8	2
5	2,3	Type B	0	10	2
6	2,3	Type B	1	2	2
7	2,3	Type B	1	4	2
8	2,3	Type B	0	2	4
9	2,3	Type B	0	4	4
10	2,3	Type B	0	6	4
11	2,3	Type B	0	8	4
12 (Note1)	2,3	Type B	0	10	4
13 (Note1)	2,3	Type B	0	2	7
14 (Note1)	2	Type A	0	2	12
14 (Note1)	3	Type A	0	3	11
15	2,3	Type B	1	2	4
16	Reserved
Note1: If the PDSCH was scheduled with SI-RNTI in PDCCH Type0 common search space, the UE may assume that this PDSCH resource allocation is not applied

Default PDSCH time domain resource allocation C
Row index	*dmrs-TypeA-Position*	PDSCH mapping type	K₀	S	L
1 (Note1)	2,3	Type B	0	2	2
2	2,3	Type B	0	4	2
3	2,3	Type B	0	6	2
4	2,3	Type B	0	8	2
5	2,3	Type B	0	10	2
6	Reserved
7	Reserved
8	2,3	Type B	0	2	4
9	2,3	Type B	0	4	4
10	2,3	Type B	0	6	4
11	2,3	Type B	0	8	4
12	2,3	Type B	0	10	4
13 (Note1)	2,3	Type B	0	2	7
14 (Note1)	2	Type A	0	2	12
14 (Note1)	3	Type A	0	3	11
15 (Note1)	2,3	Type A	0	0	6
16 (Note1)	2,3	Type A	0	2	6
Note1: The UE may assume that this PDSCH resource allocation is not used, if the PDSCH was scheduled with SI-RNTI in PDCCH Type0 common search space

Reference: 3GPP TS 38.211, 38.212, 38.213, 38.214, and 38.331

5G NR: Time Domain – Slots and Slot Formats

2019-11-20T21:46:00.000+01:00

NR numerologies and frame structure are discussed in the post: 5G NR: Numerologies and FrameStructure. This post extends the discussion about NR time-domain frame/slot structure.

A numerology is defined by Sub Carrier Spacing (SCS) and Cyclic Prefix (CP). Irrespective of the numerology, a radio frame length is 10 ms and subframe length is 1 ms.

In LTE, a subframe is used as a minimum scheduling unit in time-domain while in NR, a slot is used as a dynamic scheduling unit. Additionally, NR supports transmission based on mini-slot (a fraction of a slot) as a minimum scheduling unit. So, it is very important to understand the slot structure and other details about slot-based scheduling etc.

Slots:

Slot Structure:

In NR, the number of OFDM symbols per slot are fixed (= 14 with normal CP and =12 with extended CP)

In LTE, the number of slots per subframe is fixed (= 2). But in NR, the number of slots per subframe varies with numerology (increases with SCS).

OFDM symbol duration reduces with increased SCS -> since the number of OFDM symbols per slot are fixed, slot duration reduces with increased SCS -> since slot duration reduces but subframe duration is fixed, more slots can fit within a subframe.

The following table compares time-domain parameters of LTE and NR for normal CP.

Parameter	LTE	NR
Radio frame length	10 ms	10 ms
Subframe length	1 ms	1 ms
No. of OFDM symbols in a slot	14	14
No. of slots in a subframe	2	Numerology dependent

The following table summarises number of slots in a subframe/frame for each numerology for normal CP.

µ	SCS	No. of slots per subframe = 2^µ	No. of slots per radio frame = 10 * 2^µ	slot duration (ms)
0	15 kHz	1	10	1
1	30 kHz	2	20	0.5
2	60 kHz	4	40	0.25
3	120 kHz	8	80	0.125
4	240 kHz	16	160	0.0625

The following figure illustrates the number of slots in a subframe and slot duration for each numerology for normal CP (click on the image to enlarge).

Slot Formats:

A slot can be classified as downlink (all symbols are dedicated for downlink) or uplink (all symbols are dedicated for uplink) or mixed uplink and downlink transmissions.

In the case of FDD, all symbols within a slot for a downlink carrier are used for downlink transmissions and all symbols within a slot for an uplink carrier are used for uplink transmissions.

TDD:

In TDD, it is possible that slot may not be configured to be fully used for downlink or for uplink. Similar to LTE TDD system, a guard period is necessary for transceiver switching from downlink to uplink and to allow timing advance in the uplink.

NR TDD uses flexible slot configuration. OFDM symbols in a slot can be classified as 'downlink', 'flexible', or 'uplink'. Flexible symbol can be configured either for uplink or for downlink transmissions.

One of intentions of the introduction of the flexible symbols within a slot are to handle the required guard period in NR TDD.

In LTE TDD, UL/DL configuration provided via SIB1 informs UEs that a subframe is used for uplink, downlink or as a special subframe. The configuration of special subframe is also provided via SIB1 which contains the guarding necessary for both timing advance and transceiver switching.

In NR, the configuration of slot format can be done in static, semi-static or fully dynamic fashion. This is discussed in the upcoming sections.

Slot Configuration and slot format determination:

Slot configuration procedure is thoroughly discussed in section 11.1 of 38.213.

NR supports the configuration of slot format in static, semi-static or fully dynamic fashion. Static and semi-static slot configuration is done using RRC while dynamic slot configuration is done using PDCCH DCI.

In TDD, for small/isolated cells, dynamic TDD is suitable to adapt to traffic variations, while for large cells, semi-static TDD may be more suitable for handling interference issues than fully dynamic TDD.

All the mechanisms used in NR to provide the UE with the required DL/UL transmission pattern are discussed in the subsequent sections. It is important to note that the network can combine some or all of the mechanisms discussed below to provide the UE with a desired DL/UL transmission pattern.

Note that if a slot configuration is not provided by the network, all the slots/symbols are considered as flexible by default.

Slot configuration via RRC consists of two parts. First part is configured by the IE tdd-UL-DL-ConfigurationCommon which provides all the UEs in the cell with cell-specific DL/UL pattern.

The second part is configured by the IE tdd-UL-DL-ConfigurationDedicated via dedicated RRC signalling. This UE specific configuration further modifies/allocates the unallocated (flexible) slots and symbols by tdd-UL-DL-ConfigurationCommon.

1a. Slot configuration using RRC (tdd-UL-DL-ConfigurationCommon):

The IE tdd-UL-DL-ConfigurationCommon is either broadcasted within SIB1 or configured to the UE using dedicated RRC signalling.

When provided via SIB1, this IE is optionally present for TDD cells. For FDD cells, this IE is not configured by the network.

When provided via dedicated RRC signalling, this IE is mandatory present upon SpCell change and upon serving cell (SCell with SSB or PSCell) addition. Otherwise, this IE is not configured by the network.

The structure of the IE tdd-UL-DL-ConfigurationCommon is given below.

*tdd-UL-DL-ConfigurationCommon*
referenceSubcarrierSpacing	ENUMERATED {kHz15, kHz30, kHz60, kHz120, kHz240, spare3, spare2, spare1}
*pattern1*	TDD-UL-DL-Pattern
*pattern2*	TDD-UL-DL-Pattern
*TDD-UL-DL-Pattern*
dl-UL-TransmissionPeriodicity	ENUMERATED {ms0p5, ms0p625, ms1, ms1p25, ms2, ms2p5, ms5, ms10}
nrofDownlinkSlots	INTEGER (0..320)
nrofDownlinkSymbols	INTEGER (0..13)
nrofUplinkSlots	INTEGER (0..320)
nrofUplinkSymbols	INTEGER (0..13)
dl-UL-TransmissionPeriodicity-v1530	ENUMERATED {ms3, ms4}

This IE configures the UE with at least one DL/UL pattern. pattern1 is mandatory and pattern2 is optional but by including pattern2, the network can have additional scheduling flexibility. Both pattern1 and pattern2 contain same parameters but usually of different values.

The procedure for determining DL/UL pattern depends upon whether or not pattern2 is configured within tdd-UL-DL-ConfigurationCommon.

Case1: only pattern1 is configured:

In this case a single DL/UL pattern is repeated periodically according to dl-UL-TransmissionPeriodicity. Steps to determine DL/UL pattern is given below;

Let P1 = dl-UL-TransmissionPeriodicity, d_slots,1 = nrofDownlinkSlots, u_slots,1 = nrofUplinkSlots, d_sym,1 = nrofDownlinkSymbols, and u_sym,1 = nrofUplinkSymbols;

1. Determine µ from referenceSubcarrierSpacing

2. Determine the total no. of slots (S1) within the slot configuration period (P1); S1 = P1 x 2^µ, for example, let P1 = 2.5 ms and µ = 3, in this case, there are 20 slots within the slot configuration period.

3. From total S1 slots reserve first d_slots,1 slots for downlink symbols and last u_slots,1 slots for uplink symbols.

4. Now, reserve first d_sym,1 symbols within the slot immediately following the last full downlink slot and last u_sym,1symbols in the slot preceding the first full uplink slot.

5. Consider the remaining symbols as flexible symbols. These flexible symbols can further be allocated to either downlink or uplink by making use of dedicated configuration which will be discussed in the next section.

No. of flexible symbols = (S1 - d_slots,1 - u_slots,1).14 - d_sym,1 - u_sym,1

Note: Periods are initialised such that, the first symbol every 20 ÷ P periods is a first symbol in an even numbered radio frame.

The following example illustrates how slots and symbols are distributed when only pattern1 is configured;

Case2: both pattern1 and pattern2 are configured:

In this case two DL/UL patterns (pattern1 and pattern2) are placed next to each other. These two concatenated patterns jointly repeat with periodicity given by dl-UL-TransmissionPeriodicity (from pattern1) + dl-UL-TransmissionPeriodicity (from pattern2).

Steps to determine DL/UL pattern is given below;

1. The UE first determines µ, S1, P1, d_slots,1,u_slots,1, d_sym,1, and u_sym,1 according to procedure defined in Case1.

2. Similarly, UE determines S2, P2, d_slots,2,u_slots,2, d_sym,2, and u_sym,2 from parameters given by pattern2.

3. Determine the total no. of slots (S) within the slot configuration period; S = S1+S2 = (P1+P2).2^µ, for example, let P1 = 2.5 ms, P2 = 2.5 ms and µ = 3, there are 40 slots within the configuration period.

4. During first S1 slots of total S slots, allocate slots/symbols by following steps 3, 4 and 5 from Case1 and using parameters from pattern1.

5. During last S2 slots of total S slots, allocate slots/symbols by following steps 3, 4 and 5 from Case1 and using parameters from pattern2.

Note1: Periods are initialised such that, the first symbol every 20 ÷ (P1+P2) periods is a first symbol in an even numbered radio frame. The network should configure P1 and P2 such that, P1 + P2 divides 20 ms.

The following example illustrates how slots and symbols are distributed when both pattern1 and pattern2 are configured, click on the image to enlarge the image;

1b. Slot configuration using RRC (tdd-UL-DL-ConfigurationDedicated):

As discussed in the previous section, by using cell-specific configuration (tdd-UL-DL-ConfigurationCommon), the network configures some slots/symbols as downlink, some as uplink and the rest as flexible.

The UE specific tweak to the slot configuration is necessary to help the network adjust DL/UL pattern based on the UE needs.

The network sends the UE-specific slot configuration using IE tdd-UL-DL-ConfigurationDedicated which further modifies/allocates the unallocated (flexible) slots and symbols.

The IE tdd-UL-DL- ConfigurationDedicated is optional and if the network doesn’t configure this IE, the UE uses tdd-UL-DL-ConfigurationCommon alone to derive the slot configuration.

The configuration in tdd-UL-DL- ConfigurationDedicated overrides only flexible symbols per slot over the number of slots as provided by tdd-UL-DL- ConfigurationCommon i.e., this dedicated configuration cannot change slots/symbols which are already allocated for downlink/uplink via tdd-UL-DL-ConfigurationCommon.

The contents of tdd-UL-DL- ConfigurationDedicated are presented below;

*tdd-UL-DL-ConfigurationDedicated*
slotSpecificConfigurationsToAddModList	List of 1 to 320 TDD-UL-DL-SlotConfig
slotSpecificConfigurationsToreleaseList	List of 1 to 320 TDD-UL-DL-SlotIndex
*TDD-UL-DL-SlotConfig*
slotIndex	INTEGER (0..319)
symbols
allDownlink	NULL
allUplink	NULL
explicit
nrofDownlinkSymbols	INTEGER (0..13)
nrofUplinkSymbols	INTEGER (0..13)

The tdd-UL-DL-ConfigurationDedicated provides individual slot configuration(s) using slotSpecificConfigurationsToAddModList. Each slot configuration contains the following;

slotIndex identifies a slot within a slot configuration period given in tdd-UL-DL-configurationCommon.

symbols structure provides the direction (downlink or uplink) for the symbols within the slot that is being configured.

- allDownlink indicates that all symbols in this slot are used for downlink;

- allUplink indicates that all symbols in this slot are used for uplink;

- explicit indicates explicitly how many symbols in the beginning and end of this slot are allocated to downlink and uplink, respectively.

- nrofDownlinkSymbols is the number of consecutive downlink symbols in the beginning of the slot identified by slotIndex.

- nrofUplinkSymbols is the number of consecutive uplink symbols in the end of the slot identified by slotIndex.

If nrofDownlinkSymbols is not provided, there are no downlink symbols in the slot and if nrofUplinkSymbols is not provided, there are no uplink symbols in the slot. The remaining symbols in the slot are flexible.

The following illustration shows how UE-specific slot configuration overrides flexible slots/symbols provided by the cell-specific configuration, click on the image to view it in full;

It is important to note that a symbol can only be flexible if and only if both UE- and cell-specific slot configurations indicate that the respective symbol to be flexible.

2. Dynamic slot configuration using group scheduling:

This mechanism is mainly intended for the devices that are not being currently scheduled; the devices that are being scheduled would receive the transmit/receive pattern via scheduling grants/assignments (discussed in next section).

As discussed already, the slot configuration using RRC is done in cell-specific and UE-specific manner. The resulting slot configuration may have some more flexible slots/symbols left unallocated.

By making use of layer1 signalling, the remaining (if any) flexible symbols can dynamically be reconfigured. PDCCH DCI format 2_0 whose CRC is scrambled with SFI-RNTI is used for this purpose. For more information on DCI formats, refer to DCI Formats in 5G NR.

DCI format 2_0 is designed to provide slot format indicator (SFI)(s) for a group of UEs. Multiple UEs in the group are allocated with same SFI-RNTI and hence all those UEs decode same PDCCH (DCI). Each UE extracts its own SFI based on the position of SFI within DCI (configured by RRC).

The SFI informs the UE(s) which are downlink, uplink, and flexible symbols.

The IE SlotFormatIndicator within PDCCH-ServingCellConfig provides the configuration of SFIs to a configured group of one or more UEs. The IE structure for SlotFormatIndicator is given below;

*SlotFormatIndicator*
sfi-RNTI	INTEGER (0..65535)
dci-PayloadSize	INTEGER (1..128)
slotFormatCombToAddModList	List of 1 to 16 SlotFormatCombinationsPerCell
slotFormatCombToReleaseList	List of 1 to 16 ServCellIndex
*SlotFormatCombinationsPerCell*
servingCellId	INTEGER (0..31)
subcarrierSpacing	ENUMERATED {kHz15, kHz30, kHz60, kHz120, kHz240, spare3, spare2, spare1}
subcarrierSpacing2
slotFormatCombinations	List of 1 to 512 SlotFormatCombination
positionInDCI	INTEGER (0..127)
*SlotFormatCombination*
slotFormatCombinationId	INTEGER (0..511)
slotFormats	List of 1 to 256 slot formats, each format can take INTEGER (0..255)

dci-PayloadSize informs the UE about the total length of the DCI payload scrambled with SFI-RNTI.

slotFormatCombToAddModList configures the UE with a list of SlotFormatCombinations, each of which for a different serving cell.

positionInDCI informs the UE about the (starting) position (bit) of the slotFormatCombinationId (SFI-Index) for the serving cell identified by servingCellId within the DCI payload.

servingCellId is the ID of the serving cell for which the slotFormatCombinations are applicable.

slotFormatCombinations configures the UE with a list with slot format combinations. Each SlotFormatCombination comprises of one or more SlotFormats.

- slotFormatCombinationId is used in the DCI payload to dynamically select the slot format combination.

- slotFormats provides slot formats that occur in consecutive slots in time domain order as listed in this field. Slot formats are explained below;

Slot Formats:

Release 15 version of 38.213 has defined 56 slot formats (Table 11.1.1-1) each of which is a predefined pattern of downlink/flexible/uplink symbols during one slot. The table is presented below for a quick reference.

Format

Symbol number in a slot

56 – 254

Reserved

255

UE determines the slot format for the slot based on tdd-UL-DL-ConfigurationCommon, or tdd-UL- DL-ConfigurationDedicated and, if any, on detected DCI formats

When slot format is set to 255, the UE should not use the above table to determine the slot format. Instead, the slot format is determined based on configuration given by tdd-UL-DL-ConfigurationCommon, or tdd-UL- DL-ConfigurationDedicated or from the received scheduling grants/assignments (discussed in the next section).

Additionally, this mechanism may also be used to override already configured periodic transmissions in uplink (SRS) or downlink (CSI-RS). For example, if the UE is configured to transmit SRS periodically, but the network wants to utilise one of the SRS symbols for downlink; in this case, the network simply sends SFI overriding uplink (allocated for SRS) with downlink.

- It is only possible to override a symbol which was configured to be flexible by RRC (cell- and UE-specific) as SFI can’t change any slots/symbols that are already configured to be uplink or downlink.

3. Slot configuration via dynamic scheduling:

In addition to the above discussed mechanisms, when the network is already scheduling a UE with scheduling grants/assignments, the network could dynamically inform the UE about transmit/receive pattern.

If the UE is not configured with SlotFormatIndicator and during the flexible symbols configured by DL-ConfigurationCommon and tdd-UL-DL-ConfigurationDedicated (if configured);

- the UE receives PDSCH or CSI-RS in the set of symbols of the slot if the UE receives a corresponding indication by a DCI format 1_0, DCI format 1_1, or DCI format 0_1.

- the UE transmits PUSCH, PUCCH, PRACH, or SRS in the set of symbols of the slot if the UE receives a corresponding indication by a DCI format 0_0, DCI format 0_1, DCI format 1_0, DCI format 1_1, or DCI format 2_3.

For more details on DCI formats, refer to DCIFormats in 5G NR.

Mini-slots:

In supporting low-latency applications such as URLLC, time-domain scheduling plays a significant role. There are two ways to support low-latency transmissions w.r.t time-domain scheduling. One way is to dynamically change the SCS/slot duration which itself involves some delay. Another way is only to use only part of a slot i.e., by using as may number of OFDM symbols as necessary to send/receive the data.

NR supports transmissions over a fraction of a slot which is known as mini-slot. For a very low latency transmissions, mini-slots avoid the need to wait until the slot boundary.

With low SCS configurations, the slot duration is high and hence using a fraction of a slot provides significant advantage compared to full slot in low latency scenarios. For example, when using SCS of 15 kHz, the slot duration is 1 ms whereas a mini-slot occupying 2 symbols would last for ≈143 µs.

Mini-slot concept is also advantageous when operating in FR2; As the available bandwidth can be too large in FR2, even few OFDM symbols over a large bandwidth can deliver high amount of data. In other words, allocating full slot over a large bandwidth is unnecessary if the data to be transmitted is not that large.

Another use case of mini-slot based transmission is when operating in unlicensed spectrum wherein, after the successful LBT (listen-before-talk) procedure, the transmission can start as soon as possible without needing to wait until the slot boundary.

A mini-slot length can be 2, 4, or 7 OFDM symbols. A mini-slot contains DM-RS at position(s) relative to the start of the mini-slot.

Note that some UEs targeting certain use cases may not support all mini-slot lengths and all starting positions within a slot.

The figure below illustrates an example time-domain structure for normal CP.

Reference: 3GPP TS 38.211, 38.212, 38.213, 38.214, 38.331, and TR 38.912

*UE-NR-Capability -> rf-Parameters -> BandNR*
. . .
*rateMatchingLTE-CRS*	ENUMERATED {supported}
. . .

*FeatureSetDownlink-v1540*
. . .
*additionalDMRS-DL-Alt*	ENUMERATED {supported}
. . .

*lte-CRS-ToMatchAround = RateMatchPatternLTE-CRS*
carrierFreqDL	INTEGER (0..16383)
carrierBandwidthDL	ENUMERATED {n6, n15, n25, n50, n75, n100, spare2, spare1}
mbsfn-SubframeConfigList	EUTRA-MBSFN-SubframeConfigList
nrofCRS-Ports	ENUMERATED {n1, n2, n4}
v-Shift	ENUMERATED {n0, n1, n2, n3, n4, n5}

*ServingCellConfigCommon or ServingCellConfigCommonSIB*
. . .
*frequencyShift7p5khz*	ENUMERATED {true}
. . .

*ServingCellConfigCommon or ServingCellConfigCommonSIB*
. . .
*n-TimingAdvanceOffset*	ENUMERATED {n0, n25600, n39936}
. . .