Main MAC protocols for WSNs——S-MAC
S-MAC（Sensor Medium Access Control protocol）
S-MAC协议是在IEEE 802.11协议的SC9636-006基础上针对传感器网络节省能量的需求设计的。S-MAC包括了从各种能量消耗方式中节省能耗的方法，比如：空闲侦听、冲突、串音和控制开销。
S-MAC：一种MAC协议，目标——节能
方式：持续休眠
技术：based on carrier sensing (CSMA/CA) with RTS/CTS/ACK packets
背景意义
在传感器网络中，节点通常靠电池供电，长期开着无线模块会很耗电。
So the aim of S-MAC ：
减少空闲监听（idle listening）
同步睡醒时间，避免自己醒着时别人都在睡
降低冲突+省电+延长网络寿命
Basic Concept
frames： node activity scheduled into cycles
SYNC period: exchange of SYNC packets to synchronize
RTS period: transmission of RTS packets
duty cycle: ratio of the listen interval to the frame length
frame
在这种 MAC 协议中，frame（帧） 是一种周期性时间单位（与图像中的帧，一个信号的帧完全区分开。完全不是同一个东西，这是一个时间单位），网络中的节点活动（比如发送、接收、监听）是按帧来安排的。
每一帧内都有一套固定的时序结构（比如先同步、再发控制包等）。
所有节点都按照这个周期来“醒来”或“休眠”，以节省能源。
SYNC period
在每一帧的开头，有一个 SYNC period（同步时段），节点之间互相发 SYNC包（同步包），用来：
对齐时间（clock synchronization），
保证大家后面的通信（RTS/Data等）可以协调进行，避免错过信息。
RTS period
这个时间段专门用来发 RTS（请求发送） 包。
duty cycle
duty cycle（占空比） 是衡量节点“醒着”的比例：
举个例子，如果一帧是 100ms，节点只有前10ms在监听或通信，剩下90ms都在睡觉，那 duty cycle = 10%。
duty cycle 越小 → 越省电（但可能延迟也更高）。
周期性侦听和休眠
S－MAC通过让节点处于周期休眠状态 来降低侦听时间，每个节点休眠一段时间，然后唤醒并侦听是否有其他节点想和它通信。在休眠期间，节点 关闭无线装置，并设置定时器，随后来唤醒自己。
Virtual clusters in S-MAC S-MAC 中的虚拟集群（Virtual Clusters）
什么要有“虚拟集群”？
无线传感器网络（WSN）中的节点通常是靠电池供电，省电是第一优先级目标。
S-MAC 的核心节能思路是：节点周期性地醒来和睡眠（即 Duty Cycling），但醒来的时间必须大家同步好，否则你醒了别人都睡了，没法通信。
所以，必须有一种机制让邻居之间：形成一套共同的作息计划（schedule）
这种动态形成局部同步区域的机制就叫：虚拟集群（Virtual Clusters）
🌐 虚拟集群的核心概念
每个集群就是一组节点，它们采用相同的唤醒时间表（schedule）。
在无线网络中，物理上不一定分群，但逻辑上形成了 schedule 共享的小“团体”，这就是“虚拟”集群。
虚拟簇形成机制（S-MAC中的同步机制）
这张图说明：节点如何决定加入哪个 schedule、是否成为 Synchronizer、还是成为 Follower、或者是 Border Node
这个图分成了3个虚拟集群，黄色Synchronizer是领导，绿色Follower是听从领导的时间规划同步行动，深绿色是边界节点，服从两边/多边领导的时间同步。
流程讲解
listen during SYNC：节点在 SYNC 时段监听其他节点的 schedule（监听别人的时间表）
是否收到别人的 schedule？
是 → 成为 Follower（绿色框），加入别人的时间表，避免冲突、保持同步
否 → 自己创建 schedule，成为 Synchronizer（主导者）
【Follower 会 随机延迟，然后广播自己的 SYNC 信息。为了避免同步包冲突，使用 Carrier Sense（CS） 确保信道空闲】期间可能会收到另一个 schedule，怎么做？
没收到：保留原 schedule。
收到了：看对方是不是邻居？
--------是邻居 → 同时保留两个 schedule → 成为 Border Node边界节点
--------不是邻居 → 放弃原 schedule，采用新 schedule
随机延迟（random delay）S-MAC 中关键的一种避免冲突的机制
场景背景：为什么需要“随机延迟”
当多个节点都成为了 Follower，比如：
节点 A 是 Synchronizer，广播了一个 schedule。
节点 B、C、D 都监听到了 A 的 schedule → 成为 Follower。
接下来 B、C、D 都要把自己加入这个 schedule 的意图广播出去（发 SYNC），告诉邻居：“我也采用 A 的 schedule”。
👉 问题就来了：
如果 B、C、D 同时广播 SYNC → 会造成广播碰撞（多个包在同一时间发，谁都听不到）
解决办法
S-MAC 采用了一个常见的 MAC 层技巧：
每个 Follower 在广播 SYNC 前，先等一个“随机长度”的延迟（random delay）
这个延迟是从一个固定范围中随机选一个时间值，比如 0 ~ 10ms。
🛠️ 实际操作逻辑
节点 B 成为 Follower，准备发 SYNC。
它在范围内随机挑了个延迟，比如 7ms。它等这 7ms 的时间，并在这期间监听信道；
如果信道空闲（Carrier Sense OK），才发送 SYNC；
如果信道被别人占了（比如 C 先发了），就再退避。
⏳ 这就是所谓的：Random Backoff + Carrier Sense
这种方式非常常见，比如：在 IEEE 802.11（Wi-Fi）中叫 DCF Backoff，以及在 S-MAC 中是简化版的 CSMA。
“随机延迟”就是为了让多个 Follower 不同时发 SYNC，降低冲突风险。每个节点等一个随机时间再发，并通过 Carrier Sense 确认信道空闲。
Timing relationships S-MAC 的帧结构和时间分配规则
“时间对齐”是 S-MAC 的核心机制
所有通信行为都必须严格依照时间片段安排进行。虽然节点之间没直接关系，但它们的行为必须统一遵守 S-MAC 的帧结构和时间分配规则。
Sender 1：SYNC packet
Sender 2：data packet
Sender 3：SYNC packet and data
Sender 1 发 SYNC 的时间 → 必须在 for SYNC 段
Sender 2 发 RTS 的时间 → 必须在 for RTS 段
Sender 3 两个都发 → 必须把 SYNC 安排在 SYNC 段、RTS 安排在 RTS 段
这三种 Sender 类型分别展示了：
不同的“功能角色”
如何 对齐 Receiver 的时间计划，在“合适时间做合适的事”
Tips: Broadcast & Unicast
Broadcast packets are sent without using RTS/CTS
Unicast packets follow the sequence RTS/CTS/DATA/ACK
If a node fails to access the medium, it goes to sleep and wakes up when the receiver is expected to be listening again.
Long data packets S-MAC —— S-MAC 协议中传输长数据包（Long data packets）时的优化策略
场景背景：为什么需要长数据包策略
“Transmitting a long message as a single packet → high cost of retransmitting…”
如果把一个很长的消息一次性塞进一个包里发出去，万一中间几个 bit 出错了，那整个超大数据包都得重传！😩
成本非常高（能量 + 延迟都浪费）
解决办法
Fragments the long packets and reduces overhead to transmit the fragments.对长数据包进行分段并减少传输分段的开销
A——>B——C
关键点
A single RTS/CTS with duration of the whole transmission
一次 RTS/CTS
整个片段传输只需握手一次，降低控制开销如果一个长消息分成 3 个片段后没发完，那剩下的内容是：
❓再加一个 DATA 片段接着发？（变成第 4 个）
❓还是暂停，等下一个 Frame 醒来再继续发？
✅ 正确答案是：暂停，等下一个 Frame 醒来再继续发，不临时追加片段。
为什么不加第 4 个片段继续发？
S-MAC 中的通信严格依赖于两个节点的同步唤醒时间（schedule）：A 和 B 的 Listen 窗口是同步对齐的。每次传输窗口的长度是有限的。
开始传的时候，A 发 RTS → B 回 CTS → 约定好：
“我们这次会传多长时间！”
这一时长在 CTS 中写清楚了，大家都知道：“这次传输只包括 X 个片段”
一旦超出这个时间：接收端（B）会 直接 sleep。新片段发出去也没人收 → 白费电
S-MAC 中不能临时追加片段，超出预定传输长度的数据必须在下一帧重新建立 RTS/CTS 会话后再继续发
- Each fragment and ACK also have the duration of the whole transmission 每个片段和 ACK 也具有整个传输的持续时间
在这张图里，节点 A、B 在传输多个 DATA 时都没有 sleep，这是为什么？不是 S-MAC 要定期睡觉省电吗？
简短回答：
因为只要节点“参与通信”，它就必须保持清醒状态，直到当前数据传输完成。S-MAC 是“节奏性唤醒 + 事件驱动保持清醒”。
原因详解：
🌙 正常 S-MAC 的 Frame 构成：
Frame = Listen（用于通信） + Sleep（节省能耗）
通常情况下，节点每轮只醒来一小段时间，错过了就等下一轮。但这个规则有个例外：如果当前正在通信 → 就不能立刻睡。
图中这种情况是长数据传输（多片段），节点 A 和 B 已经握手成功（RTS/CTS），A 现在要发 多个小的 DATA 包，B 需要 每一个都接收并发 ACK
✅ 所以：A 和 B 都要保持清醒，直到整个数据包的所有片段都传完！这个“保持清醒”的时间多长在 RTS/CTS 中已经声明了。CTS 会告诉大家：“我接下来会接收 X 毫秒的数据，请大家别打扰我”
🔄 为什么不能睡？
如果传到一半 A 去睡了，或者 B 接完一个包就睡了，整个传输就中断了。ACK 不回来，重发就浪费更多能量，所以这会违反“为了省电而睡觉”的初衷。这时候：能量节省 = 不打断重要通信，而不是一味睡觉
在 S-MAC 中，如果一个节点已经开始数据传输，它就必须整段时间保持唤醒状态，直到传完为止，这就是图中 A 和 B 在整个片段传输期间都没 sleep 的原因。