VoLTE端到端业务详解 | VoLTE用户呼叫流程

Posted 2022-08-18 COCOgsta

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了VoLTE端到端业务详解 | VoLTE用户呼叫流程相关的知识，希望对你有一定的参考价值。

书籍来源：艾怀丽《VoLTE端到端业务详解》

一边学习一边整理书中的笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：VoLTE端到端业务详解 | 汇总_COCOgsta的博客-CSDN博客

5.3.1 主叫流程

如图5-37所示，VoLTE用户在LTE网络的主叫呼叫过程，大致如下。

流程1：UE发起会话，向IMS拜访网络入口P-CSCF发送Invite消息。

流程2：P-CSCF收到Invite消息，根据本地记录的主叫用户注册S-CSCF地址，路由消息到S-CSCF。

流程3～4：S-CSCF收到Invite消息，判断P-Asserted-Identity头域中的主叫号码已注册，则首先根据主叫用户签约的iFC模板数据，触发MMTel AS。MMTel AS向主叫UE提供补充业务，再进行号码分析。之后，MMTel AS发送Invite消息到S-CSCF。

流程5～6：如果Request-URI为Tel URI形式，S-CSCF会尝试查询ENUM服务器，以判断被叫用户是否为IMS网络用户。

流程7：S-CSCF对Request-URI进行路由分析，根据获取的下一跳路由地址，将呼叫请求路由到被叫网络。

5.3.2 被叫流程

根据主叫UE、被叫UE接入网络方式的不同，被叫侧会话过程也不同，可以分为以下4种场景。

· 主叫UE通过CS网络接入，被叫UE通过CS网络接入。

· 主叫UE通过CS网络接入，被叫UE通过LTE网络接入。

· 主叫UE通过IMS/LTE网络接入，被叫UE通过CS网络接入。

· 主叫UE通过IMS/LTE网络接入，被叫UE通过LTE网络接入。

5.3.2.1 主叫CS接入、被叫CS接入

（1）如果被叫用户未签约IMS网络业务，则由融合HLR/HSS做域选择，可以直接将呼叫路由到CS网络，避免呼叫锚定到IMS网络的迂回路由。

如图5-38所示，CS用户呼叫未签约VoLTE业务的CS域用户流程描述如下。

流程1：主叫用户发起呼叫，IAM消息发送到GMSC。

流程2：GMSC发起Send Routing Information给被叫用户归属的融合HLR/HSS。

流程3：融合HLR/HSS根据用户的签约数据判断用户未签约IMS，则直接发PRN给被叫用户拜访的VMSC。

流程4：被叫用户拜访的VMSC为用户分配一个MSRN后通过PRN-ACK返回给融合HLR/HSS。

流程5：融合HLR/HSS通过SRI-ACK将被叫用户的MSRN返回GMSC。

流程6：GMSC构造新的IAM消息发给VMSC。

流程7：VMSC将话务接续到被叫用户。

（2）如果被叫用户签约了IMS网络业务，则需要通过锚定功能将呼叫请求接续到IMS网络。

一般现网选择被叫锚定（IMRN前缀方式）方案。

如图5-39所示，CS用户呼叫签约VoLTE业务的CS域用户流程描述如下。

流程1：用户A呼叫用户B，被叫侧的GMSC服务器收到IAM消息。

流程2：GMSC服务器向HLR/SAE-HSS发送SRI消息，请求获取用户B的漫游号码。

HLR/SAE-HSS查询用户B的签约数据，判断签约数据中若包含终结Camel签约信息（T-CSI，Terminating CAMEL Subscription Information），则将T-CSI通过SRI RSP消息返回给GMSC服务器，其中携带Anchor AS地址。

流程3：GMSC服务器根据T-CSI签约信息，发送IDP消息到Anchor AS触发被叫智能获取IMRN前缀号码。

Anchor AS通过IDP消息中的业务键或业务触发点识别为被叫锚定，并向GMSC服务器发送连接消息，并在Destination Routing Address信元中携带IMRN前缀+被叫用户B号码。

流程4：GMSC服务器对IMRN进行号码分析，获取下一跳地址为MGCF，将呼叫请求路由到MGCF。

流程5：MGCF对IMRN进行号码分析，将呼叫请求路由到I-CSCF。在出局前，MGCF将被叫锚定前缀删除，完成被叫号码的还原且将其规整为全局号码格式。

Invite消息如下所示，其中Route头域未携带“orig”参数，且P-Asserted-Identity头域的主叫号码需要规整为全局号码格式。

流程6：I-CSCF收到Invite消息后，I-CSCF向IMS-HSS发送LIR消息，为用户B选择一个可以提供服务的S-CSCF。

