VoLTE总体技术方案

1、VoLTE总体技术方案（v 0.3）TD-SCDMA研究开发和产业化项目专家组TD-LTE工作组2013年10月修改记录版本日期更新内容备注V0.12013-8-23大纲目 录VoLTE总体技术方案 （v 0.3）11范围52参考规范53定义及缩略语53.1定义53.2缩略语64背景及简介65VoLTE网络架构66SRVCC76.1SRVCC网络架构76.2引入ATCF/ATGW 的 SRVCC 网络架构86.3SRVCC对基站的要求106.4SRVCC对核心网的要求116.4.1SRVCC增强型MSC Server116.4.2MME116.4.3HSS116.4.4S-GW/P-GW126

2、.4.5ATCF126.4.6ATGW126.5SRVCC对终端的要求137基站基本功能137.1鲁棒性报头压缩137.2无线承载要求147.3RLC配置147.4DRX147.5准入控制和QoS保障157.6半静态调度157.7TTI Bunddling157.8加密/解密158核心网子系统功能158.1IMS基本功能要求158.1.1IMS基本集158.1.2IMS媒体228.2EPC基本功能258.3PCC基本功能258.4补充要求258.4.1IP 版本258.4.2互通漫游268.4.3被叫域选择268.4.4短信268.4.5彩信268.4.6业务一致性279终端基本功能279.1

3、VoLTE终端架构279.2基本功能要求289.2.1无线功能要求289.2.2IMS功能要求299.2.3VoLTE业务质量要求299.2.4CSFB语音方案并存要求299.3VoLTE业务功能要求299.3.1语音业务299.3.2视频业务309.3.3短消息业务309.3.4彩信业务309.3.5补充业务309.3.6数据业务309.4人机界面要求309.5卡槽要求3110VoLTE业务流程3110.1附着过程3110.2主叫流程3110.3被叫流程3310.4呼叫释放3311SRVCC流程3411.1与SRVCC相关的E-UTRAN附着过程3411.2与SRVCC相关的业务请求过程和相

4、关的PS域切换流程3411.2.1与SRVCC相关的业务请求过程3411.2.2与SRVCC相关的PS域切换流程3411.3E-UTRAN发起的SRVCC流程3511.3.1从E-UTRAN到GERAN 的SRVCC过程，不带DTM3511.3.2从E-UTRAN 到GERAN的支持DTM但不支持DTM切换的SRVCC过程和从E-UTRAN到UTRAN不支持PS切换的SRVCC过程3911.3.3从E-UTRAN到UTRAN支持PS HO的SRVCC过程或到GERAN的支持DTM切换的SRVCC过程3911.4eSRVCC流程4411.4.1E-UTRAN/UTRAN 的attach过程441

5、1.4.2HSS 向MME/SGSN 更新 STN-SR 过程4411.4.3主叫流程4511.4.4被叫流程4611.4.5切换流程(无Mid-Call，呼叫被ATCF锚定，为通话状态)4811.5差错处理5011.5.1MSC开始会话转移前的差错5011.5.2UE收到切换命令之后的差错5011.5.3切换取消5012紧急呼叫51VoLTE总体技术方案 （v 0.3）11范围62参考规范63定义及缩略语63.1定义63.2缩略语64背景及简介75VoLTE网络架构76SRVCC86.1SRVCC网络架构86.2引入ATCF/ATGW 的 SRVCC 网络架构96.3SRVCC对基站的要求1

6、16.4SRVCC对核心网的要求126.4.1SRVCC增强型MSC Server126.4.2MME126.4.3HSS126.4.4S-GW/P-GW136.4.5ATCF136.4.6ATGW136.5SRVCC对终端的要求147基站基本功能147.1鲁棒性报头压缩147.2无线承载要求157.3RLC配置157.4DRX167.5准入控制和QoS保障167.6半静态调度167.7TTI Bunddling167.8加密/解密168核心网子系统功能168.1IMS基本功能要求168.1.1IMS基本集168.1.2IMS媒体238.2EPC基本功能268.3PCC基本功能278.4补充要

