19 Radio Features

21.9163GPPRelease 16Release descriptionTS

19.1 NR-related Release 16 Features

19.1.1 NR-based access to unlicensed spectrum

820067

NR-based access to unlicensed spectrum

NR_unlic

R1

RP-191575

Qualcomm

750045

Study on NR-based access to unlicensed spectrum

FS_NR_unlic

R1

RP-181339

Qualcomm

820167

Core part: NR-based access to unlicensed spectrum

NR_unlic-Core

R1

RP-190706

Qualcomm

820267

Perf. part: NR-based access to unlicensed spectrum

NR_unlic-Perf

R4

RP-190706

Qualcomm

Summary based on the input provided by Qualcomm in RP-202753 (previous version in RP-201840)

This work item specifies NR enhancements for a single global solution framework for access to unlicensed spectrum which enables operation of NR in the 5GHz and the 6GHz (e.g., US 5925 – 7125 MHz, or European 5925 – 6425 MHz, or parts thereof) unlicensed bands taking into account regional regulatory requirements and reusing features of NR as much as possible.

This work item supports NR Radio Access operating with shared spectrum channel access to operate in different modes where either PCell, PSCell, or SCells can be in shared spectrum and an SCell may or may not be configured with uplink. The applicable deployment scenarios are described in the following.

– Scenario A: Carrier aggregation between NR in licensed spectrum (PCell) and NR in shared spectrum (SCell);

o A.1: SCell is not configured with UL (DL only); A.2: SCell is configured with UL (DL+UL).

– Scenario B: Dual connectivity between LTE in licensed spectrum and NR in shared spectrum (PSCell);

– Scenario C: NR in shared spectrum (PCell);

– Scenario D: NR cell in shared spectrum and uplink in licensed spectrum;

– Scenario E: Dual connectivity between NR in licensed spectrum (PCell) and NR in shared spectrum (PSCell)

Physical Layer Signals and Channels

Initial access signals and channels: For PRACH, to support larger PRACH transmission power under PSD limitation and/or to meet OCB requirement, longer PRACH sequences of length 1151 and 517 are introduced, applicable to 15kHz SCS and 30kHz SCS, respectively. Legacy length 839 PRACH sequence is not supported in a cell with shared spectrum channel access.

DL signals and channels: DCI 2_0 is enhanced to provide time and frequency domain Channel Occupancy Time (COT) structure. For time domain COT, remaining COT duration can be included in DCI 2_0. If COT duration field is not configured, the UE can derive the remaining COT duration from SFI field included in DCI 2_0. For frequency domain COT, a bitmap for available RB sets can be included in DCI 2_0 to indicate if an RB set is included in the current COT.

Search space set group switching feature is also introduced, such that the UE can be dynamically controlled to perform PDCCH monitoring from two groups of search spaces sets. The search space set group switching can be triggered by explicit bit in DCI 2_0, a PDCCH decoding event in one of the groups, and a timer expiration.

In Rel-15, only length of 2, 4 and 7 OFDM symbols is supported with PDSCH mapping type B with. Additional lengths (i.e. 2-13 symbols) as well as corresponding additional DMRS positions are specified for unlicensed band operation. The feature is also specified for licensed operation.

In order to facilitate UE monitoring PDCCH on multiple RB sets while not significantly increasing RRC signalling overhead, a search space can be configured with multiple monitoring locations in frequency domain. The configuration of CORESET is replicated on the RB sets where these monitoring locations are located.

UL signals and channels: For PUCCH and PUSCH, PRB interlace structure is introduced to meet OCB requirement and boost transmit power under PSD limitation. For 30KHz SCS, M=5 interlaces are defined. For 15KHz SCS, M=10 interlaces are defined.. The interlaces are defined with respect to point A, and one interlace is formed by set of resource blocks M RBs apart.

For PUCCH, Rel.15 NR PUCCH format 0/1/2/3 are extended to PRB interlace waveform similar to PUSCH, but constrained within one RB set. PUCCH format 0/1 in Rel.15 is single RB only, and in Rel.16, they are extended to one interlace with 10 or 11 RBs. PUCCH format 2/3 in Rel.15 are already multiple RBs but in continuous RBs up to 16 RBs. In Rel.16, they are extended to occupy one or two interlaces. If one interlace is used, frequency domain OCC and pre-DFT OCC are introduced for PUCCH format 2 and 3 respectively to improve the multiplexing capacity.

In Rel-15, SRS is restricted to the last 6 symbols in a slot. In Rel-16, UE is able to be configured with SRS transmission on every OFDM symbols in a slot for unlicensed band operation. The feature is also specified for licensed operation.

gNB can schedule multiple contiguous PUSCH(s) by a single DCI format 0_1.

Physical Layer Procedures

Channel access procedures: Rel.16 NR-U supports two channel access operation modes: dynamic channel access mode (corresponds to Load Based Equipment in [1]) and semi-static channel access mode (corresponds to Frame Based Equipment in [1]).

When operating on a wideband (i.e. >20MHz) carrier, clear channel assessment (CCA) is performed in the unit of 20MHz or 10MHz depends on regulation requirements.

For dynamic channel access mode, the following LBT mechanisms are defined:

– Cat 4 LBT with a contention window (Type 1);

– Cat 2 LBT within a 25 µs sensing interval (Type 2A); Cat 2 LBT within a 16 µs gap (Type 2B)

– Cat 1 LBT with a gap of no more than 16 µs without channel sensing (Type 2C)

Both gNB and UE can acquire a COT with Cat 4 LBT, while a gNB or UE can share the COT acquired by the other node with Cat 2 or Cat 1 LBT under different conditions. The only exception is the transmission of discovery RS, which includes the transmission of SSBs and other non-unicast control and data, where under some restriction, Type 2A LTE can be used to acquire the COT.

For semi-static channel access, in Rel.16 NR-U, only gNB can contend for a channel as a fixed frame period boundary and a UE can share the gNB COT for transmission if gNB DL transmission is detected in an earlier part of the same COT.

Enhancements to initial access procedures: Discovery RS is a concept introduced for NR-U to deliver critical information including PSS/SSS/PBCH blocks (SSB) and critical system information including System Information Block 1 (SIB1). In NR, for sub-7GHz bands, up to 8 SSBs can be transmitted every 20ms to support beam sweeping with different SSB positions. There is no quasi-colocation (QCL) relationship across up to 8 SSBs within one cycle, but SSBs at the same position in different cycles are assumed to be QCL’ed.

For unlicensed band operation, transmissions are subject to LBT. Hence, there is a chance that SSBs cannot be transmitted due to LBT failure. There are two enhancements introduced to support a more reliable delivery of critical system information:

– Type 2A LBT can be used to start the DRS transmission if the duty cycle of the DRS is no larger than 1/20 and the length of the DRS is no longer than 1ms

– Up to 20 and 10 candidate SSB positions in a half frame are supported for 30kHz SCS and 15kHz SCS, respectively, to allow more transmission opportunities than Rel-15. SSBs on the candidate SSB positions with same SSB index are regarded as QCLed.

The RSSI measurement bandwidth is 20MHz regardless of the carrier bandwidth.

HARQ enhancements: For operation in unlicensed band, a major issue with HARQ operation is scheduled ACK/NACK transmission may not happen due to LBT failure. In licensed operation, ACK/NACK transmission failure issue is not severe. If ACK/NACK is not received by the gNB, there is no mechanism to retransmit the ACK/NACK. This was acceptable for Rel-15 since the probability for gNB failing to decode ACK/NACK is small and the gNB can schedule a retransmission of PDSCH to collect ACK/NACK. For unlicensed band operation, since the channel is shared with other nodes, the transmission of PUCCH or PUSCH carrying ACK/NACK is not guaranteed, and the probability that the UE failed ACK/NACK transmission cannot be ignored anymore. To solve this problem, three features have been designed:

– Non-numerical K1 indication for ACK/NACK transmission timing

– Enhanced (Type 2) dynamic codebook for HARQ ACK

– One-shot (Type 3) codebook for HARQ ACK

The non-numerical K1 feature is introduced, such that the gNB does not provide a time to report ACK/NACK when scheduling the PDSCH. Instead a special non-numerical K1 is indicated in the DL grant scheduling the PDSCH. The UE will hold on to the ACK/NACK corresponds to the PDSCH, and report ACK/NACK when a later PDSCH is scheduled with another DL grant with proper K1 timing indicated.

The other two HARQ enhancement features are introduced to support UE ACK/NACK re-transmissions. For enhanced dynamic codebook design, HARQ ACK group is introduced. Within an HARQ ACK group, the already scheduled ACK/NACK (transmitted or failed to transmit) can be triggered to be retransmitted. Rel.16 NR-U also defines a type-3 HARQ ACK codebook. In this codebook design, gNB can trigger the report of ACK/NACK for all configured HARQ processes over all cells by setting a bit in -the DCI.

Configured grant enhancement: Rel.16 NR-U enhanced Configured grant UL transmission by allowing the UE to performing retransmission of a TB in a CG-PUSCH resource. A CG-UCI is included to indicate the HARQ process ID, NDI and RVID of the transmission. UE can acquire a COT with Cat 4 LBT for CG-UL transmission and share the COT with gNB for DL transmissions. The COT sharing information is also carried in CG-UCI. When CG is configured, gNB can feedback HARQ-ACK for UL transmission by CG-DFI. When the UE is configured with repK > 1, repetition of a TB is mapped within a configuration in the case when an UE is configured with multiple active configurations, the UE repeats the TB in the earliest consecutive transmission occasion candidates within the same configuration instead of consecutive slots, the UE terminates the repetitions if an explicit feedback indicating ACK in the DFI is received for the HARQ process.

Wideband operation: The concept of “RB set” is introduced which approximately corresponds to one 20MHz channel. For PUSCH, the resource allocation is defined by continuous RB sets and the set of interlaces. The RB sets are defined by RRC configuring the intra-cell guard band between RB sets. If the intra-cell guard band is not configured, the default values for intra-cell guard band from RAN4 will be applied. It is also possible to configure the intra-cell guard band to be 0.

In a DL BWP with bandwidth larger than 20MHz, gNB may transmit DL channels and signals when LBT is successful on a subset of RB sets (either contiguous or non-contiguous) in the BWP. In a UL BWP with bandwidth larger than 20MHz, UE is allowed to transmit UL channel and signals only if LBT is successful on all RB sets where UL transmission is scheduled/configured and non-zero intra-cell guard is applied in between.

MAC Enhancements

At the Medium Access Control (MAC) layer, several features were introduced to alleviate the impact of LBT mechanism on MAC procedures. The main ones are: Consistent LBT failure detection and recovery; Changes to RACH procedures; Configured Grant (CG) changes.

A new mechanism to detect and recover from consistent UL LBT failures was introduced. The detection is per Bandwidth Part (BWP) and based on all uplink transmissions within this BWP. Similar to BFD, a timer is re-started with every LBT failure indication from physical layer to MAC; a counter is incremented with every LBT failure and is reset when the timer expires. When the counter exceeds a configured threshold, consistent UL LBT failure is declared on this BWP.

For failures on SCells, the UE reports this to the corresponding gNB (MN for MCG, SN for SCG) via a MAC CE. For SpCell (PCell or PSCell), when consistent uplink LBT failures are detected, the UE switches to another UL BWP with configured RACH resources on that cell, initiates RACH, and reports the failure via MAC CE. If failures happen on all such BWPs, SCG failure for PSCell and RLF for PCell is declared.

If msg1 in 4-step RACH or msgA preamble in 2-step RACH is not transmitted due to LBT failure, the UE does not increment the power of the next attempt. If the UE is configured with the above LBT failure detection/recovery, it also does not increment the transmission counter; in this case, the failure of RACH procedure is handled by the LBT failure detection/recovery.

The LBT failure for transmission of msg2 in 4-step RACH and msgB in 2-step RACH necessitated longer monitoring windows at the UE to receive these messages. The maximum window duration was increased from 10ms in Rel-15 to 40ms. However, this change caused possible ambiguity of determining the correct initial transmission for which the response was intended. To solve this, the gNB signals the last two-bits of SFN corresponding to msg1 transmission time for msg1 or msgA preamble in the corresponding response message.

The changes to configured grant transmission are mainly due to autonomous retransmission on CG resources, autonomous HARQ process ID and RV selection, and LBT failures. A new CG retransmission timer was introduced where the UE is allowed to retransmit a packet on a CG after this timer expires without any ACK from the gNB for the earlier transmission. The UE always prioritizes ongoing retransmissions over new transmissions. Since the UE signals HARQ ID and RV on CG transmissions, their selection is left to the UE implementation. Multiple CGs on a BWP are allowed where they all can use the above retransmission feature and can also share the same HARQ ID pool.

For uplink multi-TTI transmission, the UE is allowed to select a HARQ process and RV to transmit a generated packet to handle the scenario when the LBT fails for the initial TTI occasions. To support transmission of DL HARQ feedback during DRX operation, if the UE receives a non-numerical K1 where the actual DCI for HARQ feedback will be coming later, monitoring of downlink control channel was extended in time.

Upper Layer Enhancements

For Connected mode mobility, the only change for NR-U is the support of RSSI and Channel Occupancy (CO) measurements similar to LTE-LAA. These can be reported periodically or along with other measurement reports.

For Idle/Inactive mode mobility, the rules for checking other cells for reselection were relaxed to handle the cases when best cell on a frequency belongs to a different PLMN. To further help the UE consider only the cells of the home or equivalent PLMN in reselection, a “white-list” of such neighbor cells is broadcasted.

In Rel-15 NR, the UE has a single Paging Occasion (PO) for every DRX cycle in Idle/Inactive mode. Since LBT may fail during a paging transmission attempt, multiple PDCCH monitoring occasions were introduced for NR-U. This allows the gNB to transmit the paging message when LBT is not successful at the first instance. As monitoring of multiple occasions increases UE power, gNB can let the UE stop further monitoring when there is no page for that UE by transmitting a Short Message on paging channel with a newly introduced bit for this purpose. The UE can also stop monitoring when it detects a paging for other UEs with the assumption that the gNB had access to the channel and thus there is no page for itself.

Channel Access Priority Class (CAPC) can be configured for each data radio bearer (DRB) and SRB2. The signaling bearers (except for SRB2) always use the highest priority CAPC. The gNB assigns the CAPC by taking into account the specified mapping between 5QI (QoS indicator) of QoS flows in a DRB. The UE uses this configuration to determine the CAPC when not signaled by the gNB directly via DCI. This applies to all CG transmissions and some dynamic grants. When signaling data is transmitted, CAPC of the PDU is same as the CAPC of the highest priority signaling bearer. In all other cases, the lowest priority CAPC among the multiplexed data flows is chosen for the CAPC of the PDU

Targeted spectrum

Two bands have been considered and defined in relation to this work item:

NR operating band

Uplink (UL) operating band
BS receive / UE transmit

FUL_low– FUL_high

Downlink (DL) operating band
BS transmit / UE receive

FDL_low– FDL_high

Duplex Mode

n46

5150 MHz – 5925 MHz

5150 MHz – 5925 MHz

TDD13

n9614

5925 MHz – 7125 MHz

5925 MHz – 7125 MHz

TDD13

NOTE 1: This band is restricted to operation with shared spectrum channel access as defined in TS 37.213.

NOTE 2: This band is applicable in the USA only subject to FCC Report and Order [FCC 20-51]

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820067,750045,820167,820267

[1] RP-192926, Revised WID on NR-based Access to Unlicensed Spectrum

[2] RP-202751, Status report for WI on NR-based Access to Unlicensed Spectrum

19.1.2 2-step RACH for NR

820068

2-step RACH for NR

