MODELING AND SIMULATION OF COMPUTER NETWORKS AND SYSTEMS

MODELING AND SIMULATION OF COMPUTER NETWORKS AND SYSTEMS: METHODOLOGIES AND APPLICATIONS Current and Future Trends in Open Source Network Simulator for Wireless Systems Lorenzo Carlà, Francesco Chiti, Romano Fantacci, Tommaso Pecorella

2 Current and Future Trends in Open Source Network Simulator for Wireless Systems Summary 1. Network Simulation Issues 2. Simulation Frameworks Overview 3. OS oriented tools 4. OMNe. T++ / ns-3 Tiny. OS / Contiki / Ri. OT ns-3 Framework Channel Models Mobility Models IEEE 802. 11 Models IEEE 802. 15. 4 Models LTE/LTE-A Models TCP/IP, routing and transport protocols

3 1. Network Simulation Issues Smart Environments (Pervasive Ecosystems) design based on the Internet of Things paradigm Wireless Sensor Networks (WSNs) interoperability is leading to open-standards (IETF and IEEE) but the protocol suite optimization is still an open issue especially for resource constrained systems therefore, it is essential to investigate the overall system’s behavior before industrial development and practical deployment Open Source network simulators can represent a valid alternative to real device development via Operating Systems and testbed deployment for academic and industrial research goals. A simulation framework is normally meant to be an effective support in the protocol/algorithm design, evaluation and optimization phases

4 1. Network Simulation Issues Any simulation tool should be based on a real world scenario model Analytical: necessary to build an approximate model of the aspects that can not be functionally simulated, usually for reasearch purposes Functional: useful to characterize the protocols and their interactions, but sometimes leading to an overdetailed model The network simulator framework should allow to implement an abstract model, possibly alleviating the problems arising in a real implementation Possible approaches for model validation: Qualitative: whether the system behaves as expected Quantitative: performance at component or system level through a set of suitable metrics Cross-validation: model behavior against a reference implementation The granularity and flexibility of the adopted simulation tool affect the accuracy degree of validation

5 1. Network Simulation Issues WSNs represent an appropriate case study since their hardware have extremely limited resources their operating systems are very small and optimized collecting data from the implementation might be very difficult and deploying large scale testbeds can be challenging WSNs simulation framework should have the following capabilities: to implement standard protocols (such as IETF and IEEE ones) in order to optimize the WSN for a specific scenario to allow a system’s parameters modification to be able of going beyond the standards, in order to propose amendments or new standards; to test and evaluate application-level protocols

6 2. Simulation Frameworks Overview In simulating (or emulating) a wireless network, several alternatives need to be considered : generic network simulation framework, extended with necessary modules Pros: extremely flexible, well documented, availability of already existing models Cons: often require particular attention to develop and validate the WSN models specific simulator can be used Pros: good alternative Cons: scarcely used and lack from user-based verification, steep learning curve device simulator might be included in most Operating Systems of the device under investigation Pros: it reproduces almost exactly the behavior of a real node Cons: it usually lacks details and forces the user to cope with OSspecific constraints, as programming language and model

7 2. Simulation Frameworks Overview: OMNe. T++ C++ based, open-source, component based, modular, open architecture and discrete event network simulator with strong GUI support and an embeddable simulation kernel An OMNe. T++ model is composed by hierarchically nested modules communicating through message passing. Modules can send messages or directly to their destination or along a predefined path using gates and connections. OMNe. T++ has a Mobility Framework (MF) supporting node mobility, dynamic connection management and wireless channel models

