準(zhǔn)3GPP TS 32.260詳解：架構(gòu)、消息流與常見誤區(qū))
簡介面向IMS計費學(xué)習(xí)與工程實踐者的3GPP TS 32.260中文版規(guī)范聚焦IP多媒體子系統(tǒng)計費管理適合從事核心網(wǎng)計費、運營商支撐系統(tǒng)開發(fā)及通信標(biāo)準(zhǔn)研究的技術(shù)人員用于理解從GSM、UMTS到LTE演進中的計費架構(gòu)與實現(xiàn)要求。資源包共1個PDF文件約2.65MB內(nèi)容涵蓋前言、范圍、參考文獻、定義符號與縮寫以及高級IMS架構(gòu)、離線計費架構(gòu)、在線計費架構(gòu)與融合計費架構(gòu)等章節(jié)并展開計費原則、CDR生成、計費觸發(fā)點、Diameter與Gx接口等關(guān)鍵知識點。已有196人學(xué)習(xí)可作為查閱IMS計費標(biāo)準(zhǔn)條款、梳理在線與離線計費流程的案頭參考建議結(jié)合英文原版對照研讀以準(zhǔn)確把握技術(shù)細節(jié)與術(shù)語含義。1. 打電話、刷視頻背后的“賬本”IMS 計費到底是什么你打完一通 VoLTE 電話或者用手機看了一段視頻彩鈴運營商是怎么知道該收你多少錢的答案藏在一套叫 IMS 計費的機制里。IMS 是 IP 多媒體子系統(tǒng)簡單說就是讓電話、視頻通話、消息這些業(yè)務(wù)跑在 IP 網(wǎng)絡(luò)上的那套架構(gòu)而計費就是記錄“誰在什么時候用了什么業(yè)務(wù)、用了多久、該記多少賬”。3GPP TS 32.260 這份技術(shù)規(guī)范正是給這套賬本定規(guī)矩的文件——它規(guī)定了 IMS 網(wǎng)絡(luò)里各個節(jié)點該在什么時機、用什么格式、通過什么接口把計費信息交上去。搞懂它你就明白了一通電話從撥出到掛斷中間到底產(chǎn)生了哪些“賬目”也就能看懂運營商賬單和計費系統(tǒng)之間那條看不見的鏈路。2. 為什么需要一份專門的 IMS 計費標(biāo)準(zhǔn)2.1 從“按時長收費”到“按業(yè)務(wù)收費”的復(fù)雜度躍遷傳統(tǒng)電話網(wǎng)的計費很樸素接通開始計時掛斷結(jié)束按分鐘算錢。這套邏輯在電路域里跑了幾十年簡單可靠。但 IMS 把語音變成了數(shù)據(jù)包一通電話可能經(jīng)過多個應(yīng)用服務(wù)器、可能中途轉(zhuǎn)移、可能從 PS 域切到 CS 域甚至多方通話里每個人走的路由都不一樣。如果還靠“一個交換機記一張話單”賬根本對不上。打個比方傳統(tǒng)計費像小區(qū)門口一個保安記進出時間IMS 計費則像一棟有幾十個出入口的大樓每個門口都要刷卡最后要把所有刷卡記錄拼成一條完整的行動軌跡。3GPP TS 32.260 做的就是規(guī)定每個“門口”該刷什么卡、記錄里寫哪些字段、記錄之間怎么關(guān)聯(lián)。沒有這份標(biāo)準(zhǔn)不同設(shè)備商做的計費模塊各記各的運營商拿到一堆對不上的話單血淚經(jīng)驗就是月底對賬對到崩潰。2.2 離線計費與在線計費兩套賬本各管一段這份規(guī)范把 IMS 計費拆成兩條主線。離線計費是“先消費、后出賬”用戶打電話時網(wǎng)絡(luò)把計費信息攢起來通話結(jié)束后生成計費數(shù)據(jù)記錄CDR送到計費中心慢慢算適合后付費用戶。在線計費則是“先查余額、再放行”通話建立前先問計費系統(tǒng)“這人還有錢嗎”通話中還要周期性上報用量余額不夠就掐斷適合預(yù)付費用戶。通俗地說離線計費像信用卡月底出賬單在線計費像公交卡上車先扣錢、余額不足閘機不放行。規(guī)范里分別定義了這兩套架構(gòu)的參考點、消息流和觸發(fā)條件比如在線計費走 Nchf 服務(wù)化接口離線計費走 Rf 參考點。兩者不是二選一很多運營商是融合計費同一張網(wǎng)絡(luò)里兩種模式并存按用戶類型和業(yè)務(wù)類型分流。2.3 計費關(guān)聯(lián)把散落的記錄拼成一張完整賬單IMS 里一通電話可能經(jīng)過 P-CSCF、S-CSCF、AS 等多個功能實體每個實體都可能產(chǎn)生計費事件。如果各記各的最后就是一堆碎片。規(guī)范里專門定義了 IMS 計費標(biāo)識符ICID和相關(guān) ICID 機制讓同一會話在不同節(jié)點產(chǎn)生的記錄能被打上同一個“串號”計費系統(tǒng)靠這個串號把碎片拼起來。這就像寄快遞時每個中轉(zhuǎn)站都掃一次碼但運單號是同一個最后你能看到包裹從攬收到派送的全鏈路。沒有 ICID運營商看到的就是“某地某設(shè)備產(chǎn)生了一條 3 分鐘的通話記錄”根本不知道這條記錄屬于哪個用戶、哪通電話。所以計費關(guān)聯(lián)不是錦上添花而是讓賬本能成立的前提。2.4 觸發(fā)條件什么時候該“記一筆”規(guī)范第 5 章花了大量篇幅講觸發(fā)條件。計費事件不是隨便記的得在特定時機觸發(fā)會話建立、會話修改、會話釋放、收到 SIP 錯誤響應(yīng)、媒體類型變更等等。比如一通電話從語音升級為視頻SDP 里媒體描述變了計費系統(tǒng)就得知道“業(yè)務(wù)類型變了要重新記一筆”。這里容易翻車的地方是觸發(fā)太密會產(chǎn)生大量冗余記錄觸發(fā)太疏會漏記導(dǎo)致少收費。規(guī)范給出的是一套“最小必要”的觸發(fā)集合各設(shè)備商實現(xiàn)時可以加自己的觸發(fā)點但必須保證規(guī)范要求的那些不能漏。某實驗室在做互通測試時就遇到過一方設(shè)備在會話修改時沒觸發(fā)計費導(dǎo)致跨網(wǎng)通話的后半段沒記賬最后靠抓包比對 SIP 消息才定位到問題。3. 常見誤區(qū)與易混概念別把這幾組詞搞混了3.1 誤區(qū)一IMS 計費就是“打電話收錢”很多人一聽 IMS 計費第一反應(yīng)是“不就是語音通話的話單嗎”。實際上 IMS 承載的業(yè)務(wù)遠不止語音視頻通話、即時消息、視頻彩鈴、會議、甚至某些 API 調(diào)用都可能走 IMS 域。規(guī)范里明確寫了 IMS 計費適用性覆蓋語音、視頻、消息、補充業(yè)務(wù)等多種業(yè)務(wù)類型。把 IMS 計費等同于語音計費會漏掉大量非語音業(yè)務(wù)的計費場景做容量規(guī)劃或?qū)~時就會對不上。區(qū)分方法很簡單看計費記錄里的業(yè)務(wù)類型字段。如果只盯著通話時長忽略消息條數(shù)、視頻流量、會議參與方數(shù)量這些維度賬本就是不完整的。3.2 誤區(qū)二在線計費和離線計費是“新舊替代”關(guān)系有一種常見誤解是“在線計費更先進離線計費要被淘汰”。事實是兩者長期共存服務(wù)不同用戶群和業(yè)務(wù)場景。預(yù)付費用戶需要實時控費后付費用戶走離線出賬更經(jīng)濟有些業(yè)務(wù)比如某些增值業(yè)務(wù)天然適合離線批處理強行上在線計費反而增加信令負擔(dān)。規(guī)范里兩套架構(gòu)是并列定義的融合計費架構(gòu)也是把兩者放在一起協(xié)調(diào)不是誰取代誰。判斷該用哪種看的是用戶付費模式、業(yè)務(wù)實時性要求和運營商策略不是技術(shù)先進程度。3.3 誤區(qū)三CDR 就是賬單計費數(shù)據(jù)記錄CDR是網(wǎng)絡(luò)設(shè)備產(chǎn)生的原始記錄賬單是計費系統(tǒng)經(jīng)過資費規(guī)則、優(yōu)惠、稅等處理后的最終結(jié)果。CDR 里寫的是“用了多久、什么業(yè)務(wù)、哪個網(wǎng)元產(chǎn)生的”不直接等于“該收多少錢”。把 CDR 當(dāng)賬單就像把超市收銀小票上的商品條碼當(dāng)成價格標(biāo)簽——條碼只是標(biāo)識價格是另一套規(guī)則算出來的。規(guī)范定義的是 CDR 的內(nèi)容和產(chǎn)生機制資費計算不在 32.260 的范圍里。所以看這份規(guī)范時別指望找到“每分鐘多少錢”的答案它管的是“賬目怎么記”不是“賬怎么算”。3.4 誤區(qū)四ICID 和用戶標(biāo)識是一回事ICID 是 IMS 計費標(biāo)識符標(biāo)識的是一次會話/事務(wù)不是用戶。同一個用戶打兩通電話ICID 不同不同用戶參與同一個會議可能共享某些關(guān)聯(lián)標(biāo)識但各自有各自的計費記錄。把 ICID 當(dāng)用戶 ID 用會導(dǎo)致計費關(guān)聯(lián)邏輯寫錯把別人的消費記到你頭上。區(qū)分要點用戶標(biāo)識如 IMPI、MSISDN回答“是誰”ICID 回答“是哪一次”。計費系統(tǒng)需要兩者配合才能既知道誰消費了、又知道消費發(fā)生在哪次會話里。3.5 誤區(qū)五規(guī)范是“建議”實現(xiàn)可以隨意3GPP 規(guī)范雖然是技術(shù)標(biāo)準(zhǔn)但涉及計費的部分往往和運營商間的結(jié)算直接掛鉤。如果一方設(shè)備不按規(guī)范產(chǎn)生 CDR 字段另一方計費系統(tǒng)解析不了跨網(wǎng)結(jié)算就會出問題。規(guī)范里那些看起來繁瑣的字段定義、消息流順序背后都是互通性要求。當(dāng)然規(guī)范也留了擴展空間比如廠商特定字段、可選觸發(fā)點。但“可選”不等于“可省”關(guān)鍵字段和必選流程必須對齊。某公司在做跨設(shè)備商對接時就因為一方把某個必選字段填了空值導(dǎo)致對賬系統(tǒng)整批記錄拒收排查了兩天才發(fā)現(xiàn)是字段級的不一致。4. 這份中文版規(guī)范里到底寫了什么4.1 架構(gòu)章節(jié)先看清“誰跟誰說話”規(guī)范第 4 章講架構(gòu)注意事項分高級 IMS 架構(gòu)、離線計費架構(gòu)、在線計費架構(gòu)、融合計費架構(gòu)四塊。高級架構(gòu)給的是全局視圖告訴你 P-CSCF、S-CSCF、AS、CDF、CGF、OCS 這些角色在計費鏈路里各站什么位置。離線計費架構(gòu)重點在 Rf 參考點計費事件從網(wǎng)元送到 CDF計費數(shù)據(jù)功能再由 CGF計費網(wǎng)關(guān)功能匯聚成 CDR 文件。在線計費架構(gòu)重點在 Nchf 服務(wù)化接口網(wǎng)元直接和 CHF計費功能交互實時請求配額。融合計費架構(gòu)則是把兩條鏈路放在同一張圖里說明哪些節(jié)點可以復(fù)用、哪些接口需要同時支持?？催@部分時建議對照消息流章節(jié)一起看否則光看架構(gòu)圖容易“知道誰連誰不知道什么時候連”。4.2 計費原則那些“必須遵守”的底層規(guī)則第 5.1 節(jié)列了一堆計費原則看起來零散其實每條都對應(yīng)一個實際場景。比如 IMS 計費相關(guān)性講的是跨域關(guān)聯(lián)一通電話從 IMS 域切到 CS 域兩邊的計費記錄要靠標(biāo)識符關(guān)聯(lián)起來SDP 處理講的是媒體協(xié)商變化如何影響計費因為 SDP 里描述了媒體類型、編解碼、帶寬這些直接關(guān)系到業(yè)務(wù)類型判定。還有服務(wù)用戶識別、B2BUA 場景下的單一計費會話、本地分支漫游架構(gòu)的計費支持等。這些原則的共同點是它們都在回答“這種特殊場景下賬該怎么記才不漏不重”。做計費系統(tǒng)的人看這部分往往比看具體消息流更有收獲因為原則決定了實現(xiàn)方向。4.3 消息流一步一步看“賬是怎么記下來的”第 5.2 節(jié)是整份規(guī)范最厚的部分按場景拆了幾十條消息流會話建立移動發(fā)起/移動終止/PSTN 發(fā)起/IMS 發(fā)起、會話釋放、多方通話、AS 相關(guān)程序重定向服務(wù)器、語音郵件、SCC AS、會話轉(zhuǎn)移PS 到 CS、CS 到 PS、組合發(fā)起、緊急會話轉(zhuǎn)移、RTTI 實時資費信息、OMR 最佳媒體路由、ATCF 服務(wù)連續(xù)性等等。每條消息流都畫了時序圖標(biāo)了 SIP 消息和計費請求的先后順序。比如會話建立-移動發(fā)起場景UE 發(fā) INVITEP-CSCF 轉(zhuǎn)發(fā)S-CSCF 觸發(fā)計費AS 可能插入最后 200 OK 回來中間哪些節(jié)點在什么時刻發(fā)計費請求、帶哪些參數(shù)圖里都有?？催@些圖時別只記順序重點看“計費請求和 SIP 響應(yīng)的對應(yīng)關(guān)系”——很多實現(xiàn)錯誤就出在計費請求發(fā)早了或發(fā)晚了導(dǎo)致記錄和會話狀態(tài)對不上。4.4 錯誤場景失敗的通話也要記賬第 5.2.2.2 節(jié)專門講錯誤案例收到 SIP 錯誤消息怎么辦、SIP 會話失敗怎么辦、會話無關(guān)的 SIP 程序怎么處理。這點常被忽略——很多人以為只有成功通話才計費實際上失敗的呼叫嘗試、被拒的會話、超時釋放都可能產(chǎn)生計費事件只是計費類型不同。比如用戶撥號后對方忙SIP 返回 486這通“未接通”的呼叫要不要記規(guī)范里是有說法的取決于運營商策略和業(yè)務(wù)類型。做計費實現(xiàn)時如果只處理成功場景月底對賬就會發(fā)現(xiàn)“呼叫嘗試次數(shù)”和“計費記錄數(shù)”對不上又是一個踩坑點。5. 什么時候該翻這份規(guī)范什么時候別指望它5.1 適合用的場景做對接、查字段、對流程這份中文版最直接的用處是降低語言門檻。英文原版幾百頁術(shù)語密集非母語讀者看一遍容易漏細節(jié)。中文版適合三類人一是做 IMS 網(wǎng)元計費模塊開發(fā)的工程師需要查某個場景下計費請求該帶哪些參數(shù)二是做跨設(shè)備商對接的測試人員需要比對雙方消息流是否符合規(guī)范三是做計費系統(tǒng)運維的人遇到 CDR 字段異常時回來查定義。舉個具體例子某公司做 IMS 核心網(wǎng)和計費系統(tǒng)的聯(lián)調(diào)發(fā)現(xiàn)某類會話轉(zhuǎn)移場景下計費記錄缺失。翻到規(guī)范里 SCC AS 相關(guān)程序那一節(jié)對照消息流發(fā)現(xiàn)是轉(zhuǎn)移過程中某個觸發(fā)點沒實現(xiàn)補上之后記錄就完整了。這種“按場景查”的用法比從頭讀到尾效率高得多。5.2 不適合用的場景算資費、調(diào)網(wǎng)絡(luò)、替代英文原版這份規(guī)范不告訴你資費怎么定、優(yōu)惠怎么算、賬單怎么出那些是計費系統(tǒng)和運營策略的事。它也不教你網(wǎng)絡(luò)怎么部署、參數(shù)怎么調(diào)優(yōu)那是規(guī)劃優(yōu)化文檔的范疇。另外中文版是輔助理解的材料涉及法律效力和最終解釋時仍應(yīng)以英文原版為準(zhǔn)——這不是客套話是血淚教訓(xùn)某團隊曾按中文翻譯的某個術(shù)語理解去實現(xiàn)后來發(fā)現(xiàn)英文原文的措辭更精確導(dǎo)致字段語義偏差返工了一輪。還有一點要注意規(guī)范里大量引用其他 3GPP 文檔比如 32.240 計費管理總體架構(gòu)、32.299 Diameter 計費應(yīng)用單看 32.260 有時會缺上下文。遇到“這個參考點定義在哪”的問題得順著參考文獻往下查別指望一份文檔包打天下。5.3 一個判斷清單你的問題該翻這份規(guī)范嗎說明某個場景下計費請求該帶哪些參數(shù)是消息流章節(jié)有字段級說明在線計費和離線計費怎么選部分架構(gòu)章節(jié)講機制選型看運營策略這通電話該收多少錢否資費規(guī)則不在本規(guī)范范圍CDR 里某個字段什么意思是定義和縮寫章節(jié)有解釋跨設(shè)備商計費對接對不上是對照消息流和觸發(fā)條件排查網(wǎng)絡(luò)性能怎么優(yōu)化否屬于規(guī)劃優(yōu)化文檔范疇從那以后我每次碰到 IMS 計費相關(guān)的對接問題都強制走一遍“先查場景消息流、再對字段定義、最后確認觸發(fā)時機”的流程比憑經(jīng)驗猜快得多。希望這份梳理能幫到你少走一點對賬對到半夜的彎路。本文還有配套的精品資源點擊獲取 IMS計費標(biāo)準(zhǔn)3GPP TS 32.260詳解：架構(gòu)、消息流與常見誤區(qū)
簡介面向IMS計費學(xué)習(xí)與工程實踐者的3GPP TS 32.260中文版規(guī)范聚焦IP多媒體子系統(tǒng)計費管理適合從事核心網(wǎng)計費、運營商支撐系統(tǒng)開發(fā)及通信標(biāo)準(zhǔn)研究的技術(shù)人員用于理解從GSM、UMTS到LTE演進中的計費架構(gòu)與實現(xiàn)要求。資源包共1個PDF文件約2.65MB內(nèi)容涵蓋前言、范圍、參考文獻、定義符號與縮寫以及高級IMS架構(gòu)、離線計費架構(gòu)、在線計費架構(gòu)與融合計費架構(gòu)等章節(jié)并展開計費原則、CDR生成、計費觸發(fā)點、Diameter與Gx接口等關(guān)鍵知識點。已有196人學(xué)習(xí)可作為查閱IMS計費標(biāo)準(zhǔn)條款、梳理在線與離線計費流程的案頭參考建議結(jié)合英文原版對照研讀以準(zhǔn)確把握技術(shù)細節(jié)與術(shù)語含義。1. 打電話、刷視頻背后的“賬本”IMS 計費到底是什么你打完一通 VoLTE 電話或者用手機看了一段視頻彩鈴運營商是怎么知道該收你多少錢的答案藏在一套叫 IMS 計費的機制里。IMS 是 IP 多媒體子系統(tǒng)簡單說就是讓電話、視頻通話、消息這些業(yè)務(wù)跑在 IP 網(wǎng)絡(luò)上的那套架構(gòu)而計費就是記錄“誰在什么時候用了什么業(yè)務(wù)、用了多久、該記多少賬”。3GPP TS 32.260 這份技術(shù)規(guī)范正是給這套賬本定規(guī)矩的文件——它規(guī)定了 IMS 網(wǎng)絡(luò)里各個節(jié)點該在什么時機、用什么格式、通過什么接口把計費信息交上去。搞懂它你就明白了一通電話從撥出到掛斷中間到底產(chǎn)生了哪些“賬目”也就能看懂運營商賬單和計費系統(tǒng)之間那條看不見的鏈路。2. 為什么需要一份專門的 IMS 計費標(biāo)準(zhǔn)2.1 從“按時長收費”到“按業(yè)務(wù)收費”的復(fù)雜度躍遷傳統(tǒng)電話網(wǎng)的計費很樸素接通開始計時掛斷結(jié)束按分鐘算錢。這套邏輯在電路域里跑了幾十年簡單可靠。但 IMS 把語音變成了數(shù)據(jù)包一通電話可能經(jīng)過多個應(yīng)用服務(wù)器、可能中途轉(zhuǎn)移、可能從 PS 域切到 CS 域甚至多方通話里每個人走的路由都不一樣。如果還靠“一個交換機記一張話單”賬根本對不上。打個比方傳統(tǒng)計費像小區(qū)門口一個保安記進出時間IMS 計費則像一棟有幾十個出入口的大樓每個門口都要刷卡最后要把所有刷卡記錄拼成一條完整的行動軌跡。3GPP TS 32.260 做的就是規(guī)定每個“門口”該刷什么卡、記錄里寫哪些字段、記錄之間怎么關(guān)聯(lián)。沒有這份標(biāo)準(zhǔn)不同設(shè)備商做的計費模塊各記各的運營商拿到一堆對不上的話單血淚經(jīng)驗就是月底對賬對到崩潰。2.2 離線計費與在線計費兩套賬本各管一段這份規(guī)范把 IMS 計費拆成兩條主線。離線計費是“先消費、后出賬”用戶打電話時網(wǎng)絡(luò)把計費信息攢起來通話結(jié)束后生成計費數(shù)據(jù)記錄CDR送到計費中心慢慢算適合后付費用戶。在線計費則是“先查余額、再放行”通話建立前先問計費系統(tǒng)“這人還有錢嗎”通話中還要周期性上報用量余額不夠就掐斷適合預(yù)付費用戶。通俗地說離線計費像信用卡月底出賬單在線計費像公交卡上車先扣錢、余額不足閘機不放行。規(guī)范里分別定義了這兩套架構(gòu)的參考點、消息流和觸發(fā)條件比如在線計費走 Nchf 服務(wù)化接口離線計費走 Rf 參考點。兩者不是二選一很多運營商是融合計費同一張網(wǎng)絡(luò)里兩種模式并存按用戶類型和業(yè)務(wù)類型分流。2.3 計費關(guān)聯(lián)把散落的記錄拼成一張完整賬單IMS 里一通電話可能經(jīng)過 P-CSCF、S-CSCF、AS 等多個功能實體每個實體都可能產(chǎn)生計費事件。如果各記各的最后就是一堆碎片。規(guī)范里專門定義了 IMS 計費標(biāo)識符ICID和相關(guān) ICID 機制讓同一會話在不同節(jié)點產(chǎn)生的記錄能被打上同一個“串號”計費系統(tǒng)靠這個串號把碎片拼起來。這就像寄快遞時每個中轉(zhuǎn)站都掃一次碼但運單號是同一個最后你能看到包裹從攬收到派送的全鏈路。沒有 ICID運營商看到的就是“某地某設(shè)備產(chǎn)生了一條 3 分鐘的通話記錄”根本不知道這條記錄屬于哪個用戶、哪通電話。所以計費關(guān)聯(lián)不是錦上添花而是讓賬本能成立的前提。2.4 觸發(fā)條件什么時候該“記一筆”規(guī)范第 5 章花了大量篇幅講觸發(fā)條件。計費事件不是隨便記的得在特定時機觸發(fā)會話建立、會話修改、會話釋放、收到 SIP 錯誤響應(yīng)、媒體類型變更等等。比如一通電話從語音升級為視頻SDP 里媒體描述變了計費系統(tǒng)就得知道“業(yè)務(wù)類型變了要重新記一筆”。這里容易翻車的地方是觸發(fā)太密會產(chǎn)生大量冗余記錄觸發(fā)太疏會漏記導(dǎo)致少收費。規(guī)范給出的是一套“最小必要”的觸發(fā)集合各設(shè)備商實現(xiàn)時可以加自己的觸發(fā)點但必須保證規(guī)范要求的那些不能漏。某實驗室在做互通測試時就遇到過一方設(shè)備在會話修改時沒觸發(fā)計費導(dǎo)致跨網(wǎng)通話的后半段沒記賬最后靠抓包比對 SIP 消息才定位到問題。3. 常見誤區(qū)與易混概念別把這幾組詞搞混了3.1 誤區(qū)一IMS 計費就是“打電話收錢”很多人一聽 IMS 計費第一反應(yīng)是“不就是語音通話的話單嗎”。實際上 IMS 承載的業(yè)務(wù)遠不止語音視頻通話、即時消息、視頻彩鈴、會議、甚至某些 API 調(diào)用都可能走 IMS 域。規(guī)范里明確寫了 IMS 計費適用性覆蓋語音、視頻、消息、補充業(yè)務(wù)等多種業(yè)務(wù)類型。把 IMS 計費等同于語音計費會漏掉大量非語音業(yè)務(wù)的計費場景做容量規(guī)劃或?qū)~時就會對不上。區(qū)分方法很簡單看計費記錄里的業(yè)務(wù)類型字段。如果只盯著通話時長忽略消息條數(shù)、視頻流量、會議參與方數(shù)量這些維度賬本就是不完整的。3.2 誤區(qū)二在線計費和離線計費是“新舊替代”關(guān)系有一種常見誤解是“在線計費更先進離線計費要被淘汰”。事實是兩者長期共存服務(wù)不同用戶群和業(yè)務(wù)場景。預(yù)付費用戶需要實時控費后付費用戶走離線出賬更經(jīng)濟有些業(yè)務(wù)比如某些增值業(yè)務(wù)天然適合離線批處理強行上在線計費反而增加信令負擔(dān)。規(guī)范里兩套架構(gòu)是并列定義的融合計費架構(gòu)也是把兩者放在一起協(xié)調(diào)不是誰取代誰。判斷該用哪種看的是用戶付費模式、業(yè)務(wù)實時性要求和運營商策略不是技術(shù)先進程度。3.3 誤區(qū)三CDR 就是賬單計費數(shù)據(jù)記錄CDR是網(wǎng)絡(luò)設(shè)備產(chǎn)生的原始記錄賬單是計費系統(tǒng)經(jīng)過資費規(guī)則、優(yōu)惠、稅等處理后的最終結(jié)果。CDR 里寫的是“用了多久、什么業(yè)務(wù)、哪個網(wǎng)元產(chǎn)生的”不直接等于“該收多少錢”。把 CDR 當(dāng)賬單就像把超市收銀小票上的商品條碼當(dāng)成價格標(biāo)簽——條碼只是標(biāo)識價格是另一套規(guī)則算出來的。規(guī)范定義的是 CDR 的內(nèi)容和產(chǎn)生機制資費計算不在 32.260 的范圍里。所以看這份規(guī)范時別指望找到“每分鐘多少錢”的答案它管的是“賬目怎么記”不是“賬怎么算”。3.4 誤區(qū)四ICID 和用戶標(biāo)識是一回事ICID 是 IMS 計費標(biāo)識符標(biāo)識的是一次會話/事務(wù)不是用戶。同一個用戶打兩通電話ICID 不同不同用戶參與同一個會議可能共享某些關(guān)聯(lián)標(biāo)識但各自有各自的計費記錄。把 ICID 當(dāng)用戶 ID 用會導(dǎo)致計費關(guān)聯(lián)邏輯寫錯把別人的消費記到你頭上。區(qū)分要點用戶標(biāo)識如 IMPI、MSISDN回答“是誰”ICID 回答“是哪一次”。計費系統(tǒng)需要兩者配合才能既知道誰消費了、又知道消費發(fā)生在哪次會話里。3.5 誤區(qū)五規(guī)范是“建議”實現(xiàn)可以隨意3GPP 規(guī)范雖然是技術(shù)標(biāo)準(zhǔn)但涉及計費的部分往往和運營商間的結(jié)算直接掛鉤。如果一方設(shè)備不按規(guī)范產(chǎn)生 CDR 字段另一方計費系統(tǒng)解析不了跨網(wǎng)結(jié)算就會出問題。規(guī)范里那些看起來繁瑣的字段定義、消息流順序背后都是互通性要求。當(dāng)然規(guī)范也留了擴展空間比如廠商特定字段、可選觸發(fā)點。但“可選”不等于“可省”關(guān)鍵字段和必選流程必須對齊。某公司在做跨設(shè)備商對接時就因為一方把某個必選字段填了空值導(dǎo)致對賬系統(tǒng)整批記錄拒收排查了兩天才發(fā)現(xiàn)是字段級的不一致。4. 這份中文版規(guī)范里到底寫了什么4.1 架構(gòu)章節(jié)先看清“誰跟誰說話”規(guī)范第 4 章講架構(gòu)注意事項分高級 IMS 架構(gòu)、離線計費架構(gòu)、在線計費架構(gòu)、融合計費架構(gòu)四塊。高級架構(gòu)給的是全局視圖告訴你 P-CSCF、S-CSCF、AS、CDF、CGF、OCS 這些角色在計費鏈路里各站什么位置。離線計費架構(gòu)重點在 Rf 參考點計費事件從網(wǎng)元送到 CDF計費數(shù)據(jù)功能再由 CGF計費網(wǎng)關(guān)功能匯聚成 CDR 文件。在線計費架構(gòu)重點在 Nchf 服務(wù)化接口網(wǎng)元直接和 CHF計費功能交互實時請求配額。融合計費架構(gòu)則是把兩條鏈路放在同一張圖里說明哪些節(jié)點可以復(fù)用、哪些接口需要同時支持?？催@部分時建議對照消息流章節(jié)一起看否則光看架構(gòu)圖容易“知道誰連誰不知道什么時候連”。4.2 計費原則那些“必須遵守”的底層規(guī)則第 5.1 節(jié)列了一堆計費原則看起來零散其實每條都對應(yīng)一個實際場景。比如 IMS 計費相關(guān)性講的是跨域關(guān)聯(lián)一通電話從 IMS 域切到 CS 域兩邊的計費記錄要靠標(biāo)識符關(guān)聯(lián)起來SDP 處理講的是媒體協(xié)商變化如何影響計費因為 SDP 里描述了媒體類型、編解碼、帶寬這些直接關(guān)系到業(yè)務(wù)類型判定。還有服務(wù)用戶識別、B2BUA 場景下的單一計費會話、本地分支漫游架構(gòu)的計費支持等。這些原則的共同點是它們都在回答“這種特殊場景下賬該怎么記才不漏不重”。做計費系統(tǒng)的人看這部分往往比看具體消息流更有收獲因為原則決定了實現(xiàn)方向。4.3 消息流一步一步看“賬是怎么記下來的”第 5.2 節(jié)是整份規(guī)范最厚的部分按場景拆了幾十條消息流會話建立移動發(fā)起/移動終止/PSTN 發(fā)起/IMS 發(fā)起、會話釋放、多方通話、AS 相關(guān)程序重定向服務(wù)器、語音郵件、SCC AS、會話轉(zhuǎn)移PS 到 CS、CS 到 PS、組合發(fā)起、緊急會話轉(zhuǎn)移、RTTI 實時資費信息、OMR 最佳媒體路由、ATCF 服務(wù)連續(xù)性等等。每條消息流都畫了時序圖標(biāo)了 SIP 消息和計費請求的先后順序。比如會話建立-移動發(fā)起場景UE 發(fā) INVITEP-CSCF 轉(zhuǎn)發(fā)S-CSCF 觸發(fā)計費AS 可能插入最后 200 OK 回來中間哪些節(jié)點在什么時刻發(fā)計費請求、帶哪些參數(shù)圖里都有?？催@些圖時別只記順序重點看“計費請求和 SIP 響應(yīng)的對應(yīng)關(guān)系”——很多實現(xiàn)錯誤就出在計費請求發(fā)早了或發(fā)晚了導(dǎo)致記錄和會話狀態(tài)對不上。4.4 錯誤場景失敗的通話也要記賬第 5.2.2.2 節(jié)專門講錯誤案例收到 SIP 錯誤消息怎么辦、SIP 會話失敗怎么辦、會話無關(guān)的 SIP 程序怎么處理。這點常被忽略——很多人以為只有成功通話才計費實際上失敗的呼叫嘗試、被拒的會話、超時釋放都可能產(chǎn)生計費事件只是計費類型不同。比如用戶撥號后對方忙SIP 返回 486這通“未接通”的呼叫要不要記規(guī)范里是有說法的取決于運營商策略和業(yè)務(wù)類型。做計費實現(xiàn)時如果只處理成功場景月底對賬就會發(fā)現(xiàn)“呼叫嘗試次數(shù)”和“計費記錄數(shù)”對不上又是一個踩坑點。5. 什么時候該翻這份規(guī)范什么時候別指望它5.1 適合用的場景做對接、查字段、對流程這份中文版最直接的用處是降低語言門檻。英文原版幾百頁術(shù)語密集非母語讀者看一遍容易漏細節(jié)。中文版適合三類人一是做 IMS 網(wǎng)元計費模塊開發(fā)的工程師需要查某個場景下計費請求該帶哪些參數(shù)二是做跨設(shè)備商對接的測試人員需要比對雙方消息流是否符合規(guī)范三是做計費系統(tǒng)運維的人遇到 CDR 字段異常時回來查定義。舉個具體例子某公司做 IMS 核心網(wǎng)和計費系統(tǒng)的聯(lián)調(diào)發(fā)現(xiàn)某類會話轉(zhuǎn)移場景下計費記錄缺失。翻到規(guī)范里 SCC AS 相關(guān)程序那一節(jié)對照消息流發(fā)現(xiàn)是轉(zhuǎn)移過程中某個觸發(fā)點沒實現(xiàn)補上之后記錄就完整了。這種“按場景查”的用法比從頭讀到尾效率高得多。5.2 不適合用的場景算資費、調(diào)網(wǎng)絡(luò)、替代英文原版這份規(guī)范不告訴你資費怎么定、優(yōu)惠怎么算、賬單怎么出那些是計費系統(tǒng)和運營策略的事。它也不教你網(wǎng)絡(luò)怎么部署、參數(shù)怎么調(diào)優(yōu)那是規(guī)劃優(yōu)化文檔的范疇。另外中文版是輔助理解的材料涉及法律效力和最終解釋時仍應(yīng)以英文原版為準(zhǔn)——這不是客套話是血淚教訓(xùn)某團隊曾按中文翻譯的某個術(shù)語理解去實現(xiàn)后來發(fā)現(xiàn)英文原文的措辭更精確導(dǎo)致字段語義偏差返工了一輪。還有一點要注意規(guī)范里大量引用其他 3GPP 文檔比如 32.240 計費管理總體架構(gòu)、32.299 Diameter 計費應(yīng)用單看 32.260 有時會缺上下文。遇到“這個參考點定義在哪”的問題得順著參考文獻往下查別指望一份文檔包打天下。5.3 一個判斷清單你的問題該翻這份規(guī)范嗎說明某個場景下計費請求該帶哪些參數(shù)是消息流章節(jié)有字段級說明在線計費和離線計費怎么選部分架構(gòu)章節(jié)講機制選型看運營策略這通電話該收多少錢否資費規(guī)則不在本規(guī)范范圍CDR 里某個字段什么意思是定義和縮寫章節(jié)有解釋跨設(shè)備商計費對接對不上是對照消息流和觸發(fā)條件排查網(wǎng)絡(luò)性能怎么優(yōu)化否屬于規(guī)劃優(yōu)化文檔范疇從那以后我每次碰到 IMS 計費相關(guān)的對接問題都強制走一遍“先查場景消息流、再對字段定義、最后確認觸發(fā)時機”的流程比憑經(jīng)驗猜快得多。希望這份梳理能幫到你少走一點對賬對到半夜的彎路。本文還有配套的精品資源點擊獲取