摘要：出了一種基于虛擬化網(wǎng)絡(luò)和軟件定義網(wǎng)絡(luò)（SDN）的虛擬核心網(wǎng)架構(gòu)，該架構(gòu)簡化了核心網(wǎng)的接口和協(xié)議，融合了業(yè)務(wù)鏈的處理，還引入智能化管理模塊，可以支持未來移動(dòng)網(wǎng)絡(luò)的自動(dòng)化部署、自動(dòng)配置、自優(yōu)化、自愈等功能，從而更好地支持了5G復(fù)雜多變的不同場(chǎng)景。另外，該架構(gòu)將核心網(wǎng)功能集成，將處理模塊和用戶上下文分開，從而能更好地支持核心網(wǎng)的分布式處理。

關(guān)鍵詞： 5G核心網(wǎng)；虛擬化；SDN；業(yè)務(wù)鏈；智能管理

Abstract： In this paper， a virtual core network architecture based on virtual network and software-defined network （SDN） is proposed. This architecture simplifies the interface and protocol of core network and integrates service chain management. This architecture also has an intelligent management module that supports future mobile network automation deployment， automatic configuration， self optimization， self-healing and other functions. In this way， it can better support the complex and changeable scenarios of 5G. In addition， this architecture integrates the functions of core network and separates the processing module and the user context in order to better support core network distributed processing.

5G core network； virtualization； SDN； service chain； intelligent management

面向未來移動(dòng)通信的5G網(wǎng)絡(luò)將是一個(gè)支持更快速度、更短時(shí)延、更多用戶、更高速移動(dòng)性的網(wǎng)絡(luò)，它將支持超密集網(wǎng)絡(luò)、超可靠通信及大規(guī)模機(jī)器終端的接入。5G網(wǎng)絡(luò)需求不僅僅對(duì)無線技術(shù)是個(gè)挑戰(zhàn)，對(duì)移動(dòng)核心網(wǎng)同樣提出了更高的要求。

云計(jì)算、軟件定義網(wǎng)絡(luò)（SDN）等新技術(shù)是對(duì)IT產(chǎn)業(yè)的一次革命，它們同樣也為未來移動(dòng)通信提供了新的可能和機(jī)遇。隨著云計(jì)算在IT界的興起，傳統(tǒng)電信運(yùn)營商很快意識(shí)到該技術(shù)的優(yōu)勢(shì)，并希望將它引入傳統(tǒng)電信網(wǎng)絡(luò)。電信運(yùn)營商聯(lián)合設(shè)備制造商、IT廠商在歐洲電信標(biāo)準(zhǔn)化協(xié)會(huì)（ETSI）成立了網(wǎng)絡(luò)功能虛擬化（NFV）工作組，討論如何利用虛擬化技術(shù)在通用云計(jì)算平臺(tái)上實(shí)現(xiàn)傳統(tǒng)電信設(shè)備的功能。ETSI NFV定義了基于網(wǎng)絡(luò)虛擬化技術(shù)的管理和編排（MANO）架構(gòu)[1]，使用該架構(gòu)可方便地將電信網(wǎng)絡(luò)中物理網(wǎng)元虛擬化。

SDN技術(shù)則是對(duì)傳輸網(wǎng)絡(luò)的一次革命。在傳統(tǒng)交換機(jī)中，控制面和轉(zhuǎn)發(fā)面是緊耦合的。交換機(jī)行為的改變需要復(fù)雜的配置，有時(shí)甚至需要修改交換機(jī)軟件。SDN架構(gòu)將現(xiàn)有傳輸網(wǎng)絡(luò)中的控制面和轉(zhuǎn)發(fā)面分離，使得底層架構(gòu)對(duì)上層應(yīng)用和網(wǎng)絡(luò)服務(wù)抽象為一個(gè)邏輯實(shí)體，管理人員可通過編寫應(yīng)用程序（APP）控制轉(zhuǎn)發(fā)面的行為[2]。

