GSM网络呼叫全流程多接口关联方法

摘要

本发明涉及通信网络的信令监测领域，具体是GSM网络呼叫全流程多接口关联方法。本发明进行的多接口关联涉及到接口有A接口、C/D接口、E接口及L接口。其中A接口对应的协议为BSSAP，C/D接口对应的协议为MAP，E接口对应的协议为ISUP。若被叫用户为预付费用户，还有L接口的CAP协议。本发明能够将已经发生呼叫业务的每个用户的呼叫流程做多接口关联，而不仅仅是针对那些特定的用户。从而极大的方便了运营商在监测网络通信系统时查看用户的呼叫痕迹，有利于故障或问题的快速定位。

权利要求

1.GSM网络呼叫全流程多接口关联方法，包括以下步骤：

A、采集网关采集A口、C/D口、E口及L口的数据，发送到PD模块；

B、PD模块将步骤A发来的数据简解码，获得协议标识，根据协议标识将数据分发给相应的协议模块；

C、各协议模块获得PD模块分发来的数据，处理各自协议的单接口关联，向配置管理模块请求多接口关联标识CALLID，合成TDR并发送到数据库入库模块；

D、配置管理模块在各个协议模块请求多接口关联标识CALLID时，收集用户MSISDN-IMSI-TMSI-MSRN的 对 应 关 系，通 过TMSI、IMSI、MSRN 在 已 经 存 在 的MSISDN-IMSI-TMSI-MSRN对应管理里置换出对应的用户号码，再将CALLID请求消息发给全程关联模块；

E、全程关联模块在步骤D的CALLID请求消息中同时携带主被叫号码的前提下，进行主叫号码匹配查找已存在的多接口关联标识CALLID，如果找到就将此CALLID及回填信息返回给相应发出请求多接口关联标识CALLID的协议模块；如果没有找到就建立新的多接口关联标识CALLID，然后将新建的CALLID返回给相应发出请求多接口关联标识CALLID的协议模块；

F、各协议模块将CALLID发送到数据库入库模块，数据库入库模块将各协议模块发送来的TDR根据CALLID合并成一条CDR记录，插入到数据库。

2.根据权利要求1所述GSM网络呼叫全流程多接口关联方法，其特征在于：所述协议模块包括BSSAP协议处理模块、MAP协议处理模块、ISUP协议处理模块和CAP协议处理模块。

说明书

GSM网络呼叫全流程多接口关联方法

技术领域

[0001] 本发明涉及通信网络的信令监测领域，尤其涉及GSM网络信令监测系统中呼叫业务流程多接口关联的一种方法。

背景技术

[0002] 近年来，随着通讯技术被广泛运用得到人们生活中的各个方面，人们通讯技术的需求也逐渐提高。为了获取更多用户，通信网络运营商之间的竞争越来越激烈。各大运营商提出了各种各样的通信产品套餐、活动优惠及增值业务，而这些能正常推向市场的基础通信网络及各种设备的正常运行。那么，一套对通信网络及设备的运行情况起监测作用的系统显得尤其重要，七号信令监测系统是目前监测领域发展最为迅猛的监测系统。

[0003] 七号信令监测系统是采用IP镜像或者高阻跨接（TDM）的方式从信令链路上获取信令数据，然后分析数据，合成详单数据记录，统计详单数据记录，生成各种业务指标KPI。这样我们可以深层次地了解通信网络的运行情况，从而优化网络管理、用户管理、业务管理及网络的规划设计等。七号信令监测系统涉及多种接口数据的分析和关联。我们知道，用户在一个普通局间的通话流程中所涉及到的接口就有A口（BSSAP）、C/D口（MAP协议）及E接口（ISUP协议），如果用户比较特殊，譬如被叫用户是预付费用户时，还会涉及到L口（CAP协议）。在我们的监测系统中，每种接口的协议数据有一个模块单独处理。每个模块只能处理每种协议的单接口数据关联，不能关联出多接口的全部流程，这不能满足人们对通信网络监测的需求，于是提出了多接口关联。多接口关联是把一个呼叫流程相关的每种接口协议都关联在一起展现出来，并且需要合并各种协议的某些特定数据，生成CDR记录。目前已有的多接口关联方法只能针对特定的用户号码或者IMSI在进行跟踪时做多接口关联，不能对已经发生呼叫业务的用户流程进行多接口关联。

发明内容

[0004] 本发明是克服现有的多接口关联技术不能对已发生呼叫业务的每个用户做全流程关联而提出的一种多接口关联方法。

