5G NR PUSCH

The Physical Uplink Shared Channel (PUSCH) is the main physical channel used by a 5G NR UE to send user data toward the gNB. For a protocol test engineer, however, PUSCH is much more than “the uplink data channel.”

3GPP defines the PUSCH physical-layer processing and resource mapping primarily across TS 38.211, TS 38.212, TS 38.213 and TS 38.214, while TS 38.331 carries the RRC configuration used by the UE.

1. What exactly is PUSCH?

In simple terms:

PUSCH = the physical uplink radio resource on which the UE transmits UL-SCH and, when required, UCI.

UCI (Uplink Control Information) is control information sent by the UE to the gNB to help the network manage downlink and uplink transmission.

1. HARQ-ACK/NACK tells the gNB whether the UE successfully decoded a PDSCH transmission.

2. CSI (Channel State Information) provides information such as CQI, PMI and RI, helping the gNB select suitable MCS, precoding and transmission layers.

3. Scheduling Request (SR) tells the gNB that the UE needs uplink resources to transmit data.

4. UCI can be transmitted on PUCCH when dedicated uplink control resources are available.

5. UCI can also be multiplexed with PUSCH, particularly when the UE is already transmitting uplink data.

6. In practical logs, UCI is therefore important for understanding the feedback loop: PDSCH → UE decoding → HARQ-ACK/CSI → gNB scheduling decision.

A simplified protocol stack is:

The important point is that PUSCH is a physical channel, while UL-SCH is the transport channel.

For example, when a UE uploads a photo:

TS 38.212 defines NR multiplexing and channel coding, including UL-SCH processing.

IP packets – the photo is chopped up and wrapped in IP headers so it can be routed like any other internet traffic.

PDCP – compresses IP headers, encrypts and integrity-protects the data, and adds sequence numbers so nothing arrives out of order.

RLC – segments or concatenates PDCP data to fit the radio, and (in AM mode) handles retransmission of lost pieces.

MAC – multiplexes data from different logical channels into a single transport block and controls HARQ retransmissions.

UL-SCH transport block – one chunk of MAC data, sized for the current uplink grant, ready for channel coding.

LDPC coding + rate matching – adds redundancy (low-density parity-check code) so the gNB can correct errors, then punctures/repeats bits to exactly fit the allocated resources.

Scrambling – XORs the coded bits with a pseudo-random sequence tied to the UE's identity, to randomize interference between users.

Modulation – maps scrambled bits onto complex symbols (QPSK, 16/64/256-QAM) depending on channel quality.

Layer mapping – splits the symbol stream across one or more MIMO spatial layers.

Precoding – applies a matrix to the layer symbols to map them onto physical antenna ports, shaping the transmission for the channel.

PUSCH – the precoded symbols, along with DM-RS, are placed onto the assigned resource elements and transmitted over the air.

gNB – receives the waveform, reverses the whole chain (channel estimation, demodulation, descrambling, LDPC decoding) to recover the original transport block, and ultimately your photo.

2. What information can PUSCH carry?

PUSCH can carry several types of information.

2.1 User-plane data

This is the most common use.

For example:

UE → Internet

The UE's IP traffic eventually becomes an UL-SCH transport block, which is transmitted using PUSCH.

Examples:

• TCP upload

• UDP traffic

• VoNR media packets

• video upload

• FTP upload

• application traffic

2.2 MAC control information

MAC control elements can also be multiplexed into the UL-SCH transmission.

Examples include:

• Buffer Status Report — BSR

• Power Headroom Report — PHR

• other MAC CEs depending on the procedure

This is particularly important for uplink scheduling.

For example:

UE has 2 MB data waiting

        ↓

UE sends BSR

        ↓

gNB learns UE's buffer status

        ↓

gNB sends UL grant

        ↓

UE transmits data on PUSCH

This creates the basic BSR → UL scheduling → PUSCH loop.

2.3 UCI on PUSCH

PUSCH can also carry UCI such as:

