中国联通企业信息化规划咨询项目3G规划组3G支撑演进专题规划 附录一 移动数据业务系统架构

《中国联通企业信息化规划咨询项目3G规划组3G支撑演进专题规划 附录一 移动数据业务系统架构》由会员分享，可在线阅读，更多相关《中国联通企业信息化规划咨询项目3G规划组3G支撑演进专题规划 附录一 移动数据业务系统架构（74页珍藏版）》请在装配图网上搜索。

1、中国联通企业信息化规划3G支撑演进专题规划-附录一中国联通企业信息化规划3G支撑演进专题规划附录一移动数据业务系统架构Sing Off PagePrepared by :Date :Reviewed by :Date :Date :Date :Date :Approved by :Date :变更记录RevisionDateDescription of Contents缩略语文档中所涉及的缩略语解释请参见下表。缩略语英文全称中文全称AOCAdvice of Charge计费通知APIApplication Programming Interface)应用程序接口ARPUAverage Reve

2、nue Per User每个用户带来的平均收入值BSCBase Station Controller基站控制器BSSBusiness Support System业务支撑系统CDMACode Division Multiple Access码分多址，扩频多址CDRCall Detailed Record通话详单CPDContent Provider Directory内容供应商目录CRBTCustomized Ring Back Tone个性化回铃音CRMCustomer Relationship Management客户关系管理CSGContent Service Gateway内容服务网关

3、CSRCustomer Service Representative客服代表DRMDigital Right Management数字版权管理DSLADigital Speech Level Analyser语音质量测试工具EAIEnterprise Application Integration企业应用集成ERPEnterprise Resource Planning企业资源规划GGSNGateway GPRS Support NodeGPRS支持节点网关GSMGlobal System for Mobile communication全球移动通信系统IMSIInternational Mo

4、bile Subscriber Station Identity全球移动用户识别号INIntellegence Network智能网IVRInteractive Voice Response交互式语音应答LBSLocation Based Service位置服务MCPMaster Content Provider集成内容供应商MDNMobile Directory number移动电话号码MPMobile Portal移动门户MSCMobile Switching Center移动交换中心MSPMaster Service Provider集成服务供应商MSSManagement Suppor

5、t System管理支撑系统OMAOpen Mobile Alliance国际移动标准机构OSSOperation Support System运营支撑系统PDSCPPrepaid Data Service Control Point预付费数据服务控制点PDSNPacket Data Serving Node分组数据服务节点PGPayment Gateway支付网关PMOProject Management Office项目管理办公室PPCPrepaid Postpaid Convergence预付费后付费融合PRMPartner Relationship Management合作伙伴管理PS

6、PVAGProvince Service Provider Voice Access Gateway地方性SP语音接入网关QoSQuality of Service服务质量SCGService Content Gateway服务内容网关SCPService Control Platform服务控制平台SDPService Delivery Platform服务交付平台SGSNServing GPRS Support NodeGPRS服务支持节点SLAService Level Agreement服务水平协议SMGShort Message Gateway短信网关SMSAhort Message

7、 Service短消息服务SMSCShort Message Service Center短消息服务中心SPMCService Provider/Content Provider Managing Center“炫铃”业务统一接入管理中心SPMSService Provider Management SystemSP管理系统SPSMGService Provider Short Message Gateway全国性SP集中接入网关SPVAGService Provider Voice Access Gateway全国性SP语音接入网关SSPService Swithing Point业务交换点

8、UMTSUniversal Mobile Telecommunications System通用移动通信系统VAGVoice Access Gateway语音接入网关WAPWireless Application Protocol无线应用协议目 录1.移动数据业务的系统分布现状82.服务交付平台（SDP）122.1.为什么要建立SDP122.2.SDP总体框架162.3.SDP功能架构182.3.1.第三方网关192.3.2.服务创建与执行202.3.3.服务代理212.3.4.服务控制222.3.5.服务集成232.3.6.终端客户端243.移动数据业务的未来系统架构253.1.目标253.

9、2.框架254.数据分布的现状与建议285.接口分布的现状与建议326.移动数据业务系统架构实施方案和流程建议366.1.实施方案介绍366.1.1.实施方案一366.1.2.实施方案二376.2.联通在信396.2.1.流程一：用户从手机发起订制396.2.2.流程二：通过短信退定406.2.3.流程三：通过手机点播416.2.4.流程四：通过SP的WEB页面定购/退定426.2.5.流程五：用户在网站上点播436.3.CDMA 1X业务446.3.1.WAP446.3.1.1.流程一：WAP访问流程446.3.1.2.流程二：WAP定购流程456.3.1.3.流程三：WAP退定流程466.

10、3.2.彩E476.3.2.1.流程一：通过WEB/WAP开通476.3.2.2.流程二：通过WEB/WAP撤销486.3.3.BREW496.3.4.LBS业务506.4.炫铃516.5.联通丽音526.6.联通秘书536.7.如意邮箱537.移动数据业务系统架构部署方案557.1.移动数据业务系统的部署方案557.1.1.对角线型部署方案557.1.2.垂直CRM部署方案557.1.3.垂直SDP部署方案567.1.4.部署方案的比较577.1.5.全国性和省分移动数据业务平台的部署577.2.SDP的场景演示587.2.1.新的全国性移动数据业务的开发上线587.2.2.订购一项全国性增

