- 終端怎麼知道網絡支持VoLTE？
- 網絡怎麼知道終端支持VoLTE？
- 哪條NAS信令用於啓動建立IMS信令承載？
- IMS信令承載有哪些特點？
- 終端如何發現P-CSCF？
- 註冊的相關信令如何傳送到S-CSCF？
- 在註冊過程中VoLTE終端會向S-CSCF提供哪些信息？
- 在註冊成功後，VoLTE用戶會從S-CSCF得到哪些信息？
- 在IMS域中傳送端到端SIP信令需要解決哪四大問題？
- 業務數據包是如何在被叫之間傳送的？
- 建立專用業務承載需要考慮哪些因素？
- 什麼是資源預留？
- 無預留資源的呼叫流程是怎樣的？
- 預留資源的呼叫流程是怎樣的？
- 主叫方何時建立專用業務承載？
- 被叫方何時建立專用業務承載？
- 如何避免Ghost Call？
- 什麼是SRVCC？
- SRVCC涉及哪些測量事件？
- SRVCC的無線側處理過程涉及哪些步驟？
1,2.終端怎麼知道網絡支持VoLTE？網絡怎麼知道終端支持VoLTE？
確認VoLTE能力是VoLTE業務準備階段的第一項任務，終端通過附着過程的Attach Request消息告知MME是否支持VoLTE，而MME則通過附着過程的Attach Accept消息告知終端用戶網絡能否支持VoLTE。
Attach Request消息中的Voice Domain Preference參數用來指示終端的VoLTE能力，如果Voice Domain Preference參數設爲1或3，代表終端爲VoLTE終端。
Attach Accept消息中的EPS Network Feature Support部分用來指示網絡側的支持能力，包括緊急呼叫、位置服務和VoLTE，如果其中的IMS Voice over PS Session in S1 Mode參數設置爲1，代表網絡支持VoLTE;如果設爲0，代表網絡不支持VoLTE。
3.哪條NAS信令用於啓動建立IMS信令承載？
Activate Default EPS Bearer Context Request 消息的主要內容：
|
內容 |
說明 |
|
EPS承載的ID |
IMS默認承載的ID |
|
QoS參數 |
IMS默認承載的QCI設爲5，也就是最高優先級 |
|
IP地址 |
IMS域的IP地址，由PGW分配 |
|
APN |
IMS域的完整域名 |
|
APN聚合最高速率 |
簽約信息，來自HSS |
終端的承載：
|
類型 |
名稱 |
用途 |
APN |
QCI |
|
SRB |
信令承載1 |
RRC信令 |
|
|
|
SRB |
信令承載2 |
NAS信令 |
|
|
|
RB |
默認承載 |
數據業務 |
CMNET |
9 |
|
RB |
默認承載 |
SIP信令 |
IMS |
5 |
4.IMS信令承載有哪些特點？
5.終端如何發現P-CSCF？
VoLTE終端在PDN Connectivity Request 消息的PCO中，要求網絡側提供P-CSCF的IP地址。
MME收到請求後，通過SGW向PGW轉發了請求。於是PGW把P-CSCF的IP地址返回給MME，爲了增加可靠性，PGW還提供了兩個P-CSCF的IP地址。
MME在通過Active Default EPS Bearer Context Request 消息中的PCO，將兩個P-CSCF的IP地址發給終端，這樣就發現了P-CSCF的IP地址。
6.註冊的相關信令如何傳送到S-CSCF？
P-CSCF充當VoLTE終端SIP信令在IMS域的接口，註冊的信令先到達P-CSCF，P-CSCF通過DNS查詢到I-CSCF的地址，將信令轉發給I-CSCF，再由I-CSCF通過HSS定位到S-CSCF，將信令轉發給S-CSCF.經過P-CSCF和I-CSCF的接力，才實現了VoLTE終端與S-CSCF之間SIP信令的交互。
7.在註冊過程中VoLTE終端會向S-CSCF提供哪些信息？
REGISTER請求的主要內容：
|
項目 |
主要內容 |
|
註冊域 |
ims.mnc007.mcc460.3gppnetwork.org |
|
IMPI |
|
|
Cseq |
381260064 |
|
終端的IP地址 |
2409:8805:84c4:c9ff:28c2:ec0d:8302:ecae |
|
傳輸協議與端口 |
TCP:5060 |
|
業務能力 |
Audio;vedio |
|
支持的SIP請求 |
INVITE,BYE,CANCEL,ACK,NOTIFY,UPDATE,PRACK,INFO,MESSAGE,OPTIONS |
REGISTER請求2的主要內容：
|
項目 |
主要內容 |
|
IMPI |
|
|
Cseq |
381260065 |
|
終端的IP地址 |
2409:8805:84c4:c9ff:28c2:ec0d:8302:ecae |
|
傳輸協議與端口 |
TCP:8912 |
|
隨機字符串 |
8DPM+N 3z8GNKnaA1Kiw+z8d93AvmwAAm1yZfQt32gM= |
|
鑑權算法 |
AKAv1-MD5 |
|
鑑權響應 |
098237ebc33f62ced5015b158759d4cd |
8.在註冊成功後，VoLTE用戶會從S-CSCF得到哪些信息？
401響應的主要內容：
|
項目 |
主要內容 |
|
IMPI |
|
|
Cseq |
381260064 |
|
終端的IP地址 |
2409:8805:84c4:c9ff:28c2:ec0d:8302:ecae |
|
傳輸協議與端口 |
TCP:5060 |
|
隨機字符串 |
8DPM+N 3z8GNKnaA1Kiw+z8d93AvmwAAm1yZfQt32gM= |
|
鑑權算法 |
AKAv1-MD5 |
200響應的主要內容：
|
項目 |
主要內容 |
|
IMPI |
|
|
Cseq |
381260065 |
|
終端的IP地址 |
2409:8805:84c4:c9ff:28c2:ec0d:8302:ecae |
|
傳輸協議與端口 |
TCP:8912 |
|
S-CSCF地址 |
<sip:orig@[2409:8805:8029:0013:FFFF:0000:0000:0001]:0;transport=tcp;lr> |
|
IMPU |
<sip:[email protected]>;<tel:+8611234567890>; |
9.在IMS域中傳送端到端SIP信令需要解決哪四大問題？
SIP信令發給誰？怎麼傳送到對方？對方怎麼來回復？後續信令如何傳送？
第一個問題，主叫方發出的SIP請求的Request-URI和消息頭的To字段攜帶了被叫方的IMPU，這就是SIP信令的接受者。
第二個問題就是SIP信令的路由，需要依靠IMS域中的CSCF轉發，SIP消息自帶路由，可以用來確定CSCF，這個路由信息就是請求的消息頭中的Route字段，包含了VoLTE終端通過註冊得到的P-CSCF地址以及S-CSCF的地址。當主叫方發出的SIP請求抵達P-CSCF後，根據Route字段的S-CSCF的地址，P-CSCF就可以將請求轉發給S-CSCF；被叫方的CSCF沒有路由信息，因此與註冊過程類似，主叫方S-CSCF根據被叫IMPU所在的域，先找到被叫方的I-CSCF，由I-CSCF再去定位被叫方的S-CSCF。
第三個問題同樣利用了SIP信令自帶路由的特點：
SIP請求每經過一箇中間節點，消息頭的Via字段就會增加一行，寫明中間節點的地址、協議和端口。主叫方的SIP請求抵達被叫方後，Via字段將會成爲一箇中間節點列表。被叫方的響應將按照Via字段的中間節點列表原路返回，每經過一箇中間節點，就會刪除Via字段中該節點的信息，所以當SIP響應抵達主叫方後，Via字段只剩一行，內容就是主叫方的地址與端口。
第四個問題，其實如果主叫方還要發送後續的請求，沒有必要重新去尋找傳送路徑，新的請求完全可以沿用前一次的請求的傳送路徑。
10.業務數據包是如何在主被叫之間傳送的？
業務數據包不是SIP信令，沒有必要由IMS域的CSCF來轉發，因此業務數據包與SIP信令的傳送路徑相互獨立，各走各的路。
理論上，只要有了主被叫終端的IP地址，端到端的業務數據包就可以利用IP網絡來傳送，這也是企業級VOIP技術的常用方案。
被叫方由INVITE請求的消息頭中Via字段的最後一項得知主叫方的地址。
主叫方由SIP響應消息頭中Contact字段得知被叫方的地址。
有了IP地址，VoLTE終端就可以利用IP網絡把業務數據包傳送給對端了。
不過在VoLTE技術中，爲了體現出IMS域的管理，端到端的業務數據包需要通過SBC來轉發，SBC可以看成與PGW類似的角色，對端地址變成SBC地址。因此，想要傳送業務數據包，終端必須知道SBC的IP地址。SIP響應消息頭Contact字段的內容就是SBC的地址，而且根據現網的部署方式，SBC與P-CSCF合一，IP地址都是相同的。
11.建立專用業務承載需要考慮哪些因素？
發送提示音；避免Ghost Call。
12.什麼是資源預留？
在規範RFC3312中定義了Precondition機制，也就是預留資源。這裏的資源指的是專用業務承載所佔用的系統資源，而預留資源就是預先建立了專用業務承載。
13.無預留資源的呼叫流程是怎樣的？
主叫方在發出INVITE請求之後，在主叫方收到180響應之前，先建立業務承載，用來接收提示音。
當收到被叫方的200響應後，主叫方再根據被叫方發來的SDP Answer的內容，更改前面建立的業務承載，用於通話過程，這樣提示音和語音業務就都可以傳送了。
14.預留資源的呼叫流程是怎樣的？
主叫方發出INVITE請求，啓動了呼叫流程，INVITE請求中攜帶了SDP Offer，先送達P-CSCF，P-CSCF收到後回覆100響應。
主叫方收到100響應後，啓動建立專用業務承載的過程，注意：主叫方根據MME下發的NAS信令建立業務承載，與100響應沒有關係，這裏只是表明時間上的先後關係。
INVITE請求經過IMS域的CSCF中轉，最後到達被叫方。被叫方收到SDP Offer後，先發出100響應，表明已經收到INVITE請求。這個100響應不會送到主叫方。
被叫方再發出183響應，攜帶了SDP Answer，完成第一次QoS協商。
被叫方建立專用業務承載的工作由被叫方P-CSCF觸發，被叫方P-CSCF根據SDP Answer的內容，與EPC交互，觸發建立專用業務承載。被叫方最後根據MME下發的NAS信令，開始建立專用業務承載。
另外，被叫方發出的183響應按INVITE請求的轉發路徑原路返回，最後到達主叫方，主叫方的P-CSCF根據183響應中的SDP Answer的內容，觸發更新業務承載。
主叫方收到SDP Answer後，向被叫方發送PRACK請求，表明收到了SDP Answer。被叫方收到PRACK請求後，發送200響應，表明收到了PRACK請求。
當主叫方完成專用業務承載更新後，發出UPDATE請求，請求中攜帶 了SDP Offer，通知被叫方本方的專用業務承載已經建立完成。被叫方收到UPDATE請求後，發送200響應，攜帶了SDP Answer，通知主叫方本方的業務承載也已經建立完成，第二次QoS協商完成。
之後，被叫方發出180響應並振鈴，被叫方摘機後送出200響應，這是針對INVITE請求的響應。注意：上圖中出現了的多次200響應，主叫方需要根據Cseq的內容判斷到底是哪條SIP請求的響應。收到200響應後，主叫方發送ACK請求，完成呼叫過程。
15.主叫方何時建立專用業務承載？
Activate Default EPS Bearer Context Request 消息的主要參數
|
內容 |
說明 |
|
EPS Bearer ID |
EPS專用承載的標識 |
|
Linked EPS Bear ID |
關聯的默認承載的標識 |
|
EPS QoS |
QCI等QoS參數 |
|
TFT |
由PGW下發的TFT模板 |
|
Negotiated QoS |
與2G/3G系統兼容的QoS參數 |
Modify EPS Bearer Context Request 消息的主要參數
|
內容 |
說明 |
|
EPS Bearer ID |
EPS專用承載的標識 |
|
EPS QoS |
QCI等QoS參數 |
|
TFT |
由PGW下發的TFT模板 |
|
Negotiated QoS |
與2G/3G系統兼容的QoS參數 |
|
APN-AMBR |
APN聚合最高速率 |
更改專用業務承載完成後，主叫方業務承載的建立過程也就結束了。
16.被叫方何時建立專用業務承載？
被叫方的專用業務承載，只需要建立過程，不需要更改過程，只需要上題中的上半部分
17.如何避免Ghost Call？
建立專用業務承載的過程存在着不確定性，有可能失敗。由於SIP信令流程與NAS信令流程獨立進行，而且主被叫的NAS信令流程也是獨立進行的，任意一方專用業務承載建立失敗都不會影響SIP信令流程，這時就會 出現被叫方成功振鈴，但被叫用戶摘機後無法通話的現象，即所謂的“Ghost Call”
爲了解決這個問題，在規範RFC3312中定義了Precondition機制，也就是預留資源。這裏的資源指的是專用業務承載所佔用的系統資源，而預留資源就是預先建立了專用業務承載。
採用Precondition機制後，只有通話雙方都成功預留了資源，被叫方纔會振鈴，通話才能建立，這樣SIP信令流程與NAS信令流程協同起來，避免了“Ghost Call”的出現。
資源預留機制需要通過SDP Offer/Answer過程來實現，影響建立專用業務承載的NAS信令的發起時機。
18.什麼是SRVCC？
SRVCC（Single Radio Voice Call Continuity，單發射連續性語音呼叫）是VoLTE的一種切換過程，將語音業務從LTE系統切換到2G或3G的系統，也就是一種異系統互操作。至於VoLTE的業務在LTE系統內部的切換，相當於數據業務的切換。
19.SRVCC涉及哪些測量事件？
A2事件；B1事件；B2事件；異系統鄰區信息。
A2事件定義爲服務小區的信號弱於一個絕對門限，因此如果發生了A2事件，而eNB又處在LTE網絡的覆蓋邊緣，eNB就可以要求終端啓動異系統測量。
A2事件配套的異系統測量是B1事件，也就是異系統鄰區信號強於絕對門限。很明顯，如果發生了B1事件，那麼終端需要切換到異系統的鄰區。
除了B1事件，eNB還可以利用B2事件，也就是服務小區信號弱於絕對門限1並且異系統鄰區信號強於絕對門限2.B2事件可以看成A2事件和B1事件的組合，B2事件的優點是發起比較快，這樣可以降低切換的時延，缺點是配置B2事件後，LTE終端要始終進行異系統測量，增加LTE終端的開銷。
20.SRVCC的無線側處理過程涉及哪些步驟？
eNB收到測量報告後，根據測量標識可以確定測量事件，如果發現服務小區的信號差，異系統目標小區的信號強的話，再根據終端是否有QCI爲1的業務承載，判斷是否需要發起SRVCC。
eNB先根據終端上傳的GSM目標小區的頻點、NCC和BCC，取得GSM目標小區的信息。如果是WCDMA目標小區，eNB就會利用頻點和主擾碼，取得WCDMA目標小區的信息。
eNB向MME發出Handover Required消息，請求進行切換。Handover Required消息中會攜帶SRVCC指示，指明如何進行SRVCC，是隻切換CS業務還是CS業務與PS業務同時切換。
Handover Required消息還會指明切換類型，是LTEtoUTRAN還是LTEtoGERAN。這樣MME就知道要切換哪種異系統。
Handover Required消息還包含了Target ID。如果是WCDMA系統，Target ID就是目標小區所在RNC的ID；如果是GSM系統，Target ID就是目標小區的ID。
MME收到eNB發出的Handover Required消息，發現要求進行SRVCC，就會與目標系統的核心網交互，進行切換準備。
切換準備完成後，MME向eNB發出Handover Command消息，要求eNB釋放E-RAB，並轉發目標基站發給LTE終端的切換命令，其中包含目標基站提供的無線資源。
eNB收到Handover Command消息後，向LTE終端發出RRC信令Mobility From EUTRA，通知LTE終端進行切換，Mobility From EUTRA消息中攜帶了目標基站發給LTE終端的切換命令。
根據Mobility From EUTRA消息，LTE終端就能切換到異系統了。
MME角度
MME收到eNB發出的Handover Required消息，查找到異系統的MSC-S（eMSC），支持SIP協議，與IMS域進行交互。
MME向eMSC發出PS to CS Request消息，要求進行SRVCC。eMSC收到請求後，需要與無線網絡交互，準備相應的無線資源。
準備完成後，eMSC向MME發出PS to CS Response消息，指定切換所需的無線資源。收到PS to CS Response消息後，MME向eNB發出Handover Command消息，攜帶了eMSC指配的無線資源。
隨後，eMSC與IMS域交互，通知IMS域進行會話切換。