THE SHORT VERSION
Key takeaways
- Separate operational, corporate and worker networks.
- Define acceptance tests and service commitments.
- Remove shared power and routing failure points.
Begin with operational consequences
A mining site's network may carry office traffic, workforce welfare internet, telemetry and access to business systems. Not every workload has the same consequence of failure. Classify the services by required availability, delay tolerance and data sensitivity. Safety-critical and operational control systems require an engineered design; a household broadband product should not silently become their only communication path.
Compare service designs, not brand names
Managed LEO, GEO and hybrid connections can be supplied through different integrators. A proposal may include antennas, local networking, monitoring, maintenance and a network operations centre. Another may offer only connectivity. Compare the scope before comparing monthly totals. Identify the contractual party responsible for faults across the terminal, local network and onward internet path.
Ask what is committed
A peak download rate is different from a committed information rate. A service-level agreement may cover availability but exclude planned maintenance or particular weather events. Confirm the measurement point, reporting period, remedy and exclusions. Determine whether response time means a support ticket acknowledgement, remote investigation or a technician arriving on site.
Design the local network deliberately
Separate operational technology, corporate users and worker accommodation. Apply appropriate access controls, logging and patching. Use local services or caching where practical to reduce dependence on a distant connection. Do not expose industrial devices directly to the public internet for convenience. Remote access should be authenticated, controlled and reviewed with the site's security team.
Build resilient power and paths
A redundant satellite circuit does little if both terminals share one failed switch, inverter or cable route. Identify common failure points across power, mounts, weather exposure, routing and the service provider. Test failover with real applications because a change in public address can interrupt sessions even if basic web access returns quickly. Provide sufficient energy reserve for the complete network.
Plan serviceability
Document replacement parts, local spares, freight lead times and access procedures. A technician may need inductions, permits and an escort before reaching equipment. Include those constraints in the support agreement. Arrange remote monitoring that distinguishes power loss from radio failure and local network faults so an expensive site visit starts with useful evidence.
Conduct acceptance testing
Use a written schedule covering uploads, downloads, latency, packet loss, VPNs, voice and failover under representative load. Include busy worker-accommodation periods. Record results against agreed thresholds and investigate failures before signing off. Continue periodic tests after deployment, especially when the workforce grows or applications change. For a remote site, a predictable supported service can be more valuable than a spectacular speed test that cannot be repeated.
Sources & reference notes
Primary provider and technical references used for this guide. Commentary and worked examples are editorial explanations, not independent field measurements.
- Telstra: OneWeb backhaul deployment
- Starlink: service performance specifications
- ACMA: cabling in your home or office
Spotted a change? Send an editorial correction.