許 鈔,羅國(guó)明,鄒仕祥

(解放軍理工大學(xué)通信工程學(xué)院,南京210007)

同步SRVCC方案的設(shè)計(jì)與性能仿真

許 鈔,羅國(guó)明,鄒仕祥

(解放軍理工大學(xué)通信工程學(xué)院,南京210007)

將基于IP多媒體子系統(tǒng)(IMS)的單一無(wú)線語(yǔ)音呼叫連續(xù)性(SRVCC)技術(shù)應(yīng)用于長(zhǎng)期演進(jìn)(LTE)部署的初中期階段,以實(shí)現(xiàn)LTE和2G/3G CS域的語(yǔ)音切換連續(xù)性,被業(yè)界一致認(rèn)為是網(wǎng)絡(luò)共存期間LTE語(yǔ)音業(yè)務(wù)的經(jīng)典提供方案。然而,3GPP制定的關(guān)于SRVCC相關(guān)方案不能滿足語(yǔ)音業(yè)務(wù)實(shí)時(shí)性的要求,IMS核心網(wǎng)側(cè)媒體更新時(shí)間過(guò)長(zhǎng)。為此,提出一種基于歸屬域控制的遠(yuǎn)端媒體優(yōu)化的同步SRVCC方案。分析SRVCC技術(shù)特點(diǎn)和存在問題,通過(guò)會(huì)話集中和持續(xù)性應(yīng)用服務(wù)器的媒體選擇功能減少遠(yuǎn)端媒體的更新時(shí)間,并在MSC Server中設(shè)定計(jì)時(shí)器,同步UE的切換時(shí)間和遠(yuǎn)端媒體更新時(shí)間,以達(dá)到減少中斷時(shí)延的目的。仿真結(jié)果表明,在不增加網(wǎng)絡(luò)實(shí)體的情況下,該方案能滿足3GPP中斷時(shí)延小于300 ms的要求。

長(zhǎng)期演進(jìn);單一無(wú)線語(yǔ)音呼叫連續(xù)性;IP多媒體子系統(tǒng);同步;媒體更新

1 概述

為適應(yīng)全球移動(dòng)通信市場(chǎng)競(jìng)爭(zhēng)、滿足移動(dòng)寬帶的發(fā)展,3GPP提出了長(zhǎng)期演進(jìn) (Long Term Evolution,LTE)和系統(tǒng)架構(gòu)演進(jìn)(System Architecture Evolution,SAE)[1-2]計(jì)劃,LTE/SAE是第三代移動(dòng)通信系統(tǒng)向全I(xiàn)P方案演進(jìn)的重要發(fā)展階段。在LTE網(wǎng)絡(luò)部署初中期,運(yùn)營(yíng)商主要在熱點(diǎn)地區(qū)、密集城區(qū)和數(shù)據(jù)業(yè)務(wù)需求大的區(qū)域引入LTE網(wǎng)絡(luò),因此,將同時(shí)與2G、3G以及其他多種制式的無(wú)線網(wǎng)絡(luò)共存。作為支持全I(xiàn)P的移動(dòng)網(wǎng)絡(luò),LTE/EPC并不提供CS功能,而現(xiàn)有的2G/3G都是基于CS域提供語(yǔ)音業(yè)務(wù),如何實(shí)現(xiàn)LTE和現(xiàn)有移動(dòng)網(wǎng)絡(luò)在語(yǔ)音業(yè)務(wù)上的無(wú)縫連接,自VoLTE分組語(yǔ)音技術(shù)提出以來(lái)就一直是研究和探討的熱點(diǎn)問題[3]。

