CN101488835A - 一种链路检测方法、装置和通信系统 - Google Patents

Abstract

本发明公开了一种链路检测方法、装置和通信系统，包括：用多元组标识至少一条用户数据流；在预设的统计周期开始时，接收并获取所述用户数据流中下行方向开始报文的序列号，启动计数器，将实收报文数记为1，之后每收到一个报文计数器加1；统计周期结束时接收并获取结束报文的序列号，根据开始报文序列号和结束报文序列号计算应收报文数；根据应收报文数和实收报文数计算丢包数和/或丢包率。系统包括：装置1：用于用多元组标识至少一条用户数据流；装置2：用于接收并获取所述用户数据流中下行方向报文序列号；装置3：用于对实际收到的报文进行计数；装置4：用于计算所述统计周期内应收报文数；装置5：用于计算丢包数和/或丢包率。

Description

一种链路检测方法、装置和通信系统

技术领域

本发明涉及通信领域，特别涉及一种链路检测方法、装置和通信系统。

背景技术

GTP(General Packet Radio Service Tunnel Protocol)协议应用在GSN(GPRS Support Node，GPRS服务节点，包括GGSN和SGSN)之间，为各个移动台(MS)建立GTP通道，GTP通道是GSN之间的安全通道，两个主机可通过该通道交换数据。GTP承载在UDP(user datagram protocol，用户数据报文)或TCP(transmission control protocol，传输控制协议)之上，分为信令平面和传输平面，其中信令平面定义了多种消息，传输平面则提供了GSN之间数据包传送的隧道，GTP协议分为GTP-C，GTP-U和GTP’协议，其中，GTP-C是信令控制协议，GTP-U是封装用户数据协议，GTP’是计费相关的协议。在GTP协议中存在一个TEID(Tunnel End Point Identifier，隧道端点标识)，该标识无歧义地标识了数据接收方GTP-U或GTP-C协议实体上的隧道终结点。一个GTP隧道的两端节点各自分配本方准备在该隧道上接收特定数据时使用的TEID标识，并通过GTP-C消息进行节点间的协商。此外，通用路由封装(GRE，GenericRouting Encapsulation)也是一种常用的隧道协议，GRE定义了在任意一种网络层协议上封装任意一个其它网络层协议的协议，GRE协议能封装IP隧道中的多种协议包，通过IP网络创建一条虚拟点到点的链路。在现有技术中，基站和控制器侧通常采用IPPM(IP Performance Monitoring，性能监控)完成中间网络传输链路的检测，但申请人在实现本发明的过程中发现：现有的检测方法对于检测设备之间的兼容性要求较高，如果检测端设备和对端设备是由不同厂商提供的，则可能导致检测难以完成；此外，现有的检测方法需要控制面做较为复杂的计算和配置，对系统资源消耗巨大。

发明内容

本发明实施例所要解决的技术问题在于提供一种链路检测方法、装置和通信系统。

为解决上述技术问题，本发明实施例提供了一种链路检测方法，包括以下步骤：

用多元组标识至少一条用户数据流；在预设的统计周期开始时，接收并获取所述用户数据流中下行方向开始报文的序列号，启动计数器，将实收报文数记为1；在所述统计周期内，每收到一个报文，将所述计数器中实收报文数加1；统计周期结束时，接收并获取所述用户数据流中下行方向结束报文的序列号；根据所述下行方向开始报文序列号和结束报文序列号计算应收报文数；根据所述应收报文数和实收报文数计算丢包数和/或丢包率。

此外，本发明实施例还提供了一种链路检测的装置，包括：第一单元，用于用多元组标识至少一条用户数据流；第二单元，用于在预设统计周期内接收并获取所述用户数据流中下行方向报文序列号；第三单元，用于对所述统计周期内实际收到的报文进行计数；第四单元：用于根据所述第二单元接收并获取的报文序列号计算所述统计周期内应收报文数；第五单元：用于根据第三单元及第四单元的计算结果计算所述统计周期内的丢包数和/或丢包率。

此外，本发明实施例还提供了一种通信系统，包括前述的链路检测装置。

与现有技术相比较，本发明实施例提供的方法、装置和通信系统不需要对端设备参与即能检测链路质量，即使不同厂商的设备对接也不影响检测的实施，并且实现简单，消耗的系统资源少。

附图说明

图1为本发明实施例的方法示意图；

图2为本发明实施例的系统示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面结合附图对本发明的实施例作进一步的详细描述。

实施例一

本实施例提供了一种链路检测的方法，该检测方法为面向数据流ID(flowID)的链路检测，也就是说以数据流ID为统计对象对用户数据流进行的检测和统计。本实施例的方法包括：首先标识用户数据流，此处用户数据流的含义并不用于限定为用户设备与通信设备之间的数据流，而是为了与控制面的控制流区分开而使用的概念，用户数据流包括通信中产生的端到端的各种业务流，例如可以是手机通话产生的端到端的数据流，还可以是用户上网时使用BT业务产生的端到端的数据流，还可以是用户使用FTP业务产生的端到端的数据流等。同时，标识用户数据流的方法也有多种，例如可以用三元组或者五元组来标识。此外，单个用户在通信过程中可以产生一条或者多条用户数据流，也就是说可以对应一个或多个流ID，在一个统计周期内，既可以仅针对其中一条用户数据流进行统计，也可以对多条用户数据流进行统计。

预设一个统计周期T，统计周期可以根据统计精度的要求进行调整，例如，可以设为5秒，当统计周期开始时，接收并获取其中开始报文的序列号，将收到的第一个报文记为实收报文，同时启动计数器，将实收报文数记为1，当然，此处计数器的初始计数也可以不为1，当计数器的初始计数不为1时，可以在统计周期开始时读取一次计数器的初始计数值，当统计周期结束时，在计数器的计数中减去统计周期开始时读取到的初始计数值；在接下来的统计周期内，单条流上每接收到一个报文序列号计数器统计的实收报文数加1；在统计周期结束时，接收基于流ID的用户数据流并获取其中下行方向结束报文的序列号；根据开始报文的序列号和结束报文的序列号可以计算出应该收到的报文数即应收报文数，根据计算出的应收报文数和计数器中统计的实收报文数计算丢包数和/或丢包率。在检测过程中可以将检测端接收到的数据流定义为下行数据流，本实施例中对于用户数据流所作的统计是针对用户数据流中下行方向的报文进行的统计，也就是对检测端收到的数据流中的报文进行的统计，所述统计在检测端即可完成。

本实施例提供的方案可以借助设备的固有特性，无需做端到端的实现，在检测端即可完成检测过程，对端设备可以不用参与，在实践中，常常存在不同厂商的设备对接使用的情况，利用本实施例提供的方案，即使不同厂商的设备对接也不会影响检测的实施，具有很好的兼容性；此外，由于不需要对端设备的参与，本实施例的方法实现更为简单，不需要控制面做较为复杂的计算和配置，消耗的系统资源更少，而且可以做到对于链路质量的实时检测和闭环调控。

实施例二

本实施例提供了一种链路检测的方法。首先对本实施例中涉及的GTP消息帧结构进行介绍，如下表所示，GTP V1版本的消息首部由固定部分和可选部分组成。固定部分包括8个字节，描述了GTP消息所使用的版本号、标志位信息、GTP消息类型、消息长度、和TEID域。可选部分包括序列号、N-PDU号、扩充部分，这些可选部分的存在与否由标识位的值决定。

表1

其中，Version域定义了GTP采用的版本号，在V1版本中设为′001′；

PT域是协议区分符，用于区分GTP和GTP′消息；E域(Extension Header flag)用于指明是否存在扩充首部；S域(Sequence Number Flags)用于指明是否存在SN域的标识位；PN域用于指明GTP消息首部是否存在N-PDU域；MessageType域用于指明GTP消息类型；Length域指出了消息中除固定长度的消息部分之外的字节长度；TEID域表示了接收方分配接收端的TEID，并通过GTP-C、RANAP等消息与发送方进行TEID的协商；在GTP V1版本中Sequence Number域是可选域部分；N-PDU Number域也是可选域部分，用于SGSN间的路由区更新过程和SRNS relocation过程。Next Extension Header Type是GTP消息头的扩充部分，可以保持与以后版本的兼容性。

接下来对GRE帧结构进行介绍，如表2所示，GRE帧结构如下：

0                    1                    2                    3

 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|c|R|K|S|s|Recur|Flags|Ver|           Protocol Type            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|        Checksum(optional)|             Offset(optional)       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                   Key(optional)                                |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|               Sequence Number(optional)                        |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                                  Routing(optional)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

