《VoLTE信令流程詳解[共26頁]》由會員分享，可在線閱讀，更多相關《VoLTE信令流程詳解[共26頁]（27頁珍藏版）》請在裝配圖網上搜索。

1、 VOLTE信令流程 VOLTE是基于SIP協議的語音通話，所有與IMS交互的信令全部為SIP信令，在理解VOLTE信令方面必須對SIP信令進行了解，EPC只是做為業(yè)務承載體。由于SIP信令是以加密方式傳輸，SIP信令只有在CN側和終端側才能解碼，基站CDL無法記錄SIP信令，同時CDL無法解碼較多NAS層直傳消息，所以本文中的信令說明部分不結合CDL信令進行說明 1. 注冊流程及重要信令詳解 SIP 提供了發(fā)現機制，如果用戶要發(fā)起和另一個用戶的會話，SIP 必須發(fā)現可到達目的用戶的當前主機，注冊將記錄地址 URI 和一個或者多個聯系地址相關聯，這樣才能進行呼叫等業(yè)務。 嚴格意義上說

2、，SUBSCRIBE和NOTIFY過程不屬于注冊過程，但由于該過程在注冊完成后緊跟著出現，所以本文將該過程放在注冊流程中進行說明。用戶的注銷過程與注冊過程相似，主要就是注銷請求中,expire值為0，所以本文中不再進行單獨說明，注銷過程無SUBSCRIBE信令，是因為UE注冊時已有SUBSCRIBE。 信令說明如下： 1. UE進行Attach，建立QCI=9的默認承載，并使用IMS APN建立PDN連接； 2. 建立立QCI=5的默認承載，用于傳送SIP信令； 3. UE通過QCI=5的默認承載向IMS發(fā)起注冊請求； 4. P-CSCF通過HSS獲知用戶信息不在數據庫中，便向終

3、端代理回送401 Unauthorized 質詢信息，其中包含安全認證所需的令牌； 5. 終端將用戶標識和密碼根據安全認證令牌加密后，再次用REGISTER消息報告給P-CSCF服務器； 6. P-CSCF將REGISTER 消息中的用戶信息解密，驗證其合法后，IMS核心網將該用戶信息登記到數據庫中，并向終端返回成功響應消息200 OK； 7. 用戶向IMS訂閱注冊事件包 8. 服務器應答訂閱成功 9. IMS服務器發(fā)送notify消息，由于訂閱的用戶已經注冊，所以IMS服務器回應Notify消息中，狀態(tài)為active，同時攜帶XML信息 10. 終端發(fā)送Notify 200表示接

4、收成功 注冊過程測試信令載圖如下： 注銷過程測試信令截圖如下： 1) Activate Default EPS Bearer Context Request（QCI=5） 該信令是用于建立QCI=5的默認承載，所有SIP信令都通過QCI=5的承載傳輸，該信令的內容已在該信令前的RRC重配置中附帶下來。 主要說明如下： 該信令中主要是關注QCI等級，必須是QCI=5，才能傳輸SIP信令，ERAB ID=6 2) REGISTER(1ST Sip Register Request)& REGISTER 401（Unauthorized） REGISTER信令是用于網絡注

5、冊，建立關聯 主要說明如下： 這是用戶的第一個REGISTER REQUST信令，所以鑒權方面部分內容為空，需要網絡回應后才能補齊 REGISTER 401信令是用于向終端回送401 Unauthorized 質詢信息，其中包含安全認證所需的令牌，令牌對應用戶第一個REGISTER REQUST信令中鑒權摘要為空的部分，并指明算法，主要說明如下： 3) REGISTER(2nd Sip Register Request)& REGISTER 200 第二條Register信令是終端將用戶標識和密碼根據安全認證令牌加密后回送給服務器 主要說明如下： REGISTER

6、200信令是用是確認注冊流程完成，并生成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)

7、SUBSCRIBE& NOTIFY SUBSCRIBE是一個用來請求對方節(jié)點的當前狀態(tài)以及后續(xù)狀態(tài)變化的請求方法,從網絡訂閱消息，NOTIFY是用于向服務器請求返回當前狀態(tài)消息。 VOLTE中典型的消息流如下： 如果訂閱過期了，就必須發(fā)起新的SUBSCRIBE來進行訂閱 SUBSCRIBE CDS信令截圖如下： SUBSCRIBE 200 CDS信令截圖如下 網絡通過NOTIFY向UE發(fā)送訂閱的內容，UE通過NOTIFY 200確認已收到，NOTIFY的CDS信令截圖如下： 2. 語音通話流程及重要信令詳解 語音呼叫過程就是為典型的SIP通話過程，經過多個修

