一种移动通信系统中对运行或测试数据进行处理和分析的方法和装置

摘要

本发明是一种对移动通信系统在大话务量情况下，对各种呼叫事件(位置更新，呼叫过程，短消息，切换等)结果进行自动分析的方法和装置，包括采用一台信令分析仪，监测一个或多个基站、一个基站控制器和一个移动交换中心之间的信令往来，并把结果存储到信令分析仪本地存储器，然后，利用计算机自动分析系统中各种呼叫事件(位置更新、呼叫过程、短消息、切换等)的结果(成功或失败，在哪一步失败)，并为每一单独事件分离出其单独的信令记录，画出每一事件的可视化的信令流程图，使结果一目了然；所述的基站控制器用于分别接收各基站控制器、移动交换中心的信号，并能控制各基站的工作。

说明书

(一)技术领域

本发明涉及一种移动通信系统在运行或测试时对数据的采集、处理和自动分析方法和装置，更具体地说，涉及一种移动通信系统在运行或测试时对测试数据进行采集、分析，有选择地输出结果，以帮助判断可能存在的运行故障的方法和装置。

(二)背景技术

移动通信的已有技术网络结构组成如附图1所示。

空中接口的GSM术语叫Um口，UMTS术语叫Uu口；Abis接口是基站与基站控制器间的接口，其中，Abis是GSM术语，UMTS术语Iub接口；A接口是基站控制器与移动交换中心间的接口的GSM术语，其UMTS术语叫Iu接口。

为叙述方便，本发明在多处以GSM系统为例对发明方案进行了说明，因此多采用GSM系统的接口术语。需要说明的是，这只是为叙述方便，实际上当本发明采用其他系统时，应把有关的接口名称改换成相应的其它接口名称。

在移动通信系统的研制和运行过程中，需要对系统做大负载测试、多用户测试或其他类型的复杂测试，以检验系统的运行状况，包括性能、兼容性、稳定性和抗过载能力等。在做这类测试时，需要拨打几十到成百上千个电话。由此产生的消息流程的记录文件(LOG文件)可能达几百兆字节。当测试中发生错误时，需要找到错误点，错误的原因，以及错误的上下文。而已有技术所采用的手工分析几百兆字节的文件，是既费时费力，又低效的工作。在实际投入运行的系统中，这种对故障的分析处理能力是难以令人满意的。

(三)发明内容    

针对已有技术的不足，本发明提供一种分析移动通信系统工作状况的分析方法。该方法利用计算机技术，根据同一呼叫连接的消息的相关性，自动分析记录文件，当发现错误时，在分析结果中给出错误的所有信息，并且，把上百兆字节的文件分解，把每一个呼叫连接的相关消息放到单独的文件中，并且可以选择地过滤掉一些不重要的消息，如：测量报告消息，使进一步分析问题更加简单容易。另外，还可以按照不同的基站，不同的呼叫事件，画出对应的流程图，使分析问题更直观化。

在本发明中，呼叫事件指在移动通信领域中，与呼叫有关的事件，包括主叫电话、被叫电话、位置更新、切换、短消息等。

具体地说，本发明公开了一种移动通信系统中对运行或测试数据进行处理和分析的方法，对系统的工作或测试状态进行分析，包括：

采用至少一个基站，一个基站控制器，一个信令分析仪和一个移动交换中心，信令分析仪带有一个存储器，用于存储记录文件；所述的基站控制器用于分别接收各基站、移动交换中心的信号，并能控制各基站的工作，信令分析仪监测并解码各基站与基站控制器、基站控制器与移动交换中心之间的往来信令，然后把监测结果记录到本地存储器(通常为本地硬盘)的一个文件中；上述设备对系统的工作或运行或测试数据进行有选择地采集、归类、分析和输出，包括下列步骤：

(1)向分析系统输入系统的工作参数和其它需要分析的数据：由信令分析仪记录的记录文件，另外还可以输入基站与基站控制器之间接口链路配置信息，包括基站名称、基站与基站控制器之间接口上行链路名称和下行链路名称；

(2)根据系统运行情况分析的需要，信令分析仪至少分析以下的工作过程参数：信令分析仪所记录的时间标记和链路名称，所有与呼叫连接有关的基站与基站控制器之间接口消息，所有与呼叫有关的基站控制器与移动交换中心之间接口消息；

(3)根据上面的分析结果，信令分析仪至少输出以下三类文件：呼叫连接文件，公共消息文件和摘要信息表，供对系统工作情况进行分析时使用。

