幾天前發(fā)生的KDDI網(wǎng)絡(luò)故障，是KDDI史上最大、也是近年來全球罕見的網(wǎng)絡(luò)重大故障，值得整個通信行業(yè)研究和吸取教訓(xùn)。

本著好奇，雇傭軍通過收集一些零碎信息，對本次事故進(jìn)行了如下分析。由于技術(shù)水平有限，如有不當(dāng)之處，請各位在留言區(qū)指出。但求拋磚引玉，引起行業(yè)進(jìn)一步的思考和討論。

事故過程回顧

根據(jù)KDDI簡報，本次事故經(jīng)過如下： 7月2日凌晨1:35開始

因更換路由器發(fā)生故障，無法將語音流量正確路由到其中一臺“VoLTE交換機(jī)”，直接導(dǎo)致部分VoLTE語音業(yè)務(wù)中斷15分鐘。 7月2日凌晨1:50

啟動回退操作，將連接重新切換回舊的路由器上。 7月2日凌晨2:17

由于大量終端向IMS網(wǎng)絡(luò)發(fā)起位置注冊信令以請求重新連接至網(wǎng)絡(luò)，發(fā)現(xiàn)“VoLTE交換機(jī)”擁塞。 7月2日凌晨3點(diǎn)至下午15:22

KDDI在無線側(cè)、核心網(wǎng)側(cè)同時實(shí)施流量控制策略，以緩解“VoLTE交換機(jī)”擁塞。 7月2日下午15:22開始

由于發(fā)現(xiàn)“用戶數(shù)據(jù)庫”也擁塞，斷開東日本的2臺PGW設(shè)備和西日本的2臺PGW，以減輕“用戶數(shù)據(jù)庫”負(fù)荷。 7月2日下午17:31開始

為處理“用戶數(shù)據(jù)庫”與“VoLTE交換機(jī)”之間存在的數(shù)據(jù)不一致問題，KDDI對東日本的2臺PGW設(shè)備和西日本的2臺PGW設(shè)備實(shí)施“會話重置”措施，解決了數(shù)據(jù)不一致問題。 接下來，對其余13臺PGW設(shè)備（東日本7臺，西日本6臺）也實(shí)施了斷開和會話重置操作。 7月3日下午17:30

通過實(shí)施以上策略，東日本和西日本的修復(fù)工作基本完成。 7月4日凌晨4點(diǎn)

盡管實(shí)施了以上一系列措施，但在之后的網(wǎng)絡(luò)測試和驗證中發(fā)現(xiàn)，“VoLTE交換機(jī)”和“用戶數(shù)據(jù)庫”的負(fù)荷并沒有得到充分緩解。

隨后，在故障持續(xù)2天多后，KDDI發(fā)現(xiàn)其18臺“VoLTE交換機(jī)”中有6臺“VoLTE交換機(jī)”向“用戶數(shù)據(jù)庫”不斷發(fā)送“不必要的多余信令”。

7月4日12:18至13:18

切斷這6臺“VoLTE交換機(jī)”后，其余“VoLTE交換機(jī)”和“用戶數(shù)據(jù)庫”的負(fù)載大幅降低到故障發(fā)生前的水平。 7月4日14點(diǎn)51分

解除無線側(cè)流量控制。

到此，KDDI此次重大網(wǎng)絡(luò)故障總算基本恢復(fù)。

不難看出，此次事故并非單一故障，而是由某一故障點(diǎn)引發(fā)的一連串問題導(dǎo)致。正因如此，故障持續(xù)了長達(dá)60多個小時。

那問題來了，估計所有通信人都很好奇，KDDI所指的“VoLTE交換機(jī)”和“用戶數(shù)據(jù)庫”具體是4G核心網(wǎng)的哪一個網(wǎng)元？到底是哪些環(huán)節(jié)出了問題？

信令跟蹤與分析

感謝日本同行在故障發(fā)生后對網(wǎng)絡(luò)信令進(jìn)行了跟蹤與記錄，從信令截圖看，存在兩大故障現(xiàn)象。

故障現(xiàn)象一：

VoLTE手機(jī)向IMS核心網(wǎng)發(fā)起SIP Register（SIP注冊）請求后，返回500 Cx Unable To Comply或500 Server Internal Error錯誤，導(dǎo)致IMS注冊失敗。

查詢SIP協(xié)議，500 Server Internal Error指因服務(wù)器遇到了意外情況阻止了請求完成，客戶端可能會在幾秒鐘后重試請求。

Cx Unable To Comply，未查詢到這一故障代碼是什么原因引起的，但由于Cx指IMS核心網(wǎng)網(wǎng)元I/S-CSCF與HSS之間的接口，采用Diameter信令，因此，可能表明I/S-CSCF與HSS或者兩者之間的鏈路出現(xiàn)了問題。

故障現(xiàn)象二：

手機(jī)附著到LTE網(wǎng)絡(luò)并建立默認(rèn)EPS承載后，向網(wǎng)絡(luò)發(fā)起PDN Connectivity Request以請求后，返回PDN Connectivity Reject消息，導(dǎo)致無法建立QCI=5的SIP信令承載。

