5G - Agreed Items                                                          Home : www.sharetechnote.com

 

 

 

 

Agreements 

 

From RAN #84 meeting, a lot of detailed technical proposals start being documented and some of the items reaches the agreement. Most of technical items are yet to be determined, but I am trying to keep track of the agreed items in this page. There would be many items that are not listed here since I haven't gone through all the TDocs from the meeting. I am just putting those items that are closely related to my area.

 

In Mar 2017, several important TRs(RAN1 TR38.802 v2.0, RAN2 TR38.804 v1.0, RAN3 TR38.801 v2.0, RAN4 TR38.803 v2.0) were released consolidating all the agreement and the latest decision for at least Rel 15 specification. So it would be more efficient to read these document right away, but I will keep the existing note as it is so that you can trace the history of those agreements in TDoc level.

Also all the agreement as of Apr 2017 is well consolidated into a single document in R2-1702534 (Ref [21]).  

To help you with the effort to go through the full document, I would add the latest update from those TRs under each of the items.

 

 

New Terminology

 

Followings are from TR 38.804 section 3.

  • gNB : NR Node. Same component as eNB in LTE(4G) 
  • TRxP (TRP) : Transmission Reception Point. Antenna Array (with one or more antenna elements) available to the network located at a specific geographical location. <= You would see this term a lot in many of NR TDocs
  • NextGen Core : Core Network for Next Generation System. Same component as EPC in LTE(4G)
  • Nemerology : Subcarrier spacing (Frequency Domain Structure). <= This is one of the term that confused me a lot when I was reading 5G/NR TDocs.

 

 

Waveform/Modulation

 

According to TR 38.804 (Ref [18]) section 5.3, it is agreed/determined as follows :

  • Support paired and unpaired spectrum
  • Support Multiple Numerology
    • Each of the numerology is derivided by scaling a basic subcarrier spacing
    • The numerology can be selected independently of the frequency band (however it is not assumed to select a very narrow subcarrier spacing in very high frequency. <== this is physically difficult to implement)
  • Support flexible Network and UE channel bandwidth
  • Waveform
    • Downlink : OFDM based waveform
    • Uplink : Choice of two optioins
      • CP-OFDM : At least for eMBB up to 40 GHz, applicable for both single stream and multi stream
      • DFT-S-OFDM : Limited to single stream transmission
  • Modulation
    • Downlink : QPSK, 16 QAM, 64 QAM, 256 QAM with the same constellation mapping as in LTE
    • Uplink : QPSK, 16 QAM, 64 QAM, 256 QAM with the same constellation mapping as in LTE

 

Followings are agreed at RAN1 #85

  • Largest component carrier bandwidth not smaller than 80 Mhz for at least one numerology is supported ([1])
  • Waveform is based on OFDM ([2])
    • Multiple numeralogies are supported
    • Additional functionality on top of OFDM such as DFT-S-OFDM, and/or variants of DFT-S-OFDM. and/or filtering/windowing, and/or OTFS is further considered
      • Complementary non-OFDM based waveform is not precluded for some specific usecases (e.g, mMTC use case)

 

Followings are agreed at RAN1 #86

  • At least up to 40 GHz for eMBB and URLLC services, NR supports CP-OFDM based waveform with Y greater than that of LTE (assuming Y=90% for LTE) for DL and UL, possibly with additional low PAPR/CM technique(s) (e.g., DFT-S-OFDM, etc.)
    • Y is defined as  Y = transmission bandwidth configuration / channel bandwidth * 100% // This indicates how much guardband is required. Y = 90% implies it would require around 10% of guard band.

 

 

Numerology / FrameStructurre / TTI

 

