CN101789954B - 单播环境下的通信方法、设备及系统 - Google Patents

Abstract

本发明实施例涉及一种单播环境下的通信方法、主设备、从设备及单播通信系统，其中一种方法包括：主设备与至少一个从设备在进行通知报文的单播协商通过后，接收所述从设备发来的保活报文；根据所述保活报文，确定发送该保活报文的从设备的状态有效性；根据对应从设备的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备中状态为有效的从设备单播发送通知报文。通过本发明实施例，使得主设备能够感知从设备的状态是否有效，避免了当某从设备离线后仍发送通知报文的问题，从而节省资源和系统开销。

Description

单播环境下的通信方法、设备及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种单播环境下的通信方法、主设备、从设备及单播通信系统。

背景技术

精确时间协议(Precision Time Protocol，简称：PTP)是指电气电子工程师协会(Institute of Electrical and Electronics Engineers，简称：IEEE)1588v2标准，该标准是一种时钟同步标准，用于实现无线产品与基站在网上的时钟同步。

但是现有的IEEE1588v2协议都是在描述多播环境下的时钟同步，而在现有的传输网中，特别是在作为无线传输承载网的居民接入网(ResidentialAccess Network，简称：RAN)侧，真正支持多播环境的网络有限，大部分只支持单播环境，因此目前业界迫切需要一种单播环境下的通信方案。

发明内容

本发明实施例在于提供一种单播环境下的通信方法、从设备、主设备及单播通信系统，使得主设备能够感知从设备的状态是否有效。

本发明的一个实施例提供了一种单播环境下的通信方法，其中包括：

从设备与至少一个主设备在进行通知报文的单播协商通过后，向所述至少一个主设备单播发送保活报文；

接收来自于所述主设备的通知报文后，根据所述通知报文，从所述主设备中选择一个主设备作为源设备。

本发明的另一个实施例提供了另一种单播环境下的通信方法，其中包括：

主设备与至少一个从设备在进行通知报文的单播协商通过后，接收所述从设备发来的保活报文；

根据所述保活报文，确定发送该保活报文的从设备的状态有效性；

根据对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备中状态为有效的从设备单播发送通知报文。

本发明的又一个实施例提供了一种从设备，其中包括：

通知协商从模块，用于与至少一个主设备进行通知报文的单播协商；

保活从模块，用于在所述通知协商从模块进行的通知报文的单播协商通过后，向所述至少一个主设备单播发送保活报文；

授权处理模块，用于接收来自于所述主设备的通知报文后，根据所述通知报文，从所述主设备中选择一个主设备作为源设备。

本发明的又一个实施例提供了一种主设备，其中包括：

通知协商主模块，用于与至少一个从设备进行通知报文的单播协商；

保活主模块，用于根据接收到的来自于所述从设备的保活报文，确定发送该保活报文的从设备的状态有效性；

发送模块，用于根据所述保活主模块确定的对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备中状态为有效的从设备单播发送通知报文。

本发明的又一个实施例提供了一种单播通信系统，其中包括：

从设备，用于与主设备在进行通知报文的单播协商通过后，向所述主设备单播发送保活报文，根据来自于所述主设备的通知报文从所述主设备中选择一个主设备作为源设备；

主设备，用于与从设备在进行通知报文的单播协商通过后，根据所述从设备发来的保活报文确定发送该保活报文的从设备的状态有效性；根据对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述从设备中状态为有效的从设备单播发送通知报文。

本发明实施例的单播环境下的通信方案中，从设备与主设备进行通知报文的单播协商通过后，从设备向主设备单播发送保活报文，使主设备能够根据所述保活报文确定发送该保活报文的从设备的状态有效性，从而使得主设备能感知相应从设备的状态是否有效(即是否在线)，根据对应从设备的状态有效性信息及所述通知报文的单播协商结果，向状态为有效的从设备(即在线的从设备)单播发送通知报文，避免了当某从设备离线后仍发送通知报文的问题，从而能够节省资源和系统开销。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明方法实施例一所述单播环境下的通信方法的流程图；

图2为本发明方法实施例一所述通知报文的单播协商过程的信令图；

图3为本发明方法实施例一所述从设备侧的单播协商状态机的状态跳转图；

图4为本发明方法实施例一所述主设备侧的单播协商状态机的状态跳转图；

图5为本发明方法实施例二所述单播环境下的通信方法的流程图；

图6为本发明方法实施例二所述单播环境下的通信方法的信令图；

图7为本发明方法实施例三所述单播环境下的通信方法的流程图；

图8为本发明方法实施例三所述通知报文的单播协商过程的流程图；

图9为本发明方法实施例三所述同步报文的单播协商过程的流程图；

图10为本发明方法实施例三所述延迟响应报文的单播协商过程的流程图；

图11为本发明方法实施例四所述单播环境下的通信方法的流程图；

图12为本发明方法实施例四所述单播环境下的通信方法的信令图；

图13为本发明方法实施例四所述单播环境下的通信方法的另一信令图；

图14为本发明系统实施例的结构示意图；

图15为本发明装置实施例一的结构示意图；

图16为本发明装置实施例二的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例中，从设备与至少一个主设备在进行通知报文的单播协商通过后，向所述至少一个主设备单播发送保活报文；主设备根据接收到的保活报文确定发送该保活报文的从设备的状态有效性，从而使得主设备能感知相应从设备的状态是否有效(即从设备是否在线)，并根据对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向状态为有效的从设备单播发送通知报文，使得从设备根据接收到的通知报文，从所述主设备中选择一个主设备作为源设备，通过本发明实施例避免了当某从设备离线后主设备仍发送通知报文的问题，从而能够节省资源和系统开销。