11、值业务（提供的位置服务为例）597.3.SDP实施案例607.3.1.案例一：Vodafone607.3.2.案例二：TIM逻辑架构627.3.3.对案例一与案例二的总结637.3.4.案例三：Orange637.3.5.案例四：CRM所起的作用648.附录698.1.厂商及产品699.参考资料701. 移动数据业务的系统分布现状根据3G支撑演进专题规划报告第三章的具体描述，我们得到图1-1，即：移动数据业务现有的相关系统图。图1-1 移动数据业务相关系统现状图其中绿色方块表示各个业务支撑系统。虚线框勾画出每个业务。包括如意邮箱、联通丽音、旋铃、短信、以及CDMA 1X增值业务等。CDMA 1

12、X增值业务又包括JAVA业务、BREW业务、WAP业务、彩E、位置服务、以及电子商务等。图1-2描述了CDMA 1X增值业务的系统现状。图1-2 CDMA 1X增值业务的系统现状图对CDMA 1X增值业务的现状描述： BREW、JAVA、LBS、WAP等各平台中均含有计费/批价功能及用户资料。 综合接入平台中包含用户定制信息、产品信息、以及用户状态信息。 省分营帐系统中含有客户基本信息，但是缺乏用户对移动数据业务的定制信息。存在的主要问题有： 用户的定制信息和帐户信息分属不同的系统，无法对用户定制情况和用户特性进行相关性分析，从而： 无法进行统一的客户服务 无法针对用户的使用习惯进行市场细分

13、用户无法在营业厅取消某项增值业务 业务平台中各自存在批价或计费功能， 无法实现产品组合营销 用户状态无法实时更新导致出项计费漏洞因此，对联通的整体系统支撑状况会产生如下影响： 难以统一客户视图 难以针对用户进行深层次分析 难以控制用户状态 难以开展产品组合营销之所以会存在这样条状垂直分布的系统，独立支撑各项业务，有其客观的历史原因。在移动数据业务应用开发的初期，由于按业务来划分开发小组，每个业务的支撑系统在开发过程中，都包含从网络界面、服务平台接口、BSS/OSS接口、目录和价格、内容、业务逻辑，直到展现逻辑的一整套完整的体系。各个开发小组之间不共享资源（见图1-3）。因此，每当新出现一个业务

14、，就需要重新开发一整套的支撑系统，这就导致目前的现状： 各种移动数据业务独立地垂直分布，相互之间无法共享已经开发的模块 用户信息重复地散落在各个业务系统 服务目录割裂，影响新服务推出的速度 对于用户来说，接入不同业务的通道是垂直并立的，网络接入界面冗余 图1-3 CDMA 1X增值业务的系统现状图2. 服务交付平台（SDP）2.1. 为什么要建立SDPSDP是标准的服务交付架构，它可以激发运营商的创新能力，在市场驱动下，能加速移动业务应用和固定业务应用的成功推出。如图2-1所示，多种多样的终端客户通过接入网连接到核心网，而SDP正是核心网与业务应用层之间的桥梁。它代替了原先核心网与各个业务应用

15、之间错综复杂的联系，通过集成、分层的内部结构，有效地降低了新产品/服务推出的复杂程度，缩短了新产品/服务推出的时间。 图2-1 SDP在网络中的位置图3G时代以产品/服务的丰富多样著称，未来产品/服务推出的复杂程度将远远高于目前的情况。举例说明如下：未来的产品推出将会涉及内容、支撑平台、界面及终端等诸多方面，具体地会涉及更多细节，比如内容格式、内容供应商的确定，又比如会面临对交付平台、定价模式/商业模式、诸多网络/系统的选择，还包括对用户界面、终端应用、终端功能等方面的处理。使用SDP架构的主要推动力如表2-1所示：表2-1 SDP驱动力分析 资料来自于欧洲某电信运营商驱动力商业优势技术优势K

16、PI及影响能加速产品/服务的推出 与产品提供商进行前向整合 具备快速的产品开发流程 具有整合的服务创建环境 原来的KPI：60天 目标KPI：64小时 收入增长10能支持融合 对融合的支持已经被证明 能担当起多个网络适配器的角色 融合的架构 与OSS/BSS有机地整合 原来的KPI：1NW，10个终端 目标KPI：23NW，100个终端 收入增长5整合之后能获得成本优势 有成功案例已经证实 已有定义的运营流程 平台的合并 厂商数量的减少 原来的KPI：100元运营费用 目标KPI：80元运营成本 运营费用、成本减少20为未来作贮备 大规模的运营模型改变 建立SLA/KPI交付的文化 服务导向的

17、架构 原来的KPI：总成本100元 目标KPI：总成本70元 总成本减少30某家欧洲运营商在成功推出SDP平台后的一年中，通过SMS、MMS、WAP、WEB、GPRS等渠道推出的增值产品/服务为收入带来了显著的增长。在这短短一年中，用户数增长了150，定制/使用服务的用户数增长了140，定制/使用在线服务的用户数增长则达到900之多。定制的服务总数增长了240，在线服务的定制数增长了460。具体趋势如下图所示：在线服务的定制数定制的服务总数定制在线服务的实际用户数定制服务的用户数用户数图2-2 SDP的成果用户数和服务定制量的增长图SDP帮助一家欧洲运营商实质性地减少了从产品创建到产品推向市场