3GPP在 R7提出了 IP多媒體子系統(tǒng)(IP Multimedia Subsystem,IMS)/VCC[4-5]方案,以解決分組語(yǔ)音業(yè)務(wù)的持續(xù)性問題。該方案中UE同時(shí)駐留在IMS和2G/3G網(wǎng)絡(luò)中,在需要切換時(shí)選擇一種網(wǎng)絡(luò)作為終結(jié)域完成語(yǔ)音呼叫,但該方案存在的一個(gè)關(guān)鍵問題是支持LTE和GSM/UMTS的雙模手機(jī)很難實(shí)現(xiàn)雙模雙待,不能同時(shí)附著到LTE和GSM/ UMTS系統(tǒng)進(jìn)行數(shù)據(jù)收發(fā)或者語(yǔ)音通話,從而限制了VCC技術(shù)的應(yīng)用。CS FallBack[6]方案是3GPP在R8提出的技術(shù)標(biāo)準(zhǔn),主要采用將終端回落到2G/ 3G網(wǎng)絡(luò)中完成所有電路域業(yè)務(wù),該技術(shù)并未從本質(zhì)上解決LTE提供語(yǔ)音業(yè)務(wù)的問題,在進(jìn)行模式轉(zhuǎn)換時(shí),用戶在LTE網(wǎng)絡(luò)下的業(yè)務(wù)都需要中斷、切換或掛起,影響用戶的業(yè)務(wù)體驗(yàn)。為此,在VCC方案的基礎(chǔ)上,3GPP R8提出了 Single Radio VCC即SRVCC[7]技術(shù),用以實(shí)現(xiàn)雙模單待用戶在LTE和2G/3G間語(yǔ)音業(yè)務(wù)的連續(xù)性。本文在上述研究的基礎(chǔ)上,提出一種基于歸屬域控制的遠(yuǎn)端媒體優(yōu)化的同步SRVCC方案。

2 SRVCC實(shí)現(xiàn)方案及改進(jìn)思路

2.1 SRVCC切換控制流程

SRVCC的基本思路是:UE在LTE網(wǎng)絡(luò)中采用IMS呼叫流程建立語(yǔ)音呼叫,在建立過(guò)程中呼叫被錨定在IMS/會(huì)話集中和持續(xù)性應(yīng)用服務(wù)器(Service Centralization and Continuity Application Server,SCC AS)[8]上。當(dāng)終端移動(dòng)到LTE邊緣,MSC Server代替終端發(fā)起SRVCC切換請(qǐng)求(同時(shí),UE與MSC之間的CS域連接也會(huì)建立),并與IMS/SCC AS之間建立新的本端呼叫路徑,提供CS域的媒體信息給SCC AS,SCC AS通過(guò)會(huì)話持續(xù)性過(guò)程重新建立通話兩端的媒體層連接,從而完成LTE到GERAN/ UTRAN的切換。

SRVCC切換過(guò)程包括承載層的PS-CS切換和業(yè)務(wù)層的IMS域切換兩部分,這兩部分切換處理相互獨(dú)立,保證了語(yǔ)音業(yè)務(wù)在切換中的持續(xù)性。主要控制流程如圖1所示,其中,重疊的框表示同時(shí)進(jìn)行。

圖1 SRVCC切換控制流程

由于IMS域執(zhí)行會(huì)話持續(xù)性控制(步驟6)和本端UE端切換過(guò)程(步驟10)是相對(duì)獨(dú)立的,這對(duì)于本端UE來(lái)說(shuō)能夠避免切換指令被延遲發(fā)送,從而減少用戶由于離開LTE覆蓋區(qū)發(fā)生掉話現(xiàn)象。但對(duì)于遠(yuǎn)端UE來(lái)說(shuō),兩者缺乏同步機(jī)制[9],則很可能造成用戶面業(yè)務(wù)中斷,導(dǎo)致話音丟失。且UE端的切換過(guò)程通常都要比 IMS側(cè)會(huì)話持續(xù)性過(guò)程快(IMS側(cè)需要到遠(yuǎn)端終端做媒體面更新),若本端UE完成切換,IMS側(cè)遠(yuǎn)端更新還未完成,則遠(yuǎn)端UE仍會(huì)把RTP媒體發(fā)向LTE側(cè),出現(xiàn)用戶面業(yè)務(wù)中斷現(xiàn)象。此時(shí),對(duì)遠(yuǎn)端UE,可能有一段時(shí)間聽不到對(duì)方的話音,降低了遠(yuǎn)端UE用戶的業(yè)務(wù)體驗(yàn)和服務(wù)質(zhì)量。在切換時(shí)延上[10],由于IMS側(cè)需要對(duì)遠(yuǎn)端終端媒體進(jìn)行更新,因此SRVCC切換時(shí)延主要是IMS側(cè)導(dǎo)致的,而且切換時(shí)延也較長(zhǎng),通常超過(guò)300 ms[11],若考慮遠(yuǎn)端UE的漫游和網(wǎng)絡(luò)狀態(tài),則時(shí)延可能更長(zhǎng)。

