呼叫业务

呼叫业务（精选5篇）

呼叫业务 篇1

2012年6月1日上午, 首都信息发展股份有限公司与北京讯鸟软件有限公司政务云呼叫平台战略合作协议签字仪式在北京市海淀区隆重举行。

根据协议, 双方将充分发挥各自拥有的资源优势、品牌优势、以及技术优势, 共建政务云呼叫平台系统, 共同促进“政务呼叫云平台”地方标准的制订, 共同参与“云呼叫平台”相关课题研究与编制工作。政务云呼叫平台系统建设工作将基于“首都信息”已有的电子政务互联网云平台进行, 是该云平台重要的应用服务系统, 也是北京市电子政务建设的重要项目之一。政务云呼叫平台系统建成后, 将首先面向全北京市各级政府机构提供集约型高效低成本的呼叫服务。

协议的签订将确立双方在北京云呼叫服务领域的联合工作模式, 为双方共同开拓全国高端呼叫服务市场奠定了基础, 同时也为“首都信息”云平台的应用推广和占领云计算业务制高点迈出了坚实的一步。

“首都信息”借资深的专业化IT服务能力和高度的社会责任感, 承担了北京市多项重要信息化基础设施和重大信息化应用工程的建设工作。特别在北京市非紧急救助服务系统、北京市电子政务互联网云平台建设领域拥有全国领先的经验与能力。

呼叫业务 篇2

今年七月份亿伦呼叫中心新的电销业务签约却面临这不小的困难。虽然我们的管理团队具备丰富的运营经验，但新项目初期不可以避免遭遇了瓶颈，与该项目的其他呼叫中心相比，坐席成单率、被质检打回率居高不下，业绩产能提升有限。

观察总结问题原因，与此同时也和甲方交流取经，运营部门迅速做了以下调整：

首先，这个项目不同于之前有针对性呼叫项目，要适当的加大数据的使用量。在呼叫模式上重新定位，加大坐席在八小时工作时间内呼叫数量。

其次，精简话说脚本。通过研究关键点和对优质录音经验的提取，总结前期的缺点，更改话术中的关键用词，注意营销过程中的语气、语速。

通过这些手段，坐席的业务水平有了明显的提升。但业绩的提升过程中，管理上的问题也随之而来。在大强度的外呼下，部分坐席因成单量低，思想包袱重、压力大，有负面情绪。运营部门秉承“不抛弃不放弃任何一个员工”的宗旨，为让大家一起共同成长，在现场激励和业绩的结算两方面都做了调整。因为项目初期属于成长阶段，降低了业绩结算的门槛，同时加大了现场激励的力度，让坐席安心又有干劲。另一方面，针对员工压力大的问题，通过与员工的沟通让他们对压力有客观、理性的认识，寻找自身压力的来源并且调整心态积极去面对，提高抗压能力，培养良好的工作态度。我们没有只说空话，员工的压力来源于业绩，为此我们调整了原有的组织划分，化整为零的将原先的大组格局分成若干小组，平衡的将新老员工搭配分组。加强小组内的互动帮扶活动。让业绩优先又干劲的老员工帮助新员工成长，分担其压力。新员工在老员工的带动下，业绩增长很快，业绩的提升带来了自信，压力也释放了。在期间主管也做了大量的工作，观察大家的思想变化，适时的与大家沟通互动。同时放手给小组长去干，坚定的支持他们，每个人的管理方式各不相同，主管要做的就是坚定的支持加适度的扶持。

双重区号导致集团业务呼叫失败 篇3

隐患基本描述:在智能网承载集团业务的vpmnscp里面有一张长短号分析表mvpn_user。这个表对主被叫号码的匹配要求完全一致, 一旦端局上报scp主被叫号码有误将会长短号转换翻译失败, 导致有关集团业务呼叫失败。

隐患排查分析:综合VPMN业务最大的特点是可以把铁通的固定电话作为移动短号集团用户加入到移动的集团当中, 能通过短号与群内的移动电话进行集团通话, 享受一定的通话优惠。

