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 章 平臺及運行環(huán)境設計 134.1 主機系統設計原則 134.2 主機系統平臺現狀

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

3、問題 316.1 與GSM 計費系統的融合 316.1.1 簡述 316.1.2 系統結構圖 326.2 關于帳務系統 326.3 關于超額部分 336.4 關于SMC 話單 33第 7 章 系統平滑過渡 337.1 組織 337.2 系統過渡割接的方式 347.3 系統過渡割接步驟 34第1章 前言隨著我國移動通信事業(yè)的迅猛發(fā)展，為了迎接日益臨近的市場競爭，電信部門在開拓市場業(yè)務，擴大電信網通信能力的同時，越來越重視電信企業(yè)內部的服務意識，并不斷完善電信企業(yè)的服務體系，為此作出了不懈的努力。南京聯創(chuàng)系統集成股份有限公司自成立之初便確立了以電信行業(yè)作為自己重要的發(fā)展方向。目前，在電信行業(yè)已具有

4、了豐富的積累和長足的發(fā)展，取得了可喜的成績。尤其在電信計費、電信業(yè)務這一領域，公司著眼長遠，立足未來，投入了大量的精力，進行電信計費、業(yè)務等應用軟件的研究開發(fā)工作，致力于為電信行業(yè)提供全面的解決方案?，F在公司已具有一批既精通計算機技術又深諳電信業(yè)務的專業(yè)技術人員和一支穩(wěn)定的高素質開發(fā)隊伍，為能夠開發(fā)移動短消息計費系統準備了充足的人力資源和強大的技術支持。而且，江蘇移動的短消息計費的一期工程也是由聯創(chuàng)公司承建的，我們對原來系統的了解將有助于我們更好的建設新系統。同時，我們真誠地希望，藉此機會能夠和貴局進行廣泛的交流，進一步鞏固和加強相互間長期的友好合作關系。我們將虛心地向貴局的行家們學習、請教，

5、進一步提高我們的知識水平和業(yè)務能力，從而為江蘇移動提供更加優(yōu)質、完善的服務。第2章 系統概述江蘇移動通信有限公司已于 2000 年 5 月根據集團公司的要求建設了短消息計費應急系統，實現短消息按條計費的要求。隨著短消息用戶數的增加，目前所有的GSM 用戶都可以是短消息用戶，同時隨著手機炒股，GPS 定位、以及MONTERNET計劃中大量基于短消息的豐富應用逐步推出，原來的短消息應急系統在性能和功能上都難以適應業(yè)務的發(fā)展要求，迫切需要建設一個完善的短消息計費系統。2.1系統概況2.1.1現有系統概況移動計費的短消息計費系統目前為應急系統，其中有五臺機器組成，兩臺 pc機及三臺惠普的pc serv

6、er，pc 機上安裝有SCO UNIX，分別運行短消息話單的預處理及下發(fā)程序。Pc server 上安裝有NT 操作系統，運行SYBASE11.9.2 的數據庫服務器，分別處理南京、無錫、蘇州等三個短消息中心產生的短消息話單。目前該系統支持全省 100 萬用戶的短消息業(yè)務，每月的短消息話單數大概為 2000萬。2.1.2建設系統概況本期工程設計主要實現省計費中心系統實時處理能力滿足數字網（GSM）300萬以上移動用戶每天 7 條短消息話單的計費需求。2.1.3系統設計目標隨著電信企業(yè)向著規(guī)?；⒍嘣洜I轉變的不斷加劇，越來越多的電信企業(yè)開始從傳統、單一的經營模式向著“以市場為導向，以滿足用戶

7、需求為經營目標、以服務于用戶為經營宗旨”的經營理念轉變，這就更進一步加大了電信企業(yè)間競爭的力度。如何更好地服務于用戶、更好地滿足市場的需求已開始成為眾多電信企業(yè)經營者的關注所在。本期工程就是要為 XX 省構架一個覆蓋全省的短消息計費管理平臺，系統的建設按滿足到 2002 年移動通信網用戶發(fā)展的需要考慮（300 萬以上 GSM 短消息用戶）。本期工程的建設目標是，建立一套能滿足 300 萬短消息用戶的短消息計費平臺。2.1.4數據庫平臺要求數據庫平臺應采用SYBASE 數據庫平臺,能完成大容量數據的實時處理和管理的能力，SYBASE 數據庫能滿足以下要求： 支持ANSI/ISO SQL-89、A

8、NSI/ISO SQL-92； 支持并行處理技術； 支持主流廠商的操作平臺； 支持多種復制功能 支持聯機分析處理（OLAP）； 支持聯機事物處理（OLTP）； 支持C2 級以上安全標準、多級安全控制； 具有強的容錯能力、錯誤恢復能力、錯誤記錄及預警能力； 支持聯機、脫機備份等。2.1.5主機服務器平臺要求主機服務器平臺應具有較高的安全控制機制，各平臺除有足夠的能力進行計費處理外，還應具有其它（例如故障檢查、故障處理等）的應急處理能力。所選擇的主機平臺應該滿足以下特性：1高擴展性。當業(yè)務量增加或增加新業(yè)務時，主機能以增加節(jié)點、處理器、內存等方式提供更高的性能來滿足新的要求。2高可靠性。主機系統需

