Since the first broadband wireless network deployments in mining, there has been a strong use case for sending GPS corrections over these networks.
GPS corrections are relatively small packets that are transmitted once per second from the GPS base station and must be received, with as little latency as possible, and in sequence, by the High Precision GPS (HPGPS) Receivers onsite. These relatively small packets should theoretically have little impact on the network, and since coverage is typically available, it seems a good fit.
From the challenges of broadcasting
As with most other data required to be sent over mining wireless networks, there are some unique challenges to even these packets. Often the first inclination is to send these packets via a broadcast message from the base station, so that a single message is sent over the network each second, and each device that requires the message would receive it and utilise it.
The challenge comes in the way broadcast traffic is handled on the wireless medium. Broadcast traffic is connection-less, so the transmitting device sends the message and forgets it, not knowing whether it has been received by all the necessary receivers. Broadcast traffic in Wi-Fi-based wireless networks is also sent at the lowest basic data rate.
Wi-Fi sends broadcasts at these lowest rates in an effort to ensure they are received by as many wireless nodes as possible, since the highest data rates are only able to be received and understood by the closest devices, sending broadcasts at the lowest data rate should allow the devices that are in poor RF situations the best chance of receiving the broadcast.
However, that low data rate does slow the network while it is being transmitted, and there is still no guarantee of delivery. Often, network managers will increase the lowest basic data rate, in an effort to increase the performance of the network by preventing any traffic being sent at these slow speeds.
In reality, these networking basics can result in missed GPS corrections, typically by the machines that are further away from infrastructure, such as on dumps, reclamation areas, or possibly in other challenging RF conditions, such as drop cuts, shadowing from other equipment, etc. Since the message is connection-less, the HPGPS receiver won’t get the correction, and just needs to do without it. In many cases, they can, for a few corrections, but when the misses start to add up, the HPGPS application suffers.
To the limitations of unicasting GPS corrections
In an effort to work around these challenges, systems have been implemented to send the GPS corrections via unicast TCP messages, to an IP list, or peers list of HPGPS machines on the network. This works well in most cases, since the TCP messages are no longer connection-less, the GPS base station sender works hard to ensure the remote HPGPS receivers receive those messages.
Of course, nothing is free, and new challenges arise with this solution. When the receiving device is offline, the transmitter, at the GPS base station doesn’t know they are offline, and continues to try and send the messages. This unnecessary traffic results in high numbers of Address Resolution Protocol (ARP) messages being sent across the network, as the transmitter tries to find the expected receiver.
Unfortunately, these ARP messages are also sent as broadcast messages. It’s no longer a problem that these messages aren’t received, as the device is offline. However, because ARP’s are sent again at the lowest basic data rate, they slow the network considerably while they are transmitted around the network.
To make matters worse, the number of broadcast messages can be considerably higher under this new unicast solution, as there may be several devices offline at a given time, and the ARP’s are sent repeatedly when each second new GPS corrections are attempted to be sent. In the end, GPS corrections have a much better chance of getting to the HPGPS machines with this solution, but the overall network available throughput is reduced by all the new, basic data rate traffic.
3D-P Pub/Sub
3D-P recently released a product we call Pub/Sub. Available for more than just GPS corrections, but certainly perfect for this scenario, the Pub/Sub correction publishing service allows each HPGPS machine to subscribe to the GPS correction publishing server upon boot-up. The corrections are sent via unicast to that machine while it is running, ensuring the best chance of delivery. When the machine is shut down, the corrections are no longer sent to that machine, removing all the additional broadcast traffic created by the older static peers list solution.
The result is a much more reliable and robust delivery of GPS corrections to the HPGPS machines, with minimised network traffic and at the highest possible data rates. It’s the best of both worlds, the solution we really wanted from the beginning.
To learn more about how 3D-P Pub/Sub can be used at your site, fill out the enquiry form on this page.