IMS-HSS向I-CSCF返回LIA响应，携带S-CSCF地址。

流程7：I-CSCF发送呼叫请求到S-CSCF。

流程8：S-CSCF根据本地保存的锚定用户签约iFC模板数据，触发其他AS。其他AS触发业务后，S-CSCF将呼叫请求路由到SCCAS，完成T-ADS域选处理。

如果本地没有锚定用户的签约iFC模板数据，S-CSCF会发送SAR请求到IMS-HSS，IMS-HSS返回SAA响应携带锚定用户签约数据。

流程9：SCCAS域选流程，具体请参见T-ADS域选。

流程10：SCCAS向HLR/SAE-HSS发送UDR消息，携带用户B号码和抑制T-CSI指示，请求获取用户B的漫游号码。

流程11：HLR/SAE-HSS发现UDR消息携带了抑制T-CSI指示，则不再查询T-CSI信息，直接发送PRN消息到VMSC服务器，请求获取用户B的漫游号码。VMSC服务器返回用户B的漫游号码MSRN。

流程12：HLR/SAE-HSS向SCCAS转发用户B的漫游号码MSRN。

流程13：SCCAS发送Invite消息给S-CSCF，以MSRN作为被叫号码。

流程14：S-CSCF通过对被叫号码进行分析，获取下一跳路由网元MGCF的地址，将呼叫请求路由到MGCF。

流程15：MGCF对MSRN进行路由分析，将呼叫请求路由到用户B当前所在的GMSC服务器上。

流程16：GMSC服务器将呼叫请求转发到VMSC服务器。

流程17：VMSC服务器接续呼叫请求到用户B。

5.3.2.2 主叫CS接入、被叫LTE接入

图5-40所示为CS用户呼叫签约VoLTE业务的LTE域用户流程描述。

流程1：用户A呼叫用户B，被叫侧的GMSC服务器收到IAM消息。

流程2：GMSC服务器向HLR/SAE-HSS发送SRI消息，请求获取用户B的漫游号码。

流程3：HLR/SAE-HSS查询用户B的签约数据，判断签约数据中是否包含终结Camel签约信息T-CSI（Terminating Camel Subscription Information）。

流程4：HLR/SAE-HSS将T-CSI通过SRI RSP消息返回给GMSC服务器，其中携带Anchor AS地址。SRI RSP消息如图5-41所示。

流程5：GMSC服务器根据T-CSI签约信息，发送IDP消息到Anchor AS触发被叫用户智能获取IMRN号码。

流程6：Anchor AS通过IDP消息中的业务键或业务触发点识别被叫锚定，且为前缀方式分配IMRN号码。

流程7：Anchor AS向GMSC服务器发送Connect消息，并在Destination Routing Address信元中携带IMRN号码。Connect消息如图5-42所示。

流程8：GMSC服务器对IMRN进行号码分析，获取下一跳地址为MGCF，将呼叫请求路由到MGCF。

流程9：MGCF删除锚定前缀，完成被叫号码的还原且将其规整为全局号码格式。

流程10：MGCF对IMRN进行号码分析，将呼叫请求路由到I-CSCF。

Invite消息如下所示，其中Route头域未携带“orig”参数，且P-Asserted-Identity头域的主叫号码需要规整为全局号码格式。

流程11：I-CSCF收到Invite消息后，I-CSCF向IMS-HSS发送LIR消息，为用户B选择一个可以提供服务的S-CSCF。

流程12：IMS-HSS向I-CSCF返回LIA响应，携带S-CSCF地址。

流程13：I-CSCF发送呼叫请求到S-CSCF。S-CSCF根据本地保存的锚定用户签约iFC模板数据，触发其他AS。其他AS触发业务后，S-CSCF将呼叫请求路由到SCCAS，完成T-ADS域选处理。

如果本地没有锚定用户的签约iFC模板数据，S-CSCF会发送SAR请求到IMS-HSS，IMS-HSS返回SAA响应携带锚定用户签约的数据。SCCAS域选流程，具体请参见T-ADS域选。

SCCAS域选流程，具体请参见T-ADS域选。

流程14：SCCAS经过域选判断选择LTE网络接入被叫用户，发送Invite消息给S-CSCF。S-CSCF查询本地保存的被叫用户注册的P-CSCF，将呼叫请求通过P-CSCF接续到UE_B。

5.3.2.3 主叫LTE接入、被叫CS接入

图5-43所示为VoLTE用户呼叫未签约VoLTE业务的CS域用户流程。

流程1：UE发起会话，向IMS拜访网络入口P-CSCF发送Invite消息。