打開PDN Connectivity Reject消息，原因為Insufficient resources，表明由于資源不足而無法提供所請求的服務(wù)。

這兩大信令異常均會導(dǎo)致VoLTE用戶注冊失敗，這符合KDDI故障現(xiàn)象，即用戶無法接打VoLTE語音通話。

接下來，我們再來對比VoLTE用戶注冊流程，看看具體是哪一個環(huán)節(jié)出錯了？

EPS和IMS網(wǎng)絡(luò)架構(gòu)圖

VoLTE用戶注冊流程總體包括：EPS附著和QCI5承載建立、IMS注冊。

有必要先解釋一下QCI5承載。

通常，VoLTE使用雙APN架構(gòu)，包括Internet APN和IMS APN。Internet APN為默認(rèn)APN，手機(jī)開機(jī)后會首先與之建立一個PDN連接，其默認(rèn)EPS承載的QCI值通常為9。

當(dāng)手機(jī)與Internet APN建立PDN連接后，手機(jī)會額外進(jìn)行與IMS APN的PDN連接，其默認(rèn)EPS承載的QCI值為5，主要負(fù)責(zé)傳送SIP信令。

承載，就是就是指承載人、搬運(yùn)工，負(fù)責(zé)將信令和數(shù)據(jù)從一點(diǎn)運(yùn)輸?shù)搅硪稽c(diǎn)。在4G規(guī)范中，定義了不同承載業(yè)務(wù)對應(yīng)的QCI值。其中，QCI5優(yōu)先級最高，用于IMS（SIP）信令的默認(rèn)承載；QCI1-4其次，可用于VoLTE語音和視頻通話；QCI6-9優(yōu)先級最低，只能“盡力而為”保障數(shù)據(jù)傳輸。

具體流程如下。

EPS附著和QCI9默認(rèn)承載建立

1、2、3、4、5：UE向MME發(fā)送附著請求（Attach Request）后，MME與HSS對UE進(jìn)行鑒權(quán)，并在鑒權(quán)通過后，MME向HSS獲取UE的簽約數(shù)據(jù)。

6、7、8、9：MME根據(jù)用戶簽約數(shù)據(jù)中的默認(rèn)APN和PDN簽約上下文，通過Create Session Request消息向SGW/PGW請求建立EPC默認(rèn)承載（QCI一般為9），SGW/PGW向PCRF發(fā)送Credit-Control-Request（CCR） 為默認(rèn)承載請求PCC策略，PCRF根據(jù)接收到的用戶簽約數(shù)據(jù)確定PCC策略，并通過Credit-Control-Answer（CCA）響應(yīng)，隨后SGW/PGW向MME發(fā)送Create Session Response完成GTP-C會話創(chuàng)建過程。

10、11：MME向UE發(fā)送 Attach Accept，并請求激活默認(rèn)EPS承載；UE通過Attach Complete消息通知MME默認(rèn)EPS承載已激活。

此時，UE完成EPS附著并建立QCI9默認(rèn)承載。

QCI5承載建立

12、13、14、15、16：UE向MME發(fā)送PDN Connectivity Request，MME向 SGW/PGW發(fā)送Create Session Request請求建立QCI5默認(rèn)承載，SGW/PGW向PCRF發(fā)送CCR為默認(rèn)承載請求PCC策略，PCRF通過CCA響應(yīng)后，SGW/PGW向MME發(fā)送Create Session Response。

17、18：MME向UE發(fā)送Activate Default EPS Bearer Context Request激活默認(rèn)EPS承載，UE響應(yīng)Activate Default EPS Bearer Context Accept消息通知MME默認(rèn)EPS承載已被激活。

此時，UE和IMS APN之間建立了QCI值為5的默認(rèn)EPS承載，接下來，所有SIP信令流量將通過QCI5承載。

IMS注冊

19、20、21：UE通過向P-CSCF發(fā)送SIP REGISTER發(fā)起IMS注冊，I-CSCF向HSS發(fā)送User-Authorization-Request（UAR） 執(zhí)行用戶注冊狀態(tài)查詢，HSS授權(quán)用戶使用IMS服務(wù)后，在User-Authorization-Answer（UAA）響應(yīng)中返回該用戶的S-CSCF地址。

22、23、24、25、26：I-CSCF將SIP REGISTER轉(zhuǎn)發(fā)給指定的S-CSCF，S-CSCF向HSS發(fā)送Multimedia-Auth-Request（MAR）請求鑒權(quán)信息，HSS通過Multimedia-Auth-Answer（MAA）響應(yīng)后， S-CSCF通過401 UnAuthorized消息將鑒權(quán)信息發(fā)送至UE，以完成UE對網(wǎng)絡(luò)側(cè)鑒權(quán)。

27、28、29、30、31、32、33：UE向IMS發(fā)起第二次注冊請求和響應(yīng)流程，以完成網(wǎng)絡(luò)側(cè)對UE鑒權(quán)，并下載用戶IMS簽約數(shù)據(jù)。詳細(xì)步驟與第一次注冊類似。