上图是东莞的综合VPMN呼叫流程涉及网元的基本框图结构:PBX过来的主叫请求, 通过IP前置机或者NGN系统送到东莞的GW4, 由GW4触发智能业务, 再到相关的VPMNSCP进行有关集团长短号翻译, 以判断该主叫是否具备综合VPMN集团业务。

具体投诉:一综合vpmn老用户用短号呼叫群内其他号码失败, 并有没有办理vpmn业务的通知音。下面分析过程如下:

1) 考虑该用户是老用户, 之前使用一直正常, 因此首先在其归属vpm ns cp-东莞s cp14中的集团基本用户表以及长短号对应表中查询相关的用户数据是否有异。

在用户基本表中, 用户的权限标识位power参数正常, 用户集团号, 长短号数据齐全并没有异常。

在长短号对应表里面也有相关的用户数据, 长短号以及集团号齐全无异常。

2) 在s cp上确认基本用户数据没有异常之后, 我们联系用户再进行同样的拨打测试, 并在oam上做信令跟踪分析。下面摘取部分重点信令进行点评。

在智能网的信令分析中, IDP信令是端局发给scp的第一个信令, 其中包含了主被叫用户号码, 主叫所在位置等重要信息。在对投诉用户的分析中, 很明显看到calling Party Number="0769076995045008", 由于端局送上的主叫号码出现了双重区号, 导致在长短号对应表中匹配失败, 因此导致呼叫失败。

在匹配失败之后, 无法按照正常流程继续余下的过程, 只能连接到放音设备 (connecttoresource) 。

启用信令playannouncement播放通知音, ID号为3000008。经查通知音数据表得知语音为:“对不起, 您没有申请VPMN业务, 不允许呼叫此号码”。

经过对投诉用户的实时信令跟踪分析可以知道:由于端局在IDP信令中上报scp的主叫用户号码异常, scp在长短号对应表中无法匹配号码的长短号导致系统认为该用户并没有加入集团业务继而中断呼叫只向用户播放相关通知音。

问题关键在于这个上报的主叫号码异常, 因此需要端局方修改送号规则来解决这个用户投诉。

隐患解决措施:此投诉已确定与scp侧数据无关, 是由于端局上报主叫号码格式有误, 因此由端局侧修改送号规则来解决问题。

有效性分析:端局在修改相关数据后我们再一次联系用户进行拨测, 结果呼叫顺利建立, 问题得到彻底解决。下面就重点相关信令进行分析。

在IDP信令中, 主叫号码calling Party Number="076995045008"已恢复正常, 被叫号码依旧是68320。

顺利下发RRBE和AC信令。

顺利下发connect信令, 并长短号翻译成功。把被叫短号68320转换为长号 (真实号码) 13549334200。

对于一个智能网呼叫来说, 在端局向scp上报IDP信令把一些基本数据送到scp之后, 如果scp能顺利下发RRBE, AC, continue (connect) 信令的话就表明在智能网侧的鉴权已通过, 余下的呼叫过程则返回交换层继续完成。因此对于这三个信令是否如常下发成为智能网呼叫鉴权是否成功的一个重要标志, 对于定位呼叫问题在智能层还是在交换层有着十分重要的参考意义。

推广性分析:

呼叫业务 篇4

呼叫中心是基于CTI (Computer Telecommunicat ion Intergration, 计算机通信集成) 技术、充分利用通信网和计算机网的多项功能集成, 并与企业连为一体的一个完整的综合信息服务系统[1]。它又被称为客户服务中心, 可以向用户提供电话、传真、电子邮件以及等多种接入手段的服务, 处理用户对企业提出的要求、投诉、建议、咨询等。随着近年来通信技术和计算机技术的发展和融合, 呼叫中心在技术上发展迅速, 应该也越来越广泛, 在电信、银行、电子商务、保险、证券、旅游等各个行业都得到了广泛应用[2]。

