Evaluating Underground Connectivity and Monitoring Platforms

Every underground automation pitch assumes a network. The loader needs its commands on time, the proximity system needs to warn the right person, and the gas monitor at the face needs to reach someone who can act. All of that travels over the same cables, radios and access points, through rock and around corners.

So the order matters. Before a mine automates, it should know which jobs the network has to carry, what latency and coverage each job needs at the face, and what keeps working when a link drops. Then it should make every vendor show, on its own headings, that sensor and machine data reach the mine's own systems in a format the mine controls. The automation platform comes after that.

This article is the checklist for that step. It uses a public research programme as the reference point, labels vendor statements as claims, and names no winner. If you are already looking at automation platforms, read it next to our underground automation checklist.

Start with a list of traffic, not a list of products. Underground, the network usually carries some mix of these:

• Machine control and teleremote: commands to automated or remotely operated machines. These need short, steady delays and fail-safe behaviour when the link goes.
• Proximity and collision alerts: warnings between machines and people. A late warning is a failed warning.
• People and asset tracking: where everyone is, for the shift and for an emergency.
• Environmental monitoring: gas, dust, airflow, diesel particulates, noise and smoke.
• Voice: radio calls between crews, the control room and emergency teams.
• Video: cameras on machines, at the face or at orepasses. These need far more bandwidth than sensor readings.
• Production and shift data: task updates, delays and tonnes for short interval control and reporting.

Each line has a different tolerance for delay, a different bandwidth need and a different answer to "what happens if it drops for 30 seconds?". Write those three answers down for every line before you talk to a vendor. A gas reading that arrives a minute late is a nuisance. A collision alert that arrives a second late is not.

The Mandela Mining Precinct in Johannesburg runs a research programme called Real-Time Information Management Systems (RTIMS). Its stated aim is to get "the right information, to the right people, at the right time" in South African mines, using IIoT technology, open-source platforms and standardised frameworks.

RTIMS is useful to a buyer for one reason: it publishes what its projects found, including the parts that did not go to plan. Much of the published work is in hard-rock underground mining, with test sites at operating mines. It also has work streams on data platforms, interoperability and security, which are the questions most buyers get to too late.

Nothing below recommends the companies involved. Treat it as a set of field results you can use to frame your own tests.

From the RTIMS project summaries (Mandela Mining Precinct, read 12 October 2026):

• Wi-Fi 6 in the stope. An in-stope access point developed by the CSIR was tested at Impala Bafokeng's North Shaft (the Maseve test mine). The summary reports up to 10 Mbps throughput and latency under 10 ms at distances up to 100 m, with a low-power Thread mesh covering 150 m at about 20 ms. It also notes "challenges with fibre infrastructure".
• Radio around corners. A stope-face radio system was tested at Glencore's Waterval East mine. It held voice and video around one corner. In the lab, a second 90 degree turn cut the signal completely until a third radio was added as a relay. Underground, the summary notes interference from equipment such as water pumps, and an intermittent link while moving on a chairlift.
• The backbone fails first. A project to broadcast positioning signals over leaky feeder and carry fatigue-monitoring data over a Wi-Fi mesh had its hardware installed, but commissioning was delayed by repeated failures of the fibre backbone it depended on.
• Edge devices that keep working. In a lab demonstration, devices on a disconnected node kept monitoring their local area and rejoined the network when the link came back.
• Private 5G with local processing. A test mine project linked underground 5G access points to edge servers, processed data locally and fed it to SCADA, with proximity detection, wearables and gas, dust, particulate, smoke and noise sensors on the same network.

Treat these numbers as pointers, because your ground will differ. They show where to look: corners, pumps, moving machines and, most of all, the fibre behind the radios.

Independent research says the same. A private 5G trial at an underground salt mine in Sondershausen, Germany, published in 2024, found that conventional radios and radiating cables gave different signal strength, bandwidth and coverage depending on the layout of the drift, and suggested combining both (Emontsbotz and Lottermoser, Mass Mining 2024). In the United States, NIOSH researchers moved monitoring data over an existing leaky feeder system using IP data radios. It worked for low-rate monitoring, at around 28 kbps with pings near 350 ms. It also stalled at first: traffic from the mine's wider network filled the radio link, and readings took more than 10 minutes to arrive until the network switch was reconfigured.

No network type wins everywhere. Each one comes with its own questions.

Private 5G or LTE. Who holds the spectrum licence where you operate? Which devices on your list (machines, tags, sensors) actually have a compatible radio today? Where does the core network run, on site or off site, and what happens underground if the link to it is cut? What does it cost to add a cell as the decline advances?

Wi-Fi 6 and Wi-Fi mesh. How many hops does a reading take from the face to the backbone, and what is the latency after the last hop? How does a machine roam between access points while moving? Who moves the access points after each blast or advance?

Leaky feeder. What data rate does it give you for monitoring, and is that enough for the sensors you plan, not just the ones you have? Is data separated from voice and from the rest of the mine network, so a busy link cannot block alarms?

Proprietary mesh from a system vendor. Will other vendors' devices run on it? If you change that vendor, what happens to the network?

Every option. What runs on battery when power drops, and for how long? What is the plan for the fibre? Who on site can fix it at 2am?

Vendor articles are useful for knowing what is on offer. Read them as claims.

