電信計費 - 快速指南

---

---

電信計費 - 簡介

使用電子媒體將語音、資料、圖片、傳真等從一個點傳輸到另一個點被稱為電信，簡稱“telecom”。例如電話、無線電、電視和網際網路。傳輸介質包括線纜（銅）、光纖、乙太網（無線）、無線電塔、微波、衛星等。

現在，讓我們列出一些國際電信運營商，他們為客戶提供令人滿意的電信服務：

• Verizon
• 沃達豐（Vodafone）
• Airtel
• 塔塔（TATA）
• Etisalat
• Qtel

讓我們也列出一些知名電信運營商提供的基本電信服務：

• 語音通話
• 傳真服務
• 簡訊和彩信
• 網際網路連線
• 資料下載和上傳
• 視訊會議
• 基於IP的服務，即語音IP或VPN

電信運營商以各種方式向客戶收費，但主要有兩個引數用於向客戶收費：

• 租金費用 - 這是向客戶每月收取的服務費，例如，您的電話月租費為 5.00 美元，無論您是否使用。

• 使用費用 - 這是根據服務使用情況向客戶收取的費用。例如，您將為撥打的每次電話或使用手機下載的資料付費。

除了每月租金和使用費外，運營商也可能會收取您服務開通費、安裝費、服務暫停費或終止費。

電信計費是收集用量、彙總用量、應用必要的用量和租金費用，並最終為客戶生成發票的過程。電信計費流程還包括接收和記錄客戶的付款。

計費系統

可能存在非常複雜的計費場景，這些場景很難手動處理。軟體市場上有一些最先進的計費系統，可以高效地處理計費任務，併為服務提供商提供很大的靈活性，使他們能夠以不同的價格結構提供服務。

計費系統通常被視為應收賬款，因為計費系統有助於從客戶那裡收取（接收）資金。計費系統也是應付賬款的一部分（用於運營商間的結算），因為客戶經常使用其他公司的服務，例如無線漫遊、長途電話和透過其他網路完成的呼叫。

計費系統是高階、可靠且昂貴的軟體，它提供各種功能。以下是最重要的功能列表，但不限於以下內容：

• 計費與計價 - 它涉及對產品或服務的使用進行計價並生成月度賬單。

• 支付處理 - 它涉及將客戶的付款記入其帳戶。

• 信用控制和催收 - 它涉及追繳未付賬款並採取適當措施收取款項。

• 爭議和調整 - 它涉及記錄客戶對其賬單的爭議，並建立調整以退還爭議金額以解決爭議。

• 預付費和後付費服務 - 它涉及支援預付費和後付費客戶群。

• 多語言和多種貨幣 - 如果業務遍佈全球，擁有跨國客戶，或者政府法規要求，則需要多語言和多種貨幣支援。

• 運營商間結算 - 它涉及在為彼此客戶提供服務的運營商之間共享收入。

• 產品與服務 - 這涉及提供靈活的方式來維護各種產品和服務，並單獨或打包銷售。

• 折扣應用 - 這涉及定義各種折扣方案，以減少客戶流失並吸引和增加客戶群。

計費型別

當您深入研究計費主題時，它會變得更加複雜。我將在本教程的後面部分介紹大部分概念，但首先，讓我們對廣泛使用的計費型別有一個大致瞭解：

• 預付費計費 - 一種計費機制，客戶預先付款，然後開始使用服務。通常，預付費客戶不會收到任何發票，並且他們會透過稱為“IN”（智慧網路）的高可用性計費系統即時收費。

• 後付費計費 - 這是傳統的計費方式，已經使用了多年。在這裡，客戶購買產品和服務並在整個月使用它們，到月底，服務提供商會生成發票並將這些發票傳送給客戶以進行付款。

• 互聯計費：網路運營商通常對其他網路為其客戶提供的服務負有財務責任，無論客戶是否為該服務付費。互聯計費與運營商間結算或有時稱為合作伙伴結算有關。

• 漫遊費 - 當客戶從一個網路運營商的覆蓋區域移動到另一個運營商的覆蓋區域時，第一個運營商將向第二個運營商支付少量費用以向其客戶提供服務。此類費用透過漫遊計費進行結算。此結算根據 TAP3 協議進行，我們將在接下來的章節中討論。

• 融合計費 - 融合計費是指將所有服務費用整合到一張客戶發票中。融合計費意味著建立客戶及其所有服務（移動、固定、IP 等）的統一檢視。

計費系統供應商

計費系統是任何電信運營商的支柱。如果運營商沒有強大的計費系統，那麼他們將無法以有吸引力的促銷和優惠提供其產品和服務，最終他們將無法在當今競爭激烈的動態市場中立足。

您可以找到數千家供應商，他們都在銷售自己的計費產品，並聲稱擁有許多功能，但在市場上有一些真正優秀且最常用的產品。下面列出了一些優秀的計費系統：

電信計費 - 系統架構

下圖顯示了計費系統的典型架構：

這裡，我們有兩種可能性：

• CRM（客戶關係管理）/OMOF（訂單管理和訂單履行）系統與計費系統聯絡，計費系統與供應系統聯絡以供應服務和網路庫存系統，以分配電話號碼或IP地址等。

• 第二種可能性是CRM/OMOF系統本身與供應系統聯絡以供應服務和網路庫存系統，以分配電話號碼或IP地址等。

典型的計費流程

考慮到上述系統架構：→ 在撥打電話或可以說最終客戶生成使用量之後，中介系統從網路交換機收集使用資料並構建呼叫詳細記錄（CDR）。此 CDR 必須包含“A”方號碼和“B”方號碼、開始和結束日期和時間。

然後儲存 CDR，直到可以對其進行計價。要對呼叫進行計價，會檢查 CDR 以檢視呼叫是否是，例如，800 號碼、本地通話（包含在本地通話計劃中）、國際通話或長途通話。諸如呼叫時間和城市程式碼或國家/地區程式碼等資訊用於計算呼叫費率。

對每個呼叫進行計價後，將儲存此資訊，直到執行發票（通常每月一次）。執行發票時，可以將其他非使用費用（例如折扣或月費）應用於賬單或有時稱為發票。

可能存在計價時間折扣或計費時間折扣，客戶進行不同的付款，給予不同的調整，所有這些資訊都會影響最終發票的生成。

然後將此資訊轉換為可列印為可讀格式的格式。最後，列印信封，裝入附件，並郵寄給最終客戶。

計費系統需求

計費系統應由一系列獨立的應用程式組成，當這些應用程式一起執行時，被稱為計費系統。一個好的計費系統應該提供以下主要功能，並具有高度的靈活性：

• 客戶介面管理 - 計費系統必須能夠處理客戶主動聯絡，監督向客戶主動聯絡，以及管理聯絡生命週期。

• 訂單管理 - 這是典型計費系統中應該具備的基本功能。計費系統應該能夠捕獲產品和服務訂單，管理訂單錄入生命週期，並監督訂單完成生命週期。

• 銷售與市場營銷 − 完善的計費系統應能夠解答客戶疑問，處理佣金，提供銷售支援，跟蹤潛在客戶，管理營銷活動，分析產品業績以及獲取多戶住宅單元。

• 資費方案和計費 − 計費系統必須能夠管理各種產品和服務，以及與這些產品和服務相關的不同資費方案，並應提供靈活的方式來計費這些產品和服務產生的使用量。

• 折扣 − 計費系統應能夠對不同的使用情況和租賃提供各種型別的折扣。

• 開票 − 系統必須能夠執行計費查詢，生成賬單，處理存款，執行賬戶管理，維護稅費資訊以及處理財務資訊。

• 信用控制與催收 − 計費系統應透過為不同的客戶分配不同的信用等級來控制使用量和收入。系統應支援收款並將款項應用於不同的發票。

• 多語言支援 − 多語言支援包括提供多種語言的發票和客戶服務。

• 多種貨幣 − 不同國家使用的多種貨幣可能會使計費系統複雜化，因為計費和客戶服務系統必須能夠以多種貨幣單位進行記錄和處理。

• 合作伙伴收入管理 − 合作伙伴收入管理是指在相互為對方客戶提供服務的運營商之間共享收入。

• 問題處理 − 計費系統還應能夠管理故障單錄入，協調故障單關閉並跟蹤故障單的解決進度。

• 效能報告 − 完善的系統將提供效能報告，確保服務質量 (QoS) 報告，建立管理報告以及生成監管報告。

• 安裝和維護 − 系統還應提供勞動力排程並管理在客戶場所執行的活動。

• 審計與安全 − 計費系統應執行資料審計和完整性檢查。對於運營商而言，安全的系統始終是理想的選擇。

除了上述功能外，良好的計費系統還應：

• 加快新服務的上市時間。

• 實現客戶和產品的融合檢視。

• 支援經濟高效的架構可擴充套件性。

• 實現合作伙伴關係管理和結算。

• 降低總擁有成本。

下一步是什麼？

從下一章開始，我們將嘗試涵蓋完整的流程，從定義產品和服務，將計劃和資費與這些產品關聯，獲取客戶（將產品銷售給最終客戶），捕獲這些客戶產生的使用情況，最後，對該使用情況進行計費並向這些客戶傳送最終賬單。

電信計費 - 產品與服務

假設像 Airtel 這樣的電信運營商想要建立自己的計費系統。那麼，Airtel 必須首先由其銷售和市場營銷部門定義其產品和服務，然後才能繼續建立計費系統。

什麼是產品？

產品是邏輯或物理實體，運營商可以將其出售給最終客戶。這可能是手機、網際網路連線、語音通話連線、VPN、影片點播、數字電視連線等。

產品可能具有每月租金，我們也稱其為定期收費。產品可以是產生使用量的產品或不產生使用量的產品。產生使用量的產品有時也稱為產生事件的產品，而不產生使用量的產品稱為不產生事件的產品。

例如，帶有電話號碼的語音通話連線是產生使用量的產品，因為它在最終客戶使用此產品撥打電話時會產生使用量。簡單的電話機（沒有連線）是不產生使用量的產品，它可以根據每月租金提供給客戶。因此，即使客戶不使用它，也必須支付每月租金。

什麼是服務？

從市場營銷的角度來看，產品和服務之間沒有區別，因為大多數情況下，不同的計費和市場營銷專家可以互換使用這兩個詞。

簡而言之，運營商使用其產品為客戶提供語音服務。國際電話可以被稱為使用語音通話連線提供的服務。另一個例子可能是 800 號碼呼叫可能透過或可能不透過特定運營商提供，呼叫等待、來電轉接可以說是由電話機型號或運營商提供的服務。

本教程將產品和服務這兩個術語互換使用。簡單來說，產品是客戶可以 outright 購買或租賃的商品。產品可能是：

• 實際物件（例如，手機）
• 服務（例如，電話系統上的呼叫等待服務）
• 更抽象的概念（例如，服務等級協議）

產品族

相關的產品可以組合成一個產品族。可能存在多個級別的產品，因此一個產品可以同時是父產品和子產品。

此外，如果需要，每個產品族可以有多個父產品。產品族的例子包括：

• 電話服務
• 有線電視
• 網際網路
• 專線

產品組合（套餐）

很多時候，運營商會將多個產品捆綁成一個單一組並將其作為完整套餐出售。有些計費系統支援將各種型別的產品捆綁在一起作為套餐。它可以以折扣價提供。

如果產品作為套餐的一部分，則可以以更低的價格向客戶提供。每個套餐可以包含任意數量的產品，這些產品可以來自多個產品族。

產品的此套餐價格方案通常與其比較（即非套餐）價格方案不同，因為這就是公司向客戶購買完整套餐提供折扣的方式。但是，這不是強制性的，因為產品可以在套餐中分配一個正常的價目表。

產品屬性

產品可以具有一些與其相關的屬性。產品屬性允許儲存有關各個產品例項的資訊，其中相關資訊在不同型別的產品之間有所不同。例如，付費電視產品可能具有記錄其機頂盒編號的屬性。

此外，手機產品可能需要屬性來記錄國際移動使用者識別碼 (IMSI) 和移動臺國際 ISDN 號碼 (MSISDN)。

