CN100544392C - 在软交换系统中进行全网全程呼叫跟踪的方法 - Google Patents

Abstract

本发明公开了在软交换系统中进行全网全程呼叫跟踪的方法。该方法包括下列步骤：用户在跟踪终端上启动一个跟踪任务并设定跟踪条件；跟踪终端向相应的被跟踪节点请求建立连接；被跟踪节点在呼叫发生时缓存收到的或发出的消息，为每个跟踪信息编号，所述号码按时间递增；被跟踪节点根据设定的跟踪条件搜索满足该条件的呼叫；被跟踪节点将满足跟踪条件的呼叫的跟踪信息作为呼叫跟踪选项插入到呼叫消息的扩展IP数据报首部送往跟踪终端；跟踪终端将满足跟踪条件的呼叫的信令交互过程显示在跟踪终端的图形窗口中。根据该方法，在软交换系统中，当呼叫跨越多个实体时，能够在整个呼叫的序列图中直观地显示呼叫的整个信令交互过程，从而可以快速排除故障。

Description

在软交换系统中进行全网全程呼叫跟踪的方法

技术领域

本发明涉及软交换电信网络系统，特别涉及在软交换系统中由多个实体参与呼叫时，对呼叫和信令进行全网全程跟踪的方法。

背景技术

传统的电信网由多个交换节点(电话交换机)组成，而且各个交换系统没有统一的结构，对于呼叫信令的跟踪只能局限于单个交换机内。如，在一个包含交换机A，B和C的电信网络中，交换机A中的一个用户发起一个呼叫，交换机A通过交换机B(汇接局)连接到交换机C中的一个用户，这时该呼叫跨接了三个交换机。在该电信网中，只能在每个交换机内单独进行呼叫信令跟踪，无法观察整个呼叫信令交互过程，如交换机A无法观察交换机B和交换机C的呼叫信令。

由于传统的交换系统没有统一的结构，因此，也没有统一的呼叫信令跟踪方法，使传统电信网不能做到全网全程的呼叫信令跟踪。如，在一种由中央处理模块、后台处理模块以及交换处理模块组成的交换机中，在做呼叫跟踪时，维护人员在终端上设定跟踪的条件，后台处理模块将跟踪条件下发到交换处理模块，当呼叫发生时，交换处理模块将满足条件的呼叫信令送往后台处理模块，再在终端上显示。但是由于缺乏相应的关联机制，各条呼叫信令只能简单地罗列，维护人员需要在大量的消息中查找故障的消息，费时费力。

作为未来电信网发展方向的软交换系统，其所涉及的网元更多，如传统交换机软交换体系结构中往往分为呼叫服务器CS，媒体网关MG和信令网关SG，因此呼叫跟踪更为复杂，而且目前的软交换系统中也没有定义统一的呼叫跟踪规范。

图1所示为软交换系统的简略示意图。它主要由应用服务器(AS)、呼叫服务器(CS)、信令网关(SG)、媒体/中继网关(MG/TG)等实体组成。应用服务器(AS)完成业务处理，呼叫服务器(CS)完成呼叫处理，信令网关(SG)用于SS7的MTP处理，媒体/中继网关(MG/TG)用于媒体的接入。各个实体之间定义了不同类型的接口协议，如CS与SG之间为M3UA，用于传递MTP3信令；CS与MG/TG之间为IUA/MEGACO，IUA用于传递Q.931信令，MEGACO用于传递媒体控制信令。CS与AS在目前软交换规范中尚未确定。

通常，在这样一个软交换系统中，完成一个呼叫需要多个实体参与，各实体之间需要交换信息。由于信息交互十分复杂，如果某一环节发生错误而导致呼叫失败，要检查出发生错误的实体和诊断出错误的原因将是十分困难和复杂。从实践经验中，维护人员往往需要从呼叫源(即主叫用户)到呼叫目的地(被叫用户)逐步追踪和检查每个实体和接口。例如对于一个跨越多个网元或网关的异常呼叫，在定位故障时，首先要确定哪个网元异常，然后要确定网元中的哪个模块异常，最后才能定位哪个实例异常。在现有软交换系统中由于刚开始没有可用信息，这个定位过程有可能遍历所有网元的所有实例。因此定位故障的过程将是既耗费时间又耗费人力的。

