CN103973519A - 一种基于pc平台的交换中心仿真测试系统 - Google Patents

Abstract

本发明涉及一种基于PC平台的交换中心仿真测试系统，系统由心跳发送模块、人机交互模块、基站信息上报模块、信令接收和处理模块构成；心跳发送模块主要责任是在该系统与MSC建立socket网络连接之后确保BSC与MSC的网络连接正常；人机交互模块主要负责接收用户输入的信令信息，也对信令接收处理模块需要回发的信令做出响应，经由socket发送给MSC，由MSC进行处理；利用MFC框架中的按钮控件对BSC-MSC中原本无法打破的信令交互流程进行了拆分，从而达到单步发送调试的目的，利用文本控件对信令中的一些参数进行手动的设置，以达到理想条件，从而方便进行极端环境的测试。

Description

一种基于PC平台的交换中心仿真测试系统

技术领域

本发明涉及PDT基站(BSC(Base Station Controller))与交换中心(MSC)的信令交互与数据采集设备，特别涉及一种基于PC平台的交换中心仿真测试系统，用于为PDT提供多BSC--单MSC单步调试的仿真测试环境。

技术背景

现实环境下的BSC和MSC都是基于linux系统平台shell命令行的c程序开发的。在linux下最常用的程序调试手段是GDB（GNU Debugger），GDB是一种基于shell命令行的程序调试工具，所有对于程序的调试操作，包括设置断点，单步运行，子函数的跳入执行，都是基于shell命令的操作，其查看源码的方式也只是简单的在shell上打印出一段代码，这与windows上众所周知的集成开发工具（例如vc++ 6.0）的调试工具相比，缺乏有好的交互界面和强大的源码查看功能。这会给程序的调试带来不便。

此外，现实环境下的PDT-BSC和PDT-MSC的运行流程都是完整的基于TCP的网络信令交互流程，为了确定BSC，MSC之间是否处于连接状态，BSC会定期向MSC发送心跳帧，MSC也做出相应的应答，如果BSC和MSC其中有一方长时间未能发出心跳包的话，其中一方会断开网络。因此如果在其中的某个地方设置断点中断其运行的话，势必会影响以上心跳信令的发送或者接收，导致网络断开。因此，很难通过对程序的完整流程进行打断，单独对某些信令进行源码级别的调试。

实际的BSC-MSC交互流程都是按照正常的流程实现的，某些测试实际环境实现比较困难，某些极端的异常状况即使在高强度的压力测试当中也无法出现，例如信道忙排队的测试，必须在BSC信道满负荷的条件下才能测试，在实际使和测试当中，每次实现BSC信道满负荷需要一定的时间，而在前期测试中，MSC程序可能会存在较多其他的Bug，这样导致大部分的调试时间浪费在了实现BSC满信道负荷条件上了。

为了选择性的实现某些功能，满足压力测试的要求，同时也需要考虑真实现局域网内以及跨网络的环境中存在的网络延时。需要开发一种能够手动设置相关参数、并手动对其单步流程进行发送的模拟程序的方法。然而基于命令行的c程序想实现这一功能明显力不从心。

发明内容

基于以上技术现状，本文发明的目的是提供一种基于PC平台的交换中心仿真测试系统，以windows xp系统vc++6.0开发环境下的MFC为基础制作基于对话框的仿真模拟系统（仿真测试系统），对PDT-BSC与PDT-MSC的交互信令的收发进行模拟，并通过手动设置一些参数。从而模拟一些极端环境，尽可能为达到测试需要的状态提供方便。提高调试效率。

本发明为实现上述所述目的采用的技术方案是：基于PC平台的交换中心仿真测试系统，其特征在于，系统由心跳发送模块、人机交互模块、基站信息上报模块、信令接收和处理模块构成；

所述心跳发送模块主要责任是在该系统与MSC建立socket网络连接之后确保BSC与MSC的网络连接正常；

所述人机交互模块主要负责接收用户输入的信令信息，也对信令接收处理模块需要回发的信令做出响应，经由socket发送给MSC，由MSC进行处理；