7、求278.4.1IP 版本278.4.2互通漫游278.4.3被叫域选择278.4.4短信288.4.5彩信288.4.6业务一致性289终端基本功能299.1VoLTE终端架构299.2基本功能要求309.2.1无线功能要求309.2.2IMS功能要求309.2.3VoLTE业务质量要求309.2.4CSFB语音方案并存要求309.3VoLTE业务功能要求319.3.1语音业务319.3.2视频业务319.3.3短消息业务319.3.4彩信业务319.3.5补充业务329.3.6数据业务329.4人机界面要求329.5卡槽要求3210VoLTE业务流程3310.1附着过程3310.2主叫流程

8、3310.3被叫流程3410.4呼叫释放3511SRVCC流程3511.1与SRVCC相关的E-UTRAN附着过程3511.2与SRVCC相关的业务请求过程和相关的PS域切换流程3611.2.1与SRVCC相关的业务请求过程3611.2.2与SRVCC相关的PS域切换流程3611.3E-UTRAN发起的SRVCC流程3611.3.1从E-UTRAN到GERAN 的SRVCC过程，不带DTM3611.3.2从E-UTRAN 到GERAN的支持DTM但不支持DTM切换的SRVCC过程和从E-UTRAN到UTRAN不支持PS切换的SRVCC过程4011.3.3从E-UTRAN到UTRAN支持PS H

9、O的SRVCC过程或到GERAN的支持DTM切换的SRVCC过程4111.4eSRVCC流程4511.4.1E-UTRAN/UTRAN 的attach过程4511.4.2HSS 向MME/SGSN 更新 STN-SR 过程4611.4.3主叫流程4611.4.4被叫流程4711.4.5切换流程(无Mid-Call，呼叫被ATCF锚定，为通话状态)4911.5差错处理5111.5.1MSC开始会话转移前的差错5111.5.2UE收到切换命令之后的差错5111.5.3切换取消5112VoLTE性能5212.1VoLTE语音质量5212.2VoLTE KPI指标5313紧急呼叫531 范围本方案定义

10、了VoLTE的网络框架，和LTE基站、IMS核心网、终端支持VoLTE的相关技术要求。本方案对不涉及互联互通，仅为运营商内部实现方法的技术细节不做规定。本方案终端仅针对多模单待终端做要求，双待机不在本方案讨论范围内。2 参考规范本技术方案引用如下文档的相关技术内容。引用时包含日期或版本编号的文档，非此编号的文档可能不适用该文档；若该文档不包含日期或版本编号，其最新版本适用于本技术方案。本技术方案中的3GPP标准均为3GPP R10阶段2013年6月版本。GSMA IR.92 IMS Profile for Voice and SMS v7.0GSMA IR.94 IMS Profile for

11、 Conversational Video Service v5.03GPP TS 23.216Single Radio Voice Call Continuity(SRVCC);Stage 23GPP TS 23.228IP Media Subsystem(IMS);Stage 23GPP TS 23.237IP Media Subsystem(IMS) Service Continuity;Stage 23GPP TS 36.300Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terres

12、trial Radio Access Network(E-UTRAN); Overall Description;Stage 23GPP TS 36.321Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Acces Control (MAC) protocol specification3GPP TS 36.322Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification3GPP T

13、S 36.323Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification3GPP TS 36.331Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC) protocol specification3 定义及缩略语3.1 定义eSRVCC：指在基本SRVCC基础上，引入了ATCF/ATGW功能实体的、增强型的SRVCC架构，主要用于

14、缩短用户在LTE与2/3G接入的切换时延。3.2 缩略语4 背景及简介LTE（Long Term Evolution）是国际主流的新一代宽带无线移动通信技术。与3G采用的CDMA（码分多址）技术不同，LTE以面向分组业务优化为目标，以OFDM（正交频分多址）和MIMO（多输入多输出天线）技术为基础，形成了全新的面向下一代移动通信系统的系统架构，将移动通信的接入速率提升到了100Mbps的范畴。基于LTE面向于分组域优化的系统设计目标，LTE的网络架构不再区分电路域和分组域，采用统一的分组域架构。在新的LTE系统架构下，不再支持传统的电路域语音解决方案，IMS控制的VoIP业务将作为未来LTE网

