Posted on

Hosting your own network map

If you’re a wireless internet service provider or an organisation who want to show an online coverage map there are different options available depending on your level of skill. The basic option is to do this with an arbitrary polygon on a free map like Google maps but if you want a beautiful and accurate physics based coverage map, at no extra cost read on…

Embed code

The easiest way to add a map to your website or blog is with the embed code function. This is a small code (HTML) snippet which you paste into your website, like WordPress, for example. It requires that your blog supports HTML content.

To use this first you must have a layer in your archive. This could be a single area calculation or a large network mesh created from lots of individual calculations. Select it and click the code icon.

You will then be shown your embed code and a notice.

Google Maps Key

The notice says “Replace ‘GOOGLEMAPSKEY’ with your Google Maps key“. This is necessary as you need a key to share an online map as it’s licensed, not a free-for-all. You can get a key at no cost from Google if you visit this link:

https://developers.google.com/maps/documentation/javascript/get-api-key

To test your key works visit a HTML online editor, paste in your embed code and replace GOOGLEMAPSKEY with your long random Google Maps key. If successful you will see your map and your embed code is ready to go on your website!

Self-hosted (Expert mode)

The downside to embed code is the layer must be fetched from a server from Europe. For most users this won’t be a problem but if you are in Australia and your layer is quite large this could result in a blank map for a second or two – not a great advert if you are a business.

To deliver a faster map to your local customers, host the layer yourself. To do this, take the previously described embed code and extract the long link starting https://api.cloudrf.com/…

Paste that into a browser to visit the page directly then view the source code. Here you will find a link to a .png image in your archive as well as the necessary Google Maps Javascript.

Copy that code to your own website and download the PNG image. Upload the PNG image to your server and edit the link so it points to the local copy eg. yourcompany.com/files/yourlayer.png

Copy the code between the html tags.

Terms and attribution

You can host as many of these maps as you like for no extra cost but unless you have written permission, attribution is required. This is already included as a small link on the map but we won’t object if you want to add your own label too.

We will host your data so long as your account is in credit. If your account is not in credit we will retain the data as per the plan limit which is two years in most cases.

If you need your image to be available for lots of website visitors or for longer than 2 years, we strongly recommend self-hosting your PNG layers.

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

API 2.0

CloudRF API

We have a new API.

This long awaited update brings an OpenAPI 3.0 compliant REST implementation with a redesign of public facing architecture so all requests will go to https://api.cloudrf.com and documentation will be at https://docs.cloudrf.com

Human readable requests

The old API grew into an exhaustive list of +43 variables starting from only 10 when it was an Android app. That’s just the public ones. There’s more parameters relating to interfaces. We were adding about a dozen variables a year in the early years of the service and turned down many requests for protocol-specific parameters to keep the number manageable and keep the API signal and technology agnostic.

The new JSON body schema tidies these +40 variables into logical objects which not only align with the interface but can be dropped completely for example in the case of the optional environment object, and defaults used.

New endpoints

The CloudRF API is now at api.cloudrf.com

Documentation is at docs.cloudrf.com

We’ve got OpenAPI / Swagger documentation at https://api.cloudrf.com/swagger-ui/

Legacy ../API/ endpoints and old API documentation are still active and will be until October 2021.

OpenAPI

New functions

Some previously undocumented interface features are now in the new API. These are exporting user files into GIS formats and uploading GeoJSON features as private clutter. These are now documented in API2.0

New authentication

The days of sending your unique identifier ‘uid’ and your API key in the HTTP request as uid=…key=… and then scrubbing them out of presentations are thankfully finished!!!

Now you have one API key which you must put into a HTTP ‘key’ header. This keeps your sensitive credentials separate from your body which contains site parameters. This also means the path to offline JSON templates is now clear. We’ve offered templates for years but as rows in a private database, now that the private bits are out of the way you can confidently share an API request.

JSON site templates

A nice feature about this new API is because the sensitive authentication parameters have been removed, and the entire site/antenna/environment exists as a single JSON object, you can take this away and share it, save it, reuse it, publish it. We’re going to build on this concept to offer a new style of template system so as well as saving your settings for quick reuse as you can now, you can share your settings.