所述基站信息上报模块对BSC的基本信息以定时器的方式进行周期上报；

所述信令接收处理模块接收MSC下发的信令，并根据相关协议的内容判断是否要进行回发，如果需要手动回发，则通知人机交互界面；

所述系统采用一种多线程的框架来实现BSC-MSC仿真调试，并且采用多PC同时与MSC进行联机的方式进行网内与跨网络的仿真模拟已达到模拟真身网络延时的目的；

通过信令接收处理模块，实现MSC-BSC的信令交互，具体过程为：

1) MSC对收到的BSC信令做出响应；

2) BSC通过socket接收MSC应答信令，并按照约定的格式进行拆包；

3) BSC根据协议内容进行分类处理，如果需要手动回复则弹出对话框进行数据编辑，然后回复MSC，否则以默认的方式直接回复MSC；

通过人机交互模块建立连接、移动台位置的更新、单呼、组呼；

通过心跳发送模块来确认socket网路连接处于连通状态，BSC定期发送心跳包，MSC进行相应的回复，从而保证BSC-MSC双方都保持在线状态；

通过信道机信息上报模块上报的基本信息，在该模块中启动定时器，周期性的发送信道机的一些基本参数，主要包括该信道机的色码，温度，信号强度，发射功率，信道占用情况信息。

利用所述基于PC平台的交换中心仿真测试系统进行仿真测试的方法包括如下步骤：

步骤1、模拟真实环境中MSC与BSC一对多的关系:

采用多台PC联网的方式与MSC进行连接，对于每台PC，需要做如下准备操作：

a) 设置IP地址，将多台PC通过路由器连接到同一局域网中，考虑到真实环境中的网络延时，将若干台PC连接到外网当中；

b) 对每台信道机的参数进行设置，通过设置色码以区分不同的信道机，信道机的发射频率，发射功率；

步骤2、针对BSC-MSC信令交互的功能需求通过人机交互界面进行测试：

功能包括建立连接，移动台位置更新，组呼的建立、结束，单呼摘机、单呼不摘机、单呼结束，短消息上拉、发送、越区切换；

以上功能相应的信令通过人机交互模块生成，经由socket发送给MSC，MSC对信令进行处理之后将应答信令回发给BSC的接收处理模块，经由接收模块处理之后将相应的调试信息以及信令内容打印在屏幕上以便观察；如需要BSC回复应答信令则接收模块调用人机交互模块，进行相关信令的手动发送；

步骤3、所有发送和接收到的信令以日志的形式记录在文件当中，以便于集中分析解决问题，具体日志的格式描述如下：

表 1 接收信息记录格式

时间戳：帧的存储方式为小端，即低地址存放低字节，通过时间戳来记录数据发送或接收的时间，T1~T3为单字节，分别表示时，分，秒，时间戳精确到毫秒，T4为无符号短整型数据，双字节；

状态：状态S为1字节，来表征当前数据帧的状态，即正常或者异常，如果是异常的话在主对话框中做相应的高亮显示；

数据长度：表名了数据内容的长度；

CRC码：为了验证数据内容的完整性和正确性，需要对数据内容进行循环冗余校验。

本发明所产生的有益效果是：利用MFC框架中的按钮控件对BSC-MSC中原本无法打破的信令交互流程进行了拆分，从而达到单步发送调试的目的；在主对话框中添加了对于发送和接收的信令的信息提示，并且以十六进制字节码的形式对信令进行了显示，以日志的形式将该字节序列保存到文件中，以便查以后查看分析。利用文本控件对信令中的一些参数进行手动的设置，以达到理想条件，从而方便进行极端环境的测试。

附图说明

图1是系统工作模块示意图；

图2是仿真测试系统结构图；

图3是基站信息上报模块工作流程图；

图4是信令交互线程工作流程图；

图5是本发明主对话框工作流程图。

具体实施方式

为了更清楚的理解本发明，结合附图和实施例详细描述本发明：

如图1至图5所示，本发明为了模拟真实环境中MSC与BSC一对多的关系，需采用多台PC联网的方式与MSC进行连接，通过图1与图2的对比可以看出，PC仿真软件中包含了对信道机的注册功能以及对BSC的模拟。

