VOLTE学习笔记.docx
- 文档编号:24168961
- 上传时间:2023-05-25
- 格式:DOCX
- 页数:16
- 大小:28.35KB
VOLTE学习笔记.docx
《VOLTE学习笔记.docx》由会员分享,可在线阅读,更多相关《VOLTE学习笔记.docx(16页珍藏版)》请在冰豆网上搜索。
VOLTE学习笔记
VOLTE1
俗话说的好,一入豪门深似海,对于VoLTE这个新技术领域的学习认知也一样,相比传统的电信技术,它糅合了大量计算机互联网的理念,正可谓吸毒毁一生,学习VoLTE毁三代。
但是任何复杂、先进的技术都是人类制定的,因此对于VoLTE的理解只要循序渐进,把握住总体脉络,以需求入手,应该也不是什么天方夜谭。
本系列撰文拟从一个传统的无线优化工程师的思维入手,尝试逐步揭开VoLTE神秘的面纱。
如果单从电信网络的眼光去看,VoLTE不过是承载在目前4G网络中的一种数据业务而已,只不过对于这种数据业务的QOS管理、调度需要引入新的系统或者功能进行管控,这也就是我们常常说的IPmultimediasubsystem(IP多媒体子系统)或者IMS域的职责。
对于无线网络优化工程师来讲,VoLTE时代的来临对于传统的网优工作存在不小的挑战,因为大量的优化工作会从无线层面上移到业务层面的优化,熟悉一些IMS域核心网络的知识变得不可缺少。
这一篇简单得从一些IMS域的重要网元以及基础概念入手。
任何信令的交互首先涉及的是寻址或者基于用户、订阅业务的标识,例如电信网络中有IMSI、TMSI、P-TMSI、RNTI(RA-RNTI、P-RNTI、C-RNTI、SPS-RNTI)、GUTI等等常用的用户或者业务标识,在IMS域中同样存在类似的标识,主要有如下三种,PrivateUserIdentities、PublicUserIdentities,GloballyRoutableUserAgentURI(GRUU)。
PrivateUserIdentities:
该标识最大的特点不是区分用户,而是标识用户不同的订阅业务。
因此,对于每个用户而言,都可以包含一个或者几个这样的私有用户标识,该标识并不被用来进行SIP消息的路由寻址,而是被用来进行注册、鉴权、管理和统计。
私有标识由归属地网络运营商进行分配,遵循NetworkAccessIdentifier(网络访问标识)的格式,如果没有ISIM应用,通常该私有标识会从IMSI标识中继承。
通常,该私有标识的格式为用户名@域,如果从IMSI中继承,则变成了
除此之外,私有用户标识不是动态标识,而是对于该用户订阅业务的永久性标识,并且在归属地网络中对于该订阅业务始终有效。
在IMS域注册/去注册阶段,该私有标识需要被鉴权,HSS与S-CSCF需要存储该私有标识一边区分用户信息
PublicUserIdentities
公共用户标识在IMS子系统内被用来进行用户间的通信。
公共用户标识可以被任何用户使用,这就好比名片一样,是一种通用的载体格式。
公共用户标识遵循SIPURI或者TelURI的格式,例如,当遵循SIPURI格式时,应表示为”sip:
username@domain;如果遵循电信URI格式,则应表示为”tel:
+
一个用户可以包含一个或者多个公共用户标识,换言之,仅仅获得公共用户标识无法与用户进行映射。
对于ISIM应用,至少需要安全的存储一个公共用户标识,但并不要求存贮该用户其他的公共用户标识。
对于拥有同一化名的一组公共用户标识的操作,有点类似“一荣俱荣”,也就是需要对组内的公共用户标识进行同样的操作,这样的公共用户标识组需要分别被存储在HSS、AS(应用服务器)、S-CSCF以及UE中。
在IMS主叫或者被叫会话流程中,公共用户标识需要提前被显式或隐式的注册,值得注意的是,在注册过程中,公共用户标识并不需要被鉴权。
单从格式来讲,私有用户标识更像电信网中的IMSI,而公共用户标识则更像电信网中的电话号码或者计算机网络中的用户名,这也说明在注册过程中为什么只对私有用户标识进行鉴权,而仅仅是将公共用户标识作为通信的对象。
GloballyRoutableUserAgentURI(GRUU)
全局路由用户代理用户资源标识,顾名思义,该标识天生就是为了路由寻址而生的,之前提到,一个用户可能有多个公共用户标识,而且同一个公共用户标识也可以被多个用户使用,那么在寻址路由的时候仅仅依靠公共用户标识就可能产生误判(forking)。
因此需要将该公共标识与特定的用户实体进行结合,因此这就是分两种,公共GRUU、临时GRUU,前者映射公共用户标识,而后者只在IMS域注册状态下存在,与公共用户标识无关。
公共GRUU与临时GRUU由IMS核心网在用户注册时对用户进行分配,SIP信令就是通过GRUU进行特定用户之间的寻址路由。
VOLTE2
IMS域核心网的网元、接口众多,如果单纯从IMS子系统的角度来看,各个网元、功能实体以及接口是如下这样的
如果需要全部掌握了解,需要花费相当的功夫,所以理解这些网元不可能眉毛胡子一把抓,需要循序渐进。
这里从IMS域内的协议流程需要涉及的网元入手,逐步进行摸索与理解。
这里主要有5个功能实体Proxy-CSCF、Interrogating-CSCF、Serving-CSCF和BreakoutGatewayControlFunction、MultimediaResourceFunction(其中MRF包含两个逻辑网元MultimediaResourceFunctionController和MultimediaResourceFunctionProcessor)。
Proxy-CSCF
全称为Proxy-CallSessionControlFunction,只要是IMS域中涉及的会话流程,不可避免都要与P-CSCF、I-CSCF和S-CSCF这三个网元进行交互。
P-CSCF比较好理解,类似一个代理服务器,主要负责接收服务请求并在IMS子网内部中转这些服务请求。
如果需要中转到其他的域,则要通过本地出口节点(IBCF)这个网元去实现。
P-CSCF不仅转发SIP注册消息,同时转发SIP消息到相应的SIP服务器(S-CSCF)。
在转发SIP消息请求与反馈中,P-CSCF需要确保SIP消息中包含了当前UE所处接入网的信息。
除此之外,P-CSCF还有一些功能,包括检测处理紧急呼叫请求、产生计费话单、对会话的安全性管控、执行SIP消息的压缩与解压缩、QoS管理、以及对于不同业务优先级的检测与处理。
P-CSCF可以分别在拜访地网络以及归属地网络进行设置,当P-CSCF设置在拜访地网络,见下图
这两种设置方式的区别在于,P-CSCF设置在拜访地网络时,需要通过IBCF功能实体与不同域的S-CSCF进行互联,而当P-CSCF设置在归属地网络时,需要通过“发现”机制被UE来确定进行信息交互,详见。
简单的来看,P-CSCF功能实体起到了电信域与IMS域沟通互联的作用,而IBCF则是不同IMS域之间的联络节点。
Interrogating-CSCF
I-CSCF是用户接入IMS子系统的节点,这里容易和IBCF的功能混淆,其实这两个功能实体有类似之处,只不过I-CSCF作为本域接入点,而IBCF往往作为跨域(跨IMS域或者与IMS域与其他IP多媒体网络)的出口或者访问节点,这两个功能上不同的逻辑节点往往可以合设为一个物理节点。
除了二者对于所处IMS子系统的逻辑位置的不同,二者还是有很多相似之处。
例如I-CSCF在UE注册过程先从HSS获取S-CSCF的地址,然后将该S-CSCF分配给该UE用来SIP注册,之后将SIP请求或者反馈路由到注册的S-CSCF。
I-CSCF在某些场景下还起到了地址翻译的作用,当需要进行HSS位置查询时,I-CSCF需要提前将SIP请求里的SIPURI转换成电信URI的格式,如果当某些场合不需要对用户寻址的时候,I-CSCF又可能起到了将电信URI翻译成SIPURI的作用。
另外当会话的目的地并不在IMS域内,I-CSCF又可以将请求转发出去,实际起到了IBCF的作用,或者直接回复接入失败。
I-CSCF域IBCF皆具有产生计费话单的功能,这为漫游结算提供了支撑。
Serving-CSCF
S-CSCF是IMS子系统中极为重要的功能实体,主要负责会话控制服务。
在IMS子系统中,可能存在多个S-CSCF逻辑网元,并且这些逻辑网元有各自不同的功能。
S-CSCF可执行如下功能
1、通过从HSS获取的用户信息完成注册
2、当UE在注册阶段上报支持GRUU能力,S-CSCF负责为UE分配唯一的P-GRUU,同时在每次重新注册时分配唯一对应的T-GRUU,并将该UE的GRUU分配情况反馈UE(当注册信息改变的时候,例如T-GRUU改变的时候,S-CSCF也需要及时通知用户),这有点类似EPS中MME在每次UE附着时为UE分配的TMSI的流程。
3、在注册阶段,S-CSCF还应向P-CSCF和/或者UE提供基于公共用户标识的一些诸如用户优先级信息
4、对于注册后的会话流程进行管理,例如,在获知用户被禁止接入信息后,可以将会话流程拒绝掉。
同时,S-CSCF可以具备代理服务器或者用户代理的一些功能,例如中转服务请求或者独立产生、终止SIP流程。
对于主叫会话发起的流程,S-CSCF首先通过呼叫用户的电话号码或者SIPURI获取呼叫用户所在网络的接入点地址,然后将SIP请求转发至该接入点。
如果主叫用户和被叫用户均在同一运营商网络下,则将SIP请求转发至该网络下的I-CSCF网元。
如果呼叫到PSTN网络或者CS域,则需要将SIP请求转发至BGCF网元。
同时,S-CSCF需要确保主叫SIP请求和响应的内容符合IMS子网络通信服务定义。
如果INVITE消息里面包含用户优先级设置或者相应的字符串,需要将这些信息同时转发转发。
值得注意的一点,如果主叫请求来自于IMS内部的应用服务器,且该主叫请求所表征的用户并没有注册,那么S-CSCF需要先完成相应的注册流程,之后才会将来自应用服务器的这些请求进行相应的转发。
对于被叫会话的流程,S-CSCF需要将SIP请求与响应转发至P-CSCF,如果被叫用户位于PSTN或者电信网络的CS域,S-CSCF需要修改SIP请求信息,并通过BGCF网元将请求或者反馈进行转发。
如同对主叫会话流程的管理,在转发SIP请求或者反馈的时候,需要确保SIP消息的格式满足IMS子网络通信服务定义。
如果是跨IMS域的请求转发,S-CSCF需要将请求通过IBCF网元进行路由转发。
一如既往,S-CSCF也同样兼具产生计费话单功能。
BreakoutGatewayControlFunction
Breakout这个英文单词的释义为“突围;中断”,因此也就隐含了两层意思,就是离开IMS域,中转到其他的域,例如PSTN/CS域等。
BGCF起到了对被叫用户的识别以及路由。
如果被叫用户是本网络的PSTN/CS域用户,BGCF将下一跳路由到本网MGCF,后续由MGCF进行与PSTN/CS域的交互。
如果被叫用户是位于其他网络的PSTN/CS域用户,那么BGCF会首先将下一跳路由到其他网络的BGCF。
如果被叫用户位于其他的IMS网络,BGCF会将消息路由到该IMS网络的I-CSCF(接入节点)。
MultimediaResourceFunction
多媒体资源功能可以被分成多媒体资源功能控制单元(MRFC)和多媒体资源功能处理单元(MRFP)两个逻辑网元,如下图所示
电信网设计的基本架构思想是将控制面与业务面进行分离,例如在LTE核心网中,MME被设计用来进行信令层面的处理,而SGW/PGW则被设计用来对业务层面进行处理。
IMS的核心网功能实现也存在类似的思想,就是IMS域的控制面(信令面)与业务面。
对于信令的处理可以在以上介绍的网元中实现,如P-CSCF、I-CSCF、S-CSCF、BGCF等,对于媒体业务的处理主要位于应用服务器中(AS),MRF(含MRFC和MRFP)的主要功能是媒体流的处理以及提供相应的媒体资源,例如音频编码转换、媒体业务分析、多媒体放音等等。
VOLTE-注册信令流程
对于一个网络工程师而言,解读电信网络的信令是分析定位网络问题的有效手段之一。
所谓兵马未动,粮草先行,网络信令就是先于业务流程的“粮草”,当信令流程先打通时,才能保障后续业务流程的通畅与质量。
网络信令不仅是UE与网络信息交互的基础,同时也是各个网络节点之间对话的“标准语言”。
对于IMS子系统中的信令也是同样的道理,因此熟悉一些基本流程的信令对于网络优化中的排障、分析工作不无裨益。
在IMS子系统中,只存在一种信令流程控制协议,就是SessionInitiationProtocol,简称SIP协议。
该信令不仅存在于UE与P-CSCF之间的Gm接口,同时存在于IMS核心网其他众多网元节点之间的接口消息中,例如Mw,Mm,Mg,Mi,Mj,Mk,Mx等。
值得注意的是,IMS网元之间的SIP协议可能与UE与网络之间的SIP协议并不完全一样。
SIP协议最早起源于互联网机构IETF所制定的多媒体通信协议,对于电信网络的从业者来说,可能会相对比较陌生。
对于传统的电信网络核心网,大家耳熟能详,涉及较多的诸如着名的7号信令,GPRS信令,NAS层协议,S1-AP协议,GTP-U隧道协议。
而对于无线网络优化工程师而言,对于无线网协议(一般指的接入层协议)较熟悉的有GSM的RR信令,3G/4G网络的RRC信令等。
因此,看待SIP协议有时候需要抛开固有的电信网络思维,以互联网协议的角度入手进行理解。
SIP是一个应用层的信令控制协议。
用于创建、修改和释放一个或者多个参与者的会话。
这些会话可以是Internet多媒体会议、IP电话或者多媒体分发,其中最重要的应用当属对VoLTE(VoIP)会话流程的管理。
SIP的一个重要特点是它不定义要建立的会话类型,而只定义如何管理会话,由于这样的管控机制,对于众多的基于IP的多媒体应用(语音、视频、音乐与视频点播、交互式游戏)都可以由SIP协议来进行管理。
SessionDescriptionProtocal(SDP)则是对会话内容定义的一种协议类型,它本身与传输控制协议无关,仅仅可以看成对会话内容的一种描述,例如,可以描述会话内容是音频,文本,视频,短消息等。
可以通俗把SIP比喻成维护管道的,对交互管道进行控制的协议。
而在管道里面走的内容采取什么样的格式,则是由SDP协议来进行定义和描述。
由于在电信网的视角观察,IMS的信令与媒体其实可以看成电信网的一种业务,那么在UE发出SIP信令请求之前,首先需要为UE分配合适的IP-ConnectivityAccessNetwork(IP-CAN)承载,同时对于UE分配到的IP地址在IMS子系统中涉及的信令以及媒体业务需要保持一致。
一个VoLTE语音电话,无非需要经历注册/去注册、IMS域内主被叫,跨域主被叫,下面从IMS会话的的几个关键信令流程进行说明:
注册
如同4G网络需要开机或者outofservice一段时间后进行注册附着流程一样,IMS子系统的用户同样需要进行在S-CSCF的注册,该IMS注册流程可以在4G网络完成注册分配到了IP地址之后进行。
从注册信息流的意义来看,用户总是位于漫游状态发起的,换句话讲,就是注册流程对于用户位于拜访地网络或者归属地网络都是一样的,只不过“漫游”在归属地网络的用户可以认为其归属地网络同时起到了拜访地网络和归属地网络网元功能的作用。
这句话说的像协议一样如老太太裹脚布一样的严谨晦涩,其实说白了就是单从注册信令流程看,不区分漫游或非漫游用户。
对于无线网络优化工程师来讲,一般只关注UE与网络侧交互的流程信令,至于IMS网元节点内部的信令交互,暂时可以放一放,这样会使切入点更加直观,流程的掌握更加高效。
当UE在接入网完成附着获得IP分配后,就可以开始进行IMS域的注册流程。
UE首先将注册信息发送给P-CSCF(当然之前需要进行借助DHCP/DNS服务器进行P-CSCF的“发现”流程),该注册流程需要包含公共用户标识,私有用户标识,归属地网络域名称,UE分配的IP地址,UE实例标识,是否支持GRUU的指示。
例如上图,这条消息就是Request-URI,主要标识位置服务的域名,值得一提的是,与To标头域提供的内容不同,Request-URI并不提供用户名。
From(f)与To(t)标头域包含的就是临时公共用户标识(值得注意的是,就是私有用户标识),一般来讲,如果不是第三方设备发起注册,这两个标头域的内容往往保持一致,其中含的内容就是UE的IMSI信息,这里就是;CallID是对一组往返消息进行标识,在该UE的每个注册过程,Call-ID一般对于同一用户的多次注册流程都保持一致,同时对于同一用户的不同会话要求有可能不同,例如,某次多媒体会议通话期间,对同一个用户的邀请可能分配多个不同的CallID,CallID需要保持全球唯一(例如SIPCallID,可采用IMEI填充),并且为了安全目的可以采取适当的加密机制;Cseq保证注册请求的顺序,当每次注册请求发生的时候,Cseq的值应该+1;Max-Forwards该值决定request消息在IMS内部传递到目标服务器所需经历的最大条数,为了确保消息顺利到达,同时兼顾由于内部循环导致的跳转资源被过度消耗,该值一般设置为70,每一条以-1的方式进行计算,直到0为止,将反馈483(toomanyhops)的错误响应;Via(v)里面的信息主要说明传输层的协议信息,例如这里传输层使用的协议就是TCP协议。
同时,还需含SIP,标识着发送请求的协议名称以及协议版本,另外,Via里还需要插入响应发送的地址。
这里还要包含branch参数,除了CANCEL和ACK消息之外,该参数值是唯一的,且前7位一定是z9hG4bK(RFC3261),该参数的主要作用是标识SIP请求所创建的交互(UE与IMS网络之间);m对应的内容进行了媒体描述,首先包含媒体类型,例如这里的媒体类型就是视频流(video),同时也包含接收媒体协议的端口号,以及媒体格式描述(例如,传输包的格式描述)
Authorization鉴权标头域中所含的内容也有详细的规定,例如username中含有的就是用户私有标识,realm所含的是归属地网络域名,uri所含的就是归属地域名的SIPURI格式,nonce中设置应为空;Security-Client标头域指明了UE所支持的信令面的安全机制、IP层的安全机制算法,同时还有安全协商所需要的参数。
UE需要支持建立两对安全协商机制。
当UE收到来自网络401(Unauthorized)的响应的时候,说明网络需要对UE进行鉴权。
其中最重要的一点,UE需要校验Security-Server标头域所含的内容,如果该项内容未出现的在响应消息里或者没有包含安全协商所需要的相关参数,UE可以丢弃这次的鉴权过程,另起炉灶的以新的call-ID发送新的注册请求。
当校验通过后,UE需要根据P-CSCF要求和本身能力支持的鉴权算法同时结合IK和CK加密算法建立临时的安全协商机制,并规定该临时安全机制的有效时长。
接下来,UE使用临时安全协商机制再次发送注册请求到P-CSCF受保护端口(通过401chanllenge获取)。
除了初始未鉴权保护的注册请求中的相关参数,本次注册请求中还应包括如下参数:
realm:
设为从401消息中收到的realm值;
username:
设为私有用户标识;
response:
包含RES参数;
uri:
设置为归属地网络域名的SIPURI;
algorithm:
设为从401消息中收到的对应值;
nonce:
设置为从401消息中收到的对应值;
P-Access-Network-Info标头域说明了IMS承载的接入网络类型,这里就是TD-LTE网络(3GPP-E-UTRAN-TDD),同时还说明了接入小区信息,utran-cell-id-3gpp=4600018DA1A64B02;Security-Clientheader标头域说明了UE所支持的媒体面加密机制情况。
1、当P-CSCF收到注册信息流的时候,P-CSCF需要通过归属地域名称去确认归属地的接入点(I-CSCF)。
然后,P-CSCF需要将包含P-CSCF地址/名称,公共用户标识,私有用户标识,P-CSCF网络标识,UEIP地址等信息在注册信息流利转发到I-CSCF。
名称-地址解决机制被用来通过归属地域名解析出归属地的地址。
P-CSCF网络标识是用来被归属地网络确认P-CSCF所在网络的字符串。
2、I-CSCF需要将收到的信息发送给HSS进行校验是否该用户已经注册。
同时HSS需要确认用户是否允许注册。
3、如果校验通过,HSS将S-CSCF的名称或S-CSCF的能力反馈给I-CSCF,以供I-CSCF进行合适的S-CSCF选择。
如果校验不通过,这里将反馈注册请求拒绝(reject)
4、I-CSCF从HSS获取的S-CSCF名称,通过名称-地址解决机制获取对应的S-CSCF地址,将注册请求发送给S-CSCF(含P-CSCF名称/地址,公共用户标识,私有用户标识,归属地网络域名称,P-CSCF网络标识,UE分配的IP地址)。
如果对同一个公告标识的注册联系地址超过S-CSCF预设的门限,S-CSCF可以拒绝该注册请求。
S-CSCF需要存贮拜访地网络P-CSCF的地址/名称,一旦有被叫呼叫,则可将信令请求进行转发,同时S-CSCF还需要记录P-CSCF的网络ID。
5、S-CSCF需要将公共用户标识,私有用户标识,S-CSCF名称通过Cx接口发送HSS。
6、HSS存贮S-CSCF名称,并将一些包含用户名/地址或者安全的用户信息发送给S-CSCF,以便用来进行一些基于平台的服务管控。
7、S-CSCF将存贮的用户信息发送给服务平台,并进行适合的服务管控。
8、S-CSCF将返回200ok消息(包含归属地接入信息,GRUU组合)给I-CSCF。
9、如同上述,I-CSCF需要将200ok消息(包含归属地接入信息,GRUU组合)转发给P-CSCF,在转发之后,I-CSCF需要释放存贮的相应用户注册信息。
10、P-CSCF需要存贮归属地网络接入信息,并将200ok消息转发给UE(含GRUU组)。
UE在收到200ok响应之后,存贮此时的超时定时器,将P-Associated-URIheader里面包含的第一个URI存储为默认的公共用户标识,这里为,并且将之进行相应的安全关联。
如果该标头域中不含该公共用户标识,则认为该标识注册被禁止。
另外,UE需要变更前期的临时安全协商机制固化为新建立的安全协商机制
当收到200ok响应后,UE需要向S-CSCF订阅注册事件包。
该消息中所含的参数意义如下:
,说明需要订阅的公共用户标识的SIPURI
f:
需要包含公共用户标识,这里其实就是电话号码
t:
内容与f一致
o:
事件标头域,应设置为需要订阅的“reg”事件包
重新注册
UE需要在适当的时候发起重选注册流程,例如以周期形式刷新已有的注册信息或者响应UE注册信息的变动。
另外,当承载IMS会话的IP-CAN发生了变化,UE也需要发起重新注册流程。
UE重新注册流程与上述UE注册流程类似。
UE需要与网络侧依据上次注册时间同步更新周期注册的定时器,只不过该定时器比网络侧的定时器略小。
1、UE需要在网络侧的周期注册定时器超时前发起重新注册流程。
UE将注册信息发送给P-CSCF,其中需要含公共用户标识、私有用户标识、归属地域名、UE的IP地址、能力信息、IMEI标识、是否支持GRUU的标识。
2、当收到注册请求后,P-CSCF并不用之前缓存的归属地网络接入点信息,而是重新通过归属地网络名称去发现归属地的接入点信息(I-CSCF)。
P-CSCF会将注册请求转发给I-CSCF。
后续注册流程与前述一致。
注册取消
注册取消可以有两个层面来发起,一个是UE层面,另外一个是网络层面
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- VOLTE 学习 笔记
![提示](https://static.bdocx.com/images/bang_tan.gif)