產品事件型別

產品可以具有一些與其相關的事件型別。這些事件型別控制產品可以生成的事件。

例如，手機產品可能具有語音通話和訊息服務等事件型別。單個電話裝置可能與許多其他事件型別相關聯，運營商可以向最終客戶收取客戶生成的每個事件的費用。

計費系統視角

一旦您的市場營銷部門最終確定所有產品、服務、套餐以及相關的價格，它們就會配置到計費系統中。

不同的計費系統在定義產品及其在父產品、子產品和孫產品方面的層次結構方面提供了不同級別的靈活性。

有些系統足夠靈活，可以支援套餐和捆綁包，而有些系統則提供與套餐和折扣價相關的有限功能。

有些系統將產品目錄與價格目錄分開，以提供更好的模組化方法，而有些計費系統則將產品描述、其功能和相關價格組合在一起。

一旦所有產品、服務、套餐及其事件都配置到計費系統中，下一步就是定義其租金和使用價格，我們將在下一章中介紹。

下一步是什麼？

如果您瞭解什麼是產品或服務和套餐，那麼您可以繼續下一章，瞭解其價格是如何由任何運營商提供的市場營銷部門定義的。

電信計費 - 資費規劃

電信運營商公司的市場營銷部門努力為不同的產品和服務定義租金和使用費。這些收費是在考慮其他競爭對手和法規的情況下確定的。廣義地說，有兩種型別的資費，也稱為費率或價格方案，具體取決於不同計費系統中使用的術語。

可能需要對產品和相關服務應用不同型別的收費。對於給定的產品，運營商可以定義以下一種或多種收費，但並不限於這些收費，可能還有一些其他型別的收費，具體取決於國家/地區、位置和業務情況：

• 產品啟動費用 − 這些是一次性費用，可以作為安裝、啟用、服務或啟動連線的一部分向客戶收取。

• 產品定期費用 − 這些是作為產品和服務的租金按月、雙月或年度收取的費用。

• 產品終止費用 − 這些是產品和服務終止時收取的費用。

• 產品暫停費用 − 這些是由於某種原因（例如，未付款）暫停產品時收取的費用。

• 產品暫停定期費用 − 即使由於某種原因暫停了客戶，也可能需要定期向客戶收費。

• 產品重新啟用費用 − 假設產品由於某種原因被暫停，現在需要啟用它，運營商可以為此服務收取重新啟用費用。

• 產品使用費用 − 這是最重要的收費型別，它將根據服務的用途收取。例如，每分鐘或每秒的通話費，每 MB 的資料下載費等。

上述所有費用都在不同的資費目錄中定義（即配置），根據監管規定包含或不包含適用稅費。這些目錄因計費系統而異。一些計費系統將所有價格儲存在一個目錄中，而另一些計費系統則將使用費與其他費用分開。

這些目錄在計費系統中維護，但也提供給前端系統，以便在建立客戶帳戶時可以對客戶應用不同的資費。

所有價格也基於產品及其套餐進行定義。不同的產品組合在不同的套餐中可能產生不同的價格。

以下部分將為您提供關於與資費定義密切相關的不同概念的瞭解 −

預付費用和欠付費用

運營商可能希望對某些服務預收取客戶費用，而對其他服務則在每月結束時收取費用。

在提供服務之前預先收取的費用稱為**預付費用**，提供服務之後收取的費用稱為**欠付費用**。

對於欠付費用，產品費用適用於至少到當前名義賬單日期（或非定期賬單的賬單請求日期）的前一天的期間。

因此，在配置不同的費用時，計費系統應提供預先配置費用的功能，並且運營商始終可以選擇是否要預先配置特定價格或欠付。

**注意** − 使用費不能預先收取，除非是總額費用，因為您永遠不知道客戶在下個月將產生多少使用量。如果是總額費用，則可以預先收取該金額，並讓客戶根據其需求使用無限服務。

按比例計費和非按比例計費

考慮這樣一種情況：客戶在月中辦理電話連線，並且他的發票需要在每月的第一天生成。如果價格是非按比例計費的，計費系統將向客戶收取全月費用，這對客戶是不公平的。同樣的情況也適用於終止服務，如果客戶在月中終止服務，則運營商可能不願意向客戶收取剩餘月份的費用。

按比例計費意味著它們只適用於客戶將使用服務的幾天。例如，如果每月的產品租金為 30 美元，而客戶只使用了該產品 10 天，則計費系統應僅向客戶收取 10 美元的費用。

因此，計費系統應提供一個選項來配置特定價格為按比例計費和非按比例計費，並讓運營商選擇最適合他們的方案。

可退款費用和不可退款費用

現在，讓我們考慮這樣一種情況：運營商預先向客戶收取全月費用，但客戶在使用服務 10 天后在月中離開。

如果價格配置為不可退款的，則不會退還給客戶，但如果配置為可退款的，則會退還給客戶。第二個規則是，如果價格配置為按比例計費的，則將根據比例進行退款，否則將全額退款。

費用覆蓋選項

一個良好的計費系統提供了一個選項，可以在向客戶提供價格時覆蓋基本價格。

例如，目錄中特定產品的基本價格定義為每月 30 美元，但客戶不願意每月支付 30 美元，並且基於某些討價還價，他願意每月支付 25 美元。在這種情況下，客戶服務代表 (CSR) 應該能夠覆蓋定義的基本價格 30 美元，並在系統中建立客戶時將其新增為 25 美元。

計費系統應為運營商提供一個可選功能，即特定價格是否可以覆蓋，並讓運營商決定是否要在銷售時覆蓋某些費用，或者在所有情況下都是固定的。

按收入程式碼細分收入

所有運營商都希望知道他們使用特定產品、其租金、暫停或使用等獲得了多少收入。

在目錄中定義不同的價格時，計費系統應提供將某種收入程式碼或關鍵詞與不同型別的費用關聯的功能。這有助於根據與收入相關的程式碼生成不同的報告。

資費分類

運營商可以定義不同的資費，這些資費可以提供給具有不同信用等級的不同人員。例如，每月 100 美元的 5mbps 資料線路可以提供給月收入超過 1000 美元/月的客戶，而 1mbps 資料線路可以提供給月收入至少 500 美元/月的客戶。

所有計費系統都提供定義不同信用等級的選項，這些信用等級可以根據客戶的信用歷史和收入以及運營商定義的其他引數分配給客戶。

所有產品和服務都可以有不同的資費計劃，這些計劃可以提供給從普通客戶到 VIP 客戶的不同等級的人。

使用費的引數

在定義使用費時，可以使用許多引數。例如 −

• 白天（通常稱為高峰時間）的通話將按較高費率收費，而夜間（即非高峰時間）的費率相對較低。

• 如果通話在同一網路內終止（通常稱為網內通話），則將按相對較低的價格收費。

• 週末（即週六和週日）的通話將按較低的價格收費。

• 對特定目的地的通話將按高價收費。

• 節日期間的通話將按特價收費。

• 從特定站點下載資料將免費。

• 向特定程式碼傳送簡訊將按高價收費。

• 特定號碼組（通常稱為封閉使用者組 (CUG)）內的通話將免費。

• 傳送國際或國內彩信將按相同價格收費。

計費系統提供了很大的靈活性來定義各種此類規則，以收取客戶產生的語音、資料、簡訊或彩信使用費。

接下來是什麼？

現在，我們在計費系統中擁有所有產品、服務和相關的資費。在下一章中，我們將瞭解如何將這些產品銷售給終端使用者並在系統中建立其記錄。

電信計費 - 客戶獲取

客戶是“法人實體”（可以是個人或公司），它接受服務提供商提供的產品和服務，並負責支付賬單。在住宅計費場景中，客戶可能是單身戶主。在企業計費場景中，客戶可能是一家公司。

• **個人客戶** − 個人客戶是購買一種或多種產品並支付賬單的個人（或家庭）。不需要任何層次結構來維護客戶或帳戶。

• **公司客戶** − 公司客戶是單個公司或公司的分支機構。可能存在典型的父子型別的客戶層次結構，代表公司的不同分支機構或部門。

客戶獲取流程

客戶獲取是指識別、吸引和留住潛在盈利客戶的過程。這使用稱為**客戶關係管理**(CRM)的系統來處理，它是重要的業務支援系統 (BSS) 之一。

CRM 系統始終與包括計費系統在內的各種系統連線，並將客戶個人資料以及產品和服務資訊饋送到計費系統。

購買產品和服務的客戶需要在系統中啟用，為此，需要客戶的各種詳細資訊 −

• 客戶可能需要填寫申請表，提供個人詳細資訊。

• 驗證客戶身份以防止欺詐。

• 服務提供商需要對客戶進行信用檢查，並根據信用歷史和月收入等分配適當的信用等級。

• 提供在網路上配置以提供服務的適當產品。

一旦獲得客戶，就需要管理和留住客戶，這包括 −

• 與客戶互動和溝通，進行銷售和收款活動。

• 這些互動可以以不同的格式記錄，例如筆記、語音錄音等。這些資料可用於分析客戶的行為，並幫助服務提供商提供更好的服務以留住客戶。

• 處理客戶針對網路或發票等遇到的任何問題提出的故障單。這些資料也可用於分析客戶的行為，並幫助服務提供商改進服務以留住客戶。

• 處理客戶和服務提供商之間提出的任何賬單爭議和調整。

客戶生命週期

典型的客戶生命週期如下所示 −

此處簡要介紹了構成客戶生命週期的所有階段 −

• **客戶參與 −** 客戶聯絡客戶服務代表 (CSR)，並且 CSR 透過向客戶銷售各種產品和服務來與客戶互動。

• **訂單建立和履行** − 客戶獲取產品和服務，CSR 將訂單建立並完成到系統中，然後透過向客戶提供所需的產品和服務來履行訂單。

• **服務供應** − 使用稱為**供應系統**的系統在網路上提供產品和服務。供應系統將客戶資訊以及他們被授權使用的服務告知網路。事實上，這會在網路上啟用客戶。

• **產品使用** − 一旦客戶在網路上被啟用，客戶就開始使用產品和服務，包括撥打電話、下載資料等。

• **產品和服務的計費和開具賬單** − 從網路收集客戶使用情況，然後根據定義的費率計劃對其進行計費，並應用產品租金和所需的折扣、調整等。

• **賬單交付** − 生成賬單後，將其傳送給最終客戶，要求其支付已提供服務的收入。

• **賬單支付** − 客戶支付收到的發票。

• **催繳和收款** − 可能有很多客戶不會按時支付賬單。對於此類客戶，將傳送不同的催繳函以提醒他們付款。如果客戶未按時付款，則將採取不同的收款措施，從逐一停止客戶服務開始。

• **客戶終止** − 可能有多種原因需要在系統中終止客戶。例如，客戶可能遷移到不同的位置，或者客戶可能對提供的服務不滿意等。

在任何給定日期，系統中活躍客戶的總數稱為客戶群。向系統中新增客戶和終止系統中的客戶被稱為客戶流失。

客戶型別

通常，當今電信市場中存在以下型別的客戶：

• 移動預付費客戶 - 這些客戶透過預付費用來使用移動服務。例如，GSM、GPRS手機使用者。這些客戶根據自己的需求充值。

• 移動後付費客戶 - 這些客戶透過在收到每張發票後支付費用來使用移動服務。例如，GSM、GPRS手機使用者。這些客戶每月或雙月支付賬單。

• 固定預付費客戶 - 這些客戶透過預付費用來使用固定線路，即固定電話服務。例如，PSTN、WiMax電話使用者。這些客戶根據自己的需求充值。

• 固定後付費客戶 - 這些客戶透過在收到每張發票後支付費用來使用固定線路，即固定電話服務。例如，PSTN、WiMax電話使用者。這些客戶每月或雙月支付賬單。

接下來是什麼？

現在，我們的計費系統中包含客戶、產品和服務。客戶開始使用購買的所有產品和服務，並開始產生國內和國際、資料和語音呼叫，這些呼叫將由計費系統計費，我們將在後續章節中討論這些流程。

電信計費 - 用量採集

客戶一旦開始使用運營商銷售的產品和服務，就會在網路上開始產生使用情況。網路元素是軟體和硬體的組合，負責所有型別服務的整體服務控制和計量事件。

什麼是事件？

事件是產品使用的一次計費事件，通常由網路以電子方式捕獲。例如，當行動電話使用者撥打電話時，會生成一個事件，其中包含有關該電話呼叫的資訊，例如呼叫時長、呼叫時間和呼叫號碼。

什麼是CDR？

事件及其所有屬性稱為呼叫詳單 (CDR)。網路交換機中的資料收集器以呼叫詳單 (CDR)/使用詳單 (UDR) 的形式捕獲使用情況。這些原始 CDR/UDR 又由中介系統轉換為計費系統可以理解的格式。

可能有不同的網路元素控制服務併產生不同型別的 CDR；例如，對於 GSM 電話：

• 語音呼叫由 MSC（移動交換中心）捕獲。
• 簡訊流量由 SMSC 捕獲。
• 資料流量由 GGSN 捕獲。
• 彩信流量由 MMSC 捕獲。
• 漫遊 CDR 由漫遊合作伙伴的交換裝置捕獲。

有關 GSM、MSC、SMS、SMSC、GGSN、MMS、MMSC 的更多資訊，請參閱我們的 GSM 教程。

下圖顯示了捕獲使用資料並將原始 UDR 傳送到中介系統，最後傳送到計費系統進行計費的網路元素。

CDR 屬性

如上所述，CDR 保留使用詳情以及其他各種有用資訊。以下是 CDR 最重要的屬性：

• 主叫方（A 號碼）。

• 被叫方（B 號碼）。

• 呼叫開始時間（日期和時間）。

• 呼叫時長。

• 呼叫型別（語音、簡訊、資料等）。

• 標識記錄的唯一序列號。

此外，CDR 還可能記錄其他資訊，例如：

• 電話交換機的識別符號。

• 呼叫結果（是否已接聽、忙線等）。

• 用於連線呼叫的中繼線或路由。

• 遇到的任何故障情況。

• 指示來電轉接、三方通話等功能的使用情況。

• 通話期間使用的任何功能，例如呼叫等待或來電轉接。

• 根據需求的其他各種屬性。

UDR 中所有必需資訊的準確記錄取決於交換機供應商的邏輯以及交換機特定的表項。如果兩者都不能準確記錄資料，則中介系統將無法識別已完成的呼叫並將它們傳遞給計費系統。

CDR 處理

中介系統以不同的格式從不同的網路元素收集 CDR。各種網路元素以 ASN.1 格式生成 CDR，而某些網路元素則具有其自身的專有 CDR 格式。

中介系統處理所有 CDR 並將其轉換為與下游系統（通常是計費系統）相容的格式。中介系統對 CDR 應用各種規則來處理它們；例如，中介系統根據撥打的號碼（B 號碼）標記國際呼叫，同樣，中介系統根據 A 號碼和 B 號碼標記本地呼叫。

可能需要過濾掉所有通話時長少於 5 秒的呼叫，過濾此類呼叫的最佳位置是在中介系統級別。同樣，如果 CDR 中需要一些對計費至關重要的額外資訊，則中介系統將根據 CDR 中的其他屬性幫助提供此類資訊。

收集到的 CDR 處理完畢後，中介系統使用 FTP 將所有 CDR 推送到計費系統，因為中介系統和計費系統通常執行在不同的機器上。

下一步是什麼？

好了，現在您已經捕獲了客戶產生的使用情況。下一章將介紹如何對捕獲的使用情況進行計費，以便可以從終端使用者那裡收取應收款項。

電信計費 - 計費流程

費率是事件發生的費用/價格。費率示例包括電話呼叫時長的費用：例如：“每分鐘 0.40 印度盧比”或特定數量。例如：1MB 下載 10.00 印度盧比，或者可以按服務質量收費。

我們已經解釋過，事件是產品/服務使用的一次性事件。事件由網路元素以 CDRS/UDR 的形式捕獲，並傳遞給計費系統進行計費。

計費是確定單個事件費用/價格的過程。例如，2 分鐘通話的價格為 0.80 印度盧比，每分鐘費率為 0.40 印度盧比。

計費引擎是計費系統的一部分，執行此計費功能。

計費過程

計費引擎以稱為呼叫詳單 (CDR) 或使用詳單 (UDR) 的資料記錄的形式接收事件，這些記錄描述了產品/服務的使用情況。CDR 是一串包含呼叫資訊的資料，例如呼叫日期和時間、呼叫長度、主叫方、被叫方等，這些資訊用於對事件進行計費。

計費/計費引擎的一些基本功能列表：

• 在漫遊使用的情況下，從中介系統或其他服務提供商或漫遊合作伙伴處接收 CDR。

• 驗證 CDR 並消除任何重複記錄。這些重複事件儲存在資料庫表中以供以後驗證。

• 確定要為事件收費的客戶帳戶。在此，費率過程拾取事件源（行動電話號碼或 IP 地址等）並檢查資料庫以驗證此事件源是否與任何帳戶關聯。此步驟稱為事件引導。

• 如果無法引導事件，則將拒絕此事件，並將其放入暫停類別。這些被拒絕的事件儲存在資料庫表中以供以後驗證。

• 根據計費資費（也稱為費率計劃）計算事件的成本/價格。

• 應用任何適用的計費時間折扣。這可能是前五分鐘免費，之後通話將按正常費率收費。此類折扣稱為計費時間折扣。

• 將已計費的事件儲存在資料庫中以用於計費目的，或將其傳送到外部系統進行計費。

下圖顯示了計費引擎及其相關功能的概述：

客戶資訊決定在費用/價格計算中使用的費率計劃（計費資費）。計費引擎使用計費表和來自 CDR 的事件資訊（例如距離、一天中的時間、呼叫位置、事件的持續時間或數量等）來計算每次呼叫的實際費用。

重複事件

重複事件定義為任何未計費事件，該事件與另一個未計費事件在以下所有方面都相關：

• 帳戶號碼相同。
• 事件源相同。
• 事件型別 ID 相同。
• 事件日期和時間相同。

可以在計費系統中定義任何其他標準來識別重複事件。可能導致重複事件提交到計費系統的情況有很多：

• 中介系統過濾機制故障。
• 中介系統軟體中的編碼錯誤。
• 重複傳遞到計費引擎的所有或部分事件檔案。

拒絕的事件

當計費系統遇到特定事件的問題時，將拒絕有問題的事件。拒絕可能是由於以下任何問題造成的：

• 事件本身。
• 費率計劃。
• 客戶和帳戶資料。
• 配置資料。

拒絕事件的主要原因有三個：

• 解析錯誤阻止計費系統讀取事件詳細資訊記錄中的資訊。由於事件記錄中的資料損壞或格式錯誤，可能會發生解析錯誤。

• 無法引導的錯誤阻止 Geneva 識別與事件相關的事件源或帳戶。由於事件源在計費系統資料庫中尚不存在，可能會發生無法引導的錯誤。

• 無法計費的錯誤阻止計費系統計算事件的成本。由於費率計劃存在問題，可能會發生無法計費的錯誤。

所有被拒絕的事件都發布到一個特殊的帳戶，稱為內部帳戶或暫緩帳戶，這些被拒絕的事件稱為暫緩事件。財務部門跟蹤所有被拒絕的事件，並將它們計為收入損失的一部分。IT 部門始終非常重視解決被拒絕的事件並對其進行正確計費以節省收入。

如果無法修復被拒絕的事件並且運營商不想將其釋出到內部帳戶，則可以丟棄該事件。當丟棄事件時，它不會提交給計費引擎，也不會再嘗試對其進行計費。

即時計費

即時計費是在事件發生時立即對其進行計費的過程，在事件生成和計費之間儘可能減少延遲。即時計費與基於檔案的計費形成對比，在基於檔案的計費中，事件詳細資訊儲存在檔案緩衝區中數小時、數天或數週，然後最終對整個檔案進行計費。

即時系統流程包括電子商務交易和資料下載。任何必須快速評估事件並將其應用於客戶帳戶的應用程式都是即時計費的合適候選者。

重新計費事件

可能需要重新計費事件的情況有很多。例如，當：

• 使用的計費方案出錯導致事件定價錯誤。

• 事件載入到錯誤的帳戶（由於事件源註冊不正確）。

• 在上次賬單日期和下次賬單日期之間某個時間點替換了現有的計費方案。

• 產品的計費方案、價格方案或事件源已被追溯更改。

重新計費事件的過程非常簡單，步驟如下：

• 使用提供的實用程式從資料庫中解除安裝/取消計費所有事件。大多數計費系統都提供一個實用程式來解除安裝或取消計費所有已計費的事件。

• 修復問題所在。

• 透過計費引擎重新提交事件進行計費。

部分事件

部分事件允許在事件進行時維護客戶的餘額。

例如，對於長時間的資料下載，中介系統將不斷向計費系統傳送部分事件，以便計費系統持續進行計費，而不是等待事件完成；一旦客戶的信用額度超出限制，帳戶將被阻止，並通知網路元素終止呼叫。

閾值和操作

計費引擎可以自動檢查是否達到任何計費時間閾值，包括計費時間折扣閾值。

計費時間閾值有助於保護運營商免受大量收入損失。例如，客戶可能不願意支付超過其信用額度的費用，在這種情況下，一旦達到信用額度閾值，就必須終止客戶的呼叫。

如果需要採取計費時間操作，那麼儘可能進行即時計費非常重要。

下一步是什麼？

到目前為止，我們已經瞭解了客戶如何產生使用情況，中介系統如何將該使用情況（CDR）推送到計費系統，以及計費系統如何對這些 CDR 進行計費。

在下一章中，我們將討論如何收集整個月的所有已計費 CDR 並生成最終發票/賬單，該發票/賬單將傳送給最終客戶，以收取提供的服務的費用。

電信計費 - 流程

計費是按帳戶逐個帳戶彙總所有非經常性、定期和可收費事件。它也是計算所有未付費用以及可用的折扣和獎金。

計費過程的輸出是帶標籤的賬單資料流，可用於在紙張、磁碟或任何其他介質上建立賬單。計費引擎（計費系統的一部分）建立發票。

賬單流程

下圖顯示了計費引擎和相關功能的基本圖：

計費引擎選擇一個帳戶來生成賬單，並使用以下相關資訊來生成發票資料：

• 客戶在發票月份內的所有已計費 CDR。

• 適用於客戶產品和服務的各種費用（啟動、安裝、定期、暫停、終止等）。

• 如果有任何退款或任何其他適用的費用。

• 以前賬單的總欠款。

• 客戶在給定月份支付的總款項。

• 為客戶或反對客戶透過的總調整。

• 給予客戶的總折扣。

• 適用於客戶使用費和租金費用的總稅款。

• 執行計費引擎所需的計費配置引數；例如，到期付款日期等。

上述資訊僅供參考，可能因計費系統和運營商而異。

計費引擎生成包含生成最終賬單所需的所有資訊的原始資料，此原始資料可用於生成最終發票併發送給最終客戶。

賬單週期

當客戶新增到計費系統時，系統會為客戶分配預定義的賬單週期。賬單週期是計費引擎執行併為一組客戶生成賬單的日期。

如果有許多客戶，則將其分成不同的賬單週期。例如，一組客戶的賬單資料可以是每個月的第一天；另一組客戶的賬單日期可以是每個月的第 15 天。

如果客戶被分配在每月 1 日生成賬單，這將被稱為客戶的**名義賬單日期**。但由於各種原因，許多時候賬單執行會延遲，實際賬單會在稍後的日期生成，這將被稱為**實際賬單日期**。

賬單型別

使用者可能可以使用各種型別的賬單。其中一些可能不受某些計費系統支援。

賬單是自動生成或根據客戶的要求生成的。

計費模式

計費系統可以透過兩種模式生成賬單，例如：

