摘 要：物聯(lián)網(wǎng)（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ，ＩｏＴ）即服務(wù)（ＩｏＴ ａｓ ａ Ｓｅｒｖｉｃｅ，ＩｏＴａａＳ）與６Ｇ 分布式核心網(wǎng)的融合將成為未來ＩｏＴ發(fā)展的重要趨勢，亟需一種分布式自治組網(wǎng)架構(gòu)支持ＩｏＴ 中較為普遍的公網(wǎng)與專網(wǎng)混合組網(wǎng)以及多子網(wǎng)對等組網(wǎng)。針對混合組網(wǎng)中復(fù)合網(wǎng)絡(luò)功能存儲庫（Ｎｅｔｗｏｒｋ Ｒｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ，ＮＲＦ）的服務(wù)注冊與發(fā)現(xiàn)流程信令交互復(fù)雜導(dǎo)致時(shí)延較大的問題，設(shè)計(jì)了一種基于分布式自治數(shù)據(jù)面技術(shù)的復(fù)合ＮＲＦ 互聯(lián)系統(tǒng)，提出了基于ＪＳＯＮ 語義的網(wǎng)絡(luò)功能信息存儲方法和基于Ｂ＋樹狀結(jié)構(gòu)的索引方法，降低了數(shù)據(jù)索引時(shí)間復(fù)雜度，簡化了跨網(wǎng)絡(luò)節(jié)點(diǎn)的多層網(wǎng)元數(shù)據(jù)獲取流程。

關(guān)鍵詞：數(shù)據(jù)面；分布式自治；核心網(wǎng)

中圖分類號：ＴＮ９２ 文獻(xiàn)標(biāo)志碼：Ａ 開放科學(xué)（資源服務(wù)）標(biāo)識碼（ＯＳＩＤ）：

文章編號：１００３－３１１４（２０２４）０４－０６５５－０９

０ 引言

自２０１９ 年起，５Ｇ 網(wǎng)絡(luò)全球商用，全球通信技術(shù)正邁向一個(gè)新的高度。６Ｇ 網(wǎng)絡(luò)將在５Ｇ 網(wǎng)絡(luò)三大應(yīng)用場景———增強(qiáng)移動(dòng)寬帶、海量機(jī)器通信和超高可靠低時(shí)延通信的基礎(chǔ)上向深拓展［１－２］。同時(shí)，６Ｇ可應(yīng)用于沉浸式通信、感知通信一體化、超大規(guī)模連接和泛在連接［３］等多種場景，并增強(qiáng)用戶體驗(yàn)如超可靠低時(shí)延通信、極高吞吐量、基于衛(wèi)星的客戶服務(wù)以及大規(guī)模自主網(wǎng)絡(luò)的用戶體驗(yàn)［４－６］。

在ＩｏＴ 支撐技術(shù)的推動(dòng)下，到２０２５ 年ＩｏＴ 設(shè)備連接數(shù)預(yù)計(jì)將超過４００ 億［７］。ＩｏＴ 作為網(wǎng)絡(luò)物理系統(tǒng)進(jìn)行通信和交互，在智能家居、智能醫(yī)療、工業(yè)系統(tǒng)、監(jiān)控設(shè)備、精準(zhǔn)農(nóng)業(yè)等場景得到廣泛應(yīng)用［８－１３］。然而，部署大量的ＩｏＴ 設(shè)備既昂貴又耗時(shí)，這對確定ＩｏＴ 節(jié)點(diǎn)及其部署位置帶來了巨大挑戰(zhàn)［１２］。此外，ＩｏＴ 設(shè)備需要根據(jù)感測時(shí)間、位置和功率來提供數(shù)據(jù)。因此，需要一個(gè)框架來提供基于ＩｏＴ 的按需服務(wù)，以滿足這些不同要求的智能城市應(yīng)用?；谝陨媳尘?，ＩｏＴ 即服務(wù)（ＩｏＴ ａｓ ａ Ｓｅｒｖｉｃｅ，ＩｏＴａａＳ）的概念應(yīng)運(yùn)而生，ＩｏＴａａＳ 為用戶提供了一種以服務(wù)為中心的ＩｏＴ 體驗(yàn)，使ＩｏＴ 技術(shù)更加靈活、可擴(kuò)展、可定制，為ＩｏＴ 用戶提供各種級別的ＩｏＴ 設(shè)備訪問權(quán)限，如傳感器、執(zhí)行器和位置跟蹤設(shè)備［１４－１５］。ＩｏＴａａＳ 將與５Ｇ 服務(wù)化網(wǎng)絡(luò)架構(gòu)深度融合，提供統(tǒng)一的網(wǎng)絡(luò)與業(yè)務(wù)服務(wù)化平臺和基礎(chǔ)設(shè)施支撐，因而也需要一種支持公?；旌辖M網(wǎng)、多主體子網(wǎng)互聯(lián)的分布式自治組網(wǎng)架構(gòu)。

未來６Ｇ 網(wǎng)絡(luò)承載的用戶和業(yè)務(wù)種類、協(xié)議數(shù)量、網(wǎng)絡(luò)功能以及各功能間的連接數(shù)量等都將成倍增長，集中式、人工管理的網(wǎng)絡(luò)架構(gòu)無法滿足網(wǎng)絡(luò)的性能和規(guī)模要求。因此，６Ｇ 網(wǎng)絡(luò)將根據(jù)不同場景的需求以分布式的方式進(jìn)行部署，形成一個(gè)“集中式＋分布式”的網(wǎng)絡(luò)［１６］。６Ｇ 分布式核心網(wǎng)以其分布式架構(gòu)和強(qiáng)大的數(shù)據(jù)處理能力，為ＩｏＴ 技術(shù)帶來了新的機(jī)遇，有望攻克ＩｏＴ 設(shè)備部署和數(shù)據(jù)處理難題，進(jìn)一步推動(dòng)其發(fā)展。同時(shí)，６Ｇ 網(wǎng)絡(luò)的高可靠性和低延遲特性也將為ＩｏＴ 應(yīng)用提供更為穩(wěn)定和安全的網(wǎng)絡(luò)環(huán)境。

