帳號:
密碼:
最新動態
 
產業快訊
CTIMES / 文章 /
IMS應用服務─VCC簡介及技術研發
 

【作者: 呂純德】   2008年12月09日 星期二

瀏覽人次:【8923】

基於近年來行動電話的普及以及營運者在同業競爭的壓力下,優惠的行動電話費率方案,愈來愈能吸引消費者的使用,甚至影響消費者降低使用室內有線電話的頻率。此種現象已侵蝕室內電話業者的獲利,業者為保有本身既有之利益,並在無線領域的行動電話營運中佔有一席之地,以圖開創新的營運空間,紛紛建置行動電話的核心網路,除了室內電話的營運外,同樣也扮演行動電話營運者的角色。


  FMC(Fixed Mobile Convergence:固網行動整合),即固網通訊與行動通訊的整合應用,普遍為業者目前積極追求的領域;目前市場上支援FMC的技術以UMA(Unlicensed Mobile Access)及IMS(IP Multimedia Subsystem)較為熟悉,近年來Femtocell的興起也是提供FMC的解決方案之一。


  UMA基本上是以2.5G/3G的核心網路為主,但增加了GAN的設計,用戶可以在WLAN與GERAN(GSM EDGE Radio Access Network)之間作無縫式的切換,終端使用者不論是進行語音通訊或是資料傳輸都不會察覺底層網路的差異;IMS亦是提供FMC的解決方案之一,但與UMA不同的是其後端網路基本上是屬於是IP網路,除了CS domain的語音服務外,IMS的網路結構可說是一種ALL IP網路。


  VCC(Voice Call Continuity)是IMS的一種服務,主要功用即是解決CS domain與IMS domain的語音切換,在兩個domain相互切換時保持語音通訊不會中斷;本文將針對VCC的技術做一探討。


VCC簡介

目前IMS在市場上的應用大多是IP資料的傳輸,屬於3G/2.5G之GPRS與WiFi之間的切換,但在CS domain領域中與WiFi間語音的切換,在市面上則較少見到;IMS VCC為CS domain與IMS domain的語音服務切換技術,本項技術將橫跨Cellular語音通訊及IP網路通訊的領域,是為目前提供固網與行動網路整合的解決方案之一。


  VCC的協定規格主要是依循3GPP TS 23.206及TS 24.206,它是架構於IMS上的一種應用服務,在IMS的核心網路中需建置VCC Application server與之配合才可使用。


  由於VCC是屬於IMS的一種應用服務,因此VCC UE端必須是屬於IMS的client,並且需含有VCC的使用介面;而後端網路端除了原有的IMS核心網路外,主要是要有VCC Application server的建置,此server將提供4種功能:Domain Transfer Function(DTF)、Domain Selection Function(DSF)、CS Adaptation Function(CSAF)、CAMEL Service,作為語音通訊時在CS domain與IMS間切換的邏輯運用。


  另外VCC UE與IMS核心網路的訊息溝通,主要是架構於SIP(Session Initiation Protocol)之上;為達到與網際網路連通及運用的便利性,IETF機構根據其所規範的網際網路標準選擇SIP協定作為IMS下層的訊息協定。


VCC網路架構

圖一表示VCC的網路架構,VCC UE藉由A/Iu及Gm介面分別與GSM CS domain元件及IMS元件溝通;在2G/2.5G的環境下,後端網路之GERAN透過A介面與MSC溝通;在3G的環境下,後端網路UTRAN透過Iu介面與SGSN溝通;而在IMS的環境下,則透過Gm介面與P-CSCF溝通。此網路架構圖主要是表示VCC UE端與IMS核心網路間的主要介面與網路元件,相關於GSM及GPRS的標準介面與網路元件並未標示在此架構圖中。


《圖一 VCC網路架構(資料來源:3GPP TS 23.206,資策會行動通訊中心整理)》
《圖一 VCC網路架構(資料來源:3GPP TS 23.206,資策會行動通訊中心整理)》

IMS之VCC的應用服務中,其網路端的VCC Application server元件扮演著相當重要的角色,其提供語音通訊在CS domain與IMS間相互切換的各項功能,這個元件由DTF、DSF、CSAF、CAMEL Service所組成。


DTF

DTF功能元件主要是負責domain的切換;首先DTF會先判斷由UE端或MGCF(Media Gateway Control Function)所傳送來的INVITE訊息,經由其中的Request-URI所帶的參數值來決定是否要執行domain切換的動作;此參數值在CS domain切換到IMS與IMS切換到CS domain各有不同的表示,如下說明。


在CS domain切換到IMS情形下

