Time transfer

Abstract

A system, comprising: transmitter (Tx); first receiver; second receiver. Wherein, method of synchronisation comprises: at first receiver (Rx1): receiving Co-ordinated Universal Time (UTC) signal (from

Description

Field of the Invention The present invention relates to synchronisation with Coordinated Universal Time, and more particularly to use existing broadcasting signals to facilitate such synchronisation. Background to the Invention Coordinated Universal Time (UTC) is a global time standard to regulate time and provide a current time reference globally. UTC is used in communication protocols, navigation systems and many industries. In particular, power infrastructure systems require synchronisation to UTC for the correct operation, protection and control of modern electrical power infrastructure. Many devices in the electrical substation, including Phasor Measurement Units (PMU) and Merging Units (MU) depend on synchronisation with UTC for their correct operation. Presently, this is usually achieved by means of substation clocks which synchronise to Global Navigation Satellite Signals (GNSS), including the GPS system, for UTC synchronisation. Time is them disseminated to devices throughout the substation by means of dedicated cabling infrastructure or via Precision Time Protocol (PTP) over Ethernet networks. Whilst use of a GNSS signal for UTC transfer is effective, it is not failsafe. GNSS signals arrive at the Earth's surface from satellites in Medium Earth Orbit (MEO) with low power densities which makes then susceptible to blocking, jamming, or even spoofing. As such there is a need for alternative means of time synchronisation which does not depend on GNSS methods. There is known in the art methods of time transfer using Precision Time Protocol. However, such methods require considerable outlay in terms of equipment, installation costs, construction or rental of wired networks consisting of copper and fibre optic cables, and / or access to radio masts. 'A Method of High Precision Time Transfer Based on DVB-S' by Xiang Yu, Hua Yu, Xu Linsheng and Shi Shaohua provides a method of using DVB-S signals for time transfer and which uses a Programme Clock Reference (PCR) embedded in the data stream (PCR is included in the data output from the demodulator IC). The intended purpose of the PCR is to align audio tracks with their associated video tracks (i.e. for synchronisation between audio and video). It is used by devices which receive TV (i.e. a television receiver) to synchronise audio / video that is received from the broadcaster, or to synchronised audio / video that has been saved to disk by television recording apparatus; it is not intended for "absolute" time synchronisation such as to UTC. This is unsurprising since the PCR operates over a serial interface, which can degrade the timing. Additionally, TV is generally synchronised using a 90 kHz clock, which is about 11 microseconds resolution. This is about an order of magnitude away from the resolution necessary for many applications. Summary of the Invention According to a first aspect of the invention, there is provided a method according to claim 1. According to a second aspect of the invention, there is provided a device according to claim 10. According to a third aspect of the invention, there is provided a device according to claim 18. According to a fourth aspect of the invention, there is provided a method according to claims 23. According to a fifth aspect of the invention, there is provided a method according to claim 27. According to a sixth aspect of the invention, there is provided a system according to claim 30. Preferable features of the invention are defined in the appended dependent claims. A time transfer method and system is provided which uses the properties of the transport stream employed for delivering data over DVB broadcast systems. The invention provides a means to synchronise electronic clocks over wide geographical areas (i.e. the size of a nation) using signals of opportunity, such as broadcast TV or radio. In this way, components of electrical substations and other power infrastructure systems can synchronise to UTC without reliance on a direct GNSS UTC signal. The level of synchronisation that can be achieved is better than 1 microsecond, which makes the technology suitable for use as an alternative to Global Navigation Satellite Signals (GNSS), such as GPS, for synchronising apparatus in the electrical utility sector. Since the invention makes use of existing broadcast TV signals, the operational costs of the system are minimal and the cost of the time transfer equipment itself is minimal. Additionally, the invention provides cyber physical resilience. The invention uses the MPEG-TS_sync pulse at the hardware level, so if similar demodulator ICs are used at two or more locations, then the TS_sync pulses occur simultaneously without the overhead of software related time delays. Brief description of the drawings Figure 1 is an diagram of an overview of packetization and depacketization of multimedia data; Figure 2 is an overview of the construction of an MPEG-TS data stream from packetized multimedia data; Figure 3 is an illustration of the construction of TS Packets in an elementary stream; Figure 4 is a schematic diagram of a DVB-T / T2 receiver; Figure 5 is a timing diagram for MPEG-TS output interface from demodulator; Figure 6 is a diagram illustrating an overview of time transfer according to an embodiment of the invention; Figure 7 is a diagram of an experimental method to evaluate time error according to the method of time transfer described; Figure 8 is a histogram showing time error measured using the evaluation of figure 7; and Figure 9 shows Allan time deviation of time error measurements collected over a prolonged time period. Detailed Description Digital Video Broadcasting (DVB) and Moving Picture Experts Group Transport Stream (MPEG-TS) Digital Video Broadcasting (DVB) is a set of standards for digital television, maintained by an international industry consortium and published by standards bodies, including the European Telecommunications Standards Institute (ETSI). DVB describes transmission standards for terrestrial (DVB-T / T2), satellite (DVB-S / S2) and cable (DVB-C) broadcasts, amongst others. DVB is used globally for satellite and cable broadcast. DVB-T / T2 is used for terrestrial throughout Europe, Oceania, Asia and Africa, and parts of America. The invention is described herein in relation to DVB signals, but other terrestrial broadcasting standards can be used, such as ATSC (including USA, Canada), ISDB (Japan, most of South America), and DTMB (inc. China). Indeed, although the invention as described below uses DVB-T signals, any DVB or DAB broadcast can be used. Figure 1 is an overview of the data flow and signal path for delivery of a digital TV channel from a broadcaster to a television receiver using DVB. Video and audio data representing a TV channel (100) is created by the broadcaster either in real-time from a TV studio, or sourced from a recording. This video and audio data is packetized and multiplexed with other TV or radio channels 101. Packetization results in a stream of transport steam (TS) packets 102. These are sent to a modulator (103) for DVB modulation suitable for broadcast transmission. DVB allows for various modulation schemes, symbol rates and error correction options for broadcasters to design based on a trade-off between robustness of the signal and data throughput. A typical DVB-T multiplex broadcast using a 64-QAM Coded Orthogonal Frequency Division Multiplexing (COFDM) would achieve a data rate of 27.1 Mbps. Some DVB-T2 multiplexes in the UK operate at 40.2 Mbps. The modulated packets are then sent to transmitter 104 which mixes this signal to the desired frequency, amplifies it and broadcasts it via an antenna array. At receiver 105, a tuner down-mixes the DVB signal to an intermediate frequency. The signal undergoes demodulation 106 to extract the stream of packetized data 107. This is fed onwards to a device, e.g. a television set, for demultiplexing and depacketization 108, decoding 109 and finally presentation. Figure 2 shows packetization and multiplexing in more detail. The operation to packetize and multiplex is dictated by ISO / IEC 13818-1. This is commonly referred to as MPEG-TS (Moving Picture Experts Group Transport Stream). At the broadcaster, a stream of video data from a TV channel is packetized (stage 101) to create a 'packetized elementary stream' (PES), and assigned a Packet Identifier (PID) number indicating the stream of data (e.g. audio, video) to which the packet belongs. The same process is applied to the TV channel's audio, as well as other multimedia such as subtitles and teletext. The collection of PES which belong to one channel are known as a 'service'. Many PES from several services (TV and radio channels) are multiplexed together into a single transport stream (TS) 102. The packetized elementary stream comprising TS packets is shown in Figure 3. The transport stream is a synchronous stream of 188 byte TS packets. Each TS packet is constructed of a 4 byte header 301, up to 184 bytes of payload 302 and an optional adaptation field 303. The payload data is the audio, video or other multimedia data belonging to the service (TV channel). The packetizer ensures that the packet is always 188 bytes long by 'stuffing' packets with less than a 184 byte payload 302 with an adaption field 303. Rarely, some transport streams use 204 byte packets, which consists of 188 bytes of payload and 16 bytes of Reed-Solomon error correction data. The 4 byte header 301 starts with a 'sync byte', which always has the value 0x47 (a preamble which allows demodulators and decoders to synchronize), followed by a transport error indicator (TEI), Payload unit Start Indicator (PUSI), transport Priority, Packet Identifier (PID), Transport scrambling control (TSC), adaptation foiled control and continuity counter (0-15). The continuity counter starts at a value of 0 and increments by 1 for each new packet belonging to that PID. After the counter reaches 15, it loops back such that the next packet has a value of 0. This allows missing packets to be identified at the receiver. At the receiver, the synchronous stream of TS packets is recovered from the modulated radio signal by a tuner and demodulator. Figure 4 shows depacketization and demultiplexing in more detail. Tuner 105 downmixes the signal to an intermediate frequency (IF). A demodulator chip 106 outputs the MPEG-TS packets through a standardised interface (the standardised output provides a high degree of interoperability between devices from many equipment vendors). The interface consists of a clock, a data bus and control lines. Present day reception equipment for digital TV signals generally employs integrated circuits (ICs) for the functions of tuning to a particular frequency, demodulating the broadcast signal, and sending the MPEG-TS data stream to the host. In the case of a TV set, the host is usually a System-on-Chip (SoC) 107 for processing and rendering the video data to a screen for viewing, and the audio to speakers for listening. If a TV channel called is carried by a multiplex broadcast on 642 MHz and a user commands the TV set to view that channel, the SoC will usually send a request by I2C bus that the demodulator chip provides a stream of the multiplex on 642 MHz. The demodulator chip in turn sends a tuning request to the tuner chip to tune to 642 MHz and downmix it to the intermediate frequency (IF) on 36 MHz. The demodulator chip will then start to demodulate the received signal, and communicates with the tuner for functions such as automatic gain control (AGC) as the received signal strength varies. A timing diagram for the output interface is shown in Figure 5. The data bus 'TS_Data' may be either parallel or serial. In parallel mode, 8 output pins are used providing the TS packet one byte at a time. The rising edge of the clock 'TS_Clk' indicates that a new byte is available. In serial mode, theTS packet is sent as a single bit stream and only one pin is used for data; the clock edge signifies a new bit. The start of a new TS packet is indicated by the line 'TS_Sync'. 'TS_Val' indicates that the TS packet is valid. If errors occurred in the demodulation, TS_Val is held low and the SoC can determine what to do with the invalid data (either discard it, or attempt application level error correction). Time Transfer Figure 6 shows an overview of a time transfer method according to an embodiment of the invention which uses DVB receivers to demodulate a signal carrying MPEG-TS data. The system comprises a 'Time Server' 601 and one or more 'Time Clients' 602 which are both in the service area of the transmitter but are otherwise independent. Time server 601 acquires the TS_Sync signal (TSI) output by the demodulator chip (as discussed with reference to Figure 4 and 5), and compares TSI against a known, reliable UTC time signal. Using a System-on-Chip (SoC), it computes the difference in time, AT, between the edge of the TSI pulse (i.e. the first transition from logic low to high, or vice versa) and the edge of the 'tick' of the UTC second. AT is communicated via known telecoms technology to the time clients. At time client 602, a tuner and demodulator are tuned to the same DVB / MPEG-TS service that the time server is using. In the same manner as the time server, the TS_Sync signal, TS2, is acquired from the demodulator chip and passed to an SoC. Since TSI and TS2 are derived from the same DVB signal, they are synchronised. The SoC of time client 602 additionally receives AT. AT enables the SoC of time client 602 to reproduce the UTC time signal in coherence with the known good UTC source at time server 601, by adding (or subtracting) AT from TS2 . The propagation delay between the broadcast transmitter and the time server / time client also needs to be corrected for. However, this correction calculation is straightforward since the location of the transmitter and receivers are known and the delay is due to the speed of light between the locations. Although a GNSS receiver is used to provide the UTC time signal in Figure 6, it could instead be derived from another source including an atomic clock or fiber connection to a national laboratory's time server (such as that at the National Physical Laboratory). The frequency of TS_Sync edges is a function of the bitrate of the DVB multiplex, because TS packets have a fixed length of 188 bytes. For example, a DVB multiplex with 64QAM modulation, 8K carriers, and 2 / 3 Forward Error Correction (FEC) has a bitrate of 24.1 Mbps. Dividing the bitrate by 188 bytes per packet yields 16,024 packets per second, meaning that the TS_Sync line is expected to pulse at this frequency. This is confirmed experimentally. However, this frequency is too high to be of use for time transfer, since the period between pulses is likely to be longer than the telecoms transport latency. Thus, it is necessary to determine specific TS_Sync edges on which to base the AT calculation and time transfer. As discussed above with reference to Figure 3, each MPEG-TS packet consists of a header containing the packet identifier (PID) and a continuity counter. The PID of the packet indicates which PES the particular packet belongs to, with a TV programme having video, audio and subtitles. Subtitle bitrates are generally very small and packets may be absent when a programme is not subtitled. Video is the largest component of data transferred, using bitrates nominally between 2 Mbps and 8 Mbps, usually with a variable bitrate. Audio is usually at a fixed bitrate between 128 kbps and 320 kbps. A typical TV channel may use 192 kbps for its audio information, equating to 127.6 packets per second with that PID. The continuity counter rolls over every 16 packets for that PID, yielding ~8 packets per second with that PID and a continuity counter of zero. Passing this header data to the Time SoC along with the TS_Sync allows 8 unique time stamps to be created per second, with an interval between them greater than 100 ms. Using the 188 byte payload data, which expresses a small portion of the audio data, each AT message can be given a unique signature. To avoid any issues regarding copyright and retransmission of audio data, the 188 bytes is one-way hashed (e.g. MD5 or SHA256) so that the signature is unique, but the original audio data cannot be recovered. Figure 7 shows a configuration used to evaluate the performance of the described time transfer method. Two receivers 701, 702 were configured such that they are tuned to and demodulating the same DVB-T multiplex, and their TS_Sync lines are connected to an oscilloscope 703 to record the time difference between the two rising edges. The multiplex used is 'Saorview 1' on 642 MHz from the Clermont Cairn transmitter in the Rep. of Ireland, approximately 60 km from the receivers' location. Each receiver is connected to an independent aerial, and the tuning instruction comes from an independent PC (in order to eliminate the possibility that the PC's USB bus is synchronising the receivers). The time error is the difference in time between TS_Sync from Rx 1 (TSI) and TS_Sync from Rx 2 (TS2). TSI is used as the reference, or trigger, such that if TS2 leads TSI the time error is negative, whereas if TS2 lags TSI, then the time error is positive. In the experiment, the time error was found to lie in the range ±1.5 ps. Figure 8 is a histogram of the distribution of 780k measurements taken. Although the distribution is visibly tri-modal, the Laplace probability density function (solid line) is found to be a good fit to the data with an offset of -10 ns. This corresponds well with the arithmetic mean of the set of the time error which is -16.7 ns. Using a single pair of TS_Sync pulses (i.e. one pulse from the server is compared to just one pulse on the client), time transfer is possible with an uncertainty of ±1.5 ps. This is useful for many applications, including for synchrophasor measurements in power systems where the acceptable limit for time error is >20 ps. However, in many applications, it is desirable for time transfer to have an uncertainty of less than 1 ps. Using a succession of TS_Sync pulses, it is possible to average the time error over a long period of time. If the errors are random and spread equally positive and negative, then the result should tend towards zero over a long enough period of time. To verify this, 9 days worth of data was collected taking one time error measurement per second. The Allan Deviation is shown in Figure 9. This indicates that when averaged over the observation time, the initial time error is of the order of 80 ns, with the magnitude of the error increasing over a period of 250 seconds (~4 mins) to 300 ns, before starting to tend towards zero over the longer term. By 4,500 seconds (75 mins) the averaged time error is <100 ns. This period required to allow the time transfer operation to improve is similar in concept to the 'survey-in' function on stationary GNSS clocks.

Claims

1. A method of transferring a time signal, comprising, by a first apparatusreceiving a UTC signalreceiving a first synchronisation signal, wherein the first synchronisation signal indicates the start of a new transport stream packet in a data transport stream received from a digital broadcasting transmitter,calculating a time difference value between the UTC signal and the first synchronisation signal, andtransmitting the calculated time difference to a second apparatus arranged to receive the data transport stream from the digital broadcasting transmitter.

2. The method of claim 2, wherein the step of receiving a first synchronisation signal comprises demodulating a data stream received from the digital broadcasting transmitter into a packet stream, and extracting, for each packet, a synchronisation pulse that indicates the start of a new transport stream packet.

3. The method of claim 2, further comprising extracting, from each packet having a predetermined packet identifier and a pre-determined continuity counter value, a synchronisation pulse that indicates the start of a new transport stream packet.

4. The method of claim 3, further comprising generating a series of time stamps, wherein each time stamp is created using header data for each transport steam packet having the pre-determined packet identifier and the pre-determined continuity counter value and the synchronisation pulse that indicates the start of a new transport stream packet.

5. The method of claim 4, wherein the step of calculating a time difference value comprises generating a series of time difference values corresponding to the series of time stamps and the received UTC signal.

6. The method of claim 5, further comprising generating a unique signature for each time difference value in the series of time difference values, wherein the unique signature is the payload data of the transport stream packet used to generate each time stamp.7.The method of claim 6, further comprising hashing the generated unique signatures.

8. The method of claim 7, wherein the step of transmitting the calculated time difference comprising transmitting a series of hashed unique signatures to the second apparatus.

9. A device configured to carry out the method of any of claims 1-8.

10. A device for transferring a time signal, comprisinga receiver configured to receive a UTC signal and a first synchronisation signal, wherein the first synchronisation signal indicates the start of a new transport stream packet of a data stream received from a digital broadcasting transmitter,a processor configured to calculate a time difference between the UTC signal and the first synchronisation signal, anda transmitter configured to transmit the calculated time difference to one or more devices configured to receive the data stream from the digital broadcasting transmitter.

11. The device of claim 10, further configured to demodulate a data stream received from the digital broadcasting transmitter into a series of transport stream packets, and to extract, for each packet, a synchronisation pulse that indicates the start of a new transport steam packet.

12. The device of claim 11, further configured to extract the synchronisation pulse that indicates the start of a new transport stream packet from each transport steam packet having a specified packet identifier and a specified continuity counter value.

13. The device of claim 12, further configured to generate a series of time stamps, wherein each time stamp is created using header data for each transport steam packet having a specific packet identifier and a specific continuity counter value and the synchronisation pulse that indicates the start of a new transport stream packet.

14. The device of claim 13, further configured to generate a series of time difference values corresponding to the series of time stamps and the received UTC signal.

15. The device of claim 14, further configured to generate a unique signature for each time difference value in the series of time difference values, wherein the unique signature is the payload data of the transport stream packet used to generate the time stamp.

16. The device of claim 15, further configured to hash the generated unique signatures.

17. The device of claim 16, further configured to transmit a series of hashed unique signatures tothe one or more devices configured to receive a transport stream from the digital broadcasting transmitter.

18. A time synchronisation device, the device comprisinga receiver configured toreceive a first synchronisation signal from a digital broadcasting transmitter, wherein the first synchronisation signal indicates the start of a new transport stream packet received from the digital broadcasting transmitter, andreceive, from a digital broadcast receiving apparatus, a time difference value, wherein the time difference value is the difference in time between a second synchronisation signal received by the digital broadcast receiving apparatus and a UTC time signal, wherein the second synchronisation signal indicates the start of a new transport stream packet received by the digital broadcasting receiving apparatus from the digital broadcasting transmitter, anda processor configured to generate a UTC signal based on the first synchronisation signal and the time difference value.

19. The device of claim 18, wherein the receiver is further configured to demodulate a data stream received from the digital broadcasting transmitter into a series of transport stream packets, and to extract, for each packet, a synchronisation pulse that indicates the start of a new transport steam packet.

20. The device of claim 19, wherein the receiver is further configured to extract a synchronisation pulse that indicates the start of a new transport stream packet for each transport steam packet having a determined packet identifier and a determined continuity counter value.

21. The device of claim 20, wherein the processor is further configured to generate a series of time stamps, wherein each time stamp is created using header data for each transport steam packethaving a specific packet identifier and a specific continuity counter value and the synchronisation pulse that indicates the start of a new transport stream packet.

22. The method of any of claims 18 to 21, wherein the processor is configured to generate the UTC signal by adding or subtracting the time different value from a time stamp of the first synchronisation signal.

23. A method of replicating a time signal, comprisingreceiving, at a first computing device, a first synchronisation signal, wherein the first synchronisation signal indicates the start of a new transport stream packet received at a first receiver from a digital broadcasting transmitter;receiving, at the first computing device, a UTC time signal;determining the time difference between the first synchronisation signal and the UTC time signal;transmitting the time difference to a second computing device;receiving, at a second computing device, a second synchronisation signal, wherein the second synchronisation signal indicates the start of a new transport stream packet received at a second digital receiver from the digital broadcasting transmitter; andgenerating, at the second computing device, a UTC signal using the second synchronisation signal and the received time difference.

24. The method of claim 23, wherein the UTC signal is received from a GNSS transmitter, an atomic clock or a fibre transmission line.

25. The method of claim 23 or claim 24, wherein the first and second receivers are DVB receivers.

26. The method of any of claims 23 to 25, wherein the step of generating a UTC signal comprises summing the received time difference and a time stamp of the second synchronisation signal.

27. A method for transferring a time signal, comprisingreceiving, at a first DVB receiver, a UTC time signal,receiving, at the first DVB receiver, an MPEG Transport Stream comprising a stream of data packets, wherein each packet comprises the same number of bytes,demodulating, the first DVB receiver, the MPEG transport steam, wherein the demodulator is configured to output a synchronisation signal indicating the start of a new packet in the steam of data packets,determining the time difference between the synchronisation signal output by the demodulator and the UTC time signal, andtransmitting time difference to a second DVB receiver.

28. The method of claim 27, further comprising:receiving, at a second DVB receiver, the time difference from the first DVB receiverreceiving, at the second DVB receiver, the MPEG Transport Stream,demodulating, by a demodulator of the second DVB receiver, the MPEG transport steam, wherein the demodulator is configured to output a second synchronisation signal indicating the start of a new packet in the steam of data packets, wherein the second synchronisation signal is synchronised with the first synchronization signal,generating, at the second DVB receiver, a UTC signal using the second synchronisation signal and the received time difference.

29. The method of claim 28, wherein the UTC signal is received from a GNSS transmitter, an atomic clock or a fibre transmission line.

30. A system for time synchronisation, comprisingA first receiver system comprising a demodulator and a processor, wherein the first receiver system is configured to:receive a UTC signal,receive a MPEG-TS data stream, the data stream comprising a series of data packets, demodulate the data stream to generate a first synchronisation signal, wherein the first synchronisation signal indicates the start of a new packet in the steam of data packets,determine the time difference between the synchronisation signal output and the UTC time signal,transmit the time difference to a second receiver system,wherein the system further comprisesa second receiver system comprising a demodulator and a processor, wherein the second receiver system is configured to:receive the MPEG-TS data stream, the data stream comprising a series of data packets,demodulate the data stream to generate a second synchronisation signal, wherein the second synchronisation signal indicates the start of a new packet in the steam of data packets, andgenerate a UTC signal using the second synchronisation signal and the received time difference.

31. The system of claim 30, wherein the first receiver system and second receiver system are configured to receive the same multiplexed signal from the same transmitter.15

Images