基于VoLTE的多媒體彩鈴業務的設計與實現*

喬木, 王晶

（1 北京郵電大學網絡與交換技術國家重點實驗室，北京 100876；2 東信北郵信息技術有限公司，北京 100191)

1 引言

隨著移動互聯網產業的高速發展和智能終端功能的不斷強大，移動通信網絡承載更高速、更豐富、更便捷分組數據業務能力的要求越來越強烈。移動通信網絡正從2G、3G向4G時代演進，LTE（Long Term Evolution，長期演進）以其高速、寬帶、低時延等特性，被作為4G時代的移動通信制式。目前LTE下的話音解決方案有多模雙待、CSFB（Circuit Switched FallBack，電路域回落）以及VoLTE（Voice over LTE），其中VoLTE是業界公認的LTE網絡下的目標話音解決方案。

彩鈴業務是一項由被叫用戶定制，為主叫用戶提供一段悅耳的音樂或一句問候語來替代普通回鈴音的業務。其作為傳統的電信增值業務，市場滲透率和覆蓋率已經非常高，2G、3G技術也相對成熟，彩鈴業務一直以來也是運營商增值業務收入的主要來源之一。因此，實現彩鈴業務在4G網絡下平滑演進是至關重要的。此外，基于VoLTE場景下的多媒體彩鈴業務，音質將有很大的提升，甚至可以支持高清音頻、視頻播放，顯著提高了用戶體驗的滿意度。VoLTE的發展，將給彩鈴基于“黃金15 s”的富媒體業務帶來新的生機。

2 業務背景

VoLTE是基于IMS網絡的話音解決方案，其將LTE網絡作為話音的接入承載，通過IMS網絡為話音呼叫提供信令控制和話務路由。由于彩鈴平臺位于IMS域，處于較高的業務層面，信令和媒體承載嚴格分離，當同一無線網絡下大量用戶同時發起呼叫時，此時會出現無線鏈路上資源不足問題，進而出現信令平面接通的情況下，媒體平面上連接失敗的現象，最終導致主被叫之間無法進行話音交互，這將嚴重影響用戶體驗。因此設計出一種具有QoS保障的VoLTE彩鈴實現方案是至關重要的。

本文所討論的是VoLTE場景下具有資源預留機制的彩鈴實現方案。建立媒體傳輸通道的過程叫做資源預留，方案實現的原則是：在被叫摘機之前，通過特殊的資源預留信令結合QoS設置，在空中接口預留住本次通話的媒體資源，從而保證用戶的通話質量。

方案將整個會話過程分為播放彩鈴和用戶通話兩個階段，每個階段均采用SDP（Session Description Protocol, 會話描述協議）提議/應答（offer/answer）機制，進行主被叫媒體協商，通過媒體協商，主被叫雙方就本次通話的媒體類型和編解碼方案達成一致。同時，為了實現QoS保證，方案采用資源預留機制，在通話之前，主被叫分別預留出本次通話的空中接口資源，以期保證媒體會話成功建立。

3 技術實現

3.1 VoLTE系統組網

VoLTE為標準LTE話音解決方案，它采用IMS 系統作為業務控制層，采用EPC （Evolved Packet Core）作為承載層。EPC網絡不具備話音和多媒體業務的呼叫控制功能，因此VoLTE借助IMS網絡，實現呼叫控制和話務路由。

VoLTE網絡主要分為以下3個部分：無線接入側Access，EPC核心網側以及控制側Control[1]，系統架構如圖1所示。

（1） 無線接入側主要由eNode B組成，eNode B具有3G網絡中Node B功能和大部分RNC（Radio Network Controller）功能。

（2） EPC核心網主要由MME（Mobility Management Entity）、S-GW（Serving Gateway）、P-GW（PDN Gateway）3個實體組成：

MME：移動性管理實體，它是原3G網絡中的SGSN網元演進而來的，主要負責EPC核心控制功能。

S-GW：服務網關，它提供用戶面功能，負責數據分組路由和轉發，并支持終端移動性切換用戶數據功能。

P-GW：分組數據網關，它主要負責終端和外部分組數據網絡的數據傳輸。

（3） 控 制 側 網 絡 主 要 由IMS、HSS（Home Subscriber Server） 和PCRF（Policy and Charging Rules Function）組成[2]。

HSS： 負責存儲IMS 用戶的相關信息及其相關業務信息。

PCRF：主要與IMS系統接入節點P-CSCF互通，負責檢查、控制應用側所需的媒體資源的分配。

IMS：IMS包含多種AS（Application Server)，其中包括VoLTE彩鈴AS。

含有VoLTE彩鈴平臺的拓撲結構如圖2所示。

圖1 VoLTE系統架構

圖2 包含彩鈴AS的VoLTE組網架構

3.2 彩鈴業務平臺設計

