作者：中国移动集团公司 张阳 （章末附作者介绍）
作者微信公众号：网优小谈（wireless_talk）

店铺地址：https://shop66907778.taobao.com/
参考链接：https://blog.csdn.net/weixin_41486034/article/details/106240240

移动内部疯传的11篇VoLTE学习笔记，看懂了你也是技术大神（一）接续

4 被叫信令流程

唐代大诗人李白曾经道过行路难，“行路难！行路难！多歧路，今安在？”

在学习VoLTE这个新的承载话音技术上，面对的困难与茫然某种程度上并不亚于唐朝诗仙所面临的困惑，但是男子汉需要勇气和毅力去克服人生中存在的艰难，有时候，明知道不可能，却还要去尝试，这就是年青人该做的。我们都想在世界这个大海上乘风破浪，在海的另一边，有着我们所不知的广阔天地。在知识海洋的彼岸，也还有太多我们不知道的风景，我想亲眼去看一看，亲身去体会。

VoLTE的被叫信令流程相比主叫信令流程要复杂一点，一般通信系统的被叫信令流程相比主叫信令流程都要复杂一点，因为往往不知道用户的位置需要进行相应的寻呼寻址，基于IMS架构的VoLTE被叫寻呼流程也是一样的，往往不知道用户是处于何种状态，例如，漫游状态、归属地、非LTE网络（UMTS/GSM/PSTN）等等，虽然涉及到的内容略显复杂，但是整体信令脉络是大致相似的，涉及到的不同状态，无非就是新增一些网元以及专属信令流程而已。

纵观被叫终端分别在漫游地和归属地的信令流程，除了涉及到P-CSCF的位置不同外，没有什么太大的区别，我们以漫游地的信令流程入手进行解读。

1、主叫发送SIP INVITE请求，包含初始SDP，经理主叫流程以及中间流程，最终发送到被叫侧的S-CSCF；

2、被叫侧S-CSCF校验服务请求同时触发服务逻辑单元。这里基于用户订阅的多媒体服务情况，对请求的SDP进行鉴权；

3、S-CSCF根据之前UE注册时的信息，将INVITE请求转发到之前记忆的P-CSCF;

4、如果P-CSCF决定被叫是MPS会话（多媒体优先级会话），P-CSCF获取对话信息并且调用动态策略，将获取的用户信息发送PCRF网元。P-CSCF通过之前UE注册时记忆的UE地址，将INVITE转发至UE；

下述信令截图就是INVITE的消息内容，从这里我们可以看出一些信息：

(1)主叫与被叫遵从电信URI的格式，即用tel方式进行公共用户标识表征，可以看出主叫来电号码是18407404056，被叫电话号码是18407404056；

(2)Call-ID:amCanUH-KnuK3GPdcuGJySgOHl87SpbfCHKujkAGJj3YyIbH22AbyEDy-Rwrym9difa@zteims,Call-ID是为了对同一用户的会话进行标识，因此在对话中同一个用户的请求和响应中，Call-ID是唯一的，另外对于同一用户，该Call-ID也应该是全球唯一的标识符，同时一般Call-ID以一种随机加密的方式（RFC1750）出现，使用该随机加密方式可以保护会话不被非法截获，同时可以减少Call-ID的冲突，一般call-ID是由随机加密序列结合主机名称或者IP地址产生。值得注意的是，在单一多媒体会议中，对于用户发起的对同一实体邀请，可能每次分配的Call-ID都不尽相同。有趣的是，主叫的Call-ID与被叫接收的INVITE信息的Call-ID不一样，主叫Call-ID是终端发起的，因此与终端分配的IP地址有关，被叫Call-ID是被叫所处IMS域S-CSCF发起的，因此打上了被叫域S-CSCF的标签；

(3)Cseq: 1000 INVITE。Cseq对消息处理进行标识和排序。INVITE需要与对应的消息类型保持一致（INVITE）。对于对话外非注册消息的Cseq，可以是设置为任意值。在同一对话内，该值随着消息每传递一次进行+1的增量同步。其中一种设置方式可在初始设置时将其与时间（秒级）关联；

(4) Record-Route: ,Record-Route是由P-CSCF插入的，目的是为了使后续的请求(Request)依然能通过该代理进行路由，在请求从主叫路由到被叫所经历的一些代理服务器中，Record-Route是可以被替换或者改写的；

(5) Contact: ;audio;video;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;+g.3gpp.icsi-ref=“urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”
Contact里面包含一个SIP URI地址，<>里面包含的就是SIP URI地址以及相应的URI参数，<>之外的是包头参数，而不是URI参数。一般可以认为Contact与Via是对应出现的，Via告诉后续的响应消息（Response）将要发送的地址，而Contact则指示了后续的请求消息（Request）将要发送的地址。除了SIP URI地址这些信息之外，Contact里面还包含了一些支持主叫UE能够支持的特性以及能力；

(6) Via: SIP/2.0/UDP [2409:8099:0:20::1]:5062;branch=z9hG4bK-501eb3dceecc83856d94btaN0
Via里包含了期望响应消息发送的地址。Branch参数区分了该请求创建的交易。并且在客户端以及服务器端，除了Cancel以及Ack请求，Branch参数被唯一使用。Cancel消息里的Branch参数需要与被Cancel的请求里的Branch参数保持一致。Ack里的Branch参数应该与Invite里的Branch参数；