除了上述的網(wǎng)絡(luò)虛擬化技術(shù)和SDN技術(shù)之外，業(yè)務(wù)鏈也是核心網(wǎng)演進(jìn)的熱門技術(shù)之一。業(yè)務(wù)服務(wù)器是運(yùn)營商用來對(duì)用戶數(shù)據(jù)流進(jìn)行優(yōu)化和提供增值業(yè)務(wù)的重要手段。在現(xiàn)有網(wǎng)絡(luò)中，業(yè)務(wù)服務(wù)器和底層傳輸網(wǎng)絡(luò)緊耦合，導(dǎo)致網(wǎng)絡(luò)配置不靈活，擴(kuò)展性不好。業(yè)務(wù)服務(wù)器通常是插入到傳輸路徑上的，當(dāng)加入新的業(yè)務(wù)服務(wù)器時(shí)需要對(duì)網(wǎng)絡(luò)拓?fù)渥龀龈淖?。并且，為了簡化配置，業(yè)務(wù)服務(wù)器常常按固定順序串聯(lián)在傳輸路徑上，所有數(shù)據(jù)流都按事先設(shè)定的固定順序流經(jīng)所有串聯(lián)的業(yè)務(wù)服務(wù)器，不管數(shù)據(jù)流是否需要被業(yè)務(wù)服務(wù)器處理。在這種架構(gòu)中，業(yè)務(wù)鏈組合不靈活，增加或修改業(yè)務(wù)服務(wù)器配置復(fù)雜，不利于創(chuàng)新業(yè)務(wù)的開展[3]。

全球很多標(biāo)準(zhǔn)組織均已開始考慮如何將網(wǎng)絡(luò)虛擬化和SDN等新技術(shù)應(yīng)用到移動(dòng)網(wǎng)絡(luò)中。例如，開放式網(wǎng)絡(luò)基金會(huì)（ONF）的“Wireless & Mobile”工作組正在討論如何將SDN與移動(dòng)網(wǎng)絡(luò)結(jié)合：利用SDN技術(shù)可將移動(dòng)核心網(wǎng)中的用戶面轉(zhuǎn)發(fā)功能集成到支持SDN的交換機(jī)中實(shí)現(xiàn)。除此之外，中國通信標(biāo)準(zhǔn)化協(xié)會(huì)（CCSA）、IMT-2020等組織也有相關(guān)的討論。

然而，在當(dāng)前的討論中，網(wǎng)絡(luò)虛擬化與移動(dòng)網(wǎng)絡(luò)的結(jié)合常常只是簡單地將4G網(wǎng)絡(luò)的物理網(wǎng)元進(jìn)行虛擬化。SDN與移動(dòng)網(wǎng)絡(luò)的結(jié)合則傾向于簡單地將移動(dòng)網(wǎng)絡(luò)中的公用數(shù)據(jù)網(wǎng)網(wǎng)關(guān)（PDN GW）、服務(wù)GW劃分為轉(zhuǎn)發(fā)功能和控制功能，并將轉(zhuǎn)發(fā)功能放到SDN架構(gòu)中的交換機(jī)中實(shí)現(xiàn)，而控制功能則作為SDN 控制器上的應(yīng)用，通過SDN控制器控制位于交換機(jī)中的轉(zhuǎn)發(fā)功能。這樣的結(jié)合除了將網(wǎng)元進(jìn)行了虛擬化之外對(duì)4G核心網(wǎng)未做任何優(yōu)化。

1 基于4G架構(gòu)的核心網(wǎng)

虛擬化

在4G網(wǎng)絡(luò)架構(gòu)中，核心網(wǎng)由一系列物理網(wǎng)元組成，這些物理網(wǎng)元間通過標(biāo)準(zhǔn)化的接口互相通信。4G網(wǎng)絡(luò)架構(gòu)是控制面和用戶面分離的架構(gòu)，其中移動(dòng)管理實(shí)體（MME）、服務(wù)GPRS支持節(jié)點(diǎn)（SGSN）、歸屬簽約用戶服務(wù)器（HSS）、策略和計(jì)費(fèi)規(guī)則功能（PCRF）等是控制面網(wǎng)元，負(fù)責(zé)用戶接入管理、鑒權(quán)、移動(dòng)性管理、會(huì)話管理、策略控制等功能。服務(wù)網(wǎng)關(guān)（SGW）、PDN GW是用戶面網(wǎng)元，主要負(fù)責(zé)用戶數(shù)據(jù)包的轉(zhuǎn)發(fā)、隧道管理功能、地址管理等功能。盡管4G網(wǎng)絡(luò)架構(gòu)是控制面和用戶面分離的架構(gòu)，SGW和PDN GW中仍然有部分控制面的功能，這部分功能負(fù)責(zé)會(huì)話管理、IP地址分配、用戶面GTP隧道的建立等。