• HARQ-ACK

• CSI

• other uplink control information depending on configuration

Therefore, don't assume:

PUSCH = only user data.

A PUSCH transmission may contain a combination of:

UL-SCH data + MAC CE + UCI

UCI multiplexing on PUSCH is specified as part of the NR uplink control procedures. The RRC configuration includes parameters such as betaOffsets and UCI scaling associated with UCI-on-PUSCH.

3. How does the gNB schedule PUSCH?

This is one of the most important concepts.

Normally, the UE does not simply decide:

"I have data, so I will transmit PUSCH whenever I want."

Instead, the gNB scheduler decides the uplink resources.

A simplified sequence is:

The UL scheduling DCI is normally DCI format 0_0 or 0_1, with other formats/features applicable depending on configuration and release.

The DCI does not necessarily contain every PUSCH parameter explicitly.

For example, the DCI can contain a Time Domain Resource Assignment index.

That index points to an RRC-configured table.

4. The most important PUSCH scheduling parameters

For protocol debugging, I recommend thinking about PUSCH using five questions:

Question	Important parameter
When will PUSCH occur?	K2
Which symbols are used?	Start symbol + Length / SLIV
How is PUSCH mapped?	Mapping Type A/B
Which frequency resources?	PRB allocation
How robust/fast is transmission?	MCS / TBS / coding rate

Then add:

·       DM-RS

·       Power control

·       Frequency hopping

·       Transform precoding

·       UCI multiplexing

·       PTRS

5. K2 — the most important timing parameter

If you remember only one PUSCH timing parameter, remember K2.

K2 defines the relationship between the slot carrying the UL scheduling DCI and the slot in which PUSCH is transmitted.

For the common case where PDCCH and PUSCH use the same numerology,

n_pusch = n_pdcch + K₂

For example:

PDCCH / DCI

Slot 100 à  K2 = 2 à PUSCH Slot 102

So if a UE log says:

UL DCI received

·       SFN.Slot = 100.4

·       K2 = 2

you should immediately look for PUSCH around: 100.6

assuming the same numerology and the corresponding slot indexing.

K2 is part of the configured PUSCH time-domain resource allocation. The RRC structure contains k2, mappingType, and startSymbolAndLength.

Do not blindly interpret K2 as a universal "milliseconds delay."

K2 is a slot offset, and slot duration depends on SCS:

SCS	Slot duration
15 kHz	1 ms
30 kHz	0.5 ms
60 kHz	0.25 ms
120 kHz	0.125 ms

Therefore:

30 kHz , K₂ =2, means: 2 x 0.5= 1ms

60 kHz , K₂ =2 means: 2*0.25= 0.5ms

So K2 = 2 does not always mean 1 ms.

When PDCCH and PUSCH numerologies differ, determining the exact timing relationship requires the 38.214 timing procedure rather than simply adding two slot numbers.

6. Why does the network need K2?

Imagine this situation:

The UE needs processing time.

If the gNB scheduled PUSCH immediately in the same slot, the UE might not have enough time to process the grant and prepare the transmission.

Therefore K2 provides the required scheduling-to-transmission separation.

Trade-off

Smaller K2:

Advantage

• lower scheduling latency

• faster UL response

Challenge

• less UE processing time

Larger K2:

Advantage

• more processing time

• useful for demanding processing conditions

Disadvantage

• increases UL scheduling latency

This becomes particularly important for latency-sensitive applications.

7. PUSCH time-domain resource allocation

Now suppose the gNB sends: DCI 0_1

Time Domain Resource Assignment = 3

The value 3 should not immediately be interpreted as:

start symbol = 3.

It is typically an index into a configured PUSCH time-domain allocation table.

For example, imagine the UE has:

Index	K2	Mapping	Start	Length
0	1	Type A	0	14
1	2	Type A	0	14
2	2	Type A	1	13
3	2	Type A	2	12
4	3	Type B	4	8

The exact table is configuration/specification dependent; this is a realistic example table for understanding logs, not a universal operator configuration.