15、络中的语音解决方案。VoLTE是GSMA定义的标准LTE语音解决方案，其核心业务控制网络是IMS（IP多媒体子系统）网络，配合LTE和EPC网络实现端到端的基于分组域的语音、视频通信业务。 通过IMS系统的控制，VoLTE解决方案可以提供和电路域性能相当的语音业务及其补充业务，包括：号码显示、呼叫转移、呼叫等待、会议电话等。5 VoLTE网络架构VoLTE解决方案中，实现VoIP语音业务时，除了由EPS系统提供承载，由IMS系统提供业务控制外，通常还要由PCC架构实现用户业务QoS控制以及计费策略的控制。VoLTE业务的系统架构如图1所示。图1 VoLTE网络架构Error! Referenc

16、e source not found.中主要包括UE、eNodeB、MME、S-GW、P-GW、HSS、PCRF、IMS域（P-CSCF、I-CSCF、S-CSCF、AS）、MMTtel AS等网元。IMS域主要完成CSCF呼叫控制等功能。支持基于ISIM的鉴权、信令的IPSec保护、Tel-URI和SIP URI、信令压缩、Ut接口的GBA或http digest鉴权功能， MMTtel AS支持类似GSM的多媒体电话补充业务、Ut接口的补充业务管理（基于XCAP）。IMS系统和EPS网络配合，可以提供和电路域类似的语音业务及其补充业务，包括：号码显示、呼叫转移、呼叫等待、会议电话等。 Vo

17、LTE 系统采用专门的IMS APN来提供语音业务，为信令和语音数据使用特定QCI的“承载”，从而保障给语音业务较高的QoS。通常，信令承载采用QCI=5的默认承载，语音承载采用QCI=1的专用承载。图2 VoLTE协议架构EPC域主要包括MME、S-GW、P-GW、HSS等网元，需要支持IMS APN、初始附着的信令承载建立、P-CSCF发现以及信令&GBR承载丢失的处理等功能。PCRF（策略和计费规则功能）主要完成策略控制决策和基于流进行计费控制的功能。eNodeB主要负责RRM（无线资源管理）功能；IP头压缩及用户数据流加密；UE附着时的MME选择；寻呼信息的调度传输；广播信息的调度传输

18、；以及设置和提供eNodeB的测量等。6 SRVCC6.1 SRVCC网络架构3GPP UTRAN/GERAN的SRVCC架构重用了3GPP TS 23.237为IMS服务连续性定义的会话转移（Session Transfer）功能。SRVCC增强型MSC Server也可以具有3GPP TS 23.292所定义的ICS增强能力。在3GPP TS 23.401定义的E-UTRAN架构基础上，引入了一种用于SRVCC的功能，该功能由MSC Server提供，即SRVCC增强型MSC Server。图3 从E-UTRAN 到 3GPP UTRAN/GERAN的SRVCC架构SRVCC涉及到的接口包

19、括：- MMEMSC Server 间的Sv接口，用于在3GPP E-UTRAN和3GPP UTRAN/GERAN之间提供SRVCC能力。- E-UTRANMME 间的S1-MME接口，用于E-UTRAN和MME之间的切换信令传输，定义见3GPP TS 36.300。- HSS MME间的S6a接口，用于在E-UTRAN附着过程中下载SRVCC相关信息到MME，或者在HSS中的STN-SR信息发生了改变时通知MME。如果MME从HSS接收到了ICS标志，则应包含此标志。6.2 引入ATCF/ATGW 的 SRVCC 网络架构由于 SRVCC 方案在漫游时（切换 UE 漫游或双方 UE 均漫游）

20、，切换过程和语音中断可能过长，无法满足切换中保证用户体验的需求，所以，决定引入本地信令/媒体锚点（ATCF/ATGW），缩短远端更新带来的时延问题，此架构也被称为eSRVCC架构。在该方案中，将锚定点称为ATCF（Access Transfer Control Function），其主要做信令面的锚定，并控制ATGW(Access Transfer Gateway) 做媒体面的锚定。当发生切换的时候，MSC Server只需要通知ATCF做一个内部切换即可，不需要对远端进行更新，这样可以大大缩短IMS侧更新会话的时长，达到缩短切换中语音中断的目的。其架构图如图4所示。图4 支持eSRVCC的网

21、络架构增加网元ATCF和ATGW，ATCF是Access Transfer Control Functionality，ATGW是Access Transfer Gateway。ATCF是控制面的会话锚定网元，该网元的主要功能是在会话建立时以及会话切换过程中对会话进行锚定。ATGW是用户面的会话锚定网元，该网元受控于ATCF，主要对用户面数据进行锚定。图5 eSRVCC切换前后锚定变化在该架构下，对于一个 PS 网络中的用户，其建立的会话是锚定在拜访地的 ATCF(ATGW) 上，所以在切换前信令是从 UE 到 P-CSCF，再到 ATCF，然后连接到归属域的 IMS（SCC AS），再通过S

22、CC AS同远端用户建立连接。此时的媒体链接是，UE 到 ATGW，然后 ATGW 再到远端。当切换发生后，用户接入到 CS 网路，此时的信令是从 CS 接入到 MSC Server，再从 MSC Server 到 ATCF，然后连接到 S-CSCF 和 SCC AS，再通过 SCC AS 同远端用户建立连接，此时的媒体链接是，UE 到 CS-MGW，然后 CS-MGW 到 ATGW，然后从 ATGW 到远端的媒体网关。可以看出在切换前后，ATGW后的媒体链接是一样的，只需要 ATCF 通知 ATGW 本地切换媒体即可，省却了远端更新的过程。6.3 SRVCC对基站的要求基站应支持到3G/2G

23、的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能力的小区也可以被包括在

24、NCL作为候选的目标小区，无论这个UE是否建立了带有QCI=1的承载。而且：1) 如果UE已经建立一个QCI=1的承载，并且所选择的目标小区是具有VoIP能力的，那么E-UTRAN在Handover Required消息中不包括SRVCC指示；2) 如果UE已经建立一个QCI=1的承载，但是所选择的目标小区不具有VoIP能力，那么E-UTRAN在Handover Required消息中要包括SRVCC指示；3) 如果UE还没有建立QCI=1的承载，那么E-UTRAN在Handover Required消息中不包括SRVCC指示。- 如果“SRVCC操作可能”标志被设为“否” （就是说，EPC和

25、UE至少有一个不具备SRVCC的能力），那么E-UTRAN在Handover Required消息中不包括SRVCC指示。而且：1) 如果这个UE已经建立一个QCI=1的承载，NCL中不能包括没有VoIP能力的小区；2) 如果这个UE没有建立QCI=1的承载，NCL中可以包括没有VoIP能力的小区。6.4 SRVCC对核心网的要求6.4.1 SRVCC增强型MSC Server为了支持SRVCC，MSC Server需要提供下面的功能：- 处理来自Sv接口的针对语音部分的重定位准备过程。- 触发从IMS到CS的会话转移过程或紧急会话转移过程。- 协调CS切换和IMS会话转移过程。- 发起位置更

26、新过程，而不需要UE侧发起。- 如果支持ICS功能，并且通过Sv接口接受到ICS标志, 那么MSC Server执行ICS功能。- 如果有紧急会话，根据条件可以发送用户位置报告消息到GMLC，支持位置连续业务。- 不能对任何被转移的或正在进行转移的呼叫提供放音或者其他带内媒体。- eMSC Server作为和IMS域的连接点，需要产生ICID，用于增强的ICS业务的MSC还要提供用户的位置信息（例如，CGI或者SAI）或者用户时区信息。6.4.2 MME为了支持SRVCC，MME需要提供下面的功能：- 支持PS承载的拆分，分离出语音的PS承载和非语音的PS承载。- 对于非语音的PS承载，按3G

27、PP TS23.401定义的RAT间的切换过程，切换到目标小区。- 对于语音的PS承载，通过Sv接口触发SRVCC切换到目标小区。这个过程只触发一次，不管UE当前使用的语音PS承载（如QCI=1）数目是多少。- 协调PS切换和SRVCC切换过程。- 选择支持SRVCC功能的MSC，可以基于DNS过程 或者本地配置。6.4.3 HSS为了支持SRVCC，MME需要提供下面的功能：- HSS需要存贮用户的SRVCC STN-SR和C-MSISDN和可选的ICS标志，在UE进行LTE附着的时候，能从HSS下载到MME上。- 对于HSPA，STN-SR和C-MSISDN是在进行GPRS附着时，从HSS

28、下载到SGSN上的。- 当STN-SR被修改或者从用户的订阅信息中删除时，HSS应通知MME/SGSN。- HSS允许SCC AS更新用户profile中的STN-SR。如果有ATCF，STN-SR代表了ATCF，否则就代表SCC AS。6.4.4 S-GW/P-GWSRVCC技术对S-GW/P-GW没有新的需求。6.4.5 ATCFATCF位于用户当前所在网络（漫游时位于拜访网络，非漫游时位于归属网络），提供会话信令锚定和媒体面切换控制功能。接入切换控制功能（ATCF）位于当前服务网络（如果是漫游则为拜访网络）。当使用部署了 ATCF 的增强 SRVCC 时，在呼叫过程中以及切换前后 ATC

