信息中心网络ICN的物联网应用调研

摘要：

随着通信技术和制造工艺的不断进步，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模型是当网络中产生实时数据时，用户对特定的设备的所有数据都感兴趣。

架构的组件包括：

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的内容发布者和用户之间的解耦

信息中心网络ICN的物联网应用调研相关推荐

信息中心网络ICN在卫星通信中的应用调研
Supporting the IoT over Integrated Satellite-Terrestrial Networks using Information-Centric Networki ...
网络工程（物联网技术方向）专业人才培养方案
网络工程(物联网技术方向)专业人才培养方案专业名称:网络工程部颁代码:080613W 一.专业培养目标培养德.智.体全面协调发展,掌握物联网的基本理论.基础知识,具备基于计算机技术.自动控 ...
爱立信诠释网络社会：物联网的奇思妙想如何转变为现实
随着各行各业基于移动.宽带和云进行转型,我们正迎来万物互联的网络社会.从过去人与人的连接,到现在人与物的连接,再到未来网络社会物与物的连接成为趋势,物联网将使得个人.商业乃至整个社会的运作方式发生根本 ...
物联网行业网络解决方案_2021物联网趋势：有望从物联网传感器网络中受益的5大行业...
创新和保持竞争优势的核心是可靠且可访问的数据.物联网使公司能够从其资产.人员和流程中获取大量关键数据.这些数据是降低成本.提高效率和为员工提供更安全环境的生命线.尽管物联网不再是一个新概念,但对某些行 ...
如何解决多机房、多网络下的物联网部署方案？
[CSDN 编者按]随着物联网的迅速发展,场景联动越来越普遍,那么敲门砖的连接服务该如何实现呢?本文作者作为360 IoT 云连接服务技术负责人,他从结合自身的实际开发经验,详解连接服务的设计方案,以 ...
元宇宙——定向未来的网络服务：最新技术动向调研
元宇宙的概念元宇宙的特点管理技术人体姿势与眼球追踪 Metaverse 是一组相互连接的.体验式的 3D 虚拟世界,身处任何地方的人都可以实时社交,形成一个横跨数字世界和物理世界的持久的.用户所 ...
联通物联卡为什么没有网络_联通物联网卡怎么样？联通物联卡的查询官网是什么？...
原标题:联通物联网卡怎么样?联通物联卡的查询官网是什么? 物联网时代的来临为我们生活中带来了许许多多的智能应用,移动物联网卡.电信物联网卡.联通物联网卡作为物联网最基础的通讯产品,在物联网应用中发挥着 ...
Android网络请求-新大陆物联网云平台请求通信工程-使用Post登录新大陆云平台获取Token-物联网竞赛-物联网数据通信
目录一.概述二.代码与实现三.总结归纳一.概述本文将通过Android Studio原生安卓环境,通过Post网络请求与新大陆物联网云平台官网进行通信,实现获取用户Token. Need:A ...
时序预测（网络流量预测）方法调研总结
是和某公司合作的项目,调研报告,为了不影响合同,仅仅给出目录,方便有需要的人按图索骥. 主要分为线性时间序列预测模型.非线性时间序列预测模型.神经网络时间序列预测模型.Boosting预测模型.GM预 ...

信息中心网络ICN的物联网应用调研

信息中心网络ICN的物联网应用调研相关推荐

最新文章

热门文章