LEACH、LEACH-C与TS-I-LEACH：无线传感器网络分簇路由协议仿真对比

1. 从网络生命周期瓶颈说起：LEACH为什么经典却又必须被改进

做无线传感器网络（WSN）方向的研究，绕不开LEACH。我大概五年前第一次接触这个协议的时候，在网上找到一堆Matlab代码，但基本都是跑完出张图就完事。真正让我花时间把LEACH、LEACH-C和TS-I-LEACH放在一起对比研究的原因很简单：实际仿真中发现，同样的场景下，LEACH的节点死亡速度比理论预期快得多，而所谓"改进算法"的代码质量又参差不齐，跑出来的结果经常互相矛盾。

无线传感器网络的核心约束就三个字：能量有限。节点靠电池供电，部署在野外或者危险区域后基本没有更换电池的可能性。所以所有路由协议的设计目标归根结底就一句话——在能量受限的条件下，怎么把数据可靠地传回基站（Sink），同时让整个网络的寿命尽可能长。这种场景下，路由协议的好坏直接决定网络能撑多久，而LEACH就是这类问题的经典起点。

LEACH的全称是Low Energy Adaptive Clustering Hierarchy，低功耗自适应分簇层次协议。它最核心的思想就是分簇和轮换：把节点分成若干个簇，每个簇有一个簇头（Cluster Head），普通节点把数据发给簇头，簇头做数据融合后直接发给基站。关键机制在于"轮换"——簇头不是固定的，每一轮都随机选举，避免某些节点因为一直当簇头而提前耗尽能量。这个思路在1990年代提出来的时候非常超前，哪怕是现在，市面上绝大多数分簇协议都还在沿用这个框架。

但LEACH的问题也恰恰出在"随机选举"上。它选簇头的时候只考虑概率，不考虑节点的剩余能量、位置分布、邻居密度。于是经常出现一个现象：能量已经快耗尽的节点依然可能当选簇头，然后一两个周期就死掉；或者两个簇头距离特别近，造成覆盖重叠和冗余通信。所以后续的研究者都在做一件事——给簇头选举加入"智能"，LEACH-C和TS-I-LEACH就是这条演进路线上的两个典型代表。

我当时做对比研究的目标非常明确：第一，搞清楚这三种协议在相同仿真环境下的真实性能差距到底有多大；第二，弄懂它们各自的适用场景，因为不存在一个算法是万能的；第三，把Matlab代码整理成模块化的、可以复用的版本，方便后续做二次修改。这篇文章就是把整个研究过程、原理拆解、仿真配置和核心代码逻辑完整地记录下来，适合正在做WSN方向课程设计、毕业论文或者想快速上手协议仿真对比的同学参考。

2. 三种算法的核心运转逻辑：簇头选举的博弈与差异

要理解LEACH、LEACH-C和TS-I-LEACH的本质区别，不能停留在"一个随机、一个集中式、一个改进版"这种粗略标签上。我把它们各自的运转机制拆开讲清楚，尤其是簇头选举这一步，因为这是所有分簇协议性能差异的根源。

2.1 LEACH的能量阈值轮换机制

LEACH的簇头选举采用分布式控制，每个节点独立产生一个0到1之间的随机数。如果这个随机数小于阈值T(n)，节点就宣布自己是簇头。T(n)的计算公式是：

T(n) = p / (1 - p * (r mod (1/p))) 若 n ∈ G T(n) = 0 其他情况

其中p是簇头比例（通常取0.05~0.1，也就是总数的5%~10%），r是当前轮数，G是最近1/p轮内没有被选为簇头的节点集合。这个公式的逻辑很巧妙：随着轮数推进，分母越来越小，导致T(n)越来越大，所以没做过簇头的节点被选中的概率会逐渐提高，直到每个人都轮过一遍。

但这个机制有个致命缺陷——概率模型和能量状态完全脱钩。比如一个节点部署在基站附近，通信距离短、能耗天然就低，它和另一个离基站200米远的节点在选举时拥有完全相同的被选概率，这明显不公平。实际仿真中，我经常看到远端低能量节点当选簇头后，第一个周期就能量耗尽，然后那个区域直接变成"数据空洞"。

