文英，成勇，劉曉峰，葉軍

（中國移動通信集團廣西有限公司，南寧 530022）

1 GPRS按時長計費模塊的現(xiàn)狀

目前GPRS業(yè)務主要有3種計費模式：按流量、按時長和按內容計費。按流量計費，即按用戶上網(wǎng)時產生的上、下行流量之和來計費。按時長計費，即按用戶上網(wǎng)時長來計費，推出的業(yè)務主要為一些包月、包半年、包年的手機及上網(wǎng)卡套餐業(yè)務。按內容計費的核心是將流量按照業(yè)務區(qū)分開來，進行區(qū)分的規(guī)則即內容計費的規(guī)則。

1.1 GPRS按時長計費模塊的處理機制

GPRS按時長計費模塊，即TBCG（Time Based Charging Gateway）， 是 CG （Charging Gateway）與BOSS之間的“時長計費網(wǎng)關”系統(tǒng)負責采集各個CG上的CDR（Charge Detail Record）文件以及BOSS同步過來的漫游CDR文件，從這些話單文件中過濾取得“時長計費”用戶的CDR記錄，并對非正常下線及歷史記錄時間交叉、重疊的話單進行處理，最后將外理后的新CDR文件提供給BOSS系統(tǒng)進行計費。TBCG軟件架構如圖1所示，各CG對應的傳輸是通過FTP方式取得全網(wǎng)GPRS話單，再由各CG對應的處理模塊統(tǒng)一完成時長用戶訂購關系的讀取、時長CDR篩選、話單交叉及剔重處理等操作。

圖1 TBCG模塊軟件架構圖

1.2 GPRS按時長計費模塊的處理性能

現(xiàn)網(wǎng)TBCG模塊通過磁盤讀取用戶資料將按時長計費話單篩選出來，再進行后續(xù)的話單交叉去重處理。按此方式模塊I/O消耗較大，在節(jié)假日等峰值業(yè)務量較大情況下易出現(xiàn)效率低下問題。同時由于TBCG是通過BOSS同步時長用戶訂購數(shù)據(jù)來獲取用戶資料，而不是直接讀取BOSS側的全量時長用戶訂購數(shù)據(jù)，故較容易因網(wǎng)絡故障、同步異常等情況導致TBCG與BOSS側訂購關系不一致。

2011年春節(jié)期間時長用戶數(shù)僅3.5萬余戶，時長話單約為180～190萬條CDR/天，峰值為60條CDR/s。但受到全網(wǎng)GPRS用戶及話量增長的影響，期間全網(wǎng)話單量較平時增長近2倍，日均話單量達35 000～37 000萬條CDR/天，峰值達2 500條CDR/s，系統(tǒng)性能急劇下降而無法及時采集并篩選處理話單，出現(xiàn)大量話單積壓從而導致時長話單處理效率低下，存在計費延遲。

2 在BOSS側新增GPRS時長計費話單處理模塊

2.1 總體思路

基于現(xiàn)有BOSS計費系統(tǒng)中GPRS話單處理流程，新增GPRS時長計費話單處理模塊。在業(yè)務分析結束后，GPRS按時長計費用戶的GPRS話單將由該模塊按使用時間進行剔重及拆分處理，處理完后將話單傳送給批價模塊進行批價。該模塊和計費處理流程實現(xiàn)松耦合，若模塊存在話單積壓或者模塊異常不會影響到其它GPRS話單的計費正常處理。同時，該模塊和計費處理流程均通過MDB獲取用戶資料等信息，保證了數(shù)據(jù)的一致性。系統(tǒng)總體框架如圖2所示。

2.2 GPRS時長計費話單處理流程

新增的GPRS時長計費話單處理模塊，包括異常話單處理和交叉話單處理2個子模塊，分別實現(xiàn)過濾零流量話單和剔重時間交叉話單功能。

異常話單是指單個PDP上下文激活中存在通話時間大于0、但流量為0的話單，即有時長無流量的零流量話單，其處理原則是當正常話單之后連續(xù)出現(xiàn)30 min異常話單的情況，之后再出現(xiàn)的異常話單則不再計費。

交叉話單是指單個或多個PDP上下文激活產生的話單中時間存在重疊（交叉），其處理原則是后到話單如果與先到話單產生時間片交叉，則修改后到話單的開始時間和時長字段，避免與先到話單產生時間片交叉。

表1 2011年春節(jié)期間與平時話單量比較

圖2 新增GPRS時長計費話單處理模塊

3 異常話單處理場景分析

考慮用戶上網(wǎng)行為及產生的話單情況，系統(tǒng)中可能出現(xiàn)的異常話單場景共計9個，各場景下新增模塊對話單的處理情況分析如下。其中Ri表示第i條話單，i為話單到達順序；有流量話單單獨標識，無標識即為無流量話單；第i條話單的原始時長記為Di，修改后的時長記為Di’，時間戳格式為開始時間-結束時間；Tib、Tis分別為第i條話單的開始時間和結束時間，Tib’、Tis’分別為修改后第i條話單的開始時間和結束時間；時間單位均為min。

場景 1：R1（有流量）: 0～ 10，R2: 10～ 40，R3: 40～50，處理后不修改R1、R2，過濾R3。

場景 2：R1（有流量）: 0～ 10，R2: 10～ 35，R3: 35～50，處理后不修改R1、R2，修改R3時長為5。

場景 3：R1（有流量）: 0～ 10，R2: 10～ 45，R3: 45～55，處理后不修改R1，修改R2時長為30 min，過濾R3。

