Five-minute facts about packet timing
A while back I posted on the start of an standards development project: IEEE 1952, or P1952 as they call it in the IEEE standards world. The P stands for project, and that means that it has not yet grown up to become a published standard yet. That is likely still a couple of years away. A quick summary, this is a project to define levels of resilience for position, navigation, and timing (PNT) equipment. Although it pains me to admit that there are things out there that are not timing that are nevertheless important, it turns out there are, including position and navigation. Here is this blog we will, or course, focus on timing equipment.
P1952 is not done, and so anything that is in the current working draft can change before it gets published. However, a few concepts seem to be accepted by the working group members. First, Resilience is understood to mean the capability for PNT equipment to continue to operate effectively during adversities. Adversities are external events that can shut down PNT equipment or degrade its performance. This doesn’t not include parts wear out or failure, but rather things like GNSS jamming, GNSS spoofing, network asymmetry or network timing security threats. Non-timing Cyber security attacks, for example, against a management interface are also out of scope as this is a big topic, better covered elsewhere.
Why Resilience levels, why not just resilience? The ambition is that the standard will help network operators and system integrators to understand tradeoffs between project cost and required resilience behavior. Also, so that these people can set a bar for suppliers when they ask for quotes. Even if an application has a high requirement for resilience, subsystems might have lower requirements if the subsystems are combined in a clever way to create overall system resilience. Another reason for lower resilience levels is that the application might have resilience mechanisms in non-PNT related subsystems.
So with those qualifications, here is the current thinking for resilience levels.
| Resilience Level | Name | Comment |
| 1 | Detect and alert | For any adversity that might prevent equipment from maintaining acceptable performance |
| 2 | Recover | Automatically, once the adversities are no longer present |
| 3 | Resist | Maintain acceptable performance for some period of time |
| 4 | Withstand | Maintain acceptable performance indefinitely |
| 5 | Verify | Determine that time received is trustworthy |
A crucial property of the resilience levels is that for equipment to achieve a resilience level it must also achieve all resilience levels with a lower number as well. For example, to achieve RL3 – Resist, equipment must also be able to detect adversities, alert and recover once the adversities are no longer present.
In future posts I will talk about how to achieve each of these levels.
If you enjoyed this post, or have any questions left, feel free to leave a comment or question below.