9、 7*24 小時連續(xù)運行，同時系統應具有良好的容錯能力。系統應采用冗余配置，保證系統無單一故障點。3支持并行技術。支持多臺主機并行的處理，以保證大容量數據處理的要求。4易于管理與使用。保證系統的易使用性，并使系統在較優(yōu)的狀態(tài)下運行，以提高系統的的運行和處理效率。5恢復周期短。當對系統進行擴容或系統發(fā)生不可預見的故障時，系統應能在 24 小時內恢復到正常運行狀態(tài)。2.1.6計費數據處理要求數據處理包括三部分數據： 短消息中心采集到的原始話單數據。 短消息網關采集到的原始話單數據。 集團中心下發(fā)的本省用戶的全國性業(yè)務的話單文件。為保證忙時的數據處理要求，系統完成對話單的計費處理（包括格式轉換、檢錯

10、、糾錯、入庫、查找重單、分檢）的速度正常情況下要達到： 本地話單，從話單出現在計費采集接口到完成計費處理（包括采集、預處理、批價、存儲、分檢），不超過 15 分鐘； 全國業(yè)務話單，從話單放在全國移動計費結算中心設在省中心的通信服務器到完成數據的處理（包括話單的檢查、存儲、分檢），不超過 15 分鐘。2.1.7維護管理要求 系統具有良好的交互性，操作簡單、明確。 系統提供多種訪問手段，允許管理員在不同的環(huán)境下對系統進行管理。 系統提供完備的監(jiān)控和調度工具，具有完備的監(jiān)視、故障檢查與告警、故障處理功能。 盡量將主機、網絡、數據庫、應用系統、以及第三方產品的管理集中到單一的監(jiān)控和管理平臺上。 系統的

11、管理應具有較高的自動化程度。 系統應具有可靠的備份機制。2.2系統設計原則針對移動短消息計費系統的特點，為了保證系統的成功實施，我們制訂系統設計原則為：系統性、正確性、完整性、可維護性、先進性、繼承性、安全性、規(guī)范性和容災考慮。 系統性：移動短消息計費系統是一個覆蓋了全省的計算機管理工程，要想成功地構架這一系統，使之能滿足 XX 省目前直到 300 萬以上移動用戶的需要，則必須正確合理地綜合分析主機、網絡、數據庫系統所提供的性能并充分考慮到整體系統的可擴展性，使整個應用系統的性能達到最佳狀態(tài)，以滿足不斷增長的用戶數及話單數的要求。 正確性：指數據的正確性。數據的正確性必須貫穿在整個短消息計費系

12、統的每個環(huán)節(jié)中，數據采集、數據傳輸要有相應的數據校驗，必須剔除計費過程中各種類型的錯誤話單，排除用戶三個月以內的重復話單、與各業(yè)務管理中心等系統進行數據交互時的準確性、兼容性。在系統設計時充分考慮系統運行過程中數據的正確性并提供合理的解決方案。 完整性：指系統功能的完整性。它要求短消息計費系統應滿足 XX 省移動通信業(yè)務經營、管理、決策的需要，同時要求系統能與其它系統（如集團中心的短消息中心）進行信息共享或提供數據接口。 可維護性：指系統中某一相對獨立的模塊發(fā)生改變時，不影響其他模塊的運行，維護操作簡單，用戶操作界面友好；當系統處理的某些指標需要動態(tài)改變時，不需要修改程序代碼就可以實現相應功能

13、，充分做到代碼與數據的獨立性，以減少操作維護人員的工作量和工作繁重程度。 先進性：指系統模式結構的先進性以及軟件設計思想的先進。在構架移動短消息計費系統時必須采用先進、成熟、可靠的技術，確保整體系統的先進性，利用面向對象的設計思想，對一些通用性、規(guī)范性較強的模塊采用面向對象的“構件”技術，對于超大規(guī)模的數據量，引入“數據挖掘”等先進技術，為系統的決策支持、數據分析提供先進的工具平臺。 繼承性：指本系統在開發(fā)實施階段，應充分考慮利用 XX 省原有的短消息計費系統及移動電話計費系統數據資源以及其他一些可以繼承的軟、硬件資源，必須在建設系統中得到充分利用，以充分保護用戶的投資利益。 安全性：計費數據

14、是移動經營最重要的收入來源，而整個計費系統是構架在全省范圍內的一個大型廣域網系統。因此，在信息高度共享的系統中，必須充分利用主機、網絡以及數據庫管理系統提供的安全保障機制，確保計費數據的絕對安全。對于應用系統而言，對所有系統數據的操縱，嚴格按照權限級別進行，嚴禁非法用戶進入系統，對于操作人員進行的相應重要的操作有相應的操作日志。同時，對系統重要數據提供可靠的備份和恢復機制，以確保整個應用系統的安全。 規(guī)范性：在技術、業(yè)務的理解上要完全遵循 XX 省移動公司關于短消息計費的要求；在主機的安裝、網絡的設計時嚴格遵守相應的規(guī)范；應用系統實施數據庫設計時，也應按照規(guī)范化理論進行，同時保留一定的冗余，確

