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