8 2. Simulation Frameworks Overview: OMNe. T++ Several models can be used for WSNs simulations, such as: INET: this framework can be considered the standard protocol model library of OMNe. T++. INET contains models for the Internet stack (TCP, UDP, IPv 4, IPv 6, OSPF, BGP, etc. ), wired and wireless link layer protocols (Ethernet, PPP, IEEE 802. 11, etc), support for mobility, MANET protocols, Diff. Serv, MPLS with LDP and RSVP-TE signalling. Mi. Xi. M: conceived for mobile and fixed wireless networks (wireless sensor networks, body area networks, ad-hoc networks, vehicular networks, etc. ), it focuses is on the lower layers of the protocol stack Castalia: a WSNs/BANs simulator that can be used also for generic network made of low power embedded devices. Castalia’s salient features include: model for temporal variation of path loss, fine-grain interference and RSSI calculation, physical process modeling, node clock drift and several popular MAC protocols Veins: this framework is introduced for vehicular network simulations. It is based on OMNe. T++, and SUMO, a road traffic simulator. It extends these to offer a comprehensive suite of models for Infrastructure-to-Vehicles Communications (IVC) simulation

9 2. Simulation Frameworks Overview: ns-3 Open source, cross-platform, discrete event network simulator based on C++ (optional Python bindings) ns-3 is characterized by several features, such as parallel execution, real code integration (DCE, Direct Code Execution), real network integration (real-time support and real-time integration) The simulator is organized in modules. Each module provides a single functionality needed to simulate a particular network part. They are independent from each other Each module have a designated maintainer Modules are built with particular attention to real system API Modules have a closer behavior to real system. A Simulation is composed by nodes connected through one or more channels. A node is a logical representation of the relationship between the entity (e. g. Applications, Protocols, Network Devices) of a real network node.

10 2. Simulation Frameworks Overview: ns-3 Basic simulation components are grouped in: Core module: basic building blocks of the framework, such as event schedulers, smart pointer, attribute systems Networks module: nodes, headers, trailers, packets Internet module: contains all the Internet protocol (IPv 4, IPv 6, TCP, UDP, etc. ) A wireless simulation is composed by several blocks: Channel model (propagation and spectrum interference model) Mobility model Wireless Network Device (Net. Devices) model Protocols (TCP, UDP, ICMP…) Routing Applications

11 3. OS oriented tools: Tiny. OS (www. tinyos. net) Open source OS with a large developer community One of the most popular operating systems for WSNs and runs on various hardware platforms such as Mica 2, Micaz, and Telos. B It is inherently an event-driven OS Whenever an event occurs, Tiny. OS wakes-up the node and calls the event handler The handler may schedule tasks that are executed afterwards by the Tiny. OS kernel Tiny. OS and applications are written in nes. C, an extension of the C programming language Programs are built using statically linked components, resulting in a small memory footprint. Components may be nested in order to make other components. TOSSIM: it is a WSN simulator extension, using real node code evaluation of power consumption realistic radio models

