Network Simulator 3 (NS3) is a simulation tool for researchers investigating MAC and Network layer performance; it’s being used more and more within the networking research community.
NS3 has been chosen in CarMesh for conducting a capacity analysis of 802.11n based multi-radio multi-channel Wireless Mesh Networks (WMNs) using vehicular specific traffic patterns, i.e.:
- Broadcast road traffic announcements
- Video streaming of PoI content
- HTTP-like content, e.g., maps, navigation, PoI content
NS3 was chosen primarily due to its advanced 802.11n wireless models – its models are more advanced than any other open-source networking simulation tool.
NS3 is a complex tool and even getting basic topologies and network simulations working is non-trivial. While the tutorials are, of course, helpful, it’s very easy to get overwhelmed by the available content and very quickly you are editing the C++ internals of NS3 to get the basic scenario operational.
In our case, we wanted to configure an IPv6 based scenario in which nodes had multiple radios and multiple connections to other nodes. This configuration was not really covered in the tutorial content and we had to solve some configuration problems which were more complex than anticipated right at the outset. More specifically, we had to understand the node/netdevice/interface relationship to implement the scenario. Here, we include more detail on this as it can be a bit confusing when starting with NS3.
When studying the examples included in the NS3 tar ball (ns-allinone-3.16/ns-3.16/examples), the set-up of a network can be done in various ways which is sub-optimal from a introductory point of view. NS3 provides two different ways to create a network. The user either leverages smart pointers which hold one object – a node, a netdevice or an interface – or containers (vector of smart pointers) which hold a collection of nodes, netdevices or interfaces. Having said that, some of the examples use containers with only one (node, netdevice or interface) element which is somehow strange, as the NS3 documentation does not state when that approach should be used.
Figure 1 depicts a conceptual overview of the NS3 elements node, netdevice and interface and how the CarMesh project is using them. In our approach, there is only one NodeContainer, NetDeviceContainer and Ipv6InterfaceContainer in the simulation: each of these containers contains all of the respective nodes, netdevices and IPv6 interfaces. This approach was the most logical from the point of view of the NS3 modular design which allows the users to replace one part of the simulator, e.g., networking stack or MAC behaviour, with another one without affecting other parts in NS3. However, it is somewhat counter-intuitive as in most simulators, the node structures maintain information pertaining to their interfaces directly. In NS3 the mapping nodes, netdevices and interfaces is as follows (see Fig. 1):
- node -> netdevice (when creating a netdevice the node id must be provided)
- netdevice -> interface (when assigning IP addresses, the netdevices are provided – each netdevice is then bound to an interface)
In the next post, we will delve into this in more detail, discussing how it is possible to map from nodes to netdevices and interfaces and to parameterize and otherwise configure these aspects of the simulation after setting up the simulation environment.