KDDI重大故障为何持续60小时之久？

几天前发生的KDDI网络故障，是KDDI史上最大、也是近年来全球罕见的网络重大故障，值得整个通信行业研究和吸取教训。

本着好奇，雇佣军通过收集一些零碎信息，对本次事故进行了如下分析。由于技术水平有限，如有不当之处，请各位在留言区指出。但求抛砖引玉，引起行业进一步的思考和讨论。

事故过程回顾

根据KDDI简报，本次事故经过如下： 7月2日凌晨1:35开始

因更换路由器发生故障，无法将语音流量正确路由到其中一台“VoLTE交换机”，直接导致部分VoLTE语音业务中断15分钟。 7月2日凌晨1:50

启动回退操作，将连接重新切换回旧的路由器上。 7月2日凌晨2:17

由于大量终端向IMS网络发起位置注册信令以请求重新连接至网络，发现“VoLTE交换机”拥塞。 7月2日凌晨3点至下午15:22

KDDI在无线侧、核心网侧同时实施流量控制策略，以缓解“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公布详细报告。再次重申，由于技术水平有限，如有不当之处，请各位在留言区指出。

审核编辑 ：李倩