2.2 對(duì)SRVCC切換過(guò)程的改進(jìn)思路

通過(guò)以上分析可以得知,在對(duì)SRVCC方案進(jìn)行優(yōu)化時(shí),可從解決切換時(shí)延和用戶面業(yè)務(wù)中斷兩方面入手[12]。目前,業(yè)界已經(jīng)提出多種方案用于優(yōu)化SRVCC,總的來(lái)說(shuō),包括2種類型[13]。第1種類型是協(xié)調(diào)本端UE和IMS側(cè)的切換時(shí)間,使2個(gè)切換過(guò)程時(shí)間同步,以減少業(yè)務(wù)中斷時(shí)間,包括讓MSC Server協(xié)調(diào)IMS會(huì)話轉(zhuǎn)移時(shí)間,以及在發(fā)給遠(yuǎn)端UE的INVITE消息中不帶SDP信息,或者先進(jìn)行遠(yuǎn)端媒體更新,再進(jìn)行切換的方法。這類方案雖能達(dá)到同步效果,但會(huì)增加更多處理時(shí)延,整體效果不佳;第2種類型是將媒體流錨定到某一功能實(shí)體,避免遠(yuǎn)端媒體的更新,包括將媒體流錨定在拜訪網(wǎng)絡(luò)的MGW,或增加ATGW/ATCF網(wǎng)元的eSRVCC[14]方案等,這種方案對(duì)時(shí)延的改善比較明顯,但需增加新的網(wǎng)元,對(duì)網(wǎng)絡(luò)改動(dòng)比較大。

3 遠(yuǎn)端媒體優(yōu)化的同步SRVCC方案

3.1 優(yōu)化方案的設(shè)計(jì)及相關(guān)信令流程

本文在對(duì)上述方案分析的基礎(chǔ)上,綜合2.2節(jié)2種類型的特點(diǎn),提出了對(duì)遠(yuǎn)端媒體優(yōu)化的同步SRVCC方案,通過(guò)仿真分析,該方案能夠降低業(yè)務(wù)中斷時(shí)延,提升SRVCC整體切換性能。該方案的核心思路是利用SCC AS進(jìn)行媒體選擇,對(duì)遠(yuǎn)端媒體更新進(jìn)行優(yōu)化,以降低更新時(shí)間;MSC Server管理一個(gè)計(jì)時(shí)器,同步會(huì)話轉(zhuǎn)移過(guò)程和切換過(guò)程而引起的信息流中斷,從而達(dá)到降低整體語(yǔ)音中斷時(shí)間的效果。

為節(jié)約成本和對(duì)現(xiàn)網(wǎng)改造的考慮,該方案不改變?cè)蠸RVCC網(wǎng)絡(luò)架構(gòu),僅需要增強(qiáng)歸屬域IMS側(cè)SCC AS的功能,對(duì)于拜訪網(wǎng)絡(luò)和接入網(wǎng)絡(luò)僅對(duì)MSC Server進(jìn)行功能增強(qiáng),這對(duì)于數(shù)量龐大的接入網(wǎng)絡(luò)來(lái)說(shuō)無(wú)疑是最佳的方案。

在考慮本節(jié)所述實(shí)體功能增強(qiáng)基礎(chǔ)上,還需考慮如下問題:

(1)MSC Server需預(yù)定義一個(gè)與切換相關(guān)聯(lián)的MSC Server到本地UE的平均時(shí)間跨度;在域轉(zhuǎn)移過(guò)程中計(jì)算從MSC Server到SCC AS的延遲;啟動(dòng)和管理計(jì)時(shí)器,用于同步會(huì)話轉(zhuǎn)移過(guò)程和切換過(guò)程。

(2)SCC AS能夠在語(yǔ)音會(huì)話建立階段測(cè)量遠(yuǎn)端的信令延遲;在域轉(zhuǎn)移過(guò)程將延遲返回給MSC Server;選擇遠(yuǎn)端UE和MGW共有的媒體類型,并將選擇的媒體類型分別發(fā)送給遠(yuǎn)端 UE和 MSC Server。

體現(xiàn)上述方案的信令流程如圖2所示,其中,虛線箭頭表示該步為可選步驟。