• **測試（假設？）計費模式** - 此模式用於生成格式化的測試賬單，同時保持資料庫不變。這些賬單有助於確保系統正常工作，並在對賬單模板或資費進行更改後進行測試。

• 在測試模式下執行計費引擎時，不會對資料庫進行提交。因此，即使多次執行測試計費，也不會影響客戶的個人資料。

• 測試賬單通常針對一組樣本客戶執行。如果您對測試賬單滿意，則可以繼續進行生產賬單。

• **生產（即時）計費模式** - 此模式用於生成正常的生產賬單。大多數情況下，這是計費引擎的預設模式。

• 生成生產賬單後，計費引擎會使用客戶需要支付的總未付餘額和下一個賬單日期等資訊更新資料庫中的客戶個人資料。

計費引擎為所有生產賬單分配不同的發票號碼，這有助於跟蹤針對發票進行的不同付款。

賬單抑制

可能存在不值得生成賬單而最好抑制賬單的情況。以下是此類情況：

• 抑制零（零活動賬單）或價值很低的（小額賬單）帳戶的賬單。

• 如果同時請求/安排多種賬單型別，則也可以抑制特定型別的賬單，從而防止向客戶傳送不必要的賬單。

小額賬單是指賬單金額介於最小正賬單金額和最大負賬單金額之間的賬單，屬於例外賬單情況。生成小額賬單，然後將其從計費流程中刪除，這樣就不會發送給客戶。

例外賬單

可能的例外賬單示例包括異常高的賬單或超過帳戶信用額度設定倍數的賬單。計費引擎會對其生成的賬單資料進行一些基本檢查。這包括測試計費總額以確保滿足以下條件：

• 賬單總額大於最小負賬單金額。

• 賬單總額小於最大正賬單金額。

• 賬單總額小於帳戶信用額度乘以信用額度倍數。

所有上述條件因計費系統和運營商而異，它們被稱為例外賬單條件。

賬單明細

預設情況下，所有發票都提供產品和服務費用以及使用費用的詳細摘要。但它並未提供客戶所做所有呼叫的詳細資訊。

明細賬單意味著提供客戶所做所有呼叫的完整詳細資訊。這需要列印更多數量的紙張。最近的趨勢是透過電子郵件傳送明細賬單，並使用賬單的紙質副本傳送彙總報表。

賬單格式

有些計費系統提供計費格式化實用程式，可用於生成最終格式化的賬單。

賬單格式化程式採用計費引擎生成的輸出資料，通常生成 PostScript 檔案或 PDF 檔案，賬單列印公司可以使用這些檔案。

如果計費系統無法生成格式化的賬單，則系統會生成一組帶標籤的檔案以及計費資訊，任何外部賬單格式化程式都可以使用這些標籤資訊來生成格式良好的發票。

無論計費系統是否生成格式化的發票，或者我們使用外部工具使用計費引擎生成的原始資料來生成這些格式化的發票，最終這些發票都會發送到賬單列印公司，由他們負責生成最終的發票副本。我們將在後續章節“發票生成”中詳細討論。

下一步是什麼？

下一章將解釋折扣流程，這實際上是計費流程的一部分，但由於一些專案需要更多解釋，我們將其作為一個單獨的部分。

我們將討論不同型別的折扣層級以及在計費時可以提供的折扣。

電信計費 - 折扣應用

所有折扣都會更改（最常見的是減少）一組事件和/或產品應支付的價格。折扣是給客戶打折的一種方式。折扣定義了一定金額（百分比或貨幣金額），用於應用於符合特定條件的產品或使用情況。例如，在特定日期（例如 2010 年 1 月 1 日）撥打的本地電話，每通電話收費 0.20 美元。

折扣可以在計費過程中或計費過程中計算：

• 計費時折扣 - 所有在計費過程中提供的折扣。這些折扣只能針對使用情況提供。計費時折扣的一個例子是“所有國際電話前一小時享受 5% 的折扣”。

• 賬單時折扣 - 所有在賬單處理過程中提供的折扣。這些折扣可以針對已計費的使用情況，也可以針對產品和服務費用提供。賬單時折扣的一個例子是“如果在一個月內花費超過 15 美元，則享受 5% 的折扣”。

專案前折扣是對其適用的每個事件的價格進行修改，以確定重新計費的價格。此折扣也屬於賬單時折扣類別，但這與通話計費有關。其他賬單時折扣不會修改事件的價格。專案前折扣不能包含產品費用，只能包含事件費用。

折扣階梯和閾值

折扣的大小使用一系列折扣階梯和閾值來確定。當達到特定閾值時，折扣階梯允許更改折扣的大小。

例如，電話事件的折扣可能取決於通話分鐘數，通話 100 分鐘後享受 10% 的折扣，通話 200 分鐘後享受 20% 的折扣。

每個折扣至少應包含一個階梯。如果需要隨著數量的增加使折扣更有利或更不利，則可以新增更多階梯。每個折扣階梯都可以將其折扣表示為金額或百分比（但不能同時表示兩者）。

簡單的折扣型別

可以給予最終客戶無限型別的折扣，但這取決於您的計費系統支援哪些型別。以下是簡單但非常有效的折扣型別：

跨產品折扣

這是一組產品和事件決定另一組產品和事件的折扣的情況。

例如，“如果在行動電話上花費超過 30 美元，則免費贈送 10 條簡訊”。此處行動電話決定折扣，簡訊產品獲得折扣，此類折扣稱為跨產品折扣。

分級折扣

這些折扣僅適用於在指定的折扣閾值之間的一組事件或花費的部分。例如，在下圖中，0-100 美元或 0-100 個事件的支出享受 0% 的折扣，100-200 美元或 100-200 個事件的支出享受 5% 的折扣，依此類推。

批次折扣

這些折扣基於特定產品生成的事件數量或產品費用。例如，在下圖中，花費 100 美元或 100 個事件享受 5% 的折扣，依此類推。如您所見，花費越多，折扣越大。

稅收折扣

稅收折扣提供了一種處理某些稅收豁免的替代方法。它們在對賬戶進行計費時計算和應用。

折扣期限和按比例分配

大多數折扣都有與其相關的折扣期限，可以是任意數量的天、周或月。此期限可透過三種方式使用：

• 指定應達到閾值的時長。

• 指定應應用絕對摺扣的頻率。

• 指定多久確定一次附加了最高使用情況篩選器的折扣的最高使用情況。

根據要求，折扣可以按比例分配和非按比例分配。如果折扣按比例分配，則折扣將根據服務的使用天數計算；如果是非按比例分配折扣，則將根據配置折扣的整個期間進行計算。

獎勵計劃

獎勵計劃是向客戶贈送免費事件的方法，其中免費事件的數量由一段時間內（例如，上一年）一個或多個產品的先前使用情況或費用決定。

例如，“選擇超級優惠電話套餐，即可在上一季度每撥打三個小時的國際電話獲得 10 美元的免費通話”。

還有其他方法可以為客戶打折，例如，透過套餐提供更有利的資費方案，隨著數量的增加降低產品的單位價格。

呼叫圈組 (CUG)

呼叫圈組定義了使用者之間的關係，這些使用者被建模為成員和（預設情況下）非成員。

在此模型中，圈內成員之間進行的呼叫將使用與非成員（或關聯方）進行相同呼叫時應用的不同費率進行定價。

呼叫方之間的關係由呼叫方身份的組合決定。如果網路屬於同一運營商，則呼叫圈可以跨網路，並且單個呼叫圈可以包含移動使用者和固定線路使用者。

下一步是什麼？

我們已經在上一章中介紹了計費流程。在下一章中，我們將討論發票生成的最後一部分，從原始發票資料到結構化賬單的形成。

電信計費 - 發票生成

大多數計費系統都會生成包含賬單資訊內容的結構化 ASCII 文字。每個賬單的賬單資料最初寫入資料庫或平面文字檔案。此階段資料的格式相同，無論如何處理資料。

然後，可以使用多種格式化引擎之一處理此賬單資料，以生成所需形式的輸出。例如，紙張、CD-ROM 等。

有一些計費系統提供內部賬單格式化工具。如果計費系統不提供能夠生成格式化賬單的工具，則可以使用第三方工具，例如 DOC1，這是最常用的工具之一。

以下是顯示賬單格式化流程的典型圖表：

以下是 Convergy 的 Infinys 計費系統中獲取的賬單資料的快照：

DOCSTART_85
DOCTYPE BILL
GENEVAVERSION 5.0
BILLSTYLE 1
BILLTYPE 1
BILLTEMPLATE 85
BILLSEQ 1
BILLVERSION 1
ACCCURRENCYCODE BEF
BILLLANGID 2
BILLLANGNAME English (US)
BILLLANGLOCALE us
PAYMETHODID 1
FORMATREQ A30001001/0001
COPYBILLNUM 0
BILLPURPOSE 1
ADDRESSNAME Dr D Jackson
POSITION Project Manager
DEPARTMENT Recruitment
ADDRESS1 12 South Street
ADDRESS2 Detroit
ADDRESS3 Michigan
ZIPCODE 12345
COUNTRY United States
BSTARTACCFADDR
ACCFADDR_1 United States
ACCFADDR_2 Michigan
ACCFADDR_3 12345
ACCFADDR_4 12 South Street
ACCFADDR_5 Detroit
ACCFADDR_6 Dr D Jackson
BENDACCFADDR
CUSTOMERREF C30001
CUSTOMERTYPE Standard
ACCTAXSTATUS Exclusive
INVOICINGCONAME Invoicing company for English (US)
INVOICINGCOADDRESS1 Company House
INVOICINGCOADDRESS2 Atlanta
INVOICINGCOVATREG taxref000576
ACCOUNTNO A30001001
BENDBFPAYSUMMARY
BALOUT 0.00
CHARGES 142.00
NEWBAL 142.00
BSTARTBFPAYDETAILS
ACCDEPPREVTOT 0.00
ACCDEPCHANGE 0.00
ACCDEPCURRTOT 0.00
BENDBFPAYDETAILS
BENDBFSTATEMENT
BILLREF A30001001@0001
BILLDATE 02/20/99
NEXTBILLDATE 03/20/99
BSTARTPAYMENTDUEINFO
PAYMENTDUEDATE 03/04/99
DEBTSTARTDATE 02/25/99
PAYMENTTERMDESC Payment due 7 days after the bill date
PAYMENTDUEDAYS 7
BENDPAYMENTDUEINFO
GIROREF 34
GIROACCOUNT 404 7800
OCRREF 1300010019
OCRSORTCODE V6344047800
GIROAMOUNT 142.00
OCRAMOUNT 000142000
INVOICEACTUALDATE 02/25/99
INVOICETAXDATE 02/25/99
INVOICESTART 01/03/99
INVOICEEND 02/19/99
TAXTYPE 1,2.00,
TENDTAXTYPE
INVTOTALTAX 2.00
BENDTAXDETAILS
INVTOTAL 142.00
INVTOTALROUNDED 142.00
TOTALSAVE -11.00
PERIODEND 02/25/99
POINTSBALANCE 0
POINTSEARNED 0
POINTSREDEEMED 0
POINTSADJUST 0
NEWPOINTSBALANCE 0
DOCEND

賬單資料由一系列 ASCII 文字行組成。每行採用以下格式：

TAGNAME tagvalue

TAGNAME 和標籤值之間用空格分隔符 (tagsep) 分隔。標籤值可以是單個值，也可以是用分隔符 (sep) 分隔的值列表。除非另有指定，否則使用的分隔符為逗號。

賬單後處理器

計費引擎可能無法生成賬單中所需的所有資訊，或者可能需要對發票中提供的資料執行一些特殊計算。這稱為賬單後處理，通常由稱為賬單後處理器 (BPP) 的自定義元件執行。

可以使用您首選的程式語言編寫 BPP，它讀取原始發票檔案，並在將其傳遞到最終格式化之前對該檔案進行必要的修改。

沒有計費系統提供開箱即用的 BPP 功能，因為運營商的要求各不相同，並且此流程無法標準化。充其量，計費系統可以提供一個外掛點來插入您自定義的 BPP 以及計費引擎。

