VoLTE總體技術(shù)方案

VoLTE總體技術(shù)方案

(v0.3)

TD-SCDMA探討開發(fā)和產(chǎn)業(yè)化項目專家組TD-LTE工作組

2023年10月

修改記錄

版本日期更新內(nèi)容備注

V0.12023-8-23大綱

目錄

VoLTE總體技術(shù)方案(v0.3)...................................1

1范圍......................................................U5

2參考規(guī)范..................................................115

3定義及縮略語..............................................12&

3.1定義................................................12S

3.2縮略語.............................................126

4背景及簡介................................................126

5VoLTE網(wǎng)絡(luò)架構(gòu)............................................136

6SRVCC.....................................................157

6.1SRVCC網(wǎng)絡(luò)架構(gòu)......................................157

6.2引入ATCF/ATGW的SRVCC網(wǎng)絡(luò)架構(gòu)....................168

6.3SRVCC對基站的要求.................................1840

6.4SRVCC對核心網(wǎng)的要求...............................20-14

SRVCC增加型MSCServer.........................2044

MME............................................2044

HSS............................................21U

S-GW/P-GW......................................21+2

ATCF...........................................21?

ATGW..........................................2345

6.5SRVCC對終端的要求.................................2343

7基站基本功能............................................23?

7.1魯棒性報頭壓縮....................................23W

7.2無線承載要求......................................25U

7.3RLC配置...........................................26M

7.4DRX...............................................26M

7.5準入限制和QoS保障................................27?

7.6半靜態(tài)調(diào)度........................................274S

7.7TTIBunddling.....................................2715

7.8加密/解密.........................................27-^

8核心網(wǎng)子系統(tǒng)功能.........................................27-LS

8.1IMS基本功能要求...................................27+S

IMS基本集.....................................2745

IMS媒體.......................................3923

8.2EPC基本功能.......................................4425

8.3PCC基本功能.......................................4425

8.4補充要求..........................................4525

IP版本........................................4525

互通漫游.......................................4526

被叫域選擇.....................................4526

短信...........................................4626

彩信...........................................4626

業(yè)務(wù)一樣性.....................................4707

9終端基本功能.............................................4727

9.1VoLTE終端架構(gòu).....................................4727

9.2基本功能要求......................................482S

無線功能要求...................................4828

IMS功能要求...................................4929

VoLTE業(yè)務(wù)質(zhì)量要求.............................493?

CSFB語音方案并存要求..........................50^

9.3VoLTE業(yè)務(wù)功能要求.................................502y

語音業(yè)務(wù).......................................5039

視頻業(yè)務(wù).......................................5030

短消息業(yè)務(wù)....................................以部

彩信業(yè)務(wù)......................................訓(xùn)

補充業(yè)務(wù).......................................51.30

數(shù)據(jù)業(yè)務(wù).......................................51S0

9.4人機界面要求......................................5230

9.5卡槽要求..........................................5234-

10VoLTE業(yè)務(wù)流程........................................5331

10.1附著過程...........................................53S4-

10.2主叫流程..........................................5334-

10.3被叫流程..........................................5533

10.4呼叫釋放..........................................5533

11SRVCC流程...............................................5634

11.1及SRVCC相關(guān)的E-UTRAN附著過程....................5634

11.2及SRVCC相關(guān)的業(yè)務(wù)懇求過程和相關(guān)的PS域切換流程..5734

及SRVCC相關(guān)的業(yè)務(wù)懇求過程...................以34

及SRVCC相關(guān)的PS域切換流程...................5734

11.3E-UTRAN發(fā)起的SRVCC流程..........................583&

從E-UTRAN到GERAN的SRVCC過程，不帶DTM.....583S

從E-UTRAN到GERAN的支持DTM但不支持DTM切換的SRVCC

過程和從E-UTRAN到UTRAN不支持PS切換的SRVCC過程....6539

從E-UTRAN到UTRAN支持PSH0的SRVCC過程或到GERAN

的支持DTM切換的SRVCC過程..........................65a9

11.4eSRVCC流程........................................7444

E-UTRAN/UTRAN的attach過程...................7444

HSS向MME/SGSN更新STN-SR過程...............7544

主叫流程.......................................764&

被叫流程.......................................7746

切換流程（無Mid-Call,呼叫被ATCF錨定，為通話狀態(tài)）

8048

11.5差錯處理..........................................8350

MSC起先會話轉(zhuǎn)移前的差錯.......................8350

UE收到切換吩咐之后的差錯......................8350

切換取消.......................................8350

12緊急呼叫.............................................醞制

VoLTE總體技術(shù)方案（vO.3）...................................1

1范圍

本方案定義了VoLTE的網(wǎng)絡(luò)框架，和LTE基站、IMS核心網(wǎng)、終端支

持VoLTE的相關(guān)技術(shù)要求。

本方案對不涉及互聯(lián)互通，僅為運營商內(nèi)部實現(xiàn)方法的技術(shù)細微環(huán)節(jié)

不做規(guī)定。

本方案終端僅針對多模單待終端做要求,雙待機不在本方案探討范圍

內(nèi)。

2參考規(guī)范

本技術(shù)方案引用如下文檔的相關(guān)技術(shù)內(nèi)容。引用時包含日期或版本編

號的文檔，非此編號的文檔可能不適用該文檔：若該文檔不包含日期或版

本編號，其最新版本適用于本技術(shù)方案。

本技術(shù)方案中的3GPP標準均為3GPPR10階段2023年6月版本。

GSMAIR.92IMSProVoiceandSMSv7.0

GSMAIR.94IMSProConversationalVideoServicev5.0

3GPPTS23.216SingleRadioVoiceCall

Continuity(SRVCC);Stage2

3GppTS23.228IPMediaSubsystem(IMS);Stage2