对于每台PC，我们需要做如下准备操作：

c) 设置IP地址，可以将多台PC通过路由器连接到同一局域网中，考虑到真实环境中的网络延时，可以将一些PC连接到外网当中。

d) 在本发明的软件中对每台信道机的参数进行设置，例如设置色码以区分不同的信道机，信道机的发射频率，发射功率。

本系统既可以满足最基本的功能测试与数据采集，同时为了满足实际测试要求，为了贴近真实的使用环境，需要对PC的信令进行高频率的大量的发送以满足随机性以及压力测试的要求，同时为了再现一些异常情况，需要对PC机软件的环境进行预先的设置。

在这些准备工作之后，便可以进行测试了。

在本发明实际使用过程中需要将所有发送和接收到的信令以日志的形式记录在文件当中，以便于集中分析解决问题。如果在模拟测试当中出现了一些关键性的错误，会将这些错误高亮显示在主对话框中，并且在日志当中进行特别标注，具体日志的格式描述如下表：

表 1 模拟SCTP信令格式

说明：

1. 时间戳：帧的存储方式为小端（低地址存放低字节），通过时间戳来记录数据发送或接收的时间。T1~T3为单字节，分别表示时，分，秒，时间戳精确到毫秒，用T4因此T4为无符号短整型数据（双字节）。

2. 状态：状态S（1字节）用来表征当前数据帧的状态（正常或者异常）。如果是异常的话在主对话框中也会做相应的高亮显示。

3. 数据长度：表名了数据内容的长度。

4. CRC码：为了验证数据内容的完整性和正确性，需要对数据内容进行循环冗余校验。

关于本发明采用的网络传输协议的说明：

现实当中MSC和BSC之间采用流控制传输协议（SCTP），与TCP相比，SCTP是一种可以多宿主的连接，TCP是一种面向单地址的连接。SCTP的建立流程中，客户端和服务器双方均可声明若干IP地址（IPv4，IPv6）将这些地址通知给对方。如果当前连接失效，则协议自动用另外一个地址进行切换，并不像TCP那样需要建立新连接。遗憾的是，在同一局域网中，多台机器的IP地址如果相同则会出现IP地址冲突，所以每台PC只能模拟一台BSC，在MFC中也并没有对SCTP进行封装，因此，这里采用TCP-IP协议来代替SCTP协议。

为兼容基站内部CCL与DLL间的数据格式，采用与之相同的信令格式定义如下：

表 2 模拟SCTP信令格式

由于SCTP本身采用数据包形式发送数据，因而数据格式中不再包含数据校验字节。

数据包以字节为单位。

数据长度是指数据内容的长度，不包括本身所占的2字节，数据类型的1字节以及时间

戳的4字节（即套接字接收到的字节个数-9）。

时间戳为32bit，T1～T4由高到低排列。由于TCP提供可靠地连接，因此时间戳已经不再必要，此时间戳仅作为方便调试用。

该程序由两个部分组成，主对话框和服务线程。

主对话框实现了BSC对MSC的信令发送以及关键数据的采集发送，对话框中实现了BSC-MSC的一些常规功能的完整发送，并且可以将这些功能分步发送，分步接收，并且可以手动设置打断环节的一些参数，从而更好的模拟现实环境中难以测试到的一些临界情况和极端情况，并且将需要发送的信息在打包之前保存到日志文件中以便于日后的查看，同时将该信息以十六进制的形式显示在主对话中。

程序当中总共创建了3个线程。

滴一个线程用来处理MSC对BSC信令所回发的应答信令，并且将该信令拆包解析，如果收到的信令要求BSC做出应答，则BSC根据收到的内容进行选择性的应答，同时将最终内容以十六进制的形式显示在主对话框中，并且以日志的形式保存在文件中。

第二个线程实现了网络连接的初始化工作，心跳包的定期发送和接收

第三个线程定期对本信道机的信息进行上报，其中包括了当前信道的相关信息比如正在发起的信息，信道机的温度，信号强度，功率。

