段 煉,楊龍祥,任美翠
(南京郵電大學 通信與信息工程學院,江蘇 南京 210003)
內容中心網絡及其緩存策略研究
段 煉,楊龍祥,任美翠
(南京郵電大學 通信與信息工程學院,江蘇 南京 210003)
當今,因特網的使用已經演進到以內容的分發和檢索為主,但是目前使用的IP結構并不能很好地滿足這樣的需求。內容中心網絡(Content Centric Networking,CCN)打破了傳統的“主機—主機”的通信模式,將內容置于核心地位,是目前未來網絡領域的研究熱點之一。CCN將內容與主機分割開并將內容存儲在網絡節點中。任何存有內容的節點都可以充當服務器向用戶提供服務,因此CCN可以高效地進行內容傳輸。CCN的這種優勢來自于它可以進行網絡內緩存,可以說緩存是CCN的基石。緩存策略的性能直接影響了整個CCN的性能。簡要概括了CCN和IP的區別,介紹了CCN的一些核心概念和工作機制,給出了CCN中相關的緩存算法并分析了它們的優缺點。
內容中心網絡;未來網絡;網絡體系結構;緩存算法
在計算機系統開發的初期,系統內的資源非常有限。隨后,為了解決資源共享的問題,不同的網絡結構逐漸演化,最終形成了客戶端-服務器的通信模式[1]。在這種模式中,一個節點擁有資源并且其他節點可以利用這些資源。這是一種以主機為中心的面向連接的網絡模型。在這種模式中,為了從一個特定服務器獲取相應服務,節點必須與此服務器進行連接。計算機系統發展至今,系統內的資源不再匱乏且變得相對廉價,加上技術的進步,使得這種模式在逐漸轉變。
計算機體系結構設計的初衷是用于共享資源,但是隨著網絡的不斷發展,資源的共享已經不能滿足人們的需求。現今,人們對于內容的傳播更為感興趣(主要是視頻),而這也占據了因特網中大部分的流量。TCP/IP正是為了應對內容的傳播而設計的。
例如,考慮到圖1中的網絡拓撲,其網絡結構使用的是TCP/IP。因此網絡中的每一個節點將遵循TCP/IP協議。在此情況下,如果節點1需要獲取內容A,那么此節點首先需要和提供內容A的服務器進行連接。因此,節點1需要向服務器發送一個連接請求。如果此時服務器可以提供服務,那么它將會接收連接請求。之后節點1和服務器之間將會建立連接。現在,節點1發送需求內容A的請求,而服務器將會把內容A轉發給節點1來完成響應。

圖1 IP結構的低效性
同樣,如果節點2和節點3也需要內容A,那么它們將會執行和上面一樣的操作。可以說,無論多少節點需要內容A,它們都需要進行相同的操作,即和提供內容的服務器進行連接。可以看出,IP網絡以主機為中心,它更加關注被請求信息的位置而不是信息本身的內容,因此,所有對于相同內容的請求都需要源服務器來完成,不僅導致網絡的效率不高,還造成了巨大的帶寬浪費。內容中心網絡(CCN)[2]正是為了克服IP網絡的這種缺陷而提出的新型網絡架構。
CCN支持網絡內緩存,即在網絡內的所有節點都設有緩存功能[3]。通過網絡內緩存,CCN避免了對相同內容的重復傳輸。當轉發的內容經過某一節點時,此節點可以緩存該內容。當此節點再次收到對這一內容的請求時,它可以直接將請求的內容發送給請求者而不再需要請求服務器。因而CCN節省了網絡資源,加快了內容傳輸。
文中主要對內容中心網絡及其緩存策略進行研究,分析了CCN體系結構與IP體系結構的不同,介紹了CCN的包類型、節點轉發的工作機制,闡述了幾種典型的CCN緩存決策策略和緩存替換策略。在此基礎上,重點研究了幾種具有代表性的緩存決策策略,并對其性能的優缺點進行了分析,為未來的研究工作奠定了理論基礎。
與傳統的主機到主機的網絡結構不同,CCN是一種面向內容的結構。當今用戶的需求已經由傳統的“資源共享”向“內容傳播”轉變,這正是CCN被提出的內在動力。CCN是一種全新結構,它與傳統的IP結構截然不同。圖2在協議棧方面對CCN和IP進行了比較。
可以看出,IP中的大部分層都需要雙邊協議,例如IP的2層框架協議是兩個物理終端之間的協議,4層傳輸協議是生產者和消費者之間的協議,而只有第3層即網絡層需求統一的協議。CCN的第3層即策略層有效地利用了多徑連接。CCN采用接收端驅動的方式,保證了傳輸內容的安全性,避免了許多一直困擾IP網絡的安全隱患[4]。

