RTCM packet definition

The AHS Rev H RTCM packet consist of 6 MSM3 rtcm messages every second plus 2 additional messages that are only sent every 10 seconds. There is one MSM3 message that carries phase ranges and pseudo ranges for each constellation, the length of these messages is proportional to the number of visible satellites in each constellation and to the number of signals tracked. For example, with the same number of satellites, GPS L1 + L2 message is longer than GPS L1 only. The MSM 3 messages are called “Compact Multiple Signal Messages” because the size is smaller than other MSM messages.

Rev H - RTCM Message Set



Months ago we changed the phase of messages 1008 and 1006, so that they would be sent separate from the other messages every 10 seconds. These two messages are now sent with a delay of .8 and 1.8 second delay respectively.

With this RTCM message configuration the total amount of information sent every second is expected to be consistent with a slight increase every 10th second. Also, as explained before, the total size will be proportional to the total number of satellites visible at the ground sation at any time. Figure 1 shows the total RTCM message payload sent by a NetG5 installed in Tucson with all constellations enabled (RevH topcon.base script).

Figure 1: Total RTCM payload per second


* As a reference the picture below shows the number of satellites tracked at the NetG5 at the time of the data capture. It’s clear that the total RTCM payload size is proportional (4 SBAS in total but not shown). Total Number of Satellites tracked

Total Number of Satellites tracked - By Constellation

RTCM packet partitioning

Now that we have an idea of the total payload of the RTCM information sent every second, lets see how the RTCM packets are partitioned. The Total amount of information is consistent, however the way the packets are partitioned is not, let’s see how the packets of the previous example were partitioned. Figure 2 below shows the packet payload, packet length and the total payload per second as a reference. For this example the NetG5 was using the default MTU of 1500 bytes. This is the standard MTU for many networks.

Figure 2: Packet Partitioning - MSM3 RevH - MTU = 1500



It can be observed that for almost all packets, the partitioning kept the packet lengths at or below 400 bytes. There were two cases however, that the packet size exceeded 512. When these packets reach the PTX logic they are cut short and corrupted.

Let’s take a closer look of what happened:

First Case

Figure 3: Packet Partitioning - First Case

The packets are consistently split in two packets with payload 337 and 315 bytes, but on the 85th second, the same amount of information is split in two packets of 598 and 54 bytes.

Second Case

Figure 4: Packet Partitioning - Second Case

In this case the packets are not even split and only one packet of 652 bytes is sent

As you can see, with a total packet size of around 700 bytes, the occurrence of this is very low, only two events in about 6 minutes were registered. however we have no control over the partitioning, as far as I understand the protocol decides the partitioning, the only restriction is the MTU of the network interface (1500). This is in Tucson with what we can consider a “normal” count of satellites and 5 constellations.

What happens when the RTCM packet gets bigger

The test equipment is in Tucson where we don’t have the high number of Beidou satellites as in Australia. In order to replicate a similar condition, I switched to MSM4 RTCM messages. These are the “Full” messages and are slightly longer than MSM3 messages. In the picture below we go from about 620 bytes to about 710 bytes per second.

Figure 5: Packet Partitioning - MSM4 Full Message - MTU = 1500



We can see that the number of packets carrying over 512 bytes payload has dramatically increased, with a 15% increase in packet size we went from 2 events in 6 minutes, to 18 events in the same time period, that is an 800% percent increase in packet corruption rate. A slight increase in total number of satellites, regardless of the region in the world the system is located, can lead to very significant increase in packet corruption rate.

Potential Temporary Solution: MTU adjustment to 450 bytes

The same cases in figures 2 and 5 have been replicated in figure 6 and 7. This time we set the MTU size to 450 in the NetG5 network interface.

Figure 6: Packet Partitioning - MSM3 RevH - MTU = 450 bytes



Figure 7: Packet Partitioning - MSM4 Full Message - MTU = 450 bytes



By restricting the MTU size in the NetG5 network interface to 450, the RTCM packet portions longer than 450 bytes payload have been completely eliminated. Please note that the total RTCM size per second has not been reduced or affected. This indicates that the information integrity has been maintained.

Conclusions