One recent example is an article supplied by IMT (Integrated Mining Technologies) to Mining Weekly on 6 October 2026. In it, IMT says private 5G offers "ultra-low latency", that 5G nodes can be repositioned as tunnels develop, and that data stays within the mine's perimeter on a dedicated network. The article says IMT deploys its M3SH private 5G and sensor system at the Impala Bafokeng test mine as part of the RTIMS framework, with environmental, smoke, silica, dust, air velocity, diesel particulate and noise monitors. It also says the Mandela Mining Precinct is building an open-source, free-to-use data standard so that 5G systems from different vendors can feed shared data platforms.

What to do with that:

• "Ultra-low latency" needs a number behind it. Ask for the measured latency and packet loss at a working face in a mine like yours, on the move and around a corner.
• "Nodes can be repositioned" means someone repositions them. Ask who does it, how long it takes, and what the network looks like while it happens.
• "Data stays on site" is a design choice you can test. Ask where the core, the servers and the dashboards run, and which parts need an internet link.
• If interoperability matters to you, ask the vendor to name the data standard it supports and to show another vendor's device feeding the same platform.

The same applies to every vendor in this space, including the ones listed in the MSR directory.

This is the question that gets asked last and matters longest. A gas reading, a proximity event and a tag location are records your mine may have to produce after an incident. If they live only in a vendor's cloud, in a format only the vendor's software reads, you do not fully hold your own safety record.

The RTIMS data platform work lists "Data ownership not always with the mine" as one of the problems it set out to address. Put these in writing before the devices go in:

• Raw readings, with timestamps and device IDs, can be exported in a documented format at any time, without a support ticket or an extra licence.
• The mine decides how long data is kept, and gets a full copy if the contract ends.
• Devices and gateways publish over open protocols, so a second vendor's dashboard or your own historian can read them.
• Alarm thresholds and the actions they trigger, such as starting a fan or dust suppression, are recorded with who set them and when.

Security belongs in the same conversation. The CSIR, an RTIMS partner, has drafted a security maturity model for connected devices in mining, based on the Industrial Internet Consortium's model. The project summary is clear that it is a draft and not a certification. Ask each vendor how its devices are updated, how they authenticate, and what happens to the rest of the network if one is compromised. Our vendor security article has the wider list.

1. Traffic list. Every job the network carries, with its delay tolerance, bandwidth and dropout behaviour written down.
2. Coverage map. Where coverage must be continuous (haulage routes, automated zones), where it can be patchy, and how it follows the advancing face.
3. Measured performance. Latency, packet loss and throughput measured at the face, around corners and on moving machines, rather than quoted from a datasheet.
4. Backbone and power. The fibre route, redundancy, and what runs on battery for how long.
5. Offline behaviour. What each device and application does when the link drops, and how it catches up when it returns.
6. Interoperability. Which other vendors' machines, tags and sensors run on the network, shown working on site.
7. Data ownership. Export, retention and exit terms in the contract.
8. Security. Device updates, authentication and network separation between safety systems and everything else.
9. Who maintains it. Who moves nodes, replaces sensors and fixes links on night shift, and whether that is in the price.
10. A fair trial. One level, one automated zone or one monitoring circuit, measured over a few weeks against the list above. The guide to evaluating mining software without a six-month pilot covers how to set that up.

The network sits underneath the software MSR lists. Several underground products in the directory describe their own network or how they cope with poor coverage. Some examples, in alphabetical order, as their MSR profiles describe them on 12 October 2026 (profile descriptions that MSR has not tested):

• CiteOps (Commit Works): shift planning and execution, with plans pushed to mobile apps so it can be used underground with intermittent connectivity.
• Duetto Analytics (Maestro Digital Mine): brings airflow, gas, particulate and environmental data from the vendor's own devices into one interface, alongside the vendor's last-mile communication network.
• GroundHog FMS Underground (GroundHog): underground fleet and activity tracking, using a peer-to-peer mesh network where Wi-Fi is not available.
• HELIX (MST Global): an underground data platform that combines the vendor's network infrastructure, sensors and tracking with third-party systems, including environmental monitoring and ventilation control.
• Pitram (Micromine): mine control and fleet management that can capture shift activity over existing radio networks or run on in-cab tablets over Wi-Fi or peer-to-peer links.

Several of these bundle their own network or devices. That is a reasonable design, and it is also where the interoperability and data ownership questions above matter most.

For the machines that run on the network, see the fleet management buying guide and the underground automation checklist. For production records built from shift data, see the short interval control buying guide.

---

Sources: Mandela Mining Precinct, Real-time Information Management Systems (RTIMS) programme and project summaries, read 12 October 2026. IMT, "Solving underground mining's toughest connectivity challenge with secure private 5G", Mining Weekly, 6 October 2026 (vendor-supplied). J. J. Emontsbotz and B. G. Lottermoser, "Private 5G-networks in underground mines", Mass Mining 2024, ACG, doi:10.36487/ACG_repo/2435_N-01. R. Jacksha, "Data transport over leaky feeder systems using Internet-Protocol-enabled land mobile radios", NIOSH, via PubMed Central. MSR directory profiles, 12 October 2026.

This article is general guidance, not engineering or procurement advice. Test any network and monitoring system on your own ground, with your own OT, ventilation and safety teams.