|
作者：中国移动集团公司 张阳 （章末附作者介绍）
作者微信公众号：网优小谈（wireless_talk）
续《移动内部疯传的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-*5*01eb3dceecc83856d94btaN0
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进行确认。
| 
215
发表于 2015-12-3 09:37:26