VoLTE总体技术方案.pdf

《VoLTE总体技术方案.pdf》由会员分享，可在线阅读，更多相关《VoLTE总体技术方案.pdf（51页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、 VoLTE 总体技术方案（v 0.3）TD-SCDMA 研究开发和产业化项目专家组 TD-LTE 工作组 2013 年 10 月 2/51 修改记录 版本 日期 更新内容 备注 V0.1 2013-8-23 大纲 3/51 目 录 VoLTE 总体技术方案（v 0.3）.1 1 范围.5 2 参考规范.5 3 定义及缩略语.5 3.1 定义.5 3.2 缩略语.6 4 背景及简介.6 5 VoLTE 网络架构.6 6 SRVCC.7 6.1 SRVCC 网络架构.7 6.2 引入 ATCF/ATGW 的 SRVCC 网络架构.8 6.3 SRVCC 对基站的要求.10 6.4 SRVCC 对

2、核心网的要求.11 6.4.1 SRVCC 增强型 MSC Server.11 6.4.2 MME.11 6.4.3 HSS.11 6.4.4 S-GW/P-GW.12 6.4.5 ATCF.12 6.4.6 ATGW.12 6.5 SRVCC 对终端的要求.13 7 基站基本功能.13 7.1 鲁棒性报头压缩.13 7.2 无线承载要求.14 7.3 RLC 配置.14 7.4 DRX.14 7.5 准入控制和 QoS 保障.15 7.6 半静态调度.15 7.7 TTI Bunddling.15 7.8 加密/解密.15 8 核心网子系统功能.15 8.1 IMS 基本功能要求.15 8.

3、1.1 IMS 基本集.15 8.1.2 IMS 媒体.22 8.2 EPC 基本功能.25 8.3 PCC 基本功能.25 8.4 补充要求.25 8.4.1 IP 版本.25 8.4.2 互通漫游.26 8.4.3 被叫域选择.26 8.4.4 短信.26 8.4.5 彩信.26 8.4.6 业务一致性.27 4/51 9 终端基本功能.27 9.1 VoLTE 终端架构.27 9.2 基本功能要求.28 9.2.1 无线功能要求.28 9.2.2 IMS 功能要求.29 9.2.3 VoLTE 业务质量要求.29 9.2.4 CSFB 语音方案并存要求.29 9.3 VoLTE 业务功能

4、要求.29 9.3.1 语音业务.29 9.3.2 视频业务.30 9.3.3 短消息业务.30 9.3.4 彩信业务.30 9.3.5 补充业务.30 9.3.6 数据业务.30 9.4 人机界面要求.30 9.5 卡槽要求.31 10 VoLTE 业务流程.31 10.1 附着过程.31 10.2 主叫流程.31 10.3 被叫流程.33 10.4 呼叫释放.33 11 SRVCC 流程.34 11.1 与 SRVCC 相关的 E-UTRAN 附着过程.34 11.2 与 SRVCC 相关的业务请求过程和相关的 PS 域切换流程.34 11.2.1 与 SRVCC 相关的业务请求过程.34

5、 11.2.2 与 SRVCC 相关的 PS 域切换流程.34 11.3 E-UTRAN 发起的 SRVCC 流程.35 11.3.1 从 E-UTRAN 到 GERAN 的 SRVCC 过程，不带 DTM.35 11.3.2 从 E-UTRAN 到 GERAN 的支持 DTM 但不支持 DTM 切换的 SRVCC 过程和从 E-UTRAN 到 UTRAN 不支持 PS 切换的 SRVCC 过程.39 11.3.3 从 E-UTRAN 到 UTRAN 支持 PS HO 的 SRVCC 过程或到 GERAN 的支持DTM 切换的 SRVCC 过程.39 11.4 eSRVCC 流程.44 11.