本发明还公开了另一种方法，在上述方法的基础上还包括为每个呼叫连接分别产生一个单独的呼叫连接文件，所述的公共消息文件至少包含广播信道信息和呼叫信息，所述的摘要信息表为每个呼叫连接给出一行包含呼叫基本数据的信息，所述的信息至少包括发生错误时与错误有关的信息。

按照本发明的另一个方面，还包括当发生错误时，摘要表中还包含呼叫连接的错误信息、基站与基站控制器之间接口的上行链路名称、基站与基站控制器之间接口的下行链路名称、基站控制器与移动交换中心之间接口上7号信令连接的基站控制器侧的区域参数信元、基站控制器与移动交换中心之间接口上7号信令连接的移动交换中心侧的区域参数信元、被叫号码中的一项或多项。

按照本发明的另一个方面，还包括摘要表中包含呼叫连接的开始时间、呼叫连接的结束时间、无线资源连接身份号、系统帧号、呼叫者身份号、呼叫类型、呼叫连接的释放信息中的一项或多项。

按照本发明的另一个方面，本发明方法的分析过程还包括以下步骤：

(1)找出所涉及的消息属于哪一个基站；

(2)判断消息属于哪一个呼叫连接；

(3)把消息输出到相应的文件中；

(4)选择有用的信息，输出到摘要信息表。

按照本发明的另一个方面，本发明方法的分析过程还包括：

(5)根据以上步骤所得结果，画出信令流程图；

(6)在流程图中补充基站与基站控制器之间接口消息的呼叫者身份号。

本发明还公开了一种移动移动系统中对运行或测试数据进行处理和分析的装置，用于对系统的运行或测试数据进行有选择地采集、归类、分析和输出，包括：

(1)一个或多个基站，分别与下述的基站控制器相连，同时分别与下述的信令分析仪相连；

(2)一个基站控制器，分别与上述各基站、下述信令分析仪和下述移动交换中心相连，用于分别接收各基站、移动交换中心的信号，并能控制各基站的工作，

(3)一个移动交换中心，分别与所述的基站控制器和下述的信令分析仪相连，

(4)一个信令分析仪，分别与上述各基站、基站控制器和移动交换中心相连，用于以下述方式监测并解码各基站与基站控制器、基站控制器与移动交换中心之间的往来信令，然后把监测结果记录到下述本地存储器的一个文件中：分别向信令分析仪的分析系统输入系统的工作参数和其它需要分析的数据，包括由信令分析仪记录的记录文件，以及基站与基站控制器之间接口链路配置信息，包括基站名称、基站与基站控制器之间接口上行链路名称和下行链路名称；根据系统运行情况分析的需要，至少分析信令分析仪所记录的时间标记和链路名称、所有与呼叫连接有关的基站与基站控制器之间接口消息、所有与呼叫有关的基站控制器与移动交换中心之间接口消息；并根据上面的分析结果，至少输出以下三类文件：呼叫连接文件，公共消息文件和摘要信息表，供对系统工作情况进行分析时使用；

(5)一个本地存储器，与上述信令分析仪相连，用于存储系统的记录文件。

(四)附图说明

图1中示出了移动通信中已有技术的网络结构图。

图2为包括了本发明方案的网络结构示意图。

图3为本发明装置中信令分析仪配置的示意图。

图4示出了本发明方法中消息流程图模型的一个实例。

图5示出了本发明方法中摘要信息表的一个实例。

图6为本方法方法中分析过程的一个示意图。

图7中示出了本发明方法中流程图模型输出的一个实际例子。

(五)具体实施方式

具体地说，本发明方法包括两部分。

第一部分是信令的产生和记录。

该方法采用一个信令分析仪来监测一个或多个基站，一个基站控制器，和一个移动交换中心组成的无线通信系统。信令分析仪带有一个本地存储器(例如一个或多个本地硬盘，或其它技术人员公知的存储器)，用于存储记录文件；信令分析仪记录各基站与基站控制器，基站控制器与移动交换中心的往来信令，并把结果记录到信令分析仪本地存储器上的一个文件中。本发明的信令分析仪还至少包括一个分析系统，按照设定的(这种设定可以修改)模式或算法对有关数据进行分析。

图2为包括了本发明方案的网络结构示意图。

在开始之前，需要配置信令分析仪：在信令分析仪上，对每一个基站与基站控制器间的接口链路，分别给出上行链路名称和下行链路名称以及其他信令分析仪要求的配置，如，协议栈等。对于多个基站情况，每一个基站的上下行链路名称须唯一，这一点对于后面分析是很重要。例如，对于基站1，上下行链路名称可取为：BTS1->BSC和BSC->BTS1，对于BTS2，可取为：BTS2->BSC和BSC->BTS2。

图3为信令分析仪配置示意图。

