Debrief from 3GPP RAN #87e: March 2020

This Debrief comes from a standards specialist in the 5G-IA Pre-Standardization WG: Hans van der Veen, NEC Lab Europe as part of the group's efforts to track progress on 5G standardisation, support inputs from 5G PPP technical projects and help gap analyses for future standardisation work. 

This is a summary of RAN#87e (March 2020). Because of the COVID-19 virus, the meeting was held as an email meeting only (more than 1100 emails). The agenda was restricted by excluding Rel-17 topics, except for a discussion on the Rel-17 timeline.

General

E-meeting feedback (Summary: RP-200490)

The RAN2 Chairman summarised the feedback on the handling of WG emeetings.

RAN6 to be closed (Discussion under: RP-200297; Approved WF: RP-200492)

RAN6 will be closed in June 2020. RAN plenary will take over responsibility for all GERAN and UTRAN specifications under the responsibility of RAN6 including corresponding required updates to rapporteur responsibilities. RAN3 and RAN4 keep their responsibilities. A proper "send off/honouring" for GSM and UMTS work will be organised at a future 3GPP RAN F2F plenary.

RAN WGs and RAN plenary schedule Q2

To allow the WGs more time to complete their work with emeetings, a new schedule was agreed by the RAN leadership, as follows. Note that RAN#88 will be turned into an emeeting, RAN#88e, and shifted two weeks later. The SA leadership would like to keep the plenaries in the same week and is considering to move SA#88e also (decision is expected by 3 April).

Rel-16

Rel-16 Planning (aka 5G Phase 2) (delays due to lack of physical meetings (COVID-19))

Stage 1: frozen December 2018 without exceptions

Stage 2: frozen June 2019 with exceptions (all remaining Stage 2 work was completed by March 2020)

RAN1: frozen December 2019

RAN2 and RAN3: freezing target changed from March to June 2020

Stage 3: freezing target changed from March to June 2020

ASN.1 and open APIs: freezing target: June 2020

RAN4: freezing target changed from September to December 2020

Rel-16 (and Rel-17) timeline (Endorsed WF: RP-200493)

The following Rel-16 work was completed and the corresponding SIs and WIs closed:

-     WI core: Physical layer enhancements for NR ultra-reliable and low latency case (URLLC)

-     WI core: Single Radio Voice Call Continuity from 5G to 3G

-     WI core: DL MIMO efficiency enhancements for LTE

-     WI core: LTE-based 5G terrestrial broadcast

-     WI perf.: Further performance enhancement for LTE in high speed scenario

-     WI core: NavIC Navigation Satellite System for LTE

-     WI perf.: NavIC Navigation Satellite System for LTE

Work Item Summaries (descriptions of features in the release after the work has actually finished)

-     RP-200152 Single Radio Voice Call Continuity from 5G to 3G

-     RP-200170 Inter-band CA/DC for 2 bands DL with up to 2 bands UL

-     RP-200173 Inter-band CA/DC for 3 bands DL with 2 bands UL

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

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

NR: Misalignment WGs and Fallback intra band contiguous & non-contiguous FR2 (Discussion: RP-200320; RP-200326)

Misalignment between RAN2 and RAN4. Some companies want RAN2 to work out signalling for FR2 fallbacks within Rel-16. No agreement.; RAN2 is encouraged to continue work on technical solutions. RAN will discuss the status at RAN#88.

NR: Making full rate user plane integrity protection (UP-IP) mandatory (Not agreed WFs: RP-200284; RP-200505)

Operators, asked to make UE support for UP-IP mandatory, originally for architecture options 2,3,5 and 7; later in the week they weakened the request to architecture option 2. Because of a formal objection and concerns from several companies, neither Way Forward was accepted. Note: The discussion took place both in RAN (based on RAN2 involvement) and SA (based on SA3 involvement).

NR: SI 7-24GHz frequency range (SR: RP-200262)

It was discussed how to handle phase noise. It was agreed to conclude this topic in the RAN4 April emeeting and no longer address it in the May emeeting.

NR: NR-U Band Combinations (Disc.: RP-200212; Not approved Revised WID: RP-200312)

