PTP协议精讲(2.3):时间护照与签证——PTP域和时间尺度完全解读
2.3 时间护照与签证:PTP域和时间尺度
一张时间旅行的"护照"
想象你要出国旅行。
首先,你需要一本护照,证明你是哪个国家的公民。护照上有你的国籍、护照号码、有效期。
其次,你需要签证,允许你进入目标国家。签证规定了你可以停留多久、可以做什么。
最后,你需要注意时区。你从北京飞到纽约,手表要调慢12小时,否则你的时间和当地时间就对不上。
PTP网络中的"跨国旅行",也需要类似的机制:
- 域(Domain) = 护照(你是哪个"时间国家"的公民)
- 时间尺度(Timescale) = 时区(你使用什么"时间标准")
- 溯源信息(Traceability) = 签证(你的时间从哪里来,是否可信)
域:时间的"国籍"
为什么需要域?
场景一:一座智能工厂
一座智能工厂,有三条生产线:
- 生产线A:生产芯片,设备需要纳秒级同步,使用PTP over以太网
- 生产线B:装配汽车,设备需要毫秒级同步,使用PTP over以太网
- 监控系统:监控环境参数,秒级同步就够了,使用NTP
问题来了:这三套系统都连接在同一个物理网络上。如果它们使用同一个PTP域,会发生什么?
混乱场景:
生产线的PTP设备可能误同步到监控系统的NTP时间源(如果NTP设备也支持PTP)。监控系统的低精度时间"污染"了生产线的高精度同步。
或者,BMCA可能选举出一个监控系统的设备作为主时钟,导致生产线精度下降。
解决方案:使用不同的域。
- 生产线A:domainNumber = 0
- 生产线B:domainNumber = 1
- 监控系统:不使用PTP,或domainNumber = 2
PTP报文的头部携带domainNumber,设备只处理与自己domainNumber匹配的报文。不同域的报文互不干扰。
域标识符:domainNumber和sdoId
PTP使用两个字段来标识域:
domainNumber:主域标识
- 类型:UInteger8(0-255)
- 作用:用户可配置的主要隔离机制
- 默认值:0
分配规则:
| domainNumber范围 | 用途 |
|---|---|
| 0-127 | 用户自定义(默认使用) |
| 128-239 | 特殊用途(部分保留) |
| 240-255 | 保留,不得使用 |
注意:不同传输协议对domainNumber的范围有限制。例如,PTP over IEEE 802.3(二层以太网)允许使用0-127,但PTP over UDP/IPv4/IPv6(三层)可以使用更大的范围。
sdoId:标准组织隔离
- 类型:12位整数(0-4095)
- 作用:隔离不同标准组织定义的Profile
- 结构:高4位 = majorSdoId,低8位 = minorSdoId
为什么需要sdoId?
不同标准组织可能定义不同的PTP Profile(配置规则)。例如:
- IEEE 802.1 定义了802.1AS(音视频桥接)
- ITU-T 定义了G.8275.1(电信时间同步)
- IEC 定义了IEC 62439-3(工业网络)
这些Profile有不同的默认值、不同的选项要求。如果它们使用相同的domainNumber,不同Profile的设备可能相互干扰。
sdoId分配:
| sdoId范围 | 用途 | 管理方 |
|---|---|---|
| 0x000 | 默认(无特殊Profile) | — |
| 0x100 | IEEE 802.1 Profile | IEEE 802.1工作组 |
| 0x200 | 公共平均链路延迟服务 | IEEE 1588工作组 |
| 0x300-0xFFC | QSDO注册的Profile | 从IEEE RA申请 |
| 0xFFD, 0xFFE | 实验性使用 | 临时 |
| 0xFFF | IEEE 1588工作组保留 | IEEE 1588工作组 |
QSDO是什么?
QSDO = Qualified Standards Development Organization(合格标准制定组织)。
要成为QSDO,需要满足:
- 组织成员来自多家公司或学术/政府实体
- 不被单一实体主导
- Profile需通过成员投票或正式程序批准
QSDO可以向IEEE RA申请唯一的sdoId,用于标识其定义的Profile。
域隔离的实际效果
场景:一个同时运行IEEE 802.1AS和ITU-T G.8275.1的网络。
- IEEE 802.1AS设备:domainNumber = 0, sdoId = 0x100
- ITU-T G.8275.1设备:domainNumber = 0, sdoId = 0x300(假设ITU-T申请了这个值)
结果:
802.1AS设备收到G.8275.1设备的Announce报文时:
- 检查domainNumber:都是0,匹配
- 检查majorSdoId:0x100 vs 0x300,不匹配
- 丢弃报文,不处理
反过来也一样,G.8275.1设备也会丢弃802.1AS设备的报文。
两套PTP网络在同一物理网络上独立运行,互不干扰。
时间尺度:时间的"时区"
两种时间尺度
PTP支持两种时间尺度:
PTP时间尺度(PTP Timescale)
定义:
- 纪元:1970年1月1日00:00:00 TAI
- 秒长:TAI秒(SI秒,国际原子时定义的秒)
- 溯源:可溯源到国际标准
关键概念:TAI(国际原子时)
TAI = International Atomic Time,由国际计量局(BIPM)维护。
TAI基于全球约400台原子钟的平均值,使用SI秒(铯-133原子跃迁定义的秒)作为时间单位。
TAI的特点:
- 稳定:不随地球自转变化
- 均匀:不会因为闰秒而跳变
- 可溯源:可以追溯到国际标准
PTP时间与TAI的关系:
PTP时间 = TAI时间
完全相同,PTP纪元就是TAI的1970年1月1日00:00:00。
ARB时间尺度(Arbitrary Timescale)
定义:
- 纪元:由管理过程设置
- 秒长:由主时钟确定
- 溯源:无法溯源到国际标准
适用场景:
- 工业控制:设备只需要内部时间一致,不需要与外部时间对齐
- 实验室测试:测试PTP功能,不需要真实时间
- 封闭网络:与外界隔离的网络,时间可以任意设置
ARB的使用方式:
主时钟可以说:“现在的时间是1000秒”。所有从时钟跟随主时钟,也都认为现在是1000秒。
这个"1000秒"是什么意思?没关系,只要大家都认为现在是1000秒,同步就能工作。
注意:ARB时间尺度下,UTC偏移(currentUtcOffset)无效,因为ARB时间无法转换为UTC。
PTP时间 vs UTC时间:关键区别
UTC(协调世界时):
- 基于TAI,但为了与地球自转保持同步,会插入闰秒
- UTC = TAI - 累积闰秒
- 截至2026年,累积闰秒 = 37秒
PTP时间:
- 就是TAI时间
- 不会因为闰秒而跳变
- PTP时间 = UTC + 累积闰秒
示例:
某个时刻:
- UTC时间:2026-01-01 00:00:00
- PTP时间:2026-01-01 00:00:37(快了37秒)
为什么要用PTP时间而不是UTC?
原因一:避免闰秒导致的跳变
UTC会插入闰秒。当闰秒发生时,UTC时间会从23:59:59跳到23:59:60,然后再到00:00:00。
这种跳变对同步系统是灾难性的。如果主时钟和从时钟处理闰秒的方式不同,会导致时间突然差1秒。
PTP时间不插入闰秒,永远不会跳变,稳定性更好。
原因二:时间间隔计算
如果用UTC计算时间间隔,闰秒会导致问题。
假设你在23:59:58开始计时,到00:00:01结束。正常情况下,间隔应该是3秒。但如果中间插入了闰秒(23:59:60),实际间隔是4秒,但计算出来还是3秒(因为时钟只显示59→60→00→01)。
PTP时间没有闰秒,时间间隔计算永远是准确的。
从PTP时间计算UTC:currentUtcOffset
PTP设备如何知道UTC时间?
答案:通过currentUtcOffset字段。
currentUtcOffset:
- 定义:TAI - UTC的当前值
- 单位:秒
- 来源:IERS Bulletin C(国际地球自转和参考系统服务公告)
工作原理:
主时钟(通常接GPS)从GPS信号中提取当前闰秒累积值,写入Announce报文的currentUtcOffset字段。
从时钟收到Announce报文后,就知道:
UTC时间 = PTP时间 - currentUtcOffset
示例:
PTP时间:2026-01-01 00:00:37
currentUtcOffset:37
UTC时间 = 00:00:37 - 37 = 00:00:00
闰秒预告:leap59和leap61
闰秒不是突然发生的,而是提前公告的。
IERS会提前几个月发布闰秒预告:“在某年某月某日,将插入一个正闰秒。”
PTP通过两个标志位传递这个预告:
leap61:正闰秒标志
- 含义:当月最后一分钟将有61秒(插入一个闰秒)
- 取值:TRUE或FALSE
leap59:负闰秒标志
- 含义:当月最后一分钟将有59秒(删除一个闰秒)
- 取值:TRUE或FALSE
注意:到目前为止,从未发生过负闰秒。地球自转一直在变慢,所以只插入正闰秒。
闰秒发生时的PTP行为:
主时钟(接GPS):
- GPS信号会提前告知闰秒信息
- 主时钟在闰秒发生前的Announce报文中设置leap61=TRUE
- 闰秒发生后,currentUtcOffset加1
从时钟:
- 收到leap61=TRUE的Announce报文
- 知道即将发生闰秒,准备调整UTC计算
- 闰秒发生后,使用新的currentUtcOffset计算UTC
关键点:PTP时间本身不变,只有UTC计算发生变化。
溯源信息:时间的"签证"
什么是溯源(Traceability)?
定义:测量结果或标准值的属性,使其能够通过具有规定不确定度的不间断比较链与规定的参考相关联。
通俗地说:你的时间是从哪里来的?来源可靠吗?能追溯到国际标准吗?
traceability标志
PTP定义了两个溯源标志:
timeTraceable:时间可溯源
- 含义:主时钟的时间可以追溯到国际标准(如UTC)
- 典型来源:GPS、GLONASS、Galileo、国家时间实验室
示例:
主时钟接了GPS天线,GPS时间可追溯到美国海军天文台(USNO),USNO的时间可追溯到国际原子时(TAI)。
这个链条是连续的、有文档记录的,因此主时钟可以声明timeTraceable=TRUE。
frequencyTraceable:频率可溯源
- 含义:主时钟的频率可以追溯到国际标准
- 典型来源:同步以太网(SyncE)、铷原子钟、铯原子钟
示例:
主时钟从同步以太网获取频率信号,同步以太网的频率来自电信运营商的网络,运营商的频率来自铯原子钟,铯原子钟的频率可追溯到SI秒定义。
因此,主时钟可以声明frequencyTraceable=TRUE。
timeSource:时间源类型
Announce报文中携带timeSource字段,指示主时钟的时间来自哪种类型的源。
枚举值:
| 值(十六进制) | 时间源 | 说明 |
|---|---|---|
| 0x10 | ATOMIC_CLOCK | 原子钟(铯钟、铷钟) |
| 0x20 | GNSS | 全球导航卫星系统(GPS、GLONASS、Galileo、北斗) |
| 0x30 | TERRESTRIAL_RADIO | 地面无线电授时(如WWVB、BPC) |
| 0x40 | PTP | 从另一个PTP域获取时间 |
| 0x50 | NTP | 从NTP服务器获取时间 |
| 0x60 | HAND_SET | 人工设置 |
| 0x90 | OTHER | 其他 |
| 0xA0 | INTERNAL_OSCILLATOR | 内部振荡器 |
timeSource的作用:
- 信息性:不参与BMCA决策
- 诊断性:帮助管理员了解主时钟的时间来源
- 审计性:用于时间溯源审计
一个完整的时间信息传递示例
让我们用一个完整的例子,演示时间信息如何在PTP网络中传递。
网络拓扑:
GPS卫星
↓
主时钟A(接GPS天线 + 铷原子钟)
↓
边界时钟B
↓
从时钟C(5G基站)
主时钟A的数据:
| 字段 | 值 | 说明 |
|---|---|---|
| clockClass | 6 | 直接同步到GPS |
| clockAccuracy | 0x20 | 精度≤25纳秒 |
| ptpTimescale | TRUE | 使用PTP时间尺度 |
| timeTraceable | TRUE | 时间可溯源到GPS |
| frequencyTraceable | TRUE | 频率可溯源到铷钟 |
| timeSource | 0x20(GNSS) | 时间来自GPS |
| currentUtcOffset | 37 | TAI-UTC = 37秒 |
| leap61 | FALSE | 本月无闰秒 |
| leap59 | FALSE | 无负闰秒 |
Announce报文:
主时钟A发送Announce报文,携带上述所有信息。
边界时钟B的处理:
-
接收Announce报文
-
提取时间信息
-
更新自己的数据集:
- parentDS.grandmasterIdentity = A的clockIdentity
- parentDS.grandmasterClockQuality = A的clockQuality
- timePropertiesDS.currentUtcOffset = 37
- timePropertiesDS.timeTraceable = TRUE
- 等等
-
转发Announce报文(某些字段需要更新,如stepsRemoved + 1)
从时钟C的接收:
- 接收边界时钟B转发的Announce报文
- 提取时间信息
- 更新自己的数据集
从时钟C如何获取UTC时间?
从时钟C的本地PTP时间(通过同步获得):
PTP时间 = 2026-01-01 00:00:37(主时钟A的时间)
从Announce报文获取:
currentUtcOffset = 37
计算UTC:
UTC时间 = PTP时间 - currentUtcOffset
UTC时间 = 2026-01-01 00:00:37 - 37 = 2026-01-01 00:00:00
从时钟C的应用层:
5G基站的应用层需要UTC时间(用于日志时间戳、调度等)。
基站内部实现:
- PTP协议栈维护PTP时间
- 应用层调用API获取时间时,PTP协议栈自动减去currentUtcOffset,返回UTC时间
时间尺度转换的实际问题
问题一:GPS时间 vs UTC时间
背景:
GPS时间也是一个连续的时间尺度,不插入闰秒。但GPS纪元与PTP纪元不同。
- GPS纪元:1980年1月6日00:00:00 UTC
- PTP纪元:1970年1月1日00:00:00 TAI
GPS接收机输出的时间通常是GPS时间,或者UTC时间(从GPS时间减去累积闰秒)。
转换:
如果主时钟接GPS,需要知道GPS接收机输出的是哪种时间:
- 输出GPS时间:需要加上GPS-UTC偏移(截至2026年是18秒),得到TAI时间,即PTP时间
- 输出UTC时间:需要加上累积闰秒(截至2026年是37秒),得到PTP时间
配置示例:
# 主时钟配置(假设GPS接收机输出UTC时间)
ptp timescale ptp
ptp current-utc-offset 37 # 配置当前闰秒值
ptp time-traceable true
ptp frequency-traceable true
ptp time-source gnss
问题二:NTP时间 vs PTP时间
背景:
NTP(Network Time Protocol)是互联网上最常用的时间同步协议。
NTP时间:
- 纪元:1900年1月1日00:00:00 UTC
- 时间表示:32位秒 + 32位小数秒
- 时间回绕:约每136年回绕一次(2036年会回绕)
问题:
如果一个PTP主时钟从NTP服务器获取时间,需要注意:
- NTP时间通常有毫秒级误差,不能提供纳秒级精度
- NTP时间通常是UTC时间,需要转换为PTP时间
- NTP闰秒处理可能与PTP不同
建议:
- 如果需要纳秒级精度,不要使用NTP作为时间源
- 如果只需要毫秒级精度,可以使用NTP,但要正确处理时间转换
问题三:闰秒处理不一致
背景:
闰秒发生时,如果网络中的设备处理方式不一致,会导致时间混乱。
常见问题:
- 主时钟正确处理了闰秒,但某些从时钟没有处理
- 不同设备的闰秒处理时机不同(有的提前,有的延迟)
解决方案:
- 使用PTP时间尺度:PTP时间不插入闰秒,避免跳变
- 正确配置currentUtcOffset:主时钟及时更新
- 监控leap61/leap59标志:从时钟提前获知闰秒
- 测试验证:闰秒发生前,进行模拟测试
小结:域和时间尺度的核心要点
域(Domain):
- 隔离不同的PTP网络
- 通过domainNumber和sdoId双重标识
- 不同域的报文互不干扰
时间尺度(Timescale):
- PTP时间尺度:TAI时间,可溯源,稳定
- ARB时间尺度:任意时间,不可溯源,用于封闭系统
- PTP时间 = UTC时间 + currentUtcOffset
闰秒处理:
- PTP时间不插入闰秒,避免跳变
- 通过leap61/leap59预告闰秒
- 通过currentUtcOffset计算UTC时间
溯源信息:
- timeTraceable:时间是否可溯源到国际标准
- frequencyTraceable:频率是否可溯源到国际标准
- timeSource:时间源类型
下集预告
现在,我们知道了PTP如何组织"时间国家"(域)和"时间时区"(时间尺度)。
但还有一个问题:PTP设备内部如何存储和管理这些信息?
下一节,我们将深入讲解PTP数据集——PTP设备的"记忆系统"。你会看到,PTP定义了一套完整的数据结构,存储了设备的身份、状态、配置、统计等信息。
【悬念留给2.4】
PTP数据集听起来像数据库,但它不是存在硬盘上的文件,而是存在于设备内存中的实时数据。这些数据会被PTP协议不断读取和更新。
更有趣的是,某些数据集成员是"静态"的(不会变),某些是"动态"的(协议运行时自动变),某些是"可配置"的(管理员可以改)。
PTP如何区分这三种类型?如何保证数据的一致性?下一节,我们详细解读。
📚 本文内容摘自本人的开源书《PTP技术书 - 从思想实验到协议实现》
全书从时间本质的思想实验出发,深度解析 IEEE 1588 协议、逐章分析 LinuxPTP 源码,并带你动手实现一个轻量级 PTP 程序(ptp-lite)。
🔗 在线阅读/下载:ptp-book
git clone https://github.com/Lularible/ptp-book.git
⭐ 如果对您有帮助,欢迎 Star 支持,也欢迎通过 GitHub Issues 交流讨论。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐


所有评论(0)