[發(fā)明專利]限制帶寬的方法及裝置

有效

• 申請?zhí)枺?/td>: 200710030022.2
• 申請日: 2007-08-28
• 公開（公告）號: CN101119300A
• 公開（公告）日: 2008-02-06
• 發(fā)明（設計）人: 王莉麗
• 申請（專利權）人: 華為技術有限公司
• 主分類號: H04L12/56
• 分類號: H04L12/56
• 代理公司: 廣州三環(huán)專利代理有限公司
• 代理人: 郝傳鑫

技術領域

本發(fā)明涉及通信領域，尤其涉及一種限制帶寬的方法及一種帶寬限制裝置。

背景技術

目前，在下一代網(wǎng)絡(Next?GenerationNet，NGN)的承載網(wǎng)絡中，很多運營商存在著傳輸資源缺乏的情況，而在因特網(wǎng)協(xié)議(Internet?Protocol，IP)的NGN業(yè)務中，對于好的語音編碼算法，每個語音報文中的語音數(shù)據(jù)一般小于30字節(jié)，而報文報頭就將近40個字節(jié)，報文報頭一般包括IP報文報頭、用戶數(shù)據(jù)報協(xié)議(User?Datagram?Protocol，UDP)報文報頭、實時傳輸協(xié)議(Real-timeTransport?Protocol，RTP)報文報頭等，因此會導致報頭開銷太大，傳輸效率太低的問題?；诖饲闆r，因特網(wǎng)工程任務組(Internet?Engineering?Task?Force，IETF)開發(fā)了一系列請求注解(Request?For?Comments，RFC)來解決這個問題，其中包括RFC2508描述的實時壓縮協(xié)議(Compressed?Real-time?Protocol，cRTP)，cRTP可以將IP/UDP/RTP報文報頭由40個字節(jié)壓縮至2-4個字節(jié)，對于有效載荷僅為15-30字節(jié)的RTP報文來說，可以極大地降低報文的冗余度，提高傳輸帶寬的利用率，從而在很大程度上解決了傳輸資源缺乏的問題。

上述cRTP的基本算法由如下過程來實現(xiàn)：

從壓縮端來看，IP/UDP/RTP報文報頭有一半的字節(jié)在報文處理的整個連續(xù)期間保持不變，如源IP地址、目的IP地址、UDP源端口號、UDP目的端口號等，盡管每個報文中總有幾個字節(jié)要發(fā)生變化，如IP報文的身份信息、RTP報文的時間戳(Timestamp)等，但報文與報文之間的區(qū)別通常是固定的，因此其二次差分為0。壓縮端可以在發(fā)送一次未壓縮報頭(FULL_HEADER)之后，將未變化的報頭字段從其后的報文報頭中壓縮剔除，其余的壓縮來自于對變化字段進行差分編碼以減少報文長度，此外，IP報文報頭以及UDP報文報頭中的長度字段可由鏈路層長度計算單元計算得到，因此也可以被壓縮剔除。通過維護壓縮端和解壓端共享的未壓縮報頭與一次差分序列，所需通信的即只有二次差分為0的信息了。

從解壓端來看，有兩點：

第一，若不考慮任何信息丟失，解壓端在收到一個壓縮包后，可以通過將一次差分結果疊加到未壓縮報頭來重建原報文報頭。在考慮到每條鏈路需要承載多條語音會話(例如一條2兆的E1鏈路一般要承載200-300條語音會話)，IP/UDP/RTP報文的壓縮也需要為多個會話上下文維護狀態(tài)。每一個會話上下文由五元組(即源IP地址、目的IP地址、UDP源端口號、UDP目的端口號以及RTP的SSRC字段定義)組成，壓縮端可對這些五元組字段使用哈希函數(shù)來檢索存儲的會話上下文列表。壓縮包攜帶一個稱為會話上下文標識符的小整數(shù)來指示該壓縮包屬于哪個會話上下文，解壓端可以使用會話上下文標識符直接在會話上下文列表中檢索；

第二，若考慮報文被壓縮后丟包的現(xiàn)象，或報文亂序或壓縮包被損壞的情況，解壓端將無法正確地解壓以及更新會話上下文信息，從而造成后續(xù)的壓縮報文在解壓端被丟棄，針對這種情況，cRTP提供了相應的機制去監(jiān)測會話上下文信息的錯誤并進行修復，即解壓縮端向壓縮端發(fā)送會話上下文信息更新請求(CONTEXT_STATE)來修復會話上下文信息。但是由于這種監(jiān)測只有解壓失敗時才能觸發(fā)，且壓縮端收到CONTEXT_STATE報文后才能發(fā)送未壓縮報頭(FULL_HEADER)來更新會話上下文信息，這個過程中解壓縮端已經(jīng)丟棄了部分壓縮報文，因此必須減少壓縮端會話上下文信息不同步的可能。

另外，cRTP的報文壓縮率受很多因素影響，如所選擇的點對點協(xié)議(Pointto?Point?Protocol，PPP)封裝結構、待壓縮報文報頭字段的變動大小、RTP報文所承載的話音路數(shù)、鏈路的差錯率等。因此報文的壓縮率在實際進行壓縮前只能做比較粗糙的估計，而不能完全精確的預測。

關于cRTP壓縮與服務質量(Quality?of?Service，QoS)隊列調度配合處理的情況，主要是指，在報文流出口配置了cRTP壓縮功能，同時對被壓縮的報文流進行了帶寬限制，例如：報文流出口的實際物理帶寬為2兆，而將cRTP壓縮的報文流限制在1兆以內。其中，帶寬限制就是在壓縮后的報文流傳輸所占據(jù)的實際物理帶寬。cRTP壓縮與QoS隊列調度中的帶寬限制的順序有如下兩點說明：