移動短消息計費系統技術建議方案(doc 37頁)

《移動短消息計費系統技術建議方案(doc 37頁)》由會員分享，可在線閱讀，更多相關《移動短消息計費系統技術建議方案(doc 37頁)（37頁珍藏版）》請在裝配圖網上搜索。

1、XX省移動短消息計費系統技術建議方案北京成科技股份有限公司第1章 前言4第2章 系統概述42.1 系統概況52.1.1 現有系統概況52.1.2 建設系統概況52.1.3 系統設計目標52.1.4 數據庫平臺要求52.1.5 主機服務器平臺要求62.1.6 計費數據處理要求62.1.7 維護管理要求72.2 系統設計原則7第3章 系統結構設計93.1 短消息計費系統的特點93.2 應用軟件體系結構103.3 數據處理流圖113.4 軟件功能模塊123.5 服務器處理模式設計12第4章 平臺及運行環境設計134.1 主機系統設計原則134.2 主機系統平臺現狀134.3 主機系統需求分析144.

2、3.1 影響性能的幾個方面144.3.2 服務器性能分析154.3.3 在線存儲容量計算164.3.4 建議方案17第5章 應用軟件設計205.1 短消息計費系統功能介紹205.2 數據采集與傳輸子系統205.2.1 功能簡介205.2.2 傳輸系統結構215.2.3 系統功能225.3 數據預處理235.4 話單劃價255.5 重復話單過濾265.6 話單并行入庫265.7 計費結算285.8 統計分析285.9 稽核排錯285.10 數據交互295.11 系統查詢295.12 系統維護30第6章 系統關鍵問題316.1 與GSM計費系統的融合316.1.1 簡述316.1.2 系統結構圖3

3、26.2 關于帳務系統336.3 關于超額部分336.4 關于SMC話單33第7章 系統平滑過渡347.1 組織347.2 系統過渡割接的方式347.3 系統過渡割接步驟34第1章 前言隨著我國移動通信事業的迅猛發展，為了迎接日益臨近的市場競爭，電信部門在開拓市場業務，擴大電信網通信能力的同時，越來越重視電信企業內部的服務意識，并不斷完善電信企業的服務體系，為此作出了不懈的努力。南京聯創系統集成股份有限公司自成立之初便確立了以電信行業作為自己重要的發展方向。目前，在電信行業已具有了豐富的積累和長足的發展，取得了可喜的成績。尤其在電信計費、電信業務這一領域，公司著眼長遠，立足未來，投入了大量的精

4、力，進行電信計費、業務等應用軟件的研究開發工作，致力于為電信行業提供全面的解決方案?，F在公司已具有一批既精通計算機技術又深諳電信業務的專業技術人員和一支穩定的高素質開發隊伍，為能夠開發移動短消息計費系統準備了充足的人力資源和強大的技術支持。而且，江蘇移動的短消息計費的一期工程也是由聯創公司承建的，我們對原來系統的了解將有助于我們更好的建設新系統。同時，我們真誠地希望，藉此機會能夠和貴局進行廣泛的交流，進一步鞏固和加強相互間長期的友好合作關系。我們將虛心地向貴局的行家們學習、請教，進一步提高我們的知識水平和業務能力，從而為江蘇移動提供更加優質、完善的服務。第2章 系統概述江蘇移動通信有限公司已于

5、2000年5月根據集團公司的要求建設了短消息計費應急系統，實現短消息按條計費的要求。隨著短消息用戶數的增加，目前所有的GSM用戶都可以是短消息用戶，同時隨著手機炒股，GPS定位、以及MONTERNET計劃中大量基于短消息的豐富應用逐步推出，原來的短消息應急系統在性能和功能上都難以適應業務的發展要求，迫切需要建設一個完善的短消息計費系統。2.1 系統概況2.1.1 現有系統概況移動計費的短消息計費系統目前為應急系統，其中有五臺機器組成，兩臺pc機及三臺惠普的pc server，pc機上安裝有SCO UNIX，分別運行短消息話單的預處理及下發程序。Pc server上安裝有NT操作系統，運行SYB

6、ASE11.9.2的數據庫服務器，分別處理南京、無錫、蘇州等三個短消息中心產生的短消息話單。目前該系統支持全省100萬用戶的短消息業務，每月的短消息話單數大概為2000萬。2.1.2 建設系統概況本期工程設計主要實現省計費中心系統實時處理能力滿足數字網（GSM）300萬以上移動用戶每天7條短消息話單的計費需求。2.1.3 系統設計目標隨著電信企業向著規?；?、多元化經營轉變的不斷加劇，越來越多的電信企業開始從傳統、單一的經營模式向著“以市場為導向，以滿足用戶需求為經營目標、以服務于用戶為經營宗旨”的經營理念轉變，這就更進一步加大了電信企業間競爭的力度。如何更好地服務于用戶、更好地滿足市場的需求已

7、開始成為眾多電信企業經營者的關注所在。本期工程就是要為XX省構架一個覆蓋全省的短消息計費管理平臺，系統的建設按滿足到2002年移動通信網用戶發展的需要考慮（300萬以上GSM短消息用戶）。本期工程的建設目標是，建立一套能滿足300萬短消息用戶的短消息計費平臺。 2.1.4 數據庫平臺要求數據庫平臺應采用SYBASE數據庫平臺,能完成大容量數據的實時處理和管理的能力，SYBASE數據庫能滿足以下要求： 支持ANSI/ISO SQL-89、ANSI/ISO SQL-92； 支持并行處理技術； 支持主流廠商的操作平臺； 支持多種復制功能 支持聯機分析處理（OLAP）； 支持聯機事物處理（OLTP）；

8、 支持C2級以上安全標準、多級安全控制； 具有強的容錯能力、錯誤恢復能力、錯誤記錄及預警能力； 支持聯機、脫機備份等。2.1.5 主機服務器平臺要求主機服務器平臺應具有較高的安全控制機制，各平臺除有足夠的能力進行計費處理外，還應具有其它（例如故障檢查、故障處理等）的應急處理能力。所選擇的主機平臺應該滿足以下特性：1高擴展性。當業務量增加或增加新業務時，主機能以增加節點、處理器、內存等方式提供更高的性能來滿足新的要求。2高可靠性。主機系統需7*24小時連續運行，同時系統應具有良好的容錯能力。系統應采用冗余配置，保證系統無單一故障點。3支持并行技術。支持多臺主機并行的處理，以保證大容量數據處理的要

9、求。4易于管理與使用。保證系統的易使用性，并使系統在較優的狀態下運行，以提高系統的的運行和處理效率。5恢復周期短。當對系統進行擴容或系統發生不可預見的故障時，系統應能在24小時內恢復到正常運行狀態。2.1.6 計費數據處理要求數據處理包括三部分數據： 短消息中心采集到的原始話單數據。 短消息網關采集到的原始話單數據。 集團中心下發的本省用戶的全國性業務的話單文件。為保證忙時的數據處理要求，系統完成對話單的計費處理（包括格式轉換、檢錯、糾錯、入庫、查找重單、分檢）的速度正常情況下要達到： 本地話單，從話單出現在計費采集接口到完成計費處理（包括采集、預處理、批價、存儲、分檢），不超過15分鐘； 全

10、國業務話單，從話單放在全國移動計費結算中心設在省中心的通信服務器到完成數據的處理（包括話單的檢查、存儲、分檢），不超過15分鐘。2.1.7 維護管理要求 系統具有良好的交互性，操作簡單、明確。 系統提供多種訪問手段，允許管理員在不同的環境下對系統進行管理。 系統提供完備的監控和調度工具，具有完備的監視、故障檢查與告警、故障處理功能。 盡量將主機、網絡、數據庫、應用系統、以及第三方產品的管理集中到單一的監控和管理平臺上。 系統的管理應具有較高的自動化程度。 系統應具有可靠的備份機制。2.2 系統設計原則針對移動短消息計費系統的特點，為了保證系統的成功實施，我們制訂系統設計原則為：系統性、正確性、

11、完整性、可維護性、先進性、繼承性、安全性、規范性和容災考慮。u 系統性：移動短消息計費系統是一個覆蓋了全省的計算機管理工程，要想成功地構架這一系統，使之能滿足XX省目前直到300萬以上移動用戶的需要，則必須正確合理地綜合分析主機、網絡、數據庫系統所提供的性能并充分考慮到整體系統的可擴展性，使整個應用系統的性能達到最佳狀態，以滿足不斷增長的用戶數及話單數的要求。u 正確性：指數據的正確性。數據的正確性必須貫穿在整個短消息計費系統的每個環節中，數據采集、數據傳輸要有相應的數據校驗，必須剔除計費過程中各種類型的錯誤話單，排除用戶三個月以內的重復話單、與各業務管理中心等系統進行數據交互時的準確性、兼容

12、性。在系統設計時充分考慮系統運行過程中數據的正確性并提供合理的解決方案。u 完整性：指系統功能的完整性。它要求短消息計費系統應滿足XX省移動通信業務經營、管理、決策的需要，同時要求系統能與其它系統（如集團中心的短消息中心）進行信息共享或提供數據接口。u 可維護性：指系統中某一相對獨立的模塊發生改變時，不影響其他模塊的運行，維護操作簡單，用戶操作界面友好；當系統處理的某些指標需要動態改變時，不需要修改程序代碼就可以實現相應功能，充分做到代碼與數據的獨立性，以減少操作維護人員的工作量和工作繁重程度。u 先進性：指系統模式結構的先進性以及軟件設計思想的先進。在構架移動短消息計費系統時必須采用先進、成

13、熟、可靠的技術，確保整體系統的先進性，利用面向對象的設計思想，對一些通用性、規范性較強的模塊采用面向對象的“構件”技術，對于超大規模的數據量，引入“數據挖掘”等先進技術，為系統的決策支持、數據分析提供先進的工具平臺。u 繼承性：指本系統在開發實施階段，應充分考慮利用XX省原有的短消息計費系統及移動電話計費系統數據資源以及其他一些可以繼承的軟、硬件資源，必須在建設系統中得到充分利用，以充分保護用戶的投資利益。u 安全性：計費數據是移動經營最重要的收入來源，而整個計費系統是構架在全省范圍內的一個大型廣域網系統。因此，在信息高度共享的系統中，必須充分利用主機、網絡以及數據庫管理系統提供的安全保障機制

14、，確保計費數據的絕對安全。對于應用系統而言，對所有系統數據的操縱，嚴格按照權限級別進行，嚴禁非法用戶進入系統，對于操作人員進行的相應重要的操作有相應的操作日志。同時，對系統重要數據提供可靠的備份和恢復機制，以確保整個應用系統的安全。u 規范性：在技術、業務的理解上要完全遵循XX省移動公司關于短消息計費的要求；在主機的安裝、網絡的設計時嚴格遵守相應的規范；應用系統實施數據庫設計時，也應按照規范化理論進行，同時保留一定的冗余，確保系統的效率和性能。u 容災考慮：系統應盡量考慮到如何避免異常狀況的出現，同時也應考慮在異常情況出現時的處理方法。第3章 系統結構設計3.1 短消息計費系統的特點短消息計費

15、系統與傳統的GSM話音計費是有著許多的區別的，因此，短消息計費系統在業務處理上和流程上應該有其自身的要求，如：1、 短消息系統的話單源與GSM計費系統有差別。短消息系統的話單源不僅產生在短信中心，同時，也會產生在短信網關，并且，這兩種類型的話單源還起著不同的作用，一個是用來計算用戶的通信費，一個是向用戶代收取信息費以及與SP之間的結算；2、 短消息系統的話單根據采集點及話單的不同，分為MO、MT、SMO、SMT、SMC、SMF、SMA多種類型，分別起著不同的作用，而在傳統的計費系統中，一般所涉及到的話單類型為MOC、MTC、POC、PTC幾種；3、 短消息話單中某些話單是已經批好價的，如從短信

16、網關傳送回的話單，已經包括了用戶的信息費，而對于GSM來說，所有的話單都需要進行批價計費。4、 從短信中心產生的話單和從短信網關產生的話單的格式是不一樣的。5、 短消息的費用類型與GSM與區別，GSM話單的費用類型可以分為通信費、長途費兩大類，而短消息所涉及到的費用為通信費、信息費、勞務費6、 短消息牽涉到與SP之間的結算，而GSM牽涉到的是只與聯通、電信等電信運營商的結算。7、 短消息系統不僅是要向用戶“收錢”，而且由于有“WAD”信息發布、廣告業務，短消息計費系統還要向用戶“送錢”，這一部分送的錢需要與帳務系統間重新定義接口，以便于將其轉換為用戶的預存話費。但是，短消息系統的處理流程又與原

17、有的GSM話單計費的流程有著很多的相似之處，如：1、 都包括對話單的采集和預處理；2、 對需要對話單的正確性進行校驗；3、 都需要對話單進行稽核統計；4、 都需要對話單按照某一政策、按不同的費率進行計費批價；5、 都會對部分話單進行上傳和下發的接收處理工作；6、 都需要將計費產生的用戶費用信息傳遞給帳務系統，由帳務系統最終形成綜合化的帳單，向用戶收取費用。3.2 應用軟件體系結構在充分考慮到短消息計費系統自身的特點以及與GSM計費的共同點之后，我們對短消息計費系統的體系結構進行了合理的劃分：短消息計費系統應用軟件的體系結構可以分成四層：即預處理層、核心處理層、管理層和接口層。如下圖：這樣的劃分

18、對于系統的整體靈活性有著非常大的好處，可以使系統能更加適應今后業務的變化。結合應用軟件的功能和應用軟件的分布情況，應用系統的結構如下圖所示：考慮到系統充分利用現有的設備，因此，計費批價服務器采用目前已有的L2000服務器，數據庫服務器采用HP的N4000服務器。3.3 數據處理流圖短消息計費系統的數據流圖如下：3.4 軟件功能模塊短消息計費系統主要有以下幾種功能模塊，各主要功能模塊間的關系圖如下：3.5 服務器處理模式設計隨著各種短消息業務的開通，短消息的話單和剛開通短消息是相比，已經取得了長足的增長，目前應急計費系統已從開始的一臺數據庫服務器擴充到三臺數據庫服務器，目前每月的話單數已經達到了

19、3000多萬，而且數據量還在不斷的增加，因此在進行主機選型的時候，一定要考慮到主機的性能要滿足數據量不斷增加的需要。由于短消息計費系統在處理流程上與移動電話計費系統的相似性，我們在考慮服務器處理模式的時候將以目前的移動計費系統的處理模式為參考，即系統由多臺處理服務器組成，每臺服務器的處理能力達到極限后可以在系統上有機的增加服務器從而增加整個系統的處理能力，而系統的總體結構不需做大的調整。第4章 平臺及運行環境設計4.1 主機系統設計原則聯創系統集成股份有限公司在進行主機系統方案設計時遵循以下設計原則：u 開放性計算機系統應支持工業標準或事實標準，以便隨著今后需求的發展可添加和更新新的模塊。u

20、先進性在兼顧系統成熟性的前提下采用業界先進的技術，這樣才能保證現有系統的先進性，并隨著技術不斷發展得到相應的更新。u 可擴展性用戶的業務及需求在不斷地發展，當現有系統不能滿足應用需求時，系統應有平滑升級的能力。u 高性能高性能應體現在整個計算機系統中，包括服務器、網絡、I/O操作以及軟件。u 可管理性由于計算機環境的不斷擴大，IT系統的更加復雜以及覆蓋面的增加，對服務器、網絡設備和應用軟件的管理已成為設計計算機環境不可缺少的一部分。u 選領導地位廠商產品如所選廠商不在業界處于領導地位，盡管有時所選產品在技術上有暫時的領先性，但很容易被激烈的市場競爭所淘汰，用戶的投資將得不到保護。短消息計費處理

21、系統應嚴格按照業務協議的內容設計、執行，做到計費數據處理及時、準確，系統簡潔，便于維護，各類功能齊全而易于擴充。采用先進和技術成熟的主機、網絡和應用系統，建立一個具有高可用性、高可靠性、高安全性、有良好的可擴展性和可維護管理性的準確、快速、開放的高性能系統。4.2 主機系統平臺現狀目前系統的平臺現狀如下：各機器的配置信息如下：數據庫服務器：PC服務器，CPU 400MHZ以上，內存1G以上、硬盤100G（目前數據庫服務器已從一臺擴充到三臺）；預處理服務器：高檔PC,CPU300以上，內存256M以上、20G以上；下發服務器：高檔PC，CPU300MHZ以上，內存256M以上、20G硬盤，MO驅

22、動器；應用服務器：PC、CPU300以上，內存128M以上、4G以上。軟件環境如下：數據庫服務器：操作系統Win NT4.0、數據庫Sybase 11.9.2；預處理服務器：操作系統 Sco Unix 5.0以上版本、Sybase 11.9.2 Client；應用服務器：操作系統Win9X、Sybase 11.9.2 Client、PowerBuilder 6.5以上；下發服務器、預處理服務器：操作系統 Sco Unix 5.0以上版本、Sybase11.9.2。4.3 主機系統需求分析4.3.1 影響性能的幾個方面影響服務器整體性能的因素是多方面的，針對不同的應用，設計時考慮的側重點也不同。

23、移動通信計費系統這類聯機事務處理的應用，主要從CPU、內存和I/O三個方面考慮，下面分別進行論述：CPU：聯機事務處理的主機，主要是作為數據庫服務器而不是計算服務器，因此以服務器的TPM值作為相對選型參考值。需要說明的是廠家公布的服務器TPM值，一般是采用最大的硬件配置、按照100%的利用率所得到的，而在實際建設中的系統配置往往小得多，系統性能的TPM不會有公布值那么高，在對服務器處理能力進行估算時，需要將一些經驗值和TPM值一起綜合考慮。內存：內存是所有程序運行的環境，在CPU和系統軟件處理能力的范圍內，內存越大則服務器的處理性能越好，但不同的應用對內存的要求不同，所以在計費系統服務器內存設

24、計中，需要從應用需求的角度來考慮，尋找最佳的配置。I/O：在CPU處理能力一定的情況下，磁盤陣列的I/O速度，可使服務器的整體性能表現相差幾倍到幾十倍，所以我們在設計中要特別注意磁盤陣列I/O的選型，盡量選擇I/O帶寬高的磁盤陣列，同時考慮到單個磁盤的I/O速度是一定的，需要靠多磁盤的并行讀取來提高磁盤陣列I/O速度，在容量和性價比容許的情況下，盡量選擇容量小而數量多的磁盤，能大大提高磁盤陣列的I/O吞吐性能。根據應用對磁盤陣列的劃分進行優化也是提高I/O性能的一個重要方面。4.3.2 服務器性能分析4.3.2.1 預處理服務器l 聯機事務處理能力的分析預處理服務器主要用于將采集系統傳來的原始

25、話單標準化，并統一批價后形成話單清單供計費服務器排重入庫，其處理是文本轉換和簡單計算的過程。根據聯創在移動計費上的經驗和一百萬用戶級系統實際運行的測算，一百萬用戶的話單預處理需要TPM值為2000左右的服務器，則300萬用戶量需要6000tpmC處理能力的服務器。l 服務器內存容量的分析為保證預處理的高效，文本轉換的過程應全部在內存中完成，批價所需的費率等參數表也應常駐內存以避免反復讀取影響效率。根據聯創在移動計費上的經驗和一百萬用戶級系統實際運行的測算，一百萬用戶的話單預處理需要內存200MB，則300萬用戶為600MB，考慮到系統本身的開銷，所以推薦內存配置為1GB。4.3.2.2 計費數

26、據庫服務器計費數據庫服務器是整個移動計費系統的中心服務器，運行數據庫管理系統，負責進行話費排重和入庫，并提取供統計分析使用的相關數據。l 聯機事務處理能力的分析一張話單的處理流程包括：打開文件、讀記錄、糾錯、入庫、出庫等等，根據聯創在移動計費上的經驗和一百萬用戶級系統實際運行的測算，每張話單的處理約等價于0.5個標準事務，則：300萬用戶，平均每個用戶每天7張話單，即每天2100萬張話單；平均每分鐘處理的話單為：2100萬/(2460分鐘)=14584張；假設通話高峰時間每天為8小時，則高峰時服務器負荷按平均負荷的3倍計算，此時要求系統的tpmC值為：145840.53=21876 tpmC；

27、建議系統利用率不超過80，則需要配置的處理能力為21876/80=27345tpmC。l 服務器內存容量的分析計費結算是將經過標準化和批價的原始話單入庫和匯總的過程。由于交換機是定時向外傳送話單信息，因此在某種程度上計費結算是一個批處理過程。根據聯創在移動計費上的經驗，綜合考慮數據庫共享內存的使用和系統、數據庫本身的開銷，建議按照1GB/CPU配置內存。l 提高I/O性能的途徑1.采用高傳輸帶寬（100MB/s的光纖通道或相當）的存儲設備；2.根據應用對磁盤陣列進行劃分，使盡可能多的磁盤并行讀寫；4.3.3 在線存儲容量計算根據江蘇移動短消息計費系統的業務量和具體特點，以及從數據庫、磁盤使用技

28、術等方面的考慮，我們按以下要求配置存儲設備容量：s 本工程滿足300萬用戶量的處理需求，每用戶每天平均7張話單；s 在線存儲的容量主要考慮話單清單容量，每張話單按200字節計算；s 話單在線存儲4（3+1）個月，每個月按30天計算；s 數據庫冗余度50%（主要是考慮到數據庫索引和其他一些表占用空間、數據庫不能及時釋放的空間、數據庫運行、恢復、日志、臨時與共用池空間）；s 磁盤利用率85%（主要考慮到磁盤的最佳使用性能和一些額外磁盤開銷）；s 數據存儲保護技術決定的空間利用率，鏡像為50%；則所需磁盤容量=300萬7304200（1+50%）/0.85/0.5=1657GB。4.3.4 建議方案

29、雖然高檔UNIX服務器出故障的可能性很小，但由于江蘇移動短消息計費系統是江蘇移動通信公司業務支撐系統的重要組成部分，因此在進行主機系統方案設計時仍須考慮其高可用性，同時兼顧性價比。4.3.4.1 詳細設計上一節中，我們對滿足江蘇移動300萬用戶規模的短消息計費系統所需的主機處理能力、內存大小和存儲容量等進行了詳細的分析。聯創建議方案的出發點就在于在滿足性能要求的前提下，如何提高性能價格比，最大限度的為用戶節省投資。預處理服務器采用兩臺的HP A500服務器，配置單550MHz PA8600CPU，1GB內存，雙18GB內置硬盤，考慮到聯創計費軟件預處理模塊的特點，可以不組成雙機系統，而通過手工

30、切換；計費數據庫服務器采用HP N4000服務器雙機系統，每臺配置4550MHz PA8600 CPU，4GB內存，性能達到33000tpmC。下發服務器和應用服務器可以采用已有的L2000服務器。聯機存儲采用HP FC60磁盤陣列，配置容量2TB，通過光纖交換機與上述服務器連接，組成存儲區域網（SAN）。 4.3.4.2 方案特點 高可用性采用的高可用性技術：系統停機因素保護策略系統（System）MC/ServiceGuard技術保證當系統中一臺服務器失效時，其它服務器迅速恢復這臺服務器上的應用程序和數據庫系統正常工作。內存（Memory）系統可以動態檢查內存，當發現壞內存頁時屏蔽該內存頁

31、不再分配給系統使用。網卡（Network Interface card）系統配置雙網卡，一塊工作，一塊作備份。MC/ServiceGuard可監測網卡，當其中一塊不能正常工作時，MC將自動切換到備份網卡。接口卡服務器與磁盤陣列通過雙接口卡連接，其中一塊卡失效時另一塊卡仍可保證系統正常運行。Internal磁盤（Disk）系統盤：用MirrorDisk/UX軟件對引導區（root）、交換區（swap）鏡像。高可用性存儲系統（High Availability Storage System）可熱插拔的磁盤、電源和風扇模塊。FC60冗余電源子系統和系統后備電池。磁盤和高速緩存的檢測和糾錯。應用（Ap

32、plication）MC/ServiceGuard可以在同一系統上再次啟動應用軟件，或將應用遷移到備份系統上。HP-UX當系統出現突發停機時，HP的日志文件系統（JFS）將在10秒以內使系統恢復運行。 靈活性由于采用了SAN技術，當業務量出現突發性增長時，可以方便地通過增加服務器或存儲設備的方式提高系統處理能力，而不需要重新構架。這種靈活性既保護了用戶的投資，又提高了業務系統對市場變化的適應能力。 可擴充性在滿足300萬用戶規模計費性能要求的同時，該系統還具有充分的擴充能力，可以平滑擴展到更高用戶量的處理能力要求，具體表現如下：主機系統通過增加CPU擴展性能：A500單機最多可配置2個550M

33、Hz PA8600 CPU，處理能力可達15000tpmC。N4000單機最多可配置8個550MHz PA8600CPU，處理能力可達60000tpmC。主機系統通過增加內存擴展性能：N4000單機現在對內存的支持最高可達32GB。A500單機現在對內存的支持最高可達8GB，主機系統增加內存會對數據庫等大內存需求的應用有很大的性能提高。主機系統通過升級CPU擴展性能：目前HP已經推出了性能更高的550MHz PA8600芯片，HP會推出PA8xxx芯片及以后的IA64結構的CPU，N4000可以通過CPU升級達到系統性能提升的目的。主機系統I/O擴展能力：N4000單機支持12個PCI的I/O

34、槽口，I/O帶寬可達5.8GB/s。主機系統復雜擴展:除了上述簡單的擴展方法外，也可以通過在群集中加入新的結點的方法來實現性能的擴展?，F在MC/ServiceGuard可支持的HP 9000 Server結點數為16個，因此也具有相當的擴展余地。另外，如果應用的性質會轉為數據倉庫的話，在增加一個基結點后，現有的服務器都可作為附加結點加入到企業并行服務。存儲系統容量的擴展：HP FC60最大可擴充至4TB。第5章 應用軟件設計5.1 短消息計費系統功能介紹短消息計費系統是一個綜合復雜的系統，它的處理流程與移動計費系統類似，由許多子系統共同組成，并和其他相關系統存在不同的接口。短消息計費系統主要包

35、括數據采集與傳輸子系統、預處理子系統、劃價子系統、下發子系統、統計子系統、稽核子系統、查詢子系統、監控子系統等，下面對各子系統的功能要求進行詳細的描述：5.2 數據采集與傳輸子系統5.2.1 功能簡介短消息計費系統的數據源有三種：1、 短信中心的話單文件2、 短信網關的話單文件3、 集團中心下發的話單文件。其中1、2的話單文件由華為的采集機負責采集，而3的話單文件是集團中心通過自己的傳輸系統將文件放在江蘇移動公司和集團中心的通信機上，對于短消息計費系統來說，只需將三種數據源的數據傳送到預處理機上。傳輸系統主要完成短消息計費中心與全國計費中心之間、短消息計費中心與地市業務中心之間、短消息計費中心

36、與計費數據采集機之間以及短消息計費中心與外部系統之間的信息交互與數據傳輸，以保證各級管理系統之間的移動通信資源和數據能夠實時（或準實時）地共享和保持一致，為實現移動通信專業化集中管理和分級處理提供保證。5.2.2 傳輸系統結構在部、省、地市各級中心之間、短消息計費中心與外部系統之間以及短消息計費中心與采集系統之間的交互信息主要有：計費原始數據、用戶清單數據、統計數據等。對于這些數據的傳輸設計，必須充分考慮數據的傳輸效率，以保證計費結算的高效處理。傳輸系統的主要數據流向如下圖所示：u 短信采集系統與短消息計費中心的數據傳輸短信采集系統與短信計費中心之間傳輸的主要是由數據采集系統從短信中心及短信網

37、關實時采集到的所有計費原始數據，這些數據主要由短信采集系統流向短信計費中心，是一個數據集中的過程，所有的數據傳輸都是實時而且自動化無人值守的，由短信計費中心集中對數據傳輸進行監控。u 短信計費中心與地市帳務中心的數據傳輸G 短信計費中心與地市帳務中心之間傳輸的主要是地市帳務中心所需的用戶帳單、用戶清單和統計數據，所有的數據傳輸都是實時而且自動化無人值守的，由短信計費中心集中對數據傳輸進行監控。用戶清單數據文件定期下發，傳輸周期可以由參數以分鐘為單位來設置。每個下發文件中包含文件頭、用戶清單，文件頭中包含文件類型、文件長度（包含文件頭）、下發清單數、用戶數、帳單記錄數、各項費用統計值等信息，下發

38、文件的命名規則為：TLLLYYYYMMDDhhmm.NNN其中各位的含義為： T - 文件類型。 LLL - 地區編號，全省統一編號。 YYYYMMDD - 下發文件生成日期，年月日。 hhmm - 下發文件生成時間，時分。 NNN - 下發文件編號，000-999循環。傳輸系統通過文件名和文件頭信息來驗證數據傳輸的正確性。u 短信計費中心與集團中心的數據傳輸短信計費中心與集團中心傳輸的主要是省間結算數據，這是一個雙向數據交換的過程，包括上傳集團中心的結算話單數據及集團中心下發的結算話單數據。u 短信計費中心與外部系統之間的數據傳輸短信計費中心與外部系統之間主要是網間結算數據和業務統計結果數據

39、的傳輸，系統提供拷盤、聯網文件傳輸、數據庫共享等傳輸方式，具體的傳輸方式需要與相關運營商或業務部門共同協商確定。5.2.3 系統功能傳輸系統由聯創公司基于FTP自主開發，該傳輸軟件具有以下功能：1) 應用系統或程序之間可靠的、無人值守的雙向數據傳輸功能；2) 提供自動數據傳輸和定時通信功能；3) 具有傳輸消息事件觸發功能，在傳輸正確完成后自動觸發用戶指定的處理進程；4) 傳輸系統提供配置和監控工具，實時監測傳輸線路和傳輸應用的運行狀況，并能及時傳送到省中心的集中監控系統；5) 具有自動錯誤恢復功能；6) 自動重試和斷點重傳功能：數據傳輸中斷后，能自動重新傳輸并跳過已傳輸的數據；7) 提供多種數