[0005] 为实现上述目的本发明采用的技术方案是，GSM网络呼叫全流程多接口关联方法，包括以下步骤：

[0006] A、采集网关采集A口、C/D口、E口及L口的数据，发送到PD模块。

[0007] B、PD模块将步骤A发来的数据简解码，获得协议标识，根据协议标识将数据分发给相应的协议模块。

[0008] C、各协议模块获得PD模块分发来的数据，处理各自协议的单接口关联，向配置管理模块请求多接口关联标识CALLID，合成TDR并发送到数据库入库模块。

[0009] D、配置管理模块在各个协议模块请求多接口关联标识CALLID时，收集用户MSISDN-IMSI-TMSI-MSRN的对应关系，并将CALLID请求消息转发给全程关联模块。

[0010] E、全程关联模块根据步骤D中CALLID请求消息生成CALLID，并返回给相应发出请求多接口关联标识CALLID的协议模块。

[0011] F、各协议模块将CALLID发送到数据库入库模块，数据库入库模块将各协议模块发送来的TDR根据CALLID合并成一条CDR记录，插入到数据库。

[0012] 具体的，上述协议模块包括BSSAP协议处理模块、MAP协议处理模块、ISUP协议处理模块和CAP协议处理模块。

[0013] 该方法能够将已经发生呼叫业务的每个用户的呼叫流程做多接口关联，而不仅仅是针对那些特定的用户。这极大的方便了运营商在监测网络通信系统时查看用户的呼叫痕迹，有利于故障或问题的快速定位。

附图说明

[0014] 图1为本发明的基础系统图；

[0015] 图2为配置管理模块用户MSISDN-IMSI-TMSI-MSRN对应关系存储图;

[0016] 图3为全程关联模块呼叫业务全程关联的流程图；

[0017] 图4为本发明关联出来的局内呼叫全流程图；

[0018] 图5为本发明关联出来的局间呼叫全流程图。

具体实施方式

[0019] 本发明提出了一种能够将发生呼叫业务的每个用户的呼叫流程都进行多接口关联。在GSM通信网络中的呼叫业务中，涉及到接口有A接口、 C/D接口、E接口及L接口。其中A接口对应的协议为BSSAP，C/D接口对应的协议为MAP，E接口对应的协议为ISUP。这里涉及到三种协议,若被叫用户为预付费用户，还有L接口的CAP协议。下面就以BSSAP、MAP、ISUP及CAP协议为例，一步步说明呼叫业务的多接口关联。

[0020] 图1为本发明实现的基础系统图。

[0021] 1、采集网关采集A口、C/D口、E口及L口的数据，发送到PD模块。

[0022] 2、PD模块对采集网关送过来的数据做简单解码，根据协议标识，将数据分发给相应的协议处理模块。PD模块给每条二进制码流打个索引头和时间戳，并将原始码流发给原始码流存储模块。原始码流存储模块将原始码流按照索引规则存储到硬盘介质上。

[0023] 3、BSSAP处理模块处理Bssap协议的单接口关联。在处理单接口合成的过程中，在消息SetUp时向配置管理模块请求多接口关联标识CALLID。在TDR合成后，就将TDR数据发给数据库入库模块，入库的信息包括了CALLID、TDRID及其他相关字段。将CALLID、TDRID及该TDR所有的码流索引发给码流索引存储模块。

[0024] 4、MAP处理模块处理MAP协议的单接口关联。对于呼叫业务，MAP协议会产生两种事务，即会合成两种TDR。一种是路由寻址TDR，这种TDR一般在消息SendRoutingInfo_res的时候向配置管理模块请求多接口关联标识CALLID，另一种是提供漫游号码TDR，这种TDR一般在消息ProvideRoamingNuber_resp的时候向配置管理模块请求多接口关联标识CALLID。在TDR合成后，就将TDR数据发给数据库入库模块，入库的信息包括了CALLID、TDRID及其他相关字段。将CALLID、TDRID及该TDR所有的码流索引发给码流索引存储模块。

[0025] 5、ISUP处理模块处理ISUP协议的单接口关联。在处理单接口合成的过程中，在消息IAM时向配置管理模块请求多接口关联标识CALLID。在TDR合成后，就将TDR数据发给数据库入库模块，入库的信息包括了CALLID、TDRID及其他相关字段。将CALLID、TDRID及该TDR所有的码流索引发给码流索引存储模块。

[0026] 6、CAP处理模块处理CAP协议的单接口关联。在处理单接口合成的过程中，在消息initialDP时向配置管理模块请求多接口关联标识CALLID。在TDR合成后，就将TDR数据发给数据库入库模块，入库的信息包括了CALLID、TDRID及其他相关字段。将CALLID、TDRID及该TDR所有的码流索引发给码流索引存储模块。

