Location aware radios
Modern digital radio systems often have Application Programming Interfaces (APIs) for remote management. They also commonly have Global Navigation Satellite System (GNSS) modules for location awareness which enables “network maps” of where the nodes are. These vendor maps are great at showing where nodes are now (provided they are in coverage!) but what they lack is the ability to plan where nodes could be moved to.
When you combine these key features with our open standards modelling API you get a powerful new capability which allows you to observe the network now, and by moving or adding a simulated node, see the network in the future.
Case study – Trellisware
TrelliswareTM are a market leader in Mobile Ad-hoc Networks (MANET) whose versatile radios work where others fail due to their spectrum efficient TSM waveform. It’s currently in service with Government, Commercial and First responder markets.
The radios have a comprehensive API and integrated software services which allows for remote operation on a IP based network.
We were loaned some TW-950 Shadow radios to explore API integration. In a few days we were able to create an API client (in Python) to interface between the Trellisware API and our RF modelling API on SOOTHSAYER 1.3 which has a MANET planning tool.
Our Python client would interface with the radio network via the Ethernet connector on the side of a TW-950 radio from where the API would expose node metadata.
We would fetch this metadata (as JSON) and package it into a JSON document compatible with our Points API, which powers our MANET and route analysis tools. In the interface’s MANET tool, a new ‘play’ button pulls in the network document and models it through our fast API. Each link is tested using the real parameters, with minimal user interaction.
The flowchart is depicted below.
Once the data is displayed in the SOOTHSAYER interface, an operator can choose to move a node by dragging it or add an entirely new node, using settings of their choice, into the mix. This new node will be modelled alongside the rest of the nodes (many-to-many) to visualise what the impact of the new node will be.
A faster OODA loop
The Observe, Orient, Decide, Act (OODA) planning loop is an established concept which determines success in fast moving communications environments such as a fire or Police incident.
By combining real-time situational awareness with live modelling we can exercise scenarios and reach sound decisions much faster than by either guessing or using trial and error as is often the case in tactical communications in complex environments. The benefit is faster more efficient use of limited resources.
Demo: Do we launch the drone?
Deploying a drone equipped with a radio is a guaranteed way to fix MANET network issues, especially in cluttered urban environments. It’s resource intensive and risky as the drone is valuable, the radio, and network it enables, is arguably more valuable plus the battery life is very limited so this asset must be used sparingly, which is where planning comes in.
Placing a repeater drone “overhead” is not needed, unless you’re using it for observation also. If the drone has a vertical dipole, overhead would actually be the worst place for it due to the donut shaped antenna pattern as some early OEMs learnt the hard way.
A better place for a communications relay drone is at altitude but on the edge of the target network where it will be at less risk (and will present less risk to net members below it in the event of failure) but it will still be able to serve as an effective repeater.
As recent MANET demos have proven, this repeater could be effective from several miles away.
Look ahead
Now that we have a simple standards based, repeatable, method for adding live radios we’ll roll this into future SOOTHSAYER releases, the next of which is 1.4, scheduled for Q3 2022.
Customers can make their own plugins in any language to get their hardware data packaged as a JSON document for either SOOTHSAYER’s MANET tool or direct to the points API which powers it. You can find example scripts in various languages on our Github site and we are available to assist with bespoke integrations.
References
API examples: https://github.com/Cloud-RF/CloudRF-API-clients/tree/master/APIv2
API specification: https://cloudrf.com/documentation/developer/swagger-ui/
Contact
If you are a hardware manufacturer or integrator looking to add this type of capability into either your own map or ours, get in touch as we know what we’re doing and it will save you years of R&D.
Email support@cloudrf.com for more information on how you can achieve dynamic planning quicker.