基于５Ｇ 系統(tǒng)架構(gòu)的專用網(wǎng)絡(luò)———５Ｇ 專網(wǎng)（Ｎｏｎ-Ｐｕｂｌｉｃ Ｎｅｔｗｏｒｋ，ＮＰＮ）分為獨(dú)立部署模式專網(wǎng)（Ｓｔａｎｄ-ａｌｏｎｅ Ｎｏｎ-Ｐｕｂｌｉｃ Ｎｅｔｗｏｒｋ，ＳＮＰＮ）和公網(wǎng)集成模式專網(wǎng)（Ｐｕｂｌｉｃ Ｎｅｔｗｏｒｋ Ｉｎｔｅｇｒａｔｅｄ-Ｎｏｎ-ＰｕｂｌｉｃＮｅｔｗｏｒｋ，ＰＮＩ-ＮＰＮ）［１７］。

隨著客戶對網(wǎng)絡(luò)隔離、獨(dú)立組網(wǎng)等定制化需求的不斷提升，邊緣用戶平面網(wǎng)元（Ｕｓｅｒ ＰｌａｎｅＦｕｎｃｔｉｏｎ，ＵＰＦ）、輕量級５ＧＣ 等５Ｇ 定制網(wǎng)元開始越來越多地部署至網(wǎng)絡(luò)邊緣及客戶園區(qū)，對５Ｇ 網(wǎng)絡(luò)的安全運(yùn)營帶來了巨大的挑戰(zhàn)。

而在這一變革中，６Ｇ 分布式核心網(wǎng)與ＩｏＴａａＳ的融合將發(fā)揮出巨大的潛力，成為未來ＩｏＴ 發(fā)展的重要趨勢。通過６Ｇ 分布式核心網(wǎng)的分布式架構(gòu)和強(qiáng)大的數(shù)據(jù)處理能力，ＩｏＴａａＳ 可以更加高效地解決ＩｏＴ 設(shè)備的部署和數(shù)據(jù)處理問題。同時(shí)，６Ｇ 網(wǎng)絡(luò)的高可靠性和低延遲特性也將極大地提升ＩｏＴａａＳ 的服務(wù)質(zhì)量和用戶體驗(yàn)。

ＩＭＴ-２０３０、中國聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司、中國移動(dòng)通信有限公司等多個(gè)標(biāo)準(zhǔn)化組織和研究機(jī)構(gòu)對６Ｇ 數(shù)據(jù)面進(jìn)行了研究［１６，１８－２３］，提出了各自的６Ｇ網(wǎng)絡(luò)架構(gòu)設(shè)計(jì)方案和原則。中國移動(dòng)通信有限公司率先提出了跨域、跨層、多維立體的“三體四層五面”的總體架構(gòu)為基礎(chǔ)的全服務(wù)化架構(gòu)［１６］。在控制面和用戶面的基礎(chǔ)上新增數(shù)據(jù)面、計(jì)算面和安全面，實(shí)現(xiàn)“五面”協(xié)同，以適應(yīng)分布式自治新需求新場景。

６Ｇ ＩｏＴａａＳ 統(tǒng)一組網(wǎng)系統(tǒng)中，公?；旌辖M網(wǎng)、多子網(wǎng)對等組網(wǎng)等場景需要一種靈活高效的分布式自治服務(wù)化網(wǎng)絡(luò)架構(gòu)，其中網(wǎng)絡(luò)功能的跨網(wǎng)注冊和查詢至關(guān)重要。

３ＧＰＰ 制定了５Ｇ 網(wǎng)絡(luò)的基礎(chǔ)架構(gòu)———服務(wù)化架構(gòu)（Ｓｅｒｖｉｃｅ-Ｂａｓｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ，ＳＢＡ），５Ｇ 核心網(wǎng)控制面采用服務(wù)化架構(gòu)設(shè)計(jì)。服務(wù)注冊與服務(wù)發(fā)現(xiàn)對于５Ｇ 核心網(wǎng)至關(guān)重要，為各個(gè)微服務(wù)提供了動(dòng)態(tài)、自動(dòng)化的連接和管理能力，增強(qiáng)了服務(wù)間通信的靈活性和可靠性。服務(wù)注冊將網(wǎng)絡(luò)功能（ＮｅｔｗｏｒｋＦｕｎｃｔｉｏｎ，ＮＦ）信息注冊到網(wǎng)絡(luò)存儲功能（ＮｅｔｗｏｒｋＲｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ，ＮＲＦ），每個(gè)網(wǎng)元ＮＦ 都有一個(gè)唯一的標(biāo)識符，并包含其運(yùn)行狀態(tài)、ＩＰ 地址、端口等信息。通過將這些信息注冊到ＮＲＦ，其他服務(wù)可以查詢并找到需要調(diào)用的服務(wù)實(shí)例ＮＦ。

針對分布式網(wǎng)絡(luò)架構(gòu)下的中間轉(zhuǎn)發(fā)ＮＲＦ 訂閱過程中，ＮＦ 服務(wù)發(fā)現(xiàn)、訂閱等流程中由于涉及跨網(wǎng)絡(luò)節(jié)點(diǎn)的多個(gè)分層網(wǎng)元間的數(shù)據(jù)交互和獲取，存在流程復(fù)雜和時(shí)延較大的問題，提出了基于語義的ＪＳＯＮ 數(shù)據(jù)存儲方法和基于Ｂ＋樹結(jié)構(gòu)的索引方法。

１ 基于分布式自治數(shù)據(jù)面的復(fù)合ＮＲＦ 互聯(lián)

在同一公共陸基移動(dòng)網(wǎng)（Ｐｕｂｌｉｃ Ｌａｎｄ ＭｏｂｉｌｅＮｅｔｗｏｒｋ，ＰＬＭＮ）網(wǎng)絡(luò)中，將ＮＲＦ 網(wǎng)元根據(jù)地理位置和承載的業(yè)務(wù)量劃分為不同層級的ＮＲＦ［２４］，例如ＮＲＦ-Ｗｅｓｔ、ＮＲＦ-Ｎｏｒｔｈ 等和邊緣網(wǎng)絡(luò)ＮＲＦ-Ｅｄｇｅ，如圖１ 所示［２４］。