2.2 LEACH-C的集中式全局规划方案

LEACH-C的全称是LEACH-Centralized。与LEACH最大的区别在于，它把簇头选举的决定权从各个节点收回到基站统一规划，也就是集中式控制。每一轮开始时，每个节点把自己的位置信息和当前剩余能量上报给基站，基站收集全部信息后，运行一个模拟退火算法（Simulated Annealing）来寻找簇头数量固定、簇内总通信距离最小的簇头集合。

基站规划完成后，把当选簇头的节点ID列表广播给全网，然后进入稳定的数据传输阶段。这个设计的好处非常明显：基站掌握全局信息，能避开"两个簇头挨在一起"这种局部最优陷阱，也能优先选择高剩余能量的节点。仿真结果显示，LEACH-C的网络生命周期普遍比LEACH长25%~40%，在节点均匀分布的场景下尤其明显。

但LEACH-C也不是没有代价。首先，每一轮开始时的"节点上报信息 + 基站广播簇头列表"需要额外的通信开销，这在网络规模大的时候会吃不少能量；其次，模拟退火算法的迭代过程消耗的计算时间在Matlab仿真中不是问题，但在真实节点上要考虑基站的算力；最后，如果基站和节点之间的距离很远，公告信令的能量成本甚至会抵消掉分簇优化的收益。

2.3 TS-I-LEACH针对什么问题做改进

TS-I-LEACH的命名，通常是Threshold-Sensitive Improved LEACH（阈值敏感的改进型LEACH）。它针对的是上面两种协议都忽视的一个问题：ESM（事件驱动型监测）场景下的能耗浪费。

先解释一下背景。LEACH和LEACH-C都属于周期型上报协议——不管监测区域有没有异常，每个周期都会把所有数据传到基站。但很多实际场景是事件驱动的，比如森林火灾监测、入侵检测、结构健康监测，这类场景平时数据基本不变，只有超过某个阈值才需要上报。如果依然周期性全量上报，绝大部分能量都浪费在传输冗余数据上。

TS-I-LEACH在簇头选举和数据传输两个层面做了改进。簇头选举上，它不再纯粹依赖随机数，而是引入能量阈值筛选机制：

若 节点剩余能量 > E_threshold 且 随机数 < T(n)，则当选簇头

这个能量阈值E_threshold根据全网平均剩余能量动态调整，保证低能量节点即使在概率上被选中，也会主动放弃资格。数据传输上，它借鉴了TEEN（Threshold-sensitive Energy Efficient sensor Network protocol）的思路，引入硬阈值（HT）和软阈值（ST）两个参数——硬阈值决定"突变到什么程度必须上报"，软阈值决定"变化幅度多大需要触发一次新上报"。

这种设计带来的直接收益是：在事件稀疏的场景下，TS-I-LEACH的数据上报量只有LEACH的30%~50%，节点进入休眠状态的时间大幅增加，网络生命周期能延长60%以上。代价是它的实时性相对受限，如果事件变化频率极高，软硬阈值的反复触发反而会增加控制开销，这也是我在仿真中实际测到的一个反直觉现象。

2.4 三种协议在簇头选举维度上的关键差异

对比维度	LEACH	LEACH-C	TS-I-LEACH
选举控制方式	分布式，节点自决	集中式，基站规划	分布式+能量阈值筛选
决策依据	随机数+轮换周期	全网节点剩余能量+位置	剩余能量+随机数+事件触发
是否需要位置信息	不需要	需要GPS或定位算法	不需要（可扩展）
额外信令开销	低	中等（每轮上报位置和能量）	低（只需局部信息）
数据上报机制	周期上报	周期上报	事件驱动+阈值触发
适合场景	均匀分布、周期监测	节点均匀、基站算力充足	事件稀疏、突发性监测

这个表格是我做选型判断时的核心工具。简单说：如果你的应用是常规环境监控，节点分布均匀，LEACH-C是最稳妥的选择；如果是稀疏事件监测，比如部署在野外的震动传感器阵列，TS-I-LEACH的能耗优势会非常明显。