This will also enable novice API users to create valid requests by fetching a template eg. “VHF radio.json” from the library and dropping it into an API client, along with their ‘key’ to run that template through their account.

Legacy API sunset 1st October 2021

The legacy API will still run in parallel and will be retired on the 1st October 2021. Please move your projects over to the new API soon and see our documentation and client code examples on Postman to do this.

We are publishing more application specific examples to assist with this and will be on hand to help customers migrate.

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

Crunch a spreadsheet on Windows

Windows CSV

Using the CloudRF API 1.0, you can process an entire spreadsheet of site data in one go to make a complete network coverage map. This tutorial assumes you are a Windows user with minimal programming experience. It uses the free scripts available to download as a ZIP from https://github.com/Cloud-RF/CloudRF-API-clients/archive/refs/heads/master.zip. Power users can use the Python clients to integrate into their system(s).

1. Prepare your data

Your data needs to be in a basic comma separated CSV spreadsheet (known as MS-DOS CSV format in Microsoft Excel). The top row should be column headers defined at https://docs.cloudrf.com.

You can find example CSV files called ‘area.csv’ and ‘path.csv’ in the python folder or download them from here:

https://github.com/Cloud-RF/CloudRF-API-clients/blob/master/python/area.csv

https://github.com/Cloud-RF/CloudRF-API-clients/blob/master/python/path.csv

Your UID and KEY values are unique to your CloudRF account and can be obtained once logged in at the ‘my balance’ page. You can also test on Ibiza without an account using uid 101 and key IBIZA.DEMO.KEY

2. Setup your configuration file

Open a console in the ‘windows’ folder (Shift right click to open the power menu) in the folder you unzipped and run area.exe with no arguments. This will create a blank ‘cloudrf.ini’ file. Edit this file in a text editor so it contains your credentials and a destination folder for files, relative to your location:

[user] 
uid = 101 
key = IBIZA.DEMO.KEY 

[api]

strict_ssl = True base_url = https://api.cloudrf.com

[data]

dir = out

3. Process your data

Open a console in the ‘windows’ folder in the folder with the .exe files. Call the program followed by the CSV file and an output format eg. KMZ.

./area -i area.csv -s kmz 

Or for the Path Profile API with PNG chart images…

./path -i path.csv -s chart 

If your data is well formatted, you will see results appear in your terminal for each row.

Use your results

Everything you do is stored on the server. The demo script also pulls down a KMZ file for each calculation but if you want to see your finished result, login to the web interface at https://cloudrf.com/ui and open your archive. You will find your spreadsheet has become a coverage map! You can use the data either in the web interface, download it from there as a KMZ, SHP or TIFF file. If you want to publish or share the data you can get a URL or HTML embed code to host the layer on your own website.

Create a super layer

You can merge all your sites into one layer for convenience with the ‘mesh’ API.

Create a super layer by visiting this URL in any browser with your UID and network name. The layer can be named whatever you like but will belong to the ‘mesh’ network group within you archive. If you have lots of large sites this can take a minute a site so be patient and check your archive later.

https://api.cloudrf.com/API/mesh?uid={your UID}&network={your network}&name={superlayer}

Change and repeat

Once you’ve got your result its quite common to wonder what effect a different parameter might have. To change a value for all columns, change it for the first row eg. set txw (Transmitter power in Watts) to 2 then copy that value into all the rows below. Save the CSV file and reprocess with the command as before. You will need a new network name (net) to keep your new files separate. In your web archive you can then go and select the network with the old parameters and delete it by checking the box and clicking the trash can icon.

Alternative languages / scripts

The simple API can be used with any other language. You can find examples of Javascript forms from the API clients downloaded in the example above and more languages over at https://api.cloudrf.com. Expert users don’t even need a desktop as you can use CURL from a shell environment:

Posted on

Helium LPWAN

Helium vision

Helium is a novel crowd sourced LoRa LPWAN network which uses Sub-GHz ISM bands (868MHz for EU, 915MHz for US).