方法实施例一

本实施例提供了一种单播环境下的通信方法，如图1所示，包括如下步骤：

步骤101，从设备与至少一个主设备在进行通知报文的单播协商通过后，向所述至少一个主设备单播发送保活(Keep alive)报文。

具体地，所述从设备可以向所述至少一个主设备周期性地主动单播发送保活报文；或者，也可以在接收到主设备发送的状态检测报文后，向所述主设备单播发送与该状态检测报文对应的保活报文，可以是周期性地向主设备单播发送保活报文。

步骤102，主设备根据接收到的来自于从设备的保活报文，确定发送该保活报文的从设备的状态有效性。

需要说明的是，这里的从设备的状态有效性，即表示从设备在线。主设备可以维护与从设备对应的状态有效性信息，即对应从设备的状态有效性信息。

步骤103，主设备根据对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备中状态为有效的从设备单播发送通知报文。

具体地，如果与主设备的通知报文的单播协商通过的从设备在线，则根据所述通知报文的单播协商结果，向在线的从设备单播发送通知报文；换言之，如果在线的从设备多于一个，主设备就一个个的单播发送通知报文。

步骤104，从设备接收来自于所述主设备的通知报文后，根据所述通知报文，从所述主设备中选择一个主设备作为源设备。

以下，以通知(Annouce)报文的单播协商为例，来说明在单播环境下的主从设备的单播协商过程，如图2所示，其中包括如下流程：

(1-1)从设备向自身维护的单播主设备信息中的主设备发送通知请求(Ann.Req)报文；

(1-2)主设备接收来自于从设备的通知请求(Ann.Req)报文，根据自身维护的单播从设备信息，向从设备返回携带有授权信息的通知授权(Ann.Grant)报文；

从设备接收来自于主设备的通知授权报文后，获取该通知授权报文中的授权信息，当所述授权信息表示同意授权时，则确定与所述主设备的通知报文的单播协商链路建立成功；

(1-3)从设备向主设备发送通知取消(Ann.Cancel)报文；

(1-4)主设备收到通知取消(Ann.Cancel)报文后，向从设备返回通知取消确认(Ann.Cancel ACK)报文，以拆除单播协商链路。

为了更加清楚的表达上述协商过程的时序关系，本实施例还给出了单播协商状态机。如图3所示，为从设备侧的单播协商状态机；如图4所示，为主设备侧的单播协商状态机。状态跳转的条件参见状态机附图。

以下对图中所示各状态机的状态进行具体说明：

初始状态(NULL)：表示单播协商的初始状态，此时未发生任何动作；

请求状态(REQ)：表示从设备发送了单播请求报文；

授权状态(GRANT)：表示从设备接收来自主设备的授权(GRANT)报文，且其中的授权信息表示“R＝TRUE”；

拒绝状态(REFUSE)：表示从设备收到来自主设备的授权(GRANT)报文，且其中的授权信息表示“R＝FALSE”；

取消状态(CANCEL)：表示从设备接收到或是发送了取消(CANCEL)报文；

确认状态(ACK)：表示从设备接收到或是发送了取消确认(CANCEL ACK)报文；

失败状态(FAILURE)：即错误状态，表示当从设备发送多次协商请求后没有接到任何响应，此时会进入该状态，进入该状态后需要用户干预，重新初始化或是强制重新协商，以使状态机跃迁到初始状态，重新开始工作。

可见，本实施例中，通过由从设备向主设备发送保活报文，使主设备能够得知相应的从设备的状态有效性，给在线的从设备发送通知报文，而当得知某个从设备离线后，则可以删除本地的相关从设备资源，从而能够节省资源和系统开销，避免冗余异常。

方法实施例二

上述方法实施例一中说明了主设备与从设备之间进行的通知报文的单播协商过程，但实际应用中，各种不同的单播协商报文之间也有协商时序性或连贯的约束关系。这些单播协商报文包括：通知(Announce)报文、同步(Sync)报文、点对点(Point to Point，简称：P2P)延迟响应报文(Delay_Resp)报文和端对端(End to End，简称：E2E)延迟响应报文(Pdelay_Resp)报文，共四种报文。其中，通知报文用来维护时钟链路；同步报文中包含有时间戳，用于实现时钟同步；点对点的延迟响应报文和端对端的延迟响应报文分别是在P2P模式和E2E模式下进行时间同步时，用来补偿链路时延和链路中节点的时延。

为此，本实施例提供了另一种单播环境下的通信方法，如图5所示，从设备与主设备的单播协商具体可以包括如下步骤：

步骤201，从设备与至少一个主设备进行通知报文的单播协商，通过后由主设备根据所述通知报文的单播协商结果向状态为有效的从设备单播发送通知报文，由从设备根据通知报文选择一个主设备作为源设备；具体的协商过程可参见上述方法实施例一，此处不再赘述。

步骤202，所述通知报文的单播协商通过后，所述设备与选中的源设备进行同步报文的单播协商。

步骤203，所述同步报文的单播协商通过后，当确定为端对端E2E模式下的时间同步时，则从设备向主设备发起端对端的延迟响应报文的单播协商；当确定为点对点P2P模式下的时间同步时，则从设备向主设备发起点对点的延迟响应报文的单播协商。