呼叫中心的业务处理方式分为自动处理方式和人工处理方式[3]。业务的实际特性决定了其处理适合采用哪种方式。费率查询、余额查询、电话缴费、费用预约通知等业务一般适合采用自动方式进行处理, 而咨询、投诉建议、业务受理等更适合采用人工方式处理[4]。

十几年来, 随着中国改革开放的深入进行, 特别是在中国加入WTO之后经济快速发展的大背景下, 中国的呼叫中心已经取得了令人可喜的成绩, 并逐步形成一个朝气蓬勃的产业[5]。《2010 中国呼叫中心产业发展研究报告》显示, 经过近几年的发展, 就总体而言, 呼叫中心几乎已经遍布全国各行各业[6];截止2009 年底, 中国大陆呼叫中心座席总数达到480, 000 多个, 市场累计规模为470 亿元人民币。我国的呼叫中心市场正处在令人兴奋和具有挑战性的发展阶段[7]。

呼叫中心的核心是向企业用户提供租用形式的服务, 那么提供一个图形化的、界面友好的呼叫中心管理系统以供企业管理者和运营管理者使用将是呼叫中心取胜的一个关键[8]。结合呼叫中心业务需求, 提出一个基于web技术的呼叫中心业务管理系统[9]。通过J2EE分层模型, 将系统分层实现, 描述了持久层、业务逻辑层、表示层和数据库层的过程和实现方法。本课题采用B/S架构, 在Struts、Spring、Hibernate开源项目上, 使用MVC模式, 降低了模块的耦合性, 增强了系统的可维护性和灵活性, 显著提高了系统的可扩展性[10]。

1 系统功能设计

随着近些年来呼叫中心的不断发展, 呼叫中心业务的种类也越来越多, 功能也越来越强, 已经不再是单纯的服务功能, 而是开始向客户服务和产品销售等多方面的功能深入。尽管业务功能多种多样, 但他的核心还是紧紧围绕着呼叫中心的基本功能来展开和实现的。

根据呼叫中心的业务的需求, 建立一个呼叫中心业务管理系统, 此系统是一个统一的呼叫中心管理平台, 使之能够适应新型呼叫中心业务的管理需求, 并使之有很好的可维护性和可扩展性。呼叫中心业务管理系统包括节点管理、设备管理、团队管理、班组管理、人员管理、项目管理、任务管理几大模块, 系统整体流程如图1-1 所示。本章将重点介绍本呼叫中心业务管理系统的功能性需求。

1.1 节点管理

(1) 管理员可以增加节点, 节点信息包括节点名称、类别、所属团队、所在位置、备注等。

(2) 管理员可以查询系统中所有节点的列表, 也可根据节点名称, 所属团队来查询节点列表。

(3) 管理员可以修改节点信息, 包括节点名称、所属团队等。

(4) 管理员可以删除节点。

1.2 设备管理

(1) 管理员可以增加服务器, 服务器信息包括名称、型号、功能类别、IP地址、所属节点、备注等。

(2) 管理员可以查询系统中所有服务器的列表, 也可根据服务器名称、IP地址、功能类别来查询服务器列表。

(3) 管理员可以修改服务器信息, 包括名称、备注等。

(4) 管理员可以删除服务器。

1.3 团队管理

(1) 管理员可以增加团队, 团队信息包括团队号、团队名、工作方向、所属节点等。

(2) 管理员可以查询系统中所有团队的列表, 也可根据团队号、团队名、所属节点来查询团队列表。

(3) 管理员可以修改团队信息, 包括团队名、工作方向等。

(4) 管理员可以删除团队。

1.4 班组管理

(1) 管理员可以增加班组, 班组信息包括所属团队、班组号、班组名、班组类型等。

(2) 管理员可以查询系统中所有班组的列表, 也可根据所团队、班组号、班组名、班组类型来查询班组列表。

(3) 管理员可以修改班组信息, 包括班组名、备注等。

(4) 管理员可以删除班组。

1.5 人员管理

(1) 管理员可以增加员工, 员工信息包括工号、姓名、角色、状态、初始密码、所在团队、所在班组等。员工角色包括管理人员、质检人员、话务人员、项目人员等。

(2) 管理员可以查询系统中所有员工的列表, 也可根据工号、角色、所在团队来查询员工列表。

(3) 管理员可以修改员工信息, 包括姓名、状态密码、所在班组等。

(4) 管理员可以删除员工。

1.6 项目管理

(1) 管理员可以增加项目, 项目信息包括项目编号、项目名称、外呼文件等。

(2) 管理员可以查询系统中所有项目的列表, 也可根据项目编号、项目名称来查询项目列表。

(3) 管理员可以修改项目信息, 包括项目名称、备注等。

(4) 管理员可以删除项目。

1.7 任务管理

(1) 管理员可以增加任务, 任务信息包括任务编号、任务名称、呼叫类型、坐席率等。

(2) 管理员可以查询系统中所有任务的列表, 也可根据所属项目、任务编号、任务名称查询任务列表。

(3) 管理员可以修改任务信息, 包括任务编号、任务名称等。

(4) 管理员可以删除任务。

(5) 管理员分派任务到指定坐席。

2 系统整体架构

基于B/S模式的网络数据库应用系统, 只需要在客户机上安装浏览器, 而不需安装具体的应用程序, 所以称为“瘦”客户机模式。中间“Web服务器”是连接前台客户机与后台数据库服务器的桥梁, 主要的数据计算和应用逻辑都是在此实现的, 因此对中间层开发者的要求较高。基于B/S模式的网络数据库主要用于浏览、查询信息, 具有界面统一、使用简单、易于维护、扩展性好等优点。因此, 随着因特网的普及, 三层结构B/S模式将会得到广泛应用。

本呼叫中心业务管理系统采用B/S架构模式, 支持谷歌、火狐、IE、搜狗等主流浏览器。最上层的View层采用Ext Js框架搭建, 通过HTTP消息使用Json格式的数据与后台交互, 并对数据处理完成前端界面的显示。当用户通过页面提交请求是, 相应的Action接受请求并调用Service层中的对应方法, 通过Dao层来访问数据库并返回数据给前端。各个层次之间有很好的利用了Spring的依赖注入, 使相关对象通过XML配置文件联系在一起, 很大程度上解耦了Java对象之间的依赖关系。整个系统将运行于Tomcat容器中, 运行流程如图2-1 所示。

3 系统的设计与实现

本系统选择Ext Js构建前端页面, SSI框架实现后台系统。本章将以人员管理为例, 详细介绍呼叫中心管理系统的类结构设计和流程设计。

3.1 数据库表设计

呼叫中心业务管理系统使用的数据库表包括结点表、结点IP地址表、设备表、团队表、班组表、员工表、项目表、任务表、任务-员工关系表。

其中, 员工表的设计如表1 所示。

3.2 核心类设计

本文以人员管理模块为例, 介绍核心类的设计。

3.2.1 浏览器端核心类

人员管理模块在浏览器端主要有以下几个类实现: Employee Framework 、 Employee Modify 、Employee Query 、 Employee Grid 、 Employee Create 、Employee Control、Employee Store。它们的功能如表3-2所示。

3.2.2 服务器端核心类

人员管理模块主要实现增加员工、查询员工列表、修改员工信息、查看员工信息详情、删除坐席、更改坐席所属班组的功能。本模块主要有以下几个类实现:Employee Action类、 Employee Service Impl类、Employee Dao类、Excel Service Impl类、Employee类。其类结构设计如图3-1 所示。

(1) Employee Action类

Employee Action类继承自Base Dispatch Action类。它通过setter方式注入了Employee Service Impl对象和Excel Service Impl对象。以下是Employee Action类中主要方法的详细说明。

(2) Excel Service Impl类和Emplpyee Service Impl类

Excel Service Impl类和Emplpyee Service Impl类属于业务逻辑层。Excel Service Impl类主要提供Excel导入员工和导出员工名单Excel文件两大功能。Emplpyee Service Impl类则负责员工表的增删改查等主要操作。此外, 在业务逻辑层增加了数据库事务管理, 我们采用Spring的声明式事务管理来管理事务。

(3) Employee类

实体类Employee类是数据库表Employee表对应的域对象。该类包括了与数据库表中的字段相对应的属性及这些属性的setter、getter方法。

(4) Employee Dao类

Employee Dao类继承自Base Dao类。负责员工信息的持久化。

4 总结

本文通过对呼叫中心的优势进行分析, 讨论了基于Ext Js和J2EE框架的进行软件开发的技术特点, 对于实现系统的低耦合, 增强系统的安全性和可靠性, 有着非常大的优势。根据客户的需求和呼叫中心的业务特点进行了需求分析, 设计并且实现了呼叫中心业务管理系统。该系统设计思路明确, 采用模块化设计, 易于理解和实现, 未版本的升级和系统的维护打下了良好的基础。

摘要：近年来, 国内呼叫中心业务发展迅速, 通信行业竞争愈演愈烈, 提供更加优质的客户服务成为运营商吸引顾客的重要手段。为了满足市场需求, 完善和发展企业呼叫中心管理设计理论, 促进企业的发展, 提高企业的管理水平和工作效率, 一个提供图形化、界面友好的呼叫中心业务管理系统显得尤为重要。本文提供了提出了一套呼叫中心业务管理系统的设计与实现方案, 论文内容涵盖了系统架构、需求分析、技术实现等。

关键词：计算机应用,呼叫中心,管理系统

参考文献

[1]张伟, 王豪, 徐文艳.基于通用呼叫中心运营平台的研究和应用[J].计算机工程, 2006, 32 (2) :237-239.

[2]徐庆征.呼叫中心技术及其发展浅述[J].江西蓝天学院学报, 2006, 1 (4) :49-51.

[3]李少辉.面向对象与MVC框架的融合[J].软件, 2013, 34 (1) :82-84.

[4]杨鑫.呼叫中心人工业务平台的设计与实现[D].重庆:重庆大学, 2006.

[5]李吉旺, 居里锴.基于WEB的绩效津贴管理系统的设计与实现[J].软件, 2013, 34 (3) :59-60.

[6]闫峰, 门建阳.基于云计算技术的养老机构管理系统[J].软件, 2013, 34 (4) :31-33.

[7]田平.Java Web开发的环境配置[J].软件, 2013, 34 (7) :40.

[8]高玉军.面向对象分布式Web自动化实现[J].软件, 2013, 34 (11) :86-88.

[9]张慧宁.基于web技术的实验室开放管理系统设计[J].软件, 2013, 34 (11) :52-54.

呼叫业务 篇5

数字集群系统是一种专业移动通信系统, 主要应用于关键任务的调度指挥。在突发事件处置过程中, 数字集群系统提供丰富的优先级功能, 确保最高级别的指挥长最快速下达调度指令[1,2]。

优先呼叫 (PC) 是数字集群代表性业务之一, 当基站无空闲业务信道或空闲业务信道数量不满足本次呼叫时, PC业务按照呼叫优先级别的高低将呼叫进行排队, 等待空闲业务信道, 一旦基站业务信道状态发生改变, 首先从队列中搜索优先级最高的呼叫, 并触发该呼叫的接续, 直到队列为空时方可以为不具备PC业务权限的用户分配业务信道[3]。

针对数字集群PC业务的功能特点, 论述了一种基于内嵌业务逻辑机制的数字集群PC业务的设计与实现, 在智能网能力集2 (INAP CS-2) 呼叫模型和业务触发机制的基础上[4,5], 提出了业务交互流程、个呼和组呼业务触发点, 设计了呼叫优先级别和基站业务信道资源平衡使用策略, 在保证呼叫优先级的前提下, 确保基站业务信道资源利用率最大化。

1 总体设计

数字集群中心控制器软件采用业务与控制分离的思想, 业务采用内嵌业务逻辑方式。PC业务子系统位于数字集群中心控制器软件的最高层, 它与呼叫控制子系统和资源管理子系统交互[6,7], 实现数字集群系统PC业务。

PC业务子系统由业务逻辑程序模块、业务逻辑管理模块、消息处理模块和数据中心模块4部分组成, 如图1所示。

1.1 业务逻辑程序模块

业务逻辑程序模块主要实现PC业务逻辑, 业务的提供形式为动态链接库, 即PC业务逻辑将生成一个对应的动态链接库, 当触发业务后, 由业务逻辑管理模块调用动态链接库提供的业务入口函数, 进入具体的业务逻辑处理[8]。

1.2 业务逻辑管理模块

业务逻辑管理模块是PC业务子系统的一个关键模块, 它主要由业务交互管理、业务触发管理和业务信息查询3个功能模块构成。

①业务交互管理:负责裁决业务交互过程中的互斥管理[9]。

②业务触发管理:负责根据用户状态和拨号情况检测和比对业务触发的条件, 从而决定触发了哪一个业务, 然后导引到相关的逻辑处理流程[10]。

③业务信息查询:负责对业务数据信息、用户属性信息等相关数据信息的存取操作。

1.3 消息处理模块

消息处理模块主要功能是完成各种消息的收发、消息装配、消息资源管理、消息检索、消息解析和连接管理等功能。

1.4 数据中心模块

数据中心模块是PC业务子系统的数据处理中心, 负责配置数据的加载, 运行过程中的数据读取及动态数据的存储。

2 需要解决的核心问题

按照如上总体设计的描述, 数字集群PC业务需要解决以下几个核心问题:

①业务时序:业务流程中, 从业务的生效、维系和撤销, 涉及到多个系统的交互和协同, 业务时序是设计的第1个核心问题;

②业务触发点:鉴于PC业务的特殊性, 在数字集群系统内PC业务无需激活和去激活, 当系统基站业务信道资源无法满足具有PC权限用户的呼叫时要保证业务快速启动, 业务触发点是设计的另一个核心问题;

③排队策略:数字集群系统中的用户有多种优先级类型, 在业务信道资源紧张的时候, 用户的排队策略是设计的又一个核心问题;

④资源使用策略:数字集群系统中的业务信道资源是极其稀缺的资源, 为了确保业务信道资源利用率最大化, 资源使用测试是设计的最后一个核心问题。

3 设计实现

3.1 业务时序

PC业务时序涉及到发起呼叫的终端A、接收呼叫的终端B、资源管理、呼叫控制以及PC业务逻辑, 如图2所示。

主要流程包括:

①终端A发起呼叫请求, 呼叫控制在分配业务信道资源时遇忙, 向PC业务逻辑触发业务;

②PC业务逻辑通过呼叫控制向资源管理请求监视基站业务信道;

③资源管理发现空闲业务信道后, 通知呼叫控制业务信道状态改变, 随后呼叫控制回复PC业务逻辑的监视基站业务信道请求;

④PC业务逻辑通过呼叫控制向资源管理请求取消监视业务信道;

⑤PC业务逻辑指示呼叫继续, 呼叫控制完成呼叫接续。

3.2 业务触发点

数字集群系统内的呼叫包括个呼和组呼两大类型, 参考智能网技术下INAP CS-2中呼叫模型和业务触发机制, 数字集群个呼及组呼的业务触发机制分为:

①个呼时, 当呼叫模型到达“O_激活”才对主被叫分配业务信道, 如果主叫或被叫无可用业务信道时则触发“O_悬置”;所以个呼的PC业务触发点在“O_悬置”。

②组呼时, 当呼叫模型到达“选择_设备”才对主叫分配业务信道, 如果主叫无可用业务信道时则触发“T_忙”, 所以组呼的PC业务触发点在“T_忙”。

3.3 排队策略

当呼叫遇忙触发PC业务时, 生成业务实例, 会有一个单独的业务逻辑为每个基站建立一个队列, 负责将每个业务实例的呼叫进行排队, 如图3所示。根据PC优先级将每个触发业务的呼叫插入到队列中, 如果优先级相同则按照呼叫触发业务的先后次序加入队列。

当某个基站下队列已满, 又需要触发新的PC业务实例时, PC业务将会在队列中查找比新呼叫优先级别低且最低的呼叫, 将其释放, 并将新呼叫置于队列中。

触发PC业务后, 业务实体将启动一个定时器, 用于控制用户等待时间, 当定时器时超但呼叫没有获得可用资源时, 业务将释放该呼叫。

3.4 资源使用策略

数字集群呼叫类型、呼叫范围不同, 所需要的基站业务信道数量也不同[11,12], 如表1所示共计5类情况。

当业务实例收到基站业务信道资源状态变化通知时, 业务实例会从基站队列的队首取出优先级最高的呼叫, 判断业务信道资源是否满足其需求, 如果满足则将该呼叫继续并从链表中删除, 如图4所示。

当不满足其需求时, 存在以下2种情况:

①该呼叫需要多个基站下的业务信道, 而当前只有部分基站下有空闲业务信道;

②该呼叫需要当前基站下2个业务信道, 而当前只有1个空闲业务信道。

假如出现以上情况, 业务实体将依次向后搜索, 寻找目前的业务信道资源能否满足与队首同级别呼叫的需求, 在确保优先级的前提下提高基站业务信道的利用率。

4 性能测试及测试结果分析

在同基站、跨基站且基站为单载波基站的场景下, 以组呼和全双工个呼为例, 将终端分为10个优先级 (其中, 10级是最高优先级) , 对数字集群PC业务进行了性能测试, 主要测试了排队策略及业务触发成功率。

组呼排队策略和业务触发分别测试100次, 其中排队测试成功率100%, 业务触发成功率100%;同样, 全双工个呼排队策略和业务触发也分别测试100次, 其中排队测试成功率100%, 业务触发成功率100%, 如表2所示。

5 结束语

从内嵌业务逻辑机制的角度, 给出了一种数字集群PC业务的总体设计方案, 分析了数字集群PC业务具体实现中的关键问题, 并提出了具体的设计实现方法。

数字集群PC业务设计已被应用于产品研发实践, 在单基站、跨基站环境下分别实际测试了组呼、半双工个呼及全双工个呼的PC业务, 经过对测试结果的分析验证了方案的可行性, 并为其他数字集群补充业务的设计提供了很好的参考。

参考文献

[1]郑祖辉, 陆锦华, 郑岚.数字集群移动通信系统 (第2版) [M].北京:电子工业出版社, 2005:301-375.

[2]徐涛.数字集群移动通信系统原理与应用[M].北京:人民邮电出版社, 2008:295-380.

[3]EN 300 392-10-10.Priority Call (PC) [S], 1996.

[4]郑庆红.专网通信系统软交换安全方案研究[J].无线电通信技术, 2011, 37 (5) :6-8, 18.

[5]袁超伟, 刘冰滨.全业务运营下网络技术与发展趋势[J].无线电通信技术, 2012, 38 (6) :1-5.

[6]张建中.软交换系统软件架构设计与实现[J].无线电工程, 2010, 40 (6) :7-10.

[7]曹毅, 李旭.下一代网络业务交互系统的设计分析[J].无线电工程, 2012, 42 (4) :6-8.

[8]齐幸辉.软交换内嵌业务逻辑子系统框架结构设计[J].计算机与网络, 2009, 35 (14) :45-47.

[9]许飞燕.软交换呼叫控制模型的研究与功能测试[D].武汉:华中科技大学, 2006:35-46.

[10]李旭, 胡国庆.一种新的业务冲突检测和解决方案[J].无线电工程, 2012, 42 (5) :12-14, 26.

[11]ETS 300 392-1.Radio Equipment and Systems (RES) ;Trans-European Trunked Radio (TETRA) ;Voice plus Data (V+D) ;Part 1:General network design[S], 2009.