3GPPTS23.237IPMediaSubsystem(IMS)Service

Continuity;Stago2

3GPPTS36.300EvolvedUniversalTerrestrialRadioAccess

(E-UTRA)andEvolvedUniversalTerrestrialRadioAccess

Network(E-UTRAN);OverallDescription;Stage2

3GPPTS36.321EvolvedUniversalTerrestrialRadioAccess

(E-UTRA);MediumAccesControl(MAC)protocolspecification

3GPPTS36.322EvolvedUniversalTerrestrialRadioAccess

(E-UTRA);RadioLinkControl(RLC)protocolspecification

3GPPTS36.323EvolvedUniversalTerrestrialRadioAccess

(E-UTRA);PacketDataConvergenceProtocol(PDCP)specification

3GPPTS36.331EvolvedUniversalTerrestrialRadioAccess

(E-UTRA);RadioResourceControl(RRC)protocolspecification

3定義及縮略語

3.1定義

eSRVCC：指在基本SRVCC基礎(chǔ)上，引入了ATCF/ATGW功能實體的、增

加型的SRVCC架構(gòu),主要用于縮短用戶在LTE及2/3G接入的切換時延。

3.2縮略語

4背景及簡介

LTE（LongTermEvolution）是國際主流的新一代寬帶無線移動通信

技術(shù)。及3G采納的CDMA（碼分多址）技術(shù)不同，LTE以面對分組業(yè)務(wù)優(yōu)

化為目標，以O(shè)FDM（正交頻分多址）和MIMO（多輸入多輸出天線）技術(shù)

為基礎(chǔ)，形成了全新的面對下一代移動通信系統(tǒng)的系統(tǒng)架構(gòu)，將移動通信

的接入速率提升到了100Mbps的范疇。

基于LTE面對于分組域優(yōu)化的系統(tǒng)設(shè)計目標，LTE的網(wǎng)絡(luò)架構(gòu)不再區(qū)

分電路域和分組域，采納統(tǒng)一的分組域架構(gòu)。在新的LTE系統(tǒng)架構(gòu)下，不

再支持傳統(tǒng)的電路域語音解決方案，IMS限制的VoIP業(yè)務(wù)將作為將來LTE

網(wǎng)絡(luò)中的語音解決方案。VOLTE是GSMA定義的標準LTE語音解決方案，其

核心業(yè)務(wù)限制網(wǎng)絡(luò)是IMS(IP多媒體子系統(tǒng))網(wǎng)絡(luò)，協(xié)作LTE和EPC網(wǎng)絡(luò)

實現(xiàn)端到端的基于分組域的語音、視頻通信業(yè)務(wù)。通過IMS系統(tǒng)的限制，

VoLTE解決方案可以供應(yīng)和電路域性能相當?shù)恼Z音業(yè)務(wù)及其補充業(yè)務(wù)，包

括：號碼顯示、呼叫轉(zhuǎn)移、呼叫等待、會議電話等。

5VoLTE網(wǎng)絡(luò)架構(gòu)

VoLTE解決方案中，實現(xiàn)VoIP語音業(yè)務(wù)時，除了由EPS系統(tǒng)供應(yīng)承載,

由IMS系統(tǒng)供應(yīng)業(yè)務(wù)限制外，通常還要由PCC架構(gòu)實現(xiàn)用戶業(yè)務(wù)QoS限制

以及計費策略的限制。VoLTE業(yè)務(wù)的系統(tǒng)架構(gòu)如圖1所示。

圖1VoLTE網(wǎng)絡(luò)架構(gòu)

錯誤!未找到引用源。圖一1-中主要包括UE、eNodeB、MME、S-GW.P-GW、HSS、

PCRF、IMS域(P-CSCF.I-CSCF、S-CSCF,AS)、MMTtelAS等網(wǎng)元。

IMS域主要完成CSCF呼叫限制等功能。支持基于ISIM的鑒權(quán)、信令

的IPSec愛護、Tel-URI和SIPURI、信令壓縮、Ut接口的GBA或digest

鑒權(quán)功能，MMTtelAS支持類似GSM的多媒體電話補充業(yè)務(wù)、Ut接口的

補充業(yè)務(wù)管理（基于XCAP）。IMS系統(tǒng)和EPS網(wǎng)絡(luò)協(xié)作，可以供應(yīng)和電路

域類似的語音業(yè)務(wù)及其補充業(yè)務(wù)，包括：號碼顯示、呼叫轉(zhuǎn)移、呼叫等待、

會議電話等。

VoLTE系統(tǒng)采納特地的IMSAPN來供應(yīng)語音業(yè)務(wù)，為信令和語音數(shù)據(jù)

運用特定QCI的''承載"，從而保障給語音業(yè)務(wù)較高的QoS。通常，信令承

載采納QCI=5的默認承載，語音承載采納QC1=1的專用承載。

MobiledeviceRadio&accessnetworkServers(IMS)

圖2VoLTE協(xié)議架構(gòu)

EPC域主要包括MME、S-GU\P-GW,HSS等網(wǎng)元，須要支持IMSAPN、

初始附著的信令承載建立、P-CSCF發(fā)覺以及信令&GBR承載丟失的處理等

功能。

PCRF（策略和計費規(guī)則功能）主要完成策略限制決策和基于流進行計

費限制的功能。

eNodeB主要負責(zé)RRM（無線資源管理）功能；IP頭壓縮及用戶數(shù)據(jù)流

加密；UE附著時的MME選擇；尋呼信息的調(diào)度傳輸；廣播信息的調(diào)度傳輸;

以及設(shè)置和供應(yīng)eNodeB的測量等。

6SRVCC

6.1SRVCC網(wǎng)絡(luò)架構(gòu)

3GPPUTRAN/GERAN的SRVCC架構(gòu)重用了3GPPTS23.237為IMS服務(wù)