在核心網(wǎng)虛擬化時(shí)，最簡單的做法是將4G網(wǎng)絡(luò)架構(gòu)的物理網(wǎng)元分別虛擬化，即在通用硬件（如x86）和軟件（如VmWare）平臺(tái)上分別實(shí)現(xiàn)MME、SGSN、HSS、PCRF等控制面網(wǎng)元的功能。將用戶面網(wǎng)元SGW和PDN GW拆分成GW控制面功能和GW轉(zhuǎn)發(fā)面功能，并將其中的GW轉(zhuǎn)發(fā)面功能集成到SDN交換設(shè)備中；SGW、PDN GW的控制面功能虛擬化為GW控制器。虛擬化的GW控制器通過SDN接口協(xié)議（如Open Flow協(xié)議）控制SDN交換設(shè)備中的GW轉(zhuǎn)發(fā)面。對(duì)應(yīng)的架構(gòu)如圖1所示。

在圖1中，GW控制器負(fù)責(zé)GW轉(zhuǎn)發(fā)面位置的選擇及一般隧道協(xié)議（GTP）隧道的建立。GW控制器接受MME/SGSN的會(huì)話建立請(qǐng)求，并選擇適合的OFS作為該會(huì)話的GW轉(zhuǎn)發(fā)面。GW 控制器分配GTP隧道信息，建立該會(huì)話的轉(zhuǎn)發(fā)表，并通過SDN 控制器將該轉(zhuǎn)發(fā)表發(fā)送給OFS。

在該架構(gòu)中，GW 控制器與SGSN/MME間可采用現(xiàn)成的S4/S11接口進(jìn)行通信，對(duì)4G架構(gòu)和流程沒有影響。

2 核心網(wǎng)架構(gòu)的進(jìn)一步演進(jìn)

2.1 集成的虛擬核心網(wǎng)架構(gòu)

核心網(wǎng)虛擬化是建立在“不改變4G架構(gòu)”的假設(shè)的基礎(chǔ)上的。但在4G架構(gòu)設(shè)計(jì)之初，設(shè)計(jì)者假定網(wǎng)元是物理網(wǎng)元，4G架構(gòu)的設(shè)計(jì)未針對(duì)虛擬化平臺(tái)做優(yōu)化。在虛擬化平臺(tái)上，網(wǎng)元間的數(shù)據(jù)可共享，這可大大減少網(wǎng)元間的接口和信令交互，降低時(shí)延、提高效率。并且，在虛擬化平臺(tái)上，通過軟件實(shí)現(xiàn)核心網(wǎng)網(wǎng)元的功能，比之前既要設(shè)計(jì)硬件又要在該專用硬件平臺(tái)上設(shè)計(jì)軟件容易得多。軟件化可能會(huì)改變商業(yè)模式，一個(gè)集成的核心網(wǎng)軟件包是一種可能的實(shí)現(xiàn)方式。集成的核心網(wǎng)軟件包的優(yōu)點(diǎn)是少了網(wǎng)元間的接口，簡化了流程，從而降低了時(shí)延和系統(tǒng)復(fù)雜度。

圖2所示為集成的虛擬化核心網(wǎng)。在圖中，上下文和簽約模塊保存用戶上下文以及用戶簽約數(shù)據(jù)，核心網(wǎng)控制功能（CCF）負(fù)責(zé)所有核心網(wǎng)控制面的功能，包括接入控制、認(rèn)證、移動(dòng)性管理、會(huì)話管理、策略管理等。各CCF間負(fù)荷分擔(dān)，移動(dòng)用戶可以由任意CCF提供服務(wù)，而無需跨CCF的遷移。一個(gè)移動(dòng)用戶的不同事務(wù)（如附著（ATTACH）、跟蹤區(qū)更新（TAU））可動(dòng)態(tài)地由不同CCF為之提供服務(wù)，比如ATTACH時(shí)由CCF1服務(wù)，而TAU時(shí)由CCF2服務(wù)。在上下文共享域內(nèi)，這樣的架構(gòu)將不再需要傳統(tǒng)4G網(wǎng)絡(luò)中的跨MME切換和跟蹤區(qū)更新流程，也不再需要MME間的接口。負(fù)荷分擔(dān)的設(shè)計(jì)也比以前簡單，當(dāng)一個(gè)CCF超負(fù)荷或宕機(jī)時(shí)，只需將后續(xù)的事務(wù)分配給其他CCF處理，而無需CCF間的用戶遷移過程。并且，由于將所有控制面功能集成到CCF中，單個(gè)事物的處理不再需要跨不同網(wǎng)元的交互，從而降低了核心網(wǎng)的信令處理時(shí)延?？缟舷挛墓蚕碛虻囊苿?dòng)或切換需要在兩個(gè)域間同步用戶上下文，該流程可利用類似4G中的跨MME的切換和跟蹤區(qū)更新流程，或者利用IT技術(shù)進(jìn)行上下文同步，從而無需CCF間的接口。只要IT技術(shù)支持，最好將上下文共享域設(shè)置得足夠大，從而減少跨共享域的移動(dòng)和切換，但共享域的大小受IT技術(shù)的限制。

考慮與4G系統(tǒng)的共存，CCF需與傳統(tǒng)4G網(wǎng)絡(luò)中的MME、SGW等網(wǎng)元接口，CCF與傳統(tǒng)網(wǎng)元間的接口可基于現(xiàn)有4G定義的接口協(xié)議進(jìn)行通信，從而無需改變4G網(wǎng)絡(luò)。

圖2中的架構(gòu)將所有核心網(wǎng)控制功能都集成到了CCF中，CCF劃分為多個(gè)模塊，如接入認(rèn)證模塊、移動(dòng)性管理模塊、會(huì)話管理模塊、隧道管理模塊、策略控制模塊、各種接口模塊（如與SDN控制器的接口、與傳統(tǒng)網(wǎng)絡(luò)網(wǎng)元的接口）等。

2.2 虛擬核心網(wǎng)中的業(yè)務(wù)鏈

IETF 業(yè)務(wù)鏈（SFC）工作組正在討論如何更靈活地支持業(yè)務(wù)鏈。SFC的最基本的目標(biāo)是將業(yè)務(wù)鏈與網(wǎng)絡(luò)拓?fù)浣怦睢Ｔ贗ETF定義的架構(gòu)中[4]，業(yè)務(wù)分類器對(duì)業(yè)務(wù)流進(jìn)行分類和選擇業(yè)務(wù)鏈路徑，并且對(duì)業(yè)務(wù)流進(jìn)行業(yè)務(wù)鏈封裝。業(yè)務(wù)鏈封裝（簡稱SFC封裝）不用于數(shù)據(jù)傳輸，數(shù)據(jù)的傳輸依靠外層包頭，這樣可將業(yè)務(wù)鏈與網(wǎng)絡(luò)拓?fù)浣怦睢Ｔ黾有碌臉I(yè)務(wù)服務(wù)器只需增加業(yè)務(wù)服務(wù)器到業(yè)務(wù)轉(zhuǎn)發(fā)器之間的鏈路，從而與其他業(yè)務(wù)服務(wù)器解耦（星形架構(gòu)），也與傳輸網(wǎng)絡(luò)解耦。IETF定義的架構(gòu)如圖3所示。

業(yè)務(wù)轉(zhuǎn)發(fā)器負(fù)責(zé)根據(jù)SFC封裝將數(shù)據(jù)包轉(zhuǎn)給相應(yīng)的業(yè)務(wù)服務(wù)器，當(dāng)業(yè)務(wù)服務(wù)器不支持SFC封裝時(shí)，SFC代理負(fù)責(zé)將SFC封裝解開并將原始數(shù)據(jù)包發(fā)送給業(yè)務(wù)服務(wù)器。