除了最上層的一級ＮＲＦ-ＰＬＭＮ 外，選取性能較好的ＮＲＦ 固定為二級ＮＲＦ，其中ＮＲＦ-Ｗｅｓｔ、ＮＲＦ-Ｓｏｕｔｈ、ＮＲＦ-Ｅａｓｔ、ＮＲＦ-Ｎｏｒｔｈ 均屬于二級ＮＲＦ，其他ＮＲＦ 均為ＮＲＦ-Ｅｄｇｅ，每個(gè)ＮＲＦ-Ｅｄｇｅ 都是方位ＮＲＦ 的子節(jié)點(diǎn)，根據(jù)地理位置分屬于其中一個(gè)二級ＮＲＦ 的子節(jié)點(diǎn)。

圖２ 和圖３ 展示了分層ＮＲＦ 服務(wù)發(fā)現(xiàn)、服務(wù)訂閱的流程，向ＮＲＦ-Ｗｅｓｔ 發(fā)送服務(wù)訂閱、服務(wù)發(fā)現(xiàn)請求，如果能找到ＮＲＦ-Ｗｅｓｔ 對應(yīng)的ＮＲＦ-Ｅｄｇｅ，則進(jìn)行下一步的服務(wù)訂閱請求和服務(wù)發(fā)現(xiàn)請求；如果不能找到ＮＲＦ-Ｗｅｓｔ 下一級對應(yīng)的ＮＲＦ-Ｅｄｇｅ，則說明對應(yīng)ＮＲＦ-Ｅｄｇｅ 不在ＮＲＦ-Ｗｅｓｔ 的子樹上，則向ＮＲＦ-ＰＬＭＮ請求其他的ＮＲＦ 網(wǎng)元，再進(jìn)行下一級的查詢。

在分布式數(shù)據(jù)面設(shè)計(jì)中，使用分布式數(shù)據(jù)庫進(jìn)行數(shù)據(jù)的存儲，相較于傳統(tǒng)的每個(gè)ＮＲＦ 單獨(dú)維護(hù)一份ＪＳＯＮ 數(shù)據(jù)庫來存儲數(shù)據(jù)的方案，數(shù)據(jù)不再局限于單一的ＮＲＦ ＪＳＯＮ 文件內(nèi)，而是通過網(wǎng)絡(luò)架構(gòu)中多個(gè)ＮＲＦ 構(gòu)成的集群，智能地將數(shù)據(jù)分散存儲在不同的節(jié)點(diǎn)之上。圖４ 展示了分布式數(shù)據(jù)庫的信令流程，在進(jìn)行服務(wù)發(fā)現(xiàn)時(shí)，會話管理功能（Ｓｅｓｓｉｏｎ Ｍａｎ-ａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ，ＳＭＦ）或接入、移動(dòng)性管理功能（Ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ，ＡＭＦ）ＭＦ向ＮＲＦ１ 發(fā)送請求，ＮＲＦ１ 查找對應(yīng)的ＮＲＦ，如果ＮＲＦ２ 符合要求，能夠查詢到對應(yīng)存儲的信息，就停止查詢，返回響應(yīng)；否則將繼續(xù)向下一級ＮＲＦ 發(fā)送請求，并重復(fù)該步驟直至查詢到合適的ＮＲＦ。

既往的逐級服務(wù)發(fā)現(xiàn)流程涉及向外廣播和泛洪機(jī)制，不僅耗時(shí)較長，還可能引發(fā)信令風(fēng)暴，影響網(wǎng)絡(luò)性能和穩(wěn)定性。為了解決這一問題，設(shè)計(jì)了專門針對于ＮＲＦ 的分布式數(shù)據(jù)面。

基于數(shù)據(jù)面的分布式ＮＲＦ 設(shè)計(jì)中，并不是每個(gè)ＮＲＦ 將數(shù)據(jù)單獨(dú)存儲在每一級的ＮＲＦ 中，而是將多個(gè)ＮＲＦ 構(gòu)成一個(gè)集群，將數(shù)據(jù)通過集群存儲到不同的節(jié)點(diǎn)上，實(shí)現(xiàn)了數(shù)據(jù)在集群不同節(jié)點(diǎn)上的高效分布與冗余備份，如圖５ 所示。這種方式不僅提高了數(shù)據(jù)的可用性和持久性，還大幅增強(qiáng)了數(shù)據(jù)的處理能力和訪問效率。

２ 面向復(fù)合ＮＲＦ 互聯(lián)的分布式自治數(shù)據(jù)面關(guān)鍵技術(shù)

在設(shè)計(jì)和構(gòu)建核心網(wǎng)數(shù)據(jù)面時(shí)，需要考慮如何實(shí)現(xiàn)良好的存儲和查詢機(jī)制。分布式數(shù)據(jù)面通常采用分布式數(shù)據(jù)庫來實(shí)現(xiàn)高效的數(shù)據(jù)存儲和查詢。

圖６ 展示了Ｆｒｅｅ５ＧＣ 系統(tǒng)中ＭｏｎｇｏＤＢ 存儲的ＮＲＦ 數(shù)據(jù)ＮＦＰｒｏｆｉｌｅ． ｊｓｏｎ 的格式和內(nèi)容，ＮＦＰｒｏｆｉｌｅ．ｊｓｏｎ 是存儲各個(gè)網(wǎng)元信息服務(wù)注冊、服務(wù)發(fā)現(xiàn)所需信息的ＪＳＯＮ 數(shù)據(jù)庫。

本文采用Ｒｅｄｉｓ 作為分布式自治數(shù)據(jù)面的支撐數(shù)據(jù)庫，使用ｋｅｙ：ｖａｌｕｅ 鍵值對對數(shù)據(jù)進(jìn)行嵌套存儲，并使用鍵值對ｋｅｙ１：ｋｅｙ２ 或ｋｅｙ１：ｋｅｙ２：ｋｅｙ３ 進(jìn)行所需ｖａｌｕｅ 的讀取，例如可用ｎｆＳｅｒｖｉｃｅｓ：ｎｆＳｅｒｖｉｃｅＳｔａｔｕｓ 獲取其對應(yīng)的信息“ＲＥＧＩＳＴＥＲＥＤ”。

