| GNSS | |
Synchronet service demonstration results in DEMETRA H2020 Project
A scalable high performances synchronisation solution |
 |
|
 |
|
SynchroNet is a Thales Alenia Space Italia patented solution for a high performance, scalable and resilient time and frequency transfer system.
The SynchroNet system addresses an arbitrarily large and topologically distributed network of nodes equipped with atomic clock(s) (ranging from inexpensive rubidium to high end oscillators like Active Hydrogen Maser) with baselines up to thousands of kilometers between any two nodes.
SynchroNet uses GNSS (Global Navigation Satellite Systems) Signal in Space to implement a distributed approach of classical time transfer and complements this function with autonomous steering functions implemented at each node to cope with Signal in Space interruptions/disruptions.
SynchroNet provides a complete set of service oriented functionalities around the core synchronisation capability, for this reason it can be suitable for a large range of application domains where synchronisation is required either in terms of accuracy or in terms of scalability or both.
This paper will provide an overview of SynchroNet architecture and capabilities as well as its declination to the DEMETRA project and the demonstration campaign results of the core synchronization capabilities as verified by the DEMETRA Service Monitoring.
DEMETRA (DEMonstrator of EGNSS services based on Time Reference Architecture) project is funded by the European Union in the frame of the Horizon 2020 program, aimed at developing and experimenting time dissemination services based on the European GNSS. DEMETRA project has received funding from the European GNSS Agency under the European Union’s Horizon 2020 research.
Introduction
Time is a recognized fundamental function of several systems, including critical ones, and all system requiring this function implement their own solution to solve this common problem. The idea of SynchroNet is born with objective to offer industry oriented solution for the provision of time thus treating time like all other fundamental services like power/ energy or communication. Like the other services, the goal of an industry oriented time service provision solution is to offer a standardized “plug” used to retrieve time/ synchronization information. For time to be treated as a service and for a solution to be considered industry oriented it requires that a set of some high level requirements are met, here follows a selection that driven the design of the SynchroNet solution:
▪ Concept of user and Time provider shall be defined
▪ Service provider and service products shall be traceable, integer, reserved and authentic
▪ Time Service shall be integrated and not designed for the user systems
▪ Time source interface shall be the same at any user location
▪ Time service performances shall be defined by a set of Service Level Agreements (SLA) that may be different for each user and for each user’s site
▪ Each user shall be able to dimension its SLA and to control and be responsible for the service infrastructure integrated in their systems
▪ SLA shall be monitored and faults shall be timely reported to users
▪ Service shall be maintainable
▪ Users shall be independent and not affected by faults caused by of occurring to other users
▪ It shall not require timing and synchronization specialist competencies in order to be used effectively
SynchroNet is the Thales Alenia Space Italy proposed solution covering the above defined needs and providing to each user a self-contained, robust and independent reference time scale and synchronization system for each facility or unit/ equipment deployed at user’s premises.
Synchronet Architecture
The general operational concept is quite simple: it is defined a stable reference time source that can be external (e.g. a UTC timing laboratory) or internal (user’s own atomic time scale or provided as part of SynchroNet solution) with respect to user’s infrastructures; one or more remote sites retrieve reference frequency and time from the central node or from other nodes (multi-hop hierarchical time distribution).
This concept is represented in Figure 1:
Figure 1 shows also the relevant architecture and interfaces of SynchroNet. Three types of node are defined:
▪ MRT’s (main reference Times): represent a time and frequency source for other nodes in the network. The reference of the whole SynchroNet network is called MRT0.
▪ SyN (SynchroNet leaf Node): are nodes that simply receive synchronization results from their reference MRT
▪ Control Node: controls the network topology (add, remove and logically move nodes –e.g. assign a SyN to an MRT). Also the Control Node is the root for encryption and in particular for PKI used by SynchroNet nodes.
▪ GNSS: SynchroNet uses GNSS signals as carriers for its internal time transfer algorithms. This means that SynchroNet is independent of the specific time distributed through Galileo or GPS (i.e. in case a time jump is introduced in any of the GPS or Galileo constellations the SynchroNet network is not affected and doesn’t observe any jump, see DEMETRA stress test results)
▪ Communication: this is some means used to transfer digital data between each node and MRT and Control Node. Each SynchroNet node establishes two and only two pointto- point encrypted tunnels: one with MRT and one with Control Node. The two channels are independent (with separated PKI) and cannot be used to route information across the network. This architecture offers several advantages in terms of security and easiness of network topology management but also in terms of required bandwidth at each node thus allowing to exploit also low throughput communication means to reach remote nodes (i.e. few hundreds of bits per second)
Both MRT and SyN deliver locally a physical realization of system time and frequency that can exploited by real HW of other sub-systems. In particular, as a minimum, each node of the network (with the exclusion of Control Nodes) distributes:
▪ 10MHz frequency reference
▪ 1PulsePerSecond TTL
▪ NTP
Considering the nature of timing products, when designing SynchroNet some further requirements have been identified as distinctive and characterizing of the proposed solution: scalability and flexibility.
These have been captured by the following features of SynchroNet:
▪ It is possible to promote a SyN into an MRT at runtime without service interruption or degradation
▪ It is possible to move a SyN or an MRT (with all its dependency) to another MRT (e.g. in case of failure or HW malfunction) at run time and without service interruptions
▪ It is possible to add or remove a node at run time without affecting the overall system operations
▪ SynchroNet nodes can be deployed with local oscillator characteristics and performances but running the same distributed solution. This means it is possible at any time to upgrade or downgrade a SynchroNet node without requiring modification in terms of system architecture or implementation.
The entire above mentioned network layout management operations can be carried out at run-time and without interruption of locally distributed timing references.
SynchroNet system also takes care of managing all low level security infrastructures for channels impacted by the reconfiguration of the network.
These features allow users to build and manage dynamically complex hierarchies.
Security
In Synchronet security has been designed to protect two main assets:
▪ GNSS signals received from space
▪ Data exchange between any two nodes of the network
These assets are quite different in nature and with different impacts on overall system performances and availability.
GNSS threats are related to availability and authenticity which can be impaired respectively by intentional and unintentional jamming/attenuation and spoofing; an example of unintentional spoofing may be considered what happened in early 2016 to GPS in which due to an operation issue a jump in GPST has been introduced and propagated to user level.
SynchroNet exploits both the georeferenced network of nodes and internal steering algorithms to detect potential spoofing and to mitigate the effects of sppofing and jamming in terms of nodes synchronization accuracy and synchronization stability. To maximize their effectiveness, detection and mitigation are two independent processes i.e. mitigation algorithms work continuously (embedded in clock steering algorithm) also in case detection process doesn’t detect any spoofing of even in case it is not working at all. Data exchange between network nodes is necessary to exchange GNSS observation data, to implement monitoring and configuration and to deliver synchronization products.
In designing SynchroNet it has been decided to rely only on the assumption that nodes speak each other using IP stack thus neglecting any assumption actual channels used to deliver packets (in the same network some node may need to use cell data communication or sitcom systems, wired telephone lines, etc). This means that security measures for protecting nodes communication network operate only at Networking layer and above.
SynchroNet implements, at each node, a stacked approach aiming at ensuring authenticity, integrity and secrecy of the messages exchanged. In particular all network packets exchanged between any two nodes is carried out via a dedicated VPN whose based on a public key infrastructure, also all application level information are signed and encrypted using asymmetric encryption.
All communication channels and all levels of security uses a dedicated set of keys and signatures that are managed by the management system coherently with the underlying logical network topology. A byproduct of this organization is that, at each node, is available an NTP service that was never exposed to external networks, whose content has been authenticated and encrypted (at the cost of some performance loss due to the asymmetry introduced by auth verification and decryption) and that is always guaranteed to be aligned to master system time (SynchroNet can operate using a custom time reference frame other than standard UTC and NTP can be configured to distribute such reference).
Network layout
SynchroNet network is inherently oriented towards a hierarchical organization that, starting from the simple layout of Figure 1, can be scaled up to cover a larger service area or an increased number of terminal keeping balanced the overall service load.
Hierarchical organization, together with flexible and run time network logical topology management, also allows to organize nodes based on their timing HW capabilities (as a rule of thumb each node should be synchronized to a node equipped with higher performance oscillators).
From layout represented in Figure 1 a SynchroNet network can scale to configurations similar to the one represented in Figure 2
A dedicated network management and configuration mechanism has been designed in order to implement scalability and flexibility oriented runtime features described in Chapter II, in order to keep manageable and effective security mechanisms and to not bound scalability to the available network and computing resources.
The solution adopted guarantees that all communications are point-to-point over two independent communication channels described in Chapter II (synchronization and M&C); the immediate benefit of this design is that any network .logical layout modification (add, remove, assign, promote, see Chapter II) impacts at most four nodes regardless of global network size. This fact makes feasible to manage automatically security mechanisms in response to a change in network logical layout.
In particular, whatever transformation is applied to the network, the channel with Control Node is never affected, and nodes receive certificates only through this channel for which Control Node operates as Certification Authority, thus all transfer of certificates happen on point-to-point channels between each of the affected nodes and Control Node. In case a new node is deployed the keys for establishing a secure connection with Control Node are pre-installed as well as all relevant PKI and CA information.
Service performances
Since SynchroNet is a time service oriented solution the concept of service performance is tightly bounded to design and implementation decisions and in particular for what concerns monitoring capabilities and alerting.
Of course SynchroNet capabilities are defined not only in terms of synchronization accuracy and stability but also in terms of several other parameters and in particular in terms of:
▪ Service availability:
▫ Robustness and independence from GPS or Galileo Time. This is guaranteed by relying on GNSS signals only as carriers used by time transfer algorithms.
▫ Resilience to faults/ impairments of GNSS
▫ Resilience to faults/impairments of communication channels
▪ Service configurability and maintainability
▪ Synchronisation performance and integrity monitoring
▫ Stability
▫ Accuracy
▫ Uncertainty
In particular for what concerns Synchronisation performance and integrity a SLA can be defined, re-defined and monitored independently for each node of the network; SLA parameter definition is achieved through a preliminary factory calibration and can be refined with monitoring results obtained during a longer operational observation period.
Also for all synchronization SLA information it is provided a double confirmation approach in which the parameters are computed and reported (locally, to Control Node and to MRT) from the node being synchronized and as well computed and reported (locally and to Control Node) by the MRT synchronizing that node.
Test campaign results
In the frame of H2020 European Community program, Thales Alenia Space Italia is participating to the DEMETRA project with a specifically adapted SynchroNet demonstrator.
DEMETRA is carried out by a consortium of national metrology institutes, university, industries and is conceived as demonstrator of different timing services devoted to different markets and user needs.
SynchroNet takes part to the DEMETRA test campaigns and is idenfied as Time Service#9.
DEMETRA provides to time services a common time reference frame (Italian UTC as realized at Italian Metrological Institute – INRIM) as well as a Core Infrastructure that includes a facility for independent services performance assessment and continuous monitoring managed by Italian Metrological Institute personnel.
DEMETRA Test Campaign are designed to test services and their performances both in nominal and extreme conditions considering the peculiarities of each service.
In particular for SynchroNet the following relevant test cases were defined:
▪ Evaluation of accuracy and stability of time transfer between MRT and SYN nodes in nominal conditions.
▪ Stress tests:
▫ Evaluation of accuracy and continuity under strong attenuation of GNSS signals (16dB attenuation at GNSS receiver antenna)
▫ Evaluation of accuracy and continuity in case of synchronization service (e.g. in case SYN is unable to talk to MRT or due to lack of GNSS signals on MRT and/or SYN)
▪ Evaluation of continuity and availability
For all test cases the 1PPS output of the SYN under test has been continuously monitored by DEMETRA performance monitoring facility and then compared and validated with results computed internally by SynchroNet as part of its -integrity and performance selfmonitoring. Also GNSS receivers (including antenna and antenna cable) employed by SynchroNet prototype have been externally calibrated with total residual uncertainty below 3ns.
For testing purpose it has been deployed a SynchroNet SYN with minimal HW capabilities and in particular equipped with an inexpensive Rubidum oscillator as internal frequency reference.
The UT prototype is shown in Figure 3, the size is not representative of the final product since prototype rack layout was selected for reusability and easy access during further experimentation with different type of oscillators and steering equipment.
Preliminary calibration of SYN under test defined the following nominal condition SLA parameters:
▪ Time offset vs UTC(IT): <=50ns (2sigma)
▪ Synchronisation stability @12h: 4.0e-13
▪ Synchronisation stability @24h: 3.0e-13
Here below are reported some representative results related to mentioned test cases, all results have been cross-checked with results provided by DEMETRA performance monitoring facility.
Overall performances
Instead of presenting the best achieved performances it is considered interesting to report the behavior of the SYN across the whole experimentation campaign up to the time of gathering data presented below. The overall period covered is more than 200 days during which SynchroNet prototype operated completely unmanned and without need for manual intervention or parameters fine tuning, the plots reported include of course the period in which the planned stress tests have been carried out as well as unintentional stress tests caused by networking impairments happened at DEMETRA hosting site and that caused a substantial degradation of communication capabilities between SYN and MRT for more than 21 days during which only 50% of planned synchronization took place successfully; this period is the rightmost part of the phase plots shown below.
From data series represented in Figure 4 the statistical data are derived (Table 1).
And plot reports synchronization stability in which all the instability contribution has been assumed on the SYN side (Figure 5).
Stress tests performances
Here below is reported an annotated plot of the period in which planned stress test case have been excercised, in particular the first block (reading from left) is related to a general unavailability scenario in which in turn MRT and SYN has been disabled GNSS observable collection thus synchronization was inhibited and signal was autonomously steered by the SYN internal algorithms.
The second block of stress test has been applied after a short period used to observe autonomous recovery of nominal conditions; this test labeled as “SiS disturbances” is the one in which a 16dB attenuation has been introduced by DEMETRA performance monitoring team at SYN GNSS receiver antenna and that caused a rather appreciable effect over time but at the same time shown that no jumps or output signals interruption was introduced and causing the phase alignment to slightly exceed nominal SLA threshold only for a short period before effects were compensated and nominal expected behavior restored.
Conclusions
DEMETRA experimentation provided a valuable test-bed for SynchroNet synchronization capabilities and benefitted independent performance evaluation and monitoring. Also, besides, technical aspects, it provided a rich insight in market and user needs and also reinforced in the conviction of the validity of a Time service oriented approach and revealed a large domain of potential users beyond that of GNSS ground segments for which SynchroNet was originally conceived .and employed as part of GALILEO Test Range project of ASI(Agenzia Spaziale Italiana) and Regione Lazio.
Also DEMETRA experience was useful to establish new opportunities on business side (on user side the idea of Time Services appears to have been receipt with interest and enthusiasm) as well as to identify new research areas and academic transversal cooperation.
In particular SynchroNet will be the basis for a study on securing and optimizing Energy Distribution networks based on Phasor Measurement Units that will explore currently used timing source security flaws, threats and their potential consequences as well as the revenues impact of a time service that is more secure and offering several order of magnitude accuracy and stability with respect to current requirements.
References
[1] P.Tavella and ALL DEMETRA consortium by Aizoon, ANTARES, Deimos, Elproma, INRIM, Metec, NPL, ORB, Politecnico of Torino, Thales Alenia Space , UFE, Vega UK, and VTT, “The European Project DEMETRA, Timing services based on European GNSS: First experimental results” –IEEE Metrology for Aerospace, 2016 Florence (Italy)
[2] D.B. Sullivan, D.W. Allan, D.A. Howe, F.L. Walls, “Characterization of Clocks and Oscillators”, NIST Technical Note 1337, Mar. 1990
[3] M. A. Lombardi, L. M. Nelson, A. N. Novick, V. S. Zhang, “Time and Frequency Measurements Using the Global Positioning System”, Cal. Lab. Int. J. Metrology, pp. 26- 33, (July-September 2001).
[4] Q.Morante,M.Eleuteri,E. Varriale.V.Valle,G.Pesci,F. Martinino,F.Gottifredi, “Galileo Test Range: Performance Test Results”, ION ’08, San Diego (CA).
(3 votes, average: 2.33 out of 5)
Loading...
Leave your response!