40、據安全性控制機制：標識與認證、數字標記等；8) 提供詳細的傳輸事件日志，并定期對傳輸兩端的日志進行傳輸一致性檢查，若發現漏傳或錯傳，傳輸系統自動重傳；若發現其它異?；蚬收?，通知集中監控臺，給出告警。9) 對短消息中心采集的原始話單文件的連續性進行檢查，確保無話單文件重復5.3 數據預處理前臺預處理子系統是短信計費系統的核心功能子系統之一，它完成不同格式的計費原始數據的數據提取、標準化等一系列處理工作。計費預處理功能在預處理服務器上完成。鑒于各種交換機計費信息的格式不一，需要在入庫前對各種類型的計費信息進行標準化處理，將不同類型交換機的計費信息統一成標準格式。同時將原始數據中由于各種原因造成的不

41、能計費的話單標識出來，供計費模塊判別。目前短信計費中心的原始話單類型主要有：短信平臺話單：對于短信平臺話單文件，主要有以下幾種話單類型：點對點短消息的話單人工臺或自動臺發起的MT方式的短消息話單由移動臺發起的各種收費信息話單，如股票查詢、用戶訂閱的消息等各種公眾信息源發布的MT方式的短信話單，如天氣預報等開通移動夢網后，在短信網關上會增加以下幾種話單類型：短信網關話單類型：SP發送給點播用戶的短消息話單（其中包括用戶自點播、用戶為別人點播、及SP主動發送的信息三種）集團中心下發話單：集團中心每兩小時下發一個M文件，每天12個文件，文件中包括SMT、SMC、SMT-F、SMC-F四種話單類計費預

42、處理功能數據提?。涸加涗浿邪S多通話信息，但計費分揀應用所需的數據域只是原始通話記錄域的一個子集。由數據提取功能提取計費系統所需的數據域。 支持多種類型交換機原始計費數據的數據提??； 支持多通話業務的數據提取，并對新業務提供數據提取接口； 對原始計費記錄提取過程提供完善的差錯檢測功能： 提供記錄級的差錯檢測：支持對每條提取的計費記錄進行數據審核校驗，識別其中的錯誤或無效話單，包括： 格式錯，與移動交換機定義的數據結構不符 重要記錄域為空 錯誤字符，包括：G 通話日期、時間、時長非法G 對端號碼錯誤G 記錄域中含有非法字符 計費信息不足 不需計費話單 提供數據塊級的差錯控制：話單提取后計算出

43、的塊長度（包括塊頭、塊尾、有效話單、錯誤話單）與原始數據塊長度一致性檢驗、塊序號連續性檢驗。 提供文件級的差錯控制：相鄰處理文件中撥打時間的連續性檢驗、文件序號連續性檢驗、數據塊數檢驗、轉換字節數與文件長度一致性檢驗。 對數據差錯或丟失情況記錄日志，并根據差錯級別提供不同的告警。u 記錄標準化 支持原始計費記錄數據格式向計費系統定義的標準記錄格式的轉化； 支持按設置的參數對大文件進行拆分； 按照計費系統的設計進行計費記錄的數據分類。u 預處理配置與管理 提供對整個預處理子系統的各種參數的查詢、配置和修改； 支持原始計費數據的實時備份和數據轉儲；提供對預處理各個模塊的實時監控和管理，如：物理空間

44、檢測、用戶口令權限管理、預處理過程監測、入庫狀態監測、進程管理等。預處理階段統計 正常有效話單統計 異常話單統計 無效話單統計 錯單糾正統計 對預處理階段非正常的話單應存儲在文件中或數據庫中，以備查詢。 可以對每臺交換機的產生的每個文件的有效話單數、異常話單數、無效話單數的統計，該統計可以按日、周、月、季進行。5.4 話單劃價話單劃價所完成的功能是將經過預處理的話單按照相關的資費標準計算出基本費用的過程，也稱為劃價或批價，劃價后形成計費清單數據。計費處理過程能適應最新的短信資費政策，并可滿足今后業務不斷發展的需要。計費處理能夠實時地處理短信平臺及短信網關產生的和集團中心下發的話單，接收到的計費

45、文件在下一文件傳到之前處理完畢，做到話務高峰時不出現話單積壓。在計費劃價的過程中，系統可正確的對各種類型的話單進行劃價，同時可區分不同的話單類型，并做不同的標記，按照事先確定的分揀規則進行分揀，以生成不同的清單文件進行并行入庫。對包月類及封頂類的短消息話單類型，劃價程序也進行正常的劃價，清單留做查詢及統計用，具體的收費有帳務系統確定。對按條收費的短消息話單，系統可以根據不同的話單類型進行不同費率的劃價，并可滿足不同優惠的需要。對于不同類型的話單，通過統一的參數管理，進行費率的靈活配置，對于信息發布業務（WAD），需要建立單獨的用戶費用記錄，傳送給帳務系統，用來做為用戶的預存話費?？紤]到這部分費

46、用與用戶的信用度等判斷有關，建議采用每15分鐘一次的間隔，將WAD產生的用戶的預存費用下發給帳務系統。5.5 重復話單過濾要對重復話單進行過濾，首先應分析一下產生重復話單的原因及如何標識重復話單。產生重復話單的原因主要有： 交換機生成原始通話記錄時產生的重復； 采集過程中故障重采產生的重復； 文件傳輸過程中產生的重復； 數據交互過程中產生的重復（來、出訪話單的上傳、下發）等。重復話單的標識：同一用戶（IMSI）、同一天（sdate）、同一時刻（stime）產生兩條相同的通話記錄。按照集團中心的要求，需排除三個月以內的重復話單。因此對重復話單過濾技術要求就很高。解決的辦法是： 數據分割 優化索引

47、機制 快速定位 以空間換性能這是快速“過濾網”技術的設計思想。5.6 話單并行入庫目前在建的短消息計費系統以后每月處理話單的數量可達上億張，這些己劃價的話單是計費系統的基礎數據，需存儲在數據庫中。話單入庫的效率將直接影響計費處理的整體效率，尤其是月末處理的性能。話單入庫的效率除了與磁盤I/O的讀寫速度有關外，與數據庫系統的整體設計也有著密切的關系，尤其是出現月初與月末性能差異太大時。解決的辦法： 合理地進行數據分割 有效地建立索引 合理的應用分布，降低磁盤讀寫沖突，減少訪問磁盤的次數。系統效率的提高，需從系統整體設計著手，下面將針對下發文件的處理，來說明如何降低訪問磁盤的次數，以提高系統整體效

