迭代解码器 |
|||||||
| 申请号 | CN201210026165.7 | 申请日 | 2012-02-07 | 公开(公告)号 | CN102638278B | 公开(公告)日 | 2017-04-26 |
| 申请人 | 英特尔德国有限责任公司; | 发明人 | M.弗雷西亚; J.伯克曼; A.许布纳; | ||||
| 摘要 | 一种用于对代码 块 进行解码的 迭代 解码器 包括被配置为在每个解码迭代中在代码块或代码子块上执行向前和向后递归的计算单元。在第一迭代中使用第一向前/向后解码方案并在第二迭代中使用第二向前/向后解码方案。第一和第二解码方案由向前和向后处理来看是不同的。 | ||||||
| 权利要求 | 1.一种用于对代码块进行解码的迭代解码器，包括： |
||||||
| 说明书全文 | 迭代解码器技术领域背景技术[0002] 例如，诸如turbo代码的向前纠错（FER）代码由于其高纠错能力而被用于许多当今的通信设备。然而，遗憾的是使用向前和向后递归的解码器中的FER代码的迭代解码可能要求大量的存储器和/或复杂硬件，并可能导致计算费用和等待时间。 [0003] 已知多个方法来改善迭代解码器的性能。Max-Log-MAP算法用来降低计算复杂性。可以应用滑动窗口技术来限制存储数据的量并减少等待时间。并行解码器架构允许高吞吐量。尽管如此，存储器空间、等待时间和计算工作量的减少仍是正在发生的挑战。 [0004] 由于这些及其它原因，需要本发明。 发明内容[0005] 公开了一种用于对代码块进行解码的迭代解码器，包括：计算单元，其被配置为在每个解码迭代中在代码块或代码子块上执行向前和向后递归，其中，在第一迭代中使用第一向前/向后解码方案且在第二迭代中使用第二向前/向后解码方案，用于先验信息的输入端，其中所述先验信息来自前一迭代中所述计算单元的输出，其中第一和第二向前/向后解码方案由向前和向后处理来看是不同的且第二迭代高于第一迭代。 [0006] 公开了一种用于对代码块进行解码的迭代解码器，包括：计算单元，被配置为在每个解码迭代中在代码块或代码子块上执行向前和向后递归，其中，从一个迭代至随后的迭代改变向前和向后递归的调度，以及存储器，其中存储在所述一个迭代中计算并在所述随后的迭代中被用于对向前或向后递归进行初始化的状态度量值，用于先验信息的输入端，其中所述先验信息来自前一迭代中所述计算单元的输出，其中从所述一个迭代至所述随后的迭代互换向前和向后递归。 [0007] 公开了一种用于通过迭代对代码块进行解码的方法，包括：在每个解码迭代中在代码块或代码子块上执行向前和向后递归，其中在第一迭代中使用第一向前/向后解码方案；以及在第二迭代中使用第二向前/向后解码方案，其中，第一和第二向前/向后解码方案由向前和向后处理来看是不同的且第二迭代高于第一迭代；使用在前一迭代中解码的结果作为先验信息。 [0008] 公开了一种用于通过迭代对代码块进行解码的方法，包括；根据第一向前/向后解码方案在第一迭代中在代码块或代码子块上执行向前和向后递归；计算第一迭代中的状态度量值；将所述状态度量值存储在存储器中；读取所存储的状态度量值；通过使用从存储器读取的状态度量值对第二迭代中的向前或向后递归进行初始化；以及根据在调度方面不同于第一向前/向后解码方案的第二向前/向后解码方案在第二迭代中在代码块或代码子块上执行向前和向后递归，还包括：根据第一迭代中的第一向前/向后解码方案在代码块或代码子块上执行向前和向后递归；通过将向前和向后递归互换来从第一向前/向后解码方案导出第二向前/向后解码方案；以及根据第二迭代中的第二向前/向后解码方案在代码块上执行向前和向后递归；使用在前一迭代中解码的结果作为先验信息。附图说明 [0009] 包括附图以提供实施例的进一步理解且该附图被结合到本说明书中并构成其一部分。附图举例说明实施例并连同本说明一起用于解释实施例的原理。将很容易认识到其它实施例和实施例的许多预定优点，因为通过参考以下详细说明，其将被更好地理解。相似的附图标记指定相应的类似部分。 [0010] 图1是举例说明用于对代码进行解码的迭代解码器的实施例的方框图。 [0011] 图2是举例说明用于对turbo代码进行解码的迭代解码器的实施例的方框图。 [0012] 图3是示意性地举例说明包括向前递归和向后递归的解码调度的图。 [0013] 图4是示意性地举例说明使用滑动窗口解码方案的给定迭代中的连续向前递归和间断（intermittent）向后递归及稍后迭代中的连续向后递归和间断向前递归的解码调度的图。 [0014] 图5是示意性地举例说明给定迭代（诸如在图4的左侧部分中所示的一个）中的解码过程的时序图。 [0015] 图6是示意性地举例说明稍后迭代（诸如在图4的右侧部分中所示的一个）中的解码过程的时序图。 [0016] 图7是示意性地举例说明根据一个实施例的基于窗口的并行解码方案中的2个工作器（worker）的调度的图。 [0017] 图8是示意性地举例说明根据一个实施例的基于窗口的并行解码方案中的4个工作器的调度的图。 [0018] 图9是示意性地举例说明根据一个实施例的基于窗口的并行解码方案中的4个工作器的调度的图。 [0019] 图10是示意性地举例说明根据一个实施例的基于窗口的并行解码方案中的4个工作器的调度的图。 [0020] 图11是示意性地举例说明在基于非窗口的并行解码方案中的多个工作器的解码调度的图。 [0022] 图13是根据一个实施例的对代码块进行解码的方法的流程图。 具体实施方式[0023] 在以下详细说明中，对附图进行参考，附图构成其一部分，并且在附图中以图示的方式示出了其中可以实施本发明的特定实施例。在附图中，一般利用相似的附图标记来遍及本说明指相似的元件。在以下描述中，出于解释的目的，阐述了许多特定细节以便提供对本发明的实施例的一个或多个方面的透彻理解。然而，对于本领域的技术人员来说可以显而易见的是可以用较低程度的这些特定细节来实施本发明的实施例的一个或多个方面。在其它实例中，用简化表示示出了已知结构和设备以便促进描述本发明的实施例的一个或多个方面。因此，不应以限制性意义来理解以下详细说明，并且由所附权利要求来限定本发明的范围。 [0024] 可以以各种形式来体现概述的各种方面。以下说明以图示的方式示出其中可以实施各方面的各种组合和配置。应理解的是所述方面和/或实施例仅仅是示例，并且可以利用其它方面和/或实施例，并且在不脱离本公开的范围的情况下可以进行结构和功能修改。特别地，应理解的是可以将本文所述的各种示例性实施例的特征相互组合，除非另外具体说明。 [0025] 本说明书中所采用的术语“耦合”和/或“电耦合”并不意图意指必须将元件直接耦合在一起，在被“耦合”或“电耦合”的元件之间可以提供介入元件。 [0026] 可以在无线通信系统的设备中、特别是在接收机和收发机中采用此处所述的迭代解码器。它们可以在基站中以及在移动站中采用。 [0027] 可以将此处所述的迭代解码器配置为对任何种类的纠错代码解码，可以对该纠错代码使用应用向前递归和向后递归的迭代解码。特别地，可以将此处所述的迭代解码器配置为对卷积代码和/或级联代码进行解码，例如，诸如turbo代码的并行级联卷积代码。此类解码器可以在基于特别地UMTS（通用移动电信系统）标准、HSDPA（高速下行链路分组接入）或HSUPA（高速上行链路分组接入）和长期演进（LTE）的电信系统中使用。 [0028] 举例来说，图1举例说明迭代解码器100的实施例。迭代解码器100包括解码器1和终止级（termination stage）2。解码器1对在输入端3处接收到的代码块进行解码并具有提供表示原始传送（系统）数据位的估计的可靠性数据序列的输出端5。此外，解码器1具有用于先验信息的输入端4。 [0029] 解码器1对在输入端3处接收到的代码块进行解码。通常，用包括系统信息和奇偶信息的软值序列来表示代码块。系统信息对应于原始传送数据序列。奇偶信息对应于在传送机处由一个或多个编码器（例如卷积编码器）生成的奇偶信息。 [0030] 在迭代解码中，诸如在输出端5处提供的估计的解码结果被反馈到解码器1的输入端4并用作下一个解码迭代中的先验信息。此迭代继续直到达到允许迭代的最大数目或满足另一停止标准。 [0031] 在输出端5处提供的估计被输入到终止级2。当满足了停止标准时，迭代解码过程停止并从终止级2输出系统数据的估计。举例来说，如果达到在输出端5中的连续迭代中生成的估计的足够量的收敛（convergence），则可以满足停止标准。 [0032] 可以将解码器1设计为逐个符号后验概率（APP）解码器。APP解码器在格子图（trellis diagram）上操作。格子图是编码器状态对比离散时间的表示。举例来说，可以将解码器1设计为SISO（软输入软输出）解码器。 [0033] 图2举例说明用于对turbo代码进行解码的迭代解码器200的原理设计。根据图1所示的迭代解码器100的原理来设计迭代解码器200。更具体地，迭代解码器200可以包括第一分量解码器201、第二分量解码器202和耦合在第一分量解码器201的输出端与第二分量解码器202的输入端之间的交织器203。可以例如将第一分量解码器201和第二分量解码器202设计为APP解码器，即可以使其与图1中的解码器1相同。举例来说，可以将第一分量解码器201和第二分量解码器202设计为SISO解码器。每个SISO解码器201、202估计逐个符号后验概率。 [0034] 迭代解码器200还可以包括交织器204、解交织器205和终止级206。终止级206可以类似于图1的迭代解码器100中的终止级2，并对相应的说明进行参考。 [0035] 第一分量解码器201在输入端3处接收由传送机中的turbo编码器产生并由接收机中的解调器（未示出）重构的奇偶数据和系统数据。由于在接收机处接收到的信号通常由于噪声和干扰而失真，所以解调器只能提供由turbo编码器产生的奇偶数据和系统数据的估计。通常，这些估计被以对数似然比（LLR）的形式提供给turbo解码器200。给定接收到的模拟信号，LLR表示传送的位是0和是1的概率之间的比。 [0036] 第一分量解码器201按照自然顺序在输入端3处接收的系统数据和奇偶数据的序列上工作。第一分量解码器201根据在输入端3处接收到的系统数据和关联奇偶数据的LLR以及根据在输入端4处接收到的先验信息来计算传送的系统数据的后验概率。第二分量解码器201根据在先验信息输入端4处接收到的LLR和在输入端3处接收到的关联交织奇偶数据来计算交织系统数据的后验概率。因此，交织器203的输出被用作第二分量解码器202中的先验信息。 [0037] 在后续迭代中，每个分量解码器201、202在前一半迭代中将由另一分量解码器201、202输出的所谓非固有信息（extrinsic information）用作先验信息。 [0038] 应注意的是图2是turbo解码器的简化方框图。如在本领域中已知的，第一和第二分量解码器201、202可以在代码块数据的不同部分上工作。举例来说，接收到的代码块c = (u, p1, p2)可以包括系统序列u、第一奇偶序列p1和第二奇偶序列p（2 其中，所有这些序列通常由于噪声和干扰而失真）。在这种情况下，举例来说，可以在第一分量解码器201的输入端3处使用系统序列u和第一奇偶序列p1，并且可以在第二分量解码器201的输入端3处使用交织系统序列uT和第二奇偶序列p2。 [0039] 产生APP的一个算法是所谓的Bahl、Cocke、Jelinek和Raviv（BCJR）算法。根据理论BCJR算法，APP解码器1、201、202计算向前度量α和向后度量β和随后的输出度量（即可靠性数据序列；对于解码器1而言，此序列对应于原始传送数据序列的估计）。在向前和向后递归中分别收集α和β度量。 [0040] 图3是举例说明包括首先计算用于整个代码块的向前度量α的向前递归frec、计算用于整个代码块的向后度量β的向后递归brec和输出度量、即在解码器1、201、202的输出端处获得的概率值（LLR）的解码调度的图。如图3所示，为了减少等待时间和所需的存储器，可以同时地计算向后度量β和输出度量（LLR）。这里，y轴表示从1前进至L（数据块的长度）的格子索引k且x轴对应于以周期为单位的时间。 [0041] 如图3所示，向前递归frec在使用BCJR算法时确定性地从零格子状态开始。另外，由于所谓的终止位（即被添加到消息系统位以便迫使格子路径返回至初始状态的所选位），向后递归brec也可以确定性地从零状态开始。这两个度量连同对整个代码块执行的向前和向后递归frec、brec一起意味着在给定接收数据的情况下，BCJR算法计算用于传送数据块的最好可能估计。还可能的是在BCJR算法中不使用终止位。在这种情况下，最后格子状态处的向后递归brec的最佳初始化是均匀分布。 [0042] 在一个实施例中，解码器1、201、202可以使用所谓的Log-MAP（对数MAP）算法，其为BCJR算法的简化型式。Log-MAP算法基本上执行与BCJR算法相同的运算，但是在对数域中，即用加法代替乘法。Log-MAP算法提供与BCJR算法相同的性能，但具有降低的复杂性。 [0043] 在一个实施例中，解码器1、201、202使用所谓的Max-Log-MAP（最大对数MAP）算法。Max-Log-MAP算法是Log-MAP算法的近似型式。Max-Log-MAP算法在对数域中操作并以错误性能的几十分之一的dB降低（degradation）为代价避免了对数和指数运算。 [0044] 举例来说，在Max-Log-MAP算法中，根据下式分别在向前和向后递归中计算α和β度量 [0045] (1) [0046] (2) [0047] 其中，max是最大选择。在这里，状态度量 和 指的是格子索引k处的编码器状态，并且分支度量 指的是编码器状态m和m'之间的状态转移m → m'。应注意的是 对于比率1/n卷积编码器而言，使得一个信息符号和n个数据符号与索引k相关联。 [0048] 在一个实施例中，解码器1、201、202使用滑动窗口方法。滑动窗口方法用于限制存储数据的量和因此在解码器1、201、202中所需的存储器空间。根据滑动窗口方法，代码块或（如果使用并行解码器架构）代码子块被划分成多个窗口，并连续地向每个窗口应用诸如Log-MAP或Max-Log-MAP的解码算法。在向前递归frec相对于如结合图3所解释的“完美”实现而言通常未改变的同时，窗口方式（window-wise）并间断地执行向后递归brec。因此，基于窗口的方法要求用于向后递归brec的每个窗口的边界处的状态度量初始化。如本领域中所已知的，此初始化的不完美与图3所示的基于非窗口的方法相比导致基于窗口方法的性能的某些损失。 [0049] 图4的左侧举例说明使用基于窗口的方法在第一解码迭代i中调度向前和向后递归frec、brec的实施例。在符号估计过程期间，必须执行递归frec、brec以便计算在解码器输出端5处提供的可靠性信息序列（LLR）。滑动窗口方法包括逐个窗口地执行的递归遍数。窗口的位置然后在整个代码块上（或者在并行解码器架构中，在整个代码子块上）被步进地移位。 [0050] 更具体地，如图4的左侧所示，代码块（或代码子块）被划分成窗口W1、W2、...。每个窗口可以具有相同尺寸WS，并且通常，窗口尺寸WS小于代码块尺寸（或代码子块尺寸）。 [0051] 向前递归frec在初始窗口W1的开始时在时间t0开始。在相同的时间t0，开始第一向后递归brec0的获取阶段。在时间t1，向前递归frec到达初始窗口W1的末端且第一向后递归brec0的获取阶段结束。在时间t1与时间t2之间，继续连续的向前递归frec以处理第二窗口W2并继续第一向后递归brec0以对第一窗口W1进行操作。在时间间隔t1至t2期间，计算并输出用于第一窗口W1的解码结果res1（即LLR）。 [0052] 继续此过程直到到达代码块（或代码子块）的最后一个窗口并进行解码。因此，在连续地在整个代码块（或代码子块）上操作向前递归frec的同时，间断地调度向后递归brec0、brec1、brec2、...以计算向后度量和分别用于窗口W1、W2、W3、...的解码结果res1、res2、res3、...。 [0053] 应注意的是基于窗口的向后递归brec0、brec1、brec2、...的获取阶段可以具有可变长度。在图4中，举例来说，将它们选择为具有窗口尺寸WS的长度。然而，通常，向后递归brec0、brec1、brec2、...的获取阶段不需要具有与窗口相同的尺寸。获取阶段可以大于WS以便增加每个窗口中的向后度量计算的可靠性，或者其可以短于WS。如下文进一步更详细地描述的，在一个实施例中，可以省略向后递归brec0、brec1、brec2、...的获取阶段，即可以在没有获取阶段的情况下设计向后递归brec0、brec1、brec2、...。 [0054] 向后度量计算的质量取决于获取阶段的长度和窗口方式向后递归的初始化。更具体地，在向后递归brec0、brec1、brec2、...开始时（即在获取阶段开始时，如果有的话）所使用的状态度量初始化值对在获取阶段之后在向后递归中计算的向后状态度量的可靠性有影响。在图4中用标记为“读数输入”的箭头来指示向后递归brec0、brec1、brec2、...的初始化。通常，由于迫使格子路径返回至代码块结尾处的预定状态的终止位，只有代码块（或最后一个代码子块）的最后一个窗口（在这里：W6）的状态度量被可靠地初始化。相反地，对于所有其它窗口（在这里：W1～W5）而言，向后递归的确定性状态度量初始化是不可能的。这意味着如图4的左侧部分所示的滑动窗口方法的性能损失取决于除最后一个之外的所有代码块（或代码子块）的向后状态度量的初始化。 [0055] 图5举例说明如图4的左侧部分所示的迭代i中的“完美”向前递归和基于窗口的向后递归的调度。L是代码块尺寸，S是格子状态的数目，并且s＝1、...、S表示格子状态索引。完美向前递归frec在t0处确定性地开始并在整个代码块（索引1至L）上连续地运行。在窗口的边界处，mWS，m＝1、2、...、L/WS，存储向前状态度量αWS(i)(s)、α2WS(i)(s)、...、αL-WS(i)(s)、αL(i)(s)。基于窗口的向后递归brec0、brec1、...分别在t0和t1处开始，并如上文所解释地在每一个获取窗口和一个度量计算窗口上运行。为此，用状态度量β2WS(i)(s)对brec0进行初始化并用状态度量β3WS(i)(s)对brec1进行初始化。不失一般性地，在图5中i＝1。在这种情况下，由于在此初始阶段处没有可用的初始化信息，所以用βmWS(1)(s) = 1/S等概率地对向后递归的边界状态度量（例如，在获取窗口开始时，如果有的话）进行初始化。应注意的是如果使用并行解码架构，上述方案应用于代码子块和L是代码子块尺寸。 [0056] 图4的右侧部分中的图举例说明下一个解码迭代i+1中的向前和向后递归的调度。在下一个迭代i+1中，将向前和向后递归互换。结果，现在在整个代码块上（或者如果使用并行解码架构的话，在代码子块上）连续地执行向后递归，并且向前递归frec是基于窗口的，即在整个代码块上（或者如果使用并行解码架构的话，在代码子块内）不连续地执行。因此，在迭代i+1期间，“完美地”执行向后递归，同时基于窗口或“不完美地”执行向前递归，因此，其可能引起性能损失。 [0057] 一般而言，从迭代i至迭代i+1重新调度向前和向后递归。从迭代i至迭代i+1，可以交换“完美地”执行的递归和“不完美”递归。更具体地，虽然“完美地”执行的递归在迭代i中是沿着增加格子索引k的方向运行的，但其在迭代i+1中是沿着减小格子索引k的方向运行的。反之亦然，虽然“不完美地”执行的递归在迭代i中是沿着减小格子索引k的方向运行的，但其在迭代i+1中是沿着增加格子索引k的方向运行的。因此，在迭代i中使用的向前/向后解码方案和在迭代i+1中使用的向前/向后解码方案由向前和向后处理来看是不同的。特别地，这些解码方案由向前和向后处理来看可以是相反的。 [0058] 在一个实施例中，在下一个迭代i+1中使用在前一迭代i期间估计的状态度量以便对“不完美”基于窗口的递归进行初始化。如果基于窗口的递归包含初始获取阶段，则其为基于窗口的递归的获取阶段，其由在前一迭代i中估计并存储的相同递归类型（即向前或向后）的状态度量初始化。 [0059] 更具体地，如图4的左侧部分所示，在时间t2、t3和t4，存储在迭代i中的“完美”向前递归期间计算的向前状态度量并保持用于下一个迭代i+1。在下一个迭代i+1中，在t0处，开始连续向后递归brec，并且同时开始第一基于窗口的向前递归frec0。 [0060] 应注意的是第一向前递归frec0的开始时间t0取决于获取阶段的长度。如果获取阶段比WS长，则更早地开始基于窗口的向前递归frec0，否则如果获取阶段比WS短，则稍后开始向前递归frec0—其甚至可以在t1处开始，如果在没有获取阶段的情况下实现第一基于窗口的向前递归frec0的话。这适用于在迭代i+1中操作的所有向前递归frec0、frec1、frec2、...。 [0061] 不失一般性地且为了便于解释，下面假设基于窗口的递归（向前或向后）的获取阶段等于窗口尺寸WS。在图4中描绘的解码的调度适用于此情况。然后，将在迭代i期间在时间t4处存储的向前状态度量用于在时间t0处开始的迭代i+1中的基于窗口的向前递归frec0的初始化。 [0062] 在时间t0处的迭代i+1中，第一向前递归frec0在窗口W6中继续，并且同时地，计算用于窗口W6的解码结果res6（LLR）。此方案如在图4的右侧部分中所描绘地继续。也就是说，在t1、t2和t3处，分别由在时间t3、t2和t1处在迭代i中存储的向前状态度量来对分别基于窗口的向前递归frec1、frec2和frec3进行初始化，并且计算解码结果res5、res4、res3。 [0063] 图6举例说明如在图4的右侧部分中所示的迭代i+1中的“完美”向后和基于窗口的向前递归的调度。向后递归brec在t0处在代码块L的结尾处确定性地开始并沿着向后的方向（索引L至1）在整个代码块（或代码子块）上连续地运行。在窗口的边界处，L - mWS，m＝1、...、L/WS，存储向后状态度量βL-WS(i+1)(s)、...、β2WS(i+1)(s)、βWS(i+1)(s)。基于窗口的向前递归frec0、frec1、...分别在t0和t1处开始，并如上文所解释地在一个获取窗口和一个度量计算窗口上运行一次。为此，用状态度量αL-2WS(i)(s)对frec0进行初始化，用状态度量αL-3WS(i)(s)对frec1进行初始化，...等等。不失一般性地，在图5和6中i＝1。 [0064] 由于由递归方向来看从迭代i至迭代i+1改变解码方案的概念，在迭代i中基于“完美”连续递归来计算在迭代i+1中用于“不完美”基于窗口的递归的初始化的状态度量。因此，如在一个实施例中应用的下一个迭代初始化（NII）技术始终基于高度可靠的状态度量数据。 [0065] 然后可以根据在迭代i中使用的解码方案来执行迭代i+2。也就是说，向前递归再次地是连续且“完美的”，并且节省了用于后续迭代的精练前向状态度量。向后递归再次地是基于窗口且“不完美”的，但是来自前一“完美”向后递归的高度可靠的向后状态度量可用来在向后递归的获取阶段处对边界状态度量进行初始化。换言之，在迭代i+2中，可以再次地应用NII方法并使用在前一迭代i+1中的“完美”向后递归中存储的向后度量。 [0066] 在一个实施例中，并不是每个迭代都执行向前/向后解码方案的改变。举例来说，可以处理根据第一解码方案的第一数目的迭代（例如，如在图4的左侧部分中举例说明的）和根据第二解码方案的第二数目的迭代（例如，如在图4的右侧部分中举例说明的），所述第二解码方案由向前和向后递归的调度来看相对于第一解码方案被互换或是相反的。举例来说，可以每2、3、...个迭代执行解码方案的改变或反演。同样在这种情况下，可以将根据第一解码方案计算的向前/向后状态度量用于根据第二解码方案处理的向前/向后递归的初始化。 [0067] 此外，即使逐个迭代地对解码方案进行改变或反演，应注意的是在前一迭代期间也不必要地需要计算并存储用于实际迭代中的初始化的向前/向后度量。还可能的是在实际迭代中使用较早多个迭代计算并存储的向前/向后度量。并且在本实施例中，在其中操作不同或相反（由向前和向后递归的调度来看）解码方案的较早迭代期间已计算在实际迭代中使用的向前/向后度量。结果，同样在这种情况下，利用“完美”递归来生成可靠的状态度量以用于“不完美”实际递归的初始化。 [0068] 通过使用提出的解决方案，始终几乎完美地执行向前和向后递归。事实上，除第一迭代之外（其中，对于基于窗口的递归而言，获取窗口的状态度量被等概率地初始化），用来自前一迭代的完美地计算的状态度量对基于窗口的递归进行初始化。即使在前一迭代处计算这些值，这引起很少的可靠性缺乏，也可能显示的是在几个迭代之后此缺乏几乎消失。 [0069] 应注意的是解码方案变化与迭代解码期间的下一个（或稍后的）迭代初始化的组合显著地降低了性能对窗口尺寸的依赖性，即与已知方案相比可以针对组合方案选择较小的窗口尺寸（或较小的获取长度）以实现相同的性能。可以使用小窗口尺寸（例如20～130、更具体地20～70、更具体地20～40）来实现与用针对实际编码率（≤0.98）的基于非窗口的Max-Log-MAP算法可获得的性能接近的性能。小的窗口尺寸能够急剧地减少迭代解码器的所需存储器空间。 [0070] 此外，上文所解释的概念允许甚至对高编码率使用非常短的获取阶段。获取阶段越短，需要的计算工作量和功率消耗越少。如前所述，甚至可以在基于窗口的递归中消除获取阶段。 [0071] 在一个实施例中，使用多工作器（例如，诸如多个处理器的多个计算单元）实施方式。多个工作器对于高吞吐量解决方案尤其有用。当考虑多个工作器时，将代码块细分成数据的相邻代码子块。每个工作器与其它工作器并行地处理一个子块，并且可以将子块视为迭代内的独立代码字段。由并行解码器架构来实现多工作器解决方案，其中，用于每个工作器的迭代解码器结构与用于单个工作器的上述的一个相同。也就是说，根据一个或多个实施例，每个工作器可以使用如图1和2所示的迭代解码器100和/或迭代解码器200以及如图3至6所示的解码方案。 [0072] 更具体地，在图7所示的一个实施例中，针对两个工作器（处理器P1和处理器P2）以示例的方式示出使用滑动窗口方法的向前和向后递归的调度。图7所示的图对应于如图4的左侧部分所示的迭代i。然而，与图4的单工作器解决方案相反，第一工作器（处理器P1）在第一半代码块（图7的下部）上操作且第二工作器（处理器P2）同时地在第二半代码块（图7的上部）上操作。因此，将代码块分成两个代码子块。第一代码子块被分成窗口W1、W2、...，而第二代码子块被分成窗口Wm、Wm+1、...。每个窗口可以具有相同的尺寸WS，并且通常，窗口尺寸WS小于代码子块尺寸NS，即WS [0073] 在迭代i中，迭代解码将“完美”连续向前递归和“不完美”基于窗口的向后递归用于工作器P1、P2两者。为了简洁起见且为了避免重申，对在图4的左侧部分所示的相应解码方案的说明进行参考。用每个子块的边缘来表示唯一的差别。与在单工作器情况下用于基于窗口的递归的每个窗口的初始化类似，在多工作器情况下，同样地，应可靠地对子块的边缘状态度量进行初始化，例如用在不同或相反（在向前和向后递归的调度方面）解码方案上操作的前一迭代中计算的状态度量。然而，与单工作器情况类似，最后一个（即最高）代码子块的最后一个向后递归被确定性地初始化。 [0074] 在图7所示的实施例中，举例来说，用于每个工作器的向前和向后递归的调度对于给定迭代i而言是相同的，即对于给定迭代i而言沿着相同的方向针对每个工作器执行“完美”递归。然而，在一个实施例中，对于给定迭代i而言，针对一个工作器，可以执行“完美”迭代，并且针对另一工作器，可以执行相反方向的“不完美”迭代。 [0075] 可以以与上文相对于一个工作器解决方案所述的相同的方式执行从迭代i至迭代i+1（或者更一般地从前一迭代至后一迭代）的解码方案变化。此外，在“完美”连续递归中计算的状态度量的存储和相同类型的后来“不完美”基于窗口的递归中的这些存储状态度量的使用对应于在单工作器解决方案中使用的上述技术。在这方面，针对单工作器解决方案公开的所有特征和实施例可以同样地应用于多工作器解决方案。 [0076] 图8是用于四工作器情况的在迭代i中应用的解码方案（完美向前递归，基于窗口的向后递归）的示意性图示。长度L的代码块被划分成长度SBL的四个代码子块，并且每个代码子块再次被划分成长度WS的多个窗口。每个代码子块被专用工作器（处理器）、即迭代解码器100，200独立地处理，如先前所解释的。用虚线来指示获取阶段且如果期望的话可以将其省略。粗线指示执行LLR输出计算。再次地，用于一个、多个或每个代码子块的迭代解码过程可以包括根据前文所述的所有单和多工作器实施例的使用在“完美”递归中计算的状态度量的解码方案变化和NII的概念。 [0077] 图9是针对四工作器情况在奇数编号的迭代1、3、...中应用完美向前和基于窗口的向后递归并在偶数编号的迭代2、4、...中应用基于窗口的向前和完美向后递归的解码方案的一个实施例的示意性图示。类似于图8中所示的实施例，长度L的代码块被划分成用SBx表示的长度SBL的四个代码子块，x＝1、...、4，并且每个代码子块SBx再次被划分成长度WS的多个（在这里：5个）窗口。每个代码子块SBx被专用工作器（处理器）、即迭代解码器100，200独立地处理，如先前所解释的。用虚线来指示获取阶段且如果期望的话可以将其省略。 [0078] 用于一个、多个或每个代码子块SBx的迭代解码过程可以包括解码方案变化和NII的概念。在迭代i＝1中，应用与图8中所示的解码方案类似的解码方案。在后一个迭代中（在这里：i＝2），应用由向前/向后处理来看相反的解码方案。也就是说，向后递归是连续的（“完美”）且向前递归是基于窗口的（“不完美”）。此外，使用在“完美”递归中计算的状态度量对稍后迭代中的“不完美”递归进行初始化。如前所述，这可以适用于单和多工作器实施例。 [0079] 在一个实施例中，仅使用一个获取单元。举例来说，如图9所示，获取单元被用于用于奇数迭代的向后递归和用于偶数迭代的向前递归。 [0080] 如前所述，遍及本说明所使用的术语NII的意义还可以包括“随后迭代初始化”，即通常被初始化的迭代是下一个或随后的迭代。 [0081] 在一个实施例中，NII概念还可以包括多个迭代的初始化。举例来说，在图9中，用在i＝1处开始并指向i＝2和i＝3的水平双箭头来举例说明多迭代初始化的概念。更具体地，使用针对代码子块SBx（x＝1、2、3）中的最高窗口在i＝1计算的向前状态度量来对i＝2处的代码子块SBx+1中的基于窗口的向前递归和i＝3处的代码子块SBx中的“完美”向前递归进行初始化。 [0082] 在一个实施例中，可以通过使用不同的解码方案来处理不同x的代码子块SBx。举例来说，在i＝1处，可以如在i＝1处在图9中所示地处理代码子块SB1和SB3（即“完美”向前、“不完美”向后递归），而如在i＝2处在图9中所示的，在i＝1处可以处理代码子块SB2和SB4（即“完美”向后、“不完美”向前递归）。 [0083] 图10是解码方案的一个实施例的示意性图示。再次地，用虚线来指示（可选）获取阶段并用水平箭头来指示NII。在这里，举例来说，应用X结构的窗口方案。每个X在两个窗口上延伸。要处理的第一个X是与每个代码子块SBx中的最低两个窗口相关联的X。向前递归在X的第一窗口的底部处开始且向后递归在X的第二窗口的顶部处开始。在窗口上存储所计算的状态度量，并且然后一旦向前和向后递归相遇（即在X的交叉点处），则针对另一窗口计算解码结果（LLR）。一旦处理了与第一X相关联的两个窗口，则将X结构移位至下两个窗口。在图10中，举例来说，每个代码子块SBx包括6个窗口，即每个代码子块SBx处理3个X结构。 [0084] 在图10中，在随后的迭代i＝2处，应用由向前和向后处理来看不同的解码方案。同样地在i＝2处，使用如上所述的X结构的解码方案。然而，被处理的第一X结构是与每个代码子块中的最高两个窗口相关联的X结构。因此，从i＝1至i＝2，向前和向后递归的调度或者换言之解码方向被反演。 [0085] 在一个实施例中，在第一迭代中使用的第一解码方案和在第二迭代中使用的第二解码方案由处理方案的结构来看是不同的。举例来说，在第一迭代中，使用第一结构的第一解码方案，诸如图4、7、8、9所示的梯子结构方案（即一个连续递归、相反方向的多个基于窗口的递归），并且在第二迭代中，使用第二结构的第二解码方案，诸如图10中所示的X结构的方案。解码方案的结构指示在代码子块或代码块上的处理向前和向后递归的调度模式。并且在本实施例中，在第一迭代中使用的第一解码方案和在第二迭代中使用的第二解码方案是不同的，并且可以应用获取和NII。 [0086] 图11是举例说明根据一个实施例的多工作器解码方案的图。在这里，类似于图7，考虑两个工作器，亦即代码块被划分成两个代码子块SB1、SB2。与图7和8所示的多工作器实施例相反，使用基于非窗口的解码算法。举例来说，可以使用如结合图3所解释的基于非窗口的解码算法，其使用连续向前递归和连续向后递归。 [0087] 更具体地，在迭代i中，由两个工作器（例如处理器）来操作第一连续向前递归frec和后续连续向后递归brec。在迭代i+1中，改变解码方案，或者更具体地，由向前和向后处理来看使其反演，即将递归方向互换。因此，在迭代i+1中，操作第一连续向后递归brec和后续连续向前递归frec。 [0088] 在这里，从迭代i至迭代i+1的解码方案变化允许如下对迭代i+1中的递归进行初始化。由于在代码块结尾处的终止位，子块SB2中的向后递归brec被确定性地初始化。子块SB1中的向后递归brec仅仅是迭代i中的子块SB2的向后递归brec的继续，并且因此被完美地初始化。通过使用在前一迭代i中的子块SB1中的向前递归frec的结尾处计算并存储的向前度量来对子块SB2中的向前递归frec进行初始化。最后，将子块SB1中的向前递归frec确定性地初始化，因为已知初始格子状态。因此，即使在基于非窗口的解码方案的情况下，从一个迭代至另一迭代的解码方案变化（即反演）的概念也可以相当大地改善解码性能。 [0089] 在一个实施例中，在迭代i+2中使用的解码方案与在迭代i中使用的解码方案相同，即逐个迭代地执行解码方案的反演。在这种情况下，在迭代i+2中，子块SB2中的向前递归frec仅仅是前一迭代i+1中的子块SB1中的向前递归frec的继续，并且用由处于子块SB2的最低格子索引的迭代i+1中的子块SB2中的向后递归brec计算的向后度量来对子块SB1中的向后递归进行初始化。 [0090] 因此，在一个实施例中，使用在用于迭代i中的子块SB1的递归中计算的状态度量来对随后迭代（例如下一个迭代i+1）中的子块SB2中的递归进行初始化，并使用在迭代i中的子块SB2中的递归中计算的状态度量来对随后迭代（例如下一个迭代i+1）中的子块SB1中的递归进行初始化。换言之，在迭代解码期间的递归方案变化可以导致子块不再相互独立地被解码。相反，从一个迭代至另一迭代，在子块之间交换状态度量信息。 [0091] 应注意的是可以将在此处在单工作器解决方案中对代码块进行解码的上下文中描述的所有特征应用于在多工作器解决方案中对代码子块进行解码。此外，可以将在此处在多工作器解决方案中对代码块进行解码的上下文中描述的所有特征用于在单工作器解决方案中对代码子块进行解码。 [0092] 图12是举例说明以kbps为单位的迭代解码器的吞吐量对比以dB为单位的信道功率的图表。举例来说，考虑HS-PDSCH信道。使用如图2中所示的turbo解码器，并采用如图4至8中所示的基于窗口的解码方案。也就是说，在每个迭代中使用解码方案反演和状态度量交换。选择小窗口尺寸WS＝32并使用长度WS＝32的获取阶段。使用典型情况（Cat10, MaxTput 和 Ior/Ioc = 25 dB）并针对一个工作器、两个工作器和四个工作器生成模拟结果。另一方面，针对经典基于窗口的方法，其中，不使用解码方案变化且不使用NII，使用窗口尺寸WS＝ 512并仅考虑单工作器情况。如从图12可以看到的，提出的解决方案胜于经典的基于窗口的解决方案，无论并行程度如何（1、2、4个工作器）。另外，随着工作器数目的增加，几乎不存在性能损失。 [0093] 图13是根据一个实施例的迭代地对级联代码进行解码的方法的流程图。在第一迭代中，使用第一向前/向后解码方案。在此迭代中，计算并存储用于向前或向后递归中的至少一个的状态度量。在第二迭代中，使用第二向前/向后解码方案，其中，第二解码方案在向前和向后递归处理方面不同于第一解码方案。在此第二迭代中，使用在第一迭代中计算并存储的状态度量来对向前或向后递归中的至少一个进行初始化。如前所述，两个递归都可以是连续递归，或者递归中的至少一可以是间断的窗口方式的递归。此外，递归可以在整个代码块上运行（单工作器解决方案），或者递归可以每个在代码子块上运行（多工作器解决方案）。 [0094] 通常，在此处所述的一个实施例中，可以基本上减少所需的存储内存空间，导致芯片组的芯片面积和功率消耗减少。在这方面，应注意的是窗口尺寸WS的减小不仅允许减少要存储的状态度量的量，而且确定用于分支度量、读/写地址等的高速缓存尺寸。 [0095] 此外，因此可以将窗口尺寸WS的设计选择为相当大地比在常规设计中小。 [0096] 此外，可以减少等待时间。大多数基于窗口的算法中的每个迭代处的初始等待时间是窗口尺寸WS的倍数。因此，与使用较大窗口尺寸WS的常规解决方案相比，用此处所述的概念还可以显著地减少总解码等待时间来获得相同BLER TPut性能（BLER：块出错率；TPut：吞吐量）。替换地，针对给定解码等待时间，窗口尺寸减少导致在芯片面积和功率消耗方面有益的解码硬件的较小的要求时钟速率。 [0097] 另外，虽然可以相对于多个实施方式中的仅一个已经公开了本发明的实施例的特定特征或方面，但如对于任何给定或特定应用而言可以是期望和有利的，可以将此类特征或方面与其它实施方式的一个或多个其它特征或方面组合。本申请意图涵盖此处所讨论的特定实施例的任何修改或变型，并且本发明意图仅仅由权利要求及其等价物来限制。 |
||||||
QQ群二维码
意见反馈
意见反馈