3. Matlab仿真环境搭建：参数设定与场景合理性判断

做协议性能对比，最忌讳的就是"换了个算法但场景参数不统一"——这种情况跑出来的差异根本没法归因。我在设计仿真时，把所有可调参数固定在同一套配置下，只改变三个协议本身的逻辑。

3.1 仿真场景与基础参数

仿真区域设定为100m×100m的正方形区域，100个传感器节点随机均匀分布，基站（Sink）固定在坐标(50, 175)处，即区域正上方75米的位置。这个配置是LEACH研究中最经典的标准场景，几乎所有的对比文献都沿用这个设定，好处是结果可以直接和已发表论文对照验证。

节点初始能量Eo统一设置为0.5J，这个值偏小，会加速整个仿真周期，适合快速肉眼观察协议差异；如果你在做正式实验，建议把Eo提到1J~2J，跑出来的曲线更平滑，但仿真时间会长不少。

能耗模型采用经典的一阶无线通信模型：

• 发送/接收电路损耗：Eelec = 50nJ/bit
• 功放系数：短距离 εfs = 10pJ/bit/m²，远距离 εmp = 0.0013pJ/bit/m⁴
• 自由空间信道模型阈值：d0 = sqrt(εfs / εmp) ≈ 87.7m

数据包大小设定为4000bit，簇头到基站之间用多径衰落模型（d⁴），簇内节点到簇头之间用自由空间模型（d²），两种模型的分界距离就是上面算出来的d0。

3.2 生命周期评价指标的选取

协议性能好坏不能只看一个指标，我从三个维度来评价：

• FND（First Node Death）：第一个节点死亡所在的轮数。它反映的是网络的能量分配均衡程度。FND越晚，说明没有节点被过度消耗，这是衡量算法公平性的重要指标。
• HND（Half Node Death）：一半节点死亡所在的轮数。它比FND更稳定，因为第一个节点死亡有随机性，单次仿真可能波动大，HND则代表了"网络服务质量明显退化"的节点。
• 数据接收总量（Total Data Received at BS）：基站收到的总数据包数。这个指标反映的是"网络在生存期内到底干了多少活"，有时候网络活得很久但传回的数据很少，这样的协议是没有实用价值的。

另外我还记录每轮存活节点数，用这个数据画生命周期曲线。这条曲线是最直观的展示方式——曲线的平台期越长、下降的斜率越缓，说明协议的能量均衡性越好。

3.3 仿真中的随机性处理

LEACH系列协议都带有随机性，单次仿真的结果波动很大，如果只跑一次就下结论，很可能得出完全错误的比较结果。我在研究中采用了两种手段来控制：

第一种是随机数种子分组对比。在相同节点分布下，用同一组随机种子跑三种协议，保证它们面对的是完全相同的初始场景和信道条件。这种"配对对照"的方式可以消除节点分布带来的误差。

第二种是多轮独立重复实验。修改随机种子（比如从1到20），每个协议跑20次，取平均值作为最终结果。20次可能看着不算多，但每个场景跑20次就足够稳定了。我在实测中发现，FND在5次以内的波动能超过15%，而20次平均后的标准差能控制在3%以下——所以如果你赶时间只跑几次，结果只能看个大概方向，别拿去做严谨结论。

4. 关键函数代码解读：网络初始化、簇头选举与数据转发

代码质量决定实验效率。我最初从网上扒下来的LEACH代码普遍有个通病——全局变量满天飞，整个逻辑写在一个巨型脚本里，想改一个参数需要在代码里搜三次。所以我自己整理出了一套模块化结构，下面把核心代码的逻辑拆开讲，你拿到之后可以直接在此基础上改。

4.1 网络初始化和节点信息结构

Matlab中我用结构体数组来管理节点，每个字段存储节点的一个属性——坐标、能量、簇头ID、所在簇、死亡状态等。初始化的核心逻辑是：