48、率。對經計費處理后的話單文件，需經重復話單的檢測，實驗證明重復話單的檢測，應充分利用數據庫的特性，在數據庫內排重效率最高、最徹底。但發生重復的概率較小。因此在設計時，考慮到將排重的結果信息反饋給Client端，若無重復話單，則該入庫文件直接送給相應的下發隊列，并在數據庫中產生一條統計記錄（文件名、有效記錄數、重復記錄數、處理時間等）。這樣就無需再從數據庫取相應的下發數據，減少了磁盤訪問的次數。若發現有重復話單，則分兩種情況處理： 完全重復：即該文件的所有記錄都為重復話單記錄（文件重復），則在數據庫中產生一條統計記錄（文件名、有效記錄數、重復記錄數、處理時間等），該文件入重復話單文件隊列。 部分

49、重復：即該文件有部分記錄為重復話單記錄，則在數據庫中產生一條統計記錄（文件名、有效記錄數、重復記錄數、處理時間等），并排除重復話單，形成重復話單文件入重復話單文件隊列；將有效話單生成下發文件入相應下發隊列。計費劃價后產生的標準話單文件通過并行入庫程序多通道拷貝到數據庫中，并調用存儲過程進行以下工作：排除三個月（包括本月的重單）生成月清單數據生成統計中間表數據生成下發表數據入庫程序記錄詳細的日志信息，包括入庫話單數，入庫花費時間等。入庫話單不僅包括需要計費的MO、MT等話單，還要包括已經計好費的用戶信息費的短消息網關傳送的話單，以及用于進行網絡故障分析的SMA/SMA-F話單。5.7 計費結算短

50、消息計費中心具有集中計費結算功能，能進行省間、省中心與集團中心間、以及省中心與各個SP間的結算工作。計費結算模塊可以根據用戶通話詳單中的不同的短消息類型和已計算出的費用情況，形成相應的漫游結算和網間結算數據，結算比率可以通過參數設置進行動態調整。具體類型主要有：l 省公司之間的結算l 省公司與集團中心間的結算l 省公司與SP之間的結算l 省公司與廣告業務的廣告方的結算5.8 統計分析統計分析主要包括以下幾個模塊：文件統計： 對每天，每個統計月的原始文件的話單量統計，包含有效話單、錯誤話單、無效話單、發送失敗話單。業務量統計： 對全省或各地市的每天，每個統計月的業務業務構成量的統計。收入統計對全

51、省或各地市的每天，每個統計月的短消息收入的統計。5.9 稽核排錯計費系統直接面向廣大的電信用戶，是反映電信企業業務水平和管理層次的重要體現，因此，計費系統必須確保將一些錯誤因素排除在用戶面前?；伺佩e主要完成計費過程中一些異常情況的處理并形成相應的出錯報告，避免異常話單出現在用戶面前，同時，系統也應能將一些經過修改可以向用戶收取費用的話單進行回收，重新進行計費分揀，使電信企業避免不必要的損失?；伺佩e分為兩部分：原始計費數據的稽核排錯，即分揀出各短信平臺的異常話單和錯誤話單貫徹于整個計費過程中的稽核排錯，具體包括以下這些錯誤類型： 格式錯 錯誤字符 信息不足話單 重復話單 無費率話單等我們針對

52、“重復話單”這一錯誤類型，在系統中采用了先進的“過濾網排重”技術，可以在系統開銷很小的情況下迅速排除重復話單，完全能夠滿足排除3個月內重復話單的要求。系統對于出現的各種錯誤話單有相應的統計報告，可以讓相關部門對這些錯誤話單進行分析。對于經過相應修改可以向用戶收取費用的話單，系統具有完善的回收功能，對這部分話單進行重新計費分揀，以避免電信企業不必要的損失，系統給操作管理人員提供相應的維護界面，具有自動批量回收、人工回收、生成上報文件、錯單打印輸出、舍棄等處理方式，操作維護簡便。5.10 數據交互由于采用的是全省集中式的計費系統，即所有的用戶通話記錄全部傳送至省計費中心進行計費分揀，而經過省計費中

53、心計費分揀后形成的用戶清單必須下發到各個地市業務管理系統；短消息計費中心與集團計費中心之間也需要有漫游來、出訪的數據交互，同時，各種結算數據也需要進行相應的數據交互，因此，必須有相應的數據交互模塊負責進行各類交互數據的傳輸和下發。短消息計費中心向各地市的業務管理系統發送的數據包括： 省內用戶詳細話單（包括短信網關清單和短信中心清單） 省內用戶帳單（包括短消息費用及用戶由WAD所產生的預存費用） 統計數據 用戶業務變更數據（SMC/SMCF）5.11 系統查詢系統查詢管理完成計費系統各種相應的對內對外查詢功能，主要是客戶查詢、業務查詢。系統查詢應能迅速查詢出本省用戶的通話話單，并且系統查詢與計費

54、處理不能產生沖突，發生查詢和計費互相鎖定的狀況。系統查詢要求： 具有本省用戶的詳細話單查詢（按月份、按日期段） 能支持一些復雜條件的查詢。 能支持對各種計費參數的查詢。5.12 系統維護系統維護是整個短消息計費系統中非常重要的環節，它能對整個系統的運行狀況、運行效率、安全操作等起到重要的監測、維護作用。同時，XX省短消息計費系統的最終用戶是移動通信局計費中心的相關業務人員，他們有較強的業務知識和管理經驗，但是整個工程牽涉面廣，維護工作量大，為了減輕用戶的維護工作量，要求“移動計費系統”有較好的用戶界面，操作簡單直觀。 參數管理：在設計移動短消息計費結算系統中充分引入了參數驅動的設計思想。在應用

