CN101621456B

CN101621456B - 网络内部节点间信令处理的方法及系统

Info

Publication number: CN101621456B
Application number: CN2008101159058A
Authority: CN
Inventors: 陆月明; 华一强; 纪越峰; 高建华; 韩建蕊
Original assignee: Huawei Technologies Co Ltd; Beijing University of Posts and Telecommunications
Current assignee: Huawei Technologies Co Ltd; Beijing University of Posts and Telecommunications
Priority date: 2008-06-30
Filing date: 2008-06-30
Publication date: 2012-12-19
Anticipated expiration: 2028-06-30
Also published as: CN101621456A

Abstract

本发明公开了一种网络内部节点间信令处理的方法及系统，属于通信领域。所述方法包括：获取多个节点的信令信息；根据信令信息产生报文；从报文中提取对应于预设分析内容的报文；对提取的报文进行分析得到对应于预设分析内容的分析结果。所述系统包括获取模块，生成模块，报文提取模块，分析模块。本发明通过获取多个节点的信令信息，根据信息产生报文，并从报文中提取对应于预设分析内容的报文，再对报文进行分析，从而得到对应于预设分析内容的分析结果，实现了对控制平面内的各个节点之间的信令流程以及各个节点的处理性能的测试。

Description

网络内部节点间信令处理的方法及系统

技术领域

本发明涉及通信领域，特别涉及一种网络内部节点间信令处理的方法及系统。

背景技术

下一代光传送网是一个以面向业务、面向用户为主要特征的网络，它具有一系列传统通信网无法实现的智能化特性，例如快速业务指配、自动保护恢复、有效资源分配等。这些功能的实现依赖于一个功能强大的控制平面。一些重要的国际标准化组织都对控制平面相关技术进行了研究并提出了相应的研究成果。其中，自动交换光网络(ASON，AutomaticallySwitched Optical Network)构架G.8080，定义了控制平面中的主要功能模块。通用多协议标签交换(GMPLS，Generalized MultiProtocol Label Switching)体系，为控制平面的具体实现提供了依据。

控制平面通过将原来由集中式网管设备完成的部分功能改由分布式节点完成，提高了网络的效率。通过使用分布式的信令功能，控制平面的各个节点能够完成端到端的业务建立、业务拆除，保护倒换等功能。ASON的测试主要包括：控制平面的测试、传送平面的测试。由于传送平面的测试可以使用成熟的同步数字体系(SDH，Synchronous Digital Hierarchy)和数字交叉连接(DXC)测试技术，所以对测试的研究主要集中在控制平面的测试上。

目前，针对ASON的控制平面的测试已经提出了一些技术方案，但是主要侧重对单个节点或者是网络边缘节点进行各种监测，实现对诸如单个节点的信令处理速度的测试和信令正确性的验证，端到端的连接建立时间的测试和用户网络接口(UNI，User Network Interface)信令正确性的验证，而且多局限于对UNI接口和外部网络网络接口(ENNI，External NetworkNetwork Interface)的测试，对于网络内部的各个节点的信令处理动作，例如每个节点的信令处理时延和节点内部的信令流程，目前在控制平面并没有相关的测试方法，因此无法得到网络内部各个节点之间的完整信令流程，无法对网络内部各个节点处理性能进行测试，使得控制平面技术的评估受到局限。

发明内容

为了获得控制平面内各个节点间完整的信令流程以及对在信令的处理过程中各个节点的处理性能进行测试，本发明实施例提供了一种网络内部节点间信令处理的方法及系统。所述技术方案如下：

一种网络内部节点间信令处理的方法，所述方法包括：

获取自动交换光网络的控制平面内流经各个节点的信令信息，所述信令信息为资源预留协议RSVP信令信息或开放式最短路径优先OSPF协议信令信息；

根据所述信令信息产生包括对预设分析内容进行分析所需报文字段的报文；

从所述产生的报文中提取对应于预设分析内容的报文；

对所述提取的报文进行分析得到对应于所述预设分析内容的分析结果。

本发明实施例还提供了一种网络内部节点间信令处理的系统，所述系统包括：

获取模块，用于获取自动交换光网络的控制平面内流经各个节点的信令信息，所述信令信息为资源预留协议RSVP信令信息或开放式最短路径优先OSPF协议信令信息；

