Introduction
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.
Our engineering team uses emulators right from the beginning of a complex communications development project. The use of a high-fidelity emulator boosts the requirements phase, saves time, and lets teams work on the features a lot earlier than before. Beyond the time savings, the development of an emulator brings cross-functional teams together early in the process and lets them envision aspects of a project or product right from the start.
Simulation versus emulation, what is the difference? The following quote describes the differences in terminology.
For our developments, we distinguish the term “network emulation” from “network simulation” 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.
Network emulation typically occurs at the control plane for networked devices, but can also require 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 real-time messaging protocols or content required, and the behavioral characteristics that were not achievable through the use of either a commercial or open source network emulation packages available at the time of the development.
The following paragraphs describe these custom real time network emulation developments.
iNET Radio Emulator
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 emulation 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.
Defense System Networked Radio (DSNR) Emulator
Radio emulators allow for testing control and data plane interface messaging, timing, and concepts in advance of the actual development of a deployed radio. This introductory design and development effort is an important risk abatement process whose purpose is to work out many of the network interface protocols and behavior to inform the future system software design and development.
For the Defense System Networked Radio (DSNR) project, we developed as part of a broader simulation and emulation task, a radio emulator. This emulator was deployed on a network of Linux desktops to act as radios for real time emulation. The radio emulation application that executes on the hardware platform was written in C++ and used the wxWidgets cross platform GUI library for it’s user interface.
The RF interface of the radios was emulated by a hard wired network connection between each Linux desktop by way of a secondary network interface card to a hub — thus representing a digital only lossless emulated RF test environment as the over the air interface. The primary network interface to the radio simulator provided a host facing interface to Cisco routers.
The radio emulator provided a bandwidth constrained transmit path with delay and queuing characteristics that mimicked the characteristics of the target radio to emulate a wireless network.
The networked radio to be developed, and by inference the radio emulator, had 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 procedure 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 required developing the PPPoE protocol implementation between the radio and a directly connected 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 emulate 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 emulated wireless 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 emulating both the data and control planes of the networking radio, an inexpensive collection of Linux desktops was created that pioneered not only the technology necessary to be implemented in the actual radio, but allowed external upstream control systems to have a stand-in for testing and development. In addition, much of the developed source code from the radio emulator was utilized in the development of the actual physical radio firmware illustrating the importance of emulation/simulation at the physical hardware and networking layers towards a successful radio implementation.
Flight Test Telemetry Radio Emulator
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 the lightweight embedded Arch Linux operating system 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.
Smart Munition Network Messaging Application
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.
Modeling and Simulation
Simulation is a cost-effective method for developing, deploying and managing network-centric systems throughout their entire lifecycle. Users can evaluate the basic behavior of a network, and test combinations of network features that are likely to work.
The telecommunications industry has recognized the strong benefits of network emulation as a risk abatement measure to the development of a network based product. Network designers are constantly challenged by the growing complexity of communications protocols and the increasing scale of network deployments. In order for network organizations to innovate, they need robust network emulation software to easily and intuitively model the intricate end-to-end behavior of protocols. The solution must also be able to efficiently analyze the performance of these protocols and technologies in network infrastructure models of realistic scale. We have OPNET modeler emulation capabilities and expertise for testing out networking and communications protocols at scales that are difficult to replicate with hardware.
Conclusion
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.