ＮＲＦ 在讀取所需數(shù)據(jù)的過程中如果僅機(jī)械地查找對應(yīng)的字符串而不關(guān)心存儲數(shù)據(jù)的語義結(jié)構(gòu)，系統(tǒng)無法直接定位到關(guān)鍵數(shù)據(jù)，只能通過ｐａｒｓｅｒ 找到對應(yīng)數(shù)據(jù)的部分，需要遍歷整個(gè)數(shù)據(jù)集來尋找匹配的信息，顯著增加查詢的響應(yīng)時(shí)間。

如果沒有ｋｅｙ ｓｃｈｅｍａ 的關(guān)鍵信息指引，在查找ＮＦ 信息時(shí)只能先將ＪＳＯＮ 文件進(jìn)行序列和反序列化后進(jìn)行讀取，無論讀取的數(shù)據(jù)有多少，都需要進(jìn)行序列和反序列化這一過程。若ＪＳＯＮ 文件較大，將會浪費(fèi)較多時(shí)間，故需進(jìn)一步優(yōu)化存儲、查詢機(jī)制，需要針對鍵的語義進(jìn)行ｋｅｙ ｓｅｍａｎｔｉｃ 設(shè)計(jì)。

基于上述要求，使用ｎｆＩｎｓｔａｎｃｅＩｄ 和ｎｆＴｙｐｅ 兩個(gè)ｋｅｙ 聯(lián)合進(jìn)行數(shù)據(jù)索引，其中ｎｆＩｎｓｔａｎｃｅＩｄ 為主鍵，ｎｆＴｙｐｅ 輔助進(jìn)行數(shù)據(jù)的查詢。在ｕｒｉｌｉｓｔ． ｊｓｏｎ 文件中根據(jù)ｎｆＴｙｐｅ 進(jìn)行ｎｆＩｎｓｔａｎｃｅＩｄ 數(shù)據(jù)的存儲，集合中“ｈｒｅｆ”ｋｅｙ 下，每種類型的消費(fèi)網(wǎng)元會存儲各個(gè)類型網(wǎng)元的ｎｆＩｎｓｔａｎｃｅＩｄ。

在Ｆｒｅｅ５ＧＣ 中，ｎｆＩｎｓｔａｎｃｅＩｄ 是通過通用唯一識別碼（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ，ＵＵＩＤ）生成的。ＵＵＩＤ是基于時(shí)間戳、計(jì)算機(jī)的ＭＡＣ 地址、隨機(jī)數(shù)等因素生成的一個(gè)１２８ 位的唯一標(biāo)識符，可以用作主鍵。

使用哈希（Ｈａｓｈ）函數(shù)對鍵ｎｆＩｎｓｔａｎｃｅＩｄ 的值進(jìn)行處理，得到長度相等的１２８ 位Ｈａｓｈ 值，例如Ｈａｓｈ（ｎｆＩｎｓｔａｎｃｅＩｄ）。鍵“＿ｌｉｎｋ”對應(yīng)的值是一個(gè)嵌套的鍵值對，“ｉｔｅｍ”為該結(jié)構(gòu)的鍵，其對應(yīng)的值為包含多個(gè)鍵值對的數(shù)組。

以ＡＭＦ 網(wǎng)元為例，鍵值對數(shù)組存放的資源是名為Ｎｎｒｆ-ｎｆｍ 的服務(wù)的ＡＰＩ 的ｖ１ 版本中的一個(gè)ＮＦ實(shí)例資源，具體的實(shí)例標(biāo)識符分別為是“３６ａａｂ８５４-ｅ７ｅｅ-４ｆ４５-ａ０５ａ-ｄｆｃ２５ｅｄ３３ｆ０６ ”和“００６ｃ８ｆ３ａ-０２ｂ４-４ｆｄ２-ｂ９２ｅ-７８５６ｂｃ８ｄ３ａ１５”。

在Ｒｅｄｉｓ 中存儲數(shù)據(jù)和在ＭｏｎｇｏＤＢ 中很相似，將６Ｇ 數(shù)據(jù)的數(shù)據(jù)標(biāo)識、數(shù)據(jù)名或數(shù)據(jù)其他屬性等作為ｋｅｙ，數(shù)據(jù)本身作為ｖａｌｕｅ 存儲在Ｉｎｄｅｘ 標(biāo)識的數(shù)據(jù)存儲節(jié)點(diǎn)上。并使用某個(gè)Ｈａｓｈ（）將ｋｅｙ 值映射到一個(gè)Ｉｎｄｅｘ 上，即Ｈａｓｈ（ｋｅｙ）＝ Ｉｎｄｅｘ，并將與這個(gè)鍵值對應(yīng)的值存儲到Ｉｎｄｅｘ 所標(biāo)記的存儲節(jié)點(diǎn)中。查找ｋｅｙ 所對應(yīng)的ｖａｌｕｅ 值時(shí)，只需要做一次Ｈａｓｈ 運(yùn)算就可以尋址到該值所在的存儲節(jié)點(diǎn)。

３ 分布式數(shù)據(jù)面的值及其查詢設(shè)計(jì)

３． １ Ｖａｌｕｅ Ｓｃｈｅｍａ 設(shè)計(jì)

使用ｐｌｍｎＬｉｓｔ、“ｓｅｒｖｉｃｅＮａｍｅ ”：“ｎａｍｆ-ｌｏｃ ”、“ｓＮｓｓａｉｓ”，“ｓｓｔ”、“ｉｐｖ４Ａｄｄｒｅｓｓｅｓ”等信息進(jìn)行數(shù)據(jù)面的語義索引。為了增加可用性和容錯(cuò)性，使用分布式數(shù)據(jù)庫或分布式文件系統(tǒng)來存儲Ｓｃｈｅｍａ 信息。這種方法將Ｓｃｈｅｍａ 信息復(fù)制到多個(gè)節(jié)點(diǎn)上，提高了系統(tǒng)的可靠性，優(yōu)點(diǎn)如下。

（１）本地緩存

為了提高查詢效率，每個(gè)分布式數(shù)據(jù)面節(jié)點(diǎn)在本地緩存常用的Ｓｃｈｅｍａ 信息。當(dāng)接收到查詢請求時(shí)檢查本地緩存，如果命中則直接返回結(jié)果，避免遠(yuǎn)程查詢的開銷。

（２）分布式查詢

