LTE MESH
C2

LTE mesh provides an alternative data link for drone operations in areas with cellular coverage. This page covers modem hardware, failover between ELRS and LTE, and the Fresnel zone differences between ground-based cell links and aerial ELRS relay via Fischer 26 with Starlink onboard.

ELRS vs LTE

MANET 300 MHz (mil-band) is the primary link — it works anywhere, needs no infrastructure, hops frequencies to resist jamming, and has been field-tested extensively. But it has limited bandwidth: enough for telemetry and detection packets, not enough for live video streaming.

LTE (4G/5G) is the secondary link — higher bandwidth (video stream possible), lower latency (30-80ms vs ELRS 7ms for telemetry but including Starlink relay adds 40ms to ELRS path), but requires cell towers. In urban environments (cities, military bases near populated areas), cell coverage is available. In rural Norrbotten or behind enemy lines, it's not.

Both links transmit detection packets simultaneously. Lisa 26 de-duplicates at the fusion layer. If ELRS drops (range, terrain, jamming), the LTE link continues automatically. If LTE drops (no coverage, tower destroyed), ELRS continues. The drone never loses contact as long as either link works.

Hardware

Open the interactive Mission Planner →

Open the interactive Link Budget Calculator →

Sources

Parameter sources. Quectel RM500Q-GL specifications (M.2 form factor, 5G/4G/LTE) — manufacturer datasheet at quectel.com. Waveshare SIM8262E-M2 HAT parameters — Waveshare documentation. Silvus StreamCaster parameters (140–600 MHz, up to 40 Mbps, <45 ms latency, AES-256 encryption, 559-node testing) — Silvus Technologies published data. AES-256 + FIPS 140-3 Level 2 — Silvus certification.

Operational estimates — not validated by FSG-A field testing. Mesh reconvergence time 5–30 seconds is Silvus published data, not verified by FSG-A on real hardware. 30-second convergence for 20 nodes is a published value. The "80% capacity threshold" for sub-mesh splitting is a Lisa 26 design choice, not operationally calibrated. 40 ms additional latency via Starlink relay is an estimate, not measured by FSG-A. €125 + €10/month per drone is an FSG-A 2024–2025 internal procurement estimate.

Supply chain risk. Silvus Technologies is US-based and ITAR-controlled. This is established by official US government classification, not an FSG-A assumption. 2–4 week lead time is Silvus' normal commercial standard. The strategic-stockpile recommendation is FSG-A opinion, not a formal procurement requirement.

External standards and references. Quectel RM500Q-GL datasheet (quectel.com). Waveshare Jetson carrier board documentation. ArduPilot cellular telemetry guide (ardupilot.org). Lisa 26 dual-link failover architecture (FSG-A internal, 2025). FSG-A has not tested LTE integration on drones — the configuration is conceptual, though the hardware is commercially available.

MANET Self-Organization

Silvus StreamCaster radios form an ad-hoc mesh network without infrastructure. Each radio discovers neighbors through beacon frames broadcast every second on the configured frequency. When two radios hear each other, they establish a bidirectional link and exchange routing tables. Within 30 seconds of power-on, a network of 20 nodes converges to a stable routing topology where every node can reach every other node through the optimal multi-hop path. No configuration server, no IP address assignment, no manual routing — the network self-organizes.

If a node is destroyed or moves out of range, the mesh reconverges in 5-30 seconds. Neighboring nodes detect the lost link, remove it from their routing tables, and calculate alternative paths. Traffic that was flowing through the lost node automatically reroutes through surviving nodes with higher hop count but maintained connectivity. This resilience is the fundamental advantage over point-to-point radio — losing one relay in a star topology kills all traffic through that relay, but losing one node in a mesh only degrades throughput.

Bandwidth Management at Scale

Scaling beyond 50 drones requires either wider bandwidth allocation (10 MHz channel width doubles capacity to 20 Mbps) or frequency segmentation. Lisa 26 manages segmentation automatically: if battalion mesh approaches 80 percent capacity, it recommends splitting into company-level sub-meshes with Fischer 26 acting as gateway. Each sub-mesh operates on a different center frequency within 140-600 MHz. QoS prioritization ensures command messages are never delayed by video — if saturation occurs, video streams reduce quality while command traffic maintains full priority.

Mesh Resilience Under Attack

If an enemy destroys a MANET node (direct hit on antenna, vehicle destroyed), the mesh reconverges around the lost node within 5-30 seconds. During reconvergence, traffic destined for or through the lost node is rerouted via alternative paths. If the lost node was a critical relay (the only path between two sub-networks), connectivity is interrupted until an alternative relay is established — Fischer 26 can reposition to fill the gap, or a ground vehicle with MANET capability can move to bridge the disconnected segments. Lisa 26 monitors mesh health continuously and alerts when node loss creates connectivity gaps, recommending specific relay repositioning to restore full coverage.

Try the interactive Link Budget Calculator →

Implementation

# Silvus StreamCaster MANET Configuration
# Applied via silvus-cli on each node at deployment

# Basic MANET parameters
silvus-cli set frequency 300          # MHz (center)
silvus-cli set bandwidth 5            # MHz  
silvus-cli set tx-power 33            # dBm (2W)
silvus-cli set modulation OFDM        # Orthogonal FDM
silvus-cli set encryption AES256      # End-to-end
silvus-cli set fhss-mode adaptive     # Skip jammed channels
silvus-cli set mesh-mode ad-hoc       # Self-organizing
silvus-cli set max-retries 3          # Packet retry

