Posted on

GPU propagation engine

5G cell

We have developed a fast GPU RF propagation engine.

We’ve been busy behind the scenes designing and developing the next generation of fast radio simulation engines for urban modelling with NVIDIA CUDA technology and Graphics Processing Units (GPU).

The engine was made to meet demand across many sectors for speed and accuracy and to enable an automated best-site-analysis capability, which will accelerate planning and improve efficiency whilst keeping a human in the loop.

Designed for 5G

5G networks are much denser than legacy standards due to limited range of mmWave signals, necessary for high bandwidth data. The same limitation means these signals are very sensitive to obstructions, and line of sight coverage is essential for performance.

A dense network means more low power (small) cells are needed, which means more efficient planning is needed.

You can’t just place 5G cells on big hills and crank up the power like it’s the 1990s as the low power handsets would not be able to talk back to them. To achieve an economic and balanced low power urban network requires careful and thorough planning.

Core features

Our GPU engine has several modes, for different use cases. Here’s two we’re focusing on for this quarter.

LOS viewshed

Real time urban analysis

The simplest mode is a fast line of sight “2.5D” viewshed (with a path loss model) which creates a point-to-multipoint heatmap around a given site using LiDAR data. This is comparable to using the current CPU engine with LOS mode – only much quicker. This is up to 50 times faster than our multi-threaded CPU engine, SLEIPNIR.

Demo video: https://www.youtube.com/watch?v=gBrRfwcIhks

ETA: February 2022

Best site analysis

A heatmap of options..

Best Site Analysis (BSA) is a monte-carlo analysis technique across a wide area of interest to identify the best locations for a transmitter. Now we have the GPU speed, this can be done quickly with a new /bsa API call. Presently our GPU based BSA implementation can search a radius around a location, using the 2.5D viewshed technique, to grade locations. The output will identify optimal sites, and just as important, inefficient sites.

This feature will replace the “best site” tool currently in the web interface which is not GPU accelerated

This feature is powerful for IoT gateway placement, 5G deployments and ad-hoc networking where the best site might presently be determined by a map study based on contours as opposed to a LiDAR model.

ETA: March 2022

High speed

Our GPU engine is up to 50 times faster through the API than the current (CPU) engine SLEIPNIRTM

By harnessing the power of high performance graphics cards, we are able to complete high resolution LiDAR plots in near real time, negating the need for a “start” button, or even a progress bar! This speed enables API integration with autonomous drones which will need to model propagation to make better decisions, especially when they’re off the grid. It was designed around consumer grade cards like the GeForce series but will scale to enterprise Tesla grade cards due to our design.

Open API

When it goes live, it will be an option in our /area API so you can use it from any interface by setting the engine option in the request body. The OpenAPI 3.0 compliant API returns JSON which contains a PNG image so for existing API integrations using our PNG layers there will be no code changes required to enable it.

At the time of writing the API integration is undergoing bench testing (see video). This feature is scheduled for public Beta testing in February 2022.

Accessible

Using GPU cards to model Physics, including EM propagation, is an established concept dating back 20 years, despite sales-first businessmen claiming otherwise. Advances in gaming in particular have made ray tracing a mainstream term but there’s a big difference between ray tracing a visual perspective (in view) and modelling a high resolution raster or voxel map to generate a deliverable output. One is pretty and good for games, investors and technology hype-beasts and the other is actually useful for radio engineering.

What is novel here is making this exciting technology accessible to users priced out of premium tools using consumer grade GeForce cards.

Staying true to CloudRF’s accessible and affordable principles, we’ll include it in our service as an optional processing engine this year. Quite what this means for market incumbents and upstarts who currently charge SMEs a small fortune for a basic capability will be interesting. We’ll let the market answer that one.

CloudRF is a member of the free-to-join NVIDIA inception program

Posted on

Mapping mesh networks

Mesh network

Mobile ad-hoc networks (MANET) are an increasingly popular architecture in emergency services and Defence communications. Unlike classic repeater based networks, MANET radio network communications do not have fixed infrastructure so must form self-healing, self-routing networks.

MANET radio modules are well suited to working either off-grid away in remote areas or for providing resilience and independence in well served cities which may be suffering from power and/or network failure.

The bandwidth requirements and throughput of MANET networks varies substantially by waveform. Some are designed for range, others maximum throughput. For this reason, manufacturers offer a range of frequency modules.

Why RF planning tools don’t get used for emergency networks

