简介面向无线通信、数据存储与网络传输等场景这份RaptorLDPC预编码仿真资源包提供了完整的MATLAB实现特别适合通信工程专业学生、研究人员以及希望深入理解喷泉码与无速率纠错编码的开发者。包体仅含6个文件并根据功能做了清晰划分3个m脚本文件承担Raptor编码、解码以及AWGN信道下的仿真主流程可直接运行并观察结果3个mat数据文件则保存了不同参数配置下的预编码矩阵、信道中间变量与仿真输出便于对比分析。整个压缩包只有20KB下载与调试都非常轻量。已有536人学习/下载足见其参考价值。借助这套程序用户能直观理解Raptor码如何在喷泉码基础上引入LDPC预编码来提升抗错误能力并可通过修改信息长度、编码率等参数研究误码率随信道条件的变化规律为无线传输、数据存储等场景下的编码方案优化提供可复现的仿真基础。1. Raptor码不是“另一个编码”而是把擦除问题拆开了做通信系统仿真的人第一次听到Raptor码通常是在讨论喷泉码fountain code的时候。我们习惯的RS码、LDPC码都有一个固定的码率——发多少冗余符号、能纠几个错在编码前就算死了。而Raptor码和所有喷泉码一样打破了这种“码率固定”的束缚编码器可以从k个原始符号里无限地生成输出符号接收端只要凑够比k略多一点的有效符号就能把原始数据恢复出来。这个性质让它在广播、深空通信、文件分发和存储系统里非常实用因为它天然适配了“信源不知道信道丢包率”的场景。这里有一个反直觉的结论Raptor码的性能很大一部分并不来自它的“喷泉”部分而是来自它的预编码——也就是标题里那个LDPC预编码。LDPC在这里不是单独作为一个纠错码在工作而是先把原始数据变成“更容易被喷泉编码覆盖”的中间符号。把预编码理解成给喷泉编码铺路就抓住了Raptor码的核心思路把讨厌的度分布设计与纠错能力拆分让每一层只干自己擅长的事。这种分层思想后来也被无线多址接入和网络编码大量借鉴。这篇博文从Raptor码的结构讲起落到LDPC预编码的选型理由和参数取值最后给你一套可以直接跑出BER曲线的Python仿真流程并把度分布参数、预编码率、开销overhead这些仿真时最常踩的坑讲清楚。适合正在做信道编码仿真、评估喷泉码在擦除信道和衰落信道上表现、或者需要给现有系统选型编码方案的工程师看。2. 从喷泉码到Raptor码为什么预编码让LT码脱胎换骨2.1 LT码的译码雪崩与“孤独符号”问题喷泉码的思想并不复杂。Luby在2002年提出的LT码是第一种实用的喷泉码它的编码方式非常直观每生成一个输出符号就从原始符号中随机抽取若干个做异或XOR抽取的个数叫这个输出符号的“度”degree。译码端收到足够多输出符号后先找一个度为1的符号直接恢复它对应的原始符号然后用这个恢复出的原始符号去消除其它输出符号中的未知量不断迭代下去。过程很像在解一个稀疏线性方程组。但LT码有一个致命伤就是小度符号的覆盖问题。为了保证度分布是平滑的编码端必须让一部分输出符号的度很小尤其要让度为1的符号数量足够多否则译码一开始就找不到切入点。但另一方面度为1的符号太多又会浪费喷泉码“少冗余就能恢复”的优势因为度1的符号携带的信息量很低。设计合适的度分布就成了LT码的瓶颈要在“启动可靠”和“整体效率”之间精确平衡。这个平衡一旦处理好LT码可以在开销很小的情况下恢复数据一旦处理不好就会出现译码雪崩——前半程进展正常后半程突然卡住因为没有度为1的符号可供下一步消除了。2.2 Raptor的结构预编码LT输出编码Raptor码的思路是“不把宝全押在度分布上”。Shokrollahi在2004年提出这个方案时核心想法非常简洁先用一个传统的纠错码通常是LDPC码对原始数据做一次预编码把k个原始符号扩展成k′个中间符号其中k′ k然后再对中间符号做LT编码生成最终要传输的输出符号。这里最关键的是预编码增加的少量冗余让LT译码结束后即使还有少量中间符号没有恢复LDPC预编码也能把它们补回来。这个结构带来的直接好处是LT部分的度分布不再需要那么担责。LT编码器即使产生一小部分“不可覆盖”的中间符号LDPC层也能当作一个轻量级擦除修正来处理堵住了LT码单独使用时最脆弱的环节。从信息论角度看Raptor把喷泉码的“通用性”和LDPC码的“逼近香农限的能力”拼接了起来LT管无限生成、LDPC管近完全恢复。这也是为什么后来的RaptorQ码依然沿用了这个结构只是把预编码部分换成了更优的矩阵设计。2.3 Raptor码与RS、LDPC的分工对比把Raptor码和传统编码放在一起比较能更清楚地看到它的设计取向。RS码是代数编码在擦除信道上有完美的MDS性质——接收任意k个符号就能解码但它的计算复杂度是O(k²)量级的k到几千以上就非常吃力。LDPC码是概率编码译码复杂度随码长线性增长性能逼近香农限但LDPC本身是固定码率的编码前就得确定信道丢包率丢包率估计错了纠错能力就差一大截。Raptor码属于“无码率”rateless编码它把码率变成了一个自适应参数。发送端不需要知道信道状态它可以一直发送输出符号直到接收端说“够了”。在丢包率未知、时变、或者一组接收端各不相同的场景里这种特性远比固定码率的LDPC码灵活。但在码长固定的场景里LDPC的性能通常会优于Raptor——这一点在做仿真对比时不要搞反了Raptor码的价值在“无码率可用性”和“无限扩展性”它不是在码长固定的赛道上和LDPC直接竞争的。提示在设计仿真对比实验时Raptor码要加上开销overhead维度来衡量性能而不是只比较固定码率下的误码率。固定码率下比较Raptor码大概率输给专用LDPC这不能说明它不好只是衡量维度选错了。3. 编码参数怎么设ldpc预编码率、度分布和中间符号数3.1 三个必调的参数及其作用域在动手写Raptor码仿真之前先要把三个核心参数的确定顺序和影响讲清楚。第一个是预编码率precoding rate也就是k和k′的比例。预编码率决定LDPC层能扛住多少个LT译码后残留的未恢复中间符号。预编码率越高越接近1.0LDPC层保护越强但总开销也越大。仿真中常见做法是取0.95到0.98也就是说每100个原始符号被预编码成102到105个中间符号。太强了浪费喷泉码的效率太弱了LT层的短板遮不住。第二个是度分布degree distribution。Raptor码最常用的度分布是Shokrollahi在Raptor论文里给出的鲁棒孤子分布Robust Soliton DistributionRSD的改进版或者直接使用标准Raptor码的度分布表。重要的一点是Raptor的度分布允许“牺牲”掉一小部分中间符号——就是说某些原始符号可能不直接出现在任何输出符号里反正LDPC层能补。所以Raptor用RSD时度分布参数可以设计得稍微“弱”一点省下开销。第三个是原始符号大小。这在仿真里通常被忽略但很关键Raptor码的符号大小影响有限域上的运算粒度和LDPC矩阵的构造。仿真里用1比特符号就够了但在实际系统里符号通常是一个字节或多个字节。3.2 LDPC预编码矩阵怎么构造LDPC预编码的矩阵构造是Raptor仿真的隐秘难点。很多人在仿真里用了随机矩阵结果性能差得离谱还以为是度分布出问题了。实际上Raptor码要求的LDPC矩阵必须满足两个条件一是行重列重比较均匀避免出现“孤立变量节点”导致有中间符号完全不受保护二是矩阵必须保证满秩否则预编码本身就丢了信息。在仿真里构造这个矩阵可以不用自己去实现完整的LDPC构造算法直接用下面的方式生成一个规则LDPC矩阵import numpy as np def generate_ldpc_matrix(n_intermediate, n_precode, d_c, d_v): # n_intermediate: 预编码后的中间符号总数 (k) # n_precode: 原始符号数 (k) # d_c: 校验节点度数 (每行1的个数) # d_v: 变量节点度数 (每列1的个数) assert n_intermediate * d_v n_precode * d_c # 用渐进边增长(PEG)算法思想构造避免短环 H np.zeros((n_precode, n_intermediate), dtypeint) # 第一轮按列均匀填充 col_degree np.zeros(n_intermediate) row_degree np.zeros(n_precode) # 这里用一个简化的均匀分布 避免列重过大 for col in range(n_intermediate): # 找出当前度数最小的行 candidates np.argsort(row_degree)[:d_v] for row in candidates: if H[row, col] 0 and row_degree[row] d_c: H[row, col] 1 row_degree[row] 1 col_degree[col] 1 # 保证列重均匀如果某些列没填够做二次分配 for col in range(n_intermediate): while col_degree[col] d_v: row np.argmin(row_degree) if H[row, col] 0: H[row, col] 1 row_degree[row] 1 col_degree[col] 1 return H这段代码的关键在于第一轮按列填充时优先选度数最小的行这保证了LDPC矩阵的行重不会出现“一根柱子扛十根梁”的极端情况第二轮是兜底防止某些列度不够。实际构造LDPC矩阵时PEG算法会复杂得多但这个简化版本在仿真场景下已经能提供足够的多样性。参数上d_c和d_v的选取直接对应了LDPC码率码率 1 - d_v / d_c。比如d_v 3、d_c 15码率就是1 - 3/15 0.8配合Raptor整体的k/k′ 0.96可以算出总冗余是相当可观的。3.3 一个可以直接套用的参数模板做参数设定时我一般建议先用一组已经验证过的保守参数起跑而不是上来就追求极致效率。下面的表格给了一组可以直接用于仿真初始跑的参数这组参数的出发点是保证“先能跑通、再看曲线形状”而不是最优配置。参数名取值说明原始符号数 k100小规模方便调试和打印中间状态中间符号数 k′104预编码率0.962LDPC层载荷较轻LDPC矩阵 d_v / d_c3 / 12码率0.75保护强度足度分布类型RSD 修正避免纯LT的高开销仿真信道BEC二元擦除信道先验证编码逻辑再换AWGN最大生成符号数2k防止无限循环同时覆盖开销变化这组参数对应的预编码率约0.96、LDPC内部码率0.75综合冗余系数大概是1.04 × 1.33 ≈ 1.38——也就是说接收端需要约1.38k个符号才能可靠恢复。这个冗余虽然比最优状态高出不少但好处是LDPC层的纠错余量很大LT层即便设计得粗糙一些也能可靠译码。跑通之后再逐步压低预编码率、调整度分布观察性能曲线的移动方向。4. 用Python在BEC信道上把Raptor码仿真跑起来4.1 整体流程与数据结构设计Raptor码的仿真链路相对清楚原始数据 → LDPC预编码 → LT编码 → BEC信道随机擦除符号 → LT译码 → LDPC译码 → 恢复数据。整条链路里需要维护的核心数据结构是三个原始符号数组precoded symbols、中间符号数组intermediate symbols和输出符号列表output symbols。这里有一个编码顺序上的细节LT编码器工作在中间符号上而不是直接工作在原始符号上。所以LT编码生成的每个输出符号本质上都关联了一个“邻居集合”——它异或了哪些中间符号。接收端要能译码必须知道每个输出符号的邻居列表这个信息在仿真里可以直接一并生成传输真实系统里通常通过双方共享的随机数种子来重构同一组邻居关系。4.2 编码器LDPC预编码 LT输出下面是编码端的核心代码import numpy as np def raptor_encode(k, precode_matrix, degree_dist): 输入: k个原始符号 (0/1向量长度为k) 输出: 无限生成的输出符号序列这里生成固定数量 # 第一步LDPC预编码 # 原始符号向量 s (s_0, s_1, ..., s_{k-1}) # 中间符号向量 t (s | p)其中p是校验符号 k_prime precode_matrix.shape[1] n_checks k_prime - k s np.random.randint(0, 2, k).astype(np.uint8) # 校验符号 p H_check * s (mod 2)从LDPC矩阵的右边分出系统部分 H_system precode_matrix[:, :k] H_parity precode_matrix[:, k:] p (H_system s) % 2 # 这里简化处理实际应求H_parity的逆 t np.concatenate([s, p]).astype(np.uint8) # 第二步LT编码生成输出符号 outputs [] for idx in range(200): # 最多生成200个实际可无限 # 从度分布中采样一个度 degree np.random.choice(len(degree_dist), pdegree_dist) degree max(degree, 1) # 度不能为0 # 随机选degree个中间符号 neighbors np.random.choice(k_prime, sizedegree, replaceFalse) # 异或出输出符号 x 0 for n in neighbors: x ^ t[n] outputs.append({ neighbors: neighbors.tolist(), value: int(x) }) return outputs, t def degree_distribution(k): # 简化的鲁棒孤子分布RSD c 0.1 # 常数项 delta 0.5 # 译码失败概率指标 R c * np.log(k / delta) * np.sqrt(k) dist np.zeros(k 1) for d in range(1, k 1): if d 1: rho 1.0 / k else: rho 1.0 / (d * (d - 1)) # 加上孤子分布的修正项 if 1 d k / R: tau R / (d * k) elif d int(k / R): tau R * np.log(R) / k else: tau 0 dist[d] rho tau return dist / dist.sum()这段代码里最容易出错的地方在第12行的H_system s矩阵乘法在numpy里默认是整数乘法不是模2的异或和。所以必须补% 2。更严谨的写法是把所有运算都限制在GF(2)域上使用位运算或者把矩阵和向量都转成布尔型再取逻辑异或。仿真中不在意性能的话直接% 2是最精简的写法。度分布的设计在degree_distribution函数里。RSD的实际构造要比这段代码复杂但核心公式是对的标准孤子分布rho项保证译码启动和推进修正项tau项保证小度符号有一定的兜底数量。c和delta两个参数里c控制RSD的峰值位置通常取0.05到0.2之间delta是允许的译码失败概率工程上取0.5即可因为Raptor码后面还有LDPC兜底不需要LT层真的做到“极低失败率”。4.3 译码器置信传播BP在擦除信道上如何工作Raptor码在BEC信道上的译码就是经典的置信传播Belief Propagation算法的退化形式——在擦除信道上BP算法退化成一种确定性消元过程不需要计算概率只需要做异或。核心思想是维护一张“输出符号-中间符号”的二分图反复执行两条规则如果某个输出符号的度是1它连接的中间符号就可以直接被恢复然后这个中间符号从所有其它输出符号的邻居集合中移除同时把它的值异或进那些输出符号的值里如果某个输出符号的邻居集合变成空集说明它已经被完全消除不再参与后续计算。def raptor_decode(outputs, k, precode_matrix): LT译码 LDPC译码的两阶段BP k_prime precode_matrix.shape[1] # 第1阶段LT BP译码 recovered {} # 已恢复的中间符号索引 - 值 pending_outputs outputs.copy() t_hat [None] * k_prime # 初始化把所有度为1的输出符号找出来 changed True while changed: changed False for out in pending_outputs[:]: # 移除已被恢复的邻居 active_neighbors [n for n in out[neighbors] if n not in recovered] # 更新输出符号的值异或掉已知邻居的影响 for n in set(out[neighbors]) - set(active_neighbors): out[value] ^ recovered[n] out[neighbors] active_neighbors if len(active_neighbors) 1: n active_neighbors[0] if n not in recovered: recovered[n] out[value] t_hat[n] out[value] changed True pending_outputs.remove(out) # 如果LT层没有恢复全部中间符号进入LDPC层 missing [i for i in range(k_prime) if t_hat[i] is None] if missing: t_hat ldpc_recover(t_hat, precode_matrix, missing) # 取前k个作为原始符号 return t_hat[:k], t_hat def ldpc_recover(t_hat, H, missing_indices): # 把已知变量代入校验方程解出缺失变量 # 这是LDPC在擦除信道上的退化BP反复代入 changed True while changed and missing_indices: changed False for row in range(H.shape[0]): # 找出这个校验方程里还没恢复的中间符号 nonzeros [col for col in range(H.shape[1]) if H[row, col] 1] missing_here [col for col in nonzeros if col in missing_indices] known_here [col for col in nonzeros if col not in missing_indices] if len(known_here) len(nonzeros) - 1: # 只有一个未知量直接异或恢复 x 0 for col in known_here: x ^ t_hat[col] # 校验方程成立sum(all_vars) 0 missing_col missing_here[0] t_hat[missing_col] x missing_indices.remove(missing_col) changed True break return t_hat这段译码逻辑里需要解释三个关键点外循环的设计while changed 循环保证每次都重新扫描所有输出符号这在数据规模小的时候没问题但k到几千的时候会性能退化。更高效的实现是维护一个队列度为1的输出符号每次只更新一个然后只处理受影响的符号。工程实现里高性能Raptor译码器都会用队列结构这里为了可读性用了最直观的全扫描。LDPC恢复的逻辑ldpc_recover函数利用的是LDPC校验方程“所有参与的变量符号异或等于0”的性质。当某个校验方程里只剩一个未知变量时这个变量就等于所有已知变量的异或。这个过程在擦除信道上完全确定不存在误判概率。这也是为什么预编码用LDPC而不是LDPC的原始版本之一LDPC在擦除信道上的BP就是线性复杂度的高效消元器。两阶段衔接的微妙之处LT译码结束时会剩下若干个未恢复的中间符号。这些符号之所以没被恢复是因为在整个LT译码过程中它们参与的每一个输出符号都至少有两个缺失邻居。此时LDPC登场利用校验关系把它们“顺着方程解出来”。如果LDPC也不够那就说明要么预编码率太低保护不足要么总开销不够。4.4 仿真主循环与性能统计有了编码器和译码器最后的仿真主循环就比较简单了固定一个随机种子调整擦除概率p在每个p值下跑若干次实验统计恢复失败率。值得强调的是擦除信道上的Raptor码仿真有一个特殊指标叫“开销”overhead它定义是接收端实际收到的符号数除以k。越接近1说明越逼近理想喷泉码。仿真要画的曲线是“译码失败率 vs 开销”而不是传统意义上的“误码率 vs 信噪比”。import matplotlib.pyplot as plt def run_simulation(k, trials, max_overhead, erase_prob): k_prime k 4 # 预设中间符号数量预编码率约0.96 # 先构造LDPC矩阵 H generate_ldpc_matrix(k_prime, k, 12, 3) # 度分布 dist degree_distribution(k) failure_rates [] overheads np.linspace(1.0, max_overhead, 10) for overhead in overheads: num_symbols int(overhead * k) failures 0 for _ in range(trials): outputs, _ raptor_encode(k, H, dist) # 模拟擦除信道随机丢弃部分输出符号 received [out for out in outputs[:num_symbols] if np.random.rand() erase_prob] # 如果收到的符号数不够直接判失败 if len(received) k: failures 1 continue recovered, _ raptor_decode(received, k, H) # 检查是否与原始数据一致 if None in recovered or not np.array_equal(recovered, generate_original(k)): failures 1 failure_rates.append(failures / trials) plt.plot(overheads, failure_rates) plt.xlabel(Overhead (received symbols / k)) plt.ylabel(Decoding Failure Rate) plt.yscale(log) plt.show()这段主循环里有一个非常容易被忽略的问题generate_original函数必须在每次实验中重新生成原始数据且必须与raptor_encode内部随机生成的原始数据一致。这里的正确做法是修改raptor_encode让它接受原始数据作为参数而不是自己生成。否则你会看到一种极其诡异的现象接收端恢复出来的数据和发送端“自己的数据”永远对不上误码率高得离谱但代码看起来完全正确。另一个细节在received的筛选逻辑这里先按erase_prob判定输出符号是否被擦除又把num_symbols作为总发送量。这样设计其实包含了两个独立的变量总发送量受overhead控制和信道擦除率受erase_prob控制。很多仿真的失败分析在这里搅在一起到底是冗余不够导致失败还是擦除太严重导致失败正确做法是先固定erase_prob只看overhead如何影响失败率或者反过来固定overhead扫描擦除率。混在一起调两个变量性能曲线会非常难解读。5. 仿真结果验证与参数调优的三个实用技巧5.1 先固定随机种子把译码过程打印出来Raptor码的仿真在调试阶段最怕的就是“整个链路黑盒跑完只有一个失败率数字”。一旦失败率不理想你完全不知道是LDPC矩阵构造错了、度分布设计差了、还是译码逻辑写漏了某个边界条件。调试手段是加一个详细输出模式# 在raptor_decode循环里加入这行 if debug and len(active_neighbors) 1: print(fStep {step_count}: recover symbol {active_neighbors[0]} fvia output {out[id]}, degree{len(out[neighbors])})观察这个输出你能明确判断出三件事译码是否快速启动了前几步就要有大量度1符号被消耗、中间是否有阶段性的停滞这正常因为Raptor不是渐进式成功而是爆发式成功、结束时还剩多少中间符号没有恢复这个数字应该正好等于LDPC层设计要补的数量。如果结束时缺失数量比预编码冗余还多说明需要增加预编码率而不是无脑加大LT部分的符号数量。5.2 用“剩余未恢复符号数”代替“失败率”做参数搜索在调参阶段二进制式的“成功/失败”信息粒度太粗了。我一般会让译码器返回两个值恢复是否成功以及LT阶段结束后未恢复的中间符号数。这个“LT残差”是一个连续的调参信号度分布不合适时残差会猛然增大LDPC预编码率不合适时残差始终不变但LDPC恢复失败率上升。在这个信号的辅助下调参就变成了一个两个维度的最小化问题LT残差最小化决定度分布参数LDPC恢复失败率最小化决定预编码率。两个维度独立调节不要同时改。经验上度分布的影响远大于LDPC参数的影响所以先把度分布的c从0.1调成0.15、0.2看LT残差是否下降c超过0.3后残差基本不动了说明度分布已经走到了平台期再去调LDPC预编码率。5.3 对照理论下界检查你的开销是否合理这是一个最容易被跳过但非常有价值的验证手段。Raptor码在理想情况下接收端至少需要接收k个符号才能解码成功任何实际方案的“所需要的最小开销”都应该大于等于1。如果你的仿真显示出需要1.8甚至2.0k符号才能可靠恢复那么这个实现就存在明显的问题——不是度分布设计出了偏差就是LDPC预编码冗余过大。一个实用的检验标准是在BEC信道上擦除率p低于10%时Raptor码的开销中位数应该在1.05到1.15之间p升高到30%时开销中位数会跳到1.2到1.3。如果显著偏离这个区间优先怀疑LDPC层的码率是否设得太低——很多人为了追求保险把LDPC内部码率压到0.5以下结果每发一个输出符号里有一半以上都是校验开销整体性能自然上不去。把仿真跑稳定后你会发现Raptor码的调参路径其实是有方向感的LT层管效率LDPC层管兜底。真正的性能瓶颈往往出在算法实现细节上——邻居集合更新时的冗余操作、布尔运算写成了整型运算、随机数重复导致输出符号高度相关这些高频错误里只要命中一个整体失败率就能差出两个数量级。逐项排查干净后这个系统才能进入真实信道下的性能验证阶段。本文还有配套的精品资源点击获取 
长河君 · 2026/9/15 2:24:32 · 阅读 1.2k Raptor码与LDPC预编码：擦除信道下的Python仿真实现
简介面向无线通信、数据存储与网络传输等场景这份RaptorLDPC预编码仿真资源包提供了完整的MATLAB实现特别适合通信工程专业学生、研究人员以及希望深入理解喷泉码与无速率纠错编码的开发者。包体仅含6个文件并根据功能做了清晰划分3个m脚本文件承担Raptor编码、解码以及AWGN信道下的仿真主流程可直接运行并观察结果3个mat数据文件则保存了不同参数配置下的预编码矩阵、信道中间变量与仿真输出便于对比分析。整个压缩包只有20KB下载与调试都非常轻量。已有536人学习/下载足见其参考价值。借助这套程序用户能直观理解Raptor码如何在喷泉码基础上引入LDPC预编码来提升抗错误能力并可通过修改信息长度、编码率等参数研究误码率随信道条件的变化规律为无线传输、数据存储等场景下的编码方案优化提供可复现的仿真基础。1. Raptor码不是“另一个编码”而是把擦除问题拆开了做通信系统仿真的人第一次听到Raptor码通常是在讨论喷泉码fountain code的时候。我们习惯的RS码、LDPC码都有一个固定的码率——发多少冗余符号、能纠几个错在编码前就算死了。而Raptor码和所有喷泉码一样打破了这种“码率固定”的束缚编码器可以从k个原始符号里无限地生成输出符号接收端只要凑够比k略多一点的有效符号就能把原始数据恢复出来。这个性质让它在广播、深空通信、文件分发和存储系统里非常实用因为它天然适配了“信源不知道信道丢包率”的场景。这里有一个反直觉的结论Raptor码的性能很大一部分并不来自它的“喷泉”部分而是来自它的预编码——也就是标题里那个LDPC预编码。LDPC在这里不是单独作为一个纠错码在工作而是先把原始数据变成“更容易被喷泉编码覆盖”的中间符号。把预编码理解成给喷泉编码铺路就抓住了Raptor码的核心思路把讨厌的度分布设计与纠错能力拆分让每一层只干自己擅长的事。这种分层思想后来也被无线多址接入和网络编码大量借鉴。这篇博文从Raptor码的结构讲起落到LDPC预编码的选型理由和参数取值最后给你一套可以直接跑出BER曲线的Python仿真流程并把度分布参数、预编码率、开销overhead这些仿真时最常踩的坑讲清楚。适合正在做信道编码仿真、评估喷泉码在擦除信道和衰落信道上表现、或者需要给现有系统选型编码方案的工程师看。2. 从喷泉码到Raptor码为什么预编码让LT码脱胎换骨2.1 LT码的译码雪崩与“孤独符号”问题喷泉码的思想并不复杂。Luby在2002年提出的LT码是第一种实用的喷泉码它的编码方式非常直观每生成一个输出符号就从原始符号中随机抽取若干个做异或XOR抽取的个数叫这个输出符号的“度”degree。译码端收到足够多输出符号后先找一个度为1的符号直接恢复它对应的原始符号然后用这个恢复出的原始符号去消除其它输出符号中的未知量不断迭代下去。过程很像在解一个稀疏线性方程组。但LT码有一个致命伤就是小度符号的覆盖问题。为了保证度分布是平滑的编码端必须让一部分输出符号的度很小尤其要让度为1的符号数量足够多否则译码一开始就找不到切入点。但另一方面度为1的符号太多又会浪费喷泉码“少冗余就能恢复”的优势因为度1的符号携带的信息量很低。设计合适的度分布就成了LT码的瓶颈要在“启动可靠”和“整体效率”之间精确平衡。这个平衡一旦处理好LT码可以在开销很小的情况下恢复数据一旦处理不好就会出现译码雪崩——前半程进展正常后半程突然卡住因为没有度为1的符号可供下一步消除了。2.2 Raptor的结构预编码LT输出编码Raptor码的思路是“不把宝全押在度分布上”。Shokrollahi在2004年提出这个方案时核心想法非常简洁先用一个传统的纠错码通常是LDPC码对原始数据做一次预编码把k个原始符号扩展成k′个中间符号其中k′ k然后再对中间符号做LT编码生成最终要传输的输出符号。这里最关键的是预编码增加的少量冗余让LT译码结束后即使还有少量中间符号没有恢复LDPC预编码也能把它们补回来。这个结构带来的直接好处是LT部分的度分布不再需要那么担责。LT编码器即使产生一小部分“不可覆盖”的中间符号LDPC层也能当作一个轻量级擦除修正来处理堵住了LT码单独使用时最脆弱的环节。从信息论角度看Raptor把喷泉码的“通用性”和LDPC码的“逼近香农限的能力”拼接了起来LT管无限生成、LDPC管近完全恢复。这也是为什么后来的RaptorQ码依然沿用了这个结构只是把预编码部分换成了更优的矩阵设计。2.3 Raptor码与RS、LDPC的分工对比把Raptor码和传统编码放在一起比较能更清楚地看到它的设计取向。RS码是代数编码在擦除信道上有完美的MDS性质——接收任意k个符号就能解码但它的计算复杂度是O(k²)量级的k到几千以上就非常吃力。LDPC码是概率编码译码复杂度随码长线性增长性能逼近香农限但LDPC本身是固定码率的编码前就得确定信道丢包率丢包率估计错了纠错能力就差一大截。Raptor码属于“无码率”rateless编码它把码率变成了一个自适应参数。发送端不需要知道信道状态它可以一直发送输出符号直到接收端说“够了”。在丢包率未知、时变、或者一组接收端各不相同的场景里这种特性远比固定码率的LDPC码灵活。但在码长固定的场景里LDPC的性能通常会优于Raptor——这一点在做仿真对比时不要搞反了Raptor码的价值在“无码率可用性”和“无限扩展性”它不是在码长固定的赛道上和LDPC直接竞争的。提示在设计仿真对比实验时Raptor码要加上开销overhead维度来衡量性能而不是只比较固定码率下的误码率。固定码率下比较Raptor码大概率输给专用LDPC这不能说明它不好只是衡量维度选错了。3. 编码参数怎么设ldpc预编码率、度分布和中间符号数3.1 三个必调的参数及其作用域在动手写Raptor码仿真之前先要把三个核心参数的确定顺序和影响讲清楚。第一个是预编码率precoding rate也就是k和k′的比例。预编码率决定LDPC层能扛住多少个LT译码后残留的未恢复中间符号。预编码率越高越接近1.0LDPC层保护越强但总开销也越大。仿真中常见做法是取0.95到0.98也就是说每100个原始符号被预编码成102到105个中间符号。太强了浪费喷泉码的效率太弱了LT层的短板遮不住。第二个是度分布degree distribution。Raptor码最常用的度分布是Shokrollahi在Raptor论文里给出的鲁棒孤子分布Robust Soliton DistributionRSD的改进版或者直接使用标准Raptor码的度分布表。重要的一点是Raptor的度分布允许“牺牲”掉一小部分中间符号——就是说某些原始符号可能不直接出现在任何输出符号里反正LDPC层能补。所以Raptor用RSD时度分布参数可以设计得稍微“弱”一点省下开销。第三个是原始符号大小。这在仿真里通常被忽略但很关键Raptor码的符号大小影响有限域上的运算粒度和LDPC矩阵的构造。仿真里用1比特符号就够了但在实际系统里符号通常是一个字节或多个字节。3.2 LDPC预编码矩阵怎么构造LDPC预编码的矩阵构造是Raptor仿真的隐秘难点。很多人在仿真里用了随机矩阵结果性能差得离谱还以为是度分布出问题了。实际上Raptor码要求的LDPC矩阵必须满足两个条件一是行重列重比较均匀避免出现“孤立变量节点”导致有中间符号完全不受保护二是矩阵必须保证满秩否则预编码本身就丢了信息。在仿真里构造这个矩阵可以不用自己去实现完整的LDPC构造算法直接用下面的方式生成一个规则LDPC矩阵import numpy as np def generate_ldpc_matrix(n_intermediate, n_precode, d_c, d_v): # n_intermediate: 预编码后的中间符号总数 (k) # n_precode: 原始符号数 (k) # d_c: 校验节点度数 (每行1的个数) # d_v: 变量节点度数 (每列1的个数) assert n_intermediate * d_v n_precode * d_c # 用渐进边增长(PEG)算法思想构造避免短环 H np.zeros((n_precode, n_intermediate), dtypeint) # 第一轮按列均匀填充 col_degree np.zeros(n_intermediate) row_degree np.zeros(n_precode) # 这里用一个简化的均匀分布 避免列重过大 for col in range(n_intermediate): # 找出当前度数最小的行 candidates np.argsort(row_degree)[:d_v] for row in candidates: if H[row, col] 0 and row_degree[row] d_c: H[row, col] 1 row_degree[row] 1 col_degree[col] 1 # 保证列重均匀如果某些列没填够做二次分配 for col in range(n_intermediate): while col_degree[col] d_v: row np.argmin(row_degree) if H[row, col] 0: H[row, col] 1 row_degree[row] 1 col_degree[col] 1 return H这段代码的关键在于第一轮按列填充时优先选度数最小的行这保证了LDPC矩阵的行重不会出现“一根柱子扛十根梁”的极端情况第二轮是兜底防止某些列度不够。实际构造LDPC矩阵时PEG算法会复杂得多但这个简化版本在仿真场景下已经能提供足够的多样性。参数上d_c和d_v的选取直接对应了LDPC码率码率 1 - d_v / d_c。比如d_v 3、d_c 15码率就是1 - 3/15 0.8配合Raptor整体的k/k′ 0.96可以算出总冗余是相当可观的。3.3 一个可以直接套用的参数模板做参数设定时我一般建议先用一组已经验证过的保守参数起跑而不是上来就追求极致效率。下面的表格给了一组可以直接用于仿真初始跑的参数这组参数的出发点是保证“先能跑通、再看曲线形状”而不是最优配置。参数名取值说明原始符号数 k100小规模方便调试和打印中间状态中间符号数 k′104预编码率0.962LDPC层载荷较轻LDPC矩阵 d_v / d_c3 / 12码率0.75保护强度足度分布类型RSD 修正避免纯LT的高开销仿真信道BEC二元擦除信道先验证编码逻辑再换AWGN最大生成符号数2k防止无限循环同时覆盖开销变化这组参数对应的预编码率约0.96、LDPC内部码率0.75综合冗余系数大概是1.04 × 1.33 ≈ 1.38——也就是说接收端需要约1.38k个符号才能可靠恢复。这个冗余虽然比最优状态高出不少但好处是LDPC层的纠错余量很大LT层即便设计得粗糙一些也能可靠译码。跑通之后再逐步压低预编码率、调整度分布观察性能曲线的移动方向。4. 用Python在BEC信道上把Raptor码仿真跑起来4.1 整体流程与数据结构设计Raptor码的仿真链路相对清楚原始数据 → LDPC预编码 → LT编码 → BEC信道随机擦除符号 → LT译码 → LDPC译码 → 恢复数据。整条链路里需要维护的核心数据结构是三个原始符号数组precoded symbols、中间符号数组intermediate symbols和输出符号列表output symbols。这里有一个编码顺序上的细节LT编码器工作在中间符号上而不是直接工作在原始符号上。所以LT编码生成的每个输出符号本质上都关联了一个“邻居集合”——它异或了哪些中间符号。接收端要能译码必须知道每个输出符号的邻居列表这个信息在仿真里可以直接一并生成传输真实系统里通常通过双方共享的随机数种子来重构同一组邻居关系。4.2 编码器LDPC预编码 LT输出下面是编码端的核心代码import numpy as np def raptor_encode(k, precode_matrix, degree_dist): 输入: k个原始符号 (0/1向量长度为k) 输出: 无限生成的输出符号序列这里生成固定数量 # 第一步LDPC预编码 # 原始符号向量 s (s_0, s_1, ..., s_{k-1}) # 中间符号向量 t (s | p)其中p是校验符号 k_prime precode_matrix.shape[1] n_checks k_prime - k s np.random.randint(0, 2, k).astype(np.uint8) # 校验符号 p H_check * s (mod 2)从LDPC矩阵的右边分出系统部分 H_system precode_matrix[:, :k] H_parity precode_matrix[:, k:] p (H_system s) % 2 # 这里简化处理实际应求H_parity的逆 t np.concatenate([s, p]).astype(np.uint8) # 第二步LT编码生成输出符号 outputs [] for idx in range(200): # 最多生成200个实际可无限 # 从度分布中采样一个度 degree np.random.choice(len(degree_dist), pdegree_dist) degree max(degree, 1) # 度不能为0 # 随机选degree个中间符号 neighbors np.random.choice(k_prime, sizedegree, replaceFalse) # 异或出输出符号 x 0 for n in neighbors: x ^ t[n] outputs.append({ neighbors: neighbors.tolist(), value: int(x) }) return outputs, t def degree_distribution(k): # 简化的鲁棒孤子分布RSD c 0.1 # 常数项 delta 0.5 # 译码失败概率指标 R c * np.log(k / delta) * np.sqrt(k) dist np.zeros(k 1) for d in range(1, k 1): if d 1: rho 1.0 / k else: rho 1.0 / (d * (d - 1)) # 加上孤子分布的修正项 if 1 d k / R: tau R / (d * k) elif d int(k / R): tau R * np.log(R) / k else: tau 0 dist[d] rho tau return dist / dist.sum()这段代码里最容易出错的地方在第12行的H_system s矩阵乘法在numpy里默认是整数乘法不是模2的异或和。所以必须补% 2。更严谨的写法是把所有运算都限制在GF(2)域上使用位运算或者把矩阵和向量都转成布尔型再取逻辑异或。仿真中不在意性能的话直接% 2是最精简的写法。度分布的设计在degree_distribution函数里。RSD的实际构造要比这段代码复杂但核心公式是对的标准孤子分布rho项保证译码启动和推进修正项tau项保证小度符号有一定的兜底数量。c和delta两个参数里c控制RSD的峰值位置通常取0.05到0.2之间delta是允许的译码失败概率工程上取0.5即可因为Raptor码后面还有LDPC兜底不需要LT层真的做到“极低失败率”。4.3 译码器置信传播BP在擦除信道上如何工作Raptor码在BEC信道上的译码就是经典的置信传播Belief Propagation算法的退化形式——在擦除信道上BP算法退化成一种确定性消元过程不需要计算概率只需要做异或。核心思想是维护一张“输出符号-中间符号”的二分图反复执行两条规则如果某个输出符号的度是1它连接的中间符号就可以直接被恢复然后这个中间符号从所有其它输出符号的邻居集合中移除同时把它的值异或进那些输出符号的值里如果某个输出符号的邻居集合变成空集说明它已经被完全消除不再参与后续计算。def raptor_decode(outputs, k, precode_matrix): LT译码 LDPC译码的两阶段BP k_prime precode_matrix.shape[1] # 第1阶段LT BP译码 recovered {} # 已恢复的中间符号索引 - 值 pending_outputs outputs.copy() t_hat [None] * k_prime # 初始化把所有度为1的输出符号找出来 changed True while changed: changed False for out in pending_outputs[:]: # 移除已被恢复的邻居 active_neighbors [n for n in out[neighbors] if n not in recovered] # 更新输出符号的值异或掉已知邻居的影响 for n in set(out[neighbors]) - set(active_neighbors): out[value] ^ recovered[n] out[neighbors] active_neighbors if len(active_neighbors) 1: n active_neighbors[0] if n not in recovered: recovered[n] out[value] t_hat[n] out[value] changed True pending_outputs.remove(out) # 如果LT层没有恢复全部中间符号进入LDPC层 missing [i for i in range(k_prime) if t_hat[i] is None] if missing: t_hat ldpc_recover(t_hat, precode_matrix, missing) # 取前k个作为原始符号 return t_hat[:k], t_hat def ldpc_recover(t_hat, H, missing_indices): # 把已知变量代入校验方程解出缺失变量 # 这是LDPC在擦除信道上的退化BP反复代入 changed True while changed and missing_indices: changed False for row in range(H.shape[0]): # 找出这个校验方程里还没恢复的中间符号 nonzeros [col for col in range(H.shape[1]) if H[row, col] 1] missing_here [col for col in nonzeros if col in missing_indices] known_here [col for col in nonzeros if col not in missing_indices] if len(known_here) len(nonzeros) - 1: # 只有一个未知量直接异或恢复 x 0 for col in known_here: x ^ t_hat[col] # 校验方程成立sum(all_vars) 0 missing_col missing_here[0] t_hat[missing_col] x missing_indices.remove(missing_col) changed True break return t_hat这段译码逻辑里需要解释三个关键点外循环的设计while changed 循环保证每次都重新扫描所有输出符号这在数据规模小的时候没问题但k到几千的时候会性能退化。更高效的实现是维护一个队列度为1的输出符号每次只更新一个然后只处理受影响的符号。工程实现里高性能Raptor译码器都会用队列结构这里为了可读性用了最直观的全扫描。LDPC恢复的逻辑ldpc_recover函数利用的是LDPC校验方程“所有参与的变量符号异或等于0”的性质。当某个校验方程里只剩一个未知变量时这个变量就等于所有已知变量的异或。这个过程在擦除信道上完全确定不存在误判概率。这也是为什么预编码用LDPC而不是LDPC的原始版本之一LDPC在擦除信道上的BP就是线性复杂度的高效消元器。两阶段衔接的微妙之处LT译码结束时会剩下若干个未恢复的中间符号。这些符号之所以没被恢复是因为在整个LT译码过程中它们参与的每一个输出符号都至少有两个缺失邻居。此时LDPC登场利用校验关系把它们“顺着方程解出来”。如果LDPC也不够那就说明要么预编码率太低保护不足要么总开销不够。4.4 仿真主循环与性能统计有了编码器和译码器最后的仿真主循环就比较简单了固定一个随机种子调整擦除概率p在每个p值下跑若干次实验统计恢复失败率。值得强调的是擦除信道上的Raptor码仿真有一个特殊指标叫“开销”overhead它定义是接收端实际收到的符号数除以k。越接近1说明越逼近理想喷泉码。仿真要画的曲线是“译码失败率 vs 开销”而不是传统意义上的“误码率 vs 信噪比”。import matplotlib.pyplot as plt def run_simulation(k, trials, max_overhead, erase_prob): k_prime k 4 # 预设中间符号数量预编码率约0.96 # 先构造LDPC矩阵 H generate_ldpc_matrix(k_prime, k, 12, 3) # 度分布 dist degree_distribution(k) failure_rates [] overheads np.linspace(1.0, max_overhead, 10) for overhead in overheads: num_symbols int(overhead * k) failures 0 for _ in range(trials): outputs, _ raptor_encode(k, H, dist) # 模拟擦除信道随机丢弃部分输出符号 received [out for out in outputs[:num_symbols] if np.random.rand() erase_prob] # 如果收到的符号数不够直接判失败 if len(received) k: failures 1 continue recovered, _ raptor_decode(received, k, H) # 检查是否与原始数据一致 if None in recovered or not np.array_equal(recovered, generate_original(k)): failures 1 failure_rates.append(failures / trials) plt.plot(overheads, failure_rates) plt.xlabel(Overhead (received symbols / k)) plt.ylabel(Decoding Failure Rate) plt.yscale(log) plt.show()这段主循环里有一个非常容易被忽略的问题generate_original函数必须在每次实验中重新生成原始数据且必须与raptor_encode内部随机生成的原始数据一致。这里的正确做法是修改raptor_encode让它接受原始数据作为参数而不是自己生成。否则你会看到一种极其诡异的现象接收端恢复出来的数据和发送端“自己的数据”永远对不上误码率高得离谱但代码看起来完全正确。另一个细节在received的筛选逻辑这里先按erase_prob判定输出符号是否被擦除又把num_symbols作为总发送量。这样设计其实包含了两个独立的变量总发送量受overhead控制和信道擦除率受erase_prob控制。很多仿真的失败分析在这里搅在一起到底是冗余不够导致失败还是擦除太严重导致失败正确做法是先固定erase_prob只看overhead如何影响失败率或者反过来固定overhead扫描擦除率。混在一起调两个变量性能曲线会非常难解读。5. 仿真结果验证与参数调优的三个实用技巧5.1 先固定随机种子把译码过程打印出来Raptor码的仿真在调试阶段最怕的就是“整个链路黑盒跑完只有一个失败率数字”。一旦失败率不理想你完全不知道是LDPC矩阵构造错了、度分布设计差了、还是译码逻辑写漏了某个边界条件。调试手段是加一个详细输出模式# 在raptor_decode循环里加入这行 if debug and len(active_neighbors) 1: print(fStep {step_count}: recover symbol {active_neighbors[0]} fvia output {out[id]}, degree{len(out[neighbors])})观察这个输出你能明确判断出三件事译码是否快速启动了前几步就要有大量度1符号被消耗、中间是否有阶段性的停滞这正常因为Raptor不是渐进式成功而是爆发式成功、结束时还剩多少中间符号没有恢复这个数字应该正好等于LDPC层设计要补的数量。如果结束时缺失数量比预编码冗余还多说明需要增加预编码率而不是无脑加大LT部分的符号数量。5.2 用“剩余未恢复符号数”代替“失败率”做参数搜索在调参阶段二进制式的“成功/失败”信息粒度太粗了。我一般会让译码器返回两个值恢复是否成功以及LT阶段结束后未恢复的中间符号数。这个“LT残差”是一个连续的调参信号度分布不合适时残差会猛然增大LDPC预编码率不合适时残差始终不变但LDPC恢复失败率上升。在这个信号的辅助下调参就变成了一个两个维度的最小化问题LT残差最小化决定度分布参数LDPC恢复失败率最小化决定预编码率。两个维度独立调节不要同时改。经验上度分布的影响远大于LDPC参数的影响所以先把度分布的c从0.1调成0.15、0.2看LT残差是否下降c超过0.3后残差基本不动了说明度分布已经走到了平台期再去调LDPC预编码率。5.3 对照理论下界检查你的开销是否合理这是一个最容易被跳过但非常有价值的验证手段。Raptor码在理想情况下接收端至少需要接收k个符号才能解码成功任何实际方案的“所需要的最小开销”都应该大于等于1。如果你的仿真显示出需要1.8甚至2.0k符号才能可靠恢复那么这个实现就存在明显的问题——不是度分布设计出了偏差就是LDPC预编码冗余过大。一个实用的检验标准是在BEC信道上擦除率p低于10%时Raptor码的开销中位数应该在1.05到1.15之间p升高到30%时开销中位数会跳到1.2到1.3。如果显著偏离这个区间优先怀疑LDPC层的码率是否设得太低——很多人为了追求保险把LDPC内部码率压到0.5以下结果每发一个输出符号里有一半以上都是校验开销整体性能自然上不去。把仿真跑稳定后你会发现Raptor码的调参路径其实是有方向感的LT层管效率LDPC层管兜底。真正的性能瓶颈往往出在算法实现细节上——邻居集合更新时的冗余操作、布尔运算写成了整型运算、随机数重复导致输出符号高度相关这些高频错误里只要命中一个整体失败率就能差出两个数量级。逐项排查干净后这个系统才能进入真实信道下的性能验证阶段。本文还有配套的精品资源点击获取