9 Converged Networks and QoS
A building carries video, office traffic and door alarms over one network. A camera starts uploading stored footage just as a door controller reports a forced opening. The converged design must preserve the alarm’s service even though both flows share an output link.
9.1 Start With Traffic That Competes
Protect the Important Message on the Busy Link
Picture a school link carrying calls, cameras, guest downloads, door events, and a large device update. All work well at noon. During an incident, the camera load rises and the door event waits behind less urgent work.
Name each traffic class by its harm when late or lost. Set a delay, loss, and recovery limit. Measure the real narrow link under normal, peak, and failed-path load. A label alone does not reserve space.
Firmware is the built-in software that controls a device. Schedule a large firmware job in the trial, then break one path. Check that urgent messages still arrive and that lower-priority work slows in a visible, fair way.
One load test cannot cover every burst or shared queue. Practitioner builds the traffic ledger. Under the Hood follows buffers, marks, scheduling, and control across the common fabric.
A converged network carries different kinds of traffic over shared infrastructure. A sensor alarm, maintenance laptop, camera feed, voice call, and cloud sync may all want the same capacity at the same time.
QoS is the decision about what gets protected when the network is busy. The useful design story names the traffic classes, proves the bottlenecks, and shows how priority rules behave under load.
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.
Use Figure 9.1 to prepare the decision in overview: one fabric, many traffic classes. The diagram names Legacy Separate Network Infrastructures and Phone, the two anchors needed to assess separate networks provide natural isolation, but they duplicate cabling, tools, skills, and maintenance contracts.
Locate Legacy Separate Network Infrastructures on Figure 9.1 before checking Phone. The visual’s third anchor, PBX or voice network, completes separate networks provide natural isolation, but they duplicate cabling, tools, skills, and maintenance contracts. Carry Legacy Separate Network Infrastructures into overview: one fabric, many traffic classes; use PBX or voice network as its limiting condition.
Figure 9.2 makes overview: one fabric, many traffic classes inspectable through Modern Converged IP Network and secured IP. Those diagram labels establish the scope of convergence works when the shared fabric still preserves service boundaries for voice, video, control, telemetry, and best-effort data.
Figure 9.2 places Modern Converged IP Network alongside secured IP. Treat Sensors as the diagram qualifier for convergence works when the shared fabric still preserves service boundaries for voice, video, control, telemetry, and best-effort data. That labelled limit reconnects the visual to overview: one fabric, many traffic classes.
Physical Consolidation
Ethernet, Wi-Fi, PoE, IP addressing, and common switching move many building services onto one managed network.
Logical Separation
VLANs, ACLs, SSIDs, network access control, and routing policy keep service classes from becoming one flat failure domain.
Priority Under Load
QoS markings and queue policy protect alarms, control loops, voice, and video when shared links become congested.
Design doctrine: converge the cabling and management plane, not the risk. A strong IoT design can explain which traffic shares infrastructure, which traffic is isolated, which packets receive priority, and what evidence proves the policy holds under load.
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.
Figure 9.3 makes practitioner: build a traffic-class ledger inspectable through Quality of Service Mechanisms and Priority-Based Traffic Management. Those diagram labels establish the scope of qos is a queueing decision: when links are busy, classified traffic should receive the treatment promised by the design.
Begin Figure 9.3 with Quality of Service Mechanisms, then distinguish Priority-Based Traffic Management and Classifier. The diagram separates Quality of Service Mechanisms from Priority-Based Traffic Management within qos is a queueing decision: when links are busy, classified traffic should receive the treatment promised by the design. Keep both distinctions explicit in practitioner: build a traffic-class ledger.
Mark At The Edge
Classify traffic near the device or access switch, then decide whether to trust, rewrite, or discard DSCP values from endpoints.
Police Priority
A priority queue without rate limits can be abused or misconfigured until it starves every other class.
Test Congestion
QoS is unproven until alarms, control packets, voice, video, telemetry, and guest traffic are tested together at busy-hour load.
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.
Use Figure 9.4 to prepare the decision in under the hood: shared media and shared queues. The diagram names CSMA/CA local decision and evidence loop and Local decision loop, the two anchors needed to assess on shared wireless channels, devices listen before transmitting and use random backoff to reduce repeated collisions.
Locate CSMA/CA local decision and evidence loop on Figure 9.4 before checking Local decision loop. The visual’s third anchor, MAC profile sets exact counters and timings, completes on shared wireless channels, devices listen before transmitting and use random backoff to reduce repeated collisions. Carry CSMA/CA local decision and evidence loop into under the hood: shared media and shared queues; use MAC profile sets exact counters and timings as its limiting condition.
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.
The visual evidence for under the hood: shared media and shared queues sits in Figure 9.5. Find Alternative view beside IoT Platform before interpreting segmentation and queue policy let multiple services share infrastructure without pretending they have identical risk or timing needs.
Trace the visual from Alternative view to IoT Platform in Figure 9.5; verify QoS enforcement before concluding. Together those labels make segmentation and queue policy let multiple services share infrastructure without pretending they have identical risk or timing needs testable. Apply their boundary when working through under the hood: shared media and shared queues.
9.5 Classify Network Functions Before Device Names
A converged design can contain routers, Layer-3 switches, load balancers, firewalls, NAT, wireless controllers, voice gateways, intrusion-detection systems, proxies, access-control services, and many other named appliances. The source’s useful simplification is to review the function separately from the box. Shared hardware and network-function virtualization can place several functions on one platform, while one product name can hide several different decisions.
Use four function classes in the traffic ledger:
- Forwarding: decide the next hop from headers or traffic content, then send the flow through the selected interface.
- Processing: intercept or manipulate a flow by actions such as caching, encryption, marking, or changing headers or data.
- Translation: convert headers or data into another format, often with a table that preserves the mapping.
- Isolation: select fields or content, evaluate a configured policy list, then forward, prioritize, or filter the traffic.
One device can occupy more than one row. Record the order in which those functions run, because a flow that is translated before a policy check presents different evidence from one filtered before translation.
9.6 Under the Hood: Four Runtime Questions
For each hop, ask: where will this flow go, what will change, which mapping will be retained, and which policy may stop it? A forwarding function needs a lookup result and outbound interface. Processing needs an operation and proof of the resulting content. Translation needs the before-and-after form plus any retained state. Isolation needs the fields examined, matching rule, and final forward-or-filter decision. This function-first trace is more durable than an inventory of appliance names because it still works when the functions move onto shared or virtualized hardware.
9.7 Modern Alternative: Centralized Control With SDN
The hop-by-hop review above exists because of how switches have traditionally been built: each one runs its own vendor-specific operating system, keeps its own routing table, and enforces its own queue policy, configured independently of every other switch in the fabric. Nothing about that architecture guarantees that a DSCP marking written into a design document is honored the same way at the access switch, the core switch, and the WAN edge. A converged network built this way is only as consistent as its slowest configuration review.
Software-Defined Networking (SDN) restructures that model. Instead of each switch deciding its own forwarding and queue behavior, SDN separates the control plane, the decision of what a flow should receive, from the data plane, the switches that simply carry it out. A centralized controller holds a network-wide view and pushes rules down to every switch's flow table: match this traffic by protocol, VLAN, address, or port, and take this action, including which queue or priority it receives. The switches stay comparatively simple; the controller becomes the single place a converged network's QoS policy is actually defined.
OpenFlow is the protocol most SDN deployments use to install those flow-table rules, and it is the reason SDN can enforce policy consistently: because one controller writes every switch's rules, "alarms get the protected queue" is defined once and enforced everywhere, instead of being trusted, rewritten, or quietly dropped as a packet crosses each hop's separately administered configuration. SDN does not replace the queueing and airtime mechanics covered above; a flow-table rule still ultimately points traffic at a priority queue or a rate limiter, and CSMA/CA still governs contention on a shared wireless channel. What changes is who decides that mapping, and how consistently it is applied.
This centralize-the-decision pattern is not unique to enterprise switch fabrics; the same logic has been extended into wireless sensor networks and mobile radio-access networks that need equally consistent, network-wide traffic handling. Those are substantial topics in their own right, and outside the scope of this QoS walkthrough. The takeaway for a converged IoT network is narrower: centralized control is one way to make sure the priority policy this chapter describes is the policy that is actually running at every switch.
9.8 Practice: Network QoS Simulator
9.9 Keep a Camera Burst out of the Alarm Queue
Assume a 10 Mbps link and a queued 1 MB upload, using decimal units. The upload contains 8,000,000 bits, so draining it takes 0.8 s before other traffic and overhead. A small alarm placed behind the whole backlog can therefore wait far longer than its own transmission time. A 100-byte alarm is only 800 bits, taking 80 microseconds at that link rate before overhead.
Priority queueing can move the alarm ahead of waiting low-priority packets, but it does not automatically interrupt a frame already being transmitted. Under an illustrative 1,500-byte frame size, that serialization delay is 12,000 bits divided by 10,000,000 bits per second = 1.2 ms. The complete delay still includes classification, switching and later hops.
The chapter’s four function classes make the treatment inspectable. Forwarding selects the output; processing may mark traffic; translation may change headers; isolation applies the policy that admits or rejects priority use. Record the order, because a rule matching the original source address can behave differently after address translation.
Predict what happens if every camera marks its traffic as urgent. An unpoliced priority queue can become another congested queue, so the classifier needs a trusted basis and enforced limits. Next, disconnect the shared uplink. Segmentation may isolate traffic policy, but it does not create another physical path around that dependency.
Test the alarm during the camera burst and at the receiving service, not only at the first switch. Inspect queue delay, discarded packets and the matched policy rule. A policy name such as high priority is not evidence that every hop gave the flow the same treatment.
The module’s convergence argument is about sharing managed infrastructure while retaining distinct service needs. Video can often wait for bulk transfer; a door alarm has a tighter timing contract. Their common cable becomes useful only when classification, queueing and failure behaviour make that distinction observable under load.
9.10 Summary
Converged networks reduce duplicated infrastructure by carrying voice, video, data, building automation, and IoT services on one managed IP fabric. They are safe for IoT only when the shared fabric preserves service boundaries: segment traffic classes, classify packets at the edge, police priority use, and test alarms or control traffic while lower-priority traffic is busy.
9.11 Key Takeaway
Converge the infrastructure, not the failure domain: every shared IoT network needs explicit segmentation, QoS treatment, and congestion evidence for each traffic class.
9.12 See Also
Packet Switching and Network Performance
Connect converged-network behavior to multiplexing, queuing, throughput, and delay.
Collision Design and Shared Channels
Plan collision domains and retry behavior for dense IoT networks sharing radio airtime.
Wireless Access: Wi-Fi
Map Wi-Fi airtime, access categories, coverage, and capacity into a converged network.
Network Physical Classification
Compare the physical media choices that can carry a shared IoT service fabric.