專利名稱：用于提供冗余管理的系統(tǒng)和方法
技術領域：
本發(fā)明總體上涉及語音編碼。更具體地，本發(fā)明涉及用于基于IP的語音(VoIP)應用的語音編碼、容4晉性能(error resiliency )和在分組交換網絡上的語音傳輸。
背景技術：
本部分旨在為在權利要求中所陳述的發(fā)明提供背景或者上下 文。此處的描述可以包括可被推行的概念，但是這些概念不必是先 前已經構想出或者已經被推行的概念。因此，除非在此指出，否則術，也不因其被引入本部分而承認是現(xiàn)有技術。在現(xiàn)有的分組交換網絡傳輸協(xié)議中，接收機在其中檢測到比特 差錯的所有IP分組將被移除。換句話說，在接收時如果檢測到差錯， 則協(xié)議棧不會將任何失真的分組傳送給應用層。由于這個原因，當 IP分組在易于發(fā)生差錯的無線鏈路上或者在可能引起差錯的任何媒 介上傳輸時，應用層將面臨某些分組的丟失。相反地，在這樣的方 案中，到達應用層的分組均不包含任何剩余的比特差錯。因為失真的分組沒有傳輸?shù)綉脤?，所以差錯隱藏算法不能利 用部分正確的幀。然而，這樣的丟失幀還必須被替換。當丟失多于 一個的連續(xù)分組時，這種情況甚至變得更加困難。各種方法已經被 引入來應對這樣的分組丟失情況。 一些傳統(tǒng)的方法包括使用多描述 編碼，其中信息被分布于若干IP分組；以及應用層前向糾錯(FEC), 其中FEC信息用來重建丟失的分組。除了上述之外，解決分組丟失問題的另一個方法涉及使用冗余 傳輸。冗余傳輸?shù)膬?yōu)點是低計算要求。冗余傳輸通過簡單地將當前幀和一個或者多個先前幀附加在同一分組內便能實現(xiàn)。對冗余流進行解碼也是非常直接地當一個分組丟失了，接收機只需要等待下 一分組的到來，以便為解碼器獲得相應的幀。然而，幀冗余技術的 一個問題在于導致了比特速率的增大。使用幀冗余，則無論何時將 另一個幀附加到正在討論的IP分組上時，帶寬需求基本上會加倍。 此外，使用幀冗余，則由于接收機需要緩沖語音幀，而會將總延遲 增加與冗余量相等的量。用于冗余傳輸中的編解碼器模式適配和模式選擇的傳統(tǒng)解決方 案通常包括或者保持現(xiàn)有比特速率而簡單地將一個或者多個先前 幀復制到分組，或者另一方面，降低編解碼器比特速率以使得所得 的總速率不顯著增加。例如，當使用AMR編解碼器的窄帶語音呼叫 被建立并且其速率為12.2kbit/s時，100%冗余(即，在傳輸當前幀時 還傳輸一個附加到該分組的先前語音幀)由5.9kbit/s模式實現(xiàn)，這 導致了 11.8kbit/s的比特速率。此外，200%冗余(即，附加了兩個先 前的語音幀)由4.75kbit/s模式實現(xiàn)，這導致了 14.25kbit/s的比特速 率。AMR是音頻數(shù)據(jù)壓縮系統(tǒng)，其使用鏈路適配來基于鏈路狀況從 八個不同比特速率中選4奪一個。例如，就AMR-WB而言，當在 ARM-WB布置中額定速率為12.65kbit/s時，具有最低可行速率 (8.85kbit/s)的100%冗余將導致17.7kbits/s。此外，總有可能的是，選擇的編解碼模式。一種先前建議的用于解決以上所討論問題的系統(tǒng)可以在 www.ietf.org/rfc/rfc3267.txt上找到。在此系統(tǒng)中，發(fā)送機負責基于所 接收到的(例如，在RTCP接收機報告中)、關于正在使用的信道 的反饋，來選擇冗余的合適的量。然而，此系統(tǒng)依賴于反饋，并且 如果來自解碼設備的合適信息沒有被接收到，則可能因此導致出現(xiàn) 問題。因此，期待開發(fā)出能夠解決上述問題的系統(tǒng)和方法。

