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