15、保系統的效率和性能。 容災考慮：系統應盡量考慮到如何避免異常狀況的出現，同時也應考慮在異常情況出現時的處理方法。第3章 系統結構設計3.1短消息計費系統的特點短消息計費系統與傳統的GSM 話音計費是有著許多的區(qū)別的，因此，短消息計費系統在業(yè)務處理上和流程上應該有其自身的要求，如：1、短消息系統的話單源與 GSM 計費系統有差別。短消息系統的話單源不僅產生在短信中心，同時，也會產生在短信網關，并且，這兩種類型的話單源還起著不同的作用，一個是用來計算用戶的通信費，一個是向用戶代收取信息費以及與SP 之間的結算；2、短消息系統的話單根據采集點及話單的不同，分為MO、MT、SMO、SMT、 SMC、S

16、MF、SMA 多種類型，分別起著不同的作用，而在傳統的計費系統中，一般所涉及到的話單類型為MOC、MTC、POC、PTC 幾種；3、短消息話單中某些話單是已經批好價的，如從短信網關傳送回的話單，已經包括了用戶的信息費，而對于GSM 來說，所有的話單都需要進行批價計費。4、從短信中心產生的話單和從短信網關產生的話單的格式是不一樣的。5、短消息的費用類型與 GSM 與區(qū)別，GSM 話單的費用類型可以分為通信費、長途費兩大類，而短消息所涉及到的費用為通信費、信息費、勞務費6、短消息牽涉到與SP 之間的結算，而GSM 牽涉到的是只與聯通、電信等電信運營商的結算。7、短消息系統不僅是要向用戶“收錢”，而

17、且由于有“WAD”信息發(fā)布、廣告業(yè)務，短消息計費系統還要向用戶“送錢”，這一部分送的錢需要與帳務系統間重新定義接口，以便于將其轉換為用戶的預存話費。但是，短消息系統的處理流程又與原有的GSM 話單計費的流程有著很多的相似之處，如：1、都包括對話單的采集和預處理；2、對需要對話單的正確性進行校驗；3、都需要對話單進行稽核統計；4、都需要對話單按照某一政策、按不同的費率進行計費批價；5、都會對部分話單進行上傳和下發(fā)的接收處理工作；6、都需要將計費產生的用戶費用信息傳遞給帳務系統，由帳務系統最終形成綜合化的帳單，向用戶收取費用。3.2應用軟件體系結構在充分考慮到短消息計費系統自身的特點以及與 GSM

18、 計費的共同點之后，我們對短消息計費系統的體系結構進行了合理的劃分：短消息計費系統應用軟件的體系結構可以分成四層：即預處理層、核心處理層、管理層和接口層。如下圖：這樣的劃分對于系統的整體靈活性有著非常大的好處，可以使系統能更加適應今后業(yè)務的變化。結合應用軟件的功能和應用軟件的分布情況，應用系統的結構如下圖所示：數據庫服務器數據庫服務器統計結算排重高額（超過一定的條數或流量）標準化批價、入庫稽核排錯 下發(fā)計費批價服務器計費批價服務器上傳下發(fā)服務器考慮到系統充分利用現有的設備，因此，計費批價服務器采用目前已有的L2000 服務器，數據庫服務器采用HP 的N4000 服務器。3.3數據處理流圖短消息

19、計費系統的數據流圖如下：計費、分揀3.4軟件功能模塊短消息計費系統主要有以下幾種功能模塊，各主要功能模塊間的關系圖如下：3.5服務器處理模式設計隨著各種短消息業(yè)務的開通，短消息的話單和剛開通短消息是相比，已經取得了長足的增長，目前應急計費系統已從開始的一臺數據庫服務器擴充到三臺數據庫服務器，目前每月的話單數已經達到了 3000 多萬，而且數據量還在不斷的增加，因此在進行主機選型的時候，一定要考慮到主機的性能要滿足數據量不斷增加的需要。由于短消息計費系統在處理流程上與移動電話計費系統的相似性，我們在考慮服務器處理模式的時候將以目前的移動計費系統的處理模式為參考，即系統由多臺處理服務器組成，每臺服

20、務器的處理能力達到極限后可以在系統上有機的增加服務器從而增加整個系統的處理能力，而系統的總體結構不需做大的調整。第4章 平臺及運行環(huán)境設計4.1主機系統設計原則聯創(chuàng)系統集成股份有限公司在進行主機系統方案設計時遵循以下設計原則： 開放性計算機系統應支持工業(yè)標準或事實標準，以便隨著今后需求的發(fā)展可添加和更新新的模塊。 先進性在兼顧系統成熟性的前提下采用業(yè)界先進的技術，這樣才能保證現有系統的先進性，并隨著技術不斷發(fā)展得到相應的更新。 可擴展性用戶的業(yè)務及需求在不斷地發(fā)展，當現有系統不能滿足應用需求時，系統應有平滑升級的能力。 高性能高性能應體現在整個計算機系統中，包括服務器、網絡、I/O 操作以及軟

