Skip to content

[benchmark][ns3] ISL-grid scenario — routable satellite topology with no orbital mobility #214

Description

@danieljoppi

Child of #196. The cheapest useful step in the whole satellite track (#192) — it needs no substrate decision and no orbital mechanics.

Context

The standard abstraction of a LEO ISL mesh is a +Grid torus: each satellite holds two intra-plane links (fore/aft, near-constant length) and two cross-plane links (port/starboard, length varying with latitude). Frozen at one instant, that is just a static torus of point-to-point links — buildable in stock ns-3 today.

That is enough to answer most of the questions this track is actually blocked on:

None of that needs a satellite to move. Doing this first means the substrate spikes (#193) are evaluating options against a scenario we already understand, instead of the other way round.

Scope

An ns-3 example building an M × N +Grid torus of p2p links with configurable per-link delay, running the existing traffic/metric plumbing (anthocnet-compare-style FlowMonitor metrics, --diag, CSV output). Configurable: grid dimensions, ISL delay (uniform to start; per-link later), flow count and placement, and which protocols to run.

Keep it a scenario, not a module — no new devices, no mobility. If it grows either, it belongs in #195.

Acceptance

A 10×10 torus (100 nodes, 4 ISLs each) delivers end-to-end under AntHocNet and under at least one baseline; the run emits a standard CSV row; scaling the grid is a command-line flag. Run through the benchmark-results skill so the numbers get a noise verdict rather than an eyeball.

Related

#196 (parent), #203 (this is its natural test bed), #207 (consumes this for the scale numbers), #200 (its two-node delay-mutation script extends into per-link ISL delay here), #192.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions