监理公司管理系统 | 工程企业管理系统 | OA系统 | ERP系统 | 造价咨询管理系统 | 工程设计管理系统 | 签约案例 | 购买价格 | 在线试用 | 手机APP | 产品资料
X 关闭

3G无线数据业务平台面临的八大技术问题

申请免费试用、咨询电话:400-8352-114

文章来源:泛普软件

.平台架构问题与标准兼容问题

比起2G,3G提供了更多、更复杂与更灵活的数据业务功能,进而带来了业务平台架构以及管理平台架构的困难。

3G出现了诸多的规范,每个规范都为3G的某方面指定了一个架构。目前主流的规范族有OMA、Parlay与JAIN。三个规范族各有侧重,亦有重叠。OMA关注于运营商现有的各项业务,例如,规范族包含了多媒体短消息服务、内容浏览与数字版权管理等。Parlay侧重于将网络层的能力开放出来,例如,规范族包含了呼叫控制,存在管理等。而JAIN则关注的内容上与Parlay类似,它的SPA API可以对应的Parlay的相应规范。JAIN的特点在于完全基于Java语言定义,并且提供了一套业务执行环境的标准--JSLEE,该标准使得服务供应商可以将功能接口组合成复杂的业务。
各种规范族给3G数据业务平台架构提供了基础,但也带来了问题。

1.规范的各种实现之间如何互联互通,互相之间是否可以划分出一定的层次关系?如何将这些不同的规范整合起来,构成完整的运营商3G数据业务平台?
2.这些规范没有涉及到业务管理层面上问题,如CP/SP管理,业务订购等。业务平台与管理平台如何互联互通?
3.规范本身还在演进过程中,某些规范并没有厂家的相应实现。
4.中国运营商是否要制定对等的规范?哪些规范族,或是规范族的某些规范可以直接采纳?
5.运营商应该将各种接口开放给CP/SP,是否应该区分CP/SP,给不同能力的CP/SP开放不同层次的接口?

2.实现技术路线问题

从平台开发语言而言,主要有C/C++,Java与C#。从组件模型而言有CORBA、J2EE与.NET。从互联互通的协议而言,主要有RMI、IIOP、Web Service、HTTP+XML等。
上述的各种语言与技术手段都已经比较成熟。从使用角度来说,每种技术适合的场合会有所区别。例如说,运营门户可以采取J2EE技术,而计费系统采用C/C++。对于运营商而言,整个3G平台包含了方方面面,不可能采用一种技术手段。运营商也不关注厂家产品本身采用何种技术。但是,每种技术都有自己的特点和弱点,而运营商在评估特定产品时,了解平台目标与厂商采用的技术路线的关系,会对产品选择有所帮助:

1.是否满足了足够的性能指标?通常情况下,Java/J2EE会慢一些。
2.是否具有足够的可伸缩性与健壮性?对于基于.NET的技术,需要重点考察这一点。
3.是否具有一定的平台独立性?
4.是否具有较好的可扩充性,包括增添新的功能,增加新的接口?基于C/C++技术的产品,在可扩充性方面会差一点。
5.是否满足了合适的功能指标?
6.平台是否提供了开放、易用的接口?通常情况下,Web Service接口最为方便,但是,其性能与功能较弱。

重要的是,厂家产品的内部实现技术会与其开放的接口存在着密切的关系,而接口提供的简单、方便与否,会直接影响到运营商面向CP/SP的门槛,会牵涉到不同平台之间互联互通难易。例如,大多数IT开发人员并不熟悉CORBA,如果一个产品--比如说Parlay网关--采用的是CORBA接口,这时运营商就需要考虑是否对部分接口进行打包后再开放给CP/SP,或是在选择产品时候,要求支持ParlayX接口。

3.集中与分布问题/漫游问题

每个运营商都至少存在着集团/省级两极管理机制,从3G业务平台的部署上,则存在着集中与分布问题,进而导致漫游问题。由于3G数据平台涉及到业务与管理等多个方面,因此,集中与分布问题并不是简单的采取哪种方式问题,而是哪些可以集中?哪些可以分布?当业务扩展时候,如何平滑地从集中过渡到分布?如果将平台粗略地划为管理与业务两类平台的话,这两类可以分开讨论。

1.管理平台的集中/分布

