Analyzing signal coverage with line-of-sight calculation and path loss estimation

In the telecommunications industry, coverage analysis is a fundamental process for assessing the geographical areas where a network's signal is available and determining its quality. Effective signal coverage analysis ensures that telecommunication providers can deliver consistent, high-quality service to their customers, identify areas needing improvement, and strategically plan for network expansion.

This guide shows how to use CARTO telco functionality in the Analytics Toolbox for BigQuery for signal coverage analysis. Specifically, we will cover:

1. Running path profile analysis to evaluate the line-of-sight and potential obstructions between two points.

2. Estimating the path loss of a signal as it propagates through an environment using the Close In and Extended Hata models.

By the end of this guide, you will have computed the line-of-sight for a selection of transmitters in an area of interest and estimated the path loss of their corresponding signals.

Data

To run this analysis, we need the locations of the base stations (i.e. the transmitters, or Tx), the locations of the receivers (Rx), and one or more sources of clutter data. Clutter data includes information about physical obstructions or environmental features that can affect wireless signal propagation. This data can be visualized on the different layers in the map below.

Transmitters (Tx)

For the transmitters, we randomly selected three locations in London (see the Transmitters (Tx) layer in the map above). We need to specify:

• id: A unique ID

• height: The height above the ground in meters

• geom: The point location of the transmitter

• buffer: The radius in meters that determines the area around each transmitter that will be considered for the line-of-sight calculation

Data available at cartobq.docs.prop_london_tx_locations.

Receivers (Rx)

Receivers must also be indicated as point geometries. For every receiver, we need to specify:

• id: A unique ID

• geom: The point location of the receiver

• height: The height above the ground in meters

We have the option of informing only a few specific point locations, but typically, we will be interested in computing the line-of-sight for an area of interest around transmitters, i.e., in a polygon geometry. To achieve this, we first need to discretize our area of interest. We strongly recommend polyfilling the area of interest with spatial indexes, such as Quadbins, to accomplish this. Spatial indexes allow for the efficient management of large datasets, which is essential for a high-resolution line-of-sight calculation.

For our area of interest, we selected a polygon in London containing the three transmitters (see the Receivers (Rx) layer in the map above). To discretize this area, we polyfill our area of interest using Quadbin zoom 25 (around 1 sqm grid cells) to achieve decent granularity. This can be easily done using the QUADBIN_POLYFILL_MODE function available in CARTO Analytics Toolbox.

carto-un

CREATE OR REPLACE TABLE `<my-project>.<my-dataset>.prop_london_rx_locations` 
CLUSTER BY geom AS
SELECT CAST(qk AS STRING) AS id,
       `carto-un`.carto.QUADBIN_CENTER(qk) AS geom,
       2.0 AS height
FROM UNNEST(`carto-un`.carto.QUADBIN_POLYFILL_MODE(
       ST_BUFFER(ST_GEOGPOINT(-0.1276, 51.5072), 4000), 25, 'center')) AS qk
;

carto-un-eu

CREATE OR REPLACE TABLE `<my-project>.<my-dataset>.prop_london_rx_locations` 
CLUSTER BY geom AS
SELECT CAST(qk AS STRING) AS id,
       `carto-un-eu`.carto.QUADBIN_CENTER(qk) AS geom,
       2.0 AS height
FROM UNNEST(`carto-un-eu`.carto.QUADBIN_POLYFILL_MODE(
       ST_BUFFER(ST_GEOGPOINT(-0.1276, 51.5072), 4000), 25, 'center')) AS qk
;

manual

CREATE OR REPLACE TABLE `<my-project>.<my-dataset>.prop_london_rx_locations` 
CLUSTER BY geom AS
SELECT CAST(qk AS STRING) AS id,
       carto.QUADBIN_CENTER(qk) AS geom,
       2.0 AS height
FROM UNNEST(carto.QUADBIN_POLYFILL_MODE(
       ST_BUFFER(ST_GEOGPOINT(-0.1276, 51.5072), 4000), 25, 'center')) AS qk
;