29、F 都会包含在会话的控制面之中。ATCF 可能与服务网络中现有的某网元合设（如：P-CSCF 或 IBCF）。ATCF 必须：-根据运营商策略，决策：1) 分配 STN-SR：2) 将其自身插入 SIP 会话路径；并且3) 指示 ATGW 锚定起呼或终呼会话的媒体；-保持监控这些会话（无论是振铃态、激活态还是保持态），以便执行所选会话的接入切换；-执行接入切换并将 ATGW 更新至（CS）接入支路的新媒体路径，并无须发起远端更新；-接入切换之后，向 SCC AS 发起更新，通知 SCC AS 发生了接入切换，以确保 T-ADS 具有当前使用的接入信息；-处理接入切换中的失败场景。 接入切换之后

30、，根据本地策略，ATCF 可能将 ATGW 从媒体路径中移除。该步骤需要进行远端更新。 如果要使用 MSC Server assisted mid-call 功能，SCC AS 还需要提供需要切换的振铃态、保持态和/或会议情况的会话状态信息。 ATCF 不能修改UE 和 SCC AS 之间交互的动态 STI。6.4.6 ATGWATGW与ATCF位于同一网络内，由ATCF控制提供媒体面锚定和媒体面切换功能。ATGW还可提供编解码转换功能。接入切换网关（ATGW）由 ATCF 控制。如果使用部署了 ATCF 的增强 SRVCC，根据服务网络的本地策略，ATGW 在呼叫过程中以及切换之后，保持在会

31、话的媒体路径之中。如果 MSC 服务器不支持切换之前使用的媒体格式，则 ATGW 需要支持编解码转换。根据 ATCF 的位置，不同的物理节点可以考虑充当 ATGW，如 IMS-AGW 或 TrGW。6.5 SRVCC对终端的要求终端支持上报SRVCC能力。终端支持LTE下对2G/3G网络的异系统测量，并支持SRVCC到2G/3G网络。7 基站基本功能7.1 鲁棒性报头压缩基站应支持鲁棒性报头压缩（ROHC）功能。基站应对语音分组的报头进行压缩，并至少支持下表中针对RTP报文的“RTP/UDP/IP”协议框架（0x0001）和针对RTCP报文的“UDP/IP”协议框架（0x0002）。ROHC功

32、能应支持对IPv4和IPv6报头的压缩。表1 建议支持的报头压缩协议和协议框架协议框架标识用途参考规范必选/可选0x0000不压缩RFC 4995可选0x0001RTP/UDP/IPRFC 3095, RFC 4815必选0x0002UDP/IPRFC 3095, RFC 4815必选0x0003ESP/IPRFC 3095, RFC 4815可选0x0004IPRFC 3843, RFC 4815可选0x0006TCP/IPRFC 4996可选0x0101RTP/UDP/IPRFC 5225可选0x0102UDP/IPRFC 5225可选0x0103ESP/IPRFC 5225可选0x010

33、4IPRFC 5225可选7.2 无线承载要求基站应支持VoLTE的无线承载组合如下： 语音业务：SRB1 + SRB2 + 2 x AM DRB + 1 x UM DRB，其中，2个AM DRB分别用于QCI=5和QCI=8或9的EPS承载，1个UM DRB用于QCI=1的EPS承载； 视频+语音业务: SRB1 + SRB2 + 2 x AM DRB + 2 x UM DRB，其中，2个AM DRB分别用于QCI=5和QCI=8或9的EPS承载，1个UM DRB用于QCI=1的EPS承载，另1个UM DRB用于non-GBR承载或QCI=2的EPS承载。基站应支持速率为12.2kbps、