如果本地緩存未命中，節(jié)點(diǎn)需要向存儲Ｓｃｈｅｍａ信息的分布式系統(tǒng)發(fā)起查詢請求。這個(gè)請求可以通過一致性Ｈａｓｈ 或其他分片算法定位到存儲特定Ｓｃｈｅｍａ 信息的節(jié)點(diǎn)。

（３）查詢優(yōu)化

索引優(yōu)化：對Ｓｃｈｅｍａ 信息建立索引，以加快查詢速度?？梢允褂茫?樹、Ｈａｓｈ 索引等數(shù)據(jù)結(jié)構(gòu)來提高查詢效率。

緩存策略：對于頻繁查詢的Ｓｃｈｅｍａ 信息，使用緩存策略來減少查詢延遲。例如，使用最近最少使用（Ｌｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ，ＬＲＵ）算法來管理緩存。

異步更新：當(dāng)Ｓｃｈｅｍａ 信息發(fā)生變化時(shí)，使用異步更新的方式來更新各個(gè)節(jié)點(diǎn)的本地緩存，降低對查詢性能的影響。

３． ２ 分布式數(shù)據(jù)面索引與查詢

將不同節(jié)點(diǎn)的主鍵進(jìn)行Ｈａｓｈ 處理后可以得到１２８ 位Ｈａｓｈ 值，將其構(gòu)成一顆Ｂ＋樹，進(jìn)行數(shù)據(jù)索引。創(chuàng)建一個(gè)空的Ｂ＋樹，確定Ｂ＋樹的階數(shù)后，逐個(gè)將數(shù)據(jù)項(xiàng)插入到Ｂ＋樹中。插入操作通常從樹的根節(jié)點(diǎn)開始，根據(jù)鍵值大小逐級向下搜索合適的位置。如果插入位置在葉子節(jié)點(diǎn)中，直接插入數(shù)據(jù)項(xiàng)；如果插入位置在非葉子節(jié)點(diǎn)中，根據(jù)鍵值大小調(diào)整節(jié)點(diǎn)的結(jié)構(gòu)，確保子節(jié)點(diǎn)的順序正確。插入數(shù)據(jù)項(xiàng)后需要對樹進(jìn)行必要的調(diào)整，例如節(jié)點(diǎn)的分裂、合并或者更新父節(jié)點(diǎn)的鍵。

刪除節(jié)點(diǎn)時(shí)需要額外考慮數(shù)據(jù)項(xiàng)的刪除對樹結(jié)構(gòu)的影響，可能需要調(diào)整節(jié)點(diǎn)的結(jié)構(gòu)以保持Ｂ＋樹的平衡。

查詢操作通過Ｂ＋樹結(jié)構(gòu)進(jìn)行快速數(shù)據(jù)檢索。從根節(jié)點(diǎn)開始根據(jù)鍵值大小逐級向下搜索，直到找到目標(biāo)數(shù)據(jù)項(xiàng)所在的葉子節(jié)點(diǎn)。

圖７ 為Ｂ＋樹結(jié)構(gòu)圖，對主鍵ｎｆＩｎｓｔａｎｃｅＩｄ 的值進(jìn)行Ｈａｓｈ 處理，得到對應(yīng)的索引節(jié)點(diǎn)再進(jìn)行索引查詢。

４ 實(shí)驗(yàn)與分析

本次數(shù)據(jù)面結(jié)構(gòu)試驗(yàn)以Ｆｒｅｅ５ＧＣ 為基礎(chǔ)，結(jié)合３ＧＰＰ 協(xié)議進(jìn)行改造。

基于Ｒｅｄｉｓ Ｃｌｕｓｔｅｒ 平臺進(jìn)行分布式核心網(wǎng)數(shù)據(jù)面的部署，Ｒｅｄｉｓ 支持的數(shù)據(jù)結(jié)構(gòu)有字符串（Ｓｔｒｉｎｇ）、列表（Ｌｉｓｔ）、集合（Ｓｅｔ）、有序集合（Ｓｏｒｔｅｄ Ｓｅｔ）、Ｈａｓｈ、位圖（Ｂｉｔｍａｐ）、地理位置（Ｇｅｏｓｐａｔｉａｌ Ｉｎｄｅｘ）等，其中Ｈａｓｈ 為包含鍵值對的無序散列表，適用于存儲對象，使用ｋｅｙ：ｖａｌｕｅ 的方式進(jìn)行數(shù)據(jù)的存儲，Ｒｅｄｉｓ 集群請求處理流程如圖８ 所示。

４． １ 測試框架

使用Ｈａｓｈ 結(jié)構(gòu)進(jìn)行數(shù)據(jù)的存儲。采用“三主三從”的Ｒｅｄｉｓ 集群進(jìn)行實(shí)驗(yàn)，圖９ 展示了分布式核心網(wǎng)Ｒｅｄｉｓ 數(shù)據(jù)庫集群架構(gòu)。

使用ＮＲＦ 數(shù)據(jù)ＮＦＰｒｏｆｉｌｅ． ｊｓｏｎ 進(jìn)行測試，ＮＦ-Ｐｒｏｆｉｌｅ． ｊｓｏｎ 包含網(wǎng)元的注冊信息。在Ｒｅｄｉｓ 上加載ＪＳＯＮ 和Ｒｅｄｉｓｅａｒｃｈ 模塊進(jìn)行性能測試，圖１０ 為搭建的６ 個(gè)Ｒｅｄｉｓ Ｃｌｕｓｔｅｒ 容器化界面圖，圖１１ 為集群的節(jié)點(diǎn)分配。

４． ２ 測試結(jié)果

在前述研究的基礎(chǔ)上測試了Ｒｅｄｉｓ ＧＥＴ 和Ｒｅｄｉｓ ＧＥＴ 的等不同索引、查詢條件的時(shí)延進(jìn)行對比，如表１ 所示。