發(fā)明內容
本發(fā)明的各種實施方式提供了一種用于在語音編碼應用中更有 效地實現(xiàn)冗余管理的系統(tǒng)和方法。根據(jù)本發(fā)明的各種實施方式，發(fā) 送設備選擇與當前傳輸信道條件相適合的冗余傳輸水平，而與此同 時，從可用的編解碼器模式集合中選擇最適合的比特速率。在本發(fā) 明實施方式中，所使用的冗余傳輸水平通常對于所選擇的編解碼器 模式而言是最優(yōu)的，而且無需編解碼器的再協(xié)商。編解碼器模式改 變周期和模式只改變到鄰接模式的局限可能限制多速率編解碼器的
適配速度(其在www.ietf.org/rfc/rfc3267.txt中被討論)。在這種情 況下，當向最優(yōu)編解碼器模式配置步進時，冗余傳輸使用在協(xié)商適 配限制之內的中間模式。本發(fā)明各種實施方式的系統(tǒng)和方法基本上 可以應用于幾乎任何多速率語音編碼器，諸如3GPP自適應多速率 AMR編碼器和AMR-WB編碼器。
通過結合附圖給出的下述具體實施方式
，本發(fā)明的這些和其它 優(yōu)點和功能以及其操作的組織與方式將變得明顯，其中在若干下述 附圖中，類似的元素將具有類似的編號。


