无线传感器网络第5讲-节点结构.ppt

* * * * * * * * * * * * * * * * * * * * * * * * A = 174, beta= 4 - berechne effizienz * * * * * * * * * * * * * * * * * 控制收发机 类似于控制器，占空比必须低 发射器必须容易工作 – 与控制器相似的问题：什么时候值得关掉 接收机的困难: 不仅什么时候去唤醒接收机是未知的，它也取决于远程的工作伙伴 ! MAC协议与功耗之间的关联是很强的！ 对类似于DVS的技术只有有限的适用性 动态调制缩放 (DSM): 转向最适合通信的调制– 取决于信道增益 动态编码缩放– 根据信道增益选择不同的编码速率 组合 * 计算 vs. 通信能量成本 折衷? 直接比较计算与通信能量成本是不可能的 但是：可以将它们进行透视！ 发送一个比特与计算一个指令的能量比：在文献中一切介于 220 和2900 的都可以 传达（发和收）一千字节= 计算三百万个指令! 因此:只要可以就尝试计算而非 传达 WSN 中的关键技术– 网络内部处理! 开发压缩机制，智能编码机制, … * 概要 传感器节点结构 能量供给和损耗 传感器节点的运行环境 个案研究: TinyOS SS 05 Ad hoc sensor networks - Ch 2: Single node architecture * WSN中的操作系统挑战 通常的操作系统目标 使进入装置资源抽象化 (虚拟化) 从并行接入中保护资源 通常方法 CPU的保护操作模式– 只有在这种模式下才能硬件接入 使用分离的地址空间处理 由一个内存管理单元支持 问题: 在微控制器中这些是无法使用的 没有分离保护模式，没有内存管理单元 这会使得装置更贵，耗电更高 ! ??? * WSN中的操作系统挑战 可能的选择 试着在WSN节点中实施“尽可能接近一个操作系统” 尤其是，尝试提供一个已知的编程接口 也就是：进程支持! 牺牲从彼此那里的对不同进程的保护 ! 可能，但是管理费用相当高 不使用操作系统工作（或多或少） 毕竟，在WSN节点中只有一个单独的“应用” 没必要从彼此那里保护恶意软件 直接由应用处理的硬件控制可能会提高效率 目前普及的结论: 没有OS, 只是一个简单的运行时间环境 最大的影响：与众不同的编程模式 * 主要问题：怎样支持并发执行 最简单的选择：没有并发性, 顺序的任务处理 这是不符合要求的：在处理数据时有丢失数据的风险 (比如说,从收发机) ! 必须支持中断/异步操作 为什么需要并发执行 传感器节点的CPU必须为无线调制解调器服务，实际的传感器为应用执行计算，执行通信协议软件等等 Poll sensor Process sensor data Poll transceiver Process received packet * 传统的并行方式：进程 传统的OS：进程/线程 基于中断，上下文转接 但是这是不可用的– 内存开销，执行开销 但是: 并行不匹配 每个协议一个进程需要太多的上下文转接 WSN中许多关于上下文转接的小任务使得开销过大 并且: 在WSN中不需要进程间的保护 无论怎样只有一个应用程序 Handle sensor process Handle packet process OS-mediated process switching * 基于事件的并行性 供选择的: 转向基于事件的编程模型 执行常规进程或者闲置 当事件发生时立即回应 基本上是中断处理器 问题：不能在中断处理上停留太久 有丢失事件的危险 只能数据存档，公布信息事件已经发生，然后返回 ! 运行到完成原理 两种环境：一种来处理，一种是常规执行 I d l e / R e g u l a r p r o c e s s i n g R a d i o e v e n t R a d i o e v e n t h a n d l e r S e n s o r e v e n t S e n s o r e v e n t h a n d l e r * 组件代替进程 需要一个抽象概念来组功能 这个目的是代替“进程” 比如说：一个网络协议的单个功能 一个选择：组件 这里：在TinyOS的传感器中 典型的只需要一个单独的，定义好的函数 和进程的主要不同点: 组件没有执行 组件进入相同的地址空间，没有防范彼此Components access same address space, no protection against each other 不要混淆基于组件的编程！ * API 和一个基于事件的协议栈的对比 通常网络API: 套接字 问题:阻塞调用接收数据 和基于事件的操作