(7) Content-Disposition: session, 这里对用户端（含客户端和服务器）描述了消息实体的类型为session(会话)，如果这一栏丢失，则接收端置为默认设置，如果没有默认设置，则置为render(展示)类型；

(8) P-Called-Party-ID: , 这项报头内容只在被叫中出现，里面包含的信息就是被叫UE的公共用户标识。

(9)Supported: 100rel,precondition,timer。这里可选项100rel的出现可以判定SIP message来自于MGCF，也意味着主叫电话来自于交换域。

(10) Session-Expires: 3600;refresher=uac
Min-SE: 90
这两条报头往往需要结合一起来看，Min-SE决定了session在代理服务器或者UE之间最小的更新间隔，意味着代理服务器在处理request时不允许恶意将其修改更低，而Session-Expire则决定了更新的上限，在该值超时前如果没有收到周期的re-INVITE或者UPDATE消息，则会话认为结束。同时更新是由发起request的一方（uac）来启动；一般可以设置30分钟（1800秒），这是由于认为95%的会话在30小时内就结束了，不过随着新技术的实施，将该值适当拉大也可以接受（详见 RFC4028）。

(11) P-Asserted-Identity: ，该包头域应该与主叫UE发出的P-Preferred-Identity捆绑起来解读。这里涉及了一个trust domain的概念，如果在信任域之间发送，代理服务器收到了P-Preferred-Identity，如果同在可信域之内，该值作为服务器可参考值，可在被插入后续的P-Asserted-Identity包头域中，P-Preferred-Identity值。

Asserted Identity意味着该值已被证实，这个值对于接收端的UE来讲，意味着比From包头域的值更值得信任。Asserted的值出现是为了简化鉴权（防止恶意篡改，更改，重放主叫号码）来电号码而产生，这样在信任域内的不同SIP服务节点转发该值，无需再重新进行该值的修改。但是发送到信任域之外，需要将该值删除或者进行一些私有加密的处理。这两个包头域的取值设置可以是SIP,SIPs URI或者Tel格式，同时对于中间转发的服务器，最多可添加一个SIP或者SIPs URI和最多一个Tel URI；

(12)Feature-Caps: *;+g.3gpp.srvcc;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting, Feature-Caps包头域说明了在SIP信令传送中途径的SIP实体所支持的特性和能力，与Contact包头域的URI里所支持的特性和能力形成对比的是，Contact包头域里的SIP URI表征的SIP实体支持的能力不允许出现在Feature-Caps里面。一个SIP消息中可以包含多个SIP实体所添加的Feature-Caps包头域，采取先到先添的原则，后一个添加得保证都在这些包头域的置顶位置。从这里我们可以解读到在信令消息转发途径的SIP实体会支持SRVCC，mid-call，甚至支持在alerting过程中的SRVCC切换流程；

(13) Accept-Contact: *;+g.3gpp.icsi-ref=“urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”;audio,该包头域是主叫端对被叫端UE所具备的能力偏好要求，在经过一系列的IMS网元后，服务器会参考该包头域所规定内容，依据偏好选择设置，对被叫端进行选择；

5、UE根据自身是否支持主叫端发起媒体流的子集情况，反馈Offer Response消息。SDP消息中表示多媒体对话中一个或者多个媒体信息。该反馈响应发送至P-CSCF

183阶段主要做的语音编解码协商，m=audio 50010 RTP/AVP 104 105，可以看出被叫UE支持的是104、105编码格式，含意如下
a=rtpmap:104 AMR-WB/16000/1

a=fmtp:104 mode-change-capability=2;max-red=0

a=rtpmap:105 telephone-event/16000/1

a=fmtp:105 0-15，这里采用的是AMR宽带语音编码方式，采样率为16000Hz，同时telephone-event说明了一些支持DTMF信令的情况（双音多频，主要发送号码用的）；

6、P-CSCF对该对话的所需资源进行授权，值得注意的是，在第4步的时候，P-CSCF就可以根据PCRF反馈信息确认为主叫所进行的资源预留情况；

7、P-CSCF将Offer Response消息转发到S-CSCF;

8、S-CSCF将Offer Response消息转发到主叫所处IMS域；

9、主叫侧发送响应确认（Response Confirmation）。响应确认中可以包含SDP信息，这些SDP代表的媒体流信息可以与第8步中的包含的SDP信息保持一致，互或者也可以是其子集。如果SDP中定义了新的媒体，在第12步后P-CSCF（PCRF授权）重复第6步，进行重新的资源授权。主叫可以很灵活的在这一步添加新的媒体和在后续用Update方法添加，但每一次新媒体的添加都会导致P-CSCF（PCRF）重复第6步的资源授权；

10、S-CSCF将响应确认转发到拜访地的P-CSCF，其间可根据运营商配置策略经由I-CSCF路由送达；

11、P-CSCF将响应确认发送被叫UE；

12、UE对Response Confirmation进行应答（200ok）。如果可选的SDP信息被包含在Response Confirmation里，那应答中应该也包含SDP响应。如果SDP信息变化了，P-CSCF授权资源可以被使用；

13、根据运营商IP网络策略，这里需要进行IP资源预留。IP资源预留可以在第6步之后由IP接入网发起，或者可以在这里由UE发起；

14-15、P-CSCF将确认应答消息通过S-CSCF转发到主叫节点；

16-18、当主叫节点完成了资源预留，发送资源预留成功消息到S-CSCF，S-CSCF将该消息转发到被叫侧；

19、被叫UE振铃

20-22、被叫UE反馈资源预留成功；