其中，P2P模式和E2E模式是时间同步的两种链路时延检测机制，这两种机制的不同点在于：P2P模式除了计算链路时延外，还计算中间支持PTP的节点转发时钟报文的时间；而E2E模式产不计算该时间。

如果是频率同步，则协商请求过程结束。这是因为：频率同步只关注各个节点频率相同，不关注相位偏移，因此，仅通过同步报文传送节点频率即可；而时间同步(或称相位同步)相比频率同步更准确，因此需要进行协商来补偿链路上的相位偏移。

以下，通过图6，来说明本实施例的流程过程。

其中，单播协商链路的建立过程为：

(2-1)进行通知(Announce)报文的单播协商。

具体地，是根据上述方法实施例一所述方法，由从设备向主设备发送通知请求(Ann.Req)报文；再由主设备向从设备返回通知授权(Ann.Grant)报文，进而建立通知报文的单播协商链路；并根据通知(Announce)报文的内容选择一个主设备作为源设备，即执行选源。

(2-2)根据选源结果进行同步(Sync)报文的单播协商链路的建立过程。

具体地，如果选中该源(即源设备)，则对该源设备发起同步请求(Sync.Req)报文，未选中该源设备则不对该源设备发起该同步请求(Sync.Req)报文；该源设备向从设备返回同步授权(Sync.Grant)报文，进而建立同步报文的单播协商链路。

(2-3)如果是P2P模式下的时间同步，则进行点对点的延迟响应(Delay_Resp)报文的单播协商；如果是E2E模式下的时间同步，则进行端对端的延迟响应(Pdelay_Resp)报文的单播协商。

拆除过程中，各单播协商报文的执行过程与上述建立过程相反，具体地，单播协商链路的拆除过程为：

(2-4)如果进行了延迟响应报文的单播协商，则进行延迟响应报文的单播取消(Cancel)过程；具体地，由从设备向主设备发送延迟响应取消(Delay_resp/Pdelay_resp.Cancel)报文；再由主设备向从设备返回延迟响应取消确认(Delay_resp/Pdelay_resp.Cancel Ack)报文，进而拆除延迟响应报文的单播协商链路。

(2-5)如果建立有同步(Sync)报文的单播协商链路，则进行同步(Sync)报文的单播协商链路的拆除过程；具体地，由从设备向主设备发送同步取消(Sync.Cancel)报文；再由主设备向从设备返回同步取消确认(Sync.Cancel Ack)报文，进而拆除同步报文的单播协商链路。

(2-6)如果建立有通知(Announce)报文的单播协商链路，则进行通知(Announce)报文的单播协商链路的拆除过程；具体地，由从设备向主设备发送通知取消(Annouce.Cancel)报文；再由主设备向从设备返回通知取消确认(Annouce.Cancel Ack)报文，进而拆除通知报文的单播协商链路。

需要说明的是，当从设备与主设备的通知报文的单播协商通过，即通知报文的单播协商链路建立成功后，从设备向主设备单播发送保活报文，主设备接收所述从设备发来的保活报文，根据所述保活报文确定发送该保活报文的从设备的状态有效性；根据对应从设备的状态有效性信息及所述通知报文的单播协商结果，向所述从设备中状态为有效的从设备单播发送通知报文。从设备根据收到的通知报文选择一个主设备作为源设备。

以及，当从设备与源设备的同步报文的单播协商通过，即同步报文的单播协商链路建立成功后，源设备根据对应从设备的状态有效性信息确定该从设备状态为有效时，根据所述同步报文的单播协商结果向该从设备单播发送同步报文。

以及，当从设备与源设备的延迟响应报文的单播协商通过，即延迟响应报文的单播协商链路建立成功后，源设备根据对应从设备的状态有效性信息确定该从设备状态为有效时，根据所述延迟响应报文的单播协商结果向该从设备单播发送延迟响应报文。

可见，通过本实施例所述方法，在各种不同的单播协商报文之间增加了协商时序性或连贯的约束关系，其中，通知报文是控制面报文，负责建立时钟链路和触发选源，只有当通知报文协商通过后，才能进行选源；选源完成后，才会向被选中的源设备发起同步报文的单播协商，从而进行时钟的同步操作；同样，也只有同步报文的协商通过之后，才能根据自身的属性，去协商延迟响应报文。

方法实施例三

本实施例提供了另一种单播环境下的通信方法，如图7所示，以通知报文的单播协商为例子，从设备与主设备之间的单播协商具体可以包括如下步骤：

步骤301，从设备向自身维护的单播主设备信息中的主设备单播发送通知请求(Request)报文。

步骤302，主设备接收到所述通知请求报文后，根据该主设备自身维护的单播从设备信息，向所述从设备返回携带有授权信息的通知授权(Grant)报文。

例如，判断所述从设备是否包含在该单播从设备信息中，若所述从设备包含在该单播从设备信息中，则所述授权信息表示同意授权，如“R＝TRUE”，以表明同意向从设备授权；若所述从设备不包含在该单播从设备信息中，则所述授权信息表示拒绝授权，如“R＝FALSE”，以表明拒绝向从设备授权。

步骤303，所述从设备接收到所述通知授权报文后，获取该通知授权报文中的授权信息。