6、4.1 E-UTRAN/UTRAN 的 attach 过程.44 11.4.2 HSS 向 MME/SGSN 更新 STN-SR 过程.44 11.4.3 主叫流程.45 11.4.4 被叫流程.46 11.4.5 切换流程(无 Mid-Call，呼叫被 ATCF 锚定，为通话状态).48 11.5 差错处理.50 11.5.1 MSC 开始会话转移前的差错.50 11.5.2 UE 收到切换命令之后的差错.50 11.5.3 切换取消.50 12 紧急呼叫.51 5/51 1 范围 本方案定义了VoLTE的网络框架，和LTE基站、IMS核心网、终端支持VoLTE的相关技术要求。本方案对不涉及

7、互联互通，仅为运营商内部实现方法的技术细节不做规定。本方案终端仅针对多模单待终端，双待机不在本方案讨论范围内。2 参考规范 本技术方案引用如下文档的相关技术内容。引用时包含日期或版本编号的文档，非此编号的文档可能不适用该文档；若该文档不包含日期或版本编号，其最新版本适用于本技术方案。本技术方案中的 3GPP 标准均为 3GPP R10 阶段 2013 年 6 月版本。GSMA IR.92 IMS Pro Voice and SMS v7.0 GSMA IR.94 IMS Pro Conversational Video Service v5.0 3GPP TS 23.216 Single Ra

8、dio Voice Call Continuity(SRVCC);Stage 2 3GPP TS 23.228 IP Media Subsystem(IMS);Stage 2 3GPP TS 23.237 IP Media Subsystem(IMS)Service Continuity;Stage 2 3GPP TS 36.300 Evolved Universal Terrestrial Radio Access(E-UTRA)and Evolved Universal Terrestrial Radio Access Network(E-UTRAN);Overall Descriptio

9、n;Stage 2 3GPP TS 36.321 Evolved Universal Terrestrial Radio Access(E-UTRA);Medium Acces Control(MAC)protocol specification 3GPP TS 36.322 Evolved Universal Terrestrial Radio Access(E-UTRA);Radio Link Control(RLC)protocol specification 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access(E-UTRA

10、);Packet Data Convergence Protocol(PDCP)specification 3GPP TS 36.331 Evolved Universal Terrestrial Radio Access(E-UTRA);Radio Resource Control(RRC)protocol specification 3 定义及缩略语 3.1 定义 eSRVCC：指在基本 SRVCC 基础上，引入了 ATCF/ATGW 功能实体的、增强型的 SRVCC 架构，主要用于缩短用户在 LTE 与 2/3G 接入的切换时延。6/51 3.2 缩略语 4 背景及简介 LTE（Long

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

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

13、主要包括 UE、eNodeB、MME、S-GW、P-GW、HSS、7/51 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 网络配合，可以提供和电路域类似的语音业务及其补充业务，包括：号码显示、呼叫转移、呼叫等待、会议电话等。V

14、oLTE 系统采用专门的 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

15、 选择；寻呼信息的调度传输；广播信息的调度传输；以及设置和提供 eNodeB 的测量等。6 SRVCC 6.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 Serve

16、r。8/51 UEE-UTRANMMEMSC Server目标UTRAN/GERAN S-GW/P-GWIMSUEUm/UuIu-cs/AIu-ps/GbSvS11S1-MMES1-UE-UTRAN UuHSSS6aSGSNS3切换前的承载路径切换后的承载路径切换前的SIP信令路径SGi 图3 从 E-UTRAN 到 3GPP UTRAN/GERAN 的 SRVCC 架构 SRVCC涉及到的接口包括：-MMEMSC Server 间的 Sv 接口，用于在 3GPP E-UTRAN 和 3GPP UTRAN/GERAN 之间提供 SRVCC 能力。-E-UTRANMME 间的 S1-MME 接口

17、，用于 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 均漫游），切换过程和语音中断可能过长，无法满足切换中保证用户体验的需求，所以，决定引入本地信令/媒体锚点（ATCF/ATGW），缩短远端更新带来的

18、时延问题，此架构也被称为 eSRVCC 架构。在该方案中，将锚定点称为 ATCF（Access Transfer Control Function），其主要做信令面的锚定，并控制 ATGW(Access Transfer Gateway)做媒体面的锚定。当发生切换的时候，MSC Server 只需要通知 ATCF 做一个内部切换即可，不需要对远端进行更新，这样可以大大缩短IMS 侧更新会话的时长，达到缩短切换中语音中断的目的。其架构图如图 4 所示。9/51 UEISCMcMSC Server CS-MGWSCC AS ATCF*GmCS AccessTASI3ATGW*S-CSCFMw I2