圖2 優(yōu)化SRVCC信令的流程

對(duì)圖2中的信令流程描述如下:

在步驟1之前,SCC AS在會(huì)話建立階段已經(jīng)測(cè)量出遠(yuǎn)端的信令延遲,記為P1。

步驟1～步驟9:與R8 SRVCC流程相同。

步驟10:MSC Server發(fā)送包含STN-SR、MGW SDP的INVITE消息到IMS/SCC AS。此外,MSC Server發(fā)送INVITE請(qǐng)求時(shí),存儲(chǔ)發(fā)送時(shí)間。

步驟11～步驟15可能和步驟16～步驟21同時(shí)發(fā)生。

步驟11:SCC AS向MSC Server返回遠(yuǎn)端的信令延遲。

步驟12:當(dāng)MSC Server收到遠(yuǎn)端的信令延遲,計(jì)算出從MSC Server向SCC AS發(fā)送的SIP信令及響應(yīng)的持續(xù)時(shí)間,記該持續(xù)時(shí)間的一半為P2(從MSC Server到SCC AS的信令延遲)。此外,假設(shè)MSC Server預(yù)定義與CS切換相關(guān)聯(lián)的MSC Server到本地UE的平均時(shí)間跨度為P3。如2.2節(jié)分析,P1明顯長(zhǎng)于P2、P3,且P1大于P2+P3。在MSC Server啟動(dòng)一個(gè)持續(xù)時(shí)間為P1-P3-P2的計(jì)時(shí)器。在計(jì)時(shí)器超時(shí)后,MSC Server將執(zhí)行步驟13。如果P1不大于P3+P2,MSC Server不啟動(dòng)定時(shí)器,并立即執(zhí)行步驟13。

步驟13～步驟15:與R8 SRVCC流程相同。

步驟16:SCC AS存儲(chǔ)MGW SDP信息并發(fā)送不包含SDP的re-INVITE媒體更新信息到遠(yuǎn)端。

步驟17:遠(yuǎn)端響應(yīng)包含遠(yuǎn)端SDP信息的200 OK給SCC AS,其中,包含正在使用的SDP信息和所有遠(yuǎn)端支持的媒體格式。

步驟18:收到響應(yīng)消息,SCC AS對(duì)比MGW SDP和遠(yuǎn)端SDP的媒體類型,選擇共同并最適合的媒體類型。

步驟19:SCC AS響應(yīng)包含遠(yuǎn)端SDP的200 OK到目標(biāo)MSC。

步驟20:SCC AS發(fā)送包含MGW SDP信息的ACK請(qǐng)求到遠(yuǎn)端。

步驟21:釋放源IMS接入。步驟22:UE切換到CS域。步驟23～步驟31:與原SRVCC流程相同。

3.2 優(yōu)化SRVCC的性能分析

由于在信令流程中,圖2中步驟1～步驟9和步驟23～步驟31與原方案相同,步驟10只是在MSC Server中執(zhí)行存儲(chǔ)時(shí)間,不影響整個(gè)時(shí)延,故本方案主要考慮步驟11～步驟22的信令延遲。3GPP R8中SRVCC方案語(yǔ)音媒體流中斷時(shí)間分析如圖3所示。

圖3 3GPP R8中SRVCC媒體流中斷時(shí)間分析

分別計(jì)算上下行語(yǔ)音媒體流中斷時(shí)間,得:

上行:上行語(yǔ)音媒體流中斷在步驟a2或步驟b2后,并在步驟b3和步驟a4完成后恢復(fù)。因此,上行語(yǔ)音媒體流的中斷時(shí)間是:Tu=max(Ta1+Ta2+Ta3+Ta4-Tb1-Tb2,Tb3)。

下行:下行語(yǔ)音媒體流中斷在步驟b2后,并在步驟后b3和步驟a4完成后恢復(fù)。因此,下行語(yǔ)音媒體流的中斷時(shí)間是:Td=max(Ta1+Ta2+Ta3+Ta4-Tb1-Tb2,Tb3)。

步驟b1和步驟b2發(fā)生在UE當(dāng)前附著的網(wǎng)絡(luò),所以,有理由假設(shè)(Tb1+Tb2)遠(yuǎn)小于(Ta1+Ta2+Ta3+Ta4),Td和Tu可表示為:Tu=MAX(Ta1+Ta2+Ta3+Ta4,Tb3);Td=max(Ta1+Ta2+Ta3+Ta4,Tb3)。

