NR SA PUSCH Aggregation
The purpose of this tutorial is to show you how to configure and test PUSCH Aggregation Factor / Repetition. Main user case of this mechanism is to provide chance of more reliable PUSCH reception. Conceptually you may consider this to be similar to PUSCH in LTE IoT application. Overall mechanism of PUSCH Aggrection Factor can be illustrated as below.
Image Source : Sharetechnote
Table of Contents
Introduction
The Physical Uplink Shared Channel (PUSCH) Aggregation Factor and Repetition mechanism is a fundamental feature in 5G New Radio (NR) designed to enhance the reliability and robustness of uplink data transmission, particularly under challenging radio conditions. In 5G NR architecture, the PUSCH serves as the primary uplink channel for user equipment (UE) to transmit user data and control information to the gNB (5G base station). Aggregation and repetition techniques, which have conceptual parallels to mechanisms used in LTE IoT deployments, involve transmitting multiple copies or aggregations of the same PUSCH transport block to increase the likelihood of successful reception at the gNB. This is especially crucial for mission-critical applications, IoT scenarios, and environments with high interference or poor signal quality. Architecturally, PUSCH Aggregation Factor and Repetition are configured through RRC signaling and managed by both the UE and network scheduler, which coordinate the number of repetitions and the aggregation scheme based on radio link conditions and QoS requirements. This mechanism plays a pivotal role in the broader NR ecosystem by facilitating improved link adaptation, supporting ultra-reliable low-latency communication (URLLC), and optimizing uplink throughput and coverage. The feature has evolved through multiple 3GPP releases, with ongoing updates enhancing its configuration flexibility and operational efficiency, underscoring its significance in both commercial and specialized 5G deployments.
-
Context of PUSCH Aggregation Factor and Repetition:
- Technical Background: Introduced as part of 5G NR standards, the PUSCH Aggregation Factor enables the UE to transmit repeated or aggregated uplink data blocks, thereby improving reliability in uplink transmissions.
- Architectural Placement: The mechanism operates at the physical layer, coordinated via higher-layer signaling and integrated within the NR MAC and scheduler functions.
- Key Concepts: Aggregation, repetition, uplink scheduling, link adaptation, and QoS-driven resource allocation.
-
Relevance and Importance of This Tutorial:
- Understanding and configuring PUSCH Aggregation Factor and Repetition is critical for optimizing uplink performance and ensuring robust data transmission in diverse deployment scenarios.
- The feature is particularly relevant for applications requiring high reliability, such as industrial automation, public safety, and massive IoT.
- Mastery of this mechanism allows engineers and network operators to maximize coverage, enhance resilience to interference, and support advanced 5G use cases.
-
Tutorial Learning Outcomes:
- Gain detailed insight into the configuration and operation of PUSCH Aggregation Factor and Repetition in 5G NR.
- Learn how to test, verify, and troubleshoot the feature across different network releases and configurations.
- Understand best practices for deploying and tuning the mechanism to meet specific performance and reliability objectives.
-
Prerequisite Knowledge and Skills:
- Familiarity with 5G NR architecture, protocol stack, and radio interface concepts.
- Experience with network configuration, RRC parameterization, and test/measurement tools for 5G environments.
- Basic understanding of uplink scheduling, HARQ, and link adaptation mechanisms in cellular systems.
Summary of the Tutorial
This tutorial covers the procedure to test the PUSCH Aggregation Factor operation in NR SA TDD mode, including setup, configuration, test execution, and log analysis.
-
Test Setup
- The test utilizes a callbox and UE simulator as depicted in the provided setup diagram.
-
Key Configuration Parameters
-
pusch
- aggregation_factor
-
pusch
-
Test 1: PUSCH Aggregation -TDD
- This test verifies the operation of the PUSCH Aggregation Factor in NR SA TDD configuration.
-
Configuration Steps:
- Copy and modify the gnb-sa.cfg to gnb-sa-pusch-agg.cfg for the gNB, and use ims.default.cfg and mme-ims.cfg for IMS and MME settings respectively (default on Callbox).
- Add phy.rep=1 (optional, for detailed logging of repeated transmissions).
- Set duplex mode (NR_TDD) to 1 (TDD).
- Configure NR_TDD_CONFIG to 5 to use a custom uplink-dominant TDD pattern, giving more UL slots for PUSCH repetition.
- Use band n78 and subcarrier spacing 30 kHz (flexible as per 3GPP specification).
- Enable force_full_bsr and set pusch_mcs to maintain stable UL slots and observe PUSCH repetition regardless of higher layer data.
- In the pdsch configuration, set the aggregation_factor parameter to enable PDSCH aggregation.
- Configure a TDD pattern with a 5 ms cycle (10 slots @ 30kHz). Assign 3 slots and 10 OFDM symbols for downlink, 6 slots and 2 OFDM symbols for uplink.
- On the UE side, use ue-nr-sa.cfg as is, ensuring TDD mode, band, subcarrier spacing, channel and SSB frequencies match the callbox configuration.
- Set UE access release to 15 and UE category to "nr".
-
Test Execution Steps:
- Start LTE service (gNB) and execute 'cell phy' and 'cell' commands to apply configuration.
- Power on the UE using the power_on command on the UE simulator.
- Ensure the UE completes attach procedure and monitor throughput using the 't' command.
-
Log Analysis:
- Before logging, enable the 'Repetition' option in the eNB log property window for enhanced verification.
- After initial attach, inspect the UE capability information to confirm support for PUSCH aggregation (pusch-RepetitionMultiSlots).
- Verify that the gNB enables PUSCH Aggregation by configuring the corresponding parameter when the UE supports it.
- In the PHY logs, identify PDCCH/DCI 1_1 scheduling of PUSCH and observe consecutive PUSCH transmissions with n_rep and varying repetition and redundancy version indices, confirming aggregation behavior.
- Use the WebGUI to visually confirm consecutive aggregated PUSCH transmissions, with initial and repeated transmissions distinguished by color coding.
Note: For custom TDD pattern definition, refer to the referenced tutorial link if unfamiliar with the process.
This test demonstrates how to configure and verify PUSCH Aggregation in NR SA TDD, guiding through parameter selection, setup, execution, and result validation using both logs and graphical tools.
Test Setup
Test setup for this tutorial is as shown below.
Key Configuration Parameters
Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.
- pusch
Test 1 : PUSCH Aggregation -TDD
This test is to test PUSCH Aggregation Factor operation in NR SA TDD
Configuration
I used the gnb-sa-pusch-agg.cfg on gNB which is copied and modified from gnb-sa.cfg
I used ims.default.cfg as ims configuration and mme-ims.cfg as mme configuration. These two are default configuration on Callbox.
In gnb-sa-pusch-agg.cfg , the configuration is done as follows.
I added a log option phy.rep=1 for clear verification in the log. This is not mandatory, but recommended if you want to capture all of the repeated transmission.
In this test, I used TDD. You can select any specific tdd pattern with the parameter NR_TDD_CONFIG. To apply TDD configuration, you first need to configure the duplex mode (NR_TDD) to 1 (TDD). And then I set NR_TDD_CONFIG to 5 which is not the default configuration and is configured by me for this test. I defined a new TDD pattern to create a uplink dominant pattern to give enough number of UL slots for pusch repetition.
In this test, band n78, subcarrier spacing(subcarrier_spacing) 30 is used, but this is not the mandatory condition. You can specify any band and subcarrier spacing that 3GPP allows. In addition, just for this test I enabled force_full_bsr and set pusch_mcs so as to force stable UL slots to show the PUSCH repetition without the data from higher layer.
Enabling PDSCH aggregation is simple. Just add a parameter aggregation_factor in pdsch configuration.
This is the TDD pattern that I configured for this test. In this configuration, the cycle length is 5ms which is 10 slots in case of Subcarrier spacing 30Khz. Out of the 10 slots, 3 slots and 10 OFDM symbols are allocated for downlink by the parameter dl_slots and dl_symbols respectively. 6 slots and 2 OFDM symbols are allocated for uplink by the parameter ul_slots and ul_symbols respectively.
I used the ue-nr-sa.cfg as it is.
Configure UE as TDD which matches to callbox configuration. Set the band, subcarrier spacing(subcarrier_spacing), channel frequency(dl_nr_arfcn) and SSB frequency(ssb_nr_arfcn) to match with Callbox configuration.
Set UE access release (as_release) to 15 and ue_category to "nr".
Perform the Test
Start LTE service (gNB) and run 'cell phy' and 'cell' command, then everything is configured as you intended.
Power on UE on UE sim using power_on command.
Confirm that the UE completes the attach and check the throughput with 't' command.
Log Analysis
Before you start logging (i.e, before you turn on UE) I would suggest to check 'Repetition' in eNB log property window for more detailed verification.
Once the initial attach is done, check UE capability information message and see if UE support PUSCH aggregation (pusch-RepetitionMultiSlots).
If UE notifies that pdsch-RepetitionMultiSlots is supported, gNB enables the PUSCH Aggregation by setting pdsch-AggregationFactor in pusch-Config IE (Information Element)
Once PUSCH aggregation is enabled, you can check in PHY log to confirm that it is really working as expected.
First find any PDCCH/DCI 1_1 that schedule a PUSCH and then check a few consecutive PUSCH. You see the first PUSCH log after the PDCCH is printed with n_rep and the following three PUSCH are transmitted with different rep values and rv_idx values without any separate PDCCH/DCI 0_1. The k2 value in this case is calculated from the first transmission of PUSCH.
You can confirm the transmission of the aggregated PUSCH in visual way on the WebGUI. As shown here, you see the 4 consecutive PUSCH. First transmission is marked in dark color and the following repetition is marked in ligher colors.
RRC / NAS Signaling
RrcReconfiguration (SA)
: This is the RrcReconfiguration sent by gNB to configure PUSCH Aggregation Factor. (
{
message c1: rrcReconfiguration: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcReconfiguration: {
nonCriticalExtension {
masterCellGroup {
cellGroupId 0,
spCellConfig {
spCellConfigDedicated {
initialDownlinkBWP {
pdsch-Config setup: {
resourceAllocation resourceAllocationType1,
rbg-Size config1,
mcs-Table qam256,
prb-BundlingType staticBundling: {
bundleSize wideband
}
}
},
uplinkConfig {
initialUplinkBWP {
pusch-Config setup: {
txConfig codebook,
resourceAllocation resourceAllocationType1,
pusch-AggregationFactor n4,
mcs-Table qam256,
mcs-TableTransformPrecoder qam256,
codebookSubset nonCoherent,
maxRank 1
}
}
},
pdsch-ServingCellConfig setup: {
nrofHARQ-ProcessesForPDSCH n16,
maxMIMO-Layers 2
},
tag-Id 0
}
}
},
dedicatedNAS-MessageList {
'7E025ADA2D4D017E0042010977000BF200F110800101D72E2BF954070000F11000006415020101210203005E01BE3408031F19F1031F11F2'H
}
}
}
}
}