23-25，UE进行180持续振铃响应；

26、当被叫UE接通电话，向P-CSCF发送200 ok的最终响应

27、P-CSCF启动为该会话预留的媒体流资源；

28、被叫UE启动媒体流资源；

29-30，P-CSCF转发200 ok最终响应；

31-33、主叫侧对200-ok最终响应进行SIP ACK响应应答，该消息通过中间服务器转发到被叫侧；

注：这里被叫UE侧的log截取有一些奇怪的现象，有可能是网络侧的一些设置问题，虽然不影响该次电话的接通，但是仍然值得进行后续的研究；

问题1:
P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=46000E38A708F302;“sbc-domain=sbc.0731.hn.chinamobile.com”;“ue-ip=10.185.184.130”;“ue-port=5068”;“raw-ip=10.185.184.130”;“raw-port=5068”
Supported: 100rel,precondition,timer
这些现象说明主叫电话在TD-SCDMA上，但是现网TD-SCDMA并不与IMS互通，也不承载VoIP话音，同时检索主叫侧log，发现主叫UE是在LTE网络上进行起呼的，至于具体原因为什么会导致这样，建议逐SIP节点进行定位确认；

问题2:
SIP UPDATE信令消息中含有如下SDP内容
m=audio 20686 RTP/AVP 104 105 8 0 18 101，意味着到达被叫的UPDATE消息进行最终编解码协商时同时支持104，105，8，0，18，101，但是检索主叫侧UPDATE消息，只涵盖了104,105，也就是说其他编解码消息是网络侧附加上去的，至于具体原因是什么，只能通过IMS厂家进行辅助定位了。

还是以诗仙李白的名句作为本篇结束的注脚，长风破浪会有时，直挂云帆济沧海。

5 SRVCC

写此类技术文章甚为枯燥，经常在结束一天疲惫的工作后，不仅需要抗拒身心的慵懒，同时还要在台灯下查阅各种详细资料以求得专业文章描述尽量精准。写这些非专业人士看不懂的“天书”意义到底何在呢？有人说还不如利用时间炒股来的实在。诚然，在追名逐利的时代，耗费心血写些劳什子的技术八股文简直是拖时代的后腿，但是人总要活得有点情怀，经常看到文章教导我们说要不忘初心，初心到底是什么？初心其实就是你来到这个世界最本真的诉求，内心不过多受外界环境左右所渴求的梦想。笔者多年以来浑浑噩噩，近几年以来才渐渐的发现了自己的初心，写这些文章不是要改变世界，拯救产业，只不过回归了一把读书人恬淡与执着。古人讲究修身、齐家、治国、平天下，这也许就是中国人最朴素的信仰，虽然后三者还没实现，但通过潜心治学修了把身，也算能做到谈笑有鸿儒，往来无白丁了吧。

VoLTE技术里面重要的一项流程就是SRVCC（eSRVCC可以看成SRVCC的增强，本文后续进行介绍）。目的类似于跨系统的互操作，为了在LTE覆盖受限的区域保证用户VoLTE通话的连续性，需要进行跨系统SRVCC（Single Radio Voice Call Continuity）。从接入网角度进行观察，SRVCC也同样经历测量、判决等相应步骤，因此可以认为是一种跨系统的切换，但是区别于传统的例如23G话音CS-CS域切换，SRVCC一般则属于PS-CS域的一种切换流程。互操作流程一般是网络优化技术中研究的热点、难点，SRVCC也不例外，对于LTE网络建设的初级阶段，不可避免会触发大量SRVCC流程。

熟悉SRVCC技术，不仅需要从流程入手，同样需要重视IMS网络架构原理，因为为了引入SRVCC，网络结构起了相应的变化，也新增加了跨系统的接口。

以下列出一些笔者觉得比较重要的概念

1、协议（23.216）规定SRVCC的触发条件应该与E-UTRAN与UTRAN/GERAN的PS切换流程保持一致，也就是说，当触发PS切换事件满足后，也应该能够触发SRVCC切换；

2、对于视频电话，LTE网络侧需要分别为视频以及话音建立两条独立的EPS承载；

3、对于漫游情形，拜访地网络需要根据用户归属地网络策略进行相应的跨系统/跨域转换；

4、在IMS网络中引入针对（v）SRVCC的网络锚点，SCC AS；

5、QCI=1只被作为话音承载；

6、多个媒体流复用有如下方式，可以多个媒体流的话音复用一个话音承载，而视频分别承载在相应的视频承载上；也可以多个媒体流复用在一个媒体承载上；

7、协议表明SRVCC不仅从EUTRAN的PS域到CS域，同时也可以从UTRAN/GRRAN的CS域到EUTRAN的PS域，不过现网只进行了单向的转换，即PS-CS转换，在该篇笔记中我们将注意力聚焦在PS-CS切换上；

一旦上传测量报告触发异系统测量以及切换判决门限，MME会通过S1收到切换请求。如果MME含有关于该UE的STN-SR标识，MME会通过与MSC Server的Sv接口触发SRVCC流程。MSC server会与IMS进行协商，同时与UTRAN/GERAN目标小区互动进行CS域切换资源准备。当MSC server完成资源准备后，会通过Sv接口向MME发送CS切换响应，同时也会包含必要的CS域切换信息，例如频点、邻区等信息。如果在触发SRVCC时，用户同时保持了PS的数据业务，在SRVCC的流程里，数据业务同样也要进行切换，即PS-PS切换， MME负责协调整个流程中的PS-PS切换响应以及SRVCC的PS-CS切换响应。

