几天前发生的KDDI网络故障，是KDDI史上最大、也是近年来全球罕见的网络重大故障，值得整个通信行业研究和吸取教训。
本着好奇，我们通过收集一些零碎信息，对本次事故进行了如下分析。由于技术水平有限，如有不当之处，请各位在留言区指出。但求抛砖引玉，引起行业进一步的思考和讨论。
事故过程回顾
根据KDDI简报，本次事故经过如下：
- 7月2日凌晨1:35开始
- 因更换路由器发生故障，无法将语音流量正确路由到其中一台“VoLTE交换机”，直接导致部分VoLTE语音业务中断15分钟。
- 7月2日凌晨1:50启动回退操作，将连接重新切换回旧的路由器上。
- 7月2日凌晨2:17由于大量终端向IMS网络发起位置注册信令以请求重新连接至网络，发现“VoLTE交换机”拥塞。
- 7月2日凌晨3点至下午15:22KDDI在无线侧、核心网侧同时实施流量控制策略，以缓解“VoLTE交换机”拥塞。
- 7月2日下午15:22开始由于发现“用户数据库”也拥塞，断开东日本的2台PGW设备和西日本的2台PGW，以减轻“用户数据库”负荷。
- 7月2日下午17:31开始为处理“用户数据库”与“VoLTE交换机”之间存在的数据不一致问题，KDDI对东日本的2台PGW设备和西日本的2台PGW设备实施“会话重置”措施，解决了数据不一致问题。
- 接下来，对其余13台PGW设备（东日本7台，西日本6台）也实施了断开和会话重置操作。
- 7月3日下午17:30通过实施以上策略，东日本和西日本的修复工作基本完成。
- 7月4日凌晨4点尽管实施了以上一系列措施，但在之后的网络测试和验证中发现，“VoLTE交换机”和“用户数据库”的负荷并没有得到充分缓解。
- 随后，在故障持续2天多后，KDDI发现其18台“VoLTE交换机”中有6台“VoLTE交换机”向“用户数据库”不断发送“不必要的多余信令”。
- 7月4日12:18至13:18切断这6台“VoLTE交换机”后，其余“VoLTE交换机”和“用户数据库”的负载大幅降低到故障发生前的水平。
- 7月4日14点51分解除无线侧流量控制。
- 到此，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公布详细报告。