步骤304，当所述授权信息表示同意授权时，所述从设备与所述主设备的通知报文的单播协商链路建立成功。

其中，单播从设备信息可供用户配置，用以在收到从设备端发起的单播请求之后，查询用户配置的单播从设备信息中的各表项，来决定是否同意授权。具体地，还可以提供单播从设备信息的列表使能功能，如果该单播从设备信息被使能，则允许对其进行查表操作，否则不允许进行查表操作。如果用户没有使能单播从设备信息，则单播从设备信息的表项可以在主设备授权时由具体的单播请求生成；如果使能了单播从设备信息，则可以参照配置的单播从设备信息的表项判断是否同意授权。

需要说明的是，单播协商报文包括：通知(Announce)报文、同步(Sync)报文、点对点(Point to Point，简称：P2P)延迟响应报文(Delay_Resp)报文和端对端(End to End，简称：E2E)延迟响应报文(Pdelay_Resp)报文，其中每种单播协商报文的单播协商如上所述，故不再赘述。

以下，具体说明各种单播协商报文的单播协商过程。

如图8所示，为通知报文的单播协商过程的流程图，包括如下步骤：

步骤3101，从设备向自身维护的单播主设备信息中的主设备单播发送通知请求报文。

步骤3102，主设备判断自身维护的单播从设备信息是否被使能，若该单播从设备信息被使能，则执行步骤3111；若该单播从设备信息未被使能，则执行步骤3121。

步骤3111，查询单播从设备信息，判断发送该通知请求报文的从设备是否包含在所述单播从设备信息中。是则执行步骤3141，向该从设备发送携带有表示同意授权的授权信息通知授权报文，其中的授权信息可以表示为“R＝TRUE”；否则执行步骤3142，向该从设备发送携带表示拒绝授权的授权信息的通知授权报文，其中的授权信息可以表示为“R＝FASLE”。

应当理解的是，通知报文的单播协商过程中可以包括：授权与否的确定，以及如果授权同意，具体授权参数的协商，关于授权参数的协商请参见后面实施例的描述。

具体地，可以通过该通知请求报文的源IP地址等信息，来判断相应的从设备是否包含在所述单播从设备信息中。

步骤3121，判断该主设备接收到的所有请求报文所对应的从设备的数目是否超过预定值，如果没超过则执行步骤3151，生成单播从设备动态表的表项，并向该从设备发送携带有表示同意授权的授权信息的通知授权报文；否则执行步骤3152，向该从设备发送携带有表示拒绝授权的授权信息的通知授权报文。

其中，预定值是指主设备能够接收来自多少个从设备的报文，预先设定该预定值是因为主设备处理或者转发报文的能力总是有限的，以避免主设备进行超负荷工作。

需要说明的是，单播协商报文包括：通知(Announce)报文、同步(Sync)报文、点对点(Point to Point，简称：P2P)延迟响应报文(Delay_Resp)报文和端对端(End to End，简称：E2E)延迟响应报文(Pdelay_Resp)报文，上述以通知报文的单播协商过程为例子，其中每种单播协商报文的单播协商如上所述，故不再赘述。

如图9所示，为当通知报文的单播协商通过后，从设备与选中的源设备之间进行同步报文的单播协商过程的流程图，包括如下步骤：

步骤3201，源设备接收来自于从设备的同步请求报文。

步骤3202，确定已授权同意该从设备的通知请求报文，根据自身维护的单播从设备信息，向该从设备返回携带有授权信息的同步授权报文。

具体地，查询该主设备中的单播从设备信息，判断发送该同步请求报文的从设备是否包含在所述单播从设备信息中，是则执行步骤3211，向该从设备发送携带有表示同意授权的授权信息的同步授权报文；否则执行步骤3221，向该从设备发送携带有表示拒绝授权的授权信息的同步授权报文。

其中，该单播从设备信息可以是动态生成的，也可以是手动配置的。动态生成是指主设备当单播从设备信息没有被使能时，通过接收的通知报文发起单播请求且授权后生成单播从设备信息的过程。与动态生成的单播从设备信息相对应的是静态的单播从设备信息，也就是在使能单播从设备信息后，手动配置的单播从设备信息。

需要说明的是，同步请求报文是由从设备向主设备发的，主设备授权(授权信息表示同意授权)之后协商链路就建立成功了，而具体的同步报文相当于业务报文，在成功建立的协商链路上由主设备发送业务报文，因此，在本实施例所述的有关同步报文的单播协商过程中，可以不对单播从设备信息设置使能功能。

步骤3203，所述接收到来自于所述源设备的同步授权报文后，获取该同步授权报文中的授权信息，当所述授权信息表示同意授权时，则与所述源设备的同步报文的单播协商链路建立成功；否则建立失败。

完成同步的报文的单播协商后，该主设备根据对应的从设备的状态有效性信息确定该从设备状态为有效时，根据所述同步报文的单播协商结果向该从设备发送同步报文。

此后，如图10所示，为当同步报文的单播协商通过后，从设备与源设备进行延迟响应报文的单播协商过程的流程图，包括如下步骤：

步骤3301，从设备接收来自于所述源设备的同步报文后，向该源设备发送延迟响应请求报文。

具体地，当确定为端对端模式下的时间同步时，该延迟响应请求报文为点对点的延迟响应报文，用于与所述源设备进行端对端的延迟响应报文的单播协商；当确定为点对点模式下的时间同步时，该延迟响应请求报文为端对端的延迟响应报文，用于与所述源设备进行点对点的延迟响应报文的单播协商。这里的确定，可以是从设备通过检查所配置的时间同步的模式，来确定时间同步的模式。

