?幾天前發生的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公布詳細報告。?