管理的分布来源于两个前提:

a)由于业务分布导致管理的分布;
b)在本地进行管理有便于业务的推广。当某些业务可以在本地管理时,调动本地电信管理人员的积极性,可以制定更灵活的接入与计费策略,吸引更多本地的CP/SP,依据本地用户的特点,开展本地特色的应用。

2.业务平台本身的集中与分布

业务的集中与分布问题相对比较简单。当业务量比较少时候,采取集中方式,当业务量变大,计算速度带宽、网络带宽不能满足需求时,则可以采用分布方式。在分布情况下,如果不同地点的业务之间需要互联互通,比如说短信网关之间需要互联互通,则可以构造专有协议,建立路由列表,达到互联互通的目的。另外,某些业务之间的互联互通,如MMS中心之间的互通,有专门的业务协议。

两个平台的管理与集中组合起来,通常有三种情况,业务平台集中 + 管理平台集中、业务平台集中 + 管理平台分布、业务平台分布+管理平台分布。通常不会出现管理平台集中+业务平台分布的情况。从集中与分布的过程来看,通常是:集中的业务平台+管理平台(从总部接入)--〉业务平台集中 + 管理平台分布(从本地接入)--〉(业务平台分布+管理平台分布)本地建立业务系统。
上面已经谈到,对于业务平台,由于业务之间的接口比较固定,而通常都会有专门的协议,因此,业务平台的本身的集中与分布相对简单。对于管理平台,如果采用分布方式,由于每个省公司的平台可能会由不同的厂商构造,则会牵涉到异构平台的互联互通问题。不同省公司/大区,省公司与总公司之间的互联互通的目的在于:

1.省公司与省公司,省公司与集团公司之间的计费与结算。不同省公司之间的结算在语音业务中也碰到,这里的难点在于在用户漫游过程中,会发生数据费用以及对CP/SP业务访问的业务费用。如果限制用户在漫游过程中,依然只是能够访问本省CP/SP的业务以及所全网接入的CP/SP的业务,则数据费用由漫游地计算,而业务费用由归属地计算。反之,如果用户在漫游过程中可以访问漫游地所在业务的话,则会涉及到用户信息或是CP/SP业务信息在不同省市之间共享问题,会比较复杂。

2.用户信息的迁移

用户在漫游过程中会接入漫游地所在的接入点。问题在于,当用户在漫游地时,是接入到漫游地的门户,还是接入到归属地的门户;用户是否可以访问漫游地的业务,还是只能访问归属地的业务。另外,在归属地会有一部分的用户设备信息,用户配置信息,这些信息是否需要复制到漫游地?

4. 与2G、2.5G系统互联互通/并存问题

目前为止,运营商都不同程度地拥有无线数据业务以及相关管理平台。当3G上线后,该如何处理这些平台非常重要。同时,对于部分运营商而言,原有的2.5G平台已经已经有了大量的内容,将内容平滑移植到3G上非常重要。因此,此处同样将该问题分为业务和管理两部分分析。

1)原有的业务平台是否保留?是否新的业务平台取代旧业务平台,还是将原有业务平台与新的业务平台互联互通?
上述问题的答案取决于业务的需要以及业务本身的特点。

例如,如果联通G网存在大量客户,并且在一段时间内长期存在,那么G网的短信业务、WAP业务确实都应该保留。同样,PHS的短信业务,移动的GRPS、WAP与短信业务在较长的一段时间内都会存在。应根据业务的特色,决定使用取代策略、互连策略,还是分离策略。比如说,原有的短信业务已经非常成熟,对短信平台升级,可能会涉及到接口的修改,会影响到现有业务,新的平台采用新接口,老平台采用老接口,两者通过网关实现互联互通,不影响现有业务,而且终端使用者也可以使用新平台上的业务。再比如说WAP业务,由于WAP规范本身具有很强的延续性,为了旧的终端可以使用新的业务,则可以采用升级或替代策略。而对于部分新业务,如下载业务,完全可以采取升级甚至是完全保留的方式。

2)对原有的管理平台是采用升级替换,还是两者并存的方式
该问题取决于原有平台在多大程度上能满足3G的需要。由于3G业务众多,业务采取的方式接入与计费方式更为灵活,因此管理平台的复杂度要高于原有的平台。如果希望保留原有平台,那么需要确认下列问题;

