大家好，关于时间同步协议很多朋友都还不太明白，今天小编就来为大家分享关于局域网同步的知识，希望对各位有所帮助！
本文目录
一、目前 *** 时间服务有哪几种协议
杭州元帅
在一个局域网中，许多系统都要求每台计算机能够保持时间的一致性，WIN2000系统提供了与主域服务器时间同步功能，即工作站只要登录到主域服务器，工作站系统的时间自动与主域服务器时间一致，但接下来的问题是我们如何使主域服务器的时间同步世界标准时间。如要获得世界标准时间，比较精确的做法是使用GPS卫星时钟获得毫秒级精度的标准时间，但这是要money的哦。如果我们在时间精度上只需要秒级的，又能够连接到Internet，则我们可以利用Internet上的标准时间服务器获得标准时间。
事实上在Internet上有三个不同的时间服务，每一个都由Request for Comment（RFC）定义为Internet日期时间标准。这三个标准分别为：RFC-867、RFC-868和RFC-1305。下面就先介绍RFC-867：
RFC867 Daytime协议(RFC867 Daytime Protocol)
本RFC规范了一个ARPA Internet community上的标准。在ARPA Internet上的所有主机应当采用和实现这个标准。
一个有用的测量和调试工具就是daytime服务。它的作用就是返回当前时间和日期，格式是字符串格式。
daytime服务是基于TCP的应用，服务器在TCP端口13侦听，一旦有连接建立就返回ASCII形式的日期和时间(接收到的任何数据被忽略)，在传送完后关闭连接。
daytime服务也可以使用UDP协议，它的端口也是13，不过UDP是用数据报传送当前时间的。接收到的数据被忽略。
对于daytime没有特定的格式，建议使用ASCII可打印字符，空格和回车换行符。daytime应该在一行上。
一种流行的格式是：Weekday, Month Day, Year Time-Zone
例子：Tuesday, February 22, 1982 17:37:43-PST
另一种流行的格式用于 *** TP中：dd mmm yy hh:mm:ss zzz
注意：对于机器来说，有用的时间采用了时间协议（Time Protocol RFC-868)
接下来我们用VB程序实现通过RFC867协议设置我们自己的计算机系统时间，为使程序简化，程序未进行日期校正，只进行时间校正。在FORM1中添加1个Winsock控件，将下面代码剪贴到FORM1的代码窗体中即可：
'采用RFC867 Daytime协议获取标准时间例程
'www.time.ac.cn为中科院国家授时中心，采用北京时间
'时间格式：Mon Jul 26 09:58:57 2004
'time.nist.gov为美国标准技术院，采用格灵威时间
'时间格式：53212 04-07-26 02:00:12 50 0 0 488.3 UTC(NIST)*
Private Declare Sub Sleep Lib"kernel32"(ByVal dwMilliseconds As Long)
Winsock1.Protocol= sckTCPProtocol'采用TCP协议
NetTime"www.time.ac.cn"'首先取中科院国家授时中心时间
If NoSrv Or TimeFromNet="" Then
'若未取到中科院国家授时中心时间，则取美国标准技术院时间
If NoSrv Or TimeFromNet="" Then
'若不能取美国标准技术院时间，则报错
MsgBox"检测不到 *** 标准时间服务器time.nist.gov！"
'为使 *** 传输误差减小，第2次再取美国标准技术院时间
MsgBox" *** 标准时间服务器time.nist.gov超时！"
TimeFromNet= Mid(TimeFromNet, 17, 8)
TimeFromNet= TimeSerial((Hour(TimeFromNet)+ 8) Mod 24, Minute(TimeFromNet), Second(TimeFromNet))
Time= TimeFromNet'设置系统时间
'为使 *** 传输误差减小，第2次再取中科院国家授时中心时间
MsgBox" *** 标准时间服务器www.time.ac.cn超时！"
Time= Mid(TimeFromNet, 12, 8)'设置系统时间
If Winsock1.State<> sckClosed Then
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
TimeFromNet= String(bytesTotal,"")
Winsock1.GetData TimeFromNet, vbString, bytesTotal
Private Sub Winsock1_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean)
'从互联网上标准时间提供网站获取标准时间
Private Sub NetTime(TimeSrv As String)
If Winsock1.State<> sckClosed Then Winsock1.Close
Winsock1.RemoteHost= TimeSrv'"www.time.ac.cn"或"time.nist.gov"
Do While TimeFromNet=""'循环等待标准时间网站返回时间数据
If NoSrv Then Exit Do'若Winsock出错，则跳出循环等待
If Winsock1.State<> sckClosed Then Winsock1.Close
搜索更多相关主题的帖子: internet标准
上面介绍了RFC-867标准和VB例程，显然RFC-867标准采用返回当前时间和日期的格式是字符串格式以及对于daytime没有特定的格式（例如：中科院国家授时中心为"Mon Jul 26 09:58:57 2004"，而美国标准技术院为"53212 04-07-26 02:00:12 50 0 0 488.3 UTC(NIST)"），这2点似乎都不是太舒服，因此我们希望Internet上的标准时间服务器更好能够返回具有标准格式的数字类型数据，其实RFC在制定RFC-867标准时已经考虑了我们的意见，因为他同时还推出了RFC-868标准，下面就介绍RFC-868：
本RFC规范了一个ARPA Internet community上的标准。在ARPA Internet上的所有主机应当采用和实现这个标准。
此协议提供了一个独立于站点的，机器可读的日期和时间信息。时间服务返回的是以秒数，是从1900年1月1日午夜到现在的秒数，天哪，也不小呢。
设计这个协议的一个重要目的在于， *** 上的许多主机并没有时间的观念，在分布式的系统上，我们可以想一想，北京的时间和东京的时间如何分呢？主机的时间往往可以人为改变，而且因为机器时钟内的误差而变得不一致，因此需要使用时间服务器通过选举方式得到 *** 时间，让服务器有一个准确的时间观念。不要小看时间，这对于一些以时间为标准的分布运行的程序简单是太重要了。
这个协议可以工作在TCP和UDP协议下。下面是通过TCP协议工作的时间协议的工作过程：这里S代表服务器，U代表客户。
服务器在端口37上监听连接。当连接建立后，服务器返回一个32位的时间值，然后关闭连接。这个过程也不难，如果服务器不能决定现在是什么时间，服务器会拒绝连接或不发送任何数据而直接关闭连接。
下面我们看看使用UDP协议的情况：这里S代表服务器，U代表客户。
S:发送包含32位二进制数（用于表示时间）的数据报
服务器在端口37上监听数据包。当一个数据包来后，服务器返回一个包含32位的时间的数据包。这个过程也不难，如果服务器不能决定现在是什么时间，服务器会抛弃接收到的数据报而不作出任何应答。
时间是由32位表示的，是自1900年1月1日0时到当前的秒数，我们可以计算一下，这个协议只能表示到2036年就不能用了。（但是我们也知道计算机发展速度这么快，可能到时候就会有更好的协议代替这个协议，或者有已经想出有效的解决办法了。）
the time 2,208,988,800 corresponds to 00:00 1 Jan 1970 GMT,
2,398,291,200 corresponds to 00:00 1 Jan 1976 GMT,
2,524,521,600 corresponds to 00:00 1 Jan 1980 GMT,
2,629,584,000 corresponds to 00:00 1 May 1983 GMT,
以及-1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.
接下来我们用VB程序实现通过RFC868协议设置我们自己的计算机系统时间，为使程序简化，程序未进行日期校正，只进行时间校正。不过这个例程比上面的程序要完善得多，首先他可以读取全球20个标准时间服务器的时间数据，第二他采用了 *** 延时的补偿，第三对 *** 延时超过3秒的标准时间服务器进行了过滤。在FORM1中添加1个Winsock控件，将下面代码剪贴到FORM1的代码窗体中即可：
'时间协定（RFC-868）提供了一个32位元的数字，用来表示从1900年1月1日至今的秒数。
'该时间是UTC（不考虑字母顺序，它表示世界时间座标（CoordinatedUniversalTime）），
'它类似於所谓的格林威治标准时间（GreenwichMeanTime）或者GMT－英国格林威治时间。
'用TCP获得准确时间的程式应该有如下步骤:
'1连结到提供此服务的端口37；
Private Declare Sub Sleep Lib"kernel32"(ByVal dwMilliseconds As Long)
Dim TimeFromNet'存放从时间网站读取的秒数
Dim TimeURL(19) As String'20个时间提供网站的URL
Dim HH As Integer, MM As Integer, SS As Integer'时、分、秒
CDec(TimeFromNet)'转换为 Decimal子类型，28位整数
TimeURL(0)="www.time.ac.cn"'首先取中科院国家授时中心时间
TimeURL(1)="time.nist.gov"'美国标准技术院
TimeURL(2)="time-a.timefreq.bldrdoc.gov"
TimeURL(4)="nist1-dc.glassey.com"
TimeURL(5)="nist1-ny.glassey.com"
TimeURL(6)="nist1-sj.glassey.com"
TimeURL(7)="utcnist.colorado.edu"
TimeURL(8)="time-b.timefreq.bldrdoc.gov"
TimeURL(9)="time-c.timefreq.bldrdoc.gov"
TimeURL(12)="nist1.aol-va.truetime.com"
TimeURL(13)="nist1.aol-ca.truetime.com"
TimeURL(14)="time-nw.nist.gov"
TimeURL(15)="Time-b.timefreq.bldrdoc.gov"
TimeURL(16)="Time-c.timefreq.bldrdoc.gov"
TimeURL(18)="clock.cmc.ec.gc.ca"
Me.Caption="正在联接—"& TimeURL(i)
NetTime TimeURL(i)'首次读取授时中心时间
If(Not NoSrv) And TimeFromNet> 0 Then'如果时间读取成功
'为使 *** 传输误差减小，二次再取授时中心时间
T0= Timer'为减小 *** 延时引起的误差，先读取当前时间
NetTime TimeURL(i)'二次读取授时中心时间
If(Not NoSrv) And TimeFromNet> 0 Then'如果第二次时间读取成功
TimeFromNet= TimeFromNet+ Int((Timer- T0)/ 2+ 0.5)'加上 *** 延时补偿(延时/2为延时补偿)
TimeFromNet= TimeFromNet- 86400* Int(TimeFromNet/ 86400)'以天取模(86400秒)
SS= TimeFromNet Mod 60'取秒
MM= TimeFromNet Mod 60'取分
HH=((TimeFromNet 60)+ 8) Mod 24'取小时(北京时间+8)
' MsgBox" *** 延时："&(Timer- T0)
Time= TimeSerial(HH, MM, SS)'设置系统时间
Exit For'取时完毕，退出循环
If Winsock1.State<> sckClosed Then
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
TimeFromNet= TmpData(3)+ TmpData(2)* 256+ TmpData(1)* 256* 256+ TmpData(0)* 256* 256* 256
Private Sub Winsock1_Error(ByVal Number As Integer, Description As String, ByVal Scode As Long, ByVal Source As String, ByVal HelpFile As String, ByVal HelpContext As Long, CancelDisplay As Boolean)
'从互联网上标准时间提供网站获取标准时间
Private Sub NetTime(TimeSrv As String)
Dim i As Integer'超时计数器
If Winsock1.State<> sckClosed Then Winsock1.Close
Winsock1.RemoteHost= TimeSrv'时间提供网站的URL
Winsock1.RemotePort= 37'时间协定（RFC-868）指定端口
If NoSrv Or i> 50 Then Exit Do'若Winsock出错或超时约3秒，则时间获取失败
If Winsock1.State<> sckClosed Then Winsock1.Close
最精确的 *** 时间协议应该是RFC 1305—NTP（Network Time Protocol）了，它能够1-50 ms的时间精确度，但该协议非常复杂，另外很抱歉我手头没有RFC 1305中文翻译资料，不过后来RFC又出了一个RFC1769—SNTP（Simple Network Time Protocol），简化了一些RFC 1305要求的操作和使用范围，下面就介绍RFC1769—SNTP：
Network Working Group D. Mills
Request for Comments: 1769 University of Delaware
（RFC1769——Simple Network Time Protocol）
本备忘录为Internet community提供了信息，但不规定任何一种类型的 Internet标准。本备忘录的分发没有限制。
本备忘录描述简单 *** 时间协议(SNTP)，这是 *** 时间协议(NTP)的一个改写本，NTP协议适用于同步因特网上的计算机时钟。当不须要实现RFC 1305所描述的NTP完全功能的情况下，可以使用SNTP。它能用单播方式(点对点)和广播方式(点对多点)操作。它也能在IP多播方式下操作（可提供这种服务的地方）。SNTP与当前及以前的NTP版本并没有大的不同。但它是更简单，是一个无状态的远程过程调用(RPC)，其准确和可靠性相似于UDP/TIME协议在RFC868描述中所预期的。
本备忘录淘汰相同的标题的RFC 1361。它的目的是解释用广播方式操作的协议模式，提供某些地方的进一步说明并且改正一些印刷上的错误。在NTP版本3 RFC 1305中说明的工作机理对SNTP的实现不是完全需要的。本备忘录的分发没有限制。
RFC 1305 [MIL92]指定 *** 时间协议(NTP)来同步因特网上的计算机时钟。它提供了全面访问国家时间和频率传播服务的机制，组织时间同步子网并且为参加子网每一个地方时钟调整时间。在今天的因特网的大多数地方， NTP提供了1-50 ms的精确度，精确度的大小取决于同步源和 *** 路径等特性。
RFC 1305指定了NTP协议机制中的事件，状态，传输功能和操作，另外，还有可选择的算法，它改进测时质量并且减少了一些同步源中可能存在的错误。为了获得因特网上主要路径的延时精确到毫秒级，使用一些复杂的算法或者他们的等价算法是必要的。但是，在许多场合这样的精确度是不要求，或许精确到秒已足够了。在这样的情况下，更简单的协议例如“时间协议”[POS83 ]已被使用。这些协议通过基于RPC交换：客户端请求此刻时间，然后服务器回传从某个已知时间点到现在的秒钟数。
NTP被设计成了性能差异很大的客户端及服务器均能适用，且适用于客户端及服务器所在网路有大范围的 *** 延迟和抖动的情况。今天的因特网上的NTP同步子网的大多数用户使用一个软件包包括了一整套的NTP的选择和算法，是一个比较复杂，实时的应用系统。软件要适用于多种硬件平台：从巨型计算机到个人计算机。要在这样的范围都适用，它的庞大尺寸和复杂性就不适合于很多应用了。按照要求，探求一些可供选择的访问策略(使用适合于精确度要求不是
本备忘录描述简单 *** 时间协议(SNTP)，它是一个简化了的NTP服务器和NTP客户端策略。SNTP在协议实现上没有什么更改，在最近也不会有什么变动。访问范例与UDP/TIME协议是一致的，实际上，SNTP应该更容易适用于使用个人计算机的 UDP/TIME客户。而且，SNTP也被设计在一个专门的服务器(包括一台集成的无线电时钟)里操作。由于在系统里的那些各种各样反应机制的设计和控制，交付调节时间精确到微秒是可能的。这样的专门设计是切实可行的。
强烈建议SNTP仅仅在同步子网的末端被使用。 SNTP客户端应该仅在子网的叶子(更高的阶层)操作并在配置过程中没有依靠其它NTP或者SNTP客户端来同步。SNTP服务器应该仅在子网的根(阶层1)操作并在配置过程中，除一台可靠的无线电时钟外中没有其它同步源。只有使用了有冗余的同步源及不同的子网路径及整套NTP实现中的crafted算法，主服务器通常期望的可靠性才有可能达到。这种做法使主同步源在无线电时钟通信失败或者交付了错误时间时，还能用到其它几个无线电时钟和通向其它主要服务器的备份路径。因此，应该仔细考虑客户端中SNTP的使用，而不是在主服务器里的NTP的使用。
象NTP一样，SNTP能在单播(点向点)或者广播(点对多点)模式中操作。单播客户端发送请求到服务器并且期望从那里得到答复，并且（可选的），得到有关服务器的往返传播延迟和本地时钟补偿。广播服务器周期性地送消息给一指定的IP广播地址或者IP多播地址，并且通常不期望从客户端得到请求，广播客户端监听地址但通常并不给服务器发请求。一些广播服务器可能选择对客户端作出反应请求以及发出未经请求广播消息；同时一些广播客户端可能会送请求仅为了确定在服务器和客户端之间的 *** 传播延迟。
在单播方式下，客户端和服务器的IP地址按常规被分配。在广播方式下，服务器使用一指定的IP播送地址或者IP多播地址，以及指明的媒介访问播送地址，客户端要在这些地址上帧听。为此，IP广播地址将限制在一个单独的IP子网范围，因为路由器不传播IP广播数据报。就以太网而论，例如，以太网媒介访问广播地址(主机部分全部为1)被用于表示IP广播地址。
另一方面，IP多播地址将广播的潜在有效范围扩展到整个因特网。其真实范围，组会员和路由由因特网组管理协议(IGMP)确定 [DEE89 ]，对于各种路由协议，超出了这份资料的讨论范围。就以太网而论，例如，以太网媒介访问播送地址(全部为1)要和分配的224.0.1.1的IP多播地址合用。除了IP地址规范和IGMP，在服务器操作IP广播地址或者IP多播地址没有什么不同。
广播客户端帧听广播地址，例如在以太网情况下主机地址全部为1的。就广播地址的IP而论，没有更进一步规定的必要了。在IP多组广播情况下，主机可能需要实现IGMP，为的是让本地路由器把消息拦截后送到224.0.1.1多播组。这些考虑不属于这份资料的讨论范围。
就当前指定的SNTP而论，其真正的弱点是多目广播客户端可能被一些行为不当或者敌对的在因特网别处的SNTP/NTP多播服务器攻击而瘫痪，因为目前全部这样服务器使用相同的IP多播地址：224.0.1.1组地址。所以有必要，存取控制要基于那些以客户端信任的服务器源地址，即客户端选择仅仅为自己所知的服务器。或者，按照惯列和非正式协议，全部NTP多播服务器现在在每条消息内应包括已用MD5加密的加密位，以便客户端确定消息没有在传输中被修改。SNTP客户端能实现那些必要加密和密钥分发计划在原则上是可能的，但是这在SNTP被设计成的那些简单的系统里不可能被考虑。
考虑到没有一个完整的SNTP规范，故IP广播地址将使用在IP子网和局域网部分(指有完整功能的NTP服务器和SNTP客户端在同一子网上的局域网)，而对于IP多播地址来说，将只能用在为达到以上相同目而设计的特例中。尤其，只有服务器实现了RFC 1305描述的NTP认证时（包括支持MD5消息位的算法），在SNTP服务器里的IP多播地址才被使用。
sntp使用在RFC 1305及其以前的版本所描述标准NTP时间戳的格式。与因特网标准标准一致， NTP数据被指定为整数或定点小数，位以big-endian风格从左边0位或者高位计数。除非不这样指定，全部数量都将设成unsigned的类型，并且可能用一个在bit0前的隐含0填充全部字段宽度。
因为SNTP时间戳是重要的数据和用来描述协议主要产品的，一个专门的时间戳格式已经建立。 NTP用时间戳表示为一64 bits unsigned定点数，以秒的形式从1900年1月1日的0：0：0算起。整数部分在前32位里，后32bits（seconds Fraction）用以表示秒以下的部分。在Seconds Fraction部分，无意义的低位应该设置为0。这种格式把方便的多精度算法和变换用于UDP/TIME的表示（单位：秒），但使得转化为ICMP的时间戳消息表示法(单位：毫秒)的过程变得复杂了。它代表的精度是大约是200 picoseconds，这应该足以满足更高的要求了。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
注意，从1968年起，更高有效位(整数部分的0 bit位)已经被确定，64位比特字段在2036年将溢出。如果NTP或者SNTP在2036年还在使用的话，一些外部 *** 将有必要用来调整与1900年及2036年有关的时间(136年的其它倍数也一样)。用这样的限制使时间戳数据变得很讲究(要求合适的 *** 可容易地被找到)。从今以后每136年，就会有200picosecond的间隔，会被忽略掉，64个比特字段将全部置为0，按照惯列它将被解释为一个无效的或者不可获得的时间戳。
NTP和SNTP是用户数据报协议( UDP)的客户端 [POS80 ]，而UDP自己是网际协议( IP) [DAR81 ]的客户端. IP和UDP报头的结构在被引用的指定资料里描述，这里就不更进一步描述了。UDP的端口是123，UDP头中的源断口和目的断口都是一样的，保留的UDP头如规范中所述。
以下是SNTP报文格式的描述，它紧跟在IP和UDP报头之后。SNTP的消息格式与RFC-1305中所描述的NTP格式是一致的，不同的地方是：一些SNTP的数据域已被风装，也就是说已初始化为一些预定的值。NTP消息的格式被显示如下。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI| VN|Mode| Stratum| Poll| Precision|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
二、什么是window时间的同步
1、“Windows时间”系统服务维护 *** 上所有基于 Windows XP和 Windows Server 2003的计算机上的日期和时间同步。
2、此服务使用 *** 时间协议(NTP)使计算机时钟同步，以便为 *** 验证和资源访问请求分配准确的时钟值或时间戳。
3、NTP的实现和时间提供程序的集成帮助 Windows Time成为您企业的可靠、灵活的时间服务。
4、对于没有加入域的计算机，可以配置 Windows时间以使时间与外部时间源同步。
5、如果关闭此服务，则本地计算机的时间设置将不能与 Windows域中的时间服务或外部配置的时间服务同步。
6、Windows Server 2003使用 NTP。NTP运行于 UDP端口 123上。此服务的 Windows 2000版本使用简单 *** 时间协议(SNTP)。
7、SNTP也运行于 UDP端口 123上。
8、系统服务名称：W32Time应用程序协议协议端口 NTP TCP 123。
三、有关无线传感器 *** 中时间同步机制有哪些 *** 和策略
1 时间同步技术的重要性
传感器节点的时钟并不完美，会在时间上发生漂移，所以观察到的时间对于 *** 中的节点来说是不同的。但很多 *** 协议的应用，都需要一个共同的时间以使得网路中的节点全部或部分在瞬间是同步的。
之一，传感器节点需要彼此之间并行操作和协作去完成复杂的传感任务。如果在收集信息过程中，传感器节点缺乏统一的时间戳（即没有同步），估计将是不准确的。
第二，许多节能方案是利用时间同步来实现的。例如，传感器可以在适当的时候休眠（通过关闭传感器和收发器进入节能模式），在需要的时候再唤醒。在应用这种节能模式的时候，节点应该在同等的时间休眠和唤醒，也就是说当数据到来时，节点的接收器可以接收，这个需要传感器节点间精确的定时。
2 时间同步技术所关注的主要性能参数
时间同步技术的根本目的是为 *** 中节点的本地时钟提供共同的时间戳。对无线传感器
*** WSN（Wireless Sensor Networks）[1]
的时间同步应主要应考虑以下几个方面的问题：
(1)能量效率。同步的时间越长，消耗的能量越多，效率就越低。设计WSN的时间同步算法需以考虑传感器节点有效的能量资源为前提。
(2) 可扩展性和健壮性。时间同步机制应该支持 *** 中节点的数目或者密度的有效扩展，并保障一旦有节点失效时，余下 *** 有效且功能健全。
(3)精确度。针对不同的应用和目的，精确度的需求有所不用。
(4)同步期限。节点需要保持时间同步的时间长度可以是瞬时的，也可以和 *** 的寿命一样长。
(5)有效同步范围。可以给 *** 内所有节点提供时间，也可以给局部区域的节点提供时间。
(6)成本和尺寸。同步可能需要特定的硬件，另外，体积的大小也影响同步机制的实现。 (7)更大误差。一组传感器节点之间的更大时间差，或相对外部标准时间的更大差。 3 现有主要时间同步 *** 研究
时间同步技术是研究WSN的重要问题，许多具体应用都需要传感器节点本地时钟的同步，要求各种程度的同步精度。WSN具有自组织性、多跳性、动态拓扑性和资源受限性，尤其是节点的能量资源、计算能力、通信带宽、存储容量有限等特点，使时间同步方案有其特
殊的需求，也使得传统的时间同步算法不适合于这些 *** [2]
。针对WSN，目前已经从不同角度提出了许多新的时间同步算法[4]
3.1 成对(pair-wise)同步的双向同步模式
代表算法是传感器 *** 时间同步协议TPSN（Timing-Sync Protocol for Sensor
。目的是提供WSN整个 *** 范围内节点间的时间同步。
该算法分两步：分级和同步。之一步的目的是建立分级的拓扑 *** ，每个节点有个级别。只有一个节点与外界通信获取外界时间，将其定为零级，叫做根节点，作为整个 *** 系统的时间源。在第二步，每个i级节点与i-1（上一级）级节点同步，最终所有的节点都与根节点同步，从而达到整个 *** 的时间同步。详细的时间同步过程如图 1 所示。
图1 TPSN 同步过程
设R为上层节点，S为下层节点，传播时间为d，两节点的时间偏差为θ。同步过程由节点R广播开始同步信息，节点S接收到信息以后，就开始准备时间同步过程。在T1时刻，节点S发送同步信息包，包含信息(T1)，节点R在T2接收到同步信息，并记录下接收时间T2，这里满足关系：21TTd
节点R在T3时刻发送回复信息包，包含信息(T1,T2,T3)。在T4时刻S接收到同步信息包，满足关系：43TTd
最后，节点S利用上述2个时间表达式可计算出的值：(21)(43)2
TTTT
TPSN由于采用了在MAC层给同步包标记时间戳的方式，降低了发送端的不确定性，消除了访问时间带来的时间同步误差，使得同步效果更加有效。并且，TPSN算法对任意节点的同步误差取决于它距离根节点的跳数，而与 *** 中节点总数无关，使TPSN同步精度不会随节点数目增加而降级，从而使TPSN具有较好的扩展性。TPSN算法的缺点是一旦根节点失效，就要重新选择根节点，并重新进行分级和同步阶段的处理，增加了计算和能量开销，并随着跳数的增加，同步误差呈线性增长，准确性较低。另外，TPSN算法没有对时钟的频差进行估计，这使得它需要频繁同步，完成一次同步能量消耗较大。
3.2 接收方-接收方（Receiver-Receiver）模式
代表算法是参考广播时间同步协议RBS（Reference Broadcast Synchronization）[7]
。RBS是典型的基于接收方-接收方的同步算法，是Elson等人以“第三节点”实现同步的思想而提出的。该算法中，利用无线数据链路层的广播信道特性，基本思想为：节点(作为发
送者)通过物理层广播周期性地向其邻居节点（作为接收者）发送信标消息[10]
，邻居节点记录下广播信标达到的时间，并把这个时间作为参考点与时钟的读数相比较。为了计算时钟偏移，要交换对等邻居节点间的时间戳，确定它们之间的时间偏移量，然后其中一个根据接收
到的时间差值来修改其本地的时间，从而实现时间同步[11]
假如该算法在 *** 中有n个接收节点m个参考广播包，则任意一个节点接收到m个参考包后，会拿这些参考包到达的时间与其它n-1个接收节点接收到的参考包到达的时间进行比较，然后进行信息交换。图2为RBS算法的关键路径示意图。
图2 RBS算法的关键路径示意图
jkikkinjnoffsetijTTm
其中n表示接收者的数量，m表示参考包的数量，,rbT表示接收节点r接收到参考包b时的时钟。
此算法并不是同步发送者和接收者，而是使接收者彼此同步，有效避免了发送访问时间对同步的影响，将发送方延迟的不确定性从关键路径中排除，误差的来源主要是传输时间和接收时间的不确定性，从而获得了比利用节点间双向信息交换实现同步的 *** 更高的精确度。这种 *** 的更大弊端是信息的交换次数太多，发送节点和接收节点之间、接收节点彼此之间，都要经过消息交换后才能达到同步。计算复杂度较高， *** 流量开销和能耗太大，不适合能量供应有限的场合。
3.3 发送方-接收方(Sender-Receiver)模式
基于发送方-接收方机制的时间同步算法的基本原理是：发送节点发送包含本地时间戳的时间同步消息，接收节点记录本地接收时间，并将其与同步消息中的时间戳进行比较，调整本地时钟。基于这种 *** 提出的时间同步算法有以下两种。
3.3.1 FTSP 算法[8]
泛洪时间同步协议FTSP（Flooding Time Synchronization Protocol）由Vanderbilt大学Branislav Kusy等提出，目标是实现整个 *** 的时间同步且误差控制在微秒级。该算法用单个广播消息实现发送节点与接收节点之间的时间同步。
其特点为：(1)通过对收发过程的分析，把时延细分为发送中断处理时延、编码时延、传播时延、解码时延、字节对齐时延、接收中断处理时延，进一步降低时延的不确定度；(2)通过发射多个信令包，使得接收节点可以利用最小方差线性拟合技术估算自己和发送节点的频率差和初相位差；(3)设计一套根节点选举机制，针对节点失效、新节点加入、拓扑变化
等情况进行优化，适合于恶劣环境[12]
FTSP算法对时钟漂移进行了线性回归分析。此算法考虑到在特定时间范围内节点时钟晶振频率是稳定的，因此节点间时钟偏移量与时间成线性关系，通过发送节点周期性广播时间同步消息，接收节点取得多个数据对，构造更佳拟合直线，通过回归直线，在误差允许的时间间隔内，节点可直接通过它来计算某一时间节点间的时钟偏移量而不必发送时间同步消息进行计算，从而减少了消息的发送次数并降低了系统能量开销。
FTSP结合TPSN和RBS的优点，不仅排除了发送方延迟的影响，而且对报文传输中接收方的不确定延迟（如中断处理时间、字节对齐时间、硬件编解码时间等）做了有效的估计。多跳的FTSP协议采用层次结构，根节点为同步源，可以适应大量传感器节点，对 *** 拓扑结构的变化和根节点的失效有健壮性，精确度较好。该算法通过采用MAC层时间戳和线性回归偏差补偿弥补相关的错误源，通过对一个数据包打多个时戳，进而取平均和滤除抖动较大的时戳，大大降低了中断和解码时间的影响。FTSP 采用洪泛的方式向远方节点传递时间基准节点的时间信息，洪泛的时间信息可由中转节点生成，因此误差累积不可避免。另外，FTSP的功耗和带宽的开销巨大。
3.3.2 DMTS 算法[9]
延迟测量时间同步DMTS (delay measurement time synchronization) 算法的同步机制是基于发送方-接收方的同步机制。DMTS 算法的实现策略是牺牲部分时间同步精度换取较低的计算复杂度和能耗，是一种能量消耗轻的时间同步算法。
DMTS算法的基本原理为：选择一个节点作为时间主节点广播同步时间，所有接收节点通过精确地测量从发送节点到接收节点的单向时间广播消息的延迟并结合发送节点时间戳，计算出时间调整值，接收节点设置它的时间为接收到消息携带的时间加上广播消息的传输延迟，调整自己的逻辑时钟值以和基准点达成同步，这样所有得到广播消息的节点都与主节点进行时间同步。发送节点和接收节点的时间延迟dt可由21()dtnttt得出。其中，nt为发送前导码和起始字符所需的时间，n为发送的信息位个数，t为发送一位所需时间；1t为接收节点在消息到达时的本地时间；2t为接收节点在调整自己的时钟之前的那一时刻记录的本地时间，21()tt是接收处理延迟。
DMTS 算法的优点是结合链路层打时间戳和时延估计等技术，消除了发送时延和访问时延的影响，算法简单，通信开销小。但DMTS算法没有估计时钟的频率偏差，时钟保持同步的时间较短，没有对位偏移产生的时间延迟进行估计，也没有消除时钟计时精度对同步精度的影响，因此其同步精度比FTSP略有下降，不适用于定位等要求高精度同步的应用。
基于发送方-接收方单向同步机制的算法在上述三类 *** 中需要发送的时间同步消息数目最少。发送节点只要发送一次同步消息，因而具有较低的 *** 流量开销和复杂度，减少了系统能耗。
文章介绍了WSN时间同步算法的类型以及各自具有代表性的算法，分析了各算法的设计原理和优缺点。这些协议解决了WSN中时间同步所遇到的主要问题，但对于大型 *** ，已有的 *** 或多或少存在着一些问题：扩展性差、稳定性不高、收敛速度变慢、 *** 通信冲突、能耗增大。今后的研究热点将集中在节能和时间同步的安全性方面。这将对算法的容错性、有效范围和可扩展性提出更高的要求。
关于时间同步协议，局域网同步的介绍到此结束，希望对大家有所帮助。