这样，当进行大话务量运行或进行一项复杂测试时，如，大话务量测试，多用户测试，切换测试等，在信令分析仪的本地存储器上，将产生一个很大的记录文件。此记录文件记录了所有的基站与基站控制器，基站控制器与移动交换中心间的往来信令。这些信令可能包含了成百上千个呼叫事件。这里，呼叫事件可以是手机发起的呼叫，手机作被叫的呼叫，位置更新，切换，短消息等所有呼叫业务。下同。

对于每一条记录的消息，信令分析仪记录了如下的内容：

1)该消息的发送的时间标记(Time Stamp)，精确到毫秒级

2)消息被发送所在的电路的逻辑链路名称(LinkName)

3)该消息采用的协议信息(Protocol)，如，LAPD或7号信令

4)该消息的解码后的文本信息。

5)该消息的未解码的原始数字信息，即，消息的内容。一般为由16进制码字构成的数字序列。

这些内容就是下面自动分析的基础。

第二部分：信令文件的自动化分析

此分析以信令分析仪的记录文件作为输入。分析的任务是：

1)从庞大的单一的记录文件中，分离出每一个呼叫事件自己的所有消息，然后把他们放到自己的文件中。

2)建立一张摘要信息表，此摘要信息表包含了所有呼叫事件的摘要信息，以及到相应的分离出的呼叫事件的文件的超级链接，这样，可以通过此摘要信息表，直接访问任何呼叫的自己单独的信令文件。

3)在信息摘要表中，给出那些呼叫成功，那些呼叫失败，失败原因等关键信息。

4)为每一个呼叫事件，画出单独的可视化流程图，使察看问题更加直观，高效。

只有在开始分析前正确地配置了基站名称与Abis口上下行链路对应关系时，才能正确地画出可视化的流程图。

分析的输出：

根据上面的分析结果，输出以下内容：

a)呼叫连接文件：这是针对每一个呼叫事件的单独的文件，包含了该呼叫事件独有的所有消息。作为选项，有些消息可以被过滤掉，如，测量报告，以使问题的查找更容易。

b)公共消息文件：与呼叫事件不相关的所有消息，均放在此文件中。例如，Abis口的系统消息等。这些消息对于查找问题没有关系或关系不大，可以被忽略。

c)摘要信息表文件：此信息表文件中包含了对每一个呼叫事件的分析结果的关键信息，如，呼叫发起/结束的时间，呼叫事件的主叫方的身份标示，呼叫的被叫方号码，呼叫释放的原因，呼叫发生所在的基站等。另外，还可以包含到每一个呼叫事件的单独的呼叫文件的超级链接。

d)可视化的流程图。按照每个基站画出一个电子流程图，这有助于查找问题。并且，电子流程图有数据筛选功能，可筛选出任意单一呼叫事件，任意呼叫者的所有呼叫事件流程图。有关流程图的详细描述，请参考后面的流程图模型

分析的过程，分析方法：

I)为了分析，本方法建立了以下计算机模型：

1.呼叫事件模型(Call Event Model)。模型用如下参数来描述一个呼叫事件：

1)系统帧号(SFN：System Frame Number)。这一参数描述了呼叫事件发生的起始时间属性。此参数包含在消息信道需求(Channel Required)中。对于同一个呼叫事件，在消息信道激活和信道立即分配中也包含了相同的参数。

2)切换参考标示号(HORef：Handover Reference Number)。这个参数包含在与切换控制有关的消息中，如：信道激活，切换命令等。

3)连接类型(ConnectionType)。这个参数是描述呼叫事件的类型，取值为：主叫电话(MOC)或被叫电话(MTC)或位置更新(LUP：Location Update)或切换(HO：Handover)，短消息(SMS)。

4).无线资源连接身份号(RRID：Radio Connection ID)，这个参数标示此消息属于哪一个呼叫事件。此参数包含在与呼叫有关的Abis口消息中除了信道需求(Channel Required)，信道激活(Channel Activation)和立即分配命令(Immediate Assign Command)以外的所有消息中。

5).Abis口上行链路名称(AbisUpLink)。这是信令分析仪赋予的每一个从基站发往基站控制器的消息，用来标示此消息发生在哪一个链路上。

6).Abis口下行链路名称(AbisDlLink)这是信令分析以赋予的每一个从基站控制器发往基站的消息，用来标示此消息发生在哪一个链路上。

7)基站控制器本地参考号(BSClocalRef)这个参数用来标示A口消息属于哪一个呼叫连接。它包含在移动交换中心(MSC)发往基站控制器的与呼叫相关的消息的“目标参考号”(Destination Reference)中。或者基站控制器发往移动交换中心(MSC)的与呼叫相关的消息的“源参考号“(Source Reference)中。

