Numerology is the one NR parameter that changes everything downstream. Choose a subcarrier spacing and the symbol duration, the slot length, the cyclic prefix and the resource block bandwidth all follow from it. Nothing in the frame structure is configured independently of it. The table below is the short version, and the sections after it work through where each choice comes from.
|
Numerology / SCS (Subcarrier Spacing) in Detail
Numerology in 5G/NR refers to Sub Carrier Spacing (SCS). As of Release 17, there are 7 types of numberology (SCS 15, 30, 60, 120, 240, 480, 960 Khz).
Even though Numerology is one of the most widely discussed item at 3GPP RAN1 meeting before NR Technical Specification is finalized, it sounds very vague to me. I think I understand what it indicates, but I still don't understand the meaning of Numerology in ordinary dictionary can be associated with what it means in NR.
Two numbers describe a numerology, and only one of them is free. 38.300 gives the subcarrier spacing as the exponentially scalable quantity 2μ × 15 kHz, so choosing μ fixes the spacing. Every other quantity in the frame structure is derived from that spacing rather than being signalled separately.
The resource block is the part that most often causes confusion. 12 consecutive subcarriers form a physical resource block at every numerology, so the block never changes in subcarrier count and always changes in bandwidth. At μ=0 those 12 subcarriers span 180 kHz. At μ=6 the same 12 span 11.52 MHz, which is 64 times wider. A carrier supports up to 275 resource blocks whichever numerology it runs.
μ is the only free choice : the subcarrier spacing, the symbol duration and the slot length all follow from 2μ × 15 kHz.A resource block is always 12 subcarriers : the count is fixed and the bandwidth is not, so one block spans 180 kHz at μ=0 and 11.52 MHz at μ=6.The carrier limit is counted in blocks : up to 275 resource blocks are supported at any numerology, so a higher numerology gives more bandwidth rather than more blocks.Extended CP exists at one numerology only : 38.211 Table 4.2-1 lists Normal for every μ, and adds Extended for μ=2 alone.
Definition of Numerology
The very simple defination of Numerology based on the usage of the term in 3GPP specification would be 'subcarrier spacing type', also often called as SCS. In LTE, we don't need any specific terminology to indicate the subcarrier spacing since there is only one subcarrier spacing, but in NR there are several different types of subcarrier spacing
As of release 17, there are 7 numerology (SCS: Subcarrier Spacing) as shown below. (NOTE : it would be possible to had additional numerology if we support much higher mmWave frequency in future release)
< 38.211 v17.2- Table 4.2-1: Supported transmission numerologies >
Figure 1. Seven rows, and the cyclic prefix column is the only one that is not a plain doubling. Extended CP appears at μ=2 and nowhere else.
- The first column is μ, running from 0 to 6.
- The second column gives the spacing as 2μ · 15 kHz, so the values are 15, 30, 60, 120, 240, 480 and 960 kHz.
- The third column is the cyclic prefix. Every row reads Normal, and the μ=2 row reads Normal, Extended.
- The screenshot is from v17.2, and 38.211 v19.4.0 still carries the same seven rows with the same cyclic prefix column.
To help you understand the meaning of each numerology more intuitively I tried to visualize the table as follows. (NOTE: Numberology 5 was defined in an early specification, then removed, and it is back in the current one. 38.331 names the two highest values kHz480-v1700 and kHz960-v1700, so both returned in Release 17.)
Figure 2. The panels carry what the table does not. A resource block keeps its 12 subcarriers at every numerology, so the block itself grows by a factor of 64 from the left panel to the right one.
- The table at the top right is 38.211 v17.2.0 Table 4.3.2-1, with columns for μ, the symbols per slot, the slots per frame and the slots per subframe.
- The symbols per slot column reads 14 in every row, so that number does not scale with μ.
- The slots per frame column doubles down the table, from 10 at μ=0 to 640 at μ=6.
- The slots per subframe column runs 1, 2, 4, 8, 16, 32 and 64.
- Seven panels sit below, each labelled with the bandwidth that 12 subcarriers occupy : 180, 360, 720, 1,440, 2,880, 5,760 and 11,520 kHz.
- Yellow arrows join each row of the table to its panel, and the taller panels carry a break symbol because they do not fit at scale.
- The note at the lower right states that LTE has one subcarrier spacing of 15 kHz while NR has several, and calls that the biggest difference between LTE and NR numerology.
The ladder is a doubling, not a list : each numerology is twice the spacing of the one below it, so the seven values span a factor of 64.Slots per frame scale with the spacing : 10 slots per frame at μ=0 becomes 640 at μ=6, while the symbols per slot stay at 14.The subcarrier count is the invariant : 12 subcarriers make a resource block at every numerology, which is what Figure 2 is drawn to show.
Numerology and Supported Channels
Not every numerology can be used for every physical channel and signals. That is, there is a specific numerologies that are used only for a certain type of physical channels even though majority of the numerologies can be used any type of physical channels. Following table shows which numerologies can be used for which physical channels.
< 38.300-Table 5.1-1: Supported transmission numerologies and additional info.>
|
Numerology |
Subcarrier Spacing (kHz) |
CP type |
Supported for Data (PDSCH, PUSCH etc) |
Supported for Sync (PSS,SSS,PBCH) |
PRACH |
|
N/A |
1.25 |
No |
No |
Long Preamble |
|
|
N/A |
5 |
No |
No |
Long Preamble |
|
|
0 |
15 |
Normal |
Yes |
Yes |
Short Preamble |
|
1 |
30 |
Normal |
Yes |
Yes |
Short Preamble |
|
2 |
60 |
Normal,Extended |
Yes |
No |
Short Preamble |
|
3 |
120 |
Normal |
Yes |
Yes |
Short Preamble |
|
4 |
240 |
Normal |
No |
Yes |
|
|
5 |
480 |
Normal |
Yes |
Yes |
|
|
6 |
960 |
Normal |
Yes |
Yes |
38.300 states the split in a single sentence, and it is worth keeping in that form. The numerology is based on the scalable spacing 2μ × 15 kHz, with μ = {0,1,3,4,5,6} for PSS, SSS and PBCH, and μ = {0,1,2,3,5,6} for other channels. Two exclusions follow from those two sets. μ=2 carries data and never carries synchronisation, and μ=4 carries synchronisation and never carries data.
The first two rows of the table above have no μ at all, and that is not an omission. 1.25 kHz and 5 kHz are the subcarrier spacings of the long PRACH preamble formats in 38.211 Table 6.3.3.1-1. They exist for PRACH alone, neither is 2μ × 15 kHz for any integer μ, and no data or synchronisation channel uses them. The numerology index does not reach them.
Two numerologies are one-sided : μ=2 carries data and no synchronisation, and μ=4 carries synchronisation and no data.Both sets are written out in 38.300 : μ = {0,1,3,4,5,6} for PSS, SSS and PBCH, and μ = {0,1,2,3,5,6} for everything else.PRACH reaches outside the ladder : the long preamble formats use 1.25 kHz and 5 kHz, and neither value is a power of two times 15 kHz.μ=2 is the exception in two ways : it is the only numerology offering Extended CP, and the only one excluded from synchronisation.
Numerology in RRC message
Numerology selection is not a static. Different numerology (Subcarrier Spacing) can be used in various different situation and purpose. The subcarrier spacing for different situation and purpose is defined in various places in RRC messages as follows.
|
Message/ASN Sequence |
IE |
Description |
|
MIB |
subCarrierSpacingCommon |
Subcarrier spacing for SIB1, Msg.2/4 for initial access and SI-messages |
|
BandwidthPart-Config |
subcarrierSpacing |
Subcarrier spacing to be used in this BWP. It is applied to at least PDCCH, PDSCH and corresponding DMRS |
|
LogicalChannelConfig |
allowedSubCarrierSpacing |
|
|
ReferenceSignalConfig |
subcarrierSpacing |
|
|
CSI-RS-ResourceConfig-Mobility |
subcarrierSpacing |
subcarrier spacing of CSI-RS. It can take the same values available also for the data channels and for SSB |
|
RACH-ConfigCommon |
msg2-SubcarrierSpacing |
|
|
RACH-ConfigCommon |
msg3-SubcarrierSpacing |
|
|
RACH-ConfigDedicated |
rar-SubcarrierSpacing |
|
|
ServingCellConfigCommon |
subcarrierSpacingCommon |
Subcarrier spacing for SIB1, Msg.2/4 for initial access and SI-messages. Values 15, and 30 kHz are applicable for carrier frequencies < 6GHz; Values 60 and 120 kHz are applicable for carrier frequencies > 6GHz |
|
ServingCellConfigCommon |
subcarrierSpacingSSB |
Subcarrier spacing of SSB. Used only for non-initial access (e.g. SCells, PCell of SCG). If the field is absent the UE shall assume the default value of the band. |
|
BasebandParametersPerCC |
subCarrierSpacing |
|
The rows above divide into three groups, and the group a field belongs to decides when the UE can act on it. The MIB field subCarrierSpacingCommon comes first, because the UE has to decode it before any other configuration exists. The BandwidthPart-Config and ServingCellConfigCommon entries come later, once the UE is reading common or dedicated configuration. BasebandParametersPerCC is different from the rest, because it travels in the other direction as a capability rather than as a configuration.
One trap in the table is worth naming. The same short name appears in more than one place with a different scope. Inside BandwidthPart-Config, subcarrierSpacing applies to that bandwidth part alone. Inside ServingCellConfigCommon, subcarrierSpacingCommon applies to SIB1 and to the initial access messages. Reading a log by field name alone will confuse the two.
The MIB field comes first : subCarrierSpacingCommon has to be decoded before the UE holds any other configuration to work from.Numerology is a property of the bandwidth part : most rows sit inside a bandwidth part rather than the cell, so one cell can run several numerologies at once.Random access carries its own fields : msg2, msg3 and the RAR each have a subcarrier spacing entry, because random access happens before the dedicated bandwidth part arrives.One row is a capability : BasebandParametersPerCC reports what the UE can do, so the network reads that row rather than setting it.
Why different Numerologies ?
Now you have some important questions on NR Numerology design. You might have these questions even before you went through all the details described above. The question that I had when I first heard of this kind of multiple numerology (basically multiple subcarrier spacing) was 'WHY we need this kind of multiple numerologies ?'.
One thing for sure is that it is not for making your life difficult as an engineer. Then, what would be other (more technical) reason ?
More technical (practical reason) is
- NR should cover very wide range of operating frequency (e.g, sub 3 Ghz, sub 6 Ghz and mmWave(over 25 Ghz).
- Due to physics, it is hard (almost impossible) to come up with single numerology (subcarrier space) that can cover the whole of these range without sacrificing too much of efficiency or performance.
Can you be more specific ?
- In OFDM, number of subcarrier that can be packed into a specific frequency range is directly related to spectrum efficiency (how many bits can be transmitter per Hz per second). The more subcarriers you can pack into a frequency range (i.e, the narrow subcarrier spacing you use), the more data you can transmit (or recieve).
- Based on Physics(anti-proportional relationship between subcarrier spacing and OFDM symbo length), Narrow subcarrier spacing means longer OFDM symbol length. With longer OFDM symbol, we can assign more room for CP(Cyclick Prefic). With longer CP, we can make the signal more tolerable to fading channel(Ref [33]).
- In lower frequency (like sub 3Ghz, sub 6 Ghz), we don't have much wide band spectrum left for this new technology. In order to pack as many subcarriers as possible in these limited spectrum, we need to get subcarrier spacing as small as possible. That's why we use small subcarrier spacing like 15 Khz, 30 Khz, 60 Khz in NR numerology.
- Then, why we don't use even smaller subcarrier like 10 Khz, 5 Khz etc ? As you know, in OFDM maintaining orthogonolity between subcarriers is critical (See Overview section of OFDM page). The transmitted signal would go through various fading channel causing the drift of each subcarrier and the degree of the drift gets even more serious when the transmitter or reciever moves faster. So the narrower of subcarrier spacing you use, the tolerance to fading gets weaker.
- Then we need very wide subcarrier spacing like 120 Khz or 240 Khz ? It is for the operation in very high frequency like mmWave. As carrier frequency gets higher, the degree of frequency drift by moving transmitter or reciever gets higher (i.e, Doppler spread gets wider as carrier frequency gets higher). To tolerate this kind of wide range of frequency drift (or shift), we need to use wider subcarrier spacing.
- There is another reason for wider subcarrier spacing in mmWave. For the reason as explained here, we would use beamforming (Massive MIMO based beamforming), for the implementaion of beamforming controlling the phase of the signal is critical and it is difficult to control the phase of the signal with narrow subcarrier spacing (Ref [33]).
- As frequency goes higher, the degree of phase noise would increase. So we need to implement more sophisticated mechanism for phase noise estimation and correction. It is easier to implement this kind mechanism with wider subcarrier spacing(Ref [33]).
UE Capability
Numerology appears in UE capability as well as in configuration, and the capability side is narrower than it first looks. The listing below is the per carrier downlink feature set, and a single field in it carries the numerology information.
Following is based on
FeatureSetDownlinkPerCC ::= SEQUENCE {
supportedSubcarrierSpacingDL SubcarrierSpacing,
supportedBandwidthDL SupportedBandwidth,
channelBW-90mhz ENUMERATED {supported} OPTIONAL,
maxNumberMIMO-LayersPDSCH MIMO-LayersDL OPTIONAL,
supportedModulationOrderDL ModulationOrder OPTIONAL
}
SubcarrierSpacing ::= ENUMERATED {kHz15, kHz30, kHz60, kHz120, kHz240,
kHz480-v1700 , kHz960-v1700 , spare1}
supportedSubcarrierSpacingDL : Defines the supported sub-carrier spacing for DL by the UE indicating the UE supports simultaeous reception with same or different numerologies in CA. Note the UE shall support all mandated sub-carrier spacing for FR1/FR2. Same numerology for intraband NR CA including both continuous and non-continuous is mandatory with capability in both FR1 and FR2. Two mixed numerologies between FR1 band(s) and FR2 band(s) in DL are mandatory with capability if UE supports inter-band NR CA including both FR1 band(s) and FR2 band(s). Optional for other cases.
The type behind that field is where Release 17 is visible. SubcarrierSpacing is an enumeration, and its two highest values are named kHz480-v1700 and kHz960-v1700. The suffix records the release that introduced them. The first five values are unchanged, so adding two numerologies did not disturb the encoding an older UE already uses.
The enumeration has eight codepoints and seven of them are used. The last one is spare1. That is the concrete form of the note further up this page about a future numerology for higher mmWave frequencies. One more value fits without defining a new type, and a second one does not.
One more property of the field is easy to miss. The field supportedSubcarrierSpacingDL holds a single SubcarrierSpacing rather than a list, and FeatureSetDownlinkPerCC is per component carrier. A UE that handles several numerologies at once therefore reports several component carriers, and not one carrier carrying a set.
One value per component carrier : mixed numerology is reported across carriers, because the field is a single SubcarrierSpacing rather than a list.The enumeration records its own history : kHz480-v1700 and kHz960-v1700 carry the release that added them, and the first five values did not move.There is room for exactly one more : eight codepoints, seven used, and spare1 remaining.
RRC Configuration
Followings are the RRC configuration that specifies numerology (subcarrier spacing). I would just put a couple of examples of RRC configurations without much detailed explanation. Just taking a look at the example would be self explanatory. The RRC message snippet shown here is from Amarisoft Callbox log.
SA
The two captures below come from a standalone cell, so every field the UE needs arrives over NR alone. SIB1 carries the common configuration that any UE reads before connecting. The RRCSetup carries what the network adds once that UE is connected. Both use kHz30 wherever a subcarrier spacing appears.
Following is a decoded message from an
{
message c1: systemInformationBlockType1: {
cellSelectionInfo {
...
},
cellAccessRelatedInfo {
...
},
connEstFailureControl {
...
},
servingCellConfigCommon {
downlinkConfigCommon {
frequencyInfoDL {
frequencyBandList {
{
freqBandIndicatorNR 78
}
},
offsetToPointA 24,
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz30,
carrierBandwidth 51
}
}
},
initialDownlinkBWP {
genericParameters {
locationAndBandwidth 13750,
subcarrierSpacing kHz30
},
...
},
uplinkConfigCommon {
frequencyInfoUL {
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz30,
carrierBandwidth 51
}
},
p-Max 10
},
initialUplinkBWP {
genericParameters {
locationAndBandwidth 13750,
subcarrierSpacing kHz30
},
rach-ConfigCommon setup: {
rach-ConfigGeneric {
...
},
...
msg1-SubcarrierSpacing kHz30,
restrictedSetConfig unrestrictedSet
},
...
},
ssb-PositionsInBurst {
inOneGroup '80'H
},
ssb-PeriodicityServingCell ms20,
tdd-UL-DL-ConfigurationCommon {
referenceSubcarrierSpacing kHz30,
pattern1 {
...
}
},
ss-PBCH-BlockPower -28
},
...
: This part may come in many different variations. For example, some gNB would configure this in RrcSetup or RrcReconfiguration if it want to configures only one BWP. Some gNB would configure this in RrcReconfigration instead of RrcSetup. Some gNB would configure multiples of this configuration (maximum up to 4 BWPs).
Following is a decoded message from an
{
message c1: rrcSetup: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcSetup: {
radioBearerConfig {
...
},
masterCellGroup {
...
},
mac-CellGroupConfig {
...
},
physicalCellGroupConfig {
...
},
spCellConfig {
spCellConfigDedicated {
initialDownlinkBWP {
pdcch-Config setup: {
...
},
pdsch-Config setup: {
...
},
downlinkBWP-ToAddModList {
{
bwp-Id 1,
bwp-Common {
genericParameters {
locationAndBandwidth 28875,
subcarrierSpacing kHz30
},
pdcch-ConfigCommon setup: {
...
},
pdsch-ConfigCommon setup: {
...
}
},
bwp-Dedicated {
pdcch-Config setup: {
...
},
pdsch-Config setup: {
...
}
}
},
firstActiveDownlinkBWP-Id 0,
uplinkConfig {
initialUplinkBWP {
pucch-Config setup: {
...
},
pusch-Config setup: {
...
},
srs-Config setup: {
...
}
},
uplinkBWP-ToAddModList {
{
bwp-Id 1,
bwp-Common {
genericParameters {
locationAndBandwidth 28875,
subcarrierSpacing kHz30
},
pusch-ConfigCommon setup: {
...
},
pucch-ConfigCommon setup: {
...
}
},
bwp-Dedicated{
pucch-Config setup: {
...
},
pusch-Config setup: {
...
},
srs-Config setup: {
...
}
}
}
}
},
firstActiveUplinkBWP-Id0,
pusch-ServingCellConfig setup: {
}
},
NSA
The NSA case buries the same fields much deeper. The NR configuration travels inside an LTE RRCConnectionReconfiguration, wrapped in a chain of eight nonCriticalExtension containers. The subcarrier spacing entries therefore sit that many levels further down than in the SA log above. The values themselves are the same kHz30 throughout.
Following is a decoded message from an
{
message c1: rrcConnectionReconfiguration: {
rrc-TransactionIdentifier 0,
criticalExtensions c1: rrcConnectionReconfiguration-r8: {
...
},
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nonCriticalExtension {
nr-Config-r15 setup: {
endc-ReleaseAndAdd-r15 FALSE,
nr-SecondaryCellGroupConfig-r15 {
rrc-TransactionIdentifier 0,
criticalExtensions rrcReconfiguration: {
secondaryCellGroup {
cellGroupId 1,
rlc-BearerToAddModList {
{
...
}
},
mac-CellGroupConfig {
...
},
physicalCellGroupConfig {
pdsch-HARQ-ACK-Codebook dynamic
},
spCellConfig {
servCellIndex 1,
reconfigurationWithSync {
spCellConfigCommon {
physCellId 500,
downlinkConfigCommon {
frequencyInfoDL {
absoluteFrequencySSB 632256,
frequencyBandList {
78
},
absoluteFrequencyPointA 632016,
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz30,
carrierBandwidth 51
}
}
},
initialDownlinkBWP {
genericParameters {
locationAndBandwidth 13750,
subcarrierSpacing kHz30
},
pdcch-ConfigCommon setup: {
...
},
pdsch-ConfigCommon setup: {
...
}
}
},
uplinkConfigCommon {
frequencyInfoUL {
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz30,
carrierBandwidth 51
}
}
},
initialUplinkBWP {
genericParameters {
locationAndBandwidth 13750,
subcarrierSpacing kHz30
},
rach-ConfigCommon setup: {
rach-ConfigGeneric {
...
},
...
msg1-SubcarrierSpacing kHz30,
...
},
pusch-ConfigCommon setup: {
pusch-TimeDomainAllocationList {
...
},
pucch-ConfigCommon setup: {
...
}
},
dummy ms500
},
ssb-PositionsInBurst mediumBitmap: '80'H,
ssb-periodicityServingCell ms20,
dmrs-TypeA-Position pos2,
ssbSubcarrierSpacing kHz30,
tdd-UL-DL-ConfigurationCommon {
referenceSubcarrierSpacing kHz30,
pattern1 {
...
}
},
ss-PBCH-BlockPower -28
},
newUE-Identity 17921,
t304 ms1000
},
rlf-TimersAndConstants setup: {
...
},
spCellConfigDedicated {
initialDownlinkBWP {
pdcch-Config setup: {
...
},
pdsch-Config setup: {
...
},
radioLinkMonitoringConfig setup: {
...
},
firstActiveDownlinkBWP-Id 0,
uplinkConfig {
initialUplinkBWP {
pucch-Config setup: {
...
},
pusch-Config setup: {
...
},
srs-Config setup: {
...
}
},
firstActiveUplinkBWP-Id 0,
pusch-ServingCellConfig setup: {
}
},
pdcch-ServingCellConfig setup: {
},
pdsch-ServingCellConfig setup: {
...
},
...
}
}
}
}
},
...
Reference
[1] 3GPP R1-166225. 3GPP TSG RAN WG1 Meeting #86 - Considerations on numerology for support of flexible guard lengths
[2] 3GPP R1-166346. 3GPP TSG RAN WG1 Meeting #86 - Forward compatibility consideration for NR frame structure
[3] 3GPP R1-166360. 3GPP TSG RAN WG1 Meeting #86 - URLLC numerology and frame structure design
[4] 3GPP R1-166363. 3GPP TSG RAN WG1 Meeting #86 - Scaled Numerology Control Design for NR
[5] 3GPP R1-166364 . 3GPP TSG RAN WG1 Meeting #86 - NR numerology scaling and alignment
[6] 3GPP R1-166471. 3GPP TSG RAN WG1 Meeting #86 - Discussion of NR Numerology
[7] 3GPP R1-166490. 3GPP TSG RAN WG1 Meeting #86 - Numerology impact on power efficiency for mMTC
[8] 3GPP R1-166637. 3GPP TSG RAN WG1 Meeting #86 - Discussion on numerology multiplexing
[9] 3GPP R1-166676. 3GPP TSG RAN WG1 Meeting #86 - TDD frame structure with mixed numerology
[10] 3GPP R1-166747. 3GPP TSG RAN WG1 Meeting #86 - Evaluation results of OFDM-based waveform in DL and UL single numerology case
[11] 3GPP R1-166748. 3GPP TSG RAN WG1 Meeting #86 - Evaluation results of OFDM-based waveform in DL and UL mixed numerology case
[12] 3GPP R1-166749. 3GPP TSG RAN WG1 Meeting #86 - Evaluation results of OFDM-based waveform in UL single numerology and asynchronous case
[13] 3GPP R1-166753. 3GPP TSG RAN WG1 Meeting #86 - Discussion on symbol alignment across scaled numerology
[14] 3GPP R1-166754. 3GPP TSG RAN WG1 Meeting #86 - Discussion on numerology support
[15] 3GPP R1-166795. 3GPP TSG RAN WG1 Meeting #86 - Discussion on numerology aspects of NR synchronization signal
[16] 3GPP R1-166878. 3GPP TSG RAN WG1 Meeting #86 - Discussion on alignment for different numerology multiplexing
[17] 3GPP R1-166879. 3GPP TSG RAN WG1 Meeting #86 - Further evaluation results on different numerology
[18] 3GPP R1-166939. 3GPP TSG RAN WG1 Meeting #86 - Numerology evaluation results for high speed scenario
[19] 3GPP R1-166940. 3GPP TSG RAN WG1 Meeting #86 - Discussion on numerology multiplexing in NR
[20] 3GPP R1-166941. 3GPP TSG RAN WG1 Meeting #86 - On design of mixed numerology in a NR carrier
[21] 3GPP R1-167004. 3GPP TSG RAN WG1 Meeting #86 - Discussion on numerology
[22] 3GPP R1-167034. 3GPP TSG RAN WG1 Meeting #86 - On PA impact to in mixed numerology with narrow band allocation
[23] 3GPP R1-167035. 3GPP TSG RAN WG1 Meeting #86 - On PA impact to in mixed numerology with wide band allocation
[24] 3GPP R1-167040. 3GPP TSG RAN WG1 Meeting #86 - On scalable numerology
[25] 3GPP R1-167106. 3GPP TSG RAN WG1 Meeting #86 - Phase Noise Measurement/Modeling and LLS for High Frequency Numerology
[26] 3GPP R1- 167107. 3GPP TSG RAN WG1 Meeting #86 - Discussion and Evaluation on Numerology Design for High Speed Train Scenario
[27] 3GPP R1-167218. 3GPP TSG RAN WG1 Meeting #86 - Numerology and Frame Structure for NR-Unlicensed
[28] 3GPP R1-167260. 3GPP TSG RAN WG1 Meeting #86 - Resource block and guard band arrangement supporting mixed numerology
[29] 3GPP R1-167261. 3GPP TSG RAN WG1 Meeting #86 - On resource block grouping and multi-cell coordination aspects for mixed numerology support
[30] 3GPP R1-167394. 3GPP TSG RAN WG1 Meeting #86 - Views on NR numerology
[31] 3GPP R1-167527. 3GPP TSG RAN WG1 Meeting #86 - Discussion on NR Numerology
[32] 3GPP R1-167564. 3GPP TSG RAN WG1 Meeting #86 - Impact of numerology on the non-CP based waveforms
[33] NR Wide Bandwidth Operations by Jeongho Jeon, Intel Corporation