发明内容

因此，本发明的目的是提供一种在软交换体系结构中，对呼叫进行全网全程跟踪的方法。

根据本发明的在软交换系统中进行的全网全程呼叫跟踪的方法，所述网络包括至少由多个跟踪终端和多个被跟踪节点组成的呼叫跟踪子系统，其中每个跟踪终端和至少一个被跟踪节点相连，所述呼叫涉及多个实体，所述方法包括下列步骤：用户在跟踪终端上启动一个跟踪任务并设定跟踪条件；跟踪终端向相应的被跟踪节点请求建立连接；被跟踪节点在呼叫发生时缓存收到的或发出的消息，为每个跟踪信息编号，所述号码按时间递增；被跟踪节点根据设定的跟踪条件搜索满足该条件的呼叫；被跟踪节点将满足跟踪条件的呼叫的跟踪信息作为呼叫跟踪选项插入到呼叫消息的扩展IP数据报首部送往跟踪终端；跟踪终端根据呼叫的跟踪信息将满足跟踪条件的呼叫的信令交互过程显示在跟踪终端的图形窗口中。

利用本发明的全网全程呼叫跟踪方法，通过将指定的呼叫的信令交互过程实时动态地显示在跟踪终端屏幕的图形窗口中，能够得到整个呼叫的消息序列图(MSC)

，从而更加直观地反映出问题的所在。这个消息序列图包括参与呼叫的网元，实例，状态标识，信令交互和呼叫异常点。利用呼叫异常点可以得到呼叫失败原因，再根据呼叫状态和信令，得到呼叫的真正原因。

利用本发明还可以快速排除故障。现有故障定位技术要求人工手动地导出呼叫记录信息，然后再从这些记录中筛选出可用信息。而根据本发明全网全程呼叫跟踪的方法，能够自动地导出和筛选信息。对应于同样的典型呼叫异常，现有技术可能需要多个工程师花大量时间才能定位，而采用本发明的呼叫跟踪方法，只需一个工程师很短时间内就能解决。如未使用本发明之前，定位一个故障通常需要几小时来，采用本发明后，定位并找出故障原因的时间只需5分钟。

附图说明

以下通过参考附图详细说明本发明的优选实施方式，本发明的上述及其他优势将变得更加明显。在附图中：

图1所示为一个本发明实施例中所采用的软交换系统的结构示意图；

图2所示为根据本发明的实施例在软交换系统中的呼叫信令交互过程；

图3为根据本发明实施例的在软交换系统中全网全程跟踪呼叫的方法的流程图；

图4为呼叫跟踪的子系统配置图；

图5为根据本发明实施例的启动跟踪的过程；

图6所示为IPv4数据报的格式；

图7所示为IPv4数据报选项代码的格式；

图8所示为IPv4呼叫跟踪选项的格式；

图9所示为IPv6数据报的格式；

图10所示为IPv6端到端扩展首部的格式；

图11所示为IPv6呼叫跟踪选项的格式；

图12所示为根据本发明实施例的呼叫跟踪的MSC图示例；

图13为根据本发明实施例的取消跟踪的过程。

具体实施方式