NR_2step_RACH

R1

RP-190711

ZTE

820168

Core part: 2-step RACH for NR

NR_2step_RACH-Core

R1

RP-190711

ZTE

820268

Perf. part: 2-step RACH for NR

NR_2step_RACH-Perf

R4

RP-190711

ZTE

Summary based on the input provided by ZTE Corporation in RP-200087 revised to RP-200623 revised to RP-201225.

The Rel-16 Work Item 2-step RACH for NR achieves the following objectives:

– A simplified random access procedure was developed. This reduces the number of interactions between the UE and network during the connection setup and connection resume, thereby enabling a lower control plane latency. In case of connected mode, a small amount of data can be sent via 2-step RACH procedure thus also enabling a lower latency for UL UP data for connected mode UEs.

– Channel structure of transmitting PRACH and PUSCH in one step (i.e. without an intermediate message from the network) was developed. The PRACH and PUSCH are separated by a pre-configured guard period.

– The above enhancements are applicable to both licensed spectrum and shared spectrum (i.e. NR-U).

The general procedure of 4-step RACH and 2-step RACH are depicted in Figure 1. The first step of 2-step RACH comprises an UL MSGA transmission which includes the equivalent contents of msg1 and msg3 of 4-step RACH. The second step of 2-step RACH is a DL MSGB reception which includes the equivalent content of msg2 and/or msg4 of 4-step RACH, depending on the detection of UL MSGA.

(a) 4-step RACH (b) 2-step RACH

Figure 1 General procedure of 4-step RACH and 2-step RACH

RA type selection

For contention based random access (CBRA), all the triggers for Rel-15 NR 4-step RACH are also applicable to 2-step RACH except when CA is configured, the 2-step RACH is only applicable on PCell. Contention free random access (CFRA) procedure with 2-step RACH is only supported for handover.

The UE selects the type of random access at initiation of the random access procedure based on network configuration:

– when CFRA resources are not configured, an RSRP threshold is used by the UE to select between 2-step RA type and 4-step RA type;

– when CFRA resources for 4-step RA type are configured, 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.

In case of random access in a cell configured with SUL, UE performs carrier selection (between SUL and NUL) before selecting between 2-step and 4-step RA type.

MSGA structure: PRACH

The MSGA in 2-step RACH comprise a PRACH and a PUSCH. The PRACH resources for 2-step RACH in time/frequency domain can be either shared with 4-step RACH or can be configured to be separate. All the preamble formats and the PRACH configuration indexes defined in Rel-15 and in Rel-16 NR-U and TEI can be used. In case of shared time domain PRACH resources between 4-step RACH and 2-step RACH, different preambles are allocated to differentiate the RA types. The mapping between SSB and PRACH occasion reuses that for 4-step RACH.

MSGA structure: PUSCH

2-step RACH uses a specified mapping rule to determine the PUSCH resource of MSGA that is associated with the selected PRACH resource. Each PRACH slot is mapped to a number of PUSCH occasions with associated DMRS resource, once the UE selects a preamble in a PRACH occasion, the corresponding PUSCH occasion and DMRS resource can be determined by a predefined mapping order.

MSGB

After MSGA transmission, the UE monitors the downlink for a response from the network within a configured window. This response from the network is called the MSGB. The contents of MSGB depend on whether or not the gNB is able to successfully detect both the PRACH and the PUSCH parts.

– If the PRACH is detected but the decoding of PUSCH fails, network will include a fallback indication in MSGB and the subsequent UE procedure will be similar to that for a UE monitoring msg2 in the 4 step RACH.

– If both preamble and PUSCH are decoded, network will include a successRAR and reception of this at the UE completes the contention resolution. HARQ feedback is enabled for the successful reception of the successRAR.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820068,820168,820268

[1] RP-200085, Revised WID on 2 step RACH for NR

[2] RP-200622, Status report for WI – NR 2-step RACH

19.1.3 UE Power Saving in NR

830075

UE Power Saving in NR

NR_UE_pow_sav

R1

RP-191607

CATT

800094

Study on UE power saving in NR

FS_NR_UE_pow_sav

R1

RP-181463

CATT

830175

Core part: UE Power Saving in NR

NR_UE_pow_sav-Core

R1

RP-190727

CATT

830275

Perf. part: UE Power Saving in NR

NR_UE_pow_sav-Perf

R4

RP-190727

CATT

Summary based on the input provided by CATT in RP-200912.

UE battery life is an important aspect of the user’s experience.The RAN1 study of the Rel-16 UE power saving had shown substantial power saving gain comparing to considered Rel-15 NR features such as DRX operation, with UE adaptation in frequency domain, time domain, antenna domain, tight control of DRX operations, and reducing PDCCH monitoring with different traffic types.

The work item of UE power saving in NR includes the power saving techniques, such as DRX adaptation, cross-slot scheduling, and maximum MIMO layer adaptation in CONNECTED state, fast transition out of CONNECTED state, and reduced RRM measurements in idle/inactive states. The UE assistance information is part of the work to enable the UE to feedback its preferred configuration to achieve desired power saving.

The UE power saving work in Rel-16 focuses on the power saving techniques in CONNECTED state, which includes DRX adaptation, cross-slot scheduling, maximum MIMO layer adaptation, and fast transition out of CONNECTED state. The RRM measurement reductions are the power saving techniques specified in idle/inactive states.UE assistance information is supported for the UE to feedback its preferred configuration of the specific power saving technique.

Power Saving Techniques in CONNECTED state

The power saving techniques are dynamically triggered by L1 signaling indicated from PDCCH-based power saving signal/channel or semi-statically configured by RRC signaling.The PDCCH-based power saving signal/channel reuses the existing PDCCH search space and CORESET configurations with dynamic TCI states with DCI field indicating the adaptation to achieve UE power saving, such as UE wakeup in the DRX operation, cross-slot scheduling, and maximum MIMO layer adaptation through BWP switching.

– DRX adaptation

The DRX adaptation power saving technique is to configure the PDCCH-based power saving signal/channel at the active BWP before the beginning of DRX ON for UE monitoring with the indication of UE wakeup or not depending on whether there is data for UE to receive. A new DCI format 2_6 is introduced with CRC scrambled by PS-RNTI (DCP) which contains the wakeup indication as well as SCell dormancy indication if configured.A PS-offset is semi-statically configured before DRX ON defining the start of the interval for the DCP monitor occasion as shown in Figure 1.More than one monitoring occasions could be configured for DCP on PCell for CA and SpCell for DC based on the search space and CORESET configurations.Minimum time gap is specified as the UE processing time as shown in Figure 1. UE is not required to monitor DCP at the interval of minimum time gap and within Active Time.

Figure : DCP Monitoring occasion for DRX adaptation

When DCP monitoring occasion collides with other procedures with higher priority in PDCCH monitoring, the monitoring occasion is considered invalid.UE follows legacy behavior when all the configured monitoring occasions are invalid.UE is configured by RRC to wake up or not when no DCP is detected with valid monitoring occasions.One DCP can be configured to control PDCCH monitoring during on-duration for one or more UEs independently. UE is also configured by RRC whether to report periodic L1-RSRP or periodic CSI/L1-SINR when UE is not indicated to wake up at the DRX ON.

– Cross slot scheduling

Power saving technique with cross-slot scheduling facilitates UE to achieve power saving with the assumption that it won’t be scheduled to receive PDSCH, triggered to receive A-CSI or transmit a PUSCH at the scheduling slot within Active Time. A 1-bit minimum scheduling offset in DCI format 1_1 and 0_1 enables dynamic switching of DL and UL minimum scheduling offset values.

– Maximum MIMO Layer Adaptation

UE power saving techniques with the adaptation to the DL maximum number of MIMO layers could be achieved by dynamic switching of BWPs, which the DL maximum number of MIMO layers are configured to be different.

– Fast transition out of CONNECTED state

UE can feed back the assistance information of its preference to be released/suspended for gNB to get UE transitioning out of CONNECTED state quickly when there is no further data arrival.

Power Saving Techniques in idle/inactive state

– Reduced RRM measurements in idle/inactive state

Power saving in RRC_IDLE and RRC_INACTIVE can also be achieved by UE relaxing neighbour cells RRM measurements when it meets the criteria determining it is in low mobility and/or not at cell edge.

UE assistance information

UE assistance information allows the UE to feedback its preferred configuration, such as c-DRX configuration, aggregated bandwidth, SCell configuration, MIMO configuration, RRC state, minimum scheduling offset values in order for network to assist UE achieving power saving gain.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830075,800094,830175,830275

[1] RP-200494, “WID: UE power saving in NR”, CATT, CAICT

[2] TR 38.840 v15.0.0. CATT

[3] R1-1913657, 38.202CR0014 Introduction of UE power savings, Qualcomm

[4] R1-1913658, 38.212CR0028Introduction of UE power savings in 38.212, Huawei

[5] R1-1913659, 38.213CR0076 Introduction of UE power savings, Samsung

[6] R1-1913660, 38.214CR0056 Introduction of UE power savings, Nokia

[7] R2-2002369, 38.300 CR0193 Introduction of UE Power Saving in NR, CATT

[8] R2-2005949, 38.304 CR 0158, CR on 38.304 for UE Power saving in NR, vivo

[9] R2-2005869, 38.321CR0719 MAC CR for Rel-16 UE power savings, Huawei, HiSilicon, Nokia, Nokia Shanghai Bell

[10] R2-2004943, 38.331 CR1540 CR for 38.331 for power savings. MediaTek

[11] R2-2004944, 36.331 CR4245 CR for 36.331 for power savings, MediaTek

[12] R2-2005856, 38.306CR0134 UE capabilities for Rel-16 Power Saving WI, Intel

[13] R2-2005857, 38.331CR1618 UE capabilities for Rel-16 Power Saving WI, Intel

[14] R2-2005866, 37.340CR0189 SRB3 for reporting UAI for power saving, OPPO, MediaTek

[15] R4-2009133 38.133CR0854 Measurement requirements for UEs under power saving mode Ericsson

[16] R4-2009244 38.133CR0635 CR on minimum requirement at transition period for UE power saving CATT

[17] R4-200744038.133 CR0736 CR for maximum MIMO layer adaptation vivo, CATT

19.1.4 Integrated access and backhaul for NR

820070

Integrated access and backhaul for NR

NR_IAB

 

RP-191558

Qualcomm

750047

Study onNR_IAB

FS_NR_IAB

R2

RP-181349

Qualcomm

820170

Core part: NR_IAB

NR_IAB-Core

R2

RP-190712

Qualcomm

820270

Perf. Part: NR_IAB

NR_IAB-Perf

R4

RP-190712

Qualcomm

830021

Study on Security for NR_IAB

FS_NR_IAB_Sec

S3

SP-190106

Rajavelsamy Rajadurai, Samsung,

Summary based on the input provided by Qualcomm Incorporated in RP-201757.

This Feature introduces wireless relaying among RAN nodes to 5G. Its objectives closely followed the recommendation of the study item on IAB for NR, which are defined in TR 38.874. The following features are supported:

• Multi-hop backhauling for flexible range extension for both FR1 and FR2.

• Topology adaptation including redundant connectivity to optimize backhauling performance and to respond to backhaul (BH) link failure.

• Mapping of UE bearers to backhaul RLC channels and QoS enforcement over backhaul RLC channels to meet E2E QoS requirements.

• Scalability to a large number of UEs.

• Flexible deployment allowing IAB-node operation in EN-DC mode with EPC or in SA-mode with 5GC.

• Support for NR-NR DC from the UE and IAB-node perspective (see NOTE 1)

• Efficient operation for both inband and out-of-band relaying.

• Over the air (OTA) synchronization across IAB topology.

• Support of Rel-15 UEs.

IAB architecture

IAB introduces the IAB-node and IAB-donor to 5G RAN. The IAB-node is the relaying node and supports access and backhauling via NR. The IAB-donor is the terminating node of NR backhauling on network side. It represents a gNB with additional functionality to support IAB. Backhauling can occur via a single hop or via multiple hops.

The IAB-node supports gNB-DU functionality to terminate the NR access interface to UEs and next-hop IAB-nodes, and to terminate the F1 protocol to the gNB-CU functionality on the IAB-donor. The gNB-DU functionality on the IAB-node is also referred to as IAB-DU.

In addition to the gNB-DU functionality, the IAB-node also supports a subset of the UE functionality referred to as IAB-MT, which includes, e.g., physical layer, layer-2, RRC and NAS functionality to connect to the gNB-DU of another IAB-node or the IAB-donor, to connect to the gNB-CU on the IAB-donor, and to the core network.

The IAB-MT can access the network using either SA mode or EN-DC. In EN-DC, the IAB-MT connects via E-UTRA to a MeNB, and the IAB-donor terminates X2-C as SgNB.

All IAB-nodes that are connected to an IAB-donor via one or multiple hops form a directed acyclic graph (DAG) topology with the IAB-donor as its root. In this DAG topology, the neighbour node of the IAB-DU or the IAB-donor-DU is referred to as child node and the neighbour node of the IAB-MT is referred to as parent node. The direction toward the child node is referred to as downstream while the direction toward the parent node is referred to as upstream. The IAB-donor performs centralized resource-, topology- and route management for the IAB topology.

Backhaul transport

The F1 interface between IAB-DU and IAB-donor-CU uses the protocol stack and security protection defined in Rel-15.

On the wireless backhaul, the Backhaul Adaptation Protocol (BAP) has been introduced, which is a L2 sub-layer that carries the IP layer for the F1 interface and enables routing over multiple hops. The IP layer can also be used for non-F1 traffic, such as OAM traffic.

On each backhaul link, the BAP PDUs are carried by BH RLC channels. Multiple BH RLC channels can be configured on each BH link to allow traffic prioritization and QoS enforcement. To support a large quantity of BH RLC channels on each BH link, e.g., for fine-granular QoS support, an extended logical channel ID (eLCID) has been introduced.

The IAB-MT further establishes SRBs (carrying RRC and NAS) with the IAB-donor-CU. For IAB-nodes operating in ENDC, the IAB-MT also establishes one or more DRBs with the IAB-donor-CU, which can be used, e.g., to carry OAM traffic. These SRBs and DRBs are transported between the IAB-MT and its parent node over Uu access channel(s).

On the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header. The BAP routing ID consists of BAP address and BAP path ID, where the BAP address indicates the destination node of the packet on the BAP sublayer, and the BAP path ID indicates the routing path the packet should follow to this destination.

The BAP sublayer further supports flow control in downstream direction, where the IAB-node sends feedback information on available buffer size to its parent node.

To reduce UL scheduling latency over multiple hops, the Pre-emptive BSR MAC CE has been introduced, which can be sent by the IAB-node to its parent-node based on expected rather than the buffered data.

For IAB-nodes using ENDC, backhauling is only supported via the NR link.

IAB-node integration

A network integration procedure was defined for IAB-nodes. For IAB-nodes using SA mode, this procedure consists of three phases.

In phase 1, the IAB-MT selects a suitable parent node and connects to the network in the same manor as a UE including RRC connection setup with IAB-donor-CU, authentication with the core network, context management and bearer establishment. Prior to connection establishment, The IAB-MT determines if a parent node supports IAB based on an the IAB-support indicator broadcast in SIB1. The IAB-MT further indicates IAB capability to the network during the RRC connection setup. The IAB-donor-CU forwards this indicator to the core network which authorizes IAB operation in return.

In phase 2, the IAB-donor-CU configures BH RLC channels and the BAP sublayer to enable transport of the backhaul to the new IAB-node. Further, IP addresses can be allocated by RAN or OAM. These IP addresses are used by the IAB-DU for backhauling of F1 traffic.

