LEACH路由算法：WSN分簇仿真源码与能耗均衡改进策略

简介LEACH低能量自适应分层聚类路由算法是无线传感器网络中经典的层级簇首轮换协议通过随机周期性选举簇首来均衡全网节点能耗避免个别节点过早失效。这套MATLAB实现面向通信与网络仿真方向的学生与研究人员可用于理解协议运行机制及验证改进思路。压缩包共4个脚本文件全部为.m格式整体仅8KB代码量精简适合逐行研读与二次开发。实现覆盖簇首选举、簇形成、数据聚合、单播传输及轮换更新等关键流程并包含基础版与改进版在簇首选择概率上的对比读者可通过修改节点数量、能量阈值等参数直观观察网络生命周期随能耗策略的变化。已有276人学习下载适合作为无线传感器网络课程设计、毕业设计或算法仿真实验的入门参考。1. LEACH 路由算法一套能直接改的 WSN 分簇仿真源码无线传感器网络里节点电池就是命。LEACHLow-Energy Adaptive Clustering Hierarchy这个低能量自适应分层聚类算法核心就一句话——让全网节点轮流当簇首别让几个节点一直干活一直耗电把整体生命周期拉长。这套资源里带了四个 MATLAB 脚本从经典 LEACH 到带随机数种子控制的改进版全覆盖拿来就能跑、跑完就能看曲线。适合两类人一类是刚接触 WSN 路由算法、需要一份能复现的基线对比代码的学生另一类是已经在做能耗优化、想拿 LEACH 当底子往上叠改进的工程师。它的价值不是理论多高深而是把「周期性轮换簇首 数据聚合 能量均衡」这一整套机制拆成了可执行的代码你能直接看到每个 round 里节点能量怎么掉、簇首怎么换、网络什么时候死。2. LEACH 的核心机制为什么轮换簇首能延长网络寿命2.1 分簇架构与两跳传输模型LEACH 的网络模型是典型的两跳结构普通节点把数据发给所在簇的簇首簇首把聚合后的数据直接发给基站。这种设计最直接的好处是普通节点只需要近距离通信发射功率可以降到很低而簇首承担远距离传输的代价但因为簇首是轮换的这个代价不会落在固定节点头上。如果你打开 leach.m 看它的初始化部分会发现网络被定义成一个 100×100 的二维平面节点随机撒在中间区域而不是全图基站固定在坐标 (50, 175) 的位置。这其实反映出一个重要选型逻辑——仿真里基站放多远直接决定远距离传输能耗占比也就决定了你的算法还有多少优化空间。LEACH 的簇内通信用的是多播但实际代码里更多是直接按欧氏距离算能耗这个细节后面参数部分会细说。2.2 阈值公式与簇首选举的随机性控制簇首选举是 LEACH 的灵魂。每个 round 开始时每个节点生成一个 0 到 1 之间的随机数如果这个数小于当前轮次的门限值 T(n)该节点就成为簇首。门限值 T(n) 的公式长这样T(n) p / (1 - p * (r mod round(1/p))), if n is in set G T(n) 0, otherwise这里的 p 表示簇首占节点总数的期望比例G 表示在过去 round(1/p) 轮里没有当过簇首的节点集合。这套公式的逻辑是节点当过簇首后会被排除在 G 之外下轮门限值对剩余节点就会变大保证没当过簇首的节点有更高概率被选上。最终效果是全体节点在每 round(1/p) 轮内几乎都轮了一次。参数说明p 不能设置太大否则每轮簇首数量过多簇内节点太少聚合收益反而下降p 太小则簇首负载过重。经典 LEACH 里 p 一般设 0.05 到 0.1对应大约 10 到 20 个簇首分布在 100 个节点里。leach.m 和 leach2.m 的区别也在这里——leach2.m 把 p 设为 0.1 并固定了随机数种子跑出来的曲线平滑很多适合做对比实验。2.3 能量模型与最坏情况的数学账LEACH 的能量模型用的是经典一阶无线传输模型。发送方要消耗发射电路能量和功率放大能量接收方消耗接收电路能量。放大能量分两种场景d d0 时用自由空间模型能耗与距离平方成正比d ≥ d0 时用多路径衰减模型能耗与距离四次方成正比。在 leach.m 里可以看到这组典型参数Eelec 50 nJ/bitepsilon_fs 10 pJ/(bit·m²)epsilon_mp 0.0013 pJ/(bit·m⁴)。数据包默认 4000 bit。这意味着如果一个簇首离基站超过 d0约 87 米它发一帧数据的能耗会急剧上升。这也是 LEACH 的边界——它假定簇首直接和基站单跳通信一旦基站在部署区域外面且距离超过阈值簇首的能量消耗会很快被拉高网络后半段会出现大量簇首提前死亡的现象。对这部分折损有预期的读者再去改簇间多跳会更得心应手。3. 先把 MATLAB 工程跑起来四份脚本的分工与仿真流程3.1 文件清单与选型建议这套资源解压后是四个 .m 文件leach.m、leach2.m、leach3.m、leach4.m。它们不是简单的版本迭代而是按功能逻辑拆开的用途完全不同。文件核心特点适用场景leach.m经典 LEACH 完整实现随机种子未固定理解原始机制观察随机性影响leach2.m固定随机数种子簇首比例调整到 0.1做基线对比输出稳定可复现leach3.m引入节点剩余能量对簇首门限的修正改进策略验证能量均衡调优leach4.m对数据聚合函数和簇间转发做了改动进阶改造多跳与聚合折中测试新手建议从 leach2.m 开始跑因为它输出稳定不会因为每次随机数不同导致曲线差异过大而怀疑代码写错了。熟手想快速试自己的改进直接复制 leach3.m 改门限公式最省事。3.2 在 MATLAB 里跑通一次完整仿真打开 MATLAB把解压后的文件夹设为当前目录直接在命令行执行leach2脚本会自动生成两个图第一个图展示每一轮存活的节点数量网络生命周期曲线第二个图展示每轮所有节点的剩余能量总和总能耗曲线。跑完大概二三十秒取决于你的机器配置。如果你想改实验参数比如节点数量、网络覆盖面积、基站位置在 leach2.m 开头找这组代码n 100; % 节点数量 xm 100; ym 100; % 部署区域大小 sink.x 50; sink.y 175; % 基站位置 p 0.1; % 簇首比例 Eo 0.5; % 初始能量焦耳这里的 Eo 每个节点初始能量都相同也就是摘要里提到的 LEACH 原始假设——所有节点能量均匀。实际工程场景中节点能量很可能不一致比如靠近数据源的节点因转发多而掉电快这种情况下你可以在初始化数组时给不同节点赋不同初值leach3.m 里已经示范了这种改造思路。仿真结束后观察两个数据第一个是第一个节点死亡时的轮数FND第二个是最后一轮存活节点数降为零的轮数LND。LEACH 论文中最常引用的就是这两个指标你后续做任何改进都要和这两个基线数值对比。3.3 节点状态机与轮次推进逻辑LEACH 每个 round 是一个完整的状态循环。在 leach.m 里每轮流程是这样的for r 1:1:rmax % 1. 簇首选举节点随机数与门限值比较 if (rand threshold) (node.energy 0) node.role CH; end % 2. 普通节点选择最近的簇首加入 % 遍历所有簇首计算欧氏距离选择最小距离 % 3. 簇内节点 TDMA 调度发送数据 % 4. 簇首聚合后发送给基站 % 5. 更新每轮能耗和存活节点记录 end逻辑说明每轮开始时节点先判断自己是簇首还是普通成员普通节点要用一轮广播拿到所有簇首的位置信息再选择加入哪个簇。这里有个隐含成本——簇首位置信息的广播也是要耗能的只是代码里通常简化处理没有把这部分广播开销计入每轮能量更新。如果你想做更精细的能耗建模这里是一个可以扩展的切入点。参数说明rmax 是最大轮数可以根据经验手工设比如跑 2000 轮还是 4000 轮取决于网络规模和初始能量。如果初始能量 Eo 从 0.5 加到 1网络生命周期会线性增长但仿真时间也会变长。我自己习惯先设 2000 轮观察全貌确定曲线形态后再缩小范围细化。4. 簇首比例与能量均衡把 LEACH 改成适合自己场景的形态4.1 簇首比例 p 对网络生命周期的影响p 值是 LEACH 里最值得做敏感性分析的参数。你可以在 leach2.m 里循环试 p 0.05、0.1、0.15、0.2每次只改这一个变量记录 FND 和 LND。从我的经验看p 过小比如 0.02时每轮簇首就两三个簇规模太大簇内普通节点离簇首很远发送数据的距离能耗大幅上升FND 会提前出现。p 过大比如 0.3时每轮接近三分之一的节点在当簇首每个簇就两三个节点数据聚合节省的传输量不足以抵消簇首远距离传输基站的能耗LND 反而缩短。一个比较放心的区间是 0.05 到 0.1 之间。原因在于 LEACH 的能量模型里簇首发送聚合数据到基站是最大的一块开销这个开销基本固定所以每轮簇首越少这个开销越低但前提是簇内通信不能离太远。环境监测这种节点分布均匀的场景p 取 0.08 左右往往表现比较稳。4.2 节点初始能量不均匀下的改进方向摘要里提到 LEACH 的局限之一是假设所有节点初始能量相同。你拿到 leach3.m 后会看到它的门限公式已经变成这样threshold p / (1 - p * mod(r, round(1/p))) * (node.energy / Eo);这个乘上剩余能量比率的做法本质上是让剩余能量多的节点优先当簇首剩余能量少的节点降低被选概率。这就是所谓的基于剩余能量的改进思路也是 LEACH 变种里最常见的修改手段。注意看这里的实现细节它没有直接改 T(n) 的分母而是在原公式后面乘了一个能量系数。这样做的好处是保持了原算法的选举轮换机制坏处是能量系数可能让某些节点长期不愿意当簇首形成能量富余不用能量不足更不用的恶性循环。如果你自己写改进版本可以考虑加一个能量阈值下限低于阈值必须强制担任簇首保证算法在低能量阶段仍然有足够多的簇首维持覆盖。4.3 数据聚合函数的选择与能耗折算数据聚合是 LEACH 节省能耗的另一大来源。代码里一般这么写% 簇首收到簇内节点数据后做聚合 packet_aggregated mean(packet_received); % 聚合后只发送一条标准长度数据到基站 energy_consumed Eelec * packet_length epsilon_mp * packet_length * distance_to_sink^4;这个均值聚合在代码里是一条指令但在实际工程里意味着簇首要把收到的多条数据进行融合、去重、压缩这个过程本身需要计算开销和缓存开销。仿真里通常把聚合能耗算进簇首接收数据那一刻的 Eelec 里也就是把每条数据的接收能耗都计了但聚合计算本身的能耗没有单列。参数说明packet_length 默认 4000 bit 是经典值如果你仿真的是温湿度监测这类低频小数据包建议改成 200 bit 级别否则能耗占比会偏离实际。如果你想模拟更精细的聚合开销可以在每个 round 的簇首处理阶段加一行固定能耗比如cluster_head_energy cluster_head_energy - aggregation_cost;这样网络整体死亡轮数会提前但这更接近真实硬件表现。4.4 与 LEACH-C 的对比思路leach4.m 里已经做了某种程度的中心化簇首选择改动。如果你想完整对比 LEACH 和 LEACH-C集中式 LEACH需要把 leach4.m 和 leach2.m 跑在完全相同的网络拓扑上固定随机种子然后对比两条曲线。一个容易踩的坑是不同脚本生成网络的随机数序列不一样导致网络拓扑不同对比就失去意义。解决方法是把节点坐标初始化单独抽成一个函数或者让所有脚本从同一个 seed 生成随机数。leach2.m 里已经固定了 seed你可以把 leach.m 和 leach3.m 的 seed 改成和它一致确保对比的是算法差异而不是随机拓扑差异。5. 仿真避坑随机性、孤立节点与能耗统计的四个典型问题5.1 每次跑出来的结果都不一样现象同样的代码和参数连续跑三次 leach.m得到的三条生命周期曲线差异很大FND 可能差出几十轮。原因LEACH 的簇首选举依赖每个节点生成的随机数随机数不同会导致每轮簇首集合完全不同节点分簇结果也完全不同整体能耗分布自然不同。这是 LEACH 本身随机性决定的不是代码 bug。解决做对比实验时统一用 leach2.m 这种固定随机数种子的版本。或者在 leach.m 开头加一行rng(2024)这样每次跑都是同一套随机序列。如果要做多次蒙特卡洛统计建议循环跑 30 次取平均而不是一次跑完看单条曲线。5.2 网络在运行中出现孤立节点现象某个节点既没有成为簇首也没有加入任何簇每轮能量完全不消耗但也不发送数据。从图上看不像是死节点因为它能量还是满的。原因簇首选举后普通节点根据到簇首的欧氏距离选择加入哪个簇。如果某个节点周围半径内没有任何簇首比如簇首数量过少、分布不均它会找不到可加入的簇代码默认把它标记为独立簇首但这和正常簇首行为不同后续数据聚合逻辑会出问题。解决把 p 值调高一点保证每轮簇首密度足够覆盖整个网络。另一种方案是在代码里给这种孤立节点加一个兜底逻辑——如果找不到簇就把数据直接发给基站虽然能耗高但不会丢数据。看 leach3.m 时多留意它对这个边界的处理如果没有处理你自己补这个分支。5.3 能耗曲线上出现不正常的能量回增现象剩余总能量曲线在某一轮突然跳增出现一个向上的台阶明显不合物理规律。原因查一下代码里死亡节点的处理逻辑。常见错误是节点能量小于等于零后在 next round 又重新进入了候选节点集合并且因为随机数恰好低于门限值被判为簇首然后被充值了能量。这是状态机更新没做严格判断导致的逻辑漏洞。解决在簇首选举前强制检查节点能量是否大于零if node.energy 0 rand threshold node.role CH; else node.role N; % 普通节点 end凡是能量归零的节点直接跳过选举和簇加入两个环节只保留它在死亡节点统计中的记录。改完再跑能量曲线一定单调递减。5.4 结果图和文献对不上现象自己跑出来的 FND 和 LND 数值与论文里报道的差距很大怀疑脚本实现有问题。原因多数情况下是初始条件不一致——对方论文用的基站位置、节点分布范围、Eelec 参数可能都和你不同。LEACH 这类算法对网络参数极其敏感基站远 50 米网络寿命可能直接折半。解决先复现同参数条件下的基线再谈改进。记录下你的完整参数表包括 n、xm、ym、sink 坐标、Eo、p、Eelec、epsilon_fs、epsilon_mp、packet_length发给对方或在自己的实验记录里固定下来。我一般会在脚本顶部专门开一个注释块把这些参数全部写在最上面每次实验只改这一块方便复盘。5.5 改进算法的效果对比没有显著性现象把门限公式改了之后跑出来的曲线跟 LEACH 基线对比差距很小甚至时好时坏没法判断改进是否真的有效。原因单次随机种子下的对比天然具有噪声。如果你的改进点只在门限选举层面影响的是簇首分布和能耗均衡的长期表现这种影响需要几十轮甚至几百轮才能体现到总曲线上单次对比很难稳定看出差异。解决如果用蒙特卡洛方式每种方案跑 30 次分别记录 FND 和 LND 的平均值和方差然后画箱线图对比。只有当均值差超过方差带时才能说改进有统计意义上的效果。另外 LND 这个指标太粗容易掩盖问题建议同时记录每轮存活节点数在 50%、80% 存活的轮数做对比这样的差异更敏感。6. 验证自己的改进把 LEACH 从仿真推向工程应用的检查清单拿到这套代码不要急着改算法。我的习惯是先跑通 leach2.m然后把它的输出保存成一个 mat 文件作为基线数据以后任何改动都和这个基线对拍。具体操作是在脚本末尾加两行save(baseline_lifecycle.mat, alive, energy_total, fnd, lnd);alive 是每一轮存活节点数的向量energy_total 是每轮总剩余能量的向量。这样你就有了一个固定不变的数字基准不用每次重新跑一遍基线节省时间也不会因为随机种子变化弄混对比结果。接下来要做的是验证你的改动真实有效。我给的检查顺序是这样的第一步确认初始条件一致随机种子固定网络节点坐标和基站坐标完全一致第二步把改进前后两条 alive 曲线画在同一张图上观察 50% 存活轮数即半死轮数的提升幅度而不是只看 FND 和 LND 两个点第三步统计每个节点从开始到死亡被选中为簇首的次数分布理想状态下这个分布应该比较均匀如果出现某个节点当了十几次簇首而其他节点不到一次就说明你的改进不如原版均衡。第四步如果你的改进引入了额外计算开销或控制报文在能耗模型里加进去再对比否则体现在图上看起来很理想的收益到实际硬件里会被控制报文的能耗吃光。血泪经验说一句改 LEACH 最容易在门限公式上翻车尤其是能量系数这类动态修正项处理不好会让网络在后期陷入簇首稳定轮换死锁。最典型的坑是剩余能量乘数设成node.energy / Eo后当节点能量降到 10% 时门限值降到原来的 10%该节点几乎不可能再当簇首而那些能量高的节点被反复选中反而加速它们死亡。处理好细节之后你会发现LEACH 最大的价值不是拿它直接部署而是它把「均衡」这个抽象概念变成了一组可以在 MATLAB 里逐步调试的数据结构。从那以后我做任何 WSN 路由实验都强制自己先跑一遍这套标准流程先复现、再改进、最后再验证再也没出现过那种改了几十行代码最后发现基线数据错了的尴尬情况。希望这套资源也能帮你少走这些弯路。本文还有配套的精品资源点击获取