DOC1 賬單格式化程式

DOC1 是 PitneyBowes 公司提供的非常著名的賬單格式化工具，可幫助將賬單格式化為 PDF 或 PostScript 檔案。

如上所述，計費引擎的輸出是包含賬單資訊內容的結構化 ASCII 文字。在計費系統生成的源發票檔案標籤和 DOC1 需要的標籤之間建立對映。DOC1 需要固定長度的標籤，如下所示。

以下是發票檔案中提供的假設示例：

ACCOUNTNO ACC0010000
ACCUMBONUSPOINTS_1 BON0050100
ACCUMBONUSPOINTS_2 BON0050100
ACCUMBONUSPOINTS_3 BON0050100
ACCUMBONUSPOINTS_4 BON0050100
ACCUMBONUSPOINTS_5 BON0050100
ADDRESS1 ACC0030000
ADDRESS2 ACC0040000
ADDRESS3 ACC0050000
ADDRESS4 ACC0060000
ADDRESS5 ACC0070000
ADDRESSNAME ACC0020000
BUSINESSNAME ACC0120000
TSTARTADJ ADJ0000000
..........

現在使用上述轉換，將為 DOC1 生成最終檔案，DOC1 將負責使用提供的資訊生成最終發票。

也可以在 DOC1 級進行一些修改，但這並沒有提供太多靈活性來修改發票。您可以嘗試最新版本，它可以幫助您更好地滿足期望。

最終發票生成

一旦所有賬戶都被計費，並且使用內部或外部賬單格式化程式對發票進行格式化，這些發票就會發送到賬單列印公司進行最終列印。

如果運營商使用電子郵箱向客戶傳送賬單，則可以將同一賬單的副本傳送到郵箱系統以將其傳送給最終客戶。

一級運營商（擁有 2000 萬或更多客戶）通常會將此任務（包括賬單分發）外包。

下一步是什麼？

生成發票後，將傳送給最終客戶。現在，是時候從客戶那裡收取收入了。我們將在下一章討論收入收取流程。

在我們繼續之前，讓我們先介紹信用控制部分，這非常重要，應該在收入收取之前介紹。

電信計費 - 信用控制

所有運營商都提供服務並從最終客戶那裡收取收入以維持業務。向最終客戶收費可能有兩種方式：

• 預付費 - 運營商在提供服務之前向客戶預先收費。這會導致客戶滿意度降低，但運營商在收入方面更安全。

• 後付費 - 運營商承擔風險，並在提供所需服務後每個月結束時向客戶收費。這會導致客戶滿意度更高，但運營商面臨收取較少收入的風險。

運營商總是能容忍與特定客戶相關的收入損失的閾值；同時，運營商也能承受與特定客戶相關的風險閾值。

例如，如果客戶的月收入為 10,000 美元，則運營商可以很容易地向他提供高達 1000-2000 美元的服務，但對於同一家運營商來說，提供價值近 10,000 美元的月服務會很困難，因為在這種情況下，客戶很難按月付款。

秉承同樣的理念，運營商定義了不同的信用等級，他們用來對客戶進行分類並關聯不同的信用和收款行為。

信用等級

信用等級定義了客戶的類別，以及可以承擔的與該客戶相關的收入風險。信用等級還定義瞭如果客戶未能支付到期的（無爭議的）款項，應向該客戶應用的哪些收款計劃。

所有計費系統都提供定義各種信用等級的功能，這些信用等級可以在將客戶新增到系統時分配給不同的客戶。一些信用等級的例子如下：

• VIP信用等級 - 這可以分配給VIP客戶，並且信用額度非常高。

• 普通大眾等級 - 這是最常見的信用等級，信用額度大約為100美元或200美元。

• 細分特定等級 - 這些等級可以根據不同的細分市場來定義，例如警察、軍人或銀行職員等。運營商可以根據自己的情況定義信用額度。

可以根據客戶的需求和類別定義無限數量的信用等級。

信用控制

主要有兩個階段可以控制特定型別的客戶類別的信用：

未計費使用量

這是計費時間的控制，由計費流程完成。在此，將客戶的使用情況和總費用與分配的信用額度進行比較，如果客戶開始接近分配的信用額度，則會通知客戶，並且在超過信用額度後可以採取適當的措施。

有些運營商希望在客戶超過信用額度時禁止（即暫時停止）服務，並在付款後取消禁止。例如，信用額度為200美元的客戶，在使用率達到80%時會透過簡訊收到通知，在達到90%的閾值時可能會透過提醒電話收到通知，等等，當達到100%的信用額度時，則可能會禁止撥出。

為了控制信用，運營商希望僅在語音和簡訊使用的情況下禁止撥出電話，但在資料下載的情況下，客戶將無法執行任何資料下載。

已計費使用量

這通常在傳送發票後完成，更多地與收入收取流程相關，我們將在下一章討論。

為了在計費時控制信用，重要的是使計費盡可能即時。如果使用情況不是即時捕獲的，而是在較長時間後進行計費，則客戶可能已經超過了他們的信用額度，並且合法情況下客戶可能無法支付超過其分配信用額度的金額，但這因國家和運營商而異。

存款

有些計費系統支援持有賬戶存款。存款與賬戶餘額一起持有，並且可以在兩者之間轉移現金。

可以有不同級別的存款來提供不同型別的服務，這些服務可以針對某個賬戶維護。

存款幫助運營商在客戶無法付款的情況下彌補其收入。

下一步是什麼？

希望您對如何控制給予不同客戶等級的信用有一些瞭解。仍然會有一些客戶即使在給予他們能力範圍內的信用後也不會按時付款。還有一些客戶在使用服務後根本不付款。

在下一章中，我們將解釋如何定義不同的收入收取流程和時間表來收取提供的服務的收入。

電信計費 - 收款流程

發票生成併發送給客戶後，理想情況下，所有客戶都會收到賬單並及時付款。但是，可能有些客戶沒有支付賬單，並且支付賬單可能存在不可接受的延遲，因此服務提供商必須採取一些必要的措施來糾正這種情況並收取應收未付餘額（稱為應收賬款，縮寫為A/R）。

收款是指追討客戶賬戶上逾期的應收賬款的過程。這通常包括向客戶傳送通知，並在到期日後未付款的情況下采取適當的措施。

計費系統支援在發票級別和賬戶級別進行催收（追討應收賬款），在發票級別，逐個發票追討應收賬款；在賬戶級別，可以透過單次催收操作處理一個賬戶的全部逾期金額，這些金額可能跨越多個發票。

用於賬戶的催收模型將根據其信用等級分配。核心收款流程包括以下兩項：

• 逾期賬款追蹤 - 這是跟蹤在指定的付款期限到期日內未付款的客戶發票的過程。它處理“應收賬款的期限”；例如，逾期0-30天、逾期30-60天等的發票。

• 收款措施 - 收款措施是在應收賬款達到特定期限時執行的措施。例如，應向客戶傳送提醒郵件或播放錄音訊息。

收款措施時間表

通常，收款措施按以下步驟進行：

• 傳送提醒郵件和/或電話：客戶服務部門聯絡客戶，提醒付款。如果仍然沒有收到付款，則繼續執行下一步操作。

• 傳送催款函 - 例如，發出“七天內付款”的信函。如果仍然沒有收到付款，則繼續執行下一步操作。

• 斷開服務 - 網路管理部門暫停服務。

收款時間表定義了應執行的收款措施以及在客戶未付款時應執行這些措施的時間。

收款時間表指定構成收款流程的一系列階段。對於每個階段，它都包括：

• 應收賬款必須達到的有效期限才能採取行動。應收賬款的有效期限是透過獲取應收賬款的實際期限計算得出的。

• 要採取的行動。這可能是計費系統要執行的操作，例如在特定日期傳送催款通知。

• 該操作是否強制性。如果操作是強制性的，則在執行此操作之前，無法執行後續操作。

• 低於該金額將不會採取行動的最低應收賬款金額。

軟性收款措施 - 催款通知

在收款流程的早期階段，軟性收款措施通常是傳送多個催款通知，這些通知是簡單的提醒信函和付款請求。

在各個階段傳送了多個催款通知後，通常會安排其他措施。例如，您可以指定客戶服務代表 (CSR) 應致電客戶，詢問他們為什麼沒有付款。

硬性收款措施 - 列入黑名單

如果初步嘗試失敗，則可以採取更積極的措施，例如禁止服務或斷開服務或熱線（熱線是將所有拖欠客戶的電話轉接到收款運營商的過程）。

如果所有追討欠款的嘗試都失敗，則服務提供商可能會登出賬戶並將欠款標記為壞賬，或者可能會將賬戶移交給（出售給）收款機構。收款機構按收取收入的百分比收取費用。但是，一旦未收取的賬戶發票被出售給收款機構，服務提供商就不允許與客戶就付款事宜進行合作。

在這裡，登出意味著服務提供商（運營商）代表客戶結清欠款並永久關閉賬戶。這是為了會計目的，否則對運營商來說是一種損失。

服務提供商會維護登出賬戶的歷史記錄，也稱為黑名單客戶，以便他們不會再次重新啟用，並會將此類賬戶資訊通知信用檢查/報告機構。

下一步是什麼？

大多數客戶會在到期日之前付款。可以使用不同的渠道進行付款。

在下一章中，我們將討論不同型別的付款及其端到端處理，以結清發票。

電信計費 - 支付處理

一旦發票傳送給客戶，客戶就開始支付賬單。將賬單付款處理到計費系統中稱為付款處理。

客戶支付的款項記入客戶的賬戶。如果有任何未結髮票，則支付哪張發票取決於賬戶的會計方法。有兩種型別的會計方法：

• 餘額結轉會計 - 使用此方法，如果有多張發票未結，則收到的付款將根據應收賬款的期限分配給發票，最舊的發票優先建立。

• 未結項會計 - 此方法允許將付款分配給特定發票。在處理來自商業客戶的付款時，未結項會計特別有用。

付款方式

客戶可以使用服務提供商支援的不同付款方式付款；例如，客戶可以使用支票、信用卡、簽帳金融卡或電匯或直接現金存款等付款方式付款。

運營商可能有多個銀行賬戶，它將透過銀行賬戶直接接收付款。這些銀行賬戶稱為備付賬戶，並透過文字檔案將付款詳細資訊傳送到計費系統。

如果付款是透過手動或電子方式在計費系統外部收到的，則這些付款將使用自動化流程上傳到系統中，以結清發票。

自動付款

計費系統提供捕獲信用卡或簽帳金融卡資訊以及每月自動付款方式的功能。

如果使用信用卡或簽帳金融卡設定自動付款方式，則每次開具發票後或在給定日期自動生成付款請求，並將這些請求傳送到支付閘道器（或銀行）以進行付款授權。

一旦所有付款獲得授權，它們就會上傳到計費系統以結清到期發票。

手動付款

如果付款使用現金或支票進行，則可以預先將其輸入系統，或者如果由某些機構收取，則收集所有此類付款並使用計費系統提供的自動化方法將其記入計費系統。

對於所有收到的付款，都將以預定義的格式準備付款檔案，然後將它們自動推送到預定義的位置，計費系統從該位置獲取它們並將其上傳到計費資料庫。

信用卡或支票支付有時可能會失敗。如果此筆支付已記入系統，則需要取消以調整金額。計費系統提供實用程式來處理失敗或取消的支付。

支付介面

介面是計費系統與任何其他外部系統接收支付之間的橋樑。介面允許兩個系統根據預定義規則進行通訊。

例如，簡單的文字檔案可以作為銀行和計費系統之間的支付介面。如果介面基於檔案，銀行將使用預定義格式的支付檔案不斷髮送支付詳細資訊。

銀行和計費系統之間可能存在基於線上 API 的介面。如果已啟用線上介面，則銀行將呼叫提供的 API 將支付直接記入計費系統。

同樣，可以為參與收款的第三方提供基於檔案或線上的介面。

下一步是什麼？

