9 Converged Networks and QoS

9.2 Overview: One Fabric, Many Traffic Classes

A converged network carries voice, video, data, building automation, and IoT traffic on one IP infrastructure. The win is operational: one cabling plant, one switch fabric, one addressing model, and one monitoring surface instead of separate systems for phones, cameras, sensors, and workstations.

The risk is also operational. When every device shares the same fabric, a camera stream, guest download, firmware job, or broadcast storm can delay the alarm packet unless the design includes segmentation, priority, and measured capacity.

Convergence should therefore be described as a contract, not just a topology. The contract states which services share cables and switches, which services remain logically separated, which traffic may cross boundaries, and which packets receive preferential treatment when links are busy. A building may be easier to run when phones, cameras, sensors, access control, and user devices all use IP, but the network still has to respect their different risk profiles. A late guest download is annoyance; a late door-controller message or alarm packet can be a safety and operations failure.

The practical design question is not whether one fabric can carry all traffic. It is whether the shared fabric can preserve each service objective under load. That means the designer needs evidence: VLAN or SSID boundaries, route and firewall rules, queue mappings, priority policing, busy-hour utilization, and test results that show critical traffic still meets latency and loss targets when ordinary traffic is noisy.

Without that evidence, convergence can hide risk behind tidy diagrams. With it, the same fabric becomes reviewable, testable, and maintainable.

Count the separate stacks in the diagram at Figure 9.1 before judging whether convergence is worth its risk.

+

Four services run down the diagram, and each one owns its own plant. Phone traffic runs on a PBX or voice network. Video runs on CCTV coax to a recorder. Data runs on office Ethernet. Building systems run on a fieldbus of their own. The isolation is genuine, and that is the honest attraction of the old design. The two boxes at the foot of Figure 9.1 state the price: parallel cabling and parallel management, and integration that gets harder each time a service is added. Convergence trades that cost against the isolation it removes.

Trace one sensor reading across Figure 9.2 to see what the shared fabric must now carry on its own.

+

Three different sources enter from the left: IoT sensors, voice and video endpoints, and building controllers. They all join the same middle block of switches and routers, and that block is marked as a secured IP path to the cloud applications on the right. Read the middle as the whole argument. Every service boundary that used to be a separate cable now has to be created inside that one fabric, by addressing, segmentation and queue policy. Figure 9.2 is a promise, not a result. It holds only while those boundaries stay visible and testable.

9.3 Practitioner: Build A Traffic-Class Ledger

A converged design should start with a ledger, not a switch order. The ledger names each service class, its isolation boundary, its expected behavior during congestion, and the test that proves the policy is working.

For each class, record the requirement before choosing the mechanism. Alarms need bounded delivery under competing load. Voice needs low jitter. Cameras need sustained throughput without starving control traffic. Telemetry may tolerate delay, but broker backlog can still hide failures. Guest and maintenance traffic should usually be isolated and shaped. Once those requirements are visible, VLANs, ACLs, DSCP markings, queue policy, policing, and monitoring can be selected to serve an explicit outcome rather than a vendor-default template.

The ledger should also name ownership. Facilities, IT, security, and operations often share a converged network but measure success differently. A useful record states who can approve new devices, who owns QoS marking rules, who reviews firewall exceptions, and which test must be rerun when a gateway, camera, controller, access point, or uplink changes.

Use Figure 9.3 to see where a traffic-class promise becomes a queueing decision.

+

Begin with the classifier, which maps packets into traffic classes using explicit fields and policy. Separate queues then hold those classes when the link is busy. Scheduling and shaping decide which queue sends, how much capacity it may consume, and whether lower classes can still make progress. Marking alone changes no outcome if downstream devices ignore it. The evidence path should therefore create controlled congestion and measure delay, loss, and throughput per class at the receiver. A QoS record also needs admission limits, because priority cannot create capacity when every packet is declared urgent.

9.4 Under The Hood: Shared Media And Shared Queues

Two mechanisms decide whether convergence works under pressure. At the access layer, wireless stations contend for airtime with CSMA/CA or a related scheduling method. At the forwarding layer, switches and routers choose which queued packet leaves next.

The important detail is that segmentation and QoS solve different problems. Segmentation controls who can talk to whom and limits broadcast or security blast radius. QoS controls which packet receives service first when a shared resource is congested. A VLAN can isolate cameras from controllers, but it does not make an oversubscribed uplink faster. A priority queue can protect alarms under load, but it does not stop an untrusted device from reaching the wrong subnet unless access policy also exists.

Follow one frame through Figure 9.4, then read the two failure paths drawn beside it.

+

The loop starts with a frame that is ready. It waits for a random backoff, then checks whether the channel is busy. Idle means transmit. Busy sends it back around with a longer backoff, up to a limit, after which the device defers or sleeps. If an acknowledgement is expected and does not arrive, bounded retries run until a final failure. The two side panels in Figure 9.4 are where the design cost appears. A saturated channel turns backoff into delay and wasted energy. A hidden node makes the local check report idle while frames collide at the receiver. Both are why shared media need airtime planning, not just a priority label.

CSMA/CA improves fairness, but it does not guarantee that every urgent packet can transmit immediately. Dense Wi-Fi, battery devices waking together, hidden nodes, and retries can still create jitter. That is why converged wireless designs need airtime planning, channel reuse, retry limits, and priority mapping from access categories into the wired QoS policy.

End-to-end behavior depends on each hop honoring the same intent. A packet marked as urgent at a sensor may be rewritten at the access point, remapped at the switch, ignored by a router, or policed at a WAN edge. The review should trace a critical packet from device to application and confirm where markings are trusted, where they are rewritten, and where queue limits prevent a misconfigured priority flow from starving the rest of the fabric.

Where is the decision made about which traffic waits? Figure 9.5 sketches that question as a platform with policy hanging off it.

+

Treat Figure 9.5 as a schematic. One IoT platform sits at the centre, and dashed lines tie it to two named ideas: enforcing quality of service while the network is congested, and letting a controller reset priorities. The layout is making a claim about where the decision lives. Every service rides the same links, so the choice about which traffic waits is a policy held on that shared platform, not a property of the cable. What the figure cannot give you is a number. How long a class actually waits comes from the queue limits, retry settings, and airtime plan described above, and it still has to be confirmed by a trace.