% 参数初始化 S = struct('x', zeros(n, 1), 'y', zeros(n, 1), 'E', zeros(n, 1), ... 'G', zeros(n, 1), 'CH', zeros(n, 1), 'dead', zeros(n, 1)); for i = 1:n S(i).x = rand * Xm; % 节点在[0, 100]内随机定位 S(i).y = rand * Ym; S(i).E = Eo; % 初始能量0.5J S(i).G = 0; % 标志位，记录该节点当前轮是否可被选为簇头 S(i).dead = 0; % 0表示存活，1表示死亡 end

这个阶段有几个容易踩的坑。第一个是节点坐标必须加上误差范围检查，如果你修改了区域大小（比如扩大到200×200），需要同步检查节点是否和其他节点重合，否则后续计算距离时会产生大量零距离通信，影响仿真精度。第二个是G标志位在每轮簇头选举前必须清零，我DEBUG时经常遇到"节点第二轮开始全部死亡"的奇葩问题，排查到最后常常只是G没有重置。

4.2 LEACH阈值选举的Matlab实现

LEACH的簇头选举核心就是那个阈值公式，Matlab实现并不复杂，但要注意每轮对G列表的更新逻辑：

% 计算当前轮数下的阈值T(n) if s.G == 0 % 本轮有资格参选 temp_rand = rand; % 生成[0,1]随机数 if temp_rand <= (p / (1 - p * mod(r, round(1/p)))) s.CH = 1; % 选中为簇头 % 标记该节点，防止下一轮重复当选 s.G = 1; end end

这里round(1/p)的作用是计算"一轮完整轮换周期"的轮数，比如p=0.1时，每个节点在10轮内至多当选一次。当r mod (1/p)从0增长到接近1/p时，阈值T(n)会从p逐渐增大到1，这意味着越接近轮换周期末尾，未当选过的节点被选中的概率越高。

实跑的时候我建议输出统计信息来验证选举的均衡性：每轮簇头数量是否在5~10之间波动、每个节点的当选次数是否基本均等。我当时仿真时发现LEACH在某些轮次出现簇头数达到12个甚至更多的情况，原因在于G标志在节点死亡后没有正确清理，导致活跃节点的当选概率叠加。

4.3 LEACH-C的集中式选举实现逻辑

LEACH-C和LEACH的最大区别在于，它不是每个节点自己决定是否当簇头，而是基站收集所有节点的位置和能量后，运行算法来选定簇头。这个"基站视角"的选举在Matlab里可以用以下伪代码表达：

if r == 1 for i = 1:n % 每轮开始，所有存活节点上报位置和能量 S(i).pos = [S(i).xd S(i).yd]; S(i).E_remaining = S(i).E; end end % 基站计算最优簇头集合 [best_CH, min_cost] = simulated_annealing(S, optimal_CH_num);

模拟退火参数中我比较关心初始温度和降温速率的平衡。初始温度设太高、降温太慢，会拖慢每轮的运算速度；初始温度太低又容易陷入局部最优。经过实测，比较合适的组合是初始温度T0=10，降温系数alpha=0.95，每个温度下迭代L=15步。这个配置大约能把每轮的簇头规划控制在几百毫秒内完成，且规划结果基本稳定。

此外LEACH-C每轮需要所有存活节点向基站发送位置和能量信息，这个额外信令开销在代码里也必须计入能耗，否则结果偏乐观。我参考的方式是：每个节点的信息上报按一次短帧数据传输（比如200bit）计算能耗，这个看似很小的开销在长周期仿真下不容忽视。

4.4 TS-I-LEACH的核心改进代码

TS-I-LEACH最核心的创新在能量阈值筛选和数据触发逻辑。簇头选举的Matlab实现是在标准LEACH的阈值判断之前，加一个剩余能量的门槛：

% 计算全网平均剩余能量（由基站或簇头广播给节点） avg_energy = mean([S(~dead).E]); for i = 1:n if S(i).E > avg_energy * energy_factor % energy_factor可调，默认1.0 if S(i).G == 0 temp_rand = rand; if temp_rand <= (p_opt / (1 - p_opt * mod(r, round(1/p_opt)))) S(i).CH = 1; S(i).G = 1; end end end end