21、件。 可管理性由于計算機環(huán)境的不斷擴大，IT 系統的更加復雜以及覆蓋面的增加，對服務器、網絡設備和應用軟件的管理已成為設計計算機環(huán)境不可缺少的一部分。 選領導地位廠商產品如所選廠商不在業(yè)界處于領導地位，盡管有時所選產品在技術上有暫時的領先性，但很容易被激烈的市場競爭所淘汰，用戶的投資將得不到保護。短消息計費處理系統應嚴格按照業(yè)務協議的內容設計、執(zhí)行，做到計費數據處理及時、準確，系統簡潔，便于維護，各類功能齊全而易于擴充。采用先進和技術成熟的主機、網絡和應用系統，建立一個具有高可用性、高可靠性、高安全性、有良好的可擴展性和可維護管理性的準確、快速、開放的高性能系統。4.2主機系統平臺現狀目前系統

22、的平臺現狀如下：PC Server/Win NTPC/SCO UNIXD270短信息計費系統平臺各機器的配置信息如下：數據庫服務器：PC 服務器，CPU 400MHZ 以上，內存 1G 以上、硬盤 100G（目前數據庫服務器已從一臺擴充到三臺）；預處理服務器：高檔PC,CPU300 以上，內存 256M 以上、20G 以上；下發(fā)服務器：高檔 PC，CPU300MHZ 以上，內存 256M 以上、20G 硬盤，MO 驅動器；應用服務器：PC、CPU300 以上，內存 128M 以上、4G 以上。軟件環(huán)境如下：數據庫服務器：操作系統 Win NT4.0、數據庫 Sybase 11.9.2；預處理服

23、務器：操作系統 Sco Unix 5.0 以上版本、Sybase 11.9.2 Client；應用服務器：操作系統 Win9X、Sybase 11.9.2 Client、PowerBuilder 6.5 以上；下發(fā)服務器、預處理服務器：操作系統 Sco Unix 5.0 以上版本、Sybase11.9.2。4.3主機系統需求分析4.3.1影響性能的幾個方面影響服務器整體性能的因素是多方面的，針對不同的應用，設計時考慮的側重點也不同。移動通信計費系統這類聯機事務處理的應用，主要從 CPU、內存和I/O 三個方面考慮，下面分別進行論述：CPU：聯機事務處理的主機，主要是作為數據庫服務器而不是計算服

24、務器，因此以服務器的TPM 值作為相對選型參考值。需要說明的是廠家公布的服務器 TPM 值，一般是采用最大的硬件配置、按照 100%的利用率所得到的，而在實際建設中的系統配置往往小得多，系統性能的TPM 不會有公布值那么高，在對服務器處理能力進行估算時，需要將一些經驗值和TPM 值一起綜合考慮。內存：內存是所有程序運行的環(huán)境，在 CPU 和系統軟件處理能力的范圍內，內存越大則服務器的處理性能越好，但不同的應用對內存的要求不同，所以在計費系統服務器內存設計中，需要從應用需求的角度來考慮，尋找最佳的配置。I/O：在 CPU 處理能力一定的情況下，磁盤陣列的 I/O 速度，可使服務器的整體性能表現相

25、差幾倍到幾十倍，所以我們在設計中要特別注意磁盤陣列 I/O 的選型，盡量選擇I/O 帶寬高的磁盤陣列，同時考慮到單個磁盤的I/O 速度是一定的，需要靠多磁盤的并行讀取來提高磁盤陣列 I/O 速度，在容量和性價比容許的情況下，盡量選擇容量小而數量多的磁盤，能大大提高磁盤陣列的 I/O 吞吐性能。根據應用對磁盤陣列的劃分進行優(yōu)化也是提高I/O 性能的一個重要方面。4.3.2服務器性能分析預處理服務器 聯機事務處理能力的分析預處理服務器主要用于將采集系統傳來的原始話單標準化，并統一批價后形成話單清單供計費服務器排重入庫，其處理是文本轉換和簡單計算的過程。根據聯創(chuàng)在移動計費上的經驗和一百

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

27、并提取供統計分析使用的相關數據。 聯機事務處理能力的分析一張話單的處理流程包括：打開文件、讀記錄、糾錯、入庫、出庫等等，根據聯創(chuàng)在移動計費上的經驗和一百萬用戶級系統實際運行的測算，每張話單的處理約等價于0.5個標準事務，則：300萬用戶，平均每個用戶每天7張話單，即每天2100萬張話單；平均每分鐘處理的話單為：2100萬/(24×60分鐘)=14584張；假設通話高峰時間每天為8小時，則高峰時服務器負荷按平均負荷的3倍計算，此時要求系統的tpmC值為：14584×0.5×3=21876 tpmC；建議系統利用率不超過80，則需要配置的處理能力為21876/80=2

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

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

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

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

