VoLTE总体技术方案

VoLTE总体技术方案

(v0.3)

TD-SCDMA探讨开发和产业化项目专家组TD-LTE工作组

2023年10月

修改记录

版本日期更新内容备注

V0.12023-8-23大纲

目录

VoLTE总体技术方案(v0.3)...................................1

1范围......................................................U5

2参考规范..................................................115

3定义及缩略语..............................................12&

3.1定义................................................12S

3.2缩略语.............................................126

4背景及简介................................................126

5VoLTE网络架构............................................136

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

6.1SRVCC网络架构......................................157

6.2引入ATCF/ATGW的SRVCC网络架构....................168

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

6.4SRVCC对核心网的要求...............................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半静态调度........................................274S

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

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

8核心网子系统功能.........................................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

业务一样性.....................................4707

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

9.1VoLTE终端架构.....................................4727

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

无线功能要求...................................4828

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

VoLTE业务质量要求.............................493©

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

9.3VoLTE业务功能要求.................................502y

语音业务.......................................5039

视频业务.......................................5030

短消息业务....................................以部

彩信业务......................................训

补充业务.......................................51.30

数据业务.......................................51S0

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

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

10VoLTE业务流程........................................5331

10.1附着过程...........................................53S4-

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

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

10.4呼叫释放..........................................5533

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

11.1及SRVCC相关的E-UTRAN附着过程....................5634

11.2及SRVCC相关的业务恳求过程和相关的PS域切换流程..5734

及SRVCC相关的业务恳求过程...................以34

及SRVCC相关的PS域切换流程...................5734

11.3E-UTRAN发起的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锚定，为通话状态）

8048

11.5差错处理..........................................8350

MSC起先会话转移前的差错.......................8350

UE收到切换吩咐之后的差错......................8350

切换取消.......................................8350

12紧急呼叫.............................................酝制

VoLTE总体技术方案（vO.3）...................................1

1范围

本方案定义了VoLTE的网络框架，和LTE基站、IMS核心网、终端支

持VoLTE的相关技术要求。

本方案对不涉及互联互通，仅为运营商内部实现方法的技术细微环节

不做规定。

本方案终端仅针对多模单待终端做要求,双待机不在本方案探讨范围

内。

2参考规范

本技术方案引用如下文档的相关技术内容。引用时包含日期或版本编

号的文档，非此编号的文档可能不适用该文档：若该文档不包含日期或版

本编号，其最新版本适用于本技术方案。

本技术方案中的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基础上，引入了ATCF/ATGW功能实体的、增

加型的SRVCC架构,主要用于缩短用户在LTE及2/3G接入的切换时延。

3.2缩略语

4背景及简介

LTE（LongTermEvolution）是国际主流的新一代宽带无线移动通信

技术。及3G采纳的CDMA（码分多址）技术不同，LTE以面对分组业务优

化为目标，以OFDM（正交频分多址）和MIMO（多输入多输出天线）技术

为基础，形成了全新的面对下一代移动通信系统的系统架构，将移动通信

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

基于LTE面对于分组域优化的系统设计目标，LTE的网络架构不再区

分电路域和分组域，采纳统一的分组域架构。在新的LTE系统架构下，不

再支持传统的电路域语音解决方案，IMS限制的VoIP业务将作为将来LTE

网络中的语音解决方案。VOLTE是GSMA定义的标准LTE语音解决方案，其

核心业务限制网络是IMS(IP多媒体子系统)网络，协作LTE和EPC网络

实现端到端的基于分组域的语音、视频通信业务。通过IMS系统的限制，

VoLTE解决方案可以供应和电路域性能相当的语音业务及其补充业务，包

括：号码显示、呼叫转移、呼叫等待、会议电话等。

5VoLTE网络架构

VoLTE解决方案中，实现VoIP语音业务时，除了由EPS系统供应承载,

由IMS系统供应业务限制外，通常还要由PCC架构实现用户业务QoS限制

以及计费策略的限制。VoLTE业务的系统架构如图1所示。

图1VoLTE网络架构

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

PCRF、IMS域(P-CSCF.I-CSCF、S-CSCF,AS)、MMTtelAS等网元。

IMS域主要完成CSCF呼叫限制等功能。支持基于ISIM的鉴权、信令

的IPSec爱护、Tel-URI和SIPURI、信令压缩、Ut接口的GBA或digest

鉴权功能，MMTtelAS支持类似GSM的多媒体电话补充业务、Ut接口的

补充业务管理（基于XCAP）。IMS系统和EPS网络协作，可以供应和电路

域类似的语音业务及其补充业务，包括：号码显示、呼叫转移、呼叫等待、

会议电话等。

VoLTE系统采纳特地的IMSAPN来供应语音业务，为信令和语音数据

运用特定QCI的''承载"，从而保障给语音业务较高的QoS。通常，信令承

载采纳QCI=5的默认承载，语音承载采纳QC1=1的专用承载。

MobiledeviceRadio&accessnetworkServers(IMS)

图2VoLTE协议架构

EPC域主要包括MME、S-GU\P-GW,HSS等网元，须要支持IMSAPN、

初始附着的信令承载建立、P-CSCF发觉以及信令&GBR承载丢失的处理等

功能。

PCRF（策略和计费规则功能）主要完成策略限制决策和基于流进行计

费限制的功能。

eNodeB主要负责RRM（无线资源管理）功能；IP头压缩及用户数据流

加密；UE附着时的MME选择；寻呼信息的调度传输；广播信息的调度传输;

以及设置和供应eNodeB的测量等。

6SRVCC

6.1SRVCC网络架构

3GPPUTRAN/GERAN的SRVCC架构重用了3GPPTS23.237为IMS服务

连续性定义的会话转移(SessionTransfer)功能。SRVCC增加型MSCServer

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

在3GPPTS23.401定义的E-UTRAN架构基础上，引入了一种用于SRVCC

的功能，该功能由MSCServer供应,即SRVCC增加型MSCServer»

--------------------切换前的承载路径

-------------------切换后的承载路径

--------------------切换前的SIP信令路径

图3从E-UTRAN到3GppUTRAN/GERAN的SRVCC架构

SRVCC涉及到的接口包括：

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

UTRAN/GERAN之间供应SRVCC实力。

-E-UTRAN-MME间的S1-MME接口，用于E-UTRAN和MME之间的切换

信令传输，定义见3GppTS36.300»

-HSS-MME间的S6a接口，用于在E-UTRAN附着过程中下载SRVCC

相关信息到WE,或者在HSS中的STN-SR信息发生了变更时通知

MMEo假如MME从HSS接收到了ICS标记，则应包含此标记。

6.2引入ATCF/ATGW的SRVCC网络架构

由于SRVCC方案在漫游时(切换UE漫游或双方UE均漫游)，切换

过程和语音中断可能过长，无法满意切换中保证用户体验的需求，所以，

确定引入本地信令/媒体锚点(ATCF/ATGW),缩短远端更新带来的时延问

题，此架构也被称为eSRVCC架构。

在该方案中，将锚定点称为ATCF(AccessTransferControl

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

Gateway)做媒风光的锚定。当发生切换的时候，MSCServer只须要通

知ATCF做一个内部切换即可，不须要对远端进行更新，这样可以大大缩

短IMS侧更新会话的时长，达到缩短切换中语音中断的目的。其架构图如

图4所示。

collocationscenario

图4支持eSRVCC的网络架构

增加网元ATCF和ATGW,ATCF是AccessTransferControl

Functionality,ATGW是AccessTransferGateway。

ATCF是限制面的会话锚定网元，该网元的主要功能是在会话建立时以

及会话切换过程中对会话进行锚定。

ATGW是用户面的会话锚定网元，该网元受控于ATCF,主要对用户面数

据进行锚定。

切换埼PS链接

UE切换后探体链接

图5eSRVCC切换前后锚定变更

