同學(xué)們?cè)诮佑|SRVCC一段時(shí)間后，一定會(huì)有幾個(gè)百思不得其姐的問題，比如：
各種SRVCC如何區(qū)分？
為何會(huì)發(fā)生沒完沒了的SRVCC？
終端返回LTE時(shí)為何有時(shí)候會(huì)收到一堆BYE?
SRVCC切換失敗后返回LTE的流程是怎樣的？
“被叫不會(huì)發(fā)生bSRVCC”的說法對(duì)嗎？
這些問題吶，總是才下眉頭又上心頭，讓人吃不好飯睡不好覺~~~
現(xiàn)在我們一起來捋一捋這些問題的答案究竟是什么！
聲明：本文原創(chuàng)發(fā)布于微信公眾號(hào)《流鯊集結(jié)號(hào)》，轉(zhuǎn)載請(qǐng)保留來源信息。
文中所有流程圖，均使用流鯊軟件制圖，關(guān)于流鯊軟件的信息請(qǐng)?jiān)谖⑿殴娞?hào)中獲取。
友情提醒：流程圖看不清楚的，記得點(diǎn)擊圖片看無碼高清大圖。
SRVCC是個(gè)什么鬼？
首先它是個(gè)語音業(yè)務(wù)的連續(xù)性方案，其次它是個(gè)切換技術(shù)，用來在Volte和23g-CS話音呼叫之間切換，彌補(bǔ)LTE部署早期由于覆蓋不完善而帶來的問題。
針對(duì)不同的場(chǎng)景，有以下幾種SRVCC類型：
Common Name | 3GPP Release | Description
|
Basic SRVCC | Rel 8 | Call Continuity from E-UTRAN to UTRAN/GRAN |
bSRVCC | Rel 10? | Packet switched to Circuit Switched call transfer during pre-alerting Phase |
aSRVCC | Rel 10 | Packet switched to Circuit Switched call transfer during Alerting Phase |
eSRVCC | Rel 10 | Enhanced SRVCC (Support for MSC Server assisted Mid Call Feature) |
vSRVCC | Rel 11 | Video SRVCC |
rSRVCC | Rel 11 | SRVCC from UTRAN/GRAN to E-UTRAN |
當(dāng)終端和網(wǎng)絡(luò)都支持vSRVCC以后，視頻呼叫才可以支持SRVCC切換。
當(dāng)終端和網(wǎng)絡(luò)都支持rSRVCC以后，終端才能夠在通話狀態(tài)下由23g切換回LTE。
a/b/e三種SRVCC如何區(qū)分？
它們是針對(duì)發(fā)生在呼叫的不同階段而定義的SRVCC切換，如下圖所示：
有位同學(xué)提問：在專載建立前也沒振鈴呢，這時(shí)候發(fā)生SRVCC切換應(yīng)該屬于bSRVCC了吧？
NO，在專載建立前根本不會(huì)啟動(dòng)測(cè)量、不會(huì)發(fā)生B2、不會(huì)觸發(fā)SRVCC。
到底是aSRVCC還是bSRVCC？
看了前面的流程圖，似乎區(qū)分aSRVCC和bSRVCC很容易嘛！
其實(shí)不然，因?yàn)檫@是理論而已，我們來實(shí)踐一下：”翠花，上流鯊！ “
這是一個(gè)比較偶然的案例，Ringing和SRVCC的觸發(fā)時(shí)間非常接近，Ringing送回主叫的時(shí)間與eMSC返回SRVCC HO Response之前的時(shí)間重疊，兩個(gè)事件的時(shí)間軸重合，使我們可以更清晰地觀察這個(gè)時(shí)刻。
顯然Ringing消息并不是同時(shí)送達(dá)所有網(wǎng)元的，SRVCC事件也不是同時(shí)告知所有網(wǎng)元的，它們分別觸發(fā)，然后都沿著各自的路徑順次經(jīng)過各個(gè)網(wǎng)元，如果網(wǎng)元以各自的視角（時(shí)鐘）來看，eMSC認(rèn)為是bSRVCC，ATCF/SBC認(rèn)為是aSRVCC，SCC-AS認(rèn)為是aSRVCC，意見相當(dāng)?shù)牟唤y(tǒng)一吖！
如果不是因?yàn)楸唤忻Γǖ?24幀），呼叫可能早已接通，那ATCF/SBC和SCC-AS既不會(huì)認(rèn)為是aSRVCC也不會(huì)認(rèn)為是bSRVCC，而是判斷為eSRVCC了。
當(dāng)事件發(fā)生時(shí)，并不是所有的網(wǎng)元都同時(shí)知曉，因?yàn)槭录膫鞑バ枰獣r(shí)間，此時(shí)各網(wǎng)元在某種意義上似乎處在不同的時(shí)空中。
一種觀點(diǎn)是，由SCC-AS來判定到底是那種SRVCC，SCC-AS會(huì)通過INFO來通知ATCF/SBC與eMSC自己的判定結(jié)果。但是也有實(shí)際例子證明，這個(gè)INFO的信息也并沒有像規(guī)范所定義的那樣清晰和靠譜。現(xiàn)網(wǎng)各網(wǎng)元對(duì)bSRVCC的支持需要升級(jí)，在未升級(jí)前就會(huì)把bSRVCC判斷成aSRVCC，這也導(dǎo)致了基于實(shí)際案例進(jìn)行分析會(huì)遭遇各種混亂。
做個(gè)總結(jié)：網(wǎng)元會(huì)根據(jù)自己掌握的信息做出判斷，并執(zhí)行自己當(dāng)前版本所支持的轉(zhuǎn)接類型，也許這種轉(zhuǎn)接最后的結(jié)果會(huì)掉話（比如SCC-AS把b當(dāng)成a）。至于到底是b還是a，取決于網(wǎng)元的具體實(shí)現(xiàn)邏輯，它能夠處理就好，非要在全局做出一個(gè)嚴(yán)格的認(rèn)定可能并沒有現(xiàn)實(shí)的意義。
aSRVCC變成了bSRVCC的案例
SCC-AS已經(jīng)收到180，按理可以確定是aSRVCC，但是SCC-AS的邏輯是，振鈴必須在雙方資源預(yù)留完成之后。因?yàn)橛胁殊彉I(yè)務(wù)過程的存在，之后SCC-AS又收到Update，此時(shí)remote側(cè)的資源還沒有完成預(yù)留，如果此時(shí)發(fā)生SRVCC，SCC-AS會(huì)認(rèn)為是bSRVCC。
除了彩鈴，呼叫等待也會(huì)發(fā)生類似的情況，因?yàn)樗鼈兌际窍萿pdate再180。
在本案例中， SCC-AS在主叫側(cè)返回的183中攜帶了Feature-Caps信息，表明支持aSRVCC但不支持bSRVCC，因此發(fā)Cancel取消會(huì)話，攜帶原因?yàn)?em>"No appropriate session for SRVCC/eSRVCC"。
SRVCC完成后，如何釋放源側(cè)資源？
- 當(dāng)呼叫已經(jīng)建立時(shí)，通過BYE釋放源側(cè)資源
- 當(dāng)呼叫還未建立時(shí)，對(duì)被叫側(cè)資源，SCCAS通過發(fā)Cancel釋放（相當(dāng)于SCCAS扮演了主叫）
- 當(dāng)呼叫還未建立時(shí)，對(duì)主叫側(cè)資源，SCCAS通過發(fā)404釋放（相當(dāng)于SCCAS扮演了被叫）
當(dāng)UE轉(zhuǎn)接后還能夠使用Gm接口時(shí)，可能會(huì)收到這個(gè)SIP消息（否則得回到LTE以后才能收到，這也同時(shí)回答了這樣的問題： “終端返回LTE時(shí)，為何有時(shí)候會(huì)收到一堆上次會(huì)話的SIP消息” ）。
SCC-AS通過計(jì)時(shí)器延遲對(duì)該SIP消息的發(fā)送，在計(jì)時(shí)器超時(shí)前允許UE取消SRVCC返回LTE繼續(xù)剛才的會(huì)話。
eSRVCC失敗后返回LTE的案例
這個(gè)案例是UE在執(zhí)行eSRVCC過程中取消切換，又返回了LTE，發(fā)送re-INVITE恢復(fù)了之前在LTE的leg。
這里我們可以看到，在eSRVCC取消之后，BYE也用來釋放在eMSC+ATCF轉(zhuǎn)接時(shí)建立的leg。在此我們可以推斷: 如果是a或bSRVCC切換被取消，主叫側(cè)會(huì)通過404、被叫側(cè)會(huì)通過Cancel來釋放在eMSC+ATCF轉(zhuǎn)接時(shí)建立的leg。原因請(qǐng)參見上一部分《SRVCC完成后，如何釋放源側(cè)資源》。
bSRVCC切換失敗后返回LTE的案例
在呼叫建立階段發(fā)生bSRVCC，之后切換失敗返回LTE，UE發(fā)送UPDATE，攜帶原因（Reason: SIP ;cause=487 ;text="failure to transition to CS domain"） 。
為何會(huì)陷入沒完沒了的SRVCC？
這是一個(gè)非常典型的案例，很多同學(xué)們都遇到了在幾十分鐘內(nèi)上百次的“前仆后繼”的SRVCC失敗，在查不清楚原因的時(shí)候，往往歸咎于終端出毛病了（這也是很常見的背鍋邏輯，核心怪無線、無線怪終端）。
分析困難的主要原因是，同學(xué)們沒有條件看到整個(gè)流程的全貌，如果能把IMS+EPC的全流程再加上軟采信令，呈現(xiàn)一個(gè)相對(duì)而言更完整的流程，就可以馬上找到原因，原因很簡單：頻繁SRVCC都是B2觸發(fā)，而專載的存在是進(jìn)行測(cè)量的前提，因此問題都出在專載上。
在本案例中，BYE和SRVCC同時(shí)發(fā)起，會(huì)話管理要求釋放專載，而SRVCC則要求切換期間鎖定專載，因?yàn)?strong>移動(dòng)管理優(yōu)先于會(huì)話管理，因此S1_erab-release_response返回失敗，原因是”radio Network: s1-inter-system-handover-triggered”，也就是說：SRVCC阻止了專載的釋放。由于專載一直存在，所以測(cè)量一直繼續(xù)，只要符合閾值就會(huì)觸發(fā)SRVCC，早在BYE的時(shí)候呼叫已經(jīng)釋放，因此SRVCC 失敗。只要無線質(zhì)差不斷地觸發(fā)B2，就會(huì)陷入頻繁SRVCC的境地，直到由于其它原因釋放了專載。
流程沖突引發(fā)頻繁SRVCC的其它案例
呼叫釋放時(shí)的沖突（SRVCC的同時(shí)BYE），本案例陷入了頻繁SRVCC （SIP: 404 Not Found）
呼叫釋放時(shí)的沖突（SRVCC的同時(shí)BYE），本案例陷入了頻繁SRVCC，S11的DBR返回錯(cuò)誤S1-Bearer釋放失敗，失敗原因是“Cause : Temporarily rejected due to handover procedure in progress (110)” 。
呼叫釋放時(shí)的沖突（SRVCC的同時(shí)被叫Decline），本案例陷入了頻繁SRVCC
呼叫釋放時(shí)的沖突（SRVCC的同時(shí)主叫Cancel），本案例陷入了頻繁SRVCC（SIP: 410 Gone）
一個(gè)特殊的bSRVCC成功案例
專家解說：EMSC并沒有precondition的邏輯，在此例中，SCC AS代替EMSC去發(fā)呼叫流程的update消息，如果沒有這個(gè)update，MGCF的Tqos定時(shí)器就會(huì)超時(shí)，呼叫就會(huì)釋放。
被叫也會(huì)發(fā)生bSRVCC，但是不被支持
SCC-AS返回該呼叫不支持bSRVCC (“Handover fails because the call does not support bSRVCC”)。
注意：不是SCC-AS不支持bSRVCC，當(dāng)SCC-AS不支持bSRVCC時(shí)，也不會(huì)識(shí)別出bSRVCC。
本案例是CS呼叫VOLTE、被叫側(cè)發(fā)生bSRVCC的場(chǎng)景，SCC-AS直接拒絕了該切換。
規(guī)范對(duì)于被叫的bSRVCC并沒有提供支持，所以發(fā)生時(shí)一定會(huì)失敗。此外按照規(guī)范描述，還有一個(gè)一定會(huì)失敗的場(chǎng)景，當(dāng)主叫已經(jīng)存在兩個(gè)confirmed呼叫時(shí)(一個(gè)Active一個(gè)Inactive)，第三個(gè)呼叫不論是aSRVCC還是bSRVCC都會(huì)失�。ㄖ苯俞尫诺簦�
喜歡本文的同學(xué)們，請(qǐng)留下你的點(diǎn)贊 
有不同觀點(diǎn)的同學(xué)們，請(qǐng)留下你的文字 
路過的同學(xué)們，請(qǐng)留下你的足跡
想業(yè)余時(shí)間上個(gè)補(bǔ)習(xí)班的同學(xué)們，來流鯊信令分析大學(xué)堂QQ群吧（54825631, 316429471, 193964716, 575651131）
最后別忘記，打開微信，關(guān)注我們的公眾號(hào)：流鯊集結(jié)號(hào)
二維碼請(qǐng)看簽名或頭像
邀請(qǐng)看到這里的同學(xué)們，都去幫忙投個(gè)票！
論壇內(nèi)投票鏈接如下：http://gg1fic3.cn/bbs/thread-665370-1-1.html、
《不打醬油，積極參與，信令分析神器流鯊的使用情況調(diào)查》
[[i] 本帖最后由 kinghighland 于 2016-12-9 10:58 編輯 [/i]]
關(guān)注樓主