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