energy_factor我一般设成0.8~1.2之间的值，它控制"高能量优先"的强度——设太小能量筛选等于摆设，设太大又会导致高能量节点频繁当选、能量被快速集中消耗，反而不均衡。TS-I-LEACH里的一个改进是把avg_energy按距离因子加权：簇头优先从靠近网络几何中心的位置产出，以减少簇内平均通信距离。

数据传输触发逻辑是实现事件驱动省电的关键部分：

% TS-I-LEACH: 双重阈值触发上报 if sensed_value >= HT % 硬阈值，达到绝对阈值必须上报 transmit_to_CH(packet); elif abs(sensed_value - last_value) >= ST % 软阈值，变化幅度超限才上报 transmit_to_CH(packet); else % 不满足触发条件，节点进入低功耗监听 end last_value = sensed_value;

需要注意的是，硬阈值HT的设定不能太高，否则事件永远触发不了；也不能太低，否则退化成周期上报。一般根据具体监测对象的正常波动范围来取，比如监测温度时HT取正常值的三倍标准差，ST取正常波动的1%~5%。

4.5 数据转发与能量扣除的工程处理

无论哪种协议，数据转发阶段的能量扣除逻辑是相同的——发送数据要扣掉发射电路损耗和功放损耗，接收数据要扣掉接收电路损耗：

% 普通节点向簇头发送数据 (自由空间模型) ETX = Eelec * packetLen + εfs * packetLen * (d^2); S(i).E = S(i).E - ETX; % 簇头接收本簇数据 + 数据融合，然后向基站发送 (多径模型) ERX = Eelec * packetLen; S(i).E = S(i).E - ERX; S(i).E = S(i).E - EDA * packetLen; % EDA为数据融合能耗 ETX_CH = Eelec * packetLen + εmp * packetLen * (d_BS^4); S(i).E = S(i).E - ETX_CH;

这里有个细节值得注意：簇头接收完所有簇成员的数据后，还需要进行数据融合（Data Aggregation），融合过程本身也是要消耗能量的（用EDA参数，标准值是5nJ/bit）。很多入门教程的代码把数据融合的能耗漏掉，导致簇头的剩余能量偏高，仿真的生命周期会比真实情况长10%~20%。

另外，每次能量更新后要立刻检查节点是否死亡。如果节点能量小于等于0，需要标记为死亡，并在后续轮次中跳过它的计算和通信。我写代码时习惯在每个函数执行完后加一个if S(i).E <= 0, dead = 1; end的判断，避免死循环或负能量影响后续选举。

5. 仿真结果对比：网络生命周期、能耗与数据稳定性的真实差异

我跑完三种协议各20轮独立仿真之后，把结果放在一起对比，几个结论非常明显，也和一些文献里给出的结论相互印证。

5.1 FND、HND与生命周期曲线对比

用一组具有代表性的参数（p=0.1，Eo=0.5J，BS坐标(50,175)，100个节点）进行仿真，三种协议的关键指标平均数如下：

协议	FND（首个节点死亡轮数）	HND（半数节点死亡轮数）	基站接收总数据（包）
LEACH	约780轮	约1100轮	约3.2万
LEACH-C	约980轮	约1400轮	约4.1万
TS-I-LEACH	约1200轮	约1650轮	约3.0万

从生命周期曲线来看，LEACH在早期就有节点陆续死亡，曲线下降早且陡峭；LEACH-C的第一个死亡节点出现明显延后，平台期更长；TS-I-LEACH则呈现出"前中期特别稳定、后期快速崩塌"的特征——因为它的事件驱动机制让大量节点在前中期保持低功耗状态，能量消耗非常均匀，但当能量阈值筛选导致候选簇头越来越少后，少数高能量节点会被反复选中，加速了整个网络的衰竭。

5.2 能耗均匀度差异：从节点剩余能量分布看原因