在未來運(yùn)營商網(wǎng)絡(luò)中，我們可以設(shè)想：業(yè)務(wù)服務(wù)器將升級(jí)支持業(yè)務(wù)鏈，運(yùn)營商的網(wǎng)絡(luò)中也會(huì)引入業(yè)務(wù)轉(zhuǎn)發(fā)器，用于將業(yè)務(wù)數(shù)據(jù)包轉(zhuǎn)發(fā)到業(yè)務(wù)服務(wù)器。

業(yè)務(wù)服務(wù)器可利用虛擬化技術(shù)，構(gòu)建在通用平臺(tái)上，做成虛擬網(wǎng)元。而業(yè)務(wù)轉(zhuǎn)發(fā)器，更適合集成到OFS中。當(dāng)然，業(yè)務(wù)服務(wù)器也可能會(huì)由于某種特殊需要（如性能），采用特殊的硬件實(shí)現(xiàn)。將業(yè)務(wù)轉(zhuǎn)發(fā)器集成到OFS上如圖4所示。

在具體部署時(shí)，CCF和業(yè)務(wù)服務(wù)器可能部署在不同的位置。比如，CCF可能部署在比較集中的位置，而業(yè)務(wù)服務(wù)器則可能會(huì)部署在靠近邊緣的地方。運(yùn)營商根據(jù)運(yùn)營商的網(wǎng)絡(luò)拓?fù)?、需求等確定適合的部署方式。

2.3 多張網(wǎng)絡(luò)并存的核心網(wǎng)

5G的網(wǎng)絡(luò)需求具有多樣性，它將是可以滿足各種不同場(chǎng)景不同需求的網(wǎng)絡(luò)。它既要支持超密集網(wǎng)絡(luò)（UDN），又要支持海量連接（MTC）；既要支持超高速，又要支持超可靠性。并非每個(gè)5G的需求場(chǎng)景都需要同時(shí)支持所有的性能指標(biāo)：有些場(chǎng)景只需要實(shí)時(shí)性，但無需高帶寬，有時(shí)甚至只需很低帶寬；有些場(chǎng)景需要很高的帶寬，但并不需要很高的可靠性，也不需要實(shí)時(shí)性；有的場(chǎng)景需要支持高速下的移動(dòng)性，而有的場(chǎng)景根本無需支持移動(dòng)性。對(duì)所有5G需求均用同一張網(wǎng)絡(luò)支持，對(duì)網(wǎng)絡(luò)的要求勢(shì)必很高，也不利于網(wǎng)絡(luò)性能優(yōu)化。在現(xiàn)有的4G網(wǎng)絡(luò)架構(gòu)中，為了支持不同場(chǎng)景，對(duì)網(wǎng)絡(luò)打了各種補(bǔ)丁。但到了5G，各種不同的需求變得越來越多、越來越高，在一張網(wǎng)絡(luò)上疊加對(duì)所有需求的支持變得越來越困難和不優(yōu)化。

網(wǎng)絡(luò)虛擬化除了能給運(yùn)營商帶來管理、方便部署等好處外，它還帶來了一個(gè)更大的好處——為未來運(yùn)營商同時(shí)運(yùn)營多張網(wǎng)絡(luò)帶來了可能。

在運(yùn)營商現(xiàn)有的網(wǎng)絡(luò)中，部署一個(gè)新的網(wǎng)絡(luò)涉及到各物理網(wǎng)元的采購、網(wǎng)絡(luò)的組建和配置、網(wǎng)絡(luò)調(diào)試等環(huán)節(jié)，從招標(biāo)開始到最后網(wǎng)絡(luò)建成往往需要幾個(gè)月時(shí)間，有時(shí)甚至更長。不僅僅時(shí)間長，設(shè)備成本也很高，并且維護(hù)一張新的網(wǎng)絡(luò)也是一項(xiàng)艱巨的任務(wù)。無論是從運(yùn)營成本（OPEX）還是資本支出（CAPEX）角度上看，運(yùn)營商同時(shí)部署多張專用網(wǎng)絡(luò)變成艱難和漫長的歷程。