優(yōu)化SRVCC語(yǔ)音媒體流中斷時(shí)間的流程如圖4所示。

圖4 優(yōu)化SRVCC語(yǔ)音媒體流中斷時(shí)間的流程

其中,P1=Ta2+Ta3+Ta5,P2=Ta1=Ta4,P3=Tb1+Tb2,則MSC Server設(shè)定的計(jì)時(shí)器時(shí)間為Tm=P1-P2-P3=Ta2+Ta3+Ta5-Ta1-Tb1-Tb2。

分別計(jì)算上下行語(yǔ)音媒體流中斷時(shí)間,得:

上行:上行語(yǔ)音媒體流中斷在步驟b2后,并在步驟b3和步驟a5完成后恢復(fù)。因此,上行媒體流的中斷時(shí)間是:Tu=Tb3

下行:在步驟a5中一旦遠(yuǎn)端接收到ACK應(yīng)答,或SRVCC UE執(zhí)行步驟b3則下行語(yǔ)音媒體流中斷。直到完成2個(gè)步驟a5和步驟b3后恢復(fù)。因此,下行語(yǔ)音媒體流中斷時(shí)間可以分為以下3種情形:

(1)Td=Ta5-(Ta4+Tb1+Tb2),當(dāng)步驟b3在步驟a5前完成,即Ta5＞Ta4+Tb1+Tb2+Tb3,此時(shí),P1不大于P2+P3,不啟動(dòng)計(jì)時(shí)器。

(2)Td=(Ta4+Tb1+Tb2+Tb3)-Ta5-Tm=2(Ta1-Ta5+Tb1+Tb2)+Tb3-Ta2-Ta3,當(dāng)步驟b3在步驟a5后完成,即Ta4+Tb1+Tb2＞Ta5。

(3)Td=Tb3,當(dāng)步驟b3與步驟a5同時(shí)完成,此時(shí),P1不大于P2+P3,不啟動(dòng)計(jì)時(shí)器。

對(duì)比2種方案,主要取決于Tb3的時(shí)間長(zhǎng)度,即UE執(zhí)行PS到CS的切換時(shí)長(zhǎng),而Tb3一般小于300 ms,且通常為100 ms左右,也小于(Ta1+Ta2+Ta3+Ta4)。對(duì)于上行鏈路,優(yōu)化SRVCC的中斷時(shí)間為Tb3,明顯小于原方案中的中斷時(shí)間。對(duì)于下行鏈路,雖然增加了步驟a5,但降低了遠(yuǎn)端媒體的更新過(guò)程,相比原方案也有所減少,并在最好的情況下與Tb3相同。

3.3 系統(tǒng)建模與仿真分析

為了驗(yàn)證本文提出的SRVCC優(yōu)化方案的可行性,在OPNET環(huán)境下下進(jìn)行建模仿真[15]。由于同一網(wǎng)絡(luò)網(wǎng)元間的傳輸時(shí)延非常小,可忽略不記,因此,對(duì)仿真場(chǎng)景進(jìn)行了簡(jiǎn)化,將多個(gè)網(wǎng)元的功能集中到一個(gè)結(jié)點(diǎn)。根據(jù)經(jīng)驗(yàn)值,遠(yuǎn)端媒體更新的時(shí)延可設(shè)為200 ms～500 ms的隨機(jī)值。

圖5是UE速度為5 km/h、20 km/h、60 km/h時(shí)根據(jù)不同隨機(jī)種子數(shù)測(cè)得的中斷時(shí)延,切換全部成功。最小時(shí)延約為235 ms,最長(zhǎng)時(shí)延約為282 ms,平均時(shí)延259 ms,可以看出,在典型速度下,中斷時(shí)延波動(dòng)較大,這是由于遠(yuǎn)端網(wǎng)絡(luò)的不穩(wěn)定性造成的。圖6是一次成功切換中不同基站吞吐率的對(duì)比,切換發(fā)生在594 s左右。從圖中可以看出,切換后, BSC相比于切換前eNB的吞吐率有明顯下降;切換發(fā)生相對(duì)滯后,這是因?yàn)樵谇袚Q策略中加入了切換滯后差值(5 s)。

