面向下一代网络的智能网技术改进研究

admin

摘要  本文介绍了智能网技术在NGN中的一种应用改进模型，描述了基于该模型的原型系统实现方案，并给出了其性能测试结果。
1、引言
    在传统智能网（IN）的封闭式体系架构下，业务的生成和提供只能由运营商完成，从技术上阻碍了电信服务业开放的进程，逐渐背离了下一代网络（NGN）业务提供模式的发展方向。因此，在整个电信网逐步过渡到NGN的大趋势下，IN技术面临着如何演进的问题。
    可以预见的是，由于现有IN系统的大规模应用以及技术上的成熟性，在相当长的一段时间内是不可能被替换掉的。传统IN技术如何适应NGN的需求，或者说，如何有效地改造现有IN系统，使其最佳地融合在NGN中，继续发挥作用，是一个亟待解决的问题。本文介绍了IN技术在NGN中的一种应用改进模型，描述了基于该模型的原型系统实现方案，并给出了性能测试结果。
2、面向NGN的IN改进模型
    基于IN的业务提供是NGN的主要业务提供模式之一。无论是软交换系统，还是IP多媒体子系统（IMS）都提出了以互通方式接入IN业务控制点（SCP）来平滑继承现有IN业务的基本业务提供模式。
    以软交换系统为例。在互通模式下，智能业务仍旧由传统IN系统的业务控制点来提供，软交换设备仿真IN业务交换功能（SSF），提供智能业务的触发功能，通过信令网关访问SCP的业务能力，并接受SCP对智能呼叫的控制，为软交换用户提供现网智能业务，如图1所示，其中SG为信令网关，MG为媒体网关，SSP为业务交换点。

图1　软交换系统与SCP的互通

    这种互通模式尽管继承了传统IN的业务能力，但是也继承了传统IN技术存在的缺陷，不利于NGN业务提供模式的进一步发展。
    2.1　传统IN业务提供模式的缺点
    首先，传统IN系统的业务开发是一种封闭模式。尽管IN规范定义了独立于业务的构件块（SIB），但在目前的IN系统中很难实现SIB的标准化和统一化，不同厂商开发的SIB差别很大且互不兼容，运营商只有在设备厂商的技术支持下才能开发和部署智能业务，这不利于NGN业务的开放。
    其次，传统IN业务采用垂直开发、垂直部署模式。IN虽然理论上是一个独立于具体通信网络的附加业务网，但是实际应用的IN系统通常是与特定通信网（如PSTN、CDMA网、GSM网等）绑定在一起，所提供的业务也是面向特定网络的，无法满足NGN业务融合的需求。
    简而言之，由于受限于IN中封闭的业务处理和数据访问方式以及垂直的业务划分方式，通过互通模式只能简单使用SCP中已有业务，无法满足NGN业务融合的需求，也无法做到向第三方开放业务的能力，不能适应NGN中业务价值链开放的商业模式要求。
    2.2　结合Parlay技术的IN系统改进模型
    为克服现有IN应用方案的缺点，适应NGN业务发展的需要，可以通过在IN系统中引入Parlay API（应用编程接口）的方式对其进行升级改造。
    使用开放API构建业务是实现开放式业务结构的关键技术，也是NGN区别于传统电信网的主要特点之一。基于API的业务提供技术可以融合计算机领域的应用软件开发方式，被认为是NGN最具吸引力的能力之一。
    Parlay技术与传统IN系统结合的一种可能模型如图2所示，它的基本出发点是通过引入Parlay网关开放SCP业务资源，提供面向第三方的标准Parlay API接口，使Parlay应用服务器能够利用现有SCP的业务资源构建新的业务，同时也提供了从现有IN系统访问第三方业务的途径，以提升对现网用户的服务能力。

图2　Parlay API与IN系统结合的模型

    在该模式下，Parlay应用服务器与SSP/SCP进行协作，可以充分挖掘现有IN的潜能。原有的IN业务仍然由SCP实现，对于新业务则可以基于Parlay API开发，并由Parlay应用服务器执行。业务触发与执行的大致流程如下：
     ●当SCP接到一个IN业务请求（来自软交换网络或者传统电信网）时，首先判断是否请求的是它已提供的IN业务。如果是，则直接执行该业务，否则将此业务请求转发到相应的Parlay网关。
     ●Parlay网关进行业务认证和授权操作，查询此次呼叫请求有无使用该业务的权限，如果权限得到认可，则调用相应的Parlay应用服务器。
     ●由Parlay应用服务器执行新业务逻辑，并通过Parlay网关和SCP互动，控制底层网元设备。
    总的来说，基于Parlay API实现已有IN系统的开放，可以满足两方面的需求。第一，创建了一个标准的开放机制，使第三方应用能够访问IN系统的业务能力，并可以基于新技术带来的优势，提升现有IN系统的业务能力。第二，网络安全可以被严格保证，避免受到外部应用恶意的攻击或者误操作的侵害，以维护电信网络的可靠性和完整性。此外，由于Parlay API与具体的网络类型无关，基于Parlay API开发的业务适用于所有电信网络，因此，通过在现有固定IN和移动IN系统之上引入Parlay API并叠加统一的Parlay应用服务器，可以初步实现FMC（固定网与移动网融合）的业务融合目标。因此，把经过这种方式改造后的IN系统称之为开放式综合IN系统。
3、原型系统的设计与实现
    基于上述改进后的IN系统模型，在国家相关研究项目的资助下，作者在北京邮电大学CIN（中国智能网）系统的基础上设计并实现了一套原型系统，其体系结构如图3所示。

图3　原型系统体系结构

    原型系统主要包含两种网络实体：Parlay应用服务器和能力服务器，它们之间通过CORBA（公共对象请求代理体系结构）环境协作。应用服务器的主要功能是提供业务部署和运行的环境。能力服务器对应于图2中的Parlay网关，其主要功能是屏蔽各种IN应用协议细节，将其映射到标准的Parlay API，提供独立于具体网络的呼叫控制能力并保护核心网络的安全性。
    能力服务器是原型系统的设计核心，其内部实现包括3个相对独立的功能模块：管理服务器模块、呼叫控制服务器模块和IN/CORBA网关模块。管理服务器模块实现的主要功能包括应用服务器鉴权、网络访问控制、业务能力查找和计费服务等。呼叫控制服务器模块向上层的应用服务器提供访问和控制网络资源的能力，包括通用呼叫控制和用户交互控制等能力。IN/CORBA网关模块主要实现SS7网络与基于CORBA的分布式处理环境的互通。
    实际上，能力服务器包含的上述3个组成模块只是逻辑上的划分，在物理实现中，这3部分都是由一些CORBA服务器对象构成的，并通过ORB（对象请求代理）总线相连。
    下面重点介绍IN/CORBA网关模块和呼叫控制服务器模块的设计。
    3.1　IN/CORBA网关
    由于Parlay API的调用需要基于CORBA分布式处理环境，因此，能力服务器需要提供基于消息传递模式的SS7信令域与基于远程方法调用的CORBA域之间的过渡桥梁。在原型系统中，实现这一桥梁的就是IN/CORBA网关。
    通过IN/CORBA网关，SSP/SCP发出的INAP（智能网应用协议）消息被转换为合适的CORBA对象调用，在反方向上，CORBA对象回应和方法调用被转换成到SSP的INAP消息。
    由于SS7信令域的IN应用协议栈包含了多层协议（INAP/TCAP/SCCP/MTP），除SCCP（信令连接控制部分）和MTP（信息传输部分）是用于提供消息传输机制的，INAP和TCAP（事务处理能力应用部分）都可以用作实现SS7域和CORBA域互通转换的基础。因此，IN/CORBA网关的设计基础有两种可能的选择：第一种是直接基于INAP协议层，第二种是基于TCAP协议层。
    如果IN/CORBA网关选择基于INAP层协议设计互通映射，其功能将仅限于实现INAP操作与CORBA IDL（interface definition language，接口定义语言）接口之间的转换，而且必须注意的是，ITU标准化的INAP在具体应用中有许多变种（称为INAP方言），这将导致IN/CORBA网关的功能与特定的INAP方言绑定。因此，虽然其设计和实现相对简单，但应用范围将比较狭窄。
    相比之下，基于TCAP层的网关通过提供将事务处理（TC）协议的远端操作服务（RoS）结构转换到CORBA IDL的翻译算法，可以定义适用于所有TC用户（INAP只是其中之一）的通用映射功能。因此不仅能用于INAP与CORBA调用的转换，还能用于其他基于TC的应用协议（如CAP、MAP等）与CORBA IDL的转换。
    考虑到业务融合的需要，IN/CORBA网关应满足相对广泛的IN应用协议转换需求，因此原型系统采用了基于TCAP协议层的网关设计方案，并参考联合域间管理任务组（joint interdomain management task force JIDM）针对CORBA电信管理网网关的相关建议设计，实现了IN/CORBA网关。
    概括地说，IN/CORBA网关的设计包括规范翻译和交互翻译两个方面。规范翻译是将TC用户的ASN.1描述转换到CORBA对象使用的IDL描述的静态翻译过程。交互翻译则主要考虑RoS/TC相关概念如何在网关中动态实现（也即在静态翻译的基础上，提供TCAP协议功能在CORBA环境中的实现方式）。
    图4显示了IN/CORBA网关的主要软件模块组成。包括GwService服务器、TCAP服务器和TC-User服务器。各模块中定义的主要对象均来源于TCAP协议与CORBA之间的规范翻译的输出结果，而动态翻译则是通过各模块之间的对象交互过程来实现的。

图4　IN/CORBA网关的对象结构

    GwAdmin服务器负责提供网关内的公共对象服务，如网关管理和网关初始化等以及对象交互过程所需要的命名服务和生命周期管理等。
    TCAP服务器负责接收来自SS7协议栈的TCAP包，解码后通过指示原语操作，上发到TC-User服务器，同时接收TC-User服务器下发的请求原语，将TC-User操作（如INAP操作）编码成TCAP包发送到SS7网络。
    TC-User服务器则负责实现TC用户操作的编解码工作以及与上层应用之间的通信。TC-User服务器从TCAP服务器接收TC用户操作包，解码后通过SSP Proxy对象以IDL调用的方式递交给上层应用（呼叫控制服务器）的对象Ae Proxy，同时接收对方的IDL操作调用，编码后交给TCAP服务器。针对不同的IN应用协议，只需要在TC-User服务器中增加相应的SSP Proxy对象实例即可。
    3.2　呼叫控制服务器
    呼叫控制服务器的主要功能是实现IN应用协议操作与Parlay API的映射转换。
    INCS-1阶段的INAP相对简单，采用Parlay规范的基本呼叫控制（generic call control，GCC，）API即可覆盖CS-1阶段的所有INAP操作，而要实现CS-2阶段涉及到的呼叫方处理操作，则必须采用Parlay多方呼叫控制（multiparty call control，MCC）API。鉴于国内目前已投入使用的主流固定IN系统仅提供CS-1阶段的INAP操作，因此，原型系统目前只提供了CS-1 INAP操作与Parlay 4.0规范中定义的GCC和UI（用户交互）接口之间的映射转换。
    与IN/CORBA网关的体系结构类似，呼叫控制服务器也完全基于CORBA环境实现，由分布在ORB总线上的多个对象模块组成，其核心功能由呼叫控制模块、用户交互模块和网关接口模块提供，如图5所示。

图5　呼叫控制服务器的对象结构

    呼叫控制模块提供了与呼叫控制相关的INAP操作到Parlay GCC API的映射操作，用来控制和管理IN呼叫。用户交互模块提供了与用户交互相关的INAP操作到Parlay UI API的映射操作，用来实现收集用户信息、播放语音提示等用户交互功能。网关接口模块的作用是实现呼叫控制服务器和IN/CORBA网关的通信功能。
    呼叫控制服务器和IN/CORBA网关之间的通信通过两个代理对象（Ae Proxy和SSP Proxy）实现。当呼叫控制服务器向网关发送INAP消息时，只需调用SSP Proxy提供的INAP接口；当网关向呼叫控制服务器发送INAP消息时，也只需调用Ae Proxy提供的INAP接口。
    呼叫控制服务器和应用程序之间的接口是Parlay GCC API和UI API，其中应用逻辑到呼叫控制服务器对象的调用是完成呼叫控制和用户交互功能的API，而由呼叫控制服务器对象到应用程序对象的调用（在图5中以虚线表示）是回调API，用于向应用程序返回错误报告或操作结果。
4、原型系统的性能测试
    性能问题一直是阻碍CORBA技术在通信网络中应用的主要因素。为了掌握基于CORBA平台实现的原型系统的基本性能数据，作者对其基本呼叫处理时延以及呼损率进行了测试，测试环境如图6所示。

图6　原型系统测试环境

    其中SSP仿真程序运行在PC上，硬件配置为Intel Pentium3 CPU，主频为900 MHz，内存为256 Mbyte，操作系统使用Microsoft Windows 2000 （service packet 2）。
    能力服务器以及业务逻辑程序运行在另一台独立的PC上，硬件配置为Intel Pentium4 CPU，主频为1.6 GHz，内存为256 Mbyte，操作系统使用RedHat Linux 8.0，CORBA平台采用Orbacus ORB。
    PC1与PC2之间通过局域网相连。SSP仿真器与IN/CORBA网关之间通信的SS7协议栈，其INAP层协议和TCAP层协议与目前国内IN实际应用的协议完全一致，但是从SCCP协议层以下被替换为TCP/IP协议，以便在局域网上使用。
    性能测试以一个简单的300业务为主，该业务在测试过程中总共涉及到了14条INAP操作（包括TC_END）。图7显示了300业务测试过程中，IN/CORBA网关所执行的操作调用顺序。

图7　IN/CORBA网关中300业务流程

    为了全面显示原型系统的呼叫处理时延特性性能测试采用了测量平均呼叫处理时延的方式，即统计在不同的负载情况下，原型系统从接收到SSP仿真器发出的一个新的300呼叫请求消息（InitialDP）到返回最后一条响应消息（end_req）的平均时间间隔。
    图8和图9分别显示了原型系统的性能测试结果。其中图8显示了原型系统在不同负载条件下的平均呼叫处理时延，图9显示了原型系统的呼损率随负载增加时的变化情况。

图8　能力服务器的平均呼叫处理时延

图9　能力服务器的呼损率

    为了评判CORBA平台对原型系统性能的影响。作者还对CORBA ORB的性能进行了测试。CORBA性能测试主要针对一些重要的CORBA方法调用进行统计测量，单独计算花在CORBA传输上的开销，从而反映其在系统呼叫处理时延中所占的比重。图10显示了原型系统在不同负载条件下的平均呼叫处理时延中，CORBA调用所占比重（百分率）的变化情况。

图10　CORAB调用在平均呼叫处理时延中的比重

    通过实测显示，系统负荷对CORBA调用的时间开销没有太大的影响。在一个完整的300业务执行期间，原型系统在CORBA调用上的时间开销基本稳定在一个范围内（大约为2 s）。从图10可以看出，当原型系统处于轻负载时，CORAB调用在原型系统平均呼叫处理时延中所占比重较为固定，大约为50%。由此看来，在CORBA传输上的时间开销对平均呼叫处理时延的影响是比较大的。由于上述数据是在单机内测试得到的，没有涉及网络传输（但实际上还是进行了进程间的Socket传输），如果采用网络传输，预计CORBA调用对原型系统呼叫处理时延的影响更加显著。
5、下一步的工作
    NGN的发展是一个逐步演进的过程。NGN建网初期，采用与现有IN互通的方式来提供目前的IN业务，可以充分利用现有的IN业务平台。但随着NGN业务需求的不断发展，还应通过对IN系统的升级改造，实现IN系统的开放和融合，从而更充分地挖掘传统IN技术的潜力。
    本文描述了作者在这方面做的一些初步尝试工作，通过引入面向对象的编程和Parlay API技术为实现IN业务能力的开放和综合奠定了基础。然而，在研究过程中也发现，Parlay API接口的引入虽然可以解决业务开发接口的标准化问题，并将IT领域的软件开发技术引入到了IN业务的开发过程中，但是Parlay API本身只是实现了一个业务接口，并没有提供一种标准的业务开发模式。相对于IT领域的软件开发来说，电信业务的开发有其特殊之处，如必须要有严格的验证、最大程度地实现软件重用以加速业务开发等。因此，从业务工程的角度来说，如何在改进后的系统中引入基于Parlay API的规范化业务开发过程是下一步需要研究的重点。