因?yàn)椋剩樱希?數(shù)據(jù)架構(gòu)較為復(fù)雜，處理ｎａｔｉｖｅｓｔｒｉｎｇ 查詢的時(shí)延較處理ＪＳＯＮ 數(shù)據(jù)查詢的時(shí)延短，在這里測試了簡單的ｓｔｒｉｎｇ 數(shù)據(jù)。對比第１～４ 條數(shù)據(jù)可得：加ｊｓｏｎ． ｇｅｔ 進(jìn)行整條數(shù)據(jù)的讀取相較于ｓｔｒｉｎｇ 沒有優(yōu)勢。在優(yōu)化之前的系統(tǒng)中是將ＮＦＰｒｏｆｉｌｅ 數(shù)據(jù)先轉(zhuǎn)換成字符串形式，再進(jìn)行解碼得到待查詢的值，而ｊｓｏｎ． ｇｅｔ 是根據(jù)ＪＳＯＮ 文件的內(nèi)部結(jié)構(gòu)進(jìn)行查詢的，省去了先進(jìn)行序列化再解序列化的過程，所以時(shí)延較小。在實(shí)際中，ＪＳＯＮ 數(shù)據(jù)使用較多，數(shù)據(jù)架構(gòu)也較為復(fù)雜。

對比第３～４ 條數(shù)據(jù)可得：加ｉｎｄｅｘ 相較于未加ｉｎｄｅｘ 的性能更好，但是因?yàn)槠涮砑拥氖嵌壦饕?，同時(shí)測試的數(shù)據(jù)量較小，只有幾十條字段，其性能優(yōu)勢并不是很明顯。對比第５～ ６ 條數(shù)據(jù)可得：直接使用ｊｓｏｎ． ｇｅｔ 查詢相較于使用ｎａｔｉｖｅ ｓｔｒｉｎｇ 轉(zhuǎn)化成ＪＳＯＮ 后再進(jìn)行查詢性能好很多。

對比第５～７ 條數(shù)據(jù)可得：使用ｖａｌｕｅ ｓｃｈｅｍａ 進(jìn)行所需數(shù)據(jù)的讀取性能更好，第６～ ７ 條數(shù)據(jù)時(shí)延明顯低于第５ 條。

第６ ～ ８ 條數(shù)據(jù)對比的是ｆｔ． ｓｅａｒｃｈ 的性能，ｆｔ．ｓｅａｒｃｈ 優(yōu)于ｊｓｏｎ． ｇｅｔ 的性能和ｎａｔｉｖｅ ｓｔｒｉｎｇ 的查詢性能，但在本實(shí)驗(yàn)中測試的是從所有記錄中找“＄ ． ｎｆ-Ｓｅｒｖｉｃｅｓ［*］． ｓｅｒｖｉｃｅＮａｍｅ”字段為ｎａｍｆ-ｃｏｍｍ 的所有記錄，因?yàn)椋妫簦?ｓｅａｒｃｈ 預(yù)先不知道其數(shù)據(jù)結(jié)構(gòu)，所以在查詢時(shí)是全表查詢，數(shù)據(jù)量幾十倍于ｊｓｏｎ． ｇｅｔ查詢的數(shù)據(jù)，如果直接使用ｊｓｏｎ． ｇｅｔ 單條查詢其時(shí)延要乘數(shù)據(jù)條數(shù)，所以與ｊｓｏｎ． ｇｅｔ 時(shí)延的幾十倍對比后，可以得出：ｆｔ． ｓｅａｒｃｈ 遠(yuǎn)遠(yuǎn)優(yōu)于ｊｓｏｎ． ｇｅｔ 的性能。

同時(shí)可以搭建起帶有Ｒｅｄｉｓ ＪＳＯＮ 環(huán)境的ｒｅｄｉｓ集群，節(jié)點(diǎn)狀態(tài)如圖１２ 所示。

在任意節(jié)點(diǎn)存儲信息，會自動(dòng)分配存儲的節(jié)點(diǎn)，在其他節(jié)點(diǎn)都可以讀取到，并可以以ｋｅｙ：ｖａｌｕｅ 鍵值對的形式進(jìn)行索引，如圖１３ 所示。

根據(jù)實(shí)驗(yàn)可以看出，基于分布式自治數(shù)據(jù)面的ＮＲＦ 網(wǎng)元數(shù)據(jù)存儲和索引系統(tǒng)，能夠?qū)崿F(xiàn)跨節(jié)點(diǎn)數(shù)據(jù)查詢，解決了復(fù)合ＮＲＦ 節(jié)點(diǎn)互聯(lián)時(shí)跨子網(wǎng)服務(wù)發(fā)現(xiàn)效率較低的問題，降低了數(shù)據(jù)查詢的時(shí)延，大幅增強(qiáng)了６Ｇ 分布式自治核心網(wǎng)公?；旌辖M網(wǎng)和多子網(wǎng)對等組網(wǎng)場景的組網(wǎng)效率。

５ 結(jié)束語

６Ｇ 網(wǎng)絡(luò)相較于５Ｇ 網(wǎng)絡(luò)其性能指標(biāo)有了１０ 倍到１００ 倍的提升，其高可靠性和低延遲特性也將極大地提升ＩｏＴａａＳ 的服務(wù)質(zhì)量和用戶體驗(yàn)。本文面向６Ｇ 物聯(lián)網(wǎng)混合組網(wǎng)，設(shè)計(jì)的面向數(shù)據(jù)面的ＮＲＦ網(wǎng)元數(shù)據(jù)存儲和索引系統(tǒng)，降低了分布式核心網(wǎng)中ＮＦ 信令交互復(fù)雜導(dǎo)致時(shí)延。

隨著移動(dòng)通信技術(shù)的不斷發(fā)展和應(yīng)用場景的不斷拓展，該設(shè)計(jì)后續(xù)可拓展到ＳＭＦ 和ＡＭＦ，通過其進(jìn)行分布式組網(wǎng)，可以進(jìn)一步提高６Ｇ 網(wǎng)絡(luò)的可靠性和安全性。這種分布式架構(gòu)不僅能夠應(yīng)對大規(guī)模的用戶請求和數(shù)據(jù)流量，還能確保網(wǎng)絡(luò)服務(wù)的連續(xù)性和穩(wěn)定性。

致 謝

感謝清華大學(xué)－中國移動(dòng)通信集團(tuán)有限公司聯(lián)合研究院對該研究的支持。

參考文獻(xiàn)

［１］ 郎為民，安海燕，余亮琴，等． ６Ｇ 關(guān)鍵技術(shù)分析和典型場景應(yīng)用［Ｊ］． 電信快報(bào)，２０２３（８）：１－５．