如上图所示，这里需要改造的是MSC Server，因为其主要功能不仅在于与MME进行互联，同时还存在于与IMS域协调执行SRVCC流程。对于支持SRVCC功能的UE，需要在LTE网络Attach或者TAU过程中上报的字段“MS Network Capability”中都要明确。MME会存储相应的UE能力信息。如果UE的所支持的能力有所改变，需要通过TAU流程上报改变后的能力信息。另外值得注意的是，关于终端支持的MSClassmark3,MS Classmark 2，支持的编码方式等字段是通过附着请求或者非周期的TAU进行更新的。在这里，为了SRVCC流程实现，需要对一些新增实体功能进行定义：

1、MSCServer增强

（1）处理来自MME关于话音的重定位准备流程请求，如果来自Sv接口附带有优先级标识（ARP），则进行一并处理；如果收到ICS（以IMS作为中央控制的业务逻辑）的标识（true），则将MSC Server作为ICS受控实体；

（2）协调CS切换以及会话迁移

（3） 无需等待UE触发LAU,即可处理MAP_Update_Location；这里也隐含着一层意思，对比CSFB流程，CSFB回落2G过程中，起呼之前是需要做LAU通知MSC server此时UE处于的位置，但是SRVCC属于切换流程，MSC Server通过资源准备，预先知道UE回落的小区，因此可以不需要UE触发就进行核心网侧位置区更新流程。

2、MME

（1）增加PS承载分离处理功能，即可以区分处理承载语音以及数据的两种PS承载；

（2）能够处理数据业务的PS-PS切换流程；

（3）处理话音业务的SRVCC的切换流程，如果多个话音承载中包含一个紧急会话，那么MME只处理紧急会话的SRVCC流程；

（4）兼具协调并发PS切换以及SRVCC切换的能力

（5）MME需要具备传递优先级指示的能力。

3、E-UTRAN

LTE接入网功能在SRVCC流程中涉及空口的实体并不需要改变，但是需要有能力通知MME该切换流程为SRVCC。另外，E-UTRAN无法动态获取周边4G邻小区列表信息，因此，如果当一个VoLTE话音用户尝试切换一个没升级（及不支持VoIP）的目标小区时，将会被该目标小区拒绝。

以下结合SRVCC现网的一些实际测试log对主要信令流程进行解读（这里2G或者终端不支持DTM模式）：

1、以下log可以看出在执行SRVCC切换之前的最后一次测控消息，下发了需要测量的2G频点列表（已通过OMC预先进行配置），同时下发了异系统判决事件以及相应门限，这里下发的是B1事件的门限，可以估计是某厂家的设备；

最后一次测量上报结果说明测到了绝对频点号（arfcn）为70，网络色码010，基站色码100的GSM小区满足触发判决门限需要，上报基站等待后续切换判决；

2、根据UE的测量报告，eNodeB决定是否触发想GERAN的SRVCC切换

3、源eNodeB向源MME发送切换请求，其中包含目标ID，一般源至目标透传容器（原谅我没有能更好的中文翻译），SRVCC切换指示。一般源至目标透传容器中包含旧BSS到新BSS的消息，同时SRVCC切换指示表明只切换到目标小区的CS域，并不包含PS业务的切换；

4、MME中的承载分离功能根据与QCI1相关的话音承载以及SRVCC标识将话音承载从非话音的PS承载中分离出来，并启动PS-CS切换；

5、MME向MSC Server发送SRVCC PS-CS切换请求，其中可以包含鉴权过的IMSI、目标ID、STN-SR, C MSISDN, 一般源至目标透传容器，加密安全信息、Emergency Indication；

6、如果是MSC Pool组网，MSC Server会通过2G核心网内部流程发送切换准备请求至目标MSC,如果MSC Server收到了关于优先级的ARP，也封装在切换准备请求中发送到目标MSC；

7、目标MSC与目标BSS通过切换请求/应答进行资源分配。如果目标MSC指示了优先级，则BSS根据优先级进行相应无线资源分配，这里意味着优先级用户在VoLTE中享受什么样的服务，那么在SRVCC后到2G享受同样的服务；

8、目标MSC向MSC Server发送切换准备响应消息；

9、在MSC Server与目标MSC之间建立电路域连接；

10、MSC Server通过STN-SR初始化会话转移至IMS，如果获取到优先级标识应当一并转发至IMS相应处理实体，对IMS的优先级指示应当确保和IMS之前在PS域中创建的保持一致；

11、在会话迁移过程中，IMS远端通过SDP进行信息更新，意味着下行的VoIP话音需要通过CS路径承载；

12、源IMS路径被释放；

13、MSC Server向MME发送SRVCC PS-CS切换响应（目标至源透传容器）；

14、源MME向源E-UTRAN发送切换命令（目标至源的透传容器），这里只针对话音；

15、区别于以往我们认知的E-UTRAN侧的RRC层三信令，这里新增了一条 MobilityFromEUTRACommand,主要执行的就是SRVCC切换流程，它可以由handover的方式进行也可以cellchangeorder(CCO)的方式进行，我们这里的现网log则是以handover的方式进行处理

16、UE转换到2G网络；

17、在目标BSS区域的切换检测，一旦切换完成后，UE会通过目标BSS上传切换完成消息至目标MSC，如果目标MSC不是MSC Server,那么目标MSC会进一步通过核心网内部消息将切换完成消息发送至MSC Server;