32、統可以動態(tài)檢查內存，當發(fā)現壞內存頁時屏蔽該內存頁不再分配給系統使用。網卡（Network Interface card）系統配置雙網卡，一塊工作，一塊作備份。MC/ServiceGuard 可監(jiān)測網卡，當其中一塊不能正常工作時，MC 將自動切換到備份網卡。接口卡服務器與磁盤陣列通過雙接口卡連接，其中一塊卡失效時另一塊卡仍可保證系統正常運行。Internal 磁盤（Disk）系統盤： 用 MirrorDisk/UX 軟件對引導區(qū)（root）、交換區(qū)（swap）鏡像。高 可 用 性 存儲 系 統 （ High Availability Storage System）可熱插拔的磁盤、電源和風扇模塊。

33、FC60冗余電源子系統和系統后備電池。磁盤和高速緩存的檢測和糾錯。應用（Application）MC/ServiceGuard 可以在同一系統上再次啟動應用軟件，或將應用遷移到備份系統上。HP-UX當系統出現突發(fā)停機時，HP 的日志文件系統（JFS）將在 10 秒以內使系統恢復運行。 靈活性由于采用了SAN 技術，當業(yè)務量出現突發(fā)性增長時，可以方便地通過增加服務器或存儲設備的方式提高系統處理能力，而不需要重新構架。這種靈活性既保護了用戶的投資，又提高了業(yè)務系統對市場變化的適應能力。 可擴充性在滿足 300 萬用戶規(guī)模計費性能要求的同時，該系統還具有充分的擴充能力，可以平滑擴展到更高用戶量的處理

34、能力要求，具體表現如下：主機系統通過增加 CPU 擴展性能：A500 單機最多可配置 2 個 550MHz PA8600 CPU ， 處理能力可達15000tpmC。N4000 單機最多可配置 8 個 550MHz PA8600CPU ， 處理能力可達60000tpmC。主機系統通過增加內存擴展性能：N4000 單機現在對內存的支持最高可達 32GB。A500 單機現在對內存的支持最高可達 8GB，主機系統增加內存會對數據庫等大內存需求的應用有很大的性能提高。主機系統通過升級 CPU 擴展性能：目前HP 已經推出了性能更高的 550MHz PA8600 芯片，HP 會推出 PA8xxx芯片及以

35、后的IA64 結構的CPU，N4000 可以通過CPU 升級達到系統性能提升的目的。主機系統 I/O 擴展能力：N4000 單機支持 12 個PCI 的I/O 槽口，I/O 帶寬可達 5.8GB/s。主機系統復雜擴展:除了上述簡單的擴展方法外，也可以通過在群集中加入新的結點的方法來實現性能的擴展。現在MC/ServiceGuard 可支持的HP 9000 Server 結點數為 16個，因此也具有相當的擴展余地。另外，如果應用的性質會轉為數據倉庫的話，在增加一個基結點后，現有的服務器都可作為附加結點加入到企業(yè)并行服務。存儲系統容量的擴展：HP FC60 最大可擴充至 4TB。第5章 應用軟件設

36、計5.1短消息計費系統功能介紹短消息計費系統是一個綜合復雜的系統，它的處理流程與移動計費系統類似，由許多子系統共同組成，并和其他相關系統存在不同的接口。短消息計費系統主要包括數據采集與傳輸子系統、預處理子系統、劃價子系統、下發(fā)子系統、統計子系統、稽核子系統、查詢子系統、監(jiān)控子系統等，下面對各子系統的功能要求進行詳細的描述：5.2數據采集與傳輸子系統5.2.1功能簡介短消息計費系統的數據源有三種：1、短信中心的話單文件2、短信網關的話單文件3、 集團中心下發(fā)的話單文件。其中 1、2 的話單文件由華為的采集機負責采集，而 3 的話單文件是集團中心通過自己的傳輸系統將文件放在江蘇移動公司和集團中心的

37、通信機上，對于短消息計費系統來說，只需將三種數據源的數據傳送到預處理機上。傳輸系統主要完成短消息計費中心與全國計費中心之間、短消息計費中心與地市業(yè)務中心之間、短消息計費中心與計費數據采集機之間以及短消息計費中心與外部系統之間的信息交互與數據傳輸，以保證各級管理系統之間的移動通信資源和數據能夠實時（或準實時）地共享和保持一致，為實現移動通信專業(yè)化集中管理和分級處理提供保證。5.2.2傳輸系統結構在部、省、地市各級中心之間、短消息計費中心與外部系統之間以及短消息計費中心與采集系統之間的交互信息主要有：計費原始數據、用戶清單數據、統計數據等。對于這些數據的傳輸設計，必須充分考慮數據的傳輸效率，以保證

38、計費結算的高效處理。傳輸系統的主要數據流向如下圖所示：地市帳務中心短消息計費中心短信采集平臺集團中心其他接口 短信采集系統與短消息計費中心的數據傳輸短信采集系統與短信計費中心之間傳輸的主要是由數據采集系統從短信中心及短信網關實時采集到的所有計費原始數據，這些數據主要由短信采集系統流向短信計費中心，是一個數據集中的過程，所有的數據傳輸都是實時而且自動化無人值守的，由短信計費中心集中對數據傳輸進行監(jiān)控。 短信計費中心與地市帳務中心的數據傳輸 短信計費中心與地市帳務中心之間傳輸的主要是地市帳務中心所需的用戶帳單、用戶清單和統計數據，所有的數據傳輸都是實時而且自動化無人值守的，由短信計費中心集中對數據