圖2 IP和CCN協議棧
在CCN中,傳入流量一般遵循Zipf分布[5]。這種分布為流行的內容分配相應的等級。流行度表示某一內容在一定時間內被訪問的次數。被訪問的次數越多意味著這個內容的流行度越高。Zipf分布依據流行度對內容進行分類并給內容分配相應的等級。內容的流行度越高其等級越低,流行度越低等級也就越高。
在CCN中任何的通信都由用戶自己管理,而不再由傳統的服務器進行管理。用戶只會接收到那些已經需求過的內容。然而,在IP網絡中,除了那些被需求的內容外,一些未被需求的內容也可能隨之一起發送給用戶。顯然,相比IP網絡,CCN更具有安全性。
CCN結構建立在命名數據的基礎上,使用分級命名來唯一地命名內容。在CCN中有兩種包結構:Interest包和Data包。在CCN中,通過Interest包中的內容名稱進行內容的請求。如果用戶需求某個內容,他將會廣播Interest包,任何節點在收到Interest包后,如果在此節點內存有用戶請求的內容,那么此節點將向用戶返回相應的Data包。當Interest包的內容名與Data包內容名的前綴相符合時,則該Data包滿足該Interest包的請求。在CCN中,一個Interest包只會收到一個Data包作為響應,這確保了流量的平衡以及在節點之間高效的通信。
由于網絡的高度動態性,Data包和Interest包都有可能出現丟失的情況。因此,為了確保CCN的可靠性,當需求在一段時間內未被滿足時,請求節點需要重發Interest包。
CCN致力于對數據的高速獲取。為了達成這個目標,CCN采用了新的轉發引擎模型。其中包含三個主要的數據結構:轉發信息表(Forwarding Information Base,FIB)、內容存儲表(Content Store,CS)和待定請求表(Pending Interest Table,PIT)。
FIB將Interest包轉發到包含有請求內容的服務器。CCN的FIB和IP的FIB類似,不同的是CCN的FIB有一系列的出口,而IP的FIB只有一個[6]。因此CCN中的節點可以向多個源服務器發送請求。CCN中的CS和IP中的緩沖區域類似,用來作為緩存內容的存儲區域。但CS有著不同的緩存替換策略。IP緩沖區中的內容在轉發之后就將被丟棄,而CCN中的CS將會盡可能長時間地緩存內容,以便更快地為之后的請求提供服務。PIT記錄已經轉發的Interest包,當對同一內容有多個請求時,它將多余的請求記錄在一個條目中,并只向數據源發送一條請求。當Data包返回時,它會根據PIT中記錄的條目將數據發送給相應的請求源。
3.1 Interest包的處理
當一個Interest包到達一個節點的接口之后,節點將會對其進行最長前綴匹配來驗證它所需求的內容是否已經存儲在CS中。如果需求的內容已經存儲在節點的CS中,那么此節點將立刻向請求者發送Data包。由于請求已經被滿足,所以此Interest包將會被丟棄。
如果在CS中并沒有找到需求的內容,那么接著將會校驗PIT中的條目。如果和PIT中的條目相匹配,則在PIT的請求接口表中添加相應的條目并刪除此Interest包。如果后來的請求是對先前已經請求內容的請求,節點并不會因此而轉發多個Interest包。對于相同內容的請求,一個節點只會轉發一個Interest包。
如果在PIT中也沒有匹配到相應的條目,那么此Interest包將會根據FIB中的條目進行轉發。假定FIB知道所有內容的源服務器,因此它能夠有效地轉發Interest包來獲取相應的內容。
3.2 Data包的處理
相比于Interest包,Data包的處理過程比較簡單。當Data包到達一個節點的接口時,Data包的內容名將進行最長前綴匹配。如果此內容名和CS中的條目相匹配,說明此內容已經存儲在CS中,那么此內容將會被丟棄。如果和FIB中的條目相匹配,則表明該內容名在PIT中沒有相匹配的條目,也就是說該內容并沒有被請求過,此內容也會被丟棄。如果和PIT中的條目形成了匹配,則表明此節點確實發送過請求此內容的Interest包。接著將會進行內容驗證并把此內容存于CS中,最后依據PIT中匹配的條目創建一個請求接口表,并根據此表將Data包發送給每一個請求者。
CCN的緩存策略大致可以分為兩類。一類是緩存決策策略,即選擇網絡中最合適的節點去緩存相應的內容。另一類是緩存替換策略,即當節點緩存空間已滿時選擇丟棄哪個內容來為新的內容騰出空間[7]。
CCN有以下三種典型的緩存決策策略:
(1)Leave Copy Everywhere (LCE)[8]:這是CCN默認的緩存決策策略。其核心思想是將內容存儲在沿著需求路徑的每一個路由器上,但是LCE有較大的數據冗余度,造成緩存空間的大量浪費。
(2)Leave Copy Down (LCD)[9]:當緩存命中時,僅在命中節點的下游節點緩存該內容,這種策略減少了需求路徑上重復內容的數量,但降低了緩存的命中率。
(3)Probabilistic Caching (ProbCache)[10]:其核心思想是節點越靠近用戶其緩存概率越大,這種策略能將內容快速地緩存到網絡邊緣,但是并未考慮內容的流行度問題,會增加不同內容在邊緣節點的競爭。
CCN中的緩存替換策略大多使用最近最少使用置換算法(Least Recently Used,LRU)[11]和最不經常使用置換算法(Least Frequently Used,LFU)[12]來最大限度地存儲內容。
目前,研究者們大多致力于對緩存決策策略的研究。文中主要介紹并分析以下幾種具有代表性的緩存決策策略。
4.1 基于節點緩存容量的緩存策略
這種算法在緩存決策時考慮到了節點的緩存容量[13],把它作為選擇緩存節點時的一個參數。這里的緩存容量表示網絡節點的CS中還能存儲多少內容。為了記錄這個緩存容量,在Interest包中添加了Cache Capacity Value (CCV)域。當節點收到一個Interest包后,如果在其CS中沒有找到需求的內容,它將會把自己的緩存容量添加到CCV域中并轉發Interest包。當下一個節點收到這個Interest包后,如果在它的CS中也沒有找到這個內容,那么它將會把自己的CCV值和Interest包中的CCV值進行比較。如果它的CCV值小于Interest包中的CCV值,那么它會直接轉發此Interest包。如果大于,它將會用自己的CCV值替換Interest包中的CCV值并轉發此Interest包。當Interest包到達存有內容的服務器之后,服務器會根據最大的CCV值分配轉發路徑中相應的節點去緩存Data包中的內容。
這種算法在通常流量和突發流量情況下都有很好的表現。大部分緩存算法中都沒有考慮突發流量的情況,但在實際情況中,突發流量是很有可能出現的。因此考慮突發流量情況是該算法的一個優點。
現在假設有六個Interest包,每個包請求10 MB的數據。當這六個Interest包到達一個CCV值是50 MB的節點后,認定這個節點是傳輸路徑中擁有最大CCV值的節點。因此當Data包返回時前五個內容將會被緩存到此節點中。而當第六個Data包到達時,由于緩存空間已滿,此時節點必須執行緩存替換策略來為第六個內容騰出緩存空間。如果這種情況大量發生,那么節點將會忙于執行替換策略,這會降低網絡整體的性能。
4.2 基于節點核心值的緩存策略
文獻[14]采用節點的核心值作為一個參數來選擇緩存內容的節點。核心值用來衡量一個節點在通信模式中的重要性。一個節點出現在內容傳輸路徑的次數越多,其核心值越高。
假設網絡拓撲結構如圖3所示。

