Why QoS is Needed
In a cellular network, a large number of terminals within the same cell share air interface and backhaul resources. If all traffic is forwarded on a "best effort" basis, video, voice, and critical control messages may be crowded out by bursty data. QoS (Quality of Service) allows high-priority services to obtain predictable bandwidth, latency, and packet loss by marking, queuing, scheduling, and shaping traffic at various network nodes. For industrial remote control, in-vehicle safety messages, or medical alert IoT applications, QoS is often part of contractual indicators rather than just "being able to access the Internet".
Bearer Model in LTE
LTE establishes a default bearer for each PDN connection, usually mapped to a best-effort IP path. If supported by the operator and terminal, a dedicated bearer can be established for specific services, bound to different QCIs (QoS Class Identifiers). Different QCIs correspond to standardized priorities, latency, and packet loss targets—for instance, voice typically uses QCI=1, while massive IoT connections may use lower-priority classes. Terminal modules need to work with the core network through NAS/AS signaling to complete bearer establishment; the application layer usually perceives this as "multiple IP paths" or DSCP/802.1p marking (if extended on the enterprise side).
QoS Flow in 5G
5G SA introduces more fine-grained QoS Flow, where a PDU session can contain multiple Flows, each mapped to a different DRB (Data Radio Bearer). The network schedules based on 5QI (5G QoS Identifier) and related parameters (GFBR, MFBR, latency budget, etc.). In IoT scenarios using network slicing, the slice, DNN, and QoS Flow together determine the end-to-end experience. The module side needs to confirm whether the protocol stack exposes Flow-level statistics for joint analysis with the OTA platform.
Implementation Notes
Not all IoT SIM card data plans provide dedicated bearers or differentiated QoS, so it is necessary to confirm policies and billing with the operator. Even if the core network configures QCI, if the enterprise private network firewall has not set up corresponding queues, bottlenecks may still occur at the VPN or cloud ingress. The application layer can use DSCP marking, but end-to-end consistency requires full path coordination. For low data rate sensors, blindly pursuing high QCI may increase signaling and costs and is not economical.
How Guaranteed Rate and Maximum Rate Are Scheduled Differently
Cellular QoS does not take effect because an application marks its own packets as important. When the network assigns resources to a data session, it needs to know whether this traffic may be queued, roughly what delay is allowed, whether a loss should be recovered with priority, and whether a minimum rate is promised. LTE binds a quality class to a bearer. In 5G one session can be split into several flows, each with its own identifier, then mapped onto a radio bearer. A guaranteed bit rate is a floor the network tries to hold. A maximum bit rate is a ceiling. Both can exist at once. A flow with no guaranteed rate can be pushed very low when the cell is busy, even when the terminal's radio is fine.
Before use, confirm that the subscription and the network really have differentiated policy turned on. Many IoT access points offer only one default best-effort path. An application mark does not become a dedicated bearer. If the contract names a class, also ask whether it applies only on the radio side, or whether queues in the enterprise network and at the cloud entrance recognize the same mark. Asking for voice-class priority for a low-rate sensor raises signaling and cost, and there is little data on the air interface to protect. What is needed is "alarms before logs," not the highest class for every byte.
Marks Applied, Queues Not
The most common miss is a differentiated-services mark on the terminal, no mapping at the operator, and first-in-first-out forwarding at the enterprise firewall. No segment of the path is actually queuing. The second is to accept a default bearer as if it were a dedicated one. Delay looks good in an empty lab, and under a busy cell the alarm and the upgrade package are squeezed together. The third is to treat flow statistics as application delay. Radio scheduling is already preferential, but the server is still rate-limited on the public backhaul. If several flows share one socket in the module, the network may have split them and the host still cannot tell them apart.
Priority is meaningless before the session itself exists. Confirm the parameter set first; see PDP context. Whether a reduced-capability 5G device supports multiple flows also depends on whether the network has enabled that feature; see 5G RedCap. Do not copy handset bearer behavior onto the module.
Acceptance should run alarms and logs twice: once with the cell idle, and once with uplink congestion created on purpose. If both are fast while idle, that does not show whether priority is in effect. If, under congestion, the alarm still arrives inside the agreed time and the log is deferred, scheduling has separated the flows. If the two services share one socket, both slow down together under congestion. Split the flows on the host before suspecting that the network never enabled the policy. The mark value, the bearer or flow identifier, and the firewall queue should line up in the same capture. Do not announce end-to-end differentiation while any of the three is missing. After a low-rate terminal is granted a guaranteed rate, also check whether that guarantee is larger than the real service. Too large a guarantee spends subscription and radio resource for no benefit. Too small a guarantee is still crushed when the cell is busy. Write those three numbers into the integration record, so a later SIM or access-point change shows which item moved. Comparing delay only while idle mistakes a default bearer for a guaranteed rate that is already in effect, and under load the alarm is still squeezed with the log. The acceptance record should keep one arrival time from the idle run and one from the congested run. Idle data alone cannot prove the guaranteed rate is in effect.