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