圖1示出了用于與本發(fā)明一起使用的一般多媒體通信系統(tǒng)； 圖2是示出了本發(fā)明各種實施方式實現(xiàn)的流程圖； 圖3是可以在本發(fā)明的實現(xiàn)中使用的電子設備的透視圖；以及 圖4是圖3中的移動電話電路的示意表示。
具體實施例方式
本發(fā)明的各種實施方式提供了一種用于在語音編碼應用中更有 效地實現(xiàn)冗余管理的系統(tǒng)和方法。根據(jù)本發(fā)明的各種實施方式，發(fā) 送設備選擇與當前傳輸信道條件相適合的冗余傳輸水平，而與此同 時，從可用的編解碼器模式集合中選擇最適合的比特速率。在本發(fā) 明實施方式中，所使用的冗余傳輸水平通常對于所選擇的編解碼器模式而言是最優(yōu)的，而且無需編解碼器的再協(xié)商。編解碼器模式改 變周期和模式只改變到鄰接模式的局限可能限制多速率編碼器的適配速度(其在www.ietf.org/rfc/rfc3267.txt中凈皮討論)。在這種情況 下，當向最優(yōu)編解碼器模式配置步進時，冗余傳輸使用在協(xié)商適配 限制之內的中間模式。本發(fā)明各種實施方式的系統(tǒng)和方法基本上可 以應用于幾乎任何多速率語音編碼器，諸如3GPP自適應多速率 AMR編碼器和AMR-WB編碼器。圖1示出了用于與本發(fā)明一起使用的一般多媒體通信系統(tǒng)。如 圖1所示，數(shù)據(jù)源100提供模擬格式、非壓縮數(shù)字格式、壓縮數(shù)字 格式或者這些格式的任何組合的源信號。編碼器110將源信號編碼 為已編碼的媒體比特流。該編碼器110可以能夠對一種以上的媒體 類型(諸如音頻和視頻)進行編碼，或者需要多于一個的編碼器110 來對不同媒體類型的源信號進行編碼。編碼器110還可以得到合成 產生的輸入，諸如圖形和文本，或者其可以產生合成媒體的已編碼 比特流。在下文中，只考慮一種媒體類型的一個已編碼的媒體比特 流的處理，以便簡化描述。然而應當注意的是，實時廣播服務典型 地包括若千流(典型地，至少一個音頻流、^L頻流和文本字幕流)。 還應當注意的是，該系統(tǒng)可以包括很多編碼器，但是下文中只考慮 一個編碼器110，以便不失一般性地筒化描述。已編碼的媒體比特流被傳送到存儲設備120。存儲設備120可以 包括任何類型的大規(guī)模存儲器，以存儲已編碼的媒體比特流。存儲 設備120中的已編碼的媒體比特流的格式可以是初級自包含比特流 格式，或者一個或多個已編碼的媒體比特流可以被封裝在容器文件 中。某些系統(tǒng)"直播地"運行，也就是省略存儲，而將已編碼的媒 體比特流從編碼器110直接傳送給發(fā)送機130。隨后根據(jù)需要將該已 編碼的媒體比特流傳送給發(fā)送機130,也叫做服務器。傳輸中所使用 的格式可以是初級的自包含比特流格式、分組流格式，或者一個或 多個已編碼的媒體比特流可以被封裝在容器文件中。編碼器110、存 儲設備120和發(fā)送機130可以處于同一物理設備中，或者它們可以被包含在分離的設備中。編碼器110和發(fā)送機130可以利用直播的 實時內容運行，在這種情況下，典型地不會永久地存儲已編碼的媒 體比特流，而是在內容編碼器110和/或發(fā)送機130中緩沖一小段時 間，以便平滑處理時延、傳送時延和已編碼的媒體比特速率的變化。
發(fā)送機130利用通信協(xié)議棧來發(fā)送已編碼的媒體比特流。該棧 可以包括但不僅限于實時傳輸協(xié)議(RTP )、用戶數(shù)據(jù)報協(xié)議(UDP ) 和互聯(lián)網協(xié)議(IP)。當通信協(xié)議棧為面向分組時，發(fā)送機130將 已編碼的媒體比特流封裝到分組中。例如，當使用RTP時，發(fā)送機 130根據(jù)RTP有效載荷格式將已編碼的媒體比特流封裝到RTP分組 中。典型地，每個媒體類型具有專用的RTP有效載荷格式。還需要 注意的是，系統(tǒng)可以包括多于一個的發(fā)送機130，但是為了簡化，后 續(xù)描述將只考慮一個發(fā)送機130。
發(fā)送機130可以通過通信網絡連接到網關140，或者可以不通過 通信網絡連接到網關140。網關140可以執(zhí)行不同類型的功能，諸如 將根據(jù) 一種通信協(xié)議棧的分組流翻譯為另 一種通信協(xié)議棧、合并以 及拆分數(shù)據(jù)流，以及根據(jù)下行鏈路和/或接收機能力處理數(shù)據(jù)流，諸 如根據(jù)主流的下行鏈路網絡條件控制所轉發(fā)流的比特速率。網關140 的例子包括多點會議控制單元(MCU)、電路交換與分組交換視 頻電話之間的網關、無線一鍵通(PoC)服務器、手持數(shù)字視頻廣播 (DVB-H)系統(tǒng)的IP封裝器，或者將廣播傳輸本地地轉發(fā)到家庭無 線網絡的機頂盒。當使用RTP時，網關140#皮稱為RTP混頻器，并 且作為RTP連接的端點。
可選擇地，已編碼的媒體比特流可以通過其它方式從發(fā)送4幾130 傳送到接收機150,諸如當便攜的大規(guī)模存儲器磁盤或者設備連接到 發(fā)送機130時，將已編碼的媒體比特流存儲在該磁盤或者設備上， 以及隨后將該磁盤或者設備連接到接收機150。
系統(tǒng)包括一個或者多個接收機150,典型地其能夠接收、解調已 傳輸?shù)男盘?，并且將該信號解封裝為已編碼的媒體比特流。解封裝 可以包括移除那些接收機不能解碼或者不希望解碼的數(shù)據(jù)。編解碼器媒體比特流通常進一步由解碼器160處理，其輸出是一個或者多個未壓縮的媒體流。最后，呈現(xiàn)器170可以例如通過揚聲器或者顯 示器重現(xiàn)未壓縮的媒體流。接收機150、解碼器160和呈現(xiàn)器170 可以處于同一物理設備中，或者它們可以被包含在分離的設備中。圖2是示出了本發(fā)明一種具體實施方式
的實現(xiàn)的流程圖。在圖2 中的200，發(fā)送機側的應用層FEC算法確定利用冗余傳輸。在210， 該應用層FEC算法檢查可用的編解碼器模式集合，該集合是根據(jù)與 接收設備的之前會話描述協(xié)議(SDP)提供-應答協(xié)商而設置的。在 220,應用層FEC算法選擇可用的編解碼器模式，該編解碼器模式在 給定的冗余等級條件下同當前的比特速率最佳地匹配。例如，當當 前速率為12.2kbit/s以及協(xié)商得到的可用編解碼器模式為AMR-NB 12.2kbit/s、 7.4kbit/s和4.75kbit/s時,FEC算法分別為100%冗余選 擇7.4kbit/s模式，為200。/。冗余選擇4.75kbit/s。如果如230處所示， 可用的編解碼器模式只包括當前模式，則FEC算法不會改變模式。 另外，如果編解碼器由于編解碼器模式請求信令的限制只能每隔一 幀調整模式，則不能立即執(zhí)行向更低模式的模式改變。當編解碼器 在編解碼器模式適配步長中有限制時，即當編解碼器只能改變到相 鄰的編解碼器模式時，也是如此。因此，如果適用帶寬限制，則僅 在編解碼器已經到達適合于冗余傳輸?shù)钠谕Ｊ綍r，才應用冗余傳 輸。圖3和圖4示出了本發(fā)明可以在其中實現(xiàn)的示意性的電子設備 12。然而應當理解的是，本發(fā)明并非旨在限制于一種具體類型的電 子設備12。圖3和圖4中的電子設備12包括外殼30、液晶顯示器 形式的顯示器32、小鍵盤34、麥克風36、耳機38、電池40、紅外 端口42、天線44、根據(jù)本發(fā)明一個實施方式的UICC形式的智能卡 46、讀卡器48、無線接口電路52、編解碼器電路54、控制器56和 存儲器58。各個電路和元件都是現(xiàn)有技術中已知類型的，例如Nokia 系列的移動電話。在方法步驟的總的上下文中描述了本發(fā)明，其中這些步驟在一個實施方式中可以由程序產品實現(xiàn)，程序產品包括網絡化環(huán)境中的 計算機執(zhí)行的計算機可執(zhí)行指令，諸如程序代碼。通常，程序模塊 包括例程、程序、對象、組件、數(shù)據(jù)結構等等，它們執(zhí)行具體的任 務或者實現(xiàn)具體的抽象數(shù)據(jù)類型。計算機可執(zhí)行指令、相關的數(shù)據(jù)
例。這些可執(zhí)行指令或者相關數(shù)據(jù)結構的特定順序表示用于實現(xiàn)這 些步驟中所描述的功能對應行動的示例。
本發(fā)明的軟件和web實現(xiàn)可以通過標準編程技術完成，其中通 過基于規(guī)則的邏輯和其它邏輯來完成各種數(shù)據(jù)庫查詢步驟、相關步 驟、比較步驟和決策步驟。還需要注意的是，此處所使用的和權利 要求中所使用的詞語"組件"和"模塊"旨在包含使用一行或者 多行軟件代碼的實現(xiàn)、和/或硬件實現(xiàn)、和/或用于接收手動輸入的設 備。
對前述本發(fā)明實施方式的描述是為了示意和描述而給出。并不
述教導修改和變化是可行的，或者可以從本發(fā)明的實踐中得到這種 修改和改變。為了解釋本發(fā)明原理以及其實際應用，選擇并且描述 了實施方式，以便使本領域技術人員能夠在各種實施方式中利用本 發(fā)明，并且做出各種修改以適合于已預期到的特定使用。
權利要求
1. 一種用于在分組交換網絡中實現(xiàn)冗余傳輸?shù)姆椒?，包括確定可用的編解碼器模式，該可用的編解碼器模式是根據(jù)與接收設備的之前協(xié)商設置的；從所述可用的編解碼器模式中選擇一個編解碼器模式；以及依照根據(jù)所選擇的編解碼器模式的特定幀冗余等級來傳輸分組。
2. 如權利要求1所述方法，其中從所述可用的編解碼器模式中選 擇所述所選擇的編解碼器模式，以當使用所述特定幀冗余時與當前 比特速率最接近地匹配。
3. 如權利要求1所述的方法，其中，如果編解碼器適配受到適配 速率的限制，則僅在達到所述所選擇的編解碼器模式之后在所述分 組傳輸中實現(xiàn)所述特定幀冗余。
4. 如權利要求1所述的方法，其中，如果編解碼器適配受到到相 鄰模式的適配步長的限制，則僅在達到所述所選擇的編解碼器模式 之后在所述分組傳輸中實現(xiàn)所述特定幀冗余。
5. 如權利要求1所述的方法，其中，如果可用的編解碼器模式僅 包括當前正在使用的編解碼器模式，則繼續(xù)使用當前正在使用的編 解碼器模式。
6. 如權利要求1所述的方法，其中所述特定幀冗余等級包括100% 冗余。
7. 如權利要求1所述的方法，其中所述特定幀冗余等級包括200%冗余。
8. 如權利要求1所述的方法，其中所述可用編解碼器模式包括 3GPP AMR編解碼器模式。
9. 如權利要求1所述的方法，其中所述可用編解碼器模式包括 AMR-WB編解碼器一莫式。
10. 如權利要求1所述的方法，其中所述之前協(xié)商包括會話描述 協(xié)議(SDP)提供-應答協(xié)商。
11. 一種設備，包括 處理器；以及存儲器單元，其可通信地連接到所述處理器并包括用于確定可用的編解碼器模式的計算機代碼，可用的編解碼器模式是根據(jù)與接收設備的之前協(xié)商設置的；用于從所述可用的編解碼器模式中選擇一個編解碼器模式的計算機代碼；以及用于依照根據(jù)所選擇的編解碼器模式的特定幀冗余等級來 傳輸分組的計算機代碼。
12. 如權利要求11所述的設備，其中從所述可用的編解碼器模式 中選擇所述所選擇的編解碼器模式，以當使用所述特定幀冗余時與 當前比特速率最4妻近地匹配。
13. 如權利要求11所述的設備，其中，如果編解碼器適配受到適 配速率的限制，則僅在達到所述所選擇的編解碼器模式之后在所述 分組傳輸中實現(xiàn)所述特定幀冗余。
14. 如權利要求11所述的設備，其中，如果編解碼器適配受到到 相鄰模式的適配步長的限制，則僅在達到所述所選擇的編解碼器模 式之后在所述分組傳輸中實現(xiàn)所述特定幀冗余。
15. 如權利要求11所述的設備，其中，如果可用的編解碼器模式 僅包括當前正在使用的編解碼器模式，則繼續(xù)使用當前正在使用的 編解碼器模式。
16. 如權利要求11所述的設備，其中所述特定幀冗余等級包括 100%冗余。
17. 如權利要求11所述的設備，其中所述特定幀冗余等級包括 200%冗余。
18. 如權利要求11所述的設備，其中所述可用編解碼器模式包括 3GPP AMR編解碼器模式。
19. 如權利要求11所述的設備，其中所述可用編解碼器模式包括 AMR-WB編解碼器模式。
20. 如權利要求11所述的設備，所述之前協(xié)商包括會話描述協(xié)議 (SDP)提供-應答協(xié)商。
21. —種計算機程序產品，其實現(xiàn)在計算機可讀介質上，用于在 分組交換網絡中實現(xiàn)冗余傳輸，包括用于確定可用的編解碼器模式的計算機代碼，可用的編解碼器模 式是根據(jù)與接收設備的之前協(xié)商設置的；用于從所述可用的編解碼器模式中選擇一個編解碼器模式的計 算機代碼；以及用于依照根據(jù)所選擇的編解碼器模式的特定幀冗余等級來傳輸 分組的計算機代碼。
22. 如權利要求21所述的計算機程序產品，其中從所述可用的編 解碼器模式中選擇所述所選擇的編解碼器模式，以當使用所述特定 幀冗余時與當前比特速率最接近地匹配。
23. 如權利要求21所述的計算機程序產品，其中，如果編解碼器 適配受到適配速率的限制，則僅在達到所述所選擇的編解碼器模式 之后在所述分組傳輸中實現(xiàn)所述特定幀冗余。
24. 如權利要求21所述的計算機程序產品，其中，如果編解碼器 適配受到到相鄰模式的適配步長的限制，則僅在達到所述所選擇的 編解碼器模式之后在所述分組傳輸中實現(xiàn)所述特定幀冗余。
25. 如權利要求21所述的計算機程序產品，其中，如果可用的編 解碼器模式僅包括當前正在使用的編解碼器模式，則繼續(xù)使用當前 正在使用的編解碼器模式。
26. 如權利要求21所述的計算機程序產品，其中所述特定幀冗余 等級包括100%冗余。
27. 如權利要求21所述的計算機程序產品，其中所述特定幀冗余 等級包括200%冗余。
28. 如權利要求21所述的計算機程序產品，其中所述可用編解碼 器模式包括3GPP AMR編解碼器模式。
29. 如權利要求21所述的計算機程序產品，其中所述可用編解碼器模式包括AMR- WB編解碼器模式。
30. —種設備，包括用于確定可用的編解碼器模式的裝置，可用的編解碼器模式是根 據(jù)與接收設備的之前協(xié)商設置的；用于從所述可用的編解碼器模式中選擇一個編解碼器模式的裝 置；以及用于依照根據(jù)所選擇的編解碼器模式的特定幀冗余等級來傳輸 分組的裝置。
31. 如權利要求30所述的設備，其中從所述可用的編解碼器模 式中選擇所述所選擇的編解碼器模式，以當使用所述特定幀冗余時 與當前比特速率最接近地匹配。
全文摘要
一種在語音編碼應用中有效實現(xiàn)冗余管理的系統(tǒng)和方法。根據(jù)本發(fā)明的各種實施方式，發(fā)送設備選擇與當前傳輸信道條件相適合的冗余傳輸水平，而與此同時，從可用的編解碼器模式集合中選擇最適合的比特速率。在本發(fā)明實施方式中，所使用的冗余傳輸水平通常對于所選擇的編解碼器模式而言是最優(yōu)的，而且無需編解碼器的再協(xié)商。
文檔編號G10L19/14GK101536088SQ200780041638
公開日2009年9月16日 申請日期2007年9月26日 優(yōu)先權日2006年9月26日
發(fā)明者A·拉卡涅米, P·奧雅拉 申請人:諾基亞公司