According to TR 38.802 (Ref [17]) section 5.3 and TR 38.804 (Ref [18]) section 5.4.7, it is agreed as follows :

  • Maximum channel bandwidth per NR carrier is 400 Mhz in Rel 15.
  • All details for channel bandwidth up to 100 Mhz per NR Carrier are to be specified in Rel 15
  • One Numerology corresponds to one subcarrier spacing in frequency domain
  • At least for single numerology case, candidates of the maximum numbers of subcarrier is 3300 or 6600 in Rel 15
  • Subframe Duration is fixed to be 1 ms <== this is a little different from what many people expected. It is likely that one TTI length is much shorter than this to meet the latency requirement
  • One TTI duration corresponds to a number of consecutive symbols for one transmission in time domain (TR 38.804 5.4.7)
  • The combination of one numerology and one TTI duration determines how transmission is made on physical layer.
  • Frame Length is fixed to be 10 ms
  • Scalable numerology should allow the subcarrier spacing from 15 Khz to 480 Khz.
  • Number of subcarrier per PRM is 12
  • Number of OFDM symbols per slot may vary depending on subcarrier spacing
    • For subcarrier spacing <= 60, the number of OFDM symbols / slot = 7 or 14
    • For subcarrier spacing > 60, the number of OFDM symbols / slot = 14
  • Slot Aggregation (data transmission scheduling to span one or multiple slots
  • No explicit DC subcarrier is reserved for both Downlink and Uplink
  • All numerologies align on symbol boundaries every 1 ms in NR carrier (regardless of subcarrier spacing and CP-overhead)

 

Followings are agreed at RAN1 #85 <== Now that TR 38.802 is release, you may not need to read following items.. but I will keep this to help you track down the history and background of those decision in 38.802. Especially following through the TDocs mentioned here would give you further details of the background.

  • It is necessary to support more than one values of subcarrier spacing ([2])
  • RAN1 will continue further study and conclude between following alternatives in the next meeting ([2])
    • Alt 1:
      • The subcarrier spacing for the NR scalable numerology should scale as
      • f_sc = f0 x 2^m
        • where
          • f0 is FFS
          • m is an integer chosen from a set of possible values
    • Alt 2:
      • The subcarrier spacing for the NR scalable numerology should scale as
      • f_sc = f0 x M
        • where
          • f0 is FFS
          • M is an integer chosen from a set of possible positive values
  • At least the following should be supported for NR in a frequency portion([4])
    • A time interval X which can contain one or more of the following
      • DL transmission part
      • Guard
      • UL transmission part
    • FFS which combinations are supported and whether they are indicated dynamically and/or semi-statically
    • Furthermore, the following is supported
      • The DL transmission part of time interval X to contain downlink control information and/or downlink data transmissions and/or reference signals
      • The UL transmission part of time interval X to contain uplink control information and/or uplink data transmissions and/or reference signals

 

Followings are agreed at RAN1 #86

  • Followings are considered as starting points of NR frame structure at least within the CP overhead ([12])
    • Subframe
      • Already agreed upon
      • Assume x=14 in the reference numerology for subframe definition (for normal CP)
      • FFS: y=x and/or y=x/2 and/or y is signalled
    • Slot
      • Slot of duration y OFDM symbols in the numerology used for transmission
      • An integer number of slots fit within one subframe duration (at least for subcarrier spacing is larger than or equal the reference numerology)
      • The structure allows for ctrl at the beginning only
      • The structure allows for ctrl at the end only
      • The structure allows for ctrl at the end and at the beginning
      • Other structure is not precluded
      • One possible scheduling unit
    • Mini-slot
      • Should at least support transmission shorter than y OFDM symbols in the numerology used for transmission
      • May contain ctrl at the beginning and/or ctrl at the end
      • The smallest mini-slot is the smallest possible scheduling unit (FFS: smallest number of symbols)
    • Note: the names are for the purpose of discussion. Whether some terms can be merged or not is FFS
    • FFS whether NR frame structure needs to support both slot and mini-slot or these can be merged

 

 

Carrier Aggregation / Dual Connectivity

 

According to TR 38.802 (Ref [17]) section 5.5, it is agreed as follows :

  • Maximum number of Carrier Aggregation / Dual Carrier is 16
  • Maximun aggregated bandwidth in phase 1 is around 1 Ghz (contiguous or non-contiguous)
  • Cross-carrier scheduling and joint UCI feedback is supported
  • Per-carrier TB mapping is supported

 

 

Multiple Access

 

Followings are agreed at RAN1 #85

  • Non-orthogonal multiple access should be investigated for divsersified NR usage scenarios and use case([3])
  • At least for UL mMTC, autonmous/grant-free/contention based non-orthogonal multiple access should be studied ([3])

 

 

MIMO Scheme (Codeword / Layer)

 

According to TR 38.802 (Ref [17]) section 6.1.6.2, it is agreed as follows :

  • The number of codewords per PDSCH assignment per UE
    • 1 codeword for 1 to 4-layer transmission
    • 2 codewords for 5 to 8-layer transmission.
  • DL DMRS based spatial multiplexing (SU-MIMO/MU-MIMO) is supported
    • At least, the 8 orthogonal DL DMRS ports are supported for SU-MIMO
    • Maximum 12 orthogonal DL DMRS ports are supported for MU-MIMO

 

 

Massive MIMO

 

Followings are agreed at RAN1 #85

  • Max number of Antenna on eNB ([5])
    • 256 for 30 Ghz
    • 1024 for 70 Ghz

 

 

Beam Management

 

In TR 38.802 and 38.804, Beam Management are described in terms of several different aspects(Functions) and procedures. The summary here is based on TR 38.804 section 5.3.4.

  • Main functions of Beam Managements
    • Beam Determination : for TRP(s) or UE to select of its own Tx/Rx beam
    • Beam Measurement : for TRP(x) or UE to measure characteristics of received beamformed signals
    • Beam Reporting : for UE to report information a property / quality of beamformed signal based on Beam Measurement
    • Beam Sweeping : Operation of covering a spatial area, with beams transmitted and/or received during a time interval in a predefined way
  • Main Procedure of Beam Managements
    • P-1 : Beam Selection for TRP Tx/UE Rx, It is used to enable UE measurement on different TRP Tx beams to support selection of TRP Tx beams/UE Rx beam.
    • P-2 : Beam Reselection(Beam Change) for TRP Tx beam. It is used to enable UE measurement on different TRP Tx beams to possibly change inter/intra-TRP Tx beam.
    • P-3 : Beam Reselection(Beam Change) for UE Rx beam. It is used to enable UE measurement on the same TRO Tx beam to change UE Rx beam in the case UE uses beamforming.

 

The following DL L1/L2 beam management procedures are supported within one or multiple TRPs: ([15])

  • P-1: is used to enable UE measurement on different TRP Tx beams to support selection of TRP Tx beams/UE Rx beam(s)
    • For beamforming at TRP, it typically includes a intra/inter-TRP Tx beam sweep from a set of different beams
    • For beamforming at UE, it typically includes a UE Rx beam sweep from a set of different beams
    • FFS: TRP Tx beam and UE Rx beam can be determined jointly or sequentially
  • P-2: is used to enable UE measurement on different TRP Tx beams to possibly change inter/intra-TRP Tx beam(s)
    • From  a possibly smaller set of beams for beam refinement than in P-1
    • Note: P-2 can be a special case of P-1
  • P-3: is used to enable UE measurement on the same TRP Tx beam to change UE Rx beam in the case UE uses beamforming
  • Strive for the same procedure design for Intra-TRP and inter-TRP beam management
    • Note: UE may not know whether it is intra-TRP or inter TRP beam
  • Note: Procedures P-2&P-3 can be performed jointly and/or multiple times to achieve e.g. TRP Tx/UE Rx beam change simultaneously
  • Note: Procedures P-3 may or may not have physical layer procedure spec. impact
  • Support managing multiple Tx/Rx beam pairs for a UE
  • Note: Assistance information from another carrier can be studied in beam management procedures
  • Note that above procedure can be applied to any frequency band
  • Note that above procedure can be used in single/multiple beam(s) per TRP

Related to different reciprocity assumptions in beam management procedures the following agreements were reached ([15])

  • Consider different channel reciprocity assumptions in beam management procedures
    • At a TRP or UE, with TX and RX channel reciprocity (full or partial) (e.g., beam reciprocity), TX beam (or RX beam) can be obtained from RX beam (or TX beam) to reduce overhead and latency
    • Without TX and RX channel reciprocity, beam management procedure may require TX and RX beam sweeping in both DL and UL links
  • RAN1 study different methods of determining Tx and Rx beam(s) for communication on one link direction (uplink or downlink), e.g.,
    • Joint determination: Tx beam and Rx beam are determined jointly
    • Separate determination: Tx beam or Rx beam are determined sequentially.
    • Multi-stage determination: for instance, coarse Tx-Rx beam determination followed by fine Tx-Rx beam determination
  • Study beam management procedure with and without explicit signaling of beam(s) or beam group(s) used for transmission

 

 

Synchronization Signal/Process

 

RAN1 should strive for a common framework, including for example structure of synchronization signals, for initial access ([14])

More specifically, especially within a group of frequency bands in the frequency range, RAN1 should strive for an unified framework covering([14])

  • Single beam based and multi-beam based deployments
  • TDD and FDD operations
  • Different/mixed numerologies
  • Standalone and non-standalone operations
  • Licensed band and unlicensed band operations
  • FFS: mMTC use case

RAN1 should take at least following requirements into account to design initial access([14])

  • Providing at least following functionalities
  • Detection of NR cell and its ID
  • Note: In this context, NR cell corresponds one or multiple TRP(s)
  • Initial time/frequency synchronization to the cell
  • Providing necessary information for random access
  • Providing sufficient number of the identity values to allow deployment flexibility
  • FFS: supporting efficient mobility
  • FFS: supporting efficient inter-RAT measurement
  • Reducing the frequency hypothesis UE needs to search for compared to LTE
  • FFS: detecting beam ID(s)

 

For subcarrier spacing of each synchronization signal (e.g, NR PSS, SSS) in a NR Carrier, the following alternatives should be studied : (Ref [7], [10])

    Alt 1 : Subcarrier spacing is predefined in the specification for a given frequency range

      Ex: 15Khz for sub-6Ghz, 60 kHz for over-6Ghz

    Alt 2 : Subcarrier spacing is selected by NR BS

      FFS : Details on the set of possible numerologies

      Note : Blind detection of multiple numerologies can be considered

    Alt 3 : Single Subcarrier spacing if predefined in the specification for all frequency ranges

    Oter alternatives are not precluded

NR synchronization signal is based on CP-OFDM

    Note that DFT-spread-OFDM based design is not precluded

 

At least one transmission bandwidth within a carrier bandwidth can be specified for transmission of  each synchronization signal and at least some essential system information. ([13])

  • The transmission bandwidth may be specified either differently according to the frequency range or the same across the frequency ranges
  • FFS: transmission bandwidths for each synchronization signal and at least some system information are same or not
  • FFS: the transmission bandwidth and the corresponding numerology
  • FFS: whether the used transmission bandwidth is blindly detected by UE from specified bandwidths according to the frequency bands

 

 

 

Initial Access / RACH

 

General Design

  • RAN1 should strive for a common framework, including for example structure of synchronization signals for initial access : (Ref [7], [10])
  • More specifically, especially within a group of frequency bands in the frequency range, RAN1 should strive for a unified framework covering following items: (Ref [7], [10])
    • Single beam based and multi-beam based deployments
    • TDD and FDD operations
    • Different/mixed numerologies
    • Standalone and non-standalone operations
    • Licensed band and unlicensed band operations
    • FFS : mMTC use case
  • RAN1 should take at least following requirements into account to design initial access
    • Providing at least following functionalities
      • Detection of NR cell and its ID
      • Initial time/frequency synchronization to the cell
      • Providing necessary information for random access
    • Providing suffcient number of the identity values to allow deployment flexibility
    • Reducing the frequency hopothesis UE needs to search for, compared to LTE
    • FFS : supporting efficient mobility
    • FFS : supporting efficient inter-RAT measurement
    • FFS : detecting beam ID(s)

 

Random Access Procedure

  • RACH procedure including RACH preamble (Msg 1), Random Access Response (Msg 2), Msg 3 and Msg4 is at least assumed for NR from RAN1 perspective: (Ref [7], [10])
  • Simplified RACH procedure, e.g Msg 1(UL) and Msg 2(DL) should be further studied: (Ref [7], [10])
    • Details on Msg 1 and Msg2 are FFS
  • The design of the random access procedure should take into account the possible use of single-beam and multiple bean operations including following items.: (Ref [7], [10])
    • Non Rx/Tx reciprocity at BS or UE
    • Full or partial Rx/Tx reciprocity at BS or UE
  • In case that multiple team-forming is applied to DL broadcast channels/signals for initial access: (Ref [7], [10])
    • RACH resources is obtained by UE from detected DL broadcast channels/signals
      • FFS : Details on association
    • Other mechanism without association is also considered
  • Multiple occasions for RACH preamble transmission in a given time interval are considered: (Ref [7], [10])
    • Details are FFS
    • Other mechanisms are not precluded.
  • Study further RACH Reception / RAR Transmission in TRPs/beams other than the one transmitting synchronization signal: (Ref [7], [10])

 

 

Channel Coding

 

According to TR 38.802 (Ref [17]) section 6.1.5, it is agreed as follows :

  • For eMBB Data channel, LDPC for all block size
  • For eMBB DCI, Polar Coding

 

 

Physical Layer Procedure (Scheduling / HARQ)

 

According to TR 38.802 (Ref [17]) section 6.2, it is agreed as follows :

 

< Scheduling >

  • supports both data and control with the same numerology.
  • supports at least same-slot and cross-slot scheduling for both DL and UL.
  • Timing between DL assignment and corresponding DL data transmission is indicated by a field in the DCI from a set of values and the set of values is configured by higher layer.
  • The timing(s) is (are) defined at least for the case where the timing(s) is (are) unknown to the UE.
  • Both contiguous and non-contiguous resource allocation for data with CP-OFDM is supported.

 

< HARQ >

  • HARQ-ACK feedback with one bit per TB is supported.
  • Operation of more than one DL HARQ processes is supported for a given UE
  • Operation of one DL HARQ process is supported for some UEs.
  • UE supports a set of minimum HARQ processing time.
  • supports different minimum HARQ processing time at least for across UEs.
  • The HARQ processing time at least includes delay between DL data reception timing to the corresponding HARQ-ACK transmission timing and delay between UL grant reception timing to the corresponding UL data transmission timing.
  • UE is required to indicate its capability of minimum HARQ processing time to gNB.
  • Asynchronous and adaptive DL HARQ is supported at least for eMBB and URLLC.
  • From UE perspective, HARQ ACK/NACK feedback for multiple DL transmissions in time can be transmitted in one UL data/control region.
  • Timing between DL data reception and corresponding acknowledgement is indicated by a field in the DCI from a set of values and the set of values is configured by higher layer.

 

 

Radio Interface Protoocol Stack

 

Overall Radio Interface Protocol Stack of NR is almost identical to the radio protocol stack of LTE except that in NR U-Plane a new layer (AS sublayer) is added.

 

Following diagram is based on TR 38.804 Figure 5.2.1.1-1 and Figure 5.2.2.1-1. (The component in orange is the new component in NR)

 

 

Reference :

 

[1] 3GPP R1-163989. 3GPP TSG RAN WG1 Meeting #85 - Waveform for NR

[2] 3GPP R1-165242. 3GPP TSG RAN WG1 Meeting #85 - On FrameStructure for NR  

[3] 3GPP R1-165242. 3GPP TSG RAN WG1 Meeting #85 - Contention based multiple access for NR uplink

[4] 3GPP R1-166013. 3GPP TSG RAN WG1 Meeting #85 - WF on time interval X

[5] 3GPP R1-166013. 3GPP TSG RAN WG1 Meeting #85 - Multi-Antenna Technology for NR Interface

[6] 3GPP R1-168258. 3GPP TSG-RAN1 Meeting #86 - LS on NR waveform

[7] 3GPP R1-168214. 3GPP TSG RAN1 Meeting #86 - LS on RAN1 agreements for NR initial access and mobility 

[8] 3GPP R4-167323. TSG-RAN WG4 Meeting #80bis  Considerations on the requirements for the initial access in NR

[9] 3GPP R4-167322. TSG-RAN WG4 Meeting #80bis  Considerations on NR RRM with the multiple numerologies

[10] 3GPP R4-167216. TSG-RAN WG4 Meeting #80bis  LS on RAN1 agreements for NR initial access and mobility

[11] 3GPP R1-1610203 3GPP TSG RAN WG1 Meeting #86bis Synchronization in NR considering beam sweeping

[12] 3GPP R1-1610307 3GPP TSG RAN WG1 Meeting #86bis Views on time domain structure for NR  

[13] 3GPP R1-1610351 3GPP TSG RAN WG1 Meeting #86bis A Framework for Initial Access for NR  

[14] 3GPP R1-1610400 3GPP TSG RAN WG1 Meeting #86bis On NR DL synchronization  

[15] 3GPP R1-1610239 3GPP TSG RAN WG1 Meeting #86bis On beam management in NR procedures

[16] 3GPP R1-1610287 3GPP TSG RAN WG1 Meeting #86bis On the synchronization signal design principle in NR   

[17] 3GPP TR 38.802 V2.0.0 (2017-03) - Study on New Radio (NR) Access Technology; Physical Layer Aspects (Release 14)

[18] 3GPP TR 38.804 V1.0.0 (2017-03) - Study on New Radio Access Technology; Radio Interface Protocol Aspects (Release 14)

[19] 3GPP TR 38.801 V2.0.0 (2017-3) - Study on New Radio Access Technology;Radio Access Architecture and Interfaces (Release 14)

[20] 3GPP TR 38.803 V2.0.0 (2017-03) - Study on New Radio Access Technology; RF and co-existence aspects (Release 14)

[21] 3GPP R2-1702534 TSG-RAN WG2 #97bis - RAN WGs progress on NR technology SI in the February meeting