Источник: https://ipvszope.informatik.uni-stuttgart.de/.../karl.pdf

We live in a mobile world, where accessing information anytime and anywhere becomes more and more important. Recent changes in technology, such as the growth of the internet or the boom in the field of mobile phones have required robust, reliable and evaluated network protocols. There are several methods for evaluating the behavior of protocols. Besides performance analysis methods like wide-area testbeds and small-scale lab evaluations the common performance analysis method is network simulations. To carry out network simulations, network simulators are used. The development and employment of network simulators has a long history. For example the network simulator NS derives from REAL (Realistic and Large) which derives again from NEST (Network Simulation Testbed). [8] But most network simulators have some drawbacks. Many have a high resource consumption and lack certain features, like modularity, adaptability and interactivity. Therefore, a student project called CUBUS has been initiated that is aimed at developing a new network simulation tool which supports these features. Today’s network simulators have widely varying focuses. VINTs network simulator NS focuses on the simulation of networks at the packet level, while TOSSIM was developed to aid in the simulation of TinyOS sensor networks. Just as different network simulators have different focuses and are employed in different fields of research, they vary in their architecture. To develop an understanding of how to design the architecture of the simulator CUBUS, this paper investigates the architecture of two prominent network simulators – that of Tossim and NS-2 – and compares them.

TOSSIM is a discrete event simulator for TinyOS wireless sensor networks. TOSSIM and TinyOS were developed at UC Berkeley. In contrast to the network simulator NS, TOSSIM captures the behavior and interactions of networks not on the packet level but at network bit granularity. TinyOS is a sensor network operating system that runs on so-called motes. Motes are tiny sensing and computational devices that have very limitted communication, computational and energy resources. TinyOS sensor networks are often composed of large numbers of these little hardware devices [7].

The TOSSIM architecture is composed of five parts [4]: ? TinyOS Component Graphs (Frames) ? Execution Model (Events) ? Models (Radio and ADC Models) ? Hardware abstraction components ? Communication Services Figure 2 shows these five parts that make up TOSSIM. Every TinyOS Program is a graph of components. Each of these TinyOS components represents an independent computational entity. The first part of the TOSSIM architecture, the “Component Graphs” or also designated as “Frames” support the user in compiling TinyOS component graphs into the simulation infrastructure. Here, TOSSIM takes advantage of TinyOS’s structure. The second part of the architecture, the Execution Model is essentially a discrete event queue that enqueues and dequeues events and is responsible for the actuation of the simulation. To model the characteristics of TinyOS network motes, TOSSIM provides mechanisms for extensible radio and ADC models. TinyOS abstracts all hardware resources as components. Another part of the TOSSIM architecture contains TOSSIM implementations and a small number of re-implemented TinyOS hardware abstraction components.

Basis for understanding the “Component Graphs” part of the architecture is a fundamental understanding of TinyOS’s program structure. A TinyOS program is a graph of components [4]. Figure 3 shows a simplified component graph of an TinyOS Application. The TinyOS component has five interrelated parts: a set of command handlers, a set of event handlers, an encapsulated private data frame, a structure of private variables that can only be referenced by the component itself and a bundle of simple tasks. Tasks, commands, and event handlers execute in the context of the frame and operate on its state. Commands and events are mechanisms concerning communication between components, while tasks are used internal. To facilitate modularity, each component also declares the commands it uses and the events it signals. A command is used to direct a request to a component to perform some sort of service. An example for a command may be the request to initiate a sensor reading. An event signals the completion of a service. In general the command returns immediately and the event signals completion at a later time.

Since TOSSIM simulates TinyOS mote hardware it has to abstract and model all of the characteristics of the underlying hardware in software. Hardware works with interrupts, so TOSSIM has to model this as well. For that purpose a simulator event queue sits at the core of TOSSIM that delivers the interrupts that drive the execution of a TinyOS application. This event queue may be considered as the heart of TOSSIM. TOSSIM models each TinyOS interrupt as a simulation event [4]. But note that simulator events are distinct from TinyOS events. Each event is associated with a specific mote. Simulator events run atomically with respect to one another. Therefore, unlike on real hardware, interrupts cannot pre-empt one another. After each simulator event executes, TOSSIM checks the task queue for any pending tasks,and executes all of them in FIFO (First-In, First-Out) scheduling order. In TOSSIM, interrupts do not pre-empt tasks. The hardware abstraction components of the TOSSIM implementations contain a software implementation of an interrupt handler. When a simulator event calls an interrupt handler in the TOSSIM hardware abstraction components the interrupt handler signals TinyOS events and calls TinyOS commands. These TinyOS events and commands again post tasks and cause further simulator events to be enqueued, driving execution forward.

The TinyOS operating system running on motes abstracts each hardware resource as a component. TOSSIM takes advantage of that by replacing only a small numer of these components (such as the ADC, the Clock, the EEPROM, etc.) it emulates the behavior of the underlying raw hardware. TOSSIM models these components in the hardware abstraction components part of the architecture. According to [4] the connection point for the simulated environment is provided by the low level components that abstract sensors or actuators.

The network simulator NS is a discrete event network simulator developed at UC Berkeley that focuses on the simulation of IP networks on the packet level [3]. The NS project (the project that drives the development of NS) is now part of the Virtual InterNetwork Testbed (VINT) project, that develops tools for network simulation research [1]. Researchers have used NS to develop and investigate protocols such as TCP and UDP, router queuing policies (RED, ECN, CBQ), Multicast transport, Multimedia and more [8]. NS is basically an Object-oriented Tcl (Otcl) script interpreter with network simulation object libraries. NS has a simulation event scheduler, network component object libraries and network setup (plumbing) modul libraries. To use NS for setting up and running a network simulation, a user writes a simulation program in Otcl script language. Such an OTcl script initiates an event scheduler, sets up the network topology and tells traffic sources when to start and stop transmitting packets through the event scheduler.

The network simulators NS-2 and TOSSIM focus on different aspects and have therfore totally different architectures. While NS-2 focuses on the simulation of network nodes at the packet level TOSSIM’s approach is to simulate the TinyOS sensor networks at bit level granularity. However, the architecture of NS-2 and TOSSIM have some aspects in common. Both simulators have some kind of event handling mechanism to cope with the processing of events. TOSSIM calls it event queue, NS name it event scheduler. Moreover, both simulators model the components of the simulated network in some way. TinyOS abstracts each hardware device as a component and a graph of these components forms a TinyOS program. And in NS, a network is composed of compound components which are moded through the NS class hierarchy.

1. The network simulator. [электронный ресурс] - Режим доступа: http://www.isi.edu/nsnam/ns/.
2. Marc Greis's tutorial (now maintained by VINT group) [электронный ресурс] - Режим доступа: http://www.isi.edu/nsnam/ns/tutorial/index.html.
3. J. Chung, M. Claypool. NS by Example. Worcester Polytechnic Institute (WPI). [электронный ресурс] - Режим доступа: http://nile.wpu.edu/NS/purpose.
4. P. Levis, N. Lee, M. Welsh, and D. Culler. TOSSIM: Accurate and Scalable
5. Simulation of Entire TinyOS Applications. Proceedings of the First
6. ACM Conference on Embedded Networked Sensor Systems (SenSys 2003).
7. P. Levis and N. Lee. TOSSIM: A Simulator for TinyOS Networks, 2003.