The network nodes, known as ‘hotspots’, are owned and operated by individuals who are incentivised with crypto currency ($HNT). A hotspot will ‘mine’ $HNT when it can see other hotspots, known as Proof-of-coverage (POC).

Put simply, the better your coverage, the more money you make.

As a result, propagation expertise is in high demand which is where we come in 🙂

Helium has been growing for years but 2021 saw a surge in growth (see $HNT price below) which caused us to review the free plan to maintain QoS. A good problem to have all the same..

HELIUM VISION

The excitement around $HNT has been matched with a flurry of Helium hotspot businesses. The most mature of these is helium.vision (HV) owned by USMC vet and professional developer Nick Hough. We partnered with HV to add CloudRF’s API to https://app.helium.vision so HV customers could have everything in one place.

HV used the area API and LoRa templates to generate API requests from their own map. PNG images were then overlaid and stored locally. The beauty of this implementation is if a customer tries the same building, the result loads up instantly as it’s locally cached and no repeat load is sent to the CloudRF API.

Helium vision
Helium vision

We’re working with HV to add more APIs, including our new fast points API. Watch this space..

Posted on

Keeping motorsport smooth

A motorsport customer invited us to a track day to observe a peculiar RF problem… High resolution ‘dashcam’ video feeds have become standard in motorsport with multiple cameras present on vehicles and drivers. Unlike a consumer dashcam, these real-time video feeds use TV broadcasting radio links to relay a signal from the vehicle to the video processing facility via track-side receivers. The problem is Motorbikes with video feeds were experiencing RF difficulty on bends despite being close to high gain receiving antennas. This issue was investigated with the CloudRF API which revealed the following findings:

  • Lean angle has a direct impact on signal quality
  • Adjacent riders will attenuate signals
  • A bike at full tilt will experience antenna polarisation loss
  • Mast heights must be wavelength x (distance/4) to compensate for dynamic losses
  • Low masts, like tight boots, are terrible!

Doppler shift

The system must contend with several challenges; firstly the doppler effect caused by a shifting emitter. This effect is negligible at slower speeds but can cause reception issues as the vehicle increases speed and the frequency appears off tune. A superbike moving at 100mph would result in as much as a 5% shift in frequency which depending on the location of the receiver could be an increase or decrease of 1MHz. The effect can be modelled and managed with frequency tracking receivers designed to overcome this high speed issue.

Lightweight RF links

Weight is critical in maintaining a competitive edge so the RF links employed are low power emitters, using the vehicle’s native electrics. Licensing restrictions also limit the maximum allowed power output. The standard used in this case is ISDB-T which is an MPEG-4 H-264 high definition video stream which at full rate employs QAM-64 modulation. The H-264 quality High Definition (HD) video feeds people are accustomed to require a high signal-to-noise ratio of at least 20dB which is achieved by careful deployment of track-side high gain antennas and dedicated broadcasting spectrum at 2.3GHz. The system uses 7MHz of bandwidth (broken down into sub-carriers) which has an absolute noise floor of -105dBm. Adding the necessary 20dB SNR gives -85dBm which with the addition of 10dB of environmental (7dB) and receiver (3dB) noise gives a target threshold of -75dBm. The antenna on the motorbike is a shark fin, vertically polarised design mounted on the tail of the bike behind the rider. For the purposes of this investigation the antenna has been modeled with 1dBi gain and and an ERP of 18dBm / 65mW, equivalent to just under a consumer WiFi router. The video broadcast unit is concealed nearby within the bike’s tail with minimal cabling between the antenna for tidiness and maximum efficiency. The track-side antennas would be directional antennas with at least 10dBi of forward gain. These would be positioned at key points on the race track for maximum benefit. The siting of these antennas is where CloudRF is used to test options.

Bends

Using GPS data from races, it was found that there could easily be 8 motorbikes in a tight group on a bend. As the bikes all take the bend, several changes occur which all impair RF propagation, resulting in disruption to the smooth HD feed:

1. Rider attenuation

A significant change to consider is the increase in environmental attenuation caused by the crowd of riders. At 2.3GHz the human body will absorb 3dB of RF power. Assuming there are 3 bikes between the rider and the receiver this could be a substantial +9dB of attenuation – comparable to a brick wall (7dB) at this wavelength.