18、UE发起数据业务挂起流程，从而触发SGSN向源MME进行了挂起指示。MME随之也会发送目标SGSN应答指示。值得注意，该流程可与19-22步骤同步进行，也就意味着在2G中数据业务挂起流程和切换完成消息并不冲突，因为SGSN进行数据业务处理，而MSC控制话音业务处理。另外如果MME无法从收到的P-TMSI和RAI中推导出GUTI，就有可能无法根据挂起通知确定是那些用户上下文需要被挂起，例如这样的情况，相应的承载可能会像步骤22a一样被去激活和/或挂起。同时对于非GBR的承载，MME会发送挂起指示通知S-GW，S-GW会释放UE的S1-U的承载，同时发送挂起指示到P-GW。MME存储UE挂起的状态，同时S-GW和P-GW会将这些保存的非GBR承载标注为挂起状态。如果收到关于挂起UE的包，P-GW也会做丢弃处理；

19、目标BSS发送切换完成消息到目标MSC；

20、目标MSC发送SES消息（包含切换完成）到MSC Server，语音电路连接到MSC Server/MGW；

21、完成建立流程；

22、这步流程是MSC Server与MME的互动，MSC Server发送SRVCC PS-CS完成指示到MME，指明UE已经在目标2G MSC侧进行接续，源MME通过SRVCC PS-CS完成应答消息进行响应；

22a、MME去激活语音以及其他GBR业务的承载。所有的这些GBR承载去激活指令通过MME触发的专用承载去激活过程发送给S-GW和P-GW。PS-CS切换指示也通过该流程一并通知P-GW。S-GW在基于隧道协议（GTP）的S5/S8接口上通过发送删除承载指令给P-GW，要求P-GW把所有的GBR都删除掉。对于基于PMIP协议的S5/S8，SGW与PCRF交互信息一次更新PCC策略用以处理P-GW的GBR业务；

22b、源MME释放S1接口资源，MME向源eNodeB发送释放S1信令连接，同时eNodeB进行响应；

23a、如果HLR进行更新，即IMSI被鉴权但是在VLR中还没更新，MSC Server使用其非广播LAI标识和网络资源标识（NRI）进行TMSI重分配。这个TMSI重分配流程由MSC Server通过目标MSC通知UE；

23b、如果MSC Server触发了TMSI重新分配，并且重分配过程成功完成，MSC Server向HSS/HLR发起MAP Update Location流程；

在SRVCC到2G语音通话结束后，2G的SGSN会通过相应的接口将挂起的数据业务进行恢复，也就是说SRVCC通话结束后，用户照常能像2G终端一样在2G网络使用数据业务，另外当用户返回4G网络后可以通过TAU或者Service Request流程进行挂起的数据业务承载恢复；

6 eSRVCC篇

之所以有增强型SRVCC（eSRVCC）技术的出现，无非是3GPP协议22.278关于EPS核心网中对于服务的要求明确，在为了保持已建立话音服务连续的异系统互操作中，终端时延不超过300ms。其实，在SRVCC中对中断时延影响最重要的一段时间不在于MSC server通过源MME向UE发送切换命令（步骤13-15），而主要在于向IMS远端更话音的访问路径至CS域（步骤10-12），从前期实测结果看来，这段时延大大超出了人们通话中可忍受话音终端的预期（实测大约在800ms以上）。3GPP 23.856提案了很多解决方案，例如在MSC Server侧加判决timer或者在SCC AS实体加判决timer,核心思想无非就是分别拉齐向源MME的切换完成信令和IMS远端的会话迁移信令发送时刻，已将无意义的信令等待导致的话音终端时延降到最低。或者将现有的本地接入网网元进行改造，实现本地锚定功能，即局部快速进行更新，至IMS的远端后续进行更新。

目前比较稳固的一种方案采用本地新增ATCF，ATGW网元的方式进行中断时延优化。

这两个网元的功能有点分别像MME和SGW/PGW，ATCF负责进行控制面的锚定和信令的中转，ATGW负责媒体面的锚定和转发，其中ATGW由ATCF进行控制。值得一提，在后续用户需要通过MSC Server进行IMS注册的情况下，注册信令可以不用通过ATCF进行路由。另外ATCF和ATGW只是逻辑网元，实际建网中，ATCF可以跟类似P-CSCF，IBCF或MSC Server等网元进行合设。

ATCF的功能主要有：

1、分配STN-SR；

2、参与SIP会话；

3、指令ATGW锚定主叫和被叫的媒体路径；

4、执行会话迁移；

5、当会话迁移后，更新远端SCCAS中关于会话的路径信息；

6、在会话迁移过程中处理失败情况；

7、当会话迁移完成后，可根据本地策略，ATCF可以将ATGW从媒体路径中移除，这一步同样需要远端进行更新，其实就意味着ATCF和ATGW只参与会话迁移流程，至于流程完成之后，历史使命结束了，就可以适时的退出舞台；

如果UE在空闲态移动到一个新的MME/SGSN区域，并且接收到了新的IP地址，UE将发起重注册到IMS的流程，同时会选择一个新的ATCF网元进行锚定。如果UE没有收到新的IP地址，它将仍然使用旧有的P-CSCF和旧有的ATCF发起重新注册流程；

ATGW的功能：

根据本地策略部署，由ATCF控制的ATGW可在会话期间和会话迁移后进行媒体路由。ATGW根据ATCF具体的物理设置位置，可以与其他的物理网元进行合设，例如IMS-AGW，TrGW，P-GW或者CS-MGW。