RF planning software has evolved substantially in the 30 years it’s been used to build out fixed infrastructure networks. Time sensitive customers such as the emergency services have a difficult relationship with these tools. They need them, and often buy them, but don’t have the time to use them to their full capabilities. As a result they rarely get used on anything except training and exercises. Even then the numbers of staff directly interfacing with them will be very small, even in very large organisations of radio users.

The focus for most RF tools is planning with static sites. Whether that’s clicking on a map or uploading a spreadsheet of hundreds of locations it’s still static. MANET requires dynamic inputs and continuous computation which is where APIs come to the fore…

An API for MANET

Cloud-RF’s latest API has a function designed for ad-hoc networks called ‘points’. The points API functions like a point-to-point profile in terms of it’s input and output except it accepts an array of transmitters. This means you can test 10,50 or 500 transmitter nodes back to a single receiver in a single API call. It’s also fast as you’d expect and can model a link every millisecond so the 870 distinct links demonstrated in the video were processed in under a second, every second.

For more information on the points API see our documentation here: https://docs.cloudrf.com

Radio mapping planning

In this video, we demonstrate the Cloud-RF points API to model a MANET network (Mobile Ad-hoc Network). For this demo 30 nodes were moved around a 16km track covering a variety of terrain. Each node was tested against 29 siblings for a total of 870 links per second.


Coloured links denote good (green) average (amber) and poor (red) links between the nodes and map to 5dB, 10dB and 20dB signal-to-noise ratios. Only links exceeding 5dB SNR are shown or it looks like a bad game of kerplunk!

The radio settings used were L band (1-2GHz) with only 1 watt of power. This conservative start setting was chosen to show a dynamic range of links. Later in the video the template is switched at the database to demonstrate the impact or gain of using different bands such as 2.4GHz and 500MHz.

Integrating your data

The demo video used mock data and an unpublished script to present the results as a KML. The source of the data is irrelevant so long as it’s accurate and time sensitive. This could be a radio vendor’s dashboard or database. Many of the leading vendors such as DTC, Harris, Persistent Systems, Silvus and Trellisware have location aware GPS modules and software interfaces to display reported radio positions.

The required format for a point is WGS84 decimal degrees. The height is taken from the template which is defined within the body of the points request. The new APIv2 makes defining a template easy as a JSON object so you can have a local archive of template .json files.

A suggested workflow for API integration for dynamic points is as follows:

  1. Fetch a list of all radio locations as decimal degrees
  2. Choose a template as a JSON object
  3. Make an API request using the data and a client script to https://api.cloudrf.com/points
  4. Parse the JSON response to extract the results for each node
  5. Put the results on a map as lines
  6. Style the lines based upon your own local rules for your equipment, QoS and waveform eg. < 5dB is red

Download example client scripts from our Github site: https://github.com/Cloud-RF/CloudRF-API-clients

For assistance with integration and hosting options email support@cloudrf.com

Autonomous vehicles

Where this points API will really add value is in mapping and assisting autonomous vehicles who are invariably fitted with MANET radio modules. Whether it’s a drone or a UGV, this API can be used to rapidly exercise multiple routes to help make better decisions.

Posted on

RF penetration demonstration

During infantry training, soldiers are shown firsthand the impact of different weapons upon different materials to help them make better decisions about good cover versus bad cover. Spoiler: The railway sleeper doesn’t make it 🙁

As tactical radios have moved several hundred megahertz up the spectrum from their cold-war VHF roots, material attenuation is a serious issue which needs demonstrating to enable better route selection and siting. Unlike shooting at building materials it’s hard to visualise invisible radio signals, and therefore teach good siting, but equally important as ground based above-VHF signals are easily blocked in urban environments.

This blog provides a visual demonstration of the physical relationship between different wavelengths and attenuating obstacles only. It does not compare modulation schemas, multi-path, radios or technologies.

Bricks and wavelengths

Clutter data refers to obstacles above the ground such as trees and buildings. Cloud-RF has 9 classes of clutter data within the service which you can use and build with. Each class (Bricks +) has a different attenuation rate measured in decibels per metre (dB/m). This rate is a nominal value based upon the material density and derived from the ITU-R P.833-7 standard and empirical testing with broadcast signals in European homes.

A signal can only endure a limited amount of attenuation before it is lost into the noise floor. In free space attenuation is minimal but with obstacles it can be substantial. This is why a Wi-Fi router in a window can be hard to use within another room in the house but the same router is detectable from a hill a mile away.

