PTP Telecom Profiles Explained: G.8275.1 vs G.8275.2
PTP has one base standard, IEEE 1588, but mobile networks do not run the default settings. They run one of two telecom profiles defined by the ITU-T: G.8275.1, which demands that every single device on the timing path takes part in PTP, and G.8275.2, which lets timing cross ordinary routers that know nothing about it. Same protocol, same goal — phase accurate to within plus-or-minus 1.5 microseconds at the radio — and a completely different set of promises about what the network underneath has to do. This article explains both profiles in plain English, side by side.
The short answer
The difference between G.8275.1 and G.8275.2 is one question: does every box on the path help carry the time? PTP — the Precision Time Protocol, IEEE 1588 — is one protocol with a large menu of options, and a profile is a fixed selection from that menu, chosen so that equipment from different vendors makes the same choices and can work together. The telecom industry, through the ITU-T, defined two profiles for delivering phase and time (not just frequency) to mobile networks. G.8275.1 is the profile "with full timing support from the network": every device the timing passes through is itself a PTP clock that measures, corrects and re-serves the time, hop by hop. G.8275.2 is the profile "with partial timing support": the timing flows as ordinary IP traffic and some — or most — of the devices in between know nothing about PTP at all.
Think of two ways to pass a message across a country. G.8275.1 is a relay race: every runner is trained, every handover is timed, and each leg's time is measured, so the total is known precisely. G.8275.2 is posting a letter: the postal network in the middle is not yours and does not stop to help — the letter still arrives, and for many purposes it arrives well enough, but nobody measured each leg of its journey, and a slow sorting office adds delay you never see. Neither is "the good one." They are answers to two different situations: a network you control end to end, and a network you do not.
Why mobile networks need this at all
Older mobile networks mostly needed frequency: every base station transmitting at the right rate. Modern networks using TDD (Time Division Duplex) also need phase and time. In TDD, the uplink (phones talking) and the downlink (the tower talking) share the same frequency and take turns. If neighbouring towers disagree about when a turn starts, one tower's downlink bleeds into another's uplink and capacity at the cell edge collapses. So the towers must switch together, tightly: ITU-T G.8271 sets the end-to-end limit at plus-or-minus 1.5 microseconds between a common reference and the radio — a window of 3 microseconds between neighbouring base stations — and part of that budget (about 400 nanoseconds in the usual allocation) is reserved for the radio itself, leaving roughly plus-or-minus 1.1 microseconds for everything the network does on the way. Some advanced features tighten the relative alignment between cooperating radios far further, to the order of 130 nanoseconds.
One and a half microseconds is a small budget to spend across a chain of switches and routers spanning a city. Every hop either spends it carefully — measuring and correcting its own contribution — or spends it blindly. That single fact is what splits the two profiles: G.8275.1 is the design where every hop accounts for itself, and G.8275.2 is the design that accepts blind hops because the alternative is no timing service at all.
G.8275.1: the relay race (full timing support)
G.8275.1 assumes a timing-aware network and makes the most of it. Every network element on the path participates in PTP: the grandmaster (telecom naming: T-GM) serves boundary clocks (T-BC), each boundary clock re-serves time on its other ports, and transparent clocks (T-TC) may stamp their residence time where a full boundary clock is not used. Because timing is rebuilt at every hop, no single hop's queueing delay goes unmeasured — the error that accumulates is the small, specified per-hop error of each clock, which is why this profile is the one mobile fronthaul and 5G transport designs reach for when the accuracy budget is tight.
The transport matches the hop-by-hop design: PTP runs over Ethernet, in multicast mode, between directly connected neighbours. Multicast is efficient here — one stream per link serves every listener, so the grandmaster does not carry a per-client session for every clock in the city. The profile's usual domain is 24. The price is written into the assumption: the moment a path includes a device that does not speak this profile — a leased line from another operator, an older router, a segment you do not control — the chain is broken, because that device cannot re-serve or correct the time and the hop-by-hop accounting stops.
G.8275.2: the letter in the post (partial timing support)
G.8275.2 was defined for exactly the networks where G.8275.1's assumption fails. Timing runs over IP — IPv4 or IPv6 — in unicast mode: the end clock holds a session directly with a grandmaster (found by configuration and unicast negotiation, not by listening for multicast), and the packets cross whatever routers lie between as high-priority traffic. The nodes in between do not need to participate, and do not need to be directly connected to anything timing-related; PTP ports in this profile are typically tied to a loopback address rather than to one physical interface. The usual domain is 44.
This reaches places the relay race cannot: across leased capacity, across an older transport network, to a site whose path the operator does not fully own. It is how many 4G networks were timed, and it remains the practical answer where upgrading every hop is not an option. The costs are the mirror image of G.8275.1's strengths. Unicast means the grandmaster carries one session per client — designs plan for hundreds of clients per grandmaster, and up to several thousand in some cases. And because the middle hops do not correct anything, their queueing delay and any difference between the forward and return paths land directly in the end clock's error. PTP's maths assumes the two directions take the same time; a widely used rule of thumb is that every 2 microseconds of asymmetry becomes 1 microsecond of time error — most of the entire budget, from one invisible cause. Partial support can meet the requirement on a quiet, well-engineered path; it has far less margin when the path gets busy or reroutes.
Side by side
| Question | G.8275.1 | G.8275.2 |
|---|---|---|
| Timing support assumed | Full — every node on the path is PTP-aware | Partial — only the ends need to be |
| Transport | Ethernet, multicast, hop by hop between neighbours | IP (IPv4/IPv6), unicast sessions end to grandmaster |
| Usual domain | 24 | 44 |
| Devices in the middle | Boundary clocks re-serve time; transparent clocks stamp residence time | Ordinary routers forwarding priority traffic; no correction |
| Works over leased / third-party capacity? | No — the chain breaks at the first non-PTP hop | Yes — that is its main reason to exist |
| Grandmaster load | Low per client — multicast serves a link, boundary clocks fan out | One unicast session per client — plan client capacity |
| Main accuracy risk | Per-hop clock error accumulating over many hops | Unseen queueing delay and forward/return asymmetry |
| Typical home | 5G fronthaul and modern PTP-aware transport | 4G backhaul, older or leased transport, gradual upgrades |
One family member worth naming so it does not cause confusion in job ads and vendor menus: G.8265.1 is the older telecom profile for frequency only. If a design only needs every clock ticking at the same rate — and not agreeing on the time of day — that is the profile it uses. The two G.8275 profiles exist because TDD radios need the harder thing.
The election is different here too: alternate BMCA
Both telecom profiles replace PTP's default grandmaster election with an alternate BMCA, and the change that surprises engineers arriving from the default profile is this: priority1 is not used. It is fixed at 128 in these profiles, so the trick from the default profile — pinning a preferred grandmaster with a low priority1 — simply does not exist here. Preference is expressed instead with priority2 and with a local priority: a per-port setting (default 128) that tells a clock which of its own ports' candidates it should prefer, so topology — "prefer the path through this port" — can decide between otherwise equal grandmasters. The profiles also add a per-port flag (called notSlave in G.8275.1, masterOnly in G.8275.2 wording) that forbids a port from ever taking time in, for ports that must only ever serve. The election's goal is unchanged — one grandmaster, one tree, agreed by everyone — but if you troubleshoot a telecom timing network with default-profile instincts, the knob you reach for first is not connected to anything.
Both profiles are also commonly run in hybrid mode with SyncE underneath: SyncE carries a clean frequency over the physical layer, which steadies each clock's oscillator, while PTP carries phase and time on top. Frequency help does not change which profile you are running — it makes either profile's clocks behave better between PTP corrections.
Choosing between them, honestly
The decision is mostly made by the network you actually have. If you control every hop between the grandmaster and the radios, and those hops are PTP-aware, G.8275.1 gives you measured, corrected, per-hop timing and the most margin against the 1.5-microsecond budget — choose it. If any part of the path is leased, third-party, or simply too old to participate, G.8275.1 is not a worse choice, it is a non-choice: the chain cannot form, and G.8275.2 is how timing gets there at all. Many real networks run both at once in different places — full support in the new fronthaul, partial support across the legacy backhaul — with a boundary clock translating at the seam, which is a supported design (vendors call it multiprofile translation), not a hack. What you cannot do is mix the two profiles, or their domains, on the same timing segment and expect them to interoperate: a domain-24 G.8275.1 clock and a domain-44 G.8275.2 clock are holding different elections in different languages, and neither will ever elect the other.
Four profile mistakes that actually happen
1. Expecting G.8275.2 to match G.8275.1 accuracy on a busy path. Partial support's error includes whatever the unaware middle does. On a quiet path that can be small; under load or after a reroute, queueing and asymmetry grow invisibly. Budget for it, measure at the end clock, and do not promise fronthaul-grade numbers from a backhaul-grade design.
2. One non-PTP hop hiding in a G.8275.1 design. The chain is only as full-support as its least capable hop. A single ordinary switch inserted during a repair quietly converts that segment into uncorrected timing while every dashboard still says "G.8275.1." Verify the actual path, hop by hop, not the design document.
3. Trying to pin the grandmaster with priority1. In these profiles priority1 is fixed and ignored by the alternate BMCA. The preference you think you set is not set. Use priority2 and local priority — and then verify the election result on two different clocks.
4. Profile or domain mismatch at the seam. Two clocks that cannot see each other's Announce messages do not argue; they each conclude they are alone and elect themselves or a local free-running clock. When a segment "has no grandmaster," check profile and domain before checking the grandmaster itself.
Try it yourself
The profiles decide how time travels; the free tools below let you price what arrives. The PTP timing budget calculator adds up the per-hop error of a G.8275.1-style chain, so you can watch a boundary-clock chain spend the 1.5-microsecond budget hop by hop. The PTP/SyncE timing simulator models a whole timing tree over time — including what happens while a grandmaster is lost and the tree re-roots. Start with the budget calculator: build the chain from this article, then add hops until the budget breaks, and you will know exactly why profile choice and hop count are the same conversation.
- A PTP profile is a fixed selection of PTP options for one job. The two telecom profiles for phase and time are ITU-T G.8275.1 and G.8275.2, both built on IEEE 1588 and both aimed at mobile networks, where TDD radios need time within plus-or-minus 1.5 microseconds of a common reference (ITU-T G.8271).
- G.8275.1 is the full-timing-support profile: every device on the path is a PTP boundary or transparent clock, timing travels as Ethernet multicast from hop to directly connected hop, and the usual domain is 24. Accuracy is high because every hop measures and corrects its own delay.
- G.8275.2 is the partial-timing-support profile: timing travels as IP unicast (IPv4 or IPv6) and can cross ordinary routers that do not support PTP at all; nodes do not need to be directly connected, and the usual domain is 44. It reaches networks G.8275.1 cannot — including leased capacity — but unseen queues and path asymmetry cost accuracy.
- Both profiles replace the default election with an alternate BMCA: priority1 is fixed at 128 and is not used, so preference is expressed with priority2 and a per-port local priority (default 128) instead. Mixing the two profiles, or the two domains, on one timing path gives you two separate timing worlds, not one working one.