利用網(wǎng)絡(luò)虛擬化技術(shù)，可以很方便地構(gòu)建一張新的移動(dòng)核心網(wǎng)。方便到只需將不同版本、不同功能的虛擬核心網(wǎng)網(wǎng)元的軟件及對(duì)網(wǎng)絡(luò)的需求告訴編排器即可，編排器根據(jù)需求自動(dòng)為核心網(wǎng)分配硬件資源、加載核心網(wǎng)軟件、對(duì)核心網(wǎng)網(wǎng)元實(shí)例化，對(duì)核心網(wǎng)網(wǎng)元進(jìn)行配置、分配網(wǎng)元間的鏈路，從而能快速組建一張新的核心網(wǎng)。比如，運(yùn)營商可以為車聯(lián)網(wǎng)組建專門的移動(dòng)網(wǎng)絡(luò)，也可以為遠(yuǎn)程醫(yī)療組建專門的網(wǎng)絡(luò)。運(yùn)營商可以將人人通信與物物通信分開，也可以為不同組織或公司的功能類似的網(wǎng)絡(luò)需求組建不同的網(wǎng)絡(luò)并為之服務(wù)，從而更好地相互隔離。多張核心網(wǎng)并存的未來網(wǎng)絡(luò)運(yùn)營模式見圖5。

在圖5中，運(yùn)營商同時(shí)運(yùn)營了兩張?zhí)摂M核心網(wǎng)。虛擬核心網(wǎng)1是針對(duì)人人通信的網(wǎng)絡(luò)，而虛擬核心網(wǎng)2是針對(duì)物聯(lián)網(wǎng)的專用核心網(wǎng)。運(yùn)營商利用專用網(wǎng)絡(luò)為物聯(lián)網(wǎng)終端服務(wù)，可針對(duì)物聯(lián)網(wǎng)的特征對(duì)網(wǎng)絡(luò)進(jìn)行優(yōu)化，如針對(duì)物聯(lián)網(wǎng)的海量連接需求優(yōu)化，或物聯(lián)網(wǎng)的低移動(dòng)性進(jìn)行優(yōu)化。不同的虛擬核心網(wǎng)共享基礎(chǔ)設(shè)施和轉(zhuǎn)發(fā)設(shè)備。

2.4 智能管理

網(wǎng)絡(luò)管理是運(yùn)營商的重要成本之一，智能的網(wǎng)絡(luò)管理可以自動(dòng)對(duì)網(wǎng)絡(luò)進(jìn)行配置，對(duì)正在運(yùn)行的網(wǎng)絡(luò)進(jìn)行監(jiān)控，并可根據(jù)網(wǎng)絡(luò)運(yùn)行狀況對(duì)網(wǎng)絡(luò)進(jìn)行調(diào)整，以達(dá)到最佳運(yùn)行狀態(tài)。

自4G開始，自組織網(wǎng)絡(luò)（SON）技術(shù)的引入使得無線基站的配置和管理大大簡化。SON技術(shù)可實(shí)現(xiàn)鄰站的自動(dòng)發(fā)現(xiàn)和配置，通過X2接口或S1接口交換基站配置相關(guān)信息，實(shí)現(xiàn)小區(qū)的自動(dòng)配置、負(fù)荷分擔(dān)、自動(dòng)優(yōu)化和自愈等。

到了5G，NFV的引入使得多個(gè)并行的專用核心網(wǎng)絡(luò)成為可能和必然，核心網(wǎng)的配置和維護(hù)工作量將大大增加，因此，如何對(duì)網(wǎng)絡(luò)實(shí)行自動(dòng)安裝、自動(dòng)部署、自動(dòng)配置和自動(dòng)維護(hù)將變得更重要。