步骤3302，主设备确定已授权同意该从设备的通知请求报文和同步请求报文后，根据本主设备自身维护的单播从设备信息，向该从设备返回携带有授权信息的延迟响应授权报文。

具体地，查询自身的单播从设备信息，判断发送该延迟响应请求报文的从设备是否包含在所述单播从设备信息中，是则执行步骤3311向该从设备发送携带有表示同意授权的授权信息的延迟响应授权报文；否则执行步骤3321，向该从设备发送携带有表示拒绝授权的授权信息的延迟响应授权报文。

上述延迟响应报文的单播协商通过后，主设备根据对应从设备的状态有效性信息确定该从设备状态为有效时，根据所述延迟响应报文的单播协商结果向该从设备发送延迟响应报文。

可见，本实施例中，主设备通过查询单播从设备信息，判断所述从设备是否包含在该单播从设备信息中，进而决定是否向该从设备授权，因此完善了在单播环境下的主设备向从设备的授权方式，从而能够有效地防止非法的从设备的接入。

方法实施例四

前述实施例描述了主设备向从设备授权的方式，当所述从设备包含在该单播从设备信息(具体可以是单播从设备表)中，向所述从设备返回携带有授权信息的通知授权报文，而授权信息具体可以包含参数，以及表示是否授权同意的“R＝FASLE”或“R＝TRUE”，或者，授权信息包含参数。

本实施例提供了另一种单播环境下的通信方法，在上述各种报文的单播协商过程中，从设备与主设备之间还进行参数协商，不同类型报文的参数协商过程基本相同，以下仅以通知报文的参数协商过程为例进行说明。如图11所示，通知报文的参数协商过程，包括如下步骤：

步骤401，从设备向主设备发送携带有该从设备的第一协商周期和第一持续时间的通知请求报文。

其中，第一协商周期(logInterMessagePeriod)和第一持续时间(durationField)是该从设备待协商的参数。协商周期是指协商成功后报文的收发间隔，即多长时间发送或接收一个报文；持续时间是指相应报文收发过程的持续时间。例如：假设请求报文的协商周期为3秒，持续时间是1小时。其相应的含义为：每隔3秒发送一个请求报文，经过1小时后，就不再发送该请求报文。

步骤402，主设备收到该通知请求报文后，将该从设备的第一协商周期和第一持续时间与该主设备的第二协商周期和第二持续时间进行比较，选择第一协商周期和第二协商周期中的最大值，及第一持续时间和第二持续时间中的最小值。

步骤403，主设备向该从设备返回携带有授权信息的通知授权报文，所述授权信息包含第一协商周期和第二协商周期中的最大值，及第一持续时间和第二持续时间中的最小值。

需要说明的是，所述授权信息中还可以包含表示是否授权同意的信息，如“R＝FASLE”或“R＝TRUE”。

例如，如图12所示，用“GRANTMSG”表示授权报文，“REQMSG”表示请求报文，则主设备给从设备返回的协商值应该为：

GRANTMSG.logInterMes sagePeriod＝MAX(REQMSG.logInterMessagePe-riod，MasterCfg.logInterMessagePeriod)

其中，“GRANTMSG.logInterMes sagePeriod”表示授权报文中的协商后选择的协商周期；“REQMSG.logInterMessagePeriod”表示请求报文中携带的从设备协商周期；“MasterCfg.logInterMessagePeriod”表示主设备协商周期；“MAX”表示取最大值。

GRANTMSG.durationField＝MIN(REQMSG.durationField，MasterCfg.durationField)

其中，“GRANTMSG.durationField”表示授权报文中的协商后选择的持续时间；“REQMSG.durationField”表示请求报文中携带的从设备持续时间；“MasterCfg.durationField”表示主设备持续时间；“MIN”表示取最小值。

此处需要说明的是，该授权信息中除了包含协商后的参数以外，还包括表示该设备是否同意授权从设备的信息，从而完成通知消息的单播协商。具体内容可参考上述方法实施例三，此处不再赘述。

如图11所示的通知报文的参数协商过程中，从设备向主设备发送携带有该从设备的第一协商周期和第一持续时间的通知请求报文，需要说明的是，如果从设备发送的通知请求报文中不携带有请求参数，在一种实现下，主设备可以根据前述实施例描述的方法确定自身的单播从设备信息中包含该从设备(确定授权同意该从设备)后，返回的通知授权报文中携带该主设备的第二协商周期和第二持续时间。

另外，当主设备返回给从设备的授权信息中的协商后所选择的持续时间到达时，主设备将不会再给从设备提供业务，为了保证业务的正常开展，从设备可以在所述持续时间完全到达或部分到达时，重新向主设备发起单播协商。具体地，可以针对不同类型的报文，重新发起通知报文的单播协商；或重新发起同步报文的单播协商；或重新发起延迟响应报文的单播协商。

例如，如图13所示，为持续时间到达75％时，重新发起通知报文的单播协商的信令图。

可见，通过本实施例所述方法，完善了单播环境中的参数协商机制，可以杜绝收发包频率过快，以至于超过系统处理能力等事件的发生，并且通过参数的重协商机制，还可以在保证协商周期到期后，继续提供业务，以保证业务不中断。