2. Antenna tilt

As bikes lean on a bend so do their vertically polarised antennas. As an antenna deviates from its optimal polarity (vertical) to horizontal it loses power up to 3dB at full tilt (90 degrees). If a bike is at half tilt, polarisation loss will cost the RF link 1.5dB.

3. Antenna height

Coupled with tilt, the height of the antenna above the earth will reduce from ~100cm to as little as ~50cm. This will reduce its effectiveness as more of the key fresnel zone will be attenuated by the earth. Using a fresnel zone calculator the fresnel zone radius for a 2.3GHz link over 300m is 3 metres. Elevating the track side antennas on masts is one way to overcome this issue but when one end of the link is so near the earth the (tower) elevation must be much higher than the fresnel radius if it is to clear the earth completely as these profile images demonstrate. Modelling using the Irregular terrain model which considers fresnel attenuation shows substantial loss caused by minor reductions in the (bike) antenna height. As you can see in the path profile below, the curved fresnel zone clips the earth which introduces attenuation.

Modelling the problem with the CloudRF API

The customer wondered if the issue might be identified through Monte-Carlo simulations whereby random inputs, in this case bikes, were placed on the track and the coverage mapped for comparison. This type of simulation is possible through the coverage API with custom client scripts and can help identify where to site receive antennas around a given track. After much deliberation it was realised that the benefit of area modelling would be limited in contrast to focusing on the impact of a bend on a single bike which could be adjusted for different lean angles and simulated crowds. For this study the Path Profile (PtP) API was used to focus on a short 300m straight line path between a bike and a mast, with variation to the inputs. The bike’s height was adjusted to simulate lean based upon a starting height of 100cm (Superbike tail height average) down to a minimum of 50cm when at full tilt. The impact of adjacent riders was simulated by adjusting the receiver gain downwards, in this case by 9dB to simulate 3 other riders. The significance of receiver height was demonstrated by adjusting the mast to clear the fresnel zone at this distance.

Results

The following data was generated using the ITM model with transmission heights ranging from 1m (Bike is upright) to 50cm (full lean). The ITM model considers the effect of the obstruction of the fresnel zone which is the cone of power around the path of a signal. Measurements are based upon a mast 300m away, on flat earth, with a 9dBi sectorial panel antenna. The zone grows deeper as it travels so mast height must consider this as well as line of sight clearance.

3m mast

A 3m mast is higher than most vehicles and ground clutter but only for line of sight. At 300m the fresnel zone is 3.12m so this mast height is only high enough up to about 250m before power is lost as the fresnel zone is attenuated by the earth. Results show that without obstructions 3m is borderline as bikes lean and as soon as a bike is obstructed by another it falls below the target threshold, regardless of lean angle.

3 metre mast, unobstructed

3 metre mast, obstructed

6m mast

A 6m mast is a major improvement. Being well clear of the fresnel zone makes it able to handle a full 60 degree lean at 300m. Results show that without obstructions 6m is good for all scenarios and if a bike is obstructed by others it only falls below the target threshold by 5dB which could be recovered with a higher gain antenna or by siting the antenna closer to the bend.

6 metre mast, unobstructed

6 metre mast, obstructed

The results reveal the following common findings:
  • Lean angle has a direct impact on signal quality with a full 60 degree lean adding more than 6dB of attenuation
  • Adjacent riders can introduce substantial attenuation with 3dB per rider
  • A bike at full tilt will lose another 1.5dB in antenna polarisation loss
  • Receiver height must be at least twice the maximum fresnel zone distance to budget for these issues
  • Receiver distance must be sufficient to maintain the double fresnel clearance so a distant mast is OK providing it is high enough
  • Low masts, like tight boots, are terrible!

Ideal mast height

The ideal mast height is relative to the frequency. At 2.3GHz the wavelength is 0.13m which based on the 300m distance used must be multipled by 24 to clear the fresnel zone making the minimum mast height 3.1m. As tests have shown, this height is insufficient to handle dynamic losses from leaning and other riders so should be doubled. Based on data, the recommended minimum height for a mast covering bikes on a bend is wavelength multiplied by distance/4 which gives the following table.
Distance mHeight m
1003.3
2006.5
3009.8
40013
50016
60019.5