為了支持網(wǎng)絡(luò)智能管理，首先，網(wǎng)絡(luò)智能管理系統(tǒng)必須能收集正在運(yùn)行的網(wǎng)絡(luò)的狀態(tài)信息，包括，各網(wǎng)元的負(fù)荷、容量、能力、部署位置、網(wǎng)絡(luò)拓?fù)涞刃畔ⅲ黄浯?，網(wǎng)絡(luò)智能管理系統(tǒng)還需收集空閑資源的情況，如可用計(jì)算能力、可用內(nèi)存、以及可用資源的位置等。此外，網(wǎng)絡(luò)智能管理系統(tǒng)還會(huì)收集與業(yè)務(wù)相關(guān)的信息。在收集了這些信息之后，網(wǎng)絡(luò)智能管理系統(tǒng)對(duì)信息進(jìn)行分析。對(duì)信息的分析有時(shí)需大數(shù)據(jù)處理中心進(jìn)行處理，比如，對(duì)業(yè)務(wù)數(shù)據(jù)的分析需借助大數(shù)據(jù)處理中心。收集業(yè)務(wù)數(shù)據(jù)的目的是了解終端的行為模式，并據(jù)此對(duì)網(wǎng)絡(luò)進(jìn)行優(yōu)化，例如，可根據(jù)分析結(jié)果決定轉(zhuǎn)發(fā)面的位置和是否需要引入業(yè)務(wù)服務(wù)器對(duì)用戶數(shù)據(jù)流進(jìn)行處理。網(wǎng)絡(luò)智能管理系統(tǒng)從虛擬核心網(wǎng)網(wǎng)元中收集各種狀態(tài)信息和業(yè)務(wù)信息，從NFV 編排器獲取空閑資源信息。

除了從網(wǎng)絡(luò)中收集各種信息，并對(duì)信息進(jìn)行分析之外，網(wǎng)絡(luò)智能管理系統(tǒng)還需提供接口用于由運(yùn)營商管理人員配置必要的信息，如策略信息或者可選的、新的網(wǎng)絡(luò)服務(wù)需求。策略信息包括網(wǎng)絡(luò)部署策略、優(yōu)化策略等，網(wǎng)絡(luò)服務(wù)需求是來自企業(yè)、政府、虛擬運(yùn)營商等大客戶的需求。網(wǎng)絡(luò)智能管理系統(tǒng)根據(jù)網(wǎng)絡(luò)狀態(tài)、可用資源、策略信息及可選的網(wǎng)絡(luò)服務(wù)需求做出網(wǎng)絡(luò)部署或優(yōu)化決策。

圖6為未來核心網(wǎng)中的網(wǎng)絡(luò)智能管理系統(tǒng)，它集成在對(duì)象存儲(chǔ)/基本服務(wù)集運(yùn)營支持系統(tǒng)（OSS/BSS）中，當(dāng)然它也可以位于其他地方，比如作為一個(gè)虛擬服務(wù)器獨(dú)立運(yùn)行。

3 結(jié)束語

文章結(jié)合網(wǎng)絡(luò)虛擬化、SDN、業(yè)務(wù)鏈等5G熱點(diǎn)技術(shù)對(duì)虛擬化的4G核心網(wǎng)進(jìn)行了進(jìn)一步簡化，提出了一種集成的虛擬化核心網(wǎng)架構(gòu)，支持智能管理、業(yè)務(wù)鏈和多核心網(wǎng)并存。該核心網(wǎng)架構(gòu)將核心網(wǎng)功能集成，將處理模塊和用戶上下文分開，從而能更好地支持核心網(wǎng)的分布式處理。集成的核心網(wǎng)還減少了接口，除了與傳統(tǒng)網(wǎng)絡(luò)的接口之外，在內(nèi)部CCF間切換時(shí)無需傳遞數(shù)據(jù)，因此無需CCF間的接口。網(wǎng)絡(luò)智能管理模塊的引入使得網(wǎng)絡(luò)實(shí)現(xiàn)運(yùn)維自動(dòng)化，包括網(wǎng)絡(luò)自動(dòng)化部署、配置、優(yōu)化和故障處理。

參考文獻(xiàn)

[1] Network Function Virtualization （NFV） Management and Orchestration[EB/OL].http：//www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf

[2] ONF： SDN Architecture Overview[EB/OL].https：//www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN-architecture-overview-1.0.pdf

[3] draft-ietf-sfc-problem-statement-10： Service Function Chaining Problem Statement [EB/OL]. http：//tools.ietf.org/pdf/draft-ietf-sfc-problem-statement-10.pdf

[4] draft-ietf-sfc-architecture-02： Service Chaining Function Architecture [EB/OL]. http：//tools.ietf.org/pdf/draft-ietf-sfc-architecture-02.pdf