# Load encryption key (from operator USB)
silvus-cli import-key /dev/shm/keys/manet.key

# Verify mesh connectivity
silvus-cli show neighbors
# Expected: 3-8 neighbors per node in brigade deployment
silvus-cli show routes
# Expected: all nodes reachable within 5-7 hops

Swedish Supply Chain

MANET Mesh Architecture

Silvus StreamCaster creates a self-forming, self-healing mesh network. Every node (drone, vehicle, ground station) acts as both endpoint and relay. If one node goes down, traffic automatically routes through other nodes. Tested: 559-node network with 100% visibility within 30 seconds (Silvus demonstration, published data). For Lisa 26: a typical deployment uses 5-20 nodes (3-10 drones + ground stations + vehicles). The mesh handles this effortlessly.

Link Capacity Derivation

Why 40 Mbps matters. Four HD video streams at 1080p30 with H.265 compression run about 5-8 Mbps each — so a full brigade MANET needs approximately 30-40 Mbps peak aggregate capacity to carry four simultaneous Fischer 26 video feeds plus telemetry, control, and JC3IEDM track updates. The Shannon-Hartley theorem bounds channel capacity C in a bandwidth B at SNR:

C = B · log2(1 + SNR)

For Silvus SL5200 operating at 5 MHz bandwidth with typical MANET SNR of 20 dB (power ratio 100):

C = 5e6 · log2(1 + 100) = 5e6 · 6.66 ≈ 33.3 Mbps

Expanding to 20 MHz bandwidth at the same SNR yields 133 Mbps theoretical — well above the 40 Mbps observed limit. The gap between theory and observation comes from MAC-layer overhead, interference between mesh nodes sharing spectrum, and the cost of forwarding packets through multiple hops. The 40 Mbps figure is therefore a realistic end-user throughput, not a link-layer maximum.

Hop Latency Calculation

Why multi-hop paths still hit the 45 ms target. Each hop adds processing delay (queuing + radio access + transmission + propagation). A realistic per-hop budget:

t_hop = t_queue + t_tx + t_rf + t_proc = 2 + 3 + 0.03 + 2 = 7 ms

This is why the deployment guidance caps routable path depth at approximately 6 hops: beyond that, latency exceeds what Lisa 26's L2 decision loop can tolerate without noticeable operator lag. Validated in provable_claims.py under MANET_HOP_LATENCY.

Multi-Hop Throughput Model

The second code block estimates effective throughput on a multi-hop route, accounting for the fact that nodes sharing spectrum must take turns transmitting. In a linear chain of n hops on a single channel, effective throughput falls as 1/n because the same radios alternately transmit and forward.

def manet_effective_throughput_mbps(
        link_capacity_mbps: float,
        hop_count: int,
        channel_reuse_distance: int = 3) -> float:
    """
    Effective throughput on a multi-hop MANET path.

    Nodes within the channel_reuse_distance cannot transmit simultaneously
    on the same channel. A well-routed mesh can reuse spectrum beyond that
    distance, but within a 3-hop window, each hop halves effective bandwidth.
    """
    if hop_count <= 0:
        return link_capacity_mbps
    contending_hops = min(hop_count, channel_reuse_distance)
    return link_capacity_mbps / contending_hops

def brigade_video_budget(drones: int, stream_mbps: float = 6.0) -> dict:
    """How many simultaneous HD video streams fit in a 40 Mbps MANET?"""
    aggregate = drones * stream_mbps
    overhead = 0.3 * aggregate  # 30% for telemetry, control, JC3IEDM
    total_required = aggregate + overhead
    return {
        "aggregate_video_mbps": aggregate,
        "overhead_mbps": overhead,
        "total_required_mbps": total_required,
        "fits_in_40mbps_mesh": total_required <= 40.0,
    }

if __name__ == "__main__":
    # Single-hop baseline
    print(f"Single hop capacity: {manet_effective_throughput_mbps(40, 1):.1f} Mbps")
    # 6-hop chain (typical brigade worst case)
    print(f"6-hop worst case:    {manet_effective_throughput_mbps(40, 6):.1f} Mbps")

    for drones in (2, 4, 6, 8):
        b = brigade_video_budget(drones)
        status = "✓ OK" if b["fits_in_40mbps_mesh"] else "✗ OVERSUBSCRIBED"
        print(f"{drones} drones: {b['total_required_mbps']:.1f} Mbps needed  {status}")
    # Proof reference: provable_claims.py::MANET_VIDEO_CAPACITY_4DRONES

Why the Mesh Beats Point-to-Point

Topology economics. A point-to-point architecture requires a direct radio link from every drone to a ground station. For a brigade with 10 Fischer 26 airframes, that is 10 parallel radios at the ground station plus 10 dedicated frequencies — spectrum congestion, interference, and hardware cost all scale linearly. A mesh with the same 10 drones needs only enough ground-station radios to anchor the mesh (typically 2-3 for redundancy) because drones relay through each other. The mesh also survives ground-station loss: when the primary ground station goes down, the mesh self-reconfigures around the remaining nodes in under 30 seconds. A point-to-point architecture cannot do this — every drone is orphaned the moment its dedicated ground radio fails. This is why Försvarsmakten's drone C2 architecture must assume a mesh baseline; point-to-point is a fragility pattern that will not survive contact with an electromagnetic-warfare environment.

MANET Mesh Parameters

Related Chapters