NGN网络监测系统中BICC协议的研究与应用*

李丹凤，张治中

（重庆邮电大学通信网与测试技术重点试验室 重庆 400065）

1 引言

随着internet网络的飞速发展、基于IP网络的各种业务的快速增长以及网络用户数量的日益剧增，TDM网络在交换和传输容量上出现了严重不足[1]。为了在短期内解决容量问题并兼顾未来网络的发展，ITU-T提出了BICC（bearer independent call control，与承载无关的呼叫控制）协议。它由ISUP演进而来，重新定义了一个在骨干网络中实现业务承载与呼叫控制无关的协议，这样呼叫控制信令就可以承载于SS7、ATM、IP等多种网络[2]。BICC协议的研究与应用是NGN网络监测系统中最重要的部分之一。本文在认真解读BICC协议规范的基础上，根据协议测试规范[3]要求，提出以一种高效散列索引算法和CDR（呼叫详细记录）选择存储的方式对消息进行CDR合成，本方案已经过大量现网数据的测试验证，具有更好的实时性、准确性、稳定性、可移植性和可扩展性，对NGN网络监测系统中其他协议的研究具有重大的指导和推广意义。

2 BICC协议概述

2.1 BICC协议的特点

BICC协议定义了信令传送转换器（STC）、应用传送机制（APM）、承载控制隧道协议（BCTP）和IP承载控制协议（IPBCP），通过点编码建立信令联系，信令链路通过静态SCTP连接，BICC节点采用正常呼叫的选路原则选定路由，为呼叫的信令建立通路[4]。BICC利用分层、独立的结构体系思想，真正实现了呼叫控制和承载控制的分离，呼叫控制协议基于N-ISUP信令，沿用ISUP中的相关信息，利用新增的 APM（application transport mechanism）传送 BICC特定的承载控制信息，所以BICC可以承载全方位的PSTN/ISDN业务，对于不同承载网络之间的业务互通，只需要完成承载级的互通，业务级则不用进行任何修改。BICC协议的一个显著特点是直接面向电话业务的应用，来自传统的电信网，体系架构更加严谨，因此能透明地在NGN中实施现有基于电路交换的电话网络中的业务，并采用和现有网络相似的管理方式保持现有网络的功能不变。

2.2 BICC消息和参数的报文格式

BICC消息的每个PDU均由8 bit的整数倍组成，包含CIC（呼叫实例码）、消息类型码、必备固定部分、必备可变部分、任选部分（包含长度固定或可变的参数字段）5个部分[5]。BICC消息的简单结构如图1所示。

其中，CIC、消息类型码、必备固定部分是每条BICC消息都具有的。CIC占4 byte、32 bit，用来识别两个对等BICC实体间的一个信令关系；消息类型码占1 byte、8 bit，唯一定义了每个BICC消息PDU的功能和格式；必备固定部分属于BICC消息的参数部分，每个参数有一个专有名字，按8位位组编码。参数的长度可以是固定的，也可以是可变的，每个参数可包括一个长度指示语，长度也是占1 byte的8位位组。对于一个指定的消息类型，必备固定部分包括必备且长度固定的参数，参数的位置、长度和顺序唯一地由消息类型规定，因此消息中不包括这些参数的名字和长度指示语。

3 消息的基础解码

消息数据的基础解码是进行CDR合成的基础，是监测系统界面消息列表显示、消息过滤、统计分析、呼叫追踪等基础应用的前提。基础解码为合成散列表提供索引Key值，如 OPC、DPC（源、目的信令点）、CIC、SrcIP、DstIP（源目的 IP地址），其中 SrcIP、DstIP和 OPC、DPC分别由 BICC下层承载的IP层和SCTP（或者M3UA）层提供，还有CDR过程中所需的一些KPI指标，如m_Msg Type Code、m_Calling Number、m_Called Number等信息。

存放基础解码结果的结构体代码如下：

typedef struct_summary_bicc_result

{

uint32 m_uCIC;//CIC呼叫实例码

int8 m_MsgTypeCode;//BICC消息类型

TCHAR m_CallingNumber[52];//主叫号码

TCHAR m_CalledNumber[52];//被叫号码

TCHAR m_SubNumber[52];//后继号码

…

};

由于监测系统要求实时、准确、高效、独立地对网络进行监控，所以NGN监测系统的解码器部分采用注册字段的方式进行数据传输，这样既降低了与合成模块的耦合度，又减小了对内存的消耗。所有的解码结果字段注册在内存注册表pSheet中，代码实现如下：

REGISTER_SHEET_ITEM(gchBICCItem[BICC_CIC],NORMAL_USE,

CYDD_DT_UINT32,4,NULL,NULL);//申明注册字段，不占内存

CYDD_VERIFY (GetItemRef(m_chProtocolName,gch BICCItem[BICC_CIC],m_ref[BICC_CIC])==0);

在解码器的Parse合成方法中，用解码提取结果为注册表中的参数设置字段值：

SET_SHEET_VALUE(pSheet,m_ref[BICC_CIC],CYDD_DT_UINT32,

&(result->m_uCIC)); //设置字段值

在合成模块Analyzer中，通过Register方法中的GetItemRef函数取出BICC协议中CIC注册字段对应的ITEMREF值：

GetItemRef ("BICC", gchBICCItem [BICC_CIC],m_refBICC[BICC_CIC]);//取 ITEMREF 值

再通过BuildCallInfo方法，根据字段注册的名称从注册表中直接获取解码结果：

GET_SHEET_VALUE(pSheet,m_refBICC[BICC_CIC],&(m_BiccCallInfo.CIC),bValid);//获取字段值

BICC消息列表的解码器界面显示结果如图2所示。

4 BICC的合成技术

对消息进行CDR合成的实质就是对消息进行呼叫流程归类和存盘处理。由于同一时刻可能存在成千上万甚至十多万个未完成的呼叫，每一个新消息到来时，都要迅速判别它属于哪个未完成的呼叫流程，并将其加入所属流程以保证用户的话音质量。这就需要在合成过程中处理与保存CDR信息，并对所有未完成的呼叫进行所属CDR的快速搜索[6]。

4.1 BICC的CDR合成框架

NGN监测系统以实时处理为核心，以通过模块化的方式降低协议间的合成耦合度为前提，以分布采集、集中分析的方式实现对网络网元及接口的综合监测。BICC协议的监测架构分为数据采集模块、基础解码模块、解码器模块、消息合成模块、CDR存储模块5部分。本方案创新性地提出选择性保存CDR信息的方法：存盘和不存盘，此创新点减小了内存的消耗，提升了系统的处理速度，保证了网络监测的实时、准确和有效性。同时在本方案中会为每个CDR分配唯一ID，将散列技术的Key值索引、CDR ID作为映射的数据结构管理模式[7]，提高了网络通话忙时对海量呼叫的有效处理速度，保证了用户通话的流畅。

4.2 BICC的CDR合成实现

（1）合成算法设计

本方案采取的合成算法流程如下。

首先为CDR合成建立一张散列表，采用除余留数法定义散列函数：

采用线性探查法解决散列冲突：假设e为发生冲突的地址，依次探查e的下一个地址(当到达下标为m-1的散列表尾时，下一个探查的地址是表首地址0)，直到找到空闲单位为止。线性探查法的数学递推式为：

（2）存储能力算法

解码形成CDR后，将原始信令消息、CDR记录、统计结果数据存入专用服务器。一般原始消息的保存周期要求为15～30天，CDR记录要求保存90天，统计结果要求保存1年。以此为依据，设监测系统覆盖范围内的用户忙时每秒钟产生的CDR总数为CDR_SUM个，平均每个CDR的长度为M byte，忙时集中系数为l。每天CDR存储需要占用的字节数量用CDR_SC表示，则有：

当 CDR_SUM=6 400、M=150、l=0.1时，每天监测 CDR存储所需的字节数为：

设存储N天CDR所需的字节数为N，则有：

在CDR缓存模块中，既保留CDR信息的存盘方式，又独创重建一张HashBusf表来储存CDR信息的方式。两种方式的选择是通过预编译宏来实现的，具体实现代码如下：

CHashBuf m_HashsdBiccKey;//新建HashBuf存储表

#ifdef BICC_SAVE_DISK

if(0==m_pWriteCDRBuf->GetCDR(cdrID,&cdr,nLength))//存盘方式

#else

if(0==m_HashsdBiccKey.GetCDR(cdrID,cdr))//用散列存储方式

#endif

CDR合成算法的流程如图3所示，具体介绍如下。

（1）从现网采集数据，提取出BICC消息，递交给基础解码模块。

（2）基础解码模块对消息数据分别进行详细解码和简单解码，通过简单解码提取出界面显示和合成所需要的关键信息。

（3）解码器注册协议和简单解码提取关键字段。

（4）解码完成，启动合成Parse模块，从注册表中读取关键字段，生成CDR合成所需要的呼叫信息。

（5）进行超时检测，避免使系统发生越来越不稳定甚至崩溃的现象，再根据BiccCallInfo传送过来的关键信息建立该散列索引的关键Key值。

（6）判断选择何种Key值作为散列索引。如果OPC、DPC不为空，则用CIC、OPC、DPC的Key值组合在合成缓冲区中搜索相关关键字的节点是否存在，否则就采用CIC、SrcIP、DstIP的Key值组合作为索引，存在就转至步骤（7），不存在就转至步骤（8）。

（7）根据消息类型（呼叫信息中），调用不同的消息处理模块进行处理；修改CDR属性信息、SDP信息并保存消息ID，然后判断该消息是否为CDR结束消息，若该消息包含结束指示，则从缓存区中移除Key，然后结束合成，否则修改状态指示并将CDR以存盘和散列存储两种方式放回缓存区。

（8）判断是否为起始IAM消息，若是就在散列表中创建一个CDR节点，指派唯一ID，修改新CDR属性值，将CDR以存盘和散列存储两种方式放回缓存区，否则返回。

在BICC的解码合成方案中，不仅改良了通用的研究方法，采用偶合度更小的注册表方式存储关键消息，同时利用模块化设计定义公共接口，以集中处理的方式实现各子模块间的互通，提高代码的重用性，还创新性地提出了选择性存储CDR的方式，为内存减负，提升整个系统运维的速度。

5 实时数据验证结果

此研究方案已应用到中天重邮通信技术公司的NGN监测系统中，部署于中国移动通信集团甘肃有限公司的话音质量监测系统中，取得了良好的效果。BICC消息的CDR合成结果如图4所示。

6 结束语

通过对NGN集中监测系统架构和BICC协议的分析和研究，笔者提出了一种符合测试规范要求，同时也满足运营商网络监测需要的BICC协议监测模块的研究应用方案。该方法的创新点在于：采用了注册表方式存储BICC关键信息和选择性存储CDR的新方法，利用高效散列索引有效解决了合成的难题。该方案已应用到运营商的现网监测中，测试效果良好，验证了该方案的稳定、有效和可靠性。

1 姚平香,季红军,万晓榆.支持PSTN向NGN演进的协议——BICC.重庆邮电大学学报（自然科学版），2004,16(6)

2 中国电信DC1软交换信令监测系统项目测试功能规范书,2010

3 Xu Li,Zheng Baoyu.Application and development of mobile agentin AN.JournalofChinaUniversitiesofPostsand Telecommunications,2004,11(1)

4 YD/T 1193.1.与承载无关的呼叫控制（BICC）规范——第一部分：BICC的功能,2002

5 YD/T 1193.1.与承载无关的呼叫控制（BICC）规范——第二部分：BICC的消息、参数的基本功能和格式,2002

6 夏鞑,雒江涛,张治中.TD-SCDMA测试仪中Iub接口CDR的合成方案.重庆邮电大学学报,2007(3)

7 陈玉花,张治中,左书川等.TD-SCDMA网络Iu-PS接口CDR合成方案研究.电信科学,2009,25(11)