流程2：P-CSCF收到Invite消息，根据本地记录的主叫用户注册S-CSCF地址，路由消息到S-CSCF。

流程5～6：如果Request-URI为Tel URI形式，S-CSCF尝试查询ENUM服务器，以判断被叫用户是否为IMS网络用户。

流程7：当ENUM服务器返回UE_B为非VoLTE用户时，S-CSCF通过对被叫号码进行号码分析，获取下一跳路由网元MGCF的地址，将呼叫请求路由到MGCF。MGCF对MSRN进行路由分析，将呼叫请求路由到UE_B当前所在的GMSC服务器上。GMSC服务器将呼叫请求转发到VMSC服务器。VMSC服务器接续呼叫请求到UE_B。

5.3.2.4 主叫LTE接入、被叫LTE接入

图5-44所示为VoLTE用户呼叫签约VoLTE业务的LTE域用户流程。

该场景下，呼叫请求首先接续到被叫签约业务的IMS网络，再通过域选功能将呼叫请求接续到被叫用户接入的LTE网络。

流程1：用户A呼叫用户B，为用户B提供业务的IMS网络的S-CSCF收到Invite消息，根据被叫用户签约的iFC模板，触发SCCAS。

流程2：SCCAS域选流程。

流程3：SCCAS经过域选判断，选择LTE网络接入被叫用户，发送Invite消息给S-CSCF。

流程4：S-CSCF查询本地保存的被叫用户注册的P-CSCF地址，将呼叫请求通过P-CSCF接续到用户B。

5.3.3 专载建立流程

VoLTE用户发起会话时，需通过拜访地EPS网络为用户建立IMS专用承载，其中如果是音频呼叫，需建立QCI=1的承载；如果是视频呼叫，则还需建立QCI=2的承载。具体流程如图5-45所示。

流程1：VoLTE用户通过拜访地P-CSCF向网络发起Invite请求。

流程2：待通过与对方的交互后，网络返回183（Session Progress）响应。

流程3：P-CSCF向PCRF发起AAR请求，消息包括UE的地址；端口号、媒体类型和与对方协商的编解码信息。这个过程中在现网有个需要特别关注的点，P-CSCF与PCRF两个网元之间的Diameter信令消息由省内LDRA转接。LDRA根据用户的IP地址以及在用户IMS APN默认承载建立阶段保存用户IP地址与VoLTE PCRF之间的“绑定关系”，记录寻址当前控制VoLTE用户IMS APN的VoLTE PCRF。

流程4：PCRF分析Rx接口AAR消息中的媒体类型参数，若为“音频”，则通过Gx接口指示PGW为VoLTE用户建立QCI=1的专用承载；若为“视频”，则通过Gx接口指示PGW为VoLTE用户建立1个QCI=1的专用承载和1个QCI=2的专用承载。PCRF向PGW发起RAR请求，信令消息中包括QCI=1，MBR、GBR、流信息等。

流程5：SGW向MME发起创建承载请求，包括QCI=1，MBR、GBR、TFT和ARP=9等参数。

流程6：MME控制eNB建立无线承载，eNB为VoLTE用户分配RRC连接。

流程7：UE收到eNB的专载建立请求，且专载建立成功。

流程8：专载建立成功后，UE返回确认消息给eNB，后续各网元依次回复确认消息。

流程9：P-CSCF收到确认消息后，将网络侧返回的183消息转给UE，并进行后续业务流程接续。

5.3.4 资源预留过程

5.3.4.1 基本概念

资源预留协商为IMS网络中的重要特征之一，但是否启用资源预留应根据网络的总体策略。终端应具备资源预留特性开关设置的能力，如资源预留特性不能为现有业务或现有网络带来增值时，终端应将资源预留特性关闭，从而避免业务流程的复杂性。当网络具备资源预留特性需要的条件时（主要指具备QoS条件），终端应开启资源预留特性的开关。

移动通信网络的VoLTE业务资源预留机制一般来说是开通的，是一种为了提高用户接通率而引入的承载面资源预留机制，即确保用户振铃前承载已经建立完成，有足够的带宽。如果不使用该机制，用户应答后可能存在承载还未建立完成导致呼叫失败的情况。

支持资源预留机制的主叫侧UA和被叫侧UA通过Offer/Answer中的SDP进行媒体端口协商，对协商成功媒体类型的媒体端口，应在响应中携带本端分配的媒体端口号，对协商不成功的媒体类型应将端口号设置为零。如果协商结果为支持资源预留，则在用户振铃前就将承载面资源预留完成，这样用户振铃时资源已经准备就绪，能够提高呼叫接通率。