8)移动交换中心本地参考号(MSCLocalRef：MSC Local Reference Number)这个参数用来标示A口消息属于哪一个呼叫连接。它包含在移动交换中心(MSC)发往基站控制器的与呼叫相关的消息的“源参考号“(Source Reference)中。或者基站控制器发往它包含在移动交换中心(MSC)的与呼叫相关的消息的“目标参考号”(Destination Reference)中。

9)Abis口释放标记(AbisEndFlag：Abis interface End Flag)，用来标示呼叫连接在Abis口释放完毕

10)A口释放标记(AintEndFlag：A interface End Flag)，用来标示呼叫连接在A口释放完毕

11)呼叫事件结束标志(ENDFlag)

12)基站号(BtsNO：BTS Number)，也叫基站名称，用来标示消息所属的基站号。如前所述，此参数下应当在计算机开始分析前输入到计算机中，并且应为同时输入该基站对应的Abis口上下行链路名称。

13)载频号码(TrxID：TRX Identity)。此参数表示消息发生在基站的哪一个载频上。此参数将用Abis口消息的TEI值来表示。对于A口消息，此参数不用。

14)主叫身份标示号(IMSI)。此参数用来标示主叫方的身份，可以是IMSI号、TMSI号、IMEI号。此参数包含在3层服务请求消息中。具体的，服务请求包含如下消息：

·用户服务请求(CM SERVICE REQUEST)

·位置更新请求(LOCATION UPDATING REQUEST)

·IMSI解除绑定(IMSI DETACH)

·寻呼响应(PAGING RESPONSE)

·服务重新连接请求(CM RE-ESTABLISHMENT REQUEST)

·通知响应(NOTIFICATION RESPONSE)

15)被叫号码(CalledNO)。此参数用来标示被叫方的号码，也就是主叫方拨号的号码。此参数包含在呼叫建立消息(set up)中。

16)呼叫错误事件(ErrorEvent)。此参数用来登记呼叫事件是否发生错误。此参数将用来存储属于此呼叫连接的正常呼叫以外的消息名称，例如，Abis口消息：连接失败(Connection Failure)，错误指示(Error Indication)，A口消息：服务拒绝(CM Service Reject)等。

17)错误原因(ErrorCause)。此参数用来存储呼叫事件发生错误，或非正常释放时的原因。此参数可能包含在多种消息中。例如，连接释放(Disconnection)，连接失败(Connection Failure)，错误指示(Error Indication)，服务拒绝(CM Service Reject)等。

18)文件名(FileName)。此参数是程序对每一个呼叫事件分配的文件名。次文件名具有唯一性，用来唯一地确定每一个呼叫事件的单独的文件。

19)流程图名(MessageFlowName)

20)消息名称集合(Messages[])：此参数是一个数组，按顺序记录了本呼叫事件的每一条消息的名称。

21)消息时间标记集合(MsgTimeStamps[])：此参数是一个数组，按顺序记录了本呼叫事件的每一条消息的时间标记。

22)消息位置集合：LineNO[].此参数是一个数组，按顺序记录了本呼叫事件的每一条消息在本呼叫事件所属基站的流程图中的位置，也就是行数。因为，每一条消息在流程图中占用一行。此参数实际上记录了每条消息在相应的基站中所发生的序号。

关于呼叫事件连接模型的身份标示：

为了标示一个呼叫连接事件的身份，以与其它呼叫连接事件相区别，需采用如下参数联合表达：

1)基站号

2)载频号

3)无线资源连接身份号

4)系统帧号

联合表达的意思是：在系统帧号生命周期内，任何两个呼叫连接事件，即上述四个参数不可能全部相同(系统帧号生命周期是：3小时16分钟36秒)。

2.消息模型(Message)。模型用如下参数来描述一个消息：

1)链路名(LinkName)这是每条消息一定包含的，由信令仪为每条消息附加的内容。表明此消息发生在那一条逻辑链路上。

2)时间标记(TimeStamp)：这是每条消息一定包含的，由信令仪为每条消息附加的内容。表明此消息发生在那一时刻。

3)基站号码(BTSNO)：此参数不包含在消息本身当中。此参数只针对Abis或Iub口消息，它的值由计算机在分析时，根据链路名参数，和链路名与基站间的对应关系确定。对于A口消息或Iu口消息，此参数不用。

4)载频号码(TrxID)：此参数表示消息发生在基站的第几个在频上。此参数包含在所有Abis口或Iu口消息当中。对于GSM和TSM来说，此参数用LAPD信令的TEI参数代表。

5)系统帧号(SFN：System Frame Number)：只有个别消息包含此参数。