Note that our area of interest has to be large enough to contain the 500-meter buffers around transmitters that we specified before.

Data available at cartobq.docs.prop_london_rx_locations.

Clutter data

We can use different sources of clutter data, such as buildings, vegetation, or terrain height. This data can be in vector or raster format, and there are two separate procedures for each type for calculating line-of-sight, as shown in the corresponding section. In this example, we will test both the vector and raster procedures.

For vector data, we will use:

• Building footprints Source: Overture Global Buildings, a public and global dataset available in the CARTO data catalog.
• Terrain height Source: CARTO Spatial Features Quadbin resolution 18 for UK, available in the CARTO data catalog. A public version of this dataset is available in resolution 15.

Samples of the two data sources have been made available for reproducibility at cartobq.docs.prop_london_buildings_sample_overture and cartobq.docs.prop_elevation_spatialfeatures_gbr_quadgrid18_sample.

For raster data, we will use LIDAR digital surface (DSM) and digital terrain (DTM) data at 1 m resolution made publicly available by the Department of Environment, Food and Rural Affairs. DSM is the model that captures the natural and built features on the Earth’s surface. It contains the height - elevation considering the buildings, trees, and any other structure that exists. DTM is sort of a smoothed version of DSM, where non-ground points such as buildings and trees have been filtered out.

We combined the two models to create a canopy height model as CHM = DSM - DTM. The CHM and DTM were uploaded into BigQuery using the CARTO raster loader.

Raster data has been made available in BigQuery at cartobq.docs.prop_london_dtm_cog (digital terrain) and cartobq.docs.prop_london_canopy_cog (canopy height model).

Path profile analysis. Line-of-sight calculation

Once we have all our data ready, we can proceed with path profile analysis. We will first demonstrate how to perform this analysis using vector data, followed by raster data.

Line-of-sight calculation using vector data

To calculate the line-of-sight of the three transmitters in a 500-m buffer around them, we use the TELCO_PATH_PROFILE procedure that takes as input:

• The query or fully qualified name of the table containing the transmitters' locations. As stated above, for each transmitter we need a unique identifier, height, geometry, and a buffer radius, which in this case is 500 m.

• The query or fully qualified name of the table containing the receivers’ locations. As stated above, for each receiver we need a unique identifier, geometry, and height.

• The fully qualified name of the output table.

• Different options regarding clutter data sources or the operating frequency of the links in GHz. See documentation for further information.

The code below calculates the path profile for the transmitters and receivers explained in the data section, with Overture buildings and Spatial features elevation data. We select further options include_obstacles_table so that the optional output table with the details on the obstacles is exported and terrain_points so that terrain morphology is accounted for. Note we use the buildings' centroids as geometries to speed up the calculation.

carto-un

CALL `carto-un`.carto.TELCO_PATH_PROFILE(
   -- id STRING, geom GEOGRAPHY, height FLOAT64, buffer FLOAT64
   'cartobq.docs.prop_london_tx_locations',
   -- id STRING, geom GEOGRAPHY, height FLOAT64
   'cartobq.docs.prop_london_rx_locations',
   -- id, height, geom
   '<my-project>.<my_dataset>.prop_los_vector_london',
   '''{
    "buildings_query":"SELECT * EXCEPT (geometry, centroid), centroid AS geom FROM cartobq.docs.prop_london_buildings_sample_overture",     
    "terrain_height_query":"SELECT geoid, `carto-un`.carto.QUADBIN_CENTER(geoid) AS geom, elevation AS height FROM cartobq.docs.prop_elevation_spatialfeatures_gbr_quadgrid18_sample",
    "include_obstacles_table":"TRUE",
    "terrain_points":"TRUE"
    }'''
);

carto-un-eu

