專利名稱：自適應(yīng)動態(tài)前向糾錯編碼方法、裝置及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及前向糾錯編碼技術(shù)，特別是涉及一種自適應(yīng)動態(tài)前向糾錯編碼方法、裝置及系統(tǒng)。
背景技術(shù)：
網(wǎng)絡(luò)數(shù)據(jù)在通信線路上進行傳輸時，可能會由于通信線路所依賴的信道不可靠而導(dǎo)致數(shù)據(jù)包傳輸過程中出現(xiàn)錯誤，接收端接收到的數(shù)據(jù)包或多或少不同于發(fā)送端發(fā)出的數(shù)據(jù)包，使得接收到的數(shù)據(jù)包的數(shù)據(jù)不可用，而這種數(shù)據(jù)包發(fā)生錯誤的現(xiàn)象也稱為誤碼，造成誤碼的原因很多，如無線電傳輸中的電磁干擾、電傳輸鏈路中的電流浪涌或光傳輸鏈路中的信號強弱等，均可能造成通信線路的信道不可靠，導(dǎo)致數(shù)據(jù)鏈路傳輸中出現(xiàn)突發(fā)性誤碼。其中，
低速串行鏈路上的誤碼現(xiàn)象更為嚴重，比特誤碼率嚴重時可達10 — 3,其意味
著通信鏈路上傳輸?shù)膱笪拈L度超過1000字節(jié)時，平均報文錯誤率可達100% ，
使得通信線路無法進行數(shù)據(jù)包的傳輸。因此，如何保證通信鏈路上數(shù)據(jù)傳輸?shù)臏蚀_性和可靠性是一個需要解決的技術(shù)問題。
現(xiàn)有技術(shù)中還提出了一種克服傳輸誤碼的前向糾錯(Forward ErrorCorrection, FEC)編碼方法，F(xiàn)EC是指數(shù)據(jù)被傳輸之前預(yù)先對其按一定的算法進行編碼，在接收端則按同樣的算法進行解碼，以達到找出錯誤并糾正錯誤的目的。其中，在低帶寬、較大時延、高誤碼率的網(wǎng)絡(luò)環(huán)境下引入端對端的前向糾錯，是提高網(wǎng)絡(luò)數(shù)據(jù)傳輸質(zhì)量的重要手段。FEC工作在傳輸層或應(yīng)用層時，其處理的對象為數(shù)據(jù)包，而基于數(shù)據(jù)包的前向糾錯技術(shù)的基本原理是在m個源數(shù)據(jù)包中插入r個冗余包(即冗余數(shù)據(jù))，并將這m+r個包一起發(fā)送給接收設(shè)備，其中，r個冗余包是由m個源數(shù)據(jù)包經(jīng)過編碼算法計算后得到， 且可將這m+r個數(shù)據(jù)包稱為一個數(shù)據(jù)塊，每個包在塊中都有一個編號，但是， 由于網(wǎng)絡(luò)傳輸?shù)牟豢煽啃裕?一個數(shù)據(jù)塊中的一些數(shù)據(jù)包在傳輸過程中丟失， 接收設(shè)備則可以通過編號確定丟失的數(shù)據(jù)包在數(shù)據(jù)塊中的位置，在丟包數(shù)量 不超過糾錯能力極限的情況下，由于冗余包的存在，接收設(shè)備可利用冗余包 來恢復(fù)丟失的源數(shù)據(jù)包， 一般而言，冗余包的數(shù)量越多，接收設(shè)備進行糾錯 的能力也就越強，但是，冗余包數(shù)量的增多也就意味著數(shù)據(jù)傳輸中占用網(wǎng)絡(luò) 帶寬的增加，會浪費大量的網(wǎng)絡(luò)帶寬資源。
此外，在前向糾錯編碼方法的基礎(chǔ)上，現(xiàn)有技術(shù)又提出了自適應(yīng)前向動 態(tài)糾錯編碼方法，其主要包括以下幾種方法
(1)《中國礦業(yè)大學(xué)學(xué)凈艮》2006年11月發(fā)表的《實時數(shù)據(jù)傳輸?shù)淖赃m 應(yīng)前向糾錯方法研究》，其公開了針對實時數(shù)據(jù)傳輸對服務(wù)質(zhì)量的特殊需要， 提出了一種基于實時傳輸協(xié)議(Real-time Transport Protocol, RTP )的能 修復(fù)單包丟失的具有自適應(yīng)特性的前向差錯校正方法。該方法通過跟蹤網(wǎng)絡(luò) 擁塞變化，動態(tài)調(diào)整差錯編碼參數(shù)，即差錯編碼分組長度，保證傳輸服務(wù)的 質(zhì)量。
(2 )《江南大學(xué)學(xué)報》2006年4月自然科學(xué)版發(fā)表的《前向糾錯編碼傳 輸機制的優(yōu)化》，其公開了為提高FEC編碼在抖動參數(shù)上的性能，提出了一 種改進發(fā)送端與接收端之間的信息交互方式的動態(tài)FEC傳輸機制。該機制中， 發(fā)送端接收到反饋信息后，調(diào)整數(shù)據(jù)的冗余度，但不會為了等待反饋信息停 止數(shù)據(jù)的發(fā)送。其基本方法是在發(fā)送的實時數(shù)據(jù)的用戶數(shù)據(jù)報協(xié)議(User Datagram Protocol, UDP )的頭部和實際實時數(shù)據(jù)之間加入一個稱為DFEC的 首部，該首部中加入一個FEC-0n標志位，用來標志數(shù)據(jù)是否需要FEC解碼， 接收端通過判斷數(shù)據(jù)包的接收情況，若丟包率大于設(shè)定的FEC開啟閾值，就 發(fā)送一個數(shù)據(jù)包給發(fā)送端，以此方式通知發(fā)送端開啟或關(guān)閉FEC編碼。
(3)《計算機應(yīng)用》2008年9月公開的論文《無線網(wǎng)絡(luò)中支持H, 264
5的增強前向糾錯算法》，其公開了在無線網(wǎng)絡(luò)中支持H. 264視頻業(yè)務(wù)傳輸， 提出了 一種增強的FEC算法EFEC，并對EFEC的性能進^f亍了分析。增強的FEC 算法通過接收端發(fā)送的反饋信息決定是否采用EFEC傳輸數(shù)據(jù)，且不會應(yīng)為反 饋信息的丟失而停止數(shù)據(jù)傳輸，同時，EFEC可根據(jù)網(wǎng)絡(luò)誤比特率調(diào)整附加數(shù) 據(jù)信息的長度。
(4)公開號為CN101061659A、發(fā)明名稱為《自適應(yīng)前向糾錯》的中國專 利公開了用于無線網(wǎng)絡(luò)上視頻流傳輸?shù)淖赃m應(yīng)FEC設(shè)備和方法，其中，設(shè)備 包括FEC編碼器和自適應(yīng)FEC裝置，F(xiàn)EC編碼器用于將K個源數(shù)據(jù)包編碼為n 個包，其中nA，并且該n個包包括冗余數(shù)據(jù)，自適應(yīng)FEC裝置用于基于一條 或多條反饋信息的接收，來自適應(yīng)地確定要和K個編碼包一起發(fā)送的冗余包 數(shù)，這一條或多條反饋信息指示要借以發(fā)送編碼視頻的無線網(wǎng)絡(luò)的條件。
發(fā)明人在實現(xiàn)本發(fā)明的過程中發(fā)現(xiàn)現(xiàn)有的前向糾錯技術(shù)至少存在如下缺 陷現(xiàn)有自適應(yīng)FEC編碼方法中均采用單一的FEC編碼算法，且一般是對冗 余數(shù)據(jù)的大小或者是否進行FEC編碼進行控制，以適應(yīng)當前的網(wǎng)絡(luò)環(huán)境，F(xiàn)EC 編碼方式簡單，對于網(wǎng)絡(luò)數(shù)據(jù)的動態(tài)傳輸中，網(wǎng)絡(luò)環(huán)境易變化的情況下，發(fā) 送端和接收端只能采用單一的FEC編碼算法，不能適應(yīng)各種網(wǎng)絡(luò)環(huán)境下采用 前向糾錯編碼的數(shù)據(jù)的傳輸，導(dǎo)致數(shù)據(jù)傳輸效率和可靠性較低。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種自適應(yīng)動態(tài)前向糾錯編碼方法、裝置及系統(tǒng)， 可有效克服現(xiàn)有前向糾錯編碼方法的缺陷，可根據(jù)當前網(wǎng)絡(luò)環(huán)境的變化，在 發(fā)送設(shè)備和接收設(shè)備之間建立合適的編碼算法，可適合各種環(huán)境下采用前向 糾錯編碼的數(shù)據(jù)傳輸?shù)男枰?，降低?shù)據(jù)傳輸?shù)恼`碼率，提高通信鏈路的數(shù)據(jù) 傳輸效率。
為實現(xiàn)上述目的，本發(fā)明提供了一種自適應(yīng)動態(tài)前向糾錯編碼方法，包
括根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信
息，所述編碼協(xié)商請求信息包括編碼算法；
接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼算法對從 所述發(fā)送設(shè)備接收到的報文進行解碼處理。
其中，所述根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼 協(xié)商請求信息包括
當對接收到的報文進行解碼錯誤時，根據(jù)當前網(wǎng)絡(luò)狀態(tài)向通信鏈路上的 報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息。
或者，所述根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼 協(xié)商請求信息可包括
統(tǒng)計對接收到的不同報文進行連續(xù)解碼時未出現(xiàn)錯誤的解碼次數(shù)，判斷 所述解碼次數(shù)是否超過預(yù)設(shè)次數(shù)，是則向所述發(fā)送設(shè)備發(fā)送所述編碼協(xié)商請 求信息。
本發(fā)明提供了一種自適應(yīng)動態(tài)前向糾錯編碼裝置，包括
協(xié)商發(fā)送模塊，用于根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備 發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法；
接收處理模塊，用于接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并根 據(jù)所述編碼算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理。
本發(fā)明還提供了 一種自適應(yīng)動態(tài)前向糾錯編碼系統(tǒng)，包括發(fā)送設(shè)備和接 收設(shè)備，其中，
所述接收設(shè)備，用于根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備 發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法；接收所述發(fā) 送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼算法對從所述發(fā)送設(shè)備接 收到的報文進行解碼處理；
所述發(fā)送設(shè)備，用于接收所述接收設(shè)備發(fā)送的所述編碼算法協(xié)商請求信 息，并根據(jù)自身的狀態(tài)返回協(xié)商確認信息。本發(fā)明技術(shù)方案中接收設(shè)備可根據(jù)自身的網(wǎng)絡(luò)狀態(tài)向發(fā)送設(shè)備發(fā)起編碼 算法的協(xié)商請求，協(xié)商雙方之間釆用的編碼算法，并以協(xié)商后的編碼算法對 數(shù)據(jù)的發(fā)送和數(shù)據(jù)接收進行相應(yīng)的處理，使得基于協(xié)商后的編碼算法的數(shù)據(jù) 的傳送更加準確可靠，且可有效提高整個通信鏈路和通信系統(tǒng)的數(shù)據(jù)傳送效
率；本發(fā)明技術(shù)方案可根據(jù)不同網(wǎng)絡(luò)環(huán)境采用不同的編碼算法的前向糾錯編 碼，可有效提高采用前向糾錯編碼進行數(shù)據(jù)傳輸?shù)男枰档蛿?shù)據(jù)傳輸?shù)恼` 碼率，提高數(shù)據(jù)傳輸?shù)男省?br>