8、改，基本已經定型。由于VOLTE呼叫其它通話制式的手機時，VOLTE終端側的信令未有變化，所以本文中不會進行說明。 CDS軟件信令截圖如下： 呼叫流程圖如下： 信令說明如下： 1．1到6，UE起呼，UE高層協議層需要發(fā)送INVITE到IMS，觸發(fā)RRC連接、安全模式等過程，并通過RRC重配置消息建立SRB2信令無線承載、恢復QCI 5承載，配置測量控制，IMS收到主叫的INITE消息，開始尋呼，并發(fā)送INVITE 100（TRYING）給主叫UE，用于響應INVITE消息，INVITE消息中包含呼叫類型、主被叫的號碼、主叫方支持的媒體類型和編碼等； 2．7到15，核心網向處于

9、空閑態(tài)的被叫發(fā)INVITE消息，由于被叫處于空閑態(tài)，所以核心網側觸發(fā)尋呼消息，尋呼處于空閑態(tài)的被叫用戶，被叫UE收到尋呼后，觸發(fā)RRC連接、安全模式等過程，被叫通過RRC重配置消息建立SRB2信令無線承載，CN側通過QCI=5的RB向被叫發(fā)送INVITE消息，UE收到后發(fā)送INVITE 100消息進行響應，同時被叫發(fā)送INVITE 183消息給CN表示會話正在處理，啟動Precondition(資源預留)過程，并通知主叫自己所支持的媒體類型和編碼，并建立起QCI=1的承載； 3. 16到17，IMS收到被叫的INVITE 83 后，對主叫啟動Precondition(資源預留)過程，通過EP

10、C通知主叫SM層建立起QCI=1的承載后，向UE發(fā)送INVITE 183消息； 4．18到25，主叫向被叫發(fā)送PRACK消息，PRACK過程是一個預確認過程，主要為了防止會話超時及擁塞，被叫收到后返回PRACK 200，主叫收到被叫的PRACK 200以后，發(fā)送UPDATE消息，進行媒體格式協商過程，被叫通過UPDATE 200返回協商結果； 5. 26到31是振鈴接聽過程，被叫發(fā)送INVITE 180給主叫，振鈴，摘機后發(fā)送INVITE 200給主叫，主叫返回ACK進行確認，通話完全建立，進入通話過程； 6. 32到37為掛機過程 ，通話結束后，主叫發(fā)送BYE請求結束本次會話，IMS服

11、務器給被叫發(fā)送BYE,請求結束本次會話，被叫掛機，回BYE 200消息，核心網IMS服務器給主叫發(fā)BYE 200，標明會話結束，主被叫分別去激活EPS專用承載消息，刪除QCI=1的數據無線承載。 1) INVITE INVITE是發(fā)起會話邀請，在VOLTE中就是用于起呼，INVITE消息中主要包含了主叫信息、被叫號碼和主叫支持的格式 信令截圖如下： 2) RRCConnectionReconfiguration （QCI=1） 該信令對應流程中的步驟13、14的RRCConnectionReconfiguration，在核心網下發(fā)“Activate Dedicated EPS

12、 Bearer Context Request”消息后，基站將該消息附加在“RRCConnectionReconfiguration”消息中一起下發(fā)，所以“RRCConnectionReconfiguration”中解碼出來的“Activate Dedicated EPS Bearer Context Request”消息內容，與后續(xù)的“Activate Dedicated EPS Bearer Context Request”消息內容一致。 主要說明如下： 1. 在pdcp-ConfigheaderCompression可以查到頭壓縮的的相關配置，主要內容為頭壓縮使用的方案格式； 2

13、. 在mac-MainConfig節(jié)點下可以查到ttiBundling功能是否開啟； 3. 在該消息中如果查不到關于SPS的IE，則說明SPS為關閉狀態(tài)； 如果SPS開啟，SPS在信令中的格式如下： 3) UPDATE & UPDATE 200 UPDATE主要是用于在呼叫過程中進行媒體格式的二次協商，UPDATE 200消息是對UPDATE消息的確認，UPDATE 200消息中協商結果為雙方通話使用的通話格式，通常選取主被叫雙方中格式中較低的一種，主被叫雙方根據協商結果，通過“Modify EPS Bearer Context Request”消息對EPS承載進行相應的修改。

14、 在UPDATE消息中攜帶了主要建議的語音編碼格式，好點正常語音業(yè)務上下行各占用2個PRB左右，標清語音和高清語音資源占用基本相同，但差點標清PRB占用數會少一些，未來移動也有可能推廣標清語音。 在收到的UPDATE 200消息中的編碼格式為最終格式，截圖如下： 如果呼叫2/3G、固話等，協商結果為2/3G、固定電話的編碼為準，例如下圖中為呼叫2G的UPDATE 200消息，協商結果使用AMR-NB的編碼格式 4) 視頻通話流程與語音通話流程的異同 視頻電話與語音通話過程基本相同，其中最主要的區(qū)別是需要建立QCI=1和QCI=2的承載，QCI=1傳送語音，QCI=2傳送視頻，