图2描述了一个ISDN终端用户发起到PSTN/ISDN的呼叫的信令交互过程，它涉及MG、CS和SG三个实体，需要IUA和M3UA二个协议参与。当用户发起呼叫时，MG通过IUA向CS发送呼叫建立消息(setup)，CS通过号码分析认为被叫号码已收全，向MG发送呼叫进展消息(call proceeding)；然后CS将通过SG向对端交换机发送初始地址消息(IAM)；当被叫振铃后，对端交换机通过SG向CS发送地址全消息(ACM)；CS向MG发送振铃消息(alerting)；假设CS由于某种原因呼叫无法进行，CS将通过SG向对端交换机发送释放消息(REL)；CS也会向MG发送释放消息(rel)；最后对端交换机通过SG向CS发送释放完成消息(RLC)；MG向CS发送释放消息(rlc)。通常系统同时存在多个呼叫，因此各个接口有大量的消息交互，维护人员需要通过给定的条件(如用户号码)将指定的呼叫筛选出来并观察其消息交互过程，例如观察图2所示的呼叫，从而快速发现问题。

图3描述了本发明在软交换系统中全网全程跟踪呼叫的工作流程。首先，在步骤S310，跟踪控制台设置好跟踪条件，然后，在步骤S320，跟踪控制台连接被跟踪节点，将跟踪条件设置到呼叫网关中。一旦有满足条件的呼叫，呼叫跟踪系统就将被触发。在步骤S330，跟踪系统通过缓存收到的或发出的消息，为每个跟踪信息编号收集相关呼叫信息。在步骤S340，被跟踪节点根据设定的跟踪条件搜索满足该条件的呼叫。在步骤S350，跟踪节点通过将满足跟踪条件的呼叫的跟踪信息作为呼叫跟踪选项插入到呼叫消息的扩展IP数据报的首部，将所收集的相关呼叫信息封装到特有的IP数据包中，并送往跟踪终端。通过网络将IP数据包转储到监控台，在步骤S360，将满足跟踪条件的呼叫的信令交互过程显示在跟踪终端的图形窗口中。

图4为呼叫跟踪的子系统配置图，主要有两部分组成，即被跟踪节点和跟踪终端。被跟踪节点为跟踪对象，如CS，SG，MG等；跟踪终端属于网管的一部分，用于显示跟踪信息。每个跟踪终端能够与所有的被跟踪节点或指定的被跟踪节点连接，即多对多的关系。例如，在图4中，跟踪终端1可以与被跟踪节点1、2、3建立连接；跟踪终端2可以与被跟踪节点1、3建立连接；跟踪终端3可以与被跟踪节点2建立连接。

跟踪终端和被跟踪节点之间需要交互消息，如启动或停止跟踪时，跟踪终端要向被跟踪节点下发跟踪命令；在跟踪过程中被跟踪节点要向跟踪终端发送跟踪信息，即实体收到或发出的消息。

图5为启动跟踪的过程，维护人员在跟踪终端上启动一个跟踪任务，并设定跟踪的条件，例如用户号码，中继ID等，以及跟踪的范围，即需要跟踪的实体。跟踪终端向跟踪的实体请求建立连接，并将跟踪启动指令下发到相应的实体(全部的被跟踪实体或部分实体)。这时接收了跟踪启动指令的实体应记住该跟踪的条件，并回送启动指令证实。

当呼叫发生时，被跟踪实体应缓存跟踪信息，如收到的或发出的消息，并给每个跟踪信息编号(该编号只在实体内有效)，号码按时间递增。同时被跟踪实体根据跟踪的条件搜索该呼叫是否为维护人员要跟踪的呼叫，即跟踪条件是否满足，如果满足则将该呼叫的跟踪信息送往跟踪终端。

在呼叫的信令交互过程中，为了做到全网全程的呼叫跟踪，需要对标准接口进行扩充。在软交换系统中，各个接口协议，如IUA、MEGACO(H.248)、M3UA等都是承载在IP协议上，每种协议的格式各不相同，不便于扩充，否则无法实现互通性。为了不针对每种协议进行扩充，可以扩充IP数据报的首部，在其中定义用于呼叫跟踪的统一的消息头来实现。