場景4：R1（有流量）: 0～10，R2: 5-T2s（T2s>10），處理后不修改R1，修改R2開始時間為R1的結束時間，時長為D2’= T2s-R1結束時間。其中若D2’>=30，則D2’=30； 若D2’<30，則D2’取實際差值。

場 景 5：R1: 0～ 10，R2: 10～ 40，R3: 40～T3s（T3s>40），因有流量話單一直沒有到達，到達設定閾值后過濾R1、R2和R3。

場 景 6：R1: 10 ～ T1s（T1s>10），R2: T1s～ T2s（T2s>T1s>10），R3（ 有 流 量 ）: 0～ 10，過 濾R1； 若D1+D2>=30,則D3’=D3+30； 若D1+D2<30,則 D3’=D3+D1+D2。

場景 7：R1: 15～ 35，R2: 40～ 55，R3（有流量）:0～10，則R1、R2繼續(xù)等后續(xù)話單。

場景8：R1: 5～ T1s（T1s>5），R2: T1s～T2s（T2s>T1s>5），R3（有流量）: 0 ～ T3s（5=30,則 D3’=D3+30； 若（D1+5-0）-D3<30,則D3’=D1+5-0。

場 景 9：R1: 0～ T1（T1>0），R2: 30～ T2（T2>30），R3（ 有 流 量 ）: 0～ T3（T1=30,則D3’=D3+30；若 D2-（T3-30）<30,則 D3’=D3+D2-（T3-30）。

4 交叉話單處理場景分析

考慮用戶上網(wǎng)行為及產生的話單情況，系統(tǒng)中可能出現(xiàn)的交叉話單場景共計7個，各場景下話單的處理情況分析如下。其中Ri表示第i條話單，在此部分均為有流量話單，其余符號同上。

場景 1：R1: 0 ～ T1，R2: T2b ～ T2s（0

場景2：R1: T1b～T1s（0

場景3：R1: 0～T1s（T1s>0），R2: T2b～T2s（0

場景4：R1: T1b～T1s（0

場 景 5：R1: T1b ～ T1s（0

場景6：R1: T1b～T1s（0T2s），處理后不修改R1、R2，將R2切割成5條話單，其中過濾時間與R1、R2重疊部分，生成新話單R4：0～T1b（0

表2 TBCG模塊與GPRS時長話單計費模塊處理能力比較

場 景 7：R1: T1b ～ T1s（0

5 優(yōu)化前后處理性能比較

2011年10月在BOSS側新增GPRS時長話單計費模塊并正式啟用后，系統(tǒng)運行平穩(wěn)。統(tǒng)計2011年12月1～7日的GPRS按時長計費模塊的處理話單速率，得出單進程時長話單處理的平均速度為102條CDR/s。由此可計算出單進程一天的處理速度：102條CDR/s×3 600 s×24 h＝8 812 800條CDR/天，即約880萬條CDR/天。在模塊壓力測試中，輸入了5天共計270余萬條時長話單，按時長模塊在5 h即全部處理完畢，忙時處理速度約為155條CDR/s。

結合2012年1月春節(jié)期間話單量情況，對TBCG模塊與BOSS側GPRS時長話單計費模塊處理能力進行了相關比較，如表2所示。

2011年春節(jié)期間時長話單峰值話單量達60條CDR/s，此期間TBCG模塊整體性能急劇下降，累計積壓達40萬個話單文件。

BOSS側新增GPRS時長話單計費模塊后，日均所處理的GPRS按時長話單量約為80萬條CDR/天，忙時約為8～12條CDR/s，未出現(xiàn)積壓情況。2012年春節(jié)時長話單峰值話單量為95條CDR/s，平均約57萬條CDR條/天；而目前BOSS側GPRS按時長模塊平均處理速率約102條CDR/s，在壓力測試中可達155條CDR/s，平均每天可達880萬條CDR/天。從訂購數(shù)據(jù)及用戶相應話單記錄來看，未出現(xiàn)訂購數(shù)據(jù)不一致問題。從采集、解碼及其它環(huán)節(jié)日志統(tǒng)計來看，未出現(xiàn)積壓情況，平穩(wěn)支撐了春節(jié)峰值業(yè)務量增長。

6 結束語

通過對現(xiàn)網(wǎng)GPRS按時長計費模塊的性能及處理瓶頸的分析，在原有話單處理流程基礎上，新增了GPRS時長計費話單處理模塊，實現(xiàn)對異常和交叉話單的處理。通過分析和比較優(yōu)化前后系統(tǒng)性能情況，上線后及2012年春節(jié)期間的統(tǒng)計數(shù)據(jù)表明優(yōu)化后模塊處理性能提升顯著，有力地支撐了業(yè)務發(fā)展需求，保證了模塊間數(shù)據(jù)一致性，確保BOSS平穩(wěn)運行。

[1] 馬莉. 3G數(shù)據(jù)業(yè)務內容計費模式探討[D]. 北京：北京郵電大學，2009.

[2] 王孟杰. 新一代互聯(lián)網(wǎng)業(yè)務計費功能的研究與實現(xiàn)[J]. 北京：北京郵電大學學報，2009.

[3] 王伊霖，周峰，刁艷蓉. 移動互聯(lián)網(wǎng)融合業(yè)務的內容計費[J].電信科學，2009.

[4] 葉軍，周佳佳，魏立勤. 話單計費方法及裝置[P]. 專利號:201010102796，2010.

[5] 廣西移動. TBCG系統(tǒng)維護手冊[Z]. 2010.

[6] 廣西移動. OpenBillingNG操作手冊-TBCG模塊.doc[Z]. 2011.