［２］ 賽迪智庫無線電研究所． ６Ｇ 概念及愿景白皮書［Ｒ］．北京：賽迪智庫無線電研究所，２０２０．

［３］ 趙媛． ＩＴＵ 完成６Ｇ 框架和總體目標(biāo)建議書［Ｎ］． 人民郵電報(bào)，２０２３－０６－２６（１）.

［４］ ＧＵＩ Ｇ，ＬＩＵ Ｍ，ＴＡＮＧ Ｆ Ｘ，ｅｔ ａｌ． ６Ｇ：Ｏｐｅｎｉｎｇ Ｎｅｗ Ｈｏｒｉｚｏｎｓ ｆｏｒ Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ Ｃｏｍｆｏｒｔ，Ｓｅｃｕｒｉｔｙ，ａｎｄ Ｉｎｔｅｌｌｉｇｅｎｃｅ［Ｊ ］． ＩＥＥＥ Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，２０２０，２７ （５ ）：１２６－１３２．

［５］ ＢＡＲＩＡＨ Ｌ，ＭＯＨＪＡＺＩ Ｌ，ＭＵＨＡＩＤＡＴ Ｓ，ｅｔ ａｌ． Ａ Ｐｒｏｓｐｅｃｔｉｖｅ Ｌｏｏｋ：Ｋｅｙ Ｅｎａｂｌｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ａｐｐｌｉｃａｔｉｏｎｓ，ａｎｄ Ｏｐｅｎ Ｒｅｓｅａｒｃｈ Ｔｏｐｉｃｓ ｉｎ ６Ｇ Ｎｅｔｗｏｒｋｓ ［Ｊ］． ＩＥＥＥＡｃｃｅｓｓ，２０２０，８：１７４７９２－１７４８２０．

［６］ ＹＯＵ Ｘ Ｈ，ＷＡＮＧ Ｃ Ｘ，ＨＵＡＮＧ Ｊ，ｅｔ ａｌ． Ｔｏｗａｒｄｓ ６ＧＷｉｒｅｌｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋｓ：Ｖｉｓｉｏｎ，Ｅｎａｂｌｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ，ａｎｄ Ｎｅｗ Ｐａｒａｄｉｇｍ Ｓｈｉｆｔｓ［Ｊ］． Ｓｃｉｅｎｃｅ Ｃｈｉｎａ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｃｉｅｎｃｅｓ，２０２１，６４（１）：１１０３０１． １－１１０３０１． ７４．

［７］ ＨＯＱＵＥ Ｍ Ａ，ＨＯＳＳＡＩＮ Ｍ，ＮＯＯＲ Ｓ，ｅｔ ａｌ． ＩｏＴａａＳ：Ｄｒｏｎｅｂａｓｅｄ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ ａｓ ａ Ｓｅｒｖｉｃｅ Ｆｒａｍｅｗｏｒｋｆｏｒ Ｓｍａｒｔ Ｃｉｔｉｅｓ ［Ｊ］． ＩＥＥＥ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ Ｊｏｕｒｎａｌ，２０２２，９（１４）：１２４２５－１２４３９．

［８］ ＨＯＳＳＡＩＮ Ｍ Ｓ，ＲＡＨＭＡＮ Ｍ Ａ，ＭＵＨＡＭＭＡＤ Ｇ．Ｔｏｗａｒｄｓ Ｅｎｅｒｇｙａｗａｒｅ Ｃｌｏｕｄｏｒｉｅｎｔｅｄ ＣｙｂｅｒｐｈｙｓｉｃａｌＴｈｅｒａｐｙ Ｓｙｓｔｅｍ［Ｊ］． Ｆｕｔｕｒｅ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ，２０２０，１０５：８００－８１３．

［９］ ＡＬＨＵＳＳＥＩＮ Ｍ． Ｍｏｎｉｔｏｒｉｎｇ Ｐａｒｋｉｎｓｏｎ’ｓ Ｄｉｓｅａｓｅ ｉｎ ＳｍａｒｔＣｉｔｉｅｓ［Ｊ］． ＩＥＥＥ Ａｃｃｅｓｓ，２０１７，５：１９８３５－１９８４１．

［１０］ＢＩＴＡＭ Ｓ，ＭＥＬＬＯＵＫ Ａ． Ｂｉｏｉｎｓｐｉｒｅｄ Ｒｏｕｔｉｎｇ Ｐｒｏｔｏｃｏｌｓｆｏｒ Ｖｅｈｉｃｕｌａｒ Ａｄ Ｈｏｃ Ｎｅｔｗｏｒｋｓ［Ｍ］． Ｌｏｎｄｏｎ：Ｗｉｌｅｙ，２０１４．

［１１］ＡＬＳＵＬＴＡＮ Ｓ，ＡＬＤＯＯＲＩ Ｍ Ｍ，ＡＬＢＡＹＡＴＴＩ Ａ Ｈ，ｅｔａｌ． Ａ Ｃｏｍｐｒｅｈｅｎｓｉｖｅ Ｓｕｒｖｅｙ ｏｎ Ｖｅｈｉｃｕｌａｒ Ａｄ ＨｏｃＮｅｔｗｏｒｋ［Ｊ］． Ｊｏｕｒｎａｌ ｏｆ Ｎｅｔｗｏｒｋ ａｎｄ Ｃｏｍｐｕｔｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ，２０１４，３７：３８０－３９２．

［１２］ＪＩＡＮＧ Ｔ Ｇ，ＦＡＮＧ Ｈ，ＷＡＮＧ Ｈ． ＢｌｏｃｋｃｈａｉｎｂａｓｅｄＩｎｔｅｒｎｅｔ ｏｆ Ｖｅｈｉｃｌｅｓ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｎｅｔｗｏｒｋ Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄＰｅｒｆｏｒｍａｎｃｅ Ａｎａｌｙｓｉｓ［Ｊ］． ＩＥＥＥ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ Ｊｏｕｒｎａｌ，２０１９，６（３）：４６４０－４６４９．

