Ericsson ISAC vs Radar: Which Gives Better Drone Detection

TL;DR: Ericsson's Integrated Sensing and Communication (ISAC) can detect low‑altitude drones using existing 4G/5G infrastructure, but traditional radar still outperforms it in range and raw accuracy. For most developers the sensible path is to treat ISAC as a complementary layer that fills urban blind‑spots while retaining radar (or another high‑precision sensor) for perimeter and high‑value‑asset protection.

Introduction: The Growing Pressure on Drone Security

The last decade has seen a dramatic democratisation of unmanned aerial systems. Off‑the‑shelf quadcopters that cost less than £150 can now carry payloads, stream video, and hover for minutes on end. Their small size, low radar cross‑section (RCS), and ability to fly below 150 m have turned civilian airspace into a high‑frequency, low‑altitude threat landscape.

Recent incidents illustrate the urgency:

• ✔️Jersey Airport (June 2024) – A hobbyist drone entered the runway protection zone, forcing a temporary shutdown of all commercial flights.
• ✔️UK Ministry of Defence sites (July 2024) – Multiple drone sightings triggered the activation of the Defence‑wide Counter‑UAV (C‑UAV) system, exposing gaps in existing radar coverage.
• ✔️Urban festivals in Germany (August 2024) – Drone‑borne payloads were used for illicit filming, prompting local police to request “real‑time” detection capabilities.

Regulators (e.g., EASA, FAA) now require real‑time detection and mitigation for any airspace where people or critical infrastructure are present. Traditional radar, the workhorse of aviation surveillance for over half a century, offers long‑range coverage but struggles with low‑elevation, line‑of‑sight flight paths that hobbyist drones exploit.

Enter Ericsson’s Integrated Sensing and Communication (ISAC) – a technology that re‑uses the existing LTE/5G radio access network (RAN) as a passive radar. By embedding known reference signals into the downlink and analysing the reflected echoes, ISAC can spot objects as small as a few centimeters, provided the signal‑to‑noise ratio (SNR) is adequate.

The core question for developers, system integrators, and municipal planners is whether ISAC can replace radar, augment it, or simply act as a stop‑gap until more mature sensing stacks (e.g., 6G‑enabled ISAC) become available. The following sections unpack the technical underpinnings, compare performance metrics, and outline concrete implementation pathways.

1. Radar Fundamentals – Why It Has Been the Gold Standard

1.1 Physical Principles

Traditional radar systems emit high‑power microwave bursts (or continuous frequency‑modulated waves in FMCW radars) and listen for the reflected energy. The key equations governing detection are:

• ✔️Radar Range Equation

$$ Pr = \frac{Pt Gt Gr \lambda^2 \sigma}{(4\pi)^3 R^4 L} $$

• ✔️Doppler Shift

$$ f_D = \frac{2v}{\lambda} $$

These physics give radar predictable scaling: doubling transmitted power or antenna aperture roughly doubles detection range, while higher carrier frequencies improve angular resolution but reduce penetration through foliage.

1.2 Typical Deployments

Note: Costs include antenna, tower, site acquisition, licensing, and integration; they do not cover ongoing OPEX such as spectrum fees and maintenance contracts.

1.3 Strengths and Weaknesses

2. Ericsson ISAC – Turning the Cellular Network into a Sensor

2.1 Core Concept

ISAC piggy‑backs on the existing LTE/5G RAN. The base station (gNB) already transmits reference signals (e.g., Cell‑Specific Reference Signals, DMRS) for channel estimation. By modulating these signals with known patterns and listening to the same antenna array for reflected copies, the RAN can extract:

• ✔️Range (via time‑of‑flight or phase‑difference across sub‑carriers)
• ✔️Velocity (via Doppler shift)
• ✔️Angle of Arrival (via beamforming on the massive MIMO array)

Because the same hardware is used for both communication and sensing, the incremental cost is limited to software upgrades and modest additional RF front‑end calibration.

2.2 Architectural Overview

+-------------------+       +-------------------+       +-------------------+
|  LTE/5G Core      | <---> |  Base Station (gNB) | <---> |  Antenna Array    |
|  (EPC/5GC)        |       |  ISAC Processing   |       |  (MIMO)           |
^                         ^                         ^
|                         |                         |
|   ISAC Event API (gRPC/WebSocket)                |
+---------------------------------------------------+