表2

其中GRE帧结构与GTP的帧结构相比，其中Key字段相当于GTP帧中的TEID，而序列号Sequence Number参数与GTP的帧结构中的Sequence Number一样，而且是可选的。

如图1所示，在本实施例的方法包括：首先用多元组标识出至少一条用户数据流；

这里，标识用户数据流的方法有多种，例如可以用三元组或者五元组来标识，如果采用三元组的方法，则可以用源IP、目的IP、协议类型来标识至少一条用户数据流；如果采用五元组的方法，则可以用源IP、目的IP、源端口、目的端口、协议类型来标识至少一条用户数据流，当然本领域技术人员还可以想到有其他的扩展方式来标识至少一条用户数据流，此外，在对标识出的用户数据流进行检测过程中可以流ID为单位对报文进行统计和检测，这里所说的流ID(flow ID)根据报文类型不同可以有多种，例如，对于GTP报文来说，流ID可以是TEID；在实际应用中GRE报文中的Key字段通常处理为必选的，因此，对于GRE报文来说，流ID可以是Key。

接下来，在预设的统计周期开始时，接收并获取所述用户数据流中下行方向开始报文的序列号，启动计数器，将实收报文数记为1；

获取用户数据流中下行方向开始报文的序列号的方法可以有多种，例如，根据前面关于GTP帧结构的描述，GTP报文帧结构中有一部分字段是可选的，因此，可以考虑利用GTP报文帧结构中的可选字段来携带报文序列号，例如可以利用GTP报文帧结构中的Sequence Number字段来携带开始报文的序列号；此外，开始报文的序列号还可以通过用户数据流下行方向的GRE报文来携带，考虑到GRE报文帧结构中有一部分字段也是可选的，因此可以利用例如GRE报文中的Sequence Number字段来携带开始报文的序列号，例如，下行方向数据流的序列号可以16进制来表示，从0到0Xffffffff以4字节长度递增并允许翻转。此外，为了统计实际收到的报文数，可以启动一个计数器，将开始实际收到的报文数记为1。具体的，可以设置一个变量BeginSeqNo，将接收到的报文的序列号取出赋值给变量BeginSeqNo，再设置一个变量RealRcvPktNum来表示实收报文数，同时将实收报文数赋为1，即令RealRcvPktNum＝1；

接下来，在统计周期内，每收到一个报文将所述计数器中实收报文数加1；

本实施例中，单条流上每发送一个报文序列号加1，具体来说，当每收到一个GTP或GRE报文时，将实收报文变量加1，即令RealRcvPktNum＝RealRcvPktNum+1；

接下来，在统计周期结束时，接收基于TEID的用户数据流并获取其中下行方向结束报文的序列号；

与开始报文序列号相似，结束报文的序列号也可以利用GTP或GRE报文帧结构中的可选字段，例如Sequence Number字段来携带；具体的，可以设置一个变量EndSeqNo，统计周期结束时，将接收到报文的序列号取出赋值给变量EndSeqNo；

接下来，根据所述下行方向开始报文序列号和结束报文序列号计算应收报文数；具体的，可以设置一个变量ShouldRcvPktNum来表示应收报文数，需要指出的是，考虑到报文序列号可能发生翻转，在计算应收报文数时可以根据开始报文序列号和结束报文序列号做翻转处理，具体来说：如果结束报文序列号大于开始报文序列号，两种之差即得到应收的报文数，即ShouldRcvPktNum＝EndSeqNo-BeginSeqNo+1；反之则说明序列号已经发生翻转，那么应收报文数为ShouldRcvPktNum＝0xFFFFFFFF+EndSeqNo-BeginSeqNo+1；

接下来，根据应收报文数和实收报文数即可计算丢包数和/或丢包率；

具体来说，设置LostPktNum表示丢包数，则LostPktNum＝ShouldRcvPktNum-RealRcvPktNum，用LostPktRatio表示丢包率，则LostPktRatio＝LostPktNum/ShouldRcvPktNum，应收报文数的计算结果是以16进制来表示的，为了计算和统计的方便，在计算丢包率或丢包数时可以将16进制数转化为10进制数，再与采用10进制计算的实收报文数进行数学计算。