In phase 3, the IAB-DU is established using the Rel-15 F1 setup procedure. The IAB-node includes the BAP address it obtained via RRC in phase 2 into F1-C to indicate collocation of IAB-MT and IAB-DU to the IAB-donor-CU.

The network integration for IAB-nodes using ENDC uses a similar procedure. In phase 1, the IAB-node first connects to an eNB, which selects and adds the IAB-donor as a SN.

Topology adaptation

The following procedures have been defined to allow the IAB network to dynamically change its topology under operation:

IAB-node migration procedure: This procedure allows the IAB-node to change its parent node underneath the same IAB-donor. The procedure is initiated by the IAB-donor-CU. It leverages handover for the IAB-MT using SA mode and the SN-change procedure for the IAB-MT using ENDC. The IAB-donor further configures BH RLC channels and updates the BAP sublayer so that backhauling can occur via the target path. F1 may be migrated to the new IP addresses that have been allocated to the IAB-DU, if any.

Topological redundancy procedure: This procedure enables the establishment and release of redundant paths in the IAB-topology underneath the same IAB-donor-CU. The procedure is initiated by the IAB-donor-CU. It leverages SN-addition for the IAB-MT using SA mode. The IAB-donor further configures BH RLC channels and updates the BAP sublayer so that backhauling can also occur over the SCG link. The IAB-donor can further configure multiple different routes on the BAP sublayer. This route redundancy may be used for IP multi-homing of F1-C to provide robustness. It may further be used for load balancing, where F1-U GTP tunnels are assigned to separate routes. The routes are configured by the IAB-donor-CU. For IAB-MT using ENDC, user plane traffic can only be exchanged via NR. F1-C, however, can be routed via NR and/or via LTE/X2.

Backhaul RLF recovery procedure: This procedure enables IAB-nodes in SA mode to migrate to another parent node underneath the same IAB-donor-CU, when the IAB-MT declares backhaul RLF. The procedure is initiated by the IAB-MT upon observation of BH RLF and uses RRC Connection Reestablishment. When RLF recovery fails, the IAB-MT may send an RLF indication to its child nodes, so that they can try to perform RLF recovery.

PHY-layer specifications

The following physical layer procedures have been introduced for the support of IAB:

Over-the-air time synchronization: The IAB-nodes and IAB-donor-DUs within the IAB-topology are assumed to operate time-synchronized. The IAB-DU may use the downlink signal received by the collocated IAB-MT from a parent, as a reference to control its downlink timing using TA in conjunction with an additional Tdelta parameter signalled via MAC-CE

Inter node discovery: An IAB-node can be configured to transmit and receive SSB signals to discover neighbouring IAB-nodes. The configuration is expected to not create a conflict between the IAB-DU SSB transmissions and the SSB measurement windows configured for the collocated IAB-MT.

Random Access by IAB-MT: For IAB-MTs, a separate IAB-specific random access configuration can be provided in addition to the UEs’ random access configuration. The IAB-specific random access configuration may be obtained by extending the random access configurations defined for UEs via scaling the periodicity and/or offsetting the position of the RACH occasions.

IAB Resource configuration: The IAB-donor-CU can confine the resources used by the schedulers on an IAB-DU or IAB-donor-DU to account for multiplexing constraints among BH and access links in the IAB topology. The configuration assigns an attribute of Hard, Soft or Unavailable to each symbol of each serving cell.

Scheduling can occur for symbols configured as Hard, whereas scheduling cannot occur, except for some special cases, for symbols configured as Unavailable. For symbols configured as Soft, scheduling can occur conditionally based on explicit or implicit indication by the parent node. Explicit indication refers to signalling by the parent node to the collocated IAB-MT via PDCCH, which explicitly permits the usage of a designated Soft resource. Implicit indication refers to the autonomous determination whether a Soft resource can be used by the IAB-DU without creating a conflict for the collocated IAB-MT to follow its parent’s scheduling commands.

RF and RRM requirements

RAN4 decided to define following RRM requirements for IAB-MT nodes:

RRC Connected State mobility: The random access requirements of IAB-MTs were agreed to be same as those of UEs. For defining RRC re-establishment and RRC release with redirection requirements of IAB-MTs, RAN4 used the same requirements of UEs as a starting framework and then modified these further to accommodate higher periodicity of SMTC windows in IAB nodes.

Timing: The transmit timing and timing adjust requirements of IAB-MTs are same as those of UE requirements. The cell phase synchronization accuracy requirement of IAB-DUs is same as that for Rel-15 gNBs.

Signalling Characteristics: RAN4 agreed to define radio link monitoring, beam failure detection and candidate beam detection requirements for IAB-MTs. To define these requirements, RAN4 used the same requirements for Rel-15 UEs as a starting framework and then relaxed some of the evaluation periods by additional scaling factors because IAB-MTs are static nodes.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820070,750047,820170,820270,830021

[1] RP-200840: WID on integrated access and backhaul

[2] RP-200839: Status Report for integrated access and backhaul

19.1.5 Dual Connectivity (EN-DC) with 3 bands DL and 3 bands UL

841000

Dual Connectivity (EN-DC) with 3 bands DL and 3 bands UL

DC_R16_LTE_NR_3DL3UL

R4

RP-191598

ZTE

Summary based on the input provided by ZTE Corporation in RP-200112.

In Release 15, the operating bands are specified for these eligible operations with EN-DC configured. The EN-DC band combinations include at least one E-UTRA operating band and a NR operation band. In moving forward to Release 16, the configuration of EN-DC operation needs to be expanded for more simultaneous uplink and downlink configurations, including band combination of LTE, FR1 and FR2 bands.

New configurations still emerge from existing bands and whenever new band is specified, it will create a potential for several new EN-DC configurations consisting of 3 different bands DL with 3 different bands UL (1 LTE band UL and 2 NR different band UL(i.e. 1CC LTE band + 1CC NR FR1 band + NR FR2 band), or 2 LTE different band UL and 1 NR FR2 band UL).

The EN-DC configurations including NR CA will be introduced in a release independent manner based on TS38.307, which will be updated depending on newly introduced EN-DC configurations including NR CA.

All new ENDC configurations including NR with 3 bands will be defined under this WI, where :

– For only 1 NR band included, only NR FR2 band is applied

– For only 2 NR bands included, 1 NR FR1 band and 1 NR FR2 band are included and operated as inter-band CA

The companies can request their interesting ENDC configurations before each 3GPP RAN4 meeting. The WID was started from RAN #84 meeting, and will completed at RAN #88 meeting.

Usually these configurations are the potential NR NSA deployment scenarios for the operators. Each of the requested ENDC configurations includes at least applicable frequencies if necessary, applicable bandwidths and bandwidth sets if necessary, and Downlink ENDC configurations and Uplink ENDC configuration, respectively. More importantly, each ENDC configuration shall be requested with at least three other supporting companies. In addition, these combinations will be introduced in a Rel-independent way starting from Rel-15.

All of the ENDC configurations requested by the companies are all captured in two tables in the WID, shown as follow.

1. EN-DC of 3 different bands DL(LTE 1 band + NR 2 bands) with 3 different bands UL

2. EN-DC of 3 different bands DL(LTE 2 bands + NR 1 band) with 3 different bands UL

For the ENDC configuration in the WID, the RF requirements shall be specified, including:

Analyse combinations that have self-desensitization due to following reasons:

– TX Harmonic and/or intermodulation overlap of receive band

– TX signal overlap of receiver harmonic frequency

– TX frequency being in close proximity of one of the receive bands

– Any other identified reasons such that insufficient cross band isolation, harmonic mixing

For the combination where self-desensitization exists, specify at least needed

– ∆TIB, c and ∆RIB, c

– Reference sensitivity exceptions including MSD test cases

All of the study results are captured into TR37.716-33, and for the ENDC configurations will be included in TS38.101-3 specification in the case of these configurations are approved in RAN4 meeting.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=841000

[1] RP-192537, Revised WID for Dual Connectivity (EN-DC) with 3 bands DL and 3 bands , ZTE Corporation

[2] R4-1913627, CR to reflect the completed ENDC combinations for 3 bands DL with 3 bands UL into Rel16 TS 38.101-3, ZTE Corporation

[3] R4-2000501, CR to reflect the completed ENDC combinations for 3 bands DL with 3 bands UL into Rel16 TS 38.101-3, ZTE Corporation

[4] R4-1913631, TR 37.716-33 v0.1.0 Dual Connectivity (EN-DC) with 3 bands DL and 3 bands UL, ZTE Corporation

[5] RP-200110, Revised WID for Dual Connectivity (EN-DC) with 3 bands DL and 3 bands , ZTE Corporation

19.1.6 NR mobility enhancements

800087

NR mobility enhancements

NR_Mob_enh

R2

RP-190489

Intel

800187

Core part: NR mobility enhancements

NR_Mob_enh-Core

R2

RP-190489

Intel

800287

Perf. part: NR mobility enhancements

NR_Mob_enh-Perf

R4

RP-190489

Intel

Summary based on the input provided by ZTE Corporation in RP-200170.

The work item on NR mobility enhancements specifies solutions to reduce interruption time during HO (by Dual Active Protocol Stack (DAPS) handover), and to improve HO/SCG change reliability and robustness (by Conditional Handover (CHO), Conditional PSCell Change (CPC) and T312 based fast failure recovery).

The corresponding changes are captured into TS 38-series specifications and TS37.340/TS36.331 in [2]-[5].

Dual Active Protocol Stack (DAPS) handover

DAPS Handover is a handover procedure that maintains the source gNB connection after reception of RRC message for handover and until releasing the source cell after successful random access to the target gNB.

– The UE maintains DL reception and UL transmission for user data with source upon receiving DAPS HO command before successful RACH in target (UL switching);

– Upon receiving the indication on UL switching, for UL the PDCP layer will only forward the user data to target path;

– The UE will continue the reception of DL from both source and target, and provides UL to both source (PDCP will not forward the user data to low layer) and target node before release of source.

– Upon HO failure, the UE can use source link for recovery instead of reestablishment if the source link is still valid;

Conditional Handover (CHO)

Conditional Handover (CHO) is a handover procedure that is executed only when the configured execution condition(s) are met.

To improve the robustness, the network can provide the up to 8 candidate cell configuration(s) associated with execution condition (s) to UE. The UE maintains connection with source gNB after receiving CHO configuration, and starts evaluating the CHO execution conditions for the candidate cell(s). If at least one CHO candidate cell satisfies the corresponding CHO execution condition, the UE detaches from the source gNB, applies the stored corresponding configuration for that selected candidate cell, synchronises to that candidate cell and completes the RRC handover procedure by sending RRCReconfigurationComplete message to the target gNB. The UE releases stored CHO configurations after successful completion of RRC handover procedure.

Upon failure, the UE will perform CHO if the selected cell is CHO candidate cell and it is the first time of recovery and if the network allows CHO based recovery.

Conditional PSCell Change (CPC)

Conditional PSCell Change is a PSCell change procedure that is executed only when PSCell execution condition(s) are met.

To improve the robustness, the network can provide the up to 8 candidate cell configuration(s) associated with execution condition (s) to UE. If CPC is configured in the RRCReconfiguration, the UE maintains connection with source PSCell after receiving CPC configuration, and starts evaluating the CPC execution conditions for the candidate PSCell(s). If at least one CPC candidate PSCell satisfies the corresponding CPC execution condition, the UE detaches from the source PSCell, applies the stored corresponding configuration for the selected candidate PSCell and synchronises to that candidate PSCell. The UE completes the CPC execution procedure by an ULInformationTransferMRDC message to the MN which includes an embedded RRCReconfigurationComplete message to the new PSCell if SRB3 is not configured, otherwise the UE sends RRCReconfigurationComplete message to the new PSCell directly.

Upon SCG failure, same as MR-DC, the UE will transmit the SCG Failure Information message to the MN.

In Rel-16, conditional handover based NR PSCell addition/change for any architecture option with NR PSCell is supported, but limit to intra SN change without MN involvement.

T312 based fast failure recovery

T312 based solution (same as LTE) is used for both PCell and PSCell. The motivation of T312 is to speed up RLF recovery procedure by triggering re-establishment procedure sooner using a shorter timer than T310. T312 on PSCell can be configured for SCG measurement configurations provided over SRB3 or SRB1.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800087,800187,800287

[1] RP-192534, Revised WID on NR mobility enhancements, Intel Corporation, RAN#86

[2] RAN1 CR packets

[3] RAN2 CR packets

[4] RAN3 CR packets

[5] RAN4 CR packets

19.1.7 Rel-16 NR inter-band CA/Dual Connectivity for 2 bands DL with x bands UL (x=1, 2)

800074

Rel-16 NR inter-band CA/Dual Connectivity for 2 bands DL with x bands UL (x=1, 2)

NR_CADC_R16_2BDL_xBUL

R4

RP-191565

ZTE

Summary based on the input provided by ZTE Corporation in RP-200170.

This WI is to introduce the band combinations for inter-band carrier aggregation and dual connectivity for 2 bands DL with up to 2 bands UL into Rel-16 specifications and specify the corresponding configurations and RF requirements.

The study results for each band combination are captured in TR 38.716-02-00, and the configurations and RF requirements are added into the corresponding technical specifications.

This WI includes all target band combinations for both NR CA and DC including the following configurations:

• New NR CA configurations including inter band CA for 2 different bands DL with up to 2 different bands UL

o new configurations from exiting bands

o new configurations from new band

o The NR CA configurations will be introduced in a release independent manner based on TS38.307

• New NR DC configurations including inter band CA for 2 different bands DL with up to 2 different bands UL

o Accommodated only until the outcome of Rel-15 late drop handling becomes clear.

The preconditions to propose NR CA/DC configurations including Inter band CA for 2 different bands DL with up to 2 different bands UL in rel-16 are as follows.

o Constituent NR band and NR Intra band CA shall be completed and specified in advance.

o NR Band n1 and n2 requirements shall be completed and specified in advanced.

Specification for each band combination includes:

o Applicable frequencies if necessary

o Applicable bandwidth and bandwidth sets if necessary

o Analysis on potential self-desensitization due to following reasons:

o TX Harmonic and/or intermodulation overlap of receive band

o TX signal overlap of receiver harmonic frequency

o TX frequency being in close proximity of one of the receive bands

o Any other identified reasons

o At least the following for the combination where self-desensitization exists

o ∆TIB, c

o ∆RIB, c

o Reference sensitivity exceptions including MSD test cases

o Add conformance testing in RAN5 specifications (to follow at a later stage)

The target band combinations are captured in four tables in this WI respectively:

o CA configurations for 2 different bands DL with 1 band UL

o CA configurations for 2 different bands DL with 2 band UL

o CA configurations for 2 different bands DL with up to 2 band UL within FR2

o DC configurations for 2 different bands DL with 2 band UL within FR1, or within FR2 or including FR2

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800074

[1] R4-2000502 Revised WID on Rel-16 NR Inter-band Carrier Aggregation/Dual Connectivity for 2 bands DL with x bands UL (x=1,2), ZTE Corporation

[2] R4-2000497 CR to reflect the completed NR inter band CA DC combinations for 2 bands DL with up to 2 bands UL into Rel16 TS 38.101-1, ZTE Corporation

[3] R4-2000498 CR to reflect the completed NR inter band CA DC combinations for 2 bands DL with up to 2 bands UL into Rel16 TS 38.101-3, ZTE Corporation

[4] R4-2000803 TR 38.716-02-00 v0.9.0, ZTE Corporation

[5] RP-200168, Revised WID for, ZTE Corporation

19.1.8 Rel16 NR inter-band Carrier Aggregation for 3 bands DL with 1 band UL

830095

Rel16 NR inter-band Carrier Aggregation for 3 bands DL with 1 band UL

NR_CA_R16_3BDL_1BUL

R4

RP-191153

CATT

Summary based on the input provided by ZTE Corporation in RP-200173.

This WI is to introduce the band combinations for inter-band carrier aggregation and dual connectivity for 3 bands DL with 2 bands UL into Rel-16 specifications and specify the corresponding configurations and RF requirements.

The study results for each band combination are captured in TR 38.716-03-02, and the configurations and RF requirements are added into the corresponding technical specifications.

This WI includes all target band combinations for both NR CA and DC including the following configurations:

• New NR CA configurations including inter band CA for 3 different bands DL with 2 different bands UL

o new configurations from exiting bands

o new configurations from new band

o The NR CA configurations will be introduced in a release independent manner based on TS38.307

• New NR DC configurations including inter band CA for 3 different bands DL with 2 different bands UL

The preconditions to propose NR CA/DC configurations including Inter band CA for 3 different bands DL with 2 different bands UL in rel-16 are as follows.

o Requirements for all concerning bands shall be completed and specified in advanced

o Constituent NR band and NR intra band CA shall be completed and specified in advance

Specification for each band combination includes:

o Applicable frequencies if necessary

o Applicable bandwidth and bandwidth sets if necessary

o Analysis on potential self-desensitization due to following reasons:

o TX Harmonic and/or intermodulation overlap of receive band

o TX signal overlap of receiver harmonic frequency

o TX frequency being in close proximity of one of the receive bands

o Any other identified reasons

o At least the following for the combination where self-desensitization exists

o ∆TIB, c

o ∆RIB, c

o Reference sensitivity exceptions including MSD test cases

o Add conformance testing in RAN5 specifications (to follow at a later stage)

The target band combinations are captured in two tables in this WI respectively:

o CA configurations for 3 different bands DL with 2 band UL

o DC configurations for 3 different bands DL with 2 band UL

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830095

[1] R4-2000503 Revised WID on Rel-16 NR Inter-band Carrier Aggregation/Dual Connectivity for 3 bands DL with 2 bands UL, ZTE Corporation

[2] R4-2000499 CR to reflect the completed NR inter band CA DC combinations for 3 bands DL with 2 bands UL into Rel16 TS 38.101-1, ZTE Corporation

[3] R4-2000500 CR to reflect the completed NR inter band CA DC combinations for 3 bands DL with 2 bands UL into Rel16 TS 38.101-3, ZTE Corporation

[4] R4-2000804 TR 38.716-03-02 v0.4.0, ZTE Corporation

[5] RP-200171, Revised WID for Rel-16 NR Inter-band Carrier Aggregation/Dual Connectivity for 3 bands DL with 2 bands UL, ZTE Corporation

19.1.9 Add support of NR DL 256QAM for frequency range 2 (FR2)

830088

Add support of NR DL 256QAM for frequency range 2 (FR2)

NR_DL256QAM_FR2

R4

RP-200124

China Telecom

830188

Core part: Add support of NR DL 256QAM for frequency range 2 (FR2)

NR_DL256QAM_FR2-Core

R4

RP-200124

China Telecom

830288

Perf. part: Add support of NR DL 256QAM for frequency range 2 (FR2)

NR_DL256QAM_FR2-Perf

R4

RP-200124

China Telecom

Summary based on the input provided by China Telecom in RP-200727.

In NR_DL256QAM_FR2 WI, the RF requirements include BS modulation quality, UE maximum input level and BS conformance test requirements were specified to make RAN4 specification support FR2 DL 256QAM. This will enable the commercial deployment and also guarantee the transceiver performance for the feature of FR2 DL 256QAM from both BS and UE sides.

This WI firstly evaluated the feasibility of FR2 DL 256QAM based on link level simulation, system level simulation and implementation study, and concluded that FR2 DL 256QAM is feasible and beneficial in certain of identified applicable scenarios (see TR 38.883 on "Study on FR2 DL 256QAM").

After the feasibility confirmation, the WI introduced corresponding FR2 DL 256QAM specific RF requirements listed as

– For 38.104: BS modulation quality expressed as Error Vector Magnitude (EVM) requirement which is specified as 3.5%, same required value with FR1.

– For 38.101-2: UE Maximum input level for both single carrier and intra-band CA which reflects the receiver linearity capability, and the related Fixed Reference Channel which is used to test the Maximum input level.

– For 38.141-2: Manufacturers declarations for the output power, Test models, Test procedures and Test EVM requirement.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830088,830188,830288

19.1.10 SON (Self-Organising Networks) and MDT (Minimization of Drive Tests) support for NR

840091

SON (Self-Organising Networks) and MDT (Minimization of Drive Tests) support for NR

NR_SON_MDT

R3

RP-192610

CMCC

840191

Core part: SON (Self-Organising Networks) and MDT (Minimization of Drive Tests) support for NR

NR_SON_MDT-Core

R3

RP-192610

CMCC

Summary based on the input provided by CMCC in RP-200774.

This work item introduces SON and MDT features support in NR, including MRO (Mobility Robustness Optimisation), MLB (Mobility Load Balancing), RACH optimization, MDT (Minimization of Drive Test) and L2 measurements. Specification of these features will help mobile operators reduce the CAPEX/OPEX and improve the use experience.

This work item produces a new specification TS 38.314: L2 measurements for NR.

The key functionalities of this WI are described as below:

Mobility Robustness Optimisation (MRO) aims at detecting and enabling correction of mobility related problems including Connection failure due to intra-system or inter-system mobility, Inter-system Unnecessary HO and Inter-system HO ping-pong. MRO also provides means to distinguish the above problems from NR coverage related problems and other problems, not related to mobility.

– Connection failure due to intra-system mobility

– Intra-system Too Late Handover

– Intra-system Too Early Handover

– Intra-system Handover to Wrong Cell

– Connection failure due to inter-system mobility

– Inter-system/ Too Late Handover

– Inter-system/ Too Early Handover

– Inter-system Unnecessary HO

– Inter-system Ping-pong

Mobility load balancing (MLB) is to distribute load evenly among cells and among areas of cells, or to transfer part of the traffic from congested cell or from congested areas of cells, or to offload users from one cell, cell area, carrier or RAT to achieve network energy saving.

Intra-RAT and intra-system inter-RAT load balancing scenarios are specified and includes the functions ofLoad reporting, Load balancing action based on handovers and Adapting handover and/or reselection configuration.

The load reporting function is executed by exchanging load information over the Xn/X2/F1/E1 interfaces via Resource Status Reporting Initiation & Resource Status Reporting procedures.

The load metrics that have been specified consist of

– Radio resource usage (per-cell and per SSB area PRB usage: DL/UL GBR PRB usage, DL/UL non-GBR PRB usage, DL/UL total PRB usage, and DL/UL scheduling PDCCH CCE usage);

– TNL capacity indicator (UL/DL TNL offered capacity and available capacity);

– Cell Capacity Class value (UL/DL relative capacity indicator);

– Capacity value (per cell, per SSB area and per slice: UL/DL available capacity);

– HW capacity indicator (offered throughput and available throughput over E1, percentage utilisation over F1);

– RRC connections (number of RRC connections, and available RRC Connection Capacity);

– Number of active UEs.

RACH optimization is supported by UE reported information made available at the NG RAN node and by PRACH parameters exchange between NG RAN nodes.

The functionalities supported over the interfaces consist of

– PRACH configuration per served cell is signalled from DU to CU and over Xn

– PRACH configuration of Served Cells over X2

– RACH report from UE over Uu

– RACH report from CU to DU over F1

NR MDT takes LTE as baseline and takes NR new features into account, including beam, RRC_INACTIVE and EN-DC.

The following functionalities are specified:

– MDT network signaling support over S1, X2, NG, Xn, F1 and E1

– Logged MDT for RRC_IDLE and RRC_INACTIVE UEs, support event-trigged or periodic logged MDT

– Immediate MDT

– CEF (Connection Establishment Failure) report

– Resume failure report

– Immediate MDT for EN-DC

L2 measurements. In this work item, a new spec TS 38.314 was produced to capture the measurements performed by network or the UE that are transferred over the standardised interfaces in order to support NR radio link operations, radio resource management (RRM), network operations and maintenance (OAM), minimization of drive tests (MDT) and self-organising networks (SON).

The specified measurements includes

– Received Random Access Preambles

– Packet delay

– Number of active UEs

– Number of stored inactive UE contexts

– UL PDCP Packet Average Delay by the UE

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840091,840191

[1] RP-192610, Revised WID on SON/MDT support for NR, CMCC

[2] RP-200773, Status report for WI on SON_MDT support for NR, CMCC

[3] CRs and new specs

R2-2006195 draft TS 38.314 CMCC

R2-2006342 CR to 37.320 to support NR MDT CMCC, Nokia, Nokia Shanghai Bell CR Rel-16 37.320 16.0.0 0082 1 F NR_SON_MDT-Core

R2-2006336 Corrections on MDT and SON in NR Huawei, Ericsson, HiSilicon CR Rel-16 38.331 16.0.0 1669 2 F NR_SON_MDT-Core

R2-2006337 Corrections on MDT and SON Huawei, Ericsson, HiSilicon CR Re-16 36.331 16.0.0 4323 2F NR_SON_MDT-Core

R2-2006197 UE capabilities for NR MDT and SON vivo, CMCC 38.306CR

R2-2006198 UE capabilities for NR MDT and SON vivo, CMCC 36.306CR

R3-204414 BLCR to 38.420: Addition of MDT feature CMCC 38.420

R3-204415 BLCR to 38.420: Addition of SON feature CMCC 38.420

R3-204416 BLCR to 38.470: Addition of SON feature CMCC 38.470

R3-204417 BLCR to 38.460: Addition of SON feature CMCC 38.460

R3-204421 MDT support for EN-DC Huawei 36.413

R3-204423 Addition of SON features CMCC, Huawei 38.401

R3-204425 Addition of SON features Huawei 36.413

R3-204426 Addition of MDT feature Huawei 38.413

R3-204427 Addition of MDT features ZTE 38.463

R3-204428 Addition of MDT features Samsung 38.473

R3-204478 Addition of SON feature Huawei 36.300

R3-204479 Addition of SON feature CATT 36.423

R3-204480 Addition of SON features CMCC, Huawei 38.300

R3-204481 Addition of SON features Huawei 38.413

R3-204482 Addition of SON features Samsung 38.423

R3-204483 Addition of SON features Huawei 38.473

R3-204484 Addition of MDT features Samsung 38.401

R3-204485 MDT Configuration support for XnAP Ericsson 38.423

R3-204496 MDT support for EN-DC Huawei, SAMSUNG 36.423

R3-204502 Addition of SON features Ericsson 38.463

19.1.11 Introduction of NR FDD bands with variable duplex and corresponding framework

841001

Introduction of NR FDD bands with variable duplex and corresponding framework

NR_FDD_bands_varduplex

R4

RP-191567

Huawei

841101

Core part: Introduction of NR FDD bands with variable duplex and corresponding framework

NR_FDD_bands_varduplex-Core

R4

RP-191567

Huawei

Summary based on the input provided by Huawei, HiSilicon in RP-201019.

Supplementary downlink (SDL) frequency bands are defined within NR specifications in accordance with regulated licensed bands such as in the 1400-1500MHz range in Europe, and Uplink Sharing is defined as a means to operate NR uplink on the uplink resources of other bands, e.g. sharing the uplink carrier with that of an LTE carrier. Such a configuration may be particularly useful when there is not a desire to allocate downlink NR resources in a 2nd downlink carrier, e.g. for an EN-DC configuration with the SDL band as part of the secondary cell group (SCG).

This work item allows the uplink and downlink of the introduced bands to be from 2 different licensed spectrum blocks, and new paired bands are defined in the RF specifications as n91, n92, n93 and n94.

System parameters

System parameters for the new variable duplex FDD bands are defined in all the related RAN4 specifications including, operating bands, channel bandwidth, rasters, Tx-Rx separation, etc.

Operating bands and NR-ARFCN

Newly introduced variable duplex bands have the same UL frequency parts as in SUL bands either n81 or n82, while they also have the same DL frequency parts as in SDL bands n75 or n76.

n91

832 MHz – 862 MHz

1427 MHz – 1432 MHz

FDD9

n92

832 MHz – 862 MHz

1432 MHz – 1517 MHz

FDD9

n93

880 MHz – 915 MHz

1427 MHz – 1432 MHz

FDD9

n94

880 MHz – 915 MHz

1432 MHz – 1517 MHz

FDD9

A note 9 is specified in the table that says ‘Variable duplex operation does not enable dynamic variable duplex configuration by the network, and is used such that DL and UL frequency ranges are supported independently in any valid frequency range for the band’. This comes from the concern that the operator may want to dynamically configure the duplex distance used in the network.

Channel bandwidth

Since the frequency parts of the variable duplex FDD bands are acquired independently, asymmetric bandwidths must be introduced to accommodate most of the desired deployments.

NR Band

Channel bandwidths for UL (MHz)

Channel bandwidths for DL (MHz)

n911

10

5

n921

5

10, 15, 20

10

15, 20

n931

10

5

n941

5

10, 15, 20

10

15, 20

NOTE 1: The assignment of the paired UL and DL channels are subject to a TX-RX separation as specified in clause 5.4.4.

Hence other bandwidth configurations of the variable duplex FDD bands follow what was defined for the corresponding UL or DL bands that are consisted of.

Tx-Rx separation

It is worth noting that Tx-Rx separation is defined in a different way for the variable duplex bands since the default separation no longer applies with them.

NR Operating Band

TX – RX
carrier centre frequency
separation

n91

570 MHz – 595 MHz

(NOTE 2)

n92

575 MHz – 680 MHz (μ = 0)

580 MHz – 675 MHz (μ = 1)

(NOTE 2)

n93

517 MHz – 547 MHz

(NOTE 2)

n94

522 MHz – 632 MHz (μ = 0)

527 MHz – 627 MHz (μ = 1)

(NOTE 2)

Note 2 says that the range of Tx-Rx frequency separation given paired UL and DL channel bandwidths BWUL and BWDL is given by the respective lower and upper limit FDL_low – FUL_high + 0.5(BWDL + BWUL) and FDL_high – FUL_low – 0.5(BWDL + BWUL). The UL and DL channel bandwidth combinations specified in Table 5.3.5-1 and 5.3.6-1 depend on the subcarrier spacing configuration μ.

UE requirements

UE requirements considering the characteristics when operating in the variable duplex bands and band combinations are defined including REFSENS and related configurations.

REFSENS and UL configurations

REFSENS requirements follow the ones defined for n75 and n76 correspondingly for the variable duplex bands but UL configurations are not necessarily the same with those defined for n8 and n20. For n20, additional restrictions on the UL RBs are specified so that the same REFSENS value can be achieved with such a narrow duplex distance. Since the variable duplex bands have much larger expected Tx-Rx separation, additional restrictions on the UL RB allocations are not specified.

BS requirements

In this work item, BS requirements span among a series of specifications such as 38.104, 38.141-1, 37.104, 37.105, 37.141, 37.145-1, 37.145-2, 36.104, 36.141, etc. Mainly coexistence requirements are defined in these specs.

Additional spurious emission requirements

Respective requirements which correspond to BS spurious limits for co-existence with systems operating in the new variable duplex FDD bands are introduced in the mentioned spec, with maximum measured spurious levels and bandwidth configurations.

Out of band blocking requirements

Another set of Tx requirements is also defined with the similar manner as the above one. The requirements apply when co-location with other BS-s operating in the variable duplex FDD bands is observed.

Receiver response under co-location requirements

Receiver response requirements are defined in the mentioned specifications that the BS operating in the introduced bands should have the ability to block unwanted interband interferences from any other collocated BS.

For all the above mentioned BS requirements, both conducted and radiated requirements are defined.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=841001,841101

[1] RP-192820, “Revised WID: Introduction of NR FDD bands with variable duplex and corresponding framework”, Huawei, HiSilicon.

[2] RP-192818, “Status report for WI: Introduction of NR FDD bands with variable duplex and corresponding framework”, Huawei, HiSilicon.

19.1.12 Cross Link Interference (CLI) handling and Remote Interference Management (RIM) for NR

800082

Cross Link Interference (CLI) handling and Remote Interference Management (RIM) for NR

NR_CLI_RIM

R1

RP-191546

LG Electronics

800182

Core part: Cross Link Interference (CLI) handling and Remote Interference Management (RIM) for NR

NR_CLI_RIM-Core

R1

RP-190700

LG Electronics

800282

Perf. part: Cross Link Interference (CLI) handling and Remote Interference Management (RIM) for NR

NR_CLI_RIM-Perf

R4

RP-190700

LG Electronics

Summary based on the input provided by Huawei in RP-190144.

Rel-14 NR study showed that duplexing flexibility with cross-link interference mitigation shows better user throughput compared to static UL/DL operation or dynamic UL/DL operation without interference mitigation in indoor hotspot (4GHz and 30GHz) and urban macro scenarios (4GHz and 2GHz). Furthermore, semi-static and/or dynamic DL/UL resource assignments should also consider coexistence issues particularly among different operators where tight coordination are challenged. For efficient coexistence, not only coexistence requirements need to be understood but also advanced mechanisms to mitigate interference such as TRP-to-TRP measurement and adaptation based on measurements should be considered. The Rel-16 Work Item Cross Link Interference (CLI) handling to support flexible resource adaptation for unpaired NR cells achieves the following objectives [1]:

• CLI measurements and reporting at a UE (i.e., CLI-RSSI and SRS-RSRP), and network coordination mechanism(s) (i.e., exchange of intended DL/UL configuration) are developed.

• Perform coexistence study to identify conditions of coexistence among different operators in adjacent channels is accomplished.

In NR deployment on lower TDD frequency, the impact of the troposphere bending will continue existing if no special mechanisms are introduced. In the RIM SI, the frameworks for mechanisms for gNBs to start and terminate the transmission/detection of reference signal(s), the functionalities and requirements of the corresponding RS(s) as well as the design of the RS(s), and the backhaul-based coordination mechanisms among gNBs have been studied. It is recommended to specify RIM RS(s) to support identifying remote interference related information, it is also recommended to specify the inter-set RIM backhaul signalling via the core network for backhaul-based solution. The Rel-16 Work Item Remote Interference Management (RIM) to deal with mitigation of the remote interference caused by gNBs achieves the following objectives [1]:

• RIM RS resource and configurations, and the inter-set RIM backhaul signalling via the core network to convey the messages of “RIM-RS detected” and “RIM-RS disappeared are developed.

• Corresponding OAM functions to support RIM operation is identified.

CLI handling

Once different TDD UL/DL configurations are applied among neighboring cells, UL transmission from a UE in a cell causes interference to DL reception of some other UEs in the rest of the neighboring cells. The interference is referred as inter-cell UE-to-UE cross link interference (CLI). To mitigate an inter-cell UE-to-UE CLI, gNBs can exchange and coordinate the intended TDD UL/DL configuration over Xn and F1 interfaces. Taking into account the exchanged information, a gNB may decide the transmission and reception pattern in order to avoid CLI to neighboring cell or from neighboring cell.

For CLI handling, two types of CLI measurements and reporting (i.e., CLI-Received Signal Strength Indicator (RSSI) measurement and SRS-Reference Signal Received Power (RSRP) measurement) are specified. For CLI-RSSI measurement, the victim UE measures the total received power over configured CLI-RSSI measurement resource. For SRS-RSRP measurement, the victim UE measures the RSRP over configured SRS resource(s) which is/are transmitted from one or multiple aggressor UE(s). Then, Layer 3 filtering can be applied to the measurement result for both CLI-RSSI measurement and SRS-RSRP measurement. For measurement result reporting for both CLI-RSSI measurement and SRS-RSRP measurement, event triggered and periodic reporting are supported. Furthermore, CLI measurement and reporting can be configured for NR cells in multi-carrier option.

Semi-static and/or dynamic DL/UL resource assignment causes interferers between networks on adjacent channels. It has been tasked to investigate the adjacent channel co-existence effects arising when CLI, or more generically dynamic TDD is operated in an aggressor network. The technical report captures a description of the adjacent channel interference effects that arise with dynamic TDD as well as a simulation investigation of adjacent channel interference in a number of different deployment scenarios [2].

RIM

Due to the atmospheric ducting phenomenon, the DL signals of an aggressor cell in unpaired spectrum can interfere with the UL signals of a victim cell in the same unpaired spectrum bandwidth that is far away from the aggressor cell. Such interference is termed as remote interference. A remote interference scenario may involve a number of victim and aggressor cells, where the gNBs may execute Remote Interference Management (RIM) coordination on behalf of their respective cells.

To mitigate remote interference, RIM frameworks for coordination between victim and aggressor gNBs are specified. The coordination communication in RIM frameworks can be wireless- or backhaul-based. In both frameworks, all gNBs in a victim set can simultaneously transmit an identical RIM reference signal carrying the victim set ID over the air.

In the wireless framework, RIM-RS (RIM reference signal) type 1 and RIM-RS type 2 are specified. Upon reception of the RIM reference signal (RIM-RS type 1) from the victim set, aggressor gNBs undertake RIM measurement, and may send back a RIM reference signal (RIM-RS type 2) carrying the aggressor set ID if configured, and may undertake interference mitigation actions. The RIM reference signal (RIM-RS type 2) sent by the aggressor is able to facilitate estimation whether the atmospheric ducting phenomenon between victim and aggressor sets exists.

In the RIM backhaul framework, upon reception of the RIM reference signal (RIM-RS type 1) from the victim set, aggressor gNBs undertake RIM measurement, establish backhaul coordination towards the victim gNB set. The backhaul messages which carry the detection or disappearance indication are aggregated at gNB-CU via F1 interface and sent from individual aggressor gNBs to individual victim gNBs via NG interface, where the signalling is transparent to the core network.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800082,800182,800282

[1] RP-193190 “Revised WID on Cross Link Interference (CLI) handling and Remote Interference Management (RIM) for NR”

[2] 3GPP TR38.828 “Cross Link Interference (CLI) handling and Remote Interference Management (RIM) for NR”

19.1.13 RF requirements for NR frequency range 1 (FR1)

830087

RF requirements for NR frequency range 1 (FR1)

NR_RF_FR1

R4

RP-193266

Huawei

830187

Core part: RF requirements for NR frequency range 1 (FR1)

NR_RF_FR1-Core

R4

RP-193266

Huawei

830287

Perf. part: RF requirements for NR frequency range 1 (FR1)

NR_RF_FR1-Perf

R4

RP-193266

Huawei

Summary based on the input provided by Huawei in RP-201718.

In Rel-16, several FR1 non-spectrum related topics are included in one WI targeting for UE RF requirements enhancement.

In this WI, RF requirements, corresponding new feature groups and functionalities are introduced for both uplink and downlink enhancements. This enables the 5G commercial deployment requirements on FR1 fulfilled.

In Rel-15, almost-contiguous allocations for CP-OFDM was introduced for power class 3 UE. This allows UE to be scheduled with non-contiguous PUSCH allocation within one carrier which is partitioned by short PUCCH of other users. In Rel-16, RAN4 continues the work and completed RF requirement for HPUE on almost-contiguous CP-OFDM allocations.

FR1 Intra-band contiguous DL CA is up to 200MHz aggregated channel bandwidth in Rel-15. Based on commercial deployment requirement, RAN4 enhances intra-band contiguous DL CA to 300MHz in Rel-16, the corresponding RF requirements are completed within this WI. Meanwhile, intra-band non-contiguous DL CA is introduced considering latest 5G spectrum allocation is some country/region.

In correspondence, FR1 intra-band contiguous and non-contiguous UL CA are also introduced from Rel-16, all RF requirements are completed within the WI. Besides RF requirement, RAN4 also recognized the dependency relation among bandwidth class, PA architecture and MIMO layer for UE capability indicating. Additional DC location reporting UE capability is introduced to improve UL 256QAM performance for intra-band UL CA.

In Rel-15, inter-band UL CA, SA SUL and inter-band EN-DC RF requirements are specified assuming 0us switching period between 2 UL carriers when TDM operated, it leads to that UE cannot support 2Tx transmission when UE switch to one carrier if no switching period is reserved for the UE. In Rel-16, switching period between case 1 and case 2 is introduced to enable enhancement on UL performance with 2Tx transmission on one UL carrier for inter-band UL CA, SA SUL and inter-band EN-DC. For which, time mask including switching period and transient period between 2 carriers are specified. For inter-band UL CA and SA SUL, the switching periods are located in either NR carrier as indicated in RRC signalling, while for inter-band EN-DC, the switching periods are only located in NR carrier. In correspondence, UE capability on uplinkTxSwithingPeriod is introduced as 35μs, 140μs and 210μs (210μs only for inter-band UL CA and SA SUL). Meanwhile, UE DL interruption is allowed when configured with difficult band combinations.

Time masks for ULSUP-TDM that accounts for UL timing misalignment between the EUTRAN and NR cell groups are further modified in this WI, additional 2.2μs transient is added.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830087,830187,830287

19.1.14 NR RF requirement enhancements for frequency range 2

830089

NR RF requirement enhancements for frequency range 2 (FR2)

NR_RF_FR2_req_enh

R4

RP-191290

Nokia

830189

Core part: NR RF requirement enhancements for frequency range 2 (FR2)

NR_RF_FR2_req_enh-Core

R4

RP-190761

Nokia

Summary based on the input provided by Nokia in RP-201984.

This work item developed various UR RF enhancements for FR2. Basis for the WI was the features that were not developed in REL15 due to lack of time.

The following enhancements were introduced:

1. MPE: UE can report to network how much P-MPR it uses or is going to use because of MPE. Based on this reporting network can take actions to prevent sudden radio link failures.

2. Beam correspondence: Requirements for SSB-based and CSI-RS based BC were developed. This allows network to efficiently deploy different beam widths for SSB and CSI-RS. This enables e.g. to deploy wider SSB based beams for idle mode UEs and narrower CSI-RS based beams for RRC connected mode UEs.

3. Interband DL CA: Requirements were developed for band combination CA_n260-n261 based on independent beam management.

4. DL Intra-band CA BW Enhancement: New frequency separation classes Fs were introduced for up to 2400 MHz separation. Furthermore frequency separation classes for DL-only spectrum Fsd were introduced. The DL-only frequency spectrum is the width of UE frequency spectrum available to network to configure DL CCs only, and it extends on one-side of the bidirectional spectrum in contiguous manner with no frequency gap between the two.

5. Non-contiguous intra-band uplink CA: Requirements were developed for n260 for up to three uplink sub-blocks.

6. MPR enhancements: Zero dB MPR range was extended to cover more allocations.

7. Output power boost when in-band emissions are suspended: 1 dB boost was introduced for QPSK modulation.

8. Multiband relaxation framework enhancement: Based on RAN5 LS MBR framework was modified. REL15 retains original MBR concept but introduced a relaxation cap. REL16 adopted new concept where relaxation defined per band basis.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830089,830189

[1]RP-201606 Revised WID on NR RF Requirement Enhancements for FR2

[2] RP-201607 SR of NR RF requirement enhancements for frequency range 2 (FR2), RAN#89

[3] RP-201608 TR 38.831 v1.0.0

[4] RP-200666 SR of NR RF requirement enhancements for frequency range 2 (FR2), RAN#88

[5] RP-200247 SR of NR RF requirement enhancements for frequency range 2 (FR2), RAN#87

[6] RP-192652 SR of NR RF requirement enhancements for frequency range 2 (FR2), RAN#86

[7] RP-192226 SR of NR RF requirement enhancements for frequency range 2 (FR2), RAN#85

19.1.15 NR RRM enhancement

840095

NR RRM enhancement

NR_RRM_enh

R4

RP-191601

Intel

840195

Core part: NR RRM enhancement

NR_RRM_enh-Core

R4

RP-191601

Intel

840295

Perf. part: NR RRM enhancement

NR_RRM_enh-Perf

R4

RP-191601

Intel

Summary based on the input provided by Intel Corporation, ZTE Corporation, Apple in RP-201884.

The work item on NR RRM enhancement [1] introduces a number of enhanced NR RRM requirements on top of the baseline RRM requirements defined in the scope of the Rel-15 NR WI [2]. In particular, the RRM requirements for the following procedures are introduced in the scope of the work item:

– SRS carrier switching

– Multiple Scell activation/deactivation

– CGI reading with autonomous gap for NR capable UE

– BWP switching on multiple CCs

– Inter-band CA requirement for FR2

– Inter-frequency measurement without MG

– Mandatory measurement gap patterns

– Spatial relation switch for uplink

– UE specific channel BW change

The corresponding changes are captured in TS 38-series and 36-series specifications [3]-[8].

SRS carrier switching RRM requirements

SRS carrier switching functionality was defined for NR and LTE carriers in the scope of the Rel-15 NR WI [2], however, the respective requirements were not introduced in the Rel-15 scope. In the Rel-16 NR RRM Enhancements WI the specific UE interruption requirements for the SRS carrier switching are defined for the following cases:

– LTE SRS carrier switching impacting NR CC

– NR SRS carrier switching impacting LTE CC

– NR SRS carrier switching impacting NR CC

The corresponding interruption RRM requirements are specified in TS38.133 clause 8.2 and TS36.133 clause 7.32.2.13.

Multiple SCell activation/deactivation RRM requirements

In accordance to NR design multiple SCells can be activated/deactivated simultaneously. However, in Rel-15 only single SCell activation/deactivation NR RRM requirements were specified which resulted in an inefficient use of network resources. In the Rel-16 NR RRM Enhancements WI, te SCell activation and deactivation delay and interruption requirements for the case of multiple SCell activation/deactivation in FR1, FR2, and FR1+FR2 are introduced. The corresponding RRM requirements are specified in TS38.133 clause 8.3.7 and 8.3.8.

CGI reading with autonomous gap for NR capable UE

In Rel-16, the acquisition of CGI information from a neighbouring cell using autonomous gaps is supported. The NR cell CGI reading requirements are defined for NR capable UE in LTE SA, NR SA UE, EN-DC UE, NE-DC UE, and NR-DC. Besides that, the requirements for LTE cell CGI reading for NR SA UE, EN-DC UE, NE-DC UE, and NR-DC UE are defined. The RRM requirements are specified in TS38.133 clause 8.2, 9 and TS36.133 clause 7.32.2, 7.37, 7.36.2.

BWP switching on multiple CCs

The Rel-15 NR UE BWP switching requirements covered the scenario where a network configured BWP switching on a single component carrier. In practice, the network may configure BWP switching on multiple component carriers and a predictable UE behavior is important. In Rel-16 NR RRM Enhancements WI the requirements for both simultaneous and non-simultaneous BWP switching on multiple CCs, covering DCI based, timer based and RRC based BWP switching are defined. The respective RRM requirements are specified in TS38.133 clause 8.6.2A, 8.6.2B and 8.6.3A.

Inter-band CA requirement for FR2

