A few years ago from now (Jul 2017) when the discussion about 5G was at early phase, the hottest topic was 'what kind of waveform will be used in 5G' and a lot of new idea (new waveform) were proposed (If you want to look into some snapshot on this technical history, take a look at 5G Waveform Candate page). In those discussion, you might have seen many people/many techical documents talking about 'what is the problem of current OFDM based waveform' and 'why we need to redesign the waveform in 5G'. However, in more recent discussion I start sensing that the good old buddy (OFDM) would get more attention and finally as 3GPP specification rolls out, it is decided to go with the old and familiar waveform OFDM. It might be a little bit disappoiting to those who have been expecting a completely new technology (disruptive technology), but those who is working in the area of baseband DSP or FPGA in legacy LTE, this conclusion would sound like a blessing :)
If you are already familiar with the OFDM technolgy and LTE waveform, there would be only a small additional portions that you need to study. If you are new to this technolgy, it would be a good timing for you to start studying a new things (I would recommend you to start from this page : OFDM Introduction).
Overall Procedure for Waveform Generation
Following illustration (based on 38.300 - 5.1) shows overall flow of waveform generation for downlink and uplink. The biggest difference between NR and LTE is that NR can use CP-OFDM for Uplink as well as DFT-s-OFDM depending on use case.
Whether you use CP-OFDM or DFT-s-OFDM can be configurable except msg3 by sepcifying RRC parameters, given in the three information elements that follow.
Following is based on
RACH-ConfigCommon ::= SEQUENCE {
rach-ConfigGeneric RACH-ConfigGeneric,
totalNumberOfRA-Preambles INTEGER (1..63) OPTIONAL, -- Need S
ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE {
... -- eight branches, none of them waveform related
} OPTIONAL, -- Need M
... -- groupBconfigured through prach-RootSequenceIndex are not waveform related
msg1-SubcarrierSpacing SubcarrierSpacing OPTIONAL, -- Cond L139
restrictedSetConfig ENUMERATED {unrestrictedSet, restrictedSetTypeA, restrictedSetTypeB},
msg3-transformPrecoder ENUMERATED {enabled} OPTIONAL, -- Need R
...,
-- the r16, r17 and r19 extension groups follow here, and none of them is waveform related
}
PUSCH-Config ::= SEQUENCE {
dataScramblingIdentityPUSCH INTEGER (0..1023) OPTIONAL, -- Need S
txConfig ENUMERATED {codebook, nonCodebook} OPTIONAL, -- Need S
dmrs-UplinkForPUSCH-MappingTypeA SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M
dmrs-UplinkForPUSCH-MappingTypeB SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M
... -- pusch-PowerControl through pusch-AggregationFactor are not waveform related
mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S
mcs-TableTransformPrecoder ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S
transformPrecoder ENUMERATED {enabled, disabled} OPTIONAL, -- Need S
... -- codebookSubset through uci-OnPUSCH are not waveform related
tp-pi2BPSK ENUMERATED {enabled} OPTIONAL, -- Need S
...,
[[
... -- rest of the r16 group
mcs-TableTransformPrecoderDCI-0-2-r16 ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S
... -- rest of the r16 group
]],
[[
... -- the whole r17 group, none of it waveform related
]],
[[
... -- rest of the r18 group
dynamicTransformPrecoderFieldPresenceDCI-0-1-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
dynamicTransformPrecoderFieldPresenceDCI-0-2-r18 ENUMERATED {enabled} OPTIONAL, -- Need R
... -- rest of the r18 group
]],
[[
... -- the whole r19 group, none of it waveform related
]]
}
ConfiguredGrantConfig ::= SEQUENCE {
frequencyHopping ENUMERATED {intraSlot, interSlot} OPTIONAL, -- Need S
cg-DMRS-Configuration DMRS-UplinkConfig,
mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S
mcs-TableTransformPrecoder ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S
uci-OnPUSCH SetupRelease { CG-UCI-OnPUSCH } OPTIONAL, -- Need M
resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch },
rbg-Size ENUMERATED {config2} OPTIONAL, -- Need S
powerControlLoopToUse ENUMERATED {n0, n1},
p0-PUSCH-Alpha P0-PUSCH-AlphaSetId,
transformPrecoder ENUMERATED {enabled, disabled} OPTIONAL, -- Need S
... -- nrofHARQ-Processes onward, and the r16 to r19 extension groups, are not waveform related
}
Three points are worth taking from those definitions. The first is that the field the page was originally written against has been renamed. It is
The second is that a third information element carries the same switch. A configured grant is not scheduled by DCI, so it cannot inherit the choice from anywhere else, and ConfiguredGrantConfig therefore repeats
The third is a Release 18 addition. PUSCH-Config gained
Msg3 is decided in common signalling : msg3-transformPrecoder sits in RACH-ConfigCommon, which every UE in the cell reads before it has a dedicated configuration.Absent means CP-OFDM for msg3 : the field is ENUMERATED {enabled} and optional, so a UE that is not given it uses CP-OFDM.Dedicated signalling has both values : transformPrecoder in PUSCH-Config is ENUMERATED {enabled, disabled}, so the network can override an inherited setting either way.Three places, one switch : RACH-ConfigCommon for msg3, PUSCH-Config for scheduled PUSCH, and ConfiguredGrantConfig for a grant that arrives without DCI.Release 18 makes it dynamic : the two dynamicTransformPrecoderFieldPresence fields put the choice in the DCI instead of leaving it to RRC.
CP OFDM Sequence Generation
When 3GPP 38.211 was released, the first thing I checked was waveform equation since I have been waiting so long for the final conclusion to come out. Following is the waveform equation specified in 38.211 and I put the waveform equation of the legacy LTE from 36.211 for comparison.
What is your first impression ? You may think NR(5G) waveform is much simpler than the LTE waveform. Even though these two equation look very differently but if you take a closer look you would notice the difference is very small. In LTE, the waveform generation equation (basically IFFT equation) is split into two parts just to remove the point located at DC location (i.e, at frequency = 0 in baseband). In NR(5G), this DC removal is not required any more and the full IFFT equation is combine into one.
Is that all ? NR waveform generation is simpler than LTE waveform generation (at least mathematically) ?
It is not all. As you see in Frame Structure page, in NR(5G) several difference numerology (i.e, different subcarrier spacing and symbol length) are supported whearas in LTE there is only one numerology. Those different numerology are not completely new waveform on its own. All of them can be derived from a common mathematical equation by scaling up and down a couple of paramters as illustrated below.
Two things in that expanded form need care before its symbols are carried to another page. The first is arithmetic. The drawing writes the sampling time as 1 divided by the product of Δfmax and Nf, and gives the answer as 50.86 ns. It also supplies Δfmax as 480 × 103 Hz and Nf as 4096. That product is 1.966 × 109, so the reciprocal is 0.5086 ns. The stated value is a hundred times too large.
The second is the symbol. Early drafts of 38.211 called that quantity Ts, which is the name the drawing uses. The published specification calls it Tc, and keeps Ts for 1 divided by the product of Δfref and Nf,ref, which is 32.552 ns. The two differ by exactly κ, the 64 the drawing already shows. The Physical Layer Timing Unit page uses the published names.
One summation replaces two : LTE split the transform to skip the DC subcarrier, and NR carries no such exception.The equation itself does not change with numerology : μ enters through Nu, NCP,l and Δf, and every one of them scales by 2-μ.The cyclic prefix has three cases : 512κ·2-μ for extended CP, 144κ·2-μ + 16κ for the first symbol of each half subframe, and 144κ·2-μ everywhere else.κ is 64 : it is the ratio between the two sampling times, and it is why the extra 16κ is a whole number of samples.The 50.86 ns label is wrong : the constants beside it give 0.5086 ns, which is the value the timing unit page carries.
Transform Precoding
As mentioned above, unlike LTE NR has two options for UL Waveform. One is CP-OFDM (same as DL Waveform) and the other one is DFT-s-OFDM which is same as LTE UL waveform. Transform Precoding is the first step to create DFT-s-OFDM waveform as highlighed below. Whether UE need to use CP-OFDM or DFT-s-OFDM is determined by following RRC Parameter.
- RACH-ConfigCommon.msg3-transformPrecoder(msg3-tp)
- PUSCH-Config.transformPrecoder(PUSCH-tp)
In term of functionality, Transform Precoding is to spread UL data in a special way to reduce PAPR(Peak-to-Average Power Ratio) of the waveform. In terms of mathematics, Transform Precoding is just a form of DFT(Discrete Fourier Transform) as you see in the equation shown below.
If UE is to use multi-layer (UL MIMO) the equation is as below (this is the original form described in 38.211 - 6.3.1.4)
If UE is to use single layer, the equation can be simplified as below. I would look more obvious that Transform Precoding is basically DFT.
Two details in those equations are worth reading off before moving on. The first is the transform length. MscPUSCH is the number of subcarriers across the whole allocated PUSCH bandwidth, so the DFT size follows the size of the grant rather than being fixed.
The second is the scaling. The sum is divided by the square root of MscPUSCH, which makes the transform unitary. Transform precoding therefore redistributes energy across the subcarriers without adding any, and the reduction in PAPR costs nothing in transmitted power.
The two parameters listed above do not cover the same transmissions, and the split is not arbitrary. Msg3 is sent before the UE has any dedicated configuration, so the network cannot reach it through PUSCH-Config. It is told through the common RACH configuration instead, which every UE in the cell reads from SIB1.
The two chains differ by one block : DFT-s-OFDM is the CP-OFDM chain with transform precoding placed in front of the sub-carrier mapping.Two parameters decide it : msg3-transformPrecoder in RACH-ConfigCommon for msg3, and transformPrecoder in PUSCH-Config for everything after it.Msg3 is the exception for a reason : it is sent before dedicated configuration exists, so it has to be told through the common configuration.The DFT length follows the grant : MscPUSCH spans the whole allocated PUSCH bandwidth, so the transform size changes with the allocation.The transform preserves power : the 1 over square root scaling makes it unitary, so PAPR falls without any change in transmitted energy.
Reference
[1] 38.211 v19.4.0 : NR - Physical channels and modulation. Clause 5.3 is the OFDM baseband signal generation, and clause 6.3.1.4 is transform precoding.
[2] 38.331 v19.3.0 : NR - Radio Resource Control (RRC) protocol specification. RACH-ConfigCommon, PUSCH-Config and ConfiguredGrantConfig are quoted from it.
[3] 38.300 : NR - Overall description. Clause 5.1 is the basis of the waveform generation overview above.