现有的软交换系统中接口信息往往只包含必要的与呼叫相关的信息，而扩充的接口信息可以用来承载呼叫无关的跟踪信息。可以说扩充信息依附于原接口，但并不影响呼叫。需要扩充的信息有：跟踪终端IP和跟踪任务ID，用于使得接收消息的实体能够将该呼叫相关的跟踪信息送向指定的跟踪终端；发送方的跟踪信息编号，发送方实体ID和发送方呼叫实例ID，用于方便进行发送和接收消息的匹配。

以下分IPv4和IPv6这两种情形，结合图6到图11对扩充IP数据报的首部这种优选的实施方式进行描述。

图6为IPv4数据报的格式。关于IPv4的具体内容，可以参考IETF(因特网工程任务组)的rfc791。在IPv4中，IP选项包含多个八位组，为了保证IP包头为32比特的整数倍，如果IP选项长度不为32比特的整数倍，用0填充补齐。在IP选项中可包含多个选项，每个选项的第一个八位组为选项代码，如果该选项包含数据则第二个八位组为选项长度(长度等于选项数据长度加二，即计入选项代码和长度本身的长度)，其后为选项数据。图7为选项代码的格式，拷贝字段表示IP数据报分片时是否应将该选项拷贝到所有分片去，选项类和选项号指明该选项的类型，在rfc791已定义的选项类和选项号为：

通过增加一种选项来传送呼叫跟踪的信息，图8定义了IPv4呼叫跟踪选项的格式，说明如下：

图9为IPv6数据报的格式，关于IPv6的具体内容，可以参考IETF(因特网工程任务组)的rfc1883。在IPv6中，可包括多个扩展首部，其中RFC1883定义了一种端到端扩展首部，用来端到端传送可选项，图10表述了端到端扩展首部的格式。第一个八位组表示下一个首部类型(首部类型值的定义见RFC1700)，第二个八位组为首部长度(为全部首部的长度)，其后为一个或多个IP选项。每个选项的第一个八位组为类型字段，它的最高两个比特指明当主机或路由器不认识该选项时如何处理。

类型字段第三高比特(即第二比特)指明路由器能否改变选项。

第三至第七比特为选项码。

如果选项有数据，则第二个八位组为选项长度(只为数据的长度)，其后跟选项数据。目前RFC1883只定义了两种填充选项：

Pad0，为定长填充选项，只有一个八位组(即类型)，类型码为0

Pad1，为变长填充选项，包括类型、长度和填充数据，类型码为1，长度为填充数据的长度，填充数据为0值的八位组。

通过在IPv6中增加一种选项来传送呼叫跟踪的信息，图11定义了IPv6呼叫跟踪选项的格式，说明如下：

当呼叫满足设定的条件，检测条件满足的实体应将与该呼叫相关的所有消息发向相应的跟踪终端(包括已缓存的和将收到或发出的消息)，并且在发送所有后续的呼叫消息的IP数据报插入呼叫跟踪选项，即在扩充的IP头部信息中填入呼叫跟踪信息。收到带有该选项的消息的实体也应将该呼叫的所有消息(包括刚接收到的消息)送往指定的跟踪终端，即被感染，同时记住跟踪终端IP的跟踪任务ID，当它对该呼叫需要发送消息，也需加上同样的选项(再去感染对方)，这样直至所有与该呼叫相关的实体都被感染。为了防止跟踪条件嵌套(即已被跟踪的呼叫满足另一个跟踪条件)，当一个呼叫已被感染时，不再查询跟踪条件。

被跟踪实体和跟踪终端之间的接口属于产品的内部接口，在本发明的实施例中，接口应具有下列针对跟踪信息的关键元素，这些跟踪信息关键元素均承载在标准接口扩充的信息中。所述跟踪信息关键元素包括：

跟踪任务ID；

跟踪信息类型。有两种：接收的消息，发送的消息；

发送方实体ID。

接收方实体ID。只对接收的消息有效；

发送方呼叫实例ID；

接收方呼叫实体ID。只对接收的消息有效；

发送方跟踪信息编号；

接收方跟踪信息编号。只对接收的消息有效；

信息内容。

