样需要远端进行更新，其实就意味着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或者