专利名称：一种实现基群速率适配信令统计解析的方法
技术领域：
本发明涉及呼叫消息的解析技术，特别是关于实现基群速率适配(PRA，Primary Rate Adaptation)信令统计解析的方法。
背景技术：
随着PRA中继越来越广泛地在网上得到运用，与呼叫相关的PRA问题也越来越多，尽管有些数字程控交换系统已在维护台上集成了PRA消息的跟踪和解释功能，但交换机一般只提供即时解释和存盘文件回顾的功能，也就是在跟踪消息的同时，能够对消息进行解释，或是对存盘文件进行解释，很少有统计和分析功能。这种方法仅适用于简单问题的分析和定位，一旦面对大量的跟踪消息，往往就显得力不从心，很容易被无用信息所淹没。
目前虽然也有很多公司直接提供信令分析仪设备，但这类设备大都是独立的设备实体，其重点在于硬件设备，同时支持软件统计的功能。其实现方案是通过使用E1接口将信令分析仪并联到交换机的传输设备上，或者将信令分析仪作为终端和E1口直接对接。这些信令分析仪是采用独立的信令跟踪格式进行消息收集、对每条消息进行解释。但是这些现有的信令分析仪设备普遍存在许多不足，主要表现在以下几点1)价格昂贵；2)体积庞大，笨重，携带不方便；3)维护效率低，无法从整体上对消息进行统计、分析；4)操作复杂，操作人员需要经过一定的培训才能掌握其使用方法。
发明内容
有鉴于此，本发明提供了一种实现基群速率适配信令统计解析的方法，使其具有灵活的消息跟踪和分析统计功能，并且成本低廉、操作简单、便于携带。
一种实现基群速率适配信令统计解析的方法，该方法是这样实现的一种实现基群速率适配信令(PRA)统计解析的方法，在PRA信令通信过程中，将从指定PRA/基本速率适配信令(BRA)端口跟踪得到的PRA信令从交换机的主控板传到维护台，再将该PRA信令保存于维护台中的端口信令跟踪存盘文件中，其特征在于，该方法包括以下步骤A.搜索端口信令跟踪存盘文件，将端口信令跟踪存盘文件中PRA信令的每个数据帧作为一条记录，生成原始消息表；B.将步骤A中的原始消息表进行过滤和排序，然后逐条扫描原始消息表中的记录，并将扫描内容解析后得到解释内容；搜索该解释内容，将需要的信息进行统计，建立呼叫记录表。
该方法进一步包括将呼叫记录表按呼叫标识进行排序，然后从第一条记录开始扫描，统计呼叫记录表中的每个字段，建立呼叫汇总表。
该方法进一步包括将呼叫记录表按主叫号码和呼叫标识进行排序，然后从第一条记录开始扫描，统计呼叫记录表中每个字段，建立主叫汇总表。
该方法进一步包括将呼叫记录表按被叫号码和呼叫标识进行排序，然后从第一条记录开始扫描，统计呼叫记录表中每个字段，建立被叫汇总表。
该方法进一步包括将呼叫记录表按拆线原因进行排序，然后从第一条记录开始扫描，统计呼叫记录表中每个字段，建立原因汇总表。
设定所述步骤A中的原始消息表包括流水号、呼叫标识(ID)、呼叫参考、跟踪时间、方向、消息类型和消息内容。
设定所述步骤B中的呼叫记录表包括记录头、主被叫号码、呼叫状态时间点、通话时长、拆线原因和流水号区间。
设定呼叫汇总表包括主叫标识、方向、占用次数、被叫忙次数、振零早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率。
设定主叫汇总表包括主叫号码、方向、占用次数、被叫忙次数、振铃早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率。
设定被叫汇总表包括被叫号码、方向、占用次数、被叫忙次数、振铃早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率。
设定原因汇总表包括拆线原因值、呼叫个数和拆线原因名，所述的呼叫个数是该原因拆线的呼叫个数。因此，使用本发明进行信令跟踪和统计分析具有如下优点1)由于采用了成熟技术开发，所以本发明成本比较低廉；2)由于该方法全部以软件形式实现，因此可以通过网络发送，在普通计算机上安装后就可以使用，且具有较为完善的分析统计功能、对系统硬件没有任何要求；3)由于该方法为用户提供了方便的交互界面，所以使用简单、灵活，且对专业要求不高；4)由于本发明的方法是以呼叫记录表为基础，可根据用户需要，由呼叫记录表灵活生成呼叫汇总表、主叫汇总表、被叫汇总表和原因汇总表等，使其更加灵活、方便实用。
图1为本发明建立呼叫记录表的流程图；图2为本发明各表之间的层次关系示意图。
具体实施例方式
本发明的核心内容是对终端维护台PRA端口信令跟踪得到的结果文件一端口信令跟踪存盘文件进行脱机统计分析。为了减少设计工作量、降低模块的耦合性，并能保证维护台和分析软件的一致性，本发明可采用当前维护台的解释动态链接库，所有解释工作都由该链接库来完成。因此，本发明主要用于显示解释结果并对解释结果进行分析统计。
下面结合附图和具体实施例详细说明本发明的技术方案。
首先来分析一下端口信令跟踪存盘文件的结构。端口信令跟踪存盘文件是通过打开指定PRA/基本速率适配信令(BRA)端口的信令跟踪窗口，将PRA和BRA信令从交换机的主控板传到维护台，然后将这些信令保存在端口信令跟踪存盘文件中在维护台的安装目录下。
表1为端口信令跟踪存盘文件的构成。如表1所示，端口信令跟踪存盘文件分为文件头和文件体两部分，文件体可以包含多条记录，每条记录都由记录头和记录体组成，而记录体又分为数据帧头和数据帧体，一条记录包含一个数据帧。
表1表2为文件头格式。如表2所示，文件头包括存盘时长、记录数和最后记录长度。其中，存盘时长是从开始跟踪到结束存盘的时间长度，单位是Tick，也就是十毫秒；记录数是存盘文件中包含的记录条数；最后记录长度是最后一条记录的长度，单位为字节。|<---------------------文件头--------------------->|<------文件体--->|
表2表3为记录头格式。如表3所示，记录头包括记录号、最后记录长度和数据长度。其中，记录号为记录的流水号；最后记录长度是最后一条记录的长度，单位为字节；数据长度是记录体的长度，单位为字节。|<--------------------------记录头--------------------->|<-----------记录体------------->|
表3表4为数据帧格式。如表4所示，数据帧头包括设备标识、端口号、呼叫参考、跟踪时间、消息类型、方向、信令类型和帧长度。|<-------------------------------------------数据帧头---------------------------------------->|<帧体>|
表4表5为设备标识对应表。设备标识是标识被跟踪端口的设备类型，表5示出了PRA、数字用户(DSL，Digital Subscriber Line board)、V5RPA和V5DSL等四种设备类型，一种设备对应一个标识，这四种设备的标识分别为15、3、59和58。
表5端口号为被跟踪设备的端口号。
呼叫参考是用于区分不同的呼叫，呼叫参考相同的消息属于同一个呼叫。当然，也会有例外的情况，比如1)呼出呼叫的第一个消息“建立”(SETUP)的呼叫参考值为65535，在判断它属于某个呼叫时可以使用其后的“查询用户数据”(CR_USER_DATA)消息的呼叫参考，因为这两个消息是一次性输出的，所以能保证判断结果的正确性。
2)“通知DSL板连网”(CONNECT_NET)消息和“SETUP”消息一样，也要通过其后的消息的呼叫参考来判断。
3)“通知DSL板拆网(DISCONNECT_NET)消息则要通过前一条消息的呼叫参考来判断。
4)除上述3个消息以外的其他呼叫参考为65535的消息都是与呼叫无关的消息，如链路消息，跟踪打印消息等，这些消息不属于任何一个呼叫。
跟踪时间是交换机发送该消息的时间，表6为跟踪时间格式。如表6所示，时间从低位到高位分别为秒、分、小时、日和月。
表6消息类型为消息的大分类，如211代表维护消息，212代表链路消息，213代表调试消息等。
方向是消息发送的方向。
表7为消息方向的定义。如表7所示，方向有以下取值范围。用户侧发往网络侧，方向为U→N，取值为0，网络侧发往用户侧，方向为U←N，取值为1，网络侧发往CCB，方向为N→C，取值为2，CCB发往网络侧，方向为N←C，取值为3，网络内部消息，方向为NN，取值为4。
表7信令类型用于区分不同类型的跟踪消息，如PRA、电话用户部分(TUP)等。
帧长度是数据帧体的长度，单位为字节。
如图1所示，本实施例是根据端口信令跟踪存盘文件生成原始消息表，再将原始消息表进行过滤和排序后生成呼叫记录表，之后，可以根据用户不同的需要由呼叫记录表生成呼叫汇总表、主叫汇总表、被叫汇总表和原因汇总表等。其中，原始消息表是记录原始消息内容，一条记录对应端口信令存盘文件中的一个PRA消息；呼叫记录表是对原始消息表按呼叫汇总的结果表；呼叫汇总表是对呼叫记录表按出入局或呼入、呼出进行汇总的结果表；主叫汇总表是对呼叫记录表按主叫号码进行汇总的结果表；被叫汇总表是对呼叫记录表按被叫号码进行汇总的结果表；原因汇总表是对呼叫记录表按拆线原因进行汇总的结果表。
图2所示为上述各表之间有以下层次关系图。如图2，第一层次为原始消息表，第二层次为呼叫记录表，第三层次包括呼叫汇总表、主叫汇总表、被叫汇总表和原因汇总表。高层次的表都是由低层次的表生成，因此从高层表的某条记录可以查询到低层表的相关记录，从低层表的某条记录又可以查到底层表的相关记录，这样就形成了一个查询的层次结构，即由高到低查询，由低到高回溯。
另外，本实施例需要调用原维护台的消息解释动态链接库来进行某些数据的导入，比如，消息类型字符串和解释内容字符串等数据都是将数据帧输入相应的接口函数得到。
可见，呼叫记录表的获得是本发明对呼叫进行解析的基础，那么本发明的对端口信令跟踪存盘文件进行分析统计的具体过程主要包括以下两个步骤。
步骤一根据信令跟踪文件生成原始消息表。
信令跟踪文件中的每个数据帧都对应一条跟踪消息，包含有呼叫参考、跟踪时间、方向、消息类型、消息内容等信息，原始消息表中的每条记录都由一个数据帧生成，包含了数据帧的所有信息。
表8表8为原始消息表字段定义。如表8所示，原始消息表包括流水号、呼叫标识(ID)、呼叫参考、跟踪时间、方向、消息类型和消息内容。其中，流水号用于唯一标识一条消息，从1开始累加，每生成一条记录加1；呼叫参考是在显示时使用，直接用数据帧的“呼叫参考”赋值；跟踪时间是交换机发送该消息的时间，由数据帧的“跟踪时间”得到；方向是消息发送的方向，由数据帧的“方向”得到；消息类型是将数据帧传入相应的接口函数后得到；消息内容是用于存放消息的二进制编码，直接拷贝数据帧体得到；呼叫ID用于区分不同的呼叫，呼叫ID相同的消息属于同一个呼叫，其取值方法如下1)如果是呼叫参考为65535的“SETUP”消息或“(CONECT-NET)”消息，用其后第一条消息的呼叫参考赋值；2)如果是呼叫参考为65535的“(DISCONECT_NET)”消息，用前一条消息的呼叫参考赋值；3)其他消息直接用呼叫参考赋值。
生成原始消息表后，所有后续分析所需要的信息都已包含在该表中，此后的操作不再涉及跟踪存盘文件。
步骤二根据原始消息表，按每个呼叫汇总生成呼叫记录表，其具体过程如下首先把原始消息表按呼叫ID和流水号排序，并将与统计无关的消息过滤掉。排序是为避免呼叫之间的干扰，在处理完一个呼叫后再处理下一个呼叫。并且，为加快处理的速度，本实施例只保留“CR_USER_DATA”、“SETUP”、“信息”(INFORMATION)、“呼叫递交”(CALL_DELIVERED)、“呼叫接收” (CALL_RECEIVED)、“运行” (DSS1_ACTIVE)、“拆线”(DISCONNECT)、“释放” (RELEASE)、“释放完成”(RELEASE_COMPLETE)、“零状态”(DSS1_NULL)10个消息。
然后从原始记录表中的第一条记录开始向下扫描，将表中保存的消息内容传入相应的接口函数后得到解释的内容，然后在其中搜索需要的信息，并进行相应的统计，最终生成一张呼叫记录表。
呼叫记录表的结构如表9所示，呼叫记录表包括记录头、主被叫号码、呼叫状态时间点、通话时长、拆线原因和流水号区间。
表9其中，表10为记录头结构。如表10所示，记录头包括呼叫ID、方向、呼叫参考值、CCB号和主叫标识。
表10呼叫ID在每扫描到一个有效新呼叫后赋值。这里的有效是指，当扫描到原始消息表的一个新呼叫ID时，如果该消息是呼叫参考为65535的“SETUP”消息，说明是呼出呼叫，如果是“CR_USER_DATA”，说明是呼入呼叫，如果两者都不是，说明这条消息是一个不完整呼叫的后半部，这种呼叫被认为是无效的，不参与统计，可以直接将其丢弃。
主叫标识用于判断呼叫的主被叫属性，在判断新呼叫有效性的过程中就能够得到，如果是主叫，该值为TRUE，否则为FALSE。
方向是只用于显示的字段，如果主叫标识是TRUE，对于(V5)DSL和(V5)PRA，该值分别为“呼出”和“入局”，否则为“呼入”和“出局”。
呼叫参考值是Q.931协议中用来在一个接口上唯一标识一个呼叫的参考值，其可从消息解释内容中搜索得到，此字段是作为保留字段，暂时无用。
CCB号是交换机内部用于关联一个呼叫的主被叫方的一个标识，该值从消息解释内容中搜索得到，此字段也是作为保留字段，暂时无用。
表11为主被叫号码结构。如表11所示，主被叫号码的结构包括主叫号码、被叫号码、用户侧主叫号码、CCB侧主叫号码、用户侧被叫号码和CCB侧被叫号码。其中，用户侧主叫号码是用户侧发给网络侧或网络侧发给用户侧的主叫号码；CCB侧主叫号码是网络侧发给CCB或CCB发给网络侧的主叫号码；用户侧被叫号码是用户侧发给网络侧或网络侧发给用户侧的被叫号码；CCB侧被叫号码是网络侧发给CCB或CCB发给网络侧的被叫号码；如果作主叫，主叫号码的取值为用户侧主叫号码，否则为CCB侧主叫号码；如果作主叫，被叫号码的取值为用户侧被叫号码，否则为CCB侧被叫号码。并且，主叫号码和被叫号码可以分别从SETUP消息和SETUP、INFORMATION消息里搜索到，但是如果是重叠发码，需要把两种消息里的被叫号码合并成一个完整的被叫号码。当用户侧的号码不存在时，用CCB侧的号码代替，反之亦然。
表11表12为呼叫状态时间点结构。如表12所示，呼叫状态时间点的结构包括占用时间点、接通时间、应答时间点和结束时间点。其中，如果是主叫，占用时间点的值为第一个消息“SETUP”的跟踪时间，如果是被叫，该值为第一个消息“CR_USER_DATA”的跟踪时间；如果是主叫，接通时间点的值为消息“(CALL_DELIVERED)”的跟踪时间，如果是被叫，该值为消息“(CALL_RECEIVED)”的跟踪时间；应答时间点的值为消息“(DSS1_ACTIVE)”的跟踪时间；结束时间点的值为消息“(DSS1_NULL)”的跟踪时间。
表12通话时长是结束时间点和应答时间点之间的时间差，如果应答时间点或结束时间点不存在，该值为0。
表13为拆线原因结构。如表13所示，拆线原因结构包括拆线原因值和拆线原因名。其中，拆线原因值是呼叫中第一个拆线消息的原因值，可以从解释内容中搜索到；拆线原因名是呼叫原因值对应的名称，也可以从解释内容中搜索到。
表13表14为流水号区间的结构。如表14所示，流水号区间的结构包括起始流水号和结束流水号。其中，起始流水号是呼叫第一个消息的流水号，当扫描到一个新呼叫时赋值；结束流水号是呼叫最后一个消息的流水号，扫描一个呼叫里的每条记录时都赋值。这两个字段的用处在于，当包含的呼叫比较多时，呼叫ID可能会出现重复，也就是说呼叫ID不能作为区分呼叫的唯一字段，这时要通过起始流水号和结束流水号来判断，因为两个呼叫ID相同的呼叫的流水号是不可能有交叉部分的。
表14呼叫记录表是一张以一次呼叫为单位的索引表，它包含了生成以下其他表的所有信息，其后所有的分析都是在该表上进行的。也就是说，可以通过索引该呼叫记录表，生成各种汇总表。比如，按呼叫方向汇总生成呼叫汇总表，其包含呼叫方向、呼叫次数、被叫忙次数、久叫不应次数、振铃早释次数、接通次数、应答次数、其他原因次数、接通率和应答率；按主叫号码汇总生成主叫号码汇总表，其包含主叫号码和呼叫汇总表的所有字段；按被叫号码汇总生成被叫号码汇总表，其包含被叫号码和呼叫汇总表的所有字段；按拆线原因汇总生成原因汇总表，其包含原因值、呼叫次数和拆线原因等。
由于用户不同的需要，可根据不同的表项来汇总数据，在呼叫记录表的基础上进一步生成呼叫汇总表、主叫汇总表、被叫汇总表和原因汇总表等。
(1)呼叫记录表生成呼叫汇总表。
呼叫汇总表是根据呼叫方向汇总数据，按呼叫标识对呼叫记录表排序，然后从第一条记录开始扫描，对各个字段进行统计。表15为呼叫汇总表结构。如表15所示，呼叫汇总表的结构包括主叫标识、方向、占用次数、被叫忙次数、振零早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率。其中，主叫标识呼叫记录表中的主叫标识；方向同呼叫记录表中的方向；占用次数是该方向上的呼叫个数；被叫忙次数是该方向上被叫忙的呼叫个数，通过拆线原因值统计；振铃早释次数是该方向上振铃早释的呼叫个数，通过拆线原因统计；久叫不应次数是该方向上久叫不应的呼叫个数，通过拆线原因统计；接通次数是该方向上迁入“(CALL_DELIVERED)”或“(CALL_RECEIVED)”状态的呼叫个数；应答次数是该方向上迁入“(DSS1_ACTIVE)”的呼叫个数；其它是该方向上非被叫忙、振铃早释、久叫不应、接通、应答的呼叫个数；接通率是接通次数/占用次数*100％；应答率是应答次数/占用次数×100％。
表15(2)由呼叫记录生成主叫汇总表。
主叫汇总表根据主叫号码汇总数据，它首先对呼叫记录表按主叫号码、呼叫标识进行排序，然后从第一条记录开始扫描，对各个字段进行统计。表16为主叫汇总表。如表16所示，主叫汇总表的结构包括主叫号码、方向、占用次数、被叫忙次数、振铃早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率。
表16其中，主叫号码同呼叫记录表的主叫号码；方向同呼叫记录表的方向；占用次数是该主叫号码在该方向上的呼叫个数；被叫忙次数是该主叫号码在该方向上被叫忙的呼叫个数，通过拆线原因值统计；振铃早释次数是该主叫号码在该方向上振铃早释的呼叫个数，通过拆线原因统计；久叫不应次数是该主叫号码在该方向上久叫不应的呼叫个数，通过拆线原因统计；接通次数是该主叫号码在该方向上迁入“(CALL_DELIVERED)”或“(CALL_RECEIVED)”状态的呼叫个数；应答次数是该主叫号码在该方向上迁入“(DSS1_ACTIVE)”的呼叫个数；其它是该主叫号码在该方向上非被叫忙、振铃早释、久叫不应、接通、应答的呼叫个数；接通率是接通次数/占用次数×100％；应答率是应答次数/占用次数×100％。
(3)由呼叫记录表生成被叫汇总表。
被叫汇总表根据被叫号码汇总数据，按被叫号码、呼叫标识对呼叫记录表进行排序，然后从第一条记录开始扫描，对各个字段进行统计。表17为被叫汇总表的结构。如表17所示，被叫汇总表的表结构包括被叫号码、方向、占用次数、被叫忙次数、振铃早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率等。
表17其中，被叫号码同呼叫记录表的被叫号码；方向同呼叫记录表的方向；占用次数是该被叫号码在该方向上的呼叫个数；被叫忙次数是该被叫号码在该方向上被叫忙的呼叫个数，通过拆线原因值统计；振铃早释次数是该被叫号码在该方向上振铃早释的呼叫个数，通过拆线原因统计；久叫不应次数是该被叫号码在该方向上久叫不应的呼叫个数，通过拆线原因统计；接通次数是该被叫号码在该方向上迁入“(CALL_DELIVERED)”或“(CALL_RECEIVED)”状态的呼叫个数；应答次数是该被叫号码在该方向上迁入“(DSS1_ACTIVE)”的呼叫个数；其它是该被叫号码在该方向上非被叫忙、振铃早释、久叫不应、接通、应答的呼叫个数；接通率是接通次数/占用次数×100％；应答率是应答次数/占用次数×100％。
(4)由呼叫记录表生成原因汇总表。
原因汇总表根据拆线原因汇总数据，按拆线原因对呼叫记录表进行排序，然后从第一条记录开始扫描，对各个字段进行统计。表18为原因汇总表结构。如表18所示，原因汇总表的结构包括拆线原因值、呼叫个数和拆线原因名。其中，拆线原因值是同呼叫记录表的拆线原因值；呼叫个数是该原因拆线的呼叫个数。拆线原因名同呼叫记录表的拆线原因名。
表18操作人员可通过交互界面来查询原始消息表，实现脱机解释原始消息，可以将原始消息及其解释内容存盘成网页格式，还可以通过查询呼叫记录表、呼叫汇总表、主叫号码汇总表、被叫号码汇总表和原因汇总表进行呼叫记录、呼叫汇总、主叫号码、被叫号码、拆线原因等各种查询以及进行各表之间的关联查询等。
本实施例使用采用多层数据库控件中的最高层控件来存储存盘文件，所有记录数据的操作都在内存中执行。由于其运行程序时不需要后台数据库的支持，因此采用这种方式能够充分利用数据库操作数据的简易性，减少安装文件的大小和安装的繁琐程度，且有利于其功扩展。
权利要求
1.一种实现基群速率适配信令(PRA)统计解析的方法，在PRA信令通信过程中，将从指定PRA/基本速率适配信令(BRA)端口跟踪得到的PRA信令从交换机的主控板传到维护台，再将该PRA信令保存于维护台中的端口信令跟踪存盘文件中，其特征在于，该方法包括以下步骤A.搜索端口信令跟踪存盘文件，将端口信令跟踪存盘文件中PRA信令的每个数据帧作为一条记录，生成原始消息表；B.将步骤A中的原始消息表进行过滤和排序，然后逐条扫描原始消息表中的记录，并将扫描内容解析后得到解释内容；搜索该解释内容，将需要的信息进行统计，建立呼叫记录表。
2.如权利要求1所述的方法，其特征在于，该方法进一步包括将呼叫记录表按呼叫标识进行排序，然后从第一条记录开始扫描，统计呼叫记录表中的每个字段，建立呼叫汇总表。
3.如权利要求1所述的方法，其特征在于，该方法进一步包括将呼叫记录表按主叫号码和呼叫标识进行排序，然后从第一条记录开始扫描，统计呼叫记录表中每个字段，建立主叫汇总表。
4.如权利要求1所述的方法，其特征在于，该方法进一步包括将呼叫记录表按被叫号码和呼叫标识进行排序，然后从第一条记录开始扫描，统计呼叫记录表中每个字段，建立被叫汇总表。
5.如权利要求1所述的方法，其特征在于，该方法进一步包括将呼叫记录表按拆线原因进行排序，然后从第一条记录开始扫描，统计呼叫记录表中每个字段，建立原因汇总表。
6.如权利要求1所述的方法，其特征在于，设定所述步骤A中的原始消息表包括流水号、呼叫标识(ID)、呼叫参考、跟踪时间、方向、消息类型和消息内容。
7.如权利要求1所述的方法，其特征在于，设定所述步骤B中的呼叫记录表包括记录头、主被叫号码、呼叫状态时间点、通话时长、拆线原因和流水号区间。
8.如权利要求2所述的方法，其特征在于，设定呼叫汇总表包括主叫标识、方向、占用次数、被叫忙次数、振零早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率。
9.如权利要求3所述的方法，其特征在于，设定主叫汇总表包括主叫号码、方向、占用次数、被叫忙次数、振铃早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率。
10.如权利要求4所述的方法，其特征在于，设定被叫汇总表包括被叫号码、方向、占用次数、被叫忙次数、振铃早释次数、久叫不应次数、接通次数、应答次数、其它、接通率和应答率。
11.如权利要求5所述的方法，其特征在于，设定原因汇总表包括拆线原因值、呼叫个数和拆线原因名，所述的呼叫个数是该原因拆线的呼叫个数。
全文摘要
本发明公开了一种实现基群速率适配信令(PRA)统计解析的方法，在PRA信令通信过程中，将从指定PRA/基本速率适配信令(BRA)端口跟踪得到的PRA信令从交换机的主控板传到维护台，再将该PRA信令保存于维护台中端口信令跟踪存盘文件中，该方法包括以下步骤A.搜索端口信令跟踪存盘文件，将端口信令跟踪存盘文件中PRA信令的每个数据帧作为一条记录，生成原始消息表；B.将步骤A中的原始消息表进行过滤和排序，然后逐条扫描原始消息表中的记录，并将扫描内容解析后得到解释内容；搜索该解释内容，将需要的信息进行统计，建立呼叫记录表。本发明通过对终端维护台的端口跟踪存盘文件进行脱机统计分析，且成本低廉、操作简单，应用方便。
文档编号H04M1/26GK1507255SQ0215538
公开日2004年6月23日 申请日期2002年12月11日 优先权日2002年12月11日
发明者陈剑辉 申请人:华为技术有限公司