总结

本文主要讨论了在low-power环境下如何实现能量消耗低、data availability高、且大规模网络下也可以使用的IOT。

low-power环境

用省电的硬件：带宽、CPU频率、内存等性能低
RDC：把时间分成一个个slot，在每个周期内处理事务
- 非协作RDC：设备自己决定醒醒睡睡【优点是大规模网络下可以使用，缺点是能耗高】
  代表为ContikiMAC，接收方周期性检查有没有数据，没有就睡觉；发送方要发东西就得周期性发，直到接收到ACK为止
  参考这里
- 协作RDC：因为全网时钟同步，什么时候醒/睡，醒/睡多久不再是只有自己决定了优点是能耗低，但大规模网络下时钟同步困难，不可行
  代表TSCH，全网时间同步，分割成一块块时间片，节点只在时间片内通信
- 区别：协作的需要时钟周期同步，非协作的周期自己定；当节点多起来之后，协作RDC的同步不太可行，只能采用非协作RDC,但是非协作RDC没那么省能量【发送方循环发送】
- 所以本文使用非协作RDC，节点有概率p沉睡
省能量的协议：不需要太多消息传输，占用的内存相对较少等
集中的cache：代表CoAP，相当于是HTTP的简化版，CoAP的Caching就是相当于HTTP的Web caching，在COAP结点上缓存COAPresponse【缺点（不确定，猜的）,由于IOT到互联网的连接是断续的，下一个请求可能很久才过来，web caching式的缓存就没用了（缓存的内容过期了）】
所以本文利用了NDN的泛在缓存，并针对IOT应用场景设计了相应的缓存机制

single broadcast domain：每个sensor都是producer，一个uplink向IOT中的设备请求内容，uplink是断续的【consumer和producer之间只有一跳】
Coca：缓存策略，一个producer产生内容时也给其它人发一份，周围醒着的节点存下它【节点存不存看它的缓存策略】
RDC策略：非协作RDC、下一秒如果没事有概率p沉睡

衡量标准：

availability：uplink是周期性连上的，每次连上会发对一大类内容的请求，IOT里醒着的设备则会返回内容，由于有的设备睡着，所以可能不会返回全部内容，availability就是返回内容/产生内容的比例。
测试了两种缓存策略：固定概率随机缓存和MDMR；MDMR的availability高点【因为增加了多样性】

MDMR：来了一个某producer某时刻产生的内容。如果这个producer有很多缓存内容，换掉同producer最老的那个；否则，如果有producer存了复数内容，换掉它最老的那个；如果大家都只存了一个内容，换掉最老的那个
能量消耗
计算方式：能量消耗：每个状态单位时间消耗的能量（设备处获取的常量）*呆在该状态的时间
五个state：睡、醒（idle）、醒（监听和接收）、醒（单播发送）、醒（广播发送）
跟两个极端情况比：1. 最省电：同一时钟周期只有一个活着的设备存着所有的内容 2.最不省电：没有cache，非协作RDC，所有内容需要到源处找

只适用于较稳定的网络
包括：