Scripts and data

Scripts and data used to generate this study are available here. To use them you will need to enter your CloudRF API credentials into the CSV files and run them as follows: python3 pathprofile.py pathprofile_3m.csv For plotting to PNG charts you will need Gnuplot: gnuplot unobstructed.gnuplot
Posted on

DIY clutter

DIY clutter
In this video, a Port in west Africa poorly served by high resolution data is enhanced with DIY clutter. The result shows substantial attenuation from the shipping containers which due to their dynamic nature would not be current in commercial data.

Summary

High quality clutter data is necessary for accurate radio planning but it’s not always available when and where you need it. Using the new ‘My clutter’ feature at CloudRF you can define your own and use it in seconds. The data can be layered on top of existing data, regardless of resolution, to enhance accuracy with material attenuation conforming to ITU standards for forests.

Clutter data

Clutter data in modelling refers to objects on the earth’s surface. In radio this is typically buildings and trees which attenuate signals. These must be factored in to deliver accurate predictions. It’s normally very expensive and the market for this data is worth billions due to demand by global telecommunications firms. This puts it out of reach of most small businesses and organisations.

Material attenuation

Different materials attenuate RF in different ways. The impact depends upon the wavelength (eg. WiFi can’t go through thick walls) and the material (concrete absorbs more RF than wood). For more on this subject see the land cover blog here.

How

Use the form in the ‘Model’ menu to either define your own polygons and lines or upload your own bulk clutter as a KML file containing polygons.

Why

Here’s a few reasons why DIY clutter is necessary:
  • Based on market pricing it would cost over a billion dollars to purchase ‘commercial’ clutter data for the earth.
  • Based on experience, the lead time for clutter in Africa can be 6 weeks.
  • The expensive clutter data is out of date by the time you buy it. Shipping containers, construction, transport will change and they affect RF coverage.
  • Commercial clutter data doesn’t let you model future construction projects eg. a new building
Posted on

Modelling trees and buildings

3D buildings Land Cover or ‘clutter’ data describes obstacles on the earth’s surface a radio wave will have to negotiate like trees or buildings. The Land cover data is layered on top of the terrain data which can be either a smooth(er) Digital Terrain Model (DTM) or a rougher ground-with-clutter ‘Digital Surface Model’ (DSM) . For DTM and DSM this will allow you to simulate attenuation from a forest or city where it might not otherwise be represented in the data resulting in much more accurate results. It also means you can enhance basic coarse terrain data with fresh high resolution land cover to reflect recent construction developments.

Obstacles and attenuation

Radio waves are attenuated differently by different materials like vegetation and man-made buildings. The impact varies by frequency with very short wavelength signals like WiGig at 60GHz struggling to penetrate a paper wall whilst a long wavelength VHF signal can breeze through multiple brick walls. For accurate modelling its essential that land cover is considered otherwise you run a risk of an unrealistic prediction which will bear little resemblance to real world results.

Trees

Trees attenuate differently with dense coniferous pine forests attenuating the most. An ITU standard, ITU-R P.833-7 “Attenuation in Vegetation” exists to describe the impact of a forest of different signals. There have been many academic studies into this subject but the summary of this standard for a mixed deciduous/coniferous forest is as follows:
Frequency MHzAttenuation dB/m
1060.04
4660.12
9490.17
18520.3
21180.34
No two forests are the same but if you err on the side of caution you can budget for their impact with a rule of thumb that 10m of mixed forest is equivalent to 2dB of attenuation at 1GHz, 4dB at 2GHz and 8dB at 4GHz. Trees are defined in the Land cover used by the system with attenuation values aligned to ITU-R P.833-7 which scale with wavelength so the same forest block will attenuate a WiFi signal more than a PMR446 signal. The resolution varies by region with 30m for CONUS, 100m for Europe and 500m for the rest of the world.

Buildings

