8 Lab: Trace and Compare Topologies
Scenario Briefs, Model Cards, Flow Traces, Failure Probes, Evidence Notes, and Design Handoffs
network topology lab, topology comparison, topology evidence, topology flow trace, topology failure probe, IoT network design
8.1 Start With the Story
In this lab, you are not drawing topologies to make neat pictures. You are testing what each shape does to message paths, shared dependencies, failure behavior, and handoff evidence. By the end, the useful artifact is a short design note that says what you observed, what failed, what stayed uncertain, and which topology choice the evidence supports.
8.2 Overview: Compare Topologies with Bounded Evidence
This lab teaches a repeatable way to compare topology sketches without pretending that a paper model proves field behavior. You will start with one scenario brief, build comparable model cards, trace one message, probe one shared dependency, and write a short design handoff.
The goal is not to prove that star, tree, mesh, or hybrid is always best. The goal is to practice fair comparison: hold the device set and message purpose steady, change the topology family, record what the model shows, and state what still needs field or simulation evidence.
For example, use the same eight freezer sensors, one gateway, one maintenance laptop, and one dashboard service in every card. In the star card, a temperature alarm may go sensor to gateway to dashboard. In the tree card, the same alarm may pass through a parent role first. In the mesh card, the model may assume a relay path that has not been measured. The lab answer should record those path differences without changing the alarm purpose or silently adding extra devices to make one pattern look better. That control is the evidence boundary.
Scenario Question
Write the device roles, message purpose, site notes, and assumptions that every topology card must share.
Comparable Cards
Draw star, tree, mesh, and hybrid versions using the same device set so the comparison stays explainable.
Message Path
Follow one source-to-destination message through each card before judging the design.
Shared Role Test
Remove one shared node, link, relay, gateway, or service role and record what changes.
A good lab answer separates observation from conclusion. "The star card depends on one gateway role" is evidence. "All star topologies are wrong" is an unsupported overclaim.
8.3 Practitioner: Build the Evidence Packet
Use one field monitoring scenario: eight sensing devices, one local gateway, one maintenance laptop, and one application service. Sensing devices report status messages. The gateway forwards messages toward the application service. The maintenance laptop is used during service visits. The team wants a sketch that shows normal flow and what happens if a shared role is unavailable.
Build the packet in the order a reviewer can replay. First write the controlled scenario and list any assumptions, such as powered relays or a gateway with spare capacity. Then draw the comparable cards with the same nodes. Next trace one status message on each card and mark every forwarding, storage, translation, or service role. Finally remove one shared role at a time. If the gateway is removed, do not redraw the network to rescue the result; record the effect and the evidence still missing.
Run it: Build the comparable cards in the topology simulator below instead of only sketching them. Pick one deployment scenario -- Building, Farm, Warehouse, or Street -- then switch the layout between Star, Mesh, Tree, Ring, and Hybrid on that same fixed device set and watch how paths, hops, and shared roles change. Keep the scenario constant as you compare, exactly as the fair-comparison rule requires, and read each card's structure from the model rather than from intuition.
Shared Gateway
All sensing devices send through one gateway role. Mark that role as a shared dependency.
Parent Roles
Sensing devices sit under parent roles. Mark the root and each parent role before tracing messages.
Neighbor Paths
Sensing devices can forward through neighbors. Mark which nodes act as relays and which paths are only assumptions.
Mixed Pattern
Combine patterns only after naming where each pattern begins, ends, and hands traffic to another role.
For each trace, write the source node, destination role, forwarding roles, storage or translation points, shared dependency, and one assumption. Then run one failure probe by removing a shared dependency from the card without redesigning it first.
Run it: Turn the failure probe into something you can watch. In the WSN comparison animation below, select Star, Mesh, and Cluster-tree on one field scenario, then inject a failure -- Sink unavailable, One relay/sensor down, or One cluster head down -- and watch which sources lose their path and which shared role was carrying them. Record the observed effect of removing one role at a time, without redrawing the network to rescue the result.
- Write the scenario brief. State the device roles, message purpose, site notes, and open assumptions.
- Create comparable cards. Keep the same device set while changing only the topology family.
- Trace one message. Follow one source-to-destination path through every card.
- Probe one shared role. Remove one gateway, parent, relay, link, or service role and record what changes.
- Record uncertainty. State what the sketch does not prove before making a handoff recommendation.
8.4 Under the Hood: Turn Observations into Handoffs
The comparison board is where the lab becomes reviewable. It should summarize what was observed, which dependency appeared repeatedly, what the probe changed, what remains uncertain, and which design review should use the result.
A useful handoff is narrow enough that another engineer can act on it. "The mesh card used relay R2 for this alarm path, but the lab did not measure R2 power reserve or radio link margin" points to a relay-placement or field-test review. "The star card failed when the gateway role was removed" points to gateway redundancy, local buffering, or accepted-risk review. The handoff should not say that a topology family wins; it should say which observed dependency needs the next evidence step.
What Happened
Name the roles the traced message passed through. Avoid judging the whole topology from one trace.
What Was Shared
Identify roles that many traces or probes used: gateways, roots, relays, brokers, services, or links.
What Is Not Proven
State missing field evidence such as radio coverage, gateway load, battery effect, queueing, or recovery time.
Who Reviews Next
Send the finding to topology selection, failure behavior, maintenance ownership, or gateway redundancy review.
A strong evidence note might say: "In the star card, all status messages passed through the gateway role. Removing that role isolated the sensing devices from the application service in the card. This observation shows a shared gateway dependency in the model, but it does not prove real field behavior. The handoff is to review gateway redundancy, local queueing, and maintenance access."
The lab is complete only when the final note separates question, setup, trace, probe, observation, limit, and handoff. That separation is what makes the result useful to a later design review.
8.5 Summary
Topology comparison is useful when the lab controls the baseline and records evidence carefully. Start from one scenario, use the same device set, draw comparable topology cards, trace one message, probe one shared dependency, and write a bounded note.
The result is not a universal ranking of topology families. It is a review packet: observed path, shared dependency, probe result, uncertainty, and design handoff.
8.6 Key Takeaway
Treat topology labs as evidence exercises, not as design verdicts. A strong handoff says what the model showed, what it did not prove, and which follow-up review should use the finding.
8.7 See Also
Use this if a model card needs a clearer star, tree, mesh, or hybrid definition.
Deepen the failure probe into dependency, isolation, and recovery analysis.
Turn the evidence packet into a topology decision record.
Connect the lab handoff to operational monitoring and change control.