6)无线资源连接身份号(RRID：Radio Connection ID)：大多数Abis口消息都包含此参数。对于A口消息或Iu口消息，此参数不用。

7)源参考号(SourceLocalReference)：仅包含在部分A口消息当中。对于Abis口消息或Iub口消息，此参数不用。

8)目标参考号(DestLocalReference)：仅包含在部分A口消息当中。对于Abis口消息或Iub口消息，此参数不用。

9)切换参考标示号(HORef：Handover Reference Number)：仅包含在部分消息当中。

前面这些参数意义与呼叫连接模型当中的意义相同。以下这些参数是消息模型独有的参数。

10)消息名(MsgName)：这是每条消息一定包含的，由信令仪为每条消息附加的内容。

11)消息接口名称(Interface)。指示消息属于哪一个接口。

15)原因(CauseValue)这是某些消息包含的，用于表明某个事件的原因。如，切换指示(Handover indication)，连接释放(Disconnection)，连接失败(Connection Failure)等的原因。如果消息不包含这个内容，那么，原因值为空。

实际上，每一个消息并不包含消息模型中的所有参数。每一个消息还可能包含其它参数。分析时，采用匹配法，只要该消息包含消息模型中的参数，就取出该参数，用来描述该消息。

3.消息流程图模型。

其模型特征在于：

a.每个基站在自己的流程图，即流程图是基于基站的。

b.流程图中包含了此基站中所发生的所有的与呼叫有关的消息。

c.流程图流程图具有行列结构。

d.每一个呼叫连接事件的每一条消息在流程图中占用一行。

e.对每一个呼叫连接事件的每一条消息，在该消息所在的行上，至少输出该消息的如下二个参数：消息的时间标记，消息名。每个参数在流程图中占用一列。

f.消息名所在的列的位置，反映了该消息所属的接口的逻辑位置。

g.每个消息名下面，画一条横线。此横线可以有方向，也可以无方向。

h.对每一个呼叫连接事件的每一条消息，在该消息所在的行上，输出该消息所属的呼叫事件的所有参数或某些重要的参数。例如，如下六个参数：呼叫事件的载频号码(TrxID)，无线资源连接身份号(RRID)，主叫身份标示号(IMSI)，被叫号码(CalledNO)，系统帧号(SFN)，切换参考标示号(HORef)。每个参数在流程图中占用一列。

i.可选的，电子流程图具有过滤功能。利用计算机技术，采用过滤功能，过滤出特定条件的流程图。例如，可以根据载频号码(TrxID)，过滤出某一个载频上的所有呼叫事件；可以根据主叫身份标示号过滤出某一个主叫者在测试时间范围内的所发生的所有呼叫事件，可以根据系统帧号(SFN)过滤出某一个单独的呼叫事件等的流程图。

图4示出了消息流程图模型的一个实例。该例采用电子表格软件Excel来完成画流程图。采用Excel来画流程图的好处是：充分采用现有的电子表格的强大的功能，很容易的实现上述过程，如，画线，输出参数，过滤功能等。

4.正常呼叫事件模型

正常的呼叫事件模型是用来判断一个呼叫事件是否正常的标准。此模型包含如下参数：

1)一个正常呼叫事件的可能使用到的所有消息的名称的集合

2)一个正常呼叫事件的原因(Cause)集合。

当某个呼叫事件包含了不属于正常呼叫事件模型的消息名称集合中的消息时，此呼叫事件便被认为是非正常呼叫事件。或者，

当某个呼叫事件的某一个消息包含了正常呼叫事件的原因(Cause)集合以外的原因时，此呼叫事件便被认为是非正常呼叫事件。

可以对每一种呼叫事件建立一个正常的呼叫事件模型。进一步的，可以把所有的呼叫事件模型统一起来，建立一个公共的正常呼叫事件模型。此公共正常呼叫事件模型的消息名称集合包含每一种正常呼叫事件的所有消息名称。原因集合包含所有正常的原因。因此，此公共正常事件模型可用来判断每一种呼叫事件正确与否。

5.摘要信息表：

摘要信息表包含了呼叫事件模型当中的全部或部分参数。摘要信息表示表格结构。每一个呼叫事件在表中占用一行。该行中可以包含到此呼叫事件的单独的消息文件的超级链接。

图5示出了摘要信息表的一个实例。在图5中，StartTime表示事件开始时间，EndTime表示事件结束时间，RRID表示无线资源连接身份号，SFN表示呼叫发生的起始系统帧号，IMSI表示呼叫者身份号，ConnType表示连接类型，Error EventCall Release表示错误事件，AbisUPLink表示Abis口上行链路名，AbisDLink表示Abis口下行链路名，Called Number表示被叫号码，Error Cause表示错误原因。