到目前為止，我們幾乎已經瞭解了電信客戶的整個生命週期。下一章對於理解運營商和客戶之間產生的爭議情況非常重要。

電信計費 - 爭議與調整

什麼是爭議？

爭議是指關於賬戶金額的查詢記錄。通常，當客戶對賬單的某些方面提出疑問時，就會記錄爭議。爭議可以針對以下方面提出：

• 針對賬戶上的發票。

• 針對賬戶上的特定計費事件。例如，如果客戶由於停電而對特定的付費電視節目提出爭議。

爭議處理

記錄爭議後，將對其進行調查和驗證，以：

• 接受 - 如果從客戶方面來看，提出的爭議有效，則爭議將被接受，並將退款給客戶。

• 拒絕 - 如果發現爭議不可接受，則爭議將被拒絕。

• 取消 - 如果錯誤輸入爭議，則爭議將被取消。

關於爭議，應注意以下幾點，計費系統應支援這些幾點：

• 在金額處於待處理爭議狀態時，不會升級催收行動，但在此期間會計算催收賬齡。

• 爭議事件在計費前不包含在催收計算中。此後，催收賬齡將按正常方式計算。

什麼是調整？

調整是一種用任意金額貸記或借記賬戶的方法。調整可以針對整個賬戶或賬戶上的特定計費事件進行。

計費系統允許建立不同型別的調整，這些調整可用於不同的情況，並且每種調整都經過不同的審批階段。

如果接受爭議，則建立一個調整以貸記爭議金額到賬戶。在調整獲得批准之前，不會影響賬戶餘額。待批准的調整不會影響計費或催收。

針對含稅賬戶進行的爭議和調整被假定為含稅。輸入總額，並在賬單上顯示。

下一步是什麼？

在下一章中，我們將討論管理所需的各種報表。可能有一系列現成的報表，也可能需要一些需要定製開發的報表。

電信計費 - 報表生成

生成各種報表，為管理層提供有關財務、銷售和系統性能的有價值資訊。可以生成各種報表，例如財務報表、管理報表、對賬報表、網路活動報表等。

報表包含推動業務成功的資訊，有助於監控業務健康狀況，識別任何問題領域，以便採取適當的糾正措施。

報表是計費系統無法完全滿足所有需求的領域之一。市場部或財務部門肯定會提出需要大量定製開發的報表需求。

如果您的計費系統將資料推送到資料倉庫 (DWH)，則您可以將報表活動轉移到 DWH 系統，但許多部門仍然希望從源系統（即計費系統）獲取重要報表。

我們可以將報表分為兩類：

• 核心/標準報表 - 這些報表由計費系統作為系統的核心功能提供。有時，它們被稱為標準報表。

• 自定義報表 - 這些報表不會直接從系統中獲得，需要使用 PL/SQL、PERL 或 Shell 指令碼等進行一些開發。

不同的計費系統在不同領域提供不同型別的報表。互聯計費系統需要提供更多與報表相關的功能，因為它們處理批發計費。

報表需求

以下是不同部門所需的報表列表：

財務報表

支付報表提供一段時間內客戶賬戶支付的資訊。應收賬款賬齡報表提供有關應收賬款、未付欠款等的資訊。

爭議和調整報表有助於識別爭議和調整原因的模式，並有助於瞭解此類爭議和調整的原因，並採取適當的糾正措施。

管理報表

管理報表提供有關客戶、其產品和服務使用情況、呼叫模式、客戶反饋等的資訊。這些報表有助於採取適當措施以減少客戶流失並推出新服務。

流失是指客戶斷開與一個服務提供商的連線並轉向另一個服務提供商的過程，這可能是由於許多原因造成的，例如客戶服務不足、缺乏競爭性產品或缺乏競爭性收費，也可能是由於客戶的地理位置遷移等自然原因。

對賬報表

這些報表提供收入保證 (RA) 資訊，確保所有收入和支出來源都在監控之下，並且沒有任何收入流失。例如，收入可能由於許多原因而流失，例如網路系統或中介或計費錯誤中的漏洞、對快速推出新服務的 demand 等。

收入保證報表有助於識別收入流失的地方，以便採取適當的措施。

網路活動報表

這些報表提供資訊，以識別網路擁塞的區域，以便採取糾正措施（重新路由或新增更多資源）來解決這些問題。

其他報表

以下是計費系統可能需要的其他一些報表的示例列表：

自動化與手動

可能需要按月、周或每日生成的報表列表。因此，如果此類報表不可用，則會在系統內對其進行開發和排程，以便可以無需人工干預即可將其傳送到終端使用者的郵箱。

根據某些需求，不同時間段對不同報表的 demand 會有所不同，此類報表無法預先設想和開發。因此，這些報表根據不同使用者的需求進行開發和傳送。

下一步是什麼？

從下一章開始，我們將介紹不同型別的計費；例如，零售、批發、MVNO、漫遊等。

電信計費 - 預付費與後付費

大多數運營商為客戶提供兩種選擇，選擇後付費或預付費連線。後付費和預付費連線各有其自身的優缺點。

通常，運營商的客戶群中 70%-80% 是預付費客戶，其餘客戶來自後付費客戶。對於運營商來說，擁有更多後付費客戶總是好的。

您可能想知道這兩種型別的客戶、服務和系統之間的區別。讓我們列出兩者之間的一些主要區別：

• 服務支付 - 這是區分兩個客戶群的最重要因素。預付費客戶在使用服務之前預先付款，而後付費客戶在整個月使用提供的服務，並在月底收到賬單，並在規定的時間內付款。

• 收費與計費 - 對於預付費客戶，需要對其所有使用情況進行即時收費，而後付費客戶可以在月底收費。

• 服務產品 - 與即時計費系統相比，後付費計費系統提供了更大的靈活性。例如，即時計費系統難以維護複雜的企業客戶層次結構，而後付費計費系統可以處理多達 N 層的客戶層次結構。

• 支援與維護 - 運營商需要同樣關注兩項業務。如果對於預付費業務，運營商需要有熟練的員工來控制運營，同時運營商也需要優秀的員工來處理後付費客戶與其收費、賬單和解決運營問題相關的查詢。

• 支援的網路 - 很久以前，預付費和後付費連線的網路是不同的。這曾經引發投訴，即預付費連線比後付費連線提供更好的連線，反之亦然。這是融合計費的時代，運營商正在使用相同的網路開展業務，而不會影響通訊質量。

後付費場景

網路元素（例如交換機、簡訊中心SMSC）會產生稱為使用詳情記錄（UDR）或呼叫詳情記錄（CDR）的原始使用資料，其中包含計費系統所需的資訊：

• 主叫號碼（A號碼）

• 被叫號碼（接聽電話的號碼）（B號碼）

• 呼叫開始時間（日期和時間）

• 通話時長

• 呼叫型別（MOC、MTC等，MOC代表移動發起呼叫，MTC代表移動終止呼叫）

計費系統接收來自網路元素和其他服務提供商的上述原始UDR，並將這些UDR轉換為系統可理解的格式。然後，引導上述格式化/轉換後的UDR找到應向其收費的客戶/賬戶，並據此對事件進行計費。

然後將上述計費後的UDR儲存在計費資料儲存中，在計費週期日期，計費流程提取這些計費後的UDR並進行處理，生成賬單/發票，同時考慮付款、稅費、折扣等。

然後客戶支付賬單，計費系統會更新付款詳情。以下是顯示上述標準計費流程的圖表：

預付費場景

預付費計費涉及的步驟簡述如下：

• 當客戶撥打電話時，預付費交換閘道器捕獲主叫號碼並將賬戶資訊傳送到即時計費系統。

• 即時計費系統使用上述資訊，驗證使用者的身份，使用計費資費表和允許的最大通話時長計算客戶賬戶的剩餘餘額，並將此資訊傳送到預付費閘道器。

• 閘道器建立呼叫。

• 在通話期間，閘道器監控通話，以確保使用者不會超過允許的最大通話時長。

• 通話結束後，閘道器將實際通話時長髮送到預付費計費系統，然後該系統計算實際通話費用並更新賬戶餘額，減少剩餘餘額。

下圖顯示了通用的預付費計費場景：

預付費計費流程包括以下重要步驟，以及通話結束後收集賬戶資訊和更新賬戶：

• 身份驗證 - 身份驗證是驗證使用者身份的過程。使用者提供使用者ID和身份驗證憑據，例如密碼。系統接受這些輸入並驗證使用者是否有效以及是否具有訪問系統的許可權。

• 授權 - 授權是驗證已驗證使用者被允許執行的操作的過程。通常，使用遠端訪問撥入使用者伺服器 (RADIUS) 協議將對系統的訪問許可權限制為已註冊和授權的客戶。

• 提供收費建議 (AOC) - 這提供了關於呼叫實際成本的資訊，可在事件之前或之後提供。AOC 提供了電信系統在事件發生之前或之後告知事件實際成本的能力。

電信零售計費

當我們談論電信計費時，預設情況下是指零售計費。如前所述，電信零售計費定義如下：

“電信計費是收集使用情況、彙總使用情況、應用所需的使用費和租金費用，最終為客戶生成發票的過程。電信計費流程還包括接收和記錄客戶的付款。”

零售計費直接與最終客戶打交道，並面臨諸多挑戰，以滿足最終客戶的期望和監管義務。只要計費滿足以下條件，就可以認為計費成功：

• 及時計費 - 最終客戶的發票按時生成，即名義日期。由於某些物流問題，最終客戶可能有時無法按時收到發票，但這並不影響IT部門按時生成所有應付賬款的責任。

• 計費準確性 - 這是客戶滿意度和監管義務方面最重要的因素。如果計費系統沒有生成準確的賬單，則可能導致嚴重的業務問題（從合法性角度來看），並使客戶處於不滿意的狀態。

零售計費與批發計費

零售計費直接面向最終客戶，對單個客戶計費，而批發計費則根據業務情況和性質，對以下實體計費：

• 對與電信運營商相關的經銷商計費。

• 對互聯合作夥伴計費，為與其他運營商的客戶通話提供互聯。

• 對漫遊合作伙伴計費，為其客戶在其運營商覆蓋區域漫遊時提供服務。

與零售計費相比，批發計費比較容易，容忍度也比較高，而零售計費總是需要100%的準確性。由於各種原因，批發計費不可能100%準確，例如兩個運營商系統中配置的價格差異或計費呼叫數量的差異，因為某些呼叫可能會在任何網路元素中丟失。

有一些專門的計費系統用於處理零售計費，例如Convergys和Amdocs計費系統以零售計費而聞名，而ASCADE和INTEC計費系統則以批發計費而聞名。

批發計費也可以透過使用簡單的報表在零售計費系統中結算，因為它們不涉及太多的折扣和促銷型別，而零售計費需要所有這些複雜的因素，並且不能使用批發計費系統進行處理。

本教程中到目前為止討論的所有概念都與零售計費有關，後續章節將討論互聯計費、漫遊計費和其他計費型別。

電信互聯計費

互聯是處理其他服務提供商呼叫的過程。這允許一個服務提供商的客戶與另一個服務提供商的客戶進行通訊。

如果兩個運營商A和B不是互聯合作夥伴，那麼運營商A的客戶將無法與運營商B的客戶進行通訊。

通常，運營商之間會簽訂協議，以允許其客戶相互通訊。這為參與互聯的所有運營商帶來了良好的商機。雙方同意連線各自網路的任何互聯點稱為“互聯點”。

互聯的示例包括：

• 兩個相鄰的非競爭性電話網路互聯，以便一個網路上的使用者可以呼叫另一個網路上的使用者。

• 長途運營商獲得對本地服務提供商設施的訪問許可權，並在向共同客戶群提供長途服務方面與該提供商競爭。

• 傳統的固定電話和新的無線移動運營商互聯，以便傳統電話服務的訂戶可以呼叫無線訂戶，反之亦然。

• 新的競爭性本地電話運營商與現任運營商互聯，以便它們可以在共同服務區域吸引訂戶，並使這些訂戶能夠呼叫現任運營商網路上的訂戶。