19、P-CSCF*:Location of functionality depends on deployment and collocation scenarioMx 图4 支持 eSRVCC 的网络架构 增加网元 ATCF 和 ATGW，ATCF 是 Access Transfer Control Functionality，ATGW 是 Access Transfer Gateway。ATCF 是控制面的会话锚定网元，该网元的主要功能是在会话建立时以及会话切换过程中对会话进行锚定。ATGW 是用户面的会话锚定网元，该网元受控于 ATCF，主要对用户面数据进行锚定。SCC ASCSCFASUE

20、ATCFATGW远端媒体链接MSC ServerCS-MGW切换前原PS链接切换后CS链接切换后PS链接远端信令链接切换前媒体链接切换后媒体链接切换后媒体链接 图5 eSRVCC 切换前后锚定变化 在该架构下，对于一个 PS 网络中的用户，其建立的会话是锚定在拜访地的 ATCF(ATGW)上，所以在切换前信令是从 UE 到 P-CSCF，再到 ATCF，然后连接到归属域的 IMS（SCC AS），再通过 SCC AS 同远端用户建立连接。此时的10/51 媒体链接是，UE 到 ATGW，然后 ATGW 再到远端。当切换发生后，用户接入到 CS 网路，此时的信令是从 CS 接入到 MSC Ser

21、ver，再从 MSC Server 到 ATCF，然后连接到 S-CSCF 和 SCC AS，再通过 SCC AS 同远端用户建立连接，此时的媒体链接是，UE 到 CS-MGW，然后 CS-MGW 到 ATGW，然后从 ATGW 到远端的媒体网关。可以看出在切换前后，ATGW 后的媒体链接是一样的，只需要 ATCF 通知 ATGW 本地切换媒体即可，省却了远端更新的过程。6.3 SRVCC 对基站的要求 基站应支持到3G/2G的SRVCC功能。当E-UTRAN选择目标小区进行SRVCC切换时，E-UTRAN需要向MME发送一个指示，表明该切换过程需要SRVCC。E-UTRAN需要支持切换域选择

22、。切换域由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-UT

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

24、不能包括没有VoIP能力的小区；2)如果这个UE没有建立QCI=1的承载，NCL中可以包括没有VoIP能力的小区。11/51 6.4 SRVCC 对核心网的要求 6.4.1 SRVCC 增强型 MSC Server 为了支持SRVCC，MSC Server需要提供下面的功能：-处理来自Sv接口的针对语音部分的重定位准备过程。-触发从IMS到CS的会话转移过程或紧急会话转移过程。-协调CS切换和IMS会话转移过程。-发起位置更新过程，而不需要UE侧发起。-如果支持ICS功能，并且通过Sv接口接受到ICS标志,那么MSC Server执行ICS功能。-如果有紧急会话，根据条件可以发送用户位置报告消

25、息到GMLC，支持位置连续业务。-不能对任何被转移的或正在进行转移的呼叫提供放音或者其他带内媒体。-eMSC Server作为和IMS 域的连接点，需要产生 ICID，用于增强的 ICS业务的 MSC 还要提供用户的位置信息（例如，CGI 或者 SAI）或者用户时区信息。6.4.2 MME 为了支持SRVCC，MME需要提供下面的功能：-支持 PS 承载的拆分，分离出语音的 PS 承载和非语音的 PS 承载。-对于非语音的 PS 承载，按 3GPP TS23.401 定义的 RAT 间的切换过程，切换到目标小区。-对于语音的 PS 承载，通过 Sv 接口触发 SRVCC 切换到目标小区。这个过

26、程只触发一次，不管 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 下载到 SGSN 上的。12/51-当 STN-SR 被修改或者从用

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

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

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

