開機(jī)的狀態(tài)欄一直卡在“正在激活數(shù)據(jù)連接”等了一分多鐘沒動(dòng)靜用戶以為卡槽接觸不良重啟一下又好了。這種反饋在現(xiàn)網(wǎng)排障里出現(xiàn)的頻率比想象中高真把信令拉出來看十有八九是一條 ATTACH REJECT 里帶著EMM cause #19ESM failure緊接著終端就徹底安靜了整整十二分鐘期間不發(fā)起任何附著、不發(fā)起任何路由區(qū)更新直到一個(gè)叫T3402的定時(shí)器走完才重新探頭。很多人第一次看到這段 log 會(huì)以為是終端掛了、協(xié)議棧死循環(huán)了其實(shí)終端活得好好的它只是被規(guī)范要求“閉嘴”十二分鐘。這篇內(nèi)容想聊的就是這條鏈路EMM cause #19 為什么會(huì)讓終端進(jìn)入 T3402 的長靜默期、這十二分鐘里終端到底做了什么、排障時(shí)怎么把定時(shí)器的起止點(diǎn)從 log 里釘死、以及網(wǎng)絡(luò)側(cè)在什么情況下才會(huì)選擇丟 #19 而不是回一條普通的 ESM 拒絕。寫給正在做終端協(xié)議棧、網(wǎng)絡(luò)側(cè)核心網(wǎng)優(yōu)化、或者現(xiàn)場(chǎng)支撐無線數(shù)據(jù)業(yè)務(wù)的人看基礎(chǔ)一點(diǎn)的讀者也能從中拿到一份“看到這個(gè) cause 該怎么往下查”的路線圖。1. 一條 ATTACH REJECT 之后那十二分鐘終端到底在干什么1.1 cause #19 的語義ESM 層失敗被抬到了 EMM 層要理解 T3402得先把 #19 這個(gè) cause 的語義掰開。LTE 的 NAS 協(xié)議分成兩層EMM 管移動(dòng)性和注冊(cè)附著、去附著、TAU、鑒權(quán)、安全ESM 管承載和會(huì)話PDN 連接建立、默認(rèn)承載、專用承載。平時(shí)這兩個(gè)層次各管各的ESM 層出錯(cuò)就走 ESM 的拒絕消息帶上 ESM cause比如“缺少或未知的 APN”“資源不足”“服務(wù)網(wǎng)關(guān)或 PDN 網(wǎng)關(guān)拒絕請(qǐng)求”這些終端收到之后只影響這一條 PDN已經(jīng)注冊(cè)上的其他業(yè)務(wù)不受牽連。#19 ESM failure的特殊之處在于它是用 EMM 層的話筒說出 ESM 層的事故。網(wǎng)絡(luò)側(cè)在附著流程里發(fā)現(xiàn)默認(rèn)承載建不起來本來可以只回一條 PDN CONNECTIVITY REJECT 了事但它選擇了更重的手段直接一條 ATTACH REJECTcause 填 0x13也就是十進(jìn)制 19。這一條消息發(fā)出去終端收到的信號(hào)不是“這個(gè) APN 有問題”而是“你這次附著整體失敗了而且失敗原因在會(huì)話層我沒法告訴你什么時(shí)候能好”。從十進(jìn)制 19 這個(gè)編碼本身看不出情緒但它在整張 cause 表里的位置很特殊。它不像 #11PLMN 不允許那樣把終端趕進(jìn)禁用名單也不像 #22擁塞那樣明說“我等會(huì)兒再來”它給的是一種模糊的、指向網(wǎng)絡(luò)內(nèi)部故障的結(jié)論。正因?yàn)槟：K端只能采取最保守的策略——把注冊(cè)狀態(tài)整體回退然后拉起一個(gè)足夠長的定時(shí)器等網(wǎng)絡(luò)自己緩過來。這個(gè)保守策略的執(zhí)行者就是 T3402?，F(xiàn)場(chǎng)判斷時(shí)有個(gè)很實(shí)用的分辨點(diǎn)ATTACH REJECT 里帶的是 EMM causePDN CONNECTIVITY REJECT 里帶的是 ESM cause兩者在 log 里的消息名完全不同但 cause 數(shù)值可能撞車比如都出現(xiàn) 26、27 這種數(shù)字?？?log 時(shí)如果不確認(rèn)消息類型光看 cause 數(shù)字非常容易誤判成 #19 場(chǎng)景。我見過有同事把 ATTACH ACCEPT 之后跟著的一條 ESM 拒絕當(dāng)成 #19從而錯(cuò)誤地認(rèn)為終端該起 T3402結(jié)果對(duì)著 log 找了半天沒找到定時(shí)器啟動(dòng)點(diǎn)。1.2 收到 #19 的一瞬間終端改了四筆賬并起了一個(gè)表終端收到攜帶 #19 的 ATTACH REJECT 之后動(dòng)作是一連串的不是單一動(dòng)作。按規(guī)范的處理邏輯它大致要完成這么幾件事我按重要性從高到低排第一筆賬是EPS update status 置為 EU3ROAMING NOT ALLOWED。這個(gè)狀態(tài)存在 USIM 的 EPS 位置信息文件里值 3 表示“未更新且漫游不允許”。它會(huì)影響終端后續(xù)對(duì)網(wǎng)絡(luò)選擇的判斷邏輯不是簡單的一個(gè)標(biāo)志位。第二筆賬是刪掉網(wǎng)絡(luò)分配的臨時(shí)身份和位置信息包括 GUTI全球唯一臨時(shí)標(biāo)識(shí)、最近訪問的注冊(cè)跟蹤區(qū)、跟蹤區(qū)列表。這一刪很關(guān)鍵意味著下次附著要從 IMSI 附著重新走一遍鑒權(quán)和加密流程都得重來沒法再用臨時(shí)身份省事。第三筆賬是清空等價(jià) PLMN 列表。這一條經(jīng)常被忽略但它直接決定了“換個(gè)地方能不能立刻好”后面第 5 節(jié)會(huì)展開。第四筆賬是把 EMM 狀態(tài)退回 DEREGISTERED同時(shí)把附著嘗試計(jì)數(shù)器清零。注意這里是清零而不是加一因?yàn)?#19 不是“嘗試失敗了一次”而是“這次嘗試的失敗性質(zhì)決定了不用再試”。做完這些之后終端啟動(dòng)T3402。這個(gè)定時(shí)器在規(guī)范里給的值是12 分鐘固定值不像 T3346 那樣由網(wǎng)絡(luò)通過消息里的定時(shí)器 IE 動(dòng)態(tài)下發(fā)也不像 T3396 那樣分場(chǎng)景給不同長度。它就是一個(gè)常量。定時(shí)器跑起來之后終端進(jìn)入一種“冷處理”狀態(tài)不再發(fā)起普通的附著、不再發(fā)起跟蹤區(qū)更新也不會(huì)去嘗試重建 PDN 連接因?yàn)樗B注冊(cè)都沒了沒有可重建的對(duì)象。有一點(diǎn)容易搞混T3402 的啟動(dòng)并不等于終端徹底停止所有無線行為。小區(qū)測(cè)量、重選、系統(tǒng)消息接收這些照常進(jìn)行射頻也沒有關(guān)。所以從外部看終端“還在網(wǎng)上”但它不會(huì)向網(wǎng)絡(luò)發(fā)任何注冊(cè)類請(qǐng)求。這就是為什么有些測(cè)試儀表上看不到終端有任何動(dòng)作會(huì)誤判成終端把協(xié)議棧卡死了。1.3 用戶側(cè)的表現(xiàn)為什么是“過一會(huì)兒自己好了”把這套機(jī)制翻譯成用戶語言就是開機(jī) → 附著 → 被拒原因不明→ 十二分鐘不理網(wǎng)絡(luò) → 突然自己好了。這個(gè)體驗(yàn)非常具有迷惑性因?yàn)橹虚g沒有任何提示狀態(tài)欄可能顯示 4G 圖標(biāo)射頻注冊(cè)在小區(qū)上是成功的只是 NAS 層沒注冊(cè)上用戶會(huì)以為“有信號(hào)但網(wǎng)卡了”然后不斷開關(guān)飛行模式。這里有個(gè)非常重要的現(xiàn)場(chǎng)細(xì)節(jié)開關(guān)飛行模式或者重啟往往能讓它立刻恢復(fù)。原因不是“重啟修復(fù)了問題”而是 T3402 的運(yùn)行狀態(tài)不跨斷電保存重啟后定時(shí)器沒了終端會(huì)立刻重新發(fā)起一次附著這時(shí)候如果網(wǎng)絡(luò)側(cè)的臨時(shí)故障剛好過去了就成功了。這個(gè)現(xiàn)象在網(wǎng)絡(luò)側(cè)故障是間歇性的時(shí)候特別明顯也是造成“用戶說重啟就好、你去看的時(shí)候一切正?！边@種扯皮局面的根本原因。反過來如果網(wǎng)絡(luò)側(cè)故障是持續(xù)性的比如 APN 配置錯(cuò)了、簽約數(shù)據(jù)缺了重啟會(huì)立刻再被拒一次用戶就會(huì)覺得“重啟也沒用”。這兩種表現(xiàn)背后其實(shí)是同一套機(jī)制只是網(wǎng)絡(luò)側(cè)狀態(tài)不同。分辨這兩種情況看 log 里的時(shí)間戳就夠如果兩次 ATTACH REJECT 之間的間隔是幾秒到幾十秒說明是重啟觸發(fā)的如果間隔精確到 720 秒左右說明是 T3402 正常到期。從用戶抱怨的分布看還有一類表現(xiàn)是“每天早上第一次上網(wǎng)特別慢要等十幾分鐘”。這種情況往往不是 T3402而是終端在夜間待機(jī)時(shí)被網(wǎng)絡(luò)隱式去附著早上喚醒后重新附著失敗了幾次累計(jì)到附著嘗試計(jì)數(shù)器上限才啟動(dòng) T3402?？雌饋硐裢粋€(gè)現(xiàn)象實(shí)際走的路徑完全不同第 2 節(jié)會(huì)把這兩條路徑對(duì)比清楚。2. 把 #19 放到 cause 家族里對(duì)比才知道它有多“重”2.1 同樣是拒絕#22 只讓終端等幾秒#19 要等十二分鐘單看 #19 沒什么感覺把它和其他常見 cause 擺在一起輕重立現(xiàn)。我整理了一張自己排障時(shí)常用的對(duì)照表覆蓋了 ATTACH REJECT 和 TAU REJECT 場(chǎng)景里出現(xiàn)頻率最高的幾個(gè) causeEMM cause語義終端主要?jiǎng)幼麝P(guān)聯(lián)定時(shí)器典型時(shí)長#19ESM failure清 GUTI/TAI 列表/ePLMN、狀態(tài)置 EU3、回 DEREGISTEREDT340212 分鐘#22Congestion保持當(dāng)前部分狀態(tài)等待后重試T3346由網(wǎng)絡(luò)下發(fā)常見幾十秒到幾分鐘#15No suitable cells in TA把該 TA 加入禁用列表T344224 分鐘#11PLMN not allowed該 PLMN 加入禁用列表無直到手動(dòng)選網(wǎng)或換卡#12Tracking area not allowed該 TA 加入禁用列表無同上#14EPS services not allowed視為 USIM 對(duì)該網(wǎng)絡(luò)無效無需換網(wǎng)或換卡#25CS domain not available僅影響 CS 回落相關(guān)無不阻斷 PS從這張表能看出一個(gè)規(guī)律cause 越“模糊”定時(shí)器越長。#11、#12 這類原因明確的終端直接拉黑名單不需要定時(shí)器等#22 這種明確說“我忙”的等一小會(huì)兒就行而 #19 說的是“會(huì)話層失敗了具體為什么我不告訴你”終端只能猜網(wǎng)絡(luò)需要多久恢復(fù)于是給了 12 分鐘這個(gè)相當(dāng)長的保守值。還有一個(gè)容易被忽略的差別#19 是立即啟動(dòng) T3402而其他很多失敗是要累計(jì)到 5 次才啟動(dòng)。規(guī)范里對(duì)附著嘗試計(jì)數(shù)器有明確上限連續(xù)失敗達(dá)到 5 次之后終端才會(huì)清身份信息并啟動(dòng) T3402。#19 跳過了這個(gè)累計(jì)過程一次就把終端打進(jìn)長靜默。這意味著在網(wǎng)絡(luò)側(cè)偶發(fā)故障的場(chǎng)景里如果 MME 選擇用 #19 而不是讓終端多試幾次用戶體驗(yàn)的損失會(huì)被放大好幾倍——本來試第三次就成功的附著被 #19 一搞直接變成等十二分鐘。這是網(wǎng)絡(luò)側(cè)參數(shù)選擇上很值得權(quán)衡的一個(gè)點(diǎn)第 4 節(jié)會(huì)詳細(xì)說。2.2 T3402 取值 12 分鐘的由來以及為什么不做隨機(jī)化12 分鐘這個(gè)數(shù)字不是拍腦袋定的它背后是一個(gè)挺典型的工程權(quán)衡。設(shè)想核心網(wǎng)某個(gè)網(wǎng)元出現(xiàn)短時(shí)故障如果所有終端都在幾秒內(nèi)瘋狂重試信令面會(huì)瞬間被淹沒本來就 congestion 的網(wǎng)元會(huì)被徹底壓垮恢復(fù)時(shí)間被無限拉長。反過來如果定時(shí)器設(shè)得太長比如半小時(shí)那么網(wǎng)絡(luò)已經(jīng)恢復(fù)了終端還在那兒干等用戶感知直接崩掉。12 分鐘大致落在“給網(wǎng)絡(luò)留出恢復(fù)窗口”和“用戶還能忍”這兩條線的交集上。有意思的是這個(gè)定時(shí)器沒有做隨機(jī)化。規(guī)范給的是固定值理論上如果一批終端在同一時(shí)刻被同一臺(tái) MME 拒絕它們會(huì)在同一時(shí)刻到期、同一時(shí)刻發(fā)起附著形成一個(gè)整齊的尖峰。在實(shí)際網(wǎng)絡(luò)里我確實(shí)觀察到過這種同步重試的現(xiàn)象一批物聯(lián)網(wǎng)模組在同一小區(qū)幾乎同時(shí)上線被拒之后又在 720 秒后幾乎同時(shí)發(fā)起對(duì)基站來說那一瞬間的接入請(qǐng)求是密集的。有些終端實(shí)現(xiàn)會(huì)在到期后疊加一段隨機(jī)的短延遲來打散這個(gè)尖峰這屬于實(shí)現(xiàn)層面的取舍規(guī)范里并沒有這個(gè)要求。做終端測(cè)試的時(shí)候如果發(fā)現(xiàn)某款設(shè)備到期后不是精確的 720 秒而是 720 加幾十秒先別急著判 bug有可能是故意加的抖動(dòng)。判斷方法很簡單連續(xù)測(cè)多次如果是固定偏移就說明是設(shè)計(jì)如此如果是每次都不一樣且離散度大那才可能是計(jì)時(shí)精度問題。另外提一句 2G/3G 體系的對(duì)應(yīng)關(guān)系方便做跨制式排障的人對(duì)照。老體系里也有類似的重試抑制機(jī)制量級(jí)同樣是十分鐘上下觸發(fā)條件也包含“網(wǎng)絡(luò)側(cè)無法建立 PDP 上下文”這類場(chǎng)景。所以當(dāng)你看到一個(gè)多模終端在 LTE 上被拒、切到 3G 之后又安靜很久很可能不是兩個(gè)獨(dú)立的故障而是兩套機(jī)制在各自生效。2.3 三種最容易被誤認(rèn)成 #19 的現(xiàn)場(chǎng)排障中最耗時(shí)間的往往不是定位問題而是先要排除“看起來像但不是”的情況。我列三個(gè)踩過的坑第一種把 ESM 拒絕當(dāng)成 #19。ATTACH ACCEPT 之后緊跟一條 PDN CONNECTIVITY REJECTcause 是 ESM 層的“資源不足”或者“未知 APN”終端會(huì)走 ESM 層的退避邏輯可能帶一個(gè)網(wǎng)絡(luò)下發(fā)的定時(shí)器值不會(huì)啟動(dòng) T3402。表面上都是“附著之后上不了網(wǎng)”但終端的行為完全不同這種情況終端保持已注冊(cè)可以重試其他 APN而 #19 是徹底回到未注冊(cè)。log 里一條看消息名就能區(qū)分別只看 cause 數(shù)值。第二種把附著嘗試計(jì)數(shù)器耗盡當(dāng)成 #19。終端連續(xù)附著失敗 5 次第 5 次之后清身份、起 T3402。從終端的最終狀態(tài)看和 #19 一模一樣都是清 GUTI 加 12 分鐘靜默。區(qū)別在時(shí)間軸這種情況前面會(huì)有 4 次失敗的 REJECT間隔通常是幾十秒量級(jí)可能有 T3411 之類的短定時(shí)器介入而 #19 是一次到位。把前面幾條消息翻出來看如果 reject 的 cause 是 #22 或者其他值那這就是累計(jì)失敗不是 #19 直接觸發(fā)。第三種把網(wǎng)絡(luò)側(cè)的隱式去附著當(dāng)成 #19。終端從待機(jī)喚醒后發(fā)現(xiàn)被隱式去附著重新發(fā)起附著又被拒如果拒的 cause 恰好是 #19 就會(huì)同時(shí)出現(xiàn)兩個(gè)現(xiàn)象。這種場(chǎng)景下用戶感知是“待機(jī)久了就上不了網(wǎng)”和純粹的 #19 場(chǎng)景開機(jī)即失敗在時(shí)間特征上不一樣。判斷方法是看第一條 ATTACH REQUEST 之前有沒有一段長時(shí)間的靜默以及有沒有 Detach Request/Accept 或者尋呼未響應(yīng)的記錄。這三種情況的共同點(diǎn)是只看終端最終狀態(tài)都會(huì)得到“12 分鐘靜默”這個(gè)結(jié)論但根因和修復(fù)方向完全不同。我在排查時(shí)養(yǎng)成的習(xí)慣是無論現(xiàn)象多像都先把 T3402 啟動(dòng)點(diǎn)之前的那 30 秒信令完整拉出來看一遍確認(rèn)最后一條驅(qū)動(dòng)消息到底是哪一條。這一步花兩分鐘能省掉后面兩個(gè)小時(shí)的瞎猜。3. 排障時(shí)怎么把 T3402 的起止時(shí)間釘死3.1 只在 NAS 層看是不夠的三層信令要對(duì)著看很多人排這類問題只抓終端的 NAS 消息能看到 ATTACH REJECT 和 cause但看不到“為什么被拒”。原因很簡單NAS 消息是終端和 MME 之間的對(duì)話MME 拒絕終端的時(shí)候它自己往往只是在轉(zhuǎn)發(fā)一個(gè)更底層的失敗。真正的根因通常在 S1 接口之外也就是 MME 和網(wǎng)關(guān)之間的會(huì)話建立過程。我一般的抓取范圍是三層空口側(cè) NAS 消息確認(rèn) reject 的類型、cause 值、時(shí)間戳以及后續(xù)終端有沒有異常動(dòng)作。S1 接口信令看整個(gè)附著流程走到哪一步斷的。正常的附著流程是Attach Request → Identity/Authentication → Security Mode → Update Location → Create Session → Initial Context Setup → Attach Accept。如果斷在 Create Session 之后那問題基本鎖定在核心網(wǎng)側(cè)。S5/S8 接口的會(huì)話消息看 Create Session Response 里攜帶的原因值這是最接近根因的一層。三層對(duì)著看的好處是能把“終端看到的現(xiàn)象”和“網(wǎng)絡(luò)內(nèi)部的真相”串成一條線。我見過一個(gè)案例終端側(cè)看到的是 #19S1 上看到 Create Session 請(qǐng)求發(fā)出去了但沒等到響應(yīng)S5/S8 上看到對(duì)端設(shè)備壓根沒回——三層信息拼起來根因是會(huì)話網(wǎng)關(guān)側(cè)的一個(gè)地址解析問題和終端毫無關(guān)系。如果只看終端 log可能會(huì)一直懷疑終端定時(shí)器實(shí)現(xiàn)有問題。3.2 用 720 秒做標(biāo)尺幾種典型的時(shí)間偏差說明什么T3402 是個(gè)固定值這就給了排障一個(gè)非常好用的標(biāo)尺從 ATTACH REJECT 的時(shí)間戳往后推 720 秒看終端是不是在這個(gè)點(diǎn)附近發(fā)起下一次附著。偏差的類型直接指向不同的問題層面。觀察到的間隔可能原因排查方向約 720 秒±幾秒定時(shí)器正常工作問題在網(wǎng)絡(luò)側(cè)查為什么被拒遠(yuǎn)小于 720 秒幾秒到幾十秒有事件提前解鎖了定時(shí)器檢查期間是否有 PLMN 變化、飛行模式、USIM 重插遠(yuǎn)小于 720 秒且多次重復(fù)定時(shí)器未生效或?qū)崿F(xiàn)缺陷確認(rèn)是否真的收到 #19檢查協(xié)議棧狀態(tài)機(jī)720 秒到 1200 秒之間跨睡眠計(jì)時(shí)漂移查待機(jī)場(chǎng)景下的計(jì)時(shí)補(bǔ)償實(shí)現(xiàn)超過 1200 秒甚至不發(fā)起被其他禁用列表擋住查禁用 PLMN、禁用 TA 列表狀態(tài)第三行那種“幾秒就重試”的情況要特別警惕。這不一定就是 bug很可能終端在等待期間又收到了新的觸發(fā)條件比如小區(qū)重選到了一個(gè)不屬于等價(jià) PLMN 列表的新 PLMN。因?yàn)?#19 會(huì)把等價(jià) PLMN 列表清掉原來那些“不算換了網(wǎng)”的鄰區(qū)現(xiàn)在都算新網(wǎng)了終端會(huì)提前解鎖。這個(gè)機(jī)制是規(guī)范要求的設(shè)計(jì)上合理但在排障時(shí)容易誤導(dǎo)人。第四行的漂移問題在物聯(lián)網(wǎng)設(shè)備上尤其常見。這些設(shè)備大量時(shí)間在待機(jī)協(xié)議棧的定時(shí)器如果基于某種會(huì)隨睡眠暫停的計(jì)數(shù)源實(shí)現(xiàn)實(shí)際經(jīng)過的時(shí)間就會(huì)被拉長。有些平臺(tái)會(huì)用真實(shí)時(shí)鐘戳做補(bǔ)償醒來后一次性把欠的時(shí)間補(bǔ)上這種情況下 720 秒還是準(zhǔn)的。有些平臺(tái)沒做補(bǔ)償就會(huì)看到 15 分鐘、20 分鐘這樣的結(jié)果。這屬于實(shí)現(xiàn)質(zhì)量問題需要終端側(cè)確認(rèn)。3.3 一次完整排查鏈路的復(fù)盤說個(gè)具體的分析過程把前面的方法串起來。現(xiàn)象是某類終端在某個(gè)區(qū)域反復(fù)出現(xiàn)“開機(jī)后長時(shí)間無法上網(wǎng)”重啟能恢復(fù)但不重啟的話要等十幾分鐘。第一步抓終端 NAS 日志。確認(rèn)每次失敗的驅(qū)動(dòng)消息都是 ATTACH REJECTcause 值為 0x13也就是 #19。并且確認(rèn)了 REJECT 之后終端確實(shí)沒有再發(fā)任何 ATTACH REQUEST直到約 720 秒后才重發(fā)。這一步排除了“協(xié)議?？ㄋ馈钡牟聹y(cè)坐實(shí)了 T3402 在正常工作。第二步看 S1 接口。發(fā)現(xiàn)附著流程走到 Create Session 這一步MME 向網(wǎng)關(guān)發(fā)了會(huì)話建立請(qǐng)求但返回的是失敗響應(yīng)隨后 MME 才組了 ATTACH REJECT 回給終端。這就把責(zé)任從終端排除了問題在核心網(wǎng)側(cè)。第三步看 S5/S8 的會(huì)話響應(yīng)里的原因值。這一步是關(guān)鍵得到的值指向“資源不可用”這一類。再往上游查發(fā)現(xiàn)是某個(gè)地址池在特定時(shí)段被耗盡新接入的終端拿不到地址網(wǎng)關(guān)直接回了資源不可用的原因。第四步驗(yàn)證。在地址池耗盡的時(shí)間窗內(nèi)做定點(diǎn)測(cè)試能穩(wěn)定復(fù)現(xiàn)在非高峰時(shí)段測(cè)試復(fù)現(xiàn)率極低。同時(shí)觀察到一個(gè)細(xì)節(jié)同樣的網(wǎng)絡(luò)條件下不同終端的行為不完全一樣——有些終端拿到的是 #19有些拿到的是 ATTACH ACCEPT 加 ESM 拒絕這說明 MME 對(duì)不同終端的處理路徑有差異下一節(jié)會(huì)講原因。第五步修復(fù)與回歸。網(wǎng)絡(luò)側(cè)擴(kuò)容地址池之后復(fù)測(cè)附著成功率恢復(fù)正常T3402 不再被觸發(fā)。整個(gè)鏈路從現(xiàn)象到根因大概用了兩天其中大部分時(shí)間花在協(xié)調(diào)多方同時(shí)抓包和對(duì)齊時(shí)間戳上真正定位的過程其實(shí)不長。這次排查給我最大的教訓(xùn)是#19 這個(gè)名字有很強(qiáng)的誤導(dǎo)性。它叫 ESM failure會(huì)讓人下意識(shí)地去查會(huì)話層的配置但實(shí)際根因可能在更上游的資源分配。排障時(shí)不能被 cause 的命名帶著走得順著信令一層層往下鉆。4. 網(wǎng)絡(luò)側(cè)為什么選擇丟 #19 而不是回 ESM reject4.1 MME 的兩條岔路拒整次附著還是只拒這個(gè) PDN這是整個(gè)話題里最值得深挖的一點(diǎn)。當(dāng)終端在 ATTACH REQUEST 里同時(shí)帶了 PDN 連接建立請(qǐng)求而這個(gè) PDN 建不起來的時(shí)候MME 面前有兩條路第一條路回 ATTACH ACCEPT只做 EPS 附著 PDN CONNECTIVITY REJECT帶 ESM cause。這樣終端注冊(cè)成功了拿到了 GUTI只是這個(gè) PDN 沒建起來。終端可以保持注冊(cè)狀態(tài)嘗試其他 APN或者過一段時(shí)間重試這個(gè) PDN重試的節(jié)奏由 ESM 層的退避機(jī)制控制通常比 12 分鐘短得多。對(duì)用戶來說最壞情況是某些應(yīng)用上不了網(wǎng)但基礎(chǔ)的注冊(cè)、語音回落這些還是正常的。第二條路回 ATTACH REJECT #19。終端整個(gè)回到未注冊(cè)接受 12 分鐘靜默。用戶的體感是從“部分功能不可用”變成“完全不可用”。規(guī)范允許兩種做法選擇權(quán)在 MME。實(shí)際操作中不同網(wǎng)絡(luò)設(shè)備廠商、不同運(yùn)營策略下選擇不一樣。我見過的場(chǎng)景里選擇 #19 的情況大致有幾類一是網(wǎng)絡(luò)側(cè)配置為不允許“僅 EPS 附著”也就是沒有默認(rèn)承載就不讓注冊(cè)二是簽約數(shù)據(jù)里沒有該 APN 的授權(quán)MME 認(rèn)為這不是臨時(shí)故障讓終端等也沒意義三是 MME 在會(huì)話建立失敗后拿不到足夠的信息判斷該回哪個(gè) ESM cause索性回一個(gè)籠統(tǒng)的 #19。站在用戶體驗(yàn)的角度第二條路的代價(jià)明顯更大。所以做網(wǎng)絡(luò)側(cè)參數(shù)優(yōu)化的時(shí)候如果發(fā)現(xiàn)某類失敗被頻繁映射成 #19值得評(píng)估一下能不能改成走第一條路。特別是那種“特定 APN 失敗但用戶其實(shí)還用著別的 APN”的多 APN 場(chǎng)景一次 #19 會(huì)把整個(gè)終端打癱十二分鐘損失被嚴(yán)重放大。4.2 S5/S8 上的 GTP cause 是怎么變成 #19 的從底層原因到 #19中間有一層映射關(guān)系理解這層映射對(duì)定位很有幫助。會(huì)話建立失敗時(shí)網(wǎng)關(guān)回的原因值大致有這幾類它們向上映射的路徑不同會(huì)話層原因含義常見上游問題向上映射傾向上下文未找到網(wǎng)關(guān)側(cè)沒有該 APN 的上下文簽約缺失、APN 配置不一致可能映射為 #19資源不可用地址池耗盡、承載資源不足容量規(guī)劃不足可能映射為 #19 或 ESM 資源不足缺少或未知 APNAPN 名字對(duì)不上終端配置與網(wǎng)絡(luò)配置不一致通常映射為 ESM 層 APN 錯(cuò)誤請(qǐng)求被拒絕策略側(cè)拒絕策略配置沖突視策略而定對(duì)端無響應(yīng)超時(shí)鏈路問題、對(duì)端設(shè)備異?？赡苡成錇?#19系統(tǒng)故障內(nèi)部錯(cuò)誤軟件異?？赡苡成錇?#19規(guī)律大致是原因越“不知道該怎么辦”越容易被映射成 #19。因?yàn)?#19 本質(zhì)上是一個(gè)“我這邊出問題了但說不清具體是什么”的表達(dá)。而原因明確、能對(duì)應(yīng)到具體 ESM cause 的比如 APN 名字錯(cuò)了MME 更傾向于走 ESM 拒絕讓終端知道該改配置。這個(gè)規(guī)律對(duì)排障有實(shí)際指導(dǎo)意義如果問題是穩(wěn)定復(fù)現(xiàn)的往往對(duì)應(yīng)的是配置類錯(cuò)誤可能走的是 ESM 路徑如果是間歇性的、時(shí)段性的更容易看到 #19。因?yàn)殚g歇性故障超時(shí)、資源競爭恰恰是“說不清”的那一類。我在現(xiàn)場(chǎng)遇到 #19 時(shí)的第一反應(yīng)就是去查時(shí)段分布看看是不是和某個(gè)高峰時(shí)間吻合。還有一層細(xì)節(jié)MME 在決定映射方式時(shí)還會(huì)考慮終端在 ATTACH REQUEST 里帶的 PDN 連接請(qǐng)求是不是“唯一的”請(qǐng)求。如果終端只請(qǐng)求了一個(gè) PDN而這個(gè) PDN 失敗MME 傾向于認(rèn)為整個(gè)附著沒有意義回 #19 更直接如果終端請(qǐng)求了多個(gè)雖然 LTE 附著階段通常只帶一個(gè)或者網(wǎng)絡(luò)知道終端還有別的業(yè)務(wù)需求走 ESM 拒絕的動(dòng)機(jī)就強(qiáng)一些。4.3 簽約、APN、地址池三個(gè)高發(fā)源頭從根因分布看#19 的來源高度集中在三塊實(shí)際排障時(shí)可以按這個(gè)順序查簽約數(shù)據(jù)問題排第一。用戶開了某個(gè) APN 的業(yè)務(wù)但簽約數(shù)據(jù)沒有同步到歸屬服務(wù)器或者同步了但 MME 緩存的是舊版本。這種情況下MME 在會(huì)話建立時(shí)發(fā)現(xiàn)本地沒有對(duì)應(yīng)的簽約信息會(huì)話建立直接失敗映射成 #19 的可能性很高。特征是換一張卡在同一位置正常或者同一個(gè)用戶換到別的 MME 覆蓋區(qū)正常。這種“跟人走而不跟位置走”的特征是簽約類問題最典型的標(biāo)志。APN 配置不一致排第二。終端側(cè)配置的 APN 名字、鑒權(quán)方式、IP 類型和網(wǎng)絡(luò)側(cè)預(yù)期的不一致。這種情況下起因很明確理論上應(yīng)該映射成 ESM 層的 APN 錯(cuò)誤但實(shí)際中如果 MME 沒有做精細(xì)映射也可能籠統(tǒng)地回 #19。特征是特定型號(hào)終端或特定配置的終端出問題其他終端正常。這種“跟終端走”的特征和簽約問題正好相反很好區(qū)分。地址池耗盡排第三也是最容易被忽略的。它的特征是時(shí)段性極強(qiáng)忙時(shí)出問題、閑時(shí)正常而且往往影響面廣、不分終端型號(hào)。這類問題在物聯(lián)網(wǎng)場(chǎng)景里特別常見因?yàn)槲锫?lián)網(wǎng)設(shè)備大量集中在某些時(shí)段上線比如深夜批量抄表瞬時(shí)并發(fā)遠(yuǎn)高于人網(wǎng)。我遇到過一次某區(qū)域每天晚上固定時(shí)段出現(xiàn)批量 #19查了兩天才定位到地址池容量。除了這三塊還有一個(gè)隱性的第四類MME 與網(wǎng)關(guān)之間的鏈路或解析問題。這類問題最隱蔽因?yàn)樗情g歇性的出現(xiàn)在特定鏈路或特定網(wǎng)元組合上。特征是同一個(gè)用戶在移動(dòng)位置后可能恢復(fù)正常換了服務(wù)網(wǎng)元或者問題集中在某個(gè)時(shí)間段內(nèi)新增的會(huì)話上鏈路抖動(dòng)期間。這類問題往往需要多接口同時(shí)抓包才能定位單看某一層永遠(yuǎn)看不出問題。5. 終端實(shí)現(xiàn)里幾個(gè)容易翻車的細(xì)節(jié)5.1 定時(shí)器跨睡眠漂移與“十二分鐘變成二十分鐘”終端側(cè)實(shí)現(xiàn) T3402 時(shí)最實(shí)際的工程問題是計(jì)時(shí)源的選擇。如果協(xié)議棧用的是系統(tǒng) tick 計(jì)數(shù)而這個(gè) tick 在深度睡眠時(shí)被暫停那么實(shí)際經(jīng)過的物理時(shí)間就會(huì)遠(yuǎn)遠(yuǎn)超過 12 分鐘。這在手機(jī)上不太明顯屏幕亮著的時(shí)候不睡眠但在物聯(lián)網(wǎng)模組上非常突出。有些平臺(tái)的處理方式是在定時(shí)器啟動(dòng)時(shí)記一個(gè)真實(shí)時(shí)間戳喚醒后重新計(jì)算剩余時(shí)間有些平臺(tái)則簡單地讓 tick 停在那醒來后繼續(xù)數(shù)。后者就會(huì)出現(xiàn)前面表格里提到的漂移現(xiàn)象。判斷一款設(shè)備用的是哪種方式測(cè)法很簡單讓設(shè)備在被拒之后立刻進(jìn)入待機(jī)等 15 分鐘再喚醒看它是不是立刻發(fā)起附著。如果是說明用了時(shí)間戳補(bǔ)償如果還要再等好幾分鐘說明 tick 被暫停了。這個(gè)差異對(duì)用戶體驗(yàn)的影響不小。本來十二分鐘能恢復(fù)的業(yè)務(wù)變成二十分鐘甚至更久在需要定時(shí)上報(bào)的場(chǎng)景里會(huì)造成明顯的數(shù)據(jù)缺口。做終端選型或者問題定位時(shí)這一條值得專門測(cè)一次。還有一個(gè)更隱蔽的問題定時(shí)器被意外重置。有些實(shí)現(xiàn)在收到某些非相關(guān)消息時(shí)會(huì)把 T3402 重新計(jì)時(shí)導(dǎo)致它永遠(yuǎn)走不完。典型觸發(fā)是小區(qū)重選之后收到系統(tǒng)消息更新或者收到一條尋呼。這類問題在 log 里表現(xiàn)為明明應(yīng)該 720 秒到期但每次快到點(diǎn)的時(shí)候就“重新開始”實(shí)際永遠(yuǎn)恢復(fù)不了。判斷方法是看有沒有周期性的某個(gè)消息反復(fù)出現(xiàn)且每次出現(xiàn)后定時(shí)器剩余時(shí)間被拉滿。5.2 重啟能治好的原因以及它為什么是排障陷阱前面提過T3402 的運(yùn)行狀態(tài)不跨斷電保存。這個(gè)設(shè)計(jì)本身是合理的規(guī)范里 EMM 的很多上下文都不持久化只把必須保留的信息比如 GUTI、禁用列表寫進(jìn) USIM。終端重啟后從 USIM 讀出狀態(tài)發(fā)現(xiàn)沒有正在運(yùn)行的定時(shí)器就重新發(fā)起附著。這給現(xiàn)場(chǎng)排障帶來一個(gè)很麻煩的循環(huán)用戶報(bào)障 → 你去現(xiàn)場(chǎng) → 用戶說我重啟過了現(xiàn)在好了 → 你什么都抓不到 → 過兩天又報(bào)。要打破這個(gè)循環(huán)得讓用戶或者一線人員知道下次出問題時(shí)先別重啟直接抓 log 或者撥個(gè)診斷碼看狀態(tài)。我一般會(huì)給一線一份簡單的操作卡片寫清楚“出現(xiàn)無法上網(wǎng)時(shí)先別重啟保持現(xiàn)狀記錄時(shí)間點(diǎn)”這樣才有機(jī)會(huì)抓到現(xiàn)場(chǎng)。從另一個(gè)角度看重啟能恢復(fù)這個(gè)特性本身是有價(jià)值的信息。它說明問題不是永久性的否則重啟也沒用而是有時(shí)效的。結(jié)合 T3402 的 12 分鐘周期可以推斷出如果重啟能恢復(fù)說明在重啟那一刻網(wǎng)絡(luò)側(cè)是可用的中間那段時(shí)間網(wǎng)絡(luò)發(fā)生了什么變化才是根因所在。順著這個(gè)思路去查網(wǎng)絡(luò)側(cè)在那段時(shí)間的告警和日志往往能找到線索。還有一點(diǎn)值得提醒做測(cè)試的人驗(yàn)證 T3402 行為時(shí)千萬不要用重啟來“清零”。正確的做法是等定時(shí)器自然到期或者在測(cè)試儀表上重新構(gòu)造拒絕場(chǎng)景。用重啟清零會(huì)讓測(cè)試結(jié)果失去意義因?yàn)槟泸?yàn)證的其實(shí)是“重啟后能不能附著”而不是“定時(shí)器到期后能不能附著”。5.3 換 PLMN、緊急呼叫這些可以提前解鎖的例外路徑T3402 雖然是個(gè)長靜默但不是絕對(duì)的封鎖。規(guī)范里留了幾個(gè)口子理解這些口子對(duì)分析現(xiàn)場(chǎng)現(xiàn)象很有幫助第一個(gè)口子是 PLMN 變化。因?yàn)?#19 會(huì)清空等價(jià) PLMN 列表終端重新選網(wǎng)時(shí)如果選到了一個(gè)原來在等價(jià)列表里、現(xiàn)在不在的 PLMN就會(huì)認(rèn)為這是“新網(wǎng)絡(luò)”從而停止 T3402 并重新發(fā)起附著。這解釋了為什么用戶“換個(gè)地方就好了”或者“坐地鐵到下一站就好了”。反過來說如果故障是區(qū)域性的用戶在該區(qū)域內(nèi)怎么移動(dòng)都不會(huì)好因?yàn)楹蜻x小區(qū)都屬于同一個(gè) PLMN。第二個(gè)口子是緊急業(yè)務(wù)。緊急附著不受 T3402 限制這是安全相關(guān)的設(shè)計(jì)要求任何時(shí)候都得讓用戶能打緊急電話。做測(cè)試時(shí)如果發(fā)現(xiàn)終端在 T3402 期間發(fā)起了緊急附著別當(dāng)成 bug。第三個(gè)口子是用戶干預(yù)。手動(dòng)選網(wǎng)、重新插拔卡、開關(guān)飛行模式這些操作都會(huì)重置或繞過定時(shí)器狀態(tài)。這也是為什么現(xiàn)場(chǎng)支撐時(shí)“開關(guān)飛行模式”成了萬能第一招——它確實(shí)有效但它只是繞過不是修復(fù)。我在分析一個(gè)反復(fù)出現(xiàn)的現(xiàn)場(chǎng)問題時(shí)就是靠這個(gè)口子找到線索的?，F(xiàn)象是用戶在某個(gè)園區(qū)內(nèi)無法上網(wǎng)走出園區(qū)就好。一開始懷疑是園區(qū)內(nèi)的基站問題但基站側(cè)看一切正常。后來注意到“走出園區(qū)就好”其實(shí)是因?yàn)樽叱隽四莻€(gè) PLMN 的覆蓋邊界觸發(fā)了 PLMN 變化從而提前解鎖了 T3402。真正的根因是園區(qū)內(nèi)某臺(tái)網(wǎng)元在特定時(shí)段不可用導(dǎo)致持續(xù)的 #19。如果不是理解了這條例外路徑可能還在基站側(cè)繞圈子。6. 怎么在實(shí)驗(yàn)室把這套行為完整驗(yàn)證一遍6.1 最小驗(yàn)證集四個(gè)用例覆蓋全部關(guān)鍵分支如果要在實(shí)驗(yàn)室驗(yàn)證一款終端對(duì) #19 的處理是否符合預(yù)期不需要把整張 cause 表都測(cè)一遍四個(gè)用例能覆蓋全部關(guān)鍵分支用例構(gòu)造方式預(yù)期行為判定要點(diǎn)基礎(chǔ)觸發(fā)儀表在附著流程中回 ATTACH REJECTcause 填 0x13清身份信息、狀態(tài)置 EU3、啟動(dòng) T3402后續(xù) 720 秒內(nèi)無普通附著請(qǐng)求到期恢復(fù)同上保持網(wǎng)絡(luò)可用觀察 720 秒后到期后自動(dòng)發(fā)起新附著時(shí)間偏差在合理范圍附著能成功提前解鎖觸發(fā)后改變 PLMN 環(huán)境停止 T3402立即發(fā)起附著確認(rèn)不是靠重啟實(shí)現(xiàn)的不持久化觸發(fā)后斷電重啟重啟后立即發(fā)起附著驗(yàn)證定時(shí)器狀態(tài)未保存這四個(gè)用例跑下來基本能判斷終端的實(shí)現(xiàn)質(zhì)量。第一和第二個(gè)用例驗(yàn)證核心邏輯第三和第四個(gè)驗(yàn)證邊界處理。實(shí)際測(cè)試中第二個(gè)用例最花時(shí)間因?yàn)橐娴?12 分鐘建議用自動(dòng)化腳本記錄時(shí)間戳別靠人盯著。有個(gè)細(xì)節(jié)要注意構(gòu)造 REJECT 時(shí)cause 值的編碼要填對(duì)。#19 的十進(jìn)制和十六進(jìn)制容易搞混如果儀表配錯(cuò)成別的值測(cè)出來的行為完全不同而且不容易發(fā)現(xiàn)。測(cè)試前先確認(rèn)儀表配置界面用的是哪種進(jìn)制測(cè)完在 log 里再核對(duì)一次實(shí)際下發(fā)的字節(jié)。6.2 觀察窗口和判定標(biāo)準(zhǔn)驗(yàn)證時(shí)的觀察窗口不能只盯著 720 秒這個(gè)點(diǎn)要留出前后余量。我的習(xí)慣是記錄三個(gè)時(shí)間點(diǎn)REJECT 時(shí)刻 T0、預(yù)期到期時(shí)刻 T0720s、實(shí)際發(fā)起附著的時(shí)刻。三者對(duì)齊才算通過。判定標(biāo)準(zhǔn)我一般這么定實(shí)際發(fā)起時(shí)刻落在 T0715s 到 T0740s 之間算正常超出這個(gè)范圍就要看具體偏差原因。如果是固定偏移比如總是多 30 秒多半是到期后加了抖動(dòng)或者有前置檢查流程如果是離散的、每次都不一樣的偏差那就要查計(jì)時(shí)源。還有一個(gè)容易漏掉的判定點(diǎn)到期后發(fā)起的那次附著流程是否完整。有些實(shí)現(xiàn)會(huì)在到期后發(fā)一個(gè)不完整的請(qǐng)求比如漏了 PDN 連接請(qǐng)求或者用了過期的身份信息。這種情況在儀表上表現(xiàn)為附著失敗容易被誤判成“定時(shí)器到期了但網(wǎng)絡(luò)還不行”實(shí)際上是終端狀態(tài)清理得不干凈。檢查方法是看那次 ATTACH REQUEST 里的身份字段是不是空的應(yīng)該用 IMSI 而不是已刪除的 GUTI以及 PDN 連接請(qǐng)求是否正常攜帶。最后分享一個(gè)我在實(shí)際排障中養(yǎng)成的習(xí)慣每次遇到 #19不管最后查到什么原因都把這一條的完整時(shí)間線記下來——REJECT 時(shí)刻、cause 值、上游原因、T3402 是否正常到期、到期后是否恢復(fù)。攢夠十幾條之后你會(huì)發(fā)現(xiàn)規(guī)律非常明顯哪些是網(wǎng)絡(luò)側(cè)配置問題、哪些是容量問題、哪些是終端實(shí)現(xiàn)問題分布一目了然。這個(gè)過程比看任何文檔都管用因?yàn)樗菑哪阕约旱木W(wǎng)絡(luò)里長出來的經(jīng)驗(yàn)。 ATTACH REJECT cause #19與T3402靜默排障
開機(jī)的狀態(tài)欄一直卡在“正在激活數(shù)據(jù)連接”等了一分多鐘沒動(dòng)靜用戶以為卡槽接觸不良重啟一下又好了。這種反饋在現(xiàn)網(wǎng)排障里出現(xiàn)的頻率比想象中高真把信令拉出來看十有八九是一條 ATTACH REJECT 里帶著EMM cause #19ESM failure緊接著終端就徹底安靜了整整十二分鐘期間不發(fā)起任何附著、不發(fā)起任何路由區(qū)更新直到一個(gè)叫T3402的定時(shí)器走完才重新探頭。很多人第一次看到這段 log 會(huì)以為是終端掛了、協(xié)議棧死循環(huán)了其實(shí)終端活得好好的它只是被規(guī)范要求“閉嘴”十二分鐘。這篇內(nèi)容想聊的就是這條鏈路EMM cause #19 為什么會(huì)讓終端進(jìn)入 T3402 的長靜默期、這十二分鐘里終端到底做了什么、排障時(shí)怎么把定時(shí)器的起止點(diǎn)從 log 里釘死、以及網(wǎng)絡(luò)側(cè)在什么情況下才會(huì)選擇丟 #19 而不是回一條普通的 ESM 拒絕。寫給正在做終端協(xié)議棧、網(wǎng)絡(luò)側(cè)核心網(wǎng)優(yōu)化、或者現(xiàn)場(chǎng)支撐無線數(shù)據(jù)業(yè)務(wù)的人看基礎(chǔ)一點(diǎn)的讀者也能從中拿到一份“看到這個(gè) cause 該怎么往下查”的路線圖。1. 一條 ATTACH REJECT 之后那十二分鐘終端到底在干什么1.1 cause #19 的語義ESM 層失敗被抬到了 EMM 層要理解 T3402得先把 #19 這個(gè) cause 的語義掰開。LTE 的 NAS 協(xié)議分成兩層EMM 管移動(dòng)性和注冊(cè)附著、去附著、TAU、鑒權(quán)、安全ESM 管承載和會(huì)話PDN 連接建立、默認(rèn)承載、專用承載。平時(shí)這兩個(gè)層次各管各的ESM 層出錯(cuò)就走 ESM 的拒絕消息帶上 ESM cause比如“缺少或未知的 APN”“資源不足”“服務(wù)網(wǎng)關(guān)或 PDN 網(wǎng)關(guān)拒絕請(qǐng)求”這些終端收到之后只影響這一條 PDN已經(jīng)注冊(cè)上的其他業(yè)務(wù)不受牽連。#19 ESM failure的特殊之處在于它是用 EMM 層的話筒說出 ESM 層的事故。網(wǎng)絡(luò)側(cè)在附著流程里發(fā)現(xiàn)默認(rèn)承載建不起來本來可以只回一條 PDN CONNECTIVITY REJECT 了事但它選擇了更重的手段直接一條 ATTACH REJECTcause 填 0x13也就是十進(jìn)制 19。這一條消息發(fā)出去終端收到的信號(hào)不是“這個(gè) APN 有問題”而是“你這次附著整體失敗了而且失敗原因在會(huì)話層我沒法告訴你什么時(shí)候能好”。從十進(jìn)制 19 這個(gè)編碼本身看不出情緒但它在整張 cause 表里的位置很特殊。它不像 #11PLMN 不允許那樣把終端趕進(jìn)禁用名單也不像 #22擁塞那樣明說“我等會(huì)兒再來”它給的是一種模糊的、指向網(wǎng)絡(luò)內(nèi)部故障的結(jié)論。正因?yàn)槟：K端只能采取最保守的策略——把注冊(cè)狀態(tài)整體回退然后拉起一個(gè)足夠長的定時(shí)器等網(wǎng)絡(luò)自己緩過來。這個(gè)保守策略的執(zhí)行者就是 T3402?，F(xiàn)場(chǎng)判斷時(shí)有個(gè)很實(shí)用的分辨點(diǎn)ATTACH REJECT 里帶的是 EMM causePDN CONNECTIVITY REJECT 里帶的是 ESM cause兩者在 log 里的消息名完全不同但 cause 數(shù)值可能撞車比如都出現(xiàn) 26、27 這種數(shù)字?？?log 時(shí)如果不確認(rèn)消息類型光看 cause 數(shù)字非常容易誤判成 #19 場(chǎng)景。我見過有同事把 ATTACH ACCEPT 之后跟著的一條 ESM 拒絕當(dāng)成 #19從而錯(cuò)誤地認(rèn)為終端該起 T3402結(jié)果對(duì)著 log 找了半天沒找到定時(shí)器啟動(dòng)點(diǎn)。1.2 收到 #19 的一瞬間終端改了四筆賬并起了一個(gè)表終端收到攜帶 #19 的 ATTACH REJECT 之后動(dòng)作是一連串的不是單一動(dòng)作。按規(guī)范的處理邏輯它大致要完成這么幾件事我按重要性從高到低排第一筆賬是EPS update status 置為 EU3ROAMING NOT ALLOWED。這個(gè)狀態(tài)存在 USIM 的 EPS 位置信息文件里值 3 表示“未更新且漫游不允許”。它會(huì)影響終端后續(xù)對(duì)網(wǎng)絡(luò)選擇的判斷邏輯不是簡單的一個(gè)標(biāo)志位。第二筆賬是刪掉網(wǎng)絡(luò)分配的臨時(shí)身份和位置信息包括 GUTI全球唯一臨時(shí)標(biāo)識(shí)、最近訪問的注冊(cè)跟蹤區(qū)、跟蹤區(qū)列表。這一刪很關(guān)鍵意味著下次附著要從 IMSI 附著重新走一遍鑒權(quán)和加密流程都得重來沒法再用臨時(shí)身份省事。第三筆賬是清空等價(jià) PLMN 列表。這一條經(jīng)常被忽略但它直接決定了“換個(gè)地方能不能立刻好”后面第 5 節(jié)會(huì)展開。第四筆賬是把 EMM 狀態(tài)退回 DEREGISTERED同時(shí)把附著嘗試計(jì)數(shù)器清零。注意這里是清零而不是加一因?yàn)?#19 不是“嘗試失敗了一次”而是“這次嘗試的失敗性質(zhì)決定了不用再試”。做完這些之后終端啟動(dòng)T3402。這個(gè)定時(shí)器在規(guī)范里給的值是12 分鐘固定值不像 T3346 那樣由網(wǎng)絡(luò)通過消息里的定時(shí)器 IE 動(dòng)態(tài)下發(fā)也不像 T3396 那樣分場(chǎng)景給不同長度。它就是一個(gè)常量。定時(shí)器跑起來之后終端進(jìn)入一種“冷處理”狀態(tài)不再發(fā)起普通的附著、不再發(fā)起跟蹤區(qū)更新也不會(huì)去嘗試重建 PDN 連接因?yàn)樗B注冊(cè)都沒了沒有可重建的對(duì)象。有一點(diǎn)容易搞混T3402 的啟動(dòng)并不等于終端徹底停止所有無線行為。小區(qū)測(cè)量、重選、系統(tǒng)消息接收這些照常進(jìn)行射頻也沒有關(guān)。所以從外部看終端“還在網(wǎng)上”但它不會(huì)向網(wǎng)絡(luò)發(fā)任何注冊(cè)類請(qǐng)求。這就是為什么有些測(cè)試儀表上看不到終端有任何動(dòng)作會(huì)誤判成終端把協(xié)議棧卡死了。1.3 用戶側(cè)的表現(xiàn)為什么是“過一會(huì)兒自己好了”把這套機(jī)制翻譯成用戶語言就是開機(jī) → 附著 → 被拒原因不明→ 十二分鐘不理網(wǎng)絡(luò) → 突然自己好了。這個(gè)體驗(yàn)非常具有迷惑性因?yàn)橹虚g沒有任何提示狀態(tài)欄可能顯示 4G 圖標(biāo)射頻注冊(cè)在小區(qū)上是成功的只是 NAS 層沒注冊(cè)上用戶會(huì)以為“有信號(hào)但網(wǎng)卡了”然后不斷開關(guān)飛行模式。這里有個(gè)非常重要的現(xiàn)場(chǎng)細(xì)節(jié)開關(guān)飛行模式或者重啟往往能讓它立刻恢復(fù)。原因不是“重啟修復(fù)了問題”而是 T3402 的運(yùn)行狀態(tài)不跨斷電保存重啟后定時(shí)器沒了終端會(huì)立刻重新發(fā)起一次附著這時(shí)候如果網(wǎng)絡(luò)側(cè)的臨時(shí)故障剛好過去了就成功了。這個(gè)現(xiàn)象在網(wǎng)絡(luò)側(cè)故障是間歇性的時(shí)候特別明顯也是造成“用戶說重啟就好、你去看的時(shí)候一切正?！边@種扯皮局面的根本原因。反過來如果網(wǎng)絡(luò)側(cè)故障是持續(xù)性的比如 APN 配置錯(cuò)了、簽約數(shù)據(jù)缺了重啟會(huì)立刻再被拒一次用戶就會(huì)覺得“重啟也沒用”。這兩種表現(xiàn)背后其實(shí)是同一套機(jī)制只是網(wǎng)絡(luò)側(cè)狀態(tài)不同。分辨這兩種情況看 log 里的時(shí)間戳就夠如果兩次 ATTACH REJECT 之間的間隔是幾秒到幾十秒說明是重啟觸發(fā)的如果間隔精確到 720 秒左右說明是 T3402 正常到期。從用戶抱怨的分布看還有一類表現(xiàn)是“每天早上第一次上網(wǎng)特別慢要等十幾分鐘”。這種情況往往不是 T3402而是終端在夜間待機(jī)時(shí)被網(wǎng)絡(luò)隱式去附著早上喚醒后重新附著失敗了幾次累計(jì)到附著嘗試計(jì)數(shù)器上限才啟動(dòng) T3402?？雌饋硐裢粋€(gè)現(xiàn)象實(shí)際走的路徑完全不同第 2 節(jié)會(huì)把這兩條路徑對(duì)比清楚。2. 把 #19 放到 cause 家族里對(duì)比才知道它有多“重”2.1 同樣是拒絕#22 只讓終端等幾秒#19 要等十二分鐘單看 #19 沒什么感覺把它和其他常見 cause 擺在一起輕重立現(xiàn)。我整理了一張自己排障時(shí)常用的對(duì)照表覆蓋了 ATTACH REJECT 和 TAU REJECT 場(chǎng)景里出現(xiàn)頻率最高的幾個(gè) causeEMM cause語義終端主要?jiǎng)幼麝P(guān)聯(lián)定時(shí)器典型時(shí)長#19ESM failure清 GUTI/TAI 列表/ePLMN、狀態(tài)置 EU3、回 DEREGISTEREDT340212 分鐘#22Congestion保持當(dāng)前部分狀態(tài)等待后重試T3346由網(wǎng)絡(luò)下發(fā)常見幾十秒到幾分鐘#15No suitable cells in TA把該 TA 加入禁用列表T344224 分鐘#11PLMN not allowed該 PLMN 加入禁用列表無直到手動(dòng)選網(wǎng)或換卡#12Tracking area not allowed該 TA 加入禁用列表無同上#14EPS services not allowed視為 USIM 對(duì)該網(wǎng)絡(luò)無效無需換網(wǎng)或換卡#25CS domain not available僅影響 CS 回落相關(guān)無不阻斷 PS從這張表能看出一個(gè)規(guī)律cause 越“模糊”定時(shí)器越長。#11、#12 這類原因明確的終端直接拉黑名單不需要定時(shí)器等#22 這種明確說“我忙”的等一小會(huì)兒就行而 #19 說的是“會(huì)話層失敗了具體為什么我不告訴你”終端只能猜網(wǎng)絡(luò)需要多久恢復(fù)于是給了 12 分鐘這個(gè)相當(dāng)長的保守值。還有一個(gè)容易被忽略的差別#19 是立即啟動(dòng) T3402而其他很多失敗是要累計(jì)到 5 次才啟動(dòng)。規(guī)范里對(duì)附著嘗試計(jì)數(shù)器有明確上限連續(xù)失敗達(dá)到 5 次之后終端才會(huì)清身份信息并啟動(dòng) T3402。#19 跳過了這個(gè)累計(jì)過程一次就把終端打進(jìn)長靜默。這意味著在網(wǎng)絡(luò)側(cè)偶發(fā)故障的場(chǎng)景里如果 MME 選擇用 #19 而不是讓終端多試幾次用戶體驗(yàn)的損失會(huì)被放大好幾倍——本來試第三次就成功的附著被 #19 一搞直接變成等十二分鐘。這是網(wǎng)絡(luò)側(cè)參數(shù)選擇上很值得權(quán)衡的一個(gè)點(diǎn)第 4 節(jié)會(huì)詳細(xì)說。2.2 T3402 取值 12 分鐘的由來以及為什么不做隨機(jī)化12 分鐘這個(gè)數(shù)字不是拍腦袋定的它背后是一個(gè)挺典型的工程權(quán)衡。設(shè)想核心網(wǎng)某個(gè)網(wǎng)元出現(xiàn)短時(shí)故障如果所有終端都在幾秒內(nèi)瘋狂重試信令面會(huì)瞬間被淹沒本來就 congestion 的網(wǎng)元會(huì)被徹底壓垮恢復(fù)時(shí)間被無限拉長。反過來如果定時(shí)器設(shè)得太長比如半小時(shí)那么網(wǎng)絡(luò)已經(jīng)恢復(fù)了終端還在那兒干等用戶感知直接崩掉。12 分鐘大致落在“給網(wǎng)絡(luò)留出恢復(fù)窗口”和“用戶還能忍”這兩條線的交集上。有意思的是這個(gè)定時(shí)器沒有做隨機(jī)化。規(guī)范給的是固定值理論上如果一批終端在同一時(shí)刻被同一臺(tái) MME 拒絕它們會(huì)在同一時(shí)刻到期、同一時(shí)刻發(fā)起附著形成一個(gè)整齊的尖峰。在實(shí)際網(wǎng)絡(luò)里我確實(shí)觀察到過這種同步重試的現(xiàn)象一批物聯(lián)網(wǎng)模組在同一小區(qū)幾乎同時(shí)上線被拒之后又在 720 秒后幾乎同時(shí)發(fā)起對(duì)基站來說那一瞬間的接入請(qǐng)求是密集的。有些終端實(shí)現(xiàn)會(huì)在到期后疊加一段隨機(jī)的短延遲來打散這個(gè)尖峰這屬于實(shí)現(xiàn)層面的取舍規(guī)范里并沒有這個(gè)要求。做終端測(cè)試的時(shí)候如果發(fā)現(xiàn)某款設(shè)備到期后不是精確的 720 秒而是 720 加幾十秒先別急著判 bug有可能是故意加的抖動(dòng)。判斷方法很簡單連續(xù)測(cè)多次如果是固定偏移就說明是設(shè)計(jì)如此如果是每次都不一樣且離散度大那才可能是計(jì)時(shí)精度問題。另外提一句 2G/3G 體系的對(duì)應(yīng)關(guān)系方便做跨制式排障的人對(duì)照。老體系里也有類似的重試抑制機(jī)制量級(jí)同樣是十分鐘上下觸發(fā)條件也包含“網(wǎng)絡(luò)側(cè)無法建立 PDP 上下文”這類場(chǎng)景。所以當(dāng)你看到一個(gè)多模終端在 LTE 上被拒、切到 3G 之后又安靜很久很可能不是兩個(gè)獨(dú)立的故障而是兩套機(jī)制在各自生效。2.3 三種最容易被誤認(rèn)成 #19 的現(xiàn)場(chǎng)排障中最耗時(shí)間的往往不是定位問題而是先要排除“看起來像但不是”的情況。我列三個(gè)踩過的坑第一種把 ESM 拒絕當(dāng)成 #19。ATTACH ACCEPT 之后緊跟一條 PDN CONNECTIVITY REJECTcause 是 ESM 層的“資源不足”或者“未知 APN”終端會(huì)走 ESM 層的退避邏輯可能帶一個(gè)網(wǎng)絡(luò)下發(fā)的定時(shí)器值不會(huì)啟動(dòng) T3402。表面上都是“附著之后上不了網(wǎng)”但終端的行為完全不同這種情況終端保持已注冊(cè)可以重試其他 APN而 #19 是徹底回到未注冊(cè)。log 里一條看消息名就能區(qū)分別只看 cause 數(shù)值。第二種把附著嘗試計(jì)數(shù)器耗盡當(dāng)成 #19。終端連續(xù)附著失敗 5 次第 5 次之后清身份、起 T3402。從終端的最終狀態(tài)看和 #19 一模一樣都是清 GUTI 加 12 分鐘靜默。區(qū)別在時(shí)間軸這種情況前面會(huì)有 4 次失敗的 REJECT間隔通常是幾十秒量級(jí)可能有 T3411 之類的短定時(shí)器介入而 #19 是一次到位。把前面幾條消息翻出來看如果 reject 的 cause 是 #22 或者其他值那這就是累計(jì)失敗不是 #19 直接觸發(fā)。第三種把網(wǎng)絡(luò)側(cè)的隱式去附著當(dāng)成 #19。終端從待機(jī)喚醒后發(fā)現(xiàn)被隱式去附著重新發(fā)起附著又被拒如果拒的 cause 恰好是 #19 就會(huì)同時(shí)出現(xiàn)兩個(gè)現(xiàn)象。這種場(chǎng)景下用戶感知是“待機(jī)久了就上不了網(wǎng)”和純粹的 #19 場(chǎng)景開機(jī)即失敗在時(shí)間特征上不一樣。判斷方法是看第一條 ATTACH REQUEST 之前有沒有一段長時(shí)間的靜默以及有沒有 Detach Request/Accept 或者尋呼未響應(yīng)的記錄。這三種情況的共同點(diǎn)是只看終端最終狀態(tài)都會(huì)得到“12 分鐘靜默”這個(gè)結(jié)論但根因和修復(fù)方向完全不同。我在排查時(shí)養(yǎng)成的習(xí)慣是無論現(xiàn)象多像都先把 T3402 啟動(dòng)點(diǎn)之前的那 30 秒信令完整拉出來看一遍確認(rèn)最后一條驅(qū)動(dòng)消息到底是哪一條。這一步花兩分鐘能省掉后面兩個(gè)小時(shí)的瞎猜。3. 排障時(shí)怎么把 T3402 的起止時(shí)間釘死3.1 只在 NAS 層看是不夠的三層信令要對(duì)著看很多人排這類問題只抓終端的 NAS 消息能看到 ATTACH REJECT 和 cause但看不到“為什么被拒”。原因很簡單NAS 消息是終端和 MME 之間的對(duì)話MME 拒絕終端的時(shí)候它自己往往只是在轉(zhuǎn)發(fā)一個(gè)更底層的失敗。真正的根因通常在 S1 接口之外也就是 MME 和網(wǎng)關(guān)之間的會(huì)話建立過程。我一般的抓取范圍是三層空口側(cè) NAS 消息確認(rèn) reject 的類型、cause 值、時(shí)間戳以及后續(xù)終端有沒有異常動(dòng)作。S1 接口信令看整個(gè)附著流程走到哪一步斷的。正常的附著流程是Attach Request → Identity/Authentication → Security Mode → Update Location → Create Session → Initial Context Setup → Attach Accept。如果斷在 Create Session 之后那問題基本鎖定在核心網(wǎng)側(cè)。S5/S8 接口的會(huì)話消息看 Create Session Response 里攜帶的原因值這是最接近根因的一層。三層對(duì)著看的好處是能把“終端看到的現(xiàn)象”和“網(wǎng)絡(luò)內(nèi)部的真相”串成一條線。我見過一個(gè)案例終端側(cè)看到的是 #19S1 上看到 Create Session 請(qǐng)求發(fā)出去了但沒等到響應(yīng)S5/S8 上看到對(duì)端設(shè)備壓根沒回——三層信息拼起來根因是會(huì)話網(wǎng)關(guān)側(cè)的一個(gè)地址解析問題和終端毫無關(guān)系。如果只看終端 log可能會(huì)一直懷疑終端定時(shí)器實(shí)現(xiàn)有問題。3.2 用 720 秒做標(biāo)尺幾種典型的時(shí)間偏差說明什么T3402 是個(gè)固定值這就給了排障一個(gè)非常好用的標(biāo)尺從 ATTACH REJECT 的時(shí)間戳往后推 720 秒看終端是不是在這個(gè)點(diǎn)附近發(fā)起下一次附著。偏差的類型直接指向不同的問題層面。觀察到的間隔可能原因排查方向約 720 秒±幾秒定時(shí)器正常工作問題在網(wǎng)絡(luò)側(cè)查為什么被拒遠(yuǎn)小于 720 秒幾秒到幾十秒有事件提前解鎖了定時(shí)器檢查期間是否有 PLMN 變化、飛行模式、USIM 重插遠(yuǎn)小于 720 秒且多次重復(fù)定時(shí)器未生效或?qū)崿F(xiàn)缺陷確認(rèn)是否真的收到 #19檢查協(xié)議棧狀態(tài)機(jī)720 秒到 1200 秒之間跨睡眠計(jì)時(shí)漂移查待機(jī)場(chǎng)景下的計(jì)時(shí)補(bǔ)償實(shí)現(xiàn)超過 1200 秒甚至不發(fā)起被其他禁用列表擋住查禁用 PLMN、禁用 TA 列表狀態(tài)第三行那種“幾秒就重試”的情況要特別警惕。這不一定就是 bug很可能終端在等待期間又收到了新的觸發(fā)條件比如小區(qū)重選到了一個(gè)不屬于等價(jià) PLMN 列表的新 PLMN。因?yàn)?#19 會(huì)把等價(jià) PLMN 列表清掉原來那些“不算換了網(wǎng)”的鄰區(qū)現(xiàn)在都算新網(wǎng)了終端會(huì)提前解鎖。這個(gè)機(jī)制是規(guī)范要求的設(shè)計(jì)上合理但在排障時(shí)容易誤導(dǎo)人。第四行的漂移問題在物聯(lián)網(wǎng)設(shè)備上尤其常見。這些設(shè)備大量時(shí)間在待機(jī)協(xié)議棧的定時(shí)器如果基于某種會(huì)隨睡眠暫停的計(jì)數(shù)源實(shí)現(xiàn)實(shí)際經(jīng)過的時(shí)間就會(huì)被拉長。有些平臺(tái)會(huì)用真實(shí)時(shí)鐘戳做補(bǔ)償醒來后一次性把欠的時(shí)間補(bǔ)上這種情況下 720 秒還是準(zhǔn)的。有些平臺(tái)沒做補(bǔ)償就會(huì)看到 15 分鐘、20 分鐘這樣的結(jié)果。這屬于實(shí)現(xiàn)質(zhì)量問題需要終端側(cè)確認(rèn)。3.3 一次完整排查鏈路的復(fù)盤說個(gè)具體的分析過程把前面的方法串起來。現(xiàn)象是某類終端在某個(gè)區(qū)域反復(fù)出現(xiàn)“開機(jī)后長時(shí)間無法上網(wǎng)”重啟能恢復(fù)但不重啟的話要等十幾分鐘。第一步抓終端 NAS 日志。確認(rèn)每次失敗的驅(qū)動(dòng)消息都是 ATTACH REJECTcause 值為 0x13也就是 #19。并且確認(rèn)了 REJECT 之后終端確實(shí)沒有再發(fā)任何 ATTACH REQUEST直到約 720 秒后才重發(fā)。這一步排除了“協(xié)議?？ㄋ馈钡牟聹y(cè)坐實(shí)了 T3402 在正常工作。第二步看 S1 接口。發(fā)現(xiàn)附著流程走到 Create Session 這一步MME 向網(wǎng)關(guān)發(fā)了會(huì)話建立請(qǐng)求但返回的是失敗響應(yīng)隨后 MME 才組了 ATTACH REJECT 回給終端。這就把責(zé)任從終端排除了問題在核心網(wǎng)側(cè)。第三步看 S5/S8 的會(huì)話響應(yīng)里的原因值。這一步是關(guān)鍵得到的值指向“資源不可用”這一類。再往上游查發(fā)現(xiàn)是某個(gè)地址池在特定時(shí)段被耗盡新接入的終端拿不到地址網(wǎng)關(guān)直接回了資源不可用的原因。第四步驗(yàn)證。在地址池耗盡的時(shí)間窗內(nèi)做定點(diǎn)測(cè)試能穩(wěn)定復(fù)現(xiàn)在非高峰時(shí)段測(cè)試復(fù)現(xiàn)率極低。同時(shí)觀察到一個(gè)細(xì)節(jié)同樣的網(wǎng)絡(luò)條件下不同終端的行為不完全一樣——有些終端拿到的是 #19有些拿到的是 ATTACH ACCEPT 加 ESM 拒絕這說明 MME 對(duì)不同終端的處理路徑有差異下一節(jié)會(huì)講原因。第五步修復(fù)與回歸。網(wǎng)絡(luò)側(cè)擴(kuò)容地址池之后復(fù)測(cè)附著成功率恢復(fù)正常T3402 不再被觸發(fā)。整個(gè)鏈路從現(xiàn)象到根因大概用了兩天其中大部分時(shí)間花在協(xié)調(diào)多方同時(shí)抓包和對(duì)齊時(shí)間戳上真正定位的過程其實(shí)不長。這次排查給我最大的教訓(xùn)是#19 這個(gè)名字有很強(qiáng)的誤導(dǎo)性。它叫 ESM failure會(huì)讓人下意識(shí)地去查會(huì)話層的配置但實(shí)際根因可能在更上游的資源分配。排障時(shí)不能被 cause 的命名帶著走得順著信令一層層往下鉆。4. 網(wǎng)絡(luò)側(cè)為什么選擇丟 #19 而不是回 ESM reject4.1 MME 的兩條岔路拒整次附著還是只拒這個(gè) PDN這是整個(gè)話題里最值得深挖的一點(diǎn)。當(dāng)終端在 ATTACH REQUEST 里同時(shí)帶了 PDN 連接建立請(qǐng)求而這個(gè) PDN 建不起來的時(shí)候MME 面前有兩條路第一條路回 ATTACH ACCEPT只做 EPS 附著 PDN CONNECTIVITY REJECT帶 ESM cause。這樣終端注冊(cè)成功了拿到了 GUTI只是這個(gè) PDN 沒建起來。終端可以保持注冊(cè)狀態(tài)嘗試其他 APN或者過一段時(shí)間重試這個(gè) PDN重試的節(jié)奏由 ESM 層的退避機(jī)制控制通常比 12 分鐘短得多。對(duì)用戶來說最壞情況是某些應(yīng)用上不了網(wǎng)但基礎(chǔ)的注冊(cè)、語音回落這些還是正常的。第二條路回 ATTACH REJECT #19。終端整個(gè)回到未注冊(cè)接受 12 分鐘靜默。用戶的體感是從“部分功能不可用”變成“完全不可用”。規(guī)范允許兩種做法選擇權(quán)在 MME。實(shí)際操作中不同網(wǎng)絡(luò)設(shè)備廠商、不同運(yùn)營策略下選擇不一樣。我見過的場(chǎng)景里選擇 #19 的情況大致有幾類一是網(wǎng)絡(luò)側(cè)配置為不允許“僅 EPS 附著”也就是沒有默認(rèn)承載就不讓注冊(cè)二是簽約數(shù)據(jù)里沒有該 APN 的授權(quán)MME 認(rèn)為這不是臨時(shí)故障讓終端等也沒意義三是 MME 在會(huì)話建立失敗后拿不到足夠的信息判斷該回哪個(gè) ESM cause索性回一個(gè)籠統(tǒng)的 #19。站在用戶體驗(yàn)的角度第二條路的代價(jià)明顯更大。所以做網(wǎng)絡(luò)側(cè)參數(shù)優(yōu)化的時(shí)候如果發(fā)現(xiàn)某類失敗被頻繁映射成 #19值得評(píng)估一下能不能改成走第一條路。特別是那種“特定 APN 失敗但用戶其實(shí)還用著別的 APN”的多 APN 場(chǎng)景一次 #19 會(huì)把整個(gè)終端打癱十二分鐘損失被嚴(yán)重放大。4.2 S5/S8 上的 GTP cause 是怎么變成 #19 的從底層原因到 #19中間有一層映射關(guān)系理解這層映射對(duì)定位很有幫助。會(huì)話建立失敗時(shí)網(wǎng)關(guān)回的原因值大致有這幾類它們向上映射的路徑不同會(huì)話層原因含義常見上游問題向上映射傾向上下文未找到網(wǎng)關(guān)側(cè)沒有該 APN 的上下文簽約缺失、APN 配置不一致可能映射為 #19資源不可用地址池耗盡、承載資源不足容量規(guī)劃不足可能映射為 #19 或 ESM 資源不足缺少或未知 APNAPN 名字對(duì)不上終端配置與網(wǎng)絡(luò)配置不一致通常映射為 ESM 層 APN 錯(cuò)誤請(qǐng)求被拒絕策略側(cè)拒絕策略配置沖突視策略而定對(duì)端無響應(yīng)超時(shí)鏈路問題、對(duì)端設(shè)備異?？赡苡成錇?#19系統(tǒng)故障內(nèi)部錯(cuò)誤軟件異?？赡苡成錇?#19規(guī)律大致是原因越“不知道該怎么辦”越容易被映射成 #19。因?yàn)?#19 本質(zhì)上是一個(gè)“我這邊出問題了但說不清具體是什么”的表達(dá)。而原因明確、能對(duì)應(yīng)到具體 ESM cause 的比如 APN 名字錯(cuò)了MME 更傾向于走 ESM 拒絕讓終端知道該改配置。這個(gè)規(guī)律對(duì)排障有實(shí)際指導(dǎo)意義如果問題是穩(wěn)定復(fù)現(xiàn)的往往對(duì)應(yīng)的是配置類錯(cuò)誤可能走的是 ESM 路徑如果是間歇性的、時(shí)段性的更容易看到 #19。因?yàn)殚g歇性故障超時(shí)、資源競爭恰恰是“說不清”的那一類。我在現(xiàn)場(chǎng)遇到 #19 時(shí)的第一反應(yīng)就是去查時(shí)段分布看看是不是和某個(gè)高峰時(shí)間吻合。還有一層細(xì)節(jié)MME 在決定映射方式時(shí)還會(huì)考慮終端在 ATTACH REQUEST 里帶的 PDN 連接請(qǐng)求是不是“唯一的”請(qǐng)求。如果終端只請(qǐng)求了一個(gè) PDN而這個(gè) PDN 失敗MME 傾向于認(rèn)為整個(gè)附著沒有意義回 #19 更直接如果終端請(qǐng)求了多個(gè)雖然 LTE 附著階段通常只帶一個(gè)或者網(wǎng)絡(luò)知道終端還有別的業(yè)務(wù)需求走 ESM 拒絕的動(dòng)機(jī)就強(qiáng)一些。4.3 簽約、APN、地址池三個(gè)高發(fā)源頭從根因分布看#19 的來源高度集中在三塊實(shí)際排障時(shí)可以按這個(gè)順序查簽約數(shù)據(jù)問題排第一。用戶開了某個(gè) APN 的業(yè)務(wù)但簽約數(shù)據(jù)沒有同步到歸屬服務(wù)器或者同步了但 MME 緩存的是舊版本。這種情況下MME 在會(huì)話建立時(shí)發(fā)現(xiàn)本地沒有對(duì)應(yīng)的簽約信息會(huì)話建立直接失敗映射成 #19 的可能性很高。特征是換一張卡在同一位置正常或者同一個(gè)用戶換到別的 MME 覆蓋區(qū)正常。這種“跟人走而不跟位置走”的特征是簽約類問題最典型的標(biāo)志。APN 配置不一致排第二。終端側(cè)配置的 APN 名字、鑒權(quán)方式、IP 類型和網(wǎng)絡(luò)側(cè)預(yù)期的不一致。這種情況下起因很明確理論上應(yīng)該映射成 ESM 層的 APN 錯(cuò)誤但實(shí)際中如果 MME 沒有做精細(xì)映射也可能籠統(tǒng)地回 #19。特征是特定型號(hào)終端或特定配置的終端出問題其他終端正常。這種“跟終端走”的特征和簽約問題正好相反很好區(qū)分。地址池耗盡排第三也是最容易被忽略的。它的特征是時(shí)段性極強(qiáng)忙時(shí)出問題、閑時(shí)正常而且往往影響面廣、不分終端型號(hào)。這類問題在物聯(lián)網(wǎng)場(chǎng)景里特別常見因?yàn)槲锫?lián)網(wǎng)設(shè)備大量集中在某些時(shí)段上線比如深夜批量抄表瞬時(shí)并發(fā)遠(yuǎn)高于人網(wǎng)。我遇到過一次某區(qū)域每天晚上固定時(shí)段出現(xiàn)批量 #19查了兩天才定位到地址池容量。除了這三塊還有一個(gè)隱性的第四類MME 與網(wǎng)關(guān)之間的鏈路或解析問題。這類問題最隱蔽因?yàn)樗情g歇性的出現(xiàn)在特定鏈路或特定網(wǎng)元組合上。特征是同一個(gè)用戶在移動(dòng)位置后可能恢復(fù)正常換了服務(wù)網(wǎng)元或者問題集中在某個(gè)時(shí)間段內(nèi)新增的會(huì)話上鏈路抖動(dòng)期間。這類問題往往需要多接口同時(shí)抓包才能定位單看某一層永遠(yuǎn)看不出問題。5. 終端實(shí)現(xiàn)里幾個(gè)容易翻車的細(xì)節(jié)5.1 定時(shí)器跨睡眠漂移與“十二分鐘變成二十分鐘”終端側(cè)實(shí)現(xiàn) T3402 時(shí)最實(shí)際的工程問題是計(jì)時(shí)源的選擇。如果協(xié)議棧用的是系統(tǒng) tick 計(jì)數(shù)而這個(gè) tick 在深度睡眠時(shí)被暫停那么實(shí)際經(jīng)過的物理時(shí)間就會(huì)遠(yuǎn)遠(yuǎn)超過 12 分鐘。這在手機(jī)上不太明顯屏幕亮著的時(shí)候不睡眠但在物聯(lián)網(wǎng)模組上非常突出。有些平臺(tái)的處理方式是在定時(shí)器啟動(dòng)時(shí)記一個(gè)真實(shí)時(shí)間戳喚醒后重新計(jì)算剩余時(shí)間有些平臺(tái)則簡單地讓 tick 停在那醒來后繼續(xù)數(shù)。后者就會(huì)出現(xiàn)前面表格里提到的漂移現(xiàn)象。判斷一款設(shè)備用的是哪種方式測(cè)法很簡單讓設(shè)備在被拒之后立刻進(jìn)入待機(jī)等 15 分鐘再喚醒看它是不是立刻發(fā)起附著。如果是說明用了時(shí)間戳補(bǔ)償如果還要再等好幾分鐘說明 tick 被暫停了。這個(gè)差異對(duì)用戶體驗(yàn)的影響不小。本來十二分鐘能恢復(fù)的業(yè)務(wù)變成二十分鐘甚至更久在需要定時(shí)上報(bào)的場(chǎng)景里會(huì)造成明顯的數(shù)據(jù)缺口。做終端選型或者問題定位時(shí)這一條值得專門測(cè)一次。還有一個(gè)更隱蔽的問題定時(shí)器被意外重置。有些實(shí)現(xiàn)在收到某些非相關(guān)消息時(shí)會(huì)把 T3402 重新計(jì)時(shí)導(dǎo)致它永遠(yuǎn)走不完。典型觸發(fā)是小區(qū)重選之后收到系統(tǒng)消息更新或者收到一條尋呼。這類問題在 log 里表現(xiàn)為明明應(yīng)該 720 秒到期但每次快到點(diǎn)的時(shí)候就“重新開始”實(shí)際永遠(yuǎn)恢復(fù)不了。判斷方法是看有沒有周期性的某個(gè)消息反復(fù)出現(xiàn)且每次出現(xiàn)后定時(shí)器剩余時(shí)間被拉滿。5.2 重啟能治好的原因以及它為什么是排障陷阱前面提過T3402 的運(yùn)行狀態(tài)不跨斷電保存。這個(gè)設(shè)計(jì)本身是合理的規(guī)范里 EMM 的很多上下文都不持久化只把必須保留的信息比如 GUTI、禁用列表寫進(jìn) USIM。終端重啟后從 USIM 讀出狀態(tài)發(fā)現(xiàn)沒有正在運(yùn)行的定時(shí)器就重新發(fā)起附著。這給現(xiàn)場(chǎng)排障帶來一個(gè)很麻煩的循環(huán)用戶報(bào)障 → 你去現(xiàn)場(chǎng) → 用戶說我重啟過了現(xiàn)在好了 → 你什么都抓不到 → 過兩天又報(bào)。要打破這個(gè)循環(huán)得讓用戶或者一線人員知道下次出問題時(shí)先別重啟直接抓 log 或者撥個(gè)診斷碼看狀態(tài)。我一般會(huì)給一線一份簡單的操作卡片寫清楚“出現(xiàn)無法上網(wǎng)時(shí)先別重啟保持現(xiàn)狀記錄時(shí)間點(diǎn)”這樣才有機(jī)會(huì)抓到現(xiàn)場(chǎng)。從另一個(gè)角度看重啟能恢復(fù)這個(gè)特性本身是有價(jià)值的信息。它說明問題不是永久性的否則重啟也沒用而是有時(shí)效的。結(jié)合 T3402 的 12 分鐘周期可以推斷出如果重啟能恢復(fù)說明在重啟那一刻網(wǎng)絡(luò)側(cè)是可用的中間那段時(shí)間網(wǎng)絡(luò)發(fā)生了什么變化才是根因所在。順著這個(gè)思路去查網(wǎng)絡(luò)側(cè)在那段時(shí)間的告警和日志往往能找到線索。還有一點(diǎn)值得提醒做測(cè)試的人驗(yàn)證 T3402 行為時(shí)千萬不要用重啟來“清零”。正確的做法是等定時(shí)器自然到期或者在測(cè)試儀表上重新構(gòu)造拒絕場(chǎng)景。用重啟清零會(huì)讓測(cè)試結(jié)果失去意義因?yàn)槟泸?yàn)證的其實(shí)是“重啟后能不能附著”而不是“定時(shí)器到期后能不能附著”。5.3 換 PLMN、緊急呼叫這些可以提前解鎖的例外路徑T3402 雖然是個(gè)長靜默但不是絕對(duì)的封鎖。規(guī)范里留了幾個(gè)口子理解這些口子對(duì)分析現(xiàn)場(chǎng)現(xiàn)象很有幫助第一個(gè)口子是 PLMN 變化。因?yàn)?#19 會(huì)清空等價(jià) PLMN 列表終端重新選網(wǎng)時(shí)如果選到了一個(gè)原來在等價(jià)列表里、現(xiàn)在不在的 PLMN就會(huì)認(rèn)為這是“新網(wǎng)絡(luò)”從而停止 T3402 并重新發(fā)起附著。這解釋了為什么用戶“換個(gè)地方就好了”或者“坐地鐵到下一站就好了”。反過來說如果故障是區(qū)域性的用戶在該區(qū)域內(nèi)怎么移動(dòng)都不會(huì)好因?yàn)楹蜻x小區(qū)都屬于同一個(gè) PLMN。第二個(gè)口子是緊急業(yè)務(wù)。緊急附著不受 T3402 限制這是安全相關(guān)的設(shè)計(jì)要求任何時(shí)候都得讓用戶能打緊急電話。做測(cè)試時(shí)如果發(fā)現(xiàn)終端在 T3402 期間發(fā)起了緊急附著別當(dāng)成 bug。第三個(gè)口子是用戶干預(yù)。手動(dòng)選網(wǎng)、重新插拔卡、開關(guān)飛行模式這些操作都會(huì)重置或繞過定時(shí)器狀態(tài)。這也是為什么現(xiàn)場(chǎng)支撐時(shí)“開關(guān)飛行模式”成了萬能第一招——它確實(shí)有效但它只是繞過不是修復(fù)。我在分析一個(gè)反復(fù)出現(xiàn)的現(xiàn)場(chǎng)問題時(shí)就是靠這個(gè)口子找到線索的?，F(xiàn)象是用戶在某個(gè)園區(qū)內(nèi)無法上網(wǎng)走出園區(qū)就好。一開始懷疑是園區(qū)內(nèi)的基站問題但基站側(cè)看一切正常。后來注意到“走出園區(qū)就好”其實(shí)是因?yàn)樽叱隽四莻€(gè) PLMN 的覆蓋邊界觸發(fā)了 PLMN 變化從而提前解鎖了 T3402。真正的根因是園區(qū)內(nèi)某臺(tái)網(wǎng)元在特定時(shí)段不可用導(dǎo)致持續(xù)的 #19。如果不是理解了這條例外路徑可能還在基站側(cè)繞圈子。6. 怎么在實(shí)驗(yàn)室把這套行為完整驗(yàn)證一遍6.1 最小驗(yàn)證集四個(gè)用例覆蓋全部關(guān)鍵分支如果要在實(shí)驗(yàn)室驗(yàn)證一款終端對(duì) #19 的處理是否符合預(yù)期不需要把整張 cause 表都測(cè)一遍四個(gè)用例能覆蓋全部關(guān)鍵分支用例構(gòu)造方式預(yù)期行為判定要點(diǎn)基礎(chǔ)觸發(fā)儀表在附著流程中回 ATTACH REJECTcause 填 0x13清身份信息、狀態(tài)置 EU3、啟動(dòng) T3402后續(xù) 720 秒內(nèi)無普通附著請(qǐng)求到期恢復(fù)同上保持網(wǎng)絡(luò)可用觀察 720 秒后到期后自動(dòng)發(fā)起新附著時(shí)間偏差在合理范圍附著能成功提前解鎖觸發(fā)后改變 PLMN 環(huán)境停止 T3402立即發(fā)起附著確認(rèn)不是靠重啟實(shí)現(xiàn)的不持久化觸發(fā)后斷電重啟重啟后立即發(fā)起附著驗(yàn)證定時(shí)器狀態(tài)未保存這四個(gè)用例跑下來基本能判斷終端的實(shí)現(xiàn)質(zhì)量。第一和第二個(gè)用例驗(yàn)證核心邏輯第三和第四個(gè)驗(yàn)證邊界處理。實(shí)際測(cè)試中第二個(gè)用例最花時(shí)間因?yàn)橐娴?12 分鐘建議用自動(dòng)化腳本記錄時(shí)間戳別靠人盯著。有個(gè)細(xì)節(jié)要注意構(gòu)造 REJECT 時(shí)cause 值的編碼要填對(duì)。#19 的十進(jìn)制和十六進(jìn)制容易搞混如果儀表配錯(cuò)成別的值測(cè)出來的行為完全不同而且不容易發(fā)現(xiàn)。測(cè)試前先確認(rèn)儀表配置界面用的是哪種進(jìn)制測(cè)完在 log 里再核對(duì)一次實(shí)際下發(fā)的字節(jié)。6.2 觀察窗口和判定標(biāo)準(zhǔn)驗(yàn)證時(shí)的觀察窗口不能只盯著 720 秒這個(gè)點(diǎn)要留出前后余量。我的習(xí)慣是記錄三個(gè)時(shí)間點(diǎn)REJECT 時(shí)刻 T0、預(yù)期到期時(shí)刻 T0720s、實(shí)際發(fā)起附著的時(shí)刻。三者對(duì)齊才算通過。判定標(biāo)準(zhǔn)我一般這么定實(shí)際發(fā)起時(shí)刻落在 T0715s 到 T0740s 之間算正常超出這個(gè)范圍就要看具體偏差原因。如果是固定偏移比如總是多 30 秒多半是到期后加了抖動(dòng)或者有前置檢查流程如果是離散的、每次都不一樣的偏差那就要查計(jì)時(shí)源。還有一個(gè)容易漏掉的判定點(diǎn)到期后發(fā)起的那次附著流程是否完整。有些實(shí)現(xiàn)會(huì)在到期后發(fā)一個(gè)不完整的請(qǐng)求比如漏了 PDN 連接請(qǐng)求或者用了過期的身份信息。這種情況在儀表上表現(xiàn)為附著失敗容易被誤判成“定時(shí)器到期了但網(wǎng)絡(luò)還不行”實(shí)際上是終端狀態(tài)清理得不干凈。檢查方法是看那次 ATTACH REQUEST 里的身份字段是不是空的應(yīng)該用 IMSI 而不是已刪除的 GUTI以及 PDN 連接請(qǐng)求是否正常攜帶。最后分享一個(gè)我在實(shí)際排障中養(yǎng)成的習(xí)慣每次遇到 #19不管最后查到什么原因都把這一條的完整時(shí)間線記下來——REJECT 時(shí)刻、cause 值、上游原因、T3402 是否正常到期、到期后是否恢復(fù)。攢夠十幾條之后你會(huì)發(fā)現(xiàn)規(guī)律非常明顯哪些是網(wǎng)絡(luò)側(cè)配置問題、哪些是容量問題、哪些是終端實(shí)現(xiàn)問題分布一目了然。這個(gè)過程比看任何文檔都管用因?yàn)樗菑哪阕约旱木W(wǎng)絡(luò)里長出來的經(jīng)驗(yàn)。