此外，为了便于下一个周期的统计，可以在本统计周期结束时，将结束报文的序列号加1之后预设为下一个统计周期的开始报文序列号，即令下一个周期的开始报文序列号NextBeginSeqNo＝EndSeqNo+1。

需要指出的是上个统计周期最后的结束报文序列号很重要，如果该报文出现乱序或者错误，将对下一个周期的统计产生较大影响，因此当出现异常情况时，可以考虑对下一个周期实际收到的开始报文序列号进行修正。具体的，对于下一个周期来说，如果该周期实际收到的第一个报文序列号同其前一个周期的最后一个报文序列号差别不大，例如差别为2-3左右，可以认为是本周期内的乱序报文，依然作为本周期的统计报文；如果本周期实际收到的第一个报文序列号同上周期的差别非常大，如10000以上，超出了本周期的统计范畴，可以认为是本周期内传送错误的报文，也记作本周期统计；如果本周期实际收到的第一个序列号小于上周期结束报文序列号，则认为是上周期报文，可以做丢弃处理；此外，还要考虑本周期开始连续收到的几个报文序列号的连续性，如果连续性好并同上一个周期的序列号相差较大，可以认为上一个周期的有问题，做赋值更正处理。此外，现在通讯网络通常都采用专网，专网通过很好的规划，通常情况下不会出现拥挤和乱序的情况，在这种场景下，可以认为报文都是有序的，但如果通讯链路走到公网，公网一般是没有质量保障的，通常会不同的流走不同的路由会导致报文乱序，为了避免报文乱序对检测可能带来的影响，可以在统计周期开始之前对用户数据流中的报文进行排序，以进一步提高检测的准确度和效率。

在获知了丢包数和丢包率之后，还可以根据这些参数进行链路质量的实时监控和统计。具体来说，通过对于统计周期的设置，检测端对丢包率数据做精确到秒级别的统计，在预设的时长内，例如1分钟，根据统计结果做累加，然后将每分钟的丢包率情况上报到上层操作维护中心，如基站OM，基站OM定时向网管上报分钟级别的丢包率数据，网管以此为基线即可形成分丢包率曲线；如果将预定时长设为1小时或者1天，则网管可以绘制出时、天的丢包率曲线，利用丢包率曲线，用户可以监测传送网络运行质量从而对网络运行参数进行实时调整。

此外，在计算出丢包率之后，还可以根据结果对检测链路进行闭环调整，具体来说，可以预先设置一个丢包率阀值，将计算出的丢包率同包率阀值进行比较，如果计算出的丢包率超过预设丢包率阀值，则可以向对端发送限制流速的消息，对端在收到该消息之后做限流处理。之后可以对检测链路进行实时监控和比较，如果丢包率低于预设丢包率阀值一定时间之后，可以通知对端解除对流速的限制。

实施例三

本实施例提供了一种链路检测装置，如图2所示，该系统包括：

第一单元，用于用多元组标识至少一条用户数据流；其中标识用户数据流的方法可以有多种，例如采用三元组(源IP、目的IP、协议类型)或者五元组(源IP、目的IP、源端口、目的端口、协议类型)来标识用户数据流，单个用户在通信过程中可以产生一条或者多条用户数据流，也就是说可以对应一个或多个TEID，在一个统计周期内，既可以仅针对其中一条用户数据流进行统计，也可以以TEID为单位对多条用户数据流进行统计；

第二单元，用于在预设统计周期内接收并获取所述用户数据流中下行方向报文序列号；其中下行方向报文的序列号可以携带在GTP/GRE帧中的可选字段内，例如Sequence Number字段内；

第三单元，用于对所述统计周期内实际收到的报文进行计数，具体实现时可以采用计数器来进行统计，单条流上每收到1个报文计数器加1；

第四单元：用于根据所述第二单元接收并获取的报文序列号计算所述统计周期内应收报文数，具体来说：如果结束报文序列号大于开始报文序列号，两者之差即得到应收的报文数，即应收报文数ShouldRcvPktNum等于结束报文序列号EndSeqNo减去开始报文序列号BeginSeqNo加1；反之则说明序列号已经发生翻转，那么应收报文数为ShouldRcvPktNum等于0xFFFFFFFF加EndSeqNo减BeginSeqNo加1；

