5G 網(wǎng)絡學習系列寫到第四篇這次終于要聊用戶面里最核心的課題5G 網(wǎng)絡中數(shù)據(jù)包轉(zhuǎn)發(fā)模型。前幾篇我們把核心網(wǎng)網(wǎng)元、服務化接口、PDU 會話建立流程都過了一遍但很多朋友反映看完信令流程之后還是對“數(shù)據(jù)包到底怎么走”沒概念。信令只是告訴網(wǎng)絡“這個用戶是誰、他能用哪些服務”真正決定延時、帶寬、業(yè)務連續(xù)性的是用戶面的數(shù)據(jù)包轉(zhuǎn)發(fā)模型。這一篇就是把 PDU 會話、QoS 流、UPF、GTP-U 隧道這幾件事串起來講清楚一個 IP 包從數(shù)據(jù)網(wǎng)絡進入終端、再從終端回到數(shù)據(jù)網(wǎng)絡的完整路徑。這篇內(nèi)容適合正在學 5G 核心網(wǎng)的工程師也適合準備接觸用戶面排障的運維朋友。我會把模型拆成“位置、概念、路徑、場景、排障”五塊來講最后留一個未完待續(xù)的收尾方便下一期繼續(xù)補接入網(wǎng)側(cè)的細節(jié)。希望讀完你能在腦海里畫出一張完整的用戶面地圖。1. 數(shù)據(jù)包轉(zhuǎn)發(fā)模型在整個 5G 網(wǎng)絡里的位置1.1 控制面與用戶面分離是理解一切的起點很多初學者第一步容易卡住5G 核心網(wǎng)里那么多網(wǎng)元我怎么知道誰在“指揮”誰在“干活”答案其實很簡單控制面管“怎么連”用戶面管“怎么傳”。5G 從架構(gòu)設計上就把這兩個面分開了這叫控制與用戶面分離。在傳統(tǒng)網(wǎng)絡設備里路由引擎和轉(zhuǎn)發(fā)引擎往往是同一個盒子里的兩塊芯片控制邏輯和數(shù)據(jù)轉(zhuǎn)發(fā)緊密耦合。而 5G 核心網(wǎng)把控制面網(wǎng)元集中部署把用戶面網(wǎng)元下沉部署讓用戶流量盡量靠近接入側(cè)這樣既降低回傳帶寬壓力也縮短業(yè)務時延。落到具體網(wǎng)元上AMF 負責移動性管理SMF 負責會話管理UPF 是用戶面功能節(jié)點。SMF 通過 N4 接口給 UPF 下發(fā)指令包括“什么時候建立會話、如何識別用戶數(shù)據(jù)、該執(zhí)行什么轉(zhuǎn)發(fā)動作”。真正把用戶 IP 包從基站搬到數(shù)據(jù)網(wǎng)絡、再從數(shù)據(jù)網(wǎng)絡搬回基站的是 UPF。所以聊數(shù)據(jù)包轉(zhuǎn)發(fā)模型主角就是 UPF配角是 SMF 和基站側(cè)的 gNB。有個我常用的比喻控制面像快遞系統(tǒng)的調(diào)度中心用戶面像快遞運輸車隊。調(diào)度中心不搬包裹但它決定包裹裝哪輛車、走哪條路、多快到達車隊負責真搬但必須按調(diào)度中心的指令走。你抓包分析時如果只盯著控制面信令看以為“流程走通了”就萬事大吉往往會被用戶面的轉(zhuǎn)發(fā)問題坑得團團轉(zhuǎn)。1.2 數(shù)據(jù)包轉(zhuǎn)發(fā)模型要回答哪幾個問題數(shù)據(jù)包轉(zhuǎn)發(fā)模型不是一個單一概念而是一套規(guī)則組合至少要回答五個問題第一數(shù)據(jù)包在哪些網(wǎng)絡節(jié)點之間轉(zhuǎn)發(fā)在 5G 里主要涉及 N3、N9、N6 三個接口。N3 是 gNB 和 UPF 之間的接口N9 是兩個 UPF 之間的接口N6 是 UPF 和數(shù)據(jù)網(wǎng)絡之間的接口。數(shù)據(jù)包從終端出發(fā)先經(jīng)過空口到 gNB再從 gNB 經(jīng)過 N3 到 UPF在 UPF 內(nèi)部按規(guī)則處理后從 N6 出去如果中間有多個 UPF還會經(jīng)過 N9。第二一個用戶的數(shù)據(jù)包怎么區(qū)分靠 PDU 會話和 QoS 流。每個終端可以建立多個 PDU 會話每個會話里再拆成多個 QoS 流每一個流用 QFI 標識保證不同業(yè)務得到不同質(zhì)量的服務。第三轉(zhuǎn)發(fā)時遵循哪些規(guī)則SMF 通過 N4 接口給 UPF 下發(fā)的包檢測規(guī)則、轉(zhuǎn)發(fā)規(guī)則、QoS 執(zhí)行規(guī)則和流量上報規(guī)則基本決定了包的命運。第四數(shù)據(jù)包怎么跨節(jié)點傳輸目前主要靠 GTP-U 隧道隧道里用 TEID 標識上下文用擴展頭攜帶 QFI。第五在移動性場景和邊緣計算場景下轉(zhuǎn)發(fā)路徑如何切換和分流比如切換時怎么改隧道本地分流時怎么走“近路”。這些問題就是數(shù)據(jù)包轉(zhuǎn)發(fā)模型的核心骨架。下面逐個展開。2. 幾個繞不開的核心概念2.1 PDU 會話與 QoS 流用戶業(yè)務的“隔離層”PDU 會話全稱是 Protocol Data Unit Session可以理解為 UE 與數(shù)據(jù)網(wǎng)絡之間的一條端到端邏輯連接。它很像 4G 時代的 EPS 承載但又更靈活。一個終端可以同時建立多個 PDU 會話每個 PDU 會話對應一個 DNN數(shù)據(jù)網(wǎng)絡名稱也可以關(guān)聯(lián)不同的切片標識。比如一個手機終端可以有一個基礎(chǔ)互聯(lián)網(wǎng) PDU 會話同時再建一個面向企業(yè)專線的 PDU 會話兩個會話的 IP 地址、轉(zhuǎn)發(fā)規(guī)則、服務質(zhì)量是互相隔離的。在同一個 PDU 會話內(nèi)還會有更細粒度的隔離和區(qū)分這就是 QoS 流。QoS 流是 PDU 會話中具備相同轉(zhuǎn)發(fā)服務質(zhì)量保障的流量聚合每條 QoS 流由 QFI 唯一標識。QFI 是 0 到 255 之間的數(shù)值含義本身不固定一般結(jié)合 5QI 一起使用。5QI 是一個標準化的 QoS 指標定義了資源類型、優(yōu)先級、包延時預算、包錯誤率等參數(shù)。比如最常見的 5QI1 用于 VoNR 語音5QI8 或 9 用于普通互聯(lián)網(wǎng)業(yè)務。QoS 流建立的方式有兩種一種是會話建立時默認生成的默認 QoS 流通常是非 GBR 類型另一種是按需建立的專用 QoS 流可以是 GBR 類型由 SMF 根據(jù)策略觸發(fā)。實際抓包時QoS 流的概念不會直接出現(xiàn)在 IP 層而是體現(xiàn)在 GTP-U 頭擴展的 QFI 字段中這點后面詳細說。PDU 會話和 QoS 流的關(guān)系可以類比成家庭寬帶PDU 會話是“一條入戶光纜”QoS 流是光纜里的“不同服務通道”IPTV 一個通道、上網(wǎng)一個通道、語音一個通道彼此共享物理線路但互不影響優(yōu)先級。沒有 QoS 流做區(qū)分所有流量擠在一起關(guān)鍵業(yè)務質(zhì)量根本沒法保障。2.2 UPF真正干活的節(jié)點UPF 是用戶面功能節(jié)點負責 PDU 會話的錨點、數(shù)據(jù)包檢測、流量轉(zhuǎn)發(fā)、QoS 執(zhí)行、計費信息收集等。通俗講它就是一張“可編程的數(shù)據(jù)轉(zhuǎn)發(fā)卡”既像路由器又像防火墻還帶著策略執(zhí)行能力。UPF 與 SMF 之間通過 N4 接口連接N4 接口上的關(guān)鍵消息包括會話建立請求、會話修改請求、會話刪除請求等。SMF 每次下發(fā)規(guī)則UPF 就按照規(guī)則更新自己的本地轉(zhuǎn)發(fā)表。這里有很多朋友不熟悉的術(shù)語PDR、FAR、QER、URR。PDR 是包檢測規(guī)則規(guī)定“哪些流量匹配這條規(guī)則”FAR 是轉(zhuǎn)發(fā)動作規(guī)則規(guī)定“匹配到的流量是轉(zhuǎn)發(fā)、丟棄、復制還是重定向”QER 是 QoS 執(zhí)行規(guī)則規(guī)定“流速限制和調(diào)度參數(shù)”URR 是用量上報規(guī)則規(guī)定“什么時候上報流量統(tǒng)計”。UPF 收到一個數(shù)據(jù)包后不是簡簡單單查路由表就轉(zhuǎn)發(fā)而是先按 PDR 的匹配條件比如源目的 IP、端口、TEID、QFI識別這條流再依據(jù)對應的 FAR 決定動作依據(jù) QER 做限速依據(jù) URR 做統(tǒng)計上報。這套機制比傳統(tǒng) IP 路由復雜很多但換來的是非常精細的流級控制既能分流又能限速還能計費邊緣計算和網(wǎng)絡切片都依賴這種能力。UPF 的位置選擇也很講究。集中部署的 UPF 策略簡單、管理方便但回傳路徑長時延高靠近基站部署的 UPF 時延低但數(shù)量多、維護復雜。實際組網(wǎng)往往會做分級部署省級層面放中心 UPF地市層面或園區(qū)內(nèi)部放邊緣 UPF中間用 N9 接口連接。轉(zhuǎn)發(fā)模型在不同層級之間有微妙差異后面會展開。2.3 隧道與 QFI包里到底藏著什么5G 用戶面轉(zhuǎn)發(fā)最明顯的特點就是隧道封裝。gNB 和 UPF 之間的 GTP-U 隧道外層是普通 IP/UDP 頭內(nèi)層是用戶的真實數(shù)據(jù)包。GTP-U 使用 UDP 端口 2152頭部里最關(guān)鍵的是 TEID也就是隧道端點標識符。TEID 用來告訴接收端“這個包屬于哪個 PDU 會話”接收端根據(jù) TEID 找到對應的會話上下文再按規(guī)則繼續(xù)處理。GTP-U 頭部之后還有可選的擴展頭QFI 就在擴展頭里。也就是說一個數(shù)據(jù)包到了 N3 接口你看到的結(jié)構(gòu)是外層 IP 頭、外層 UDP 頭、GTP-U 頭、GTP-U 擴展頭包含 QFI、內(nèi)層 IP 頭、業(yè)務數(shù)據(jù)。我用 Wireshark 抓 N3 口流量時經(jīng)?？吹絻蓚€ IP 頭疊著第一次看的朋友會有點懵但只要記住“外層是節(jié)點之間的隧道地址內(nèi)層是用戶報文”就好了。QFI 放在 GTP-U 擴展頭而不是內(nèi)層 IP 頭里是有講究的。因為同一個 PDU 會話里QoS 流的區(qū)分是網(wǎng)絡側(cè)幫忙加標簽不是修改用戶的 IP 數(shù)據(jù)包。這樣用戶的 IP 包不會因網(wǎng)絡轉(zhuǎn)發(fā)而被篡改到了數(shù)據(jù)網(wǎng)絡側(cè)還是原樣。過去 4G 中 QoS 區(qū)分依賴 EPS Bearer ID5G 換成 QFI更靈活也更能支持后續(xù)的反射 QoS 機制?？吹竭@里你應該明白一個核心邏輯5G 用戶面真正傳輸?shù)氖恰凹恿怂淼赖?IP 包”隧道里面掛著會話上下文擴展頭里標著 QoS 流標識。所有轉(zhuǎn)發(fā)、分流、限速的動作都圍繞這兩個標識展開。3. 一步一圖數(shù)據(jù)包怎么走完一整條路3.1 下行從數(shù)據(jù)網(wǎng)絡到終端下行方向數(shù)據(jù)包從數(shù)據(jù)網(wǎng)絡出發(fā)目標是終端 UE。先走 N6 接口進入 UPF。UPF 收到這個包以后要做的事情很多但最關(guān)鍵的是三件事識別會話、匹配規(guī)則、封裝隧道。UPF 先看目的 IP 地址和端口等信息把它對應到某個 PDU 會話上。如果這個 PDU 會話有多條 QoS 流UPF 還要根據(jù)包的 DSCP、五元組或應用層信息判斷它屬于哪條 QoS 流然后填上對應的 QFI。接著UPF 根據(jù)這個 PDU 會話在 N3 口的隧道信息把用戶的 IP 包封裝成 GTP-U 包加上外層 IP/UDP 頭通過 N3 接口發(fā)給 gNB。gNB 收到 GTP-U 包后先去掉外層隧道頭讀取 QFI知道這個包屬于哪條 QoS 流。接下來 gNB 要根據(jù) QoS 流到數(shù)據(jù)無線承載的映射關(guān)系把包放到對應的 DRB 里。DRB 是空口上的數(shù)據(jù)無線承載一個 DRB 可以映射一個或多個 QoS 流。映射關(guān)系通過 SDAP 層完成SDAP 是 5G 新增的協(xié)議層專門在 RLC 之上做 QoS 流和 DRB 之間的映射。經(jīng)過 SDAP 映射之后數(shù)據(jù)包繼續(xù)往下走經(jīng)過 PDCP 層加密、RLC 層分段、MAC 層調(diào)度最終通過空口發(fā)給終端。終端側(cè)的 SDAP 層會反向操作把 DRB 里的包還原成對應的 QoS 流然后交給上層協(xié)議處理。所以下行方向可以總結(jié)成一句話數(shù)據(jù)網(wǎng)絡進入 UPFUPF 加隧道頭gNB 拆隧道按 QFI 映射到空口承載終端還原。3.2 上行從終端到數(shù)據(jù)網(wǎng)絡上行方向幾乎是下行的鏡像但有一個點值得注意上行鏈路里終端需要先決定業(yè)務包放到哪個 QoS 流再映射到哪個 DRB。終端應用產(chǎn)生一個 IP 包之后SDAP 層會根據(jù)規(guī)則給它標上 QFI。這些規(guī)則可以是會話建立時網(wǎng)絡側(cè)下發(fā)的也可以通過反射 QoS 從下行包中學到。然后這個包進入對應的 DRB經(jīng)過 PDCP、RLC、MAC 交給 gNB。gNB 從 DRB 里收包后根據(jù) DRB 到 QFI 的映射關(guān)系恢復 QFI再根據(jù) PDU 會話的隧道信息加上 GTP-U 頭通過 N3 接口發(fā)給 UPF。UPF 從 N3 口收到隧道包后根據(jù) TEID 找到會話上下文去掉外層隧道頭讀取 QFI再按 PDR/FAR 規(guī)則決定從哪個 N6 出口轉(zhuǎn)發(fā)出去。如果這個 PDU 會話接到了多個數(shù)據(jù)網(wǎng)絡或者有本地分流規(guī)則UPF 還要做出口選擇。上行最關(guān)鍵的一點是UE 側(cè)的映射質(zhì)量直接影響業(yè)務體驗。如果一個低優(yōu)先級業(yè)務錯誤映射到了高優(yōu)先級 DRB會擠占關(guān)鍵業(yè)務的空口資源。因此終端側(cè)的 SDAP 配置必須準確網(wǎng)絡側(cè)也要定期通過 RRC 重配置下發(fā)最新映射關(guān)系。排障時遇到“上行體驗差但下行沒問題”我一般會先看 UE 上報的 QoS 流映射和功控參數(shù)。3.3 QoS 流到 DRB 的映射最后一公里的排隊規(guī)則前面提到 DRB 是空口上的數(shù)據(jù)無線承載QoS 流到 DRB 的映射決定了一個業(yè)務包在空口上“排哪條隊”。這個映射不是固定的網(wǎng)絡可以隨時通過 RRC 信令調(diào)整。舉個例子一個 PDU 會話里有兩條 QoS 流一條是 VoNR 語音流5QI1要求低時延高可靠另一條是視頻流5QI8要求高帶寬但允許一定時延。如果這兩條 QoS 流映射到同一個 DRB它們享受同樣的調(diào)度優(yōu)先級語音的時延優(yōu)勢會大打折扣最好的做法是映射到兩個 DRB語音走專有 DRB高優(yōu)先級調(diào)度視頻走默認 DRB普通調(diào)度。SDAP 層在實現(xiàn)映射時既可以做“限定映射”讓某條 QoS 流只走指定 DRB也可以做“默認映射”在 DRB 建立后未顯式映射的 QoS 流都走默認 DRB。這里有個容易踩坑的地方如果 RRC 配置里的 SDAP 映射關(guān)系和下發(fā)的 QoS 流列表不一致終端側(cè)的包可能會被丟棄或錯誤映射業(yè)務就會忽好忽壞。從抓包角度QFI 在 N3 口上能直接看到但 DRB 映射情況在空口上看不全需要借助 RRC 信令和 gNB 側(cè)日志。所以我做轉(zhuǎn)發(fā)鏈路分析時習慣把 N3 抓包、RRC 重配置消息、UE 側(cè)日志放在一起看才能完整還原整個路徑。4. 多錨點與邊緣場景下的轉(zhuǎn)發(fā)模型4.1 UL CL給本地流量開一條“近路”標準的下行路徑是數(shù)據(jù)網(wǎng)絡到中心 UPF再走 N3 到 gNB。但如果業(yè)務是園區(qū)內(nèi)部應用或者邊緣計算服務堅持繞到中心 UPF 再回來時延會很高回傳帶寬也浪費。5G 提供了一種機制叫 UL CL中文叫上行分類器。UL CL 是在 UPF 上實現(xiàn)的一種數(shù)據(jù)包分流能力。SMF 在 PDU 會話建立或修改時可以在路徑上插入一個具備 UL CL 功能的 UPF。這個 UPF 收到上行數(shù)據(jù)后會按匹配規(guī)則做分流一部分流量送到中心 UPF走 N9 接口再進入中心數(shù)據(jù)網(wǎng)絡另一部分流量直接從本地 UPF 的 N6 接口送到邊緣應用服務器。下行方向反之來自兩個數(shù)據(jù)網(wǎng)絡的流量會在分支點匯合再通過同一個 N3 隧道送往 gNB。UL CL 最大的優(yōu)點是終端無感知。終端不需要改 IP 地址也不需要重新建立會話網(wǎng)絡側(cè)悄悄把一部分流量本地卸載了。對于視頻監(jiān)控、工業(yè)控制、車聯(lián)網(wǎng)等低時延業(yè)務這個模型幾乎是剛需。配置時要注意分流規(guī)則的粒度和優(yōu)先級比如按目的 IP 網(wǎng)段分流還是按域名分流。規(guī)則寫得太寬會把不該本地的流量也帶走寫得太窄又起不到分流效果需要針對業(yè)務逐個梳理。4.2 切換場景下的路徑切換移動中的終端一旦發(fā)生小區(qū)切換轉(zhuǎn)發(fā)路徑也要跟著變。5G 里切換分很多種比如 gNB 內(nèi)部切換、Xn 接口切換、N2 接口切換但核心目標都一樣讓用戶面隧道從舊基站快速切到新基站同時盡量不中斷業(yè)務。如果是基于 Xn 的切換源 gNB 會把用戶面數(shù)據(jù)轉(zhuǎn)發(fā)給目標 gNB同時目標 gNB 向核心網(wǎng)發(fā)起路徑切換請求。核心網(wǎng)收到請求后SMF 更新 UPF 側(cè)的用戶面信息把 N3 接口的隧道端點從源 gNB 改到目標 gNB。這里有個細節(jié)終端 IP 地址不會變因為 UPF 的 PDU 會話錨點沒有變變的只是 N3 隧道的對端。如果場景更復雜比如終端跨大區(qū)移動原有 UPF 離新基站太遠SMF 可能會重新選擇一個更近的 UPF。這時涉及中間 UPF 和錨點 UPF 的重新選址以及 N9 隧道的重新建立路徑切換影響就大得多。實際組網(wǎng)里核心網(wǎng)往往通過“UPF 選址策略”控制切換時是否遷移 UPF盡量優(yōu)先保證會話不斷而不是一味追求“最優(yōu)路徑”。排障中最常遇到的問題是切換后下行數(shù)據(jù)丟失。這種現(xiàn)象多數(shù)不是隧道建立失敗而是舊路徑上的數(shù)據(jù)包還在路上目標 gNB 未及時建立對應的承載或者 UPF 的轉(zhuǎn)發(fā)規(guī)則更新順序出了問題。我一般先看切換完成信令里攜帶的用戶面更新結(jié)果再看 gNB 是否收到了目標側(cè)隧道信息最后看 UPF 上的會話上下文時間戳基本能定位。4.3 邊緣計算對轉(zhuǎn)發(fā)模型的影響邊緣計算場景是 5G 用戶面轉(zhuǎn)發(fā)最典型的擴展應用。傳統(tǒng) 4G 時代數(shù)據(jù)必須從基站回傳到核心網(wǎng)網(wǎng)關(guān)再到互聯(lián)網(wǎng)5G 時代把 UPF 下沉到園區(qū)、機房甚至基站的邊緣位置讓業(yè)務流量在離用戶最近的地方完成轉(zhuǎn)發(fā)。邊緣節(jié)點通常有兩種組網(wǎng)方式。一種是“UL CL 本地 UPF”的組合本地 UPF 作為分流節(jié)點中心 UPF 作為主錨點另一種是“獨立 UPF 本地會話”終端建立單獨的 PDU 會話直接連到邊緣流量完全本地化。兩種方式各有取舍前者兼容性好適合公網(wǎng)和本地業(yè)務共存的場景后者隔離性更強適合企業(yè)專網(wǎng)和切片場景。邊緣計算給轉(zhuǎn)發(fā)模型帶來的最大變化是“N9 接口的使用”。多了一個中間 UPF 之后包從 gNB 到邊緣 UPF再通過 N9 到中心 UPF路徑上多了一段隧道。排查邊緣場景問題時不僅要關(guān)心 N3 隧道還要把 N9 隧道抓出來看。我遇到過很多次“業(yè)務不通但 UE 看起來正?！钡那闆r最后定位到 N9 接口的隧道 MTU 不一致大包過不去小包沒問題典型的轉(zhuǎn)發(fā)模型問題。另外邊緣場景下 DNS 分流也很常見。UE 發(fā)起域名解析時本地 UPF 可以把特定域名解析到本地服務器的地址把其余域名回源到中心 DNS。這個能力通常依賴 UPF 的 DNS 分流規(guī)則和本地 DNS 服務器的配合。配置時要驗證清楚否則會出現(xiàn)“同一域名不同終端解析結(jié)果不同”的怪象。5. 轉(zhuǎn)發(fā)模型相關(guān)的問題排查與實際心得5.1 抓包看轉(zhuǎn)發(fā)鏈路關(guān)鍵字段別搞錯數(shù)據(jù)包轉(zhuǎn)發(fā)模型的排查繞不開抓包。用戶面接口里N3 口是最有價值的觀察點。這里既有 GTP-U 隧道頭又有擴展頭里的 QFI還有內(nèi)層的真實用戶數(shù)據(jù)幾乎可以看到轉(zhuǎn)發(fā)模型的全部信息。抓包時重點看幾個字段外層 IP 頭的源和目的地址判斷隧道對端是否正確UDP 目的端口GTP-U 固定是 2152GTP-U 頭中的 TEID判斷這個包屬于哪個 PDU 會話擴展頭里的 QFI判斷 QoS 流標識再往下就是內(nèi)層 IP 頭看用戶真實的源目的地址。實際項目里我會在 gNB 側(cè)和 UPF 側(cè)同時抓包然后拿 TEID 和 QFI 對同一段流。如果 gNB 側(cè)收到下行包但 UPF 側(cè)沒發(fā)問題在 UPF 側(cè)或傳輸鏈路如果兩側(cè)都有但終端收不到問題就在空口和 DRB 映射上。這個方法看著笨但非常有效。需要注意的是N3 口有時會看到超長包或多片 IP 分片。GTP-U 封裝會增加幾十字節(jié)開銷如果底層傳輸設備開啟了較小的 MTU大包會被丟棄。抓包時如果看到 ICMP 需要分片消息反復出現(xiàn)基本可以定位為 MTU 問題。5.2 常見故障與排查順序我整理了轉(zhuǎn)發(fā)模型相關(guān)的幾個常見故障場景以及對應的排查思路做成了一張速查表故障現(xiàn)象可能原因排查方向PDU 會話建立成功但業(yè)務完全不通UPF 沒有正確配置轉(zhuǎn)發(fā)規(guī)則或 N6 路由缺失檢查 N4 會話規(guī)則、PDR/FAR、UPF 到數(shù)據(jù)網(wǎng)絡的路由下行時延高但上行正常N3 隧道路徑繞行、UPF 部署過遠、QFI 映射異常檢查 N3 路徑、QoS 流配置、UPF 節(jié)點位置大包不通小包通GTP-U 開銷導致 MTU 超限、傳輸鏈路分片異常核對端到端 MTU調(diào)大需要配合的隧道接口 MTU視頻卡頓但其他業(yè)務正常QoS 流映射失敗QFI 未正確傳遞抓 N3 口看 QFI檢查 UPF 的包檢測規(guī)則切換瞬間業(yè)務閃斷N3 隧道更新延遲、源基站數(shù)據(jù)轉(zhuǎn)發(fā)順序問題看切換信令和用戶面更新時間戳邊緣業(yè)務流量繞到了中心UL CL 分流規(guī)則未匹配或未下發(fā)檢查 UL CL 配置、分流規(guī)則優(yōu)先級排障時我的建議是遵循“從外向里、從控制面到用戶面”的順序。先確認終端有沒有建立 PDU 會話再確認 N4 接口上 SMF 有沒有把規(guī)則下發(fā)到 UPF然后是 N3 隧道是否正常最后才看數(shù)據(jù)網(wǎng)絡側(cè)的路由和防火墻。不要一上來就在 UPF 上用 ping 命令去測數(shù)據(jù)網(wǎng)絡因為很多問題不在連通性上而在流分類和隧道標識上。5.3 實操心得匯總做用戶面工作久了我積累了一些不算高深但很實用的心得。第一一定要區(qū)分“信令通了”和“數(shù)據(jù)通了”是兩回事。PDU 會話建立成功只能說明控制面流程走通用戶面隧道有沒有真正建立、UPF 的規(guī)則有沒有生效完全是另一回事。很多初級工程師看到“PDU Session Establishment Accept”就認為問題解決了這是最危險的習慣。第二抓包要多點同時抓不要只抓一個點。只抓 N6 口看不到 QFI只抓 N3 口看不到數(shù)據(jù)網(wǎng)絡側(cè)的回包。最低限度是 N3 口抓一遍、N6 口抓一遍然后把兩份抓包按內(nèi)部五元組和時間戳對齊。我自己做復雜排障時會同時在 gNB、中間傳輸設備、UPF、應用服務器四個點部署抓包雖然管理工作量大但能大大減少來回猜測時間。第三留意 UPF 上的會話狀態(tài)。UPF 側(cè)一般會有 show 命令或者管理面接口能看到哪些 PDU 會話處于激活狀態(tài)、哪些規(guī)則已經(jīng)安裝、哪些隧道端點正在使用。這個信息往往是判斷問題的最快路徑。N4 抓包反映的是 SMF 下發(fā)規(guī)則的過程但 UPF 最終執(zhí)行結(jié)果還是要看 UPF 本地狀態(tài)兩側(cè)要對照。第四涉及 QoS 流時別忽略 RRC 里的 SDAP 配置。很多無線側(cè)問題最終表現(xiàn)為轉(zhuǎn)發(fā)模型問題比如 DRB 映射錯誤導致高優(yōu)先級業(yè)務被低優(yōu)先級業(yè)務搶占。這時候只抓 N3 口是看不出端倪的因為 N3 口 QFI 標識沒問題但空口側(cè)把它放錯了隊列。需要把 RRC 重配置消息和 UE 日志拿來看才能發(fā)現(xiàn) SDAP 映射異常。第五邊緣場景里N9 接口的抓包非常重要但很多人會漏掉。如果終端建立了 PDU 會話數(shù)據(jù)也到了邊緣 UPF但業(yè)務還是繞到了中心那一定是有流量沒有命中本地分流規(guī)則。N9 抓包可以快速判斷流量是否從邊緣 UPF 被送到了中心 UPF從而反推 UL CL 規(guī)則是否生效。第六靈活使用流量模擬和測速工具。用戶面驗證時我會先用一個簡單 ICMP 包驗證基本連通性再用大包測試 MTU然后用 TCP/UDP 打流工具驗證帶寬和時延最后跑真實業(yè)務確認 QoS 效果。分階段加壓能避免把“配置錯誤”誤判成“帶寬不夠”。6. 未完待續(xù)后面想聊什么這期的內(nèi)容本來想一口氣寫到空口調(diào)度但實際梳理下來發(fā)現(xiàn)用戶面轉(zhuǎn)發(fā)模型涉及的面太廣光是把 PDU 會話、QoS 流、GTP-U 隧道、UPF 錨點和本地分流講透篇幅就已經(jīng)很長了。因此這一次先停在“數(shù)據(jù)包轉(zhuǎn)發(fā)模型的主干路徑”上。下一期我準備接著講空口側(cè)的 QoS 調(diào)度和 DRB 更細的映射邏輯以及網(wǎng)絡切片 S-NSSAI 在轉(zhuǎn)發(fā)面上的具體體現(xiàn)。這兩個話題和本期的轉(zhuǎn)發(fā)模型息息相關(guān)算是把“從核心網(wǎng)到終端”的最后一段補齊。如果你對某個方向更感興趣也可以在評論區(qū)點題我盡量安排。這個系列目前前四篇的話題逐步從架構(gòu)信令走向了用戶面。按照我自己做網(wǎng)絡工作多年的習慣看一張網(wǎng)絡先不要著急看協(xié)議細節(jié)而是先搞清楚數(shù)據(jù)從哪來、到哪去、在哪排隊、在哪分叉。希望這一篇的轉(zhuǎn)發(fā)模型梳理能幫你建立同樣的整體感。后續(xù)再遇到業(yè)務卡頓、流量繞行、邊緣分流不生效這些問題時起碼心里有數(shù)知道該從哪一段路徑下手。