ACC AS的功能：

SRVCC中会话迁移直接锚定在ACC AS的过程由本地的ATCF所取代，因此ACC AS网元的功能也有了一些相应的更新。例如，将远端对话与由会话迁移更新消息创建的新的对话进行关联；清除已有的STN-SR，并且向HSS提供归属地网络配置的STN-SR或者接收到的第三方登记STN-SR；根据UE能力以及SRVCC订阅信息决定是否进行eSRVCC流程；通知ATCF是否SCC AS参与锚定媒体。

从UE侧的信令流程或者测试log来看，增加新的逻辑网元ATCF、ATGW的eSRVCC并没有太大区别，主要的改变还是在新增网元之后的注册、主被叫、PS-CS话音迁移流程中，关于注册，主被叫流程中ATCF只能看作参与中转信令，甚或包括决定ATGW是否作为话音媒体的锚定点，而PS-CS话音迁移则参与了一些主导作用，以下信令流程就是从PS-CS话音迁移进行一些总体分析说明。

1、与上一篇中SRVCC中的信令流程一致，后续步骤在MSC Server收到PS-CS请求之后触发；

2、MSC Server发起Access Transfer消息，如果MSC Server支持mid-call能力，需要在该消息中一并指明。MSC Server提供能够支持的全部码流。如果CS MGW能够支持关于LTE话音的的码流，那么ATCF必须指明ATGW插入匹配码流的概率就降低了，这其实意味着如果MGW侧能够提供码流后续就能使得编码流程简化，否则还得需要ATGW介入进行协商；

3、ATCF收到Access Transfer消息通过C-MSISDN对迁移的会话进行关联。ATCF识别出正确的锚定会话，并且对新加入的会话进行迁移。ATCF通过发送配置ATGW消息更新ATGW中PS访问路径为新的CS访问路径；

4、ATGW返回配置ATGW应答消息至ATCF；

5、ATCF发送Access Transfer响应至MSC Server。当MSC Server支持辅助mid-call功能，ATCF提供会话状态信息Session State Information（SSI）。媒体路径已经转为CS域；

6、在收到AccessTransfer消息后，ATCF重建与SCC AS的通信，同时根据存储的ATU-STI发送Access Transfer更新消息。Access Transfer更新消息创建了在ATCF与SCC AS之间新的对话。SCC AS把新创建的对话与远端对话相关联，如果在对话描述（SDP）中没有更新内容，SCC AS也不会发送更新至远端；

7、SCC AS发送确认响应至ATCF；

8、如果MSC Server收到关于激活会话或者活跃会话更多的状态信息SSI，会触发与前述步骤相同的Access Transfer流程。

7 那些年与VoLTE相关的参数

学习一门技能，总有一天能用的上，你懂的。

VoLTE可以说是IMS主导的舞台，因此接入网层面与VoLTE相关的参数以及特征功能并不太多，可以算是舞台上的配角。VoLTE技术本身涉及的一些无线参数并不多，不过由于话音业务的出现，研究重点会适当的从涉及信令层面的参数转向涉及业务层面的参数，因此诸如PDCP/RLC的一些流程以及相关参数可以被提炼出来咀嚼一番，而这些恰恰是LTE建网初期主流优化中并不太关注的。其实涉及LTE网络，终端的参数名目种类繁多，我们之前对于无线参数有过系统性的介绍，这里不再拘泥于系统性的分类介绍，只是谈谈一些可能涉及VoLTE的参数，这其中有通过网络侧预先配置，并通过信令下发UE的，也有UE本身的一些参数。

由于从R9及之后版本终端可以支持VoLTE，所以在UE无线接入能力上报中UE一些能力字段会改变，这些字段的分析解读有助于后续一些问题的端到端定位，例如，涉及终端的一些问题。

这里值得一提的是PDCP字段与FeatureGroup Indicator（特征组标识，FGI）。pdcp-Parameters里包含的内容说明UE所支持的PDCP包头压缩的能力以及最大能够压缩的包头数量，与网络侧通过RRC重配消息中下发无线专用资源配置IE（RadioResourceConfigDedicated）中所带有的PDCP-Config是不同的。PDCP-Config是网络侧用来配置数据承载（dataradio bear）的PDCP层相关参数的。

discardTimer

该定时器伴随上行传输，即控制数据包上传的一个定时器，每一个PDCP SDU对应一个discardTimer。当UE从上层接收到PDCP SDU时，开始启动该SDU对应的定时器。当该定时器超时或者已经通过PDCP状态报告确认将相应PDCP SDU传到下层时，UE需要将PDCP SDU以及相应的PDCP PDU丢弃。如果PDCP PDU被提交到下层，那么丢弃这一状态也应一并通知下层，意味着PDCP这层把相应的包彻底清空了，这就好比搬家一样，把家具从楼上搬到楼下，需告知楼下的搬家公司，楼上已经清空了。不过，UE高层要求数据承载对应的RLC非确认模式（这里比较拗口，一般就是指的VoLTE话音业务）下进行PDCP进行重建立时，在重建之前没发出的PDCP SDU不需要重新触发discardTimer。因此，该定时器如果设置过小，对于PDCP重建成功有一定影响，会影响丢包率，而设置过大，则容易过多的占用PDCP层的资源，影响后续包的发送时延。

statusReportRequired