VoLTE彩鈴平臺屬于IMS網元中的一個AS，位于IMS業務層之上。其按功能邏輯可分為6大部分，如圖3所示，分別為SIP前臺，AS，MS，鈴音資源服務器，數據庫，Portal。在實際組網中，這些邏輯部分可以實現在一個或多個物理實體上，多個SIP前臺與多個AS之間以及多個AS與多個MS之間可以交叉相連[3]。各功能實體的描述如下：

（1） SIP前臺：負責對外來SIP信令以及外出SIP信令進行控制和管理，負責超時重發SIP消息以及攔截重發消息。

（2） AS：負責呼叫過程中IMS域彩鈴業務控制，通過SIP前臺與S-CSCF交互。AS與S-CSCF交互以實現對業務的呼叫控制，并執行彩鈴的業務邏輯。

（3） MS：MS根據AS的指示與主叫進行媒體協商，并根據媒體協商結果播放被叫定制的鈴音。MS與主叫之間直接通過IP網絡傳送多媒體流，采用的協議為RTP（Real-time Transport Protocol, 實時傳輸協議）。

（4） 鈴音資源服務器：其負責存儲媒體文件，并通過NFS/TFTP協議接收MS的請求并將媒體文件傳送給MS。

（5） Portal：Portal是VoLTE彩鈴的門戶網站，VoLTE彩鈴用戶可以使用WWW瀏覽器通過Web接口登錄門戶網站，訂制并設置彩鈴的播放規則。比如用戶可以新建群組，并且給該群組設置指定鈴音，針對不同用戶以及不同的時間段設置個性化鈴音等。

（6） DB（Data Base）：用戶信息數據庫，負責存儲用戶業務數據，其余網元通過數據庫訪問接口可以訪問用戶信息數據庫。

3.3 信令流程

圖3 VoLTE彩鈴平臺系統結構

VoLTE彩鈴為被叫側業務，當主叫IMS域發起的INVITE消息送至被叫IMS域S-CSCF后，被叫S-CSCF通過用戶的IFC（Initial Filter Criteria）簽約信息，觸發到彩鈴平臺，彩鈴平臺進行主被叫的資源預留過程，為主叫播放高清彩鈴。當被叫接聽后，彩鈴平臺需要作為B2BUA角色通過SIP信令將被叫和主叫的通話媒體做端到端的協商，這里會出現主叫終端在播放彩鈴后改變本地媒體端口的情況，本流程考慮此情況，設計出一種能夠保證主被叫在通話階段更新主被叫媒體信息的方案，從而保證主被叫的通話暢通。具體流程如圖4所示。

VoLTE彩鈴信令流程描述如下：

步驟1～6：主叫發出初始INVITE，被叫IMS域的彩鈴AS收到INVITE消息，彩鈴AS透傳主被叫消息，完成主被叫資源預留；

步驟7～8：被叫返回180，到達被叫歸屬域彩鈴AS；

步驟9!12：彩鈴AS向主叫域update彩鈴的SDP（其中current status的local為sendrecv，remote為none，攜帶conf要求），主叫根據自身狀態回復200 update（攜帶SDP，其current status的local為none，remote為sendrecv），后續待主叫資源預留成功后，發送update（攜帶SDP，其current status的local為sendrecv，remote為sendrecv），彩鈴AS回復200 udpate（攜帶彩鈴SDP，其current status的local為sendrecv，remote為sendrecv）；

注：主叫可能根據自身狀態，在步驟10的SDP中將local標識為sendrecv，此時后續無步驟11、12；

步驟13：彩鈴AS在確認主叫的資源預留完成后，向主叫播放彩鈴，并轉發180消息；

圖4 VoLTE彩鈴信令流程圖

步驟14～15：被叫UE摘機回復200 OK，經被叫TAS、I/S-CSCF傳遞到彩鈴AS，彩鈴AS停止彩鈴播放；

步驟16：彩鈴AS向主叫UE發送Update，攜帶步驟6中收到B用戶SDP，其中local標識為sendrecv，攜帶conf要求；

若主叫媒體、端口不變化，則進行以下步驟，

步驟17～19：主叫側回復200 Update（攜帶SDP，其中local標識為none。注：若local標識為sendrecv，則無步驟18、19），后續主叫資源預留成功，發起update（攜帶SDP，其中local標 識 為sendrecv）。彩 鈴AS比對步驟5、18（若無18步，則選步驟17）中的SDP的媒體能力、端口無變化。向主叫回復200 Update（攜帶步驟6中收到B用戶SDP，local為sendrecv，remote為sendrecv）；

步驟20～21：彩鈴AS向主叫發送初始invite的200 OK，并轉發主叫的Ack至被叫，完成主被叫的通話協商。

若主叫媒體、端口發生變化，則進行以下步驟：