34、7.4kbps、 5.9kbps 和4.75kbps 的AMR业务承载和速率为23.85kbps、12.65kbps、8.85kbps和6.60kbps的AMR-WB业务承载。7.3 RLC配置RLC按照如下要求配置： Unacknowledged Mode (UM) for EPS bearers with QCI = 1（语音） Unacknowledged Mode (UM) for EPS bearers with QCI = 2 (视频) Acknowledged Mode (AM) for EPS bearers with QCI = 5 Acknowledged Mode (AM

35、) for EPS bearers with QCI = 8/97.4 DRX为减少UE的耗电，基站应支持LTE非连续接收（DRX）。非连续接收周期包含Long Cycle和Short Cycle。7.5 准入控制和QoS保障基站应支持针对VoLTE业务的准入控制功能和GBR Monitoring功能。基站应支持基于QoS的资源调度。7.6 半静态调度基站应支持半静态调度SPS。对于TD-LTE基站，半静态调度与波束赋形的协同工作方式需进一步研究。7.7 TTI Bunddling为提升小区边界的上行覆盖，基站应支持TTI Bundling。对于TD-LTE基站，TTI Bundling只适用

36、于TDD configuration 0/1/6上下行时隙配置。TTI Bundling不可与SPS同时使用。7.8 加密/解密基站应支持VoLTE业务在空口的加密和解密，应支持ZUC算法。8 核心网子系统功能8.1 IMS基本功能要求8.1.1 IMS基本集 通用IMS功能（1） SIP 注册 UE和IMS核心网必须支持3GPP TS 24.229中定义的SIP注册流程，这也包括IETF RFC 3608中定义的业务路由发现机制。网络必须支持P-Visited-Network -ID头域。UE必须包含ICSI值用于指示IMS多媒体电话业务，即，3GPP TS 24.229 5.

37、节中定义的urn:urn-7:3gpp-service.ims.icsi.mmtel。UE和 IMS核心网必须支持3GPP TS 24.229定义的网络侧发起的去注册过程。UE能够订阅3GPP TS 24.229 节中定义的注册事件包。为了支持视频呼叫，UE必须遵从IETF RFC 3840的要求，在REGISTER请求的Contact头域中增加“video”媒体功能标记。（2） 鉴权 UE和IMS核心网须支持3GPP TS 24.229 和3GPP TS 33.203中定义的包含IMS-AKA、Sec-Agree 和IPSec机制的IMS鉴权过程，同时还要支持完整

38、性保护过程。考虑到底层的安全性，加密保护功能是可选的。IMS核心网和UE都必须支持基于ISIM的鉴权程序。根据3GPP TS 23.228附录 E.3.1和3GPP TS 24.229附录C.2定义，如果UICC上没有ISIM，那么UE和IMS核心网都必须支持基于USIM的鉴权程序。这个也包括支持P-Associated Uniform Resource Identifier (URI)头以处理闭锁的IP Multimedia Public Identities (IMPU)。UE和IMS核心网必须支持3GPP TS 24.623定义的Ut接口的鉴权流程。（3） 寻址 UE和IMS核心网必须支

39、持SIP URI和基于IMPU的MSISDN。 UE和网络必须支持3GPP TS 24.229中 5.1.2A.1.3节的选项2和5.1.2A.1.5节中定义的本地号码。UE必须根据3GPP TS 24.229中的7.2A.10节设置“phone-context”参数。UE和IMS核心网必须支持P-Called-Party-ID头域，网络要按照3GPP TS 24.229中的要求使用该头域。UE和网络都不要求支持GRUU。（4） 呼叫建立和释放 UE和IMS核心网要遵从3GPP TS 24.229中定义的SIP呼叫建立和释放程序，包括使用Route头域。UE要根据3GPP TS 24.229的

40、要求传递P-Access- Network-Info头域。UE和IMS核心网都要支持可靠的临时响应。为了给网络指示IMS业务类型，UE必须根据3GPP TS 24.229的要求使用ICSI值，ICSI值的格式是3GPP TS 24.173中定义的urn:urn-7:3gpp-service.ims.icsi. mmtel。（5） 分叉 网络不要求支持分叉功能，但是，考虑互操作和前向兼容性，UE必须能够接收由于分叉请求产生的响应，并根据IETF RFC 3261、3GPP TS 23.228第节和3GPP TS 24.229操作。（6） 信令跟踪 UE可选支持3GPP TS 24.

41、229第A节定义的故障排除事件包。（7） 信令压缩SigComp功能是运营商可配置的。UE和P-CSCF可选支持信令压缩，其中，UE的要求在3GPP TS 24.229的8.1节中定义，P-CSCF的要求在3GPP TS 24.229的8.2节中定义。 补充业务（1） 概述UE和TAS必须支持下表列出的补充业务。表2 补充业务Originating Identification Presentation 3GPP TS 24.607 Terminating Identification Presentation 3GPP TS 24.608 Originating