12 3. OS oriented tools: Contiki (www. contiki-os. org) Contiki OS is built around an event-driven kernel. An event scheduler that dispatches events to the running processes is included in the Contiki kernel Contiki maintains a queue of pending events and the events are dispatched to target processes according to a First In First Out (FIFO) policy In addition, a preemption mechanism allows to manage and prioritize events Concurrent events can be managed by resorting to Protothreads Contiki and its applications are written in Embedded C (a special C for embedded systems Contiki OS has its own simulator (Cooja), which allows the simulation of Contiki motes Motes can be emulated at hardware level (slower but allowing precise inspection of the system behavior) less detailed level (faster and allowing simulation of larger networks).

13 3. OS oriented tools: Ri. OT (www. riot-os. org) Open source OS with a large developer community Ri. OT OS aims at bridging the gap between OSes for WSNs and ‘normal’ OSes, currently running on Internet hosts. Among the goals of Ri. OT are included energy-efficiency, small memory footprint, modularity and uniform, hardware-independent, API access. Ri. OT implements a microkernel architecture inherited from Fire. Kernel, thus supporting multi-threading with standard API. In addition , Ri. OT adds support to C++ and provides a TCP/IP network stack. The advantages of the Ri. OT architecture include: high reliability developer-friendly API robustness against bugs in single components developers are allowed to create as many threads as necessary Ri. OT does not have a specific node simulator

14 4. ns-3 Framework Modular architecture Each module implements one or more protocols (e. g. , OLSR, AODV, TCP/IP, etc. ) Modules are aggregated into a node A simulation is made of multiples nodes communicating through channels

15 Channel Models Channel between two nodes can be modelled through two modules: Propagation module Spectrum module Propagation module – fading and attenuation effects: Friis, Jakes, Nakagami, Okumura Hata, etc. Attenuation models can be composed. They may depend on antenna distance, elevation, angles, etc. The result is the signal power at the receiver (for each transmitted packet) Spectrum module – signal composition effects: Allows to model the interference between signals. If two signals share the same spectrum, the model allows to sum their signal in order to calculate the noise and the useful signal powers.

16 Mobility Models Mobility models are split into: Position Movement Mobility models are applied to a whole node. The node mobility can be bound to a specific region. The mobility can take into account different parameters, and can also be correlated to other nodes positions (e. g. , flock-like movements). The node position is 3 D, and Helpers can be used to setup the most common used topologies (e. g. , grid). It is possible to use traces generated by popular mobility simulators (e. g. , SUMO, Bonn. Motion, Tra. NS).

17 IEEE 802. 11 Models Include different extension to the standard, up to 802. 11 n Models provide several functionalities: Infrastructure mode Ad-hoc modes Qo. S and aggregation support The development is focused on Supporto to multiple antenna and MIMO Extension to vehicular and ad-hoc models Possible future development could be represented by the harmonization between the Wi-Fi model and other wireless models.

18 IEEE 802. 15. 4 Models the 802. 15. 4 -2006 standard Simple MAC by default MAC can be extended to simulate complex MAC (e. g. , Contiki. MAC, Z-MAC, etc. ). Ad-hoc, beacon-less mode of operation (at the time of writing) Planned enhancements: Beacon-based operations 802. 15. 4 -2011 compliance Sleep models and energy-aware MAC protocols

19 LTE/LTE-A Models (http: //networks. cttc. es/mobile-networks/softwaretools/lena/) Tool for the test and the evaluation of several aspects of the LTE network: Radio Resource Management Inter-Cell Interference Coordination Mobility management Handover The network scenario can be composed by multiple e. Node. B (e. NB) and User Equipment (UE) The simulator can be divided in two main components: EPC model: provide end-to-end IP connectivity over the LTE model. It supports only IPv 4 connectivity LTE model: composed by e. Node. B (e. NB) and User Equipment (UE) EPC model is composed by SGW, PGW, MME and partially by the e. NB. It focused mainly on data plane aspects.

20 LTE/LTE-A Models (http: //networks. cttc. es/mobile-networks/softwaretools/lena/) The LTE model implements all levels of the LTE protocol stack (i. e. RRC, PDCP, RLC, MAC and PHY) At PHY layer, the minimum level of granularity is represented by the Resource Block (RB) MAC layer follows the guideline proposed by the Small. Cell Forum and provides a good number of schedulers RLC model provides Transparent Mode (TM), Unacknowledge Mode (UM), Acknowledge Mode (AM) connectivity PDCP entity maintains the PDCP Sequence Number (SN) RRC provides part of control plane functionality, initial cell selection, RRC connection reconfiguration and handover management Lack of IPv 6 and evolved Multimedia Broadcast/Multicast Service (e. MBMS) support

21 TCP/IP, routing and transport protocols TCP/IP models fully support: IPv 4 and IPv 6, including accessory protocols, like: ARP, NDP, RADV DHCP is not supported TCP, UDP, including multiple TCP flavours: Tahoe, Reno, New. Reno, Westwood+, BIC, CUBIC, etc. TCP options (e. g. , Window Scale, Time. Stamp, etc. ) Routing protocols: IPv 4 – Static, AODV, OLSR, DSDV, etc. IPv 6 – Static, RIPng, RPL, etc. Integration with Click and Quagga is possible