［１３］ＭＡＨＭＵＤ Ｍ Ｓ，ＦＡＮＧ Ｈ，ＷＡＮＧ Ｈ． Ａｎ Ｉｎｔｅｇｒａｔｅｄ Ｗｅａｒａｂｌｅ Ｓｅｎｓｏｒ ｆｏｒ Ｕｎｏｂｔｒｕｓｉｖｅ Ｃｏｎｔｉｎｕｏｕｓ Ｍｅａｓｕｒｅｍｅｎｔ ｏｆＡｕｔｏｎｏｍｉｃ Ｎｅｒｖｏｕｓ Ｓｙｓｔｅｍ［Ｊ］． ＩＥＥＥ Ｉｎｔｅｒｎｅｔ ｏｆ ＴｈｉｎｇｓＪｏｕｒｎａｌ，２０１９，６（１）：１１０４－１１１３．

［１４］ＳＵＮ Ｌ，ＬＩ Ｙ，ＲＡＨＥＥＬＡＨＭＥＤ Ｍ． Ａｎ Ｏｐｅｎ ＩｏＴ Ｆｒａｍｅｗｏｒｋ Ｂａｓｅｄ ｏｎ Ｍｉｃｒｏｓｅｒｖｉｃｅｓ Ａｒｃｈｉｔｅｃｔｕｒｅ ［Ｊ ］． ＣｈｉｎａＣｏｍｍｕｎｉｃａｔｉｏｎｓ，２０１７，１４（２）：１５４－１６２．

［１５］ＫＲＹＬＯＶＳＫＩＹ Ａ，ＪＡＨＮ Ｍ，ＰＡＴＴＩ Ｅ． Ｄｅｓｉｇｎｉｎｇ ａ ＳｍａｒｔＣｉｔｙ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ Ｐｌａｔｆｏｒｍ ｗｉｔｈ Ｍｉｃｒｏｓｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ［Ｃ］∥２０１５ ３ｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ ＦｕｔｕｒｅＩｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ ａｎｄ Ｃｌｏｕｄ． Ｒｏｍｅ：ＩＥＥＥ，２０１５：２５－３０．

［１６］中國移動(dòng)通信有限公司，北京航空航天大學(xué)，廣東省新一代通信與網(wǎng)絡(luò)創(chuàng)新研究院，等． ６Ｇ 網(wǎng)絡(luò)架構(gòu)白皮書［Ｒ］． 北京：中國移動(dòng)通信有限公司，２０２３．

［１７］中國電信集團(tuán)有限公司． 中國電信５Ｇ 混合專網(wǎng)增強(qiáng)架構(gòu)白皮書［Ｒ］． 北京：中國電信集團(tuán)有限公司，２０２２．

［１８］ＩＭＴ-２０３０ （６Ｇ）推進(jìn)組． ６Ｇ 數(shù)據(jù)面架構(gòu)研究報(bào)告［Ｒ］．北京：ＩＭＴ-２０３０ （６Ｇ）推進(jìn)組，２０２３．

［１９］中國聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司． ６Ｇ 網(wǎng)絡(luò)體系架構(gòu)白皮書［Ｒ］． 北京：中國聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司，２０２３．

［２０］ Ｎｅｘｔ Ｇ Ａｌｌｉａｎｃｅ． ６Ｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ ｆｏｒ Ｗｉｄｅ-ａｒｅａ ＣｌｏｕｄＥｖｏｌｕｔｉｏｎ［Ｒ］． Ｗａｓｈｉｎｇｔｏｎ Ｄ． Ｃ． ：Ｎｅｘｔ Ｇ Ａｌｌｉａｎｃｅ，２０２３．

［２１］Ｎｅｘｔ Ｇ Ａｌｌｉａｎｃｅ． Ｎｅｘｔ Ｇ Ａｌｌｉａｎｃｅ Ｒｅｐｏｒｔ：６Ｇ ＤｉｓｔｒｉｂｕｔｅｄＣｌｏｕｄ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ ［Ｒ］． Ｗａｓｈｉｎｇｔｏｎ Ｄ． Ｃ． ：Ｎｅｘｔ Ｇ Ａｌｌｉａｎｃｅ，２０２２．

［２２］中國電信集團(tuán)有限公司，中興通訊股份有限公司． 未來移動(dòng)核心網(wǎng)演進(jìn)趨勢白皮書［Ｒ］． 北京：中國電信集團(tuán)有限公司，２０２３．

［２３］張皓然． 基于微服務(wù)的５Ｇ 核心網(wǎng)管理與編排技術(shù)研究［Ｄ］． 西安：西安電子科技大學(xué)，２０２２．

［２４］ ＳＨＥＫＨＡＲ Ｒ，ＳＥＴＨ Ｓ，ＢＨＡＴＥ Ｓ，ｅｔ ａｌ． Ｔｅｃｈｎｉｑｕｅｓ ｔｏＦａｃｉｌｉｔａｔｅ Ｓｅｌｅｃｔｉｏｎ ｏｆ Ｎｅｘｔ ＨＯＰ ＮＲＦ ｉｎ ａ ＨｉｅｒａｒｃｈｉｃａｌＮｅｔｗｏｒｋ Ｒｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ （ＮＲＦ）Ｄｅｐｌｏｙｍｅｎｔ ｉｎ ５ＧＮｅｔｗｏｒｋｓ［ＥＢ／ ＯＬ］． （２０２１ －０３ －１２）［２０２４ － ０４ － ０７］ｈｔｔｐｓ：∥ｗｗｗ． ｔｄｃｏｍｍｏｎｓ． ｏｒｇ／ ｄｐｕｂｓ＿ｓｅｒｉｅｓ／４１４８．

作者簡介：

郭欣雨 女，（１９９８—），碩士研究生。主要研究方向：６Ｇ 核心網(wǎng)、數(shù)據(jù)面。

（*通信作者）徐 湛 男，（１９８２—），博士，教授。主要研究方向：寬帶無線通信。

田志剛 男，（１９７８—），博士，高級工程師。主要研究方向：６Ｇ 網(wǎng)絡(luò)架構(gòu)、ＮＰＮ 網(wǎng)絡(luò)架構(gòu)、網(wǎng)絡(luò)安全架構(gòu)。

基金項(xiàng)目：國家重點(diǎn)研發(fā)計(jì)劃（２０２２ＹＦＣ３３０ ／２０２）