BSC与MSC交互的主要功能包括以下几个方面：

连接的建立：

BSC启动之后，定时向MSC发送连接申请，直到MSC启动就绪，此时双方知连接已建立。BSC向MSC发送携带自身的信道配置信息的信令。MSC向BSC回应信令，设置各项业务参数。

移动台位置更新：

BSC收到MS的登记请求之后，向MSC发送移动台位置更新信令。MSC收到该信令后，记录MS相关信息，判断是否允许该MS入网（HLR、VLR），向BSC返回应答信令。

组呼的建立过程：

组呼采用先期分配信道方式。BSC收到组呼建立请求，先为其分配好业务信道（若无空闲业务信道，则直接因系统忙拒绝），向MSC发送组呼叫建立信令，携带分配信道信息，以及申请建立识别号。

MSC收到该信令后，判断呼叫是否合法，向主叫BSC发送组户应答信令，其中携带唯一的呼叫识别号，同时向其他被叫BSC发送组呼建立通知信令。主叫BSC自动完成之后的组呼建立流程。被叫BSC收到信令后，为新业务分配信道，将分配信道的信息通过组呼叫连接信令返回给MSC，并自动完成剩下的建立流程。

组呼叫的结束流程：

主叫BSC收到组呼结束的语音等待超时信令时，转换成上行呼叫维护格式的信令，发送到MSC，MSC判断是否合法，若合法，则像所有涉及的BSC发送组呼叫清除信令。BSC自动完成信道结束呼叫，以及信道释放的过程。

单呼摘机过程

BSC收到MS单呼请求信令时，向MSC发送呼叫建立请求，携带为该单呼分配的信道信息。MSC收到呼叫建立请求，判断是否可以发起呼叫，若允许，则向被叫侧BSC发送呼叫通知信令。被叫侧收到MS的ACKU应答，向MSC发送呼叫建立信令。MSC收到呼叫建立信令后，向主叫侧BSC发送应答。

单呼不摘机：

BSC收到MS单呼请求信令时，向MSC发送呼叫建立信令，携带为该单呼分配的信道信息。MSC收到呼叫建立请求，判断是否可以发起呼叫，若允许，则向被叫侧BSC发送通知信令。被叫侧BSC收到MS的ACKU应答，向MSC发送呼叫建立（arc=MS_ALT）表示被叫振铃，或发送呼叫建立表示被叫不在线。

MSC向主叫侧BSC发送呼叫应答（arc=MS_ALT）表示被叫振铃，或结束呼叫。

被叫侧BSC收到MS的振铃应答，向MSC发送呼叫连接，若被叫摘机（arc=TS_MA）则该信令中携带分配信道信息。MSC向主叫侧BSC发送呼叫应答，建立或结束呼叫。

单呼结束流程：

主叫侧BSC收到MS授权/释放申请，向MSC发送上行呼叫维护信令。MSC收到CALL_MAINT信令后，判断是否授权给该MS，向主/被叫侧发送下行信令。

短消息上拉

主叫侧BSC收到主叫MS的短消息上拉申请，发给MSC判别主、被叫MS是否合法。

若不合法，则MSC向主叫侧BSC发送短消息应答拒绝。若判断合法，则MSC向被叫侧BSC发送短消息查询，让其发送短消息。被叫侧基站收到被叫MS的短消息之后，向MSC发送SD_MSG_UP携带MS的短消息。MSC向主叫侧发送短消息下拉携带上拉的短消息内容。

短消息发送：

主叫侧BSC收到主叫MS的短消息发送申请，向MSC发送短消息建立，由MSC判断是否合法。MSC向主叫侧BSC发送判断结果。若合法，主叫侧BSC向MSC发送上行短消息内容携带短消息内容。MSC向被叫侧BSC发送下行短消息内容携带短消息内容。被叫侧BSC向MSC发送上行收信方应答携带应答内容MSC向主叫侧BSC发送下行消息方应答给主叫MS应答。

越区切换：

