几天前发生的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公布详细报告。再次重申,由于技术水平有限,如有不当之处,请各位在留言区指出。
审核编辑 :李倩
-
交换机
+关注
关注
21文章
2640浏览量
99639 -
数据库
+关注
关注
7文章
3799浏览量
64389 -
信令
+关注
关注
0文章
40浏览量
14181
原文标题:信令分析:KDDI重大故障为何持续60小时之久?
文章出处:【微信号:wuxian_shenhai,微信公众号:无线深海】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论