系统实施例一

本实施例提供了一种单播通信系统，如图14所示，包括从设备10和主设备20，该系统包括：

从设备10，用于与主设备20在进行通知报文的单播协商通过后，向所述主设备20单播发送保活报文，根据来自于所述主设备20的通知报文从所述主设备中选择一个主设备作为源设备；

主设备20，用于与从设备10在进行通知报文的单播协商通过后，根据所述从设备10发来的保活报文确定发送该保活报文的从设备的状态有效性；根据对应从设备的状态有效性信息及所述通知报文的单播协商结果，向所述从设备中状态为有效的从设备单播发送通知报文。

可见，通过本实施例所述系统中，从设备与主设备进行通知报文的单播协商通过后，从设备向主设备单播发送保活报文，使主设备能够根据所述保活报文确定发送该保活报文的从设备的状态有效性，从而使得主设备能感知相应从设备的状态是否有效(即是否在线)，根据对应从设备的状态有效性信息及所述通知报文的单播协商结果，向状态为有效的从设备(即在线的从设备)单播发送通知报文，避免了当某从设备离线后仍发送通知报文的问题，而当得知某个从设备离线后，则可以删除本地的相关从设备资源，从而能够节省资源和系统开销，避免冗余异常。

装置实施例一

请参见图15，为本发明实施例的一种从设备10的结构示意图，如图所示，所述从设备10包括：

通知协商从模块11，用于与至少一个主设备20进行通知报文的单播协商；

保活从模块12，用于在所述通知协商从模块进行的通知报文的单播协商通过后，向所述至少一个主设备单播发送保活报文；

授权处理模块13，用于接收来自于所述主设备的通知报文后，根据所述通知报文从所述主设备中选择一个主设备作为源设备。

在一种实现下，通知协商从模块11，具体用于向自身维护的单播主设备信息中的主设备单播发送通知请求报文；接收来自于主设备的通知授权报文后，获取该通知授权报文中的授权信息，当所述授权信息表示同意授权时，则与所述主设备的通知报文的单播协商链路建立成功，换言之，即完成了通知报文的单播协商过程。

以及，本发明实施例的从设备进一步包括：

同步协商从模块14，用于向所述源设备发送同步请求报文，并在接收到来自于所述源设备的同步授权报文后，获取该同步授权报文中的授权信息，当所述授权信息表示同意授权时，确定与所述源设备的同步报文的单播协商链路建立成功；

相应地，授权处理模块13，进一步用于接收所述源设备发来的同步报文。

以及，本发明实施例的从设备10进一步包括：

延迟协商从模块15，用于在所述授权处理模块13接收来自于所述源设备20的同步报文后，确定为端对端模式下的时间同步时，与所述源设备20进行端对端的延迟响应报文的单播协商；当确定为点对点模式下的时间同步时，与所述源设备20进行点对点的延迟响应报文的单播协商；

具体地，从设备10中的延迟协商从模块15与所述源设备20进行延迟响应报文的单播协商的过程参见前述的方法实施例，不再赘述。

相应地，授权处理模块13，进一步用于在所述延迟响应报文的单播协商通过后，接收来自于所述源设备20的延迟响应报文。

需要说明的是，单播协商报文包括：通知(Announce)报文、同步(Sync)报文、点对点(Point to Point，简称：P2P)延迟响应报文(Delay_Resp)报文和端对端(End to End，简称：E2E)延迟响应报文(Pdelay_Resp)报文，共四种报文。针对同步报文而言，在进行同步报文的单播协商过程中涉及同步请求报文(Sync.Req)、同步授权报文(Sync.Grant)，应当理解的是，如果概括地说，即针对单播协商报文而言，在进行单播协商报文的单播协商过程中涉及单播协商请求报文、单播协商授权报文。

以及，本发明实施例的从设备10进一步包括：

重协商模块16，用于在所述单播协商授权报文(如同步授权报文)中的授权信息中的持续时间完全到达或部分到达时，触发对应的协商从模块(如同步协商从模块)重新进行所述同步报文的单播协商。

具体地，当通知协商从模块11接收到的通知授权报文中携带的授权信息中的持续时间完全到达或部分到达时，由重协商模块16触发所述通知协商从模块11重新进行所述通知报文的单播协商。

另外，针对同步报文的重协商过程，当同步协商从模块14接收到的同步授权报文中携带的授权信息中的持续时间完全到达或部分到达时，由重协商模块16触发所述同步协商从模块14重新进行所述同步报文的单播协商。

另外，针对延迟响应报文的重协商过程，当延迟协商从模块15接收到的延迟授权报文中携带的授权信息中的持续时间完全到达或部分到达时，由重协商模块16触发所述延迟协商从模块15重新进行所述延迟报文的单播协商。

可见，本实施例的从设备与主设备进行通知报文的单播协商通过后，向主设备发送保活报文，使主设备能够得知相应从设备的状态有效性，给在线的从设备发送通知报文，避免了当某从设备离线后仍发送通知报文的问题，而当得知某个从设备离线后，则可以删除本地的相关从设备资源，从而能够节省资源和系统开销，避免冗余异常。

装置实施例二

请参见图16，为本发明实施例的一种主设备20的结构示意图，如图所示，所述主设备20包括：

通知协商主模块21，用于与至少一个从设备10进行通知报文的单播协商；

保活主模块22，用于根据接收到的来自于所述从设备10的保活报文，确定发送该保活报文的从设备的状态有效性；