42、Identification Restriction 3GPP TS 24.607 Terminating Identification Restriction 3GPP TS 24.608 Communication Diversion Unconditional 3GPP TS 24.604 Communication Diversion on not Logged in 3GPP TS 24.604 Communication Diversion on Busy 3GPP TS 24.604 Communication Diversion on not Reachable 3GPP TS

43、 24.604 Communication Diversion on No Reply 3GPP TS 24.604 Barring of All Incoming Calls 3GPP TS 24.611 Barring of All Outgoing Calls 3GPP TS 24.611 Barring of Outgoing International Calls 3GPP TS 24.611 Barring of Incoming Calls - When Roaming 3GPP TS 24.611 Communication Hold 3GPP TS 24.610 Messag

44、e Waiting Indication 3GPP TS 24.606 Communication Waiting 3GPP TS 24.615 Ad-Hoc Multi Party Conference 3GPP TS 24.605 （2） 补充业务配置UE和IMS核心网必须支持3GPP TS 24.623定义的Ut接口的XCAP，用于配置补充业务。（3） 多方会议UE和IMS核心网必须支持3GPP TS 24.605中定义的程序，同时还要遵从以下规定。UE和IMS核心网必须支持3GPP TS 24.147 第.3节中定义的三方会话创建程序。要邀请其他用户加入到会议，UE和IM

45、S核心网必须支持3GPP TS 24.147 第.3中定义的程序，UE还应利用UE和IMS网络现有会议会话中的对话来发送REFER方法。UE能够将Replaces头增加到REFER中的Refer-to头域中。UE和IMS核心网必须支持3GPP TS 24.605中的签约会话状态事件程序。IMS核心网必须支持以下单元和属性： conference-info：entity maximum-user-count users user: entity display-text endpoint: entity status (supported values: connected, di

46、sconnected, on-hold) UE和IMS核心网必须支持会议会话中的语音媒体成分。不要求支持Floor contro功能。UE和IMS核心网能够支持会议会话中有一个语音和一个视频流。视频会议是由会议创建UE用INVITE请求建立的，其中的SDP offer包含有语音和视频媒体描述符，见3GPP TS 24.147第.3节描述。参加会议的 UE可以仅用语音业务，这可以通过将SDP应答中的视频描述符端口号设置为0来实现。视频会议中的参与者可以通过发送SIP re-INVITE，并将其中的视频描述符端口号设置为0，来请求退出会议。视频流也可以通过发送一个新的SIP re-I

47、NVITE请求，并将其中的视频描述符端口号设置为一个非0值，来重新建立。如果建立视频会议的会议参加者发送一个SIP re-INVITE，其中的视频被删除了，由网络策略来决定是否要将会议降级为一个语音会议，或者决定在会议发起者在只使用语音的情况下视频会议还要不要继续。（4） 通信等待UE和 IMS核心网必须支持3GPP TS 24.615中定义的基于终端的业务，不要求支持基于网络的业务。3GPP TS 24.615第4.4.1中定义的通信等待不做要求。UE要求支持Alert-Info，其取值遵从3GPP TS 24.615。业务的激活、去激活和查询则不做要求。（5） 消息等待指示 UE和IMS必

48、须支持3GPP TS 24.606 和 IETF RFC 3842中定义的消息等待指示事件包。（6） 主叫标识限制UE必须支持3GPP TS 24.607定义的SIP程序，业务配置则是可选的。（7） 被叫标识限制UE必须支持3GPP TS 24.607定义的SIP程序，业务配置则是可选的。（8） 通信转移UE和IMS核心网必须支持3GPP TS 24.604中定义的通信转移（CDIV）SIP程序。CDIV通知业务不做要求。UE和IMS必须支持下表中列出的条件和动作，用于CDIV业务的激活、去激活和查询（XCAP操作），并建议UE支持History-Info头用于转移方的呈现。表3 CDIV中支

49、持的条件和动作Condition busy Condition media (supported media types: audio, audio AND video) Condition no-answer Condition not-registered Condition not-reachable (Note) Action target Action NoReplyTimer （9） 通信闭锁UE和IMS核心网必须支持3GPP TS 24.611中定义的SIP程序，UE和IMS核心必须支持下表中列出的条件，用于业务激活、去激活和查询（XCAP操作）。表4 CB中支持的条件 roam