對比信令追蹤和VoLTE注冊流程，此次VoLTE語音故障原因可能發(fā)生在CSCF與HSS之間，以及S/PGW與PCRF之間。（如信令流程圖中的紅星標(biāo)識）

對比KDDI故障簡報，其提到的“VoLTE交換機(jī)”可能是CSCF網(wǎng)元，而“用戶數(shù)據(jù)庫”可能是HSS網(wǎng)元，或者HSS與PCRF融合網(wǎng)元。

CSCF，Call Session Control Function，IMS網(wǎng)絡(luò)架構(gòu)中關(guān)鍵網(wǎng)元實(shí)體功能，其按位置和功能又分為P/S/I三種類型，其中，P-CSCF（Proxy CSCF）是IMS網(wǎng)絡(luò)的初始接入點(diǎn)，所有起始和終止于SIP終端的會話均通過P-CSCF；S-CSCF（Serving CSCF）在IMS核心網(wǎng)中處于核心控制地位，其配合HSS網(wǎng)元對用戶進(jìn)行鑒權(quán)，從HSS下載用戶簽約信息，并根據(jù)用戶簽約的IMS觸發(fā)規(guī)則進(jìn)行路由觸發(fā)和業(yè)務(wù)控制，以及管理基本會話路由；I-CSCF（Interrogating CSCF），IMS歸屬網(wǎng)絡(luò)的入口點(diǎn)，在注冊過程中I-CSCF通過查詢HSS為用戶選擇一個S-CSCF。

HSS，Home Subscriber Server，歸屬用戶服務(wù)器，存儲并管理用戶簽約數(shù)據(jù)，包括用戶鑒權(quán)信息、位置信息及路由信息等。在VoLTE網(wǎng)絡(luò)架構(gòu)中，EPC HSS和IMS HSS可以融合部署。

PCRF，策略和計費(fèi)控制單元，用于用戶信息管理、PCC策略管理、PCC策略動態(tài)生成及事件觸發(fā)等差異化服務(wù)業(yè)務(wù)。

Diameter信令異常？

再來回顧KDDI故障簡報，有兩點(diǎn)值得關(guān)注。

1）KDDI在新聞發(fā)布會上表示，回退操作后，盡管有相當(dāng)多的用戶向“VoLTE交換機(jī)”發(fā)起重新連接，但這些用戶數(shù)量并不是KDDI總用戶數(shù)。同時，KDDI在全國范圍內(nèi)有18個“VoLTE交換機(jī)”，且相互冗余備份。KDDI也做過模擬測試，即使所有用戶發(fā)起重新連接，也不會引起VoLTE擁塞。因此，本次事故可能還潛伏著其他原因。

2）“VoLTE交換機(jī)”擁塞發(fā)生后，盡管實(shí)施了接入限制、流控控制、斷開部分PGW網(wǎng)元等措施，但“VoLTE交換機(jī)”和“用戶數(shù)據(jù)庫”的負(fù)荷并沒有得到充分緩解，直到故障持續(xù)2天多后，KDDI才進(jìn)一步發(fā)現(xiàn)其18臺“VoLTE交換機(jī)”中有6臺“VoLTE交換機(jī)”向“用戶數(shù)據(jù)庫”不斷發(fā)送“不必要的多余信令”。斷開這6臺“VoLTE交換機(jī)”后，其余“VoLTE交換機(jī)”和“用戶數(shù)據(jù)庫”的負(fù)載大幅降低到故障發(fā)生前的水平。

所謂”VoLTE交換機(jī)“不斷向”用戶數(shù)據(jù)“發(fā)送”不必要的多余信令“，即CSCF網(wǎng)元不斷向HSS（或者HSS與PCRF融合網(wǎng)元）發(fā)送異常信令。

在4G網(wǎng)絡(luò)架構(gòu)中，I/S-CSCF與HSS之間的為Cx接口，采用Diameter信令。

Diameter 信令主要應(yīng)用于EPC系統(tǒng)、策略及計費(fèi)控制PCC系統(tǒng)和IMS域，主要用于用戶鑒權(quán)、數(shù)據(jù)、策略、計費(fèi)管理等。

EPC、PCC、IMS網(wǎng)絡(luò)中使用Diameter信令的網(wǎng)元和接口包括：I/S-CSCF 與 HSS 之間的接口、PCRF與PGW之間的Gx接口、HSS與MME之間的S6a接口等。

而從前文分析看，本次事故的故障點(diǎn)均發(fā)生在與Diameter信令相關(guān)的接口和網(wǎng)元。

因此，懷疑此次事故還潛伏著一個重要故障：Diameter信令網(wǎng)異常。

當(dāng)然，以上只是基于一些碎片信息的不成熟分析，具體原因只能等待KDDI公布詳細(xì)報告。再次重申，由于技術(shù)水平有限，如有不當(dāng)之處，請各位在留言區(qū)指出。

審核編輯 ：李倩