The support of the FR2 inter-band CA was introduced in the scope of the FR2 RF WI [9]. In particular, the functionality to support independent beam management on the different CCs was introduced in the scope of [9]. The RRM requirements for inter-band CA requirement for FR2 UE measurement capability of independent Rx beam are defined in the scope of the NR RRM enhancements WI. The RRM requirements are specified in TS38.133 clause 9.2.5 and 9.5.6.

Inter-frequency measurement without MG

In Rel-15 NR, all the inter-frequency measurements have to be done within measurement gap. However, from UE implementation perspective inter-frequency measurement can be done without MG (inter-frequency RRM measurement and serving cell data reception/transmission can be done concurrently) under certain conditions. In Rel-16, RAN4 defines conditions under which UE can perform inter-frequency measurement without MG. RAN4 also introduces corresponding RRM requirement for CSSF update, which can be found in TS38.133 clause 9.1.5.

Mandatory measurement gap patterns

Only measurement gap patterns 0 and 1 are mandatorily supported in Rel-15. However, some other measurement gap patterns are also very important in balancing gap overhead and measurement performance. In Rel-16 additional mandatory measurement gap patterns were defined in Rel-16.

• GP#17, GP#18 and GP#19 shall be additional mandatory

• GP#2, GP#3 and GP#11 shall be additional mandatory for NR only measurement

Besides, a capability to support measurement gap patterns for NR only measurements was introduced. Definition of NR only measurement gaps can be found in TS38.133 Table 9.1.2-2 and Table 9.1.2-3.

Spatial relation switch for uplink

Uplink spatial relation can be changed since Rel-15. However, in Rel-15 RAN4 only specified RRM requirements for downlink spatial relation change. In Rel-16, delay requirements for spatial relation switch for uplink channels and SRS are defined. Corresponding requirements are specified in TS38.133 clause 8.12.

UE specific channel BW change

Both active BWP and UE specific channel BW can be dynamically changed in Rel-15. However, in RAN4 RRM only active BWP change requirements were specified in Rel-15. In Rel-16, RRM requirements for UE specific channel BW change are defined. Corresponding requirement can be found in TS38.133 clause 8.2.1.2.11, 8.2.2.2.8 and 8.13.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840095,840195,840295

[1] RP-201112 Revised WID: NR RRM enhancement in R16, Intel Corporation, ZTE Corporation, Apple

[2] RP-191971 Revised WID: New Radio Access Technology

[3] TS 38.133

[4] TS 38.331

[5] TS 38.306

[6] TS 36.133

[7] TS 36.331

[8] TS 36.306

[9] RP-200668 Revised WID on NR RF Requirement Enhancements for FR2

19.1.16 RRM requirement for CSI-RS based L3 measurement in NR

840093

RRM requirement for CSI-RS based L3 measurement in NR

NR_CSIRS_L3meas

R4

RP-191580

CATT

840193

Core part: RRM requirement for CSI-RS based L3 measurement in NR

NR_CSIRS_L3meas-Core

R4

RP-191580

CATT

840293

Perf. part: RRM requirement for CSI-RS based L3 measurement in NR

NR_CSIRS_L3meas-Perf

R4

RP-191580

CATT

Summary based on the input provided by CATT in RP-201942.

Compared to SSB based RRM measurement, CSI-RS based measurement is more refined and flexible in terms of resource usage, mobility enhancement and handover reliability. This WI [1] targets to specify the RRM requirements for CSI-RS based L3 measurement.

In R16 WI on RRM requirements of CSI-RS based L3 measurement, to guarantee the mobility, the RRM requirements including synchronization assumption, applicable CSI-RS configuration, CSI-RS based intra/inter-frequency definition, intra/inter measurement requirements, and UE measurement capability are specified.

Synchronization assumption

The CSI-RS based L3 measurement requirements in R16 WI are based on single FFT implementation and UE supports using the serving cell timing for intra-frequency measurements in Rel-16.

Measurement bandwidth of CSI-RS resources: The RRM requirements for CSI-RS based L3 measurement in R16 WI are specified based on the CSI-RS configuration {D=3, PRB≥48}.

CSI-RS based intra/inter-frequency definition: For CSI-RS based L3 measurement, the measurement is defined as a CSI-RS based intra-frequency measurement provided that the centre frequency, SCS and CP type (applied for SCS = 60KHz) of CSI-RS resources on the neighbour cell configured for measurement are the same as the centre frequency, SCS and CP type of CSI-RS resources on the serving cell indicated for measurement. Otherwise, the measurement is defined as CSI-RS based inter-frequency measurement.

Scenarios for CSI-RS based L3 measurement requirements: For CSI-RS based intra-frequency measurement, the RRM requirements in R16 are defined for the scenarios that all CSI-RS resources in the same MO have the same BW and the BW of the CSI-RS on the neighbour cell is within the active BWP of the UE. No requirement is defined when the BW of intra-MO is different from that of the CSI-RS resources configured for the serving cell in Rel-16.

For CSI-RS based inter-frequency measurement, the RRM requirements in R16 are defined for the scenarios that all CSI-RS resources in the same MO have the same BW and the CSI-RS resources to be measured with gap is not confined in the active BWP.

Intra/inter measurement requirements: The RRM requirements for CSI-RS based L3 measurement in R16 WI are specified for the case when associated SSB is configured. So the measurement delay consists of cell identification delay, SSB index acquisition time and CSI-RS measurement period.

The RRM requirements for CSI-RS based L3 measurement in R16 are specified based on the assumption that CSI-RS based L3 measurement and SSB based L3 cell detection/measurement share the measurement engines and applied when CSI-RS resources are configured within a 5ms window at any location.

UE measurement capability: On top of the legacy measurement capability of SSB based measurement, for the UE supporting CSI-RS based L3 measurement, UE shall be able to measure at least 1 SSB intra-frequency layer and 1 CSI-RS intra-frequency layer per serving cell, 8 NR inter-frequency layers including SSB and CSI-RS in total.

The cells to be monitored based on CSI-RS can be the same set or a subset of the cells monitored based on SSB.

For each intra-frequency layer, during each layer 1 measurement period, the UE shall be capable of performing CSI-RSRP, CSI-RSRQ, and CSI-SINR measurements for at least 32 CSI-RS resources for FR1and 32 CSI-RS resources for FR2.

For each inter-frequency layer, during each layer 1 measurement period, the UE shall be capable of performing CSI-RSRP, CSI-RSRQ, and CSI-SINR measurements for at least 14 CSI-RS resources for FR1 and 24 CSI-RS resources for FR2.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840093,840193,840293

[1] RP-201345 Revised WID on RRM requirements for CSI-RS based L3 measurement, CATT

[2] RP-201793 Status report for RRM requirements for CSI-RS based L3 measurement, CATT

19.1.17 Over the air (OTA) base station (BS) testing TR

860054

Over the air (OTA) base station (BS) testing TR

OTA_BS_testing

R4

RP-193225

Huawei

860254

Perf. Part: Over the air (OTA) base station (BS) testing TR

OTA_BS_testing-Perf

R4

RP-201021

Huawei

Summary based on the input provided by Huawei in RP-202600.

WI on OTA BS testing has introduced new Technical Report TR 37.941 (both Rel-15 and Rel-16) is collecting inputs from multiple existing RAN4-internal Technical Reports treating on AAS BS and NR BS radiated conformance testing aspects (i.e. TR 37.842, TR 37.843, TR 38.817-02), by collecting and aligning Measurement Uncertainty and Test Tolerance derivations methodologies for multiple OTA testing methodologies for directional measurements, TRP measurements, and co-location measurements.

Technical Report for the Work Item on Over The Air (OTA) Base Station (BS) testing covers background information of OTA testing methods, Measurement Uncertainty (MU) and Test Tolerance (TT) values derivation for the radiated conformance testing requirements. This Technical Report covers radiated conformance testing requirements for AAS BS in Frequency Range 1 (FR1), and for NR BS radiated conformance testing in FR1 and FR2:

– Hybrid AAS BS as specified in AAS BS radiated testing specification TS 37.145-2 for the following radio technologies:

– Hybrid AAS BS in single RAT UTRA operation, TDD

– Hybrid AAS BS in single RAT UTRA operation, FDD

– Hybrid AAS BS in single RAT E-UTRA operation

– Hybrid AAS BS in MSR operation implementing any of the above RATs, including NR operation.

– OTA AAS BS as specified in AAS BS radiated testing specification TS 37.145-2 [4] for the following radio technologies:

– OTA AAS BS in single RAT UTRA operation, FDD

– OTA AAS BS in single RAT E-UTRA operation

– OTA AAS BS in MSR operation implementing any of the above RATs, and/or NR.

– BS type 1-H in single RAT NR operation in FR1, as specified in NR BS radiated testing specification TS 38.141-2,

– BS type 1-O in single RAT NR operation in FR1, as specified in NR BS radiated testing specification TS 38.141-2,

– BS type 2-O in single RAT NR operation in FR2, as specified in NR BS radiated testing specification TS 38.141-2.

TR 37.941 consolidates the OTA measurement related information originating from multiple AAS BS and NR BS internal technical reports. This information is needed to supplement the BS radiated testing specifications as a single, 3GPP external technical report, such that the information can be referred to from external specifications and bodies.

Technical Report in TR 37.941 (both Rel-15 and Rel-16) is collecting inputs from multiple existing RAN4 internal Technical Reports: TR 37.842; TR 37.843 and TR 38.817-02.

Collected inputs were aligned updated to provide consistent information on Measurement Uncertainty (MU) and Test Tolerance (TT) derivations methodologies for directional, TRP and co-location measurements. For the purpose of future references and MU/TT values derivation verification, Excel spreadsheets were attached to the TR (for TX/RX MU values in FR1 and FR2, as well as for the co-location requirements).

The following OTA test methods were captured in Rel-15 version of the TR: IAC; CATR; NF; PWS; 1D and reverb.

TR 37 941 is expected to be further updated with relevant inputs related to the OTA BS testing, e.g. new or extended frequency ranges consideration, new OTA test methodologies, etc.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=860054,860254

19.2 Release 16 Features impacting both LTE and NR

19.2.1 Transfer of Iuant interface specifications from 25-series to 37-series

820071

Transfer of Iuant interface specifications from 25-series to 37-series

Iuant_transfer

R3

RP-190160

Huawei

Summary based on the input provided by Huawei in RP-190144.

This feature transfers the contents of TSs 25.46x into TSs 37.46x (x=0, 1, 2, 6) for releases 8/9/10/11/12/13/14/15, considering the fact theses specifications apply to different RAT i.e. UTRA, E-UTRA and NR.

Indeed, 25 series of specifications are dedicated to UMTS only, when the material which was previous there referred to multiple RATs, i.e. UTRA, E-UTRA and NR.

Rel-6/7: UMTS only (no changes needed, also no changes possible as these releases are no longer maintained)

Rel-8/9/10/11/12/13/14: UMTS and E-UTRA/LTE

Rel-15: UMTS, E-UTRA/LTE and NR

Note: The TSs 25.4.6x are turned into empty specifications referring to the new created TSs 37.46x.

The TSs 25.46x are not withdrawn so references to these specs will lead to the correct specs.

Additional remarks:

1. This transfer of data over 8 releases is an exceptional case: Instead of creating Rel-8 specs and step-by-step upgrade to higher releases via CRs (which would be the normal approach), it was decided with the specs manager to bring v1.N.0 of TS 37.46x for 1-step approval to RAN #83 and instead of approving them to vN.0.0 it was decided to approve them the same version as the last 25.46x version that is created via the CRs.

2. The text shown in TS 37.46x is taken 1:1 from the corresponding TS 25.46x showing changes of the contents via revision marks (note: spec cover and history adaptations are done without revision marks). The changes are mainly to indicate the considered RATs in the scope, to replace 25.46x references by 37.46x references and to correct obvious problems. Further technical changes of the contents of the specifications may rather be considered in a future cat.F CR (and probably just focusing on the latest releases).

3. There is also a TS 25.463 which exists for Rel-6 and Rel-7 only. TS 25.466 replaced TS 25.463 in Rel-7 and future releases. This means for Rel-6 TS 25.463 is still valid and cannot be withdrawn. Rel-7 is no longer maintained i.e. no CRs are possible i.e. 3GPP internal references to TS 25.463 could not be corrected anymore, so also 25.463 Rel-7 will not be withdrawn but it will be clarified on the 3GPP webpage that for Rel-7 TS 25.466 should be considered instead of TS 25.463.

4. References of Rel-16 and higher should refer to TS 37.46x instead of TS 25.46x. Changes of existing references of Rel-8 to Rel-15 specifications of TS 25.46x may be corrected to references to TS 37.46x but such a change is not mandatory as 25.46x Rel-8 to Rel-15 will remain. A further upgrade of 25.46x Iuant specs to Rel-16 and higher will not be considered. Rel-16 and higher specifications shall refer to TS 37.46x.

Following this transfer, RAN3 agreed to transfer the ownership of the clauses currently owned by RAN4 in TS 37.461 back to RAN3. RAN3 informed RAN4 by LS (R3-191145).

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820071

[1] R3-190104 Presentation of Specifications to TSG: TS 37.460 v1.N.0, TS 37.461 v1.N.0, TS 37.462 v1.N.0, TS 37.466 v1.N.0 (N=8/9/a/b/c/d/e/f) ETSI MCC, Huawei, Ericsson

19.2.2 Introduction of GSM, UTRA, E-UTRA and NR capability set(s) (CS(s)) to the multi-standard radio (MSR) specifications

830086

Introduction of GSM, UTRA, E-UTRA and NR capability set(s) (CS(s)) to the multi-standard radio (MSR) specifications

MSR_GSM_UTRA_LTE_NR

R4

RP-190642

Ericsson

Summary based on the input provided by Ericsson in RP-191816.

The WI added support for MSR BS including GSM, UTRA, E-UTRA and NR combinations by means of creating two new CS, CS 18 (GSM+E-UTRA+NR) and CS19 (UTRA+E-UTRA+NR).

The WI created two new capability sets, CS 18 (GSM+E-UTRA+NR) and CS19 (UTRA+E-UTRA+NR). A BS with multiple connectors can support all 4 RATs by transmitting CS18 on at least one connector and CS19 on at least one connector. To add these CS, the following was needed:

  • Updating of the MSR core specification to include correct OBUE emissions tables for GSM/UTRA when operating together with MSR as well as some fixes to the blocking and RX IM requirements.
  • Introduction in the conformance specification of:
    • The new capability sets
    • Test configurations relating to the new capability sets
    • Test applicability rules relating to the new capability sets and test configurations
    • Updated test requirements corresponding to the core requirement updates.

All of the new functionality was introduced in the two approved CRs in [1] and [2].

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830086,830186,830286

[1] R4-1908049 Introduction of requirements for NR + UTRA/GSM combinations, Ericsson, Nokia, Nokia Shanghai Bell, Vodafone, ZTE

[2] R4-1910476 Introduction of requirements for NR + UTRA/GSM combinations, Ericsson, Nokia, Nokia Shanghai Bell, Vodafone, Huawei

19.2.3 Direct data forwarding between NG-RAN and E-UTRAN nodes for inter-system mobility

820072

Direct data forwarding between NG-RAN and E-UTRAN nodes for inter-system mobility

Direct_data_fw_NR

R3

RP-182886

Ericsson

Summary based on the input provided by Ericsson in RP-192162.

This WI specified direct data forwarding per bearer during inter-system mobility between NG-RAN and E-UTRAN nodes in addition to the solution for indirect data forwarding specified in Rel-15 during the NR WI.

This WI continued discussions on direct data forwarding between NG-RAN and E-UTRAN nodes during the Rel-15 discussions on the NR WI. Direct data forwarding encompasses the following two main features:

– While data forwarding between NG-RAN and E-UTRAN nodes in Rel-15 foresees establishing the data forwarding path via the EPC and the 5GC, direct data forwarding allows establishing the data forwarding path directly between the involved RAN nodes, without the need to interact with user plane functions of the EPC and the 5GC.

– Indirect data forwarding for inter-system handover in Rel-15 foresees transporting to be forwarded user plane data between the NG-RAN node and the UPF via PDU Session tunnels. As forwarding paths on the E-UTRAN side are established on a per-E-RAB basis, the Rel-15 solution requires interworking functions at the UPF and the NG-RAN node in order to map per-DRB / per-E-RAB packets to the per-PDU Session tunnel and vice versa. Such interworking is not necessary in case of direct data forwarding.

In the course of the WI RAN3 realised that direct data forwarding tunnel related information may be communicated between the NG-RAN node and the 5GC in a way that the inter-system handover signalling performance benefits from such approach, which was realised in the agreed CRs in [3] and [4].

Further, SA2 and CT4 where contacted to perform necessary work in their areas of responsibility [5].

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820072

[1] RP-182886 "New WID: Direct data forwarding for inter-system mobility", approved at RAN#82

[2] RP-191369 "Status report of WI: Core part: Direct data forwarding between NG-RAN and E-UTRAN nodes for inter-system mobility"

[3] R3-192626 "Support of Direct Data forwarding for handover between 4G and 5G", agreed CR0041r4 38.413

[4] R3-193272 "Introduction of direct and indirect data forwarding for inter-system HO between EPS and 5GS", endorsed CR 38.300

[5] R3-193284 "LS on Finalization of Direct Data Forwarding feature", agreed LS out to SA2 and CT4

19.2.4 eNB(s) Architecture Evolution for E-UTRAN and NG-RAN

Unique_ID

Name

Acronym

WG

WID

WI Rapporteur

790054

eNB(s) Architecture Evolution for E-UTRAN and NG-RAN

LTE_NR_arch_evo

R3

RP-180531

China Unicom

Summary based on the input provided by China Unicom in RP-192964.

In Rel-15, the F1 interface was standardized in the gNB (LTE) to support gNB-CU and gNB-DU split, i.e. to split the Control Unit from the Data Unit (supporting the user data).

Similarly, in Rel-16, the W1 interface is standardized in the ng-eNB (5G) to support ng-eNB-CU and ng-eNB-DU split.

These two interfaces adopt the same higher layer split architecture for between PDCP and RLC, with similar functionalities, such as control plan functionalities.

The ng-eNB-CU and gNB-CU could be physically collocated, deployed in a same physical "box". This unification of the , as to unify the ng-eNB and gNB architectures would simplify the network deployment complexity and facilitate hardware upgrades.

The W1 interface specifications includes the general aspects and principles (TS 37.470), W1 layer 1 (TS 37.471), signalling transport (TS 37.472) and W1AP aspects (TS 37.473). The general aspects and principles and W1 layer1 are aligned with F1 interface. For signalling transport, the W1-C signalling bearer aligned with F1 interface, function and protocol stack in figure 1 are defined.

Figure 1: W1-C signalling bearer protocol stack

The functionalities of W1 interface are supported over W1-C and W1-U (in a similar way as for the F1 interface).

The W1-C functionalities are the following:

  1. Interface management: W1 setup, eNB-CU/eNB-DU configuration update, error indication function, reset function coordination function.
  2. system information management: system information is critical for high layer split architecture, eNB-DU is responsible for transmitting MIB, SIB1, SIB2, SIB3, SIB8 and SIB 16. Other system information is responsible by ng-eNB-DU.
  3. Paging function: The eNB-DU is responsible for transmitting the paging information. While, the eNB-CU provides paging information to enable the eNB-DU to calculate the exact PO and PF.
  4. UE context management function: The W1 UE context management function supports the establishment and modification of the necessary overall UE context.
  5. RRC message transfer function: RRC message transfer function supports the establishment and modification of the necessary overall UE context. This function allows to transfer RRC messages between eNB-CU and eNB-DU.
  6. Warning message information transfer function: This function allows to cooperate with the warning message transmission procedures over NG interface.

The W1-U functionalities are specified as below:

  1. Transfer of user data: The functionalities are used to transfer of user data between ng-eNB-CU and ng-eNB-DU.
  2. flow control function: It is designed for control the downlink user data flow to the ng-eNB-DU.

More detail procedures and IEs for W1 can be founded in TS 37.473 on W1AP specification.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=790054

[1] The WID

[2] RP-191972 Status report for WI Core part: eNB(s) Architecture Evolution for E-UTRAN and NG-RAN WI (China Unicom)

[3] R3-187270 pCR to 37.470 on W1AP functions and procedures (Huawei, China Unicom, TIM)

[4] R3-191163 pCR to 37.470 on W1AP functions and procedures(Huawei, TIM, China Unicom)

[5] R3-193174 pCR to 37.470 on W1AP functions and procedures (Huawei, China Unicom, Orange, TIM)

[6] R3-194676 pCR to 37.470 on W1 general aspects and principles (China Unicom)

[7] R3-194678 pCR to 37.472 on W1 signalling transport (China Unicom)

[8] R3-194425 pCR to 37.470 on W1AP functions (Huawei, China Unicom, TIM)

[9] R3-194426 pCR for 37.473 on UE context management procedures (Huawei, China Unicom, TIM)

[10] R3-194427 pCR for 37.473 on Interface Management procedures (Huawei, China Unicom, TIM)

[11] R3-194565 Structure pCR for TS 37.473 (Huawei, China Unicom, TIM)

[12] R3-194562 pCR to 37.470 on W1AP functions (Huawei, China Unicom, TIM, Orange)

[13] R3-194563 pCR for 37.473 on UE context management procedures (Huawei, China Unicom, TIM, Orange)

[14] R3-194564 pCR for 37.473 on Interface Management procedures (Huawei, China Unicom, TIM, Orange)

[15] R3-197544 pCR to 37.473 on ASN.1 completition (Huawei, China Unicom, TIM)

[16] R3-197636 pCR to 37.473 on miscellaneous correction to contexts (Huawei, China Unicom, Orange, TIM)

[17] R3-197544 CR to 38.401 on corrections to ng-eNB deployment (Huawei, China Unicom, Orange, TIM)

19.2.5 High power UE (power class 2) for EN-DC (1 LTE TDD band + 1 NR TDD band)

820079

High power UE (power class 2) for EN-DC (1 LTE TDD band + 1 NR TDD band)

ENDC_UE_PC2_TDD_TDD

R4

RP-190315

CMCC

Summary based on the input provided by CMCC in RP-200214.

This WI contains a general part and band specific combination part for high power UE (power class 2) for EN-DC (1 LTE TDD band + 1 NR TDD band). The purpose is to introduce high power UE (power class2) for EN-DC (1 LTE TDD band +1 NR TDD band). The actual requirements are added to the corresponding technical specifications.

The purpose of this WI on High power UE (power class 2) for EN-DC (1 LTE TDD band + 1 NR TDD band) is to improve the UP coverage of 5G UE. In order to reduce the big imbalance between 5G NR uplink and downlink coverage, we can improve uplink coverage by defining high power UE for SA and NSA, and it is a feasible way to improve the uplink coverage. This PC2 EN-DC (TDD+TDD) feature will meet the operator’s deployment request for uplink coverage enhancement.

In this work item, we focus on the PC2 EN-DC RF requirements including UE maximum output power, Tx power tolerance, MPR, A-MPR, configured output power, ACLR, SAR and n41-B40 UE-UE co-existence for Power Class 2 EN-DC.

There are two important issues that have been addressed in this topic, and in the end we have resolved them through appropriate solutions

For SAR issue, RAN4 specified UE Tx duty cycle requirements sufficient to prevent exceeding local regulatory limits such as SAR for inter-band PC2 EN-DC UE.

For PC2 EN-DC (TDD+TDD) release independent issue, RAN4 reached a conclusion that PC2 inter-band EN-DC (LTE TDD PC3 + NR TDD PC3) can be supported from Rel-15 in release independence manner.

This WI was completed in the RAN#86 meeting and the complete version of NR Technical Report 37.825 has been approved.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820079

[1]R4-1913208 TR 37.825 v0.4.0 Finalization, CMCC, RAN4#93

[2]R4-1915992 CR for adding solutions for addressing SAR issue for EN-DC PC2 UE, CATT,CMCC, RAN4#93

[3]R4-1913209 CR for REL-16 TS 38.307 for PC2 EN-DC TDD+TDD, CMCC, RAN4#93

[4]R4-1913210 CR for REL-15 TS 38.307 for PC2 EN-DC TDD+TDD, CMCC, RAN4#93

[5]RP-192583Presentation of TR 37.825 V1.0.0,CMCC,RAN#86

19.2.6 LTE-NR & NR-NR Dual Connectivity and NR Carrier Aggregation enhancements

800088

LTE-NR & NR-NR Dual Connectivity and NR Carrier Aggregation enhancements

LTE_NR_DC_CA_enh

R2

RP-191600

Ericsson

800188

Core part: LTE-NR & NR-NR Dual Connectivity and NR CA enhancements

LTE_NR_DC_CA_enh-Core

R2

RP-190452

Ericsson

800288

Perf. part: LTE-NR & NR-NR Dual Connectivity and NR CA enhancements

LTE_NR_DC_CA_enh-Perf

R4

RP-190452

Ericsson

Summary based on the input provided by Ericsson in RP-202039.

The LTE and NR Work Item [1] introduces enhancements to Multi-RAT Dual Connectivity (MR-DC) and Carrier Aggregation (CA) operation, mainly focusing on reducing setup delays and improving robustness and deployment flexibility. This is addressed by introducing idle/inactive measurements for DC/CA, allowing SCG/SCell configuration during transition from idle/inactive state, introducing dormant SCell in NR, introducing fast recovery from MCG link failure, introducing support for asynchronous NR-DC operation and cross carrier scheduling with different numerologies. Changes triggered by the work item are captured into TS 36-, 37- and 38-series specifications.

The key functionalities introduced in this work item include the following:

• Support for asynchronous NR-DC: Allowing non-co-located deployments by relaxing synchronization requirements for gNBs involved in NR-DC operation. Both semi-static and dynamic uplink power control is supported for deployments with bands of the same frequency range in MCG and SCG.

• Idle/inactive measurement reporting: Allowing the eNB to assign UE to do measurements during IDLE or INACTIVE that the network can use for when the UE enters CONNECTED mode.

o This may include limitations on which cells are measured, how long the measurements are done and in which cells the measurements are applicable.

o UE can indicate the availability of the measurements at connection setup or resume, and network can decide whether to query them via RRC reporting.

• Direct SCG/SCell configuration: Allowing the network to configure the UE to store the SCG/SCell configuration upon transition to INACTIVE state, so that it can be quickly restored upon transition back to CONNECTED, thus minimizing signaling overhead and latency.

• NR SCell Dormancy: SCell dormancy is introduced for NR. The UE does not monitor PDCCH on the dormant BWP for an SCell, but continues performing RRM/CSI measurements, AGC and beam management, if configured.

o Switching between dormant and normal operation is network controlled and reuses the existing Bandwidth Part (BWP) framework of NR. One dormant BWP can be configured for an SCell. DCI is used to control entering/leaving the dormant BWP.

o The SpCell and PUCCH SCell cannot be configured with a dormant BWP.

• Fast MCG link recovery: Support fast recovery from MCG link failure by allowing the UE in MR-DC to send an MCG Failure Information message to the MN via the SCG upon the detection of a radio link failure on the MCG. Based on measurement information received in MCG Failure Information message the network can then determine the correct action to restore the MCG connection, e.g. change of PCell.

o Fast MCG link recovery requires that both UE and network support the feature, and that the UE is configured with either split SRB or SCG SRB.

o The UE initiates the RRC connection re-establishment procedure if it does not receive a reconfiguration message from the network within a certain time after fast MCG link recovery was initiated.

• Cross-carrier scheduling with different numerologies: Support for cross carrier scheduling in carrier aggregation, with different numerology on the scheduling and scheduled carriers.

• CA with unaligned frame boundary: Support for NR inter-band carrier aggregation with slot alignment, but with unaligned frame boundary and partial SFN alignment.

• Enhancements to single Tx switched uplink for EN-DC: Various improvements introduced for using the reference TDD pattern, e.g. support is added for LTE TDD PCell and for dual-Tx UL. LTE PRACH operation is not restricted by the reference TDD pattern.

• Aperiodic CSI-RS triggering with different numerologies: Support for triggering Aperiodic CSI-RS with different numerology between CSI-RS and triggering PDCCH is introduced.

• Minimum requirements for NR-DC: RF requirements for both synchronous and asynchronous operations.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800088,800188,800288

[1] RP-200791, Revised WID on DC and CA enhancements, Ericsson, RAN#88e

19.2.7 29 dBm UE Power Class for LTE band 41 and NR Band n41

800078

29 dBm UE Power Class for LTE band 41 and NR Band n41

LTE_NR_B41_Bn41_PC29dBm

R4

RP-201134

Sprint

800178

Core part: 29 dBm UE Power Class for LTE band 41 and NR Band n41

LTE_NR_B41_Bn41_PC29dBm-Core

R4

RP-201134

Sprint

Summary based on the input provided by T-Mobile USA in RP-201905.

This WI created the requirements for 29 dBm PC1.5 for intra-band EN-DC, NR UL MIMO and NR Tx Diversity including MPR and A-MPR and allows for 29 dBm UE transmit power for TDD bands, including:

• The introduction of 29 dBm power class 1.5 for intra-band EN-DC, NR UL MIMO and NR TxD

• MPR for PC1.5 intra-band EN-DC

• A-MPR for PC1.5 intra-band EN-DC for NS_04 Band 41/n41

• MPR for PC1.5 UL MIMO and Tx Diversity

• A-MPR for PC 1.5 for UL MIMO and Tx Diversity for NS_04 Band 41/n41

• Additional requirements including EVM, behavior related to PC2, P-Max and maxUplinkDutyCycle, ACLR

• Release independence to Rel-15 for PC1.5 intra-band EN-DC, NR UL MIMO and NR Tx Diversity

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800078,800178

[1] TR 38.817-01, “General aspects for User Equipment (UE) Radio Frequency (RF) for NR,” 3GPP

[2] RP-201904, “Status report for 29 dBm UE Power Class for LTE band 41 and NR Band n41,” T-Mobile USA (rapporteur)

19.2.8 LTE/NR Dynamic Spectrum Sharing (DSS) in band 48/n48 frequency range

860060

LTE/NR spectrum sharing in band 48/n48 frequency range

NR_n48_LTE_48_coex

R4

RP-201858

Apple

860160

Core part: LTE/NR spectrum sharing in band 48/n48 frequency range

NR_n48_LTE_48_coex

R4

RP-201858

Apple

Summary based on the input provided by Apple Inc. in RP-202581.

Dynamic spectrum sharing (DSS) is an important feature that allows for sharing existing spectrum between the LTE and NR carriers, thus enabling smoother transition from LTE and faster adoption of NR. After the RAN#86 meeting, a new WI was agreed [1] aiming to analyse and introduce, if needed, changes to support dynamic spectrum sharing in band 48/n48 frequency range, which is also known as the CBRS band.

The first version of the WI had the following objectives:

– Channel raster: Confirm that NR channel raster can be aligned with LTE centre frequencies [RAN4];

– UL shift: Specify UL 7.5kHz sub-carrier shift for 15kHz SCS. Investigate whether the 7.5kHz sub-carrier shift has any impact on the needed guard between LTE and 30kHz SCS NR. Specify the shift only if there is a clear benefit [RAN4];