39、傳輸進行監(jiān)控。用戶清單數據文件定期下發(fā)，傳輸周期可以由參數以分鐘為單位來設置。每個下發(fā)文件中包含文件頭、用戶清單，文件頭中包含文件類型、文件長度（包含文件頭）、下發(fā)清單數、用戶數、帳單記錄數、各項費用統計值等信息，下發(fā)文件的命名規(guī)則為：TLLLYYYYMMDDhhmm.NNN其中各位的含義為：T - 文件類型。LLL- 地區(qū)編號，全省統一編號。 YYYYMMDD - 下發(fā)文件生成日期，年月日。 hhmm - 下發(fā)文件生成時間，時分。NNN - 下發(fā)文件編號，000-999 循環(huán)。傳輸系統通過文件名和文件頭信息來驗證數據傳輸的正確性。 短信計費中心與集團中心的數據傳輸短信計費中心與集團中心傳輸的

40、主要是省間結算數據，這是一個雙向數據交換的過程，包括上傳集團中心的結算話單數據及集團中心下發(fā)的結算話單數據。 短信計費中心與外部系統之間的數據傳輸短信計費中心與外部系統之間主要是網間結算數據和業(yè)務統計結果數據的傳輸，系統提供拷盤、聯網文件傳輸、數據庫共享等傳輸方式，具體的傳輸方式需要與相關運營商或業(yè)務部門共同協商確定。5.2.3系統功能傳輸系統由聯創(chuàng)公司基于FTP 自主開發(fā)，該傳輸軟件具有以下功能：1)應用系統或程序之間可靠的、無人值守的雙向數據傳輸功能；2)提供自動數據傳輸和定時通信功能；3)具有傳輸消息事件觸發(fā)功能，在傳輸正確完成后自動觸發(fā)用戶指定的處理進程；4)傳輸系統提供配置和監(jiān)控工具

41、，實時監(jiān)測傳輸線路和傳輸應用的運行狀況，并能及時傳送到省中心的集中監(jiān)控系統；5)具有自動錯誤恢復功能；6)自動重試和斷點重傳功能：數據傳輸中斷后，能自動重新傳輸并跳過已傳輸的數據；7)提供多種數據安全性控制機制：標識與認證、數字標記等；8)提供詳細的傳輸事件日志，并定期對傳輸兩端的日志進行傳輸一致性檢查，若發(fā)現漏傳或錯傳，傳輸系統自動重傳；若發(fā)現其它異常或故障，通知集中監(jiān)控臺，給出告警。9)對短消息中心采集的原始話單文件的連續(xù)性進行檢查，確保無話單文件重復5.3數據預處理前臺預處理子系統是短信計費系統的核心功能子系統之一，它完成不同格式的計費原始數據的數據提取、標準化等一系列處理工作。計費預處

42、理功能在預處理服務器上完成。鑒于各種交換機計費信息的格式不一，需要在入庫前對各種類型的計費信息進行標準化處理，將不同類型交換機的計費信息統一成標準格式。同時將原始數據中由于各種原因造成的不能計費的話單標識出來，供計費模塊判別。目前短信計費中心的原始話單類型主要有：短信平臺話單：對于短信平臺話單文件，主要有以下幾種話單類型：點對點短消息的話單人工臺或自動臺發(fā)起的MT 方式的短消息話單由移動臺發(fā)起的各種收費信息話單，如股票查詢、用戶訂閱的消息等各種公眾信息源發(fā)布的MT 方式的短信話單，如天氣預報等開通移動夢網后，在短信網關上會增加以下幾種話單類型：短信網關話單類型：SP 發(fā)送給點播用戶的短消息話單

43、（其中包括用戶自點播、用戶為別人點播、及SP 主動發(fā)送的信息三種）集團中心下發(fā)話單：集團中心每兩小時下發(fā)一個M 文件，每天 12 個文件，文件中包括SMT、SMC、SMT-F、SMC-F 四種話單類計費預處理功能數據提?。涸加涗浿邪S多通話信息，但計費分揀應用所需的數據域只是原始通話記錄域的一個子集。由數據提取功能提取計費系統所需的數據域。·支持多種類型交換機原始計費數據的數據提?。?#183;支持多通話業(yè)務的數據提取，并對新業(yè)務提供數據提取接口；·對原始計費記錄提取過程提供完善的差錯檢測功能： 提供記錄級的差錯檢測：支持對每條提取的計費記錄進行數據審核校驗，識別其中的

