The term Aggregation Factor in this context refers to the aggregation in time domain, more specifically the PDSCH and PUSCH over multiple consecutive slots. Those multiple PDSCH and PUSCH in this mechanism carries the same user data but with different redundancy version. It means those multiple PDSCH or PUSCH is basically the repetative transmission of a same data like the repetition mechanism you saw in TTI bundling and repetion in LTE and LTE CatM.
- PDSCH AggregationFactor/RepetitionSchemeConfig
- PUSCH AggregationFactor/RepetitionSchemeConfig
- Msg4 Aggregation Factor in Release 19
- UE Capability Information
- RRC Parameters
- Reference
- Get the Test Procedure and Log / Amarisoft TechAcademy
PDSCH Aggregation Factor/RepetitionSchemeConfig
PDSCH Aggregation is a kind of PDSCH repetition mechanism for reliable transmission (of course at the sacrifice of throughput). Overall concept would be similar to TTI Bundling in LTE (in LTE TTI bundling is for Uplink. You may take PDSCH Aggregation is downlink version of TTI bundling) or it can be comparable to PDSCH repetition in Cat M or NBIot in LTE. Overall mechanism of PDSCH Aggregation can be illustrated as below.
In Release 15, 3GPP allows three types of repeition (n2, n4, n8) and you may apply the specific number of repetition depending on use case as listed below. This is just examples and the decision is supposed to be made by network operators (carriers)
eMBB data with high data throughput requirement : a single PDSCH transmission, meaning No Aggregation.Critical IoT data with medium reliability requirement : a few PDSCH repetitionsCritical IoT data with high reliability requirement : using many PDSCH repetitionsCritical IoT data with low latency requirement : using only one or two PDSCH repetitions
When this IE is configured, the number of allocated symbol (SLIV) for all the consecutive slots are same as the first slot.
The RV_id (Redundancy Version) for each slot varies depending on following table.
< 38.214 - Table 5.1.2.1-2: Applied redundancy version when aggregationFactor is present >
< 38.214 - Table 5.1.2.1-3: Applied redundancy version for the second TCI state when sequenceOffsetforRV ispresent >
rvs : sequenceOffsetforRV
PUSCH AggregationFactor/RepetitionSchemeConfig
PUSCH repetition is the uplink half of the same idea, and the shape of it is close enough to PDSCH that the differences are what matter. The offset from the DCI to the first transmission is k2 rather than k0. The repetitions travel from UE to gNB, and RRC sets how many of them there are. The overview diagram traces one DCI through the repetitions it schedules.
Two tables from 38.214 decide what the repetitions carry. The first sets how many there are when the repetition count is signalled through the MCS field, which is the Msg3 case. The second sets which redundancy version each occasion uses.
< 38.214 - Table 6.1.2.1-1A: Number of repetition K as a function of 2 MSBs of MCS information field >
The table has two halves, and which one applies depends on whether numberOfMsg3Repetitions is configured. When it is, the two bits select one of the four configured values. When it is not, the same two bits mean K of 1, 2, 3 and 4 directly, so a UE that never receives the configuration still has a usable repetition count.
< 38.214 - Table 6.1.2.1-2: Redundancy version for PUSCH transmission >
N : numberOfSlotsTBoMS-r17 = number of slots N used for TBS determination
The row is chosen by the redundancy version the DCI indicates, and the column by the position of the occasion in the sequence. The four rows are the cyclic orders 0,2,3,1 and 2,3,1,0 and 3,1,0,2 and 1,0,2,3, so every starting point walks the same cycle from a different place. Starting at 0 matters because rv 0 is the only self-decodable version, and the receiver needs it before combining helps.
N is the number of slots the transport block spans, so with TBoMS the redundancy version advances once per group of N slots rather than once per slot.
Msg4 Aggregation Factor in Release 19
Everything above has one assumption hidden in it. The field pdsch-AggregationFactor sits in PDSCH-Config, and PDSCH-Config is dedicated RRC. So the UE gets it only after the RRC connection is set up. Then what about Msg4 itself ? Msg4 is the PDSCH that carries the UE contention resolution identity and RRCSetup. It is sent before the UE has any dedicated configuration at all. Release 19 adds a separate aggregation factor just for this PDSCH.
Why do we need repetition for Msg4 ? The UE capability for this feature applies only to the bands in 38.101-5 Table 5.2.2-1. 38.101-5 is the satellite access RF specification, so this is an NTN feature. In NTN, the link budget during initial access is the weak point. Release 17 already added Msg3 PUSCH repetition, which is the case of Table 6.1.2.1-1A in the PUSCH section. Release 18 added PUCCH repetition for the HARQ-ACK of Msg4, with numberOfMsg4HARQ-ACK-Repetitions-r18 in NTN-CovEnh-r18. After those two, the Msg4 PDSCH was left as a single transmission. Release 19 fills this gap.
Then you may ask how the gNB knows whether the UE can receive a repeated Msg4. At Msg4 time, the gNB has not seen UECapabilityInformation yet. The UE has not seen any dedicated RRC either. So both sides have to learn about each other through the messages that already exist before Msg4. The solution uses three of them.
The sequence diagram below follows one random access procedure from SIB1 to the HARQ-ACK of Msg4. The blue messages are where the support information is exchanged, SIB1 in one direction and Msg3 in the other. The red messages are the Msg4 PDSCH itself, sent over four consecutive slots in this example. The redundancy versions on the red arrows assume that the DCI indicates rvid 0.
Msg4 PDSCH repetition needs two indications before the DCI. SIB1 tells the UE that the cell supports it, and Msg3 tells the gNB that the UE supports it. Only after that can the MCS field of the DCI turn the repetition on.
SIB1 : pdsch-AggregationFactor-r19 in PDSCH-ConfigCommon gives the number of consecutive slots, n2 or n4. The UE may indicate support in Msg3 only if SIB1 provides this field.Msg3 : The UE indicates support through the LCID of the CCCH SDU. It uses the extended LCID space, with the LX field set to 1 (38.321 Table 6.2.1-2c). So no new MAC CE or RRC field is needed for it.DCI format 1_0 with TC-RNTI : The MSB of the MCS field set to 1, with IMCS less than 29, turns on the repetition for this Msg4.Msg4 PDSCH : The same symbol allocation is applied across pdsch-AggregationFactor-r19 consecutive slots, and the PDSCH is limited to a single transmission layer. The rv of each occasion follows 38.214 Table 5.1.2.1-2, the same table as the PDSCH section.
The LCID part needs a little more explanation. 38.321 Table 6.2.1-2c has a separate codepoint for each combination of three things. The first is the CCCH size, 48 or 64 bits. The second is the UE type, RedCap, eRedCap or other UE. The third is whether PUCCH repetition of Msg4 HARQ-ACK is requested as well. So one LCID can carry both Msg4 requests at once. The MAC entity may use a codepoint only if the network indicates support for that feature.
The trick in the DCI is the most interesting part, I think. DCI format 1_0 has no field for repetition. Adding one would change the size of a DCI that every UE monitors. So 38.214 reuses the MSB of the 5 bit MCS field instead. If the UE has indicated support in Msg3, the MSB is 1 and IMCS is less than 29, the UE applies the repetition. Then the UE assumes the MSB to be 0 and looks up Table 5.1.3.1-1 with the result.
Let's work through the numbers. With the MSB set to 1, IMCS is between 16 and 31. The condition of less than 29 leaves 16 to 28. After the MSB is cleared, they become MCS 0 to 12. That is QPSK up to MCS 9, and 16QAM for MCS 10 to 12. So a repeated Msg4 can use only the lower part of the MCS table. This is not a real loss, because a UE that needs repetition would not decode a high MCS anyway. IMCS 29 to 31 are left out of the rule, so they keep their usual meaning. My understanding is that this keeps them for retransmission, where the DCI signals only the modulation order.
One thing you would notice is that the repetition is decided per DCI, not per cell. SIB1 sets only how many slots a repetition uses. The gNB can still send a normal single slot Msg4 to a UE that indicated support, by keeping the MSB at 0. Following is the RRC side of it.
< PDSCH-ConfigCommon >
Following is based on
PDSCH-ConfigCommon ::= SEQUENCE {
pdsch-TimeDomainAllocationList PDSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R
...,
[[
pdsch-AggregationFactor-r19 ENUMERATED {n2,n4} OPTIONAL -- Need R
]]
}
Compare this with pdsch-AggregationFactor in PDSCH-Config. The dedicated one allows n2, n4 and n8, but the Msg4 one allows only n2 and n4. The dedicated one is Need S, and the Msg4 one is Need R. The field description gives only the number of consecutive repetition slots for Msg4 PDSCH. The rest of the behaviour is in 38.214 clause 5.1.2.1, and the diagram above follows that clause.
On the UE side, pdsch-RepetitionMsg4-r19 is a per-band capability in BandNR. It indicates that the UE supports reception of Msg4 PDSCH repetition with repetition factors 2 and 4. It is FR1 only. A UE that reports it shall also report pdsch-RepetitionMultiSlots, the capability for the ordinary aggregation factor in the UE Capability Information section.
< BandNR >
Following is based on
BandNR ::= SEQUENCE {
...
-- R1 65-1-5: Msg4 PDSCH repetition
pdsch-RepetitionMsg4-r19 ENUMERATED {supported} OPTIONAL,
...
}
The gNB cannot use this capability for Msg4 itself, because UECapabilityInformation arrives long after Msg4. This is why the Msg3 LCID exists. The capability is what the network reads later, after the RRC connection is set up.
Msg4 gets its own aggregation factor : pdsch-AggregationFactor-r19 in PDSCH-ConfigCommon is broadcast in SIB1, because there is no dedicated PDSCH-Config yet at Msg4.Support is exchanged before the DCI : SIB1 tells the UE about the cell, and the LCID of the Msg3 CCCH tells the gNB about the UE.The DCI decides each time : The MSB of the MCS field in DCI format 1_0 turns the repetition on, and the usable MCS range drops to 0 to 12.The rv rule is shared : A repeated Msg4 uses the same 38.214 Table 5.1.2.1-2 as the dedicated aggregation factor.
UE Capability Information
This is an optional configuration and it is not guaranteed that all the UE support this capability. If a UE support this capability, it should inform it to Network via the IE : pdsch-RepetitionMultiSlots in Phy-ParametersCommon of UE CapabilityInformation.
The capability sits in Phy-ParametersCommon rather than in a band-specific list, so a UE that reports it reports it once for every band it supports. A network that configures pdsch-AggregationFactor without seeing the capability relies on behaviour the UE never claimed. The failure is also silent. The UE decodes the first slot and ignores the rest, so the transport block fails rather than the configuration being rejected.
Check the capability before configuring repetition : Repetition costs slots whether or not the UE uses them, so configuring it blindly loses throughput and gains nothing.Uplink and downlink are reported separately : Support for PDSCH repetition says nothing about PUSCH repetition, and the two are configured by different IEs.
The uplink counterpart is pusch-RepetitionMultiSlots, and both fields are declared the same way. Each is an ENUMERATED with the single value supported, and each is OPTIONAL, so the field is either present or absent and there is no value meaning not supported. Reading a capability message therefore means checking for presence rather than for a value.
Release 16 added its own variants alongside the original fields, pdsch-RepetitionMultiSlots-r16 and pusch-RepetitionMultiSlots-r16, with pusch-RepetitionMultiSlots-v1650 following. The older fields were not withdrawn, so a capability message can carry more than one of them and the network reads whichever matches the release it is operating.
RRC Parameters
Both listings below are cut down to the fields this page is about, because PDSCH-Config and PUSCH-Config are each far too long to read whole. Two things are worth noticing as you read them. The aggregation factor itself is a single enumerated field with three values, and everything else here exists to describe repetition schemes that arrived later and are configured separately from it.
< PDSCH-Config and the IEs it refers to >
Following is based on
PDSCH-Config ::= SEQUENCE {
...
pdsch-AggregationFactor ENUMERATED { n2, n4, n8 } OPTIONAL, -- Need S
...
pdsch-TimeDomainAllocationList-r16 SetupRelease { PDSCH-TimeDomainResourceAllocationList-r16}
OPTIONAL, -- Need M
repetitionSchemeConfig-r16 SetupRelease { RepetitionSchemeConfig-r16} OPTIONAL--Need M
]],
[[
repetitionSchemeConfig-v1630 SetupRelease { RepetitionSchemeConfig-v1630} OPTIONAL--Need M
]],
...
}
PDSCH-TimeDomainResourceAllocation-r16 ::= SEQUENCE {
k0-r16 INTEGER(0..32) OPTIONAL, -- Need S
mappingType-r16 ENUMERATED {typeA, typeB},
startSymbolAndLength-r16 INTEGER (0..127),
repetitionNumber-r16 ENUMERATED {n2, n3, n4, n5, n6, n7, n8, n16}
OPTIONAL,--Cond Formats1-0_1-1_4-0_4-1_4-2
...,
[[
k0-v1710 INTEGER(33..128) OPTIONAL -- Need S
]],
[[
repetitionNumber-v1730 ENUMERATED {n2, n3, n4, n5, n6, n7, n8, n16}
OPTIONAL -- Cond Format1-2
]]
}
RateMatchPatternGroup ::= SEQUENCE (SIZE (1..maxNrofRateMatchPatternsPerGroup)) OF CHOICE {
cellLevel RateMatchPatternId,
bwpLevel RateMatchPatternId
}
MinSchedulingOffsetK0-Values-r16 ::= SEQUENCE (SIZE (1..maxNrOfMinSchedulingOffsetValues-r16))
OF INTEGER (0..maxK0-SchedulingOffset-r16)
MinSchedulingOffsetK0-Values-r17 ::= SEQUENCE (SIZE (1..maxNrOfMinSchedulingOffsetValues-r16))
OF INTEGER (0..maxK0-SchedulingOffset-r17)
MaxMIMO-LayersDL-r16 ::= INTEGER (1..8)
RepetitionSchemeConfig-r16 ::= CHOICE {
fdm-TDM-r16 SetupRelease { FDM-TDM-r16 },
slotBased-r16 SetupRelease { SlotBased-r16 }
}
RepetitionSchemeConfig-v1630 ::= SEQUENCE {
slotBased-v1630 SetupRelease { SlotBased-v1630 }
}
FDM-TDM-r16 ::= SEQUENCE {
repetitionScheme-r16 ENUMERATED {fdmSchemeA, fdmSchemeB,tdmSchemeA },
startingSymbolOffsetK-r16 INTEGER (0..7) OPTIONAL -- Need R
}
SlotBased-r16 ::= SEQUENCE {
tciMapping-r16 ENUMERATED {cyclicMapping, sequentialMapping},
sequenceOffsetForRV-r16 INTEGER (1..3)
}
SlotBased-v1630 ::= SEQUENCE {
tciMapping-r16 ENUMERATED {cyclicMapping, sequentialMapping},
sequenceOffsetForRV-r16 INTEGER (0)
}
< PUSCH-Config and the IEs it refers to >
Following is based on
PUSCH-Config ::= SEQUENCE {
...
pusch-AggregationFactor ENUMERATED { n2, n4, n8 } OPTIONAL, -- Need S
...
pusch-RepTypeIndicatorDCI-0-1-r16 ENUMERATED { pusch-RepTypeA, pusch-RepTypeB}
OPTIONAL, -- Need R
...
availableSlotCounting-r17 ENUMERATED { enabled } OPTIONAL, -- Need S
...
}
PUSCH-TimeDomainResourceAllocationList-r16 ::= SEQUENCE (SIZE(1..maxNrofUL-Allocations-r16))
OF PUSCH-TimeDomainResourceAllocation-r16
PUSCH-TimeDomainResourceAllocation-r16 ::= SEQUENCE {
k2-r16 INTEGER(0..32) OPTIONAL, -- Need S
puschAllocationList-r16 SEQUENCE (SIZE(1..maxNrofMultiplePUSCHs-r16))
OF PUSCH-Allocation-r16,
...
}
PUSCH-Allocation-r16 ::= SEQUENCE {
mappingType-r16 ENUMERATED {typeA, typeB} OPTIONAL, -- Cond NotFormat01-02-Or-TypeA
startSymbolAndLength-r16 INTEGER (0..127) OPTIONAL, -- Cond NotFormat01-02-Or-TypeA
startSymbol-r16 INTEGER (0..13) OPTIONAL, -- Cond RepTypeB
length-r16 INTEGER (1..14) OPTIONAL, -- Cond RepTypeB
numberOfRepetitions-r16 ENUMERATED {n1, n2, n3, n4, n7, n8, n12, n16}
OPTIONAL, -- Cond Format01-02
...,
[[
numberOfRepetitionsExt-r17 ENUMERATED {n1, n2, n3, n4, n7, n8, n12, n16, n20, n24, n28,
n32, spare4, spare3, spare2, spare1} OPTIONAL,
-- Cond Format01-02-For-TypeA
numberOfSlotsTBoMS-r17 ENUMERATED {n1, n2, n4, n8, spare4, spare3, spare2, spare1}
OPTIONAL, -- Need R
extendedK2-r17 INTEGER (0..128) OPTIONAL -- Cond MultiPUSCH
]],
[[
ul-MutingIndicator-r19 ENUMERATED {enabled} OPTIONAL, -- Need S
occ-Length-r19 ENUMERATED {n2, n4} OPTIONAL -- Need R
]]
}
Release 19 also extends PUSCH-Allocation-r16. The new occ-Length-r19 gives the inter-slot OCC length, n2 or n4, for a dynamic grant or a Type 2 CG. The OCC is applied on top of PUSCH repetitions. The other new field, ul-MutingIndicator-r19, enables the semi-statically configured UL muting symbols for the PUSCH of that row. Inter-slot OCC for PUSCH belongs to the same Release 19 NTN feature group as the Msg4 aggregation factor, R1 65-3-1 against R1 65-1-5.
Reference
- PDSCH dynamic repetition: Setting a new standard for supporting dynamic radio conditions and traffic profiles - Erricson (2022)
- 38.213 v19.5.0 : NR; Physical layer procedures for control
- 38.214 v19.5.0 : NR; Physical layer procedures for data
- 38.306 v19.4.0 : NR; User Equipment (UE) radio access capabilities
- 38.321 v19.4.0 : NR; Medium Access Control (MAC) protocol specification
- 38.331 v19.4.0 : NR; Radio Resource Control (RRC); Protocol specification