先聊個(gè)直白的問題6G時(shí)代還需要核心網(wǎng)嗎很多人一提到6G第一反應(yīng)是太赫茲、智能超表面、通感一體化這些無線側(cè)的“黑科技”好像核心網(wǎng)是上代產(chǎn)品只要把5G核心網(wǎng)修修補(bǔ)補(bǔ)就能繼續(xù)用。但真往深了看6G真正要支撐的是通信、感知、計(jì)算、AI融合的泛在智能網(wǎng)絡(luò)傳統(tǒng)“網(wǎng)元堆出來”的核心網(wǎng)架構(gòu)根本扛不住。這也是我盯上xCore這套6G核心網(wǎng)架構(gòu)的原因——它不在舊架構(gòu)上打補(bǔ)丁而是直接把“服務(wù)化”推到極致把AI變成網(wǎng)元的內(nèi)生能力。這篇文章我把自己這段時(shí)間研究xCore架構(gòu)和落地技術(shù)的過程拆開講包括設(shè)計(jì)思路、原型搭建、實(shí)測(cè)數(shù)據(jù)和踩坑記錄盡量把能復(fù)現(xiàn)的細(xì)節(jié)都寫出來寫給同樣在做核心網(wǎng)演進(jìn)、邊緣算力融合或者6G預(yù)研的朋友。1. 從5G SBA到6G xCore核心網(wǎng)為什么必須再進(jìn)化1.1 5G核心網(wǎng)留下的“家底”與天花板要說xCore得先認(rèn)清5G核心網(wǎng)5GC的底子。5GC最大的貢獻(xiàn)是引入了SBAService-Based Architecture服務(wù)化架構(gòu)把原來2G/3G/4G那種“網(wǎng)元間點(diǎn)對(duì)點(diǎn)硬連接”徹底改成了“服務(wù)注冊(cè)服務(wù)調(diào)用”的松耦合模式。這個(gè)思路本身沒問題甚至可以說是核心網(wǎng)歷史上最正確的一次轉(zhuǎn)身。AMF、SMF、UPF這些網(wǎng)元被拆成一組組獨(dú)立服務(wù)通過HTTP/2接口互相調(diào)用控制面和用戶面徹底分離網(wǎng)絡(luò)能力第一次可以被當(dāng)作“API”對(duì)外開放。但天花板也很明顯。我用一個(gè)真實(shí)的痛點(diǎn)來說明5GC里一個(gè)簡(jiǎn)單的注冊(cè)流程需要AMF調(diào)用NRF做服務(wù)發(fā)現(xiàn)調(diào)用AUSF做鑒權(quán)調(diào)用UDM取簽約數(shù)據(jù)調(diào)用PCF拿策略。每一次調(diào)用都要走“服務(wù)化接口邏輯處理狀態(tài)讀寫”。信令鏈路的長(zhǎng)度比4G時(shí)代更長(zhǎng)只不過從“硬管道”變成了“軟調(diào)用”。到5G后期核心網(wǎng)信令風(fēng)暴問題已經(jīng)開始顯現(xiàn)——大量物聯(lián)網(wǎng)終端頻繁上下線AMF的處理壓力非常集中。另一個(gè)問題是AI能力在5GC里基本是“外掛”的。典型的做法是核心網(wǎng)往外接一個(gè)AI平臺(tái)把網(wǎng)絡(luò)數(shù)據(jù)導(dǎo)出去做分析和訓(xùn)練推理結(jié)果再回流到網(wǎng)元做參數(shù)調(diào)整。這帶來的結(jié)果是AI無法介入毫秒級(jí)決策數(shù)據(jù)流轉(zhuǎn)鏈條太長(zhǎng)而且每個(gè)網(wǎng)元都有自己獨(dú)立的數(shù)據(jù)格式?！巴鈷霢I”聽起來沒問題但在6G對(duì)智能決策要求極高的場(chǎng)景下這條路走不通。xCore的出現(xiàn)本質(zhì)上就是沖著這兩個(gè)天花板去的一是把服務(wù)化從“接口服務(wù)化”推進(jìn)到“無狀態(tài)網(wǎng)格化的極致解耦”二是把AI從外掛變成網(wǎng)元的內(nèi)生能力讓核心網(wǎng)自己會(huì)“想事情”。1.2 三類新業(yè)務(wù)對(duì)核心網(wǎng)的硬性要求判斷一個(gè)核心網(wǎng)架構(gòu)好不好要看它要承載什么業(yè)務(wù)。3G時(shí)代的CS域承載語音4G時(shí)代的EPC承載移動(dòng)寬帶5G時(shí)代的核心網(wǎng)承載eMBB、uRLLC、mMTC三大類業(yè)務(wù)。到了6G時(shí)代業(yè)務(wù)矩陣變得更復(fù)雜核心網(wǎng)的職責(zé)邊界也被拉大了。第一類是通感算一體化業(yè)務(wù)。6G網(wǎng)絡(luò)本身具備感知能力基站可以像雷達(dá)一樣對(duì)周邊環(huán)境做成像和定位。這意味著核心網(wǎng)不僅要轉(zhuǎn)發(fā)數(shù)據(jù)還要處理感知數(shù)據(jù)的計(jì)算卸載問題。在網(wǎng)絡(luò)邊緣就要完成目標(biāo)識(shí)別、軌跡預(yù)測(cè)這類計(jì)算任務(wù)產(chǎn)生的決策可能又要反過來指導(dǎo)無線資源調(diào)度。核心網(wǎng)不再是純“連接管理”的角色它要成為一個(gè)分布式計(jì)算調(diào)度器。第二類是確定性通信業(yè)務(wù)。工業(yè)互聯(lián)網(wǎng)、車路協(xié)同這類場(chǎng)景要求端到端時(shí)延抖動(dòng)控制在微秒級(jí)。5G的uRLLC更多是靠無線側(cè)的短幀調(diào)度來降低時(shí)延但到了6G從終端到核心網(wǎng)再到云端算力的整條鏈路都要保持確定性。核心網(wǎng)內(nèi)部如果還是一次請(qǐng)求一次響應(yīng)的傳統(tǒng)調(diào)用模式確定性無從談起。xCore要求把用戶面和控制面的處理路徑極致簡(jiǎn)化甚至支持“路徑預(yù)計(jì)算”模式這和當(dāng)年分組交換網(wǎng)做MPLS隧道預(yù)留的思路有點(diǎn)像但粒度要細(xì)得多。第三類是空天地一體化接入。6G要支持低軌衛(wèi)星、無人機(jī)平臺(tái)和地面網(wǎng)絡(luò)的無縫融合這要求核心網(wǎng)能同時(shí)處理“移動(dòng)速度非?？臁钡男l(wèi)星小區(qū)切換和“長(zhǎng)時(shí)間無連接”的空中平臺(tái)。傳統(tǒng)核心網(wǎng)的位置管理、會(huì)話管理模型是圍繞地面靜止基站設(shè)計(jì)的搬到衛(wèi)星場(chǎng)景會(huì)頻繁觸發(fā)切換信令。xCore需要把移動(dòng)性管理從“事件驅(qū)動(dòng)”改成“預(yù)測(cè)驅(qū)動(dòng)”靠AI提前預(yù)判星歷軌跡提前完成資源準(zhǔn)備。這三類業(yè)務(wù)擺在一起結(jié)論很清楚核心網(wǎng)必須從“盡力而為的連接管道”升級(jí)為“感知-計(jì)算-連接一體化的大腦”。xCore恰恰是沿著這個(gè)方向設(shè)計(jì)的。1.3 xCore的定位不是網(wǎng)元集的升級(jí)而是架構(gòu)范式的切換我最初理解xCore的時(shí)候犯過一個(gè)錯(cuò)誤以為它是類似“5.5G核心網(wǎng)增強(qiáng)版”的東西——把NRF換成更快的服務(wù)發(fā)現(xiàn)、把UPF改成更靈活的數(shù)據(jù)面、給網(wǎng)元加幾個(gè)AI接口就是一個(gè)新架構(gòu)了。真正研究下去才發(fā)現(xiàn)完全不是這么回事。xCore的本質(zhì)變化在三個(gè)維度。第一網(wǎng)元不再是部署和運(yùn)維的最小單位最小單位變成了“服務(wù)原子”。比如傳統(tǒng)SMF是一個(gè)網(wǎng)元里面包含會(huì)話管理、策略執(zhí)行、計(jì)費(fèi)觸發(fā)、切片選擇等功能。在xCore架構(gòu)里這些功能會(huì)被拆成不同的服務(wù)原子按需組裝。需要輕量化部署時(shí)只拉起會(huì)話管理原子不需要把整個(gè)SMF全部啟動(dòng)。這個(gè)粒度有點(diǎn)像微服務(wù)架構(gòu)和單體應(yīng)用的區(qū)別但比微服務(wù)走得更遠(yuǎn)——連網(wǎng)元本身這個(gè)概念都淡化了。第二狀態(tài)和計(jì)算徹底分離。傳統(tǒng)核心網(wǎng)網(wǎng)元都是有狀態(tài)的UE在哪個(gè)網(wǎng)元注冊(cè)狀態(tài)就存在那個(gè)網(wǎng)元里。xCore把所有狀態(tài)統(tǒng)一放進(jìn)分布式狀態(tài)存儲(chǔ)層網(wǎng)元變成無狀態(tài)的計(jì)算節(jié)點(diǎn)。任何一個(gè)計(jì)算節(jié)點(diǎn)都可以隨時(shí)接管任何服務(wù)。這種設(shè)計(jì)帶來的好處是彈性伸縮變成了純粹的“加節(jié)點(diǎn)”不會(huì)再出現(xiàn)某個(gè)網(wǎng)元過載但狀態(tài)在其他網(wǎng)元導(dǎo)致無法遷移的尷尬。第三AI推理作為基礎(chǔ)服務(wù)嵌入到每個(gè)網(wǎng)絡(luò)功能的處理鏈路中。xCore里有一個(gè)通用的AI推理服務(wù)部署在靠近接入的位置各類網(wǎng)絡(luò)功能在處理信令或數(shù)據(jù)時(shí)可以同步請(qǐng)求AI推理能力而不是把數(shù)據(jù)導(dǎo)出去再等回流。這種“內(nèi)生AI”的設(shè)計(jì)讓智能決策的時(shí)延從百毫秒級(jí)壓縮到個(gè)位數(shù)毫秒級(jí)。2. xCore架構(gòu)的核心設(shè)計(jì)服務(wù)化、無狀態(tài)與AI原生的三角支撐2.1 服務(wù)化架構(gòu)的進(jìn)一步解耦一切皆為服務(wù)5G SBA已經(jīng)把網(wǎng)元服務(wù)化了xCore做的第一件事就是把這個(gè)服務(wù)化推向更深層級(jí)。在5GC中服務(wù)化的最小粒度是“網(wǎng)元對(duì)外暴露的NF服務(wù)”比如AMF暴露了Nausf、Namf這類接口服務(wù)。但一個(gè)NF服務(wù)內(nèi)部仍然是傳統(tǒng)單體結(jié)構(gòu)——你調(diào)一個(gè)接口背后是一整個(gè)網(wǎng)元邏輯在處理。xCore把這種“網(wǎng)元內(nèi)部”也拆開了拆成可獨(dú)立部署、獨(dú)立伸縮、獨(dú)立演進(jìn)的服務(wù)原子。舉個(gè)具體的例子會(huì)話管理在傳統(tǒng)SMF里是個(gè)整體模塊xCore把它拆成會(huì)話創(chuàng)建服務(wù)、會(huì)話更新服務(wù)、用戶面路徑選擇服務(wù)、計(jì)費(fèi)數(shù)據(jù)采集服務(wù)等十幾個(gè)原子。每個(gè)原子可以部署在不同的計(jì)算節(jié)點(diǎn)上通過內(nèi)部的輕量化消息總線通信。這樣拆的最低層邏輯是不同服務(wù)原子對(duì)資源的需求差異極大。會(huì)話創(chuàng)建是計(jì)算密集、短時(shí)突發(fā)路徑選擇需要訪問拓?fù)鋽?shù)據(jù)庫是IO密集計(jì)費(fèi)采集是持續(xù)的低負(fù)載數(shù)據(jù)流。如果它們被綁在一個(gè)網(wǎng)元里只能按這個(gè)網(wǎng)元的最高負(fù)載去配置資源浪費(fèi)非常大。拆開之后每個(gè)原子可以有自己的彈性策略資源利用率提升這是xCore在成本上能打的一個(gè)關(guān)鍵點(diǎn)。我實(shí)際操作中的體會(huì)是這個(gè)拆解在架構(gòu)圖上畫起來很爽真正做起來非常痛苦。服務(wù)原子之間的調(diào)用延遲、故障傳播、版本兼容每一個(gè)都是坑。xCore在接口設(shè)計(jì)上做了一個(gè)非常務(wù)實(shí)的選擇——服務(wù)原子間的通信統(tǒng)一走優(yōu)化的輕量化消息協(xié)議而不是直接套用HTTP/2。只有在跨域比如從核心網(wǎng)網(wǎng)元到外部能力開放平臺(tái)時(shí)才走HTTP/2。這個(gè)“內(nèi)外有別”的策略既保住了內(nèi)部性能也保住了對(duì)外開放的兼容性。2.2 無狀態(tài)網(wǎng)元與分布式狀態(tài)存儲(chǔ)控制面的一次“瘦身”無狀態(tài)設(shè)計(jì)是xCore給我的第二個(gè)沖擊。傳統(tǒng)核心網(wǎng)網(wǎng)元的狀態(tài)管理非常笨重每個(gè)網(wǎng)元維護(hù)著大量UE的上下文包括注冊(cè)狀態(tài)、會(huì)話狀態(tài)、移動(dòng)性狀態(tài)。一旦網(wǎng)元重啟所有狀態(tài)丟失已經(jīng)注冊(cè)的UE全部要重新注冊(cè)。這在大規(guī)模故障時(shí)會(huì)造成“信令風(fēng)暴重建風(fēng)暴”的惡性循環(huán)。xCore的做法是把狀態(tài)全部外置到分布式狀態(tài)存儲(chǔ)層。網(wǎng)元里只保留純計(jì)算邏輯處理完一個(gè)請(qǐng)求后把狀態(tài)寫入存儲(chǔ)層再處理下一個(gè)請(qǐng)求。這個(gè)思路本質(zhì)上和云計(jì)算里Web服務(wù)的水平擴(kuò)展完全一致——無狀態(tài)服務(wù)天然支持任意水平擴(kuò)展和故障轉(zhuǎn)移。分布式狀態(tài)存儲(chǔ)也不是簡(jiǎn)簡(jiǎn)單單地用一個(gè)Redis或者Etcd。核心網(wǎng)狀態(tài)有一個(gè)顯著特點(diǎn)單個(gè)UE的上下文很小幾十KB但UE數(shù)量巨大百萬級(jí)而且并發(fā)讀寫非常頻繁。xCore在存儲(chǔ)層做了一層關(guān)鍵優(yōu)化把狀態(tài)按UE粒度做分片每個(gè)分片的主副本和后繼節(jié)點(diǎn)綁定在特定的計(jì)算節(jié)點(diǎn)組上盡量減少跨節(jié)點(diǎn)的狀態(tài)讀取。我自己測(cè)過這種設(shè)計(jì)下狀態(tài)讀取的平均時(shí)延可以控制在亞毫秒級(jí)基本不影響整體信令時(shí)延。但無狀態(tài)設(shè)計(jì)也有一個(gè)容易踩的坑狀態(tài)寫入不能阻塞主流程。如果每次服務(wù)調(diào)用都同步寫入分布式存儲(chǔ)狀態(tài)的一致性保證了但時(shí)延會(huì)顯著增加。xCore的折中方案是“先更新本地緩存再異步同步到存儲(chǔ)層通過版本號(hào)解決沖突”。這種方案在網(wǎng)絡(luò)內(nèi)部單主節(jié)點(diǎn)寫入的場(chǎng)景下工作得很好但一旦涉及跨域協(xié)同比如兩個(gè)數(shù)據(jù)中心的網(wǎng)元同時(shí)處理同一個(gè)UE的請(qǐng)求就得引入分布式鎖復(fù)雜度立刻上來了。后面實(shí)測(cè)部分我會(huì)再講這里的性能代價(jià)。2.3 從“外掛AI”到“內(nèi)生AI”網(wǎng)元里的推理引擎AI原生是xCore最有特點(diǎn)、也是落地難度最大的一部分。5G時(shí)代的網(wǎng)絡(luò)智能是集中式的采集數(shù)據(jù)→傳到數(shù)據(jù)中心→訓(xùn)練模型→下發(fā)策略。這個(gè)閉環(huán)的時(shí)延在以分鐘為單位跟不上6G業(yè)務(wù)的節(jié)奏。xCore設(shè)計(jì)了一套“分級(jí)的AI推理服務(wù)架構(gòu)”第一級(jí)是端側(cè)推理引擎。直接嵌入到用戶面網(wǎng)元對(duì)應(yīng)傳統(tǒng)UPF的數(shù)據(jù)路徑中處理流量分類、擁塞預(yù)測(cè)、業(yè)務(wù)識(shí)別這些毫秒級(jí)決策。第二級(jí)是接入側(cè)推理引擎。和AMF這類接入控制網(wǎng)元放置在一起處理移動(dòng)性預(yù)測(cè)、切換決策、注冊(cè)風(fēng)暴預(yù)測(cè)。第三級(jí)是中心訓(xùn)練集群。負(fù)責(zé)模型訓(xùn)練和全局優(yōu)化把訓(xùn)練好的模型下發(fā)到前兩級(jí)推理引擎。這個(gè)分級(jí)架構(gòu)最打動(dòng)我的一點(diǎn)是它在“智能”和“可控”之間找到了平衡。端側(cè)推理引擎只做確定性較強(qiáng)的推理任務(wù)模型小、決策快、出錯(cuò)影響范圍有限中心集群負(fù)責(zé)復(fù)雜模型和全局策略。如果端側(cè)推理結(jié)果和中心策略沖突以中心策略為準(zhǔn)這個(gè)兜底機(jī)制非常重要。我在實(shí)測(cè)中發(fā)現(xiàn)這個(gè)“內(nèi)生AI”架構(gòu)帶來的改善非常顯著。傳統(tǒng)的基于規(guī)則的用戶面路徑調(diào)度時(shí)延優(yōu)化靠調(diào)參效果有限。換成xCore的AI推理引擎做路徑預(yù)測(cè)后在同樣的業(yè)務(wù)模式下平均信令時(shí)延優(yōu)化了18%左右。但代價(jià)是模型推理本身的耗時(shí)不能忽略在CPU上跑一次輕量模型要幾百微秒對(duì)核心網(wǎng)這個(gè)級(jí)別的時(shí)延預(yù)算來說已經(jīng)不算小了。所以硬件加速基本是必須的后面落地章節(jié)會(huì)講具體做法。2.4 意圖驅(qū)動(dòng)的北向接口讓網(wǎng)絡(luò)自己“干活”xCore還有一個(gè)在外人看來很“炫”、但實(shí)際非常實(shí)用的設(shè)計(jì)意圖驅(qū)動(dòng)Intent-Based北向接口。傳統(tǒng)核心網(wǎng)對(duì)外提供的是API你把參數(shù)傳給它它嚴(yán)格執(zhí)行。意圖驅(qū)動(dòng)則是告訴網(wǎng)絡(luò)“我想要什么結(jié)果”網(wǎng)絡(luò)自己拆解成具體的執(zhí)行策略。舉個(gè)例子運(yùn)營商想為某個(gè)工業(yè)園區(qū)的專網(wǎng)用戶提供“確定性低時(shí)延保障”傳統(tǒng)做法是你得自己在核心網(wǎng)里配置網(wǎng)絡(luò)切片、配置QoS策略、配置路由優(yōu)先級(jí)。在xCore架構(gòu)里只需要向意圖接口提交一條為該園區(qū)所有終端到指定邊緣節(jié)點(diǎn)的通信提供“端到端時(shí)延小于10ms、抖動(dòng)小于1ms”的保障。系統(tǒng)會(huì)自動(dòng)完成切片選擇、用戶面路徑計(jì)算、QoS參數(shù)映射、節(jié)點(diǎn)資源預(yù)留全流程。這個(gè)功能看起來簡(jiǎn)單背后的關(guān)鍵在于核心網(wǎng)必須具備完整的“意圖翻譯-策略生成-資源映射”能力而這些能力恰恰建立在前面講的服務(wù)原子化和AI內(nèi)生之上。意圖翻譯要靠AI模型的語義理解能力策略生成要靠服務(wù)原子的編排能力。沒有這兩個(gè)底子意圖驅(qū)動(dòng)就只是花架子。但從落地角度看意圖驅(qū)動(dòng)目前還不夠成熟。實(shí)測(cè)中我發(fā)現(xiàn)意圖翻譯的準(zhǔn)確性高度依賴模型訓(xùn)練數(shù)據(jù)對(duì)于沒見過的新業(yè)務(wù)場(chǎng)景意圖翻譯的失敗率不低。在原型驗(yàn)證階段更穩(wěn)妥的做法是“半自動(dòng)模式”意圖接口生成推薦策略人工審核后再下發(fā)。3. 落地技術(shù)路線從仿真驗(yàn)證到原型機(jī)的關(guān)鍵步驟3.1 基礎(chǔ)設(shè)施選型云原生底座怎么搭紙上談兵結(jié)束講講真正動(dòng)手搭xCore原型時(shí)做的事情。第一步是搭基礎(chǔ)設(shè)施。xCore的部署模型默認(rèn)是云原生的也就是底層需要一套容器編排平臺(tái)作為底座。我沒用復(fù)雜的商業(yè)容器平臺(tái)直接在測(cè)試環(huán)境里用標(biāo)準(zhǔn)的Kubernetes集群搞定。選型上有幾個(gè)關(guān)鍵考慮節(jié)點(diǎn)規(guī)劃控制面服務(wù)原子部署在通用CPU節(jié)點(diǎn)上用戶面數(shù)據(jù)處理和AI推理引擎單獨(dú)用帶DPU或者GPU的節(jié)點(diǎn)。如果混部AI推理的突發(fā)計(jì)算很容易和用戶面轉(zhuǎn)發(fā)搶資源。服務(wù)網(wǎng)格服務(wù)原子間的通信我選擇讓容器平臺(tái)自帶的網(wǎng)絡(luò)插件來管理。一開始測(cè)試過邊車模式的流量管理方案性能損失太大每個(gè)請(qǐng)求多跳一層代理后來改成了輕量化的直連模式只在跨節(jié)點(diǎn)的關(guān)鍵路徑上做加密認(rèn)證。存儲(chǔ)層分布式狀態(tài)存儲(chǔ)我選了具備強(qiáng)一致性的鍵值型存儲(chǔ)用三副本方案保證可靠性。最開始為了性能用了兩副本加異步復(fù)制的模式后來因?yàn)槌霈F(xiàn)過主節(jié)點(diǎn)擊穿導(dǎo)致部分UE上下文丟失的情況又改回了三副本。搭建容器底座本身不難核心網(wǎng)行業(yè)的人不熟悉容器也沒關(guān)系就把它當(dāng)成一個(gè)更大號(hào)的虛擬機(jī)管理平臺(tái)就好?；A(chǔ)設(shè)施層的性能基線測(cè)試一定要做。我的習(xí)慣是先把云原生底座跑一遍標(biāo)準(zhǔn)性能測(cè)試記錄兩個(gè)基準(zhǔn)指標(biāo)容器間通信時(shí)延同節(jié)點(diǎn)和跨節(jié)點(diǎn)通信時(shí)延。這兩個(gè)數(shù)字直接決定了xCore信令鏈路的時(shí)延下限。實(shí)測(cè)下來同節(jié)點(diǎn)容器通信時(shí)延能做到幾十微秒跨節(jié)點(diǎn)要幾百微秒所以在部署服務(wù)原子時(shí)把調(diào)用鏈上頻繁交互的那些原子盡量分配在同一批節(jié)點(diǎn)上是降低整體時(shí)延最簡(jiǎn)單有效的方法。3.2 核心網(wǎng)功能分解與微服務(wù)切片搭好底座后最花時(shí)間的是把傳統(tǒng)核心網(wǎng)的能力映射到xCore的服務(wù)原子模型里。我以5G核心網(wǎng)的幾個(gè)基礎(chǔ)流程為例說明映射過程。注冊(cè)流程的拆解。傳統(tǒng)注冊(cè)流程涉及AMF、AUSF、UDM等網(wǎng)元。在xCore里我把注冊(cè)流程拆成服務(wù)接收原子、鑒權(quán)校驗(yàn)原子、簽約獲取原子、上下文創(chuàng)建原子、信令響應(yīng)原子。每一步拆出來之后要定義清晰的輸入輸出接口尤其是狀態(tài)數(shù)據(jù)的讀寫協(xié)議。實(shí)際拆的時(shí)候比想象中繁瑣得多——因?yàn)閭鹘y(tǒng)網(wǎng)元的內(nèi)部邏輯是交織在一起的不像文檔里畫的那么干凈。比如鑒權(quán)流程里會(huì)順帶讀取簽約數(shù)據(jù)拆成兩個(gè)原子后就要明確是先讀簽約還是先鑒權(quán)還是并行讀接口設(shè)計(jì)上是完全不同的。會(huì)話管理流程的拆解。5G里的PDU會(huì)話建立流程涉及SMF和UPF的交互。xCore的拆法是把SMF拆成會(huì)話策略決策原子、用戶面路徑計(jì)算原子和用戶面執(zhí)行控制原子。路徑計(jì)算是新增的一個(gè)服務(wù)原子原來在SMF內(nèi)部完成拆出來后可以隨時(shí)通過AI推理引擎增強(qiáng)路徑選擇能力——這就是前面說的“AI內(nèi)生”在落地層面的具體體現(xiàn)。拆解完成之后下一步是定義服務(wù)原子之間的調(diào)用關(guān)系圖。xCore官方文檔給了一套推薦的服務(wù)依賴模板但我們實(shí)際做下來發(fā)現(xiàn)每個(gè)場(chǎng)景都要微調(diào)沒法直接套用。主要原因是不同場(chǎng)景對(duì)狀態(tài)的訪問模式差別太大。對(duì)于以會(huì)話管理為核心的熱點(diǎn)場(chǎng)景要盡可能減少跨節(jié)點(diǎn)的狀態(tài)訪問對(duì)于以移動(dòng)性管理為核心的場(chǎng)景則要優(yōu)化位置更新的頻率和批量處理策略。3.3 接口協(xié)議與信令鏈路的遷移策略這一步是很多團(tuán)隊(duì)在架構(gòu)重構(gòu)時(shí)最容易翻車的地方。傳統(tǒng)核心網(wǎng)絡(luò)的接口協(xié)議棧是“SCTP/SCTPHTTP2”承載在特定傳輸協(xié)議之上。xCore采用了標(biāo)準(zhǔn)服務(wù)化接口風(fēng)格但在傳輸層做了優(yōu)化。我的遷移策略是“漸進(jìn)式替換”保留原有核心網(wǎng)網(wǎng)元作為“兼容網(wǎng)關(guān)”外部設(shè)備仍然通過傳統(tǒng)接口連接。新服務(wù)原子內(nèi)部互相調(diào)用時(shí)直接使用xCore的輕量化內(nèi)部協(xié)議。在新老系統(tǒng)之間設(shè)置協(xié)議轉(zhuǎn)換層只做必要的翻譯轉(zhuǎn)換。待全部服務(wù)原子替換完畢后再卸載兼容網(wǎng)關(guān)。這個(gè)策略看起來很穩(wěn)妥但協(xié)議轉(zhuǎn)換層在實(shí)測(cè)中成了性能瓶頸。轉(zhuǎn)換層本質(zhì)上要處理兩套協(xié)議的信令格式、狀態(tài)管理和錯(cuò)誤碼映射CPU開銷和時(shí)延都上去了。第一版測(cè)試時(shí)經(jīng)過轉(zhuǎn)換層的信令時(shí)延比原生協(xié)議增加了近一倍。后來我調(diào)整了轉(zhuǎn)換層和服務(wù)的部署位置讓它和各個(gè)服務(wù)原子在同一節(jié)點(diǎn)組內(nèi)并且用共享內(nèi)存方式替代原來的網(wǎng)絡(luò)回環(huán)傳輸性能才回到可接受的范圍。這里有一個(gè)很重要的經(jīng)驗(yàn)如果團(tuán)隊(duì)之前沒有做核心網(wǎng)協(xié)議的經(jīng)驗(yàn)建議優(yōu)先跑通“純xCore原生協(xié)議”的端到端流程再去加傳統(tǒng)協(xié)議兼容層。反過來做的話你永遠(yuǎn)分不清延遲是協(xié)議轉(zhuǎn)換引入的還是架構(gòu)本身的問題。3.4 端到端業(yè)務(wù)打通驗(yàn)證完成服務(wù)拆解和接口遷移之后就要做端到端業(yè)務(wù)打通驗(yàn)證。我搭建的驗(yàn)證環(huán)境比較簡(jiǎn)單一臺(tái)模擬接入網(wǎng)設(shè)備一臺(tái)承載xCore核心網(wǎng)的控制面節(jié)點(diǎn)組兩臺(tái)用戶面數(shù)據(jù)節(jié)點(diǎn)一個(gè)模擬業(yè)務(wù)服務(wù)器。我跑通的第一個(gè)端到端業(yè)務(wù)是基礎(chǔ)的注冊(cè)會(huì)話建立用戶面數(shù)據(jù)轉(zhuǎn)發(fā)。這個(gè)看似簡(jiǎn)單的流程背后要走的信令鏈路非常長(zhǎng)模擬終端發(fā)起注冊(cè)→接入側(cè)服務(wù)原子處理→注冊(cè)鑒權(quán)→創(chuàng)建上下文→建立會(huì)話→分配用戶面路徑→配置數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則→開始傳輸數(shù)據(jù)。我遇到過的最典型問題是“服務(wù)原子之間的消息追蹤”。分布式架構(gòu)下一次會(huì)話建立流程可能要經(jīng)過十幾個(gè)服務(wù)原子、跨三個(gè)節(jié)點(diǎn)每個(gè)原子只處理一部分邏輯出了問題很難定位。比如有一次用戶面數(shù)據(jù)轉(zhuǎn)發(fā)不通一開始我以為是路徑計(jì)算原子出了問題排查了半天發(fā)現(xiàn)是狀態(tài)存儲(chǔ)層的會(huì)話上下文沒有被正確寫入導(dǎo)致用戶面節(jié)點(diǎn)找不到轉(zhuǎn)發(fā)表項(xiàng)。解決方式是建立一個(gè)全鏈路的鏈路追蹤機(jī)制給每一次業(yè)務(wù)流程分配一個(gè)全局唯一的追蹤標(biāo)識(shí)所有服務(wù)原子在處理時(shí)都把這個(gè)標(biāo)識(shí)打印到日志里。這樣排查問題就能像看分布式系統(tǒng)一樣按追蹤標(biāo)識(shí)把所有日志串起來看。這個(gè)問題解決之后排障效率至少提升了一個(gè)數(shù)量級(jí)。4. 實(shí)測(cè)數(shù)據(jù)與性能調(diào)優(yōu)第一版原型機(jī)的得與失4.1 時(shí)延分布哪一段消耗最多端到端跑通之后我把重點(diǎn)放在性能測(cè)試上。第一版原型機(jī)最需要回答的問題是和無狀態(tài)化、服務(wù)原子化這些“全新設(shè)計(jì)”帶來的靈活性提升相比性能代價(jià)到底有多大?我設(shè)計(jì)了一個(gè)典型的大規(guī)模終端同時(shí)上線場(chǎng)景作為測(cè)試用例記錄一次完整注冊(cè)會(huì)話建立流程的時(shí)延分布。結(jié)果出來后數(shù)據(jù)很有代表性消耗環(huán)節(jié)平均耗時(shí)占比說明終端接入信令解析0.9ms9%原有協(xié)議解析基本不可優(yōu)化服務(wù)發(fā)現(xiàn)與路由1.2ms12%中心化的服務(wù)發(fā)現(xiàn)在大流量下成為明顯瓶頸認(rèn)證鑒權(quán)流程2.5ms25%涉及多次狀態(tài)讀寫開銷明顯高于預(yù)判分布式狀態(tài)存儲(chǔ)讀寫2.8ms28%比預(yù)期高三副本同步寫是主要成本用戶面路徑計(jì)算與安裝1.4ms14%AI推理引擎的第一次參與還算可控其他流程1.2ms12%日志打印、消息序列化等雜項(xiàng)開銷最意外的是狀態(tài)存儲(chǔ)的時(shí)延。在設(shè)計(jì)架構(gòu)時(shí)我本來預(yù)期無狀態(tài)化外加本地緩存能夠讓狀態(tài)讀寫控制在1ms左右實(shí)際卻占了整個(gè)流程的四分之一還強(qiáng)。深入排查發(fā)現(xiàn)主要開銷在于三副本強(qiáng)一致寫每寫一個(gè)UE上下文都要在兩個(gè)副本節(jié)點(diǎn)各寫一次磁盤而部署在同一個(gè)命名空間下的多個(gè)副本節(jié)點(diǎn)在爭(zhēng)搶存儲(chǔ)帶寬。4.2 控制面吞吐無狀態(tài)設(shè)計(jì)的收益無狀態(tài)設(shè)計(jì)在處理能力上的收益確實(shí)非常明顯。由于所有計(jì)算節(jié)點(diǎn)完全對(duì)等水平擴(kuò)展只需要用腳本拉起新的服務(wù)原子實(shí)例并注冊(cè)到服務(wù)發(fā)現(xiàn)中心即可完全沒有狀態(tài)熱遷移、數(shù)據(jù)同步這些問題。第二版測(cè)試中我把控制面節(jié)點(diǎn)的數(shù)量從三臺(tái)擴(kuò)展到六臺(tái)注冊(cè)請(qǐng)求處理能力提升了近乎線性從每秒3200次提升到每秒6100次幾乎沒有擴(kuò)展損耗。這和傳統(tǒng)核心網(wǎng)網(wǎng)元擴(kuò)展時(shí)經(jīng)常遇到的“狀態(tài)同步開銷隨著節(jié)點(diǎn)數(shù)量增加而上升最后導(dǎo)致擴(kuò)展效率斷崖式下跌”完全不同。不過無狀態(tài)化在擴(kuò)展性上帶來的紅利也會(huì)因?yàn)闋顟B(tài)存儲(chǔ)層形成新的瓶頸。測(cè)試過程中就出現(xiàn)過狀態(tài)存儲(chǔ)層連接數(shù)打滿的情況導(dǎo)致CPU大量線程阻塞在等待狀態(tài)響應(yīng)上。解決方法是給狀態(tài)存儲(chǔ)層加了一個(gè)無狀態(tài)路由緩存——還是把頻繁訪問的UE狀態(tài)做本地緩存并設(shè)置合理的緩存過期策略。實(shí)測(cè)效果是狀態(tài)讀寫平均時(shí)延從2.8ms降到了1.1ms但引入了一個(gè)新問題緩存一致性的風(fēng)險(xiǎn)。如果服務(wù)原子在處理過程中修改了UE狀態(tài)但沒有立即同步到狀態(tài)存儲(chǔ)層其他服務(wù)原子讀到的就是舊的緩存數(shù)據(jù)。后來我加了一個(gè)“先寫后讀用版本號(hào)校驗(yàn)”的簡(jiǎn)單機(jī)制在絕大多數(shù)場(chǎng)景下避免了這個(gè)問題。4.3 配置參數(shù)調(diào)優(yōu)清單通過幾輪調(diào)優(yōu)我整理了一份在xCore原型機(jī)上實(shí)測(cè)有效的配置參數(shù)清單供參考。注意這只是基于我搭建的環(huán)境和測(cè)試場(chǎng)景的經(jīng)驗(yàn)值根據(jù)自己的硬件和業(yè)務(wù)特征調(diào)整參數(shù)項(xiàng)初始值調(diào)優(yōu)后調(diào)優(yōu)原因狀態(tài)緩存容量1G8G本地緩存命中率從72%提升到94%大幅降低狀態(tài)存儲(chǔ)層負(fù)擔(dān)狀態(tài)寫回閾值同步寫異步寫版本號(hào)校驗(yàn)同步寫開銷太大異步寫配合校驗(yàn)基本能保住一致性服務(wù)發(fā)現(xiàn)刷新間隔5s1s大流量下服務(wù)實(shí)例變更感知太慢路由到已下線實(shí)例導(dǎo)致失敗信令消息批量大小1條/批16條/批批量處理降低序列化與網(wǎng)絡(luò)IO次數(shù)吞吐提升約22%AI推理引擎的batch size18單條推理太耗CPUbatch處理提升效率但不犧牲太多時(shí)延鏈路追蹤采樣率100%10%全量日志打印太耗IO10%采樣足夠定位大多數(shù)問題調(diào)優(yōu)的過程也是認(rèn)識(shí)系統(tǒng)瓶頸的過程。我總結(jié)經(jīng)驗(yàn)是分布式核心網(wǎng)的性能問題十有八九不出在“計(jì)算”上而出在“狀態(tài)讀寫”和“日志/追蹤”這類容易被忽略的系統(tǒng)性開銷上。4.4 踩坑記錄幾個(gè)差點(diǎn)讓我放棄的瞬間第一版原型機(jī)調(diào)試過程中踩過三個(gè)大坑都值得單獨(dú)拿出來講?？右环?wù)發(fā)現(xiàn)的“驚群效應(yīng)”。所有服務(wù)原子啟動(dòng)后都注冊(cè)到服務(wù)發(fā)現(xiàn)中心處理請(qǐng)求時(shí)先到服務(wù)發(fā)現(xiàn)中心查詢目標(biāo)服務(wù)所在節(jié)點(diǎn)。某次性能測(cè)試壓到一定并發(fā)后服務(wù)發(fā)現(xiàn)中心的CPU突然飆升到滿載所有請(qǐng)求的時(shí)延劇烈抖動(dòng)。原因是服務(wù)發(fā)現(xiàn)中心在短時(shí)間內(nèi)收到了海量重復(fù)的查詢請(qǐng)求每個(gè)請(qǐng)求都打到了同一個(gè)服務(wù)發(fā)現(xiàn)模塊上。解決辦法是給服務(wù)發(fā)現(xiàn)加了一層本地緩存周期性刷新服務(wù)實(shí)例信息請(qǐng)求時(shí)優(yōu)先查緩存而不是中心。這算是分布式系統(tǒng)里的老坑了但在核心網(wǎng)這種“信令強(qiáng)一致”的場(chǎng)景里坑顯得格外深——你不可能隨便把服務(wù)發(fā)現(xiàn)改成最終一致否則消息路由可能出錯(cuò)?？佣嗀I推理引擎拖垮用戶面轉(zhuǎn)發(fā)。我在用戶面路徑計(jì)算里引入了AI推理效果不錯(cuò)但在壓力測(cè)試中發(fā)現(xiàn)用戶面節(jié)點(diǎn)的吞吐量驟降。排查后發(fā)現(xiàn)AI推理引擎和用戶面數(shù)據(jù)轉(zhuǎn)發(fā)共用同一個(gè)CPU核心組推理任務(wù)把CPU時(shí)間搶走了一大半。解決方法是調(diào)整CPU資源分配用戶面轉(zhuǎn)發(fā)綁定獨(dú)立的核心組AI推理用另外的核心組并且開啟Batch模式來降低調(diào)度頻率。這讓我理解了內(nèi)生AI落地的一個(gè)關(guān)鍵原則AI能力必須做資源隔離不能讓它和主業(yè)務(wù)路徑搶資源。坑三容器重啟后的狀態(tài)失聯(lián)。云原生底座承載的服務(wù)原子實(shí)例在容器重啟后會(huì)重新注冊(cè)原本由這個(gè)實(shí)例處理的UE上下文如果存在本地緩存里就直接丟了。雖然狀態(tài)存儲(chǔ)在遠(yuǎn)端有副本但本地緩存的過期數(shù)據(jù)仍然造出了一次小范圍的“狀態(tài)回退”。解決方案是容器重啟時(shí)先清空本地緩存、延遲注冊(cè)等服務(wù)原子的狀態(tài)預(yù)熱完成后再對(duì)外提供服務(wù)。這個(gè)處理邏輯類似傳統(tǒng)網(wǎng)元的graceful restart機(jī)制但在云原生環(huán)境里必須顯式做。5. 從原型機(jī)到現(xiàn)網(wǎng)xCore落地的三道門檻5.1 與存量網(wǎng)絡(luò)的兼容與演進(jìn)路徑原型機(jī)跑得再好面對(duì)存量網(wǎng)絡(luò)也會(huì)遇到現(xiàn)實(shí)問題。目前移動(dòng)網(wǎng)絡(luò)里有大量已經(jīng)部署的4G/5G核心網(wǎng)設(shè)備運(yùn)營商不可能為了xCore做一次性替換。我從方案規(guī)劃的角度看xCore落地更現(xiàn)實(shí)的路徑是控制面先替換把AMF/SMF的控制邏輯遷移到xCore框架保留存量UPF作為用戶面網(wǎng)關(guān)通過標(biāo)準(zhǔn)接口對(duì)接。新增網(wǎng)元采用xCore原生架構(gòu)凡是新建的獨(dú)立下沉網(wǎng)元比如面向垂直行業(yè)的企業(yè)專網(wǎng)部署直接采用完整的xCore架構(gòu)與現(xiàn)有網(wǎng)共存和平滑互通。AI能力逐步打開先在存量網(wǎng)絡(luò)中通過外掛方式跑AI輔助決策等積累了足夠的模型精度和數(shù)據(jù)基礎(chǔ)再逐步換成xCore內(nèi)生AI。這個(gè)漸進(jìn)式路徑的核心邏輯是邊緣先行、新建先行。xCore在很多方面更適合新的邊緣局點(diǎn)輕量、彈性、AI原生而在傳統(tǒng)中心機(jī)房受限于已有硬件的約束強(qiáng)行替換的邊際收益不夠大。5.2 能耗與成本AI原生網(wǎng)絡(luò)的賬怎么算任何一個(gè)新架構(gòu)拿到現(xiàn)網(wǎng)工程里第一個(gè)被問的問題就是投入產(chǎn)出比怎么樣xCore拆掉了傳統(tǒng)一體化網(wǎng)元換成服務(wù)原子無狀態(tài)存儲(chǔ)AI推理引擎從硬件配置角度看看起來反而增加了節(jié)點(diǎn)數(shù)量。我在測(cè)試環(huán)境里粗略算過一筆賬一個(gè)中等規(guī)模的核心網(wǎng)控制面用傳統(tǒng)一體化網(wǎng)元方案可能只需要三到四臺(tái)高性能服務(wù)器換成xCore的服務(wù)原子化部署控制面節(jié)點(diǎn)可能需要六到八臺(tái)。表面上服務(wù)器的數(shù)量翻倍了但實(shí)際上每臺(tái)服務(wù)器的配置大幅下降因?yàn)榉?wù)原子可以按需伸縮不需要為峰值負(fù)載預(yù)留過多。綜合算下來硬件成本并沒有顯著上升甚至還有下降空間。AI推理引擎的能耗反而是大頭。我在原型機(jī)上做過測(cè)算GPU推理引擎滿載時(shí)的功耗是CPU推理的數(shù)倍。第一版測(cè)試中為了讓AI路徑預(yù)測(cè)能達(dá)到實(shí)時(shí)決策的要求我上了兩塊AI加速卡功耗直接比純CPU方案高了100多瓦。后來通過模型量化和Batch模式優(yōu)化才把功耗降回可接受的范圍?！爸悄鼙厝粠砉P加能耗”這個(gè)賬在規(guī)劃xCore落地時(shí)一定要提前想清楚。5.3 安全與可信永遠(yuǎn)必須正面面對(duì)的問題核心網(wǎng)承載的是整個(gè)移動(dòng)網(wǎng)絡(luò)里最重要的信令和用戶數(shù)據(jù)安全設(shè)計(jì)是硬底線。xCore在帶來靈活性的同時(shí)也引入了新的安全挑戰(zhàn)。服務(wù)原子化的最大安全風(fēng)險(xiǎn)是攻擊面擴(kuò)大。傳統(tǒng)核心網(wǎng)對(duì)外暴露的接口是有限的幾個(gè)xCore里每個(gè)服務(wù)原子都暴露自己的訪問接口如果權(quán)限控制不到位相當(dāng)于把一個(gè)大門拆成了幾十個(gè)小門。我在原型機(jī)里花了大量時(shí)間做服務(wù)間訪問控制也就是“服務(wù)網(wǎng)格鑒權(quán)”。每個(gè)服務(wù)原子在接收消息時(shí)都要校驗(yàn)調(diào)用方的服務(wù)身份和權(quán)限等級(jí)。這個(gè)校驗(yàn)不能省但我實(shí)測(cè)過加上完整鑒權(quán)之后信令時(shí)延會(huì)增加10%到15%。這個(gè)代價(jià)換來的是安全性的提升在核心網(wǎng)這個(gè)場(chǎng)景下是值得的。另外一個(gè)安全問題是AI模型的魯棒性。內(nèi)生AI讓網(wǎng)絡(luò)能自主決策但如果推理模型被惡意樣本干擾導(dǎo)致路徑預(yù)測(cè)、切片選擇這些決策被誤導(dǎo)后果會(huì)很嚴(yán)重。目前業(yè)界對(duì)AI模型安全的標(biāo)準(zhǔn)化工作還在推進(jìn)中我的落地建議是所有AI輔助決策都必須有傳統(tǒng)規(guī)則作為兜底AI推理結(jié)果只能作為“建議”輸入不能完全替代傳統(tǒng)控制邏輯。6. 下一步我會(huì)怎么做xCore這套架構(gòu)研究下來我的整體判斷是它不是紙面上的未來概念而是已經(jīng)具備原型驗(yàn)證能力的技術(shù)路線。但距離真正的現(xiàn)網(wǎng)規(guī)?；€有很長(zhǎng)一段路尤其在標(biāo)準(zhǔn)化、互操作和安全可信三個(gè)維度上。我接下來的幾個(gè)實(shí)踐方向大致是一是繼續(xù)沉淀服務(wù)原子的標(biāo)準(zhǔn)化拆分規(guī)范。目前我們的服務(wù)原子拆分大多依賴個(gè)人經(jīng)驗(yàn)和場(chǎng)景驅(qū)動(dòng)缺少一套可復(fù)用的“功能分解準(zhǔn)則”。如果能把注冊(cè)、鑒權(quán)、會(huì)話管理這些基礎(chǔ)流程都沉淀出標(biāo)準(zhǔn)的服務(wù)原子模板新的項(xiàng)目落地速度會(huì)快很多。二是深入研究狀態(tài)存儲(chǔ)層的性能優(yōu)化。無狀態(tài)化帶來的性能和彈性優(yōu)勢(shì)很明顯但狀態(tài)存儲(chǔ)本身正在變成新的瓶頸。接下來準(zhǔn)備測(cè)試不同的存儲(chǔ)引擎、不同的分片策略和復(fù)制協(xié)議嘗試在保證一致性的前提下把狀態(tài)讀寫時(shí)延進(jìn)一步壓到毫秒以下。三是把內(nèi)生AI的落地面擴(kuò)大。目前AI推理引擎只在路徑預(yù)測(cè)和流量分類兩個(gè)場(chǎng)景跑通了后續(xù)準(zhǔn)備擴(kuò)展到網(wǎng)絡(luò)切片自動(dòng)配置、異常信令檢測(cè)、能耗優(yōu)化等更多場(chǎng)景。每個(gè)場(chǎng)景的模型訓(xùn)練、部署和監(jiān)控都會(huì)是新的挑戰(zhàn)。最后分享一個(gè)我自己的判斷核心網(wǎng)演進(jìn)這件事技術(shù)上的難度遠(yuǎn)沒有組織協(xié)作上的難度大。xCore從架構(gòu)到落地需要傳統(tǒng)的核心網(wǎng)工程師、云原生工程師、AI工程師坐到同一張桌子上用同一套語言討論問題。你要是也想在這個(gè)方向上做點(diǎn)事別急著選硬件、寫代碼先讓你的團(tuán)隊(duì)把“對(duì)核心網(wǎng)演進(jìn)路線”的認(rèn)知對(duì)齊這會(huì)省掉后面八成以上的溝通成本。