为了分析为什么FND差异这么大，我在仿真过程中记录了第600轮时所有存活节点的能量分布情况。LEACH在第600轮时节点能量出现了明显的两极分化：一部分节点能量接近0.4J基本没怎么耗，另一部分已经跌到0.1J以下——这是随机选举导致某些节点反复当簇头、被集中消耗的结果。

LEACH-C的能量分布相对均匀，大部分节点集中在0.2J~0.35J之间，标准差比LEACH小得多。这说明集中式规划确实起到了"能量均衡调配"的作用。

TS-I-LEACH在第600轮时各节点剩余能量均值最高，而且分布也均匀。这得益于能量阈值筛选，低能量节点被排除在候选簇头之外，高能量节点承担更多转发任务，能量消耗更合理。

5.3 数据稳定性与事件触发效率的权衡

如果只看生命周期，TS-I-LEACH似乎完胜，但基站接收总数据包数量反而最少。原因是事件驱动机制下，节点只在事件触发时上报数据，在正常状态下数据非常少。这在真实场景中是合理的——监测系统不希望在风平浪静时收到海量冗余数据——但在有些对数据完整性要求较高的应用中，这种"省电靠牺牲数据量"的方式并不适用。

我在仿真中还故意插入了一个周期性突变事件（每50轮在某个区域内产生持续2轮的高温信号），用来测试三种协议的事件捕获率。结果：LEACH和LEACH-C因为周期性上报，100%捕获到了事件数据，但捕获效率低；TS-I-LEACH因为阈值触发机制，捕获率达到92%，但事件结束后还会产生1~2轮尾随上报。

这个现象说明了一个很实在的道理：TS-I-LEACH适合监测"异常重要、常态不重要"的对象，比如安防、灾情预警；但对那些需要持续收集环境数据用于建模分析的项目，LEACH-C依然是更合适的底座。

5.4 不同初始能量下的稳定性验证

我还额外做了一组成组对比，把节点初始能量从0.5J提高到1J，其他条件不变。三种协议的FND和HND基本按比例提升，但提升幅度略有差异：LEACH的FND提升约2.1倍，LEACH-C约2.3倍，TS-I-LEACH约2.4倍。这说明初始能量越充足，TS-I-LEACH的低功耗优势越能发挥出来；而LEACH-C在初始能量高时依然会比LEACH多出约30%的寿命周期。

6. 仿真中常见但容易被忽略的问题与排查建议

这一部分我结合自己重复实验的过程，整理出几个最具迷惑性的坑，这些问题是很多初做协议对比的人容易忽略的。

6.1 为什么你的TS-I-LEACH跑出来比LEACH还差

有几次我用别人的"改进算法"代码跑实验，结果改进协议的生命周期反而不如原始LEACH。排查下来发现，大多数改进协议代码中增加了不少控制消息（比如能量广播包、簇头竞选包），但这些控制消息在能耗计算中被漏记了，所以看起来"有改进"其实只是在纸面上省能量，实际开销全被甩到了脑后。

我在自己的TS-I-LEACH实现里，把所有额外的控制消息按100bit/包计入能量消耗。这样处理之后，TS-I-LEACH在能耗上的优势虽然缩小了一些，但结果才是真实有用的。

6.2 Matlab仿真结果波动太大怎么办

LEACH系协议每一轮的选举都有随机性，所以单次仿真的曲线波动非常大。如果你不对随机种子做控制，可能会出现"这次LEACH比LEACH-C好，下次又是反过来的"这种无法下结论的情况。我的建议是：

• 固定节点初始分布的种子，保证同一批节点用于所有协议的测试。
• 每个协议至少重复10次以上取平均。
• 在报告中同时给出均值和标准差，而不是只给一条平滑曲线。

6.3 死亡节点判断和二重计费问题

在真实物理节点上，能量消耗是连续的；在Matlab仿真中，能量消耗是离散的。如果一个节点发送数据后发现能量变为-0.002J，那它算不算死亡？这一轮的数据包还算不算成功到达？我采用的做法是：发送前先检查能量是否足够，不够则直接丢弃数据包并把节点标记为死亡，不走"发送完再扣费"的流程。这样既避免负能量问题，也让死亡节点的判断更贴近实际。