連續(xù)性定義的會話轉(zhuǎn)移(SessionTransfer)功能。SRVCC增加型MSCServer

也可以具有3GPPTS23.292所定義的ICS增加實力。

在3GPPTS23.401定義的E-UTRAN架構(gòu)基礎(chǔ)上，引入了一種用于SRVCC

的功能，該功能由MSCServer供應(yīng),即SRVCC增加型MSCServer?

--------------------切換前的承載路徑

-------------------切換后的承載路徑

--------------------切換前的SIP信令路徑

圖3從E-UTRAN到3GppUTRAN/GERAN的SRVCC架構(gòu)

SRVCC涉及到的接口包括：

MME-MSCServer間的Sv接口，用于在3GPPE-UTRAN和3GPP

UTRAN/GERAN之間供應(yīng)SRVCC實力。

-E-UTRAN-MME間的S1-MME接口，用于E-UTRAN和MME之間的切換

信令傳輸，定義見3GppTS36.300?

-HSS-MME間的S6a接口，用于在E-UTRAN附著過程中下載SRVCC

相關(guān)信息到WE,或者在HSS中的STN-SR信息發(fā)生了變更時通知

MMEo假如MME從HSS接收到了ICS標記，則應(yīng)包含此標記。

6.2引入ATCF/ATGW的SRVCC網(wǎng)絡(luò)架構(gòu)

由于SRVCC方案在漫游時(切換UE漫游或雙方UE均漫游)，切換

過程和語音中斷可能過長，無法滿意切換中保證用戶體驗的需求，所以，

確定引入本地信令/媒體錨點(ATCF/ATGW),縮短遠端更新帶來的時延問

題，此架構(gòu)也被稱為eSRVCC架構(gòu)。

在該方案中，將錨定點稱為ATCF(AccessTransferControl

Function),其主要做信令面的錨定，并限制ATGW(AccessTransfer

Gateway)做媒風(fēng)光的錨定。當發(fā)生切換的時候，MSCServer只須要通

知ATCF做一個內(nèi)部切換即可，不須要對遠端進行更新，這樣可以大大縮

短IMS側(cè)更新會話的時長，達到縮短切換中語音中斷的目的。其架構(gòu)圖如

圖4所示。

collocationscenario

圖4支持eSRVCC的網(wǎng)絡(luò)架構(gòu)

增加網(wǎng)元ATCF和ATGW,ATCF是AccessTransferControl

Functionality,ATGW是AccessTransferGateway。

ATCF是限制面的會話錨定網(wǎng)元，該網(wǎng)元的主要功能是在會話建立時以

及會話切換過程中對會話進行錨定。

ATGW是用戶面的會話錨定網(wǎng)元，該網(wǎng)元受控于ATCF,主要對用戶面數(shù)

據(jù)進行錨定。

切換埼PS鏈接

UE切換后探體鏈接

圖5eSRVCC切換前后錨定變更

在該架構(gòu)下，對于一個PS網(wǎng)絡(luò)中的用戶，其建立的會話是錨定在探

望地的ATCF(ATGW)上，所以在切換前信令是從UE到P-CSCF,再到

ATCF,然后連接到歸屬域的IMS(SCCAS),再通過SCCAS同遠端用戶建

立連接。此時的媒體鏈接是，UE到ATGW,然后ATGW再到遠端。當切換

發(fā)生后，用戶接入到CS網(wǎng)路，此時的信令是從CS接入到MSCServer,

再從MSCServer到ATCF,然后連接到S-CSCF和SCCAS,再通過SCC

AS同遠端用戶建立連接，此時的媒體鏈接是，UE到CS-MGW,然后CS-MGW

到ATG肌然后從ATGW到遠端的媒體網(wǎng)關(guān)。可以看出在切換前后，ATGW

后的媒體鏈接是一樣的，只須要ATCF通知ATGW本地切換媒體即可，省

卻了遠端更新的過程。

6.3SRVCC對基站的要求

基站應(yīng)支持到3G/2G的SRVCC功能。

當E-UTRAN選擇目標小區(qū)進行SRVCC切換時，E-UTRAN須要向MME發(fā)送一

個指示，表明該切換過程須要SRVCC。

E-UTRAN須要支持切換域選擇。

切換域由E-UTRAN選擇，E-UTRAN的選擇邏輯應(yīng)盡可能把話務(wù)留在LTE

域。為了取得域切換所必需的信息，E-UTRAN可以依據(jù)“SRVCC操作可能”

標記以及/或?qū)δ硞€特定UE已建立的QCI=1的承載來確定須要測量的相鄰

小區(qū)列表。

E-UTRAN可以依據(jù)下面的做法確定相鄰小區(qū)列表（NCL）：

-假如“SRVCC操作可能”標記被設(shè)為“真”（就是說，EPC和UE都具

備SRVCC的實力），那么不具有VoIP實力的小區(qū)也可以被包括在NCL

作為候選的目標小區(qū)，無論這個UE是否建立了帶有QCI=1的承載。

而且：

1）假如UE已經(jīng)建立一個QCI=1的承載，并且所選擇的目標小區(qū)是具

有VoIP實力的，那么E-UTRAN在HandoverRequired消息中不包

括SRVCC指示；

2）假如UE已經(jīng)建立一個QCI=1的承載，但是所選擇的目標小區(qū)不具

有VoIP實力，那么E-UTRAN在HandoverRequired消息中要包括

SRVCC指示;

3）假如UE還沒有建立QCI=1的承載，那么E-UTRAN在Handover

Required消息中不包括SRVCC指示。

假如“SRVCC操作可能”標記被設(shè)為“否”（就是說，EPC和UE至

少有一個不具備SRVCC的實力），那么E-UTRAN在HandoverRequired