If DCI says:

TimeDomainAssignment = 3

the UE looks up row 3:

K2 = 2

Mapping = Type A

Start = 2

Length = 12

This table-driven approach is extremely important when decoding UE logs.

8. StartSymbolAndLength and SLIV

NR often represents the starting symbol and number of symbols using:

StartSymbolAndLength commonly discussed as the SLIV — Start and Length Indicator Value.

Conceptually:  SLIV = f(S, L)

where:

• S = starting OFDM symbol

• L = number of consecutive symbols

For example:

The exact SLIV encoding is defined by the NR resource-allocation procedure.

if (L −1) ≤ 7 then

SLIV =14⋅(L −1) + S

else

SLIV =14⋅ (14− L +1) + (14−1− S)

where 0 < L ≤ 14 − S, and The PUSCH mapping type is set to Type A or Type B

For this example:

S = 2, L = 12,

and the corresponding SLIV is: SLIV =53

The important point is not memorizing every SLIV number.

Instead:

Decode SLIV → obtain S and L → draw the PUSCH symbols on the slot timeline.

The configured RRC structure uses startSymbolAndLength as the index/encoding for these valid start-length combinations.

9. Mapping Type A vs Type B

PUSCH has two mapping types:

Mapping Type A

Mapping Type B

These are not two different physical channels.

They describe how the PUSCH allocation and its DM-RS placement relate to the transmission duration.

Mapping Type A

Generally associated with allocations that are aligned toward the beginning of the slot.

The DM-RS position is tied to the Type-A DM-RS positioning rules.

Mapping Type B

Useful for shorter or more flexibly positioned PUSCH transmissions.

The DM-RS position is determined relative to the beginning of the PUSCH allocation.

Mapping type is part of the PUSCH time-domain allocation and is selected/configured along with the resource assignment.

10. Frequency-domain resource allocation

Time tells us:

When does PUSCH occur?

Frequency allocation tells us:

Which PRBs does PUSCH occupy?

Suppose the active UL BWP has:

273 PRBs

and the scheduler assigns:

PRB 40 → PRB 139

Then: N _PRB =100 are allocated.

At 30 kHz SCS: BW_PRB = 12 x 30 kHz = 360 kHz

Therefore: 100 x 360 kHz = 36 MHz

So the PUSCH occupies approximately 36 MHz of instantaneous frequency-domain resources.

This does not mean the carrier itself is only 36 MHz wide. The remaining PRBs can be used by other UEs, control channels, SRS, guard regions, etc.

11. Frequency resource allocation Type 0 and Type 1

PUSCH frequency allocation can use different resource-allocation mechanisms.

Resource Allocation Type 0

Resource allocation is represented through a bitmap/resource indication mechanism.

Resource Allocation Type 1

The allocation is based on a starting position and number/size of resource blocks, making it convenient to represent contiguous allocations.

In practical UE logs you may see something resembling:

Frequency domain assignment

RB Start = 40

RB Length = 100

or a decoded RIV/resource indication value.

The exact interpretation depends on the DCI format, RRC configuration and resource-allocation configuration. The PUSCH resource-allocation configuration is part of the 38.214 procedure.

12. Putting time + frequency together

Suppose the UE receives:

UL DCI

PDCCH:

SFN.Slot = 125.6

K2 = 2

PUSCH:

PRB Start = 40

PRB Length = 100

Start Symbol = 2

Length = 12

And: npusch = 125.6+2 =125.8

So the UE transmits on:

SFN.Slot 125.8

Symbols 2–13

PRBs 40–139

This is exactly how you should mentally reconstruct a PUSCH transmission from logs.

13. Where does DM-RS fit?

This is one of the most important aspects of PUSCH.

The gNB needs to estimate the radio channel before reliably decoding the PUSCH.

The UE therefore transmits DM-RS — Demodulation Reference Signal along with PUSCH.

Conceptually:

The gNB uses DM-RS to estimate:

H(f,t)

where H represents the radio channel response over frequency and time.

The gNB then uses that estimate to demodulate the PUSCH data.

14. DM-RS configuration type 1 and type 2

Do not confuse:

PUSCH Mapping Type A/B

with:

DM-RS Configuration Type 1/2

They are different concepts.

DM-RS Configuration Type 1

Uses a particular frequency-domain DM-RS RE structure.

DM-RS Configuration Type 2

Uses a different RE arrangement and can provide different pilot density/resource behavior.

The DM-RS mapping for PUSCH is defined in TS 38.211. 3GPP test specifications also explicitly reference the PUSCH DM-RS mapping rules and configuration type.

15. Why does DM-RS consume PUSCH resources?

Imagine:

Without DM-RS, All REs → Data

versus:

With DM-RS,

·       Some REs → DM-RS

·       Remaining REs → Data

Therefore, increasing DM-RS density can improve channel estimation but reduces resources available for payload.

This is a classic engineering trade-off:

More reference signals à Better channel tracking

but:

More reference signals ⇒ less payload efficiency

For a fast-changing channel, additional DM-RS positions can be useful.

For a relatively stable channel, excessive reference-signal overhead reduces spectral efficiency.

16. Additional DM-RS positions

PUSCH DM-RS can be configured with additional positions.

Conceptually:

This becomes particularly relevant for:

• high UE mobility

• high Doppler

• long PUSCH allocations

• challenging radio conditions

The RRC configuration includes parameters such as dmrs-AdditionalPosition and maxLength; Type-A and Type-B configurations can have different DM-RS-related settings.

17. A realistic UE log example

Let's build a realistic 30 kHz SCS, 5G SA, n78 example.

Imagine the UE receives:

[UL_DCI]

SFN              = 125

Slot             = 6

RNTI             = C-RNTI

DCI Format       = 0_1

Frequency Domain Assignment

RB Start         = 40

RB Length        = 100

Time Domain Assignment

Index            = 3

MCS              = 20

NDI              = 1

RV               = 0

HARQ Process     = 5

PUSCH TDRA[3]

K2               = 2

Mapping Type     = Type A

SLIV             = 53

Start Symbol     = 2

Length           = 12

DMRS

Config Type      = 1

Additional Pos   = pos0

Max Length       = 1

Now decode it step by step.

Step 1 — Find the PUSCH slot

DCI:

N =125.6

K2:

K2=2

Therefore:

N= 125.6 + 2 =125.8

So we expect PUSCH in:

SFN 125, Slot 8

Step 2 — Find the symbols

SLIV:

53

Decoded as: S = 2, L = 12

Therefore:

PUSCH symbols = 2...13

Step 3 — Find frequency resources

RB Start = 40

RB Length = 100

Therefore:

PRB = 40 … 139

Total:

N_PRB =100

18. Estimate the available REs

Each PRB contains: 12 subcarriers.

Therefore:

100 x 12 =1200 REs per OFDM symbol.

There are 12 PUSCH symbols:

1200 x 12 =14400

REs before removing DM-RS and other overhead.

If one complete OFDM symbol is occupied by DM-RS:

1200 REs are used for DM-RS.

Approximate remaining REs:

14400-1200 = 13200

before considering other overheads such as UCI, PTRS or other implementation-dependent details.

19. Connecting REs to data rate

Suppose:

100 PRBs

12 PUSCH symbols

1 DM-RS symbol

64-QAM

64-QAM carries:

Q_m =6 bits per modulation symbol.

Therefore, the rough uncoded bit capacity is:

13200 x 6 =79200 bits

or:

79.2 kbits

before coding/rate matching overhead.

If the effective code rate were approximately:

R = 0.75

then a rough payload estimate would be:

79200 x 0.75 = 59400 bits

or approximately:

59.4 kbits

This is not the final NR TBS calculation. The actual TBS comes from the standardized TBS procedure using the number of REs, modulation order, layers, overhead and target code rate. But this rough calculation is extremely useful when sanity-checking a log.