55、程序中，凡是不能確定的因素或是可能變動的因素都盡量做到參數化，以達到通過對參數的設置就可適應不同情況、不同應用時期的要求。在計費系統的設計中，各種費率、基本資源、資費信息、優惠定義、結算標準等都是以參數的形式存放于數據庫的相應的表中，當某些業務發生變化需要修改時，只需修改相應的參數即可做到整個計費業務的修改，做到了參數的修改與程序的修改相獨立。在參數管理中，引入了“計費參數預定義”的設計思想，即可以預先定義某些計費參數和它的啟用日期。當系統運行到了這個啟用日期后會自動啟用這些新的計費參數。這種設計思想大大地加強了系統的自適應性和靈活性。參數管理主要包括：u 費率管理u 優惠管理u 省內資源維護

56、u 其它資源維護 系統管理：計費系統中很大的一部分維護工作量是體現在數據庫系統的管理維護上，而對于電信企業來說，不可能也沒有必要去培訓一批數據庫專家來為系統做管理維護，因此，系統提供一些圖形化的界面反映出數據庫系統的活動狀況，以便于操作管理人員進行系統維護；對重要的參數數據具備記錄校驗功能，防止非法刪改。同時，系統具有自動備份、日志管理等功能，對任何被保護的數據資源，如系統文件、應用程序文件、數據庫文件等的訪問、拷貝或修改等操作記錄詳細日志，包括操作員工號、操作類型、操作對象、操作時間、操作設備點、操作結果等。當有任何非法的存取操作時，系統立即反映到主控操作臺并給出告警提示。數據庫系統的管理備

57、份也可以采用第三方的工具軟件來完成，如百達靈公司的數據庫管理工具等。系統也具備相應容錯手段，允許操作人員在有限范圍內的誤操作，對于一些關鍵性的操作要經過多次確認后方能進行，并會根據用戶的登錄名、時間等記錄下完整的用戶操作日志，對每次非法操作產生告警。同時，系統具備完整的操作權限管理辦法，例如：操作口令管理，修改或刪除用戶的權限等。不具有某些權限的用戶絕對不能進行相對應的操作，系統具有在線幫助功能。第6章 系統關鍵問題6.1 與GSM計費系統的融合6.1.1 簡述移動短信計費系統作為移動局業務支撐系統的一個有機的組成部分，是不可能和移動計費系統完全獨立的，作為業務支撐系統的一部分，該系統的很多組

58、成部分將和現有的移動計費系統共用，主要有以下幾個方面：參數管理目前的短消息計費系統的參數是從計費系統傳來的，系統每天接收一次移動計費系統的參數表數據，由于網絡及計費數據庫的原因，有時參數傳遞會失敗從而導致短消息計費產生錯單，在本期短消息計費系統的設計上，我們將短消息計費的參數放入移動計費系統的參數數據庫中，由移動計費的參數管理系統統一管理，從而避免兩個系統參數的不一致造成的技術和管理上的不方便。上傳下發集團中心下發的M文件可以和計費系統的D文件、I文件等放在同一個通信機上，由傳輸程序將文件傳送到短信計費中心的預處理機上處理。對下發各地市的清單文件，同樣可以和計費系統的下發服務器共用，采用此方法

59、，即可以充分利用目前的軟件及硬件資源，又可以減少維護的復雜程度。統計分析通過SYBASE的復制服務器，可以將短信計費系統的統計信息實時復制到計費系統的統計服務器上，在現在的統計結算模塊中增加對短消息信息的統計報表輸出，同時可以將短信的統計結果和移動計費的統計結果合并到一張報表中。6.1.2 系統結構圖短信計費系統與移動計費系統的系統結構圖如下：6.2 關于帳務系統在我們的建議方案中，并沒有包括關于帳務系統的內容，原因如下：1、 短消息計費系統是目前的GSM計費系統的功能擴充，是與GSM計費系統有著密切的聯系的，應當將GSM計費系統與短消息計費系統進行有機的結合；2、 目前，一臺清、一單清是提高

60、服務水平，提高服務質量的普遍要求，不能因為增加了一項業務功能，就需要單獨建立一個相應的帳務系統，這樣對用戶來說很不方便；3、 目前GSM的帳務系統所采用的模式已經固定，如果要對其進行改造則非常困難，應當不屬于短消息計費系統所應考慮的范圍。6.3 關于超額部分短消息計費系統需求中提出：1、 實現月租 + 超額信息量計費方式；2、 月租 + 超額次數計費方式；同時，需求中也明確提出希望以上兩項功能在帳務系統中實現。當然，在帳務系統中實現是最容易實現的方法，但如果要想在清單一級體現出以上兩項功能，則需要計費系統進行相應的判斷，為此，計費系統必須要獲得相關的用戶資料，才能進行準確判斷，這對整個系統的開

61、銷都是比較大的。因此，考慮到實際情況，我們也認為以上兩種計費方式應當由帳務系統實現。6.4 關于SMC話單SMC話單反映出用戶的業務變化情況，需要及時通知各地市的業務系統。為了實現這一功能，可以采取類似于移動漫游用戶話單上傳的方式，即每15分鐘生成一個文件，向各地市業務系統下發，以便業務系統能及時了解到用戶業務變更的信息，同時，考慮到傳輸的穩定可靠和處理的及時性，可以由各地市的業務系統在收到這些SMC話單話向省中心傳送確認文件，用以確保各地市收到相關的信息。第7章 系統平滑過渡7.1 組織成立系統割接領導小組，確定雙方技術負責人員，明確雙方技術人員在系統割接各環節的分工及職責；確定系統割接各階

62、段的時間進度表，并落實到每個執行人；7.2 系統過渡割接的方式系統過渡割接一般采用如下三種方式之一： 分步到位 一次到位 并行運行建議采用并行運行的方式。即新老系統并行運行13個月，運行過程中，雙方技術人員進行全方位的比較測試，確保萬無一失。7.3 系統過渡割接步驟在整個割接過程中，關鍵在于準備工作是否充分，測試、驗收工作是否細致。整個過程分如下步驟：準備工作 主機服務器性能測試； 網絡傳輸可靠性測試； 交換機原始計費數據文件傳輸測試； 客戶端維護終端測試； 預處理與原始計費數據文件傳輸隊列接口測試； 入庫性能測試； 負載均衡測試； 參數準備及維護測試； 計費正確性測試； 上傳、下發接口測試； 系統性能調優測試等。在整個系統過渡割接過程中，始終要保證預處理服務器地址不變。系統過渡割接的時間應選擇在一個計費周期的開始。