- **ISAC Processing Block** lives inside the gNB’s baseband unit. It extracts **I/Q samples**, performs **matched filtering** against the known reference, and outputs **detection events**.

- **Event API**: Typically a **gRPC streaming service** or **WebSocket** that pushes JSON‑encoded detection objects to subscribed clients.

- **Optional Raw I/Q Stream**: For research or high‑resolution processing, the gNB can expose a **binary I/Q stream** (e.g., 16‑bit complex samples at 30 Msps) over a dedicated UDP channel.

2.3 Detection Workflow

1. Transmit a known reference waveform (e.g., a Zadoff‑Chu sequence) on a reserved sub‑carrier block.
2. Receive the superposition of the direct downlink, reflections from static objects, and reflections from moving objects (drones, birds, vehicles).
3. Correlate the received signal with the transmitted reference to obtain a range‑Doppler map.
4. Apply CFAR to suppress clutter and generate candidate detections.
5. Classify candidates using a lightweight ML model (e.g., a decision tree on Doppler‑SNR features).
6. Publish events with fields: timestamp, lat, lon, alt, velocity, confidence, type.

2.4 Sample API Payload

{
  "id": "evt-20241103-00123",
  "timestamp": "2024-11-03T12:34:56.789Z",
  "type": "drone",
  "lat": 51.5074,
  "lon": -0.1278,
  "alt": 78.3,
  "velocity": 5.2,
  "confidence": 0.87,
  "source": {
    "cellId": "310-260-01",
    "sector": "A",
    "frequencyMHz": 3500
  }
}

Key points for developers

• ✔️confidence is a normalized score (0 – 1) derived from the classifier’s softmax output.
• ✔️source provides traceability back to the originating base‑station, useful for triangulation when multiple cells detect the same object.
• ✔️alt is derived from the range estimate combined with the known base‑station height; it is less precise than radar altitude.

3. Comparative Analysis – Range, Accuracy, Latency, and Overheads

3.1 Why Range Differs So Much

Radar transmits kilowatts to megawatts of peak power, whereas a 4G/5G base station typically transmits ≤ 5 W per sector. The radar range equation shows that received power falls with \(R^4\); a 1000× reduction in transmit power translates to roughly a 10× reduction in detection range.

Additionally, radar antennas are purpose‑built with high gain (30–40 dBi), while cellular antennas are designed for omnidirectional coverage and have lower gain (≈ 15 dBi per panel). The combination of lower power and lower gain explains the limited ISAC range.

3.2 Accuracy Trade‑offs

• ✔️Range error in ISAC is dominated by sampling resolution of the reference signal (typically 15 kHz sub‑carrier spacing) and the clock jitter of the baseband.
• ✔️Angular error stems from the sector beamwidth; a typical macro cell covers 120° in azimuth, so the system can only localise an object to within that sector unless multi‑cell triangulation is performed.
• ✔️Radar, by contrast, can use digital beamforming across hundreds of elements, delivering sub‑degree azimuth.

3.3 Operational Overheads

• ✔️Radar requires site acquisition, tower construction, high‑power amplifiers, licensed spectrum, and specialist staff for calibration and maintenance.
• ✔️ISAC needs only a software upgrade on the gNB, calibration of the antenna array for sensing, and API integration on the client side. The major OPEX factor is the service‑level agreement (SLA) with the mobile operator—latency guarantees, data‑retention policies, and per‑cell pricing.

3.4 Summary of Trade‑off Matrix

4. Practical Implementation Guide – From Raw I/Q to Actionable Alerts

Below is a step‑by‑step blueprint for developers who want to build a drone‑detection service on top of Ericsson ISAC. The guide assumes you have a subscription with an MNO that exposes the ISAC API.

4.1 Architecture Overview

+-------------------+ +-------------------+ +-------------------+

v v v

1. Ingress Layer – Connect to the MNO’s WebSocket/gRPC endpoint.
2. Stream Processor – Use a fault‑tolerant framework (Apache Flink, Kafka Streams, or Spark Structured Streaming) to window events (e.g., 1‑second tumbling windows) and deduplicate detections that appear in adjacent cells.
3. Enrichment Layer – Join with GIS data: no‑fly zones, building footprints, and weather data (rain can affect SNR).
4. Classification Engine – Run a lightweight ML model (e.g., XGBoost or TensorFlow Lite) that refines the raw confidence score into a risk score.
5. Alert Engine – When the risk score exceeds a configurable threshold, publish to an MQTT topic, a webhook, or a push‑notification service.
6. Actuation – Edge‑deployed counter‑UAVs, RF jammers, or law‑enforcement dashboards subscribe to the alert channel.