20. Why MCS matters

The scheduler chooses an MCS based on radio conditions and scheduling objectives.

For example:

So when debugging PUSCH throughput, don't look only at PRB allocation.

Check:

21. A practical PUSCH throughput problem

Suppose you observe:

UL PRBs       = 100

MCS           = 27

Rank          = 2

BLER          = 12%

PUSCH        = retransmissions

It is tempting to conclude:

"The scheduler is giving enough PRBs, so throughput should be high."

Not necessarily.

A high MCS with poor channel quality can produce:

This is a very common real-world troubleshooting pattern.

22. PUSCH HARQ

PUSCH transmissions are associated with an uplink HARQ process.

Example:

When troubleshooting UL throughput, look at:

HARQ process ID

NDI

RV

TB size

CRC result

retransmission count

For example:

HARQ ID = 5

NDI = 1

RV = 0

CRC = FAIL

HARQ ID = 5

NDI = 1

RV = 2

CRC = PASS

This tells you that the original transmission failed and a retransmission was subsequently decoded.

23. PUSCH power control

PUSCH performance is also strongly connected to UL transmit power.

The gNB controls UE uplink transmission power through PUSCH power-control mechanisms.

A simplified view is:

P_PUSCH  = baseline power+ resource dependent component + closed-loop correction

The exact standardized formula contains several configuration terms and is specified in TS 38.213.

The practical relationship is:

But simply increasing power is not always the answer:

24. Frequency hopping

PUSCH can also use frequency hopping.

Frequency hopping can provide frequency diversity.

But it also increases scheduling/resource-management complexity.

The RRC configuration includes PUSCH frequency-hopping parameters such as frequencyHopping and frequency-hopping offset lists.

25. PUSCH with BSR — a very practical scenario

Consider a UE uploading a large file.

Step 1 — Data arrives

UE MAC buffer

0 KB

 ↓

500 KB

 ↓

2 MB

The UE needs uplink resources.

Step 2 — UE sends BSR

The BSR informs the gNB about the amount of UL data waiting in the buffer.

Step 3 — gNB scheduler

The scheduler evaluates:

UE buffer

UE priority

QoS

CQI

UL channel quality

power headroom

available PRBs

other UE demand

and decides:

PRBs = 100

MCS = 20

K2 = 2

HARQ ID = 5

Step 4 — gNB sends DCI

DCI 0_1

       ↓

Time allocation

Frequency allocation

MCS

HARQ process

NDI

RV

TPC

Step 5 — UE transmits PUSCH

PUSCH

 ─ DMRS

 ─ UL-SCH

 ─ MAC CE

 ─ possibly UCI

Step 6 — gNB decodes

CRC PASS

   ↓

ACK

   ↓

Next scheduling opportunity

This is the fundamental BSR → grant → PUSCH → HARQ cycle.

26. A complete log-analysis example

Suppose your test log contains:

15:21:10.100  UL-DCI

              RNTI = 0x1234

              DCI = 0_1

              TDRA = 3

              FreqAlloc = RB40-RB139

              MCS = 20

              HARQ = 5

              NDI = 1

              RV = 0

15:21:10.100  RRC TDRA[3]

              K2 = 2

              Mapping = Type A

              SLIV = 53

15:21:10.600  PUSCH TX

              RB40-RB139

              Symbol2-13

              HARQ5

              MCS20

15:21:10.620  PUSCH CRC

              PASS

At 30 kHz:

T_slot = 0.5ms

Therefore:

K2 =2 à 1ms

The key observation is:

DCI (K2 = 2)

 ↓

PUSCH

You should then verify:

Timing

n_pusch = n_DCI +K2

Frequency

40–139

Time

Symbol 2–13

MCS

20

HARQ

Process 5

NDI 1

RV 0

DM-RS

Check that the observed DM-RS location agrees with:

Mapping Type A

DMRS Type

Additional Position

Max Length

