OHILEACH协议解析：从LEACH到启发式优化的无线传感器网络分簇路由

1. 从LEACH到OHILEACH：能耗黑锅到底出在哪

拿到这套“基于优化的启发式集成低能耗自适应集群层次结构协议（OHILEACH）”的Matlab代码时，我第一反应是：这不就是LEACH吗？但真正跑通一遍，把每一轮的能耗曲线打出来对比之后，我发现自己太天真了。OHILEACH的全称是Optimized Heuristic Integrated Low-Energy Adaptive Clustering Hierarchy，核心不是“换了个壳”，而是把启发式优化算法真正缝进了LEACH的分簇决策里。简单说，LEACH靠概率随机选簇头，OHILEACH靠粒子群或遗传这类启发式算法反复寻优，挑出一组能让全网能耗最低、负载最均衡的簇头组合，再把数据聚合、转发路径一起规划好。

这篇文章适合谁看？两类人。一类是刚接触无线传感器网络路由协议、想在Matlab里复现仿真、拿它写论文或者做课程设计的学生；另一类是已经在跑LEACH、熟悉分簇路由，但觉得传统协议太随机、死节点曲线不够漂亮、想找一个优化方向做对比实验的研究者。只要你能看懂最基本的Matlab语法，下面的代码逻辑、参数调优和经验坑，你都能直接拿去用。

先说结论：OHILEACH不是推翻LEACH，而是把LEACH里最不稳定的那几步——选簇头、定簇型、分配传输路径——从“看运气”改成“看全局”。我一直觉得，想理解任何一个优化型协议，得先搞清楚它到底在优化谁的痛点。所以这一篇，我不打算只贴代码，而是从LEACH的缺陷讲起，把OHILEACH的每一个设计动机、每一段Matlab实现、以及我在实测中踩过的坑，掰开揉碎讲清楚。

1.1 LEACH自带的三宗罪：选簇、定簇、传数据全靠撞运气

LEACH是Low Energy Adaptive Clustering Hierarchy的缩写，这个协议的核心思路是分轮运行，每轮随机选一部分节点当簇头，其他节点加入最近的簇头，簇头负责聚合数据并直接发给基站。这个机制在1990年代末提出来的时候，算是里程碑式的创新，因为它让网络里没有“固定中心”，每个节点轮着当消耗大户，寿命被摊薄了。但在实际跑Matlab仿真的时候，你会很明显地感觉到它的问题。

第一宗罪，簇头数量完全随机。LEACH每轮都会给每个节点生成一个0到1之间的随机数，如果这个数小于阈值T(n)，节点就当簇头。T(n)的计算公式里有当前轮数和期望簇头比例p，看着挺美，但那只是一个概率期望值。我跑过一次150个节点、p=0.1的仿真，某一轮居然跳出来24个簇头，下一轮只剩3个。簇头太多，意味着大量节点在干转发和聚合的活，能量哗啦啦地掉；簇头太少，意味着每个簇的成员太多，簇头接收数据量巨大，聚合压力全压在少数节点上。这种方差从一开始就没有被控制。

第二宗罪，成簇阶段只会“就近抱大腿”。普通节点入簇的逻辑在LEACH里通常基于接收信号强度，也就是哪个簇头离我近、信号强，我就加入谁。这个逻辑本身没毛病，但在节点分布不均匀的网络里會很吃亏。比如我做过一个实验，基站放在区域正上方，部署的时候右下角恰好有一片节点特别密集，结果那片区域的若干个簇头同时被一堆节点请求加入，负载失衡非常严重。

第三宗罪，也是我最无法忍受的一点：所有簇头都直接和基站单跳通信。只要基站不在整个网络的几何中心，远端簇头的通信距离就会非常大。传感器节点发送数据消耗的能量和距离的平方甚至四次方成正比，一阶无线模型里d越大，能耗增长越恐怖。那些离基站远的簇头，常常在不到三分之一的轮数里就耗尽能量，成为死节点，然后它管辖的簇成员全部变成孤立节点，网络覆盖率骤降。

1.2 OHILEACH是怎么把“启发式”缝进层次协议的

OHILEACH针对上面三宗罪的解法，一句话概括就是：把随机选择改成优化选择。具体来说，它用一个启发式算法（比如粒子群优化PSO）在每一轮开始前求解一个组合优化问题——从N个节点里挑出k个簇头，使得“全网总能耗 + 负载不均衡惩罚 + 剩余能量惩罚”这个目标函数最小。

这个思路和LEACH最大的区别在于：LEACH是“局部决定”，每个节点自己掷骰子；OHILEACH是“全局决策”，每一轮都要对全网状态做一次扫描，然后给出一组确定的最优解。你也可以理解为，LEACH是在闭着眼睛买彩票，OHILEACH是在开奖之前先把赔率算清楚再下注。

启发式算法在这里的作用不是碰运气。PSO中每个粒子代表一种簇头组合方案，粒子在解空间里飞行，通过个体最优和历史最优不断修正自己的位置，最终收敛到一组“足够好”的簇头。因为网络生命周期仿真的每一轮只需要做一次这样的寻优，时间复杂度完全可以接受。我实测下来，150个节点一轮的PSO寻优在普通笔记本上大约需要几十毫秒，相比每轮数据传输的模拟时长，这个开销几乎可以忽略。

这也就解释了为什么协议名字里要强调“启发式集成”——它优化的不是单个环节，而是把簇头选择、成簇边界、数据传输链路作为一个整体去求解。这个“集成”两个字，才是OHILEACH和那些只在簇头选择环节做文章的半吊子改进方案的本质区别。

2. OHILEACH的协议机制拆解：分轮、选头、成簇、传输每个环节到底优化了什么

OHILEACH整体上仍然沿用LEACH的分轮架构：每轮分成建立阶段和稳定阶段，稳定阶段远长于建立阶段。这一点没有变，变的是建立阶段内部的动作。我先把整个一轮的完整流程列出来，再逐个环节拆解它的Matlab实现逻辑和设计动机。

• 第1步：检查存活节点集合，更新每个节点的剩余能量、坐标与邻居列表。
• 第2步：基于有限节点集合，编码启发式算法的候选解（粒子或染色体）。
• 第3步：计算每个候选解的目标函数值，选出本轮的簇头集合。
• 第4步：按优化后的簇头集合，每个普通节点就近加入簇。
• 第5步：簇头分配TDMA时隙，簇成员按调度发送数据。
• 第6步：簇头聚合数据并直接发送给基站（或经由中继）。
• 第7步：更新能耗，检查是否存在死亡节点，进入下一轮。

看着像老酒换新瓶？别急，真正有意思的是第2、3、4步的实现细节。

2.1 分轮结构与能量模型：先把账算清楚

不管是哪一代LEACH变种，能耗模型几乎都是固定的一套，OHILEACH也没有脱离这个框架，因为它是无线传感器网络仿真的标准范式。我给这套代码整理过一张完整的能耗计算表，建议你第一次跑仿真之前，先对着它校对一遍你手头版本里的参数，不然结果偏差会非常离谱。

这里的d₀