圖5 不同速度下的中斷時(shí)延

圖6 切換前后基站吞吐率對(duì)比

4 結(jié)束語(yǔ)

本文在分析LTE與2G/3G網(wǎng)絡(luò)共存情況下,語(yǔ)音業(yè)務(wù)的現(xiàn)有解決方案SRVCC的基礎(chǔ)上,提出一種改進(jìn)的采用SCC AS進(jìn)行媒體選擇,并對(duì)切換和會(huì)話持續(xù)過(guò)程進(jìn)行同步的SRVCC方案。通過(guò)對(duì)語(yǔ)音鏈路媒體流中斷時(shí)延的分析與仿真,結(jié)果證明,中斷時(shí)延達(dá)到了3GPP對(duì)中斷時(shí)延的要求。同時(shí),該方案對(duì)現(xiàn)有網(wǎng)絡(luò)改動(dòng)較小,且接續(xù)控制過(guò)程完全在IMS歸屬域中完成,方便部署和實(shí)現(xiàn)。目前,SRVCC技術(shù)切換時(shí)需要多網(wǎng)協(xié)調(diào),信令過(guò)程復(fù)雜,切換性能遠(yuǎn)不如電路域切換,并且SRVCC只能實(shí)現(xiàn)LTE到2G/3G的單向切換,反向切換標(biāo)準(zhǔn)還未制定,同時(shí),如何在切換時(shí)也能進(jìn)行分組數(shù)據(jù)切換,這些問題都將在以后做更加深入的研究。

[1] 龐韶敏,李亞波.3G UMTS與4G LTE核心網(wǎng)——CS, PS,EPC,IMS[M].北京:電子工業(yè)出版社,2010.

[2] 3GPP.TS 36.133-2012 Evolved Universal Terrestrial Radio Access(E-UTRA);Requirements for Support of Radio Resource Management(Release 11)[S].2012.

[3] Vaishali P.Seamless Voice over LTE[C]//Proceedings of the 4th IEEE International Conference on Internet Multimedia Services Architecture and Application. Bangalore,India:IEEE Press,2010:1-5.

[4] 3GPP.TS 23.228-2008 IP MultimediaSubsystem (IMS);Stage2(Release 8)[S].2008.

[5] 3GPP.TS 23.206-2007 Voice Call Continuity(VCC) Between Circuit Switched(CS)and IP Multimedia Subsystem(IMS);Stage 2(Release 7)[S].2007.

[6] 徐德平,耿魯靜.淺析LTE系統(tǒng) CSFB話音解決方案[J].電信工程技術(shù)與標(biāo)準(zhǔn)化,2013,(1):55-59.

[7] 3GPP.TS 23.216-2012 SingleRadio VoiceCall Continuity(SRVCC);Stage 2(Release 11)[S].2012.

[8] 3GPP.TS 23.237-2009 IP Multimedia Subsystem(IMS) Service Continuity;Stage 2(Release 10)[S].2009.

[9] 劉 晨.SRVCC優(yōu)化方案研究及改進(jìn)[D].北京:北京郵電大學(xué),2010.

[10] Koshimizu T,Tanaka I.Improvement on the VoLTE (Voice Over LTE)Domain Handover with Operator’s Vision[C]//Proceedings of World Telecommunications

[3] Begen A C,Akgul T,Baugher M.Watching Video over the Web:Part 1:Streaming Protocols[J].IEEE Internet Computing,2011,15(2):54-63.

[4] Akhshabi S,Begen A C,Dovrolis C.An Experimental Evaluation of Rate-adaptation Algorithms in Adaptive Streaming over Http[C]//Proceedings of the 2nd Annual ACM Conference on Multimedia Systems.[S.l.]:ACM Press,2011:157-168.

[5] Swaminathan V,Sheng Wei.Low Latency Live Video Streaming using HTTP Chunked Encoding[C]// Proceedings of MMSP’11.Hangzhou,China:[s.n.], 2011:1-6.

[6] Roverso R,El-Ansary S,H?gqvist M.On HTTP Live Streaming in Large Enterprises[C]//Proceedings of SIGCOMM’13.Hong Kong,China:[s.n.],2013:489-490.

