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

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

．平臺架構問題與標準兼容問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2．用戶信息的遷移

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

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

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

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

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

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

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

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

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

5.靈活計費問題

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

a)面向不同業(yè)務與產品的計費

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

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

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

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

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

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

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

6. CP/SP門檻問題

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

1．接口復雜，過于底層

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

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

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

7．管理平臺與業(yè)務平臺的關系問題

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

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

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

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

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

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

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

1．用戶模型的整合

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

2．CP/SP模型的整合

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

3．相關流程的整合

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

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

來源：CCW