4.2 Sample Ingress – Node.js WebSocket Client

const WebSocket = require('ws');
const kafkaProducer = require('kafka-node-producer'); // placeholder

const url = 'wss://isac.mno.example.com/stream?region=EU';
const ws = new WebSocket(url);

ws.on('open', () => console.log('Connected to ISAC stream'));

ws.on('message', (data) => {
  const evt = JSON.parse(data);
  // Basic filter – only forward high‑confidence drone events
  if (evt.type === 'drone' && evt.confidence >= 0.75) {
    // Push to Kafka (or any message bus)
    kafkaProducer.send({
      topic: 'isac.detections',
      messages: [{ value: JSON.stringify(evt) }]
    });
  }
});

ws.on('error', (err) => console.error('ISAC stream error', err));

ws.on('close', () => console.warn('ISAC stream closed – reconnecting...'));

Key considerations

• ✔️Back‑pressure handling – The WebSocket may burst during high‑traffic periods; implement a buffering queue or use a reactive library (RxJS) to throttle.
• ✔️Authentication – Most MNOs require mutual TLS and an API token; store credentials securely (e.g., HashiCorp Vault).
• ✔️Geofencing – Apply a client‑side bounding box filter to discard events outside your area of interest before they hit your processing cluster.

4.3 Stream Processing – Flink Example (Java)

DataStream<String> raw = env
  .addSource(new KafkaSource<>("isac.detections"))
  .name("Kafka ISAC Source");

DataStream<Detection> parsed = raw
  .map(json -> new ObjectMapper().readValue(json, Detection.class))
  .name("Parse JSON");

DataStream<Detection> deduped = parsed
  .keyBy(d -> d.getId())
  .window(TumblingProcessingTimeWindows.of(Time.seconds(1)))
  .reduce((d1, d2) -> d1.getConfidence() > d2.getConfidence() ? d1 : d2)
  .name("Deduplicate & Keep Best");

deduped
  .addSink(new MqttSink<>("tcp://broker.local:1883", "drone/alerts"))
  .name("Publish Alerts");

• ✔️Window size: 1 second balances latency and false‑positive reduction.
• ✔️KeyBy on id ensures that duplicate detections from overlapping cells are collapsed.
• ✔️Reduce keeps the detection with the highest confidence, assuming the same object will generate multiple events with slightly different timestamps.

4.4 Classification – TensorFlow Lite (Python)

import tensorflow as tf
import numpy as np

# Load a pre‑trained lightweight model (≈ 30 KB)

interpreter = tf.lite.Interpreter(model_path="drone_classifier.tflite")
interpreter.allocate_tensors()

input_idx = interpreter.get_input_details()[0]["index"]
output_idx = interpreter.get_output_details()[0]["index"]

def classify(event):
    # Feature vector: [doppler_hz, snr_db, range_m, azimuth_deg]
    features = np.array([[event["doppler"], event["snr"],
                          event["range"], event["azimuth"]]], dtype=np.float32)
    interpreter.set_tensor(input_idx, features)
    interpreter.invoke()
    prob = interpreter.get_tensor(output_idx)[0][0]  # probability of "drone"
    return prob > 0.85   # 85 % confidence threshold

Model training tips

• ✔️Dataset: Use a mix of synthetic reflections (ray‑tracing) and field‑collected ISAC logs.
• ✔️Features: Doppler shift, SNR, range, and azimuth, plus optional spectral kurtosis (helps separate birds from drones).
• ✔️Class imbalance: Drones are rare; apply SMOTE or focal loss to avoid bias toward the majority “no‑drone” class.

4.5 Alert Dispatch – MQTT Example

# mqtt.yaml – configuration for the alert broker

broker: tcp://mqtt.city.gov:1883
topic: city/drone/alerts
qos: 1
retain: false

# Example subscriber (edge counter‑UAV)

mosquitto_sub -h mqtt.city.gov -t city/drone/alerts -v

The alert payload can be the original detection JSON plus an additional risk score:

{
  "riskScore": 0.92,
  "source": { "cellId": "310-260-01", "sector": "A" }
}