44、錯誤或無效話單，包括： 格式錯，與移動交換機定義的數據結構不符 重要記錄域為空 錯誤字符，包括： 通話日期、時間、時長非法 對端號碼錯誤 記錄域中含有非法字符 計費信息不足 不需計費話單 提供數據塊級的差錯控制：話單提取后計算出的塊長度（包括塊頭、塊尾、有效話單、錯誤話單）與原始數據塊長度一致性檢驗、塊序號連續(xù)性檢驗。 提供文件級的差錯控制：相鄰處理文件中撥打時間的連續(xù)性檢驗、文件序號連續(xù)性檢驗、數據塊數檢驗、轉換字節(jié)數與文件長度一致性檢驗。 對數據差錯或丟失情況記錄日志，并根據差錯級別提供不同的告警。 記錄標準化·支持原始計費記錄數據格式向計費系統定義的標準記錄格式的轉化；

45、3;支持按設置的參數對大文件進行拆分；·按照計費系統的設計進行計費記錄的數據分類。 預處理配置與管理·提供對整個預處理子系統的各種參數的查詢、配置和修改；·支持原始計費數據的實時備份和數據轉儲；提供對預處理各個模塊的實時監(jiān)控和管理，如：物理空間檢測、用戶口令權限管理、預處理過程監(jiān)測、入庫狀態(tài)監(jiān)測、進程管理等。預處理階段統計 正常有效話單統計 異常話單統計 無效話單統計 錯單糾正統計 對預處理階段非正常的話單應存儲在文件中或數據庫中，以備查詢。 可以對每臺交換機的產生的每個文件的有效話單數、異常話單數、無效話單數的統計，該統計可以按日、周、月、季進行。5.4話單劃價

46、話單劃價所完成的功能是將經過預處理的話單按照相關的資費標準計算出基本費用的過程，也稱為劃價或批價，劃價后形成計費清單數據。計費處理過程能適應最新的短信資費政策，并可滿足今后業(yè)務不斷發(fā)展的需要。計費處理能夠實時地處理短信平臺及短信網關產生的和集團中心下發(fā)的話單，接收到的計費文件在下一文件傳到之前處理完畢，做到話務高峰時不出現話單積壓。在計費劃價的過程中，系統可正確的對各種類型的話單進行劃價，同時可區(qū)分不同的話單類型，并做不同的標記，按照事先確定的分揀規(guī)則進行分揀，以生成不同的清單文件進行并行入庫。對包月類及封頂類的短消息話單類型，劃價程序也進行正常的劃價，清單留做查詢及統計用，具體的收費有帳務系

47、統確定。對按條收費的短消息話單，系統可以根據不同的話單類型進行不同費率的劃價，并可滿足不同優(yōu)惠的需要。對于不同類型的話單，通過統一的參數管理，進行費率的靈活配置，對于信息發(fā)布業(yè)務（WAD），需要建立單獨的用戶費用記錄，傳送給帳務系統，用來做為用戶的預存話費?？紤]到這部分費用與用戶的信用度等判斷有關，建議采用每 15 分鐘一次的間隔，將WAD 產生的用戶的預存費用下發(fā)給帳務系統。5.5重復話單過濾要對重復話單進行過濾，首先應分析一下產生重復話單的原因及如何標識重復話單。產生重復話單的原因主要有： 交換機生成原始通話記錄時產生的重復； 采集過程中故障重采產生的重復； 文件傳輸過程中產生的重復； 數

48、據交互過程中產生的重復（來、出訪話單的上傳、下發(fā)）等。重復話單的標識：同一用戶（IMSI）、同一天（sdate）、同一時刻（stime）產生兩條相同的通話記錄。按照集團中心的要求，需排除三個月以內的重復話單。因此對重復話單過濾技術要求就很高。解決的辦法是： 數據分割 優(yōu)化索引機制 快速定位 以空間換性能這是快速“過濾網”技術的設計思想。5.6話單并行入庫目前在建的短消息計費系統以后每月處理話單的數量可達上億張，這些己劃價的話單是計費系統的基礎數據，需存儲在數據庫中。話單入庫的效率將直接影響計費處理的整體效率，尤其是月末處理的性能。話單入庫的效率除了與磁盤 I/O 的讀寫速度有關外，與數據庫系統

49、的整體設計也有著密切的關系，尤其是出現月初與月末性能差異太大時。解決的辦法： 合理地進行數據分割 有效地建立索引 合理的應用分布，降低磁盤讀寫沖突，減少訪問磁盤的次數。系統效率的提高，需從系統整體設計著手，下面將針對下發(fā)文件的處理，來說明如何降低訪問磁盤的次數，以提高系統整體效率。對經計費處理后的話單文件，需經重復話單的檢測，實驗證明重復話單的檢測，應充分利用數據庫的特性，在數據庫內排重效率最高、最徹底。但發(fā)生重復的概率較小。因此在設計時，考慮到將排重的結果信息反饋給 Client 端，若無重復話單，則該入庫文件直接送給相應的下發(fā)隊列，并在數據庫中產生一條統計記錄（文件名、有效記錄數、重復記錄

