NAS congestion control is the one fault class in this entire course that isn’t actually a fault. Every other module has covered something breaking — a misconfiguration, a drifted clock, a dead UPF. This module covers the AMF working exactly as designed: deliberately rejecting registration attempts it could technically process, because processing all of them would risk failing everyone.
That distinction matters diagnostically. An engineer who treats NAS congestion control as a bug to fix will spend hours looking for a misconfiguration that doesn’t exist. The actual skill here is recognizing the signature quickly, understanding why it’s happening, and addressing the underlying load rather than the symptom.
The AMF rejecting a registration on purpose looks identical, from the UE’s side, to the AMF failing to process one by accident. The cause values are what separate them.
Why an AMF needs congestion control at all
The AMF is a shared, finite resource serving every device in a tracking area. A mass event — a citywide power restoration after an outage, a stadium releasing tens of thousands of devices at once, a software update causing simultaneous device reboots across a fleet — can generate a registration signaling spike far beyond the AMF’s provisioned capacity, all within a few seconds.
Without any congestion control, that spike would degrade processing for every request indiscriminately — including the ones for devices that were already registered and just needed a routine service. NAS congestion control exists specifically to make the degradation controlled and partial rather than total: reject some new attempts outright, so the AMF retains enough headroom to keep serving everyone else.
Figure 1. AMF overload is graded, not binary — the response escalates in steps as load crosses successive thresholds.
The two mechanisms: NAS-level rejection and RAN-level barring
| Mechanism | Where it acts | How it works |
| Mobility Management congestion control | AMF, NAS layer | Rejects a percentage of new registration and service request attempts with a specific cause value and a Back-off Timer instructing the UE how long to wait before retrying |
| Unified Access Control (UAC) barring | gNB, RRC layer, before NAS is even reached | The RAN itself signals barring factors and timers via system information, causing a percentage of UEs to defer their access attempt before it ever generates AMF-bound signaling at all |
These operate at different layers and different points in the escalation curve. NAS-level rejection is the AMF protecting itself once load is already arriving. UAC barring is a earlier, coarser lever — reducing the volume of attempts before they ever reach the core, used when the overload is severe enough that even rejecting at the AMF isn’t sufficient.
Reading the cause values: congestion vs. an actual fault
| Cause | Meaning | How to tell it’s congestion, not a fault |
| #22 | Congestion | Explicit — this cause value exists specifically for this scenario. Always accompanied by a Back-off Timer telling the UE when it may retry |
| #42 | Severe network failure | Used in some congestion scenarios as an alternative to #22 depending on vendor/release — check for an accompanying back-off timer, which distinguishes controlled congestion from an actual severe fault |
| No cause / connection simply drops | Not congestion control by design — legitimate congestion control always returns an explicit reject with a cause and timer. A silent drop or timeout during high load looks similar but indicates the AMF is beyond even its congestion-control capacity — a more severe condition |
The diagnostic tell: if rejected registrations cluster in a short time window, affect a broad cross-section of devices rather than one model or one cell, and carry cause #22 with a back-off timer, this is congestion control operating correctly — the fix is capacity or load distribution, not a configuration change. If rejections lack cause codes entirely, or if the pattern is narrow (one device model, one cell, one slice) rather than broad, treat it as a genuine fault and apply the relevant earlier module instead.
Worked example
A regional AMF pool reports a spike in registration failures lasting roughly six minutes, affecting a broad mix of device models and cells, then resolving on its own without any configuration change.
- Classify and scope. The failure pattern is broad — not concentrated on one device model, cell, or slice — which immediately points away from every device-specific or cell-specific fault class covered in Modules 2 through 13.
- Read the cause values. Rejected registrations carry cause #22 with Back-off Timer values ranging from several seconds to a couple of minutes, escalating as the event continues — consistent with graduated congestion control, not a fault.
- Correlate with an external event. The six-minute window aligns exactly with a regional power restoration following a brief outage — a mass simultaneous device power-on event across the affected tracking areas.
- Confirm no underlying fault. The AMF’s own resource utilization metrics show it operating at its provisioned overload threshold throughout the window — exactly as designed, not evidence of an unrelated capacity problem.
- Assess whether action is needed. Since the AMF recovered on its own once the registration surge subsided, no reactive fix is required for this specific event. The forward-looking question is whether this pool’s provisioned capacity is adequate for the region’s realistic mass-event scenarios — a capacity-planning question, not a troubleshooting one.
The entire investigation here is about recognizing what did NOT need fixing — the AMF worked exactly as intended, and the only genuine follow-up is a capacity conversation, not a configuration change.
Elimination order for a suspected congestion event
- Check whether the failure pattern is broad (many devices, many cells) or narrow (one device model, one cell, one slice). Broad points here; narrow points back to an earlier module.
- Read the actual cause values on rejected registrations — #22 or #42 with an accompanying Back-off Timer is the specific signature of deliberate congestion control.
- Correlate the timing against any known mass-event trigger: a power restoration, a scheduled mass update, a large public gathering.
- Check the AMF’s own load/utilization metrics during the window to confirm it was genuinely near a provisioned threshold, rather than assuming from the symptom alone.
- If the pattern recurs regularly rather than as a one-off event, treat it as a capacity-planning finding, not a fault to troubleshoot away.