生成模块，用于根据所述信令信息产生包括对预设分析内容进行分析所需报文字段的报文；

报文提取模块，用于从所述产生的报文中提取对应于预设分析内容的报文；

分析模块，用于对所述提取的报文进行分析得到对应于所述预设分析内容的分析结果。

本发明实施例提供的技术方案的有益效果是：

通过获取多个节点的信令信息，并根据该信息产生报文，提取对应于预设分析内容的报文，再对该报文进行分析得到对应于预设分析内容的分析结果，从而获得网络内部的各个节点的信令处理动作，进而可以得到网络内部各个节点之间的完整信令流程，实现了对网络内部各个节点处理性能进行测试。

附图说明

图1是本发明实施例1的网络内部节点间信令处理的方法流程图；

图2是本发明实施例1提供的基于报文字段中的上/下跳节点排序的最小字段示意图；

图3是本发明实施例1提供的基于报文字段中的时间排序的最小字段示意图；

图4是本发明实施例2提供的RSVP建路信令流程的演示拓扑示意图；

图5是本发明实施例2的网络内部节点间信令处理的方法流程图；

图6是本发明实施例2提供的报文格式示意图；

图7是本发明实施例2提供的信令流程分析结果示意图；

图8是本发明实施例3的网络内部节点间信令处理的方法流程图；

图9是本发明实施例3提供的报文格式示意图；

图10是本发明实施例4提供的OSPF协议泛洪信令流程的演示拓扑示意图；

图11是本发明实施例4的网络内部节点间信令处理的方法流程图；

图12a是本发明实施例4提供的节点和其邻居组成的树结构示意图；

图12b是本发明实施例4提供的排序后的树结构示意图；

图13是本发明实施例5的网络内部节点间信令处理的系统结构示意图。

具体实施方式

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

实施例1

参见图1，本实施例提供一种网络内部节点间信令处理的方法，包括：

步骤101：获取流经各个节点的信令信息。

获取控制平面内流经各个节点的信令信息，该步骤在实现的过程中可以通过测量流经每个节点的信令包完成，信令测量在具体的实现过程中可以由软件实现，例如抓包软件，测量的方法是捕获网络中的信令包。

步骤102：根据各个节点的信令信息产生报文；

其中，该步骤可以包括：从各个节点的信令信息中提取对应于预设分析内容的关联信息；该关联信息中包括对预设分析内容进行分析所需的报文字段，根据上述关联信息产生报文。

其中，对应于预设分析内容的关联信息可以是一个完整的信令信息，也可以是对应于预设分析内容的信令信息的某些项，例如：协议类型和/或消息类型；也可以是信令信息或信令信息的某些项和本地添加的信息的混合体，例如：消息类型与本地添加的信息的混合体，比如可以是添加了编号的消息。

步骤103：从产生的报文中提取对应于预设分析内容的报文；

对于RSVP协议的信令分析而言，预设分析内容可以是：

(1)RSVP的信令流程。例如追踪信令过程的细节，分析任何一种过程的信令流程。例如网络中任何一条业务的建路、拆路、折回等过程的信令流程。

(2)故障时的业务恢复时间和故障解除时业务倒换回原路径的时间。

(3)RSVP信令信息穿过每个节点的时延。这可以通过发出包的时间和输入包的时间相减得到，这也可以称作节点的信令处理时间。

(4)RSVP刷新的状态。在业务建立以后，节点间将定期发送刷新消息以保证业务的连通性。通过分布式测量，可以得到一些参数，例如一个几千条连接负载的网络中，在一秒内有多少条刷新消息，也可以得到其中每一条具体连接的刷新流程。

(5)全网业务恢复和倒换回到原路径的时间。

(6)用于故障通告的Notify消息发送的时延。

(7)源节点的信令处理时间和中间节点信令处理时间的比较。

(8)大业务量下信令处理的“瓶颈”节点。

对于OSPF协议的信令分析而言，预设分析内容可以是：

(1)OSPF包对RSVP信令包的影响。由于节点的信令处理速度有一定的极限，如果包的输入速度超过了最大包处理速度，接下来的包需要放在缓存中进行等待。由于OSPF协议的泛洪(Flood)机制，网络中OSPF包的量远大于RSVP信令包的量，可能对RSVP信令包的处理速度产生影响。

