VOLTE信令流程VOLTE是基于SIP協(xié)議的語(yǔ)音通話，所有與IMS交互的信令全部為SIP信令，在理解VOLTE信令方面必須對(duì)SIP信令進(jìn)行了解，EPC只是做為業(yè)務(wù)承載體。由于SIP信令是以加密方式傳輸，SIP信令只有在CN側(cè)和終端側(cè)才能解碼，基站CDL無(wú)法記錄SIP信令，同時(shí)CDL無(wú)法解碼較多NAS層直傳消息，所以本文中的信令說(shuō)明部分不結(jié)合CDL信令進(jìn)行說(shuō)明1. 注冊(cè)流程及重要信令詳解SIP 提供了發(fā)現(xiàn)機(jī)制，如果用戶(hù)要發(fā)起和另一個(gè)用戶(hù)的會(huì)話，SIP 必須發(fā)現(xiàn)可到達(dá)目的用戶(hù)的當(dāng)前主機(jī)，注冊(cè)將記錄地址 URI 和一個(gè)或者多個(gè)聯(lián)系地址相關(guān)聯(lián)，這樣才能進(jìn)行呼叫等業(yè)務(wù)。嚴(yán)格意義上說(shuō)，SUBSCRIBE和NOTIFY過(guò)程不屬于注冊(cè)過(guò)程，但由于該過(guò)程在注冊(cè)完成后緊跟著出現(xiàn)，所以本文將該過(guò)程放在注冊(cè)流程中進(jìn)行說(shuō)明。用戶(hù)的注銷(xiāo)過(guò)程與注冊(cè)過(guò)程相似，主要就是注銷(xiāo)請(qǐng)求中,expire值為0，所以本文中不再進(jìn)行單獨(dú)說(shuō)明，注銷(xiāo)過(guò)程無(wú)SUBSCRIBE信令，是因?yàn)閁E注冊(cè)時(shí)已有SUBSCRIBE。信令說(shuō)明如下：1. UE進(jìn)行Attach，建立QCI=9的默認(rèn)承載，并使用IMS APN建立PDN連接；2. 建立立QCI=5的默認(rèn)承載，用于傳送SIP信令；3. UE通過(guò)QCI=5的默認(rèn)承載向IMS發(fā)起注冊(cè)請(qǐng)求；4. P-CSCF通過(guò)HSS獲知用戶(hù)信息不在數(shù)據(jù)庫(kù)中，便向終端代理回送401 Unauthorized 質(zhì)詢(xún)信息，其中包含安全認(rèn)證所需的令牌；5. 終端將用戶(hù)標(biāo)識(shí)和密碼根據(jù)安全認(rèn)證令牌加密后，再次用REGISTER消息報(bào)告給P-CSCF服務(wù)器；6. P-CSCF將REGISTER 消息中的用戶(hù)信息解密，驗(yàn)證其合法后，IMS核心網(wǎng)將該用戶(hù)信息登記到數(shù)據(jù)庫(kù)中，并向終端返回成功響應(yīng)消息200 OK；7. 用戶(hù)向IMS訂閱注冊(cè)事件包8. 服務(wù)器應(yīng)答訂閱成功9. IMS服務(wù)器發(fā)送notify消息，由于訂閱的用戶(hù)已經(jīng)注冊(cè)，所以IMS服務(wù)器回應(yīng)Notify消息中，狀態(tài)為active，同時(shí)攜帶XML信息10. 終端發(fā)送Notify 200表示接收成功注冊(cè)過(guò)程測(cè)試信令載圖如下：注銷(xiāo)過(guò)程測(cè)試信令截圖如下：1) Activate Default EPS Bearer Context Request（QCI=5）該信令是用于建立QCI=5的默認(rèn)承載，所有SIP信令都通過(guò)QCI=5的承載傳輸，該信令的內(nèi)容已在該信令前的RRC重配置中附帶下來(lái)。主要說(shuō)明如下：該信令中主要是關(guān)注QCI等級(jí)，必須是QCI=5，才能傳輸SIP信令，ERAB ID=62) REGISTER(1ST Sip Register Request)& REGISTER 401（Unauthorized）REGISTER信令是用于網(wǎng)絡(luò)注冊(cè)，建立關(guān)聯(lián)主要說(shuō)明如下：這是用戶(hù)的第一個(gè)REGISTER REQUST信令，所以鑒權(quán)方面部分內(nèi)容為空，需要網(wǎng)絡(luò)回應(yīng)后才能補(bǔ)齊REGISTER 401信令是用于向終端回送401 Unauthorized 質(zhì)詢(xún)信息，其中包含安全認(rèn)證所需的令牌，令牌對(duì)應(yīng)用戶(hù)第一個(gè)REGISTER REQUST信令中鑒權(quán)摘要為空的部分，并指明算法，主要說(shuō)明如下： 3) REGISTER(2nd Sip Register Request)& REGISTER 200第二條Register信令是終端將用戶(hù)標(biāo)識(shí)和密碼根據(jù)安全認(rèn)證令牌加密后回送給服務(wù)器主要說(shuō)明如下：REGISTER 200信令是用是確認(rèn)注冊(cè)流程完成，并生成SIP-URI和TEL URI，3GPP TS 23.003定義了三種URI如下，VOLTE中使用了后面兩種：Alphanumeric SIP-URIs Example: sip:voicemail MSISDN represented as a SIP URI: Example: sip:+447700900123;user=phone MSISDN represented as a Tel URI: Example: tel:+447700900123：REGISTER 200信令截圖如下：4) SUBSCRIBE& NOTIFYSUBSCRIBE是一個(gè)用來(lái)請(qǐng)求對(duì)方節(jié)點(diǎn)的當(dāng)前狀態(tài)以及后續(xù)狀態(tài)變化的請(qǐng)求方法,從網(wǎng)絡(luò)訂閱消息，NOTIFY是用于向服務(wù)器請(qǐng)求返回當(dāng)前狀態(tài)消息。VOLTE中典型的消息流如下：如果訂閱過(guò)期了，就必須發(fā)起新的SUBSCRIBE來(lái)進(jìn)行訂閱SUBSCRIBE CDS信令截圖如下：SUBSCRIBE 200 CDS信令截圖如下網(wǎng)絡(luò)通過(guò)NOTIFY向UE發(fā)送訂閱的內(nèi)容，UE通過(guò)NOTIFY 200確認(rèn)已收到，NOTIFY的CDS信令截圖如下：2. 語(yǔ)音通話流程及重要信令詳解語(yǔ)音呼叫過(guò)程就是為典型的SIP通話過(guò)程，經(jīng)過(guò)多個(gè)修改，基本已經(jīng)定型。由于VOLTE呼叫其它通話制式的手機(jī)時(shí)，VOLTE終端側(cè)的信令未有變化，所以本文中不會(huì)進(jìn)行說(shuō)明。CDS軟件信令截圖如下：呼叫流程圖如下：信令說(shuō)明如下：11到6，UE起呼，UE高層協(xié)議層需要發(fā)送INVITE到IMS，觸發(fā)RRC連接、安全模式等過(guò)程，并通過(guò)RRC重配置消息建立SRB2信令無(wú)線承載、恢復(fù)QCI 5承載，配置測(cè)量控制，IMS收到主叫的INITE消息，開(kāi)始尋呼，并發(fā)送INVITE 100（TRYING）給主叫UE，用于響應(yīng)INVITE消息，INVITE消息中包含呼叫類(lèi)型、主被叫的號(hào)碼、主叫方支持的媒體類(lèi)型和編碼等；27到15，核心網(wǎng)向處于空閑態(tài)的被叫發(fā)INVITE消息，由于被叫處于空閑態(tài)，所以核心網(wǎng)側(cè)觸發(fā)尋呼消息，尋呼處于空閑態(tài)的被叫用戶(hù)，被叫UE收到尋呼后，觸發(fā)RRC連接、安全模式等過(guò)程，被叫通過(guò)RRC重配置消息建立SRB2信令無(wú)線承載，CN側(cè)通過(guò)QCI=5的RB向被叫發(fā)送INVITE消息，UE收到后發(fā)送INVITE 100消息進(jìn)行響應(yīng)，同時(shí)被叫發(fā)送INVITE 183消息給CN表示會(huì)話正在處理，啟動(dòng)Precondition(資源預(yù)留)過(guò)程，并通知主叫自己所支持的媒體類(lèi)型和編碼，并建立起QCI=1的承載；3. 16到17，IMS收到被叫的INVITE 83 后，對(duì)主叫啟動(dòng)Precondition(資源預(yù)留)過(guò)程，通過(guò)EPC通知主叫SM層建立起QCI=1的承載后，向UE發(fā)送INVITE 183消息；418到25，主叫向被叫發(fā)送PRACK消息，PRACK過(guò)程是一個(gè)預(yù)確認(rèn)過(guò)程，主要為了防止會(huì)話超時(shí)及擁塞，被叫收到后返回PRACK 200，主叫收到被叫的PRACK 200以后，發(fā)送UPDATE消息，進(jìn)行媒體格式協(xié)商過(guò)程，被叫通過(guò)UPDATE 200返回協(xié)商結(jié)果；5. 26到31是振鈴接聽(tīng)過(guò)程，被叫發(fā)送INVITE 180給主叫，振鈴，摘機(jī)后發(fā)送INVITE 200給主叫，主叫返回ACK進(jìn)行確認(rèn)，通話完全建立，進(jìn)入通話過(guò)程；6. 32到37為掛機(jī)過(guò)程 ，通話結(jié)束后，主叫發(fā)送BYE請(qǐng)求結(jié)束本次會(huì)話，IMS服務(wù)器給被叫發(fā)送BYE,請(qǐng)求結(jié)束本次會(huì)話，被叫掛機(jī)，回BYE 200消息，核心網(wǎng)IMS服務(wù)器給主叫發(fā)BYE 200，標(biāo)明會(huì)話結(jié)束，主被叫分別去激活EPS專(zhuān)用承載消息，刪除QCI=1的數(shù)據(jù)無(wú)線承載。1) INVITEINVITE是發(fā)起會(huì)話邀請(qǐng)，在VOLTE中就是用于起呼，INVITE消息中主要包含了主叫信息、被叫號(hào)碼和主叫支持的格式信令截圖如下：2) RRCConnectionReconfiguration （QCI=1）該信令對(duì)應(yīng)流程中的步驟13、14的RRCConnectionReconfiguration，在核心網(wǎng)下發(fā)“Activate Dedicated EPS Bearer Context Request”消息后，基站將該消息附加在“RRCConnectionReconfiguration”消息中一起下發(fā)，所以“RRCConnectionReconfiguration”中解碼出來(lái)的“Activate Dedicated EPS Bearer Context Request”消息內(nèi)容，與后續(xù)的“Activate Dedicated EPS Bearer Context Request”消息內(nèi)容一致。 主要說(shuō)明如下：1. 在pdcp-ConfigheaderCompression可以查到頭壓縮的的相關(guān)配置，主要內(nèi)容為頭壓縮使用的方案格式；2. 在mac-MainConfig節(jié)點(diǎn)下可以查到ttiBundling功能是否開(kāi)啟；3. 在該消息中如果查不到關(guān)于SPS的IE，則說(shuō)明SPS為關(guān)閉狀態(tài)；如果SPS開(kāi)啟，SPS在信令中的格式如下：3) UPDATE & UPDATE 200UPDATE主要是用于在呼叫過(guò)程中進(jìn)行媒體格式的二次協(xié)商，UPDATE 200消息是對(duì)UPDATE消息的確認(rèn)，UPDATE 200消息中協(xié)商結(jié)果為雙方通話使用的通話格式，通常選取主被叫雙方中格式中較低的一種，主被叫雙方根據(jù)協(xié)商結(jié)果，通過(guò)“Modify EPS Bearer Context Request”消息對(duì)EPS承載進(jìn)行相應(yīng)的修改。在UPDATE消息中攜帶了主要建議的語(yǔ)音編碼格式，好點(diǎn)正常語(yǔ)音業(yè)務(wù)上下行各占用2個(gè)PRB左右，標(biāo)清語(yǔ)音和高清語(yǔ)音資源占用基本相同，但差點(diǎn)標(biāo)清PRB占用數(shù)會(huì)少一些，未來(lái)移動(dòng)也有可能推廣標(biāo)清語(yǔ)音。在收到的UPDATE 200消息中的編碼格式為最終格式，截圖如下：如果呼叫2/3G、固話等，協(xié)商結(jié)果為2/3G、固定電話的編碼為準(zhǔn)，例如下圖中為呼叫2G的UPDATE 200消息，協(xié)商結(jié)果使用AMR-NB的編碼格式4) 視頻通話流程與語(yǔ)音通話流程的異同視頻電話與語(yǔ)音通話過(guò)程基本相同，其中最主要的區(qū)別是需要建立QCI=1和QCI=2的承載，QCI=1傳送語(yǔ)音，QCI=2傳送視頻，視頻電話的信令截圖如下,其中需要注意的是正常結(jié)束后會(huì)去激活兩個(gè)承載。主要區(qū)別如下：1. 語(yǔ)音業(yè)務(wù)INVITE消息中，呼叫的原因?yàn)檎Z(yǔ)音，只攜帶支持的語(yǔ)音編碼格式，視頻業(yè)務(wù)的INVITE中呼叫原因?yàn)橐曨l，并攜帶了主叫支持的視頻編碼格式。 2. 視頻業(yè)務(wù)需要建立兩條業(yè)務(wù)承載，QCI=1和QCI=2,這與3G的視頻電視只建議一個(gè)承載不同，同時(shí)視頻業(yè)務(wù)釋放時(shí)需要釋放兩條承載；3. eSRVCC切換及重要信令詳解VOLTE系統(tǒng)內(nèi)切換與R8/9的切換相同，所以本文只針對(duì)eSRVCC切換流程進(jìn)行說(shuō)明；SRVCC切換流程在3GPP協(xié)議TS 23.216里定義，有多種SRVCC流程，本文介紹的是“SRVCC from E-UTRAN to GERAN without DTM support ”流程。eSRVCC切換過(guò)程比較簡(jiǎn)單，與TD-SCDMA中的CS系統(tǒng)間切換流程相似，通過(guò)對(duì)比可以加深理解。eSRVCC的主要流程為A2B2HORELEASE，目前移動(dòng)公司的策略是從LTE切向GERAN，本文只說(shuō)明LTE向GERAN的SRVCC切換過(guò)程。測(cè)試軟件UU口信令截圖如下：CDL解碼截圖如下：信令流程如下： 信令說(shuō)明只說(shuō)明UU口和S1口的信令，其它步驟詳細(xì)說(shuō)明見(jiàn)本節(jié)最后面的附件或查詢(xún) TS 23.216的6.2.2.1，主要說(shuō)明如下：1. 步驟1 UE上報(bào)B2報(bào)告，基站會(huì)發(fā)起切換判決，這里有兩個(gè)注意事項(xiàng)，必須UE和CN側(cè)均支持SRVCC切換，基站RRM才會(huì)有步驟2判決進(jìn)行SRVCC切換，否則判決為重定向，詳見(jiàn)本文4.3.1；2. 步驟3 eNodeB向源MME發(fā)送Handover Required消息，該消息中包含括Target ID（多為CGI）、generic Source to Target Transparent Container、 SRVCC切換指示等。SRVCC HO 指標(biāo)標(biāo)明切換目標(biāo)只是CS域；3. 步驟 14和15，MME和目標(biāo)MSC、IMS等經(jīng)過(guò)一系統(tǒng)交互過(guò)程后，完成PS到CS的轉(zhuǎn)換過(guò)程及目標(biāo)小區(qū)資源預(yù)留后，MME向eNodeB發(fā)送 Handover Command， eNodeB通過(guò)MobilityFromEUTRACommand通知UE進(jìn)行切換。4. 步驟16到18，UE切換到GSM,進(jìn)行同步過(guò)程，同步后UE發(fā)現(xiàn)Suspend過(guò)程，對(duì)GPRS業(yè)務(wù)掛起，后續(xù)CN側(cè)會(huì)數(shù)據(jù)業(yè)務(wù)掛起及通知MME進(jìn)行鏈路釋放等一系列過(guò)程，切換完成。如果在CS 語(yǔ)音結(jié)束后UE還在GERAN(or for any other reason specified in TS24.008), UE則需要按照TS23.060規(guī)定恢復(fù)PS業(yè)務(wù). GN SGSN將按照TS 23.060 規(guī)定恢復(fù)PDP上下文， S4 SGSN將按照TS 23.060 規(guī)定恢復(fù)承載，并且通知S- GW和P-GW(s)恢復(fù)暫停的承載；如果UE在CS語(yǔ)音呼叫終止后已經(jīng)返回到E-UTRAN，則UE必須通過(guò)發(fā)送TAU向MME恢復(fù)PS服務(wù)， MME將通知S-GW and P-GW(s)恢復(fù)掛起的承載，恢復(fù)在S-GW和P-GW中掛起的承載，應(yīng)該通過(guò)使用某種操作觸發(fā)Modify Bearer request消息進(jìn)行隱式恢復(fù)，例如RAU、TAU 或Service Request。S- GW知道承載的暫停狀態(tài)，并且將轉(zhuǎn)發(fā)Modify Bearer request消息到P- GW，如果Modify Bearer Request不是由某類(lèi)操作觸發(fā)時(shí)，直接恢復(fù)必須使用恢復(fù)指示消息。1) Attach Request& Initial Context Setup Request Attach Request信令與Attach過(guò)程中的 Initial Context Setup Request信令分別包含了UE和網(wǎng)絡(luò)的SRVCC能力，這是進(jìn)行SRVCC的必要條件。主要說(shuō)明如下：從Attach Request信令中可以得到UE對(duì)SRVCC的能力，消息中其它內(nèi)容與平常的信令相同，UE將 SRVCC capability indication作為“UE Network Capability”的一部分包含在Attach Request message/Tacking Area updaterequest中發(fā)送給MMEInitial Context Setup Request：注意該消息必須是在Attach過(guò)程中的消息才攜帶SRVCC能力部分。注意事項(xiàng)：1. 1、SRVCC與SIM卡簽約業(yè)務(wù)有關(guān)，HSS向MME指示UE的簽約信息（STN-SR）是否支持SRVCC