BSS计费系统（共7篇）
BSS计费系统 篇1
在实际工作当中, 通过检查, 或接到用户投诉和咨询解答时, 因有些概念性的知识及维护经验的不足, 常常无法正确定位到问题, 能影响到服务质量及效率, 便于快速准确定位及解决问题, 避免同类问题继续发生, 下面就将我日常工作中的一些维护经验技巧介绍给大家, 能给同行有所帮助。
1 关于档案漏洞问题
通过检查, 发现营业员的人为操作错误形成问题档案, 会影响到计费正确性。主要影响计费准确性的问题档案有无具体收费价格、优惠参数异常、包年续费时的续费次数异常或主价格计划生效方式被改动、同类价格重复、预拆机时间错误、在用优惠参数日期或状态日期或服务日期已失效、小灵通携号转网用户未限制省外漫游等等。维护人员需要编写Oracle应用程序, 运用定时器每天查询问题档案及时整改, 能保证计费的准确性。
2 关于计费处理
计费批价采用择优、部分覆盖、完全覆盖形式。
计费批价事件执行顺序是优先级低的先处理, 高的后处理, 如果优先级高的资费类型是独占性作用, 那么优先级低的资费会被完全覆盖, 减免信息不保留;如果优先级高的资费类型是部分独占性作用, 那么优先级低的资费会被部分覆盖, 减免信息保留 (减免叠加) , 批价计费结果被覆盖;如果优先级高的资费类型是协同性作用, 那么减免是叠加的, 但批价结果是和前面比较后进行择优。
比如, 用户有两个套餐, 优先级分别为10和20的举例介绍下面4种情况:1) 优先级10协作, 20协作, 程序在批价时先作用优先级10的套餐, 先批一个费用出来, 如果20的比这个还便宜, 则最后作用20的套餐, 如果20的比10的贵, 那最后不作用20的。优先级10的为最后执行的套餐。2) 优先级10独占, 20协作, 如果20的比10便宜执行20, 如果贵执行10。3) 优先级10协作, 20独占, 不管20是贵还是便宜, 执行20。4) 优先级10独占, 20独占, 不管20是贵还是便宜, 执行20。
计费类问题大体种类:号段局向、特殊号码类问题;用户话费收取异议;集团、亲情网用户互打收费问题;sp扣费问题;优惠类问题。
计费类问题涉及常用知识:超长话单切割为多条话单是正常现象, 一般1800秒时切割成一条话单;小时长批价举3G用户介绍, 省内拨打移动长途一批资费是0点到7点每6秒钟0.04元, 7点至24点每6秒钟0.07元, 二批资费是3G套餐资费, 用户资费属于协作性作用择优批价时, 小时长通话一批资费比二批资费更优惠时就按如上小时长资费计收, 如果费用超过套餐本身的标准资费就按照二批资费计收;G网校园套餐等涉及到小区的注意清单表In_cell字段, Y表示小区内, N表示小区外, 通过此字段判断用户拨打地点是否在小区内, 以便确认具体批价资费;10193特服仅参与一批资费, 不参与套餐累计, 承载类型为carrier_type=23, 3G用户等有套餐累计资费的用户建议直拨长途, 可以避免此类用户多收费用现象;集团、亲情网用户互打收费问题需要查看成员表tf_f_user_member和资费表tf_f_feepolicy。集团生效条件是成员表中的user_id一致, 且生效时间在合理范围内, 资费表的rele_user_id和成员表的user_id一致;沃家庭生效条件是成员表的user_id一致, 且生效时间在合理范围内, 资费表中虚拟用户挂的id和成员表中的user_id一致;亲情生效条件是成员表的user_id一致, 并且生效时间在合理范围内, 主卡用户需要在资费表中rele_user_id和成员表中user_id一致, 如果是集团间用户, 首先用户要满足集团所有条件, 然后在td_B_vpnrelfeepolicy表中配置集团间资费;sp扣费需要查看Monfee清单表:tg_cdr XX_monfee、Sp清单表:tg_cdr XX_sp、订购关系表:tf_f_user_sp、Sp配置表:td_a_sp_traiff、Sp产品配置表:td_b_party_product。sp费用当天订购后在当天取消会正常收费;优惠费注意查看是通过公式计算还是通过crm前台参数收取等, 帐务优惠是依据帐务资费对账单费用进行打折或赠送的处理过程。根据优惠对象的不同帐务优惠分为用户级、用户群和帐户级优惠。根据优惠规则执行策略又可以分为实时和月末优惠。实时优惠是定时任务或话单触发完成。根据优惠方式分为打折、赠送、保底、封顶优惠。优惠和计费的资费配置基本类似。在td_b_feediscnt中dispatch_method为0是用户级优惠, 5是账户总量优惠, 6是用户群总量优惠。
3 关于信用控制
免催免停、固网现金、固网银行托收、固网大户用户不参与信控;有隔月欠费的G网用户不参考信用度, 有隔月欠费的固网用户不参考停机阀值 (参与实时信控的固网设备) ;过户后如老账户下有未缴清的欠费时新账户不欠费也会停机, 不缴清老账户欠费, 新账号即使开机, 费用变化时还会停。
信控侧问题处理思路是查询用户系统内状态与问题描述是否一致;查询work表是否生成相应停开机工单, 停开机工单是否报错;未生成工单是否符合免处理规则;何类报错信息;正常生成的工单, 看俩小时内work表工单在crm侧trade表状态及指令侧状态;判断是否为信控侧规则问题。
缴费不开机, 欠费不停机等信控问题的多数原因为资料问题造成。具体从信控工单表ti_o_credit_work着手查询。信控问题需要o表oh表ohb表都得查询, 不能只查其中的一个表。o表处理成功后进入oh表, oh表1个月后进入ohb表, ohb表每隔一段时间进行清理。实时信用控制工单表ti_o_credit_dispatch字段process_tag为1处理成功, 3正在处理 (已生成催费工单) 。31赔付赠款是有历史欠费计入实时结余, 可以抵扣全部账目, 但是已停机用户做31赠款不会开机;131和79营销类赠款有历史欠费不计入实时结余, 无历史欠费时赠款结余计入实时结余, 已停机用户做赠款不会开机, 对部分全国sp账目项不进行抵扣。
参考文献
[1]谈竹贤.Oracle9iPL/SQL从入门到精通.[M].中国中国水利水电出版社, 2002.
[2]Bss维护手册.
3G对BSS系统的影响 篇2
3G网络为开展多业务提供了良好的平台, 3G在带宽、传输速率、Qo S方面都有显著的优势, 但是丰富业务对支撑系统提出更高要求。如何实现从众多的数据源有效采集, 如何与众多的合作伙伴实现结算, 如何确保遏制及流失;这些都是面向3G运营支撑急需解决的问题。
二、3G业务简介
目前从3G网络来看, 以客户使用情况来划分, 3G业务大致可以分成以下五大类。1.通信类:包括语音、可视电话、移动电子邮件、即时消息、统一消息、SMS等, 这些是电信运营商提供的基本业务, 也是其未来3G业务收入的主体。2.信息内容类:包括新闻类信息、位置信息服务、个性化定制、门户服务、移动广告。3.交易类:主要包括移动支付、移动银行、移动证券、移动保险、移动拍卖、移动订票等。4.娱乐类:如流媒体、个性化图片下载、个性化铃声下载、音乐下载/播放、网络游戏等。5.效率应用类:包括个人信息管理、个性化首页、移动办公、企业信息发布、移动企业资源调配等。
三、3G对采集的影响
引入3G业务后, 采集的完整性和实时性更成为关键。客户使用业务以后, 是否产生有效的记录并生成相应的报告, 数据的采集是否完整、实时、准确, 这些都可能产生收入流失。
采集可以由提供网元的设备厂商来提供, 但是关键是是否会对计费产生影响。同时3G引入了内容服务和大量的增值业务, 将产生大量的CDR数据。这些数据可以分为两种, 一种是手机上网数据, 另一种整合了多种增值业务 (包括:手机音乐、视频点播、炫铃等) 的VAC平台数据。引入中介采集系统后, 可以将大量的CDR数据直接分流, 将计费数据导入计费系统, VAC平台的数据过滤成代收、用户使用数据, 用户使用数据不参与计费可直接导入经营分系统, 分析用户的使用习惯等, 这样可以从很大程度降低计费系统本身的压力。
四、3G对计费系统的影响
3G时代是全业务竞争的时代, 各运营商全业务运营方式的转变对3G计费方式和计费要素有了更多的要求。同时复杂的价值链带来了复杂的运营模式, 也带来了复杂的结算模式, 给计费增加了复杂性。
3G业务的计费必须具备对各种业务及服务, 如语音、数据、影音流媒体内容和基础网络服务进行融合计费的能力。新的计费系统应能够实现不同计费模式间、不同网络平台间、不同业务间及预付费与后付费间的完美结合, 实现各种3G应用能够按照其对于用户的价值、按照运营商的要求进行分门别类的计费。通过一套系统来完成计费账务, 通过一套账务管理系统支持多项业务, 是非常重要也是能够有效降低成本的一个措施。
五、3G对结算系统的影响
3G业务正式投入运营后, 面临着很多的结算对象, 所以结算的压力可想而知。结算系统必须能够及时准确地采集到来自交换机、关口局和增值业务平台的数据。与所有提供业务的网元建立连接, 同时对所有采集环节建立监控体制, 避免收入的流失。
3G业务的种类繁多, 大大增加了结算系统的复杂程度;针对不同的合作伙伴, 不同结算规则, 结算周期可能不同, 结算方式也可能不同;需要建立一套针对合作伙伴的PRM管理系统, 此系统主要实现对合作伙伴资质、结算规则设置、投诉进行监管, 另此系统需要具备高度的灵活性和海量数据的处理能力。
六、3G对合作伙伴管理的影响
3G业务服务种类众多, 很受的客户的青睐。如何快速建立新的产品和应用, 如何快速发布, 这些是3G运营支撑的热点问题;需要建立完善的合作伙伴服务流程, 其内容包括应用的发布、服务定价管理、产品申请管理、合作伙伴关系管理、资质申请管理等, 在合作上建立自动化管理流程, 同时提供自助服务手段。
3G业务种类虽多, 但是服务与内容的盈利程度会有很大的差异;针对这种情况需要建立内容服务和应用的评估, 业务部门对业务提供者的内容、使用量进行有效的考核和评估, 以便可以了解最新的动态, 而且对不同的合作伙伴及时调整策略。
参考文献
商业智能在BSS系统中应用 篇3
商业智能代表为提高通信企业运营性能而采用的一系列方法、技术和软件, 它能够从BSS系统中获取各类客户数据和业务数据, 由此建立多层次的分析体系, 并将其转化成有商业意义的信息。商业智能把先进的信息化技术应用到整个企业, 不仅为企业提供信息获取能力, 而且通过对信息的开发, 将其转变为企业的竞争优势。商业智能系统对于企业发现市场新机会、创造竞争新优势的作用是显而易见的。
二、商业智能体系框架
商业智能通常被理解为将通信公司中现有的数据转化为知识, 帮助公司做出明智的业务经营决策的工具。这里的数据包括来自BSS系统的订单、欠费、现金交易、佣金、客户和渠道资料, 以及公司内部和其他运营商的结算数据。而商业智能能够辅助的市场经营决策, 既可以是操作层的, 也可以是战术层和战略层的决策。为了将数据转化为知识, 需要利用数据仓库、联机分析处理工具和数据挖掘等技术。因此, 从技术层面上讲, 商业智能技术并不是基础技术或者产品技术, 它是数据仓库、OLAP和数据挖掘等相关技术走向商业应用后形成的一种应用技术。
商业智能系统主要包括数据预处理、建立数据仓库、数据分析及数据展现四个主要阶段。数据预处理是整合企业原始数据的一步, 它包括数据的提取、转换和装载三个过程。建立数据仓库则是处理海量数据的基础。数据分析是体现系统智能的关键, 一般采用联机分析处理和数据挖掘两大技术。
三、商业智能在BSS中应用
商业智能及数据仓库在BSS系统中应用主要有以下几个方面。 (1) 客户关系管理。CRM的目标是以更好服务留住客户, 提高通话质量和利用率, 扩大市场份额;刺激“零次户”用户, 激活对公司业务兴趣;放弃信用度差和欠费久的用户, 降低运营成本和风险。要实现这个目标必须尽可能收集用户的资料信息, 利用数据挖掘技巧, 对无序、复杂的信息挖掘出想要知识及规律, 尽可能了解用户的消费行为。通过对数据分析, 不但能挽留老客户, 而且能吸引新的客户, 同时还能针对不同的客户采取不同的策略达到个性化服务。 (2) 账务分析。账务分析主要是从财务的角度来看的, 对计费、财务、账务进行分析, 通过对财务账务的分析, 可以清晰掌握公司每天运营收入和支出情况;可以对投资与收益进行详细的分析。 (3) 整合企业信息。数据仓库系统具有很高扩展能力, 支持超大容量的数据存储能力, 高效的查询响应能力和并行处理能力, 适合于整合公司内部和外部系统的数据, 使公司对客户信息的认知度达到一致性, 提升企业运营数据的内在价值。 (4) 市场经营分析。市场经营分析的主要内容是面向与电信运营企业市场活动密切相关的市场活动及其业务产品相关情况的分析。通过对提供的产品和服务的使用情况进行统计、分析和预测, 通过综合分析, 根据不同的地区、不同时段的分布, 提供相应的业务品牌和服务。在营销管理分析方面, 数据仓库对各渠道的客户发展情况、收入情况、业务量发展情况等指标进行不同角度和层次的分析, 能够从不同的层面和角度对所有渠道进行全面考察, 为制定合理有效的宣传促销及推广提供决策依据。 (5) 欠费与防欺诈行为分析。欠费和防欺诈行为分析是指在总结各种骗取或套取结算费用、欠费行为的内在规律后, 在数据仓库中建立一套欺骗行为和欠费行为规则库, 该规则需要动态维护, 不断更新, 当用户的消费行为与该库中规则吻合或类似就发出告警。这种分析能及时预警各种欺骗、套取、欠费, 使企业损失尽量减少;同时通过用户缴费和消费情况, 分析用户的信用度也提供很大的便利。
四、结束语
商业智能系统正逐步成为通信企业管理中一把面向未来竞争的利剑, 推动着整个企业管理实现数字化、精细化、科学化。同时, 商业智能也是一个年轻而充满希望的研究领域, 商业利益的强大驱动力将会不停地促进它的发展, 每年都会有新的商业智能的理论和应用问世, 随着商业智能应用的不断深入, 企业还将面临着更多的问题和挑战, 等待我们去深入探索和研究。
参考文献
BSS计费系统 篇4
电信支撑系统中以原九七系统为代表的业务支撑系统暴露出来功能重叠、业务僵化、对客户、市场、营销支撑不到位等诸多问题, 已经成为影响企业业务发展的瓶颈。九七改造中包括BSS、OSS和EAI三大部分的内容。其中, BSS部分实现前端CRM和后端Billing两个核心系统的整合, 通过核心共享数据区实现数据的完全共享;OSS部分实现服务开通及施工调度系统, 以及支撑业务提供必须的号线资源管理系统, 通过EAI平台和点对点服务调用等适用技术实现与BSS的流程集成、数据集成和系统互联。
BSS&OSS系统整合目标架构如图1所示:
二、BSS/OSS衔接关系与主要内容
BSS负责产品的配置定价, 客户接触和交互, 接收客户的各种服务要求;OSS提供业务开通、服务保障和资源管理等方面的基础支撑。BSS系统和OSS系统间存在数据、流程功能和接口三个层次上的衔接关系。
数据衔接主要表现在BSS和OSS系统间在员工、客户、产品、资源和定单等数据上的共享与交互, 保证信息编码和业务规则的一致;
流程功能衔接是BSS和OSS间最主要的衔接, 表现在BSS和OSS共同完成相关的业务功能, 如服务开通、割接通知等;
BSS系统和OSS系统间存在少量的接口衔接关系, 比如后端资源查询与选择等接口的共享;
BSS和OSS系间交互的核心流程是支撑服务的端到端开通流程。用文字可以概要表述为:CRM负责接收客户的服务请求, 生成销售订单, 并进一步分解为客户订单, 将客户订单按照原子服务提供分解并传递给服务开通系统;服务开通系统收到客户订单后转化为面向内部作业流程的服务定单, 调度后端资源配置和施工管理部门进行资源和服务的配置;客户订单内全部服务配置完成后, 将客户订单开通消息通知CRM系统同步进行服务启动, 生成完整客户数据并传递给计费等相关支撑系统。
围绕这一核心流程进行进一步分解, BSS和OSS之间主要存在以下接口的交互, 描述如图3所示:
三、BSS/OSS流程集成设计
3.1 总体方案
流程集成采用BPM+Workflow的架构, 尽量降低BPM与不同厂商各业务系统的耦合度, 如下图4所示:
图中MDB表示消息驱动BEAN, BC表示业务适配器, RA表示资源分配, IC表示集成收费, SP表示服务开通, SA表示服务激活。企业级流程部署在EAI平台上, 相当于企业流程总线, CRM、RA、SP等系统支持在总线上插拔部署, 通过统一的BC API与BPM交换。
3.2 流程建立阶段
BPM流程在流程建模系统中建立, 发布到EAI平台部署。RA、SP节点都是子流程, 例如:RA (资源分配) 子流程是配线、配号、配端口、电路调度等节点的组合;SP段 (服务开通) 子流程是施工节点的组合。RA, SP子流程支持发布到不同的业务并与因素相关。
子流程按名称标识, 提供按名称检索、缩略图等技术手段支持流程的发布和预览, 支持流程的查看和修改。
3.3 流程运行阶段
流程执行中根据业务相关因素匹配BPM流程, 生成BPM实例, 运行到相应的节点, 启动相关系统的子流程, 生成子流程实例。相关系统子流程结束后通知BPM流程, BPM流程继续向下流转。
提供流程运行情况视图的实现:BC根据BPM流程中运行的节点, 调用CRM、RA或SP系统服务, 返回子流程内运行情况。
提供综合查询, 如任务派发及完成情况的实现:BC根据流程环节分别调用CRM、RA或SP系统服务, 以BC约定的格式返回子流程内任务的派发及完成情况, 拼合为完整视图。
摘要：本文简要描述了电信支撑系统BSS与OSS的整合目标架构, 讨论了BSS与OSS衔接的主要内容, 最后提出了采用BPM+Workflow的两级流程架构实现流程集成的设计方案。
关键词：BSS,OSS,EAI,BPM,WorkFlow
参考文献
[1]冯铁, 张家晨, 陈伟等.基于框架和角色模型的软件体系结构规约.软件学报, 2000, 11 (8) :1078～1086
[2]蔡康, 中国电信计费模型总论, 2006年12月:12-23;
BSS计费系统 篇5
OCS (Online Charging System在线计费系统) 概念在3GPP R5中被首次提出, 中国联通根据自身的网络结构和业务模式的特点, 在基于3GPP R6定义的架构上, 制定了一套在线计费相关的解决方案。基于OCS的方案为中国联通建立标准化预付费产品, 实现对用户欠费控制、改善服务感知和快速开展新业务提供了良好的支撑。目前, 中国联通通过OCS系统支撑的2G、3G预付费用户已经超过6000万, 同时还有超过2亿的通过BSS系统以HotBilling方式支撑的后付费用户。
中国联通的OCS系统现状
中国联通集团于2008年开始进行OCS规划, 2009年全国开始实时计费系统 (OCS) 的建设, 并在2011年完成OCS系统V2.0规范的编制。甘肃省分公司在2011年将预付费用户全部由智能网割接至OCS系统承载, 并利用实时计费特性, 实现了顺利迁移76万用户、割接期间零投诉、不可回收欠费不足700元的好成绩。目前全部预付费用户均通过OCS系统承载, 2G在网出账用户超过90万。
1、当前面临的挑战
作为收入重点来源的后付费 (含准预付费用户) 采取了传统Hotbilling方式计费, 其与生俱来的缺陷形成难以消除的业务管理风险:严重的计费滞后, 批价滞后, 用户包月类消费和赠款销账滞后, 形成巨大的欠费管理风险。
不同产品类型并存、不同扣费模式并存同时造成了计费管理风险:在计费控制、用户产品定制及账户管理等多个方面存在交叉, 致使两个系统功能重复、配置繁琐、业务维护复杂、数据同步难度加大。
日趋激烈市场竞争中的服务感知和产品管理要求不断提高, 产品和服务缺陷也随之出现:传统的预付费用户生命周期管理已不能被用户所接受, 随着2G业务市场竞争日趋激烈、3G业务快速发展的急迫需求, 移动业务生命周期管理需要进行一次彻底的变革;以客户为中心的分级信誉度控制, 迫切需要实现针对2G、3G产品的统一信誉度支撑, 提升客户感知;从销售角度考虑, 需要通过可管理的涵盖移动业务、宽带业务、固定电话业务的全业务混合组网解决方案, 提升竞争力。
2、解决方案必须遵循的原则
为破解Hotbilling和OCS计费系统并存遇到的挑战, 重新定位营业、计费、账务三大BSS (业务支撑系统) 核心模块相互关系, 实现统一业务管理和支撑下的实时计费、产品灵活、快捷服务、风险控制迫在眉睫。重造BSS核心架构, 实现统一计费支撑, 必须遵循以下原则:
(1) 利用实时计费特性, 通过全业务OCS系统统一支撑, 降低欠费风险;
(2) 以客户感知角度出发, 立足于全业务统一生命周期, 才能改善服务;
(3) 从统一管理角度出发, 需要重新定位系统分工界面, 创新优化流程, 提升灵活性;
(4) 从风险管理和控制角度出发, 实现统一信控管理, 遏制经营风险。
重造以OCS为计费核心的BSS核心架构
1、重新定位BSS核心营业、计费、账务模块
现有OCS系统与Billing系统需根据OCS系统和Billing系统各自系统定位进行调整。根据对两个系统新的定位:OCS系统负责计费层管理, Billing系统负责帐务层管理;OCS系统的实时在线控制取代原有离线话单批价方式, 提高欠费风险控制能力;Billing专注于用户的帐务管理。如图1、2所示。
2、方案风险控制和业务管理的特点
(1) 统一预付费、准预付费、后付费三类用户生命周期管理;
(2) 支持预付费、准预付费和后付费所有付费方式、所有业务产品类型, 并可以可管理灵活混合组网;
(3) 支持各种信用额度管理;提供具有风险控制能力的欠费用户的单向停机服务;
(4) 对处于呼限状态的低概率缴费复机用户在HLR侧进行停机控制, 避免呼限用户长期在HLR侧为正常状态, 防止OCS遭受恶意攻击, 降低OCS系统负载;
(5) 支持用户在营业前台进行预约销户。
3、与企业技术规范要求的对比
对比中国联通《中国联通计费账务业务管理规范》, 新的解决方案不仅达到规范要求, 同时OCS作为唯一计费平台, 新增功能有:
(1) 跨账期的数据业务话单切割功能:根据临界资源片为切割条件对整个话单进行切割, 实现了跨账期的准确计费。
(2) 限制用户在某一时段内不能使用某项资源功能:如3G体验卡赠送流量资源只允许用户在每天0-8点之间使用赠送流量资源。
(3) 话单重批价功能:主要处理因套餐配置有误造成的扣费不准确、多用户使用过的业务进行重新计价, 回退之前使用的金额和累积量。
(4) 月底试算费提醒功能:用户账户余额已不足以支付下月的套餐月费, 提醒用户尽快充值, 以便不影响用户业务使用。
(5) 语音提醒 (AOC) 功能:对于用户余额在小于某个阀值后, 在用户通话前进行语音提醒和短信提醒, 增强用户感知度。
BSS核心架构重造后的主要功能实现方式
1、重塑用户生命周期管理
(1) 现有生命周期定义
中国联通在OCS系统V2.0规范中对传统的生命周期进行了完善, 完善后的生命周期图如图3所示。
(2) 新的生命周期和管控流程
打破传统的生命周期定义, 为OCS系统支撑预付费、准预付费、后付费用户定义一个统一的生命周期成为OCS系统用户规模发展中必须解决的问题。新生命周期图如图4所示。
新生命周期废除了有效期、充值期、锁定期定义, 以客户已经习惯并接受的准预付费、后付费生命周期为基础, 吸收预付费生命周期优点, 在确保用户使用习惯一致性前提下, 形成新的生命周期。
2、面向全业务的分级信用度统一管理
(1) 分级信用度统一管理
OCS系统增加对信用度的支撑, 支持基础信用度、动态信用度、临时信用度三种信用度类型, 支持VIP (钻石卡、金卡、银卡) 、非VIP各类信用等级。
CRM系统负责基础信用度、临时信用度管理, 负责动态信用度计算;OCS系统作为计费单元负责信用额度参与信控过程, 负责信用度有效期控制。
为了确保用户余额不足情况下紧急通信需求, 针对单停用户, OCS系统支持单停信控额度及有效期控制;针对后付费用户, OCS系统实现信用额度控制, Billing系统实现逾期控制。
(2) 信用度控制流程 (如图5-8所示)
3、优化后的一卡充充值
根据系统定位, 明确Billing系统负责统一缴费管理, 向外围系统 (第三方代缴费、电子渠道缴费、充值卡缴费等) 提供缴费通道。将目前OCS系统与两个缴费系统对接 (一是与Billing系统对接, 二是与一卡充充值系统对接) 改为OCS系统与Billing系统对接。如图9、10所示。
流程优化后的优点体现在:
(1) 一卡充系统不再与多个系统对接, 统一与Billing系统对接;
(2) Billing统一负责与一卡充和OCS系统的对账, 简化对账管理流程;
(3) Billing有全量充值记录, 不再处理OCS系统返回的一卡充充值记录;
(4) 营业、客服人员通过Billing系统准确查询充值记录, 方便投诉处理。
4、优化分月话费解冻/赠款流程
目前用户预存款、赠款解冻功能由BSS控制, 每月月初将用户解冻的费用传递给OCS系统;赠送功能由OCS控制, 每月月初自动将赠送费用存入用户账本。导致管理不统一、业务活动配置不统一、业务控制不统一等问题。
根据已明确的Billing系统负责账务控制原则, 优化现有流程, 解冻功能保持当前流程不变, 赠送功能改由Billing系统控制, 每月月初Billing系统将赠送费用传递给OCS系统, 最终实现活动管理、配置、业务规则统一由Billing系统控制。
5、灵活多样的扣费模式
从创新计费模式降低欠费 (欠费总额中的13%由于月初扣取月固定费导致) 和站在用户角度提升感知二个层面出发, 创建三种新的计费控制模式:一是针对包月不限资源使用类产品, 实现余额不足扣取月固定费时转按日扣取模式;二是包有效资源类产品, 实现余额不足扣取月固定费时转标准资费扣取模式;三是按固定费率收取费用, 用够定额资源时再赠送一定额度资源。新计费模式正式上线后, 除了可降低欠费率外还可降低月初扣取月固定费后弃卡率, 提升用户满意度。
6、支撑可管控的全业务混合组网
实现多业务、跨平台混合组网功能, 向集团客户提供2G/3G、移动业务/固话业务, 跨平台、跨业务的综合通信产品服务, 实现多业务间多平台间统一的集团资费及便捷应用, 将极大增强集团客户拓展的竞争力。但是, 此项功能涉及到业务支撑平台、网络支撑平台多个系统功能改造:
(1) 改造CRM系统, 实现混合组网业务受理及开通, 向周边HLR、SACP、综合智能网网元发送联机指令。
(2) 改造Biling、OCS系统, 共享混合组网集团及集团成员信息, 批价时根据共享表信息进行资费优惠。Biling、OCS系统分别配置相同的混合业务资费, 实现基于各自平台用户的资费优惠, 支持集团内包通话时长、集团间资费及集团外资费, 支持统一集团内2G、3G成员指定不同集团内通话时长包, 支持统一集团内移动业务、固网业务执行不同月功能费及集团资费。
(3) 改造VPN平台, 实现对混合组网集团用户VPN信息的统一管理, 支撑短号互拨, VPN平台与OCS平台通过DCC协议对接, 实现集团预付费用户使用语音业务的话务控制。如图11所示。
截至2012年12月, 甘肃分公司混合组网集团客户已经接近100个, 总用户数超过3000户。
OCS作为核心计费的未来
计费单元作为通信运营企业业务支撑系统 (BSS) 的核心, 其灵活性、响应速度决定了前端业务模式的多样性和用户体验的满意程度, 将现网基于Billing系统计费的所有用户迁移至OCS平台, 实现OCS系统作为唯一的计费单元实现全业务、全用户的实时计费, 将为业务支撑系统装上一颗强壮的心脏。
BSS计费系统 篇6
接下来看一下interdb与ACTDB之间的关系, 业务转发数据库与账务数据库同为关键业务数据库, 之间的关系较为复杂, 在开发设计、存储过程调用等密切相关业务处理时, 都做了较为密切的耦合, 而这个密切的关系又是通过建立数据库链接, 使用大量公用同义词的方式建立的。
ACTDB中用户bill被赋予以下权限:
sql>grant connect, resource, select any table, update anytable, insert any table, delete any table to bill;
然后, 在interdb数据库建立有指向ACTDB的数据库链接:
sql>create public database link ACTDB_LINK connectto bill identified by'***'using'ACTDB';
同时, 存在大量同义词, 如:
sql>create or replace public synonym tab_act_data fortab_act_data@ACTDB_LINK;
因为有了这个权限较高的数据库链接ACTDB_LINK, 和通过这个数据库链接建立的同义词, 使得在interdb中可以方便的对ACTDB数据库进行读取与DML操作, 但actdb和testdb之间还看不到有什么影响。
testdb现在与interdb和ACTDB之间有什么样的关系呢?下面进行几个操作, 看看结果是否在意料之中。
在testdb选取一个用户scott, 该用户只有connect角色权限和select any table权限。
操作1, 在本数据库testdb下执行对本数据库表的操作:sql>update int.tab_code_name set seq_id=555;ora-01031:insufficient privileges (权限不足)
操作2, 通过数据库链接执行对interdb的表操作:
SQL>up date tab_ineter_data@INTER_LINK seta aa='szx 5';ora-01031:insufficient privileges (权限不足)
操作3, 通过数据库链接执行对interdb指向ACTDB的同义词的操作:
SQ L>u p d ate ta b_a ct_d ata@IN TER_LIN K se tchange='2006';65 row updated
突然发现, ACTDB的数据严重的暴露在testdb的一个极低权限的用户下, 这个用户对interdb的数据是没有任何DML操作权限的, 甚至在testdb都只有很低的权限。这足以让一个开发设计人员惊出一身冷汗, 严重的安全隐患, 严重的设计缺陷, 但好像又不可思议, 逻辑上不应出现这种现象。这考验了数据库开发设计人员的长远思维, 甚至考验了DBA的洞察力。
来从数据库语句执行方式上分析一下这个虫洞效应出现的原因。熟悉oracle数据库技术的都知道, oracle数据库在执行一条语句时, 会先进行语句解析, 采取一种较为优化的方式来进行数据库的操作。当一条SQL语句从客户端进程传递到服务器端进程后, 需要执行如下步骤:
(1) 在共享池中搜索SQL语句的现有副本;
(2) 验证SQL语句的语法是否准确;
(3) 执行数据字典查找来验证表和列的定义;
(4) 获取对象的分析锁以便在语句的分析过程中对象的定义不会改变;
(5) 检查用户访问引用方案对象的权限;
(6) 确定语句的最佳执行计划;
(7) 将语句和执行计划载入共享的SQL区。
可以看到检查对象权限是在语句解析中执行的, 而发起采用数据库链接的语句相当于在客户端向目标数据库发送了一个SQL指令, 只是这个SQL指令被数据库链接又重新做了封装。而这个封装主要就是被赋予了数据库链接所具有的权限。这样可以分析操作3种的DML语句从testdb发起后经历了如何的变迁。首先, 语句在testdb经过验证, 目标对象先指向了interdb, SQL指令要通过INTER_LINK数据库链接转发到in terd b, 在interdb, 权限被赋予cxlink用户权限;在interdb上。发现它指向了一个同义词, 同义词又是根据ACTDB_LINK创建的, 这样, 这条sql指令又被传递到ACTDB, 注意此时, DML语句已通过ACTDB_LINK数据库链接获得DML (update) 操作的权限, 而此时, 该SQL指令才开始进行解析过程, 而对象的DML权限在此时已被间接赋予。
摘要：在业务支撑系统中, 由于各分系统数据库较多, 业务数据交互比较频繁, 也经常使用数据库链接的方式来实现业务的处理, 并且其中不乏有信赖度较高的数据库之间采用了同义词来方便在业务流程的开发与使用。同时由于复杂环境的存在使得这种方式存在潜在的安全隐患。文中通过实例的展现了安全隐患的产生过程及预防措施。
BSS计费系统 篇7
信息通信技术和行业正处在一个变革和发展的时期, 云计算、物联网、智慧星球、大数据等, 推动着包括经济、民生、知识获取、军事国防等领域的社会全面进步。
无论是社会需求还是企业发展, 信息通信的这些演进对今天的电信服务提供商和网络运营商提出了更高的要求, 并促进其在传统业务领域和新兴信息服务领域更有作为, 而运营支撑的创新和努力是其中关键组成部分。
从商务和技术的发展趋势来看, 以下OSS/BSS的发展方向值得重视。
OSS/BSS在云计算环境下的部署
云计算的发展已经成为大势所趋。除了开放Iaa S能力以外 (当前运营商注意力集中重点) , 运营商也开始重视内部IT应用在云计算环境下的部署。这可以降低IT建设和拥有成本, 提高系统的性能和可伸缩性, 提高系统对业务变化的适应能力。与此同时, 内部的云计算应用还将促进电信企业对外云计算服务水平的提高和业务的发展。目前, 运营商正在考虑将一些非关键的系统部署到云环境下 (主要是IaaS环境) , 对OSS/BSS的部署还较为慎重。从长远来看, OSS/BSS在企业云计算环境下部署, 甚至在公有云计算环境下部署是必然的趋势。
在云计算环境下部署OSS/BSS除了一般的安全、系统稳定性等问题以外, 还要考虑如何充分发挥云计算的优势及投入产出。为保证OSS/BSS在云计算环境下部署后能充分发挥优越性, 必须考虑OSS/BSS本身的体系架构, 例如:
·对现有系统进行有效解耦, 以适应云计算小粒度应用调度灵活的优越性;
·采用适当算法, 使得对计算能力要求较高的任务能够并行和分布处理;
·对系统进行抽象, 利用门户、广义编程、规则等服务关联技术, 降低服务对象和软件部署的关联程度、降低软件和硬件的关联程度。
OSS/BSS系统的一体化
由于移动互联网、云计算、大数据等业务的发展和企业管理的需要, 运营商十分重视集约化运营。当前OSS/BSS按省分散建设和部署的局面对集约化运营不利, 因此, 运营商逐渐重视OSS/BSS的一体化, 甚至整个企业IT系统的一体化。一体化并不意味着集中化, 而需要在良好规划的基础上, 使系统合理分布, 完成各种需要协调的复杂业务处理任务。
系统一体化的关键仍然在于规划和架构, 其中比较重要的工作包括抽象与解耦。当前运营商的IT规划还不能完全满足一体化的要求。在进行规划、实现OSS/BSS系统一体化时, 应当重视业界已有的框架成果的应用, 其中包括TOGAF、Zachman、Frameworx等, 在这些框架的基础上, 建立符合自己企业战略要求的IT规划, 使得系统建设有一定的抽象和解耦高度, 能够在收放自如地应付业务、技术变化和运营结构调整的前提下, 稳定运行, 平滑演进。
对能力开放的支持
随着企业经营和社会需求的发展, 运营商业务多样化趋势越来越明显, 其中一个重要的举措就是在能力开放方面的推进。电信能力开放实际上是将电信内部的能力平台化、服务化, 使外部的用户获得更为广泛的信息服务, 这将大大扩充服务的种类, 同时, 也帮助企业更好地培养客户忠诚度, 拓展各种业务。
能力开放使得面向客户的服务和资源多样化, 这与传统电信业务提供的方式有很大不同, 给运营支撑带来巨大挑战。它要求OSS/BSS系统更加灵活和开放, 能够根据客户方的要求迅速重组各种能力, 支持客户的应用和开发, 而这都是传统OSS/BSS所不具备的。
随着云计算业务的开展和云计算商务模式的拓展, 电信企业的能力开放不仅要着眼于传统的通信和服务资源, 也需要着眼于SaaS、PaaS等软件实现的服务。运营商所重视的“智慧城市”、行业信息化的云计算应用都属于这一领域。这些服务和传统的通信服务差别较大, 对它们的运营支持也存在较大挑战。OSS/BSS要更好支撑这类业务, 必须进行补充和升级。
为了使OSS/BSS能够支持能力开放所涉及的各种通信信息服务, 需引入新的概念和体系。例如TM-Forum正进行的e-TOM和ITIL的对接。它不仅可以丰富OSS/BSS的支持能力, 也使得OSS/BSS本身有可能作为对外服务的能力来使用, 因为客户使用运营商集成和提供的各种ICT能力, 在很大程度上是为了用信息通信技术实现对他们业务的支持, 其中自然要牵涉IT服务管理 (ITSM) 。