(2)OSPF的全网拓扑同步时间。在全网每30分钟一次的重新拓扑同步的过程中，可以测得多少时间全网能够交换完节点和链路状态，达到拓扑同步。网络初始化时，各个OSPF路由器之间使用Hello协议进行邻居确认以及拓扑同步。相邻的OSPF路由器互相通告链路状态。当网络中的OSPF路由器都获得了全网一致的拓扑后，网络中剩下的包只剩下维持邻居关系的Hello包。根据链路状态包消失的时间，可以测出各个节点的拓扑同步时间。

(3)某节点或链路故障后，拓扑更新消息多长时间能够到达全网。

(4)节点对OSPF的5种消息里的每种消息的处理时延。

(5)大业务量下寻找OSPF处理的“瓶颈节点”。

(6)全网泛洪时的OSPF信令过程。当链路状态发生变化时，OSPF通过Flood过程通告网络上其他路由器。OSPF路由器接收到包含有新信息的链路状态更新报文，将更新自己的链路状态数据库，如果此信息和自己以前存储的信息不同，则将此报文转发给其他的邻居节点，实现全网的状态更新。

步骤104：对经过提取的报文进行分析得到对应于预设分析内容的分析结果。

对于经过提取的报文的分析，可以包括按照报文字段内容进行排序。按照报文字段排序所需的报文基本项可以是：协议类型、消息类型、上/下跳节点。在生成报文序列的过程中，可以根据这些报文基本项中的内容和根据预设分析内容添加其他功能项对报文进行排序。例如，可以根据报文字段中的上/下跳节点(Last/next hop node)排序获得报文序列。如图2所示，为基于报文字段中的上/下跳节点排序的最小字段示意图。具体的排序过程在后面的实施例中以具体的应用环境为例解释。

对于经过提取的报文，按照报文字段排序所需的报文基本项还可以是：协议类型、消息类型、时间。如图3所示，为基于报文字段中的时间排序的最小字段示意图。在生成报文序列的过程中，可以根据报文基本项中的时间值按照从小到大的顺序对报文进行排序，也可以根据预设分析内容在报文基本项的基础上再添加其他报文项对报文进行排序。

进一步地，对于经过排序得到的报文序列，可以进行进一步的处理，得到对应于预设分析内容的结果。该处理可以是非数值处理，例如，对报文序列按照信令流程进行图形处理，得到节点间信令的流程图。

本实施例通过获取各个节点的信令信息，并根据该信息产生报文，提取对应于预设分析内容的报文，再对该报文进行分析得到对应于预设分析内容的分析结果，从而获得网络内部的各个节点的信令处理动作，进而可以得到网络内部各个节点之间的完整信令流程，实现了对网络内部各个节点处理性能进行测试。

上述实施例是对信令处理的方法进行总述，下述实施例将以具体应用环境RSVP、OSPF为例对网络内部节点间信令处理的方法展开进一步的说明。

实施例2

本实施例提供一种针对RSVP协议的建路节点间信令的处理方法，如图4所示，为RSVP建路信令流程的演示拓扑示意图。该图所示的拓扑中，在节点1-2-3之间的链路带宽是STM-16，在节点1-4-5-3之间的链路带宽是STM-4。建立起5个带宽是STM-4的软永久连接，源端节点都是1，目的端节点都是3。路由算法使用最短路径优先(SPF，Shortest Path First)算法。前四条业务经过的路径都是1-2-3，因为此路径最短；第五条业务经过的路径是1-4-5-3。在本实施例中预设分析内容为第五条业务连接的建路信令流程。

参见图5，本实施例提供的网络内部节点间信令处理的方法包括以下步骤：

步骤201：获取各个节点的RSVP信令信息。

建路过程中，捕获并记录流经控制平面5个节点的RSVP信令信息。

步骤202：根据RSVP信令信息产生报文。

具体地，由于在本实施例中预设分析内容为第五条业务连接的建路信令流程，因此提取RSVP信令信息中对应于预设分析内容的关联信息包括：协议类型、消息类型、上/下跳节点、源节点、目的节点和通道号；其中，协议类型、消息类型、上/下跳节点为本实施例中产生的报文的报文基本项，源节点、通道号为针对预设分析内容提取报文所需要的报文项，目的节点为对提取的报文进行分析所需要的报文项。根据上述关联信息产生报文，该报文的格式如图6所示。