UE是在CS domain的通話狀態,UE將先建立IMS的link後再切換到CS domain,所以UE將直接送出INVITE訊息,經由Gm介面傳送到IMS核心網路的P-CSCF,然後再轉送到VCC Application server的DTF;DTF將會解析訊息中Request-URI的參數值,若此參數若為VDI(VCC Domain Transfer URI)值,則表示UE端準備進行domain的切換;若不是,則表示為一通IMS的MO call。


在IMS切換到CS domain情形下

UE是在IMS的通話狀態,UE將先建立CS domain的link後再切換到IMS,所以UE會送出CC SETUP訊息,然後經由A介面傳送到VMSC,此時VMSC會透過gsmSCF及CAMEL service機制與VCC Application server中的CSAF溝通取得一個IMRN值,然後再轉送到MGCF;待MGCF收到此CS call的訊息後,MGCF將會送出INVITE訊息到IMS核心網路的P-CSCF,然後再轉送到VCC Application server的CSAF及DTF;DTF則會解析訊息中Request-URI的參數值,若此參數值所對應之MT電話號碼為VDN,則表示UE端準備進行domain的切換;若不是,則表示為一通CS domain的MO call。


若DTF認可UE要進行domain的切換,則會把INVITE訊息轉送到MT端,MT端則會回覆訊息透過DTF給UE端,如此進行信息的溝通,以完成domain切換之signalling的動作。


DSF

DSF功能元件主要是負責domain的選擇;DSF根據Operator Policy及User preferences提供一個UE端對於incoming call之選擇domain的機制。每個VCC UE要使用VCC應用服務之前,都必需進行對IMS註冊的動作,VCC Application server可以知道這個UE的註冊狀態,例如這個UE會以IMS為優先來建立通話的Link,或只能用IMS來建立通話Link的能力;DSF會根據這些條件,選擇適當的domain建立與UE端的Link。


CSAF

CSAF及CAMEL Service功能元件是VCC UE在CS domain要與IMS核心網路進行訊息溝通時必要的元件;當UE端送出CC SETUP訊息時,會經由CAMEL Service傳送到CSAF,此時CSAF會根據訊息中的發話端號碼及收話端號碼產生一個IMRN值,此IMRN值會依據收話端號碼不同而有不同的意義;若收話端號碼為VDN,則此IMRN代表即將進行domain的切換;若收話端號碼為一般MT的號碼,則此IMRN代表即將進行CS MO originating call。


透過上述收話端號碼的判斷,CSAF會與DTF溝通,共同完成將CS call routing到IMS的動作。


CAMEL Service

CAMEL Service為Customised Application Mobile network Enhanced Logic Service的縮寫,ETSI SMG1團體從1994年開始制訂CAMEL的標準,1996年發佈第一版本,1997年發佈第二版本,目前最新版本為Phase 4;CAMEL Service的主要功用是提供一個機制,讓終端設備可以在不同的網路間漫遊;其規格在3GPP TS 22.078、TS 23.078及TS 23.278等文件中有詳細描述。


CAMEL Service在VCC所扮演的角色,主要是與CSAF合作取得IMRN值,並根據IMRN值將CS call reroute到IMS。


VCC UE端模組架構

依據3GPP TS 23.206及TS 24.206協定文件,VCC UE端須具備IMS client及2G/3G client的功能;協定文件中主要是描述UE端與IMS核心網路中各個網路元件的訊息溝通,對於UE端的協定堆疊則較少提及,圖二所表示的UE端架構是VCC與IMS client的部分,至於2G/3G的部分則不在此圖內。


  本架構是以Windows Mobile 6.0為作業系統,在此OS上建構VCC及IMS client的協定;架構中區分為三層,最上層為UI、IMS client端的核心物件所提供的API介面及VCC client端物件所提供的API介面;中間層為IMS client端核心物件及VCC所建構的物件;底層則為區分為兩部分,一部分為與傳輸機制有關的RTP、RTCP及SIP處理,另一部份為與multimedia相關的codec處理。


《圖二 VCC UE端模組架構(資料來源:資策會行動通訊中心整理)》
《圖二 VCC UE端模組架構(資料來源:資策會行動通訊中心整理)》

使用者透過UI的操作,使用IMS或VCC的應用服務;VCC UI為整個UI的一部份,VCC UI呼叫VCC API所提供的函式介面,用以驅動VCC物件;VCC物件可區分為IMS Method及CS Method兩部分,分別負責IMS及CS domain相關的訊息處理。


對IMS domain而言,IMS Method呼叫IMS core所提供的函式用以填入傳送SIP訊息之Body部分,並呼叫Signalling Communication PS中之SIP處理函式用以填入SIP訊息之Header部分,如此以完成一個SIP訊息內容的填入,最後透過UDP的傳輸方式將SIP訊息傳送到IMS的核心網路;另外也接收從IMS核心網路傳送來的SIP回覆訊息。


