TL;DR
- ▸G.8275.1 = telecom with full timing support, multicast over Ethernet, layer 2. The default for 5G fronthaul.
- ▸G.8275.2 = telecom with partial timing support, unicast over IP. Used when intermediate switches are not PTP-aware.
- ▸ST 2110 = SMPTE broadcast video infrastructure. Different defaults to telecom; often coexists with PTP for reference time.
- ▸Default profile = IEEE 1588v2 baseline. Fine for closed lab networks, almost never the right answer in production.
Why profiles exist (and why getting this wrong burns weeks)
The IEEE 1588v2 standard is intentionally flexible. It defines a protocol with many configurable parameters — message rates, BMCA priorities, transport mechanisms, port states — and leaves it to deployment-specific "profiles" to set sensible defaults for particular industries. A PTP profile is a constrained subset of the standard, with specific values nailed down so that two devices from different vendors implementing the same profile can interoperate without per-device configuration tuning.
Profile selection is the single most common source of "PTP works in the lab but breaks in production" incidents. A grandmaster shipped with default-profile defaults dropped into a G.8275.1 telecom network will produce announce-message timeouts, BMCA priority confusion and silent drift. The protocol is technically the same; the timing and priority assumptions are not.
Choosing the right profile is the easy part. Making sure every PTP-aware device on the network is configured for the same profile, with consistent priorities and message rates, is where deployments succeed or fail.
G.8275.1 — telecom full timing support
ITU-T G.8275.1 is the dominant PTP profile in modern telecom networks, and the only profile recommended by 3GPP for 5G fronthaul timing. It assumes a network where every intermediate switch and router is PTP-aware ("full timing support from the network"), and it operates over Ethernet using multicast PTP messages, layer 2 only.
G.8275.1 nails down a specific set of message rates: announce messages every 1 second, sync messages 16 times per second, delay-request messages 16 times per second. It defines specific BMCA priority handling, with priority1 fixed at 128 for ordinary boundary clocks (so the BMCA decisions cascade entirely from clockClass and clockAccuracy fields) and explicit rules for how grandmaster failover should propagate down a long chain of boundary clocks.
The key point about G.8275.1 is that it requires every hop to be a PTP boundary or transparent clock — there is no notion of "transparent transit" through unmanaged switches. This is fine in a greenfield 5G fronthaul build where you control the entire timing fabric. It is not fine in an enterprise network where you have a mix of PTP-aware and PTP-naive equipment. For the latter case, you want G.8275.2.
When to use it
G.8275.1 is the right answer for 5G fronthaul, O-RAN deployments, telecom backhaul, mobile networks targeting Class 6 (±1.5 µs) or Class 6A (±1.1 µs) accuracy, and any network where you control every PTP-aware device end to end.
G.8275.2 — telecom partial timing support
ITU-T G.8275.2 is the answer when you don't have full PTP support across the network — typically because you're delivering timing across a third-party transport network, or because some intermediate equipment can't be upgraded to PTP-aware. Instead of multicast over Ethernet, G.8275.2 uses unicast PTP over IP, which means PTP messages can traverse unmanaged switches and routers without needing them to be PTP-aware (at the cost of variable network delay, which the grandmaster and slave have to compensate for).
G.8275.2 is much more forgiving operationally — it works in messy real-world topologies — but the achievable accuracy is materially worse than G.8275.1 because the network is no longer compensating for asymmetric latency hop by hop. For 5G fronthaul, G.8275.2 is generally too loose; for telecom backhaul, mobile core sync, and time-of-day distribution to enterprise edge, it's often the only viable option.
The other major operational difference: G.8275.2 uses unicast PTP, which means each PTP slave establishes a unicast session with the grandmaster individually. This puts a non-trivial CPU load on the grandmaster as the number of slaves grows; large G.8275.2 deployments need to plan for grandmaster scaling in a way that G.8275.1 deployments don't.
SMPTE ST 2110 — broadcast IP infrastructure
The SMPTE ST 2059-2 PTP profile (commonly referred to as the "ST 2110" profile because it's used for ST 2110 IP-based broadcast production) is the dominant PTP profile in professional broadcast and live media production. It's used by every major broadcaster running an IP-based studio infrastructure, and it's the timing reference behind IP audio standards like AES67 and Ravenna.
ST 2110 PTP defines a different set of message rates from telecom profiles (typically 8 sync messages per second, 8 delay-request messages per second), and it uses multicast over IP rather than multicast over Ethernet. The BMCA configuration is also distinct — broadcast networks often run a single primary grandmaster and a backup, with the backup priority configured for graceful failover during a maintenance window rather than for hot standby.
Broadcast networks frequently coexist with telecom networks (a broadcast facility may receive its reference time from an external GNSS-locked grandmaster, then distribute internally via ST 2110). This means a real-world broadcast deployment may need a grandmaster that can simultaneously run multiple PTP profiles on different ports — for example, ST 2110 on the studio LAN and G.8275.2 to the WAN. Confirm this capability explicitly with vendors.
The IEEE 1588v2 default profile (and why you should rarely use it)
Annex J of IEEE 1588-2008 defines a "default" PTP profile — essentially the protocol with reasonable defaults for general-purpose lab and enterprise use. It uses multicast over Ethernet or IP, sync messages once per second, delay-request messages once per second, and a permissive BMCA configuration. It is the simplest profile to set up and the easiest to interoperate against.
It is also rarely the right answer in production. The default profile's slow message rates (1 Hz) make it slow to react to network events; its permissive BMCA configuration makes it sensitive to misconfigured downstream devices; and its lack of telecom or broadcast-specific assumptions means it doesn't interoperate cleanly with the equipment you'll actually deploy alongside it.
The default profile's correct use case is exactly what its name suggests: a default, for development environments, lab benches and proof-of-concept builds. If you're running PTP in production over the default profile, it's almost certainly because nobody made an explicit decision and the equipment shipped that way. That's fixable, and worth fixing.
Mixing profiles: when and how
Real networks frequently need to support more than one PTP profile simultaneously. A broadcast facility may run ST 2110 on its studio LAN and consume reference time over G.8275.2 from a colocation provider. A telecom operator may run G.8275.1 in the radio access network and G.8275.2 in the core. A financial venue may run the default profile on a development network alongside a G.8275.1 production deployment.
Mixing profiles is supported, but it requires the grandmaster to be explicitly configured per port — different ports running different profiles, with their own BMCA configuration, message rates and transport mechanism. Not all grandmasters support per-port profile selection; the ones that don't will force you to deploy separate physical grandmasters per profile, which is expensive and operationally noisy.
If your deployment may mix profiles, confirm explicit per-port profile support with the vendor before purchase. "Supports G.8275.1 and ST 2110" is not the same as "supports G.8275.1 on port 1 and ST 2110 on port 2 simultaneously." The latter is what you actually need.
Frequently asked questions
What is the difference between G.8275.1 and G.8275.2?+
Which PTP profile is used for 5G fronthaul?+
Can a single PTP grandmaster run multiple profiles?+
What PTP profile does broadcast IP video use?+
Is the default IEEE 1588 profile suitable for production?+
Related guides
Pillar guide · PTP
PTP Grandmaster Clock: The Complete 2026 Guide
What a PTP grandmaster clock actually does, how to choose one, and what separates a grandmaster you can trust from one that quietly drifts. Written by TimeBeat's engineering team for network architects deploying IEEE 1588 in production.
Pillar guide · 5G fronthaul
5G Fronthaul Timing: The Complete 2026 Guide
How precision timing actually works in 5G fronthaul networks — the time-error budget, the ITU-T accuracy classes, the role of G.8275.1, and what it takes to operate a fronthaul timing fabric without dropping calls or losing handovers. Written by TimeBeat's engineering team for mobile network operators and O-RAN integrators.
Cluster · G.8275.1
ITU-T G.8275.1 Explained: The Telecom PTP Profile for 5G Fronthaul
What ITU-T G.8275.1 actually specifies, why it's the only PTP profile that meets the 5G fronthaul time-error budget, and what to look for in a grandmaster claiming G.8275.1 support.