具体地，本实施例中的关联信息中的协议类型是RSVP，消息类型是PATH/RESERVE。

步骤203：从产生的报文中提取对应于预设分析内容的报文。

预设分析内容为第五条业务连接的建路信令流程，第五条业务经过的路径是1-4-5-3。

将根据上述关联信息产生的报文汇集在一起，这些报文的协议类型是RSVP，消息类型是PATH/RESERVE；再根据源节点、通道号这两个报文项对产生的报文进行提取。本实施例中，源节点是1、通道号是5提取出属于第五个业务连接的报文，如表1所示。表1显示了属于第五个业务连接的报文，包括节点1、节点3、节点4和节点5的所有消息类型为PATH/RESERVE的报文。

表1

节点3	节点4	节点5	节点1
				收到PATH从5	收到PATH从1	收到PATH从4	发送PATH到4
发送RESV到5	发送PATH到5	发送PATH到3	收到RESV从4
					收到RESV从5	收到RESV从3
	发送RESV到1	发送RESV到4

从表1中无法获知第五个连接的信令流程，需要进一步对报文进行排序分析。

步骤204：对提取的报文进行分析得到对应于预设分析内容的分析结果。

在本实施例中先使用报文字段中的上/下跳节点的内容，对步骤203得到的报文进行排序。

具体地，本实施例根据报文字段中的上/下跳节点寻找该报文的下一跳报文，依次将报文排序。

排序的过程如下：

(1)找到第一条报文，该报文的内容包括：本地节点(local node)IP地址等于源节点IP地址并且是发送的消息，消息类型是PATH；

(2)按照第一条报文的下一跳节点找到第二条报文，该报文的内容包括：local node IP地址等于第一条报文的下一跳IP地址并且是接收到的消息，消息类型是PATH；

(3)如果第二条报文的local node IP地址不等于其目的(destination)IP地址，将要寻找第三条报文，该报文的内容包括：local node IP地址等于上一跳节点(即第二条报文)的local node IP地址并且是发送消息，消息类型是PATH；

(4)如果第二条报文的local node IP地址等于其目的(destination)IP地址，这意味着收到这个消息的节点是这个连接的目的节点。根据软永久连接的信令过程，这个节点将要发一个RESERVE消息回去。根据上/下跳节点寻找第三条报文，该报文的内容包括：local nodeIP地址等于报文2的local node IP地址并且是发送消息，消息类型是RESERVE；这是一个RESERVE消息，发送地址是第二条报文的local node IP地址。

(5)采用上述方法对RESERVE消息进行分析，找到其它的RESERVE报文。

通过上述报文字段匹配排序得到的报文序列如表2所示。其中，Sequence表示对此次分析过程的编号，send/receive表示发送/接收消息，meg type表示消息类型，last/next nodeIP表示上/下跳节点的IP地址；本实施例中具体地，192.168.100.1表示源节点1的IP地址，192.168.100.3表示目的节点3的IP地址，192.168.100.4表示节点4的IP地址，192.168.100.5表示节点5的IP地址，send表示发送消息，receive表示接收消息。

表2

这里预设分析内容是第五个连接的信令流程。表2所示的报文序列按照信令流程进行排序的结果可以以图形的方式展现，比如可以得到图7所示的第五个连接的信令流程图。图7中192.168.100.1～192.168.100.5均表示节点的IP地址，PATH PROCESS表示关于PATH消息的流程，RESV PROCESS表示关于RESV消息的流程，由表2将PATH PROCESS和RESV PROCESS过程分开显示可以得到图7所示的信令流程。

实施例3

如图8所示，本实施例提供一种针对RSVP协议的建路节点间信令的处理方法。其中，本实施例与实施例2的不同之处在于，本实施例在对提取的报文进行分析的过程中，对于经过提取的报文按照报文字段中的时间顺序进行排序。该方法包括：

步骤301：获取各个节点的RSVP信令信息。

步骤302：根据RSVP信令信息产生报文。

具体地，提取RSVP信令信息中对应于预设分析内容的关联信息，本实施例中，该关联信息包括：协议类型、消息类型、时间、源节点、目的节点和通道号；其中，协议类型、消息类型、时间为本实施例中产生报文的报文基本项，源节点、通道号为针对预设分析内容提取报文所需要的报文项，目的节点为对提取的报文进行分析所需要的报文项。根据上述关联信息产生报文，该报文的格式如图9所示。