消息中不包括SRVCC指示。而且：

1）假如這個UE己經(jīng)建立一個QC1=1的承載，NCL中不能包括沒有

VoIP實力的小區(qū);

2）假如這個UE沒有建立QCI=1的承載，NCL中可以包括沒有VoIP實

力的小區(qū)。

6.4SRVCC對核心網(wǎng)的要求

6.4.1SRVCC增加型MSCServer

為了支持SRVCC,MSCServer須要供應(yīng)下面的功能：

-處理來自Sv接口的針對語音部分的重定位打算過程。

-觸發(fā)從IMS到CS的會話轉(zhuǎn)移過程或緊急會話轉(zhuǎn)移過程。

協(xié)調(diào)CS切換和IMS會話轉(zhuǎn)移過程。

發(fā)起位置更新過程，而不須要UE側(cè)發(fā)起。

假如支持IC$功能，并且通過Sv接口接受到IC$標記，那么MSC

Server執(zhí)行ICS功能。

假如有緊急會話，依據(jù)條件可以發(fā)送用戶位置報告消息到GMLC,支

持位置連續(xù)業(yè)務(wù)。

-不能對任何被轉(zhuǎn)移的或正在進行轉(zhuǎn)移的呼叫供應(yīng)放音或者其他帶

內(nèi)媒體。

eMSCServer作為和IMS域的連接點，須要產(chǎn)生ICID,用于增加的

1CS業(yè)務(wù)的MSC還要供應(yīng)用戶的位置信息（例如，CGI或者SAD

或者用戶時區(qū)信息。

6.4.2MME

為了支持SRVCC,MME須要供應(yīng)下面的功能:

支持PS承載的拆分，分別出語音的PS承載和非語音的PS承載。

對于非語音的PS承載，按3GPPTS23.401定義的RAT間的切換過

程，切換到目標小區(qū)。

對于語音的PS承載，通過Sv接口觸發(fā)SRVCC切換到目標小區(qū)。這

個過程只觸發(fā)一次，不管UE當前運用的語音PS承載（如QCI=1）

數(shù)目是多少。

協(xié)調(diào)PS切換和SRVCC切換過程。

選擇支持SRVCC功能的MSC,可以基于DNS過程或者本地配置。

6.4.3HSS

為了支持SRVCC,MME須要供應(yīng)下面的功能：

HSS須要存貯用戶的SRVCCSTN-SR和C-MSISDN和可選的ICS標記，

在UE進行LTE附著的時候，能從HSS下載到MME上。

對于HSPA,STN-SR和C-MSISDN是在進行GPRS附著時,從HSS下

載到SGSN上的。

-當STN-SR被修改或者從用戶的訂閱信息中刪除時，HSS應(yīng)通知

MME/SGSN,

-HSS允許SCCAS更新用戶profile中的STN-SR。假如有ATCF,STN-SR

代表了ATCF,否則就代表SCCAS,

6.4.4S-GW/P-GW

SRVCC技術(shù)對S-GW/P-GW沒有新的需求。

6.4.5ATCF

ATCF位于用戶當前所在網(wǎng)絡(luò)（漫游時位于探望網(wǎng)絡(luò)，非漫游時位于歸

屬網(wǎng)絡(luò)），供應(yīng)會話信令錨定和媒風(fēng)光切換限制功能。

接入切換限制功能（ATCF）位于當前服務(wù)網(wǎng)絡(luò)（假如是漫游則為探望

網(wǎng)絡(luò)）。當運用部署了ATCF的增加SRVCC時，在呼叫過程中以及切換前

后ATCF都會包含在會話的限制面之中。

ATCE可能及服務(wù)網(wǎng)絡(luò)中現(xiàn)有的某網(wǎng)元合設(shè)（如：P-CSCF或IBCF）.

ATCF必需：

-依據(jù)運營商策略，決策：

1）安排STN-SR：

2）將其自身插入SIP會話路徑：并且

3）指示ATGW錨定起呼或終呼會話的媒體；

-保持監(jiān)控這些會話（無論是振鈴態(tài)、激活態(tài)還是保持態(tài)），以便執(zhí)

行所選會話的接入切換；

-執(zhí)行接入切換并將ATGW更新至（CS）接入支路的新媒體路徑，并

無須發(fā)起遠端更新；

-接入切換之后，向SCCAS發(fā)起更新，通知SCCAS發(fā)生了接入切

換，以確保T-ADS具有當前運用的接入信息；

-處理接入切換中的失敗場景。

接入切換之后，依據(jù)本地策略，ATCF可能將ATGW從媒體路徑中移

除。該步驟須要進行遠端更新。

假如要運用MSCServerassistedmid-call功能，SCCAS還須要

供應(yīng)須要切換的振鈴態(tài)、保持態(tài)和/或會議狀況的會話狀態(tài)信息。

ATCF不能修改UE和SCCAS之間交互的動態(tài)STK

6.4.6ATGW

ATGW及ATCF位于同一網(wǎng)絡(luò)內(nèi)，由ATCF限制供應(yīng)媒風(fēng)光錨定和媒風(fēng)光

切換功能。ATGW還可供應(yīng)編解碼轉(zhuǎn)換功能。

接入切換網(wǎng)關(guān)(ATGW)由ATCF限制。假如運用部署了ATCF的增加

SRVCC,依據(jù)服務(wù)網(wǎng)絡(luò)的本地策略，ATGW在呼叫過程中以及切換之后，保

持在會話的媒體路徑之中。

假如MSC服務(wù)器不支持切換之前運用的媒體格式，則ATGW須要支持

編解碼轉(zhuǎn)換。

依據(jù)ATCF的位置，不同的物理節(jié)點可以考慮充當ATGW,如IMS-AGW

或TrGW.

6.5SRVCC對終端的要求

終端支持上報SRVCC實力。

終端支持LTE下對2G/3G網(wǎng)絡(luò)的異系統(tǒng)測量，并支持SRVCC到2G/3G網(wǎng)絡(luò)。

7基站基本功能

7.1魯棒性報頭壓縮

基站應(yīng)支持魯棒性報頭壓縮(ROHC)功能?；緫?yīng)對語音分組的報頭

進行壓縮，并至少支持下表中針對RTP報文的“RTP/UDP/IP”協(xié)議框架

(0x0001)和針對RTCP報文的“UDP/IP”協(xié)議框架(0x0002)。

ROHC功能應(yīng)支持對IPv4和IPv6報頭的壓縮。

表1建議支持的報頭壓縮協(xié)議和協(xié)議框架

協(xié)議框架標用途參考規(guī)范必選/可

識選

0x0000不壓縮RFC4995可選

0x0001RTP/UDP/IPRFC3095,RFC必選

4815

0x0002UDP/IPRFC3095,RFC必選

4815

0x0003ESP/IPRFC3095,RFC可選

4815

0x0004IPRFC3843,RFC可選

4815

0x0006TCP/IPRFC4996可選

0x0101RTI7UDP/IPRFC5225可選

0x0102UDP/IPRFC5225可選

0x0103ESP/IPRFC5225可選

0x0104IPRFC5225可選

7.2無線承載要求

基站應(yīng)支持VoLTE的無線承載組合如下:

-語音業(yè)務(wù)：SRB1+SRB2+2xAMDRB+1xUMDRB,其中，2

個AMDRB分別用于QCI=5和QCI=8或9的EPS承載，1個UMDRB用于

QCI=1的EPS承載;

-視頻+語音業(yè)務(wù)：SRB1+SRB2+2xAMDRB+2xUMDRB,其中，

2個AMDRB分別用于QCI=5和QCI=8或9的EPS承載，1個UMDRB用于

QCI=1的EPS承載，另1個UMDRB用于non-GBR承載或QCI=2的EPS承

載。

基站應(yīng)支持速率為12.2kbps、7.4kbps、5.9kbps和4.75kbps的AMR

業(yè)務(wù)承載和速率為23.85kbps、12.65kbps、8.85kbps和6.60kbps的AMR-WB

業(yè)務(wù)承載。

7.3RLC配置

RLC依據(jù)如下要求配置：

:帶格式的：法語（法國）

-—^UnacknowledgedMode(UM)forEPSbearerswithQCI=1

(語音)

-UnacknowledgedMode(UM)forEPSbearerswithQCI=2(視

頻）

一_AcknowledgedMode(AM)forEPSbearerswithQCI=5

-AcknowledgedMode(AM)forEPSbearerswithQCI=8/9

7.4DRX

為削減UE的耗電，基站應(yīng)支持LTE非連續(xù)接收（DRX）。

非連續(xù)接收周期包含LongCycle和ShortCycle?

7.5準入限制和QoS保障

基站應(yīng)支持針對VoLTE業(yè)務(wù)的準入限制功能和GBRMonitoring功能。

基站應(yīng)支持基于QoS的資源調(diào)度。

7.6半靜態(tài)調(diào)度

基站應(yīng)支持半靜態(tài)調(diào)度SPS。

對于TD-LTE基站，半靜態(tài)調(diào)度及波束賦形的協(xié)同工作方式需進一步探

討。

7.7TTIBunddling

為提升小區(qū)邊界的上行覆蓋，基站應(yīng)支持TTIBundlingo

對于TD-LTE基站，TTIBundling只適用于TDDconfiguration0/1/6

上下行時隙配置。TTIBundling不行及SPS同時運用。

7.8加密/解密

基站應(yīng)支持VoLTE業(yè)務(wù)在空口的加密和解密，應(yīng)支持ZUC算法。

8核心網(wǎng)子系統(tǒng)功能

8.1IMS基本功能要求

8.1.1IMS基本集

8.1.1.1通用IMS功能

(1)SIP注冊

UE和IMS核心網(wǎng)必需支持3GppTS24.229中定義的SIP注冊流程，這也

包括IETFRFC3608中定義的業(yè)務(wù)路由發(fā)覺機制。網(wǎng)絡(luò)必需支持

P-Visited-Network-ID頭域。UE必需包含ICSI值用于指示IMS多媒體電話

業(yè)務(wù)，即，3GPPTS24.2295.1.1.2.1節(jié)中定義的。UE和IMS核心網(wǎng)必需

支持3GppTS24.229定義的網(wǎng)絡(luò)側(cè)發(fā)起的去注冊過程。UE能夠訂閱3GPPTS

24.2295.1.1.3節(jié)中定義的注冊事務(wù)包。

為了支持視頻呼叫，UE必需遵從IETFRFC3840的要求，在REGISTER

懇求的Contact頭域中增加"video”媒體功能標記。

(2)鑒權(quán)

UE和IMS核心網(wǎng)須支持支PPTS24.229和3GppTS33.203中定義的包

含IMS-AKA、Sec-Agree和IPSec機制的IMS鑒權(quán)過程，同時還要支持完整

性愛護過程?？紤]究竟層的平安性，加密愛護功能是可選的。

IMS核心網(wǎng)和UE都必需支持基于ISIM的鑒權(quán)程序。

依據(jù)3GppTS23.228附錄和3GppTS24.229附錄C.2定義,假如依據(jù)

上沒有ISIM,那么UE和IMS核心網(wǎng)都必需支持基于USIM的鑒權(quán)程序。這個

也包括支持P-AssociatedUniformResourceIdentifier(URI)頭以處理

閉鎖的IPMultimediaPublicIdentities(IMPU)?

UE和IMS核心網(wǎng)必需支持3GPPTS24.623定義的Ut接口的鑒權(quán)流程。

