We typically develop hardware and software solutions that are components of larger systems, with both upstream controlling applications and downstream controlled components. With a focus on digital communications, we have had to develop radio emulators to be able to successfully develop and test our primary applications, or as part of a broader simulation/emulation environment. Simulation versus emulation, what is the difference? The following quote describes the differences in terminology.
Emulation is the process of mimicking the outwardly observable behavior to match an existing target. The internal state of the emulation mechanism does not have to accurately reflect the internal state of the target which it is emulating. Simulation, on the other hand, involves modeling the underlying state of the target. The end result of a good simulation is that the simulation model will emulate the target which it is simulating.
For our developments, we distinguish the term “network emulation” from “network simulation” based primarily on the real time nature of network emulation versus simulation. Most of our hardware in the loop (HWIL) developments require real time emulation — whereas OPNET and other products such as ns-3, are discrete event based network simulators that are not real-time. The differences between the terms network emulation and simulation are further described in the news post Network Emulation vs. Simulation.
This network emulation typically occurs at the control plane for networked devices, but can also required emulation of the data plane such as when emulating the queuing and delay characteristics of a bandwidth constrained device to emulate and test network latencies representing the transfer of data over a wireless shared medium.
The necessity for developing custom network emulators stemmed from the custom messaging protocols or content, and the behavior characteristics that we not achievable through the use of either a commercial or open source network emulation package available at the time of the development.
The following sections describe these custom real time network emulation developments. Click and item to expand the panel for viewing details on the emulator described in the heading text.
For the iNET Link Manager, while we developed the radio control application, we were not provided the actual radio hardware, which makes it virtually impossible to develop, test, and verify our controlling application. Radio hardware can be both expensive and often times development time lines do not coincide with our development ambitions, so we had to create substitutes.
On the iNET program, as a result of a lack of actual physical radio hardware, we developed a radio emulator application that executes on desktop Linux and/or embedded Linux on a cluster of Raspberry Pi hardware. This application, written in C++ using the Qt cross platform framework, emulators from the control plane perspective of the radio’s network interface, the messaging and timing of the RF transceivers. This emulator responds to custom binary control messages from the iNET Link Manager, which consists of TDMA transmit opportunities relative to a synchronized clock. This application verifies and records the integrity of the control messaging from the iNET Link Manager to verify that transmit opportunity values are correct. Transmit opportunities from the iNET Link Manager are based on the radio’s outgoing queue loading and link quality metrics in closed loop fashion.
To craft different test scenarios, the content of outgoing messaging generated by the radio emulator application were soft coded with content specified by a loadable spreadsheet. The spreadsheet contents provided queue status and link quality metric values as a function of time with repeat patterns. Like a player piano, once simulation begins, beginning at the start of the next minute, the radio emulator provides queue status and link quality metric values based on the test defined sequences of values.
In the iNET system, radios can be combinations of connected types: ground, airborne, or airborne relay. To support these three types, the iNET radio emulator imitated the control plane messaging for all three of these radios in a single program. Separate user interface tabs were used for the three radio types displaying information, statistics, and control. The tabbed user interface allowed enabling or disabling logical “links” between each of the 3 radio types to test out the behavior of dropped and reconnected links and the handover procedure.
Value Change Dump (VCD) logging was provided on the iNET radio emulator to allow for microsecond precision capture and analysis of messaging timing for system verification.
Another scenario where radio emulators are required is for a pure simulation environment, where the radio emulators allow for testing control and data plane interface messaging and concepts in advance of the actual development of a deployed radio. This introductory effort is a risk abatement process to work out many of the network interface protocols and behavior details to guide the future system software design and development.
For the Defense System Networked Radio (DSNR) project, we developed as part of a broader simulation task a radio emulator that was deployed on a network of Linux desktops. This application was written in C++ and used the wxWidgets cross platform GUI library. The RF interface of the radios was emulated by a hardwired network to the desktop to a hub thus representing a digital only and lossless emulated RF test environment. The radio simulator provided a bandwidth constrained transmit path with delay and queuing characteristics that mimicked the characteristics of the target radio.
The DSNR radio, and by inference the radio emulator, has data and control plane exchanges with a host device by way of Cisco routers in a Mobile Ad Hoc Network (MANET) configuration. This is part of Cisco’s Mobile Ad Hoc Networks for Router-to-Radio Communications strategy. In this Cisco strategy, the PPPoE protocol is extended to enable a router or radio to query or report link-quality metric information.
The MANET implementation uses PPP over Ethernet (PPPoE) sessions to enable intra-nodal communications between a device and its partner radio. Each radio initiates the PPPoE session as soon as the radio establishes a radio link to another radio. After the PPPoE sessions are active, a PPP session is established end-to-end (device-to-device). This is duplicated each time a radio establishes a new radio link. The virtual multipoint interface (VMI) on the device can aggregate multiple PPPoE sessions and multiplex them to look like a single interface to the routing processes. Underneath the VMI are virtual access interfaces that are associated with each of the PPP and PPPoE connections.
A PPPoE session is established between a device and a radio on behalf of every other device and radio neighbor located in the MANET. These Layer 2 sessions are the means by which radio network status gets reported to the Layer 3 processes in the device. The figure below shows the PPPoE session exchange between mobile devices and directional radios in a MANET network.
The radio emulator involved developing the PPPoE protocol implementation between the radio and a paired Cisco router to achieve point to point links. To control the rate at which a sender can transmit data for each PPPoE session, extensions to the PPPoE protocol as credit flows (per RFC4938) were implemented as part of the control plane. The credit flow implementation minimized the queuing in the radio. In order to emulator the bandwidth constraints and delay timing of an actual radio, the data plane implemented in the radio emulator used a configurable delay mechanism between host data from the wired interface to the simulated wireless network. This allowed for evaluating credit flow and bandwidth limitations of the simulated channel.
The radio emulator also provided an SNMP agent interface and support for a custom MIB, so that an upstream SNMP manager could be developed in advance or parallel to the radio’s design and development. To inform an upstream SNMP Manager, this application generates event notifications via SNMP traps, and SNMP is used for customizing radio parameters such as neighbor lists, packet latencies, packet drops and bandwidth allocations per link.
By simulating both the data and control planes of the radio, an inexpensive desktop implementation was created that pioneered not only the technology necessary to be implemented in the actual radio, but allowed external systems to have a stand in for testing and development. Much of the developed source code from the radio emulator was utilized in the development of the physical radio firmware illustrating the importance of simulation at the physical hardware level towards a successful target implementation.
A customer of ours had the challenge of being able to test out a network of high performance telemetry receivers at a time when they were shipping receivers as quickly as they could be built and tested. There are times when it is simply not economical or possible to maintain a network test lab of physical devices.
We were able to port the networking and web interface components of this telemetry receiver firmware based on embedded Arch Linux to a very low cost cluster of Raspberry Pi hardware running under a generalized distribution UbuntuMATE embedded Linux operating system. The radio emulator emulated in real time the control plane networking message protocol of the actual radios along with the web interface to permit testing out the telemetry receiver’s networking software at scale without tying up actual physical telemetry receivers.
What do you do when you need to develop a network based device which interfaces with both upstream and downstream components from other vendors, but you will never receive those external devices from the other vendors due to their own parallel development time lines? The answer is you must develop a custom test application to emulate the interface messaging from the external components in real time to allow you to develop and test your own network based device.
Radio emulators are not the only custom test applications that we have developed. We developed a Windows based test application in C++ and MFC that emulated the control and status messages for a smart anti-personnel munitions network. This custom application allowed for synthesizing the interface control messages and all message arguments through an easy to use GUI based user interface.
This test application was used by ourselves and other component vendors for a networked based system of several components from different vendors. The test application allowed an operator to first script a sequence of messages along with message arguments to be issued for testing, and then run the scripted configuration wherein the created message stream is sent to a device under test (DUT). Received messages from the DUT are captured and decoded from binary format into human readable format.
Network emulation and simulation frameworks are essential for designing, developing, and analyzing the creation of communications systems. The differences between network emulation and simulation are described in the post Network Emulation vs Simulation.
While there are circumstances where only a custom network emulator will suffice for the project requirements, sometimes a more generalized solution may be possible using an open source real-time network emulator. For real-time network emulation, we utilize the Extended Mobile Ad-hoc Network Emulator (EMANE) framework. EMANE is a next-generation framework for real-time modeling of mobile network systems. For discrete event network simulation, we utilize OPNET Modeler. The EMANE framework has a focus on real-time modeling of link and physical layer connectivity so that network protocol and application software can be experimentally subjected to the same conditions that are expected to occur in real-world mobile, wireless network systems. The EMANE architecture provides for Network Emulation Modules (NEMs) that can be associated with computer system (real or virtualized) network stacks as interfaces. The EMANE framework further provides an event-driven control bus and logging facilities.
EMANE 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.
At the real time physical networking level, we have developed radio emulators with very specific custom behaviors, timing, and messaging protocols. These emulators allow for system level development and testing in the absence of the actual radio hardware. The following list summarizes the features:
- These networking device emulators operate real time on the control plane of a network device.
- As required, the emulators operate on the data plane as well such as when mimicking the delay and queuing characteristics of a network device by storing and then forwarding host data over a simulated RF network.
- Control plane messaging responses (e.g. queue status and link metrics) can either be externally scripted to the radio emulator to implement a specific test scenario using message contents loaded from an external spreadsheet, or may be naturally occurring as a function of data plane activity reflecting bandwidth constraints.
- SNMP agent interfaces can be implemented for network devices that are SNMP network managed devices to allow upstream SNMP management development to occur using the SNMP agent interface provided in the emulator.
- Web interfaces and REST API interfaces can be added to the emulators to allow for HTTP/HTTPS control and status of a emulator, and for upstream REST API clients to be developed.
We can leverage this broad experience to create emulators for your specific requirements — which extends beyond radio emulators to simulating any form of real time network accessible device where network control and possibly data plane emulation is required.
OPNET discrete event network simulation coupled with real time platform based network emulation provide the full suite of tools necessary for prototyping and evaluating systems in advance of the relatively longer and more expensive cycle of designing and developing an embedded networked communications product.