CALL `carto-un-eu`.carto.TELCO_PATH_PROFILE(
   -- id STRING, geom GEOGRAPHY, height FLOAT64, buffer FLOAT64
   'cartobq.docs.prop_london_tx_locations',
   -- id STRING, geom GEOGRAPHY, height FLOAT64
   'cartobq.docs.prop_london_rx_locations',
   -- id, height, geom
   '<my-project>.<my_dataset>.prop_los_vector_london',
   '''{
    "buildings_query":"SELECT * EXCEPT (geometry, centroid), centroid AS geom FROM cartobq.docs.prop_london_buildings_sample_overture",     
    "terrain_height_query":"SELECT geoid, `carto-un-eu`.carto.QUADBIN_CENTER(geoid) AS geom, elevation AS height FROM cartobq.docs.prop_elevation_spatialfeatures_gbr_quadgrid18_sample",
    "include_obstacles_table":"TRUE",
    "terrain_points":"TRUE"
    }'''
);

manual

CALL carto.TELCO_PATH_PROFILE(
   -- id STRING, geom GEOGRAPHY, height FLOAT64, buffer FLOAT64
   'cartobq.docs.prop_london_tx_locations',
   -- id STRING, geom GEOGRAPHY, height FLOAT64
   'cartobq.docs.prop_london_rx_locations',
   -- id, height, geom
   '<my-project>.<my_dataset>.prop_los_vector_london',
   '''{
    "buildings_query":"SELECT * EXCEPT (geometry, centroid), centroid AS geom FROM cartobq.docs.prop_london_buildings_sample_overture",     
    "terrain_height_query":"SELECT geoid, carto.QUADBIN_CENTER(geoid) AS geom, elevation AS height FROM cartobq.docs.prop_elevation_spatialfeatures_gbr_quadgrid18_sample",
    "include_obstacles_table":"TRUE",
    "terrain_points":"TRUE"
    }'''
);

As a result, the output is stored in <my-project>.<my_dataset>.prop_los_vector_london that contains every transmitter-receiver pair with a flag indicating whether each link is clear of obstacles (i.e., is within line of sight), among other information. See documentation for further details.

The details about the intersected clutter (buildings) are stored in table <my-project>.<my_dataset>.prop_los_vector_london_details.

The resulting tables from the TELCO_PATH_PROFILE call are available at cartobq.docs.prop_los_vector_london and cartobq.docs.prop_los_vector_london_details.

The top-map below shows the resulting line-of-sight of one of the transmitters and assuming we have a receiver in each grid point in the area of interest. We can see areas that are obstructed (yellow) vs areas that are not (light blue).

Line-of-sight calculation using raster data

Similarly, we perform the same analysis using the raster data described in the Clutter data section, i.e., the digital terrain model and canopy height model data. We do so with the PATH_PROFILE_RASTER procedure that is optimized to work with raster data. This procedure takes as input:

• The query or fully qualified name of the table containing the transmitters' locations. As stated above, for each transmitter we need a unique identifier, height, geometry, and a buffer radius, which in this case is 500 m.

• The query or fully qualified name of the table containing the receivers’ locations. As stated above, for each receiver we need a unique identifier, geometry, and height.

• The fully qualified name of the output table.

• Different options regarding clutter data sources or the operating frequency of the links in GHz. See documentation for further information.

The code below calculates the path profile for the transmitters and receivers explained in the data section, with the digital terrain model and canopy height model data. We select as further options:

• include_obstacles_table so that the optional output table with the details on the obstacles is exported

• clutter_raster_band with the bands and aliases to be extracted from the clutter raster

• intersect_center to extract the pixel values from raster tables by intersecting the pixel center or instead the pixel boundary from the Fresnel zone (see RASTER_VALUES)
• intersect_fresnel_zone to use the First Fresnel Zone for extracting the obstructing pixels or the line connecting the transmitter-receiver pairs.

carto-un

CALL `carto-un`.carto.TELCO_PATH_PROFILE_RASTER(
      -- id STRING, geom GEOGRAPHY, height FLOAT64, buffer FLOAT64
      'cartobq.docs.prop_london_tx_locations',
      -- id STRING, geom GEOGRAPHY, height FLOAT64
      'cartobq.docs.prop_london_rx_locations',
      -- id, height, geometry
      '<my-project>.<my-dataset>.prop_los_raster_london',
      '''{
       "clutter_query":"cartobq.docs.prop_london_canopy_cog",
       "terrain_height_query":"cartobq.docs.prop_london_dtm_cog",       
       "include_obstacles_table":"TRUE",
       "clutter_raster_band":"band_1 AS height, 'clutter' AS type",
       "intersect_center":"TRUE",
       "intersect_fresnel_zone":"TRUE"
       }'''
  );