II)为了分析，本方法根据每个基站分别定义一个消息计数器。

消息计数器用来记录该基站收到或发出的与呼叫事件有关的消息总数。设置此计数器的目的在于，为呼叫事件的每个消息，记录该消息在流程图中的位置，即行数。为了表达方便，定义计数器名称为：BTS_Received_Message[x]，x代表第几个基站。

III)分析过程

本方法的分析过程如以下图6所示，详细步骤请见后面的主要步骤详细描述。

主要步骤的详细描述：

在计算基中，根据呼叫事件模型，建立一个呼叫事件数组。为了表达方便，为数组取个名字：Connection[]。

并用Connection[i]来表示数组中的第i个元素。这里，i是正整数，i＝1，2，3，4，5...根据消息模型，设定一个变量，此变量代表按照消息模型的参数来描述的一个实际的消息。为了以下描述方便，这里，给定变量名为MSG。

根据以上定义，在说明某个具体的呼叫事件时，可以用Connection[i]表示呼叫事件数组中第i个呼叫事件。说明某个呼叫事件的模型参数时，用Connection[i].xxx表示，说明某个消息的参数时，用MSG.yyy表示。这里，xxx代表呼叫事件模型的参数名称。如：Connection[i].SFN代表第i个呼叫事件的系统帧号。yyy代表消息模型的参数名称，如MSG.msgName代表该消息的消息名属性。下面详细描述主要步骤。

步骤1：向程序输入Abis口配置参数。建立基站号与Abis口上下行链路名称的对应关系基站号与Abis口上下行链路名称可以是一对多的关系。如下表所示：

    基站号    上行链路名称    下行链路名称    1    bts1_trx1_uplink    bts1_trx1_downlink    1    bts1_trx2_uplink    bts1_trx2_downlink    1    bts1_trx3_uplink    bts1_trx3_downlink    2    bts2_trx1_uplink    bts2_trx1_downlink

计算机根据如上表所示的数据，建立基站号与链路名称之间的对应关系数据库。这样，

根据Abis口的消息的链路名参数，就可以判断出此消息属于哪一个基站。

步骤2：从记录文件中读取下一条完整的消息(可包含多行内容)

在记录文件中，消息是按照顺序，一条一条存储的。本步骤的任务是，顺序的，从记录文件中，读取下一条消息。对于不同的记录文件的格式，有不同的方法实现。对于同一种记录文件的格式，也可能有多种方法实现。

通常的，在记录文件中，每一条消息都有一个起始的标志，或起始的特征。一个新消息的起始，就意味着前一个消息的结束。计算机可以根据这一特征，判断是否得到完整的消息。

步骤3：对此消息的内容进行参数扫描，按照消息模型的参数取出对应的消息内容。

每一条消息都至少包含消息模型定义的如下内容：消息名称(MessageName)，时间标记(TimeStamp)，链路名(LinkName)。对于消息模型定义的其他参数，每一条消息可能包含，也可能不包含。如果包含，就取出该参数。如果不包含，该参数就为空值。另外，每一条消息都包含了该消息使用的协议名称。根据不同接口使用的不同协议，就可以判断出该消息的消息接口名称(Interface)参数值。如果不同接口使用相同的协议，那么，就需要根据不同接口的链路名的不同来判断该消息的消息接口名称(Interface)参数值。在这种情况下，需要在计算机分析开始之前，向计算机输入每一接口的链路名与接口名之间的对应关系，类似于步骤1。

步骤4：如果该消息是Abis消息，根据该消息的链路名称，利用基站号与链路名称的对应关系，找出该消息所属的基站号。

步骤5：根据该消息的各项参数，利用同一个呼叫事件的各个消息之间的相关性，找出消息属于哪一次呼叫事件，并根据消息的参数，确定呼叫事件的参数。

同一个呼叫事件的不同消息间是有相关性的。在不同的系统里，相关性的表现是不同的。计算机根据这种相关性，判断某一条消息属于哪一个呼叫事件。

下面，以TD-SCDMA TSM标准为例，来描述这种相关性。

1)如果该消息名称是信道需求(Channel Required)，那么，这是一个呼叫事件中，基站向基站控制器发送的第一条消息。这意味着，一个新的呼叫事件已经开始。由此，计算机在呼叫事件的数组中，增加一个新的元素。在这里，记为Connection[i]，并且，设置此呼叫事件的以下参数。并且，设置此呼叫事件的如下参数：

Connection[i].SFN＝MSG.SFN

Connection[i].trxID＝Msg.trxID

Connection[i].AbisULLink＝MSG.LinkName