18、整个过程所需的时间（4个月的时间缩短成1个月），并相应地降低了IT服务开发的成本（大约80左右）。如下图所示： 在使用SDP之前，开发一项产品/服务需要的开发、集成、测试总费用达到25.6万美元，耗时4个月之久。 在借助SDP之后，开发同样的产品/服务需要投资的总金额为3.2万美元，耗时一个月。 两相比较，可以看出，用SDP，可以将服务开发的时间缩小到原先的25，成本压缩到原先的12.5。图2-3 两种服务/产品开发方式的时间及费用比较图在增值服务和IP服务的创新领域，服务交付平台可以为无线运营商和有线运营商提供新的能力，如图所示： 为增值业务的开发及管理提供集成的环境。 能够支持灵活的计费方

19、式及融合计费（内容、流量、声音）。 能够将客户的数据统一管理。 能够控制外部服务提供商的集成。 能够实现接入控制和内容过滤。 能够管理所有的内容，并支持数字版权管理准则。 用这些能力可以有效地管理所有的服务，而且这些服务各自独立，可以来自不同的接入网。图2-4 SDP的概念介绍图2.2. SDP总体框架图2-5 SDP总体框架图上图是SDP总体架构图，其中灰色部分是SDP所涉及的范围。主要包含：第三方网关 向服务开发商系统提供服务服务创建与执行 创建、存放和交付基于内容的应用的环境 提供用来管理数字和多媒体内容的能力服务代理 通过对通用组件的重组和使用，来实现对新的复杂的服务的功能开发 简化与

20、其他IT/网络平台和SDP中组件的集成 控制外部服务提供商、合作伙伴、大客户的接入，并使其更安全服务控制 管理与网络的集成，并且主动控制资源的使用 提供管理静态和动态客户数据统一视图以及控制用户接入的能力服务集成 基础网络和应用服务：用来创建复杂的增值服务应用终端客户端 向用户的设备（包括移动电话、PDA、个人电脑） 提供软件，这些软件具有管理所有适用于不同应用的协议的能力2.3. SDP功能架构对上述六个模块进行细化，得到下图。图2-6 SDP二级框架图下文将对每个模块进行更细致的描述和分析。2.3.1. 第三方网关图2-7 第三方网关模块解析图第三方网关是安全地发布标准的、简化的对网络、业

21、务应用和BSS服务等的接触，实现认证，以及对那些由外部服务提供商发起的事件进行控制的模块。主要组件包括： 服务发布：是一种安全管理，也是第三方与运营商之间的单点接触，通常使用网页的常规方式来发布各种能力 服务请求处理：第三方运行中的请求管理，基于提供者的身份认可制度，提供认证和授权并将结果派发给合适的能力处理模块。 制度管理：对运营商的各种服务，第三方都需要有相应的认证制度，在这些认证制度的创建、更新、和删除过程中，制度管理是最重要的模块。 能力处理：主要负责与服务能力组件的接触管理，换言之也负责与 “核心”网络特征（如消息、计费、位置，等）及其他电信运营商应用和BSS服务的接触管理。 PRM

22、 接触：提供登录和跟踪的功能，用以获得所有事件的历史记录并将这些历史记录发送到运营商收入共享/结算/数据库平台 ，为财务分析提供依据。2.3.2. 服务创建与执行图2-8 服务创建与执行模块解析图服务创建环境由一系列“库”、软件开发工具包、以及配置工具组成 ，这些工具可以加快服务开发的速度并使服务开发更加容易。在这里详细说明了一个应用开发商所应该采用的所有标准和界面以及普遍的功能。内容管理 / 数字版权管理 组件提供服务套件，以简化基于内容的服务的开发： 内容发布与交付：它包含所有用来管理内容流入（收集、摄取、储存）的功能，并包含用来创建内容索引目录、在最终发布前校验和审查内容的功能； 内容集

23、成与联合：对向第三方发行人和/或多渠道/多方式的内容交付进行支撑（例如，桌上电脑、手机、个人数字助理，等）； 搜索引擎： 具备搜索和获取特殊内容的特点； 数字版权管理：处理数字版权及内容创造者的版税问题，确认用户对内容的使用是否恰当，等； 个性化定制：该引擎允许在已获得的用户数据（隐匿的）和用户直接请求（公开的）基础上，创造一对一的通信和促销方案。创建环境为开发、整合、获得、和管理分布式的以服务为导向的应用提供了基础设施和条件。2.3.3. 服务代理图2-9 服务代理模块解析图接入与安全 功能域主要负责标准的和简化的界面与内部应用和第三方接触，同时对认证进行控制，并提供安全接入到电信运营商“核

24、心”SDP的能力。服务功能 功能域 使一系列普遍的和可再利用的特征以及复杂的流程成为可能，这使得应用能够影响交付的内容和服务： 将收到的请求分派给合适的非同步的工作流； 控制那些多步骤流程的事件序列； 允许存在不同时的流程创建，以及不同时的通信事件； 执行规则，储存用来定义流程的元数据； 在出现突发事件或者出错时，能妥善处理； 能处理对所有与应用、业务流程相关的报告。连接 功能域控制那些与周围平台互相影响的通信功能、 路由、数据转换等必要的转换，等。2.3.4. 服务控制图2-10 服务控制模块解析图统一目录 功能域 实现标准的界面用以普通数据的恢复和更新 终端信息： 是用户在接入服务交付，进