[7] 全國(guó)廣播電影電視標(biāo)準(zhǔn)化技術(shù)委員會(huì).GY/T258-2012下一代廣播電視網(wǎng)(NGB)視頻點(diǎn)播系統(tǒng)技術(shù)規(guī)范[S].2012.

[8] Li Jun,ChenJun,LiMingzhe,etal.A Multi-core Architecture for Video Streaming[EB/OL].(2010-11-21). http://www.scientific.net/AMM.411-414.960.

[9] Erbad A,Hutchinson N C,Krasic C.DOHA:Scalable Realtime Web ApplicationsThroughAdaptiveConcurrent Execution[C]//Proceedings of the 21stInternational Conference on World Wide Web.Lyon,France:ACM Press,2012:161-170.

[10] Wang Xin.TechnicalAnalysis ofHigh-capacity and Concurrency Server Groups[C]//Proceedings of ICEEE’10.Zhengzhou,China:[s.n.],2010:1-4.

[11] Kimpe D,Carns P,Harms K,et al.Aesop:Expressing Concurrency in High-performance System Software[C]// Proceedings of NAS’12.[S.l.]:IEEE Press,2012: 303-312.

[12] Anderson J A,Head T J.Automata Theory with Modern Applications[M].New York,USA:Cambridge University Press,2006.Congress.Miyazaki,Japan:[s.n.],2012:1-5.

編輯 劉 冰

[11] 3GPP.TR 25.913-2010 Requirements for E-UTRA and E-UTRAN(Release 9)[S].2010.

[12] Namakoye J,Olst R V.Performance Evaluation of a Voice Call Handover Scheme between LTE and UMTS[C]// Proceedings of IEEE AFRICON’11.Livingstone,Zambia: IEEE Press,2011:1-4.

[13] 許慕鴻.SRVCC增強(qiáng)技術(shù)分析[J].電信網(wǎng)技術(shù), 2010,(12):10-16.

[14] 3GPP.TR 23.856-2010 Single Radio Voice Call Continuity (SRVCC)Enhancements:Stage 2(Release 10)[S].2010.

[15] 劉 靜.LTE系統(tǒng)中的切換與切換自優(yōu)化方法研究[D].西安:西安電子科技大學(xué),2009.

編輯 劉 冰

Design and Performance Simulation of Synchronous SRVCC Scheme

XU Chao,LUO Guoming,ZOU Shixiang
(College of Communication Engineering,PLA University of Science and Technology,Nanjing 210007,China)

Single Radio Voice Call Continuity(SRVCC)based on IP Multimedia Subsystem(IMS)is implemented to realize the voice continuity between Long Term Evolution(LTE)and 2G/3G in CS domain during the middle stage of LTE deployments.It is voted by the industry as the target solution to provide LTE voice service during network convergence.But related programs about SRVCC developed by 3GPP can not meet the requirements of real-time voice service.The main problem is the media update time for too long at IMS core network side.On the basis of the analysis of the characteristics and problems of SRVCC,it proposes the remote media optimization and synchronous scheme of SRVCC under the domain control.The scheme reduces the update time of remote end by Service Centralization and Continuity Application Server(SCC AS)media selection function,and sets the timer in the MSC Server to synchronous UE switching time and remotes media update time in order to achieve the purpose of reducing interrupt delay.Simulation results show that,this scheme can meet the requirements of 3GPP to interrupt delay in the case without increasing the network entity.

Long Term Evolution(LTE);Single Radio Voice Call Continuity(SRVCC);IP Multimedia Subsystem (IMS);synchronous;media update

1000-3428(2015)01-0251-05

A

TP37

10.3969/j.issn.1000-3428.2015.01.047

許 鈔(1985-),男,碩士研究生,主研方向:網(wǎng)絡(luò)多媒體技術(shù);羅國(guó)明,教授;鄒仕祥,講師。

2014-01-20

2014-03-14 E-mail:glorde@qq.com

中文引用格式:許 鈔,羅國(guó)明,鄒仕祥.同步SRVCC方案的設(shè)計(jì)與性能仿真[J].計(jì)算機(jī)工程,2015,41(1):251-255.

英文引用格式:Xu Chao,Luo Guoming,Zou Shixiang.Design and Performance Simulation of Synchronous SRVCC Scheme[J].Computer Engineering,2015,41(1):251-255.