3G無線數(shù)據(jù)業(yè)務(wù)平臺面臨的八大技術(shù)問題

申請免費試用、咨詢電話：400-8352-114

．平臺架構(gòu)問題與標準兼容問題

比起2G，3G提供了更多、更復(fù)雜與更靈活的數(shù)據(jù)業(yè)務(wù)功能，進而帶來了業(yè)務(wù)平臺架構(gòu)以及管理平臺架構(gòu)的困難。

3G出現(xiàn)了諸多的規(guī)范，每個規(guī)范都為3G的某方面指定了一個架構(gòu)。目前主流的規(guī)范族有OMA、Parlay與JAIN。三個規(guī)范族各有側(cè)重，亦有重疊。OMA關(guān)注于運營商現(xiàn)有的各項業(yè)務(wù)，例如，規(guī)范族包含了多媒體短消息服務(wù)、內(nèi)容瀏覽與數(shù)字版權(quán)管理等。Parlay側(cè)重于將網(wǎng)絡(luò)層的能力開放出來，例如，規(guī)范族包含了呼叫控制，存在管理等。而JAIN則關(guān)注的內(nèi)容上與Parlay類似，它的SPA API可以對應(yīng)的Parlay的相應(yīng)規(guī)范。JAIN的特點在于完全基于Java語言定義，并且提供了一套業(yè)務(wù)執(zhí)行環(huán)境的標準--JSLEE，該標準使得服務(wù)供應(yīng)商可以將功能接口組合成復(fù)雜的業(yè)務(wù)。
各種規(guī)范族給3G數(shù)據(jù)業(yè)務(wù)平臺架構(gòu)提供了基礎(chǔ)，但也帶來了問題。

1．規(guī)范的各種實現(xiàn)之間如何互聯(lián)互通，互相之間是否可以劃分出一定的層次關(guān)系？如何將這些不同的規(guī)范整合起來，構(gòu)成完整的運營商3G數(shù)據(jù)業(yè)務(wù)平臺？
2．這些規(guī)范沒有涉及到業(yè)務(wù)管理層面上問題，如CP/SP管理，業(yè)務(wù)訂購等。業(yè)務(wù)平臺與管理平臺如何互聯(lián)互通？
3．規(guī)范本身還在演進過程中，某些規(guī)范并沒有廠家的相應(yīng)實現(xiàn)。
4．中國運營商是否要制定對等的規(guī)范？哪些規(guī)范族，或是規(guī)范族的某些規(guī)范可以直接采納？
5．運營商應(yīng)該將各種接口開放給CP/SP，是否應(yīng)該區(qū)分CP/SP，給不同能力的CP/SP開放不同層次的接口？

2．實現(xiàn)技術(shù)路線問題

從平臺開發(fā)語言而言，主要有C/C++，Java與C#。從組件模型而言有CORBA、J2EE與.NET。從互聯(lián)互通的協(xié)議而言，主要有RMI、IIOP、Web Service、HTTP+XML等。
上述的各種語言與技術(shù)手段都已經(jīng)比較成熟。從使用角度來說，每種技術(shù)適合的場合會有所區(qū)別。例如說，運營門戶可以采取J2EE技術(shù)，而計費系統(tǒng)采用C/C++。對于運營商而言，整個3G平臺包含了方方面面，不可能采用一種技術(shù)手段。運營商也不關(guān)注廠家產(chǎn)品本身采用何種技術(shù)。但是，每種技術(shù)都有自己的特點和弱點，而運營商在評估特定產(chǎn)品時，了解平臺目標與廠商采用的技術(shù)路線的關(guān)系，會對產(chǎn)品選擇有所幫助：

1．是否滿足了足夠的性能指標？通常情況下，Java/J2EE會慢一些。
2．是否具有足夠的可伸縮性與健壯性？對于基于.NET的技術(shù)，需要重點考察這一點。
3．是否具有一定的平臺獨立性？
4．是否具有較好的可擴充性，包括增添新的功能，增加新的接口？基于C/C++技術(shù)的產(chǎn)品，在可擴充性方面會差一點。
5．是否滿足了合適的功能指標？
6．平臺是否提供了開放、易用的接口？通常情況下，Web Service接口最為方便，但是，其性能與功能較弱。

重要的是，廠家產(chǎn)品的內(nèi)部實現(xiàn)技術(shù)會與其開放的接口存在著密切的關(guān)系，而接口提供的簡單、方便與否，會直接影響到運營商面向CP/SP的門檻，會牽涉到不同平臺之間互聯(lián)互通難易。例如，大多數(shù)IT開發(fā)人員并不熟悉CORBA，如果一個產(chǎn)品--比如說Parlay網(wǎng)關(guān)--采用的是CORBA接口，這時運營商就需要考慮是否對部分接口進行打包后再開放給CP/SP，或是在選擇產(chǎn)品時候，要求支持ParlayX接口。

3.集中與分布問題/漫游問題

每個運營商都至少存在著集團/省級兩極管理機制，從3G業(yè)務(wù)平臺的部署上，則存在著集中與分布問題，進而導(dǎo)致漫游問題。由于3G數(shù)據(jù)平臺涉及到業(yè)務(wù)與管理等多個方面，因此，集中與分布問題并不是簡單的采取哪種方式問題，而是哪些可以集中？哪些可以分布？當業(yè)務(wù)擴展時候，如何平滑地從集中過渡到分布？如果將平臺粗略地劃為管理與業(yè)務(wù)兩類平臺的話，這兩類可以分開討論。

1．管理平臺的集中/分布

管理的分布來源于兩個前提：

a）由于業(yè)務(wù)分布導(dǎo)致管理的分布；
b）在本地進行管理有便于業(yè)務(wù)的推廣。當某些業(yè)務(wù)可以在本地管理時，調(diào)動本地電信管理人員的積極性，可以制定更靈活的接入與計費策略，吸引更多本地的CP/SP，依據(jù)本地用戶的特點，開展本地特色的應(yīng)用。

2．業(yè)務(wù)平臺本身的集中與分布

業(yè)務(wù)的集中與分布問題相對比較簡單。當業(yè)務(wù)量比較少時候，采取集中方式，當業(yè)務(wù)量變大，計算速度帶寬、網(wǎng)絡(luò)帶寬不能滿足需求時，則可以采用分布方式。在分布情況下，如果不同地點的業(yè)務(wù)之間需要互聯(lián)互通，比如說短信網(wǎng)關(guān)之間需要互聯(lián)互通，則可以構(gòu)造專有協(xié)議，建立路由列表，達到互聯(lián)互通的目的。另外，某些業(yè)務(wù)之間的互聯(lián)互通，如MMS中心之間的互通，有專門的業(yè)務(wù)協(xié)議。

兩個平臺的管理與集中組合起來，通常有三種情況，業(yè)務(wù)平臺集中 + 管理平臺集中、業(yè)務(wù)平臺集中 + 管理平臺分布、業(yè)務(wù)平臺分布+管理平臺分布。通常不會出現(xiàn)管理平臺集中+業(yè)務(wù)平臺分布的情況。從集中與分布的過程來看，通常是：集中的業(yè)務(wù)平臺+管理平臺（從總部接入）--〉業(yè)務(wù)平臺集中 + 管理平臺分布（從本地接入）--〉（業(yè)務(wù)平臺分布+管理平臺分布）本地建立業(yè)務(wù)系統(tǒng)。
上面已經(jīng)談到，對于業(yè)務(wù)平臺，由于業(yè)務(wù)之間的接口比較固定，而通常都會有專門的協(xié)議，因此，業(yè)務(wù)平臺的本身的集中與分布相對簡單。對于管理平臺，如果采用分布方式，由于每個省公司的平臺可能會由不同的廠商構(gòu)造，則會牽涉到異構(gòu)平臺的互聯(lián)互通問題。不同省公司/大區(qū)，省公司與總公司之間的互聯(lián)互通的目的在于：

1．省公司與省公司，省公司與集團公司之間的計費與結(jié)算。不同省公司之間的結(jié)算在語音業(yè)務(wù)中也碰到，這里的難點在于在用戶漫游過程中，會發(fā)生數(shù)據(jù)費用以及對CP/SP業(yè)務(wù)訪問的業(yè)務(wù)費用。如果限制用戶在漫游過程中，依然只是能夠訪問本省CP/SP的業(yè)務(wù)以及所全網(wǎng)接入的CP/SP的業(yè)務(wù)，則數(shù)據(jù)費用由漫游地計算，而業(yè)務(wù)費用由歸屬地計算。反之，如果用戶在漫游過程中可以訪問漫游地所在業(yè)務(wù)的話，則會涉及到用戶信息或是CP/SP業(yè)務(wù)信息在不同省市之間共享問題，會比較復(fù)雜。

2．用戶信息的遷移

用戶在漫游過程中會接入漫游地所在的接入點。問題在于，當用戶在漫游地時，是接入到漫游地的門戶，還是接入到歸屬地的門戶；用戶是否可以訪問漫游地的業(yè)務(wù)，還是只能訪問歸屬地的業(yè)務(wù)。另外，在歸屬地會有一部分的用戶設(shè)備信息，用戶配置信息，這些信息是否需要復(fù)制到漫游地？

4. 與2G、2.5G系統(tǒng)互聯(lián)互通/并存問題

目前為止，運營商都不同程度地擁有無線數(shù)據(jù)業(yè)務(wù)以及相關(guān)管理平臺。當3G上線后，該如何處理這些平臺非常重要。同時，對于部分運營商而言，原有的2.5G平臺已經(jīng)已經(jīng)有了大量的內(nèi)容，將內(nèi)容平滑移植到3G上非常重要。因此，此處同樣將該問題分為業(yè)務(wù)和管理兩部分分析。

1)原有的業(yè)務(wù)平臺是否保留？是否新的業(yè)務(wù)平臺取代舊業(yè)務(wù)平臺，還是將原有業(yè)務(wù)平臺與新的業(yè)務(wù)平臺互聯(lián)互通？
上述問題的答案取決于業(yè)務(wù)的需要以及業(yè)務(wù)本身的特點。

例如，如果聯(lián)通G網(wǎng)存在大量客戶，并且在一段時間內(nèi)長期存在，那么G網(wǎng)的短信業(yè)務(wù)、WAP業(yè)務(wù)確實都應(yīng)該保留。同樣，PHS的短信業(yè)務(wù)，移動的GRPS、WAP與短信業(yè)務(wù)在較長的一段時間內(nèi)都會存在。應(yīng)根據(jù)業(yè)務(wù)的特色，決定使用取代策略、互連策略，還是分離策略。比如說，原有的短信業(yè)務(wù)已經(jīng)非常成熟，對短信平臺升級，可能會涉及到接口的修改，會影響到現(xiàn)有業(yè)務(wù)，新的平臺采用新接口，老平臺采用老接口，兩者通過網(wǎng)關(guān)實現(xiàn)互聯(lián)互通，不影響現(xiàn)有業(yè)務(wù)，而且終端使用者也可以使用新平臺上的業(yè)務(wù)。再比如說WAP業(yè)務(wù)，由于WAP規(guī)范本身具有很強的延續(xù)性，為了舊的終端可以使用新的業(yè)務(wù)，則可以采用升級或替代策略。而對于部分新業(yè)務(wù)，如下載業(yè)務(wù)，完全可以采取升級甚至是完全保留的方式。

2)對原有的管理平臺是采用升級替換，還是兩者并存的方式
該問題取決于原有平臺在多大程度上能滿足3G的需要。由于3G業(yè)務(wù)眾多，業(yè)務(wù)采取的方式接入與計費方式更為靈活，因此管理平臺的復(fù)雜度要高于原有的平臺。如果希望保留原有平臺，那么需要確認下列問題；

a）平臺架構(gòu)設(shè)計是否完整，有沒有考慮到多業(yè)務(wù)接入的需要？有無考慮到不同類型的CP/SP接入與管理的需要？
b）用戶模型、CP/SP模型具有極好的可擴展性。
c）管理流程可以用較為方便的方式定制或更改。

如果使用替代方式，那么需要考慮：

a）如何將對原有業(yè)務(wù)的管理平滑移植過去？
b）如何不影響原有業(yè)務(wù)的開展與運行？

5.靈活計費問題

從業(yè)務(wù)推廣角度來說，最終用戶希望賬單簡單、清晰并且易于預(yù)測。但是對于3G業(yè)務(wù)，由于運營商網(wǎng)絡(luò)的另一側(cè)還連接內(nèi)容提供商，每個內(nèi)容供應(yīng)商的業(yè)務(wù)不同，采取的計費方式、計費標準也會有所不同，運營商需要根據(jù)與內(nèi)容供應(yīng)商簽訂的計費協(xié)議幫助計費。 因此，從計費軟件角度來說，需要具有足夠的靈活性。
具體而言，計費軟件需要處理下列多個維度的靈活性：

a)面向不同業(yè)務(wù)與產(chǎn)品的計費

在3G環(huán)境下，增值業(yè)務(wù)類型非常豐富，同樣是短信服務(wù)，提供電影院信息的可以比提供天氣預(yù)報信息的更貴。同樣是位置服務(wù)，查詢自己所在位置與查詢最近的餐館價格也不一樣。更重要的是，頁面點擊次數(shù)，短信發(fā)送次數(shù)并不能作為計費的標準。以WAP為例，通常只有對特定URL的成功的訪問才構(gòu)成計費的條件。以BREW與J2ME為例，客戶端運行的小程序在與后端服務(wù)器的連接過程中，通常并不基于HTTP。

在對業(yè)務(wù)的計費中，也牽涉到運營商對內(nèi)容供應(yīng)商的管理問題，運營商需要確定內(nèi)容供應(yīng)商服務(wù)價格是否合理，需要在技術(shù)上排除最終客戶未享受到合適的服務(wù)，卻被錯誤計費的情況。
另外，如果一個計費系統(tǒng)需要處理不同業(yè)務(wù)類型的計費，則需要從不同的業(yè)務(wù)系統(tǒng)（如位置服務(wù)，短信中心，媒體服務(wù)器）中獲得合適服務(wù)描述記錄（SDR）。此時，每個業(yè)務(wù)系統(tǒng)需要有SDR采集系統(tǒng)。該系統(tǒng)與計費系統(tǒng)具有標準的協(xié)議接口。由于不同業(yè)務(wù)會由不同的廠家部署，因此，運營商需要定義合適的協(xié)議。

b)信道計費/流量計費/業(yè)務(wù)計費的交叉

對于運營商來說，短信/彩信可以根據(jù)條數(shù)計費，WAP可以根據(jù)點擊，視頻可以根據(jù)流量來計費。對于內(nèi)容供應(yīng)商來說，需要根據(jù)內(nèi)容來計費。每種方式的計費采集點會有所不同，如流量計費會在GPRS接入點，短信在短信中心，而根據(jù)內(nèi)容計費通常在CP網(wǎng)關(guān)處，彩信在發(fā)送過程中，也會花費GRPS流量。問題的難點在于，流量計費很難區(qū)分業(yè)務(wù)的不同，如果希望一部分業(yè)務(wù)按照一種方式計費，而部分業(yè)務(wù)按照業(yè)務(wù)或其他方式計費，則很有可能發(fā)生計費交叉的情況。

c)與不同利益團體的計費與結(jié)算。在3G環(huán)境下，為更好地拓展業(yè)務(wù)，架通增值業(yè)務(wù)價值鏈，運營商需要內(nèi)容供應(yīng)商，服務(wù)供應(yīng)商，行業(yè)客戶，企業(yè)大客戶等不同利益團體進行合作，其合作模式，計費方式必然不相同。以企業(yè)客戶為例，企業(yè)客戶在使用運營商的網(wǎng)絡(luò)設(shè)施過程中，并不直接通過無線業(yè)務(wù)盈利，因此，計費、結(jié)算方式必然有所區(qū)別。

另外，增值業(yè)務(wù)從技術(shù)角度來說，與地域并無直接的關(guān)系，一臺放在因特網(wǎng)上的視頻服務(wù)，既可以為北京的客戶提供服務(wù)，也可以為上海的客戶服務(wù)。但是，從業(yè)務(wù)管理、網(wǎng)絡(luò)設(shè)施的使用，以及目前運營商的現(xiàn)狀而言，會有區(qū)域問題。在此過程中，就會用戶在漫游過程中如何進行計費，省公司之間如何結(jié)算的問題。

d)可以處理不同的優(yōu)惠策略與打包方式，可以處理不同的計費方式。例如，可以按照訪問時間、訪問個人、訪問個人所屬團體等等進行優(yōu)惠，可以支持預(yù)付費與后付費等。

6. CP/SP門檻問題

如果說3G將是業(yè)務(wù)之爭的話，那么業(yè)務(wù)背后，開發(fā)業(yè)務(wù)、宣傳業(yè)務(wù)的CP/SP將是關(guān)鍵的關(guān)鍵。在3G業(yè)務(wù)中，運營商與CP/SP之間的依賴性更為密切。
因此，對于運營商而言，數(shù)據(jù)業(yè)務(wù)平臺應(yīng)該給CP/SP提供方便，保證CP/SP可以高速地開發(fā)、部署與測試他們的應(yīng)用程序，為了降低CP/SP門檻，需要解決下列問題：

1．接口復(fù)雜，過于底層

在原有的數(shù)據(jù)業(yè)務(wù)平臺中，提供給CP/SP的接往往過于復(fù)雜，以短信為例，幾乎所有的運營商的接口都牽涉到網(wǎng)絡(luò)字節(jié)順序，參數(shù)排序等TCP/IP Socket編程需求，而特定廠商提供的打包API互不相同，沒有相關(guān)協(xié)議。

2．業(yè)務(wù)分類過于僵化，跨業(yè)務(wù)CP應(yīng)用門檻過高。

與原有的2.5G平臺不同的是，3G平臺支撐的業(yè)務(wù)種類多，類型復(fù)雜，業(yè)務(wù)之間的復(fù)合度會越來越高。CP/SP將不再以短信、彩信等業(yè)務(wù)來分類，而是以用戶群以及用戶的需求來劃分。例如，一個專門做游戲的CP或許同時使用彩信、位置服務(wù)、短信等多項業(yè)務(wù)。因此，平臺應(yīng)提供集成的接入方式與接入接口。應(yīng)該可以提供一次接入，全業(yè)務(wù)接通服務(wù)。

7．管理平臺與業(yè)務(wù)平臺的關(guān)系問題

由于數(shù)據(jù)業(yè)務(wù)牽涉的業(yè)務(wù)較多，在原有運營商的平臺中，通常是業(yè)務(wù)優(yōu)先，業(yè)務(wù)之后才是管理，而在每上一個業(yè)務(wù)平臺之后，都會牽涉到是否要加入管理功能的問題。此時，存在兩種不同的情況：

1．業(yè)務(wù)平臺本身具有完整的管理功能，如用戶管理，計費等。例如，某些廠商的BREW下載服務(wù)器就具有較完整的業(yè)務(wù)管理功能。
2．業(yè)務(wù)平臺本身沒有管理功能，需要增加管理功能，或是接入到運營商的綜合管理平臺上。

如果每個業(yè)務(wù)平臺都具有管理功能，隨著而來的就是管理的混亂，因此，需要避免出現(xiàn)這種情況。目前為止，大多運營商都會有一個綜合業(yè)務(wù)管理平臺，該平臺的目的在于對不同的業(yè)務(wù)做管理。但充分使用綜合管理平臺管理所有的業(yè)務(wù)還需要解決下列問題。

1．需要在業(yè)務(wù)上線之前，考慮到特定業(yè)務(wù)平臺的特定需求，比如說，對于位置服務(wù)平臺，有可能會有不同類型的CP/SP，有些行業(yè)用戶僅僅使用定位功能，而有些GIS供應(yīng)商提供地圖服務(wù)，有些提供黃頁數(shù)據(jù)，不同類型的CP/SP計費策略不同，這些，在構(gòu)造綜合管理平臺都需要考慮到。這就需要綜合管理平臺有足夠的靈活性。

2．由于不同的業(yè)務(wù)有可能屬于不同業(yè)務(wù)部門管理，需要規(guī)范管理，避免出現(xiàn)面向特定業(yè)務(wù)的管理平臺。

3．有些平臺已經(jīng)有了管理功能，而這些管理功能與業(yè)務(wù)功能息息相關(guān)，很難棄置不用，此時綜合管理平臺需要提供開放的接口，以便互聯(lián)互通。

8．平臺整合問題
在3G平臺中，由于業(yè)務(wù)為不同的廠商開發(fā)，每個系統(tǒng)均有可能有各自的用戶管理、計費、鑒權(quán)管理，CP管理會有分離的文檔、分離的應(yīng)用接口。如何將這些平臺集成起來，形成完整的、統(tǒng)一的平臺，具有統(tǒng)一的用戶模型，集成的流程，集成的業(yè)務(wù)管理，這是在規(guī)劃過程中必須要考慮的。

1．用戶模型的整合

運營商需要定一個統(tǒng)一的用戶模型。當業(yè)務(wù)增加時，由于特殊業(yè)務(wù)的需要，有可能會增加相關(guān)用戶信息，因此，該模型必須具有足夠的擴展性。另外，基于該模型的相關(guān)應(yīng)用的實現(xiàn)也必須具有足夠的靈活性，例如，當模型添加信息時，在用戶管理界面上會有相關(guān)反應(yīng)。
與此同時，該用戶模型需要有開放的接口，可以與特定業(yè)務(wù)系統(tǒng)中的用戶信息同步。同樣，這種開放性也必須具有一定的靈活性，比如與用戶信息的哪些字段同步，同步的流程如何，是否需要專人審批，甚至是人工干預(yù)后，才可以同步。這些，都對系統(tǒng)的實現(xiàn)提出了更高的要求。

2．CP/SP模型的整合

與用戶模型類似，每個業(yè)務(wù)也可能會管理自己的CP/SP，需要運營商構(gòu)造統(tǒng)一的、靈活的CP/SP模型以及相應(yīng)的應(yīng)用。

3．相關(guān)流程的整合

CP/SP的接入申請，接入后相關(guān)業(yè)務(wù)的開通，開通后的測試，新業(yè)務(wù)的申請等等，均需要更為自動化流程。

另外，由于數(shù)據(jù)平臺本身以及足夠復(fù)雜，將該平臺與語音平臺區(qū)分管理，將是一個較好的解決方案。當然，兩者之間的邊界問題是另一個值得探討的問題。

來源：CCW