30、 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”协议框架（0 x0001）和针对RTCP报文的“UDP/IP”协议框架（0 x0002）。ROHC功能应支持对

31、IPv4和IPv6报头的压缩。14/51 表1 建议支持的报头压缩协议和协议框架 协议框架标识 用途 参考规范 必选/可选 0 x0000 不压缩 RFC 4995 可选 0 x0001 RTP/UDP/IP RFC 3095,RFC 4815 必选 0 x0002 UDP/IP RFC 3095,RFC 4815 必选 0 x0003 ESP/IP RFC 3095,RFC 4815 可选 0 x0004 IP RFC 3843,RFC 4815 可选 0 x0006 TCP/IP RFC 4996 可选 0 x0101 RTP/UDP/IP RFC 5225 可选 0 x0102 UDP/

32、IP RFC 5225 可选 0 x0103 ESP/IP RFC 5225 可选 0 x0104 IP RFC 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用于no

33、n-GBR承载或QCI=2的EPS承载。基站应支持速率为12.2kbps、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

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

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

36、SI值用于指示IMS多媒体电话业务，即，3GPP TS 24.229 5.1.1.2.1节中定义的urn:urn-7:3gpp-service.ims.icsi.mmtel。UE和 IMS核心网必须支持3GPP TS 24.229定义的网络侧发起的去注册过程。UE能够订阅3GPP TS 24.229 5.1.1.3节中定义的注册事件包。为了支持视频呼叫，UE必须遵从IETF RFC 3840的要求，在REGISTER请求的Contact头域中增加“video”媒体功能标记。（2）鉴权 16/51 UE和IMS核心网须支持3GPP TS 24.229 和3GPP TS 33.203中定义的包含I

37、MS-AKA、Sec-Agree 和IPSec机制的IMS鉴权过程，同时还要支持完整性保护过程。考虑到底层的安全性，加密保护功能是可选的。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 T

38、S 24.623定义的Ut接口的鉴权流程。（3）寻址 UE和IMS核心网必须支持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呼叫建立和

39、释放程序，包 括 使 用 Route 头 域。UE 要 根 据 3GPP TS 24.229 的 要 求 传 递 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第4.

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

41、Identification Presentation 3GPP TS 24.608 Originating 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

42、24.604 Communication Diversion on not Reachable 3GPP TS 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 3G

43、PP TS 24.611 Communication Hold 3GPP TS 24.610 Message 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

44、 TS 24.147 第5.3.1.3.3节中定义的三方会话创建程序。18/51 要邀请其他用户加入到会议，UE和IMS核心网必须支持3GPP TS 24.147 第5.3.1.5.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

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

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

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

48、激活、去激活和查询（XCAP操作），并建议UE支持History-Info头用于转移方的呈现。表3 CDIV中支持的条件和动作 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核心

49、必须支持下表中列出的条件，用于业务激活、去激活和查询（XCAP操作）。表4 CB中支持的条件 roaming international international-exHC （10）呼叫保持 UE能够利用3GPP TS 24.610第4.5.2.1节定义的程序请求语音和视频媒体流进行保持或者恢复。如果语音和视频媒体流都被保持了，网络只能发起给被保持的用户提供录音通知的流程，或者利用3GPP TS 24.610第4.5.2.4节中定义的网络选项来减少带宽。要恢复视频媒体流，须遵从3GPP TS 26.114第14.3的要求。8.1.1.3 呼叫建立过程（1）SIP 预留 UE必须支持IETF

50、RFC 3312和IETF RFC 4032中定义的SIP预留机制。根据3GPP TS 24.229第5.1.3.1节中的定义，UE应使用Supported头，而不是Require头，20/51 来指示自己支持预留。根据3GPP TS 24.229第5.1.3.1节的定义，UE在发起一个IMS会话的时候，必须始终包含precondition-tag。运营商可以关闭网络中预留机制的使用。被叫UE的实现与主叫是否使用预留机制无关。（2）资源管理和 SIP 的融合 PDN连接的丢失 根据3GPP TS 24.229第5.2.8的要求，如果UE和网络间的PDN连接中断了，网络必须终端跟该UE相关的所有