主叫侧BSC收到主叫MS的状态短消息发送申请，向MSC发送短消息申请，由MSC判断是否合法。若不合法，则MSC向主叫侧BSC发送短消息应答拒绝。若合法，则MSC向被叫侧BSC发送短消息查询，携带状态短信内容。被叫侧BSC 向MSC发送上行短消息内容携带被叫MS应答内容。MSC向主叫侧BSC发送下行短消息内容通知主叫MS应答。

根据上述说明，结合本领域技术可实现本发明的方案。

Claims (2)

1.基于PC平台的交换中心仿真测试系统，其特征在于，系统由心跳发送模块、人机交互模块、基站信息上报模块、信令接收和处理模块构成；

所述心跳发送模块主要责任是在该系统与MSC建立socket网络连接之后确保BSC与MSC的网络连接正常；

所述人机交互模块主要负责接收用户输入的信令信息，也对信令接收处理模块需要回发的信令做出响应，经由socket发送给MSC，由MSC进行处理；

所述基站信息上报模块对BSC的基本信息以定时器的方式进行周期上报；

所述信令接收处理模块接收MSC下发的信令，并根据相关协议的内容判断是否要进行回发，如果需要手动回发，则通知人机交互界面；

所述系统采用一种多线程的框架来实现BSC-MSC仿真调试，并且采用多PC同时与MSC进行联机的方式进行网内与跨网络的仿真模拟已达到模拟真身网络延时的目的；

通过信令接收处理模块，实现MSC-BSC的信令交互，具体过程为：

MSC对收到的BSC信令做出响应；

BSC通过socket接收MSC应答信令，并按照约定的格式进行拆包；

BSC根据协议内容进行分类处理，如果需要手动回复则弹出对话框进行数据编辑，然后回复MSC，否则以默认的方式直接回复MSC；

通过人机交互模块建立连接、移动台位置的更新、单呼、组呼；

通过心跳发送模块来确认socket网路连接处于连通状态，BSC定期发送心跳包，MSC进行相应的回复，从而保证BSC-MSC双方都保持在线状态；

通过信道机信息上报模块上报的基本信息，在该模块中启动定时器，周期性的发送信道机的一些基本参数，主要包括该信道机的色码，温度，信号强度，发射功率，信道占用情况信息。

2.利用权利要求1所述基于PC平台的交换中心仿真测试系统进行仿真测试的方法包括如下步骤：

步骤1、模拟真实环境中MSC与BSC一对多的关系:

采用多台PC联网的方式与MSC进行连接，对于每台PC，需要做如下准备操作：

设置IP地址，将多台PC通过路由器连接到同一局域网中，考虑到真实环境中的网络延时，将若干台PC连接到外网当中；

对每台信道机的参数进行设置，通过设置色码以区分不同的信道机，信道机的发射频率，发射功率；

步骤2、针对BSC-MSC信令交互的功能需求通过人机交互界面进行测试：

功能包括建立连接，移动台位置更新，组呼的建立、结束，单呼摘机、单呼不摘机、单呼结束，短消息上拉、发送、越区切换；

以上功能相应的信令通过人机交互模块生成，经由socket发送给MSC，MSC对信令进行处理之后将应答信令回发给BSC的接收处理模块，经由接收模块处理之后将相应的调试信息以及信令内容打印在屏幕上以便观察；如需要BSC回复应答信令则接收模块调用人机交互模块，进行相关信令的手动发送；

步骤3、所有发送和接收到的信令以日志的形式记录在文件当中，以便于集中分析解决问题，具体日志的格式描述如下：

表 1 接收信息记录格式

时间戳：帧的存储方式为小端，即低地址存放低字节，通过时间戳来记录数据发送或接收的时间，T1~T3为单字节，分别表示时，分，秒，时间戳精确到毫秒，T4为无符号短整型数据，双字节；

状态：状态S为1字节，来表征当前数据帧的状态，即正常或者异常，如果是异常的话在主对话框中做相应的高亮显示；

数据长度：表名了数据内容的长度；

CRC码：为了验证数据内容的完整性和正确性，需要对数据内容进行循环冗余校验。