This is an understanding of the paper NsDocker

Motivation¶

Lack of system-level impact capture from ns-3 in simulation of Low Earth Orbit satellite topologies, as a result of the abstraction imposed by the discrete event-driven simulation of ns-3.
High resource demands of a full emulated Docker-container-based test-bed, which scale badly with growth in network complexity.

Methodology¶

Hybrid model combining containers with ns-3 networks, using the Tap-Bridge to bridge the connection between the emulated "ghost" node with the external Docker node.
Using the Ansys STK for modelling and building the LEO constellation network, and emulating topology variations by bringing links up and down periodically.
Synchronises the Docker time-scale with the ns-3 clock by using the RealtimeSimulatorImpl. (which is as far as I can see, the best method to do this)
External Docker nodes are connected via a veth-pair to a bridge device bound to a TAP device. (Similarly to the layout presented in the blogpost by SEI)
The packets forwarded to the TAP device through /dev/tap are passed via IPC to the TapBridge module. This is then passed to the simulator.
Packets recieved by the "ghost" node are passed through a callback function to the TapBridge module in the opposite direction.
As such, all packets sent to and received by the "ghost" node are handled by the Docker daemon's network stack.
Ansys STK is used to construct the LEO satellite model and integrates the model into ns-3.
A ns-3 CSMA channel is used to emulate the link statuses of the inter-satellite links.
NSDocker periodically changes the state of links by configuring NetDevice.active, simulating periodic connection losses in satellites.