a)平台架构设计是否完整,有没有考虑到多业务接入的需要?有无考虑到不同类型的CP/SP接入与管理的需要?
b)用户模型、CP/SP模型具有极好的可扩展性。
c)管理流程可以用较为方便的方式定制或更改。

如果使用替代方式,那么需要考虑:

a)如何将对原有业务的管理平滑移植过去?
b)如何不影响原有业务的开展与运行?

5.灵活计费问题

从业务推广角度来说,最终用户希望账单简单、清晰并且易于预测。但是对于3G业务,由于运营商网络的另一侧还连接内容提供商,每个内容供应商的业务不同,采取的计费方式、计费标准也会有所不同,运营商需要根据与内容供应商签订的计费协议帮助计费。 因此,从计费软件角度来说,需要具有足够的灵活性。
具体而言,计费软件需要处理下列多个维度的灵活性:

a)面向不同业务与产品的计费

在3G环境下,增值业务类型非常丰富,同样是短信服务,提供电影院信息的可以比提供天气预报信息的更贵。同样是位置服务,查询自己所在位置与查询最近的餐馆价格也不一样。更重要的是,页面点击次数,短信发送次数并不能作为计费的标准。以WAP为例,通常只有对特定URL的成功的访问才构成计费的条件。以BREW与J2ME为例,客户端运行的小程序在与后端服务器的连接过程中,通常并不基于HTTP。

在对业务的计费中,也牵涉到运营商对内容供应商的管理问题,运营商需要确定内容供应商服务价格是否合理,需要在技术上排除最终客户未享受到合适的服务,却被错误计费的情况。
另外,如果一个计费系统需要处理不同业务类型的计费,则需要从不同的业务系统(如位置服务,短信中心,媒体服务器)中获得合适服务描述记录(SDR)。此时,每个业务系统需要有SDR采集系统。该系统与计费系统具有标准的协议接口。由于不同业务会由不同的厂家部署,因此,运营商需要定义合适的协议。

b)信道计费/流量计费/业务计费的交叉

对于运营商来说,短信/彩信可以根据条数计费,WAP可以根据点击,视频可以根据流量来计费。对于内容供应商来说,需要根据内容来计费。每种方式的计费采集点会有所不同,如流量计费会在GPRS接入点,短信在短信中心,而根据内容计费通常在CP网关处,彩信在发送过程中,也会花费GRPS流量。问题的难点在于,流量计费很难区分业务的不同,如果希望一部分业务按照一种方式计费,而部分业务按照业务或其他方式计费,则很有可能发生计费交叉的情况。

c)与不同利益团体的计费与结算。在3G环境下,为更好地拓展业务,架通增值业务价值链,运营商需要内容供应商,服务供应商,行业客户,企业大客户等不同利益团体进行合作,其合作模式,计费方式必然不相同。以企业客户为例,企业客户在使用运营商的网络设施过程中,并不直接通过无线业务盈利,因此,计费、结算方式必然有所区别。

另外,增值业务从技术角度来说,与地域并无直接的关系,一台放在因特网上的视频服务,既可以为北京的客户提供服务,也可以为上海的客户服务。但是,从业务管理、网络设施的使用,以及目前运营商的现状而言,会有区域问题。在此过程中,就会用户在漫游过程中如何进行计费,省公司之间如何结算的问题。

d)可以处理不同的优惠策略与打包方式,可以处理不同的计费方式。例如,可以按照访问时间、访问个人、访问个人所属团体等等进行优惠,可以支持预付费与后付费等。

6. CP/SP门槛问题

如果说3G将是业务之争的话,那么业务背后,开发业务、宣传业务的CP/SP将是关键的关键。在3G业务中,运营商与CP/SP之间的依赖性更为密切。
因此,对于运营商而言,数据业务平台应该给CP/SP提供方便,保证CP/SP可以高速地开发、部署与测试他们的应用程序,为了降低CP/SP门槛,需要解决下列问题:

1.接口复杂,过于底层

在原有的数据业务平台中,提供给CP/SP的接往往过于复杂,以短信为例,几乎所有的运营商的接口都牵涉到网络字节顺序,参数排序等TCP/IP Socket编程需求,而特定厂商提供的打包API互不相同,没有相关协议。

