Introduction
EMANE (Extendable Mobile Ad-hoc Network Emulator) is an open source distributed emulation framework which provides wireless network experimenters with a highly flexible modular environment for use during the design, development and testing of simple and complex network architectures. EMANE uses a physical layer model to account for signal propagation, antenna profile effects and interference sources in order to provide a realistic environment for wireless experimentation. Individual radio model plugins are used to emulate the lowest layers of a waveform and can be combined with existing Software Defined Radio (SDR) implementations to enable shared code emulation.
The EMANE emulator consists of three major subsystems:
EMANE emulation processing consists of physical layer model instances paired with instances of one or more radio (waveform) models. The emulator processes configuration XML in order to determine the type of radio model plugins to instantiate, how the models and physical layer instances should be configured and what general application level settings to apply.
The EMANE distribution contains three radio models:
and one utility model:
As the emulator instantiates model plugins it places each in a Network Emulation Module (NEM) along with a dedicated instance of the emulator's physical layer. Physical layer instances are interconnected using an Over-The-Air (OTA) multicast channel. All OTA messages are processed by every emulator instance using the same OTA multicast channel. This is how the emulator physical layer accounts for signal propagation, antenna effects and interference sources across heterogeneous radio models.
Each radio model operates differently but the general idea is that a model receives a message from application space to transmit over the air and sends the message to it's physical layer instance for transmission over the OTA multicast channel (possibly after the radio model performs a channel access function). All emulator instances using the same OTA multicast channel receive the message and perform a receive power test. Those physical layer instances that determine the message receive power was greater than the receiver sensitivity either categorize the message as noise or as a valid in-band waveform signal. Valid waveform signals are sent to the receiving radio model for additional processing. Most radio models then employ Bit Error Rate (BER) curves based on the message Signal to Noise and Interference Ratio (SINR) as part of the decision as to whether or not to deliver the message to the corresponding application space process.
The term application space process should not be confused with the notion of kernel and application/user space. All EMANE processes run in user space. We use the term application space, usually as part of the application/emulation boundary topic, to mean any process not running as a plugin within the emulator but that is somehow connected to (using) the emulator.
We use the term downstream for all messages headed towards the OTA multicast channel and the term upstream for all messages headed towards delivery to application space processes. This does not mean that the OTA multicast channel or an application space process must be the final message destination. When a radio model sends a control message to it's corresponding physical layer instance we call that a downstream control message and when a physical layer instance sends a packet message to a radio model we call that an upstream packet message. Once you start analyzing radio model performance statistics, you'll appreciate understanding the distinction.
The application/emulation transport boundary is the emulation component responsible for delivering messages between an emulator instance and one or more application space processes. We call this component a transport. Transports provide the entry and exit point for emulator and application space messages.
Transport plugins can either be instantiated internally as part of the emulator process or externally as part of some other application. The Transport Daemon EMANE application processes configuration XML in order to determine the types of external transport plugins to instantiate, how the plugins should be configured and what general application level settings to apply.
The EMANE distribution contains two transports:
EMANE supports IP and non-IP wireless emulation, so the types of application space messages individual transports support varies widely. However, once a transport has a message to deliver they all must generally do the same thing. In the downstream direction, a transport must determine the NEM Id for the message next hop (which may be the NEM broadcast address) and send the message to the connected NEM along with the source and destination NEM Ids. In the upstream direction, a transport must determine the application space process to receive the message and send it.
As application space messages travel through a transport they lose their form and are sent through the emulator as an opaque payload of a specified size. The transport is the only component in the emulator that can read and write application space message specifics.
The Virtual Transport for example, uses the TUN/TAP interface to create a virtual interface (vif) as the application/emulation boundary entry/exit point. In the downstream direction, ethernet frames routed to the vif by the kernel are packaged into messages and sent to the appropriate NEM for processing. In the upstream direction, NEM messages are unpackaged and written to the TUN/TAP interface as ethernet frames.
Application/emulation boundaries are not limited to plugins loaded internally by the emulator or externally by the Transport Daemon. When connecting Software Defined Radio (SDR) waveforms to EMANE, custom transports should be developed and embedded within the SDR at the Modem Hardware Abstraction Layer (MHAL). EMANE provides application level APIs to make developing a custom transport very easy.
In order to be interesting, a running emulation requires a scenario. A scenario is a set of events that are sent to one or more NEMs in order to change environmental characteristics. Events are delivered opaquely to registered radio model instances so individual radio models may require their own specialized events. Whenever possible we advocate reusing EMANE standard events over creating new events that do the same thing.
The EMANE distribution contains the following events:
- Antenna Profile Event
- Comm Effect Event
- Location Event
- Pathloss Event
- TDMA Schedule Event
- Fading Selection Event
Events are created by an event generator. The Event Service EMANE application processes configuration XML in order to determine the types of event generator plugins to instantiate, how the plugins should be configured and what general application level settings to apply.
The EMANE distribution contains one event generator that will create all the standard events:
and provides python modules to allow you to create your own event generator applications:
- emane.events.EventService
- emane.events.AntennaProfileEvent
- emane.events.CommEffectEvent
- emane.events.LocationEvent
- emane.events.PathlossEvent
- emane.events.TDMAScheduleEvent
- emane.events.FadingSelectionEvent
Have an open source EMANE plugin that you would like us to link to or would you like to sponsor the development of an open source radio model?
Drop us an email: labs@adjacentlink.com.