圖1為基于PPP協(xié)議進行數(shù)據(jù)傳輸?shù)氖疽鈭D； 圖2為PPP協(xié)議協(xié)商階段的示意圖3為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼方法實施例一的流程圖4為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼方法實施例二的流程圖5為FCP中Reset-Request和Reset-Ack才艮文編碼格式的示意圖6為FCP中X0R編碼算法的報文格式示意圖7為FCP中RS編碼算法的報文格式示意圖8為本發(fā)明實施例通過FCP進行編碼算法協(xié)商的工作階段示意圖9為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼裝置實施例一的結(jié)構(gòu)示意圖IO為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼裝置實施例二的結(jié)構(gòu)示意圖;
圖11為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼系統(tǒng)實施例的結(jié)構(gòu)示意圖。
具體實施例方式
下面通過附圖和實施例，對本發(fā)明的技術(shù)方案做進一步的詳細描述。 本發(fā)明實施例可應(yīng)用于基于前向糾錯技術(shù)進行報文傳輸?shù)木W(wǎng)絡(luò)中，具體
地，本發(fā)明實施例可在報文傳輸?shù)耐ㄐ沛溌返陌l(fā)送設(shè)備和接收設(shè)備之間建立
編碼協(xié)商纟幾制，
8協(xié)商后的編碼 算法下進行前向糾錯編碼時，發(fā)送設(shè)備和接收設(shè)備之間的通信可以同步，在 降低數(shù)據(jù)傳輸中的誤碼率的同時，還可有效保證數(shù)據(jù)傳輸?shù)男省Ｆ渲?，?br> 便于對本發(fā)明技術(shù)方案進行說明，本發(fā)明實施例以采用點對點協(xié)議(Point to Point, PPP)進行凈艮文傳輸?shù)耐ㄐ沛淾各為例進行說明。
下面首先對采用PPP協(xié)議進行通信的過程進行說明。圖1為基于PPP協(xié) 議進行數(shù)據(jù)傳輸?shù)氖疽鈭D；圖2為PPP協(xié)議協(xié)商階段的示意圖。低速通信鏈 路中，如無線電臺、衛(wèi)星通信等鏈路，報文的傳輸一般采用PPP協(xié)議進行鏈 路控制、數(shù)據(jù)壓縮控制、網(wǎng)絡(luò)層協(xié)議控制和數(shù)據(jù)封裝，這使得PPP協(xié)議成為 低速鏈路數(shù)據(jù)通信的首選，而對于誤碼率較高，或者雖然誤碼率不高但對數(shù) 據(jù)傳輸可靠性要求較高的高速鏈路，如光纖通信系統(tǒng)，PPP協(xié)議也被廣泛應(yīng)用， 因此，有必要在PPP協(xié)議的基礎(chǔ)上擴展對報文糾錯的控制。其中，基于PPP 協(xié)議的協(xié)商過程如下.'
(1) 當PPP鏈路激活(UP)后，進入鏈路建立(Establish)階段，具 體地，基于PPP協(xié)議標準，由鏈路控制協(xié)議(Link Control Protocol, LCP ) 通過交換Configure才艮文來建立連接，當4矣收到Configure-Ack報文后，協(xié) 商交互完成并進入LCP 0pen狀態(tài)，使LCP處于打開(Opened)狀態(tài)。
(2) 鏈路建立階段結(jié)束后，進入認證(Authenticate)階段，該認證階 段為可選的，如果通信雙方配置了認證選項，則PPP協(xié)議實體要求對方在進 行網(wǎng)絡(luò)層協(xié)議報文交換之前進行認證，此時，只有鏈路雙方通過彼此的認證 后才能進入到下 一個階段的協(xié)商。
(3) 在認證階段結(jié)束后，進入網(wǎng)絡(luò)(Network)層協(xié)議協(xié)商階段，根據(jù) PPP協(xié)議標準，首先對壓縮控制協(xié)議(Compression Control Protocol, CCP ) 協(xié)商，CCP負責(zé)在PPP鏈路的兩端配置、使能和關(guān)閉數(shù)據(jù)壓縮算法，還可以一 種可靠的方式通告壓縮/解壓縮機制的失效，其中，CCP協(xié)商也是可選的。
由于大多數(shù)的數(shù)據(jù)傳輸均使用IP協(xié)議，因此，在CCP協(xié)商完成后，網(wǎng)絡(luò)層協(xié)議協(xié)商的一個重要部分就是使用IP控制協(xié)議(IP Control Protocol, IPCP)在PPP鏈路的兩端來配置、使能和關(guān)閉IP協(xié)議模塊，且IPCP使用與 LCP相同的報文交換機制，其中，本發(fā)明實施例技術(shù)方案即可在采用PPP協(xié)議 的通信鏈路上來實現(xiàn)前向糾錯編碼算法的協(xié)商以及采用前向糾錯編碼實現(xiàn)數(shù) 據(jù)的傳輸。
圖3為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼方法實施例一的流程圖。如圖3 所示，本實施例方法包括以下步驟
步驟IOI、根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié) 商請求信息，所述編碼協(xié)商請求信息包括編碼算法；
步驟102、接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼 算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理。
本實施例技術(shù)方案可應(yīng)用于采用前向糾錯編碼進行的數(shù)據(jù)傳輸?shù)耐ㄐ畔?統(tǒng)中，數(shù)據(jù)傳輸中的接收設(shè)備可根據(jù)自身的網(wǎng)絡(luò)狀態(tài)，如信道的實際誤碼率 或測量得到的誤碼率、帶寬、延遲、可用性、用戶需求等，確定適合于當前 網(wǎng)絡(luò)狀態(tài)，且可滿足數(shù)據(jù)傳輸可靠性的編碼算法，并將該編碼算法攜帶在編 碼協(xié)商請求信息中發(fā)送給數(shù)據(jù)傳輸中的發(fā)送設(shè)備，在雙方之間建立采用合適 編碼算法對數(shù)據(jù)進行傳輸，使得利用該編碼算法進行前向糾錯數(shù)據(jù)傳輸時， 可有效保證數(shù)據(jù)傳輸?shù)目煽啃?，降低?shù)據(jù)傳輸?shù)恼`碼率，降低數(shù)據(jù)傳輸時帶 寬的占用率，提高數(shù)據(jù)傳輸效率。具體地，當接收設(shè)備將攜帶編碼算法的編 碼協(xié)商請求信息發(fā)送至發(fā)送設(shè)備時，發(fā)送設(shè)備接收到該編碼協(xié)商請求信息后， 可根據(jù)自身的條件或網(wǎng)絡(luò)環(huán)境，如是否支持該編碼算法等，響應(yīng)該編碼協(xié)商 請求，若同意該編碼協(xié)商請求信息中的編碼算法，則向接收設(shè)備返回編碼協(xié) 商確認信息，表示同意以該編碼協(xié)商請求信息中的編碼算法進行數(shù)據(jù)傳輸， 然后發(fā)送設(shè)備和接收設(shè)備即可按照該協(xié)商的編碼算法對數(shù)據(jù)進行處理，完成 數(shù)據(jù)的發(fā)送和接收，即發(fā)送設(shè)備即可按照該協(xié)商后的編碼算法對數(shù)據(jù)進行處 理并發(fā)送，而接收設(shè)備則可按照該編碼算法對從發(fā)送設(shè)備接收到的數(shù)據(jù)進行相應(yīng)的解碼處理。
實際應(yīng)用中，當接收設(shè)備對接收到的報文進行解碼錯誤時，可根據(jù)檢測 得到的當前網(wǎng)絡(luò)狀態(tài)向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息， 以在發(fā)送設(shè)備和接收設(shè)備之間建立合適的編碼算法，提高接收設(shè)備對報文解 碼的準確性和可靠性，提高整個通信鏈路數(shù)據(jù)傳輸?shù)男省?br> 實際應(yīng)用中，所述的編碼算法可以為區(qū)塊碼算法、回旋碼算法、渦輪碼
算法、低集成度奇偶校驗碼算法或RAID碼算法等，其中，區(qū)塊碼中可采用RS 碼(Reed-Solomon碼)、RAID碼或XOR碼等。具體地，發(fā)送設(shè)備或接收設(shè)備 可以根據(jù)當前網(wǎng)絡(luò)狀態(tài)等的需要，在雙方之間建立合適的編碼算法，以使得 根據(jù)該編碼算法進行前向糾錯編碼時數(shù)據(jù)傳輸占用的帶寬小，鏈路消耗低， 且可有效保證接收數(shù)據(jù)的準確性，提高數(shù)據(jù)傳輸?shù)目煽啃浴Ｍ瑫r，由于編碼 算法是根據(jù)當前的網(wǎng)絡(luò)狀態(tài)而設(shè)定，因此，采用協(xié)商后的編碼算法進行前向 糾錯，可有效降低數(shù)據(jù)傳輸中占用的網(wǎng)絡(luò)的帶寬，提高數(shù)據(jù)傳輸?shù)男?，?而提高整個通信系統(tǒng)的吞吐量。
實際應(yīng)用中，當發(fā)送設(shè)備向接收設(shè)備發(fā)起編碼協(xié)商請求信息，而發(fā)送設(shè) 備不支持其攜帶的編碼算法時，發(fā)送設(shè)備可向接收設(shè)備返回重協(xié)商請求信息， 該重協(xié)商請求信息可包含發(fā)送設(shè)備建議采用的新的編碼算法，接收設(shè)備若接 收到發(fā)送設(shè)備返回的重協(xié)商請求信息時，可根據(jù)所述重協(xié)商請求信息向所述 發(fā)送設(shè)備重新發(fā)起編碼協(xié)商請求信息，該重新發(fā)起的編碼協(xié)商請求信息可包 含攜帶所述新的編碼算法的請求信息，使得發(fā)送設(shè)備和接收設(shè)備之間可以協(xié)
商確定一種適合雙方的編碼算法。同時，接收設(shè)備也可以根據(jù)自身的需要， 選擇另一合適的編碼算法向發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息，在發(fā)送設(shè)備和
接收設(shè)備之間建立適合雙方的編碼算法。
因此，本發(fā)明實施例中接收設(shè)備可根據(jù)自身的網(wǎng)絡(luò)狀態(tài)向發(fā)送設(shè)備發(fā)起 編碼算法的協(xié)商請求，協(xié)商雙方之間釆用的編碼算法，并以協(xié)商后的編碼算 法對數(shù)據(jù)的發(fā)送和數(shù)據(jù)接收進行相應(yīng)的處理，使得基于協(xié)商后的編碼算法的
ii數(shù)據(jù)的傳送更加準確可靠，且可有效提高整個通信鏈路和通信系統(tǒng)的數(shù)據(jù)傳
送效率；本發(fā)明實施例可根據(jù)不同網(wǎng)絡(luò)環(huán)境采用不同的編碼算法的前向糾錯 編碼，可有效提高采用前向糾錯編碼進行數(shù)據(jù)傳輸?shù)男枰档蛿?shù)據(jù)傳輸?shù)?誤碼率，提高數(shù)據(jù)傳輸?shù)男省?br> 圖4為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼方法實施例二的流程圖。本實施 例方法可包括以下步驟
步驟201、統(tǒng)計對接收到的不同報文進行連續(xù)解碼時未出現(xiàn)錯誤的解碼次數(shù)。
步驟202、判斷所述解碼次數(shù)是否超過預(yù)設(shè)次數(shù)，是則執(zhí)行步驟203，否 則，執(zhí)行步驟201。
步驟203、根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié) 商請求信息。
步驟204、接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼 算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理。
本發(fā)明實施例中，接收設(shè)備可對其對接收到的不同報文連續(xù)解碼正確的 解碼次數(shù)進行統(tǒng)計，當連續(xù)解碼次數(shù)超過預(yù)設(shè)次數(shù)時，說明當前的網(wǎng)絡(luò)狀態(tài) 良好，此時網(wǎng)絡(luò)狀態(tài)下還可能允許具有更低編碼強度的數(shù)據(jù)的傳輸，因此， 當對不同的報文連接解碼正確的解碼次數(shù)超過預(yù)設(shè)次數(shù)時，接收設(shè)備可設(shè)定 更加適合該網(wǎng)絡(luò)狀態(tài)下的編碼算法，向發(fā)送設(shè)備發(fā)起編碼協(xié)商請求，以使得 在新的編碼算下進行前向糾錯編碼時，降低編碼強度，使得數(shù)據(jù)傳輸時占用 更少的網(wǎng)絡(luò)帶寬，提高數(shù)傳輸?shù)男剩瑫r，還可保證數(shù)據(jù)傳輸?shù)臏蚀_性和 可靠性。
可以看出，本發(fā)明實施例可根據(jù)接收設(shè)備接收的實際需要，當網(wǎng)絡(luò)狀態(tài) 良好時，可重新發(fā)送編碼協(xié)商請求信息，以建立采用新的編碼算法進行前向 糾錯編碼，可避免數(shù)據(jù)長期處于較強的編碼強度下而降低了數(shù)據(jù)傳輸?shù)男剩?可有效提高整個通信鏈路數(shù)據(jù)傳輸?shù)男?，提高整個通信系統(tǒng)的吞吐量。上述各實施例中，接收設(shè)備在向發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息時，編 碼協(xié)商請求信息中還可包括與編碼算法對應(yīng)的編碼參數(shù)，以確認編碼后的冗 余數(shù)據(jù)的大小，當然，根據(jù)實際的需要，在進行編碼協(xié)商時，也可只協(xié)商發(fā) 送設(shè)備和接收設(shè)備之間編碼時采用的合適的編碼參數(shù)，以保證數(shù)據(jù)傳輸?shù)臏?確性和可靠性，保證數(shù)據(jù)傳輸?shù)男省?br> 上述各實施例中，發(fā)起編碼協(xié)商請求信息的也可以是發(fā)送設(shè)備，此時， 一般是在數(shù)據(jù)發(fā)送前建立發(fā)送設(shè)備和接收設(shè)備之間采用的前向糾錯編碼算 法，以使得數(shù)據(jù)開始傳輸時即具有較好的數(shù)據(jù)傳輸效果。
為對本發(fā)明技術(shù)方案有更好的了解，下面對上述發(fā)送設(shè)備和接收設(shè)備之 間進行編碼算法協(xié)商在PPP鏈if各上的實現(xiàn)進行說明。
實際應(yīng)用中，本發(fā)明實施例發(fā)送設(shè)備和接收設(shè)備之間編碼算法的協(xié)商可 以在采用PPP協(xié)議的通信鏈路上實現(xiàn)，且可在PPP鏈路的發(fā)送設(shè)備和接收設(shè)
備上分別配置FEC糾錯算法協(xié)議(FEC Control Protocol, FCP ) ， FCP可以 用來標識糾錯編碼與解碼采用的編碼算法，因此，可以通過FCP協(xié)商發(fā)送設(shè) 備和接收設(shè)備之間在進行前向糾錯編碼傳輸數(shù)據(jù)時采用的編碼算法，具體地， 接收設(shè)備或發(fā)送設(shè)備可以根據(jù)自身網(wǎng)絡(luò)的需要向數(shù)據(jù)傳輸?shù)牧?一端協(xié)商合適 的編碼算法，以提高數(shù)據(jù)傳輸?shù)男屎蛿?shù)據(jù)傳輸?shù)目煽啃?。其中，F(xiàn)CP為網(wǎng)絡(luò) 層協(xié)商協(xié)議，F(xiàn)CP可使用與LCP相同的報文交互機制，只有當PPP到達網(wǎng)絡(luò)層 協(xié)議階段才能交換FCP報文。
下面對FCP協(xié)議進行說明，以對其有較好的理解，具體地，F(xiàn)CP協(xié)議與 LCP除了以下不同之外，其它均具有與LCP相同
(1) 幀格式的不同。
FCP報文的幀格式與LCP在鏈路建立階段協(xié)商時所使用的幀格式不同，具 體地，對其中某些域的值進行了修改，可見以下各域不同之處的說明。
(2) 數(shù)據(jù)鏈路協(xié)議域不同。
PPP信息域中封裝了一個FCP報文，此時PPP協(xié)議域的類型號為803D，
13表示對應(yīng)于FCP。
(3) 代碼域(Code Field)不同。
除了代碼1 ~ 7,即Configure-Request, Configure—Ack， Conf igure-Nak， Configure-Reject, Terminate—Request, Terminate—Ack和Code-Reject, FCP中還力口入了兩個i貞夕卜6々纟扁石馬14禾口 15，民卩Reset-Request禾口 Reset—Ack。 此外，其它編碼應(yīng)該祐:視作不認識并回應(yīng)Code-Rejects。
(4) 超時操作不同。
FCP報文只有當PPP已經(jīng)到達網(wǎng)絡(luò)層協(xié)議階段才能開始交換，實現(xiàn)時，應(yīng) 該先等待認證和鏈路質(zhì)量判定(Link Quality Determination)已經(jīng)結(jié)束后 開始進行Configure-Ack或其它響應(yīng)的超時才喿作，具體實現(xiàn)時，建議只有當
用戶干預(yù)或等待了一個可配置的時間后才放棄繼續(xù)等待響應(yīng)。
(5) 配置選項類型(Configuration Option Types)不同。 FCP協(xié)議有自己的配置選項，具體將在后面介紹。
(6) 發(fā)送FEC編碼數(shù)據(jù)報文(Sending Fee-coded Datagrams)不同。 在任何FEC編碼報文可以通訊前，PPP必須到達網(wǎng)絡(luò)層協(xié)議階段，F(xiàn)CP必
須處于Opend狀態(tài)。
一個或多個FEC編碼報文封裝在PPP信息域，PPP協(xié)議域類型的十六進制 值為003D,即對應(yīng)于FEC編碼凈艮文。每一種FEC編碼算法可以-使用不同的初』 制來表明在一個數(shù)據(jù)鏈路層幀(Data Link Layer frame)中包含了一個或多 個未編碼的報文，以用于確認前面的解碼報文是否正確，或者用于編碼同步 等。
在PPP鏈路的每個方向一次只能使用一種主要的FEC編碼算法，具體使 用何種算法以及相應(yīng)的編碼算法參數(shù)是在報文交互之間協(xié)商完成，F(xiàn)EC編碼報 文的PPP協(xié)議域表明該幀是FEC編碼的，但不表明具體使用的是何種FEC編 碼算法及相關(guān)的編碼算法參數(shù)。
在PPP鏈路上傳遞的FEC編碼報文的最大長度與PPP封裝報文的信息域(Information field)的最大長度相同，而更長的才艮文可以用不編碼的方式 發(fā)送，如可使用標準格式，或者，如果FEC編碼算法支持則可用多個報文發(fā) 送。在本協(xié)議約定中，未使用FEC編碼的正常報文可以使用協(xié)議域類型為003F 的PPP幀進行封裝發(fā)送，以便于FEC編碼的同步或其它需要。鑒于FEC編碼算法可以從報文中的編碼信息中判斷所收到的數(shù)據(jù)是否正 確，因此，F(xiàn)EC算法并不要求底層PPP數(shù)據(jù)發(fā)送是可靠的，但FEC編碼算法必 須有機制可以判斷編碼的報文在編碼和解碼雙方是否同步。FCP的報文格式和基本機制與LCP協(xié)議中的定義相同，而在FCP中FCP 的代碼域(Code field)的最新值為003D、 003F,用于報文的收發(fā)，且在FCP 中加入了以下的FCP代碼域值14 Reset—Request15 Reset-Ack為了在通信鏈路的一個方向上提供一種表明解碼失效的機制而不影響另 一個方向的流量，F(xiàn)CP提供Reset-Request和Reset-Ack碼，解碼失效可通過 解碼時的出錯數(shù)據(jù)塊數(shù)大于當前編碼糾錯能力來判斷，而出錯數(shù)據(jù)塊可以通 過數(shù)據(jù)塊后附加的CRC纟交—驗值來判斷。如果FCP實現(xiàn)希望指示解碼失效，可發(fā)送一個代碼域為14,即 Reset-Request的FCP才艮文，并且在數(shù)據(jù)域填入任何想要的數(shù)據(jù)。當發(fā)送了 Reset-Request后，4壬何收到的FEC編碼的凈艮文都應(yīng)該丟棄，并發(fā)送另一個 Reset—Request,直至甘》1史至1』——個合法^; Reset—Ack。 j!欠至!J Re set—Request后， 發(fā)送方FEC編碼器返回初始狀態(tài)，即重新初始化編碼算法的相關(guān)參數(shù)，此時， FEC須發(fā)送一個代碼域為15，即Reset-Ack的FEC報文作為應(yīng)答，其id域， 即標識符域與Reset-Request中的id相同，數(shù)據(jù)域填入任何想要的數(shù)據(jù)。如 果收到Reset-Request或Reset-Ack的FCP報文，接收者應(yīng)該判斷本地解碼 是否出現(xiàn)致命錯誤，如果出現(xiàn)致命錯誤，則應(yīng)該關(guān)閉FCP，向?qū)Ψ桨l(fā)送代碼域 為Terminate-Request的FCP報文，如果出現(xiàn)非致命的錯誤，則可以發(fā)送Conf igure-Request報文，要求與對方返回到鏈路建立階段。圖5為FCP中Reset-Request和Reset-Ack寺良文編碼才各式的示意圖。具 體地，如圖5所示，Reset-Request和Reset-Ack才艮文編碼才各式中相應(yīng)的報 文域從左至右傳輸，其中，代碼(Code)中，14表示Reset-Request, 15表示Reset-Ack;在傳輸 時，當數(shù)據(jù)域的內(nèi)容改變和收到一個關(guān)于先前的請求(Request)的合法回復(fù) (r印ly )時必須改變id域，即標識符(Identifier )i或，當收到Reset-Reques t 才艮文時，Reset-Request的id域應(yīng)拷貝到Reset-Ack^艮文的id域；凄t據(jù)(Data ) 域為0個或多個字節(jié)，包含給發(fā)送者的不可解釋的數(shù)據(jù)，數(shù)據(jù)可以包含任何 二進制值，長度可以是任意長度，從0到對方的MRU值-4。下面對FCP配置選項進^f于說明。FCP配置選項允許協(xié)商壓縮算法及相應(yīng)的 算法參數(shù)，F(xiàn)CP使用與LCP協(xié)議相同的配置選項格式，但選項的內(nèi)容不同。FCP 中配置選項指出接收設(shè)備所用的編碼算法，接收設(shè)備根據(jù)該編碼算法愿意或 能夠解碼出由發(fā)送設(shè)備發(fā)送的數(shù)據(jù)，假定系統(tǒng)可以提供多種算法，可協(xié)商并 采用其中一種算法。由于數(shù)據(jù)的收發(fā)雙方可能無法對所有的糾錯算法(即前向糾錯編碼算法)達成一致，此時可能無法使用糾錯算法，因此，通信鏈路 必須在沒有糾錯的方式下達成一致，當LCP再次協(xié)商時，則必須重新協(xié)商FCP 狀態(tài)。此外，由于許多用戶均可以使用自己專有的算法，此時用戶也可根據(jù) 自己的編碼來設(shè)定一個編號，且該編號與后面FCP協(xié)議給出的編號不同，即 用戶也可以自定義算法及FCP中相應(yīng)的編號。實際應(yīng)用中，如果配置選項不能祐j妾收方識別就發(fā)送Configure-Reject, 若所有的FEC編碼算法接收者均不識別，則表明在這條通信鏈路的這個方向 上不能使用FEC編碼。如果配置選項能夠被接收方識別，但由于選項值不能 被接收方接受，或者沒有選項參數(shù)，則須發(fā)送一個Configure-NAK,其中包含 j務(wù)改過的選項值，Configure-NAK必須只包含可以接受的選項。當發(fā)送者接收 到一個Configure-NAK時應(yīng)該發(fā)送一個新的Configure-Request，其中選項值修改為接收方想要的值，由此，即可在雙方之間達成一致的編碼算法。具體地，F(xiàn)CP選項類型域可支持以下選項值FCP Option FEC Coding Type2 X0R3 RS4 RAID6-Like5 渦輪碼6 巻積碼7 低集成度奇偶校驗碼 8-15 未JS武值碼255 Reserved上述各選項類型域的選項值1 ~ 7對應(yīng)的編碼算法均為常用的編碼算法， 未賦值碼可以為用戶專有的FEC編碼算法，且用于專有的FEC編碼算法可以 不需要許可授權(quán)，相應(yīng)的選項值可以由用戶自己定義。為對本發(fā)明實施例中編碼算法應(yīng)用于FCP中有較好的理解，下面給出XOR 和RS編碼算法的編碼方式進行說明 (1) XOR編碼算法。圖6為FCP中XOR編碼算法的報文格式示意圖。具體地，如圖6所示， 該配置選項提供了一種協(xié)商使用XOR編碼算法的方式，XOR是一種典型的區(qū)塊 碼，由于一個區(qū)段(segment)內(nèi)只能包含一個糾錯塊(即冗余碼)，而一個 糾錯只能糾正一個區(qū)段內(nèi)一個塊的錯，因此，它的糾錯能力完全取決于區(qū)段 內(nèi)的分塊數(shù)，即一個糾錯塊對應(yīng)的原始數(shù)據(jù)塊的數(shù)目。對于XOR編碼而言， 編碼參數(shù)包括原始數(shù)據(jù)分塊大小(block size, BS )和分段數(shù)(segment size， SS)，單位為字節(jié)。 一個分段內(nèi)的分塊數(shù)為BS/SS。此外，對于每個原始數(shù)據(jù) 塊，需要一個或多個校驗字節(jié)以驗證該數(shù)據(jù)塊接收后的正確性，校驗方式為 CRC8或CRC16,即8位或16位的循環(huán)冗余校-驗。下面對X0R編碼算法的報文格式中各報文域進行說明 Type數(shù)值為2，表示采用的是X0R編碼算法；Length數(shù)值為8; BS代表 每個編碼塊的大小，單位為字節(jié)，塊尾附加一個CRC校驗；SS代表每個編碼 段的大小，單位為字節(jié)，段尾附加一個X0R編碼的糾錯塊，其中，SS為0， 表示將整個數(shù)據(jù)作為一個分段，SS—般為BS的整倍數(shù)，如果為非整倍數(shù)，則 段尾的最后一個塊要補齊0后再進行編碼；CRC bits表示每個編碼塊后的CRC 校驗的位數(shù)，其值通常為8 (即1個字節(jié))或16 (即2個字節(jié))，采用CRC8 或CRC16校驗。(2) RS編碼算法。圖7為FCP中RS編碼算法的報文格式示意圖。具體地，如圖7所示，該 配置選項提供了一種協(xié)商使用RS編碼算法的方式，與X0R碼一樣，RS編碼也 是一種典型的區(qū)塊碼，但RS編碼的糾錯能力要大大高于XOR碼，根據(jù)國際電 信聯(lián)盟ITU-T的建議，RS編碼格式可以表示為(n, k, d),其中n=2m-1, d =n-k+l， m為正整數(shù)，RS編碼算法可以糾正t-(d-l)/2個m進制的碼錯。一 般而言，m=8,即通常的RS8編碼時，其可糾正長度為t個字節(jié)的突發(fā)碼錯， 由于是區(qū)塊碼，還必須對編碼的數(shù)據(jù)塊長度和分段長度進行說明，這與XOR 編碼相同，數(shù)據(jù)塊的校驗也使用CRC校驗。下面對RS編碼算法的報文格式中M艮文域進行說明 Type數(shù)值為3，表示采用的是RS編碼算法；Length對應(yīng)的數(shù)值為14; Coded size (n)用來表示當前編碼的取值范圍，即全部符號的數(shù)量，由于RS 編碼是在有限域的基礎(chǔ)上得到，有限域，即伽羅華域，是指元素個數(shù)有限的 域，域中的元素個數(shù)稱為域的階，通過用GF U) ， RS編碼的符號取值域均 在GF U)域內(nèi)，其長為n = q-1; Data size (k)對應(yīng)的數(shù)值K表示編碼前 的原始信息符號的數(shù)量；Minimum Distance (d)對應(yīng)的數(shù)值d表示RS編碼 的最小漢明距離，d應(yīng)該滿足d-n-k+l-2t+l， t是指能糾錯的錯誤數(shù)，因此 在實際傳輸中，如果接收方收到的d值不能滿足以上條件應(yīng)該默認丟棄該報文；BS表示每個編碼塊的大小，單位為字節(jié)，塊尾附加一個CRC校驗；SS表 示每個編碼段的大小，單位為字節(jié)，根據(jù)所采用的編碼，段尾附加一個或多 個RS糾錯塊，SS為0表示將整個數(shù)據(jù)作為一個分段，SS —般為BS的整倍數(shù)， 如果為非整倍數(shù)，則段尾的最后要補齊0后再進行編碼；CRC bits表示每個 編碼塊后的CRC校驗的位數(shù)，其值通常為8 (即1個字節(jié))或16 (即2個字 節(jié))。圖8為本發(fā)明實施例通過FCP進行編碼算法協(xié)商的工作階段示意圖。具 體地，發(fā)送設(shè)備和"l妄收設(shè)備之間采用PPP協(xié)議通信，且利用上述的FCP進行 收發(fā)雙方的編碼算法協(xié)商時，其工作階段可如圖8所示，整個PPP協(xié)議中包 括有鏈路控制協(xié)商、口令認證協(xié)商、壓縮控制協(xié)商、FEC控制協(xié)商和IP控制 協(xié)商，其中控制報文交互的類型可以從1 15,其中，14為Reset-Request, 15為Reset-Ack。可以看出，在PPP協(xié)議通信過程中，在原有的鏈i 各控制協(xié) 商、口令認證協(xié)商、壓縮控制協(xié)商和IP控制協(xié)商之外，還可通過FEC控制協(xié) 商，即FCP協(xié)商來達到接收設(shè)備和發(fā)送設(shè)備之間的編碼算法的一致。可以看 出，通過FCP協(xié)商可以實現(xiàn)發(fā)送設(shè)備和接收設(shè)備之間采用的編碼算法的同步， 可有效保證數(shù)據(jù)傳輸?shù)臏蚀_性和可靠性。此外本發(fā)明實施例中還提出了 一種網(wǎng)絡(luò)中進行數(shù)據(jù)通信是糾錯能力的確 定方法，其是假定網(wǎng)絡(luò)數(shù)據(jù)傳輸中數(shù)據(jù)出錯的概率p確定的情況下，最佳的 編碼原始數(shù)據(jù)分段長度為n，糾錯編碼部分的長度為k。接收設(shè)備可根據(jù)數(shù)據(jù)傳輸?shù)那闆r，計算數(shù)據(jù)報文丟失的概率為p ,對數(shù) 據(jù)進行編碼后報文的總長度為w + h則由概率論可知，接收設(shè)備接收到的報 文中有/個錯誤的概率為^:(1)經(jīng)過FEC糾錯修復(fù)后，實際包錯誤概率可以近似用以下公式計算("+一 & (" + * -1 C^' (1 — ' t C (1 - p)"+" 尸'=-=-^-= JP—Jd- (2)19從公式(2)可知，接收設(shè)備完全正確接收的概率由網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)報文 丟失的概率/7和報文長度w + A決定，由于/t是一個常量，所以最佳的報文長度 由"決定。但公式(2)不便于轉(zhuǎn)換成解析表達式，本實施例中用近似方法來 確定《的值。
由于每個報文解碼后錯誤數(shù)目/服從參數(shù)為"+ yfc的二項分布，根據(jù)概率論 可知，報文的出錯數(shù)目/的數(shù)學(xué)期望為 鄰)=0 + 一 (3)
因此，可以得到每個報文中出錯數(shù)目小于A對應(yīng)的報文原始數(shù)據(jù)長度"應(yīng)
為
<formula>formula see original document page 20</formula>
其中，w只能為整數(shù)，所以: <formula>formula see original document page 20</formula>
1) (5)
實際使用中，根據(jù)公式(5 )可得到原始數(shù)據(jù)長度n，并可根據(jù)用戶對實 際數(shù)據(jù)丟失概率(即丟包率)的具體需要對"進行適當?shù)男拚?，并可使用FCP 協(xié)議由收發(fā)雙方重新協(xié)商最適合的塊大小和分段大小，以獲得合適的編碼算 法和相應(yīng)的編碼參數(shù)。
實際上，根據(jù)公式(1),可有
<formula>formula see original document page 20</formula>("+ "!
因此，當p很小時，而"合適時，顯然; ,>/7,+1,因此，報文錯誤概率隨著 錯誤的增加而呈現(xiàn)迅速減少的趨勢。
圖9為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼裝置實施例一的結(jié)構(gòu)示意圖。如 圖9所示，本實施例裝置包括協(xié)商發(fā)送模塊11和接收處理模塊12,其中， 協(xié)商發(fā)送模塊11,用于根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法；
接收處理模塊12，用于接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并 根據(jù)所述編碼算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理。
本發(fā)明實施例可以在發(fā)送設(shè)備和接收設(shè)備之間建立協(xié)商機制，根據(jù)網(wǎng)絡(luò) 狀態(tài)協(xié)商發(fā)送設(shè)備和接收設(shè)備之間采用的編碼算法，具體地，本發(fā)明實施例 中各模塊的功能可以通過上述本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼方法實施例一 中的步驟來實現(xiàn)，其可產(chǎn)生與方法實施例相同的技術(shù)效果，在此不在贅述。
圖10為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼裝置實施例二的結(jié)構(gòu)示意圖。具 體地，如圖10所示，本實施裝置包括協(xié)商發(fā)送;f莫塊11、接收處理模塊12、 解碼次數(shù)統(tǒng)計模塊15和判斷^t塊16,其中，
解碼次數(shù)統(tǒng)計模塊15，用于統(tǒng)計對接收到的不同報文進行連續(xù)解碼時未 出現(xiàn)錯誤的解碼次數(shù)；
判斷模塊16,用于判斷所述解碼次數(shù)是否超過預(yù)設(shè)次數(shù)，并將判斷結(jié)果 傳送至協(xié)商發(fā)送模塊11;
協(xié)商發(fā)送模塊11，用于在所述判斷模塊16的判斷結(jié)果為所述解碼次數(shù)超 過預(yù)設(shè)次數(shù)時，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息，所述 編碼協(xié)商請求信息包括編碼算法；
接收處理模塊12,用于接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并 根據(jù)所述編碼算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理。
本發(fā)明實施例可根據(jù)通信鏈路在數(shù)據(jù)傳輸中接收設(shè)備接收的實際需要， 當網(wǎng)絡(luò)狀態(tài)良好時，可在發(fā)送設(shè)備和接收設(shè)備之間建立編碼協(xié)商，以采用新 的編碼算法來實現(xiàn)前向糾錯編碼，其具體實現(xiàn)過程可通過上述本發(fā)明自適應(yīng)
動態(tài)前向糾錯編碼方法實施例二中的步驟來實現(xiàn)，其可產(chǎn)生與方法實施例相 同的技術(shù)效果，在此不再贅述。
圖11為本發(fā)明自適應(yīng)動態(tài)前向糾錯編碼系統(tǒng)實施例的結(jié)構(gòu)示意圖。具體 地，如圖ll所示，本實施例系統(tǒng)包括接收設(shè)備l和發(fā)送設(shè)備2，其中，所述接收設(shè)備l,用于根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備
發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法；接收所述發(fā)
送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼算法對從所述發(fā)送設(shè)備接
收到的報文進行解碼處理；
所述發(fā)送設(shè)備2,用于接收所述接收設(shè)備發(fā)送的所述編碼算法協(xié)商請求信 息，并根據(jù)自身的狀態(tài)返回協(xié)商確認信息。
間建立合適的前向糾錯編碼算法，以適應(yīng)當前網(wǎng)絡(luò)環(huán)境下數(shù)據(jù)的傳輸，提高 數(shù)據(jù)傳輸?shù)男剩渲?，接收設(shè)備可包括上述本發(fā)明自適應(yīng)動態(tài)前向糾錯編 碼裝置實施例中的各模塊，其可以根據(jù)當前網(wǎng)絡(luò)狀態(tài)向發(fā)送設(shè)備發(fā)起編碼協(xié) 商請求。
最后應(yīng)說明的是以上實施例僅用以說明本發(fā)明的技術(shù)方案而非對其進 行限制，盡管參照較佳實施例對本發(fā)明進行了詳細的說明，本領(lǐng)域的普通技 術(shù)人員應(yīng)當理解其依然可以對本發(fā)明的技術(shù)方案進行修改或者等同替換， 而這些修改或者等同替換亦不能使修改后的技術(shù)方案脫離本發(fā)明技術(shù)方案的 精神和范圍。
權(quán)利要求
1、一種自適應(yīng)動態(tài)前向糾錯編碼方法，其特征在于，包括根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法；接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理。
2、 根據(jù)權(quán)利要求l所述的自適應(yīng)動態(tài)前向糾錯編碼方法，其特征在于，還包括若接收到所述發(fā)送設(shè)備返回的重協(xié)商請求信息時，根據(jù)所述重協(xié)商請求信息向所述發(fā)送設(shè)備重新發(fā)起編碼協(xié)商請求信息，其中，所述重協(xié)商請求信息為所述發(fā)送設(shè)備不同意所述編碼算法時，返回的包含新的編碼算法的響應(yīng)信息。
3、 根據(jù)權(quán)利要求l所述的自適應(yīng)動態(tài)前向糾錯編碼方法，其特征在于，所述編碼算法為區(qū)塊碼算法、回旋碼算法、渦輪碼算法、低集成度奇偶校驗碼算法或RAID碼算法。
4、 根據(jù)權(quán)利要求l所述的自適應(yīng)動態(tài)前向糾錯編碼方法，其特征在于，所述通信鏈路為采用PPP協(xié)議進行報文傳輸?shù)逆溌贰?br> 5、 根據(jù)權(quán)利要求l所述的自適應(yīng)動態(tài)前向糾錯編碼方法，其特征在于，所述根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息包4舌當對接收到的報文進行解碼錯誤時，根據(jù)當前網(wǎng)絡(luò)狀態(tài)向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息。
6、 根據(jù)權(quán)利要求l所述的自適應(yīng)動態(tài)前向糾錯編碼方法，其特征在于，所述根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息包括統(tǒng)計對接 到的不同報文進行連續(xù)解碼時未出現(xiàn)錯誤的解碼次數(shù)，判斷所述解碼次數(shù)是否超過預(yù)設(shè)次數(shù)，是則向所述通信鏈路上的所述發(fā)送設(shè)備發(fā)送所述編碼協(xié)商請求信息。
7、 一種自適應(yīng)動態(tài)前向糾錯編碼裝置，其特征在于，包括協(xié)商發(fā)送模塊，用于根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法；接收處理模塊，用于接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理。
8、 根據(jù)權(quán)利要求7所述的自適應(yīng)動態(tài)前向糾錯編碼裝置，其特征在于，還包括解碼次數(shù)統(tǒng)計模塊，用于統(tǒng)計對接收到的不同報文進行連續(xù)解碼時未出現(xiàn)錯誤的解碼次數(shù)；判斷模塊，用于判斷所述解碼次數(shù)是否超過預(yù)設(shè)次數(shù)，是，則將判斷結(jié)果傳送至所述協(xié)商發(fā)送模塊；所述協(xié)商發(fā)送模塊用于在所述判斷模塊的判斷結(jié)果為所述解碼次數(shù)超過預(yù)設(shè)次數(shù)時，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法。
9、 一種自適應(yīng)動態(tài)前向糾錯編碼系統(tǒng)，包括發(fā)送設(shè)備和接收設(shè)備，其特征在于，所述接收設(shè)備，用于根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法；接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理；所述發(fā)送設(shè)備，用于接收所述接收設(shè)備發(fā)送的所述編碼算法協(xié)商請求信息，并根據(jù)自身的狀態(tài)返回編碼協(xié)商確認信息。
全文摘要
本發(fā)明公開了一種自適應(yīng)動態(tài)前向糾錯編碼方法、裝置及系統(tǒng)。該方法包括根據(jù)當前網(wǎng)絡(luò)狀態(tài)，向通信鏈路上的報文發(fā)送設(shè)備發(fā)起編碼協(xié)商請求信息，所述編碼協(xié)商請求信息包括編碼算法；接收所述發(fā)送設(shè)備返回的編碼協(xié)商確認信息，并根據(jù)所述編碼算法對從所述發(fā)送設(shè)備接收到的報文進行解碼處理。該裝置包括協(xié)商發(fā)送模塊和接收處理模塊。本發(fā)明技術(shù)方案可以在發(fā)送設(shè)備和接收設(shè)備之間建立編碼協(xié)商機制，以在雙方之間建立合適的編碼算法，在保證數(shù)據(jù)傳輸可靠性的同時，提高數(shù)據(jù)傳輸?shù)男?，可適應(yīng)各種網(wǎng)絡(luò)環(huán)境下采用前向糾錯編碼進行數(shù)據(jù)傳輸?shù)男枰?br> 文檔編號H04L1/00GK101651519SQ200910092478
公開日2010年2月17日 申請日期2009年9月15日 優(yōu)先權(quán)日2009年9月15日
發(fā)明者劉亞萍, 盧澤新, 廖海寧, 張曉哲, 宏 王, 王寶生, 寧 胡, 酈蘇丹, 琳 陳, 陳曉梅, 靜 陶, 陶孜謹, 龔正虎 申請人:中國人民解放軍國防科學(xué)技術(shù)大學(xué)