了解：信令分析：KDDI重大故障为何持续60小时之久2022/12/26 16:24:13

哦不明白

几天前发生的KDDI络故障，是KDDI史上比较大、也是近年来全球罕见的络重大故障，值得整个通信行业研究和吸取教训。?几天前发生的KDDI络故障，是KDDI史上比较大、也是近年来全球罕见的络重大故障，值得整个通信行业研究和吸取教训。ip地址归属地查询的相关知识也可以到网站具体了解一下，有专业的客服人员为您全面解读，相信会有一个好的合作！

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





事故过程回顾



根据KDDI简报，本次事故经过如下：



7月2日凌晨1:35开始因更换路由器发生故障，法将语音流量正确路由到其中一台“VLTE交换机”，直接导致部分VLTE语音业务中断15分钟。7月2日凌晨1:50启动回退操作，将连接重新切换回旧的路由器上。7月2日凌晨2:17由于大量终端向IMS络发起位置注册信令以请求重新连接至络，发现“VLTE交换机”拥塞。7月2日凌晨3点至下午15:22KDDI在线侧、核心侧同时施流量控制策略，以缓解“VLTE交换机”拥塞。7月2日下午15:22开始由于发现“用户数据库”也拥塞，断开东日本的2台PGW设备和西日本的2台PGW，以减轻“用户数据库”负荷。7月2日下午17:31开始为处理“用户数据库”与“VLTE交换机”之间存在的数据不一致问题，KDDI对东日本的2台PGW设备和西日本的2台PGW设备施“会话重置”措施，解决了数据不一致问题。接下来，对其余13台PGW设备（东日本7台，西日本6台）也施了断开和会话重置操作。7月3日下午17:30通过施以上策略，东日本和西日本的修复工作基本完成。7月4日凌晨4点尽管施了以上一系列措施，但在之后的络测试和验证中发现，“VLTE交换机”和“用户数据库”的负荷并没有得到充分缓解。随后，在故障持续2天多后，KDDI发现其18台“VLTE交换机”中有6台“VLTE交换机”向“用户数据库”不断发送“不必要的多余信令”。7月4日12:18至13:18切断这6台“VLTE交换机”后，其余“VLTE交换机”和“用户数据库”的负载大幅降低到故障发生前的水平。7月4日14点51分解除线侧流量控制。到此，KDDI此次重大络故障总算基本恢复。

不难看出，此次事故并非单一故障，而是由某一故障点引发的一连串问题导致。正因如此，故障持续了长达60多个小时。



那问题来了，估计所有通信人都很好奇，KDDI所指的“VLTE交换机”和“用户数据库”具体是4G核心的哪一个元到底是哪些环节出了问题





信令跟踪与分析



感谢日本同行在故障发生后对络信令进行了跟踪与记录，从信令截图看，存在两大故障现象。



故障现象一：





VLTE手机向IMS核心发起SIPR（SIP注册）请求后，返回500CUTC或500SIE错误，导致IMS注册失败。



查询SIP协议，500SIE指因服务器遇到了意外情况阻止了请求完成，客户端可能会在几秒钟后重试请求。



CUTC，未查询到这一故障代码是什么原因引起的，但由于C指IMS核心元IS-CSCF与HSS之间的接口，采用D信令，因此，可能表明IS-CSCF与HSS或者两者之间的链路出现了问题。



故障现象二：





手机附着到LTE络并建立默认EPS承载后，向络发起PDNCR以请求后，返回PDNCR消息，导致法建立QCI=5的SIP信令承载。



打开PDNCR消息，原因为I，表明由于资源不足而法提供所请求的服务。



这两大信令异常均会导致VLTE用户注册失败，这符合KDDI故障现象，即用户法接打VLTE语音通话。



接下来，我们再来对比VLTE用户注册流程，看看具体是哪一个环节出错了





EPS和IMS络架构图



VLTE用户注册流程总体包括：EPS附着和QCI5承载建立、IMS注册。



有必要先解释一下QCI5承载。



通常，VLTE使用双APN架构，包括IAPN和IMSAPN。IAPN为默认APN，手机开机后会首先与之建立一个PDN连接，其默认EPS承载的QCI值通常为9。



当手机与IAPN建立PDN连接后，手机会额外进行与IMSAPN的PDN连接，其默认EPS承载的QCI值为5，主要负责传送SIP信令。



承载，就是就是指承载人、搬运工，负责将信令和数据从一点运输到另一点。在4G规范中，定义了不同承载业务对应的QCI值。其中，QCI5先级比较高，用于IMS（SIP）信令的默认承载；QCI1-4其次，可用于VLTE语音和视频通话；QCI6-9先级比较低，只能“尽力而为”保障数据传输。



具体流程如下。



EPS附着和QCI9默认承载建立







1、2、3、4、5：UE向MME发送附着请求（AR）后，MME与HSS对UE进行鉴权，并在鉴权通过后，MME向HSS获取UE的签约数据。



