简介这份资源围绕ALOHA与时隙ALOHA多址接入协议的性能仿真展开面向无线通信、卫星通信及局域网方向的学习者与研究人员帮助理解时隙划分、随机发送、碰撞检测与捕获效应等核心机制。压缩包共2个文件均为m脚本文件整体约3KB可直接用于MATLAB环境下的协议仿真与参数调试。资源重点覆盖存在捕获效应与不存在捕获效应两种场景通过设定用户数量、时隙长度、数据包大小等参数统计成功传输率、冲突率与吞吐量并支持多次仿真取均值以观察系统性能变化。已有1011人学习适合作为课程实验、论文复现或协议对比分析的参考素材也可在此基础上调整用户选择时隙策略进一步探索时隙ALOHA与CSMA/CA等机制的差异与优化空间。1. 从一次轮询超时说起ALOHA 和时隙 ALOHA 到底在解决什么问题如果你维护过物联网平台大概率遇到过这种场景几百个低功耗传感器通过无线信道往网关上报数据平时一切正常某天设备数量翻倍后丢包率突然从 1% 飙到 30%网关日志里全是 CRC 校验失败。你查了信号强度、查了天线、查了电源都没问题——问题出在多个节点同时抢信道上。这就是 ALOHA 协议要解决的核心问题在共享信道上多个节点如何决定“什么时候可以发”。纯 ALOHA 的思路极其简单粗暴想发就发发完等确认超时没确认就随机退避重发。它的信道利用率理论上限只有 18.4%因为两个节点发送时间只要有重叠就会碰撞。时隙 ALOHA 做了一个关键改进把时间切成等长的时隙所有节点只能在时隙边界开始发送。这样碰撞窗口从“两倍帧长”缩小到“一个帧长”理论吞吐率翻倍到 36.8%。别小看这 18 个百分点的提升在 LoRa、NB-IoT 这类低功耗广域网的随机接入阶段它直接决定了网关能挂多少终端。这篇文章会从协议原理讲到可运行的仿真代码再到参数调优和踩坑记录适合正在做物联网接入层、无线通信仿真或协议栈开发的工程师。2. 纯 ALOHA 的吞吐率为什么卡在 18.4%从碰撞窗口推导到 Python 仿真2.1 碰撞窗口的几何直觉与泊松到达假设要理解 ALOHA 的性能天花板得先接受一个建模前提所有节点的发送时刻服从泊松过程帧长固定为 T。纯 ALOHA 里一个帧要想成功到达它的发送时间段内不能有任何其他帧与之重叠。但麻烦在于碰撞可能来自两个方向——一个节点在你开始发送之前一点点开始发另一个节点在你发送过程中开始发。这两个“危险区域”各占一个帧长 T所以总的脆弱期是 2T。用泊松分布算一下在 2T 时间内到达 k 个帧的概率是 ( P(k) \frac{(2G)^k e^{-2G}}{k!} )其中 G 是负载每帧时间内平均到达的帧数。成功发送要求 k0所以成功率 ( P_{succ} e^{-2G} )。吞吐率 S G × P_succ G e^{-2G}。对 G 求导令其为零得 G0.5 时 S 最大S_max 0.5 × e^{-1} ≈ 0.184。这就是 18.4% 的来历。时隙 ALOHA 把脆弱期从 2T 压缩到 T因为节点只能在时隙边界发送不可能出现“提前一点点开始发”的情况。同样的推导( P_{succ} e^{-G} )S G e^{-G}G1 时 S_max e^{-1} ≈ 0.368。翻倍的本质是消除了部分重叠碰撞只留下完全重叠。2.2 用 60 行 Python 跑出两条吞吐率曲线光看公式不够直观我一般会写一个离散事件仿真来验证。下面这段代码模拟 N 个节点在共享信道上发送对比纯 ALOHA 和时隙 ALOHA 在不同负载下的吞吐率。import numpy as np import matplotlib.pyplot as plt def simulate_aloha(num_nodes50, num_slots100000, load_rangeNone, slottedFalse): 仿真 ALOHA 协议吞吐率 num_nodes: 节点数量 num_slots: 仿真时隙总数 load_range: 负载 G 的扫描范围 slotted: True 为时隙 ALOHAFalse 为纯 ALOHA if load_range is None: load_range np.arange(0.05, 3.0, 0.1) throughput [] for G in load_range: # 每个时隙内帧到达服从泊松分布均值为 G arrivals np.random.poisson(G, num_slots) success_count 0 if slotted: # 时隙 ALOHA帧在时隙边界对齐一个时隙内到达超过 1 帧就碰撞 success_count np.sum(arrivals 1) else: # 纯 ALOHA帧可以在任意时刻到达脆弱期为 2 个时隙 # 用简化模型当前时隙和前后各一个时隙都不能有其他帧 for i in range(1, num_slots - 1): if arrivals[i] 1 and arrivals[i-1] 0 and arrivals[i1] 0: success_count 1 # 吞吐率 成功帧数 / 总时隙数 throughput.append(success_count / num_slots) return load_range, np.array(throughput) # 运行仿真 G_range, S_pure simulate_aloha(slottedFalse) _, S_slotted simulate_aloha(slottedTrue) # 理论曲线 G_theory np.linspace(0.01, 3, 200) S_pure_theory G_theory * np.exp(-2 * G_theory) S_slotted_theory G_theory * np.exp(-G_theory) plt.figure(figsize(10, 6)) plt.plot(G_range, S_pure, o, markersize3, labelPure ALOHA (仿真)) plt.plot(G_range, S_slotted, s, markersize3, labelSlotted ALOHA (仿真)) plt.plot(G_theory, S_pure_theory, --, labelPure ALOHA (理论)) plt.plot(G_theory, S_slotted_theory, -, labelSlotted ALOHA (理论)) plt.axhline(y0.184, colorgray, linestyle:, alpha0.5) plt.axhline(y0.368, colorgray, linestyle:, alpha0.5) plt.xlabel(负载 G (每帧时间内的平均到达帧数)) plt.ylabel(吞吐率 S) plt.legend() plt.grid(True, alpha0.3) plt.title(ALOHA vs Slotted ALOHA 吞吐率对比) plt.show()这段代码的关键逻辑在simulate_aloha函数里。对于时隙 ALOHA判断条件很简单一个时隙内恰好到达 1 帧就算成功到达 0 帧或超过 1 帧都不计入成功。对于纯 ALOHA我用了简化模型——当前时隙有帧且前后相邻时隙都没有帧才认为成功。这个简化模型在 G 较小时误差不大但 G 较大时因为忽略了更远距离的碰撞会略微高估吞吐率。参数方面num_slots建议至少 100000否则随机波动会让曲线不够平滑。num_nodes在仿真里其实没用到因为泊松到达已经隐含了多节点的聚合效果。load_range从 0.05 扫到 3.0 足够覆盖峰值点。跑完你会看到两条曲线纯 ALOHA 在 G0.5 附近达到峰值 0.18 左右时隙 ALOHA 在 G1.0 附近达到峰值 0.36 左右和理论值吻合。提示如果你发现仿真曲线在峰值附近抖动很大把num_slots加到 500000 再跑一次或者多跑几次取平均。2.3 从仿真结果反推为什么时隙同步是收益翻倍的关键仿真跑完两条曲线的差距一目了然。但真正值得琢磨的是时隙 ALOHA 的收益完全来自“同步”这个约束。节点必须知道时隙边界在哪里这在实际系统里需要额外的机制——网关周期性广播信标帧终端根据信标做时间同步。这个同步开销在低功耗场景下不可忽略终端要定期唤醒接收信标功耗会增加。所以选型时要算一笔账如果你的终端数量少、流量低纯 ALOHA 的简单性可能更划算如果终端密集、碰撞严重时隙 ALOHA 带来的吞吐率翻倍值得付出同步成本。我见过一些 LoRa 网络在终端超过 200 个之后从纯 ALOHA 切到时隙 ALOHA丢包率从 25% 降到 8% 左右效果立竿见影。3. 时隙 ALOHA 的工程实现同步机制、退避策略与参数配置3.1 时隙同步的三种常见做法与选型对比时隙 ALOHA 落地的第一个难题是同步。节点怎么知道时隙边界常见做法有三种第一种是网关广播信标。网关每隔一个时隙周期发一个短信标帧终端收到后校准本地时钟。这种做法同步精度高但终端需要频繁唤醒接收信标功耗较大。适合有稳定供电或对时延敏感的場景。第二种是GPS 或北斗授时。终端自带定位模块直接获取 UTC 时间时隙边界由绝对时间计算。精度最高但成本和功耗也最高适合户外资产追踪这类场景。第三种是基于下行帧的隐式同步。网关不需要专门发信标终端从任何下行帧的到达时间推算时隙边界。这种做法功耗最低但同步精度受下行帧到达间隔影响终端数量多时可能长时间收不到下行帧导致时钟漂移。我一般会推荐第一种和第三种结合网关周期性发信标但终端不需要每个信标都收可以隔几个周期收一次用本地晶振维持时隙计数。这样功耗和精度比较平衡。3.2 退避算法二进制指数退避在时隙 ALOHA 里的参数怎么设碰撞后的退避策略直接决定了高负载下的稳定性。纯 ALOHA 和时隙 ALOHA 都可以用二进制指数退避BEB但参数设置不一样。BEB 的基本逻辑是第一次碰撞后从 [0, 1] 里随机选一个时隙等待第二次碰撞后从 [0, 3] 里选第三次从 [0, 7] 里选以此类推。等待窗口随碰撞次数指数增长直到达到上限。在时隙 ALOHA 里退避窗口的单位就是一个时隙。下面是一个简化的退避逻辑实现import random class SlottedAlohaNode: def __init__(self, node_id, max_backoff10): self.node_id node_id self.collision_count 0 self.max_backoff max_backoff # 最大退避指数2^10 1024 个时隙 self.backoff_counter 0 def on_collision(self): 碰撞后计算退避时隙数 self.collision_count 1 # 退避指数取碰撞次数和上限的较小值 backoff_exp min(self.collision_count, self.max_backoff) # 在 [0, 2^backoff_exp - 1] 里随机选一个等待时隙数 self.backoff_counter random.randint(0, (1 backoff_exp) - 1) def on_success(self): 发送成功后重置碰撞计数 self.collision_count 0 self.backoff_counter 0 def can_transmit(self): 检查是否退避结束可以发送 if self.backoff_counter 0: self.backoff_counter - 1 return False return True关键参数是max_backoff。设得太小高负载时退避窗口不够大碰撞会持续设得太大低负载时节点等待时间过长时延增加。在终端数量 100~500 的场景下max_backoff8到10是比较稳妥的范围对应最大退避窗口 256 到 1024 个时隙。如果时隙周期是 100ms最大退避时间就是 25.6 秒到 102 秒这个量级对大多数物联网上报是可以接受的。还有一个容易忽略的点退避计数器应该在每个时隙边界递减而不是连续递减。因为时隙 ALOHA 的发送只能在时隙边界开始如果计数器连续递减节点可能在时隙中间减到零然后立即发送破坏了时隙对齐。这个坑我在早期实现里踩过表现是时隙 ALOHA 的吞吐率只有理论值的一半查了很久才发现是退避计数器递减时机不对。3.3 时隙长度怎么定和帧长、传播时延、晶振精度的关系时隙长度 T_slot 的设定需要满足几个约束首先T_slot 必须略大于一个完整帧的传输时间 T_frame否则帧会跨时隙边界碰撞概率反而增加。一般取 T_slot T_frame T_guard保护间隔 T_guard 用来吸收传播时延和同步误差。传播时延在无线场景下通常很小几百米距离对应微秒级可以忽略。但同步误差不能忽略如果终端用晶振维持时隙计数晶振精度 20ppm 的话1 秒累积误差 20 微秒100 秒就是 2 毫秒。如果 T_guard 只有 1 毫秒同步就会失效。所以 T_guard 要根据信标间隔和晶振精度来算。我一般会按这个公式估算T_guard ≥ 2 × 晶振误差 × 信标间隔 最大传播时延。比如晶振 20ppm信标间隔 10 秒那 T_guard 至少 0.4 毫秒实际取 1~2 毫秒留余量。注意如果你的系统里帧长本身就很短比如几十字节T_guard 占比可能超过 10%这时候时隙 ALOHA 的有效吞吐率会明显低于理论值。选型时要算上这个开销。4. 避坑与排查时隙 ALOHA 落地时最容易翻车的 4 个地方4.1 现象吞吐率远低于理论值但碰撞计数不高原因时隙边界没有对齐。终端各自维护本地时隙计数如果初始对齐后没有定期校正晶振漂移会让不同终端的时隙边界逐渐错开。错开到半个时隙时碰撞概率最大吞吐率最低。解决网关信标里带上时隙序号终端收到后直接重置本地计数器而不是只校准时间。另外信标间隔要小于晶振漂移半个时隙所需的时间。20ppm 晶振、时隙 100ms 的话漂移半个时隙需要 250 秒所以信标间隔不要超过 200 秒。4.2 现象低负载时延正常高负载时时延爆炸原因退避窗口上限设得太小或者碰撞后没有正确翻倍退避指数。有些实现里碰撞计数在成功发送后没有重置导致退避窗口一直很大反过来如果碰撞计数被意外清零退避窗口永远很小高负载时持续碰撞。解决在节点状态机里明确区分“发送成功”和“收到确认”两个事件。只有收到确认才重置碰撞计数超时重传要保留碰撞计数。另外退避窗口上限不要超过网络里最大节点数的 2 倍否则退避时间会超过应用层超时。4.3 现象仿真结果和实测对不上实测吞吐率只有仿真的 60%原因仿真里假设所有节点都能完美听到彼此但实际场景里可能存在隐藏终端问题。节点 A 和节点 B 都能和网关通信但 A 和 B 之间互相听不到它们同时发送时网关处碰撞但 A 和 B 都不知道碰撞发生了。解决隐藏终端是 ALOHA 类协议的固有缺陷时隙化不能解决这个问题。如果隐藏终端严重需要考虑 CSMA 类协议或者让网关在信标里反馈碰撞信息终端据此调整退避。但后者会增加下行开销要权衡。4.4 现象终端功耗比预期高很多原因时隙同步要求终端定期唤醒接收信标如果信标间隔太短终端大部分时间都在接收状态。另外如果退避计数器在每个时隙都要唤醒递减功耗也会累积。解决让终端在退避期间进入休眠只在退避计数器减到零时唤醒发送。这要求终端有精确的定时器能在指定时隙唤醒。另外信标间隔可以适当拉长用晶振精度换功耗只要保证同步不失效就行。5. 进阶技巧用捕获效应和自适应时隙提升实际吞吐率前面讲的都是理想模型实际无线环境里还有一个被低估的效应捕获效应。当两个帧碰撞时如果其中一个帧的信号强度明显高于另一个比如相差 6dB 以上接收机可能正确解调强信号弱信号被当作噪声。这意味着碰撞不一定导致两个帧都丢失强信号帧可能幸存。在时隙 ALOHA 里利用捕获效应可以让靠近网关的节点用更短的退避窗口远端节点用更长的退避窗口人为制造信号强度差异。我做过一组对比测试在 200 个节点的 LoRa 网络里开启捕获效应感知的退避策略后吞吐率从 28% 提升到 34% 左右接近理论峰值。另一个技巧是自适应时隙长度。如果网络里帧长不固定可以按最大帧长设时隙但小帧会浪费时隙空间。更好的做法是分几个时隙等级短帧用短时隙长帧用长时隙网关在信标里广播当前时隙配置。这种做法实现复杂度高一些但在帧长差异大的场景下收益明显。验证这些优化是否生效我一般会看两个指标一是网关统计的每秒成功接收帧数二是终端统计的平均重传次数。如果成功帧数上升但重传次数也上升说明退避策略可能太激进如果成功帧数上升且重传次数下降说明优化方向对了。最后说一个我自己的习惯每次调整时隙 ALOHA 参数后不要只看平均值一定要看分布。平均吞吐率 30% 可能意味着 80% 的时隙吞吐率是 020% 的时隙吞吐率是 100%。这种突发性对上层应用的影响比平均值大得多。用滑动窗口统计最近 100 个时隙的吞吐率画出时间序列图你会看到很多平均值掩盖的问题。希望帮到你。本文还有配套的精品资源点击获取