指示UE在PDCP重建中是否需要发送PDCP状态报告。这个参数标识伴随着RLC-AM模式，即意味着对于AM模式下的SRB或者DRB处理。如果UE高层配置RB在上行中发送PDCP状态报告，需要在处理由于底层重建产生的PDCP数据PDU之后，按照如下要求，将状态报告编译，并向下以第一个PDCP PDU的方式发送至底层：

将FMS域设置成第一个缺失的PDCPSDU的PDCP SN；

如果有至少一个乱序PDCPSDU存在，分配Bit位图的长度等同于PDCP SN的数量，这里不包括第一个缺失的PDCP SDU，但是包括最后乱序的PDCP SDUs，并且补齐为8的整数倍；

针对底层指示的所有没有收到的PDCP SDUs，在Bit位图相应的位置中设为0；对于解压缩失败的PDCP SDUs，可选择性的在Bit位图相应的位置设为0；

对于其他的PDCPSDUs设置为1。

这里说明的是在接收到下行的包，发现有些包是缺失的，因此处于RLC-AM格式下，后续需要通过PDCP Control PDU进行上行反馈，值得一提的是，PDCP层设置的这个控制PDU格式其实对应了RLC-AM的这种保护机制，确保包能够被正确接收，但是这个PDU本身却不具备什么应答确认机制，如果这个包没有被正确收到会怎样呢？有兴趣的读者可以琢磨一下。

图例说明的是一个PDCP控制PDU携带一个PDCP状态报告的格式，适用于RLC-AM模式下的DRB承载。上图每一行是一个8bit的位图，FMS代表第一个丢失的PDCPSN,共12bit。下面的位图代表着从第一个缺失PDCP SN（FMS）开始，即FMS+1，从左至右逐行遍历，如果第n bit置为0，则代表（FMS+n）mod4096为缺失PDCP SN，否则（即置为1）为无需重传的PDCP SDU。

当然，这个PDCP Control PDU即可以由UE高层触发进行配置，并通过上行信道发送出去，诚然，有来有往，也可以通过下行信道接收下来，收到之后，如果相应Bitmap置为1或者COUNT值小于FMS对应PDCP SDU的COUNT值，则UE就会将与之对应已发送的PDCP SDU与PDCP PDU丢弃，意味着这些PDCP SDU已经成功被接收并解码。

该参数主要结合了非话音/视频的数据业务承载，相较话音而言，数据业务对于包的丢失更敏感。

pdcp-SN-Size

这里说明的是PDCP-SN串号长度，分为12bit和7bit两种长度。这个串号长度其实与HFN对应，HFN又用来计算解密时候所需要的COUNT值。对于RLC-AM模式下，PDCP-SN设置为12bit,而对于RLC-UM模式，可选择性的设置12bit或者7bit。这两种串号长度设置的区别在于，由于RLC-UM模式下没有对于PDCP SDU是否正确接收到的应答机制，相较于较长的12bit，7bit的设置会一定程度上降低包漏检或者错检的概率（这是理论分析，实际情况还需要网络侧进行评估），因此对于时延较敏感的VoLTE话音来说，能够兼顾降低丢包的概率，这应该也是增加7bit作为UM候选项的一个初衷。

PDCP Data PDU format for DRBs using a 12 bit SN

PDCP Data PDU format for DRBs using 7 bit SN

Profiles

Profile是为ROHC（RobustHeader Compression）结构定义的包头压缩算法，针对不同的网络层，传输层以及上层协议组合而不同，具体算法的含义可参考不同协议文献，这里仅列出协议列表供参考。需要指出的是，Profile 0x0000即使不指明，也会默认存在。

UE能力上报中还有一个FGI字段（FeatureGroup Indicator）,以下是R10中关于这个字段中对于PDCP SN长度的设置说明，可以将bit3与bit7捆绑起来解读，这里指出如果UE支持VoLTE，则必须将bit7置为1（true），从而连锁导致bit3也应置为1（true），这意味着VoLTE话音必须通过RLC UM模式进行传输，同时PDCP SN也应该支持7bit的能力设置。

这里也遗留一个小问题，如果UE自身的错误设置，将bit7设置为1，bit3设置为0，那么在UE能力上报阶段网络侧会不会禁止UE接入？这就要在现网实际验证一下了，各个LTE主流厂商的的策略可能都不一致。
对于前期所叙述的SRVCC流程，UE的支持能力也可以在bit9进行确认。

8 现网测试案例分析

下面就给大家带来两个现网中遇到的小案例，希望能够起到抛砖引玉的作用。我们为大家提供的是开胃的小菜，主菜就需要大家不断摸索，在日常的优化工作中获取了。

提到甜点，大家第一时间想到的应该都是法国吧。德国美食在人们心中往往都是一副硬派的形象，肥美的烤猪肘子、烤香肠，再搭配上麦芽味醇厚的自酿黑啤酒，简直就是完美的享受。但是德国这个国家粗中有细，把严谨的做派沿用到甜点上，也能够诞生令人惊异的美味。

我们从现网测试的一些具体案例入手尝试对一些异常现象进行分析。

以下是南京现网实测的一个主叫未接通案例，在主叫发送INVITE之前，网络侧下发了一个UPDATE消息。

协议RFC3311说明，UPDATE消息可被用来进行媒体流和码流信息的更新，有点类似于re-INVITE消息，但是区别于re-INVITE消息，UPDATE消息可以在初始的INVITE消息完成之前发送。因此可以知道这个电话是已经在通话中或者上一次的INVITE消息已经收到响应，由于被叫一端发起了UPDATE流程。紧接着，主叫又发起了一个INVITE流程，如下图所示：

