模拟喷泉码这个词第一次摆在面前的人往往会先愣一下——喷泉码不是数字域里那套LT、Raptor的东西吗怎么还有“模拟”的而“自适应模拟喷泉码在无线信道中的应用”这个题目把三个信息量很大的词堆在了一起模拟喷泉码、自适应、无线信道。说白了它讨论的是一类不走传统“先信道编码再调制”串行路线的无速率传输方案编码符号不再是0/1比特而是一个可以直接叠加到载波上的实数值收端收到多少个符号就译多少收得越多译得越准中间不需要精确的握手和码率协商。这类方案特别适合链路质量抖动剧烈、包长又短的场景比如低功耗广域物联网、短报文卫星链路、水声通信、车联网的侧链路广播。如果你正在做基带链路仿真、想找一个比固定码率LDPC更“随遇而安”的编码结构或者你只是好奇“实数编码符号”到底怎么译码、怎么评估那这篇内容应该能给你一些直接能抄的东西。下面我按自己搭仿真时的思路从设计动机、结构拆解、实操步骤到踩过的坑完整走一遍。1. 为什么无线链路上要重新捡起喷泉码这套思路1.1 数字喷泉码在无线链路里的三个尴尬数字喷泉码的理论很漂亮发射端源源不断吐编码包接收端收够了就停理论上不需要反馈天然适配组播和信道条件未知的场景。但真把它丢进无线链路问题马上就来了。第一个尴尬是“停止时刻”的判断。LT码和Raptor码要译码成功需要一个可判定的完成条件工程上几乎都靠外挂CRC或者反馈ACK。这个反馈在无线链路上是有延迟的链路越差、往返时间越长你多发的那部分冗余就越多频谱效率的损失直接体现在吞吐上。第二个尴尬是码率的颗粒度。喷泉码号称无速率但实际译码需要“整个符号”到位收端要么译出来、要么没译出来中间没有软信息可以利用。在低信噪比区数字喷泉码的译码器拿到的是硬判决或者不太可靠的软信息性能曲线会在某个点上突然“断崖”而不是平滑地劣化。第三个尴尬是分离定理的失效。有限码长下把信道编码和调制分开设计、分成两级优化的做法本来就有性能损失而在时变信道里这个损失会被放大因为编码器根本不知道当前这一帧会经历什么样的衰落。我自己在做短包仿真时对这个感受很深包长从几千比特压到几百比特固定码率的LDPC和Turbo的编码增益掉得厉害而喷泉类方案又受限于反馈开销和硬判决损失两边都不讨好。模拟喷泉码恰恰是从这个夹缝里长出来的方案——它把“编码符号”从离散字母表搬到实数域让软信息从编码阶段就一路带着走同时保留了无速率的骨架。提示不要把模拟喷泉码理解成“模拟信号的喷泉码”。它仍然是离散时间、离散信息的编码只是编码输出取连续实数值信道是AWGN噪声是加性的。这个区别在建模时一定要拎清楚否则仿真里信噪比的定义会写错。1.2 模拟喷泉码的核心转变让编码符号变成实数模拟喷泉码的基本构造其实非常朴素。假设有N个信息符号取值是BPSK的±1也可以推广到高阶星座第m个编码符号这样生成先按某个度分布随机挑出d个信息符号再给每个被选中的符号配一个权重最后把所有加权项加起来。写成式子就是 y_m 等于权重乘以对应信息符号的累加和接收端看到的是这个和再加上高斯噪声。因为权重是实数、信息符号也是实数编码输出自然就是实数可以直接送进调制器不需要再做星座映射这一步。这个结构带来两个直接好处。第一译码可以全程在实数域做置信传播消息是高斯分布的均值和方差而不是离散的LLR表软信息没有被量化损失掉。第二码率是连续可调的。你多发一个符号接收端就多一条线性方程信息量就多一点点不存在“多发一个包浪费一整个包”的问题。用生活化的比喻数字喷泉码像是往杯子里倒水一次倒一杯倒多了溢出来模拟喷泉码像是用滴管滴水滴多少是多少杯子满了就停。当然代价也是有的。实数域BP的复杂度比二进制BP高每个校验节点的消息更新都要算方差权重集的选择会直接影响性能上界权重选大了噪声被放大选小了方程之间的区分度不够另外随机图构造必然带来短环短环会让BP的消息在几个节点之间空转收敛变慢甚至不收敛。这些问题在后面几节会逐个拆。2. 自适应模拟喷泉码的整体设计拆解2.1 生成矩阵一次编码在物理层到底做了什么把上面那个构造用矩阵写出来就是 y Gx n其中x是N维信息向量y是M维接收向量G是M×N的稀疏矩阵每一行只有d个非零元位置随机、取值来自权重集W。这个形式和压缩感知里的观测矩阵非常像但两者的问题设定正好相反压缩感知是M远小于N、要求x稀疏模拟喷泉码是M略大于N、x是稠密的稀疏性在图结构上而不在信号上。这个类比很有用因为压缩感知里成熟的BP、AMP、OMP一类算法基本都能平移过来做译码只是要按过定系统调整迭代停止条件和先验。从物理层角度看G的每一行代表“一次线性叠加”在模拟域实现就是一组加权求和。如果权重取整数比如1、2、3那这一行在硬件上就是几个支路的增益相加用开关电容或者电阻网络都能做代价极低。这也是这类方案在实际系统里比较有吸引力的原因之一——它的编码器不是一个复杂的状态机而是一个可配置的加权求和网络甚至可以把权重固定下来只随机化连接关系。相比LDPC那种需要大规模并行走线的结构模拟喷泉码的编码端实现难度低不少。不过这里有个容易忽略的细节G的随机化程度决定了性能的下界。如果连接关系是伪随机的且种子固定那么同一个码字在不同帧之间会重复出现短环某些信息符号可能长期被少数几个校验节点覆盖导致译码时的置信度分布严重不均。我的做法是每帧重新抽取连接关系把种子和帧号绑定如果帧长固定、要求确定的图结构那就要在设计阶段做一次离线搜索把包含4环的行挑出来重抽。2.2 权重集与度分布两个必须一起调的旋钮权重集W是模拟喷泉码独有的设计自由度。数字喷泉码没有这个概念每个编码包就是若干个信息包的异或等价于权重恒为1。一旦权重可以取不同的值问题就变成了“怎么选一组数让线性方程组既好解、又不放大噪声”。这里有个直观的权衡权重越大不同行之间的“区分度”越高G的条件数越好但校验节点更新时噪声方差会按照权重的平方被放大等效信噪比下降。极端情况下如果权重取到10那这一行的观测就基本是噪声了。实践中比较常见的做法是取小整数集合比如{1, 2, 3}或者{1, 2, 4}让权重的动态范围控制在两三倍以内。另一个思路是取正负对称的集合比如{±1, ±2}这样每一行的和值分布更接近零均值对BP的初始消息更友好。我在仿真里对比过这两类正负对称的集合在低信噪比区收敛更快但在高信噪比区优势不明显反而因为负权重的存在让部分硬件实现变复杂。如果你的场景是纯软件仿真或者数字域的等效实现倾向选对称集如果奔着低功耗硬件去老老实实用正整数集。度分布和权重集必须联合优化不能分开调。度分布决定了每个编码符号连接多少个信息符号平均度太低会导致译码的“涟漪”起不来BP在第一步就卡死平均度太高会让每一行的计算量暴涨而且外信息的方差累积过快置信度的动态范围被压缩。经验上平均度落在8到14之间比较稳妥短码N在几百量级可以往低了取长码可以往高了取因为长码的环更分散。2.3 自适应到底适应的是什么这个词是全篇最容易被误解的。自适应在模拟喷泉码的语境下通常有两个层次要分清。第一个层次是符号级自适应发射端知道当前信道的瞬时质量比如通过导频估计出的信噪比据此调整每个编码符号的发射功率或者有效权重。信道好的时候加大权重、提高单符号的信息承载量信道差的时候把权重压小保证观测的可靠性。这个层次的自适应本质上是把功率控制和编码设计揉在了一起。第二个层次是码级自适应也就是根据信道状态选择不同的度分布和权重集。因为模拟喷泉码的等效码率是连续可调的理论上你在任意信噪比下都能找到一组参数让吞吐逼近容量。工程上的做法是离线跑一组信噪比点每个点用差分进化或者密度进化优化出一套度分布做成本地表运行时根据估计的信噪比查表切换。这个思路和LDPC的codebook切换是一样的只是模拟喷泉码切换的是分布参数而不是整个校验矩阵表小得多。还有第三种更“野”的理解就是完全不做显式自适应靠无速率特性自然适配。收端不问发端要多少收到多少算多少译不出来就继续收。这种做法在单向广播或者反馈极贵的场景里非常实用代价是收端要承受一定的过收冗余通常比理想自适应多花20%到40%的符号。我个人倾向于把这个叫“被动自适应”它和前面两个层次并不冲突可以叠加使用。3. 从零搭一套仿真编码端、信道、译码端3.1 参数怎么定先算清楚再动手动手写代码之前先把几个量算清楚否则跑出来的曲线你根本不知道问题出在哪。信息符号数N先定下来短包场景取256或者512中等包长取1024验证长码性能取4096以上。过收比例overhead定义为(M-N)/N这个值在模拟喷泉码里通常比数字喷泉码低因为实数观测携带的信息量更大1e-3误码率下大概20%到30%就够具体取决于度分布和信噪比。然后是复杂度核算。编码端每个符号需要d_avg次乘加M个符号就是M乘d_avg次运算。取N1024、d_avg10、overhead25%则M1280编码端约1.3万次乘加每帧。假设符号率是1兆符号每秒每帧1280个符号占1.28毫秒那编码端算力需求约每秒1000万次乘加一颗中低端MCU都能扛住。译码端是迭代的复杂度是迭代次数乘以M乘以d_avg再乘以一个常数取迭代50次就是每秒5亿次量级这时候就得考虑用向量化或者定点实现了。这个账一定要提前算不然仿真跑到一半发现一帧要跑十秒参数就没法扫了。参数短包场景中等包长长码验证说明信息符号数 N25610244096BPSK取值±1平均度 d_avg81012与N成正相关过收比例30%25%20%低信噪比区适当放宽BP最大迭代6080100配合早停使用目标误码率1e-31e-41e-5决定统计帧数信噪比的定义要特别小心。因为编码输出是实数加权和它的平均功率不等于1所以Eb/N0不能直接套用BPSK的公式。正确的做法是先算编码符号的方差对每一行求权重平方和再对度分布取期望得到平均符号能量E_s再用E_s/N0换算。如果这一步算错了整条曲线会平移好几dB白跑。3.2 编码端实现与稀疏结构存储编码端的核心是把图结构建好。不要用稠密矩阵N到4096的时候M×N就是五百多万个浮点数内存和乘法都吃不消。用行列表的形式存储每行记一个索引数组和一个权重数组这是最省事也最快的。import numpy as np def sample_degree(omega, rng): ds np.array(list(omega.keys())) ps np.array(list(omega.values()), dtypefloat) ps ps / ps.sum() return int(rng.choice(ds, pps)) def build_graph(N, M, omega, W, seed0): rng np.random.default_rng(seed) rows [] for _ in range(M): d sample_degree(omega, rng) idx rng.choice(N, sized, replaceFalse) w rng.choice(W, sized, replaceTrue) rows.append((idx, w.astype(float))) return rows def encode(u, rows): y np.empty(len(rows)) for m, (idx, w) in enumerate(rows): y[m] w u[idx] return y这段代码有两个可以立刻改进的点。第一rng.choice在N很大时是O(N)的跑几万帧会明显拖慢可以换成先用permutation取前d个或者用一个洗牌池维护。第二同一行里允许重复权重是必要的否则度高的行权重组合数不够但要注意别让同一行出现同一个索引两次那等于把某个符号的权重翻倍会引入隐式的确定性。我一般还会在构完图之后做一次4环检测把有4环的行重抽短码下这一招能省下0.3到0.5dB。信道部分就是标准的AWGNy_rx y np.sqrt(sigma2) * rng.standard_normal(M)。sigma2按前面算的平均符号能量来定。如果要加衰落就在每个符号上乘一个瑞利或者莱斯系数注意这时候接收端要拿到相干检测后的等效模型否则BP的消息更新公式要重写。3.3 实数域BP译码的实现细节译码是整套方案里最需要小心的地方。二进制BP里的消息是LLR是一维的实数域BP里的消息是高斯分布要同时传均值和方差所以每条边上要存两个数。校验节点的更新逻辑是对第m行已知y_m约等于该行所有变量贡献之和加噪声那么要对第k条边给出关于x_k的估计就用y_m减去其他所有边的贡献再除以权重w_k方差相应传播。def bp_decode(y, rows, N, sigma2, max_iter80, tol1e-6): M len(rows) # 每条边上的消息mean 和 var m2v_mean [[0.0] * len(r[0]) for r in rows] m2v_var [[1e6] * len(r[0]) for r in rows] v2c_mean [[0.0] * len(r[0]) for r in rows] v2c_var [[1e6] * len(r[0]) for r in rows] # 变量节点 - 校验节点的边索引表 var_edges [[] for _ in range(N)] for m, (idx, _) in enumerate(rows): for k, j in enumerate(idx): var_edges[j].append((m, k)) xhat np.zeros(N) for it in range(max_iter): # 第一步变量节点合并外信息精度加权平均 post_mean np.zeros(N) post_var np.zeros(N) for j in range(N): num, den 0.0, 0.0 for (m, k) in var_edges[j]: p 1.0 / (m2v_var[m][k] 1e-12) num m2v_mean[m][k] * p den p if den 0: post_mean[j], post_var[j] 0.0, 1e6 continue post_mean[j] num / den post_var[j] 1.0 / den for (m, k) in var_edges[j]: p 1.0 / (m2v_var[m][k] 1e-12) d_ den - p if d_ 1e-12: v2c_mean[m][k], v2c_var[m][k] 0.0, 1e6 else: v2c_mean[m][k] (num - m2v_mean[m][k] * p) / d_ v2c_var[m][k] 1.0 / d_ # 第二步校验节点消去其他边的贡献 for m, (idx, w) in enumerate(rows): cm [w[k] * v2c_mean[m][k] for k in range(len(idx))] cv [(w[k] ** 2) * v2c_var[m][k] for k in range(len(idx))] sm, sv sum(cm), sum(cv) for k in range(len(idx)): m2v_mean[m][k] (y[m] - (sm - cm[k])) / (w[k] 1e-12) m2v_var[m][k] (sigma2 (sv - cv[k])) / (w[k] ** 2 1e-12) xhat np.where(post_mean 0, 1.0, -1.0) # 早停重编码残差小于门限 resid 0.0 for m, (idx, w) in enumerate(rows): resid (y[m] - w xhat[idx]) ** 2 if resid 3.0 * len(rows) * sigma2: break return xhat, it, resid这段代码里有两个点值得单独说。第一个是早停条件。模拟喷泉码没有CRC怎么知道译对了用重编码残差把硬判决结果代回编码方程算一遍残差应该接近噪声功率乘以M。我用的门限是3倍的期望残差实测在1e-3误块率附近比较稳门限设太小会误判明明译对了但残差偏大设太大则会放过错误帧。这个门限最好按你的目标误块率扫一遍定下来不要照搬。第二个是方差的初值。流程图里通常写“初始化为无穷大”实际代码里必须给一个有限的大数因为后面要做倒数。这个初值不能太小否则第一轮变量节点的置信度就是错的也不能太大太大反而会在倒数的时候数值下溢。我的经验是按照信道方差乘以十的数量级来给比较稳。3.4 结果曲线怎么读、怎么判断方案的好坏跑完仿真至少要看三条曲线只看BER是不够的。第一条是BER随Eb/N0的变化用来判断方案的编码增益同时要叠一条理想的二进制LDPC或者香农限做参照不然你不知道自己离理论还有多远。第二条是吞吐随信噪比的曲线吞吐要按“成功译出的信息比特数除以实际消耗的符号时间”来算过收冗余要计进去这才是工程上有意义的指标。第三条是平均迭代次数随信噪比的变化这条曲线能告诉你自适应切换点应该放在哪也能暴露BP的病态问题。读曲线的时候有个经验模拟喷泉码的BER曲线在低信噪比区往往比较陡然后在高信噪比区出现一个“拖尾平台”。拖尾一般是两类原因造成的一是度分布里高度的行太多噪声被权重平方放大形成误差底二是图里有顽固的短环某些变量节点长期收不到有效外信息。前者靠调权重集和截断度分布解决后者靠重新构图或者加交织。这个平台的判断很重要如果你的目标误码率是1e-5而平台在1e-4那整个方案就是不可用的必须回头改设计。4. 调参与排错实录那些跑不出曲线的坑4.1 译码不收敛的四类原因第一类图结构问题。最简单的表现是迭代到最大次数重编码残差还在噪声功率的十倍以上BER停在0.1左右不动。这种大概率是图里有变量节点完全没被任何一行覆盖或者覆盖次数只有一次BP给它传的外信息始终是先验等于这个符号永远解不出来。排查办法是统计每个变量节点的连接度最小度必须是2以上出现0或者1就立刻重构图。这个检查我一般写成断言构图后立刻跑一遍。第二类是方差传播发散。表现是迭代到二三十轮之后某些边的方差变成NaN或者负值。根源是校验节点更新里的除法当权重很小或者减去其他贡献后余量接近零的时候会爆掉。前面代码里加的1e-12只是在掩耳盗铃真正稳妥的做法是在校验节点更新前做一次下限截断把方差限制在sigma2的百分之一以上把均值的绝对值限制在一个合理区间。这个截断不会改变收敛点只是防止数值炸掉。第三类是信噪比失配。接收端估的sigma2和实际噪声方差差了3dB以上LLR的尺度就全错了。好消息是实数域BP对尺度误差有一定容忍度只要不是差一个数量级通常只影响收敛速度不影响最终BER坏消息是如果差得太多置信度的相对权重大乱会直接把某些正确的符号推翻。调试时把真实的sigma2喂进去对比一下如果曲线立刻好了5dB那就说明你的噪声估计模块有问题。第四类其实是思路问题不是bug度分布和信噪比不匹配。低信噪比下用了高平均度的分布每一行的噪声被放大得太厉害高信噪比下用了低平均度的分布方程数量不够过收比例再高也补不回来。这个不是改代码能解决的得重新优化分布。我一般会在三四个典型信噪比点各跑一次密度进化做成本地表运行时根据估计信噪比选最近的表项。4.2 权重集和度分布的调参经验权重集的经验前面提了一部分这里补充几条实操的。第一权重集里不要出现互为整数倍的元素比如{1,2,4}看起来没问题但2和4的组合等价于把两个1和一个2做替换会让不同行之间出现隐式的线性相关BP在迭代后期会在这几行之间振荡。我吃过这个亏把4换成3之后拖尾平台直接掉了半个数量级。第二权重的个数不用太多三到四个足够多了意义不大还增加硬件配置复杂度。第三如果要做不等错误保护可以把重要的信息符号分配到高权重的边上这是一个很自然的扩展不需要额外的编码结构。度分布方面别迷信教科书上的鲁棒孤波分布。那是为理想的数字喷泉码设计的搬到模拟域性能会差一截。原因是鲁棒孤波分布的形状是为了保证涟漪不中断而模拟域的约束条件多了权重的噪声放大和实数观测的信息量最优点会明显右移。我自己的做法是用一个参数化的分布族比如以两个峰值位置和一个衰减指数为参数然后用差分进化在目标信噪比下优化误块率迭代五十代左右就能收敛到比教科书分布好1dB以上的结果。这个过程很耗算力但只做一次做完存表。注意优化度分布时目标函数要选误块率或者吞吐不要选误码率。误码率对分布不敏感容易优化到一个看起来很好但实际用不了的点。另外优化时的帧数要够至少统计到两百个错误帧否则优化结果会被噪声带着跑。4.3 常见问题速查表现象大概率原因处理方式BER卡在0.1不动存在度为0或1的变量节点构图后加最小度断言重抽迭代后期出现NaN校验节点更新除零或方差溢出方差下限截断、均值范围截断高信噪比出现拖尾平台权重集有整数倍关系或度高行过多换权重集、截断度分布上界曲线整体左移好几dB平均符号能量算错Eb/N0定义不对重算E_s按权重平方和期望换算低信噪比完全无法启动平均度太低初始涟漪不足提高d_avg到10以上单帧运行时间过长稠密矩阵存储、无早停改行列表存储加重编码残差早停收敛慢但最终BER正常短环多方差更新保守4环检测重抽适度提高迭代上限帧间性能波动大随机图种子未随帧变化把种子和帧号绑定5. 落地场景与后续可以扩展的方向5.1 这套方案真正适合的三类场景第一类是反馈昂贵或者干脆没有反馈的单向链路。广播、卫星下行、水声这类链路的共同点是往返时间远超帧长等反馈回来信道早就变了。模拟喷泉码的被动自适应特性正好补上这个缺口收端自己决定什么时候停发端只管按固定速率吐符号。第二类是短包、低时延场景。传统方案在短包下编码增益损失严重而模拟喷泉码的结构简单、没有长交织、没有复杂的打孔译码的启动延迟就是一个符号的时间。工业无线控制、车联网的周期性状态广播都符合这个画像。第三类是信道质量动态范围特别大的链路。因为码率连续可调它在信噪比大范围波动时不需要频繁切换编码方案一个码字应付全程避免了切换带来的同步和信令开销。这一点在低轨卫星这类多普勒和仰角变化剧烈的场景里很有价值。5.2 工程上还能往哪扩往硬件方向走最直接的想法是把权重固定成小整数用开关电容阵列实现加权求和编码器可以做成纯无源的。这个思路在超低功耗的传感节点上很有吸引力因为编码阶段几乎不耗动态功耗。往算法方向走可以把BP换成近似消息传递在观测矩阵接近高斯独立同分布时收敛更快代价是对图结构的随机性要求更高。另一个值得试的方向是把模拟喷泉码和稀疏码多址结合起来做联合设计。多址场景下多个用户同时发接收端看到的叠加信号天然就是多个编码符号的和这个结构跟模拟喷泉码的线性叠加非常契合有希望把多用户检测和信道译码做成一个整体。这个想法我自己只跑过初步的仿真多用户之间的功率不平衡处理起来比单用户复杂得多还没到能给出结论的程度。我在实际搭这套仿真的过程中最深的一个体会是模拟喷泉码的性能上限八成取决于图结构和度分布这两件事译码算法本身的改进空间反而有限。很多人一开始就想去折腾更高级的译码器其实把4环清干净、把平均度调到合适的区间收益比换算法大得多。另外一点别急着上长码先用N等于256把整条链路跑通把残差早停的门限定下来再去扩到1024和4096能省掉大量返工。
模拟喷泉码这个词第一次摆在面前的人往往会先愣一下——喷泉码不是数字域里那套LT、Raptor的东西吗怎么还有“模拟”的而“自适应模拟喷泉码在无线信道中的应用”这个题目把三个信息量很大的词堆在了一起模拟喷泉码、自适应、无线信道。说白了它讨论的是一类不走传统“先信道编码再调制”串行路线的无速率传输方案编码符号不再是0/1比特而是一个可以直接叠加到载波上的实数值收端收到多少个符号就译多少收得越多译得越准中间不需要精确的握手和码率协商。这类方案特别适合链路质量抖动剧烈、包长又短的场景比如低功耗广域物联网、短报文卫星链路、水声通信、车联网的侧链路广播。如果你正在做基带链路仿真、想找一个比固定码率LDPC更“随遇而安”的编码结构或者你只是好奇“实数编码符号”到底怎么译码、怎么评估那这篇内容应该能给你一些直接能抄的东西。下面我按自己搭仿真时的思路从设计动机、结构拆解、实操步骤到踩过的坑完整走一遍。1. 为什么无线链路上要重新捡起喷泉码这套思路1.1 数字喷泉码在无线链路里的三个尴尬数字喷泉码的理论很漂亮发射端源源不断吐编码包接收端收够了就停理论上不需要反馈天然适配组播和信道条件未知的场景。但真把它丢进无线链路问题马上就来了。第一个尴尬是“停止时刻”的判断。LT码和Raptor码要译码成功需要一个可判定的完成条件工程上几乎都靠外挂CRC或者反馈ACK。这个反馈在无线链路上是有延迟的链路越差、往返时间越长你多发的那部分冗余就越多频谱效率的损失直接体现在吞吐上。第二个尴尬是码率的颗粒度。喷泉码号称无速率但实际译码需要“整个符号”到位收端要么译出来、要么没译出来中间没有软信息可以利用。在低信噪比区数字喷泉码的译码器拿到的是硬判决或者不太可靠的软信息性能曲线会在某个点上突然“断崖”而不是平滑地劣化。第三个尴尬是分离定理的失效。有限码长下把信道编码和调制分开设计、分成两级优化的做法本来就有性能损失而在时变信道里这个损失会被放大因为编码器根本不知道当前这一帧会经历什么样的衰落。我自己在做短包仿真时对这个感受很深包长从几千比特压到几百比特固定码率的LDPC和Turbo的编码增益掉得厉害而喷泉类方案又受限于反馈开销和硬判决损失两边都不讨好。模拟喷泉码恰恰是从这个夹缝里长出来的方案——它把“编码符号”从离散字母表搬到实数域让软信息从编码阶段就一路带着走同时保留了无速率的骨架。提示不要把模拟喷泉码理解成“模拟信号的喷泉码”。它仍然是离散时间、离散信息的编码只是编码输出取连续实数值信道是AWGN噪声是加性的。这个区别在建模时一定要拎清楚否则仿真里信噪比的定义会写错。1.2 模拟喷泉码的核心转变让编码符号变成实数模拟喷泉码的基本构造其实非常朴素。假设有N个信息符号取值是BPSK的±1也可以推广到高阶星座第m个编码符号这样生成先按某个度分布随机挑出d个信息符号再给每个被选中的符号配一个权重最后把所有加权项加起来。写成式子就是 y_m 等于权重乘以对应信息符号的累加和接收端看到的是这个和再加上高斯噪声。因为权重是实数、信息符号也是实数编码输出自然就是实数可以直接送进调制器不需要再做星座映射这一步。这个结构带来两个直接好处。第一译码可以全程在实数域做置信传播消息是高斯分布的均值和方差而不是离散的LLR表软信息没有被量化损失掉。第二码率是连续可调的。你多发一个符号接收端就多一条线性方程信息量就多一点点不存在“多发一个包浪费一整个包”的问题。用生活化的比喻数字喷泉码像是往杯子里倒水一次倒一杯倒多了溢出来模拟喷泉码像是用滴管滴水滴多少是多少杯子满了就停。当然代价也是有的。实数域BP的复杂度比二进制BP高每个校验节点的消息更新都要算方差权重集的选择会直接影响性能上界权重选大了噪声被放大选小了方程之间的区分度不够另外随机图构造必然带来短环短环会让BP的消息在几个节点之间空转收敛变慢甚至不收敛。这些问题在后面几节会逐个拆。2. 自适应模拟喷泉码的整体设计拆解2.1 生成矩阵一次编码在物理层到底做了什么把上面那个构造用矩阵写出来就是 y Gx n其中x是N维信息向量y是M维接收向量G是M×N的稀疏矩阵每一行只有d个非零元位置随机、取值来自权重集W。这个形式和压缩感知里的观测矩阵非常像但两者的问题设定正好相反压缩感知是M远小于N、要求x稀疏模拟喷泉码是M略大于N、x是稠密的稀疏性在图结构上而不在信号上。这个类比很有用因为压缩感知里成熟的BP、AMP、OMP一类算法基本都能平移过来做译码只是要按过定系统调整迭代停止条件和先验。从物理层角度看G的每一行代表“一次线性叠加”在模拟域实现就是一组加权求和。如果权重取整数比如1、2、3那这一行在硬件上就是几个支路的增益相加用开关电容或者电阻网络都能做代价极低。这也是这类方案在实际系统里比较有吸引力的原因之一——它的编码器不是一个复杂的状态机而是一个可配置的加权求和网络甚至可以把权重固定下来只随机化连接关系。相比LDPC那种需要大规模并行走线的结构模拟喷泉码的编码端实现难度低不少。不过这里有个容易忽略的细节G的随机化程度决定了性能的下界。如果连接关系是伪随机的且种子固定那么同一个码字在不同帧之间会重复出现短环某些信息符号可能长期被少数几个校验节点覆盖导致译码时的置信度分布严重不均。我的做法是每帧重新抽取连接关系把种子和帧号绑定如果帧长固定、要求确定的图结构那就要在设计阶段做一次离线搜索把包含4环的行挑出来重抽。2.2 权重集与度分布两个必须一起调的旋钮权重集W是模拟喷泉码独有的设计自由度。数字喷泉码没有这个概念每个编码包就是若干个信息包的异或等价于权重恒为1。一旦权重可以取不同的值问题就变成了“怎么选一组数让线性方程组既好解、又不放大噪声”。这里有个直观的权衡权重越大不同行之间的“区分度”越高G的条件数越好但校验节点更新时噪声方差会按照权重的平方被放大等效信噪比下降。极端情况下如果权重取到10那这一行的观测就基本是噪声了。实践中比较常见的做法是取小整数集合比如{1, 2, 3}或者{1, 2, 4}让权重的动态范围控制在两三倍以内。另一个思路是取正负对称的集合比如{±1, ±2}这样每一行的和值分布更接近零均值对BP的初始消息更友好。我在仿真里对比过这两类正负对称的集合在低信噪比区收敛更快但在高信噪比区优势不明显反而因为负权重的存在让部分硬件实现变复杂。如果你的场景是纯软件仿真或者数字域的等效实现倾向选对称集如果奔着低功耗硬件去老老实实用正整数集。度分布和权重集必须联合优化不能分开调。度分布决定了每个编码符号连接多少个信息符号平均度太低会导致译码的“涟漪”起不来BP在第一步就卡死平均度太高会让每一行的计算量暴涨而且外信息的方差累积过快置信度的动态范围被压缩。经验上平均度落在8到14之间比较稳妥短码N在几百量级可以往低了取长码可以往高了取因为长码的环更分散。2.3 自适应到底适应的是什么这个词是全篇最容易被误解的。自适应在模拟喷泉码的语境下通常有两个层次要分清。第一个层次是符号级自适应发射端知道当前信道的瞬时质量比如通过导频估计出的信噪比据此调整每个编码符号的发射功率或者有效权重。信道好的时候加大权重、提高单符号的信息承载量信道差的时候把权重压小保证观测的可靠性。这个层次的自适应本质上是把功率控制和编码设计揉在了一起。第二个层次是码级自适应也就是根据信道状态选择不同的度分布和权重集。因为模拟喷泉码的等效码率是连续可调的理论上你在任意信噪比下都能找到一组参数让吞吐逼近容量。工程上的做法是离线跑一组信噪比点每个点用差分进化或者密度进化优化出一套度分布做成本地表运行时根据估计的信噪比查表切换。这个思路和LDPC的codebook切换是一样的只是模拟喷泉码切换的是分布参数而不是整个校验矩阵表小得多。还有第三种更“野”的理解就是完全不做显式自适应靠无速率特性自然适配。收端不问发端要多少收到多少算多少译不出来就继续收。这种做法在单向广播或者反馈极贵的场景里非常实用代价是收端要承受一定的过收冗余通常比理想自适应多花20%到40%的符号。我个人倾向于把这个叫“被动自适应”它和前面两个层次并不冲突可以叠加使用。3. 从零搭一套仿真编码端、信道、译码端3.1 参数怎么定先算清楚再动手动手写代码之前先把几个量算清楚否则跑出来的曲线你根本不知道问题出在哪。信息符号数N先定下来短包场景取256或者512中等包长取1024验证长码性能取4096以上。过收比例overhead定义为(M-N)/N这个值在模拟喷泉码里通常比数字喷泉码低因为实数观测携带的信息量更大1e-3误码率下大概20%到30%就够具体取决于度分布和信噪比。然后是复杂度核算。编码端每个符号需要d_avg次乘加M个符号就是M乘d_avg次运算。取N1024、d_avg10、overhead25%则M1280编码端约1.3万次乘加每帧。假设符号率是1兆符号每秒每帧1280个符号占1.28毫秒那编码端算力需求约每秒1000万次乘加一颗中低端MCU都能扛住。译码端是迭代的复杂度是迭代次数乘以M乘以d_avg再乘以一个常数取迭代50次就是每秒5亿次量级这时候就得考虑用向量化或者定点实现了。这个账一定要提前算不然仿真跑到一半发现一帧要跑十秒参数就没法扫了。参数短包场景中等包长长码验证说明信息符号数 N25610244096BPSK取值±1平均度 d_avg81012与N成正相关过收比例30%25%20%低信噪比区适当放宽BP最大迭代6080100配合早停使用目标误码率1e-31e-41e-5决定统计帧数信噪比的定义要特别小心。因为编码输出是实数加权和它的平均功率不等于1所以Eb/N0不能直接套用BPSK的公式。正确的做法是先算编码符号的方差对每一行求权重平方和再对度分布取期望得到平均符号能量E_s再用E_s/N0换算。如果这一步算错了整条曲线会平移好几dB白跑。3.2 编码端实现与稀疏结构存储编码端的核心是把图结构建好。不要用稠密矩阵N到4096的时候M×N就是五百多万个浮点数内存和乘法都吃不消。用行列表的形式存储每行记一个索引数组和一个权重数组这是最省事也最快的。import numpy as np def sample_degree(omega, rng): ds np.array(list(omega.keys())) ps np.array(list(omega.values()), dtypefloat) ps ps / ps.sum() return int(rng.choice(ds, pps)) def build_graph(N, M, omega, W, seed0): rng np.random.default_rng(seed) rows [] for _ in range(M): d sample_degree(omega, rng) idx rng.choice(N, sized, replaceFalse) w rng.choice(W, sized, replaceTrue) rows.append((idx, w.astype(float))) return rows def encode(u, rows): y np.empty(len(rows)) for m, (idx, w) in enumerate(rows): y[m] w u[idx] return y这段代码有两个可以立刻改进的点。第一rng.choice在N很大时是O(N)的跑几万帧会明显拖慢可以换成先用permutation取前d个或者用一个洗牌池维护。第二同一行里允许重复权重是必要的否则度高的行权重组合数不够但要注意别让同一行出现同一个索引两次那等于把某个符号的权重翻倍会引入隐式的确定性。我一般还会在构完图之后做一次4环检测把有4环的行重抽短码下这一招能省下0.3到0.5dB。信道部分就是标准的AWGNy_rx y np.sqrt(sigma2) * rng.standard_normal(M)。sigma2按前面算的平均符号能量来定。如果要加衰落就在每个符号上乘一个瑞利或者莱斯系数注意这时候接收端要拿到相干检测后的等效模型否则BP的消息更新公式要重写。3.3 实数域BP译码的实现细节译码是整套方案里最需要小心的地方。二进制BP里的消息是LLR是一维的实数域BP里的消息是高斯分布要同时传均值和方差所以每条边上要存两个数。校验节点的更新逻辑是对第m行已知y_m约等于该行所有变量贡献之和加噪声那么要对第k条边给出关于x_k的估计就用y_m减去其他所有边的贡献再除以权重w_k方差相应传播。def bp_decode(y, rows, N, sigma2, max_iter80, tol1e-6): M len(rows) # 每条边上的消息mean 和 var m2v_mean [[0.0] * len(r[0]) for r in rows] m2v_var [[1e6] * len(r[0]) for r in rows] v2c_mean [[0.0] * len(r[0]) for r in rows] v2c_var [[1e6] * len(r[0]) for r in rows] # 变量节点 - 校验节点的边索引表 var_edges [[] for _ in range(N)] for m, (idx, _) in enumerate(rows): for k, j in enumerate(idx): var_edges[j].append((m, k)) xhat np.zeros(N) for it in range(max_iter): # 第一步变量节点合并外信息精度加权平均 post_mean np.zeros(N) post_var np.zeros(N) for j in range(N): num, den 0.0, 0.0 for (m, k) in var_edges[j]: p 1.0 / (m2v_var[m][k] 1e-12) num m2v_mean[m][k] * p den p if den 0: post_mean[j], post_var[j] 0.0, 1e6 continue post_mean[j] num / den post_var[j] 1.0 / den for (m, k) in var_edges[j]: p 1.0 / (m2v_var[m][k] 1e-12) d_ den - p if d_ 1e-12: v2c_mean[m][k], v2c_var[m][k] 0.0, 1e6 else: v2c_mean[m][k] (num - m2v_mean[m][k] * p) / d_ v2c_var[m][k] 1.0 / d_ # 第二步校验节点消去其他边的贡献 for m, (idx, w) in enumerate(rows): cm [w[k] * v2c_mean[m][k] for k in range(len(idx))] cv [(w[k] ** 2) * v2c_var[m][k] for k in range(len(idx))] sm, sv sum(cm), sum(cv) for k in range(len(idx)): m2v_mean[m][k] (y[m] - (sm - cm[k])) / (w[k] 1e-12) m2v_var[m][k] (sigma2 (sv - cv[k])) / (w[k] ** 2 1e-12) xhat np.where(post_mean 0, 1.0, -1.0) # 早停重编码残差小于门限 resid 0.0 for m, (idx, w) in enumerate(rows): resid (y[m] - w xhat[idx]) ** 2 if resid 3.0 * len(rows) * sigma2: break return xhat, it, resid这段代码里有两个点值得单独说。第一个是早停条件。模拟喷泉码没有CRC怎么知道译对了用重编码残差把硬判决结果代回编码方程算一遍残差应该接近噪声功率乘以M。我用的门限是3倍的期望残差实测在1e-3误块率附近比较稳门限设太小会误判明明译对了但残差偏大设太大则会放过错误帧。这个门限最好按你的目标误块率扫一遍定下来不要照搬。第二个是方差的初值。流程图里通常写“初始化为无穷大”实际代码里必须给一个有限的大数因为后面要做倒数。这个初值不能太小否则第一轮变量节点的置信度就是错的也不能太大太大反而会在倒数的时候数值下溢。我的经验是按照信道方差乘以十的数量级来给比较稳。3.4 结果曲线怎么读、怎么判断方案的好坏跑完仿真至少要看三条曲线只看BER是不够的。第一条是BER随Eb/N0的变化用来判断方案的编码增益同时要叠一条理想的二进制LDPC或者香农限做参照不然你不知道自己离理论还有多远。第二条是吞吐随信噪比的曲线吞吐要按“成功译出的信息比特数除以实际消耗的符号时间”来算过收冗余要计进去这才是工程上有意义的指标。第三条是平均迭代次数随信噪比的变化这条曲线能告诉你自适应切换点应该放在哪也能暴露BP的病态问题。读曲线的时候有个经验模拟喷泉码的BER曲线在低信噪比区往往比较陡然后在高信噪比区出现一个“拖尾平台”。拖尾一般是两类原因造成的一是度分布里高度的行太多噪声被权重平方放大形成误差底二是图里有顽固的短环某些变量节点长期收不到有效外信息。前者靠调权重集和截断度分布解决后者靠重新构图或者加交织。这个平台的判断很重要如果你的目标误码率是1e-5而平台在1e-4那整个方案就是不可用的必须回头改设计。4. 调参与排错实录那些跑不出曲线的坑4.1 译码不收敛的四类原因第一类图结构问题。最简单的表现是迭代到最大次数重编码残差还在噪声功率的十倍以上BER停在0.1左右不动。这种大概率是图里有变量节点完全没被任何一行覆盖或者覆盖次数只有一次BP给它传的外信息始终是先验等于这个符号永远解不出来。排查办法是统计每个变量节点的连接度最小度必须是2以上出现0或者1就立刻重构图。这个检查我一般写成断言构图后立刻跑一遍。第二类是方差传播发散。表现是迭代到二三十轮之后某些边的方差变成NaN或者负值。根源是校验节点更新里的除法当权重很小或者减去其他贡献后余量接近零的时候会爆掉。前面代码里加的1e-12只是在掩耳盗铃真正稳妥的做法是在校验节点更新前做一次下限截断把方差限制在sigma2的百分之一以上把均值的绝对值限制在一个合理区间。这个截断不会改变收敛点只是防止数值炸掉。第三类是信噪比失配。接收端估的sigma2和实际噪声方差差了3dB以上LLR的尺度就全错了。好消息是实数域BP对尺度误差有一定容忍度只要不是差一个数量级通常只影响收敛速度不影响最终BER坏消息是如果差得太多置信度的相对权重大乱会直接把某些正确的符号推翻。调试时把真实的sigma2喂进去对比一下如果曲线立刻好了5dB那就说明你的噪声估计模块有问题。第四类其实是思路问题不是bug度分布和信噪比不匹配。低信噪比下用了高平均度的分布每一行的噪声被放大得太厉害高信噪比下用了低平均度的分布方程数量不够过收比例再高也补不回来。这个不是改代码能解决的得重新优化分布。我一般会在三四个典型信噪比点各跑一次密度进化做成本地表运行时根据估计信噪比选最近的表项。4.2 权重集和度分布的调参经验权重集的经验前面提了一部分这里补充几条实操的。第一权重集里不要出现互为整数倍的元素比如{1,2,4}看起来没问题但2和4的组合等价于把两个1和一个2做替换会让不同行之间出现隐式的线性相关BP在迭代后期会在这几行之间振荡。我吃过这个亏把4换成3之后拖尾平台直接掉了半个数量级。第二权重的个数不用太多三到四个足够多了意义不大还增加硬件配置复杂度。第三如果要做不等错误保护可以把重要的信息符号分配到高权重的边上这是一个很自然的扩展不需要额外的编码结构。度分布方面别迷信教科书上的鲁棒孤波分布。那是为理想的数字喷泉码设计的搬到模拟域性能会差一截。原因是鲁棒孤波分布的形状是为了保证涟漪不中断而模拟域的约束条件多了权重的噪声放大和实数观测的信息量最优点会明显右移。我自己的做法是用一个参数化的分布族比如以两个峰值位置和一个衰减指数为参数然后用差分进化在目标信噪比下优化误块率迭代五十代左右就能收敛到比教科书分布好1dB以上的结果。这个过程很耗算力但只做一次做完存表。注意优化度分布时目标函数要选误块率或者吞吐不要选误码率。误码率对分布不敏感容易优化到一个看起来很好但实际用不了的点。另外优化时的帧数要够至少统计到两百个错误帧否则优化结果会被噪声带着跑。4.3 常见问题速查表现象大概率原因处理方式BER卡在0.1不动存在度为0或1的变量节点构图后加最小度断言重抽迭代后期出现NaN校验节点更新除零或方差溢出方差下限截断、均值范围截断高信噪比出现拖尾平台权重集有整数倍关系或度高行过多换权重集、截断度分布上界曲线整体左移好几dB平均符号能量算错Eb/N0定义不对重算E_s按权重平方和期望换算低信噪比完全无法启动平均度太低初始涟漪不足提高d_avg到10以上单帧运行时间过长稠密矩阵存储、无早停改行列表存储加重编码残差早停收敛慢但最终BER正常短环多方差更新保守4环检测重抽适度提高迭代上限帧间性能波动大随机图种子未随帧变化把种子和帧号绑定5. 落地场景与后续可以扩展的方向5.1 这套方案真正适合的三类场景第一类是反馈昂贵或者干脆没有反馈的单向链路。广播、卫星下行、水声这类链路的共同点是往返时间远超帧长等反馈回来信道早就变了。模拟喷泉码的被动自适应特性正好补上这个缺口收端自己决定什么时候停发端只管按固定速率吐符号。第二类是短包、低时延场景。传统方案在短包下编码增益损失严重而模拟喷泉码的结构简单、没有长交织、没有复杂的打孔译码的启动延迟就是一个符号的时间。工业无线控制、车联网的周期性状态广播都符合这个画像。第三类是信道质量动态范围特别大的链路。因为码率连续可调它在信噪比大范围波动时不需要频繁切换编码方案一个码字应付全程避免了切换带来的同步和信令开销。这一点在低轨卫星这类多普勒和仰角变化剧烈的场景里很有价值。5.2 工程上还能往哪扩往硬件方向走最直接的想法是把权重固定成小整数用开关电容阵列实现加权求和编码器可以做成纯无源的。这个思路在超低功耗的传感节点上很有吸引力因为编码阶段几乎不耗动态功耗。往算法方向走可以把BP换成近似消息传递在观测矩阵接近高斯独立同分布时收敛更快代价是对图结构的随机性要求更高。另一个值得试的方向是把模拟喷泉码和稀疏码多址结合起来做联合设计。多址场景下多个用户同时发接收端看到的叠加信号天然就是多个编码符号的和这个结构跟模拟喷泉码的线性叠加非常契合有希望把多用户检测和信道译码做成一个整体。这个想法我自己只跑过初步的仿真多用户之间的功率不平衡处理起来比单用户复杂得多还没到能给出结论的程度。我在实际搭这套仿真的过程中最深的一个体会是模拟喷泉码的性能上限八成取决于图结构和度分布这两件事译码算法本身的改进空间反而有限。很多人一开始就想去折腾更高级的译码器其实把4环清干净、把平均度调到合适的区间收益比换算法大得多。另外一点别急着上长码先用N等于256把整条链路跑通把残差早停的门限定下来再去扩到1024和4096能省掉大量返工。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
