5G NR PUSCH - Physical Uplink Shared Channel

What PUSCH means in simple terms

In practical engineering language, PUSCH is the uplink data channel the UE uses when it has been given or has derived the uplink resources for transmission. The UE sends its payload on selected RBs and symbols, and the gNB tries to decode that transmission using the configured uplink assumptions.

• PUSCH is the main uplink data-bearing channel in NR.
• It often depends on an uplink grant delivered by PDCCH.
• Its behavior is shaped by RBs, symbols, MCS, DMRS, layers, and UE power conditions.
• Engineers inspect PUSCH when judging uplink throughput, uplink coverage, and gNB decode quality.

Technical summary

How PUSCH works in practice

Engineers should read PUSCH as a scheduled uplink transmission event. The network decides the resources and assumptions, the UE sends on those resources, and the gNB then tries to decode the received waveform under real channel and interference conditions.

Uplink grant and allocation

In many normal scheduled cases, the UE receives an uplink grant and then transmits PUSCH on the granted RBs and symbols. This is why uplink troubleshooting often starts from the control step before the actual transmission.

MCS and coding

The MCS determines how efficiently the UE uses the granted resources. A more aggressive MCS can increase throughput, but only if uplink channel quality and gNB decode conditions remain strong enough.

DMRS and decoding support

PUSCH relies on reference-signal support so the gNB can estimate the uplink channel well enough to decode the transmission. This means not all granted resource elements become pure payload.

UE power and uplink limitations

Uplink performance depends not only on resource allocation but also on what the UE can realistically transmit. Power limits, coverage conditions, and uplink interference can become the real bottleneck.

PUSCH formats and operational variants

PUSCH does not use numbered channel formats like PUCCH. In practice, engineers usually compare the main uplink transmission variants below.

How PUSCH connects to control, timing, and uplink conditions

• PDCCH often delivers the uplink grant that starts the scheduled PUSCH transmission.
• OFDM provides the time-frequency grid on which PUSCH is mapped.
• Numerology defines slot timing, symbol duration, and uplink scheduling scale.
• Frame structure explains where uplink resources sit in time and how HARQ timing is interpreted.
• Bandwidth Part (BWP) defines the active uplink bandwidth context seen by the UE.

A common engineering mistake is to treat uplink performance like a mirror image of downlink behavior. In real networks, UE transmit power and uplink channel conditions make PUSCH analysis distinctly different.

Where PUSCH appears in real procedures

Regular uplink data delivery

PDCCH uplink grant -> PUSCH transmission -> gNB decode -> HARQ handling

This is the core PUSCH workflow. The UE receives or derives the transmission opportunity, sends the uplink payload, and then the network evaluates decode success and follow-up retransmission behavior.

Connected-mode uplink throughput behavior

Scheduler decision -> UE transmit opportunity -> PUSCH payload delivery -> uplink throughput result

Engineers analyzing upload speed or latency should inspect how much useful uplink resource is really being granted and how well the gNB is decoding it under the current radio conditions.

Coverage-limited uplink cases

Near the edge of coverage, a PUSCH problem may be driven less by nominal resource availability and more by UE power headroom, uplink interference, and uplink decode robustness at the gNB.

Real-world engineering examples

Example 1: Why uplink speed can remain low even with good downlink conditions

The downlink may look healthy while uplink remains constrained because the UE is power-limited, because uplink grants are modest, or because the gNB is seeing unstable decode quality on PUSCH.

Example 2: Why a valid uplink grant still does not guarantee good uplink throughput

Even with a grant, the usable throughput depends on MCS, DMRS overhead, retransmissions, uplink radio conditions, and whether the UE can sustain the requested transmission cleanly.

Example 3: Why a PUSCH issue might actually start with control

If expected uplink traffic never appears, the first question may be whether the UE received and interpreted the uplink grant correctly on PDCCH rather than whether the data channel itself failed first.

What to check in logs, counters, and traces

• whether the expected uplink grant was present before the PUSCH transmission
• RB allocation, symbol allocation, and actual uplink scheduling cadence
• MCS and whether it is realistic for the uplink radio conditions
• DMRS setup and uplink decode stability at the gNB
• UE power headroom or transmit limitation indicators if available
• HARQ retransmission behavior and uplink BLER
• active uplink BWP and numerology assumptions
• whether uplink throughput estimates match the granted resources

Common mistakes engineers make with PUSCH

• assuming uplink behaves just like downlink under the same signal conditions
• ignoring UE power limitations and uplink coverage constraints
• looking only at granted RB count and not at symbols, DMRS, MCS, or retransmissions
• analyzing missing uplink traffic without checking the preceding control grant
• forgetting that active uplink BWP can be more relevant than the full carrier width

Beginner takeaway

PUSCH is the main uplink data channel in 5G NR. If you want to understand why the UE is or is not sending useful uplink data, PUSCH is one of the first places to inspect.

Advanced engineer notes

• Real uplink efficiency depends on both granted resources and what the UE can transmit reliably.
• Power limits, DMRS quality, and retransmission behavior often explain uplink gaps better than headline coverage metrics alone.
• PUSCH analysis becomes much stronger when paired with grant interpretation, BWP context, and HARQ behavior.
• Uplink troubleshooting should always separate scheduler limitation from UE-side radio limitation.

FAQ

What does PUSCH do in 5G NR?

PUSCH carries most scheduled uplink data from the UE to the network once the transmission resources are known.

How is PUSCH related to PDCCH?

In many scheduled uplink cases, PDCCH delivers the uplink grant that tells the UE where and when to transmit on PUSCH.

Why is PUSCH important for uplink throughput?

Because it is the main uplink data-bearing channel. Uplink throughput depends on how much PUSCH resource is really granted and how well the transmission can be decoded at the gNB.

Why is uplink troubleshooting often harder than downlink troubleshooting?

Because uplink depends more strongly on UE transmit power, coverage margin, interference, and gNB-side decode quality, not only on network-side scheduling choices.

What should I inspect first when uplink data seems low?

Start with the uplink grant, PUSCH allocation, MCS, DMRS setup, retransmission behavior, and UE power or coverage limitations.

How does BWP affect PUSCH?

PUSCH is interpreted within the active uplink bandwidth context, so engineers should read allocations using the active BWP instead of only the nominal carrier bandwidth.

Use the tools naturally in this workflow

Pair this page with the NR Throughput Calculator when you want to translate uplink resource allocation into practical rate expectations, and use the 3GPP Decoder when you need to connect uplink procedures and signaling to the radio behavior you are seeing.