跟踪终端首先将收到的信息按跟踪任务分类，这是由于一个跟踪终端上可以启动多个跟踪任务，属于同一个跟踪任务的信息应在一起显示出来(如在同一个窗口中)。

其次找出每个呼叫实例，这是由于一个跟踪任务可以观察多个呼叫，即它们满足相同的条件，维护人员需要对每个呼叫分开观察(如分为独立的MSC图)。这可以通过发送与接收消息的关联来判定。当一条发送消息的发送方呼叫实例ID和发送方跟踪信息编号与接收消息的发送方呼叫实例ID和发送方跟踪信息编号相同，则可以认为这两条消息是一对，并且发送和接收的呼叫实例属于同一个呼叫，这样凡是这两个呼叫实例发出的跟踪信息也都属于同一个呼叫，由此可以将属于一个呼叫的实例和跟踪信息找出来。

再次对其在每一实体内按跟踪信息编号排序。而对于接收的消息有两个编号，但由于发送方跟踪信息编号不是由该实体产生的，所以只对接收方跟踪信息编号进行排序。

最后要根据已排好顺序的信息画出MSC图。不过在画图之前还有一个问题需要解决，即信息在MSC中的位置。MSC有很多竖线表示状态机实例。状态机实例表示上文的一个实例，由于每个实例都会存在状态变迁，所以又称为状态机实例。实例间通过箭头表示消息流向，消息的产生时间顺序由纵向的位置来表示，越往下表示事件发生的时间越晚。一般来说信息编号越大，它在MSC中的位置越往下，但对于接收事件来说，它必然比发送事件晚，所以对接收消息，除了要判定信息编号，还要比较它相对应的发送消息的发送编号，它的位置必然比发送事件靠下。跟踪终端除了画出MSC图，还根据信息内容解析出消息的参数以利于维护人员阅读。

图12为一MSC图实例，其中描述了一个简单呼叫的跟踪MSC图。此例的跟踪条件为被叫号“6635551”，媒体网关MG1首先触发呼叫跟踪系统，然后当呼叫经过呼叫中心CS1和信令网关SG1时，呼叫跟踪信息也同样传播到相应的模块，最后所有参与呼叫的网关(例如此例中的MG1，CS1和SG1)和模块都将共同完成呼叫跟踪任务。图右侧显示的是一条捕捉到的ISUP的IAM消息，其中Seq为发送方跟踪信息编号，Type为类型，其值表示类型为消息类；Dir为方向，其值表示为接收的消息；Source为消息发送方标示，其值表示CS1中发送方实体ID为1；Dest为消息接收方标示，其值表示SG1中接收方实体ID为1；OOPC为七号信令系统中源信令点编号，其值为32-33-55；DPC为七号信令系统中目的信令点编号，其值为32-33-66；CIC为电路标示，其值为332；msg type为消息类型，其值表示为IAM消息；Nature of connection indictor为连接特性指示，其值为no satellite(无卫星电路)，continuity not(未导通)，outgoingecho not(无去话回声控制)。

维护人员可以通过跟踪终端取消跟踪任务，图13为取消跟踪的过程。维护人员首先选择要取消的跟踪任务，然后点击控制台的一个停止按钮，这样控制台会发送一个停止的控制命令给相应的跟踪节点，跟踪节点收到停止命令后清除跟踪条件和缓存的跟踪信息，并返回确认消息。控制台收到确认消息，跟踪任务即被取消。

上述详细说明中给出的各优选实施方式只是为了说明的目的，不应理解为对本发明的任何限制。本领域技术人员可以根据上述描述获得有关本发明的任何变形和改进，但这些变形和改进都包括在随附权利要求书中所限定的本发明的范围和精神内。

Claims (12)

1.在软交换系统中进行的全网全程呼叫跟踪的方法，所述软交换系统包括至少由多个跟踪终端和多个被跟踪节点组成的呼叫跟踪子系统，其中每个跟踪终端和至少一个被跟踪节点相连，所述呼叫涉及多个实体，所述方法包括下列步骤：