步驟17～30：主叫側回復200 Update（攜帶SDP，其中local標識為none。注：若local標識為sendrecv，則無步驟18、28），后續主叫資源預留成功，發起Update（攜帶SDP，其中local標識為sendrecv）。彩鈴AS比對步驟5、18（若無18步，則選步驟17）中的SDP的媒體能力、端口有變化。彩鈴AS向被叫發送Ack。通過Update機制向被叫更新主叫側媒體、端口變化，完成被叫側資源預留。彩鈴AS將被叫側完成資源預留的SDP通過200 Update（若無28步，則通過Update機制向主叫側同步信息)更新至主叫側。彩鈴AS向主叫側回復針對初始INVITE的200 OK，主叫回復Ack至彩鈴AS。主被叫進行通話。

3.4 資源預留機制

由于VoLTE是基于IMS提供話音業務的，所以主被叫之間的會話建立是通過SIP信令協商的，而 SIP本身不支持媒體協商，因此本方案采用在SIP消息中攜帶SDP描述來達到媒體協商目的。方案利用媒體協商和資源預留機制，在呼叫建立之前，在主被叫側分別完成資源預留。

本節將闡述如何實現資源預留（precondition）機制[4]。如圖5所示，A表示主叫用戶，B表示被叫用戶。首先A發起初始INVITE請求，該請求將攜帶表示主被叫均沒有完成資源預留的預置信息。此信息將通知被叫B，告知B：在雙方均沒有完成資源預留前，B不能振鈴。此時B返回183消息表示同意A的請求，此時B開始資源預留。A收到B的回復也開始資源預留。此過程中，如果B先完成資源預留，B仍不能振鈴，因為根據之前的協商必須保證雙方都已資源預留成功，才能夠振鈴。當A資源預留成功后，將馬上發送UPDATE消息給被叫B，通知B主叫端已經資源預留成功。此時B回復200（OK），表示雙方資源預留都已經成功，這時B才可以對初始INVITE請求發出SIP 180（振鈴）響應，會話建立完成。

為了實現上述機制，主被叫在SDP offer/answer的協商過程中需要交換預置條件[5]。

如下例所示：

m=audio 20002 RTP/AVP 0

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

在A發送給B的消息中將攜帶此信息。其中，倒數第二行：

a=des:qos mandatory local sendrecv

這一行指出了主叫用戶端（local）想要的（des）服務質量（QoS）預置條件。主叫用戶需要在發送和接收兩個方向（sendrecv）預留資源，因為音頻流（audio）是雙向的。它還聲明如果主叫用戶不能成功預留資源，會話將不會建立（mandatory）。

最后一行：

a=des:qos none remote sendrecv

指出了被叫用戶端（remote）想要的（des）服務質量（QoS）預置條件。由于主叫和被叫用戶終端彼此之間沒有直接連接，因此主叫終端不知道對方終端以哪種方式附著到網絡，如果此時被叫端是通過CS電話網絡接入，因而并不需要進行任何資源預留，因此主叫側只能要求如果對端需要資源預留的話，應該同時在收和發兩個方向上進行預留（sendrecv）。但是主叫側當前并不知道真的需要進行預留才能建立起媒體會話（none）。

a=curr:qos local none

a=curr:qos remote none

這兩行表示目前（curr）無論主叫方（local）還是被叫方（remote）都還沒有（none）實現任何和服務質量（qos）有關的預置條件。a=des的行能夠用于為本地和對方用戶設置預置條件，a=curr的行用于指示目前已經實現了的那些預置條件。

4 結束語

傳統的2G、3G彩鈴已經取得了很大的成功，目前VoLTE建設還處于初期階段，4G網絡下的VoLTE彩鈴如果想繼續很好地發展和創新，必須解決在VoLTE網絡下為用戶提供可靠彩鈴業務的問題。

本文提出了一種VoLTE場景下彩鈴AS實現彩鈴業務的資源預留方案，方案可以解決SIP信令和媒體流同步傳輸問題，為彩鈴會話提供服務質量保障，進而能夠為用戶提供有保障的彩鈴服務。本文論述了VoLTE彩鈴業務的組網、彩鈴平臺總體設計和主要信令流程，通過本文希望能夠給從事VoLTE業務開發人員一些參考。

[1]Miikka Poikselka, Harri Holma, Jukka Hongisto.VOICE OVER LTE[M].Hoboken:John Wiley&Sons, 2012.

[2]韓健.VoLTE網絡架構及關鍵技術論述[J].科技視界, 2014（9).

[3]黃順，李煒.基于IMS多媒體彩像業務網關模式的設計與實現[J].電信技術，2010（10).

[4]RFC 3312.Integration of resource management and session initiation protocol （SIP)[S].2002.

[5]波克申科.IMS:IP多媒體概念和服務[M].北京：機械工業出版社，2011.