December 16, 2025 • 16 mins
A comprehensive technical overview of synchronization and timing solutions within telecommunications, with a specific focus on 4G and 5G mobile networks. It explores the historical necessity of synchronization, progressing from frequency alignment for digital networks to the modern requirement for phase and time synchronization driven by mobile base stations and new radio technologies. A significant portion of the text addresses the implementation and management of timing solutions, detailing protocols like Precision Time Protocol (PTP) and Synchronous Ethernet (SyncE), including their various ITU-T profiles and performance metrics such as time error, jitter, and wander. Furthermore, the text examines the architecture of 5G RAN (Radio Access Network), the challenges of timing distribution (xHaul) in these disaggregated environments, and the critical processes of testing, verifying, and securing these timing systems.
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Synchronizing-Mobile-Networks-Anshul-Tanwar/dp/0136836259?&linkCode=ll1&tag=cvthunderx-20&linkId=4706ea3212cea4cd4454343c92116d92&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Synchronizing-Mobile-Networks-Anshul-Tanwar/dp/0136836259?&linkCode=ll1&tag=cvthunderx-20&linkId=4706ea3212cea4cd4454343c92116d92&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome to the deep dive. Today, we're getting into something
fundamental but often totally invisible, network synchronization. And we're not
just talking about you know, knowing it's lunchtime. We mean
hyper precise time down to nanoseconds that underpins things like
five G automated trading.
Speaker 2 (00:18):
The works. It really does hold it all together. Our
mission today really is to get a handle on the
basics of this digital time. You know, what are the
different kinds of zync frequency, phase time, and how do
we actually get this level of precision across huge networks
down to the nanosecond. And there's a key point in
the source material too. When this stuff fails, it's sneaky.
Speaker 1 (00:39):
Yeah, that really jumped out. It says timing failures often
look like something else entirely.
Speaker 2 (00:43):
At first exactly. I remember back in my circuit board
design days, a clock problem could totally look like a
software bug or just weird logic makes it incredibly hard
to track down. Now, scale that up from one board
to say, a whole continence network, multiple vendors, different gear
a few microseconds off could look like a bad route,
a broken process. Really tough.
Speaker 1 (01:03):
Okay, so let's maybe start at the beginning time seems simple, yeah, right,
but trying to get everyone on the same page globally, Yeah,
that I complicated fast.
Speaker 2 (01:12):
Oh absolutely. I mean historically, every town just set its
clock by the sun. Noon was noon locally. Worked fine
until the trains came along. Suddenly you needed timetables that
worked across different zones. You couldn't have a train leaving
one town at two pm and arriving somewhere else, you know,
before two pm according to their clock. That push, that
(01:32):
need for consistency led to standardizing time ach wor Greenwich
Meantime GMT back in eighteen eighty four.
Speaker 1 (01:38):
Right, GMT. But today the standard is Coordinated Universal Time UTC.
What's the practical difference for most people or for these networks.
Speaker 2 (01:47):
Well, the core reference is different. UTC is what we
all use. Yeah, but it's based on International Atomic Time TAI.
TI comes from hundreds of atomic clocks around the world.
It's incredibly stable, just ticks a long perfectly, well almost perfectly.
It's continuous. But UTC is what we call discontinuous. We
sometimes have to add leap seconds.
Speaker 1 (02:04):
Ah, yes, leap seconds the bane of sysadminin's everywhere.
Speaker 2 (02:07):
Huh, exactly, They exist because the Earth's rotation isn't perfectly regular.
It wobbles a bit, so the IIRS, that's the International
Earth Rotation Service, they manage these leap seconds. The goal
is to keep UTC within zero point nine seconds of
the actual solar day, you know, based on Earth's spin.
Speaker 1 (02:25):
Okay, so if UTC is the gold standard, how do
we know what the real official UTC is like right
this second.
Speaker 2 (02:32):
That's the fascinating part. You don't not perfectly in real time.
Any time signal you get right now is an approximation,
a very very good one hopefully, but still an approximation.
The actual single official UTC value. It's only calculated after
the month ends. They gather data from all those atomic clocks,
globally process it, and then the BPM, the International Bureau
of Weights and Measures, publishes the definitive value in something
(02:54):
called circular t, usually a couple of weeks late.
Speaker 1 (02:57):
So the absolute truth about this very nanosecond we won't
know it for weeks.
Speaker 2 (03:01):
Pretty much kind of changes how you think about real time,
doesn't it.
Speaker 1 (03:04):
It really does? Okay? Knowing the official time is always
a bit delayed, that's a big takeaway. Now let's talk terminology.
Synchronization gets thrown around a lot, but the sources are clear.
There are three distinct types.
Speaker 2 (03:17):
Yeah, getting these straight is super important if you're dealing
with high performance networks. Let's maybe use an orchestra analogy.
Speaker 1 (03:23):
Okay, sound good. Let's start with frequency synchronization. What's that about.
Speaker 2 (03:27):
Frequency sync is about the rate of the clock, the
tempo maybe, or the pitch in music. So in the orchestra,
it's making sure two violins are playing the exact same
a you know, four hundred and forty hertz, four hundred
and forty oscillations per second. In a network device, it
means making sure its internal oscillator is ticking at the
(03:47):
correct speed, its nominal frequency. We can use external sources
like SINCSA, which we'll get to to make that much
more accurate. Instead of maybe being off by say four
point six parts per million, we can get down to
like sixteen parts per billion, much tighter control over the rate.
Speaker 1 (04:02):
Okay, so frequencies of the rate, the speed of the ticking.
What about phase synchronization? Then?
Speaker 2 (04:06):
Facinc is about aligning the tick itself, making sure the
ticks happen at the exact same instant. Back to the orchestra.
It's the conductor ensuring everyone hits the downbeat together right
on time. Phase is about the relative offset between clocks,
usually measured in tiny fractions of a second, milliseconds, microseconds, nanoseconds.
It's about agreeing on when now is.
Speaker 1 (04:27):
And the sources gave a really good, kind of stark
example of why phase matters so much in industry factory automation.
Speaker 2 (04:34):
Oh yeah, that's a perfect illustration. Imagine you've got two
robots passing a part between them. They're not using cameras,
they're just timed. Robot A let's go at say start
plus point four over zero seconds. Robot B needs to
grab it at exactly start plus point four zero zero
seconds for that to work. Their idea of when start
plus zero point zero zero theory happen has to be
(04:55):
absolutely identical. Now, their facecinc is a bit loose, maybe
only accurate to fifty milliseconds. Robot A might let go
fifty milliseconds before Robot B is ready, and bam, part
hits the floor, a physical failure caused by a tiny,
tiny timing error.
Speaker 1 (05:07):
Wow, so fifty milliseconds is enough to cause real physical problem.
Speaker 2 (05:10):
Absolutely shows you the stakes.
Speaker 1 (05:12):
That factory example really brings it home. Milliseconds matter physically,
but looking at the big data networks, the requirements are
pushing into micro seconds, even nanoseconds. Why such extreme precision
across whole continents?
Speaker 2 (05:26):
Right, It's not just factories. There are really three big
areas pushing this need for tighter and tighter timing.
Speaker 1 (05:31):
Okay, where should we start? Maybe one? We can perceive
directly audio and video.
Speaker 2 (05:35):
Yeah, av sync. Humans are surprisingly sensitive to this. Research
shows if the audio is ahead of the video by
just forty milliseconds that's less than two frames of video,
about twenty percent of people will notice it it feels wrong.
So for professional broadcast streaming movies, they use specific timing
profiles like SMPTE twenty five nine to two built on
(05:56):
PTP to keep audio and video locked tight.
Speaker 1 (05:59):
Okay, so av is on one. What about finance? You
mentioned high frequency trading earlier.
Speaker 2 (06:03):
Definitely a huge driver. This really kicked into high gear
with a regulation called MIFIED two from the EU back
in twenty fourteen. It basically mandated that all high frequency
trading transactions had to have super accurate time stamps. Traceable
time stamps. We're talking precision way beyond what older protocols
like MTP could reliably deliver. It became a legal necessity
(06:24):
for transparency, for proving when trades happened, preventing manipulation, they
needed microsecond Sometimes better accuracy makes sense.
Speaker 1 (06:33):
Legal compliance often pushes technology, but the sources suggests the
biggest driver, the one really pushing phasinc. Everywhere, is mobile
networks five G.
Speaker 2 (06:42):
Specifically, without a doubt, five G is the main engine
right now for widespread phase synchronization, deployment and transport networks.
The core reason is a technology called time division duplex
or TDD. In TDD, a base station uses the same
chunk of radio frequency to both transmit and receive. It
just switches really fast between the two. Now, imagine two
base stations near each other. If one is transmitting while
(07:02):
its neighbor is trying to receive on that same frequency,
you get massive interference. They jam each other.
Speaker 1 (07:07):
Uh okay. So they have to coordinate very very carefully
when they transmit and when they listen exactly.
Speaker 2 (07:12):
They need extremely tight phase alignment. The requirement is pretty stunning.
The time difference between any two neighboring base stations has
to be less than three microseconds, and the way networks
achieve that is by making sure every base station across
the entire network is synchronized to the master UTC reference
clock to within plus or minus one point five microseconds.
(07:32):
If everyone stays within that one point five microsecond window
relative to UTC, then any two neighbors will automatically be
within three microseconds of each other.
Speaker 1 (07:40):
Plus or minus one point five microseconds. Wow, that's the
tolerance across the whole system.
Speaker 2 (07:45):
Tolerance it's demanding.
Speaker 1 (07:46):
Okay, so we understand the need plus or minus one
point five microseconds for five G, even tighter for finance
in some cases, How do networks actually get this timing
signal and then distribute it reliably? Where does it originate?
Speaker 2 (08:01):
Well, the ultimate source, the primary reference time clocks or prtcs.
Those are generally the Global Navigation Satellite Systems GNSS, So
think GPS, which is the US system, gel NASS from Russia,
Galileo from Europe, bay DO from China. They are, in essence,
constellations of atomic clocks orbiting the Earth. They constantly broadcast
(08:22):
signals that include very precise timing information. Receivers on the
ground pick these up and can figure out their position,
and crucially for us, the current precise time. Got it?
Speaker 1 (08:30):
So the time comes from space basically. Then once a
receiver on the ground has that signal, how does it
get shared across say miles of fiber optic cable in
the finance port network. What tools do network designers use?
Speaker 2 (08:43):
There are two main specialized methods used often in combination.
The first one is called synchronous ethernet or sink.
Speaker 1 (08:49):
Okay, sink E. What's this role?
Speaker 2 (08:51):
Sink E is all about frequency synchronization, remember the rate
of the clock. It's actually built into the physical layer
of the ethernet connection, kind of like how older technologies
like SDH or sonnet handled frequency. It allows network devices
to pass along a very stable frequency reference directly over
the fiberlink itself, without needing special timing packets or relying
(09:13):
on software higher up. So it's very reliable, very predictable
for keeping the rate stable across the network carrier grade frequency.
Speaker 1 (09:20):
Okay, so SYNC nails the frequency. What about the actual
time of day, the phase alignment down to microseconds. That's
the other one. PTP exactly.
Speaker 2 (09:28):
PTP the precision time protocol that's defined by IE fifteen
eighty eight PTP is specifically designed to distribute precise phase
and time synchronization over packet networks. Like standard ethernet networks,
it aims for microsecond level accuracy, sometimes even better. The
key thing that makes PTP so much better than older
protocols like NTP is its use of hardware time stamping.
Speaker 1 (09:48):
Hardware time stamping what does that mean?
Speaker 2 (09:50):
It means the time stamps marking when a PTP timing
packet arrives or departs, are applied right at the network
interface card as close to the physical wire as possible.
If you rely on the main CPU or the operating
system to do the time stamping, you introduce all sorts
of delays and variability jitter that kills your accuracy. PTP
with hardware support bypasses a lot of that software unpredictability.
Speaker 1 (10:13):
Right, get the time stamp as close to the physical
event as possible makes sense. So SYNCY for frequency stability,
PTP for phase and time accuracy. How do operators get
the absolute best result? Do they choose one or the other?
Speaker 2 (10:26):
Usually for the most demanding applications like five G, they
use both together. It's often called hybrid mode. They use
sync along constantly on the physical layer to provide that
rock solid, stable frequency foundation, and then they run PTP
on top of that stable frequency to distribute the precise
phase and time information. This combination gives you the best
of both worlds, the stability of SYNC and the accuracy
(10:47):
of PTP. It's generally considered the gold standard for carrier
networks define inspects like the itut G point eight two
seven five point one profile for telecom. It provides deterministic performance.
Speaker 1 (10:59):
Okay, so hybrid mode seems like the way to go.
But even with the best protocols, the network itself can
fight back, right. The sources mentioned packet delay, variation, jitter,
and something called asymmetry as the main enemy. So let's
focus on asymmetry.
Speaker 2 (11:13):
What is that, ah, asymmetry. Yes, that's a really tricky
one for PTP. It's kind of the silent killer of
timing accuracy. See PTP works out the time it takes
for a packet to travel from the master clock to
the slave clock by measuring the total round trip time
and then dividing by two. It fundamentally assumes that the
path delay from master to slave is exactly the same
(11:35):
as the path delay from slave back to master.
Speaker 1 (11:37):
AH Okay, it assumes the journey takes the same amount
of time in both directions precisely.
Speaker 2 (11:42):
Asymmetry is simply when that assumption is wrong, when the
forward path delay is different from the reverse path delay.
Speaker 1 (11:48):
What could cause that?
Speaker 2 (11:49):
Yeah, different routs exactly. Maybe the packets go out via
one set of routers and fibers but come back via
completely different set due to network routing decisions. Or maybe
the five verer length itself is physically different in one
direction versus the other in some older setups. Or maybe
there's traffic congestion affecting delays only in one direction. Lots
of potential causes.
Speaker 1 (12:10):
Why is that so bad for PTP?
Speaker 2 (12:12):
Because of what some call the golden rule of packet timing,
half of the total path asymmetry shows up directly as
a constant time error a phase offset at the slave clock.
So if your network path has one hundred nanoseconds of asymmetry,
meaning the trip one way is one hundred thens longer
than the other way, your slave clock will be permanently
wrong by fifty nanoseconds. PDP can't easily detect or correct
(12:34):
for that on its own.
Speaker 1 (12:35):
Wow, fifty nanoseconds just baked in his error. Okay, that's
a huge deal when the total budget is only, say,
fifteen hundred nanoseconds. Yeah, so that's an internal network problem.
What about the sorts itself. We rely heavily on GNSS
those satellites. Are they vulnerable?
Speaker 2 (12:47):
Oh? Absolutely, that's a major concern. GENUSA signals are very
weak by the time they reach the ground. This makes
them susceptible to jamming, basically overpowering the signal with noise
so the receiver can't lock on. That's denial of service.
Even more worrying, perhaps, is spoofing. That's when an attacker
transmits fake GNSS signals to trick the receiver into calculating
(13:08):
the wrong time or position.
Speaker 1 (13:10):
So some could potentially feed incorrect time into the network
at its source.
Speaker 2 (13:14):
It's a known vulnerability. Yes, and because our critical infrastructure,
power grids, finance, mobile networks relies so heavily on GNSS timing,
this vulnerability is taken very seriously. Resilient backup timing sources
are becoming essential, not just nice to haves.
Speaker 1 (13:29):
Is that where things like h l RAN come in.
I saw that mention enhanced.
Speaker 2 (13:33):
Loran exactly A loran is being looked at and deployed
in some regions as a terrestrial backup or complement to
space based GNSS. Loran uses very powerful low frequency radio
transmitters on the ground. The signals are much harder to
jam than genss and can penetrate buildings, tunnels, even underground
to some extent where satellite signals can't reach. The goal
(13:55):
for l RAN is to provide UTC traceability potentially down
to the fifteen nanosecond level, offering a really robust alternative
if GNSS is unavailable or compromised.
Speaker 1 (14:05):
Interesting a ground based backup using very different technology.
Speaker 2 (14:08):
Yeah, diversity and sources is key for resilience. Hashtag tag outro.
Speaker 1 (14:11):
Okay, we'scovered a lot of ground here, from old town
clocks needing sun dials to needing nanoseca precision from space
and distributing it globally. Before we wrap up, let's quickly
just nail down the difference between two terms we used,
accuracy and stability. They sounds similar, but.
Speaker 2 (14:25):
Aren't the same, right, correct, They're related, but distinct. Accuracy
is about how close your clock is to the true
reference time. Like UTC, we measure it using time error.
Often the maximum absolute time error maxte is your clock
actually showing the right time. Stability, on the other hand,
is about how consistently your clock ticks does its rate
(14:46):
change over time. A clock could be very stable its
frequency doesn't drift much but still be inaccurate if it
was set wrong initially, or it could be unstable it's
rate wandering even if it happens to be accurate right now. Ideally,
for network timing, you want both high accuracy and high stability.
Speaker 1 (15:01):
Got Accurate means close to the truth. Stable means keeps
a steady beat. So looking ahead, we talked about that
demanding one point five microsecond absolute requirement from five G
relative to UTC, but the source material also mentions something
even tighter, e merging relative timing requirements between nearby five
G radios, sometimes needing alignment as close as sixty five nanoseconds.
Speaker 2 (15:21):
That's right. That relative requirement is incredibly tight. It's needed
for some of the really advanced five G features, like
coordinated multipoint comp where multiple cell sites coordinate transmissions to
your phone simultaneously, or for sophisticated massive MIMO antenna arrays.
These features only work if the radios involved are synchronized
(15:42):
to each other with extreme precision, far tighter than just
their individual alignment to UTC.
Speaker 1 (15:48):
Okay, sixty five nanoseconds relative alignment. So here's the final
thought we wanted to leave you the listener with. Today
we learned that half of any path asymmetry turns directly
into time air. If these new radio features demand relative
accuracy down to maybe sixty five nanoseconds between sites, what
kind of challenges does that create for the people designing
and running these transport networks, especially if they're getting their
(16:09):
timing signal maybe as a service over fiber circuits owned
by a third party, where they might not have full
control or visibility over the path symmetry.
Speaker 2 (16:17):
Yeah, that's the rub, isn't it. The margin for error
is just vanishingly small. Trusting that the underlying path provides
that level of nanosecond symmetry constantly, that's going to be
I think one of the next big headaches and opportunities
in network timing. How do you guarantee that?
Speaker 1 (16:33):
Definitely something to chew on. A fascinating look into an
invisible world. Thanks for joining us on the deep dive.
Welcome to the deep dive. Today, we're getting into something
fundamental but often totally invisible, network synchronization. And we're not
just talking about you know, knowing it's lunchtime. We mean
hyper precise time down to nanoseconds that underpins things like
five G automated trading.
Speaker 2 (00:18):
The works. It really does hold it all together. Our
mission today really is to get a handle on the
basics of this digital time. You know, what are the
different kinds of zync frequency, phase time, and how do
we actually get this level of precision across huge networks
down to the nanosecond. And there's a key point in
the source material too. When this stuff fails, it's sneaky.
Speaker 1 (00:39):
Yeah, that really jumped out. It says timing failures often
look like something else entirely.
Speaker 2 (00:43):
At first exactly. I remember back in my circuit board
design days, a clock problem could totally look like a
software bug or just weird logic makes it incredibly hard
to track down. Now, scale that up from one board
to say, a whole continence network, multiple vendors, different gear
a few microseconds off could look like a bad route,
a broken process. Really tough.
Speaker 1 (01:03):
Okay, so let's maybe start at the beginning time seems simple, yeah, right,
but trying to get everyone on the same page globally, Yeah,
that I complicated fast.
Speaker 2 (01:12):
Oh absolutely. I mean historically, every town just set its
clock by the sun. Noon was noon locally. Worked fine
until the trains came along. Suddenly you needed timetables that
worked across different zones. You couldn't have a train leaving
one town at two pm and arriving somewhere else, you know,
before two pm according to their clock. That push, that
(01:32):
need for consistency led to standardizing time ach wor Greenwich
Meantime GMT back in eighteen eighty four.
Speaker 1 (01:38):
Right, GMT. But today the standard is Coordinated Universal Time UTC.
What's the practical difference for most people or for these networks.
Speaker 2 (01:47):
Well, the core reference is different. UTC is what we
all use. Yeah, but it's based on International Atomic Time TAI.
TI comes from hundreds of atomic clocks around the world.
It's incredibly stable, just ticks a long perfectly, well almost perfectly.
It's continuous. But UTC is what we call discontinuous. We
sometimes have to add leap seconds.
Speaker 1 (02:04):
Ah, yes, leap seconds the bane of sysadminin's everywhere.
Speaker 2 (02:07):
Huh, exactly, They exist because the Earth's rotation isn't perfectly regular.
It wobbles a bit, so the IIRS, that's the International
Earth Rotation Service, they manage these leap seconds. The goal
is to keep UTC within zero point nine seconds of
the actual solar day, you know, based on Earth's spin.
Speaker 1 (02:25):
Okay, so if UTC is the gold standard, how do
we know what the real official UTC is like right
this second.
Speaker 2 (02:32):
That's the fascinating part. You don't not perfectly in real time.
Any time signal you get right now is an approximation,
a very very good one hopefully, but still an approximation.
The actual single official UTC value. It's only calculated after
the month ends. They gather data from all those atomic clocks,
globally process it, and then the BPM, the International Bureau
of Weights and Measures, publishes the definitive value in something
(02:54):
called circular t, usually a couple of weeks late.
Speaker 1 (02:57):
So the absolute truth about this very nanosecond we won't
know it for weeks.
Speaker 2 (03:01):
Pretty much kind of changes how you think about real time,
doesn't it.
Speaker 1 (03:04):
It really does? Okay? Knowing the official time is always
a bit delayed, that's a big takeaway. Now let's talk terminology.
Synchronization gets thrown around a lot, but the sources are clear.
There are three distinct types.
Speaker 2 (03:17):
Yeah, getting these straight is super important if you're dealing
with high performance networks. Let's maybe use an orchestra analogy.
Speaker 1 (03:23):
Okay, sound good. Let's start with frequency synchronization. What's that about.
Speaker 2 (03:27):
Frequency sync is about the rate of the clock, the
tempo maybe, or the pitch in music. So in the orchestra,
it's making sure two violins are playing the exact same
a you know, four hundred and forty hertz, four hundred
and forty oscillations per second. In a network device, it
means making sure its internal oscillator is ticking at the
(03:47):
correct speed, its nominal frequency. We can use external sources
like SINCSA, which we'll get to to make that much
more accurate. Instead of maybe being off by say four
point six parts per million, we can get down to
like sixteen parts per billion, much tighter control over the rate.
Speaker 1 (04:02):
Okay, so frequencies of the rate, the speed of the ticking.
What about phase synchronization? Then?
Speaker 2 (04:06):
Facinc is about aligning the tick itself, making sure the
ticks happen at the exact same instant. Back to the orchestra.
It's the conductor ensuring everyone hits the downbeat together right
on time. Phase is about the relative offset between clocks,
usually measured in tiny fractions of a second, milliseconds, microseconds, nanoseconds.
It's about agreeing on when now is.
Speaker 1 (04:27):
And the sources gave a really good, kind of stark
example of why phase matters so much in industry factory automation.
Speaker 2 (04:34):
Oh yeah, that's a perfect illustration. Imagine you've got two
robots passing a part between them. They're not using cameras,
they're just timed. Robot A let's go at say start
plus point four over zero seconds. Robot B needs to
grab it at exactly start plus point four zero zero
seconds for that to work. Their idea of when start
plus zero point zero zero theory happen has to be
(04:55):
absolutely identical. Now, their facecinc is a bit loose, maybe
only accurate to fifty milliseconds. Robot A might let go
fifty milliseconds before Robot B is ready, and bam, part
hits the floor, a physical failure caused by a tiny,
tiny timing error.
Speaker 1 (05:07):
Wow, so fifty milliseconds is enough to cause real physical problem.
Speaker 2 (05:10):
Absolutely shows you the stakes.
Speaker 1 (05:12):
That factory example really brings it home. Milliseconds matter physically,
but looking at the big data networks, the requirements are
pushing into micro seconds, even nanoseconds. Why such extreme precision
across whole continents?
Speaker 2 (05:26):
Right, It's not just factories. There are really three big
areas pushing this need for tighter and tighter timing.
Speaker 1 (05:31):
Okay, where should we start? Maybe one? We can perceive
directly audio and video.
Speaker 2 (05:35):
Yeah, av sync. Humans are surprisingly sensitive to this. Research
shows if the audio is ahead of the video by
just forty milliseconds that's less than two frames of video,
about twenty percent of people will notice it it feels wrong.
So for professional broadcast streaming movies, they use specific timing
profiles like SMPTE twenty five nine to two built on
(05:56):
PTP to keep audio and video locked tight.
Speaker 1 (05:59):
Okay, so av is on one. What about finance? You
mentioned high frequency trading earlier.
Speaker 2 (06:03):
Definitely a huge driver. This really kicked into high gear
with a regulation called MIFIED two from the EU back
in twenty fourteen. It basically mandated that all high frequency
trading transactions had to have super accurate time stamps. Traceable
time stamps. We're talking precision way beyond what older protocols
like MTP could reliably deliver. It became a legal necessity
(06:24):
for transparency, for proving when trades happened, preventing manipulation, they
needed microsecond Sometimes better accuracy makes sense.
Speaker 1 (06:33):
Legal compliance often pushes technology, but the sources suggests the
biggest driver, the one really pushing phasinc. Everywhere, is mobile
networks five G.
Speaker 2 (06:42):
Specifically, without a doubt, five G is the main engine
right now for widespread phase synchronization, deployment and transport networks.
The core reason is a technology called time division duplex
or TDD. In TDD, a base station uses the same
chunk of radio frequency to both transmit and receive. It
just switches really fast between the two. Now, imagine two
base stations near each other. If one is transmitting while
(07:02):
its neighbor is trying to receive on that same frequency,
you get massive interference. They jam each other.
Speaker 1 (07:07):
Uh okay. So they have to coordinate very very carefully
when they transmit and when they listen exactly.
Speaker 2 (07:12):
They need extremely tight phase alignment. The requirement is pretty stunning.
The time difference between any two neighboring base stations has
to be less than three microseconds, and the way networks
achieve that is by making sure every base station across
the entire network is synchronized to the master UTC reference
clock to within plus or minus one point five microseconds.
(07:32):
If everyone stays within that one point five microsecond window
relative to UTC, then any two neighbors will automatically be
within three microseconds of each other.
Speaker 1 (07:40):
Plus or minus one point five microseconds. Wow, that's the
tolerance across the whole system.
Speaker 2 (07:45):
Tolerance it's demanding.
Speaker 1 (07:46):
Okay, so we understand the need plus or minus one
point five microseconds for five G, even tighter for finance
in some cases, How do networks actually get this timing
signal and then distribute it reliably? Where does it originate?
Speaker 2 (08:01):
Well, the ultimate source, the primary reference time clocks or prtcs.
Those are generally the Global Navigation Satellite Systems GNSS, So
think GPS, which is the US system, gel NASS from Russia,
Galileo from Europe, bay DO from China. They are, in essence,
constellations of atomic clocks orbiting the Earth. They constantly broadcast
(08:22):
signals that include very precise timing information. Receivers on the
ground pick these up and can figure out their position,
and crucially for us, the current precise time. Got it?
Speaker 1 (08:30):
So the time comes from space basically. Then once a
receiver on the ground has that signal, how does it
get shared across say miles of fiber optic cable in
the finance port network. What tools do network designers use?
Speaker 2 (08:43):
There are two main specialized methods used often in combination.
The first one is called synchronous ethernet or sink.
Speaker 1 (08:49):
Okay, sink E. What's this role?
Speaker 2 (08:51):
Sink E is all about frequency synchronization, remember the rate
of the clock. It's actually built into the physical layer
of the ethernet connection, kind of like how older technologies
like SDH or sonnet handled frequency. It allows network devices
to pass along a very stable frequency reference directly over
the fiberlink itself, without needing special timing packets or relying
(09:13):
on software higher up. So it's very reliable, very predictable
for keeping the rate stable across the network carrier grade frequency.
Speaker 1 (09:20):
Okay, so SYNC nails the frequency. What about the actual
time of day, the phase alignment down to microseconds. That's
the other one. PTP exactly.
Speaker 2 (09:28):
PTP the precision time protocol that's defined by IE fifteen
eighty eight PTP is specifically designed to distribute precise phase
and time synchronization over packet networks. Like standard ethernet networks,
it aims for microsecond level accuracy, sometimes even better. The
key thing that makes PTP so much better than older
protocols like NTP is its use of hardware time stamping.
Speaker 1 (09:48):
Hardware time stamping what does that mean?
Speaker 2 (09:50):
It means the time stamps marking when a PTP timing
packet arrives or departs, are applied right at the network
interface card as close to the physical wire as possible.
If you rely on the main CPU or the operating
system to do the time stamping, you introduce all sorts
of delays and variability jitter that kills your accuracy. PTP
with hardware support bypasses a lot of that software unpredictability.
Speaker 1 (10:13):
Right, get the time stamp as close to the physical
event as possible makes sense. So SYNCY for frequency stability,
PTP for phase and time accuracy. How do operators get
the absolute best result? Do they choose one or the other?
Speaker 2 (10:26):
Usually for the most demanding applications like five G, they
use both together. It's often called hybrid mode. They use
sync along constantly on the physical layer to provide that
rock solid, stable frequency foundation, and then they run PTP
on top of that stable frequency to distribute the precise
phase and time information. This combination gives you the best
of both worlds, the stability of SYNC and the accuracy
(10:47):
of PTP. It's generally considered the gold standard for carrier
networks define inspects like the itut G point eight two
seven five point one profile for telecom. It provides deterministic performance.
Speaker 1 (10:59):
Okay, so hybrid mode seems like the way to go.
But even with the best protocols, the network itself can
fight back, right. The sources mentioned packet delay, variation, jitter,
and something called asymmetry as the main enemy. So let's
focus on asymmetry.
Speaker 2 (11:13):
What is that, ah, asymmetry. Yes, that's a really tricky
one for PTP. It's kind of the silent killer of
timing accuracy. See PTP works out the time it takes
for a packet to travel from the master clock to
the slave clock by measuring the total round trip time
and then dividing by two. It fundamentally assumes that the
path delay from master to slave is exactly the same
(11:35):
as the path delay from slave back to master.
Speaker 1 (11:37):
AH Okay, it assumes the journey takes the same amount
of time in both directions precisely.
Speaker 2 (11:42):
Asymmetry is simply when that assumption is wrong, when the
forward path delay is different from the reverse path delay.
Speaker 1 (11:48):
What could cause that?
Speaker 2 (11:49):
Yeah, different routs exactly. Maybe the packets go out via
one set of routers and fibers but come back via
completely different set due to network routing decisions. Or maybe
the five verer length itself is physically different in one
direction versus the other in some older setups. Or maybe
there's traffic congestion affecting delays only in one direction. Lots
of potential causes.
Speaker 1 (12:10):
Why is that so bad for PTP?
Speaker 2 (12:12):
Because of what some call the golden rule of packet timing,
half of the total path asymmetry shows up directly as
a constant time error a phase offset at the slave clock.
So if your network path has one hundred nanoseconds of asymmetry,
meaning the trip one way is one hundred thens longer
than the other way, your slave clock will be permanently
wrong by fifty nanoseconds. PDP can't easily detect or correct
(12:34):
for that on its own.
Speaker 1 (12:35):
Wow, fifty nanoseconds just baked in his error. Okay, that's
a huge deal when the total budget is only, say,
fifteen hundred nanoseconds. Yeah, so that's an internal network problem.
What about the sorts itself. We rely heavily on GNSS
those satellites. Are they vulnerable?
Speaker 2 (12:47):
Oh? Absolutely, that's a major concern. GENUSA signals are very
weak by the time they reach the ground. This makes
them susceptible to jamming, basically overpowering the signal with noise
so the receiver can't lock on. That's denial of service.
Even more worrying, perhaps, is spoofing. That's when an attacker
transmits fake GNSS signals to trick the receiver into calculating
(13:08):
the wrong time or position.
Speaker 1 (13:10):
So some could potentially feed incorrect time into the network
at its source.
Speaker 2 (13:14):
It's a known vulnerability. Yes, and because our critical infrastructure,
power grids, finance, mobile networks relies so heavily on GNSS timing,
this vulnerability is taken very seriously. Resilient backup timing sources
are becoming essential, not just nice to haves.
Speaker 1 (13:29):
Is that where things like h l RAN come in.
I saw that mention enhanced.
Speaker 2 (13:33):
Loran exactly A loran is being looked at and deployed
in some regions as a terrestrial backup or complement to
space based GNSS. Loran uses very powerful low frequency radio
transmitters on the ground. The signals are much harder to
jam than genss and can penetrate buildings, tunnels, even underground
to some extent where satellite signals can't reach. The goal
(13:55):
for l RAN is to provide UTC traceability potentially down
to the fifteen nanosecond level, offering a really robust alternative
if GNSS is unavailable or compromised.
Speaker 1 (14:05):
Interesting a ground based backup using very different technology.
Speaker 2 (14:08):
Yeah, diversity and sources is key for resilience. Hashtag tag outro.
Speaker 1 (14:11):
Okay, we'scovered a lot of ground here, from old town
clocks needing sun dials to needing nanoseca precision from space
and distributing it globally. Before we wrap up, let's quickly
just nail down the difference between two terms we used,
accuracy and stability. They sounds similar, but.
Speaker 2 (14:25):
Aren't the same, right, correct, They're related, but distinct. Accuracy
is about how close your clock is to the true
reference time. Like UTC, we measure it using time error.
Often the maximum absolute time error maxte is your clock
actually showing the right time. Stability, on the other hand,
is about how consistently your clock ticks does its rate
(14:46):
change over time. A clock could be very stable its
frequency doesn't drift much but still be inaccurate if it
was set wrong initially, or it could be unstable it's
rate wandering even if it happens to be accurate right now. Ideally,
for network timing, you want both high accuracy and high stability.
Speaker 1 (15:01):
Got Accurate means close to the truth. Stable means keeps
a steady beat. So looking ahead, we talked about that
demanding one point five microsecond absolute requirement from five G
relative to UTC, but the source material also mentions something
even tighter, e merging relative timing requirements between nearby five
G radios, sometimes needing alignment as close as sixty five nanoseconds.
Speaker 2 (15:21):
That's right. That relative requirement is incredibly tight. It's needed
for some of the really advanced five G features, like
coordinated multipoint comp where multiple cell sites coordinate transmissions to
your phone simultaneously, or for sophisticated massive MIMO antenna arrays.
These features only work if the radios involved are synchronized
(15:42):
to each other with extreme precision, far tighter than just
their individual alignment to UTC.
Speaker 1 (15:48):
Okay, sixty five nanoseconds relative alignment. So here's the final
thought we wanted to leave you the listener with. Today
we learned that half of any path asymmetry turns directly
into time air. If these new radio features demand relative
accuracy down to maybe sixty five nanoseconds between sites, what
kind of challenges does that create for the people designing
and running these transport networks, especially if they're getting their
(16:09):
timing signal maybe as a service over fiber circuits owned
by a third party, where they might not have full
control or visibility over the path symmetry.
Speaker 2 (16:17):
Yeah, that's the rub, isn't it. The margin for error
is just vanishingly small. Trusting that the underlying path provides
that level of nanosecond symmetry constantly, that's going to be
I think one of the next big headaches and opportunities
in network timing. How do you guarantee that?
Speaker 1 (16:33):
Definitely something to chew on. A fascinating look into an
invisible world. Thanks for joining us on the deep dive.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.