25、行内容选择和播放等过程中，用户终端的技术数据的仓库（屏幕大小，清晰度，浏览限制，等各种参数） 用户信息： 完整的客户视图（个人信息，偏好数据，定购信息，任务，接入，等），是提供个性化服务和发起市场营销/促销的关键 服务信息：提供的服务的目录，这些服务配以商业和技术的说明 第三方目录：外部服务提供商的信息列表（消息名录，主页URL，内容目录URL，简要介绍，等）控制与安全 功能域将所有增值业务应用所需要的接入控制特征集中起来 基于应用中用户身份的联合，实现单点登录(SSO) 储存和管理与会话相关的信息 接收和管理与用户网络接入相关的事件，更新统一目录上的展现信息 管理所有接入服务和平台的规则在线

26、服务管理 功能域使在线交互成为可能， 在交互过程中，网元探测以得到网络使用的实时信息2.3.5. 服务集成图2-11 服务集成模块解析图网关/ IF 使应用和第三方能简单和标准地接入网络能力，而不像以前那样基于复杂的网络协议接入（如：SS7，INAP，等）服务平台 支持固网/移动网络上的内容应用，这些内容应用具备如下特点： 内容代码转换： 负责编码和格式转换；编码是指将模拟信息流数字化的过程 （例如，从实况信号转换为mpeg 2格式）；格式转换是指将已存在的内容转换成不同的格式（例如，从Real格式的视频转换为Windows Media格式的视频） 提示管理：该引擎允许在不同渠道上计划和执行群

27、发信息给用户组，这些用户组可以是基于时间触发的（不包括上午8点），也可以是基于事件的（不包括，在足球赛记分后） 下载配置/终端配置：允许通过OTA消息进行终端配置，允许在移动电话上进行文件下载的操作 即时信息服务器： 使即时信息服务成为可能，并且可以与统一目录交互用以控制用户的存在性 位置服务： 管理所有地图和地理信息用来交付基于位置的服务和内容网络服务 是网络提供的在不同渠道用来与用户交互的一个基础功能2.3.6. 终端客户端图2-12 终端客户端模块解析图我们认为终端客户端领域是SDP的一部分，是因为随着终端软件的多样化（Series 60，Microsoft，等），为了确保与服务和内容的

28、协同性，对用户配置管理的需求在不断增长。此功能域提供了那些用来管理所有不同应用所需协议的软件，这些软件适用于各种用户终端（如，移动电话，PDA， PC机）。3. 移动数据业务的未来系统架构3.1. 目标第一章已提出传统的移动数据业务开发模式所存在的问题： 传统的移动数据服务应用开发方法（垂直式的，并且为每一个业务建立一个全功能的模块)不再适合今天的市场状况和技术趋势， 模块的冗余导致了一些效率低下的问题； 数据的分散导致了难以建立全业务的视图和客户统一视图； 难以开展跨传统语音业务和增值服务，甚至是增值服务各业务间的组合营销； 新的业务推向市场速度缓慢。 在新的移动数据服务的场景下，有必要引入

29、一种能让各业务应用共享能力模块（这些模块应该是基于标准技术，并且易于使用）的开发方式，以便更充分有效地利用有限资源、以及节省新业务开发所需的时间。 基于此，我们提出SDP开发方式并在上一章对SDP的概念和框架进行了详细的介绍。在中国联通移动数据业务领域引入SDP，主要是为了能够： 便捷地提供统一的客户视图，尤其是统一的产品定制信息，改善客户感受。 使配置产品目录、定价、组合营销和促销等的服务特性和应用更加灵活方便。 为开发不同种类的服务提供通用的基本API。 简化内部和外部系统的应用集成。 最小化新服务开发和推向市场的成本和时间。 使与第三方应用的互动更加安全和可控。 采用标准的技术使得不同平

30、台产品间的交互更加方便。 使联通的IT架构面向未来。 易于扩展，系统更加稳定和安全。3.2. 框架为实现上述目标，我们根据联通的实际情况和埃森哲公司过去的经验，提出移动数据业务相关系统的SDP框架（如图2-1所示）。 建立以功能为主的分层系统架构，如服务创建与执行、服务代理、服务控制、服务集成，等。 把与业务支持有关的两大功能及三大信息整合到BSS系统，其中，两大功能指计费功能、结算功能，三大信息指用户信息、定制信息、产品目录信息。 逐步统一SDP中的服务控制层，即：将服务控制模块标准化，用以支撑各个业务的服务控制功能。同时我们也建议以EAI联系SDP与BSS的数据传输及更新，减少目前系统之间