[0027] 7、配置管理模块保存了每个用户的MSISDN-IMSI-TMSI-MSRN对应关系。各个协议请求CALLID的消息先发送到配置管理模块。通过TMSI、IMSI、MSRN（漫游号码）在已经存在的MSISDN-IMSI-TMSI-MSRN对应管理里置换出对应的用户号码，再将CALLID请求消息发给全程关联模块。

[0028] 8、对于呼叫业务来说，全程关联模块在上述请求CALLID消息中同时携带主被叫号码的前提下，进行主叫号码匹配查找已存在的多接口联标识CALLID，如果找到就将此CALLID及回填信息返回给相应的协议模块；如果没有找到就建立新的多接口关联标识CALLID，然后将新建的CALLID返回给相应的协议模块。对于请求消息只是携带了“主叫号码”或者“被叫号码”，进行单号匹配查找已存在的多接口关联标识CALLID，如果找到就将此CALLID及回填信息返回给相应的协议模块；如果没有找到，就将该消息进行缓存。在建立新的CALLID的时候，反查这些缓存的消息，将新建立的CALLID返回给相应的协议模块。

[0029] 9、数据库入库模块主要负责将各个协议发过来的TDR根据呼叫CALLID合并成一条CDR记录，并入数据库。

[0030] 10、码流索引存储模块将各个协议模块发过来的码流索引按照CALLID及TDRID规则存储到硬盘介质上。

[0031] 11、启动前台，查询呼叫详单记录。点击一条CDR记录，查看“多接口分析”。将该条记录的CALLID传到接口机。

[0032] 12、接口机将CALLID发送到码流接口机。

[0033] 13、码流接口机将CALLID发送到码流索引读取模块。码流索引读取模块根据CALLID查询对应的码流索引，然后再根据码流索引发到原始码流读取模块，原始码流读取模块根据码流索引将原始码流读出来发给码流索引读取模块，码流索引读取模块将原始码流发给码流接口机，码流接口机将原始码流发给接口机，接口机将原始码流发给前台。

[0034] 14、前台接收到原始码流，根据点码绘制该CDR记录对应的呼叫多接口关联接续图。

[0035] 图2为配置管理模块用户MSISDN-IMSI-TMSI-MSRN对应关系存储图。

[0036] CALLID请求消息是各个协议模块请求CALLID时发送到配置管理模块的消息。在这个消息中，携带了主叫用户或者被叫用户的某些对应关系，配置管理模块收集这些对应关系并加以整理，就能形成每个用户MSISDN-IMSI-TMSI-MSRN的对应关系。这里介绍下，各个协议发送的CALLID请求消息里所携带的对应关系。

[0037] 1、Bssap协议：在消息CM Service Request中一般携带主叫号码的IMSI或者TMSI,在CommandID里获取主叫的IMSI。当CM Service Request中携带主叫号码TMSI的时候，可以获取主叫号码TMSI与IMSI的对应关系。Paging里携带有被叫号码IMSI与TMSI，这里可以获取被叫号码的TMSI与IMSI的对应关系。

[0038] 2、MAP协 议：在 消 息SendRoutingInfo_req携 带 有 被 叫 号 码，在 消 息SendRoutingInfo_res里携带有被叫号码IMSI，漫游号码。这里可以获取被叫号码与被叫IMSI的对应关系，还能获取被叫号码与漫游号码的对应关系。在消息ProvideRoamingNumber_req带有被叫号码，ProvideRoamingNuber_resp带有漫游号码。这里可以获取被叫与漫游号码的对应关系。

[0039] 在MAP协议处理的业务中，位置更新业务的消息UpdateLocation_req中会携带有用户的IMSI，在第一条InsertSubscriberData_con消息中会携带用户的电话号码。这个时候会收集到用户IMSI与电话号码的对应关系。

[0040] 配置管理模块在对以上关系经过一段时间的收集和整理，形成了每个用户MSISDN-IMSI-TMSI-MSRN的对应关系，而且对于同一个对应关系我们用了四个列表来存储其对应关系，分别是以MSISDN为键值的MSISDN列表，以IMSI为键值的IMSI列表，以TMSI为键值的TMSI列表，以MSRN为键值的MSRN列表。在后来的协议请求CALLID 的时候，通过IMSI或者TMSI或者漫游号码去相应的列表置换用户号码是非常快速的。用置换出的号码去做呼叫业务的多接口关联是具有显著效果的。