另外一个常见问题是二重计费：某个节点把数据发出去，下一轮又重复统计了一次数据接收量。这种情况通常在簇头重选后出现——原来的簇成员已经把数据发给旧簇头了，新簇头又重新请求了一遍。所以要在数据转发逻辑中保证"每轮每个节点只发送一次数据"，并在代码中做去重判断。

6.4 参数p的敏感性分析

LEACH模型中的p值（簇头比例）不是越大越好。p太小则簇头数量少、每个簇覆盖面积大、簇内通信距离远、能耗高；p太大则簇头数量多、数据融合效率降低。我在仿真中测试了p从0.02到0.2的变化：

• p=0.05时，FND和HND最佳平衡；
• p=0.1时，单轮数据接收量最大，但节点死亡速度偏快；
• p=0.2时，出现了大量轮次没有簇头当选的异常情况，因为round(1/p)=5导致轮换周期太短，部分节点还没来得及轮换就死亡。

所以如果你只是做默认仿真，p=0.05是下限，p=0.1是网上代码最常见的取值。做实际工程时，应该根据节点密度和区域大小做一次扫描实验，选择让FND最大的p值。

6.5 事件驱动场景下ST和HT的调参策略

TS-I-LEACH的硬阈值的设定直接决定了"事件触发"的灵敏度。我的调参经验是：先用历史监测数据画出正常的波动范围，HT取超出正常范围的上限值，ST取正常波动的幅度下限。举例来说，如果正常情况下温度变化不超过±1℃，突发事件要达到5℃以上的变化，那么HT取3（超过正常变化3倍即触发），ST取0.5（变化超过0.5℃即上报一次）。ST太小时会产生大量重复上报，浪费能量；太大时事件变化过程中可能丢失中间过程的数据。

7. 从仿真到真实部署的思考：代码价值的延伸方向

这篇对比研究做完之后，我最大的收获不是"哪个协议更省电"这个结论，而是理解了协议设计中的一个核心权衡——省电、实时性、可靠性三者不可兼得。LEACH用随机换简单，LEACH-C用集中控制换均衡，TS-I-LEACH用事件驱动换低功耗，每个取舍背后都是特定应用场景的需求在驱动。

如果你想把仿真代码延伸到更贴近实际的方向，我建议按以下顺序做扩展：

**第一，加入移动节点或移动基站的模型。**真实场景中，很多WSN系统的基站会搭载在无人机或车辆上，数据通过移动汇聚节点来收集。这种情况下，分簇协议中"簇头直传基站"这个假设不成立，需要重新设计簇头与移动基站之间的通信时序。我在这个方向做过初步实验，把基站坐标从固定改为在一段路径上移动，LEACH-C的优势就不明显了，因为集中式规划基于的是静态几何关系，移动场景下每轮都要重新规划，信令开销激增。

**第二，加入链路质量评估机制。**LEACH系协议都是基于距离和能量的理想链路模型。实际部署中，墙体遮挡、多径衰落、干扰都会让真实丢包率远高于仿真值。你可以给每条链路增加一个随机丢包率参数，观察协议在丢包环境下的健壮性。从我的经验看，TS-I-LEACH受丢包影响最大，因为它的事件触发上报本身就依赖少量数据包，一旦丢包就可能错过关键事件。

**第三，把Matlab代码移植到硬件平台上。**如果只是做性能评估，Matlab足够；如果想做原型验证，可以使用真实传感器节点（比如ZigBee节点或LoRa节点）实现简化版的LEACH和TS-I-LEACH逻辑。这时候对比的就不再是仿真能耗，而是电池实际电压和运行时间，那才是最有说服力的数据。

目前我的这套代码已经在多个课程设计中被复用，也帮几个做毕业论文的同学改造成了个性化的仿真环境。如果你读完也在跑这个对比，建议不要只跑完默认参数就收工，试着改一下节点数量、区域大小、基站位置，你会发现很多结论都会改变——这才是研究的乐趣所在。