15、視頻電話的信令截圖如下,其中需要注意的是正常結束后會去激活兩個承載。 主要區(qū)別如下： 1. 語音業(yè)務INVITE消息中，呼叫的原因為語音，只攜帶支持的語音編碼格式，視頻業(yè)務的INVITE中呼叫原因為視頻，并攜帶了主叫支持的視頻編碼格式。 2. 視頻業(yè)務需要建立兩條業(yè)務承載，QCI=1和QCI=2,這與3G的視頻電視只建議一個承載不同，同時視頻業(yè)務釋放時需要釋放兩條承載； 3. eSRVCC切換及重要信令詳解 VOLTE系統內切換與R8/9的切換相同，所以本文只針對eSRVCC切換流程進行說明；SRVCC切換流程在3GPP協議TS 23.216里定義，有多種

16、SRVCC流程，本文介紹的是“SRVCC from E-UTRAN to GERAN without DTM support ”流程。eSRVCC切換過程比較簡單，與TD-SCDMA中的CS系統間切換流程相似，通過對比可以加深理解。eSRVCC的主要流程為A2B2HORELEASE，目前移動公司的策略是從LTE切向GERAN，本文只說明LTE向GERAN的SRVCC切換過程。 測試軟件UU口信令截圖如下： CDL解碼截圖如下： 信令流程如下： 信令說明只說明UU口和S1口的信令，其它步驟詳細說明見本節(jié)最后面的附件或查詢 TS 23.216的6.2.2.1，主要說明如下：

17、 1. 步驟1 UE上報B2報告，基站會發(fā)起切換判決，這里有兩個注意事項，必須UE和CN側均支持SRVCC切換，基站RRM才會有步驟2判決進行SRVCC切換，否則判決為重定向，詳見本文4.3.1； 2. 步驟3 eNodeB向源MME發(fā)送Handover Required消息，該消息中包含括Target ID（多為CGI）、generic Source to Target Transparent Container、 SRVCC切換指示等。SRVCC HO 指標標明切換目標只是CS域； 3. 步驟 14和15，MME和目標MSC、IMS等經過一系統交互過程后，完成PS到CS的轉換過程及目

18、標小區(qū)資源預留后，MME向eNodeB發(fā)送 Handover Command， eNodeB通過MobilityFromEUTRACommand通知UE進行切換。 4. 步驟16到18，UE切換到GSM,進行同步過程，同步后UE發(fā)現Suspend過程，對GPRS業(yè)務掛起，后續(xù)CN側會數據業(yè)務掛起及通知MME進行鏈路釋放等一系列過程，切換完成。 如果在CS 語音結束后UE還在GERAN(or for any other reason specified in TS24.008), UE則需要按照TS23.060規(guī)定恢復PS業(yè)務. GN SGSN將按照TS 23.060 規(guī)定恢復PDP上下文，

19、 S4 SGSN將按照TS 23.060 規(guī)定恢復承載，并且通知S- GW和P-GW(s)恢復暫停的承載；如果UE在CS語音呼叫終止后已經返回到E-UTRAN，則UE必須通過發(fā)送TAU向MME恢復PS服務， MME將通知S-GW and P-GW(s)恢復掛起的承載，恢復在S-GW和P-GW中掛起的承載，應該通過使用某種操作觸發(fā)Modify Bearer request消息進行隱式恢復，例如RAU、TAU 或Service Request。S- GW知道承載的暫停狀態(tài)，并且將轉發(fā)Modify Bearer request消息到P- GW，如果Modify Bearer Request不是由某類

20、操作觸發(fā)時，直接恢復必須使用恢復指示消息。 1) Attach Request& Initial Context Setup Request Attach Request信令與Attach過程中的 Initial Context Setup Request信令分別包含了UE和網絡的SRVCC能力，這是進行SRVCC的必要條件。 主要說明如下： 從Attach Request信令中可以得到UE對SRVCC的能力，消息中其它內容與平常的信令相同，UE將 SRVCC capability indication作為“UE Network Capability”的一部分包含在Attach Request message/Tacking Area updaterequest中發(fā)送給MME Initial Context Setup Request：注意該消息必須是在Attach過程中的消息才攜帶SRVCC能力部分。 注意事項： 1. 1、SRVCC與SIM卡簽約業(yè)務有關，HSS向MME指示UE的簽約信息（STN-SR）是否支持SRVCC