2.业务分类过于僵化,跨业务CP应用门槛过高。

与原有的2.5G平台不同的是,3G平台支撑的业务种类多,类型复杂,业务之间的复合度会越来越高。CP/SP将不再以短信、彩信等业务来分类,而是以用户群以及用户的需求来划分。例如,一个专门做游戏的CP或许同时使用彩信、位置服务、短信等多项业务。因此,平台应提供集成的接入方式与接入接口。应该可以提供一次接入,全业务接通服务。

7.管理平台与业务平台的关系问题

由于数据业务牵涉的业务较多,在原有运营商的平台中,通常是业务优先,业务之后才是管理,而在每上一个业务平台之后,都会牵涉到是否要加入管理功能的问题。此时,存在两种不同的情况:

1.业务平台本身具有完整的管理功能,如用户管理,计费等。例如,某些厂商的BREW下载服务器就具有较完整的业务管理功能。
2.业务平台本身没有管理功能,需要增加管理功能,或是接入到运营商的综合管理平台上。

如果每个业务平台都具有管理功能,随着而来的就是管理的混乱,因此,需要避免出现这种情况。目前为止,大多运营商都会有一个综合业务管理平台,该平台的目的在于对不同的业务做管理。但充分使用综合管理平台管理所有的业务还需要解决下列问题。

1.需要在业务上线之前,考虑到特定业务平台的特定需求,比如说,对于位置服务平台,有可能会有不同类型的CP/SP,有些行业用户仅仅使用定位功能,而有些GIS供应商提供地图服务,有些提供黄页数据,不同类型的CP/SP计费策略不同,这些,在构造综合管理平台都需要考虑到。这就需要综合管理平台有足够的灵活性。

2.由于不同的业务有可能属于不同业务部门管理,需要规范管理,避免出现面向特定业务的管理平台。

3.有些平台已经有了管理功能,而这些管理功能与业务功能息息相关,很难弃置不用,此时综合管理平台需要提供开放的接口,以便互联互通。

8.平台整合问题
在3G平台中,由于业务为不同的厂商开发,每个系统均有可能有各自的用户管理、计费、鉴权管理,CP管理会有分离的文档、分离的应用接口。如何将这些平台集成起来,形成完整的、统一的平台,具有统一的用户模型,集成的流程,集成的业务管理,这是在规划过程中必须要考虑的。

1.用户模型的整合

运营商需要定一个统一的用户模型。当业务增加时,由于特殊业务的需要,有可能会增加相关用户信息,因此,该模型必须具有足够的扩展性。另外,基于该模型的相关应用的实现也必须具有足够的灵活性,例如,当模型添加信息时,在用户管理界面上会有相关反应。
与此同时,该用户模型需要有开放的接口,可以与特定业务系统中的用户信息同步。同样,这种开放性也必须具有一定的灵活性,比如与用户信息的哪些字段同步,同步的流程如何,是否需要专人审批,甚至是人工干预后,才可以同步。这些,都对系统的实现提出了更高的要求。

2.CP/SP模型的整合

与用户模型类似,每个业务也可能会管理自己的CP/SP,需要运营商构造统一的、灵活的CP/SP模型以及相应的应用。

3.相关流程的整合

CP/SP的接入申请,接入后相关业务的开通,开通后的测试,新业务的申请等等,均需要更为自动化流程。

另外,由于数据平台本身以及足够复杂,将该平台与语音平台区分管理,将是一个较好的解决方案。当然,两者之间的边界问题是另一个值得探讨的问题。

来源:CCW

发布:2007-04-22 10:14    编辑:泛普软件 · xiaona    [打印此页]    [关闭]
沈阳OA系统
联系方式

成都公司:成都市成华区建设南路160号1层9号

重庆公司:重庆市江北区红旗河沟华创商务大厦18楼

咨询:400-8352-114

加微信,免费获取试用系统

QQ在线咨询

泛普沈阳OA快博其他应用

沈阳OA软件 沈阳OA新闻动态 沈阳OA信息化 沈阳OA快博 沈阳OA行业资讯 沈阳软件开发公司 沈阳门禁系统 沈阳物业管理软件 沈阳仓库管理软件 沈阳餐饮管理软件 沈阳网站建设公司