對CS domain而言,CS Method呼叫Windows Mobile 6.0之TAPI函式,來完成CS MO call及CS MT call的流程。VCC UE模組架構主要功能部分分別描述如下。


IMS core

IMS core核心物件之CSR 281是根據JSR 281改版而來,JSR 281是屬於Java的版本,定義Java IP Multimedia Subsystem Services API的應用介面,藉此標準用以發展IMS的應用。在我們的研發過程中,為因應與其他軟體及環境的配合,將之修改為C/C++的版本,並將名稱由JSR 281更改為CSR 281。


CSR 281提供與JSR 281相同的功能函式介面,例如IMS的註冊機制、多重IMS應用服務、建立/使用IMS session、建立/使用媒體連線、協調出合適的QoS以及傳輸安全機制等各類函式介面,這些函式介面讓IMS應用開發者可以快速、便利的開發IMS的應用服務。


Signalling Communication PS

本模組物件主要是提供與PS(Packet switch)domain相關的功能,如RTP/RTCP及CSR 180等。RTP/RTCP是數據資料傳輸時為達到資料即時傳輸的目的,必須對其傳送服務品質有所控制的模組。


CSR 180則是由JSR 180改版而來,JSR 180為SIP(Session Initiation Protocol)所提供的函式介面,JSR 180為Java的版本;同樣的,為因應與其他軟體及環境的配合,將之修改為C/C++的版本,並將名稱由JSR 180更改為CSR 180。


Multimedia

本模組物件是提供語音資料在Packet domain傳輸時之codec處理用,目前使用的是G.711的標準。


VCC物件

VCC物件是IMS VCC應用服務之client端主要的物件,包含CS domain及IMS domain兩種的處理方式。對於CS domain而言,將呼叫Windows Mobile 6.0所提供的TAPI函式,進行CS MO call及CS MT call的流程。


對於IMS domain而言,主要是呼叫CSR 281及CSR 180所提供的函式進行SIP訊息內容的填入、incoming call的處理及session的維護;使用CSR 281所提供的函式進行SIP訊息中Body內容的填入,SIP訊息中Body部份的內容通常採用SDP(Session Description Protocol)的格式,使用者需填入足夠的資訊讓對方(remote user)得以判斷及回覆適當的訊息,以一個multimedia session為例,必須要有本身的IP位址及port number、傳輸語音時的codec資料以及是屬於audio或video或是兩者均有等media的資料。


另外使用CSR 180所提供的函式進行SIP訊息中Header內容的填入;即各種SIP訊息的Header內容處理。


Operator Policy及User Preferences

Operator Policy(系統業者策略)是指由系統業者制訂一套選擇domain的條件,讓VCC UE端及VCC Application server中的DSF功能元件來應用。同樣的,User Preferences(使用者偏好)則是由使用者來決定要選擇何種domain。


依據3GPP TS 23.206的規範,在DSF中之選擇domain的機制裡,Operator Policy的條件判斷將優先於User Preferences,但在UE端則未說明有此限制。圖三為DSF中之選擇domain機制的流程圖。Operator Policy的制訂需遵循下列幾項原則:


  • * 定義發話端的domain選擇偏好。


  • * 當特定domain可使用時,是否立即切換到該domain。


  • * 是否限制單向的domain切換。


  • * 是否限制在held/waiting call/session時,不能執行domain的切換。




《圖三 DSF中domain選擇流程圖(資料來源:3GPP TS 23.206,資策會行動通訊中心整理)》
《圖三 DSF中domain選擇流程圖(資料來源:3GPP TS 23.206,資策會行動通訊中心整理)》

另外UE端的Operator Policy是可以透過OMA Device Management,由Operator下載到UE端;Device Management是OMA組織所制訂的標準,是屬於一種client端及server端雙向溝通的標準。當Operator Policy被更新時,系統業者便可透過OMA Device Management與UE溝通,將更新後的Operator Policy下載到UE端供其使用。


VCC domain切換之Control Plane

VCC應用服務最主要的功能就是語音通訊時在IMS與CS domain的切換,切換的程序可區分為由IMS切換到CS domain或由CS domain切換到IMS的程序;當UE端偵測到需要進行domain切換的條件,切換的過程大約可分成三個階段,如下描述:


  • 1. UE端先行建立與VCC Application server之DTF的管道,此管道之建立是透過未來要轉進的domain來進行;這個管道的建立是整個domain切換中之signalling的一部份,用意在於建立與IMS核心網路的連通;其實這個步驟就是一個IMS(或CS)originating call的前半段作業。


  • 2. 當DTF收到INVITE訊息,經判斷屬於domain切換的訊息,即開始執行domain切換的程序;與MT端建立連通的管道,待MT端回覆訊息與VCC Application server及UE(MO)端協調/確認相關資料成功後,即完成未來要轉進domain的signalling的動作,建立起transferred-in domain的Link;之後,語音資料開始由transferred-in domain傳輸。


  • 3. 在完成建立transferred-in domain後,DTF通知UE(MO)端釋放要轉出 (transferred-out)domain的Link,並釋放原有相關的media的資源,即結束原來透過transferred-out domain傳輸語音的Link。