在该架构下，对于一个PS网络中的用户，其建立的会话是锚定在探

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

ATCF,然后连接到归属域的IMS(SCCAS),再通过SCCAS同远端用户建

立连接。此时的媒体链接是，UE到ATGW,然后ATGW再到远端。当切换

发生后，用户接入到CS网路，此时的信令是从CS接入到MSCServer,

再从MSCServer到ATCF,然后连接到S-CSCF和SCCAS,再通过SCC

AS同远端用户建立连接，此时的媒体链接是，UE到CS-MGW,然后CS-MGW

到ATG肌然后从ATGW到远端的媒体网关。可以看出在切换前后，ATGW

后的媒体链接是一样的，只须要ATCF通知ATGW本地切换媒体即可，省

却了远端更新的过程。

6.3SRVCC对基站的要求

基站应支持到3G/2G的SRVCC功能。

当E-UTRAN选择目标小区进行SRVCC切换时，E-UTRAN须要向MME发送一

个指示，表明该切换过程须要SRVCC。

E-UTRAN须要支持切换域选择。

切换域由E-UTRAN选择，E-UTRAN的选择逻辑应尽可能把话务留在LTE

域。为了取得域切换所必需的信息，E-UTRAN可以依据“SRVCC操作可能”

标记以及/或对某个特定UE已建立的QCI=1的承载来确定须要测量的相邻

小区列表。

E-UTRAN可以依据下面的做法确定相邻小区列表（NCL）：

-假如“SRVCC操作可能”标记被设为“真”（就是说，EPC和UE都具

备SRVCC的实力），那么不具有VoIP实力的小区也可以被包括在NCL

作为候选的目标小区，无论这个UE是否建立了带有QCI=1的承载。

而且：

1）假如UE已经建立一个QCI=1的承载，并且所选择的目标小区是具

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

括SRVCC指示；

2）假如UE已经建立一个QCI=1的承载，但是所选择的目标小区不具

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

SRVCC指示;

3）假如UE还没有建立QCI=1的承载，那么E-UTRAN在Handover

Required消息中不包括SRVCC指示。

假如“SRVCC操作可能”标记被设为“否”（就是说，EPC和UE至

少有一个不具备SRVCC的实力），那么E-UTRAN在HandoverRequired

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

1）假如这个UE己经建立一个QC1=1的承载，NCL中不能包括没有

VoIP实力的小区;

2）假如这个UE没有建立QCI=1的承载，NCL中可以包括没有VoIP实

力的小区。

6.4SRVCC对核心网的要求

6.4.1SRVCC增加型MSCServer

为了支持SRVCC,MSCServer须要供应下面的功能：

-处理来自Sv接口的针对语音部分的重定位打算过程。

-触发从IMS到CS的会话转移过程或紧急会话转移过程。

协调CS切换和IMS会话转移过程。

发起位置更新过程，而不须要UE侧发起。

假如支持IC$功能，并且通过Sv接口接受到IC$标记，那么MSC

Server执行ICS功能。

假如有紧急会话，依据条件可以发送用户位置报告消息到GMLC,支

持位置连续业务。

-不能对任何被转移的或正在进行转移的呼叫供应放音或者其他带

内媒体。

eMSCServer作为和IMS域的连接点，须要产生ICID,用于增加的

1CS业务的MSC还要供应用户的位置信息（例如，CGI或者SAD

或者用户时区信息。

6.4.2MME

为了支持SRVCC,MME须要供应下面的功能:

支持PS承载的拆分，分别出语音的PS承载和非语音的PS承载。

对于非语音的PS承载，按3GPPTS23.401定义的RAT间的切换过

程，切换到目标小区。

对于语音的PS承载，通过Sv接口触发SRVCC切换到目标小区。这

个过程只触发一次，不管UE当前运用的语音PS承载（如QCI=1）

数目是多少。

协调PS切换和SRVCC切换过程。

选择支持SRVCC功能的MSC,可以基于DNS过程或者本地配置。

6.4.3HSS

为了支持SRVCC,MME须要供应下面的功能：

HSS须要存贮用户的SRVCCSTN-SR和C-MSISDN和可选的ICS标记，

在UE进行LTE附着的时候，能从HSS下载到MME上。

对于HSPA,STN-SR和C-MSISDN是在进行GPRS附着时,从HSS下

载到SGSN上的。

-当STN-SR被修改或者从用户的订阅信息中删除时，HSS应通知

MME/SGSN,

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

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

6.4.4S-GW/P-GW

SRVCC技术对S-GW/P-GW没有新的需求。

6.4.5ATCF

ATCF位于用户当前所在网络（漫游时位于探望网络，非漫游时位于归

属网络），供应会话信令锚定和媒风光切换限制功能。

接入切换限制功能（ATCF）位于当前服务网络（假如是漫游则为探望

网络）。当运用部署了ATCF的增加SRVCC时，在呼叫过程中以及切换前

后ATCF都会包含在会话的限制面之中。

ATCE可能及服务网络中现有的某网元合设（如：P-CSCF或IBCF）.

ATCF必需：

-依据运营商策略，决策：

1）安排STN-SR：

2）将其自身插入SIP会话路径：并且

3）指示ATGW锚定起呼或终呼会话的媒体；

-保持监控这些会话（无论是振铃态、激活态还是保持态），以便执

行所选会话的接入切换；

-执行接入切换并将ATGW更新至（CS）接入支路的新媒体路径，并

无须发起远端更新；

-接入切换之后，向SCCAS发起更新，通知SCCAS发生了接入切

换，以确保T-ADS具有当前运用的接入信息；

-处理接入切换中的失败场景。

接入切换之后，依据本地策略，ATCF可能将ATGW从媒体路径中移

除。该步骤须要进行远端更新。

假如要运用MSCServerassistedmid-call功能，SCCAS还须要

供应须要切换的振铃态、保持态和/或会议状况的会话状态信息。

ATCF不能修改UE和SCCAS之间交互的动态STK

6.4.6ATGW

ATGW及ATCF位于同一网络内，由ATCF限制供应媒风光锚定和媒风光

切换功能。ATGW还可供应编解码转换功能。

接入切换网关(ATGW)由ATCF限制。假如运用部署了ATCF的增加

SRVCC,依据服务网络的本地策略，ATGW在呼叫过程中以及切换之后，保

持在会话的媒体路径之中。

假如MSC服务器不支持切换之前运用的媒体格式，则ATGW须要支持

编解码转换。

依据ATCF的位置，不同的物理节点可以考虑充当ATGW,如IMS-AGW

或TrGW.

6.5SRVCC对终端的要求

终端支持上报SRVCC实力。

终端支持LTE下对2G/3G网络的异系统测量，并支持SRVCC到2G/3G网络。

7基站基本功能

7.1鲁棒性报头压缩

基站应支持鲁棒性报头压缩(ROHC)功能。基站应对语音分组的报头

进行压缩，并至少支持下表中针对RTP报文的“RTP/UDP/IP”协议框架

(0x0001)和针对RTCP报文的“UDP/IP”协议框架(0x0002)。

ROHC功能应支持对IPv4和IPv6报头的压缩。

表1建议支持的报头压缩协议和协议框架

协议框架标用途参考规范必选/可

识选

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无线承载要求

基站应支持VoLTE的无线承载组合如下:

-语音业务：SRB1+SRB2+2xAMDRB+1xUMDRB,其中，2

个AMDRB分别用于QCI=5和QCI=8或9的EPS承载，1个UMDRB用于

QCI=1的EPS承载;

-视频+语音业务：SRB1+SRB2+2xAMDRB+2xUMDRB,其中，

2个AMDRB分别用于QCI=5和QCI=8或9的EPS承载，1个UMDRB用于

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

载。

基站应支持速率为12.2kbps、7.4kbps、5.9kbps和4.75kbps的AMR

业务承载和速率为23.85kbps、12.65kbps、8.85kbps和6.60kbps的AMR-WB