50、inginternationalinternational-exHC （10） 呼叫保持UE能够利用3GPP TS 24.610第节定义的程序请求语音和视频媒体流进行保持或者恢复。如果语音和视频媒体流都被保持了，网络只能发起给被保持的用户提供录音通知的流程，或者利用3GPP TS 24.610第节中定义的网络选项来减少带宽。要恢复视频媒体流，须遵从3GPP TS 26.114第14.3的要求。 呼叫建立过程（1） SIP预留UE必须支持IETF RFC 3312和IETF RFC 4032中定义的SIP预留机制。根据3GPP TS 24.229第5.1

51、.3.1节中的定义，UE应使用Supported头，而不是Require头，来指示自己支持预留。根据3GPP TS 24.229第节的定义，UE在发起一个IMS会话的时候，必须始终包含precondition-tag。 运营商可以关闭网络中预留机制的使用。被叫UE的实现与主叫是否使用预留机制无关。（2） 资源管理和SIP的融合 PDN连接的丢失根据3GPP TS 24.229第5.2.8的要求，如果UE和网络间的PDN连接中断了，网络必须终端跟该UE相关的所有在线SIP会话。一旦UE重新恢复了PDN连接，而在IP连接丢失期间，用户的IP地址改变了，或者IMS注册超时了，那么，UE

52、必须执行一次新的初始IMS注册。 SIP信令承载丢失根据3GPP TS 24.229第5.2.8的要求，如果SIP信令承载丢失了，网络必须终止跟该UE相关的所有的在线SIP会话。如果SIP信令承载丢失了，UE必须重新建立PDN连接，这会触发网络发起一次PDN连接建立以建立新的SIP承载。一旦SIP承载建立了，而在IP连接丢失期间，用户的IP地址改变了，或者IMS注册超时了，UE必须执行一次新的初始IMS注册。 媒体承载和无线连接的丢失根据TS 24.229第5.2.8的要求，如果用于语音的GBR承载建立失败，或者在会话过程中丢失了，网络必须终止与语音流相关的会话。承载一旦丢失，PCRF应通知P

53、-CSCF。根据3GPP TS 24.229第 6.1.1节的定义，如果SIP会话包含媒体流，并且用于其它媒体流的专有承载建立失败，或者在会话过程中丢失了，UE应基于自己的选择修改、拒绝或终止与该专有媒体承载相关的SIP会话。媒体类型不同，UE的行为也可不同。如果UE已经丢失了无线连接，后来又重新恢复了无线连接，而且在无线连接中断的过程中，UE的IMS注册超时了，UE必须支持一次新的IMS初始注册。 视频呼叫如果用于视频的GBR承载建立失败，或者在会话过程中丢失了，网络可以基于策略将会话作为语音呼叫继续处理，也可以根据3GPP TS 24.229第5.2.8节的要求终止SIP会话，此时PCRF

54、应通知P-CSCF承载丢失了。如果用于视频的GBR承载建立失败，或者在会话过程中丢失了，UE可以根据3GPP TS 24.229第6.1.1节的要求，修改、拒绝或者中断跟媒体承载相关的SIP会话。如果用于视频的Non-GBR承载建立失败，或者在会话过程中丢失了，或者所提供的QoS级别不够，UE可以根据3GPP TS 24.229第6.1.1节的要求，修改、拒绝或者中断跟该专用媒体承载相关的SIP会话。（3） 语音媒体用于语音媒体的SDP offer/answer必须按照3GPP TS 26.114第6.2.2节中定义的进行编码。（4） 多媒体 具有媒体功能全集的UE可以发送包含多个“m=”行的SDP offer，来指示自己想建立一个更高级别的多媒体会话。如果这些“m=”行中的一个指示UE想建立一个语音会话，采用的是兼容的编解码，UE必须接受offer，并允许使用自己能够支持的任何媒体流。对于自己不支持的媒体流，UE将端口号设置为0。具有媒体功能全集的UE，还可以可选地通过发送SDP offer中包含了多个“m=”行的的SIP (re-)INVITE请求，来进行会话的更新，以指示自己想要将会话扩展为一个更高级别的多媒体会话。UE