Turbo译码研究及其DSP实现(精)

1、Turbo 译码研究及其 DSP 实现Turbo 码是近年来通信系统纠错编码领域的重大突破，他以其接近Shannon 限的优越性能博得众多学者的青睐。本文采用基于Max-Log-Map 的优化译码算法，对状态量度归一化计算和滑动窗算法等关键技术进行优化，在满足性能要 求的情况下，大大降低算法复杂度。1 Turbo 编码器. 译码器及算法Turbo 编码器采用 3GPP 勺编码方案，由约束长度 K 为 4,码率为 1/2 的RSC 编码器通过 1 个交织器并行级联而成，为提高性能对 2 个译码器分别附加 3 个尾比特使译码器的最终状态为全 0。译码器采用反馈迭代结构，每级译码模块除了交织器，解交

2、织器外主要包 括两个级联的分量译码器 ; 一个分量译码器的输出的软判决信息经过处理成为外 信息输入另一个分量译码器，形成迭代译码，在迭代一定级数后硬判决输出。编码网格表贯穿整个译码过程，任意时刻 kk+1 的 RSC 网格结构如图 3 所 示，图中编码器输入的 07 状态可以由二进制表示。F 面介绍 Max-Log-Map 算法。由于需要进行大量的乘法运算和指数运算，Map 算法不适用于硬件实现。ERFanian 和 Pasupanthy 最早提出了 Map 算法在对数域的简化算*og-Map 算法。 通过转换到对数域运算，避免了指数运算，同时乘法变成加法，而加法则变成 Max 运算，不过由此

3、也会带来了一定的性能损失。下面简要描述Max-Log-M ap算法。设 Ak(s)，Bk(s)，rk(s)分别代表对数域的前向状态度量、后向状态度 量和分支度量，其表达式分别可表示为：如图 3 所示，每个节点状态 s 都对应于一个 Ak(s) , 1 个 Bk(5)和 2 个rk(s)。因此编码网络贯穿整个编译码过程，译码前要先按图3 建立网格映射2 译码器实现的关键改进与优化Turbo 码译码是一个复杂的过程，之所以这么说，除了算法本身复杂外， 还有两个主要的原因，一个是递推计算过程中前、反向度量不断增大给信号处 理器带来的麻烦，即经常说的溢出 ; 另一个是大存储量需求。这里，就这两个细 节

4、问题进行讨论和总结，并且给出详细解决方案。2.1 状态量度归一化问题由式(1) ，式(2) 可注意到，随着计算的不断深入，状态量度值不断增加， 为防止计算溢出和减小硬件复杂度，必须对其进行归一化处理。一种方法是减 去前一时刻状态度量的最小值，这种方法在每个时刻都需要减法器和用于计算 最小值的比较器，当状态数较多时，由此带来的额外的时延和硬件消耗是不能 忽略的。本算法采用一种十分有效的归一化方法(以 Ak(s)为例)，在每个计算 时刻，判断有没有状态度量值(A或 B)大于某一门限值 T,若有则所有节点的状 态度量值(A 或 B)都减去 T，若没有则保持原值不变。这样便大大减少了减法器 使用的次数

5、，也无需计算最小值。由于所有的节点都减去了相同的值，因此式 (5)的结果不会受到影响。T 值不宜设置太大，但设置得太小，归一化发生的很 频繁，会增加译码时延和硬件开销。通过试验仿真，若 q 代表状态量度值的量 化字长，则 T 设为 2q-2 为合适。2.2 引入滑动窗减小存储量由于 Turbo 码译码算法的迭代特性，每一级 Map 译码器需要大量存储器。 在译码时引入滑动窗，能有效减少所需的存储量。采用滑动窗的Map 译码步骤为：每次译码过程被分为若干段以间隔 L(假设滑动窗的长度为 L，LN)连续进 行，只需在对 nL 长的数据进行前向处理后，每个反向子处理过程即可执行，而 未使用滑动窗时，需要对整个数据块处理后才能进行。实验证明，滑动窗大小 选择 78 倍的约束长度时对误码率的性能影响几乎可以忽略。本算法中约束长 度为 4，选择窗口大小为 32。下面给出采用滑动窗译码前后两种算法存储空间 分配情况的比较。假设编码帧长为 L，B 表示窗口长度，L 为 B 的整数倍。按照表 1,这个存储空间为 26L,当 L=1K 时，为 26K。如果我们采用分块 译码，按照表 2,那么整个译码的存储需求为 20B+8L B 一般取编码约束长度 的 510 倍，对于 8 状态编码，取 B=32,那么这个存储空间为 640+8L，与表 1 的 26L 相比