业务承载。

7.3RLC配置

RLC依据如下要求配置：

:带格式的：法语（法国）

-—^UnacknowledgedMode(UM)forEPSbearerswithQCI=1

(语音)

-UnacknowledgedMode(UM)forEPSbearerswithQCI=2(视

频）

一_AcknowledgedMode(AM)forEPSbearerswithQCI=5

-AcknowledgedMode(AM)forEPSbearerswithQCI=8/9

7.4DRX

为削减UE的耗电，基站应支持LTE非连续接收（DRX）。

非连续接收周期包含LongCycle和ShortCycle»

7.5准入限制和QoS保障

基站应支持针对VoLTE业务的准入限制功能和GBRMonitoring功能。

基站应支持基于QoS的资源调度。

7.6半静态调度

基站应支持半静态调度SPS。

对于TD-LTE基站，半静态调度及波束赋形的协同工作方式需进一步探

讨。

7.7TTIBunddling

为提升小区边界的上行覆盖，基站应支持TTIBundlingo

对于TD-LTE基站，TTIBundling只适用于TDDconfiguration0/1/6

上下行时隙配置。TTIBundling不行及SPS同时运用。

7.8加密/解密

基站应支持VoLTE业务在空口的加密和解密，应支持ZUC算法。

8核心网子系统功能

8.1IMS基本功能要求

8.1.1IMS基本集

8.1.1.1通用IMS功能

(1)SIP注册

UE和IMS核心网必需支持3GppTS24.229中定义的SIP注册流程，这也

包括IETFRFC3608中定义的业务路由发觉机制。网络必需支持

P-Visited-Network-ID头域。UE必需包含ICSI值用于指示IMS多媒体电话

业务，即，3GPPTS24.2295.1.1.2.1节中定义的。UE和IMS核心网必需

支持3GppTS24.229定义的网络侧发起的去注册过程。UE能够订阅3GPPTS

24.2295.1.1.3节中定义的注册事务包。

为了支持视频呼叫，UE必需遵从IETFRFC3840的要求，在REGISTER

恳求的Contact头域中增加"video”媒体功能标记。

(2)鉴权

UE和IMS核心网须支持支PPTS24.229和3GppTS33.203中定义的包

含IMS-AKA、Sec-Agree和IPSec机制的IMS鉴权过程，同时还要支持完整

性爱护过程。考虑究竟层的平安性，加密爱护功能是可选的。

IMS核心网和UE都必需支持基于ISIM的鉴权程序。

依据3GppTS23.228附录和3GppTS24.229附录C.2定义,假如依据

上没有ISIM,那么UE和IMS核心网都必需支持基于USIM的鉴权程序。这个

也包括支持P-AssociatedUniformResourceIdentifier(URI)头以处理

闭锁的IPMultimediaPublicIdentities(IMPU)»

UE和IMS核心网必需支持3GPPTS24.623定义的Ut接口的鉴权流程。

(3)寻址

UE和IMS核心网必需支持SIPURI和基于IMPU的MSISDN。

UE和网络必需支持3GppTS24.229中节的选项2和节中定义的本地号

码。UE必需依据3GppTS24.229中的节设置“phone-context”参数。

UE和IMS核心网必需支持P-Called-PartyTD头域，网络要依据3GppTS

24.229中的要求运用该头域。UE和网络都不要求支持GRUU。

(4)呼叫建立和释放

UE和IMS核心网要遵从3GPPTS24.229中定义的SIP呼叫建立和释放程

序，包括运用Route头域。UE要依据3GppTS24.229的要求传递1>'“6$$-

岫1\丫0心-1[1£0头域。

UE和IMS核心网都要支持牢靠的临时响应。

为了给网络指示IMS业务类型，UE必需依据3GppTS24.229的要求运用

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

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

(5)分叉

网络不要求支持分叉功能，但是，考虑互操作和前向兼容性，UE必需

能够接收由于分叉恳求产生的响应，并依据IETFRFC3261、3GPPTS23.228

第节和3GppTS24.229操作。

(6)信令跟踪

UE可选支持3GppTS24.229第节定义的故障解除事务包。

(7)信令压缩

SigComp功能是运营商可配置的。UE和P-CSCF可选支持信令压缩,其中，

UE的要求在3GppTS24.229的8.1节中定义，P-CSCF的要求在3GppTS

24.229的8.2节中定义。

补充业务

(1)概述

UE和TAS必需支持下表列出的补充业务。

表2补充业务

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）补充业务配置

UE和IMS核心网必需支持3GppTS24.623定义的Ut接口的XCAP,用于配

置补充业务。

（3）多方会议

UE和IMS核心网必需支持3GppTS24.605中定义的程序，同时还要遵从

以下规定。

UE和IMS核心网必需支持3GppTS24.147第节中定义的三方会话创建

程序。

要邀请其他用户加入到会议，UE和IMS核心网必需支持3GppTS24.147

第5.3.1.5.3中定义的程序，UE还应利用UE和IMS网络现有会议会话中的对

话来发送REFER方法。UE能够将Replaces头增加到REFER中的Refer-to头域

中。

UE和IMS核心网必需支持3GppTS24.605中的签约会话状态事务程序。

IMS核心网必需支持以下单元和属性：

•conference-info：entity

,maximum-user-count

,users

/user:entity

/display-text

/endpoint:entity

-status(supportedvalues:connected,disconnected,

on-hold)

UE和IMS核心网必需支持会议会话中的语音媒体成分。不要求支持

Floorcontro功能。

UE和IMS核心网能够支持会议会话中有一个语音和一个视频流。

视频会议是由会议创建UE用INVITE恳求建立的，其中的SDPoffer包含

有语音和视频媒体描述符，见3GppTS24.147第5.3.1.3.3节描述。

参与会议的UE可以仅用语音业务，这可以通过将SDP应答中的视频描

述符端口号设置为0来实现。

视频会议中的参及者可以通过发送SIPre-INVITE,并将其中的视频描

述符端口号设置为0,来恳求退出会议。

视频流也可以通过发送一个新的SIPre-INVITE恳求，并将其中的视频

描述符端口号设置为一个非0值，来重新建立。

假如建立视频会议的会议参与者发送一个SIPre-INVITE,其中的视

频被删除了，由网络策略来确定是否要将会议降级为一个语音会议，或者

确定在会议发起者在只运用语音的状况下视频会议还要不要接着。

(4)通信等待

UE和IMS核心网必需支持3GppTS24.615中定义的基于终端的业务,

不要求支持基于网络的业务。3GPPTS24.615第4.4.1中定义的通信等待

不做要求。UE要求支持Alert-Info,其取值遵从3GppTS24.615»业务的

激活、去激活和查询则不做要求。

（5）消息等待指示

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

待指示事务包。

（6）主叫标识限制

UE必需支持3GppTS24.607定义的SIP程序，业务配置则是可选的。

（7）被叫标识限制

UE必需支持3GppTS24.607定义的SIP程序，业务配置则是可选的。

（8）通信转移

UE和IMS核心网必需支持3GppTS24.604中定义的通信转移（CDIV）SIP

程序。CDIV通知业务不做要求。UE和IMS必需支持下表中列出的条件和动

作，用于CDIV业务的激活、去激活和查询（XCAP操作），并建议UE支持

History-Info头用于转移方的呈现。

表3CDIV中支持的条件和动作

Conditionbusy

Conditionmedia(supportedmediatypes:audio,audio

ANDvideo)

Conditionno-answer

Conditionnot-registered

Conditionnot-reachable(Note)

Actiontarget

ActionNoReplyTimer

（9）通信闭锁

UE和IMS核心网必需支持3GppTS24.611中定义的SIP程序，UE和IMS

核心必需支持下表中列出的条件，用于业务激活、去激活和查询（XCAP操

作）。

表4CB中支持的条件

roaming

international

international-exHC

（10）呼叫保持

UE能够利用3GppTS24.610第节定义的程序恳求语音和视频媒体流进

行保持或者复原。

假如语音和视频媒体流都被保持了，网络只能发起给被保持的用户供

应录音通知的流程，或者利用3GppTS24.610第4.5.2.4节中定义的网络

选项来削减带宽。

要复原视频媒体流，须遵从3GppTS26.114第14.3的要求。

8.1.1.3呼叫建立过程

(1)SIP预留

UE必需支持IETFRFC3312和IETFRFC4032中定义的SIP预留机制。依

据3GPPTS24.229第5.23.1节中的定义,UE应运用Supported头,而不是

Require头，来指示自己支持预留。依据3GppTS24.229第5.1.3.1节的定

义，UE在发起一个IMS会话的时候，必需始终包含precondition-tag。

运营商可以关闭网络中预留机制的运用。被叫UE的实现及主叫是否运

用预留机制无关。

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

-PDN连接的丢失

依据3GppTS24.229第5.2.8的要求，假如UE和网络间的PDN连接中断

了，网络必需终端跟该UE相关的全部在线SIP会话。

一旦UE重新复原了PDN连接，而在IP连接丢失期间，用户的IP地址变更

了，或者IMS注册超时了，那么，UE必需执行一次新的初始IMS注册。

-SIP信令承载丢失

依据3GppTS24.229第5.2.8的要求，假如依P信令承载丢失了,网络

必需终止跟该UE相关的全部的在线SIP会话。

假如SIP信令承载丢失了，UE必需重新建立PDN连接，这会触发网络发

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

接丢失期间，用户的IP地址变更了，或者IMS注册超时了，UE必需执行一

次新的初始IMS注册。

-媒体承载和无线连接的丢失

依据TS24.229第5.2.8的要求，假如用于语音的GBR承载建立失败，或

者在会话过程中丢失了，网络必需终止及语音流相关的会话。承载一旦丢

失，PCRF应通知P-CSCF。

依据3GPPTS24.229第6.1.1节的定义，假如SIP会话包含媒体流，并

且用于其它媒体流的专有承载建立失败，或者在会话过程中丢失了，UE应

基于自己的选择修改、拒绝或终止及该专有媒体承载相关的SIP会话。媒

体类型不同，UE的行为也可不同。

假如UE已经丢失了无线连接，后来又重新复原了无线连接，而且在无

线连接中断的过程中，UE的IMS注册超时了，UE必需支持一次新的IMS初始

注册。

-视频呼叫

假如用于视频的GBR承载建立失败，或者在会话过程中丢失了，网络可

以基于策略将会话作为语音呼叫接着处理，也可以依据3GPPTS24.229第

5.2.8节的要求终止SIP会话，此时PCRF应通知P-CSCF承载丢失了。

假如用于视频的GBR承载建立失败，或者在会话过程中丢失了，UE可以

依据3GppTS24.229第6.1.1节的要求，修改、拒绝或者中断跟媒体承载

相关的SIP会话。

假如用于视频的Non-GBR承载建立失败，或者在会话过程中丢失了，或

者所供应的QoS级别不够,UE可以依据3GppTS24.229第6.1.1节的要求,

修改、拒绝或者中断跟该专用媒体承载相关的SIP会话。

(3)语音媒体

用于语音媒体的SDPoffer/answer必需依据3GppTS26.114第6.2.2

节中定义的进行编码。

(4)多媒体

具有媒体功能全集的UE可以发送包含多个“m=”行的SDPoffer,来指

示自己想建立一个更高级别的多媒体会话。

假如这些“m=”行中的一个指示UE想建立一个语音会话，采纳的是兼

容的编解码，UE必需接受offer,并允许运用自己能够支持的任何媒体流。

对于自己不支持的媒体流，UE将端口号设置为0。

具有媒体功能全集的UE,还可以可选地通过发送SDPoffer中包含了多

个“m=”行的的SIP(re-)INVITE恳求，来进行会话的更新，以指示自己

想要将会话扩展为一个更高级别的多媒体会话。UE必需接受offer,并允

许运用自己能够支持的任何媒体流。对于自己不支持的媒体流，UE将端口

号设置为0。

(5)视频呼叫

UE和网络能够建立视频呼叫，在会话建立过程中，通过发送SIP

(re-)INVITE恳求，其中的SDPoffer包含语音和视频媒体描述符，在语音

会话中增加视频来实现的。

为了指示远端的forking,UE必需遵从IETFRFC3840和RFC3841,

在INVITE恳求中的Accept-Contact头域包含“video”媒体特性标记用于

视频呼叫。

不管视频媒体是不是$DPoffer的一部分，UE都必需能够在INVITE恳求

的Contact头域包含一个"video”媒体特性标记，以指示自己的视频处理

实力。

不管视频媒体是不是SDPanswer的一部分，UE都必需能够在全部的18x

或200响应的Contact头域包含一个"video”媒体特性标记，以指示自己

的视频处理实力。

UE能够发送带有全双工视频媒体的SDPoffer和应答消息。

SDP应答可以通过将视频媒体的描述符端口号设置为0来拒绝视频媒

体，也可以通过忽视SDPdirection属性或者利用sendrecvSDP属性来接

收全双工模式的视频媒体，还可以通过利用sendonly或recvonlySDP

属性来接收单工模式的视频媒体。

视频呼叫的视频流可以在单工或双工模式间变更，或者通过带有合适

的视频媒体描述符(sendrecv,sendonly,recvonly或inactive)的SDP

0££61'的匿-1时。£恳求，使其去激活。

视频呼叫中的视频流可以通过发送SIPre-INVITE恳求来删除，其中的

SDPoffer的视频描述符端口号设置为0。

UE能够接收带有多个early对话的SIP响应，这个响应是由于fork恳求

产生的。UE也能够接收带有1个eary对话的语音和视频媒体。

SMSoverIP

依据3GppTS24.341第5.3.1和5.3.2节的定义,UE必需能够发送和接

收SM-over-IP,同时还应支持3GppTS24.341第、5.3.2.4和节定义的状

态报告实力、发送报告、存储空间通知。

IMS核心网必需具有具-SM-GW网元,支持3GppTS24.341第5.3.3.1节

中定义的通用程序，以及3GppTS24.341第5.3.3.3和第5.3.3.4节中定义

的功能。

8.1.2IMS媒体

语音编码

依据3GppTS26.071、TS26.090、TS26.073和TS26.104中的定义，

UE和IMS中的媒风光网元必需支持AMR和AMR-WB语音编码，以及3GppTS

26.093中定义的全部8种模式和源速率限制操作，还应支持这8种编码模式

的全部子集。

在发送时，UE和IMS中的媒风光网元能够将变更的编码模式及每个

帧的边界对齐，并且能够限制编码模式变更，以及其他任何一个帧边界对

齐，犹如3GppTS26.103UMTS_AMR_2的定义;还能限制编码模式变更,

以使得编码模式及协商的编码模式集接近。

在接收时，UE和IMS中的媒风光网元能够任何帧边界的编码模式变

更，或者变更为协商的编码模式集合中的任何一种编码模式。

8.1.2.2视频编码

IMS核心网用户而网元必需支持3GppRIOTS26.114第5.2.2节中的定

义的ITU-TH.264CBP级别1.2。

3GPPR8TS26.114第5.2.2节定义的对ITU-TH.263Profile0Level

45的支持则不做要求。

必需支持在RTP媒体流中传送新的参数集，以变更流中的视频信号辨别

率，只要这些参数集符合协商的结果。

收到一个采纳H.264编码的FIR媒体流，UE和网络中的媒风光网元

必需发送一个当前激活的参数集。

RTP和SDP

(1)RTP

必需采纳IETFRFC3551中定义的RTPAVP。

(2)SDP

运用AVP时，不能运用SDPCapNeg机制。

(3)SDP