This is how a protocol engineer turns a large UE trace into a meaningful PUSCH analysis.

27. PUSCH troubleshooting decision tree

When PUSCH throughput is low, use this sequence.

This sequence prevents a common mistake:

blaming the scheduler before proving that the UE's radio transmission is actually healthy.

28. Important PUSCH parameters to remember

Parameter	What it tells you	Where to investigate
K2	PUSCH slot relative to scheduling	38.214 / RRC
Mapping Type	PUSCH/DM-RS mapping behavior	38.214
SLIV	Start symbol + allocation length	38.214
Start Symbol	First PUSCH symbol	TDRA(Time domain Resource Allocation)
Length	Number of PUSCH symbols	TDRA(Time domain Resource Allocation)
PRB allocation	Frequency resources	DCI
MCS	Modulation/coding selection	DCI
NDI	New/retransmission indication	DCI
RV	Redundancy version	DCI
HARQ ID	HARQ process	DCI
DMRS Type	DM-RS frequency mapping	RRC
DMRS Additional Position	DM-RS density	RRC
DMRS Max Length	Single/double-symbol DM-RS behavior	RRC
TPC	UL power-control adjustment	DCI/RRC
Frequency hopping	Frequency-domain movement	RRC/DCI
Rank/layers	Spatial transmission	DCI/PHY
TBS	Transport block size	PHY/MAC calculation

29. The most useful model

For every PUSCH transmission, think:

Then add one more question:

Was it successfully decoded?

That takes you to:

30. One practical rule for protocol testers

When you encounter a PUSCH in a log, don't start by looking at throughput.

Start with this exact checklist:

1. Find UL DCI

2. Identify DCI format

3. Identify RNTI

4. Decode frequency-domain assignment

5. Decode time-domain assignment

6. Find K2

7. Calculate PUSCH slot

8. Decode SLIV

9. Find start symbol and length

10. Check mapping type

11. Check DM-RS configuration

12. Check MCS

13. Check TBS

14. Check HARQ process

15. Check NDI/RV

16. Check PUSCH power

17. Check UL SINR/BLER

18. Check CRC

19. Check retransmissions

20. Compare expected vs actual throughput

This approach turns PUSCH from a collection of PHY parameters into a traceable scheduling transaction.

31. The key relationship: K2 + TDRA + DCI

The most important relationship to remember is: DCI 0_x   à TDRA index à K₂ +SLIV + Mapping Type A PUSCH

For example:

This is the connection that makes PUSCH scheduling understandable from real UE traces.

32. One final real-world insight

A PUSCH problem is rarely caused by a single parameter.

Consider:

100 PRBs

MCS 27

2 layers

K2 = 2

BLER = 15%

At first glance, the allocation looks excellent.

But if the UL channel cannot support MCS 27:

High MCS

   ↓

CRC failures

   ↓

HARQ retransmissions

   ↓

Effective throughput decreases

Conversely:

Excellent SINR

Low BLER

But only 10 PRBs allocated

can also produce poor throughput.

So the correct engineering equation is closer to:

UL throughput ~=  f(N_{PRB ,} N_symb, MCS, Layers, TBS, BLER, HARQ, DMRS overhead, UCI Overhead, Scheduling frequency)

That is why PUSCH should be analyzed as an end-to-end scheduling and PHY transmission process, rather than simply as an uplink physical channel.

3GPP references

• TS 38.211 — NR Physical channels and modulation; PUSCH and DM-RS physical mapping.

• TS 38.212 — NR Multiplexing and channel coding, including UL-SCH processing.

• TS 38.213 — NR Physical layer procedures, including uplink control and power-control procedures.

• TS 38.214 — NR Physical layer procedures for data, including PUSCH time/frequency resource allocation. Recent 3GPP change-control material continues to reference PUSCH resource allocation in clause 6.1.2.1.

• TS 38.331 — NR RRC, including PUSCH-TimeDomainResourceAllocation, k2, mappingType, and startSymbolAndLength