(3)尋址

UE和IMS核心網(wǎng)必需支持SIPURI和基于IMPU的MSISDN。

UE和網(wǎng)絡(luò)必需支持3GppTS24.229中節(jié)的選項2和節(jié)中定義的本地號

碼。UE必需依據(jù)3GppTS24.229中的節(jié)設(shè)置“phone-context”參數(shù)。

UE和IMS核心網(wǎng)必需支持P-Called-PartyTD頭域，網(wǎng)絡(luò)要依據(jù)3GppTS

24.229中的要求運用該頭域。UE和網(wǎng)絡(luò)都不要求支持GRUU。

(4)呼叫建立和釋放

UE和IMS核心網(wǎng)要遵從3GPPTS24.229中定義的SIP呼叫建立和釋放程

序，包括運用Route頭域。UE要依據(jù)3GppTS24.229的要求傳遞1>'“6$$-

岫1\丫0心-1[1￡0頭域。

UE和IMS核心網(wǎng)都要支持牢靠的臨時響應(yīng)。

為了給網(wǎng)絡(luò)指示IMS業(yè)務(wù)類型，UE必需依據(jù)3GppTS24.229的要求運用

ICSI值，ICSI值的格式是3GPPTS24.173中定義的

urn:urn-7:3gpp-service.ims.icsi.mmtel。

(5)分叉

網(wǎng)絡(luò)不要求支持分叉功能，但是，考慮互操作和前向兼容性，UE必需

能夠接收由于分叉懇求產(chǎn)生的響應(yīng)，并依據(jù)IETFRFC3261、3GPPTS23.228

第節(jié)和3GppTS24.229操作。

(6)信令跟蹤

UE可選支持3GppTS24.229第節(jié)定義的故障解除事務(wù)包。

(7)信令壓縮

SigComp功能是運營商可配置的。UE和P-CSCF可選支持信令壓縮,其中，

UE的要求在3GppTS24.229的8.1節(jié)中定義，P-CSCF的要求在3GppTS

24.229的8.2節(jié)中定義。

補充業(yè)務(wù)

(1)概述

UE和TAS必需支持下表列出的補充業(yè)務(wù)。

表2補充業(yè)務(wù)

OriginatingIdentificationPresentation3GPPTS24.607

TerminatingIdentificationPresentation3GPPTS24.608

OriginatingIdentificationRestriction3GPPTS24.607

TerminatingIdentificationRestriction3GPPTS24.608

CommunicationDiversionUnconditional3GPPTS24.604

CommunicationDiversiononnotLoggedin3GPPTS24.604

CommunicationDiversiononBusy3GPPTS24.604

CommunicationDiversiononnotReachable3GPPTS24.604

CommunicationDiversiononNoReply3GPPTS24.604

BarringofAllIncomingCalls3GPPTS24.611

BarringofAllOutgoingCalls3GPPTS24.611

BarringofOutgoingInternationalCalls3GPPTS24.611

BarringofIncomingCalls-WhenRoaming3GPPTS24.611

CommunicationHold3GPPTS24.610

MessageWaitingIndication3GPPTS24.606

CommunicationWaiting3GPPTS24.615

Ad-HocMultiPartyConference3GPPTS24.605

（2）補充業(yè)務(wù)配置

UE和IMS核心網(wǎng)必需支持3GppTS24.623定義的Ut接口的XCAP,用于配

置補充業(yè)務(wù)。

（3）多方會議

UE和IMS核心網(wǎng)必需支持3GppTS24.605中定義的程序，同時還要遵從

以下規(guī)定。

UE和IMS核心網(wǎng)必需支持3GppTS24.147第節(jié)中定義的三方會話創(chuàng)建

程序。

要邀請其他用戶加入到會議，UE和IMS核心網(wǎng)必需支持3GppTS24.147

第5.3.1.5.3中定義的程序，UE還應(yīng)利用UE和IMS網(wǎng)絡(luò)現(xiàn)有會議會話中的對

話來發(fā)送REFER方法。UE能夠?qū)eplaces頭增加到REFER中的Refer-to頭域

中。

UE和IMS核心網(wǎng)必需支持3GppTS24.605中的簽約會話狀態(tài)事務(wù)程序。

IMS核心網(wǎng)必需支持以下單元和屬性：

?conference-info：entity

,maximum-user-count

,users

/user:entity

/display-text

/endpoint:entity

-status(supportedvalues:connected,disconnected,

on-hold)

UE和IMS核心網(wǎng)必需支持會議會話中的語音媒體成分。不要求支持

Floorcontro功能。

UE和IMS核心網(wǎng)能夠支持會議會話中有一個語音和一個視頻流。

視頻會議是由會議創(chuàng)建UE用INVITE懇求建立的，其中的SDPoffer包含

有語音和視頻媒體描述符，見3GppTS24.147第5.3.1.3.3節(jié)描述。

參與會議的UE可以僅用語音業(yè)務(wù)，這可以通過將SDP應(yīng)答中的視頻描

述符端口號設(shè)置為0來實現(xiàn)。

視頻會議中的參及者可以通過發(fā)送SIPre-INVITE,并將其中的視頻描

述符端口號設(shè)置為0,來懇求退出會議。

視頻流也可以通過發(fā)送一個新的SIPre-INVITE懇求，并將其中的視頻

描述符端口號設(shè)置為一個非0值，來重新建立。

假如建立視頻會議的會議參與者發(fā)送一個SIPre-INVITE,其中的視

頻被刪除了，由網(wǎng)絡(luò)策略來確定是否要將會議降級為一個語音會議，或者

確定在會議發(fā)起者在只運用語音的狀況下視頻會議還要不要接著。

(4)通信等待

UE和IMS核心網(wǎng)必需支持3GppTS24.615中定義的基于終端的業(yè)務(wù),

