> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/usecases-workflows/mining/rajant-mesh-backhaul.md).
# Rajant Mesh Backhaul
## Overview
Most open-pit mines already run a Rajant Kinetic Mesh. BreadCrumb nodes on haul trucks, shovels, drills and light plants form a peer network that moves with the operation, and the autonomous haulage systems are validated on it. A private network has to work alongside the mesh rather than replace it.
The mesh's limit is hop count. InstaMesh routes over half-duplex unlicensed radios, so every hop adds latency and roughly halves the throughput that remains, and reaching the pit bottom from the ROM pad can take five to eight of them. The 2.4 and 5.8 GHz bands are crowded as well, with drills, dozers and everything else unlicensed on site.
A private LTE cell on a crest or a ROM-pad mast covers kilometers of pit in a single RF hop, on spectrum the mine licenses and controls. Attaching BreadCrumbs to that cell gives InstaMesh a second route to choose from. The mesh still handles the last hop to moving equipment, and the cellular link carries the traffic behind it. Rajant sells a module built for this.
***
## How It Works
The mesh keeps the last hop. The LTE path is an additional route InstaMesh can choose, not a replacement for the RF links.
### What each component does
| Component | Role in this workflow |
| ------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **BreadCrumb node** | The mesh radio on a truck, shovel, drill or light plant. Peers with every other node in range |
| **InstaMesh** | Rajant's routing protocol. Scores every available link and selects a path per packet |
| **Cellular attachment** | An LTE Enhance module, a Peregrine BreadCrumb with the modem built in, or a GXC CPE on the node's Ethernet port |
| **Onyx AP** | The cell, sited for reach across the pit rather than for capacity at a point |
| **Onyx Edge** | Terminates the session and bridges it, so mesh nodes stay in one Layer 2 domain |
| **APN on a VLAN** | The mesh transport network, carried without NAT so nodes remain directly addressable |
| **Local breakout** | Keeps mesh traffic on the mine network, never leaving site |
| **Onyx Portal** | Per-node attachment, session state and link quality, alongside the mesh's own view |
| **AHS and fleet systems** | The dispatch, autonomy and telemetry platforms the mesh was built to carry |
### The path, hop by hop
| # | From → To | Interface | What happens |
| - | --------------------------------- | -------------------------- | ---------------------------------------------------------------- |
| 1 | Truck BreadCrumb → neighbor nodes | unlicensed RF | The local mesh forms as it always has. Nothing changes here |
| 2 | BreadCrumb → cellular attachment | Ethernet | The node sees an ordinary wired peer link |
| 3 | Attachment → Onyx AP | **LTE Uu**, uplink-leaning | One RF hop, on licensed spectrum, replacing several mesh hops |
| 4 | Onyx AP → Onyx Edge | backhaul | Standard IP transport from the cell |
| 5 | Onyx Edge → VLAN | **bridge, no NAT** | Nodes land in one broadcast domain, which is what lets them peer |
| 6 | VLAN → the far BreadCrumb | the same path back | InstaMesh now sees a link it can score |
| 7 | InstaMesh → path selection | continuous | Per packet, the cheapest route wins, cellular or RF |
### Where the time goes
| Stage | Typical |
| ------------------------------------------------ | ------------------------------ |
| BreadCrumb to cellular attachment, over Ethernet | < 1 ms |
| Attachment to Onyx Edge, over the air | 10 to 20 ms |
| Bridge and VLAN forwarding | 1 to 3 ms |
| Return leg to the far node | 10 to 20 ms |
| **Equivalent mesh path, five to eight RF hops** | **40 to 120 ms, and variable** |
The cellular route usually wins on both latency and consistency. The consistency is the part that matters, for the reason below.
### InstaMesh decides whether to use the link, and it judges consistency
Most workflows are sized by throughput. This one is sized by how stable the link looks to somebody else's routing algorithm.
InstaMesh continuously scores every link it can see and chooses a path per packet. The cellular route is not privileged. It competes with the RF links on observed quality, and a bearer with excellent peak throughput but variable latency gets scored down and routed around. The capacity is installed, paid for, and unused, and nothing in the mesh reports a fault because the mesh is working exactly as designed.
So the bearer is engineered for predictable latency rather than peak rate. A reserved GBR bearer with a firm delay budget will be used. A best-effort bearer that is fast when the pit is quiet and slow at shift change will be used only when the pit is quiet, which is when it was needed least.
The same property makes failure graceful. Rajant's make-make-never-break behavior means the cellular link joins the link set rather than replacing it. If the cell drops, the RF mesh carries on at its old hop count. If RF degrades behind a highwall, the cellular route absorbs it. Neither side needs to detect the other's failure, because InstaMesh was already measuring both.
***
## Network Requirements
| | |
| ----------------------------- | --------------------------------------------------------------------- |
| Per-node sustained rate | 10 to 50 Mbps, uplink-leaning |
| Aggregate per cell | sized on the number of attached nodes, not on peak demand |
| One-way latency, node to Edge | **< 30 ms** |
| **Jitter** | **< 10 ms, the figure that decides whether the link is used** |
| Packet loss | < 0.1% |
| Availability | 99.9% during production shifts |
| Mesh transport QoS | **reserved GBR bearer**, LTE QCI 3 or 5G 5QI 83 as the starting point |
| Bulk and update traffic | non-GBR, scheduled outside shift change |
| Networking mode | **Bridge, APN on VLAN.** NAT breaks node-to-node peering |
{% hint style="info" %}
**Read the jitter row, not the throughput row.** Throughput determines what the link could carry. Jitter determines whether InstaMesh offers it any traffic at all.
{% endhint %}
***
## Deploying It
{% stepper %}
{% step %}
### Map the existing mesh first
Record the current hop count from the deepest working face to the core, and the throughput available at the far end. That number is the benchmark. Without it there is no way to show what the cellular route bought.
{% endstep %}
{% step %}
### Site cells for reach, not for capacity
Pit cells go high: crest positions, ROM-pad masts, existing comms towers. The design goal is line of sight into the pit across the longest span, not throughput at a point.
{% endstep %}
{% step %}
### Choose the attachment per node class
Fixed and semi-mobile nodes take a CPE on the Ethernet port. Mobile plant is usually better served by an LTE Enhance module or a Peregrine node, which survive the vibration and dust without a separate enclosure.
{% endstep %}
{% step %}
### Configure Bridge mode before anything else
Put the mesh transport on its own APN mapped to a VLAN, bridged without NAT. Mesh nodes have to be directly addressable to peer. Confirm this on two nodes before scaling, because retrofitting it later means re-provisioning every SIM.
{% endstep %}
{% step %}
### Reserve the bearer
Put mesh transport on a GBR bearer with a delay budget, separate from bulk traffic. Schedule firmware and map updates outside production shifts.
{% endstep %}
{% step %}
### Check MTU end to end
Any encapsulation between the node and the Edge reduces the usable MTU, and fragmentation degrades mesh throughput more than the lost bytes suggest. Measure the path MTU rather than assuming it.
{% endstep %}
{% step %}
### Verify InstaMesh is choosing the route
Confirm in Rajant's own tools that traffic moves to the cellular path under load. A link that exists but is never selected is the failure mode for this design, and it is silent.
{% endstep %}
{% step %}
### Re-measure the hop count
Repeat the first measurement. The deliverable is a shorter path from the working face to the core, with throughput and latency to prove it.
{% endstep %}
{% endstepper %}
***
## Devices & Ecosystem
* **Rajant LTE Enhance**: the purpose-built integration module, attached to an existing BreadCrumb. Designed for the vibration, dust and temperature range of mobile mining plant.
* **Rajant Peregrine**: a BreadCrumb with the cellular modem integrated, where one box is preferable to two.
* **GXC CPE**: a cellular unit on the BreadCrumb's Ethernet port, for fixed and semi-mobile positions.
* **BreadCrumb nodes**: the existing mesh estate, unchanged.
* **Autonomous haulage and fleet management**: the dispatch and autonomy platforms carried over the combined network.
* **Drill and shovel automation, teleremote**: the other mesh-borne workloads that benefit from a shorter path.
* **Onyx Edge**: hosting the mine-side applications that the mesh reaches.
***
## Design Considerations
**Bridge mode is a prerequisite, not a preference.** Mesh nodes peer at Layer 2. Behind NAT they are not directly addressable and InstaMesh cannot form the link, so the whole design fails at the first node pair. Settle the networking mode before the SIM order.
**Broadcast and multicast cross the bearer too.** A Layer 2 mesh floods, and autonomous haulage traffic is frequently multicast. Every flooded frame crosses the cellular link and reaches every node on the VLAN. Scope the broadcast domain deliberately rather than putting the entire mesh estate on one VLAN.
**Two nodes on one cell hairpin.** Traffic from one BreadCrumb to another on the same cell travels up to the Onyx Edge and back. Local breakout keeps it on site, but it is still a longer path than the direct RF hop those nodes may already have. The cellular route earns its place between distant nodes, not adjacent ones.
**Fault attribution crosses a vendor boundary.** When a truck stops, the question is whether the mesh, the cellular link or the autonomy stack caused it. Correlate Onyx Portal session records with Rajant's link history on a common clock, and agree who looks first before the first incident rather than during it.
**The pit changes shape and the cells do not.** Mesh nodes move with the operation by design. A cell on a crest position may be overlooking a different pit profile in six months. Review cell siting against the mine plan, not just against today's survey.
**LTE today does not foreclose 5G.** The architecture is unchanged by the generation: a bridged bearer presenting a link InstaMesh can score. Moving to 5G raises throughput and tightens the delay budget without altering the design.
***
## Validation Checklist
* [ ] Baseline hop count and far-end throughput recorded before any cellular attachment
* [ ] Bridge mode confirmed on two nodes, with node-to-node peering proven across the bearer
* [ ] Path MTU measured end to end, with no fragmentation under load
* [ ] Mesh transport on a reserved GBR bearer, separate from bulk traffic
* [ ] Jitter measured at the working face during shift change, not at rest
* [ ] InstaMesh confirmed to select the cellular route under load, in Rajant's own tooling
* [ ] Failover tested both ways: cell down with RF carrying, RF degraded with the cell carrying
* [ ] Broadcast domain scoped, with flooded traffic volume measured across the bearer
* [ ] Coverage verified at the deepest working face and behind the highwall
* [ ] Hop count re-measured and the improvement documented
* [ ] Portal and Rajant link records correlated on a common clock
***
## Next steps
* **Size it.** Take these requirements through [Plan Your Network](https://docs.gxc.io/plan-your-network): capacity, coverage, architecture, and a preliminary bill of materials.
* **Compare it.** [Network Requirements at a Glance](https://docs.gxc.io/usecases-workflows/network-requirements-at-a-glance) puts every workflow side by side, for sites carrying more than one.
* **Talk to us.** For a validated design and a quote, [contact GXC](https://gxc.io/contact-us/).
## Related reading
* [4G & 5G Onyx Networking Modes](https://docs.gxc.io/docs/application-notes/4g-and-5g-onyx-networking-modes) : NAT and Bridge modes, and how an APN maps to a VLAN
* [AGV and AMR Fleet Control](/usecases-workflows/manufacturing/agv-and-amr-fleet-control.md) : closed-loop vehicle control on a private network indoors
* [Network Requirements at a Glance](/usecases-workflows/network-requirements-at-a-glance.md) : all workflows side by side
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.gxc.io/usecases-workflows/mining/rajant-mesh-backhaul.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