发送模块23，用于根据所述保活主模块22确定的对应从设备10的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备10中状态为有效的从设备单播发送通知报文。

其中，通知协商主模块21，具体用于接收来自于从设备10的通知请求报文，根据该主设备20自身维护的单播从设备信息向所述从设备10返回携带有授权信息的通知授权报文。

以及，本发明实施例的主设备20进一步包括：

同步协商主模块24，用于接收来自于所述从设备10的同步请求报文，确定已授权同意该从设备的通知请求报文，根据维护的单播从设备信息向该从设备10返回携带有授权信息的同步授权报文；

相应的，发送模块23，进一步用于根据对应从设备10的状态有效性信息确定该从设备状态为有效时，根据所述同步授权报文中的授权信息向该从设备10发送同步报文。

以及，本发明实施例的主设备20进一步包括：

延迟协商主模块25，用于接收来自于所述从设备10的延迟响应请求报文，确定已授权同意该从设备的通知请求报文和同步请求报文，根据维护的单播从设备信息向该从设备10返回携带有授权信息的延迟响应授权报文。

相应地，发送模块23，进一步用于根据对应从设备10的状态有效性信息确定该从设备10状态为有效时，根据所述延迟响应授权报文中的授权信息向该从设备10发送延迟响应报文。

可见，本实施例所述的主设备20中，在与从设备10进行通知报文的单播协商通过后，根据接收的来自从设备10的保活报文确定发送该保活报文的从设备10的状态有效性，从而使得主设备20能感知相应从设备10的状态是否有效(即是否在线)，根据对应从设备10的状态有效性信息及所述通知报文的单播协商结果，向状态为有效的从设备(即在线的从设备)单播发送通知报文，避免了当某从设备离线后仍发送通知报文的问题，从而能够节省资源和系统开销。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)或随机存储记忆体(Random Acces s Memory，RAM)等。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (21)

1.一种单播环境下的通信方法，其特征在于，包括：

从设备与至少一个主设备在进行通知报文的单播协商通过后，从设备向所述至少一个主设备单播发送保活报文，使得所述主设备根据所述保活报文，确定发送该保活报文的从设备的状态有效性，根据对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备中状态为有效的从设备单播发送通知报文；

从设备接收来自于所述主设备的通知报文后，根据所述通知报文，从所述至少一个主设备中选择一个主设备作为源设备。

2.根据权利要求1所述的单播环境下的通信方法，其特征在于，所述向所述至少一个主设备单播发送保活报文，包括：

向所述至少一个主设备周期性地主动单播发送保活报文；或者，

接收到主设备发送的状态检测报文后，向所述主设备单播发送与该状态检测报文对应的保活报文。

3.根据权利要求1所述的单播环境下的通信方法，其特征在于，所述从设备与至少一个主设备进行通知报文的单播协商，包括：

从设备向自身维护的单播主设备信息中的主设备单播发送通知请求报文；

接收来自于主设备的通知授权报文后，获取该通知授权报文中的授权信息，当所述授权信息表示同意授权时，则与所述主设备的通知报文的单播协商链路建立成功。

4.根据权利要求3所述的单播环境下的通信方法，其特征在于，所述选择一个主设备作为源设备之后，进一步包括：

从设备向所述源设备发送同步请求报文；

接收到来自于所述源设备的同步授权报文后，获取该同步授权报文中的授权信息，当所述授权信息表示同意授权时，则与所述源设备的同步报文的单播协商链路建立成功。

5.根据权利要求4所述的单播环境下的通信方法，其特征在于，从设备与所述源设备的同步报文的单播协商链路建立成功之后，进一步包括：

接收来自于所述源设备的同步报文；

当确定为端对端模式下的时间同步时，与所述源设备进行端对端的延迟响应报文的单播协商；

当确定为点对点模式下的时间同步时，与所述源设备进行点对点的延迟响应报文的单播协商；

当所述延迟响应报文的单播协商通过后，接收来自于所述源设备的延迟响应报文。

6.权利要求3所述的单播环境下的通信方法，其特征在于，所述获取该通知授权报文中的授权信息之后，进一步包括：

当所述授权信息中的持续时间完全到达或部分到达时，与相应的主设备重新进行所述通知报文的单播协商。

7.一种单播环境下的通信方法，其特征在于，包括：

主设备与至少一个从设备在进行通知报文的单播协商通过后，接收所述从设备发来的保活报文；

根据所述保活报文，确定发送该保活报文的从设备的状态有效性；

根据对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备中状态为有效的从设备单播发送通知报文。

8.根据权利要求7所述的单播环境下的通信方法，其特征在于，所述接收所述从设备发来的保活报文之前，进一步包括：

根据自身维护的单播从设备信息向对应的从设备发送状态检测报文。

9.根据权利要求7所述的单播环境下的通信方法，其特征在于，所述主设备与至少一个从设备进行通知报文的单播协商，包括：

接收来自于从设备的通知请求报文，根据该主设备自身维护的单播从设备信息，向所述从设备返回携带有授权信息的通知授权报文。

10.根据权利要求9所述的单播环境下的通信方法，其特征在于，所述向所述至少一个从设备中状态为有效的从设备单播发送通知报文之后，进一步包括：

接收来自于该从设备的同步请求报文；

确定已授权同意该从设备的通知请求报文，根据自身维护的单播从设备信息，向该从设备返回携带有授权信息的同步授权报文；