不要求支持基于網(wǎng)絡(luò)的業(yè)務(wù)。3GPPTS24.615第4.4.1中定義的通信等待

不做要求。UE要求支持Alert-Info,其取值遵從3GppTS24.615?業(yè)務(wù)的

激活、去激活和查詢則不做要求。

（5）消息等待指示

UE和IMS必需支持3GppTS24.606和IETFRFC3842中定義的消息等

待指示事務(wù)包。

（6）主叫標識限制

UE必需支持3GppTS24.607定義的SIP程序，業(yè)務(wù)配置則是可選的。

（7）被叫標識限制

UE必需支持3GppTS24.607定義的SIP程序，業(yè)務(wù)配置則是可選的。

（8）通信轉(zhuǎn)移

UE和IMS核心網(wǎng)必需支持3GppTS24.604中定義的通信轉(zhuǎn)移（CDIV）SIP

程序。CDIV通知業(yè)務(wù)不做要求。UE和IMS必需支持下表中列出的條件和動

作，用于CDIV業(yè)務(wù)的激活、去激活和查詢（XCAP操作），并建議UE支持

History-Info頭用于轉(zhuǎn)移方的呈現(xiàn)。

表3CDIV中支持的條件和動作

Conditionbusy

Conditionmedia(supportedmediatypes:audio,audio

ANDvideo)

Conditionno-answer

Conditionnot-registered

Conditionnot-reachable(Note)

Actiontarget

ActionNoReplyTimer

（9）通信閉鎖

UE和IMS核心網(wǎng)必需支持3GppTS24.611中定義的SIP程序，UE和IMS

核心必需支持下表中列出的條件，用于業(yè)務(wù)激活、去激活和查詢（XCAP操

作）。

表4CB中支持的條件

roaming

international

international-exHC

（10）呼叫保持

UE能夠利用3GppTS24.610第節(jié)定義的程序懇求語音和視頻媒體流進

行保持或者復(fù)原。

假如語音和視頻媒體流都被保持了，網(wǎng)絡(luò)只能發(fā)起給被保持的用戶供

應(yīng)錄音通知的流程，或者利用3GppTS24.610第4.5.2.4節(jié)中定義的網(wǎng)絡(luò)

選項來削減帶寬。

要復(fù)原視頻媒體流，須遵從3GppTS26.114第14.3的要求。

8.1.1.3呼叫建立過程

(1)SIP預(yù)留

UE必需支持IETFRFC3312和IETFRFC4032中定義的SIP預(yù)留機制。依

據(jù)3GPPTS24.229第5.23.1節(jié)中的定義,UE應(yīng)運用Supported頭,而不是

Require頭，來指示自己支持預(yù)留。依據(jù)3GppTS24.229第5.1.3.1節(jié)的定

義，UE在發(fā)起一個IMS會話的時候，必需始終包含precondition-tag。

運營商可以關(guān)閉網(wǎng)絡(luò)中預(yù)留機制的運用。被叫UE的實現(xiàn)及主叫是否運

用預(yù)留機制無關(guān)。

(2)資源管理和SIP的融合

-PDN連接的丟失

依據(jù)3GppTS24.229第5.2.8的要求，假如UE和網(wǎng)絡(luò)間的PDN連接中斷

了，網(wǎng)絡(luò)必需終端跟該UE相關(guān)的全部在線SIP會話。

一旦UE重新復(fù)原了PDN連接，而在IP連接丟失期間，用戶的IP地址變更

了，或者IMS注冊超時了，那么，UE必需執(zhí)行一次新的初始IMS注冊。

-SIP信令承載丟失

依據(jù)3GppTS24.229第5.2.8的要求，假如依P信令承載丟失了,網(wǎng)絡(luò)

必需終止跟該UE相關(guān)的全部的在線SIP會話。

假如SIP信令承載丟失了，UE必需重新建立PDN連接，這會觸發(fā)網(wǎng)絡(luò)發(fā)

起一次PDN連接建立以建立新的$IP承載。一旦SIP承載建立了，而在IP連

接丟失期間，用戶的IP地址變更了，或者IMS注冊超時了，UE必需執(zhí)行一

次新的初始IMS注冊。

-媒體承載和無線連接的丟失

依據(jù)TS24.229第5.2.8的要求，假如用于語音的GBR承載建立失敗，或

者在會話過程中丟失了，網(wǎng)絡(luò)必需終止及語音流相關(guān)的會話。承載一旦丟

失，PCRF應(yīng)通知P-CSCF。

依據(jù)3GPPTS24.229第6.1.1節(jié)的定義，假如SIP會話包含媒體流，并

且用于其它媒體流的專有承載建立失敗，或者在會話過程中丟失了，UE應(yīng)

基于自己的選擇修改、拒絕或終止及該專有媒體承載相關(guān)的SIP會話。媒

體類型不同，UE的行為也可不同。

假如UE已經(jīng)丟失了無線連接，后來又重新復(fù)原了無線連接，而且在無

線連接中斷的過程中，UE的IMS注冊超時了，UE必需支持一次新的IMS初始

注冊。

-視頻呼叫

假如用于視頻的GBR承載建立失敗，或者在會話過程中丟失了，網(wǎng)絡(luò)可

以基于策略將會話作為語音呼叫接著處理，也可以依據(jù)3GPPTS24.229第

5.2.8節(jié)的要求終止SIP會話，此時PCRF應(yīng)通知P-CSCF承載丟失了。

假如用于視頻的GBR承載建立失敗，或者在會話過程中丟失了，UE可以

依據(jù)3GppTS24.229第6.1.1節(jié)的要求，修改、拒絕或者中斷跟媒體承載

相關(guān)的SIP會話。

