几天前发生的KDDI网络故障，是KDDI史上最大、也是近年来全球罕见的网络重大故障，值得整个通信行业研究和吸取教训。
本着好奇，我们通过收集一些零碎信息，对本次事故进行了如下分析。由于技术水平有限，如有不当之处，请各位在留言区指出。但求抛砖引玉，引起行业进一步的思考和讨论。
事故过程回顾根据KDDI简报，本次事故经过如下：
【资料图】
不难看出，此次事故并非单一故障，而是由某一故障点引发的一连串问题导致。正因如此，故障持续了长达60多个小时。
那问题来了，估计所有通信人都很好奇，KDDI所指的“VoLTE交换机”和“用户数据库”具体是4G核心网的哪一个网元？到底是哪些环节出了问题？
信令跟踪与分析感谢日本同行在故障发生后对网络信令进行了跟踪与记录，从信令截图看，存在两大故障现象。
故障现象一：
VoLTE手机向IMS核心网发起SIP Register（SIP注册）请求后，返回500 Cx Unable To Comply或500 Server Internal Error错误，导致IMS注册失败。
查询SIP协议，500 Server Internal Error指因服务器遇到了意外情况阻止了请求完成，客户端可能会在几秒钟后重试请求。
Cx Unable To Comply，未查询到这一故障代码是什么原因引起的，但由于Cx指IMS核心网网元I/S-CSCF与HSS之间的接口，采用Diameter信令，因此，可能表明I/S-CSCF与HSS或者两者之间的链路出现了问题。
故障现象二：手机附着到LTE网络并建立默认EPS承载后，向网络发起PDN Connectivity Request以请求后，返回PDN Connectivity Reject消息，导致无法建立QCI=5的SIP信令承载。
打开PDN Connectivity Reject消息，原因为Insufficient resources，表明由于资源不足而无法提供所请求的服务。
这两大信令异常均会导致VoLTE用户注册失败，这符合KDDI故障现象，即用户无法接打VoLTE语音通话。
接下来，我们再来对比VoLTE用户注册流程，看看具体是哪一个环节出错了？
EPS和IMS网络架构图
VoLTE用户注册流程总体包括：EPS附着和QCI5承载建立、IMS注册。
有必要先解释一下QCI5承载。
通常，VoLTE使用双APN架构，包括Internet APN和IMS APN。Internet APN为默认APN，手机开机后会首先与之建立一个PDN连接，其默认EPS承载的QCI值通常为9。
当手机与Internet APN建立PDN连接后，手机会额外进行与IMS APN的PDN连接，其默认EPS承载的QCI值为5，主要负责传送SIP信令。
承载，就是就是指承载人、搬运工，负责将信令和数据从一点运输到另一点。在4G规范中，定义了不同承载业务对应的QCI值。其中，QCI5优先级最高，用于IMS（SIP）信令的默认承载；QCI1-4其次，可用于VoLTE语音和视频通话；QCI6-9优先级最低，只能“尽力而为”保障数据传输。
具体流程如下。
EPS附着和QCI9默认承载建立1、2、3、4、5：UE向MME发送附着请求（Attach Request）后，MME与HSS对UE进行鉴权，并在鉴权通过后，MME向HSS获取UE的签约数据。
6、7、8、9：MME根据用户签约数据中的默认APN和PDN签约上下文，通过Create Session Request消息向SGW/PGW请求建立EPC默认承载（QCI一般为9），SGW/PGW向PCRF发送Credit-Control-Request(CCR) 为默认承载请求PCC策略，PCRF根据接收到的用户签约数据确定PCC策略，并通过Credit-Control-Answer（CCA）响应，随后SGW/PGW向MME发送Create Session Response完成GTP-C会话创建过程。
10、11：MME向UE发送 Attach Accept，并请求激活默认EPS承载；UE通过Attach Complete消息通知MME默认EPS承载已激活。
此时，UE完成EPS附着并建立QCI9默认承载。
QCI5承载建立12、13、14、15、16：UE向MME发送PDN Connectivity Request，MME向 SGW/PGW发送Create Session Request请求建立QCI5默认承载，SGW/PGW向PCRF发送CCR为默认承载请求PCC策略，PCRF通过CCA响应后，SGW/PGW向MME发送Create Session Response。
17、18：MME向UE发送Activate Default EPS Bearer Context Request激活默认EPS承载，UE响应Activate Default EPS Bearer Context Accept消息通知MME默认EPS承载已被激活。
此时，UE和IMS APN之间建立了QCI值为5的默认EPS承载，接下来，所有SIP信令流量将通过QCI5承载。
IMS注册19、20、21：UE通过向P-CSCF发送SIP REGISTER发起IMS注册，I-CSCF向HSS发送User-Authorization-Request(UAR) 执行用户注册状态查询，HSS授权用户使用IMS服务后，在User-Authorization-Answer（UAA）响应中返回该用户的S-CSCF地址。
22、23、24、25、26：I-CSCF将SIP REGISTER转发给指定的S-CSCF，S-CSCF向HSS发送Multimedia-Auth-Request(MAR)请求鉴权信息，HSS通过Multimedia-Auth-Answer（MAA）响应后， S-CSCF通过401 UnAuthorized消息将鉴权信息发送至UE，以完成UE对网络侧鉴权。
27、28、29、30、31、32、33：UE向IMS发起第二次注册请求和响应流程，以完成网络侧对UE鉴权，并下载用户IMS签约数据。详细步骤与第一次注册类似。
对比信令追踪和VoLTE注册流程，此次VoLTE语音故障原因可能发生在CSCF与HSS之间，以及S/PGW与PCRF之间。（如信令流程图中的红星标识）
对比KDDI故障简报，其提到的“VoLTE交换机”可能是CSCF网元，而“用户数据库”可能是HSS网元，或者HSS与PCRF融合网元。
CSCF，Call Session Control Function，IMS网络架构中关键网元实体功能，其按位置和功能又分为P/S/I三种类型，其中，P-CSCF（Proxy CSCF）是IMS网络的初始接入点，所有起始和终止于SIP终端的会话均通过P-CSCF；S-CSCF（Serving CSCF）在IMS核心网中处于核心控制地位，其配合HSS网元对用户进行鉴权，从HSS下载用户签约信息，并根据用户签约的IMS触发规则进行路由触发和业务控制，以及管理基本会话路由；I-CSCF（Interrogating CSCF），IMS归属网络的入口点，在注册过程中I-CSCF通过查询HSS为用户选择一个S-CSCF。
HSS，Home Subscriber Server，归属用户服务器，存储并管理用户签约数据,包括用户鉴权信息、位置信息及路由信息等。在VoLTE网络架构中，EPC HSS和IMS HSS可以融合部署。
PCRF，策略和计费控制单元，用于用户信息管理、PCC策略管理、PCC策略动态生成及事件触发等差异化服务业务。
Diameter信令异常？再来回顾KDDI故障简报，有两点值得关注。
(1）KDDI在新闻发布会上表示，回退操作后，尽管有相当多的用户向“VoLTE交换机”发起重新连接，但这些用户数量并不是KDDI总用户数。同时，KDDI在全国范围内有18个“VoLTE交换机”，且相互冗余备份。KDDI也做过模拟测试，即使所有用户发起重连，也不会引起VoLTE拥塞。因此，本次事故可能还潜伏着其他原因。
(2）“VoLTE交换机”拥塞发生后，尽管实施了接入限制、流控控制、断开部分PGW网元等措施，但“VoLTE交换机”和“用户数据库”的负荷并没有得到充分缓解，直到故障持续2天多后，KDDI才进一步发现其18台“VoLTE交换机”中有6台“VoLTE交换机”向“用户数据库”不断发送“不必要的多余信令”。断开这6台“VoLTE交换机”后，其余“VoLTE交换机”和“用户数据库”的负载大幅降低到故障发生前的水平。
所谓”VoLTE交换机“不断向”用户数据“发送”不必要的多余信令“，即CSCF网元不断向HSS（或者HSS与PCRF融合网元）发送异常信令。
在4G网络架构中，I/S-CSCF与HSS之间的为Cx接口，采用Diameter信令。
Diameter 信令主要应用于EPC系统、策略及计费控制PCC系统和IMS域，主要用于用户鉴权、数据、策略、计费管理等。
EPC、PCC、IMS网络中使用Diameter信令的网元和接口包括：I/S-CSCF 与 HSS 之间的接口、PCRF与PGW之间的Gx接口、HSS与MME之间的S6a接口等。
而从前文分析看，本次事故的故障点均发生在与Diameter信令相关的接口和网元。
因此，怀疑此次事故还潜伏着一个重要故障：Diameter信令网异常。
当然，以上只是基于一些碎片信息的不成熟分析，具体原因只能等待KDDI公布详细报告。