[0041] 图3为全程关联模块呼叫业务全程关联的流程图。

[0042] 图中相关说明：呼叫节点FSM;主叫号码CALLER；被叫号码CALLED；主叫IMSI；被叫IMSI；呼叫标识CALLID；BSSAP协议返回CALLID记数BssapCount；MAP协议返回CALLID记数MapCount；ISUP协议返回CALLID记数IsupCount；Cap协议返回CALLID记数CapCount；小节点存在的句柄pTimehItem；呼叫容器节点CALLNODE：时间最近的呼叫节点PlastFsm；等待消息队列TholdList;等待消息总数usHoldNum;对端号码小节点列表MAP<对端号码，FSM*> CallingNode;等待队列的超时句柄pHoldTime；主叫队列MAP CallerMap;被叫队列MAP CalledMap。

[0043] 1、全称关联模块在处理呼叫业务多接口关联的时候，一般有三种情况。第一种：请求消息同时带有主叫号码Caller及被叫号码Called。第二种：请求消息只带有主叫号码Caller。第三种：请求消息只带有别叫号码Called。

[0044] 2、当请求消息同时带有主被叫号码Caller及Called时，先用Caller在主叫队列CallerMap查找容器节点CALLNODE。如果找到CALLNODE，就用Called在CALLNODE里的CallingNode查找FSM，没有超时就将FSM里CALLID返回给相应协议模块；如果CALLNODE不存在，就要新建一个CALLNODE，并以Caller为键值将CALLNODE插入到主叫队列CallerMap中。当CALLNODE中的CallingNode没有查找到FSM或者CallingNode为空的前提下就新建一个FSM，这个时候需要将请求消息里的主被叫号码及主被叫IMSI赋值给FSM里的相关字段，FSM的CALLID也需要重新获取值。将建立好的FSM以被叫号码为键值插入到 CallingNode中，并将该FSM赋值给PlastFsm。如果CALLNODE不是新建的，还需要处理CALLNODE里的TholdeList,这里请求消息都只带了跟caller一致的主叫号码，这里需要将新建立FSM中的CALLID返回给相应协议模块。最后，以被叫号码为节点在被叫队列CalledMap查找容器节点CALLNODE，如果不存在CALLNODE就要新建一个，以被叫号码为键值将CALLNODE插入到被叫队列CalledMap，将FSM以主叫号码为键值插入到CALLNODE里的CallingNode, 并将该FSM赋值给PlastFsm。如果存在CALLNODE，还要处理CALLNODE里的TholdList队列，这个队列里缓存的是只是携带了与被叫号码Called一致的请求消息，这里将FSM里的CALLID返回相应的协议处理模块。这里就有一个关键点，就是FSM，同时在主叫队列及被叫队列存在，这么做只是为了方便后面的单主叫号码关联或者单被叫号码关联。

[0045] 3、当请求消息指示携带了主叫号码的时候，以主叫在主叫队列查找CALLNODE，如果查找到CALLNODE，就判断该CALLNODE里的PlastFsm是否为空，不为空时，再判断该PlastFsm是否超时，如果不超时就将该FSM里的CALLID返回给相应的协议模块。如果PlastFsm超时，就删除FSM，将请求消息插入到TholdList里。如果PlastFsm为空，也将将请求消息插入到TholdList里。如果没有找到CALLNODE，就新建立一个CALLNODE，以主叫号码为键值，将CALLNODE插入到主叫队列CallerMap中，将请求消息插入到TholdList里。

[0046] 4、当请求消息只携带了被叫号码的时候，以被叫号码在被叫队列查找CALLNODE，如果查找到CALLNODE，就判断该CALLNODE里的PlastFsm是否为空，不为空，在判断PlastFsm是否超时，如果不超时就将该FSM里的CALLID返回给相应的协议模块。如果PlastFsm超时，就删除FSM，将请求消息插入到TholdList里。如果PlastFsm为空，也将将请求消息插入到TholdList里。如果没有找到CALLNODE，就新建立一个CALLNODE，以被叫号码为键值，将CALLNODE插入到被叫队列CalledMap中，将请求消息插入到TholdList里。

[0047] 图4为局内呼叫全流程图。

[0048] 该流程图就是根据上述呼叫多接口关联方法关联出来的局内呼叫流程图，这里有主叫测Bssap,Cap,Map及被叫测Bssap.

[0049] 图5为局间呼叫全流程图。

[0050] 该流程图就是根据上述呼叫多接口关联方法关联出来的局间呼叫流程图，这里有主叫测Bssap,Cap,Map及ISUP。