根据对应从设备的状态有效性信息，确定该从设备状态为有效时，根据所述同步授权报文中的授权信息向该从设备发送同步报文。

11.根据权利要求10所述的单播环境下的通信方法，其特征在于，所述向该从设备发送同步报文之后，进一步包括：

接收来自于该从设备的延迟响应请求报文；

确定已授权同意该从设备的通知请求报文和同步请求报文，根据自身维护的单播从设备信息，向该从设备返回携带有授权信息的延迟响应授权报文；

根据对应从设备的状态有效性信息确定该从设备状态为有效时，根据所述延迟响应授权报文中的授权信息向该从设备发送延迟响应报文。

12.根据权利要求9所述的单播环境下的通信方法，其特征在于，所述根据该主设备自身维护的单播从设备信息，向所述从设备返回携带有授权信息的通知授权报文，包括：

确定该单播从设备信息被使能时，查询该单播从设备信息，当所述从设备包含在该单播从设备信息中时，向所述从设备返回携带有授权信息的通知授权报文。

13.根据权利要求12所述的单播环境下的通信方法，其特征在于，如果所述通知请求报文中携带有该从设备的第一协商周期和第一持续时间，则所述向所述从设备返回携带有授权信息的通知授权报文，包括：

将所述第一协商周期和第一持续时间与该主设备的第二协商周期和第二持续时间进行比较；

选择第一协商周期和第二协商周期中的最大值，及第一持续时间和第二持续时间中的最小值；

向所述从设备返回携带有授权信息的通知授权报文，所述授权信息包含第一协商周期和第二协商周期中的最大值，及第一持续时间和第二持续时间中的最小值。

14.一种从设备，其特征在于，包括：

通知协商从模块，用于与至少一个主设备进行通知报文的单播协商；

保活从模块，用于在所述通知协商从模块进行的通知报文的单播协商通过后，向所述至少一个主设备单播发送保活报文，使得所述主设备根据所述保活报文，确定发送该保活报文的从设备的状态有效性，根据对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备中状态为有效的从设备单播发送通知报文；

授权处理模块，用于接收来自于所述主设备的通知报文后，根据所述通知报文，从所述至少一个主设备中选择一个主设备作为源设备。

15.根据权利要求14所述的从设备，其特征在于，所述从设备进一步包括：

同步协商从模块，用于向所述源设备发送同步请求报文，并在接收到来自于所述源设备的同步授权报文后，获取该同步授权报文中的授权信息，当所述授权信息表示同意授权时，确定与所述源设备的同步报文的单播协商链路建立成功；

所述授权处理模块，进一步用于接收所述源设备发来的同步报文。

16.根据权利要求15所述的从设备，其特征在于，所述从设备进一步包括：

延迟协商从模块，用于在所述授权处理模块接收到来自于所述源设备的同步报文后，确定为端对端模式下的时间同步时，与所述源设备进行端对端的延迟响应报文的单播协商；当确定为点对点模式下的时间同步时，与所述源设备进行点对点的延迟响应报文的单播协商；

所述授权处理模块，进一步用于在所述延迟响应报文的单播协商通过后，接收来自于所述源设备的延迟响应报文。

17.根据权利要求15或16所述的从设备，其特征在于，所述从设备进一步包括：

重协商模块，用于在所述同步授权报文中的授权信息中的持续时间完全到达或部分到达时，触发所述同步协商从模块重新进行所述同步报文的单播协商。

18.一种主设备，其特征在于，包括：

通知协商主模块，用于与至少一个从设备进行通知报文的单播协商；

保活主模块，用于根据接收到的来自于所述从设备的保活报文，确定发送该保活报文的从设备的状态有效性；

发送模块，用于根据所述保活主模块确定的对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述至少一个从设备中状态为有效的从设备单播发送通知报文。

19.根据权利要求18所述的主设备，其特征在于，所述主设备进一步包括：

同步协商主模块，用于接收来自于所述从设备的同步请求报文，确定已授权同意该从设备的通知请求报文，根据维护的单播从设备信息向该从设备返回携带有授权信息的同步授权报文；

所述发送模块，进一步用于根据对应的从设备的状态有效性信息确定该从设备状态为有效时，根据所述同步授权报文中的授权信息向该从设备发送同步报文。

20.根据权利要求19所述的主设备，其特征在于，所述主设备进一步包括：

延迟协商主模块，用于接收来自于所述从设备的延迟响应请求报文，确定已授权同意该从设备的通知请求报文和同步请求报文，根据维护的单播从设备信息向该从设备返回携带有授权信息的延迟响应授权报文；

所述发送模块，进一步用于根据对应从设备的状态有效性信息确定该从设备状态为有效时，根据所述延迟响应授权报文中的授权信息向该从设备发送延迟响应报文。

21.一种单播通信系统，其特征在于，包括：

从设备，用于与至少一个主设备在进行通知报文的单播协商通过后，向所述至少一个主设备单播发送保活报文，根据来自于所述主设备的通知报文从所述至少一个主设备中选择一个主设备作为源设备；

主设备，用于与从设备在进行通知报文的单播协商通过后，根据所述从设备发来的保活报文确定发送该保活报文的从设备的状态有效性；根据对应的从设备的状态有效性信息及所述通知报文的单播协商结果，向所述从设备中状态为有效的从设备单播发送通知报文。

Images