carto-un-eu

CALL `carto-un-eu`.carto.TELCO_PATH_PROFILE_RASTER(
      -- id STRING, geom GEOGRAPHY, height FLOAT64, buffer FLOAT64
      'cartobq.docs.prop_london_tx_locations',
      -- id STRING, geom GEOGRAPHY, height FLOAT64
      'cartobq.docs.prop_london_rx_locations',
      -- id, height, geometry
      '<my-project>.<my-dataset>.prop_los_raster_london',
      '''{
       "clutter_query":"cartobq.docs.prop_london_canopy_cog",
       "terrain_height_query":"cartobq.docs.prop_london_dtm_cog",       
       "include_obstacles_table":"TRUE",
       "clutter_raster_band":"band_1 AS height, 'clutter' AS type",
       "intersect_center":"TRUE",
       "intersect_fresnel_zone":"TRUE"
       }'''
  );

manual

CALL carto.TELCO_PATH_PROFILE_RASTER(
      -- id STRING, geom GEOGRAPHY, height FLOAT64, buffer FLOAT64
      'cartobq.docs.prop_london_tx_locations',
      -- id STRING, geom GEOGRAPHY, height FLOAT64
      'cartobq.docs.prop_london_rx_locations',
      -- id, height, geometry
      '<my-project>.<my-dataset>.prop_los_raster_london',
      '''{
       "clutter_query":"cartobq.docs.prop_london_canopy_cog",
       "terrain_height_query":"cartobq.docs.prop_london_dtm_cog",       
       "include_obstacles_table":"TRUE",
       "clutter_raster_band":"band_1 AS height, 'clutter' AS type",
       "intersect_center":"TRUE",
       "intersect_fresnel_zone":"TRUE"
       }'''
  );

As a result, the output is stored in <my-project>.<my_dataset>.los_raster_london that contains every transmitter-receiver pair with a flag (column los) indicating whether each link is clear of obstacles, among other information. See documentation for further details.

The details about the intersected clutter (buildings) are stored in the table <my-project>.<my_dataset>.los_raster_london_details.

The resulting tables from the TELCO_PATH_PROFILE_RASTER call are available at cartobq.docs.prop_los_raster_london and cartobq.docs.prop_los_raster_london_details.

The bottom-map above shows the resulting line-of-sight of each transmitter where we can see areas obstructed vs areas that are not.

Details table

One interesting visualization that can provide insights on the types of clutter that intervene with the links can be created using the information stored in <my-project>.<my_dataset>.prop_los_vector_london_details or <my-project>.<my_dataset>.prop_los_raster_london_details. For example, the map below shows the clutter data and the projected-to-the-ground Fresnel zone between a selected receiver and its corresponding transmitter.

Propagation models. Path loss estimation

Path loss estimation is crucial in wireless communications for power management, link budget calculation, cell planning and optimization, interference mitigation, and resource allocation.

In this section, we show how to estimate path loss using the two propagation models available in the Analytics Toolbox: Close In and Extended Hata. These models take the line-of-sight previously calculated as input.

Note that path loss is usually a part of link calculation, which in conjunction with transmitting power, antenna gains, etc. provide an estimation of the received signal level.

Close In

To estimate path loss using the Close In model, we use the CLOSE_IN procedure that takes as input:

• The query or the fully qualified name of the table containing the Tx-Rx link information. This is the output of the path profile procedure (vector or raster).

• The fully qualified name of the output table.

• Different options regarding frequency in GHz or the scenario (UMa, UMi-S.C., UMi-O.S.).

The code below estimates the path loss for the vector path profile output with a frequency of 2.4 GHz and for a UMi-S.C. scenario:

carto-un

CALL `carto-un`.carto.CLOSE_IN(
   '<my-project>.<my-dataset>.prop_los_vector_london',
   '<my-project>.<my-dataset>.prop_london_closein',
   '{"frequency":2.4, "scenario":"UMi-S.C."}'
);

carto-un-eu

CALL `carto-un-eu`.carto.CLOSE_IN(
   '<my-project>.<my-dataset>.prop_los_vector_london',
   '<my-project>.<my-dataset>.prop_london_closein',
   '{"frequency":2.4, "scenario":"UMi-S.C."}'
);

manual

CALL carto.CLOSE_IN(
   '<my-project>.<my-dataset>.prop_los_vector_london',
   '<my-project>.<my-dataset>.prop_london_closein',
   '{"frequency":2.4, "scenario":"UMi-S.C."}'
);

The resulting table from the CLOSE_IN call is available at cartobq.docs.prop_london_closein.

As a result, the procedure returns a table with all transmitter-receiver pairs and their corresponding path gain in dB as can be seen on the top-map at the end of the guide.

Extended Hata

To estimate path loss using the Extended Hata model, we use the EXTENDED_HATA procedure that takes as input:

• The query or the fully qualified name of the table containing the Tx-Rx link information. This is the output of the path profile procedure (vector or raster).

• The fully qualified name of the output table.

• Options regarding frequency in GHz and the scenario (urban, suburban, or open area).

Note that for the Extended Hata model, the heights of the transmitters and receivers need to be measured relative to the ground. When the terrain height is provided in the path profile procedure, the resulting heights in the output are measured relative to sea level. Therefore, when using terrain height for path profile calculation, it is necessary to adjust the resulting heights back to the original ground-referenced values for accurate path loss estimation.

The code below estimates the path loss for the vector path profile output with readjusted heights for an urban scenario:

carto-un

CALL `carto-un`.carto.EXTENDED_HATA(
   R'''
   SELECT tx_id, rx_id, distance, b.height AS heightTx, c.height AS heightRx
   FROM `<my-project>.<my-dataset>.prop_los_vector_london` a
   JOIN `<my-project>.<my-dataset>.prop_london_tx_locations` b
   ON a.tx_id = b.id
   JOIN `<my-project>.<my-dataset>.prop_london_rx_locations` c
   ON a.rx_id = c.id
''',
   '<my-project>.<my-dataset>.prop_london_extended_hata',
   '{"frequency":2.4, "scenario":"urban"}'
);

carto-un-eu

CALL `carto-un-eu`.carto.EXTENDED_HATA(
   R'''
   SELECT tx_id, rx_id, distance, b.height AS heightTx, c.height AS heightRx
   FROM `<my-project>.<my-dataset>.prop_los_vector_london` a
   JOIN `<my-project>.<my-dataset>.prop_london_tx_locations` b
   ON a.tx_id = b.id
   JOIN `<my-project>.<my-dataset>.prop_london_rx_locations` c
   ON a.rx_id = c.id
''',
   '<my-project>.<my-dataset>.prop_london_extended_hata',
   '{"frequency":2.4, "scenario":"urban"}'
);

manual

CALL carto.EXTENDED_HATA(
   R'''
   SELECT tx_id, rx_id, distance, b.height AS heightTx, c.height AS heightRx
   FROM `<my-project>.<my-dataset>.prop_los_vector_london` a
   JOIN `<my-project>.<my-dataset>.prop_london_tx_locations` b
   ON a.tx_id = b.id
   JOIN `<my-project>.<my-dataset>.prop_london_rx_locations` c
   ON a.rx_id = c.id
''',
   '<my-project>.<my-dataset>.prop_london_extended_hata',
   '{"frequency":2.4, "scenario":"urban"}'
);

The resulting table from the EXTENDED_HATA call is available at cartobq.docs.prop_london_extended_hata.

As a result, the procedure returns a table with all transmitter-receiver pairs and their corresponding path gain in dB as observed on the bottom-map below.