由于INVITE流程不能与前一次的INVITE流程发生冲突，即之前的INVITE流程在进行中时，主被叫UE均不能发起INIVTE,因此可以认为初始的INVITE流程已经完成或者收到响应。之前来自于网络侧的UPDATE是在前一次的INVITE流程之后由网络侧或被叫UE发起的（例如，被叫UE暂时挂起）。

之后主叫UE收到了403（Forbidden）消息，Forbidden消息是服务器识别了INVITE请求，但是无法进行相应的鉴权，另外UE收到403消息后，不能重复发起re-INVITE请求，除非进行相应鉴权信息修改。(RFC 3261),同时回溯测试时间之前大约10分钟的测试log,都发现频繁重复的出现了SIP INVITE-403 FORBIDDEN-SIPACK信令，由此可以初步判定这一系列的INVITE消息应该是终端的设置造成的，并不符合标准协议流程。

这个403 Forbidden消息有可能由如下原因导致：

1、P-CSCF发起，可能是因为新的re-INVITE请求与现有对话无关；

2、S-CSCF发起，可能由于与之前存储信息不符；

3、I-CSCF发起，由于鉴权信息的不一致；

…

后续,网络侧发来SIP BYE消息,注意红线圈出的原因“SCSCF released the session because of session timer expiration”，因此，最终由于SCSCF的对于会话的周期性更新，当会话定时超时后，S-CSCF删除了对话相关的存储信息，并下发了SIP BYE。

从上述现象结合起来观察，当终端收到403 FORBIDDEN后，并不释放终端的SRB、EPS承载，因此可以看到在收到403后，RRC层依然进行着重配，测量，切换等一系列操作。

这个未接通的案例值得进一步深思，存在如下几点：

1、终端什么情况下会重复发送SIPINVITE，触发条件是什么？

2、终端收到403FORBIDDEN后是否会回复SIP ACK？

3、网络侧为什么在过程中会发UPDATE，更新的内容是什么？

4、同时，回溯之前的测试log，在两次的SIP INVITE-403 FORBIDDEN-SIP ACK之间还收到了主叫发起的注册流程，终端在什么条件下会发起注册流程？而注册请求到200ok之间还收到了网络侧的NOTIFY消息，而注册消息和NOTIFY消息的SIP Call ID还不一样。

这个case信令统计点来看容易被误判成掉线（call drop），但其实从用户感受以及结合回溯的实际信令流程来看属于未接通的的案例（callsetup failure）。

下面一个案例也是在南京现网发生的主叫未接通案例。

主叫UE发出SIP INVITE收到100 trying后，相隔一段时间后收到了网络侧下发的SERVICE_UNAVAILABLE(503)，

协议规定SERVICE_UNAVAILABLE(503)表示服务器由于负荷过载或者维护问题暂时无法处理发送请求。服务器可能会在Retry-After头域里指示客户端何时再进行请求重发尝试。如果Retry-After没有给出，那么客户端必须表现的如同收到Server Internal Error(500)响应一样。而对于Server Internal Error(500)响应的描述，一般指的是服务器处于不可预计的条件下，从而无法满足请求。客户端可以将该特定错误状况进行展示，例如该次的错误状态为"Media Bearer Lost"，一般收到500响应，可以基本断定是S-CSCF出现的问题，其中P-CSCF只是将之转发。

我们回溯一下信令发现，当主叫UE收到了100 trying后，迟迟等不到后续的183-180ringing，以及最后的SIP 200 ok,当大约10秒超时后，由RRC层先进行了了链路释放。



之后收到503后，其实已经处于RRC-IDLE状态，因此通过网络侧寻呼后又变成了连接态，其实从主叫状态经历了RRC-IDLE,之后又变成了“被叫”。随后，网络侧下发QCI1的专用承载去激活NAS ESM信令，UE反馈Accept，同时将专用承载状态置为Inactive。


这里仅仅是专用承载去激活，默认承载QCI9，QCI5还依然保留，EUTRAN侧并没有立即发起RRC释放。后续可能由于目前UE的私有设置，UE变成了一个CSFB终端，后续的信令流程就是标准的CSFB主叫流程了

结合整个流程的分析，推测出现问题是由于UE收到100 trying后没有收到后续SIP响应，因此当10秒超时后，EUTRAN下发了RRC Connection Release,这里释放掉了SRB也同时释放掉了DRB，同时EUTRAN上报核心网由于该UE不活跃（User Inactivity）触发导致MME也将EPS承载释放(这里一般由eNodeB发起，通过UE Context Release Request信令发起，通知MME将该UE的所有在S1接口建立起来的E-RAB释放掉)，这样通知IMS域媒体承载释放，也就造成了后续503的下发。问题的关键是需要明确在10秒之内为什么没有收到183-180ringing响应，这里有一种可能被叫处于CSFB状态（或者CS域），导致协商时间过长，超过了10秒。
有一个值得注意的现象，当网络侧异常释放了RRC连接，即下发了RRC Connection Release，根据协议36.331描述，UE会清空自己所有建立的RB，但是不一定会释放掉EPS Bear，因此当再收到RRC重配消息后，通过重配消息中EPS Bear ID与DRB ID的耦合，可以分别确认默认承载QCI9，QCI5以及话音的专用承载QCI1的映射情况。