Man-made buildings are even less predictable due to the variety in size, density and materials used. Many studies have been conducted into building attenuation but they are region specific due to construction materials and designs. A good reference is a UK paper by OFCOM which merges multiple research papers and has a useful table of attenuation by material and frequency on page 39.
MaterialAttenuation dB/m
at 1GHz
Attenuation dB/m
at 10GHz
Concrete24>50
Brick3232
Plasterboard11>50
Wood5>50
Glass344
Ceiling board110
Chipboard22>50
Floorboard4>50
The system currently has four classes of building attenuation for high to low intensity developments. The attenuation rate is 1% of the solid material attenuation rate (eg. Brick is 32dB/m so a brick house in CloudRF is 0.32dB/m) since most buildings are largely hollow.

Land cover data

To enhance DTM and DSM models with 3D clutter, Land Cover data can be layered on top of the terrain to apply representative attenuation. This Land Cover data has been sourced from a variety of sources with up to 30m resolution. The total possible resolution possible is determined by the highest resolution data so if you are in New York City for example where there is 2m LIDAR / DSM data available, your effective resolution will be 2m.

30m Digital surface model

30m Digital surface model plus 30m land cover

2m Digital surface model (LIDAR)

2m Digital surface model (LIDAR) plus 30m land cover

Propagation models

Propagation models vary in complexity from the simple ‘one liners’ like the free-space-path-loss model to the incredibly complex Irregular Terrain / Longley Rice model. Most models are simple and must be used within their parameter limits (especially with empirical ‘measured’ models) otherwise you could get wildly inaccurate results. A good example is the well known Hata model which was designed for elevated cellular base stations serving mobile subscribers which were lower than it. If you use this model at the bottom of a hill you can get some incredibly unlikely results as the simple model has no concept of terrain only A to B. By using Land cover, the output from these simple models can be enhanced greatly to provide a result which is sensitive to changes in the terrain along a given path, similar to how the ITM model works.
A UHF repeater at the foot of some hills with 20m DSM only. By default the Sleipnir engine will restrict coverage to line-of-sight for simple models like Hata.
With knife-edge-diffraction enabled, the Hata coverage is free to roam beyond line-of-sight. The coverage becomes very optimistic to the west up in the hills as Hata has no concept of terrain and expects a clear shot from the base station to the mobile station.
With knife-edge and 30m Land cover enabled, the optimistic Hata coverage is still free to roam beyond line-of-sight but is now severely constrained by the dense forests and urban developments without modifying the model itself.

Forest example

Modelling little forest blocks far away from your tower is easy with accurate DSM data but modelling a huge forest where your tower is within it is a harder problem. Heights are all defined as relative to the ground so if you have a 10m tall forest which is represented as raised earth in a DSM model and your tower is 12m tall you will end up with a tower which is in fact 22m above the ground – not ideal! Instead, when working with the 30m DSM you should define your height as the height above the canopy which is 2m. Here’s a comparison using 30m DSM and 30m Land cover in west Virginia.

Free space path loss prediction for an outdoor WiFi router, 30m DSM.

30m DSM plus 30m Land cover.

Urban example

To demonstrate the attenuation of buildings, this example has an emitter (LTE eNodeB on 800MHz) equidistant between a city and some countryside. The attenuation of the urban land cover becomes obvious once applied which contrasts with the open fields and water.

Free space path loss prediction for an LTE eNodeB, 30m DSM

Free space path loss prediction for an LTE eNodeB, 30m DSM with 30m Land cover

Summary

Land cover is essential for accurate planning and is now supported at 30m resolution. Coupled with high resolution data like 2m LIDAR, you can now accurately model attenuation of different materials in a cluttered environment. More land cover data is planned for the near future along with an upgraded ‘my clutter’ interface to allow you to define your own forests or housing developments for areas where data may not be available.
Posted on

Modelling the Bit Error Rate (BER)

2400MHz_propagation_models When simulating radio propagation you can choose to model results in a variety of ways: Path loss will show you the attenuation in decibels (dB), Received Power will show you the signal strength at the receiver in dBm and field strength will show you the signal strength in micro-volts (dBuV/m). If you are using a digital modulation schema such as Quadrature-Amplitude-Modulation (QAM) your effective coverage will be dictated by the desired Bit Error Rate (BER) and local noise floor. This blog will describe these concepts and show you how to apply them to model a given modulation schema.