Connection[i].BTSNO＝MSG.BTSNO

Connection[i].FileName＝基站号.txt，这里，基站号是在步骤4中得到的这条消息的消息模型参数基站号码(BTSNO)的参数值。

Connection[i].ENDFlag＝False

2)如果该消息名称是信道激活(Channel Activation)，那么，如果该消息包含了系统帧号(SFN：System Frame Number)，那么，这条消息是基站控制器对前一条消息信道需求(Channel Required)的响应。在所有的呼叫事件中，如果某个呼叫事件同时满足如下条件：

Connection[i].SFN＝＝MSG.SFN  //呼叫事件的系统帧号等于该消息的系统帧号

Connection[i].BTSNO＝＝MSG.BTSNO  //呼叫事件的基站号等于该消息的基站号

Connection[i].trxID＝＝msg.trxID，  //呼叫事件的载频号等于该消息的载频号

Connection[i].ENDFlag＝＝false  那么，//呼叫事件的结束标志等于false，即，该呼叫事件还没有结束

那么，此消息属于呼叫事件Connection[i]。同时，设置如下参数：

Connection[i].RRID＝＝MSG.RRID                             //把该消息的

参数RRID赋给呼叫事件Connection[i]

Connection[i].AbisdownlinkName＝＝Msg.LinkName//把该消息的参数链路名

赋给呼叫事件Connection[i]下行链路名

如果该消息不包含系统帧号(SFN)，倡是，包含切换参考号(HOREF)，那么，这条消息是一个切换事件的第一条消息。在呼叫事件数组中，增加一条新元素Connection[i]，并且，设置此呼叫事件的以下参数：

Connection[i].HOREF＝MSG.HOREF

Connection[i].RRID＝MSG.RRID，Connection[i].trxID＝MSG.trxID

Connection[i].AbisUplinkName＝Msg.LinkName

Connection[i].ConnectionType＝”HO”Connection[i]

3)如果该消息名称是立即分配命令(Immediate Assignment CMD)或立即分配拒绝(Immediate Assignment Reject)，那么在所有的呼叫事件中，如果某个呼叫事件同时满足如下条件：

Connection[i].SFN＝＝MSG.SFN  //呼叫事件的系统帧号等于该消息的系统帧号

Connection[i].BTSNO＝＝MSG.BTSNO  //呼叫事件的基站号等于该消息的基站号

Connection[i].trxID＝＝msg.trxID，  //呼叫事件的载频号等于该消息的载频号

Connection[i].ENDFlag＝＝false  那么，//呼叫事件的结束标志等于false，即，该呼叫事件还没有结束

那么，此消息属于第i个呼叫事件。

4)如果该消息名称是Abis口消息位置更新请求(Location Update)或服务请求(CMService Request)或寻呼响应(Paging Response)那么在所有的呼叫事件中，如果某个呼叫事件同时满足如下条件：

Connection[i].BTSNO＝＝MSG.BTSNO //同一个基站

Connection[i].trxID＝＝msg.trxID //同一个载频

Connection[i].RRID＝＝MSG.RRID  //同一个无线资源连接

Connection[i].ENDFlag＝＝false

那么，此消息属于第i个呼叫事件。设者呼叫事件的参数：

Connection[i].IMSI＝MSG.IMSI

分别的，可以判断出此呼叫事件的类型：

Connection[i]＝LUP或MOC或MTC

5)如果该消息名称是A口消息Complete Lay3 Information(完整的3层消息)，那么，此消息中必然包含了下面消息当中的一个：

用户服务请求(CM SERVICE REQUEST)

位置更新请求(LOCATION UPDATING REQUEST)

IMSI解除绑定(IMSI DETACH)

寻呼响应(PAGING RESPONSE)

服务重新连接请求(CM RE-ESTABLISHMENT REQUEST)

通知响应(NOTIFICATION RESPONSE)

在所有的呼叫事件中，如果某个呼叫事件同时满足如下条件：

Connection[i].IMSI＝＝MSG.IMSI

Connection[i].EndFlag＝＝false

那么，此消息属于第i个呼叫事件。给此呼叫事件如下参数赋值：

Connection[i].BSCLocalRef＝MSG.SourceRef  //

6)如果该消息名称是A口消息位置更新接受(Location Update Accept)或位置更新拒绝(Location Update Reject)，或服务接受(CM Service Accept)或服务拒绝(CM Service Reject)或身份请求(Identiy Request)等，那么在所有的呼叫事件中，如果某个呼叫事件同时满足如下条件：

Connection[i].BSCLocalRef＝＝MSG.DestRef

Connection[i].EndFlag＝＝false

那么，此消息属于第i个呼叫事件。给此呼叫事件如下参数赋值

Connection[i].MSCLocalRef＝MSG.SourceRef

7)如果该消息是射频信道释放证实(RF Channel Release Acknowledge)，么，那么在所有的呼叫事件中，如果某个呼叫事件满足如下条件：

Connection[i].BTSNO＝＝MSG.BTSNO //同一个基站

Connection[i].trxID＝＝msg.trxID //同一个载频

Connection[i].RRID＝＝MSG.RRID //同一个无线资源连接

Connection[i].ENDFlag＝＝false //该呼叫事件还没有结束

那么，此消息属于第i个呼叫事件。给此呼叫事件如下参数赋值

Connection[i].AbisEndFlag＝TRUE //Abis口释放完毕

8)如果该消息是A口消息释放完成(Release Complete)，那么在所有的呼叫事件中，如果某个呼叫事件满足如下条件：

Connection[i].BSCLocalRef              ＝MSG.DestRef              或

Connection[i].MSCLocalRef＝Msg.DestRef //这两个条件之一

并且同时Connection[i].EndFlag＝＝false

那么，此消息属于第i个呼叫事件。给此呼叫事件如下参数赋值

Connection[i].AintEndFlag＝TRUE

9)如果该消息名称是A口其它消息，那么在所有的呼叫事件中，如果某个呼叫事件满足如下条件：

Connection[i].BSCLocalRef              ＝MSG.DestRef             或

Connection[i].MSCLocalRef＝Msg.DestRef //这两个条件之一

并且同时Connection[i].EndFlag＝＝false

那么，此消息属于第i个呼叫事件。

否则，此消息不属于任何呼叫事件。

10)如果该消息名称是Abis口其它消息，那么，那么在所有的呼叫事件中，如果某个呼叫事件同时满足如下条件：

Connection[i].BTSNO＝＝MSG.BTSNO//同一个基站

Connection[i].trxID＝＝msg.trxID//同一个载频

Connection[i].RRID＝＝MSG.RRID//同一个无线资源连接

Connection[i].ENDFlag＝＝false//该呼叫事件还没有结束

那么，此消息属于第i个呼叫事件。给此呼叫事件如下参数赋值

否则，此消息不属于任何呼叫事件。

11)如果该消息属于第i个呼叫事件：Connection[i]，那么，此呼叫事件的参数消息名称集合，消息时间标记集合，消息位置集合各增加一个新元素，赋值如下：

Connection[i].Messages[j]＝MSG.MsgName

Connection[i].MsgTimeStamps[j]＝MSG.TimeStamp

BTS_Received_Message[x]＝BTS_Received_Message[x]+1 //消息计数器增1

Connection[i].LineNO[j]＝BTS_Received_Message[x] //记录该消息在流程

图中的行位置

12)如果该消息属于第i个呼叫事件：Connection[i]，那么判断该消息是否是属于正常呼叫模型当中的消息。判断方法为：

该消息的名称被包含在正常呼叫模型的名称集合当中，并且，该消息没有包含原因参数(CauseValue)，即，原因参数为空，或者，该消息包含了原因参数(CauseValue)，但该原因参数(CauseValue)值也包含在正常呼叫模型的原因集合当中，那么，此消息就是正常消息。

如果不满足上述条件，则为非正常消息。这就意味着，该消息所属的呼叫事件非正常。那么，对该呼叫事件的如下参数赋值：

Connection[i].ErrorEvent＝MSG.MsgName//把该消息的名称赋给呼叫事件的呼叫错误事件参数。对于发生多个错误事件的情况，应该考虑，在呼叫错误事件参数上叠加新的值。

Connection[i].ErrorCause＝MSG.CauseValue

步骤6：将此消息输出到其所属于的呼叫事件的单独的文件中。

根据此消息所属的呼叫事件的参数：文件名(FileName)，把该消息附加到相应的文件末尾。

步骤7：把呼叫事件的各项参数输出到信息摘要表中。

按照摘要信息表的结构，输出相应的呼叫事件参数到表中

步骤8：根据每一个呼叫事件的参数，按照该呼叫事件的基站号，在相应的流程图中，画出流程图。

按照流程图模型的结构，在流程图中输出相应的信息。呼叫事件模型的参数消息名称集合(Messages[])记录了此呼叫事件的所有消息名称。对应的该消息的时间标记记录在消息时间标记集合(MsgTimeStamps[])中。而对应的该消息在流程图中的行位置记录在消息位置集合(LineNO[])中。因此，根据行位置，在流程图中的相应行数输出相应的参数，并且在该消息名下面画一条横线。

下面的图7为流程图模型输出的一个实际例子。