许建宏,刘永平 (.中讯邮电咨询设计院有限公司,北京00048;.中国联合网络通信集团有限公司,北京00033)
近年来,在国际信息产业发展迅猛的大背景下,国内电信运营商在增值业务方面也有了长足的发展。按照工信部的相关统计,2009年中国移动增值业务收入占营运收入的比重为29.1%,达到1 311亿元;中国电信增值服务收入占经营收入的比重为10.3%,达到215.33亿元,;中国联通GSM增值业务收入占GSM通信服务收入比重为27.3%,达到186.3亿元。2010年,移动增值业务市场规模超过2 000亿;2011年,移动增值业务市场规模将超过2 200亿元,年增长率差超过10%。
国内电信运营商在进行增值业务运营过程中,建设了大量的业务平台,如短信网关、短信互通网关、彩信网关、WAP系统、流媒体、Java下载、IVR系统、定位、应用商店等等。在通过这些平台向用户提供增值服务的过程中,包括用户、业务及产品认证、鉴权、计费等在内的服务策略管理一直是运营商关注的焦点。
在国际上,各标准化组织,如ITU、3GPP/3GPP2、OMA、Parlay等,基于研究重点不同,对业务平台的研究深度也不相同,对增值业务平台分别提出了不同的架构;但其共同的核心思想之一就是运营管理与能力提供的分离,认证、鉴权与控制则是运营管理的核心内容。在各国际组织的推动以及业务需求驱动下,电信运营商正将增值业务平台从垂直独立、条块部署模式,转向统一支撑管理的部署模式。
另一方面,在当前技术革新加速、各种产业面临融合的形势下,电信运营商不但需要应对传统电信行业内的竞争,也日益面临互联网厂商、广电、终端厂商等其他行业的竞争,面临管道化的风险。电信运营商在增值业务运营中,如何构筑合理有效的运营控制平台、整合内部服务资源至为重要,而理顺认证、鉴权等控制流程将是提高运营商核心竞争力的关键环节。
本文结合国内电信运营商增值业务运营的实际,对其中的认证、鉴权、控制方案进行具体阐述。
经过多年的建设,电信运营商已经普遍建成了一定规模的增值业务系统,原有业务系统的建设基本上都采用垂直体系结构。随着业务深入发展,新业务不断涌现,逐渐暴露出一些问题,并影响业务的进一步发展。统一的增值业务认证、鉴权、控制方案需要解决以下迫切问题。
a)增值系统条块分割,综合管理成本高。
b)业务开发与上线时间长。现有各业务系统自成体系,用户管理、定购关系管理、预付费接口分别实现,导致每新开发一种增值产品,都需要和BOSS、智能网等进行协调接口。
c)用户管理分散。现有增值业务的用户管理分散在各业务系统中,用户业务定制信息与账务信息分离,难以形成统一的客户视图,以开展针对性强的组合营销。
d)组合业务实现困难。现有各业务的实现流程相互独立,很难实现多业务的组合。
e)缺乏统一客服支持与展现。增值业务种类众多,但缺乏针对客服的统一支持,客服及营销人员难以统一获取、展示用户定购的业务资料并进行必要操作;用户难以从统一界面全面了解运营商业务。
f)业务计费分散。各业务单独计费,难以实现产品的组合销售。
鉴于以上原因,急需探索增值业务认证、鉴权、控制、管理的基本技术和业务管理模式,加强对增值业务的运营支撑。
在移动网架构中,设置了HLR等对移动网通信能力进行控制的网元。增值业务认证鉴权控制系统的设置,将形成增值业务网中的HLR,可以通过在其上设置参数,简便地实现各增值服务能力的开通、暂停、关闭,真正实现增值服务的模块化、产品化,提升用户感受,为增值业务的运营提供基本保障。
增值业务认证鉴权控制系统负责增值业务处理中公共的鉴权与数据管理。通过提取各业务运营中的认证、鉴权共性特点,形成统一接口与增值业务系统互联,负责业务运营中的核心控制;同时负责增值生产类数据的保存,负责BOSS支撑系统、业务系统、CP/SP间数据的传递。
认证鉴权控制系统总体定位如图1所示。
由于各种增值业务的运营、业务逻辑千差万别,为减少认证鉴权控制系统与具体增值业务及平台的耦合度,保证认证鉴权控制系统的稳定性、可实现性,需要抽象出其中共性的、和具体业务无关的鉴权、控制特性,并由此形成认证鉴权控制系统的核心功能(用户认证、用户鉴权、CP/SP状态鉴权、业务鉴权、定购关系鉴权、付费属性鉴权等),实现增值业务的统一控制。
2.2.1 认证
图1 认证鉴权控制系统总体定位图
认证功能负责完成增值业务运营中的身份合法性验证功能,其主要包括对用户身份、CP/SP合法身份的认证。
用户认证指的是对用户身份信息、状态信息、签约属性信息等的认证。
CP/SP的认证通过CP/SP接入号、IP地址、用户名、密码、端口、URL等综合认证。
2.2.1.1 用户身份认证
用户身份认证的目的在于对用户的身份进行确认、验证。针对不同接入方式的增值业务用户,针对用户的认证要求也不同。
对于移动增值用户来说,由于在接入电信运营商无线网络时已经采用了多重身份认证机制,从而保证了到达增值业务平台的用户身份本身都是可信的。因此在移动增值业务运营过程中,需要处理的主要是针对用户身份的保密处理。包括用户使用业务时,如果在增值业务平台、CP/SP之间传递的用户信息通过伪码来传递,而不是真实的手机号码时,认证鉴权系统需要支持用户伪码的生成、加密、解码与传递。使用伪码的目的是对CP/SP等外部系统屏蔽用户的手机号,根据业务信息确定是否使用伪码。认证鉴权控制系统在用户认证通过后,完成伪码与手机号的转换,在鉴权应答消息中返回给业务系统。
对于宽带用户来说,认证鉴权系统需要根据用户访问的IP地址对用户身份进行反查;或对用户访问业务时输入的用户账号信息进行验证。其中反查与验证工作均需借助于宽带接入认证系统(AAA)实现。
宽带用户IP反查流程如图2所示。
图2 宽带用户IP反查流程
a)增值业务平台向认证鉴权系统发起IP反查请求。
b)认证鉴权系统通过用户IP反查接口向宽带接入认证系统发起请求。
c)宽带接入认证系统返回结果给认证鉴权系统。
d)认证鉴权系统返回结果给增值业务平台。
接入账号认证流程如图3所示。
图3 接入账号认证流程
a)增值业务平台向认证鉴权系统发起用户认证请求。
b)认证鉴权系统通过用户认证接口向宽带接入认证系统发起请求。
c)宽带接入认证系统返回结果给认证鉴权系统。d)认证鉴权系统返回结果给增值业务平台。
2.2.1.2 用户状态信息管理
认证鉴权系统通过接口从BOSS获取所有用户的停开机状态信息,根据用户状态将号码分为白名单、灰名单、黑名单三大类。在业务运营中,对正常状态用户提供正常服务;对状态不正常的用户进行暂停部分服务或暂停全部服务处理。
对于白名单用户,增值系统向用户提供正常服务,增值系统向用户认证鉴权系统发起针对该用户的鉴权请求时,鉴权通过。
对于灰名单用户,增值业务系统暂停其所有订制类服务的正常使用,增值系统向认证鉴权系统发起针对该用户的鉴权请求时,鉴权不通过,对后付费用户不再产生原始话单,但保留该用户的定购类服务关系。当灰名单用户恢复为白名单用户时,认证鉴权系统针对当月用户计费按照正常处理,对后付费用户产生原始话单。
对于黑名单用户,增值系统向认证鉴权系统发起针对该用户的鉴权请求时,鉴权不通过。
2.2.1.3 用户属性信息管理
用户属性包括用户的付费类型、基本登记信息等。用户付费类型指用户开户时具体签约类型,包括预付费、后付费等。
用户在使用增值业务时,增值业务系统通过接口向认证鉴权系统发起实时用户鉴权请求,认证鉴权系统按照用户付费类型对用户进行鉴权,并对预付费用户进行实时计费处理,成功后向增值系统反馈信息;对后付费用户,产生原始使用记录。
2.2.2 定购关系管理
定购管理模块核心功能包括:接受来自业务支撑系统(如BOSS、客服、各种电子渠道)、用户直接发起的定购、退定请求,生成、取消定购关系,将定购关系信息同步给BOSS,将定购关系变化通知SP/CP等,对用户关于增值业务的使用进行定购关系鉴权。
用户定购、退定可以采用短信、WAP、Web、IVR和客服等方式,认证鉴权控制系统接受各种定购、退定消息请求,定购结果由发起定购方根据需要通知用户;定购、退定过程中认证鉴权控制系统负责和增值业务系统及BOSS进行必要的交互,定购、退定成功后,认证鉴权控制系统负责通知SP/CP。
认证鉴权控制系统负责按照用户属性要求完成用户定购、使用过程中的定购关系鉴权。在用户定购、退订过程中,认证鉴权控制系统在定购鉴权处理中需要保证用户在定购产品时在同一业务中只能定购其一种产品;对用户定购、退订的产品属性进行鉴权,判断能否在增值侧定购、退订。
2.2.3 CP/SP资料管理
CP/SP业务资料管理功能是认证鉴权控制系统对业务进行鉴权的基础。认证鉴权控制系统负责通过与合作管理系统的接口接收CP/SP资料数据,包括CP/SP静态配置数据、业务信息、产品信息等。
2.2.4 鉴权
增值业务系统向认证鉴权控制系统触发鉴权消息,由认证鉴权控制系统的鉴权模块完成具体的鉴权操作。鉴权包括用户鉴权、CP/SP状态鉴权、业务鉴权、用户定购关系鉴权、付费属性鉴权。认证鉴权控制系统按照以下步骤逐步鉴权。
2.2.4.1 付费方用户鉴权
a)对用户归属地进行鉴权,如果用户不属于本认证鉴权控制系统范围,鉴权失败,进入异常处理流程。
b)后付费用户根据用户状态进行鉴权,黑名单、灰名单鉴权失败,进入异常处理流程。
c)根据用户业务能力信息,判断是否开通相应业务,如未开通则鉴权失败,进入异常处理流程。
2.2.4.2 接收方用户鉴权。
2.2.4.3 SP鉴权
a)根据SP状态鉴权。非正常状态则鉴权失败,进入异常处理流程。
b)根据SP信用度鉴权。针对不同信用度,作不同处理。
c)根据SP区域鉴权。判断SP注册服务区域和使用的用户归属地是否一致,如不一致则鉴权失败,进入异常处理流程。
2.2.4.4 业务鉴权
a)根据业务属性鉴权。如果业务不允许此业务能力使用则鉴权失败,进入异常处理流程。
b)根据业务状态鉴权。
c)根据业务区域鉴权。判断业务注册服务区域和使用的用户归属地是否一致,如不一致则鉴权失败,进入异常处理流程。
2.2.4.5 定购关系鉴权。
2.2.4.6 产品鉴权
根据产品类型、属性和产品状态进行鉴权。
2.2.4.7 付费属性鉴权
根据用户类型判断,如果是预付费用户则进入实时计费流程。
2.2.5 计费支撑
对后付费用户,认证鉴权控制系统负责生成、保存统一格式的原始话单,并由BOSS系统采集后进行后续的计费、账务、结算处理。
对预付费用户,认证鉴权控制系统负责通过与实时计费系统的接口,实现预付费用户使用增值业务的实时计费。
2.2.6 配置管理
作为数据中心,认证鉴权控制系统通过接口将业务信息、SP业务能力信息、产品信息等配置信息同步给相关的业务系统,供业务系统使用。
2.3.1 BOSS方式业务定购流程
BOSS定购业务流程如图4所示。
步骤①:用户通过各种BOSS定购业务渠道发出定购请求。
步骤②:BOSS进行定购预处理,判断渠道来源,做用户状态等业务运营规则鉴权。
步骤③:BOSS向用户发起二次确认,用户回复确认。
步骤④:BOSS向认证鉴权控制系统发送定购通知。
步骤⑤:认证鉴权控制系统做定购鉴权,返回结果给BOSS。
图4 BOSS定购业务流程
步骤⑥:认证鉴权控制系统向增值业务平台或SP同步定购关系。
步骤⑦:BOSS负责通知用户定购结果。
2.3.2 增值业务平台门户定购流程
增值业务平台门户定购流程如图5所示。
步骤①:用户在增值业务平台门户发起定购业务请求。
步骤②:按照工信部统一要求,增值业务平台门户提供用户资费明示,二次确认。
步骤③:增值业务平台门户向认证鉴权控制系统发起定购请求。
步骤④:认证鉴权控制系统做定购关系鉴权。
步骤⑤:认证鉴权控制系统同步定购请求给BOSS,BOSS生成定购关系后返回响应。
步骤⑥:认证鉴权控制系统生成定购关系,给增值业务平台门户返回成功定购响应。
步骤⑦:增值业务平台门户通知用户定购结果。步骤⑧:认证鉴权控制系统同步定购关系给增值业务平台或SP。
2.3.3 增值业务使用流程
增值业务使用流程如图6所示。
步骤①:用户向增值业务平台发起业务服务请求。
图5 增值业务平台门户定购流程
图6 增值业务使用流程
步骤②:增值业务平台向认证鉴权控制系统触发鉴权计费请求。
步骤③:认证鉴权控制系统进行SP、业务、用户、定购关系等鉴权。
步骤④:认证鉴权控制系统向增值业务平台返回鉴权计费响应。
步骤⑤:增值业务平台向用户提供服务。
步骤⑥:增值业务平台向认证鉴权控制系统触发鉴权计费确认请求。
步骤⑦:认证鉴权控制系统向增值业务平台返回实时鉴权计费确认响应。针对步骤⑥、⑦,根据业务、产品具体运营方式选择实现。
步骤⑧:认证鉴权控制系统记录话单,或对预付费用户进行相应实时计费处理。
由于各种增值业务逻辑各不相同,导致鉴权控制实现过程复杂,难以形成统一的认证鉴权系统,并使鉴权系统建设陷入了条块分割的局面,对新业务的推出难以快速支撑。
通过本文研究,经过归纳现有增值业务运营的特点,提出了增值业务认证鉴权控制与具体增值业务处理逻辑无关的总体设计思路,通过对用户身份进行认证,以用户使用权限为核心,进而对用户的状态属性、费用属性、产品属性、业务属性、定购属性进行鉴权,最终形成了以用户为核心的增值业务认证、鉴权控制技术体系,解决了增值业务运营中认证鉴权实现困难、和业务系统耦合度高、对业务支撑范围小的突出难题。
在国内电信运营商全业务运营的情况下,认证鉴权控制系统的部署需要考虑移动、固网、宽带、互联网等各种增值业务的运营特点;另一方面,由于认证鉴权控制系统在增值业务运营中的核心地位,其系统安全性与稳定性也不可忽视。认证鉴权控制系统在建设初期可以采取集中设置,在演进过程中可以考虑按照业务分担的方式,并设置容灾备份中心,以保证系统的稳定运行。
对于集团、行业业务,认证鉴权控制系统部署中需要考虑这类业务自有的前后向计费特点、用户管理特点、增值平台设置特点。
在以往增值业务运营过程中,各增值系统自成体系,并通常采用以业务逻辑为核心的认证、鉴权控制方法,缺乏整体规划。通过在电信运营商建设增值业务认证鉴权控制系统,逐步形成增值业务网中的HLR,可以解决增值业务控制系统条块分割、业务开发与上线时间长等难题,能够较好适应3G时代互联网业务运营的需要。
需要指出的是,认证鉴权控制系统的部署涉及运营商现网中增值平台、合作伙伴、BOSS支撑系统、智能网等各个环节,因此需要妥善处理与各相关系统的接口、界面,以切实保障电信增值业务的长远发展。
[1]Server-Server Protocol Transport Binding V1.2.OMA Instent Messaging and Presence Service [EB/OL]. [2011-10-08].http://www.openmobilealliance.org/technical/release_program/imps_archive.aspx.
[2]3GPP TS 23.140 Multimedia Messaging Service Functional description[EB/S]. [2011-10-08].http://www.quintillion.co.jp/3GPP/Specs/23140-6g0.pdf.
[3]SMPP.Short Message Peer to Peer Protocol Specification [EB/OL].[2011-10-08].http://www.sms16.ru/content/smpp-sms-v3.4.pdf.
[4]WAP-247_100-PAP-20011010-a.Push Access Protocol[EB/OL].[2011-10-08].http://pudding.sharera.com/blog/BlogTopic/49989.htm.