步骤303：从产生的报文中提取对应于预设分析内容的报文。

上述步骤中的步骤301、步骤303与实施例2中的步骤201和步骤203原理相似，此处不再赘述。

步骤304：对提取的报文进行分析得到对应于预设分析内容的分析结果。

在本实施例中先使用报文字段中的时间顺序进行排序生成报文序列，按时间顺序排序可以是按照时间值从小到大进行排列。

本实施例对于报文按照基本字段中时间匹配进行排序，以时间为依据，报文的排序更加直观地反映出第五个连接的信令流程，从而也可以得到图7所示的信令流程。

实施例4

本实施例提供一种针对OSPF协议泛洪的节点间信令的处理方法。如图10所示的拓扑中，有5个节点即1、2、3、4、5和5条链路<1，2>、<2，3>、<3，4>、<4，5>和<5，1>组成了一个环网。当链路状态发生变化时，OSPF通过泛洪过程通告网络上其他节点。OSPF节点接收到包含有新信息的链路状态更新消息，将更新自己的链路状态数据库。在图10所示的拓扑中，如果链路<2，3>失效了，节点2和3将分别发送链接状态更新消息给相邻的节点。

在本实施例中预设分析内容为未失效的链路中节点间的泛洪信令流程。

参见图11，本实施例包括以下步骤：

步骤401：获取各个节点的OSPF信令信息。

当链路<2，3>失效时，捕获并记录流经控制平面5个节点的OSPF信令信息。

步骤402：根据OSPF信令信息产生报文。

本实施例中，预设分析内容为未失效的链路中节点间的泛洪信令流程。

具体地，提取OSPF信令信息中对应于预设分析内容的关联信息，本实施例中，该关联信息包括：协议类型、消息类型、上/下跳节点；根据上述关联信息产生报文，该报文的格式如图2所示。图2所示的三个项是报文基本项，由于在本实施例中针对预设分析内容提取报文所需要的报文项、目的节点作为对提取的报文进行分析所需要的报文项都属于报文基本项，所以本发明实施例中只需要提取三个报文基本项。

步骤403：从产生的报文中提取对应于预设分析内容的报文。

将根据上述关联信息产生的报文汇集在一起，根据报文字段的两个报文基本项：协议类型和消息类型提取出5个节点中相邻节点相互发送的含有链接状态更新消息的报文，如表3所示。具体地，协议类型是OSPF，消息类型是链接状态更新消息。

表3

从表3中无法获知OSPF协议的链接更新消息的发送和接收的报文顺序，需要进一步对报文进行分析。

步骤404：对提取的报文进行分析得到对应于预设分析内容的分析结果。

在本实施例中先使用报文字段中的上/下跳节点对步骤403得到的报文进行生成报文树的树排序。

排序的过程可以如下：

(1)为每一个节点构造一个树。由于链路<2，3>的失效和拓扑的环形形状，每个节点收到链接状态更新消息后，将其转发给另一个邻居节点，这里构造的数都是单枝的，如图12a所示；

(2)从泛洪的起始节点开始，在这里从节点2和3开始，由表3和图12a所示的内容，根据每个节点发送链接状态更新消息流程的特征将这些树按照树根-树枝-树根的顺序连接起来，直到图中所有的树都使用过一遍。连接结果如图12b所示。

通过这种按照报文字段内容进行排序的方法得到的报文序列如表4所示，在表4中，从上到下为节点间发送链接状态更新消息的时间顺序，其中，需要说明的是，节点2与节点3发送链接状态更新消息的时间顺序在本实施例中不作限定。

表4

根据表4所示的报文序列可以得到节点间的泛洪的流程。

实施例5

参见图13，本实施提供了一种网络内部节点间信令处理的系统，包括：

获取模块51，用于获取各个节点的信令信息；

生成模块52，用于根据获取模块51获取的各个节点的信令信息产生报文，该报文中包括对预设分析内容进行分析所需报文字段；

报文提取模块53，用于从生成模块52生成的报文中提取对应于预设分析内容的报文；

分析模块54，用于对报文提取模块53经过提取的对应于预设分析内容的报文进行分析得到对应于预设分析内容的分析结果。