4.6 End‑to‑End Latency Budget

If your use‑case requires sub‑100 ms (e.g., autonomous counter‑UAV interception), you must push processing to the edge – for instance, run the classifier directly on the base‑station’s edge compute node (e.g., a small x86 or ARM server co‑located with the gNB). This reduces network hops but requires a service‑level agreement (SLA) that permits third‑party workloads on the MNO’s edge infrastructure.

5. Trade‑offs in Real‑World Deployments

5.1 Urban vs Rural Environments

• ✔️Urban Canyons – Multipath reflections from glass façades increase the false‑positive rate for ISAC. Mitigation: increase the CFAR guard cells, use machine‑learning‑based clutter models, and fuse with visual analytics (CCTV).
• ✔️Rural Open Areas – ISAC range can approach 6–8 km due to fewer obstructions, but terrain masking (hills, trees) still creates blind spots. Radar remains the only reliable solution for wide‑area perimeter monitoring.

5.2 Spectrum and Regulation

• ✔️ISAC uses licensed mobile spectrum (e.g., 3.5 GHz, 2.6 GHz). Operators already have exclusive rights, so there is no extra licensing cost for the sensing function.
• ✔️Radar often occupies dedicated bands (X‑band, S‑band) that require national frequency allocation and may be subject to export controls.
• ✔️Regulatory trend: The European Commission’s 2025 Radio Spectrum Policy encourages dual‑use of mobile bands for sensing, but mandates that sensing must not degrade QoS for communication services. Developers should therefore monitor the MNO’s QoS metrics (e.g., PRB utilization) to ensure that heavy ISAC processing does not impact user traffic.

5.3 Power Consumption and Environmental Impact

• ✔️Radar: High‑power amplifiers (kW‑MW) consume significant electricity and generate heat, requiring active cooling.
• ✔️ISAC: Adds only a few watts of DSP load on the base‑station’s edge compute; the incremental power draw is negligible compared with the base station’s normal transmit power (≈ 30 W per sector).

From a sustainability perspective, ISAC offers a lower carbon footprint, especially when the same hardware serves both communication and sensing.

5.4 Maintenance and Upgradability

6. Designing a Sensor‑Fusion Framework

Given that no single sensor satisfies all requirements, the most robust architecture fuses multiple modalities:

1. Primary Layer – Long‑range radar (X‑band) covering the outer perimeter (≥ 30 km).
2. Secondary Layer – ISAC covering the urban core and low‑altitude corridors.
3. Tertiary Layer – Acoustic arrays (micro‑phoned clusters) and computer‑vision (high‑resolution PTZ cameras).

6.1 Fusion Strategies

Implementation tip: Use an open‑source data‑fusion library such as RTKLIB for Kalman‑filter based track fusion, or Apache Beam for a unified streaming pipeline that can ingest radar, ISAC, and video detections concurrently.

6.2 Time Synchronisation

Accurate fusion demands sub‑millisecond timestamp alignment. Recommended approaches:

• ✔️Precision Time Protocol (PTP, IEEE 1588) across the edge compute nodes (gNB, radar processing server, acoustic gateway).
• ✔️GPS‑disciplined clocks for radar sites where PTP is impractical.
• ✔️Timestamp embedding in the ISAC event payload (ISO 8601 with nanosecond precision).

6.3 Data‑Retention and Privacy

• ✔️Radar raw IQ is often considered critical infrastructure data and may be subject to national security classification.
• ✔️ISAC raw IQ contains user‑plane information (e.g., channel state) and must be handled according to GDPR and ePrivacy regulations.
• ✔️Best practice: Store only derived detection events for longer than 30 days; purge raw IQ after immediate processing unless a forensic investigation is required.

7. Future Outlook – 6G, Higher Frequencies, and AI‑Enhanced ISAC

7.1 6G‑Enabled Sensing

The 6G research agenda (e.g., ITU‑R M.2410) envisions Terahertz‑band communications (140 GHz – 1 THz) with ultra‑massive MIMO (≥ 1024 elements). This will dramatically improve ISAC capabilities:

• ✔️Higher carrier frequency → smaller wavelength → larger antenna aperture for the same physical size, boosting angular resolution to < 1°.
• ✔️Wider bandwidth (up to several GHz) → finer range resolution (centimeter‑level).
• ✔️Integrated AI accelerators at the edge → on‑device deep‑learning inference for classification within 10 ms.