31、借口繁杂的现状。图3-1 移动数据业务相关系统的SDP架构图(目标）具体来看： 第三方网关将包含CP网关等。 服务创建与执行层将包括所有业务应用的开发模块，诸如BREW开发模块、JAVA开发模块、WAP开发模块等。 综合接入平台将纳入服务控制层，用户信息、定制信息、产品目录信息也会在这里储存。服务控制层里的IP服务控制点也会是实现内容计费的主要模块。 在服务集成层将会包含内容格式的转换、下载/终端的配置、即时终端服务器、电子邮件服务器、流媒体服务器、提示管理等模块。接下来以全国性移动数据业务为例，给出建议的架构（如图2-2所示）：图3-2 全国性移动数据业务SDP架构图给出具体建议如下： 由C

32、RM统一负责面向客户的服务，用户可以在CRM中实现增值业务的开通、定制、暂停、取消及其他客户服务。 统一管理产品目录和计费，实现跨业务的产品组合。 减少新增值业务开发和推向市场的时间，同时提高整个体系的安全性。 对目前的SP与用户欺诈控制提供一定的IT支撑。为此，需要进行如下操作 计费/结算/SP管理功能将从增值业务各系统中剥离，依次分别由BSS中计费、结算、PRM模块实现。 SDP负责与增值服务交付相关的功能，比如负责服务的开发、满足来自客户的服务请求，等。 省分CRM里存储产品目录、用户信息、服务订购关系等数据, 并向总部SDP同步必要的鉴权、认证信息。 SP/CP提供的新服务服务，经总部

33、PRM的准入流程后进入产品目录，并在总部SDP中开展具体业务。 今后移动数据各相关业务的系统建设应按照SDP的架构开展。 省分SDP架构基本与总部SDP结构类似。4. 数据分布的现状与建议通过实地调研、以及与各个业务支撑系统厂商之间的多次沟通，我们了解到：目前，移动数据业务的数据分布呈现出零散的分布状态（如图3-1所示）： 几乎在每种业务的支撑系统中都存在本业务的定制信息，如：邮箱管理系统、旋铃的CRBT管理控制平台、总部SP管理系统 一次批价后的详单分布在所有CDMA 1X业务系统（包括JAVA、BREW、彩E、LBS、电子商务业务应用）以及增值业务大区业务平台和WAP业务省分业务平台中，除

34、此之外，还分布在短信网关中，而且，联通丽音业务、旋铃业务和联通在信业务在短信网关中的一次批价详单是独立分布的。 服务内容数据主要存在于联通丽音、旋铃、及所有CDMA 1X增值业务的支撑系统中，主要包括总部及省分的语音业务管理平台、旋铃全国接入管理中心、旋铃CRBT管理控制平台以及各个CDMA 1X增值业务的业务应用平台。 使用事件原始详单主要是分布在CDMA 1X各增值业务应用平台中，在其他移动数据业务的支撑系统也重复存在，如：如意邮箱管理系统、全国语音接入网关、语音增值业务接入网关、旋铃CRBT管理控制平台、短信网关、全国性SP短信网关、以及总部SP管理系统，等。 总之，从图3-1可以得到，

35、目前的数据分布不利于信息的共享和同步，当用户同时定制或者使用多种移动数据业务的时候，很容易由于业务支撑系统之间的割裂、数据分布的杂乱无章而使客户的感知度不一。而且当用户同时使用多种业务的时候，很难对客户进行准确的计费，难以进行有效的信用管理和余额控制，给管理带来诸多问题。图4-1 移动数据业务数据分布现状图通过对数据分布现状的描述，我们总结出移动数据业务数据分布上存在的严峻问题。基于此，我们给出解决的思路和建议（见图3-2，）： 将用户资料、定制信息、产品目录信息纳入CRM系统。 将与SP/CP的结算信息纳入PRM系统。 二批后的详单与其他计费信息纳入综合计费帐务系统。 在未来某个适当的时点，

36、将SP/CP关系管理信息纳入PRM系统。 在未来某个适当的时点，将费率信息纳入到综合计费帐务系统中去。 在适当的时候，将一批也纳入到综合计费帐务系统中去。图4-2 移动数据业务数据分布建议逻辑图在图3-2给出逻辑关系的基础上，我们给出更具体的数据分布建议图，涵盖总部和省分的BSS系统域（见图3-3）： 总部BSS系统域 将用户资料、定制信息、产品目录信息纳入CRM系统。 将与SP/CP的结算信息、全国性SP/CP关系管理信息纳入PRM系统。 省分BSS系统域 将用户资料、定制信息、全国产品目录信息（含费率信息）纳入CRM系统。 将与SP/CP的结算信息、SP/CP关系管理信息纳入PRM系统。

37、二批后的详单与其他计费信息纳入综合计费帐务系统。 在未来某个恰当的时刻，将一批相关数据纳入综合计费帐务系统。图4-3 移动数据业务数据分布建议图（含省分）5. 接口分布的现状与建议在与各业务支撑系统厂商的多次沟通后，根据从厂商处收集到的有效材料，我们理顺系统之间的关系，画出移动数据业务主要相关系统目前的接口示意图（如图4-1所示）。从图中可以看到： 接口复杂且繁多。 各个移动数据业务都有独立的与省分营帐的接口。 几乎每个业务都有独立的与SP/CP的接口。图5-1 移动数据业务支撑系统的接口分布现状示意图 具体的系统接口说明如表4-1所示。表5-1 移动数据业务部分系统接口说明（现状）接口编号系

38、统1系统2接口说明接口内容数据传送形式C1-D1SP/CPSPMC准实时/批处理音源文件、业务资料、铃音定制信息等文件C1-D2SP/CPCBRT实时/准实时/批处理音乐文件、业务资料、铃音定制信息等文件/消息包D1-D2SPMCCBRT实时/准实时/批处理铃音文件、业务资料、定制信息、信息费详单、SP/CP基本资料等B1-D1SP管理SPMC准实时/批处理SP管理服务系统将通过审核的全国SP/CP的企业基本资料发送到SPMC指定的目录下文件A1-D1接入管理平台SPMC实时铃音定制信息消息包A1-E1接入管理平台各CDMA1X业务应用平台D1-A2SPMC结算平台准实时/批处理信息费详单文件

39、A3-D2省分营帐CBRT准实时/批处理详单信息、用户资料及其变更信息、注册注销信息文件C1-E1SP/CP各CDMA1X业务应用平台A1-A2接入管理平台结算平台批处理计费结算的话单、SP基本信息、SP业务信息、投诉统计信息文件A1-A3接入管理平台省分营帐A2-B1结算平台SP管理A2-E1结算平台各CDMA1X业务应用平台实时/准实时/批处理二次批价后的详单记录、详单的核对统计文件、用户帐单记录、费率描述代码与优惠描述代码信息、结算结果、详细业务投诉信息等文件A2-A3结算平台省分营帐实时/准实时/批处理二次批价内容详单、日接收详单的核对统计文件、SP实收统计信息、SP基本信息、SP业务

40、信息、费率描述代码与优惠描述代码信息等文件A3-F1省分营帐SPMS批处理黑名单等A3-F3省分营帐SMGF1-F2SPMSSPSMGC1-F2SP/CPSPSMGF2-F3SPSMGSMGC1-G2SP/CPSPVAGG1-G2TTSSPVAGG2-G3SPVAGVAG针对上述存在的系统接口问题，我们给出SDP与BSS/OSS系统接口的建议。图4-2是建议的总部SDP与总部/省分 BSS系统的接口分布图。图5-2 总部SDP与总部/省分BSS系统接口的建议图 具体描述见表4-2。表5-2 总部SDP与总部/省分BSS系统接口的说明接口标识源系统目标系统接口内容接口频率接口方式BSS和OSS接

41、口A0-B0客户关系管理系统SDP平台产品目录信息周期自动A0-B1合作伙伴管理系统SDP平台合作伙伴准入信息周期/实时自动A0-B3SDP平台总部综合采集系统详单实时自动A0-C0省分客户关系管理系统SDP平台定制信息、用户信息同步实时自动SDP平台省分客户关系管理系统定制信息、用户同步实时自动A0-C3省分综合计费帐务系统SDP平台帐户余额信息实时PULL图4-3是建议的省分SDP与省分BSS系统的接口分布图。省分SDP与BSS/OSS系统接口图（建议）图5-3 省分SDP与省分BSS系统接口的建议图具体描述见表4-3。表5-3 省分SDP与省分BSS系统接口的说明接口标识源系统目标系统接

42、口内容接口频率接口方式BSS和OSS接口A0-B0省分客户关系管理系统省分SDP平台产品目录信息同步周期自动省分SDP平台省分客户关系管理系统定制信息、用户信息同步实时自动A0-B1省分合作伙伴管理系统省分SDP平台合作伙伴准入信息周期/实时自动A0-B2省分综合计费帐务系统省分SDP平台帐户余额信息实时PULLA0-B3省分SDP平台省分综合采集系统详单实时自动6. 移动数据业务系统架构实施方案和流程建议本章将给出建议的移动数据业务系统架构的实施方案。同时对主要的移动数据业务目前的部分主要的定制、使用流程进行现状描述，如果必要也会给出需要的修改。方案的主要出发点就是要使用户资料在（特别是CR

43、M系统）与服务控制层之间准确、及时地同步。6.1. 实施方案介绍6.1.1. 实施方案一方案一的思路为：区分服务的定制、服务使用的流程；但CRM与SDP定制过程松耦合。服务定制的流程和服务使用的流程如图5-24所示。图6-24 CRM与SDP松耦合实施方案示意图 具体说明如下： 移动数据业务管理平台（SDP的控制层） 保留定制关系，移动数据业务产品目录和必要的用户状态。 CRM也拥有定制关系、产品目录和用户信息。 管理平台与CRM以（近）实时方式相互同步定制关系的变化。 CRM向SDP同步产品目录和用户状态。 数据发生矛盾时，以CRM的数据为准。 此方案既加强了管理也利于实施。6.1.2. 实

44、施方案二实施方案二的思路主要为：区分服务的定制、服务使用的流程。服务定制的流程和服务使用的流程如图5-25所示。图6-25 区分服务定制与服务使用的实施方案示意图服务定制的步骤为：1、用户向CRM发出定制请求2、CRM将定制关系传至管理平台3、对包月等当时即需扣费的服务，进行计费4、管理平台将确认定制成功的信息发给CR* 服务定制、取消、暂停都是走这一条线路服务使用的步骤为：1、用户使用服务的请求传至移动数据业务管理平台2、管理平台将使用请求传至各业务应用3、服务响应* 服务使用也可能要进行计费，图中未标出这一方案对于数据的一致性和及时同步起到了更好的保证，但是也加大了CRM系统的实时压力。因

45、此我们根据联通的具体实际，没有加以推荐，可以在未来合适的时候进行改造。在国际上也有系统在移动数据业务的控制中不但参与定制，而且参与服务使用控制的案例，由于同样的理由，我们在此对该方案不加介绍和推荐。下面将介绍主要的移动数据业务的业务流程，同时我们基于方案二的假设(涉入到客户对移动数据业务的订购、取消等定制服务中),提出了相关的修改建议。读者可以发现，所有对流程的改变都可以只涉及现有的控制层对应系统（比如说联通在信得控制层对应系统是SPMS）和规划中的CRM（必要时也可用现有营帐替代）。尽管我们在某些流程的建议中可能有CRM与其他系统地交互，但是那只是使流程更加清晰，易于理解。读者可以很简单的修

46、改为只有CRM与该业务的相应控制层系统地交互的方案。同时，对于方案一的流程改造，与方案二是相似的；主要的区别在于方案二中CRM的控制力度减弱。所谓控制力度的减弱，是指，在方案二中，所有的定制请求无论从哪里进来，首先要通过CRM的确认后才能在SDP中生效；但在方案一中，由SDP侧发起的定制请求，可以直接得到SDP的确认和生效。尽管SDP需要及时将该定制信息通知CRM，同时CRM也可以取消SDP中的定制关系。6.2. 联通在信6.2.1. 流程一：用户从手机发起订制图6-1 用户从手机发起订制（现状）图图5-1给出用户从手机发起定制的现状，步骤如下：1. 用户发起MO订制；2. SPMS以SP的接

47、入代码发资费明示及确认通知；3. 用户按提示重发订制命令；4. SPMS将订制命令送SP；5. SP下发订制成功的信息到SPMS；6. SPMS以SP的接入代码下发通知短信给用户。图6-2 用户从手机发起订制（建议）图图5-2是我们建议的用户从手机发起定制的流程图，步骤如下：1. 用户发起MO订制；2. CRM以SP的接入代码发资费明示及确认通知；3. 用户按提示重发订制命令；4. CRM将订制命令送SPMS；5. SPMS将订制命令送SPMS；6. SP下发订制成功的信息到SPMS；7. SPMS 下发订制成功的信息到CRM；8. CRM以SP的接入代码下发通知短信给用户。6.2.2. 流程

48、二：通过短信退定图6-3 通过短信退定（现状）图图5-3给出通过短信退定的现状，步骤如下：1. 用户用手机发送退定请求 2. SPSMG提送退定请求给SPMS3. SPMS完成退定操作并将退定成功的消息返回SPSMG4. SPSMG将退定成功的消息发给用户5. SPMS将退定成功的消息通知SP图6-4 通过短信退定（建议）图图5-4给出通过短信退定的建议，步骤如下：1. 用户用手机发送退定请求 2. SPSMG提送退定请求给CRM3. CRM将退定请求发给SPMS4. SPMS将退定成功的信息发回给CRM5. CRM将退定成功的信息发给SPSMG6. SPSMG将退定成功的信息发给SMG7.

49、SPMS将退定成功的信息通知SP6.2.3. 流程三：通过手机点播图6-5通过手机点播（现状）图通过手机点播的步骤如下：1. 用户用手机发起MO点播 2. SPMS生成关于该MO的LINKID，填入保留字段，将该点播请求发送给SP 3. SP下发点播的短信息经SPMS鉴权成功后发送到用户建议：不作改变6.2.4. 流程四：通过SP的WEB页面定购/退定图6-6 通过SP的WEB页面定购/退定（现状）图目前，通过SP的WEB页面定购/退定的步骤为：1. 用户在web页面定购/退定2. SP将用户定购/退定信息提交给SPMS3. SPMS以SP的接入代码发资费明示及确认通知4. 用户 确认5. S

50、PMS告知SP用户定购/退定6. SP确认此定购退定请求7. SPMS通知用户定购/退定成功图6-7 通过SP的WEB页面定购/退定（建议）图建议通过SP的WEB页面定购/退定的步骤为：1. 用户在web页面定购/退定2. SP将用户定购/退定信息提交给SPMS3. SPMS将定购/退定信息发给CRM4. 定购/退定信息写入CRM5. SPMS以SP的接入代码发资费明示及确认通知6. 用户确认7. SPMS告知SP用户定购/退定8. SP确认9. SPMS通知用户定购/退定成功6.2.5. 流程五：用户在网站上点播图6-8 用户在网站上点播（现状）图目前，用户在网站上点播的步骤为：1. 用户在

51、web页面点播SP业务2. SP将用户点播请求送SPMS3. SPMS以SP的接入代码向用户下发资费明示、校验码 4. 用户在web页面填写校验码后提交给SP 5. SP下发点播的短信息经SPMS鉴权成功后发送到用户 建议：不作改变6.3. CDMA 1X业务6.3.1. WAP6.3.1.1. 流程一：WAP访问流程图6-9 WAP访问流程（现状）图目前WAP访问流程的步骤为：1. 用户的访问请求通过PDSN和WAP网关的预处理，到达相关CP网关和平台2. 相关平台将请求转发到对应的SP3. SP将请求的结果发回给相应平台4. 经由相应网关发送给用户终端建议：不作改变6.3.1.2. 流程二

52、：WAP定购流程图6-10 WAP定购流程（现状）图目前WAP定购流程的步骤为：1. 用户定购请求通过PDSN和WAP网关的预处理，到达相关平台2. 相关平台处理请求并将结果发送给相应的SP3. 将结果发送给全国管理中心4. 相关平台将定购结果通过WAP网关发送给用户终端图6-11 WAP定购流程（建议）图建议WAP定购流程的步骤如下：1. 用户定购请求通过PDSN和WAP网关的预处理，到达CRM2. CRM认证用户的合法性后将定购请求发送给大区平台3. 相关平台处理请求并将结果发送给相应的SP4. 将结果发送给全国管理中心5. 相关平台将定购结果反馈给CRM6. 由CRM通过WAP网关将定购

53、结果发送给用户终端* 请求在步骤1到达CRM前可能经过大区平台转送6.3.1.3. 流程三：WAP退定流程图6-12 WAP退定流程（现状）图目前WAP退定流程的步骤为：1. 用户的退定请求通过PDSN和WAP网关的预处理，到达用户接入大区CP网关2. 用户接入大区的业务选择路由将请求转发到归属大区的WAP门户3. WAP门户调用用户归属大区退订接口4. WAP门户将退订结果返回给接入大区的CP网关5. 退订结果返回给用户图6-13 WAP退定流程（建议）图建议WAP退定流程的步骤如下：1. 用户的退定请求通过PDSN和WAP网关的预处理，到达CRM2. CRM将退定请求转发给接入大区CP网关

54、3. 用户接入大区的业务选择路由将请求转发到归属大区的WAP门户4. WAP门户调用用户归属大区退订接口5. WAP门户将退订结果返回给接入大区的CP网关6. 接入大区的CP网关通知CRM7. 退订结果返回给用户6.3.2. 彩E6.3.2.1. 流程一：通过WEB/WAP开通图6-14 通过WEB/WAP开通（现状）图目前通过WEB/WAP开通的步骤为：1. 用户通过WAP或WEB方式申请开户2. U-IMAP服务器向综合管理平台请求认证手机用户合法性3. 综合管理平台返回手机用户合法性信息/状态信息及手机用户的相关信息（如IMSI号码），若手机用户非法，则拒绝提供服务，否则则进行下一步4.

55、 U-IMAP服务器通过短信网关向用户手机发送确认数字串，以确认用户身份5. 用户填入接收到的确认数字串，填写用户资料，选择资费套餐并提交。U-IMAP服务器完成后续的开户操作6. 将用户开通信息通知综合管理平台7. 获得综合管理平台的反馈8. 通知用户彩E业务已开通成功图6-15 通过WEB/WAP开通（建议）图建议通过WEB/WAP开通的步骤如下：1. 用户通过WAP或WEB方式申请开户2. U-IMAP服务器向CRM请求认证手机用户合法性3. CRM返回手机用户合法性信息及手机用户的相关信息（如IMSI号码），若手机用户非法，拒绝，否则则进行下一步4. U-IMAP服务器通过短信网关向用

56、户手机发送确认数字串，以确认用户身份5. 用户填入接收到的确认数字串，填写用户资料，选择资费套餐并提交。U-IMAP服务器完成后续的开户操作6.3.2.2. 流程二：通过WEB/WAP撤销图6-16 通过WEB/WAP撤销（现状）图目前通过WEB/WAP撤销的步骤为：1. 用户通过WAP或WEB方式申请撤销2. U-IMAP服务器告知综合管理平台3. U-IMAP服务器完撤销并由短信网关告知用户图6-17 通过WEB/WAP撤销（建议）图建议通过WEB/WAP撤销的步骤如下：1. 用户通过WAP或WEB方式申请撤销2. U-IMAP服务器告知CRM3. U-IMAP服务器完撤销并由短信网关告知

57、用户6.3.3. BREW图6-18 BREW平台业务流程示意图（现状）图见图5-18，BREW一期流程说明如下：1、用户连到高通BDS的ADS（下载服务器）上；2、ADS把信息传给CTXN（计费服务器），产生一次批价话单3、一次批价话单传给IBM相关平台的计费模块进行合帐4、传给联通总部进行结算目前BREW二期正在建设中，具体流程说明如下：1、用户通过WAP/WEB等展现层浏览BREW业务2、用户MB直接连到BDS的ADS服务器上进行下载操作3、由CTXN模块传相关数据到BREW二期平台的计费模块产生一次批价话单4、由BREW二期平台传合帐（或二批结果）给联通总部结算平台进行结算5、二期增加的业务功能有：赠送、推送、推荐，BI，客服，网管BREW业务由于中国联通无法完全控制用户的定制和使用，建议流程暂时不做改变。6.3.4. LBS业务图6-19 LBS业务流程示意图（现状）图图5-19是对LBS业务流程的描述，说明如下：1、MPL有计费模块，但在真正运作时，还是在 WAP里计费，直接与SP分成2、总部与12个省通过L1接口连接3、用户与PDL通过19801连接业务流程描述如下：1、用户端请求通过WAP网关到达SP处2、SP辨识其为定位服务，向MPL发出指令3、MPL经由SP向用户端发送IP信息4、用户端与MPL会话5、MPL作出回应6