Bit Error Rate (BER)

The Bit Error Rate (BER) is the number of acceptable errors you are prepared to tolerate. This is typically a number between 0.1 (every 10th bit is bad!) and 0.000001 (Only one in a million is bad). This ratio is closely linked to the Signal-to-Noise-Ratio (SNR) which is measured in decibels (dB). A high SNR is required for a low BER. A low SNR will have an increased BER. Put simply a strong signal is better than a weak one and has less chance of errors. The reason error increases with SNR is because of noise. The closer you get to the noise floor for your band (about -100dBm at 2.4GHz), the more unstable and unpredictable things become.
DecimalExponentialLink quality
0.110e-1Bad
0.0110e-2Not bad
0.00110e-3OK
0.000110e-4Good
0.0000110e-5Very good
0.00000110e-6Excellent

The noise floor

The noise floor is the ambient power present in the RF spectrum for your location, frequency, temperature and bandwidth. Understanding the noise floor is important when modelling Bit Error Rate as it is subject to change and will determine your SNR. The SNR will determine your BER so if you want good coverage you need to know your noise floor so you can set your power accordingly. There are several factors that influence noise floor:

Location

A lot of noise if man-made so the noise floor is higher in a city than in the mountains. The difference varies not just by city but by country as countries have different spectrum authorities and regulate spectrum usage differently. The difference between a city and the countryside for a popular band like 2.4GHz is huge and can be over 6dB. Using a calibrated spectrum analyser with averaging is a good way to measure the noise floor. Ensure you set the bandwidth to your system’s bandwidth for best results. If you don’t own a spectrum analyser you can use Boltzmann’s Constant (see bandwidth section) and add an arbitrary margin to it depending on your location. This table has some suggested generic values:
LocationSignalNoise floor
Rural / RemoteWiFi 2.4GHz-101dBm
SuburbanWiFi 2.4GHz-98dBm
Urban cityWiFi 2.4GHz-95dBm
Rural / RemoteWiFi 5.8GHz-98dBm
SuburbanWiFi 5.8GHz-95dBm
Urban cityWiFi 5.8GHz-92dBm

Frequency

Thermal noise is spread uniformly over the entire frequency spectrum but man-made noise is not. The 2.4GHz ISM band is much busier than neighbouring bands for example due to its unlicensed nature. As a result the noise floor is several dB higher than a ‘quieter’ piece of the RF spectrum. Some of the quietest spectrum is co-incidentally the most tightly regulated, which keeps users down, which reduces noise, and improves performance.

Temperature

Thermal noise increases with temperature so in general you will get slightly more distance for your power in northern Scandanavia than in central Africa. The difference is about 1dB between a cold day and a hot day so can be considered negligible when compared with other factors. Budget for a hot day with an extra dB in your planning.

Bandwidth

Bandwidth has a direct influence on noise power because of Boltzmann’s Constant. This simple formula lets you calculate the absolute noise from the bandwidth. There are different ways to apply the formula but if you use dBm then the simplest form is: Noise floor dBm = -114dBm + 10 Log(Bandwidth in MHz) Using this formula you get the following results.
Receiver Bandwidth MHzNoise floorEquivalent system
0.1-124dBmLPWAN
1.0-114dBmBluetooth
10-104dBmWiFi 10MHz
20-101dBmWiFi 20MHz
40-98dBmWiFi 40MHz
100-94dBmSpectrum analyser with 100MHz FFT
If in doubt, use a noise floor of -98dBm

Example

A low power 20MHz wide 64QAM signal is being simulated in a city. The noise power is computed from the bandwidth with Boltzmann’s Constant as -101dBm to which we add +3dB for man-made noise putting the noise floor at -98dBm. When selecting a BER of 0.1 / 10e-1 the SNR is 11dB which equates to a receiver threshold of -87dBm.
The difference in propagation between the two error rates is noticeable with 64QAM but what happens if you switch up the modulation to 1024QAM which carries a higher SNR?