7.2 Multi‑Static ISAC

Future deployments may coordinate multiple base stations to perform synthetic aperture radar (SAR)‑style imaging of the low‑altitude volume. By sharing raw IQ across a low‑latency backhaul (e.g., fiber or mmWave), the network can achieve coherent multi‑static processing, effectively turning a city’s cellular grid into a distributed radar array.

7.3 Regulatory Evolution

• ✔️The EU’s “Digital Europe Programme” (2024‑2027) includes a sandbox for dual‑use spectrum where operators can trial ISAC without impacting user QoS.
• ✔️In the U.S., the FCC’s “Spectrum Frontiers” docket (2025) is expected to allocate mmWave bands (24 GHz‑28 GHz) for both communication and sensing, paving the way for co‑primary ISAC services.

Developers should design their systems with future‑proof interfaces (e.g., abstract SensingProvider class) so that a 6G‑enabled ISAC source can be swapped in without rewriting the downstream pipeline.

8. Practical Guidance Checklist

• ✔️[ ] Assess Coverage Needs – Map the area, identify low‑elevation blind spots, and decide whether radar, ISAC, or both are required.
• ✔️[ ] Secure MNO Partnership – Negotiate SLAs that guarantee ≤ 300 ms end‑to‑end latency and ≥ 99.5 % event delivery reliability.
• ✔️[ ] Prototype with Real Data – Use the MNO’s sandbox environment to ingest a week of ISAC events; evaluate false‑positive rates against known ground truth (e.g., manual video logs).
• ✔️[ ] Implement Multi‑Sensor Fusion – Start with a weighted probabilistic model; iterate to a track‑to‑track Kalman filter as data volume grows.
• ✔️[ ] Define Alert Thresholds – Calibrate confidence and risk scores per environment (urban vs suburban). Use ROC curves to pick operating points that meet regulatory false‑alarm limits (often < 0.1 % for public safety).
• ✔️[ ] Plan for Edge Deployment – If sub‑100 ms response is needed, provision edge compute at the gNB (e.g., Intel NUC or Nvidia Jetson) and containerise the classification service.
• ✔️[ ] Document Data‑Retention Policies – Align with GDPR, local privacy laws, and any national security classification for radar data.
• ✔️[ ] Future‑Proof Interfaces – Abstract the sensing source behind a REST/gRPC contract that can later accept 6G‑grade ISAC streams or even satellite‑based passive radar data.

Conclusion

Ericsson’s ISAC technology marks a significant shift in how low‑altitude airspace can be monitored. By leveraging the ubiquitous 4G/5G infrastructure, ISAC offers a cost‑effective, rapidly deployable sensor layer that excels at detecting drones flying close to the ground in dense urban environments. However, the physics of cellular transmit power and sector‑wide antenna patterns impose hard limits on range (≈ 5 km) and positional accuracy (≈ 5‑10 m).

Traditional radar, with its high transmit power, narrow beams, and mature processing chain, continues to dominate long‑range, high‑precision surveillance and remains indispensable for critical infrastructure and airport perimeter protection.

The pragmatic path for developers and city planners is to adopt a hybrid architecture:

1. Deploy radar where budget permits and long‑range coverage is mandatory.
2. Overlay ISAC to fill low‑altitude blind spots, especially in city centres where installing radar is impractical.
3. Fuse additional modalities (acoustic, video, LiDAR) to improve classification and reduce false alarms.

By building a modular ingestion pipeline, establishing clear SLAs with mobile operators, and preparing for the 6G‑enabled future, organizations can future‑proof their aerial security stack while keeping CAPEX within realistic limits.

Key Takeaways

• ✔️Complement, don’t replace – Use ISAC to augment radar, not to supplant it.
• ✔️Modular pipelines – Build ingestion → stream processing → classification → alert layers that can ingest any sensor type.
• ✔️Threshold tuning – Urban environments need higher confidence thresholds to curb false positives.
• ✔️Future‑proof – Abstract the sensing interface to accommodate 6G‑grade ISAC and higher‑frequency radar later.

Read Next

• ✔️WordPress Plugin Data Leaks Reveal Broken Capability Checks
• ✔️WP Job Portal XSS vs murgroland Booking System Privilege Issue: Patch Strategies
• ✔️Claude Code Extensions Are a Security Liability Until You Harden Them

Read next: continue with one of these related guides.