The following proposals seem agreeable, though no formal decision was taken and further discussion will take place in RAN4:

Proposal 1: Carry on with NR-U core requirements with emphasis on generic requirements. For the NR-U combinations captured in the current NR-U WID, the TPs will be handled into the corresponding Rel-16 band combination baskets TR. Target a limited set of those band combinations within Rel-16 timeframe for successful completion of the WI.

Proposal 2: Additional NR-U band combinations beyond the ones already documented in the NR-U WID will be entertained once the generic requirements are in place, i.e., no additional band combinations to be added to the WID at this point.

NR: Mandatory features for wide-area IAB nodes (Disc.: RP-200285; RP-200501)

It was endorsed that RAN WGs investigate which of the mandatory Rel-15 UE features (as defined in TR 38.822) can be optional for basic operation of (and if found useful, for different classes of IAB-MTs as defined by RAN4); and that RAN WGs should strive to minimise specification impact. There are differing views on how UE capabilities exactly relate to IAB nodes and how to formulate this relation.

NR: Transient period (Disc.: RP-200281; RP-200245; Not approved Company CR: RP-200261)

There is no consensus on whether the transient time capability is feasible to test or not. RAN4 to continue discussing feasibility of testing the transient periods in RAN4 during Q2 and report outcome at RAN#88.

NR: Performance requirement enhancement (Revised WID: RP-200472)

The approved revised WID includes a possibility to study the definition of power imbalance demodulation requirements for FR1 intra-band non-contiguous EN-DC scenarios.

NR: UE Capabilities (Informational summary: RP-200502)

The main discussion was about "Feature groups". The moderator of the email discussion provided an "informational" summary:

• Terminology definitions based on Rel-15 (TR38.822)
  
  • “Feature(s)”: It is a highest level grouping. In Rel-16, it is per-WI grouping.
  • “Feature group(s)”: It is a kind of “subfeature(s)” within a “feature”, and is defined by each row in the UE features list.
  • “Component(s)”: One feature group contains one or multiple components. When UE reports support of the feature group, basically it is applied to all components in the feature group.
• In case that a set of feature groups/components is necessary to be supported by UE (and NW) for a certain purpose,
  
  • There are at least two possible approaches below to define the set of feature groups for a purpose.
    • Approach 1: A basic feature group(s), which is a set of components that are viewed necessary to provide a minimum level of support for the feature. Defining a basic feature group(s) is not always possible or necessary for a given feature.
    • Approach 2: A set(s) of feature groups necessary to be supported for the purpose is defined somewhere in specification(s).
  • Each WG is responsible on whether/how to define the basic feature group(s) or the set(s) of feature groups, and it is possible to take different decision on approaches (including possibility to not define any basic feature group or set) for different purposes/features. It is preferable to take common approach across WGs for same feature/purpose.
    • The Plenary guidance may be requested, if needed after WG discussions, on whether defining a set of feature groups based on Approach 2 for some feature, either in addition or instead of approach 1. There has been no conclusion in previous discussions, including RAN 87e, that it would be necessary.
  • Irrespective of defining a set of feature groups for a purpose, capability bit(s) should be defined for each of feature groups independently.
• For each feature group (capability bit(s)) defined as “mandatory with capability signaling”, each WG should take either one of following approaches.
  
  • Approach 1: default value should be defined in each WG for the case where UE does not report or the case before UE reports.
  • Approach 2: the capability signaling is mandatory present so that UE must report.

Rel-17

Rel-17 Planning (delays due to lack of phyiscal meetings (COVID-19))

Stage 1: frozen December 2019 with exceptions (2 SA1 items still open: eCAV, MPS2)

RAN "Feature Packaging" ("Content definition") achieved December 2019 and definition of "inter-TSG coordination areas" started (to be progressed further by June 2020)

Stage 2: freezing target December 2020

RAN1: freezing target changed from March to June 2021

RAN2 and RAN3: freezing target changed from June to September 2021

Stage 3: freezing target September 2021

ASN.1 and open APIs: freezing target December 2021

RAN4: freezing target changed from December 2021 to March 2022

Rel-17 timeline (Endorsed WF: RP-200493)

See the picture under Rel-16 timeline above.