6、7、8、9：MME根据用户签约数据中的默认APN和PDN签约上下文，通过CSR消息向SGWPGW请求建立EPC默认承载（QCI一般为9），SGWPGW向PCRF发送C-C-R(CCR)为默认承载请求PCC策略，PCRF根据接收到的用户签约数据确定PCC策略，并通过C-C-A（CCA）响应，随后SGWPGW向MME发送CSR完成GTP-C会话创建过程。



10、11：MME向UE发送AA，并请求激活默认EPS承载；UE通过AC消息通知MME默认EPS承载已激活。



此时，UE完成EPS附着并建立QCI9默认承载。



QCI5承载建立

12、13、14、15、16：UE向MME发送PDNCR，MME向SGWPGW发送CSR请求建立QCI5默认承载，SGWPGW向PCRF发送CCR为默认承载请求PCC策略，PCRF通过CCA响应后，SGWPGW向MME发送CSR。



17、18：MME向UE发送ADEPSBCR激活默认EPS承载，UE响应ADEPSBCA消息通知MME默认EPS承载已被激活。



此时，UE和IMSAPN之间建立了QCI值为5的默认EPS承载，接下来，所有SIP信令流量将通过QCI5承载。



IMS注册





19、20、21：UE通过向P-CSCF发送SIPREGISTER发起IMS注册，I-CSCF向HSS发送U-A-R(UAR)执行用户注册状态查询，HSS授权用户使用IMS服务后，在U-A-A（UAA）响应中返回该用户的S-CSCF地址。



22、23、24、25、26：I-CSCF将SIPREGISTER转发给指定的S-CSCF，S-CSCF向HSS发送M-A-R(MAR)请求鉴权信息，HSS通过M-A-A（MAA）响应后，S-CSCF通过401UA消息将鉴权信息发送至UE，以完成UE对络侧鉴权。



27、28、29、30、31、32、33：UE向IMS发起第二次注册请求和响应流程，以完成络侧对UE鉴权，并下载用户IMS签约数据。详细步骤与首次注册类似。



对比信令追踪和VLTE注册流程，此次VLTE语音故障原因可能发生在CSCF与HSS之间，以及SPGW与PCRF之间。（如信令流程图中的红星标识）



对比KDDI故障简报，其提到的“VLTE交换机”可能是CSCF元，而“用户数据库”可能是HSS元，或者HSS与PCRF融合元。



CSCF，CSCF，IMS络架构中关键元体功能，其按位置和功能又分为PSI种类型，其中，P-CSCF（PCSCF）是IMS络的初始接入点，所有起始和终止于SIP终端的会话均通过P-CSCF；S-CSCF（SCSCF）在IMS核心中处于核心控制地位，其配合HSS元对用户进行鉴权，从HSS下载用户签约信息，并根据用户签约的IMS触发规则进行路由触发和业务控制，以及管理基本会话路由；I-CSCF（ICSCF），IMS归属络的入口点，在注册过程中I-CSCF通过查询HSS为用户选择一个S-CSCF。



HSS，HSS，归属用户服务器，存储并管理用户签约数据,包括用户鉴权信息、位置信息及路由信息等。在VLTE络架构中，EPCHSS和IMSHSS可以融合部署。



PCRF，策略和计费控制单元，用于用户信息管理、PCC策略管理、PCC策略动态生成及事件触发等差异化服务业务。





D信令异常



再来回顾KDDI故障简报，有两点值得关注。



(1）KDDI在新闻发布会上表示，回退操作后，尽管有相当多的用户向“VLTE交换机”发起重新连接，但这些用户数量并不是KDDI总用户数。同时，KDDI在全国范围内有18个“VLTE交换机”，且相互冗余备份。KDDI也做过模拟测试，即使所有用户发起重连，也不会引起VLTE拥塞。因此，本次事故可能还潜伏着其他原因。



(2）“VLTE交换机”拥塞发生后，尽管施了接入限制、流控控制、断开部分PGW元等措施，但“VLTE交换机”和“用户数据库”的负荷并没有得到充分缓解，直到故障持续2天多后，KDDI才进一步发现其18台“VLTE交换机”中有6台“VLTE交换机”向“用户数据库”不断发送“不必要的多余信令”。断开这6台“VLTE交换机”后，其余“VLTE交换机”和“用户数据库”的负载大幅降低到故障发生前的水平。



所谓”VLTE交换机“不断向”用户数据“发送”不必要的多余信令“，即CSCF元不断向HSS（或者HSS与PCRF融合元）发送异常信令。



在4G络架构中，IS-CSCF与HSS之间的为C接口，采用D信令。



D信令主要应用于EPC系统、策略及计费控制PCC系统和IMS域，主要用于用户鉴权、数据、策略、计费管理等。



EPC、PCC、IMS络中使用D信令的元和接口包括：IS-CSCF与HSS之间的接口、PCRF与PGW之间的G接口、HSS与MME之间的S6接口等。



而从前文分析看，本次事故的故障点均发生在与D信令相关的接口和元。







因此，怀疑此次事故还潜伏着一个重要故障：D信令异常。



当然，以上只是基于一些碎片信息的不成熟分析，具体原因只能等待KDDI公布详细报告。?