Network QoS Simulator

Interactive workbench for seeing how network QoS scheduling protects critical IoT traffic during congestion

A deterministic network QoS simulator that compares strict priority, weighted fair queuing, traffic shaping, and policing across mixed IoT traffic classes.

Network QoS Queue scheduling Congestion IoT traffic classes

Network QoS Scheduling Workbench

Send mixed IoT traffic through one congested gateway and watch how the scheduler chooses which packets leave first. The default case shows a real trade-off: strict priority protects alarms, but lower-priority traffic can wait or drop.

0%critical packets on time

0/0packets delivered

0packets dropped

0%peak queue pressure

What Changes

QoS changes queue order, service share, and drop rules. It does not create new bandwidth; it decides who waits when demand exceeds the link.

Why It Matters

An alarm, actuator command, telemetry sample, log line, and firmware chunk should not all compete as equal traffic during a gateway bottleneck.

Try First

Step through the congested gateway with strict priority. Then switch to weighted fair queuing and compare alarm latency against bulk progress.

Common Mistake

Network QoS is not MQTT QoS. MQTT QoS confirms message delivery between clients and broker; network QoS schedules packets inside the network.

Scenarios

Scheduling policy

Strict priority

Each policy uses the same offered traffic and link capacity so the trade-off is visible.

Link capacity

64 kbps

Offered traffic load

120%

Above 100%, the workload is intentionally larger than the bottleneck can comfortably carry.

Base network latency

35 ms

Queue depth

14 packets

Alarm burst

8 packets

Gateway Queue And Scheduler

The simulation is paused at 4.2 seconds so the queue trade-off is already visible.

Strict priority always serves the highest non-empty queue first. It protects alarms, but low-priority flows may starve during sustained congestion.

IoT devicesAlarms, commands, telemetry, logs, bulk

QoS schedulerStrict priority

Cloud or controllerReceives selected packets first

safety alarm actuator command telemetry logs firmware bulk

Time 0.0 sStep to inspect the next scheduling decision.

Queue policy readyThe gateway will classify traffic and schedule packets according to the selected policy.

Notice thisQoS can protect deadlines, but it cannot make an overloaded link carry every packet.

Traffic Classes

Each row shows the current queue, packets sent during this step, and the result for that class so far.

Policy Comparison

The same traffic and link are replayed to compare what each policy would do by the end of the 12 second window.

Learning Support

Classification

QoS starts by classifying packets: alarm, command, telemetry, logs, or bulk. Classification may use application ports, VLAN tags, DSCP markings, or gateway rules.

Scheduling

The scheduler chooses which queue transmits next. Strict priority minimizes alarm delay; weighted fair queuing reserves some service for every class.

Congestion

When incoming traffic exceeds the bottleneck link, queues grow. Eventually packets wait too long or are dropped, even if QoS is configured correctly.

Quick Reference

Network QoS

Queueing and traffic treatment inside the network. It controls latency, drop priority, and share of a bottleneck link.

MQTT QoS

Application message-delivery levels: at most once, at least once, exactly once. It is separate from network packet scheduling.

Strict Priority

Always serves high-priority queues first. Strong for alarms, risky for best-effort traffic if critical traffic is sustained.

Weighted Fair

Allocates a configured share of service to each class. It improves fairness while still giving larger shares to important traffic.

Shaping

Smooths bursts before they hit the bottleneck. It usually reduces burst loss but adds deliberate delay.

Policing

Enforces hard caps and drops excess traffic. It protects the link, but the cost is visible packet loss.

Guided Practice

1. Find starvation

Use Congested gateway with Strict priority. Watch firmware bulk and logs. Then switch to Weighted fair and compare whether low classes recover.

2. Protect alarms

Use Alarm burst and increase link capacity until safety alarm packets are on time. Notice that extra capacity and QoS policy both matter.

3. Test a deployment rule

Build a rule such as "alarms under 250 ms, telemetry under 2 s, firmware can wait." Pick the policy that meets it without hiding drops.

Network mechanisms Network conditions emulator MQTT QoS simulator Traffic testing