VoLTE业务的资源预留机制使用Invite（Offer）/183（Answer）进行SDP协商，以更新消息携带SDP指示本端的资源预留完成信息，在200 OK (Update)消息中携带对端的资源预留完成信息。

5.3.4.2 实现原理

如图5-46所示，资源预留过程详细描述如下。

1.主叫用户UE_A发起呼叫，在Invite消息的Supported头域中指示本端支持资源预留，同时SDP中携带与资源预留相关的QoS参数。

Invite消息示例如下：

2.被叫用户UE_B收到Invite消息后，悬置会话的建立，向UE_A发送携带SDP信息的183消息，SDP信息中携带与资源预留相关的QoS参数。

3.主叫侧完成资源预留后，发送Update消息给被叫侧，参数“a=curr:qos local sendrecv”指示本端资源预留已经满足。

Update消息示例如下：

4.被叫侧完成资源预留后，返回200 OK (for UPDATE)给主叫侧，参数“a=curr:qos local sendrecv”指示本端资源预留已经满足。

200 OK (for Update)消息示例如下：

被叫侧确认会话双方都已完成资源预留，继续会话处理，振铃并向主叫侧返回180消息。

5.3.4.3 现网示例

（1）在城市1的一次呼叫路测日志中可以看到主叫和被叫各激活一次专载，速率是128kbit/s，如图5-47所示。

主、被叫的专载建立的信令流程如图5-48所示。

（2）在城市2的一次路测日志中看到主叫激活（Activate），速率是52kbit/s，等待被叫1次激活，速率是63kbit/s，发送183给主叫，主叫收到183后再次修改（Modify），速率是63kbit/s，如图5-49所示。

主、被叫的专载建立的信令流程如图5-50所示。

（3）SBC收到用户发的SIP信令时是怎么通过PCRF去给用户建立QCI=1的专载呢？VoLTE SBC应能够在仅收到SDP Offer时发起Rx接口流程，也可以在收到SDP Offer和SDP Answer后再发起Rx接口流程。

VoLTE SBC应能够根据SDP中的相关信息生产Rx接口AAR消息中相应的AVP。针对SDP中的每种媒体成分（音频、视频等）分别生成不同的Media-Component，并在Media-Type中指明其类型。

VoLTE SBC应能够在AAR消息中的Media-Component AVP中添加两个Media-Sub-Component AVP，分别携带RTP和对应的RTCP信息。

VoLTE SBC应可以根据SDP中的RR和RS参数生成RR-Bandwidth AVP和RS-Bandwidth AVP。

当SDP中不包含RR和RS参数时，不携带RR-Bandwidth AVP和RS-Bandwidth AVP。

示例如图5-51所示，存在以下三个问题。

① 为什么AAR中的带宽选自SDP中的b=as行？

因为现网承载控制策略配置为信任终端媒体带宽信息。

② 为什么AAR中没有携带RR-Bandwidth和RS-Bandwidth？

SBC初始收到终端发送过来的SDP是属于Offer，不是属于Answer，所以不携带RR-Bandwidth和RS-Bandwidth。

③ 为什么PCRF进行Active的速率是52kbit/s，而不是49kbit/s？

根据协议29213.6.3“QoS Parameter Mapping Functions at PCRF”的定义，SAEGW的带宽是RTP流+RTCP流总带宽。

当AAR消息中携带了RS-Bandwidth和RR-Bandwidth AVP且取值不为0时，最终下发的MBR和GBR上下行带宽都为RS-Bandwidth和RR-Bandwidth取值之和。

当AAR消息中携带的RS-Bandwidth和RR-Bandwidth AVP取值为0，将对应RTCP流的规则合并到非RTCP流的规则中下发。最终下发的MBR上下行带宽为AAR消息中携带的Max-Requested-Bandwidth-UL和Max-Requested-Bandwidth-DL AVP取值，GBR上下行带宽为AAR消息中携带的Min-Requested-Bandwidth-UL和Min-Requested-Bandwidth-DL AVP取值。

当AAR消息中未携带RS-Bandwidth和RR-Bandwidth AVP或只携带了其中一个，则最终下发的MBR和GBR上行带宽都为0.05×正常流Max-Requested-Bandwidth-UL取值，下行带宽都为0.05×正常流Max-Requested-Bandwidth-DL取值。

现网实际情况是：主叫SBC在收到终端发送的Invite消息，发送给PCRF的AAR消息中携带的Max-Requested-Bandwidth-UL流取值是49kbit/s，没有携带RS-Bandwidth和RR-Bandwidth，这样总计带宽就是RTP流（49kbit/s）+RTCP流（49kbit/s×0.05）=51.45kbit/s (52kbit/s)。

（4）被叫侧语音专载建立过程如图5-52所示。