圖3 路由器的核心值
用戶A發送一個Interest包,此Interest包將會到達服務器S1,服務器S1將會沿路徑S1-V1-V2-V3-V4-V5發送Data包。根據文獻[15]可知,V4的核心值最高。根據文獻[14]中的算法,選擇V4作為緩存內容的節點。
這種算法選擇了在傳輸路徑中出現次數最多的節點作為緩存內容的節點。由于此節點很靠近網絡邊緣,因此它能夠為大多數的請求提供服務。同時僅選擇一個節點來緩存內容使得資源的利用率很高。
不過這種算法并沒有考慮突發流量的情況,當突發流量發生時,緩存內容的節點負載會劇增,從而影響服務質量。不僅如此,該算法對于緩存節點的選擇僅依據節點在拓撲中的位置而并沒有考慮內容的流行度問題,因此在緩存節點中,流行的內容很可能被不流行的內容替換掉,從而使流行的內容無法被充分利用。
4.3 基于內容流行度的緩存策略
文獻[16]提出一種思路,每個節點記錄對每個內容的需求次數,然后以成對的形式把內容名和流行值記錄到一個流行度表(Popularity Table)中。一旦一個內容的流行度達到流行度臨界值之后,這個內容將會被標記為流行的。
如果某個節點擁有這個內容,它將會通過一條建議信息(Suggestion)去建議它的鄰節點緩存這個內容。在發送建議信息之后該節點將會重置該內容的流行度,防止重復地將該內容發送給鄰節點。MPC緩存的示例如圖4所示。

圖4 MPC緩存示例
假設A,B,C節點請求內容d1,A節點請求內容e1,每次請求使得相關內容的流行度增加1,并假設流行度臨界值為3。此時D節點中內容d1的流行度達到3,達到了臨界值,這時D節點將建議其鄰節點C和E對d1進行緩存。
這種算法依據流行度對內容進行緩存,由于流行度高的內容被存儲在了更多的節點中,因此算法的緩存命中率相比傳統的LCE算法有很大提升。此外,由于緩存內容的減少(僅緩存流行度高的內容),節約了節點的緩存空間并減少了緩存的操作次數。但也因此使得網絡中內容的多樣性有所下降。
4.4 核心協作緩存策略
文獻[17]的主要思想是,通過構造支配集來構建一個虛擬骨干網絡。文獻[18]介紹了如何構造一個連接的支配集(Connected Dominating Set,CDS)。核心節點是構成CDS的主要部分,其余節點被稱為常規節點。每個核心節點為一個或者幾個常規節點提供服務。流行度高的內容被存儲在核心節點,因此減少了內容的冗余度。同時,常規節點不允許緩存內容。當核心節點的緩存空間已滿時,被刪除的內容將發送給其服務的常規節點。核心節點每刪除一個內容將相應地增加一個條目。
算法中并不是所有節點都需要緩存內容,大部分的運算都集中在核心節點。由于只有少部分的節點需要進行運算,因此網絡的資源利用率得到了提高。同時該算法考慮了內容的流行度問題。
構建虛擬骨干網絡的過程十分復雜,這正是該算法的瓶頸所在。如果一個核心節點失去連接,那么與之相連的其他核心節點也會失去連接,這將導致網絡中斷。
4.5 基于Modulo hashing的分布式協作緩存策略
文獻[19]針對大視頻文件,提出了一種基于Modulo hashing的協同緩存策略[20]。當某個內容塊到達一個緩存節點時,該節點將通過一個Modulo hashing函數計算出該內容塊應該由哪個鄰居節點或者自身來緩存。
如圖5所示,將需求的視頻內容分為很多內容塊,每一個節點并不緩存全部的內容塊,而是分別緩存部分內容塊,由k個節點共同協作緩存全部的內容塊。規定,每個節點都擁有一個標簽,該標簽是一個小于固定整數k的自然數。每個節點只對符合一定緩存規則的內容塊進行緩存。若內容塊標號對k取余的結果與該節點的標簽相等,則節點緩存此內容塊。如圖所示,假設總塊數為21(內容塊0到內容塊20)且k=3,那么每個節點(路由器)ri的標簽為i(0,1,2)。路由器r0緩存的內容為內容塊{0,3,6,…,18},也就是連續10個其標號對3取余為0的內容塊。

圖5 基于Modulo hashing的協同緩存策略
這種算法使用了Modulohashing使得一個節點與其k-1個鄰節點共同協作完成對內容的緩存。由于將內容切分并存儲在不同的網絡節點中,因此網絡中內容的多樣性得到了很大提升,從而許多對于內容的請求不再需要源服務器來提供服務,這有效地減少了服務器的負載。但由于這是一種基于Modulohashing的算法,當網絡中增加或者移除一個路由器時,先前的模值將會發生變化,之前緩存的內容的位置也必將隨之更改。同時網絡將會出現負載均衡的問題,使得某些路由器負載過大。
4.6 基于Consistent hashing的分布式協作緩存策略
這種算法是一種基于Consistent hashing的協同緩存算法[21]。首先在一組路由器中根據路由器緩存容量的大小分配不同個數的Keys,容量越大分配的Keys個數越多,Keys的范圍為0到n并由這些Keys組成一個Hash環。
如圖6所示,假設路由器1擁有5個Keys,分別是2,6,7,12,13(根據容量隨機分配),路由器2擁有4個Keys,分別是1,5,8,10,路由器3擁有0,4,9,路由器4擁有3,11。當一個內容塊到達路由器時,首先計算其hash值并根據它的歷史和當前請求頻率計算出它的流行度。接著用其hash值和該路由器擁有的Keys值進行匹配,如果相匹配且其流行度大于臨界值則緩存該內容,否則不緩存。例如,路由器1將只緩存hash值為2,6,7,12,13且流行度大于臨界值的內容塊。

圖6 基于Consistent hashing的協同緩存策略
這種算法考慮了路由器容量的大小問題,這在實際情況中非常值得考慮。同時算法還將流行度納入為決策的要素,有效地提高了緩存的命中率,減少了服務器的負載。同時算法還利用Consistenthashing有效降低了增加或者移除路由器時造成的影響。
但Consistenthashing對內容塊進行分布式緩存,網絡邊緣節點并不能夠緩存流行度最高的內容,這會導致命中距離的提升。而且算法綜合考慮了多方面的因素,也因此使其復雜度大大提升,這將使節點需要大量的資源去進行計算,降低了網絡的整體性能。
隨著網絡規模的增長,新興業務的不斷出現,以及用戶對服務的需求越來越多樣化,傳統的IP網絡基礎架構已經不堪重負,成為了網絡進一步發展的瓶頸。為了解決這個問題,提出了很多關于未來網絡方面的研究。文中涉及的CCN是未來網絡發展方向之一。其以用戶需求為中心,支持網絡內所有節點的緩存,有效提高了內容的傳播效率,從而克服了IP結構效率低的問題,使得用戶能夠更便捷地獲取他們想要的內容。其眾多優點使得它很有可能在不久的將來取代IP的主體地位,也因此使得它成為當前對未來網絡方面研究的重點。
圍繞內容中心網絡重點介紹并討論了幾種具有代表性的緩存決策策略,詳細分析了各自的優缺點。諸如,基于節點緩存容量的緩存策略考慮到了節點的緩存容量,提升了突發流量下的緩存性能,卻容易因為頻繁執行替換策略而降低了網絡的整體性能;基于節點核心值的緩存策略提高了網絡資源的利用率,卻沒有考慮內容流行度的問題;基于內容流行度的緩存策略,顯著改善了緩存命中率,但也降低了網絡內容的多樣性;核心協作緩存策略考慮了內容流行度的同時提高了資源利用率,但核心節點失去連接時將會導致網絡中斷;基于Modulohashing的分布式協作緩存策略提高了緩存內容的多樣性,減少了服務器的負載,但增加或者移除一個路由器時會對算法造成影響;基于Consistenthashing的分布式協作緩存策略有效降低了增加或者移除路由器時造成的影響,卻使得算法的復雜度大幅提升,從而降低了網絡的整體性能。綜上所述,CCN仍有諸多理論和技術問題有待解決,需要深入的研究。
[1]XylomenosG,VerveridisCN,SirisV,etal.Asurveyofinformation-centricnetworkingresearch[J].IEEECommunicationsSurveys&Tutorials,2014,16(2):1024-1049.
[2]JacobsonV,SmettersDK,ThorntonJD,etal.Networkingnamedcontent[C]//Internationalconferenceonemergingnetworkingexperiments&technologies.[s.l.]:ACM,2011:1-12.
[3] 胡 騫,武穆清,郭 嵩.以內容為中心的未來通信網絡研究綜述[J].電信科學,2012,28(9):74-80.
[4] 夏春梅,徐明偉.信息中心網絡研究綜述[J].計算機科學與探索,2013,7(6):481-493.
[5]NewmanM.ParetodistributionsandZipf'sLaw[J].ContemporaryPhysics,2004,46(5):323-351.
[6] 閔二龍,陳 震,許宏峰,等.內容中心網絡CCN研究進展探析[J].信息網絡安全,2012(2):6-10.
[7] 張國強,李 楊,林 濤,等.信息中心網絡中的內置緩存技術研究[J].軟件學報,2014,25(1):154-175.
[8]JiangA,BruckJ.Optimalcontentplacementforen-routewebcaching[C]//IEEEinternationalsymposiumonnetworkcomputing&applications.[s.l.]:IEEEComputerSociety,2003.
[9]LaoutarisN,SyntilaS,StavrakakisI.Metaalgorithmsforhierarchicalwebcaches[C]//IEEEinternationalconferenceonperformance,computing,andcommunications.[s.l.]:IEEE,2004:445-452.
[10]PsarasI,ChaiWK,PavlouG.Probabilisticin-networkcachingforinformation-centricnetworks[C]//Proceedingsofthesecondeditionoftheworkshoponinformation-centricnetworking.[s.l.]:ACM,2012:55-60.
[11]MegiddoN,ModhaDS.OutperformingLRUwithanadaptivereplacementcachealgorithm[J].Computer,2004,37(4):58-65.
[12]PetevPG,WintergerstM.Leastfrequentlyusedevictionimplementation:U.S.,7 552 284[P].2009-06-23.
[13]KimD,LeeSW,KoYB,etal.Cachecapacity-awarecontentcentricnetworkingunderflashcrowds[J].JournalofNetwork&ComputerApplications,2015,50(C):101-113.
[14]ChaiWK,HeDiliang,PsarasI,etal.Cache“lessformore”ininformation-centricnetworks(extendedversion)[J].ComputerCommunications,2013,36(7):758-770.
[15]WassermannS,FaustK.Socialnetworkanalysis:methodsandapplications[M].Cambridge:CambridgeUniversityPress,1994.
[16]BernardiniC,SilverstonT,FestorO.MPC:popularity-basedcachingstrategyforcontentcentricnetworks[C]//IEEEinternationalconferenceoncommunications.[s.l.]:IEEE,2013:3619-3623.
[17]XuY,LiY,LinT,etal.Adominatingset-basedcollaborativecachingwithrequestroutingincontentcentricnetworking[C]//IEEEinternationalconferenceoncommunications.[s.l.]:IEEE,2013:3624-3628.
[18]GuhaS,KhullerS.Approximationalgorithmsforconnecteddominatingsets[J].Algorithmica,1998,20(4):374-387.
[19]LiZ,SimonG.Time-shiftedTVincontentcentricnetworks:thecaseforcooperativein-networkcaching[C]//IEEEinternationalconferenceoncommunications.[s.l.]:IEEE,2011:1-6.
[20] 劉外喜,余順爭,蔡 君,等.ICN中的一種協作緩存機制[J].軟件學報,2013,24(8):1947-1962.
[21]TharK,OoTZ,PhamC,etal.Efficientforwardingandpopularitybasedcachingforcontentcentricnetwork[C]//Internationalconferenceoninformationnetworking.[s.l.]:IEEE,2015:330-335.
Research on Content Centric Networking and Its Caching Strategies
DUAN Lian,YANG Long-xiang,REN Mei-cui
(College of Communication and Information Engineering,Nanjing University of Posts and Telecommunications,Nanjing 210003,China)
Use of Internet in today’s world has evolved to be dominated by distribution and retrieval of content,while currently used IP architecture cannot meet this demand.Content Centric Networking (CCN) breaks the traditional “host to host” communication mode,making content in the core position is one of the research hotspots.CCN decouples content from host and stores the content in every node.Any node can act as host and serve client if the requested content has been cached in it.Thus,CCN can deliver content efficiently.These advantages are mainly based on that CCN supports in-network caching,so it can be concluded that caching is backbone of CCN.The performance of the caching strategies directly affects the performance of CCN.The difference between the CCN and IP is summarized in brief,and then the key concepts and working mechanism of CCN are introduced.Finally,some proposed caching strategies have also been covered along with analyzing their advantages and disadvantages.
content centric networking;future network;network architecture;caching algorithm
2016-04-22
2016-08-10
時間:2017-02-17
國家自然科學基金資助項目(61372124);國家“973”重點基礎研究發展計劃項目(2013CB329104)
段 煉(1991-),男,碩士,研究方向為移動通信與無線技術;楊龍祥,教授,博士生導師,研究方向為移動無線通信系統和物聯網。
http://www.cnki.net/kcms/detail/61.1450.TP.20170217.1628.036.html
TP31
A
1673-629X(2017)03-0075-06
10.3969/j.issn.1673-629X.2017.03.016