The attenuation rate is an average based upon a hollow building with solid walls.

Common building materials attenuate signals to different amounts based on their density and the signals wavelength.

A higher wavelength signal such as L band (1-2GHz) will be attenuated more than VHF (30-300MHz) for example.

A long wavelength signal like HF will suffer minimal attenuation making it better suited to communicating through multiple brick walls.

The layer cake house

A brick house is not just brick. It’s bricks, concrete blocks, glass, insulation, stud walls, furniture and surfaces of varying absorption and reflection characteristics. Modelling every building material and multi-path precisely, is possible, given enough data and time due to the exponential complexity of multi-path but wholly impractical.

A trade-off for accurate urban modelling is to assign a local attenuation value. It’s local since building regulations vary by country and era so a 1930s brick house in the UK has different characteristics to a 1960s timber house in Germany. Taking the brick house we can identify the nominal value by adding up the materials and dividing it by the size.

For example, 2 x solid 10dB brick walls plus a 5 dB margin for interior walls and furniture would be 25dB. Divide this by a 10m size and you have 2.5dB/m. Using some local empirical testing you can quickly refine this for useful value for an entire city (assuming consistent architecture) but in reality the *precise* value will vary by each property, even on a street of the same design, due to interior layouts and furniture.

Range setup

We created nine 4 metre tall targets using each of the 9 clutter classes in attenuation order from left-to-right, measuring 10x10m and fired radio-bulletsTM at them from a distance of 300m using the same RF power of 1W.

The following bands were compared: HF 20MHz, VHF 70MHz, UHF 700MHz, UHF 1200MHz, UHF 2.4GHz. SHF 5.8GHz.

The ITU-R P.525 model was used to provide a consistent reference.

Only the stronger direct-ray is modelled. Multipath effects mean that reflections will reach into some of the displayed null zones, with an inherent reflection loss for each bounce, but these are nearly impossible to model accurately and in a practical time.

Here are the results.

HF 20MHz

VHF 70MHz

UHF 700MHz

UHF 1200MHz

UHF 2.4GHz

SHF 5.8GHz

Findings

  • Dense materials, especially concrete, attenuates higher frequency signals more than natural materials like trees
  • Lower UHF signals perform much better than SHF with the same power
  • Higher frequencies with low power can be blocked by a single house, even after only 300m
  • HF eats bricks for breakfast!

Summary

Modern tactical UHF radios, and their software eco-systems, are unrecognisable from their cold-war VHF ‘voice only’ ancestors in terms of capabilities but have an Achilles heel in the form of material penetration. To get the best coverage the network density must be flexed to match the neighbourhood.

This is obvious when comparing rolling terrain with a urban environment but the building materials and street sizes in the urban environment will make a significant difference too. Ground units which communicated effectively in a city in one country may find the same tactics and working ranges ineffective in another city with the same radios and settings. Understanding the impact of material penetration will help planning and communication.

Posted on

Uplink and Downlink

A popular question when modelling GSM / UMTS / TETRA / LTE networks is how can I show the coverage from the mobile subscribers (Uplink)? Showing a tower’s coverage (Downlink) is easy but how do you go the other way back to the tower? If you know your equipment capabilities (tower and subscribers) you can calculate link budgets for both the uplink and downlink and then use those values to perform an area prediction. Here’s a simple example with the GSM900 band and without some of the other gains and losses which can complicate this for the benefit of novices. You can always add in your own gains and losses where you like to suit your needs.

1. Calculate the total effective radiated power for the BTS tower by adding the power and antenna gain (Limited to 33dBm in the UK)

2. Repeat for handset (Limited to 23dBm in the UK)

3. Calculate the minimum receive level for the BTS by subtracting the receive antenna gain from the receiver sensitivity eg. -110 – 10 = -120

4. Repeat for handset

5. Calculate the maximum allowed path loss (MAPL) by subtracting the minimum receive level from the ERP.

6. Repeat for handset

A balanced network will have similar values. If your base station can radiate for miles but your handsets cannot you have an unbalanced and inefficient network.

Finally, to see this on a map, use the ‘Path loss (dB)’ output mode in CloudRF along with the ‘Custom RGB’ colour schema. Enter the uplink value into the green box and the downlink value into the blue box and run the calculation. A typical cell site will have a greater reach (blue) than it’s subscribers (green). The system will automatically factor in the effect of terrain, ground absorption, antenna heights to give you an accurate prediction.