Turbo碼是近年來通信系統(tǒng)糾錯(cuò)編碼領(lǐng)域的重大突破，他以其接近Shannon限的優(yōu)越性能博得眾多學(xué)者的青睞。本文采用基于Max-Log-Map的優(yōu)化譯碼算法，對(duì)狀態(tài)量度歸一化計(jì)算和滑動(dòng)窗算法等關(guān)鍵技術(shù)進(jìn)行優(yōu)化，在滿足性能要求的情況下，大大降低算法復(fù)雜度。

　　1 Turbo編碼器.譯碼器及算法

　　Turbo編碼器采用3GPP的編碼方案，由約束長(zhǎng)度K為4，碼率為1/2的RSC編碼器通過1個(gè)交織器并行級(jí)聯(lián)而成，為提高性能對(duì)2個(gè)譯碼器分別附加3個(gè)尾比特使譯碼器的最終狀態(tài)為全0。

　　譯碼器采用反饋迭代結(jié)構(gòu)，每級(jí)譯碼模塊除了交織器，解交織器外主要包括兩個(gè)級(jí)聯(lián)的分量譯碼器;一個(gè)分量譯碼器的輸出的軟判決信息經(jīng)過處理成為外信息輸入另一個(gè)分量譯碼器，形成迭代譯碼，在迭代一定級(jí)數(shù)后硬判決輸出。

　　編碼網(wǎng)格表貫穿整個(gè)譯碼過程，任意時(shí)刻k～k+1的RSC網(wǎng)格結(jié)構(gòu)如圖3所示，圖中編碼器輸入的0～7狀態(tài)可以由二進(jìn)制表示。

　　下面介紹Max-Log-Map算法。

　　由于需要進(jìn)行大量的乘法運(yùn)算和指數(shù)運(yùn)算，Map算法不適用于硬件實(shí)現(xiàn)。ERFanian和Pasupanthy最早提出了Map算法在對(duì)數(shù)域的簡(jiǎn)化算*og-Map算法。通過轉(zhuǎn)換到對(duì)數(shù)域運(yùn)算，避免了指數(shù)運(yùn)算，同時(shí)乘法變成加法，而加法則變成Max運(yùn)算，不過由此也會(huì)帶來了一定的性能損失。下面簡(jiǎn)要描述Max-Log-Map算法。設(shè)Ak(s)，Bk(s)，Γk(s)分別代表對(duì)數(shù)域的前向狀態(tài)度量、后向狀態(tài)度量和分支度量，其表達(dá)式分別可表示為：

　　如圖3所示，每個(gè)節(jié)點(diǎn)狀態(tài)s都對(duì)應(yīng)于一個(gè)Ak(s)，1個(gè)Bk(5)和2個(gè)Γk(s)。因此編碼網(wǎng)絡(luò)貫穿整個(gè)編譯碼過程，譯碼前要先按圖3建立網(wǎng)格映射表。

　　2譯碼器實(shí)現(xiàn)的關(guān)鍵改進(jìn)與優(yōu)化

　　Turbo碼譯碼是一個(gè)復(fù)雜的過程，之所以這么說，除了算法本身復(fù)雜外，還有兩個(gè)主要的原因，一個(gè)是遞推計(jì)算過程中前、反向度量不斷增大給信號(hào)處理器帶來的麻煩，即經(jīng)常說的溢出;另一個(gè)是大存儲(chǔ)量需求。這里，就這兩個(gè)細(xì)節(jié)問題進(jìn)行討論和總結(jié)，并且給出詳細(xì)解決方案。

　　2.1狀態(tài)量度歸一化問題

　　由式(1)，式(2)可注意到，隨著計(jì)算的不斷深入，狀態(tài)量度值不斷增加，為防止計(jì)算溢出和減小硬件復(fù)雜度，必須對(duì)其進(jìn)行歸一化處理。一種方法是減去前一時(shí)刻狀態(tài)度量的最小值，這種方法在每個(gè)時(shí)刻都需要減法器和用于計(jì)算最小值的比較器，當(dāng)狀態(tài)數(shù)較多時(shí)，由此帶來的額外的時(shí)延和硬件消耗是不能忽略的。本算法采用一種十分有效的歸一化方法(以Ak(s)為例)，在每個(gè)計(jì)算時(shí)刻，判斷有沒有狀態(tài)度量值(A或B)大于某一門限值T，若有則所有節(jié)點(diǎn)的狀態(tài)度量值(A或B)都減去T，若沒有則保持原值不變。這樣便大大減少了減法器使用的次數(shù)，也無需計(jì)算最小值。由于所有的節(jié)點(diǎn)都減去了相同的值，因此式(5)的結(jié)果不會(huì)受到影響。T值不宜設(shè)置太大，但設(shè)置得太小，歸一化發(fā)生的很頻繁，會(huì)增加譯碼時(shí)延和硬件開銷。通過試驗(yàn)仿真，若q代表狀態(tài)量度值的量化字長(zhǎng)，則T設(shè)為2q-2為合適。

　　2.2 引入滑動(dòng)窗減小存儲(chǔ)量

　　由于Turbo碼譯碼算法的迭代特性，每一級(jí)Map譯碼器需要大量存儲(chǔ)器。在譯碼時(shí)引入滑動(dòng)窗，能有效減少所需的存儲(chǔ)量。采用滑動(dòng)窗的Map譯碼步驟為：每次譯碼過程被分為若干段以間隔L(假設(shè)滑動(dòng)窗的長(zhǎng)度為L(zhǎng)，L《N)連續(xù)進(jìn)行，只需在對(duì)nL長(zhǎng)的數(shù)據(jù)進(jìn)行前向處理后，每個(gè)反向子處理過程即可執(zhí)行，而未使用滑動(dòng)窗時(shí)，需要對(duì)整個(gè)數(shù)據(jù)塊處理后才能進(jìn)行。實(shí)驗(yàn)證明，滑動(dòng)窗大小選擇7～8倍的約束長(zhǎng)度時(shí)對(duì)誤碼率的性能影響幾乎可以忽略。本算法中約束長(zhǎng)度為4，選擇窗口大小為32。下面給出采用滑動(dòng)窗譯碼前后兩種算法存儲(chǔ)空間分配情況的比較。假設(shè)編碼幀長(zhǎng)為L(zhǎng)，B表示窗口長(zhǎng)度，L為B的整數(shù)倍。

　　按照表1，這個(gè)存儲(chǔ)空間為26L，當(dāng)L=1K時(shí)，為26K。如果我們采用分塊譯碼，按照表2，那么整個(gè)譯碼的存儲(chǔ)需求為20B+8L，B一般取編碼約束長(zhǎng)度的5～10倍，對(duì)于8狀態(tài)編碼，取B=32，那么這個(gè)存儲(chǔ)空間為640+8L，與表1的26L相比要小的多。

　　當(dāng)L=1K時(shí)，存儲(chǔ)空間只占原來的33.2%。當(dāng)編碼幀長(zhǎng)L的取更大值時(shí)，存儲(chǔ)空間的節(jié)約更加可觀，比較得知采用滑動(dòng)窗后，Turbo譯碼能夠大大節(jié)省硬件的存儲(chǔ)資源。