用户在跟踪终端上启动一个跟踪任务并设定跟踪条件；

跟踪终端向相应的被跟踪节点请求建立连接；

被跟踪节点在呼叫发生时缓存收到的或发出的消息，为每个跟踪信息编号，所述编号按时间递增；

被跟踪节点根据设定的跟踪条件搜索满足该条件的呼叫；

被跟踪节点将满足跟踪条件的呼叫的跟踪信息作为呼叫跟踪选项插入到呼叫消息的扩展IP数据报首部送往跟踪终端；

跟踪终端根据呼叫的跟踪信息将满足跟踪条件的呼叫的信令交互过程显示在跟踪终端的图形窗口中。

2.根据权利要求1的全网全程呼叫跟踪的方法，所述IP数据报是IPv4数据报或IPv6数据报。

3.根据权利要求1或2的全网全程呼叫跟踪的方法，将所述呼叫跟踪选项插入到扩展IPv4数据报首部包括：在IP数据报首部扩充长度为二个八位组的跟踪任务ID，长度为四个八位组的跟踪终端IP，长度为四个八位组的发送方的跟踪信息编号，长度为四个八位组的发送方实体ID和长度为四个八位组的发送方呼叫实例ID。

4.根据权利要求1或2的全网全程呼叫跟踪的方法，将所述呼叫跟踪选项插入到扩展IPv6数据报首部包括：在IP数据报首部扩充长度为二个八位组的跟踪任务ID，长度为十六个八位组的跟踪终端IP，长度为四个八位组的发送方的跟踪信息编号，长度为四个八位组的发送方实体ID和长度为四个八位组的发送方呼叫实例ID。

5.根据权利要求1的全网全程呼叫跟踪的方法，所述呼叫涉及的实体至少包括媒体网关MG，呼叫服务器CS和信令网关SG。

6.根据权利要求5的全网全程呼叫跟踪的方法，所述呼叫的信令交互过程包括下列步骤：

MG通过用户适配层协议IUA向CS发送呼叫建立消息；

CS通过号码分析认为被叫号码已收全，向MG发送呼叫进展消息；

CS通过SG向对端交换机发送初始地址消息；

当被叫振铃后，对端交换机通过SG向CS发送地址全消息；

CS向MG发送振铃消息；

当呼叫无法进行时，CS通过SG向对端交换机发送释放消息，同时，CS还向MG发送释放消息；

对端交换机通过SG向CS发送释放完成消息，MG向CS发送释放完成消息。

7.根据权利要求1的全网全程呼叫跟踪的方法，跟踪终端向相应的被跟踪节点请求建立连接的步骤进一步包括：

跟踪终端向被跟踪节点发送跟踪启动指令；

被跟踪节点记住跟踪条件；

被跟踪节点回送启动指令证实。

8.根据权利要求1的全网全程呼叫跟踪的方法，其中所设定的跟踪条件包括呼叫用户号码，中继ID和被跟踪节点的ID。

9.根据权利要求1的全网全程呼叫跟踪的方法，呼叫的信令交互过程以消息序列图MSC图的形式显示在跟踪终端的图形窗口中。

10.根据权利要求9的全网全程呼叫跟踪的方法，所述MSC图是跟踪终端根据对接收方跟踪信息编号的排序画出的，其中用竖线表示被跟踪节点实例，用竖线间的箭头表示实例间的消息流向，用箭头在竖线上的纵向位置表示消息产生的时间顺序。

11.根据权利要求10的全网全程呼叫跟踪的方法，其中跟踪信息编号越大，它在所述MSC图中的位置越往下。

12.根据权利要求1的全网全程呼叫跟踪的方法，其中接收到其中插入呼叫跟踪选项的呼叫消息的实体也将该呼叫的所有消息送往指定的跟踪终端，从而使所有与该呼叫相关的实体都被感染。

Images