• 現任電話運營商的客戶撥打其撥號上網服務提供商的電話，而撥號上網服務提供商反過來又是競爭性本地運營商的客戶。

互聯開票

這是生成發票以傳送給與傳入互聯呼叫詳情記錄 (CDR) 相關的互聯合作夥伴的過程。

互聯計費涉及計算應向我們的基礎設施連線的每個網路運營商支付和收取的金額，以便成功發起和終止呼叫。互聯呼叫的 CDR 將呼叫路由資訊保留為一組有效值，以識別運營商和國家/地區詳細資訊。

請注意，互聯 CDR 集包括以下詳細資訊：

• 可向零售和批發客戶收費的 CDR。它是電信提供商的收入。也稱為本地計費。

• 僅可向互聯提供商收費的 CDR。例如：外撥電話、外撥中轉電話、來電等。外撥電話是電信提供商的支出，來電是電信提供商的收入。

互聯計費系統對所有傳入和傳出互聯 CDR 進行定價。通常，根據承載呼叫的傳入或傳出中繼互聯路由，為傳入和傳出互聯 CDR 確定互聯價格。最常見的是，中繼 ID 代表互聯計費系統中的唯一互聯合作夥伴。

結算流程

結算流程將用於結算參與從互聯所有者到其他網路運營商目的地或反向承載呼叫的網路運營商/運營商。

該流程將帶來用於結算的傳出流量（互聯所有者的支出）和傳入流量（互聯所有者的收入）。

結算可以每月或每兩週進行一次，可以使用手動或自動流程。它取決於計費系統如何支援合作伙伴的結算。

淨額結算流程

淨額結算用於在為商定的提供商/運營商完成結算後執行。淨額結算針對多個結算期間的多種服務進行，它支援運營商級別的相同貨幣。

有兩種淨額結算方法：

• AFTER - 對運營商的互聯成本進行淨額結算，在運營商和提供商/運營商之間扣除金額後。

• BEFORE - 對運營商的互聯成本進行淨額結算，無需在運營商和提供商/運營商之間扣除任何金額。

對賬流程

這是對來自與傳出 CDR 相關的互聯合作夥伴的發票進行對賬的過程。

每月，互聯合作夥伴都會交換他們的 CDR 以進行對賬。兩個合作伙伴提供的 CDR 中存在差異是很常見的。

計費系統提供有助於對傳入和傳出互聯 CDR 進行對賬的報表。這些報表保留諸如呼叫型別、目的地、成本範圍和持續時間等引數，以便這兩個運營商都可以使用這些 CDR 來匹配這些引數並識別缺失的 CDR。

可能存在這種情況，即在任一運營商方面都發現某些 CDR 丟失。如果經過必要的對賬後問題仍未解決，則合作伙伴之間會進行各種談判，最終透過向受影響的互聯合作夥伴支付少量金額來解決問題。

互聯呼叫場景

根據不同運營商之間的協議型別，可能存在各種互聯呼叫場景。讓我們嘗試涵蓋一些最常用的場景：

• 運營商 A 的客戶向運營商 B 的客戶撥打國內電話。在這種情況下，運營商 A 將向運營商 B 支付一定金額。

• 運營商 A 的客戶透過運營商 B 撥打國際電話，因為運營商 A 與任何國際運營商都沒有直接協議。在這種情況下，運營商 A 將向運營商 B 支付一定金額，運營商 B 將負責與國際運營商結算。

• 運營商 A 的客戶直接使用國際運營商撥打國際電話。在這種情況下，運營商 A 將直接向國際運營商支付一定金額。

以上所有呼叫都可能是語音、簡訊、彩信和資料等。

互聯協議

為了實現成功的互聯，互聯協議或監管機構的規則或命令應處理以下問題：

• 價格和調整 - 這包括互聯費用的初始水平，互聯費用支付的貨幣定義以及價格如何在協議期限內調整以考慮匯率變化和通貨膨脹。

• 互聯點 - 定義了互聯發生的地點以及互聯中使用的技術標準。

• 傳輸和流量路由 - 必須對如何路由呼叫以及傳輸什麼來傳遞呼叫進行一些定義。

• 服務質量 − 定義了質量標準，特別是電路準備時間和呼叫阻塞率，並規定了未達到這些標準時的補救措施。

• 計費和收款 − 應明確說明何時以及如何收集流量資料、何時以及如何交換賬單以及何時以及如何付款。

• 對賬 − 應納入對賬流量資料、向對方查詢和處理索賠的流程。解決差異的程式非常有用，這通常涉及尋求仲裁、監管機構或法院的救濟。

• 號碼計劃 − 必須定義每個運營商訪問國家號碼計劃和號碼資源的許可權。

• 流量負載 − 應討論和記錄互連網路之間流量的傳輸和接收能力。

協議型別

運營商可以簽訂不同型別的協議來交換流量。最常用的協議列在下面 −

• 雙邊協議 − 根據此協議，各方同意透過其網路在互連點和/或一個或多個直接互連處與對方交換數字通訊流量。根據協議，不同合作伙伴之間的結算按月或雙月進行。根據此協議，兩家運營商都可以在對方的網路中發起和終止呼叫。

• 單邊協議 − 根據此協議，一方將其流量傳送到對方的網路互連點，而不從對方接收流量。根據協議，不同合作伙伴之間的結算按月或雙月進行。

電信-漫遊計費

漫遊是指行動通訊客戶能夠在離開其家庭網路地理覆蓋區旅行時，透過使用另一運營商的網路自動撥打和接聽電話、傳送和接收資料或訪問其他服務的能力。

漫遊可以是國內漫遊或國際漫遊。國內漫遊是指移動使用者在其運營商沒有覆蓋的地理區域使用另一個網路。例如，這被那些在全國沒有完全覆蓋的運營商使用。國際漫遊是指移動使用者出國旅行並使用外國運營商的網路時使用。

它實際上是如何進行的？如果服務提供商在一個特定城市或國家沒有網路覆蓋，那麼該服務提供商會與在該城市或國家擁有網路的另一服務提供商簽訂漫遊協議。根據該協議，另一服務提供商向第一服務提供商的漫遊客戶提供所有可用服務。

在一個漫遊合作伙伴區域生成的CDR由該漫遊合作伙伴收集和計費，最後傳送給漫遊客戶的實際服務提供商。實際服務提供商根據其預定義的服務費向最終客戶收取所有漫遊服務費用。

兩個漫遊合作伙伴透過交換實際漫遊CDR和基於這些CDR的報告，每月結算其財務。

HPMN和VPMN

歸屬公共行動網路 (HPMN) 是移動使用者擁有訂閱的運營商的網路。該術語與訪問公共行動網路 (VPMN) 相對使用。

訪問公共行動網路 (VPMN) 是移動使用者漫遊時使用的網路。該術語與歸屬公共行動網路 (HPMN) 相對使用。

清算中心

有一些著名的機構，例如MACH，它們在不同的漫遊合作伙伴之間進行介面，以幫助他們交換CDR、建立漫遊協議和解決任何爭議。

清算中心從一個漫遊合作伙伴處接收入網漫遊使用者的計費記錄，並向另一個漫遊合作伙伴提交計費記錄，對於該漫遊使用者將被稱為出網漫遊使用者。

什麼是TAP3？

轉賬賬戶程式版本3 (TAP3) 是允許訪問網路運營商 (VPMN) 向其各自的歸屬網路運營商 (HPMN) 傳送漫遊使用者的計費記錄的流程。TAP3 是該標準的最新版本，它將支援網路打算為其客戶提供的許多新服務。

清算中心使用TAP3協議在不同的漫遊合作伙伴之間交換所有CDR。TAP3 定義了必須在網路運營商之間傳遞哪些漫遊使用資訊以及如何傳遞。這些檔案使用簡單的FTP連線進行交換。

TAP 有不同的版本。TAP 從 TAP1 演變到 TAP2 和 TAP2+，再到 TAP3。最新的版本 TAP3 包括對衛星網路、WLAN 和 UMTS 及其他 3G 技術中標準間漫遊的支援。

• GSM TAP 標準 TD.57 − GSM 轉賬賬戶程式 (TAP) 定義了在不同國家/地區的移動運營商之間傳輸漫遊使用資訊的格式和驗證規則。TAP3 是該標準的第三個規範版本。傳輸的檔案稱為 TAP 檔案。

• GSM RAP 標準 TD.32 − GSM 返回賬戶程式 (RAP) 定義了返回在傳輸的 TAP 檔案/事件中發現的錯誤資訊的格式，從而拒絕這些檔案/事件的財務責任。傳輸的檔案稱為 RAP 檔案。

漫遊計費

移動使用者前往另一個國家並在外國網路上產生使用情況。為了向用戶計費，必須將此資訊傳遞迴使用者的家庭網路。外國網路將從其交換機等處收集使用情況資訊，然後建立包含標準中規定的資訊的 TAP 檔案。

然後，這些檔案將定期（通常每天至少一個檔案）匯出到家庭運營商，家庭運營商將匯入這些檔案，然後使用這些資訊向用戶開具發票。外國運營商將對呼叫進行計費，然後向用戶的家庭網路收取檔案內所有呼叫的費用。家庭運營商可以提高或重新計費呼叫以獲得收入。

電信 MVNO 計費

什麼是 MVNO？

MVNO 代表移動虛擬網路運營商。移動虛擬網路運營商 (MVNO) 是一家提供行動電話服務的公司，但它沒有自己的無線電頻譜許可分配，也不一定擁有提供行動電話服務所需的所有基礎設施。

MVNE 代表移動虛擬網路使能器，它是一家為移動虛擬網路運營商提供服務的公司，例如計費、網路單元配置、管理、運營、基站子系統和運營支援系統的支援以及後端網路元素的配置，以實現蜂窩電話連線等行動網路服務的提供。

實際上，MVNO 是實際運營商的移動產品和服務的轉售商，但使用不同的品牌。

例如，運營商 A 擁有所有基礎設施，包括網路、交換機、計費系統、配置系統和客戶服務系統等。現在，如果有人想透過少量投資啟動電信業務，那麼 MVNO 是可行的選擇。

MVNO 將批次從成熟的運營商處購買服務，並根據其方便更改品牌名稱，並將這些產品和服務作為運營商進行銷售。實際運營商將對最終客戶保持透明，客戶會有自己是 MVNO 的最終客戶的感覺。

根據具體情況，MVNO 可以從運營商處購買一個或多個基礎設施元件，並相應地支付費用。例如，MVNO 可能只想使用運營商的網路，或者 MVNO 可以使用運營商的網路和計費系統，而 MVNO 可以自行設定其餘元件，例如客戶服務、配置等。

MVNO 完全控制 SIM 卡、品牌、營銷、計費和客戶服務運營。

英國首家商業上成功的 MVNO 是 Virgin Mobile UK [3]，於 1999 年在英國推出，目前在英國擁有超過 400 萬用戶。

MVNO 服務

MVNO 通常沒有自己的基礎設施，但一些領先的 MVNO 部署了自己的移動 IN 基礎設施，以便提供提供增值服務的手段。MNVO 可以將現有的基礎設施（如無線電裝置）視為商品，而 MVNO 提供基於其自身智慧網路基礎設施的利用的先進和差異化服務。

這樣，每個 MVNO 和網路運營商都可以專注於自己的細分市場，並形成定製的詳細服務，從而擴大其客戶範圍和品牌。

大多數 MVNO 進入市場是為了只針對預付費客戶，並向他們提供語音、簡訊、彩信、資料、寬頻等預付費服務，以及一些不錯的增值服務。

MVNO 計費

假設現有的運營商將其基礎設施出售給 MVNO，那麼現有運營商和 MVNO 之間可能存在不同的商業模式和協議。以下是最常用的 −

• MVNO 可以為其服務貼上品牌並將其銷售到市場，而 MVNE 將幫助向最終客戶提供這些服務。在這裡，固定百分比的佣金將支付給 MVNE。

• MVNO 可以批次以特價購買產品和服務，然後用自己的名稱為其貼上品牌並在市場上銷售。