– Sync raster: Check mechanisms to avoid overlapping transmissions between NR SSB and LTE CRS. Apply changes to ensure non overlap of NR SSB and LTE CRS if determined that solutions with existing specifications are insufficient [RAN4].

Referring to the sync raster discussion, no consensus was reached by the RAN4#96 meeting on whether e.g. the sync pattern B can be added into band n48 definition to mitigate the negative impact of colliding NR SSB and 4-port LTE CRS transmission. The majority of companies preferred not to introduce this change at least to band n48. And even though some companies could accept sync pattern related modifications if a new band is introduced, there were concerns on whether adding a new band is a right way forward. It was decided to remove this aspect from the scope of the WI.

For the UL 7.5kHz shift, it was concluded to introduce this functionality into band n48 following the CBRS Alliance agreement to add 15kHz SCS as one of the mandatory deployment options. Following the outcome of similar discussions for band n38 and n40, the UL shift is enabled only for 15kHz SCS and is not supported for 30kHz SCS.

As for the DL channel raster alignment, RAN4 conclusion was that it is possible to shift, if needed, the centre frequency by -/+100kHz to align LTE and NR sub-carriers when SAS allocates the channel which is not on the common 300kHz raster point. RAN4 also concluded that there is no specification impact for DL transmission, i.e. it is up to the base station how to ensure emission requirements when the centre frequency is shifted by -/+100kHz. For the UL transmission, RAN4 discussed how to ensure UE emission requirements and concluded that "for the dynamic spectrum sharing operation in band 48/n48 frequency range, what is supported in NR for both BS and UE can ensure UE emission requirements through appropriate configuration/scheduling".

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=860060,860160

[1] RP-192427, "New WID: LTE/NR spectrum sharing in band 48/n48 frequency range", Apple Inc

[2] RP-202580, "Status report for LTE/NR spectrum sharing in band 48/n48 frequency range", RAN WG4

19.3 LTE-related Release 16 Features

19.3.1 LTE-based 5G terrestrial broadcast

830076

LTE-based 5G terrestrial broadcast

LTE_terr_bcast

R1

RP-190732

Qualcomm

800091

Study on LTE-based 5G terrestrial broadcast

FS_LTE_terr_bcast

R1

RP-181342

Qualcomm

830176

Core part: LTE-based 5G terrestrial broadcast

LTE_terr_bcast-Core

R1

RP-190732

Qualcomm

830276

Perf. part: LTE-based 5G terrestrial broadcast

LTE_terr_bcast-Perf

R4

RP-190732

Qualcomm

Summary based on the input provided by Qualcomm Incorporated in RP-200850.

The work item on “LTE-based 5G terrestrial broadcast” [1] specified enhancements on top of Rel-14 MBMS [2] to meet the 5G requirements for broadcast systems [3]. These enhancements, obtained as a result of the study in [4], are summarized as follows:

– Introduction of a new numerology for PMCH with 100us cyclic prefix and 2.5kHz subcarrier spacing for support of high mobility scenarios (up to 250km/h).

– Introduction of a new numerology for PMCH with 300us cyclic prefix and approximately 0.37kHz subcarrier spacing for support of rooftop reception.

– Enhancements to PBCH and PDCCH to increase robustness in low SINR scenarios.

This work item also produced a TR [5] summarizing the overall aspects of LTE-based 5G terrestrial broadcast.

Numerology for high speed reception

A new numerology for PMCH with 100us cyclic prefix, 400us OFDM core symbol duration, and 2.5kHz subcarrier spacing is introduced to support high mobility scenarios (up to 250km/h). With this numerology, each OFDM symbol uses one slot (0.5ms), and a transport block is mapped to two OFDM symbols (1ms).

Associated to this new numerology, a single reference signal pattern (MBSFN-RS) is introduced with a time-stagger length of 2, and a frequency separation (after de-staggering) of 4 subcarriers, which gives a maximum theoretical equalization interval of 200us.

Numerology for rooftop reception

A new numerology for PMCH with 300us cyclic prefix, 2700us OFDM core symbol duration, and approximately 0.37kHz subcarrier spacing is introduced to support rooftop reception, especially tailored for deployments with large inter-site distance (e.g. HPHT-1 as defined in [4], with an inter-site distance of 125km).

With this new numerology, a new variation of frame structure type 1 is introduced. This frame structure consists of, every 40ms:

– One subframe (1ms) with 15kHz SCS, containing synchronization and system information, also named “cell acquisition subframe” (CAS)

– 13 slots (3ms each) carrying the PMCH with 0.37kHz SCS. Note that the time-transmission interval (TTI) for a transport block is extended to 3ms.

This frame structure is depicted in Figure 1

Four radio frames = 40ms

One 3ms slot, one symbol per slot

#0

One 1 ms subframe

#12

…………

#2

#1

#1

CAS

Figure 1: Frame structure type 1 for transmissions using f = 0.370 kHz.

Two reference signal patterns are introduced associated with this new numerology, with a stagger length of 2 and 4 OFDM symbols. Both of them have a frequency separation (after de-staggering) of 3 subcarriers, which gives a maximum theoretical equalization interval of 900us.

Enhancements to cell acquisition subframes

As shown in [4], in some deployment scenarios the CAS will experience significantly lower SINR than PMCH due to the former being based on 15kHz subcarrier spacing. Several enhancements are introduced to enhance the performance of the CAS, and are detailed as follows:

– Semistatic CFI: A semistatic value for CFI (which determines the number of symbols to be used for PDCCH in a given subframe) is indicated in MIB. This allows the UE to skip PCFICH decoding, which can become the bottleneck in low SINR conditions.

– Aggregation level 16: Before Rel-16, the maximum aggregation level for PDCCH was 8. Rel-16 introduces aggregation level 16 (only for MBMS dedicated cells) to enhance performance in low SINR conditions.

– PBCH repetition: Similar to the scheme defined for eMTC (but with additional symbol-level rotation for interference randomization), PBCH is repeated in CAS.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830076,800091,830176,830276

[1] RP-193050: “Revised WID on LTE-based 5G terrestrial broadcast”, RAN#86

[2] RP-160675, “New WID: eMBMS enhancements for LTE”

[3] TR 38.913: "Study on scenarios and requirements for next generation access technologies"

[4] TR 36.776: “Evolved Universal Terrestrial Radio Access (E-UTRA); Study on LTE-based 5G terrestrial broadcast”

[5] TR 36.976: “Overall description of LTE-based 5G broadcast”

19.3.2 Support for NavIC Navigation Satellite System for LTE

850072

Support for NavIC Navigation Satellite System for LTE

LCS_NAVIC

R2

RP-192408

Reliance Jio

850172

Core part: Support for NavIC Navigation Satellite System for LTE

LCS_NAVIC-Core

R2

RP-192408

Reliance Jio

850272

Perf. part: Support for NavIC Navigation Satellite System for LTE

LCS_NAVIC-Perf

R4

RP-192408

Reliance Jio

Summary based on the input provided by Reliance Jio in RP-200604.

The LCS_NAVIC feature introduces NavIC satellite system specific assistance data support used by the location server to enable UE-based and UE-assisted A-GNSS positioning methods in E-UTRAN. This is applicable to both Control plane and User plane positioning. Before this work item EUTRAN A-GNSS methods supported assistance data for only for GPS, Galileo, GLONASS, BDS, SBAS & QZSS constellations.

Introduction of NavIC satellite system assistance data speeds up positioning performance, improves receiver sensitivity and helps to conserve battery power.in UEs supporting NavIC RNSS for positioning.

The LCS_NAVIC feature is applicable only to LTE UEs using L5 band GNSS reception for positioning and has been standardized starting from Rel-16.

3GPP TSG RAN has introduced A-GNSS support for BDS, Galileo, GLONASS, GPS, SBAS & QZSS to cellular positioning systems. The LCS_NAVIC feature introduces NavIC constellation support under the existing framework of A-GNSS.

The key updates introduced under this feature are as follows:

1) The support for NavIC satellite system has been added to the A-GNSS specifications by assignment of new ‘GNSS ID’, ‘GNSS Signal ID’, and ‘GNSS Time ID’, together with ASN.1 extensions to existing assistance data elements.

2) NavIC specific New Clock Model, Orbit Model, Almanac Model, UTC model update, Differential corrections and Ionospheric Model have been added to existing assistance data elements.

3) The GNSS-GenericAssistData used by the location server to aid data for a specific GNSS has been updated by introducing NavIC satellite system specific Differential corrections & Grid model.

4) Positioning assistance data broadcast has been extended to include NavIC satellite system specific generic assistance data by introduction of two new Positioning System Information Block Type 2 as listed below:

posSibType

assistanceDataElement

GNSS Generic Assistance Data

posSibType2-24

NavIC-DifferentialCorrections

posSibType2-25

NavIC-GridModelParameter

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=850072,850172,850272

[1] TS 37.355: LTE Positioning Protocol (LPP); Protocol specification

[2] RP-200439: SR LCS_NAVIC, Reliance Jio

19.3.3 Even further mobility enhancement in E-UTRAN

800089

Even further mobility enhancement in E-UTRAN

LTE_feMob

R2

RP-200148

China Telecom

800189

Core part: Even further mobility enhancement in E-UTRAN

LTE_feMob-Core

R2

RP-200148

China Telecom

800289

Perf. part: Even further mobility enhancement in E-UTRAN

LTE_feMob-Perf

R4

RP-200148

China Telecom

Summary based on the input provided by China Telecom in RP-200738.

The work item on Even further mobility enhancement in E-UTRAN [1] studies solutions to meet both the reliability and very low HO interruption time requirements in the Study Phase, and specifies the chosen solutions, i.e., Dual Active Protocol Stack (DAPS) handover to reduce interruption time during HO and Conditional Handover (CHO) to improve HO reliability and robustness in the Work Phase.

The corresponding changes are captured into TS 36-series specifications.

Dual Active Protocol Stack (DAPS) handover

DAPS Handover is a handover procedure that maintains the source eNB connection after reception of RRC message for handover and until releasing the source cell after successful random access to the target eNB.

– If DAPS handover is configured, the UE continues the downlink user data reception from the source eNB until releasing the source cell and continues the uplink user data transmission to the source eNB until successful random access procedure to the target eNB.

– Upon reception of the handover command, the UE:

– Creates a MAC entity for target cell;

– Establishes the RLC entity and an associated DTCH logical channel for target cell for each DRB configured with DAPS;

– For the DRB(s) configured with DAPS, reconfigures the PDCP entity to configure DAPS with separate security and ROHC functions for source and target and associates them with the RLC entities configured for source and target respectively;

– Retains rest of the source link configurations until release of the source.

– When DAPS handover fails, the UE falls back to source cell configuration, resumes the connection with source cell, and reports the DAPS handover failure via the source without triggering RRC connection re-establishment if the source link is still available; Otherwise, RRC re-establishment is performed;

Conditional Handover (CHO)

A Conditional Handover (CHO) is defined as a handover that is executed by the UE when one or more handover execution conditions are met.

– UE maintains connection with source eNB after receiving CHO configuration, and starts evaluating the CHO execution condition(s) for the CHO candidate cell(s) and executes the HO command once the execution condition(s) are met for a CHO candidate cell.

– To improve the robustness, the network can provide the up to 8 candidate cell configuration(s) associated with execution condition (s) to UE. If at least one CHO candidate cell satisfies the corresponding CHO execution condition, the UE detaches from the source eNB, applies the stored corresponding configuration for that candidate cell and synchronises to that candidate cell. UE stops evaluating the execution condition(s) for other candidate cells once the handover is triggered.

– The UE accesses to the target eNB and completes the handover procedure by sending RRCConnectionReconfigurationComplete message to target eNB. The UE releases stored CHO configurations after successful completion of RRC handover procedure.

– When initial CHO execution attempt fails or HO fails, if network configured the UE to try CHO after HO/CHO failure and the UE performs cell selection to a CHO candidate cell, the UE attempts CHO execution to that cell; Otherwise, RRC re-establishment is performed.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800089,800189,800289

19.3.4 DL MIMO efficiency enhancements for LTE

800086

DL MIMO efficiency enhancements for LTE

LTE_DL_MIMO_EE

R1

RP-182901

Huawei

800186

Core part: DL MIMO efficiency enhancements for LTE

LTE_DL_MIMO_EE-Core

R1

RP-182901

Huawei

800286

Perf. part: DL MIMO efficiency enhancements for LTE

LTE_DL_MIMO_EE-Perf

R4

RP-182901

Huawei

Summary based on the input provided by Huawei, HiSilicon in RP-200885.

MIMO is an effective technique to improve spectral efficiency and increase overall network capacity. SRS can be utilized to improve DL MIMO performance, especially for massive MIMO in TDD. In this WI [1], SRS capacity and coverage are enhanced by introducing more than one SRS symbol in a UL normal subframe and introducing virtual cell ID for SRS [2].

More than one symbol for SRS in a UL normal subframe

With the introduction of more than one SRS symbol in a UL normal subframe, the SRS capacity and coverage can be increased. These additional SRS symbol(s) are referred to as trigger type 2 SRS.

1 to 13 symbols of the first 13 symbols of a UL normal subframe can be configured to a UE for aperiodically triggered SRS transmission. Intra-subframe repetition, frequency hopping and antenna switching of the additional SRS symbols can be supported. A guard period of one SC-FDMA symbol can be configured for frequency hopping and antenna switching.

The number of repetitions can be configured from the set {1, 2, 3, 4, 6, 7, 8, 9, 12, 13}. If a UE has more receive antennas than transmit chains (e.g. 1T2R), the UE can be configured to transmit the additional SRS with antenna switching. And a UE can additionally be configured with frequency hopping for the additional SRS. The number of antennas (pairs) to switch is:

– 2 for 1T2R, or the number of pairs is configured as 2 for 2T4R

– 3 if the number of pairs is configured as 3 for 2T4R

– 4 for 1T4R

Both legacy SRS and additional SRS can be configured to the same UE, and transmission of legacy SRS and additional SRS symbol(s) in the same subframe for the UE is supported.

For sequence generation, per-symbol group hopping and sequence hopping are supported.

Independent open loop and close loop power control is supported for additional SRS, and DCI formats 3/3A/3B are used for close loop power control.

UEs not configured with SPUCCH/SPUSCH are not expected to be triggered with additional SRS in the same subframe as PUSCH/PUCCH in the same serving cell. UEs configured with SPUCCH/SPUSCH drop the SRS transmission in the symbols colliding with SPUCCH/SPUSCH in the same serving cell.

The additional SRS transmission in the symbols colliding with PUSCH/PUCCH of another serving cell in the same TAG, the same band and with the same CP, is dropped.

The additional SRS transmission in the symbols colliding with PUSCH/PUCCH of another serving cell in the different TAG is dropped if the total transmission power exceeds the PCMAX in any overlapping portion.

Virtual cell ID

Virtual cell ID within the range from 0 to 503 can be configured for SRS to increase SRS capacity.

The virtual cell ID can be configured to only additional SRS symbol(s) or both legacy and additional SRS symbol(s). If virtual cell ID is not configured, the physical cell ID is used.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800086,800186,800286

[1] RP-192766, “WID Revision: DL MIMO efficiency enhancements for LTE”, Huawei, HiSilicon, RAN#86, Sitges, Spain, December, 2019.

[2] R1-1913596, RAN1 agreements for DL MIMO efficiency enhancements for LTE, WI rapporteur (Huawei), RAN1#99, Reno, USA, November, 2019.

19.3.5 Other LTE-only items

Further performance enhancement for LTE in high speed scenario: Covered in the section on Railways.