50、數、處理時間等）。這樣就無需再從數據庫取相應的下發(fā)數據，減少了磁盤訪問的次數。若發(fā)現有重復話單，則分兩種情況處理： 完全重復：即該文件的所有記錄都為重復話單記錄（文件重復），則在數據庫中產生一條統計記錄（文件名、有效記錄數、重復記錄數、處理時間等），該文件入重復話單文件隊列。 部分重復：即該文件有部分記錄為重復話單記錄，則在數據庫中產生一條統計記錄（文件名、有效記錄數、重復記錄數、處理時間等），并排除重復話單，形成重復話單文件入重復話單文件隊列；將有效話單生成下發(fā)文件入相應下發(fā)隊列。計費劃價后產生的標準話單文件通過并行入庫程序多通道拷貝到數據庫中，并調用存儲過程進行以下工作：排除三個月（包括本

51、月的重單）生成月清單數據生成統計中間表數據生成下發(fā)表數據入庫程序記錄詳細的日志信息，包括入庫話單數，入庫花費時間等。入庫話單不僅包括需要計費的MO、MT 等話單，還要包括已經計好費的用戶信息費的短消息網關傳送的話單，以及用于進行網絡故障分析的 SMA/SMA-F 話單。5.7計費結算短消息計費中心具有集中計費結算功能，能進行省間、省中心與集團中心間、以及省中心與各個SP 間的結算工作。計費結算模塊可以根據用戶通話詳單中的不同的短消息類型和已計算出的費用情況，形成相應的漫游結算和網間結算數據，結算比率可以通過參數設置進行動態(tài)調整。具體類型主要有： 省公司之間的結算 省公司與集團中心間的結算 省公

52、司與SP 之間的結算 省公司與廣告業(yè)務的廣告方的結算5.8統計分析統計分析主要包括以下幾個模塊：文件統計：對每天，每個統計月的原始文件的話單量統計，包含有效話單、錯誤話單、無效話單、發(fā)送失敗話單。業(yè)務量統計：對全省或各地市的每天，每個統計月的業(yè)務業(yè)務構成量的統計。收入統計對全省或各地市的每天，每個統計月的短消息收入的統計。5.9稽核排錯計費系統直接面向廣大的電信用戶，是反映電信企業(yè)業(yè)務水平和管理層次的重要體現，因此，計費系統必須確保將一些錯誤因素排除在用戶面前?；伺佩e主要完成計費過程中一些異常情況的處理并形成相應的出錯報告，避免異常話單出現在用戶面前，同時，系統也應能將一些經過修改可以向用戶

53、收取費用的話單進行回收，重新進行計費分揀，使電信企業(yè)避免不必要的損失?；伺佩e分為兩部分：原始計費數據的稽核排錯，即分揀出各短信平臺的異常話單和錯誤話單貫徹于整個計費過程中的稽核排錯，具體包括以下這些錯誤類型： 格式錯 錯誤字符 信息不足話單 重復話單 無費率話單等我們針對“重復話單”這一錯誤類型，在系統中采用了先進的“過濾網排重”技術，可以在系統開銷很小的情況下迅速排除重復話單，完全能夠滿足排除 3個月內重復話單的要求。系統對于出現的各種錯誤話單有相應的統計報告，可以讓相關部門對這些錯誤話單進行分析。對于經過相應修改可以向用戶收取費用的話單，系統具有完善的回收功能，對這部分話單進行重新計費分

54、揀，以避免電信企業(yè)不必要的損失，系統給操作管理人員提供相應的維護界面，具有自動批量回收、人工回收、生成上報文件、錯單打印輸出、舍棄等處理方式，操作維護簡便。5.10數據交互由于采用的是全省集中式的計費系統，即所有的用戶通話記錄全部傳送至省計費中心進行計費分揀，而經過省計費中心計費分揀后形成的用戶清單必須下發(fā)到各個地市業(yè)務管理系統；短消息計費中心與集團計費中心之間也需要有漫游來、出訪的數據交互，同時，各種結算數據也需要進行相應的數據交互，因此，必須有相應的數據交互模塊負責進行各類交互數據的傳輸和下發(fā)。短消息計費中心向各地市的業(yè)務管理系統發(fā)送的數據包括： 省內用戶詳細話單（包括短信網關清單和短信中

55、心清單） 省內用戶帳單（包括短消息費用及用戶由WAD 所產生的預存費用） 統計數據 用戶業(yè)務變更數據（SMC/SMCF）5.11系統查詢系統查詢管理完成計費系統各種相應的對內對外查詢功能，主要是客戶查詢、業(yè)務查詢。系統查詢應能迅速查詢出本省用戶的通話話單，并且系統查詢與計費處理不能產生沖突，發(fā)生查詢和計費互相鎖定的狀況。系統查詢要求： 具有本省用戶的詳細話單查詢（按月份、按日期段） 能支持一些復雜條件的查詢。 能支持對各種計費參數的查詢。5.12系統維護系統維護是整個短消息計費系統中非常重要的環(huán)節(jié)，它能對整個系統的運行狀況、運行效率、安全操作等起到重要的監(jiān)測、維護作用。同時，XX 省短消息計費系統的最終用戶是移動通信局計費中心的相關業(yè)務