• MVNO 銷售產品和服務，並根據最終客戶產生的使用情況，MVNO 向 MVNE 付款。

在所有情況下，MVNO 可能需要向 MVNE 支付一定數額的保證金，然後使用 MVNE 生成的簡單報告進行每月結算。

只要 MVNO 提供後付費服務，MVNE 就可以在其計費系統中新增 MVNO 作為公司客戶，並且可以新增提供給 MVNO 的所有產品和服務。每月結束或通常每兩週後，可以生成發票並進行催收。

但是通常，大多數虛擬行動網路運營商（MVNO）提供預付費服務，這些服務由預付費系統處理。在這種情況下，MVNO 功能是透過使用預付費系統中的內建功能實現的，或者僅僅是定義一個單獨的服務類別。所有使用 CDR 和其他資訊都從資料倉庫中轉儲，從中可以生成報告以準備發票。

電信融合計費

什麼是融合計費？

假設一個運營商提供不同的服務，例如移動語音、固定語音、資料、IPTV、寬頻、預付費和後付費等。客戶可以從同一個運營商處獲得一項或多項這些服務。一個典型的客戶肯定希望擁有單一的發票和單一的賬戶檢視。

融合計費是指將所有服務費用整合到一張客戶發票上，並統一顯示客戶資訊。客戶應該撥打呼叫中心，並獲得所有已選擇服務帳戶的完整資訊。客戶收到一張單一賬單，併為所有服務支付單筆款項。

真正的融合計費系統應該能夠將任意數量和組合的產品和服務整合到一張賬單上，無論產品型別和市場細分如何，即預付費和後付費服務。

另一個有助於融合計費的重要引數是為預付費和後付費客戶提供單一的產品和價格目錄。

融合計費的優勢

融合計費將幫助運營商實現以下主要優勢：

• 單一的產品和服務目錄縮短了上市時間並降低了實施成本。

• 統一的賬單支援跨服務折扣，以便訂購多種服務的客戶可以享受優惠價格。

• 融合計費支援多服務打包和定價，從而吸引現有客戶新增新服務，並透過創新的服務捆綁吸引新客戶。

• 對兩種型別的客戶（預付費和後付費）提供集中化的客戶關懷和支援。

主要瓶頸

到目前為止，實現真正的融合一直是所有大型電信運營商的夢想。也許明天會出現一些支援所有產品和服務真正融合的計費系統，但今天要實現真正的融合，面臨著以下障礙：

• 愛立信 IN 或諾基亞西門子計費系統等即時計費系統是提供預付費產品和服務解決方案的非常流行的系統。這些系統不夠靈活，無法處理後付費客戶所需的一些功能，例如：複雜的客戶層級、CDR 重新計費、批次折扣、靈活的報表、漫遊計費、互聯計費等。

• Convergys Infinys 或 Amdocs 計費系統等後付費計費系統非常適合後付費產品和服務。這些系統無法處理預付費流量並即時計費。重要的是，由於其基礎架構的原因，這些系統無法實現高可用性。

結合上述兩個約束，如果我們透過在預付費和後付費系統之間進行某種介面來合併這兩個系統，那麼就有可能實現真正的融合。Convergys 和愛立信等公司正朝著同樣的方向努力，以合併這兩個系統，並使用兩種系統所需的各項功能，並將它們製成單一的融合計費系統。

電信計費 - 支援與維護

支援和維護是電信運營中不可或缺且最重要的部分。客戶滿意度直接取決於為他們提供的支援效率和質量。如果客戶被置於迴圈之中，並且沒有得到對其提出的問題/問題的良好回應，那麼客戶就會簡單地轉向另一個可用的運營商。

支援和維護涵蓋以下主要領域：

• 系統支援和維護 - 這包括保持 BSS（業務支撐系統）和 OSS（運營支撐系統）良好執行。如果任何系統（計費、供應、網路、中介、客戶關懷等）出現任何問題，則由專家負責檢查並在最短時間內修復。

• 客戶支援 - 這包括解決與客戶相關的所有問題。客戶透過客戶關懷或呼叫中心投訴，然後問題會流轉到不同的階段。此問題可能與訊號、通話中斷、語音或資料下載質量、賬單錯誤、某些爭議、服務啟用或終止等有關。

• 系統升級 - 這包括使用最新版本升級現有系統，以提高業務的穩定性和靈活性。任何系統的最新版本都帶有滿足新業務需求的新功能。這也包括硬體升級，以保持系統性能和更多儲存空間。

支援級別

服務提供商始終設定不同的支援級別。這些級別根據其性質和嚴重性處理不同型別的問題。最常用的支援級別如下：

• 一級 - 客戶聯絡客戶支援（可能是呼叫中心），客戶支援專家會聽取客戶的問題並當場提出解決方案。例如，可能存在一些問題，只需重新啟動電話即可解決。因此，高效的客戶服務專家瞭解此類問題，可以在不將問題（通常稱為故障單）升級到下一級的情況下提出解決方案。

• 二級 - 如果客戶服務專家無法解決問題，則問題將升級到二級支援，這是一個技術專家組。這些專家屬於資訊科技 (IT) 部門，如果他們能夠理解問題，他們就可以提出解決方案並將問題發回一級，否則他們會檢查問題的性質，以瞭解問題是否與網路、計費系統、供應系統或硬體等相關，並根據問題的性質，問題將分配到下一級，即部門。

• 三級 - 這些是專門從事其領域的不同部門，例如核心工程、無線規劃、計費、供應、訂單管理等。如果問題升級到他們那裡，他們會分析問題並嘗試找出問題的根本原因。大多數情況下，問題將由三級支援診斷和修復，因為他們是各自領域的高技能工程師。可能存在三級支援無法修復問題的情況，因為它可能與系統核心功能相關，三級支援無法修改。在這種情況下，問題將進一步升級到四級支援。

• 四級 - 這些是支援業務的系統的實際供應商，例如計費系統、網路交換機、供應系統等。因此，如果發現問題與計費系統的核心功能相關，例如計費系統無法應用正確的折扣，則將其升級到計費系統供應商；如果問題與供應系統的核心功能相關，則將其升級到供應系統供應商。

服務等級協議 (SLA)

支援部門始終使用預定義的服務等級協議（SLA）工作。這些 SLA 的定義和實施考慮了各種引數。例如：

• 問題的嚴重性或運營任務。

• 問題或運營任務的業務影響。

• 問題或運營任務是否影響單個客戶或多個客戶。

• 問題或運營任務是否直接與收入損失或客戶滿意度有關。

基於此類引數，為不同的問題或運營任務定義和分配不同的優先順序。運營任務可能是報表生成、發票生成、資料庫清理活動或備份活動。

最後，每個問題和運營任務都帶有一個分配的優先順序，每個優先順序都將具有相關的 SLA。例如，如果建立客戶訂單出現問題，則將其視為高優先順序問題，因為它會直接影響業務。此類問題需要由指定的部門儘快解決。因此，為高優先順序問題定義了非常嚴格的 SLA。

SLA 是在雙方協商一致的基礎上制定的，將業務需求放在首位。通常，SLA 包含以下資訊：

• 用於限定問題性質的引數，即它是優先順序 1、2、3 或 4 問題。優先順序數字越低，問題的嚴重性越高。

• 對於給定的優先順序和嚴重性型別，解決問題需要多長時間。

• 如果 SLA 失敗，將應用什麼處罰。

• 每個支援級別的升級聯絡人。

• 問題解決過程中的流程和溝通媒介。

• 影響問題解決的基礎設施可用性和其他約束。

SLA 可以定義在不同部門之間、供應商和運營商之間，以及在互連情況下不同的運營商之間。

電信計費 - 系統介面

下圖顯示了計費系統的典型架構。本章將簡要介紹從上到下所有介面系統。

CRM/OMOF 系統

這是第一個捕獲客戶訂單並將客戶建立到系統中的系統。CRM 代表客戶關係管理，OMOF 代表訂單管理和訂單履行。

有些系統，例如 Siebel，提供 CRM 和 OMOF 模組。CRM 系統保留與客戶相關的產品和服務資訊。OMOF 模組負責跟蹤訂單從建立到完成的全過程。

這裡，我們有兩種可能性：

• CRM（客戶關係管理）/OMOF（訂單管理和訂單履行）系統與計費系統聯絡，計費系統與供應系統聯絡以供應服務和網路庫存系統，以分配電話號碼或IP地址等。

• 第二種可能性是 CRM/OMOF 系統本身聯絡供應系統來供應服務，以及網路資源系統來分配電話號碼或 IP 地址等。

供應系統

此係統接受來自計費系統或 CRM/OMOF 系統的命令，以啟用、停用和暫停服務。這兩種架構都是有效的，並且取決於架構師如何設計整個設定。

在接受供應命令後，此係統會聯絡核心網路系統以啟用、停用或暫停服務。供應成功後，此係統會將響應傳送回計費系統或 CRM 系統，具體取決於誰傳送了最後一條命令。

網路資源系統 (NIS)

此係統維護所有網路識別符號，例如電話號碼、MSISDN、IP 地址、電子郵件地址等，技術上稱為網路資源系統。

根據系統架構，CRM/OMOF 或計費系統會聯絡 NIS 以獲取所需的網路識別符號，並在建立訂單時將其分配給客戶。

此係統負責維護網路識別符號的生命週期，該生命週期從可用狀態開始，然後流經不同的階段，例如啟用、暫停、終止、隔離，然後再次可用。

網路交換機

通常，計費系統不與網路交換機互動。網路交換機負責根據為客戶提供的服務向最終客戶提供所有服務。這些系統負責控制呼叫、資料下載、SMS 傳輸等，並最終生成呼叫詳單記錄。

網路交換機包括MSC、SMSC、GGSN和MMSC。有關GSM、MSC、SMS、SMSC、GGSN、MMS、MMSC的更多資訊，請參考我們的GSM教程。

中介系統

中介系統以不同的格式從不同的網路元素收集 CDR。各種網路元素以 ASN.1 格式生成 CDR，而某些網路元素則具有其自身的專有 CDR 格式。

中介系統處理所有CDR（呼叫詳單），並將它們轉換為與下游系統（通常是計費系統）相容的格式。中介系統對CDR應用各種規則進行處理；例如，中介系統根據撥打的號碼（B號碼）標記國際電話，同樣，中介系統根據A號碼和B號碼標記網內電話。

可能需要過濾掉所有通話時長少於5秒的呼叫，過濾此類呼叫的最佳位置是在中介系統級別。同樣，如果CDR中需要一些對計費至關重要的額外資訊，則中介系統將根據CDR中其他可用屬性提供此類資訊。

收集到的 CDR 處理完畢後，中介系統使用 FTP 將所有 CDR 推送到計費系統，因為中介系統和計費系統通常執行在不同的機器上。

資料倉庫 (DWH) 系統

這是計費系統的下游系統，通常儲存大量與客戶相關的歷史資料。計費系統將各種客戶資訊轉儲到DWH系統中。這些資訊包括服務使用情況、發票、付款、折扣和調整等。

所有這些資訊都用於生成各種型別的管理報告以及用於商業智慧和預測。

DWH系統始終旨在處理批次和海量資料，如果需要任何小型報告，則始終值得直接從計費系統生成它，而不是為了小型任務而濫用DWH。

企業資源規劃 (ERP)

企業資源規劃 (ERP) 系統提供模組來處理財務、人力資源和供應鏈管理等。

計費系統與該系統的介面用於過賬所有財務交易，例如發票、付款和調整。

該系統就像財務部門的總賬，可以在任何需要的時候提供完整的收入資訊。

支付閘道器

它本身不一定是完整的系統，但它可以是一種自定義元件，位於計費系統和不同的支付渠道（如銀行、信用卡閘道器、商店和零售商等）之間。

所有支付渠道都使用支付閘道器將付款傳送到計費系統以結算客戶發票。

通常，支付閘道器向外部世界公開一種API（應用程式程式設計介面）來將付款傳送到計費系統。任何外部資源都可以使用該API來過賬付款。