透過以上三個階段,語音通訊將從原來的domain切換到另一個domain,圖四為語音通訊從CS domain切換到IMS domain的訊息流程。



《圖四 CS domain to IMS切換之訊息流程(資料來源:3GPP TS 24.206,資策會行動通訊中心整理)》
《圖四 CS domain to IMS切換之訊息流程(資料來源:3GPP TS 24.206,資策會行動通訊中心整理)》

VCC domain切換之User Plane

VCC應用服務在語音通訊時,若兩端都屬於IP base的IMS domain時,則語音資料是利用IP封包在傳輸,倘若有一端是屬於CS domain時,則中間必須經過MGW將語音轉換成適當的格式才能讓兩端通話;這是因為屬於CS domain這一端的語音傳送/接收並不屬於IP封包,而是經過codec的encode/decode處理後,透過radio bearer來傳送/接收,兩者的傳輸機制是完全不一樣的。


當domain在切換時,UE端transferred-in的domain為CS domain時,則在UE與DTF建立Access Leg的階段中,MGCF就會與MGW溝通,以便configure MGW的media bearer,此舉是讓MGW知道UE端即將透過CS domain的Link來傳送語音;同樣的,在與另一端建立Link時,經由MT所回覆的訊息中,MGCF會知道MT端的media資料,並configure MGW;如此,MGW就可知道MO及MT兩端的media資料,並在兩端進行語音通訊時作語音資料轉換的動作。圖五是VCC UE與IMS UE之user plane路徑切換的示意圖。



《圖五 VCC UE(MO端)與IMS UE(MT端)之user plane路徑切換(資料來源:3GPP TS 23.206,資策會行動通訊中心整理)》
《圖五 VCC UE(MO端)與IMS UE(MT端)之user plane路徑切換(資料來源:3GPP TS 23.206,資策會行動通訊中心整理)》

結語

在使用無線行動通訊的領域中,Cellular之核心網路技術是目前的主流技術,這項核心網路技術從2G時代以服務circuit switch為主的語音通訊,轉變到目前加入了packet switch的技術,由2G提升到3G/3.5G,可以傳輸大量資料用以服務多媒體的應用。在3G時代的核心網路技術已陸續加入一些網路元件,將網際網路與Cellular之核心網路結合,期望透過這種整合可以讓應用服務供應者提供更多的應用服務。


依目前情勢來看,雖然以後技術的發展會朝向All IP的方向,然而目前Cellular之核心網路尚存在有circuit switch的部份。circuit switch的存在從2G延續到現在,甚至在未來的若干年內它依然會存在,究其原因不外乎Operator尚未有全面更新後端網路的動機,畢竟後端網路更新的投資報酬率及需要服務原有使用2G的end user,都是重大的考慮因素。在目前的情況下,經由circuit switch的語音通訊與經由IP base的語音通訊,在兩者之間相互切換而不使語音通話中斷的技術,就有其利基存在,而VCC就是具備這種切換的技術。


雖然VCC與UMA都具有這種domain切換的能力,同樣也是提供FMC的解決方案之一,然而VCC是架構於IMS上的應用服務,在核心網路的架構中是比UMA更趨近於All IP的網路架構。


當然VCC要能夠在市場中廣泛的運用,首先電信業者必須先建置IMS的核心網路,也就是要將原有2.5G/3G的核心網路提升至3GPP Release 5以後的架構;在未來的通訊領域中,不論是結合固網、資訊網路或是行動通訊網路,整個的通訊環境正逐漸走向一個匯流的方向,以All IP為主的網路架構預料會是近年來市場的主流。


---作者任職於財團法人資訊工業策進會網路多媒體研究所行動通訊中心---


相關文章
傳輸網路的明日之星-ATM
comments powered by Disqus
相關討論
  相關新聞
» 倚天酷碁於2024歐洲自行車展亮相電動輔助自行車與電動滑板車新品
» 麗臺進駐雙和生醫園區推動智慧醫院發展
» 瀚錸引進智能家居系列產品 推進連網增速新趨勢
» 工研院CES展後賦能科技創新 掌握AI產業鏈商機可期
» 國科會TTA偕新創團隊挑戰CES 2024


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.3.133.134.123
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw