摘要：
隨着通信技術和製造工藝的不斷進步，IoT（物聯網）的概念被提出，並迅速發展，成爲繼互聯網，計算機後的又一重大技術革新，IoT極有可能成爲未來計算機與通信的發展方向。同時，由於物聯網設備與傳統互聯網中運行的設備之間差別甚大，IoT應用所帶來的技術問題和挑戰需要深入研究和思考。information-centric-networking（ICN）是一種新型的未來互聯網的設計方案，基於其內容中心網絡的特性，ICN能夠爲IoT應用所面臨的問題和挑戰提供可能的解決方案。本文針對ICN在IoT上的應用以及應用中出現的問題和挑戰，總結了到目前爲止，國際上對於該問題的研究和討論，同時深入瞭解各種研究的思路、優點和不足；並基於此，指出ICN在IoT應用的未來發展方向和新的研究突破點。
一、引言：
IoT（物聯網）是一種新興的網絡概念，在internet的基礎上，提出萬物相連的理念。IoT的功能是將大量的異構設備與互聯網相連接，設備包括車輛，電子電器，可穿戴設備比如無線射頻識別標籤（RFID），計步器等，這些設備通常嵌入傳感器、執行器、內存等元件，並具有網絡連接能力，他們主要用於傳感，監測以及控制等各種應用場景。由於應用的廣泛性，IoT逐漸成爲一個熱門的話題，並且受到了工業界和學術界的廣泛關注。
在物聯網社區目前熱門的話題是智慧城市。智慧城市目前處於設計階段，在不久的將來會成爲現實。在智慧城市中，IoT設備廣泛地部署在基礎設施中，比如智能建築、智能辦公室等，不僅如此，在其他領域，IoT也能夠實現很多應用，如智能家居，智能汽車，工廠，環境監測等。
目前的互聯網連接骨幹協議是IP協議，IoT亦是在IP架構上設計運行的。然而物聯網中往往包含許多資源受限的設備，這些設備的內存更小，計算能力和能源（通常是電池供電）受到限制。許多物聯網應用要求設備能夠在不具有工具設施的偏遠地區運行更長時間，比如森林。由於這些條件約束，物聯網設備通常配備第二層技術比如IEEE 802.15.4以及低功耗藍牙技術，因此，他們採用的MTU大小遠遠小於目前因特網中使用的MTU。此外，IP模式的設計歷史可追溯到幾十年前，它最初的設計理念是基於host to host的通信模式，共享資源而不是內容。這就意味着每個連接的設備必須通過主機名或者IP地址唯一尋址。而由於IP地址的限制，當數十億設備進行連接時，如何進行地址分配成爲一個難點。
除了協議之外，大量IoT設備之間的通信問題也應引起關注。在任何情況下，物聯網的大量設備都能輕易產生數十億大小的數據。目前在IoT上運行的通信協議都是依賴點對點的連接，因此容易遭受鏈路故障的影響。物聯網的許多節點使用數據存儲和代理服務器，引入了潛在的單點故障。
此外，還有一點不能被忽視：目前幾乎沒有任何的協議能與每個協議兼容。而在IoT中，不同的傳感器網絡應用的特殊要求和特點導致了獨立的發展不兼容的通信協議和服務模型。
Information centric networking（ICN）是一種新的網絡範例，在ICN中，打破了TCP/IP以主機爲中心的連接模式，變成以信息(或內容)爲中心的模式，節點之間的數據交換是基於內容的名字，而不是端點的IP地址。這種從“基於位置的”網絡轉變爲“以內容爲中心”的網絡爲內容傳播提高了效率，尤其當內容存儲在多個節點中，並且內容提供者或者內容請求者在移動中。由於ICN諸多設計實現中提供了節點的緩存功能，這些廣泛的緩存能夠進一步提高網絡運行性能。由於ICN設計理念的新穎，ICN研究羣體迅速增加，開發者們對ICN的路由，轉發，緩存，命名等方面的研究日益增多。
與ICN類似，在物聯網中，設備感興趣的是數據內容而不是他們的位置，也就是說，IoT實際上是以內容爲中心的。因此ICN的設計適用於物聯網，不再需要維持點到點的通信。目前提出的ICN的設計方案中，比如named data networking（NDN）和content oriented publish/subscribe system，後者在NDN的基礎上提供了一個高效的發佈/訂閱功能，並採用可讀性強、分層結構的命名方案和內容描述符（CD）。ICN中名字空間是無界的 能輕易地支持數十億臺設備，甚至更多。在安全性方面，ICN直接在內容中進行加密而不是在通信鏈路上，安全性得到加強。值得一提的是，IoT並不需要完整的content centric networking（CCN）/NDN協議棧，一些輕量的實現如CCN-lite就能夠支持IoT設備。
二、IoT應用ICN的優勢：
數據和服務的命名機制
在物聯網的大多數應用中，數據和服務是最主要的實現目標，而與具體設備進行通信則是次要的。ICN通過IoT設備分發數據內容並提供服務，而不是在兩個設備之間建立一個通信鏈路。在很多物聯網設備冗餘的場景下，數據內容和服務能夠由幾個設備或者一組設備來提供，因此命名數據和服務通常比命名設備更爲重要。
分佈式緩存
雖然很多其他類型的覆蓋式網絡已經採用了緩存機制，由於IoT網絡的資源限制，IoT網絡能從緩存機制中受益更多。無線帶寬和電源供應可以限制多個設備共享一個通信通道。在這種情況下，避免IoT設備的不必要的傳輸，將IoT數據檢索和分發到多個地方顯得很重要。而在網絡中存儲數據內容能夠減少無線網絡的帶寬和電池能源的損耗。不僅如此，本地的緩存能夠減少內容請求和分發之間的延時，這對於一些需要短暫延時的IoT應用非常重要。
內容發佈者和用戶之間的解耦
IoT設備大多數是移動的或者間斷性的網絡連接。當設備請求具體數據時，數據可直接通過ICN緩存進行傳遞，而不用任何兩個設備的直接連接。除了如前所述的使用結構化緩存系統來傳輸數據，信息也可通過數據的機會轉發進行傳播。這種在數據發佈者和用戶之間的去耦爲物聯網的應用程序和服務之間的數據橫向共享創造了更多的可能性。
特別的，這爲物聯網中用戶的機動性提供了內在的支持。當用戶設備在整個網絡中移動時，不在需要維持長時間的有效連接或者更新設備的拓撲位置，因爲對數據的每一個請求都是獨立的。因此, 在請求流對象時，將從用戶設備移動到的新位置發送新的請求，如果設備能 預見接入技術之間的切換，它可以通過發送多個請求來進一步提高性能，同時減少某些返回數據包丟失的風險。
三、IoT應用ICN的問題和難點
如上面所描述的， ICN的應用能爲IoT帶來很多好處。然而爲了使IoT網絡獲得一個靈活的、高效的架構，當ICN應用在IoT上時，需要對ICN進行一些特定的思考和改進。這一章重點描述了ICN應用在IoT上的一些具體的難點。
路由方法的挑戰
IoT設備的內存受限，也限制了ICN路由方法的可用性。目前的提案通常是直接或間接利用命名進行路由操作。在IP層進行名字解析是不可行的，甚至一些純基於命名的路由方案，比如[1]和[2]，也需要IP的支持。而使用積極的鏈路狀態算法，該算法會導致（a）大量的控制流量，（b）大量的數據存儲，一般是O(n)，n是網絡中節點的數量。這些特徵與IoT設備有限的內存和能量資源並不匹配。
在IoT設備上運行的路由協議必須要滿足複雜度爲O(1)的路由狀態和最小的控制流量-理想情況是0，也就是幾乎沒有控制流量。
- M. Hoque et al., \NLSR: Named-data Link State Routing Protocol," in Proc. of ACM SIGCOMM WS on ICN, 2013, pp. 15-20.
- L. Wang et al., \Ospfn: An ospf based routing protocol for named data networking," 201
設備、數據和服務的命名
ICN的數據和服務命名方法對於IoT通常是可取的，然而以數據爲中心的命名也可能帶來挑戰。
- 設備命名
設備的命名在物聯網中非常重要，執行器通常會要求客戶端在設備上進行一些操作，比如開關的打開和關閉。此外，對設備進行管理和監控也需要一個特別的命名來唯一地識別它們。
- 數據/服務名稱的大小
在以數據爲中心的應用中，數據的大小一般是大於數據的名字。對於IoT而言，傳感器和執行器非常常見，由於它們通常採用以太網通信技術比如IEEE 802.15.4和BLE，MTU的大小會遠遠小於傳統的二層互聯網的MTU，因此生成或者使用數據類型爲短整數型的數據，或者利用一個比特的數據實現控制。對於每一塊數據，它們的內容命名必須能夠唯一地標識內容。對於許多物聯網應用而言，許多現有的命名方案都有很長的命名，比實際的數據內容更長。雖然對於開銷較大的數據對象，這是可以接受的，然而當數據對象大小爲幾個字節，卻是不可行的。
- 基於哈希的內容命名
爲了確認數據的有效性，廣泛採用哈希算法對數據進行命名。然而這僅僅當所需要的數據對象已經存在，以及存在目錄服務對名字進行查找時纔可能實現。該方法適用於具有大數據的系統，且需要對內容進行驗證時。然而對於在IoT中，數據是動態生成的情況而言，如何運用這種方法是一個難點。
- 服務的命名：
與數據和設備的命名相似，在IoT中，服務可以通過唯一的標識符進行引用。與基於哈希的內容命名相反，這種服務能夠由一組設備通過ICN實現，例如 匹配某些元數據條件的，類似的服務包括內容檢索、採取內容名稱作爲輸入並返回該內容，或者以執行命令作爲輸入 之後可能返回一個狀態代碼。
分佈式緩存的效率
分佈式緩存是ICN的核心特徵。然而， 爲了最大程度上利用ICN的緩存機制，物聯網框架必須要經過更爲合理的設計。當內容的流行度是異構時，一些內容數據通常會被重複請求，這種情況下，網絡能夠從緩存機制中獲益。
然而，當每個目標數據最多只需要一次時，分佈式緩存的作用就無法凸顯出來了，因爲緩存只從第二次之後需要某個數據時才能發揮作用。另外，當網絡中存在分佈式倉庫作爲覆蓋層時，ICN的緩存作用被削弱，比如雲存儲或者Content Distribution Network (CDN)，所有客戶端都可以從中檢索數據。使用ICN協議從這些服務中檢索數據毫無疑問是有幫助的，但對於存在大量的CDN服務器作爲覆蓋層時，ICN緩存機制所帶來的性能優化會有所折損。
同時，在ICN有線網絡中，雖然網絡緩存已經得到了廣泛的研究 ，由於IoT對信息實時性的嚴格要求以及IoT設備有限的資源，爲internet設計的傳統的緩存算法顯然不適用於IoT。
IoT數據生成模式與ICN數據傳輸模式的矛盾（鏈路流量優化問題）
在IoT應用中，訂閱/通知是非常重要的通信模式，它允許對數據進行任意條件的篩選。比如，在智能家居場景中，只有當樓層溫度小於40F時，用戶才需要收到通知，也就是有條件的訂閱/通知。而在物聯網一些其他場景中，存在一些低功耗的網絡，這些低功耗網絡由一些傳感器，低功耗用戶以及其他網絡設備組成，因此單個內容提供者可能會有多個用戶的不同的時間粒度的請求，比如溫度傳感器以高頻率向火災報警系統發送數據，10秒一次。而對於自動調溫系統，5分鐘一次的數據傳輸足矣。因此，信息不應該多播給每個用戶，對於自動調溫系統，10秒鐘一次的數據傳輸會增加29個無用信息開銷。
因此對於使用訂閱/通知機制的ICN而言，如何使其適應IoT的數據訂閱模式，減少鏈路開銷，值得考慮。
協議轉換與網關設計
一般而言，IoT網絡是個局域網，而如果要對IoT設備進行遠程控制，必須利用網關使其連入互聯網，而當ICN應用在IoT網絡中，ICN協議與internet所使用的協議存在差異，比如，一個典型的場景如下：
IoT網絡中包含傳感器和基站BS，它們運行CCN的一個輕量級的實現協議CCN-lite，而用戶所在的互聯網使用的是完整的ICN協議棧，比如NDN協議棧。
由於IoT網絡與internet採用不同的協議，爲了保證協議棧的互相通信，需要通過網關進行協議轉換。而在網關設計中，有幾點需要注意：
- 網關要同時運行IOT網絡和互聯網網絡協議
- 網關應該配置必要的功能和數據結構，從而在兩個網絡進行業務透明流傳輸。
內容發佈者和用戶之間的解耦
將發佈者和用戶之間進行解耦是由ICN提供的一個有效的策略，特別是對於週期性的設備和間斷性連接的設備的信息檢索。然而，爲了有效地檢索數據，用戶必須要簡單的推斷出所需要內容的名字，而不與信息發佈者有任何直接的連接。
解耦爲用戶的移動性問題和消除維持長期連接的需要提供瞭解決問題的方法。然後，對於發佈者的移動的情況，當一個移動中的設備產生併發佈一個數據對象，仍然會存在很多問題與挑戰，因爲在現如今的互聯網機制下，將數據請求通過路由轉發至所需要的數據所在的網絡位置是必要的。
不僅如此，當身份需要進行管理和驗證，或者設備之間需要進行實時通信時，解耦策略的應用存在問題。因此，對於向用戶安全身份認證進行解耦以及對於實時數據的傳輸方式進行解耦，是需要進一步研究的。
四、對ICN在IoT中路由改進的研究
- Information Centric Networking in the IoT: Experiments with NDN in the Wild
Vanilla Interest Flooding (VIF)
對於需要路由狀態最小化而言，最簡單的路由算法就是interest泛洪，網絡中的每個節點都重複轉發interest，直到interest第一次被接受。當使用VIF時，即使用戶的FIB是空的，仍然可以傳播interest，接着，泛洪的interest會到達內容生成者，然後由內容生成者將interest所需要的數據回傳給用戶。
VIF是適用於IOT中資源受限的設備。原因如下：
- VIF不依賴於任何額外的控制流量來維持FIB
- VIF滿足最小的路由狀態，只有在返回的路徑上的暫時的interest是被接受的，這裏的interest是表示沒有找到任何匹配的數據。
實驗場景配置
平臺：RIOT（物聯網操作系統）
測試平臺：testbed of Freie Universitat Berlin，60個節點分佈在多個建築物，多個樓層以及多個房間中。如下圖所示：
下圖展示了在NDN上使用VIF算法的單用戶場景的模擬結果。在該實驗中，用戶定期的請求大小爲5，10以及20的數據內容，
實驗結果表明NDN成功在IoT設備上運行，並且用戶可通過NDN獲取內容數據。通常來說，一個網絡中有n個節點，k個內容數據，對於單個內容所需要的傳輸量爲k*((n-1)+√n)，假設平均路徑長度爲√n。我們注意到雖然VIF比較簡單並且在設置的場景上正常工作，但是當網絡規模增大或者內容增多時，VIF中的無線電廣播數量不能很好地擴展，從能源的角度，對於由電池供電的IoT設備，無線電的發送和接受的花費高昂。因此接下來的第二種算法改進了VIF。
Reactive Optimistic Name-based Routing(RONR)
爲了減少無線電傳輸的數量，我們提出了Reactive Optimistic Name-based Routing (RONR)，該算法利用第一個interest數據塊，在回傳路徑節點上自動配置一個臨時的FIB的條目，這樣當FIB是空的時或者FIB沒有條目匹配內容的名字或前綴時，只需要對最初的單一interest進行泛洪，隨後的請求類似內容的interest可以利用FIB的入口進行單播，避免了泛洪傳播。
RONR是樂觀的路由算法，其假設所有的內容都存儲在一個節點上，這種情況通常是不常見的。然而，在IoT中這個假設非常合理，因爲IOT典型的數據大小爲幾百byte。除此之外，FIB條目的超時機制確保如果FIB的條目所引導的節點中並不包含所有內容，用戶最終會轉向利用最初的interest 泛洪算法，通過泛洪算法可以找到包含剩下內容的其他節點。在無線多跳場景中，這種超時策略在反應式路由中很常見。
下圖展示了在NDN上使用RONR的測試結果，拓撲結構和實驗場景都與VIF測試相同。
可以看出，與VIF相比，無線電的傳輸減少了50%，尤其是廣播的傳遞大大降低，這得益於RONR，只有第一個interest數據包需要泛洪，剩下的interest包只需要單播即可。對該網絡進行簡單的量化分析，n個節點和k個內容塊，需要傳輸的數量爲(n-1)+2(k-1/2) √n，可以看出，當網絡規模變大時，RONR的性能表現優於VIF，RONR更適用於IoT設備。
RONR算法可以更爲樂觀以及進行暫時的前綴聚合，例如，一個FIB條目指向接口所連接的內容的前綴爲/riot/text/*，而一個請求/riot/temp/c數據的interest被同一接口也就是同一節點接受並返回數據，那麼可以將前綴聚合爲/riot/*併爲此創建新的FIB條目，最好的情況下，該聚合只需要利用該前綴通過單播命中所有需要的數據內容，而最糟糕的情況，用戶會轉向利用interest泛洪。
疑問：對於新建的FIB條目，是否要將其刪除，還是將舊的條目刪除，受限於IoT設備的資源，FIB不可能具有很大空間。
對於不包含所有內容時FIB的超時機制，該如何設置時間上限，如果根據網絡節點數目和網絡規模而定的話，由於IoT是一個動態變化的網絡，如何確保時間上限的值也隨着網絡規模變化而更新。
2. Towards Exploring the Benefits of Scope-Flooding in Information-Centric Networks
Scope Flooding 算法
用戶向網絡請求數據，發送一系列的interest數據包，當發送第一個interest之前，發送一個search interest，該數據以泛洪的方式探索網絡中的所需數據的備份， 當search interest到達一個節點時，會在其content store 表上進行最長匹配查找，如果匹配到所需要的數據，節點生成search data 包，該數據包僅僅是一個內容回覆包並不包含任何數據，search data包將通過interest到達的接口進行轉發。空的內容轉發確保能夠避免緩存驅逐。而如果沒有匹配到所需要的內容，search interest中scope的值減1，當scope爲正數時，search interest會進行泛洪傳播；反之則丟棄search interest。在search interest達到節點的同時，一個PIT條目會被創建，並對interest 數據包的入口和出口進行監控。
由於泛洪，一個search interest包可能會觸發多個search data 包。那麼當第一個search data 包到達節點，該節點會搜索器PIT表來匹配interest，如果匹配成功，節點檢查search data包中的跳數是否小於該節點與源節點之間的跳數，若所需的內容能夠在源節點找到並且與備份節點相比，花銷更少，那麼傾向選擇源節點。上述條件如果成立，節點會在Temporary Forwarding Interest Base（TFIB）中尋找對應內容名字的條目，當條目不存在，會創建一個新的，否則條目會被更新爲當前獲得的指標，隨後search data 包會基於PIT的條目進一步回傳，最終當search data 包到達用戶節點或者search data包超時，用戶開始獲取數據內容。
當節點接受到實際請求數據的interest包時，首先在cs table中查詢，如果沒有找到，轉向TFIB table尋找對應的轉發策略，若TFIB也沒有找到對應的條目，interest會基於FIB table進行傳播，接着interest 請求會在PIT table中保留一個條目，隨後請求同樣內容的interest則會被抑制。要注意的是，search包不能採用抑制策略，因爲這些interest可能包含不同的scope值，合併這些值會導致錯誤的泛洪結果。最終，當最後一個數據包交付完成， 執行緩存決策。
利用ndnSIM模擬器進行仿真評估，並與最短路徑路由算法（SPR）比較，結果表示Scope Flooding 算法性能優於SPR。
未來可改進的工作：可考慮對TFIB條目進行管理，比如在生命期滿時刪除一個條目值，TFIB的生命期限的計算基於那些擁有備份數據的節點的平均替換時間；或者是當備份缺失的通知消息到達節點時，對TFIB條目的刪除。
對路由的一些想法：上面的兩種都是基於泛洪進行改進，若直接利用回溯算法進行最優路徑計算呢？
五、命令方案的研究
- ISI: Integrate Sensor Networks to Internet with ICN
實驗場景
如下圖所示，類似一個小的智能建築，建築中包含溫度傳感器，GPS，以及基站
Naming in IoT
我們提出一個命名結構：Metric/ID/Area/Date/Time
第一部分Metric明確了是IoT設備產生的何種數據，比如溫度，壓力，溼度等。
第二部分ID指出設備的編號。
第三部分Area表明IoT設備所在的位置/地理範圍，比如房間，建築，GPS定位等。
第四部分Date詳細說明了數據測量的日期
第五部分Time表明設備讀取數據的時間
將該命名方案應用到上述智能建築場景中，比如在2016年11月3號12:30，一個id爲01的設備在房間1產生了溫度數據，那麼該數據命名爲：/temp/01/r1/03-11-16/12:30，該命名大小僅有26B，能夠節省許多空間。
在大多數傳感器網絡，通常利用基站週期性的收集數據，爲了區分這些數據，可使用如下命名方案: /Metric/BS/Area/Date/Time，對於基站存在的情況，Area所代表的不再是單獨的房間而是整個建築。
2. Design Choices for the IoT in Information-Centric Networks
對數據命名的思考
由於IoT數據通常比較簡單，在ICN應用中的存在一個問題：如何將數據組合或者聚合，來保證有效的命名和查找。在此基礎上，如果請求其中部分數據，這就類似數據庫的查詢操作。而對於ICN，不應該有對於查找數據或者查找部分數據的新的要求，而應該定義一個物聯網框架去解決。ICN所支持的應該只是原子數據的命名，任何的查詢操作都應該由IoT框架完成，框架中可以包含一系列高度集中的節點來提供數據的處理，分析和聚合。
因此一個可選的設計爲不要求ICN網絡支持高級的數據搜索，只支持直接可尋址的數據對象，任何高級或者組合的數據將會在應用層進行處理而不是ICN協議棧內部。這就避免了對ICN提出新的要求，並且確保ICN網絡的計算量很小。
Data naming in streams of immutable data objects：
IoT的設備和其產生的數據的數量都很大，如果我們允許數據作爲可變對象，緩存不一致的問題可能會變得很嚴重。而爲了支持網絡的可拓展性和水平分佈，在最小化對動態全局同步的需求的同時，確保數據具有獨立性和一致性顯得非常重要。
關鍵的設計是確保IoT只使用不可變的原子數據對象，確保ICN中沒有陳舊的數據，能夠支持大規模的分佈。
許多IoT設備週期性的產生數據，而當使用上述設計時，需要利用不可變的數據對結果數據流進行建模。這與視頻流類似。由於傳感器頻繁發出不同版本的新數據，必須要有對這些不同數據進行區分。
爲了有效地支持不可變的流數據，建議給數據命名時加上一個序列號，當請求中不包含序列號時，將最近的緩存數據作爲回覆，而若請求包含序列號，只有對應的緩存能夠作爲回覆。
對於序列號的支持取決於ICN的特定實現版本，CCN/NDN可能更具有優勢，而是否可以支持使用不支持序列號的ICN（比如通過巧妙地使用元數據、命名空間， 和搜索功能）。
未來可改進的工作：序列號空間的大小和序列號之間的間隔。序列數字空間中的間隔可能導致效率低下，或者若間隔過大，導致不可實現，目前來說，並不是總能保證不存在間隔。
六、對ICN在IoT中的緩存改進的研究
- Performance Implications for IoT over Information Centric Networks
這篇論文研究了ICN的緩存，併爲IoT中的定期傳感器數據介紹一種提高緩存效率的方法 ，新提出的cache方案：UTS-LRU：Update Time Series - Least Recently Used。
論文中建立的IoT over CCN 的模型
模型特點：
節點在內存和計算資源上受到限制。
由於節點資源的限制以及大數量的設備，效率和可伸縮性是主要的考慮點。
內容數據生成並被髮布爲時間序列數據，用戶所關心的是一次測量中的最新數據，因此對於用戶而言，數據週期短暫，而用戶所感興趣的是一個特定時間窗口中的數據。
網絡中的邊緣鏈路通常是無線且有損的。但是和其他網絡不同，內容發佈者通常是傳感器，因此發佈者也可能會與有損耗的無線鏈路連接。
評估場景：
我們將我們的評估集中在一個反映真實場景的特徵的典型的拓撲上，拓撲類型是基於 Barabási-Albert (BA) 圖（無標度網絡）
無標度網絡：無標度網絡具有嚴重的異質性，其各節點之間的連接狀況（度數）具有嚴重的不均勻分佈性：網絡中少數稱之爲Hub點的節點擁有極其多的連接，而大多數節點只有很少量的連接
圖1：Barabási-Albert，共30個節點，10個傳感器（白色），20個用戶（藍色）
爲了確保評估結果不是特定於某個特定的場景。我們進行了兩個BA場景的評估，結果相似度很高，因此在這篇論文中，我們只提供了一個實例的結果。
網絡拓撲的參數：
鏈路模型：
在IoT網絡中，在內容發佈者和用戶的附近，總是存在無線連接，並且無線連接通常部署在具有衰落鏈接的動態環境中，鏈路可能長時間的衰弱或停用。我們試圖利用馬爾科夫鏈捕捉鏈路的行爲。
每一個鏈路都在活動的和中斷的兩個狀態中變化，狀態的變化是基於傳輸概率矩陣。這種模型稱爲吉爾伯特-艾略特模型。鏈路處於活動狀態時，丟包率低至P=0.01，而當處於中斷狀態時，丟包率高達P=0.5。這個簡單的模型捕捉了丟包率的時間相關特性並提供了比獨立於時間的隨機丟包率更爲精確的模型。
首先評估ICN的緩存策略在有損鏈路中的運行情況
下圖是描述傳輸數量與緩存大小的結果圖，緩存概率爲100%，80%和60%。
由圖可以看出，當緩存的大小爲0時，傳輸完畢的數據的數量最大，隨着緩存的增加，數據的數量開始急劇下降。在設置的場景中，存在10個節點作爲內容發佈者，從圖中不難發現，當緩存的大小與數據流的大小處於同一數量級時，已傳輸的數據的數量低於原來的一半。也就是說，當數據請求與時間高度相關且限制在某一個時間週期發佈，緩存大小如果遠遠超過內容數據流的大小時，緩存對於網絡性能並不會有所改善。相反，當緩存資源較少時，基於概率的緩存策略將內容分散到各個緩存中去，能夠提高緩存的多樣性，然而在圖中，我們發現緩存概率的降低並不會爲傳輸數據的數量提供幫助。這是因爲在我們的場景中，內容流的數量非常少，這導致緩存所帶來的幫助幾乎不可見。
UTS-LRU緩存替代策略
在上面我們指出了緩存的大小並不需要比數據流大很多。我們感興趣的是在知道數據內容是週期性產生的，並且用戶所關心的是最新的數據的基礎上，能否找到一個提高緩存管理的策略。
不同流中的內容能夠以不同的速率進行發佈和使用，因此如果一個內容發佈的頻率更爲緩慢，由於對該內容的請求已經持續很久，該內容將會被緩存驅逐出去。相反的，如果同一個流的最新的數據替換了之前的數據，那麼就能提高該緩存的命中率，基於這個想法，我們提出了一種替換緩存的實現策略：首先在同一個流中查找能夠替換最古老的數據，如果不存在，則轉向使用原始的LRU策略，我們將該策略命名爲：UTS-LRU(Update Time Series - Least Recently Used).
下圖比較了LRU與UTS-LRU的性能：
不難看出，UTS-LRU的性能總是優於初始的LRU策略，最好情況下，UTS-lRU相對LRU能夠少發送16%的數據。除此之外，採用了UTS-LRU策略的已發送的數據的數量在當緩存大小與數據流的大小相同時變得平緩，而採用LRU策略的數據的數量會在緩存更大時變得平緩。由於不同的數據流的發佈速率以及其他隨機的時間因素的影響，不同的流的最新數據達到緩存的順序是不一致的， LRU可以替換在網絡中仍然被請求的對象，因此LRU要替換所有流中的最新數據，而UTS-LRU通過替換同一種流中的舊數據來減少這種情況的發生，這使得對於LRU的緩存大小的要求要超過UTS-LRU。
思考：由於場景的限制，UTS-LRU算法的侷限性較大，對於非重複的數據，算法則失效。
未來可改進的工作：希望能夠將該算法的評估擴展到具有更大範圍的不同拓撲和訪問模式。對於UTS-LRU在數據的觸發，執行器和報警數據上的應用，也有一些挑戰和問題，因爲每一個涉及到一個不同的內容模型。
- Caching in Named Data Networking for the Wireless Internet of Things
緩存策略：pCASTING（probabilistic CAching STrategy for the INternet of thinGs）
假設IoT場景中共存在N個資源受限的節點，其中C個節點作爲用戶，一個節點作爲內容生成者P，剩餘節點作爲轉發節點，能夠緩存數據包。緩存決策是完全分佈式的，並且由兩步組成。
- 緩存概率的計算，這需要考慮到與設備和內容相關的一些動態特性。
- 實際的概率決策，決定是否進行緩存。
關於設備的動態特性，主要有兩個參數：電池電量以及緩存佔用率。緩存概率應與電池電量直接成比例，當電池電量低時，應停止緩存活動。因此將電池電量設置爲歸一化變量EN（0<=EN<=1），0表示電量爲0,1表示滿電。而緩存概率應與緩存佔用率成反比，將緩存佔用率歸一化爲OC（0<=OC<=1），0表示緩存是空的，1表示緩存已滿。
而對於內容的動態特性，主要考慮內容的新鮮度。較新的數據包在緩存決策中應該更佔優勢，因爲更可能滿足用戶的需求。因此定義歸一化的數據新鮮度FR：
如果ts與currenttime相同，FR爲1，代表內容是新生成的，而當currenttime增加時，新鮮度下降。FR爲負數表示數據包過期，不會緩存。
緩存概率的計算：
定義一個緩存能力函數Fu，並將EN，OC，FR作爲參數：
其中Np=3，表示三個參數，Wi是權重比，表示該參數在緩存能力計算中的重要性。而g函數應滿足爲遞增或者遞減函數，並且當參數xi越接近臨界值，對結果的影響越大。因此
選用冪函數作爲原型。最終結果爲：
利用ndnsim仿真器將該緩存算法與其三種他算法進行比較：a) the Caching Everything Everywhere strategy, CE; b) a probabilistic scheme, p = 0.5 c) the no caching scheme。
仿真結果表明，與其他方案相比，pCASTING減少了大量的鏈路流量。
未來可改進的工作：
- 在緩存決策中包含其他屬性
- 評估緩存與不同路由之間的相互作用。
七、ICN訂閱/通知模式的改進（開銷優化問題）
- CCN Traffic Optimization for IoT
在CCN中，只有接收到interest，節點纔會轉發數據，因此CCN的基本使用方法是用戶直接向內容提供者請求數據，如下圖所示，這種機制稱爲pull。
而在ICN上運行push的概念也被提出能夠作爲可能的解決方案，push的概念與IP的多播類似，如下圖所示。
目前基於push設計了發佈-訂閱機制，但該機制仍然基於IP。因此文章中提出一個策略，利用FIB進行數據的push，也就是說，訂閱請求類似於將內容記錄在FIB中，而傳感器數據的發佈類似於interest的散播，因此數據不會被緩存，而是作爲單方向多播的信息，比如，直接在interest中傳播非常小的數據，/roomA/temperature/ts=10/value=20，這樣的interest通過FIB轉發，而不在PIT上創建任何條目，因爲沒有返回數據。然而，在PIT上創建一個條目的優點是能夠避免路由迴環。因此爲避免該情況，我們在內容名字中使用一個時間戳，同時在FIB創建新的區域稱之爲last_seen確保只對最新的數據進行路由轉發，而對於一個新的傳輸，總是會檢查last_seen的值保證最新的數據能夠被轉發，而陳舊的數據被丟棄。這樣可節省帶寬和避免迴環。
優化轉發策略
爲了以最佳方式減少消息開銷，可以結合pulling和pushing的優點，在用戶在t時間發送interest的條件下，路由器纔將數據轉發至用戶，t是採樣時間的倍數。因此，當用戶訂閱數據時，要明確採樣時間這樣路由器能夠根據計時器進行追蹤。比如t爲2，也就是時間爲2或者2的倍數，才訂閱該數據，其他時間並不是用戶所需的數據，因此路由器不會轉發。這解決了不同用戶對於數據不同時間週期的需要，如下圖所示：
然而這個優化轉發策略需要額外的計數器，計數器的值需求很大，而受限於有限的資源，計數器的值不能很大，因此存在問題。
改進措施是提出一種智能轉發策略，智能轉發策略的目標是細化推送模式，同時限制轉發消息的數量，比如最糟糕的情況下，單個計數器要判斷多個採樣時間，i1=2，i2=4，那麼計數器只要在1和2之間循環即可。因此可以利用最小公約數，在下圖中，i1=4，i2=6，那麼計數器只要循環gcd(4,6)=2即可。
未來可改進的工作：文中的工作都是基於單個IoT設備（內容提供者），未來可拓展至多個IoT設備，進一步評估該策略的性能。
2. Design Choices for the IoT in Information-Centric Networks
定義pull就是隻有當數據被請求時纔會被髮送，push則是數據是由源主動發送的，這兩個模型之間存在內在的權衡，pull模型是網絡中存在大量的，冗餘的信息，而用戶只是對部分信息感興趣，push模型是當網絡中產生實時數據時，用戶對特定的設備的所有數據都感興趣。
對於IoT的設計選擇則是主要支持pull，同時對push有一些特定的支持，因爲ICN本身是pull模型。pull模型的缺陷是某些情況下檢索新數據可能效率低下。網絡必須支持無限期的掛起的請求狀態，有些ICN網絡可能不支持這樣的一個特徵。而我們的設計則是必須支持此類的觸發信息，因此在請求中也可包含觸發，這意味着當觸發條件滿足 時將返回數據（push），這種設計可以用來選擇報警條件，要求連續的或定期的推送等條件。在這種設計下，ICN就不用實現push模式了。
3. INADS: IN-NETWORK AGGREGATION AND DISTRIBUTION OF lOT DATA SUBSCRIPTION IN ICN
ICN目前的發佈/訂閱機制並不適用於IoT中基於數據變化進行發佈/訂閱的特性，因此提出對於網內interest包聚合分配的概念。
FIB在NDN中本是用來轉發interest，追蹤內容生產者的，爲了對ICN的發佈/訂閱機制進行改進，我們改進了對FIB的結構，進一步利用FIB來跟蹤訂閱的分佈，訂閱的到達能力以及對應的通知的狀態。如下表所示
Forwarding Face List to Subscriber and Associated Condition (FFLS)，該值記錄了訂閱信息的傳入接口以及聚合的情況。
ICN路由器會從多個不同 設備接收到多種訂閱信息。比如下圖所示，有三個訂閱者也就是用戶訂閱同一數據”/example.com/temp”，分別與路由器3,4,5相連，而聚合的訂閱信息會記錄在FIB中的 Forward Face List to Producer (FFLP) 中，該記錄是用來決定如何爲信息提供者分配數據回傳任務。訂閱者3訂閱信息的要求是value>80，因此在路由器4中，FFLS收集了該信息，然後FFLP進行聚合，由於只存在一個信息，因此聚合信息也是value>80，對於路由器2而言，FFLS有兩個訂閱要求: value>80和value>60，因此FFLP對信息進行聚合，也就是value>60。
在場景模擬中，存在兩種情況：單個內容提供者和多個內容提供者。對於前者而言，當路由器接收到對信息的訂閱請求時，路由器首先判斷該請求是不是FFLP中已經存在的請求的子集，如果是，就表明FFLP中已存在的請求可以保證能夠回傳數據至該路由器，並不需要再添加FFLP條目了，因此路由器會丟棄該請求，但會在FFLS中記錄該請求進入的接口。另一方面，如果該請求不是已存在子集，該請求會在FFLP中記錄下來。
而對於場景中存在多個內容提供者，需要注意的是當前接收到的訂閱請求可能與其他路由器的FFLP的訂閱請求記錄有部分重合，也就是存在交集，這種情況下，既不能直接丟棄也不能將該請求全部用於FFLP記錄，而應該只記錄下請求中除了交集以外的部分請求。算法如下：
測試結果：
利用模擬器對提出的INADS聚合算法進行評測，並與COPSS進行比較。
測試指標如下：
內容生產者發出數據的平均數（ANN），更少的ANN表示更少的能源消耗。
在傳輸過程中帶寬減少的百分比（BUR）
結果表明，無論內容提供者的數量如何變化，COPSS的ANN值保持不變，而對於INADS算法，隨着內容提供者的數量增加，ANN的值減少。說明INADS通過對請求的聚合，有效減少了鏈路中的數據流量。
可能的創新點：不用路由器，而直接用節點進行聚合。
八、網關的研究
1.Content centric networking in the Internet of thing
CCN網橋
平臺：There公司的家庭自動化系統平臺。該平臺支持溫度、溼度和能源消耗的無線傳感器。中心網關採用there公司基於Linux的路由設備稱之爲ThereGate，該設備支持多種無線技術，例如Z-ware和ZigBee。可通過REST API和HTTP進行遠程接入。
- CCN presentation bridge
爲ThereGate實現一個新的網橋，能夠通過CCN與外部網絡通信，我們稱之爲pb-ccnx，默認的HTTP是利用GET獲取數據，返回的數據頭部是’200 Ok’，在CCN中，是利用InterestMessage(IM)請求數據，而返回數據形式爲contentobject（CO）。
CCN倉庫運行在ThereGate中來存儲傳感數據，可以儘可能的存儲數據，這些數據也可分派到外部網絡。
- 組件描述
下圖描述了CCN網關中的組件：
CCN網橋的核心是pb-ccnx，是CCN與ThereCore的耦合。Ccnd是CCN連接功能的daemon，ccnr是CCN的倉庫，這兩者都在CCNx開源項目中得以實現。ThereCore是ThereGate中的核心軟件，用以與傳感器通信，並提供了C語言的驅動接口。
那麼對於IM有三種情況：
- 對當前數據的interest
這種情況下， 用戶所關心的是當前傳感器的數據，對於這種需求，會在pb-ccnx中開啓一個進程進行命名描述，在ThereCore中對每一個傳感器接口都提供專用的線程，該線程會在DBus發送對於最新數據的請求。
- 對歷史數據的interest
歷史數據存儲在CCN 倉庫中，因此，傳感器的專用線程不用採集數據，而是CCN倉庫負責回傳數據。由於不會以相同的名稱命名歷史數據，可以在數據命名中加上Unix時間戳來描述。
- Interest作爲actuator（執行器）
與第一種情況類似，不同在於我們要求傳感器設備執行某個行爲而不是傳回數據，IM使用一個命名來描述行爲，比如/lights/on，而傳感器的專用線程則負責將該行爲通過DBus傳遞給設備，然後等待設備回傳CO告知用戶設置完畢。
pb-ccnx組件會對目前所擁有的IoT設備註冊同一的命名前綴，比如ccnx:/alice/home，接着會通過DBus向ThereCore獲取每一個設備的名稱比如temperature，並新建一個線程註冊一個名字爲：cnx:/alice/home/temperature。因此，pb-ccnx的作用是進行命名的拓展或者稱之爲內部網絡與外部網絡的映射。
未來可改進的工作：文中設計的網關只是基於There公司的產品，其中的一些技術實現依賴於There公司的產品設計，比如網關中ThereCore對IoT設備的管理以及命名等，這些IoT設備僅僅適用於There的產品，並不支持其他廠商的設備。因此從某種程度而言，網關的設計並不具有通用性。未來可基於此設計更爲通用的ICN-IoT網關。
- ISI: Integrate Sensor Networks to Internet with ICN
場景設置：
場景如下圖所示：
NDN網絡：我們選擇NDN作爲一個代表性的ICN 體系結構，該網絡能夠從內容發佈者取回數據，也可以向傳感器網絡發送控制信息，也就是interest actuator。
傳感器網絡：通常包含多種IoT設備，接入方式包括無線和有線，在傳感器網絡，使用ICN的一種輕量級實現CCN-lite，通常在IoT環境中，包含一個基站來收集傳感器數據或者控制設備。
網關設計
網關位於運行NDN協議的互聯網和運行ccn -lite 協議傳感器網絡的中間。所有來自互聯網和傳感器網絡的數據流量都必須通過網關，因此網關主要作用是在兩個網絡之間進行協議轉換。衆所周知，IPV6的MTU大小爲1280B，而IEEE 802.15.4僅支持127B大小的MTU。IETF標準的作者認爲對IPV6的header進行壓縮是不可避免的了，然後由於傳感器網絡的數據量較小，若對ICN的命名進行更高效率的設計，網關並不需要壓縮header。
爲了進行兩個不同網絡的協議轉換，網關需要同時運行NDN協議和CCN-lite協議，此外，網關維持一個映射表，將從來自運行NDN的internet的冗長、無界的命名映射到傳感器網中等效短名稱。
對於傳感器網絡，網關爲每一個IoT設備提供註冊程序，新加入的設備會被分配一個ID，然後爲設備提供的內容註冊一個短的和長的名字，這些條目會加入到網關的映射表中，因此，每當傳感器網絡中的內容服務發生變化時映射表都要進行更新。
術語Inbound traffic表示進入傳感器網絡的數據流量，Outbound traffic表示由傳感器網絡傳出的數據，前者可能是用戶對數據的請求或控制請求，Outbound traffic則可能對Inbound traffic的回覆或者傳感器內部產生的請求/訂閱的流量數據，這兩種outbound traffic的區別在於，對Inbound traffic的回覆需要通過網關的映射表進行名字轉換。
當網關接收到Inbound traffic中的用戶對數據的請求，網關會掃描映射表找到等效短名稱，網關會創建一個基於CCN-lite的短名稱的interest包並轉發給傳感器網絡。同樣的，當網關接受到傳感器發出的CCN-lite的數據包，會在映射表中查找對應的長名稱，然後創建NDN數據包發送給internet。
另一種out bound traffic是基於CCN-lite的interest包表明內容在Internet或者其他IoT網絡中，網關支持IoT網絡之間的通信，當一個IoT網絡需要其他網絡的數據時，會簡單的產生一個CCN-lite interest 轉發至網關，網關轉換爲NDN interest並轉發至internet，最終到達internet中某個用戶發佈者或者某個目標傳感網絡。如果發佈者在Internet中，會遵循NDN協議回覆數據包；而若發佈者在某個傳感器網絡中，該網絡的網關則會進行映射、查找等工作，然後通過NDN網絡傳回用戶所在的傳感器網絡，經由網關的轉換，得到數據。
未來可改進的工作：目前的設計只停留在理論，未來可實際開發一個原型機。
九、用戶與內容提供者的解耦研究
1. Design Choices for the IoT in Information-Centric Networks
ICN提供了用戶與內容提供者之間的解耦功能，能夠允許內容提供者出現短暫的不可連接，且得益於緩存機制，無論存在多少個用戶，IoT設備只需要發送一次數據。然而這雖然解決了用戶移動性的問題，內容提供者的移動性問題仍然存在，對此，ICN網絡需支持本地的數據的備份，或者提供一個相對穩定的節點備份高度移動的內容提供者產生的數據。
然而，目前ICN並不支持數據的轉發和聚合，因此IoT的傳播框架應該支持任意數量的中間處理節點，該節點在ICN網絡中作爲端節點可充當請求者和內容提供者，並且可以執行聚合，過濾等操作，這樣的中間節點可能最終會在用戶和內容提供者之間形成定向圖。
未來可改進的工作：如何定義IoT傳播框架來支持任意數量的中間處理節點是進一步研究的內容。可以利用ICN的輕量級實現比如CCN-lite協議將該想法進一步實現，並對性能進行評估。
十、對安全性能和IoT框架的總體研究
1．A Secure ICN-IoT Architecture
我們定義pull就是隻有當數據被請求時纔會被髮送，push則是數據是由源主動發送的，這兩個模型之間存在內在的權衡，pull模型是網絡中存在大量的，冗餘的信息，而用戶只是對部分信息感興趣，push模型是當網絡中產生實時數據時，用戶對特定的設備的所有數據都感興趣。
對於IoT的設計選擇則是主要支持pull，同時對push有一些特定的支持，因爲ICN本身是pull模型。pull模型的缺陷是某些情況下檢索新數據可能效率低下。網絡必須支持無限期的掛起的請求狀態，有些ICN網絡可能不支持這樣的一個特徵。而我們的設計則是必須支持此類的觸發信息，因此在請求中也可包含觸發，這意味着當觸發條件滿足 時將返回數據（push），這種設計可以用來選擇報警條件，要求連續的或定期的推送等條件。在這種設計下，ICN就不用實現push模式了。
架構的組件包括：
1.嵌入式系統，使能傳感和驅動功能，向聚合傳輸數據
2.聚合，作爲一個本地網關連接IoT設備和其他聚合，同時聚合傳感器和網絡服務
3.本地服務網關（LSG），連接本地IoT網絡與外部網絡，處理本地的命名分配和爲物聯網設備執行數據訪問策略。
4.ICN-IoT服務器，管理查詢和訂閱服務
5.用戶
架構的目標是使得數據發現，處理和傳遞這些服務與分佈的節點更爲接近，也就是縮小網絡的分佈。
對ICN-IoT框架設計完成後，另一個值得研究的就是安全問題，因爲IoT系統經常會處理一些比較隱私和敏感的數據。因此在ICN-IoT實體之間必須集成安全解決方案。實體包括，設備發現，服務發現，命名服務，用戶註冊，數據交付等，以設備發現爲例，詳細描述如何爲其首先安全方案。
設備發現的最終目標是實現節點之間連接，在基於IP的IoT系統中，是利用IP與物理地址的映射關係來完成連接，但必須手動配置，這對於動態變化的IoT，效率很低。而ICN-IoT克服了這一問題，直接利用名字就能發現新設備。在這個過程中，利用聚合組件與IoT設備利用公鑰/密鑰進行身份確認。
如圖所示，IoT設備會配備設備ID，公鑰/密鑰（PK），以及一個證書用來證明設備ID和公鑰/密鑰。當設備被發現時，聚合組件首先證實設備ID，若ID確認返回成功，聚合組件發送活動指令，通知設備可以進行數據傳輸。在此過程中，爲了保證機密性和完整性，聚合首先對密鑰進行確認，接着將活動指令以密鑰進行加密再傳輸給設備，這些行爲提高了魯棒性，保證了安全性。
其他IoT實體之間的安全解決方案都與設備發現的方案類似。
可改進的地方：目前方案和架構只是理論提出的，並沒有實際證明，因此未來可在真實場景中測試方案和架構的有效性。而對目前存在的NOS（NetwOrked Smart object）IoT架構進行集成與整合也是可研究的方向。
總結：
ICN運用在IoT上的優點：
IoT本質以是信息爲中心的，這與ICN的設計相當匹配。
ICN的分佈式緩存大大減少數據的傳輸量，這對於資源有限的IoT很重要。
ICN的內容發佈者和用戶之間的解耦