假如用于視頻的Non-GBR承載建立失敗，或者在會話過程中丟失了，或

者所供應(yīng)的QoS級別不夠,UE可以依據(jù)3GppTS24.229第6.1.1節(jié)的要求,

修改、拒絕或者中斷跟該專用媒體承載相關(guān)的SIP會話。

(3)語音媒體

用于語音媒體的SDPoffer/answer必需依據(jù)3GppTS26.114第6.2.2

節(jié)中定義的進行編碼。

(4)多媒體

具有媒體功能全集的UE可以發(fā)送包含多個“m=”行的SDPoffer,來指

示自己想建立一個更高級別的多媒體會話。

假如這些“m=”行中的一個指示UE想建立一個語音會話，采納的是兼

容的編解碼，UE必需接受offer,并允許運用自己能夠支持的任何媒體流。

對于自己不支持的媒體流，UE將端口號設(shè)置為0。

具有媒體功能全集的UE,還可以可選地通過發(fā)送SDPoffer中包含了多

個“m=”行的的SIP(re-)INVITE懇求，來進行會話的更新，以指示自己

想要將會話擴展為一個更高級別的多媒體會話。UE必需接受offer,并允

許運用自己能夠支持的任何媒體流。對于自己不支持的媒體流，UE將端口

號設(shè)置為0。

(5)視頻呼叫

UE和網(wǎng)絡(luò)能夠建立視頻呼叫，在會話建立過程中，通過發(fā)送SIP

(re-)INVITE懇求，其中的SDPoffer包含語音和視頻媒體描述符，在語音

會話中增加視頻來實現(xiàn)的。

為了指示遠端的forking,UE必需遵從IETFRFC3840和RFC3841,

在INVITE懇求中的Accept-Contact頭域包含“video”媒體特性標記用于

視頻呼叫。

不管視頻媒體是不是$DPoffer的一部分，UE都必需能夠在INVITE懇求

的Contact頭域包含一個"video”媒體特性標記，以指示自己的視頻處理

實力。

不管視頻媒體是不是SDPanswer的一部分，UE都必需能夠在全部的18x

或200響應(yīng)的Contact頭域包含一個"video”媒體特性標記，以指示自己

的視頻處理實力。

UE能夠發(fā)送帶有全雙工視頻媒體的SDPoffer和應(yīng)答消息。

SDP應(yīng)答可以通過將視頻媒體的描述符端口號設(shè)置為0來拒絕視頻媒

體，也可以通過忽視SDPdirection屬性或者利用sendrecvSDP屬性來接

收全雙工模式的視頻媒體，還可以通過利用sendonly或recvonlySDP

屬性來接收單工模式的視頻媒體。

視頻呼叫的視頻流可以在單工或雙工模式間變更，或者通過帶有合適

的視頻媒體描述符(sendrecv,sendonly,recvonly或inactive)的SDP

0￡￡61'的匿-1時。￡懇求，使其去激活。

視頻呼叫中的視頻流可以通過發(fā)送SIPre-INVITE懇求來刪除，其中的

SDPoffer的視頻描述符端口號設(shè)置為0。

UE能夠接收帶有多個early對話的SIP響應(yīng)，這個響應(yīng)是由于fork懇求

產(chǎn)生的。UE也能夠接收帶有1個eary對話的語音和視頻媒體。

SMSoverIP

依據(jù)3GppTS24.341第5.3.1和5.3.2節(jié)的定義,UE必需能夠發(fā)送和接

收SM-over-IP,同時還應(yīng)支持3GppTS24.341第、5.3.2.4和節(jié)定義的狀

態(tài)報告實力、發(fā)送報告、存儲空間通知。

IMS核心網(wǎng)必需具有具-SM-GW網(wǎng)元,支持3GppTS24.341第5.3.3.1節(jié)

中定義的通用程序，以及3GppTS24.341第5.3.3.3和第5.3.3.4節(jié)中定義

的功能。

8.1.2IMS媒體

語音編碼

依據(jù)3GppTS26.071、TS26.090、TS26.073和TS26.104中的定義，

UE和IMS中的媒風(fēng)光網(wǎng)元必需支持AMR和AMR-WB語音編碼，以及3GppTS

26.093中定義的全部8種模式和源速率限制操作，還應(yīng)支持這8種編碼模式

的全部子集。

在發(fā)送時，UE和IMS中的媒風(fēng)光網(wǎng)元能夠?qū)⒆兏木幋a模式及每個

幀的邊界對齊，并且能夠限制編碼模式變更，以及其他任何一個幀邊界對

齊，猶如3GppTS26.103UMTS_AMR_2的定義;還能限制編碼模式變更,

以使得編碼模式及協(xié)商的編碼模式集接近。

在接收時，UE和IMS中的媒風(fēng)光網(wǎng)元能夠任何幀邊界的編碼模式變

更，或者變更為協(xié)商的編碼模式集合中的任何一種編碼模式。

8.1.2.2視頻編碼

IMS核心網(wǎng)用戶而網(wǎng)元必需支持3GppRIOTS26.114第5.2.2節(jié)中的定

義的ITU-TH.264CBP級別1.2。

3GPPR8TS26.114第5.2.2節(jié)定義的對ITU-TH.263Profile0Level

45的支持則不做要求。

必需支持在RTP媒體流中傳送新的參數(shù)集，以變更流中的視頻信號辨別

率，只要這些參數(shù)集符合協(xié)商的結(jié)果。

收到一個采納H.264編碼的FIR媒體流，UE和網(wǎng)絡(luò)中的媒風(fēng)光網(wǎng)元

必需發(fā)送一個當前激活的參數(shù)集。

RTP和SDP

(1)RTP

必需采納IETFRFC3551中定義的RTPAVP。

(2)SDP

運用AVP時，不能運用SDPCapNeg機制。

(3)SDP