3 Measuring Topologies with Graph Metrics

3.3 Overview: Topology Analysis Turns Diagrams Into Evidence

A topology diagram is a useful sketch, but analysis asks what the sketch proves. Model devices and links as a graph, measure the paths that traffic depends on, and test which nodes, links, gateways, channels, power sources, or ownership boundaries can break the service.

The goal is not to crown one topology name as good or bad. Star, tree, ring, mesh, bus, and hybrid patterns all work in the right conditions. A design is defensible when its metrics, failure behavior, and field evidence match the deployment constraints.

Consider a warehouse design where forty shelf sensors appear to form a healthy wireless layout because every sensor can reach a gateway during installation. The graph record may tell a different story: most routes still cross one relay aisle, the gateway has the highest degree, and the cold-room sensors have longer retry paths than the rest of the floor. A useful analysis records those dependencies before release. It asks which nodes become unreachable if the relay aisle loses power, whether alarms still arrive during a burst, and whether operations can see the difference between weak radio links, gateway queues, and application ingestion delays.

The warehouse sketch becomes defensible only when its nodes and links pass through a repeatable analysis. Figure 3.1 previews that route so each later metric and probe has a clear place in the final decision record.

The numbered path in Figure 3.1 begins with Inventory, recording nodes and links, then moves through Metrics such as degree, diameter, paths, and reach. Failure Zones exposes hubs, bridge links, gateways, and power dependencies before Scale Pressure and Routing Work add state, support, discovery, and repair costs. Evidence captures counters and traces, and Decision Record binds the assumptions, limits, evidence, and recheck triggers. That sequence turns the opening warehouse example from a tidy drawing into an inspectable claim about what remains reachable under stress.

Overview Knowledge Check

3.4 Practitioner: Build the Topology Analysis Record

A practical analysis record should fit on one review page. It names the graph boundary, the metrics that matter, the failure probe, the operations evidence, and the trigger that reopens the decision when the site changes.

Counting links alone cannot reveal whether the remaining paths are useful. The graph diagram Figure 3.2 gives the vocabulary needed to complete the one-page analysis record.

In Figure 3.2, router R1 degree = 3 illustrates Node degree, while the strong highlighted route between sensors and the GW illustrates one Shortest path. The callout for Diameter identifies the longest shortest path, not simply the longest drawn edge. On the right, a dashed Bridge link or relay shows how one failure can split the graph, and Weighted links attach retry rate, latency, quality, or capacity to edges that would otherwise look equal. Those labels supply the record fields used below: connectivity explains possibility, while weights and failure probes explain operational fitness.

Use formulas as first-pass checks, not as deployment truth. A full mesh with `n` nodes needs `n(n - 1) / 2` links, while a partial mesh with average degree `k` has about `n * k / 2` links. Those numbers reveal maintenance pressure, but the decision still needs weighted links and failure probes.

Practitioner Knowledge Check

3.5 Under the Hood: Failure Domains Decide Whether Metrics Matter

A topology can be connected and still be fragile. A graph has an articulation node if removing one node separates reachable groups. It has a bridge link if removing one link partitions traffic. It has a shared dependency when apparently redundant paths rely on the same gateway, switch, channel, power circuit, certificate, cloud service, or operating team.

Routing overhead also grows through the graph. Neighbor discovery, route maintenance, acknowledgements, retries, state storage, convergence, and sleep behavior can make a theoretically resilient topology expensive or unstable in the field.

This is why failure-domain evidence should be paired with weighted-link evidence. Removing a bridge link from an unweighted graph shows partition risk, but it does not show whether the alternate path is usable under battery, latency, duty-cycle, or interference constraints. A sleepy relay may be a valid backup for slow telemetry and a poor backup for command traffic. A redundant uplink may still share one power circuit or one operations team. The under-the-hood record should therefore name the assumed failure, the affected flows, the measured or observed weights, the degraded mode, and the exact condition that would require a retest.

Graph metrics matter only when they predict the service effect of a plausible loss. The comparison diagram Figure 3.3 contrasts familiar shapes by failure boundary rather than by topology reputation.

The stacked cases in Figure 3.3 label Star: hub dependency and Tree: branch risk, where one shared role can isolate many leaves. Ring: break creates line shows that continuity changes after a break, while Mesh: prove reroute refuses to count a candidate alternate as a working path without observation. The final Gateway boundary: local is not enough points toward cloud service and asks for queues, uplink state, timing, and duplicates. This comparison sharpens graceful degradation: the record must say which flow persists, which slows or buffers, and which still fails beyond a surviving local graph.

After the failure comparison, the evidence must be consolidated without erasing its scope. Figure 3.4 shows the six inputs that make the topology decision reusable and bounded.

Around the centre of Figure 3.4, Assumptions fixes scope, environment, roles, and traffic; Graph Metrics records degree, paths, diameter, connectivity, and weak links. Failure Tests names the removed hub, router, link, gateway, channel, or power source, while Operations Evidence supplies neighbour tables, traces, logs, counters, and timestamps. Limits and Recheck Triggers prevent those observations from becoming a universal verdict. The central Topology Decision Record is therefore the running narrative’s endpoint: an accepted or constrained choice that can be reopened when placement, load, ownership, or firmware changes.

Under-the-Hood Knowledge Check