ITU-T Recommendation G.8271.2 edition 2 was published in May 2021 and addresses the network limits for deployment scenarios of partial timing support (PTS) in mobile networks.

In PTS networks, it is assumed that the core network is not fully time aware. In other words, not every node in the core network implements a transparent clock or boundary clock function. In some regions this is a fairly common deployment model. The network may traditionally have implemented GNSS at every base station such that the core network did not have to be phase synchronised. More recently, there has been an increase in attention focused on the vulnerabilities of GNSS. Also new smaller cell deployments are often in urban canyons or even indoors without clear view of the sky. In either case, operators recognise the need to implement time awareness on the network. However, parts of the network may be leased or otherwise not under their direct control and may not implement timing support. Also, complete implementation of full timing support will take a finite amount of time.

Operators, therefore, may have a network with GNSS as the primary timing source at the base station and partial timing support on the core network as backup if the GNSS timing becomes unavailable. This is the deployment scenario described by the recommendation as Assisted Partial Timing Support or APTS. It is assumed that the GNSS based time source at the base station, when operating properly, will have better accuracy than the network provided timing as it is not subject to impairments such as asymmetry. Asymmetry will create a constant time error in network provided timing. In the event of loss of GNSS at the base station, the instantaneous value of phase (time) will be maintained and only changes in the phase on the network provided timing will be tracked. Therefore, the ITU-T G.8271.2 network limit at the reference point C for APTS networks only specifies the peak-to-peak variation of the TE.

Eventually, the operator of an APTS network may have full timing support in the core network while still implementing GNSS at the base station. We are then operating in what might be called Assisted Full Timing Support (AFTS). This is a different case from either a fully time aware network as is described in G.8271.1 or an assisted partial timing support network as described in G.8271.2. It raises the question as to which recommendation should be used to set the network limits?

In the case of a network designed for APTS, in the event of loss of GNSS, the absolute phase is retained but holdover is extended by using the network provided timing to limit any phase variation. As G.8271.2 assumes PTS on the core network, it specifies that packet selection be implemented and so the network limit at reference point C to be Peak-to-peak pktSelected2wayTE < 1100 ns

In the case of AFTS, packet selection is not required, and one might assume the network limit to be Peak-to-peak 2wayTE < 1100 ns If we test to this limit, we assume that the network uses GNSS as the primary reference at the base station and, in the event of loss of the GNSS, it maintains the instantaneous phase and then only tracks changes in phase as indicated by the core provided timing.

However, if the network identifies the GNSS timing and the core provided timing as two valid master clock sources, then the constant time error on the core network is important. In this case, you would expect the core network to comply with G.8271.1 network limits.

G.8271.1 sets network limits on the maximum and dynamic components of the timing error and so are more stringent than the limit set by G.8271.2. The most pragmatic solution may be to test to G.8271.1. This would assure that the requirements of G.8271.2 are also met.

However, it is often best to speak with your vendor and understand how the network manages the event if GNSS is lost.

Related product: Sentinel

Related literature: Timing and Synchronization Library

Bryan Hovey
Product Manager