第五单元：用于根据第三单元及第四单元的计算结果计算所述统计周期内的丢包数和/或丢包率，具体来说，设置LostPktNum表示丢包数，则LostPktNum＝|ShouldRcvPktNum-RealRcvPktNum|，其中“||”表示取绝对值，用LostPktRatio表示丢包率，则LostPktRatio＝LostPktNum/ShouldRcvPktNum。

此外，考虑到检测开始之前报文可能已经存在乱序的情况，本实施例中的装置还可以包括第六单元，用于对报文进行排序，排序之后再开始检测。

此外，本实施例的装置还可以包括第七单元，用于将计算出来的实际丢包率与预设丢包率阀值进行对比，若所述丢包率超过所述预设丢包率阀值，则可以向对端发送限流消息。

实施例四

本实施例提供了一种通信系统，该通信系统包括实施例三中提到的链路检测装置，其中该链路检测装置可以包括实施例三中提到的第一单元至第五单元，优选的，还可以包括实施例三中提到的第六单元和/或第七单元。

需要说明的是，以上实施例提供的方法和系统不仅可以使用在LTE(LongTerm Evolution，长期演进)系统中，还可以使用在WiMaX(WorldwideInteroperability for Microwave Access，微波存取全球互通)、WCDMA等其他通信制式的系统中。

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

以上实施例仅用以说明本发明的技术方案，而非对本发明作限制性理解。尽管参照上述较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解：其依然可以对本发明的技术方案进行修改或者等同替换，而这种修改或者等同替换并不脱离本发明技术方案的精神和范围。

Claims (11)

1、一种链路检测方法，其特征在于，包括以下步骤：

用多元组标识用户数据流；

在预设的统计周期开始时，接收并获取所述用户数据流中下行方向开始报文的序列号，启动计数器；

在所述统计周期内，每收到一个报文，将所述计数器中实收报文数加1；

统计周期结束时，接收并获取所述用户数据流中下行方向结束报文的序列号；

根据所述下行方向开始报文序列号和结束报文序列号计算应收报文数；

根据所述应收报文数和实收报文数计算丢包数和/或丢包率。

2、如权利要求1所述的方法，其特征在于，所述统计周期开始时收到的报文序列号和统计周期结束时收到的报文序列号携带在GTP报文或者GRE报文中。

3、如权利要求1所述的方法，其特征在于，所述多元组为由源IP、目的IP、源端口、目的端口、协议类型组成的5元组。

4、如权利要求1所述的方法，其特征在于，所述方法还包括：在所述统计周期结束时，将所述结束报文的序列号加1预设为下一个统计周期的开始报文序列号，且当下一个统计周期实际收到的开始报文序列号与所述预设的开始报文序列号不一致时对所述下一个统计周期实际收到的开始报文序列号作修正。

5、如权利要求1所述的方法，其特征在于，所述方法还包括：在所述统计周期开始前对所述报文进行排序。

6，如权利要求1所述的方法，其特征在于，所述方法还包括：在预设时长内对所述丢包率进行统计，并将统计结果发送给操作维护中心OM，所述操作维护中心OM将所述统计的结果上报网管，所述网管根据所述统计结果绘制丢包率曲线。

7，如权利要求1所述的方法，其特征在于，所述方法还包括：将所述丢包率与预设丢包率阀值进行对比，若所述丢包率超过所述预设丢包率阀值，则向对端发送限流消息。

8、一种链路检测装置，其特征在于，包括：

第一单元，用于用多元组标识至少一条用户数据流；

第二单元，用于在预设统计周期内接收并获取所述用户数据流中下行方向报文序列号；

第三单元，用于对所述统计周期内实际收到的报文进行计数；

第四单元：用于根据所述第一单元接收并获取的报文序列号计算所述统计周期内应收报文数；

第五单元：用于根据第三单元及第四单元的计算结果计算所述统计周期内的丢包数和/或丢包率。

9、如权利要求8所述的链路检测系统，其特征在于，所述系统还包括：

第六单元：用于对所述报文进行排序。

10、如权利要求8所述的链路检测系统，其特征在于，所述系统还包括：

第七单元，用于将所述丢包率与预设丢包率阀值进行对比，若所述丢包率超过所述预设丢包率阀值，则向对端发送限流消息。

11、一种通信系统，其特征在于，包括如权利要求8至10任意一项所述的链路检测装置。

Images