其中，获取模块51在具体的实现过程中可以由软件实现，例如抓包软件；可以为控制平面内的每个节点均设置获取模块51，获取该节点的信令信息。

预设分析内容根据不同的协议类型可以有不同的多种。

进一步地，生成模块52包括：

信息提取单元，用于从各个节点的信令信息中提取对应于预设分析内容的关联信息，该关联信息包括报文基本项、针对预设分析内容提取报文所需要的报文项、对提取的报文进行分析所需要的报文项；

产生单元，用于根据信息提取单元提取的关联信息产生报文。

其中，分析模块54可以具体用于：

按照报文字段中的上/下跳节点对报文提取模块53提取的报文进行排序；该报文基本项包括协议类型、消息类型和上/下跳节点。

分析模块54也可以具体用于：

按照报文字段中的时间对报文提取模块53提取的报文进行排序；该报文基本项包括协议类型、消息类型和时间。

另外，分析模块54也可以包括：第三排序单元，用于对报文提取模块53提取的报文进行排序，得到报文序列；

显示单元，用于以图形的方式呈现所述排序结果。

本实施例中，通过获取模块获取各个节点的信令信息，由生成模块获取的各个节点的信令信息产生报文，由提取模块提取对应于预设分析内容的报文，由分析模块对对应于预设分析内容的报文进行分析，从而得到对应于预设分析内容的分析结果。从而实现了对控制平面内的各个节点之间的信令流程以及各个节点的处理性能的全面完整的测试。

本发明实施例可以通过软件实现，相应的软件可以存储在可读取的存储介质中，例如计算机的硬盘、光盘或软盘中。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种网络内部节点间信令处理的方法，其特征在于，包括：

从所述产生的报文中提取对应于所述预设分析内容的报文；

2.根据权利要求1所述的网络内部节点间信令处理的方法，其特征在于，所述根据所述信令信息产生包括对预设分析内容进行分析所需报文字段的报文的步骤包括：

从所述各个节点的信令信息中提取对应于预设分析内容的关联信息，所述关联信息包括报文基本项、针对所述预设分析内容提取报文所需要的报文项、对所述提取的报文进行分析所需要的报文项；

根据所述关联信息产生报文。

3.根据权利要求2所述的网络内部节点间信令处理的方法，其特征在于，所述对所述提取的报文进行分析的步骤具体为：

按照所述报文字段中的上/下跳节点对所述提取的报文进行排序；所述报文基本项包括协议类型、消息类型和上/下跳节点。

4.根据权利要求2所述的网络内部节点间信令处理的方法，其特征在于，所述对所述提取的报文进行分析的步骤具体为：

按照所述报文字段中的时间对所述提取的报文进行排序；所述报文基本项包括协议类型、消息类型和时间。

5.根据权利要求1所述的网络内部节点间信令处理的方法，其特征在于，所述对所述对应于预设分析内容的报文进行分析的步骤包括：

对所述对应于预设分析内容的报文进行排序，得到报文序列；

以图形的方式呈现所述排序结果。

6.一种网络内部节点间信令处理的系统，其特征在于，所述系统包括：

7.根据权利要求6所述的网络内部节点间信令处理的系统，其特征在于，所述生成模块包括：

信息提取单元，用于从所述各个节点的信令信息中提取对应于预设分析内容的关联信息，所述关联信息包括报文基本项、针对所述预设分析内容提取报文所需要的报文项、对所述提取的报文进行分析所需要的报文项；

产生单元，用于根据所述关联信息产生报文。

8.根据权利要求7所述的网络内部节点间信令处理的系统，其特征在于，所述分析模块具体用于按照所述报文字段中的上/下跳节点对所述提取的报文进行排序；所述报文基本项包括协议类型、消息类型和上/下跳节点。

9.根据权利要求7所述的网络内部节点间信令处理的系统，其特征在于，所述分析模块具体用于按照所述报文字段中的时间对所述提取的报文进行排序；所述报文基本项包括协议类型、消息类型和时间。

10.根据权利要求6所述的网络内部节点间信令处理的系统，其特征在于，所述分析模块包括：

第三排序单元，用于对所述提取报文进行排序，得到报文序列；

显示单元，用于以图形的方式呈现所述排序结果。