1、VOLTE概述和基本特征
VOLTE是什么？最直接簡單的理解就是VOIP，因為LTE沒有電路域，需要基于分組域提供IP語音業(yè)務(wù)，即VoLTE(Voice over LTE)。
特征1：VoLTE由IMS提供呼叫控制和業(yè)務(wù)邏輯。VoLTE的信令和媒體經(jīng)EPC路由至IMS網(wǎng)絡(luò)，由IMS提供會話控制和業(yè)務(wù)邏輯。
特征2：VoLTE由EPC提供高質(zhì)量的分組域承載。在VoLTE中EPC作為IMS的接入網(wǎng)，通過全球統(tǒng)一的專用APN(‘IMS’ APN) 及獨(dú)立承載為用戶提供區(qū)別于普通數(shù)據(jù)業(yè)務(wù)的QoS保障。
特征3：連續(xù)覆蓋前VoLTE可通過eSRVCC保障呼叫連續(xù)性。VoLTE終端在通話過程中漫游至無LTE覆蓋的區(qū)域時，通過eSRVCC將當(dāng)前呼叫切換至2G/3G電路域，此時2G/3G網(wǎng)絡(luò)作為IMS的接入網(wǎng)。
2、VoLTE競爭力
體驗特性 | VoLTE | 2G/3G |
呼叫時延 | 0.5-2秒 | 5-8秒 |
視頻質(zhì)量 | 典型分辨率：480*640
可選720P/1080P | 分辨率：176*144 |
話音質(zhì)量 | AMR-WB 頻率：50~7000Hz
編解碼：AMR-WB 23.85Kbps
抽樣：16KHz | AMR-NB 頻率：300~3400Hz
編解碼：AMR-NB 12.2Kbps
抽樣：8KHz |
3、終端開機(jī)的IMS注冊過程
用戶開機(jī)以后，首先完成EPC附著過程，建立QCI=9默認(rèn)承載，附著完成以后，發(fā)起IMS注冊過程和鑒權(quán)。在IMS注冊流程中，先建立QCI=5的SIP信令承載。然后進(jìn)行SIP的注冊過程，當(dāng)完成注冊過程以后，就可以進(jìn)行VoLTE呼叫了。SIP信令的注冊過程如下圖所示。
SIP注冊過程：
序號 | 消息解釋 |
1.REGISTER | 用戶首次試呼時，終端向代理服務(wù)器發(fā)送REGISTER注冊請求 |
2.REGISTER401 | IMS認(rèn)證/計費(fèi)中心獲知用戶信息不在數(shù)據(jù)庫中，向終端回401 Unauthorized質(zhì)詢信息，其中包含安全認(rèn)證所需的令牌 |
3．REGISTER | 終端將用戶標(biāo)識和密碼根據(jù)安全認(rèn)證令牌加密后，再次用REGISTER消息報告給IMS服務(wù)器 |
4．REGISTER 200 | IMS服務(wù)器將REGISTER消息中的用戶信息解密，認(rèn)證合法后，將該用戶信息登記到數(shù)據(jù)庫中，并向終端返回 響應(yīng)消息200 OK。 |
5．SUBSCRIBE | 用戶訂閱注冊事件包。 |
6. SUBSCRIBE 200 | 服務(wù)器應(yīng)答訂閱成功。 |
7.NOTIFY | IMS服務(wù)器發(fā)送notify消息，由于訂閱的用戶已經(jīng)注冊，所以IMS服務(wù)器回應(yīng)Notify消息中，狀態(tài)為active，同時攜帶XML信息。 |
8. NOTIFY 200 | 終端發(fā)送Notify 200表示接收成功。 |
4、VoLTE呼叫VoLTE的信令呼叫流程
對關(guān)鍵流程的解釋如下表所示：
序號 | 消息解釋 |
1 | 主叫發(fā)INVITE消息，觸發(fā)主叫RRC建立過程，INVITE消息中包含被叫方的號碼，主叫方支持的媒體類型和編碼等。 |
2 | 主叫建立SRB2信令無線承載，QCI9默認(rèn)承載和QCI5 SIP信令無線承載。例如在本例中，信令無線承載SRB-ID=2;QCI=9的默認(rèn)承載的eps-BearerID=5,DRB-ID=3;QCI=5的SIP信令承載的eps-BearerID=6,DRB-ID=4 |
3 | 核心網(wǎng)側(cè)收到主叫的INVITE消息以后，給主叫發(fā)送INVITE的應(yīng)答消息，INVITE 100.表示正在處理中。 |
4 | 核心網(wǎng)向處于空閑態(tài)的被叫發(fā)INVITE消息，由于被叫處于空閑態(tài)，所以核心網(wǎng)側(cè)觸發(fā)尋呼消息，尋呼處于空閑態(tài)的被叫用戶 |
5 | 被叫建立SRB2信令無線承載，QCI9默認(rèn)承載和QCI5 SIP信令無線承載 |
6 | 核心網(wǎng)在QCI5 RB承載上，給被叫用戶發(fā)送INVITE消息 |
7 | 被叫對INVITE消息的響應(yīng) |
8 | 被叫方通知主叫方，自己所支持的媒體類型和編碼。 |
9 | 主叫建立QCI1的數(shù)據(jù)無線承載，用于承載語音數(shù)據(jù)，使用UM方式。例如本例中，eps-BearerID=7，DRB-ID=5。關(guān)鍵參數(shù)包括頭壓縮參數(shù)，TTI Bundling，SPS。DRX參數(shù)也會按照語音業(yè)務(wù)的要求進(jìn)行重新配置。 |
10 | 被叫建立QCI1的數(shù)據(jù)無線承載。例如本例中QCI1承載的eps-BearerID=7，DRB-ID=5。 |
11 | 核心網(wǎng)通知主叫終端的SM層，建立qci=1的承載,例如：eps-BearerID=7 |
12 | 主叫收到被叫的INVITE 183消息 |
13 | 核心網(wǎng)通知被叫終端的SM層，建立qci=1的承載 |
14 | 主叫收到INVITE 183消息以后，發(fā)送確認(rèn)消息PRACK，啟動資源預(yù)留過程。 |
15 | 被叫收到主叫的PRACK以后，返回PRACK 200響應(yīng)，啟動資源預(yù)留過程。 |
16 | 主叫收到被叫的PRACK 200以后，發(fā)送UPDATE消息，標(biāo)明資源預(yù)留成功。 |
17 | 被叫收到主叫的UPDATE消息后，得知主叫UE的資源預(yù)留成功。被叫發(fā)送UPDATE 200，標(biāo)明被叫資源預(yù)留成功。 |
18 | 被叫發(fā)送INVITE 180，被叫振鈴，主叫放回鈴音 |
19 | 被叫摘機(jī)，被叫向主叫發(fā)送INVITE 200. |
20 | 主叫給IMS服務(wù)器發(fā)ACK，證實已經(jīng)收到IMS對于INVITE請求的最終響應(yīng)。核心網(wǎng)IMS服務(wù)器發(fā)ACK消息給被叫，證實對于INVITE請求的最終響應(yīng)。 |
21 | 主叫掛機(jī)，發(fā)BYE,請求結(jié)束本次會話。IMS服務(wù)器給被叫發(fā)送BYE,請求結(jié)束本次會話。 |
22 | 被叫掛機(jī)，回BYE 200消息，核心網(wǎng)IMS服務(wù)器給主叫發(fā)BYE 200，標(biāo)明會話結(jié)束。 |
23 | 通過RRCConntctionReconfiguration消息和去激活EPS專用承載消息，主叫刪除QCI=1的數(shù)據(jù)無線承載。 |
24 | 被叫刪除QCI=1的數(shù)據(jù)無線承載。 |
5、Volte呼叫volte的AMR-WB 12.65K的確定
1）AMR-WB的9種速率索引表
Frame Type Index | Mode Indication | Mode Request | Frame content (AMR-WB mode,comfort noise, or other) |
0 | 0 | 0 | AMR-WB 6.60 kbit/s |
1 | 1 | 1 | AMR-WB 8.85 kbit/s |
2 | 2 | 2 | AMR-WB 12.65 kbit/s |
3 | 3 | 3 | AMR-WB 14.25 kbit/s |
4 | 4 | 4 | AMR-WB 15.85 kbit/s |
5 | 5 | 5 | AMR-WB 18.25 kbit/s |
6 | 6 | 6 | AMR-WB 19.85 kbit/s |
7 | 7 | 7 | AMR-WB 23.05 kbit/s |
8 | 8 | 8 | AMR-WB 23.85 kbit/s |
9 | — | — | AMR-WB SID (Comfort Noise Frame) |
11~13 | — | — | For future use |
14 | — | — | speech lost |
15 | — | — | No Data (No transmission/No reception) |
| — | — |
|
2）volte呼叫過程中，Invite消息中攜帶的媒體類型和編碼格式
3）主被叫協(xié)商以后，在UPDATE消息中確定的媒體類型和編碼格式
AMR-WB采樣頻率為16kHz，AMR的采用頻率為8kHZ。AMR-WB總共支持8種模式，在上圖中就是mode-set=2，表示AMR-WB只適應(yīng)12.65kbps編碼方式。
6、Volte呼叫vollte的AMR-WB 23.85k的確定
1）Invite消息中的AMR-23.85k的編碼方法
2）update 消息中協(xié)商以后的媒體類型和編碼方式
下圖中：媒體類型為AMR-WB，采樣頻率為16k，單通道。采用的模式為AMR-WB的mode 8。mode8對應(yīng)的編碼速率為23.85kbps。
7、Volte語音呼叫2G
上圖是VoLTE呼叫2G信令流程。流程和VoLTE呼叫VoLTE是相同的。區(qū)別是如果VoLTE使用AMR-WB語音，在協(xié)商之后，會變?yōu)锳MR12.2。
下圖中，主要使用AMR-WB語音，被叫為GSM語音是的語音編碼協(xié)商結(jié)果。語音采用采樣頻率為8k的AMR語音，mode-set=7，表示使用AMR 12.2 kbit/s (GSM-EFR)。
INVITE消息中，VoLTE終端支持的語音編碼方案：
協(xié)商后的語音編碼方案：
8、Volte視頻呼叫2G
流程如下所示：
序號 | 消息解釋 |
1 | 主叫發(fā)INVITE消息，觸發(fā)主叫RRC建立過程，INVITE消息中包含被叫方的號碼，主叫方支持的媒體類型和編碼等。例如支持的音頻和視頻等。 |
2 | 核心網(wǎng)側(cè)收到主叫的INVITE消息以后，給主叫發(fā)送INVITE的應(yīng)答消息，INVITE 100.表示正在處理中。 |
3 | 核心網(wǎng)向處于空閑態(tài)的被叫發(fā)送尋呼消息。 |
4 | 核心網(wǎng)向被叫GSM手機(jī)發(fā)送setup消息，消息中包含語音承載能力和主叫號碼 |
5 | GSM被叫給核心網(wǎng)發(fā)送call confirmed消息，包含語音編碼能力相關(guān)信息。 |
6 | 主叫LTE手機(jī)，建立qci=1的語音承載。由于被叫不支持視頻，所以沒有建立qci=2的承載。 |
7 | 核心網(wǎng)IMS服務(wù)器發(fā)送INVITE 183，表示會話正在處理中，其中包含了被叫支持的語音編碼類型和媒體格式等信息。 |
8~11 | 進(jìn)行媒體格式協(xié)商和資源預(yù)留。由于被叫為GSM手機(jī)，所以只支持12.2語音 |
12 | 被叫GSM建立業(yè)務(wù)承載 |
13 | 核心網(wǎng)發(fā)送INVITE 183，表示會話在處理中 |
14 | 被叫振鈴 |
15 | 核心網(wǎng)發(fā)送INVITE 180，主叫放回鈴音。 |
16 | 被叫摘機(jī) |
17 | 核心網(wǎng)給主叫發(fā)送Invite 200，表示ok |
18 | 主叫發(fā)ACK，表示呼叫建立成功， |
19 | 被叫收到connect acknowledge，表示呼叫連接建立成功 |
20 | 主叫掛機(jī)，發(fā)BYE消息,刪除建立的語音業(yè)務(wù)承載。 |
21 | 核心網(wǎng)給GSM被叫發(fā)送disconnect消息 |
22 | gsm被叫收到后，發(fā)送RELEASE |
23 | 核心網(wǎng)刪除建立的語音業(yè)務(wù)承載，同時給主叫發(fā)BYE 200，表示成功 |
24 | 核心網(wǎng)收到被叫的RELEASE消息以后，發(fā)送release complete，表示釋放成功 |
9、eSRVCC
SRVCC（Single Radio Voice Call Continuity）存在切換性能問題，無法達(dá)到語音中斷時長小于300ms的部署要求，會嚴(yán)重影響VoLTE用戶體驗
1. SRVCC終端發(fā)起向另一IMS終端的語音呼叫
2. 呼叫成功，媒體連接建立，雙方進(jìn)行通話
3. 用戶離開LTE覆蓋，eNodeB觸發(fā)SRVCC切換,MME通知SRVCC MSC準(zhǔn)備切換，MSC完成預(yù)留資源
4. MME通知終端切換到2G/TD，切換過程中語音發(fā)生中斷，中斷時間T1約為200ms
5. SRVCC MSC發(fā)起遠(yuǎn)端媒體更新，通知遠(yuǎn)端IMS終端通過SRVCC MSC接收和發(fā)送語音
6. 遠(yuǎn)端IMS終端將媒體連接切換至SRVCC MSC
7. 從SRVCC終端切換到2G/TD到遠(yuǎn)端IMS終端切換媒體連接完成，這段時間語音將發(fā)生中斷，中斷時間T2約為800ms左右（如果遠(yuǎn)端終端處于漫游中，這段時間還會更長）
eSRVCC：在SRVCC基礎(chǔ)上，通過在拜訪地引入ATCF作為媒體錨定點(diǎn)，節(jié)省遠(yuǎn)端媒體更新時間，可將切換時延減低至300ms以內(nèi)。（注：ATCF功能集成在SBC內(nèi)實現(xiàn)）
一． 終端不區(qū)分SRVCC和eSRVCC，均看做SRVCC，附著過程中終端上報SRVCC能力，并存儲在HSS中；
二． 是否支持eSRVCC是由拜訪地和歸屬地的網(wǎng)絡(luò)部署決定的，只有當(dāng)拜訪地和歸屬地均支持eSRVCC時，終端才能進(jìn)行eSRVCC切換，否則執(zhí)行SRVCC切換：
eSRVCC與SRVCC方案區(qū)別點(diǎn)在于前者 在 IMS 系 統(tǒng) 中 新 增 了 一 對 功 能 實 體 ：ATCF（Acess Transfer Control Functionality，接入 轉(zhuǎn) 移 控制 功 能 ）和 ATGW（Access Transfer Gateway，接 入 轉(zhuǎn) 移網(wǎng)關(guān)），分別作為 VoIP 呼叫 在控制平面和用戶平面的錨定點(diǎn)。兩者對比如下圖所示：
圖1 SRVCC和eSRVCC的區(qū)別
10、頭壓縮RoHC
Ø 減少報頭開銷
n 語音包頭開銷：RTP開銷占12Byte，UDP頭開銷占8Byte，IP層的IP頭開銷占20Byte（IPv4）/40Byte （IPv6）。
n ROHC頭壓縮后IP+UDP+RTP 頭開銷4Byte左右。
n 以12.2k語音為例，頭壓縮前60+32=92字節(jié)，壓縮后4+32=36字節(jié)，壓縮率為60%。
Ø 實現(xiàn)策略
n 只對用戶面的數(shù)據(jù)執(zhí)行頭壓縮；
n 可以分承載配置是否打開頭壓縮：
p 默認(rèn)頭壓縮僅針對QCI=1語音承載開啟；
p 對于視頻通話業(yè)務(wù)中QCI=2的視頻承載默認(rèn)不開啟；
確認(rèn)頭壓縮打開，通過查看RRCConnectionReconfiguration消息確認(rèn)。
11、TTI捆綁說明
TTI bundling就是把上行的連續(xù)TTI進(jìn)行綁定，在多個連續(xù)的子幀上多次發(fā)送同一個TB（Transport Block）。
l 提高數(shù)據(jù)解碼成功的概率，提高上行3~4dB的SINR
l 提升30%上行覆蓋范圍
TD-LTE的TTI Bundling僅適用于子幀配置0、1、6，中移動使用子幀配置2，所以TTI Bundling為關(guān)閉狀態(tài)，同時TTI Bundling和SPS不能同時配置。
使用8天線可以有效提升上行性能，可以滿足VoLTE的要求，因此基本不需要開啟TTI bundling。主要應(yīng)用于FDD 2天線。
參數(shù)位置：TD-LTE業(yè)務(wù)àTD-LTE小區(qū)à信道及過程配置àPUSCH信道
通過查看qci=1語音承載RRCConnectionReconfiguration消息，有沒有相關(guān)ie。
12、9種QCI值索引
VoLTE使用QCI=5、QCI=1、QCI=2這三種！
語音業(yè)務(wù)：QCI=5 +QCI=1
視頻電話：QCI=5+QCI=1+QCI=2
QCI | Resource Type(資源類型） | Priority（優(yōu)先權(quán)） | Packet Delay Budget (NOTE 1)信息包延遲 | Example Services（服務(wù)例子） |
|
1 |
| 2 | 100 ms | Conversational Voice（語音會話） |
(NOTE 3) |
2 |
| 4 | 150 ms | Conversational Video (Live Streaming)（視頻會話） |
(NOTE 3) | GBR |
3 |
| 3 | 50 ms | Real Time Gaming（實際活動時間） |
(NOTE 3) |
4 |
| 5 | 300 ms | Non-Conversational Video (Buffered Streaming) |
(NOTE 3) |
5 |
| 1 | 100 ms | IMS Signalling（IMS信號） |
(NOTE 3) |
6 |
|
|
| Video (Buffered Streaming) |
(NOTE 4) | 6 | 300 ms | TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)（TCP基礎(chǔ)） |
7 | Non-GBR |
|
| Voice, |
(NOTE 3) | 7 | 100 ms | Video (Live Streaming) |
|
|
| Interactive Gaming（組合業(yè)務(wù)互動） |
8 |
|
|
|
|
(NOTE 5) | 8 |
| Video (Buffered Streaming) |
|
| 300 ms | TCP-based (e.g., www, e-mail, chat, ftp, p2p file |
9 |
| 9 |
| sharing, progressive video, etc.)（數(shù)據(jù)承載） |
(NOTE 6) |
VOLTE信令學(xué)習(xí).pdf
關(guān)注樓主