專利名稱：一種傳輸報文的方法和裝置的制作方法
技術領域：
本發明涉及數據通信技術領域，特別地涉及一種傳輸報文的方法和裝置。
背景技術：
隨著通訊技術的高速發展，無論是在傳統的低速串行鏈路還是3G等無線 鏈路，基于實時傳送協議RTP( Real Time Protocol)的多Jf某體應用越來越廣泛， RTP報文通常具有負載小的特點，語音報文的負載甚至比其IP/UDP/RTP報文 頭還小，造成了帶寬的很大浪費，為了節省帶寬，通常會使用報文壓縮技術。
目前主流的RTP報文壓縮協議包括壓縮實時傳送協議CRTP、魯棒頭壓 縮RoHC (Robust Header Compression)協議，前者設計之初是為了用于低速串 行鏈路，后經增強型CRTP即ECRTP (Enhanced Compressed RTP)優化增強 后，可適應更廣泛的鏈路環境；后者主要設計用于無線網絡。RoHC協議相比 CRTP在對抗丟包、亂序和保持高壓縮率等方面更強，缺點是實現相比CRTP 復雜的多。
作為主要的頭壓縮4支術之一，CRTP協議可將原始IPv4/UDP/RTP共40個 字節的報文頭壓縮到最小2-4個字節，實際應用中因RTP報文多半攜帶UDP 校驗和，所以最小壓縮報文并不是理論上的2字節，而通常是4字節，其結構 見圖1 ，這種結構的^艮文稱作COMPRESSED—RTP—8或COMPRESSED_RTP—16 報文，該報文由1個字節的上下文標識字段CID字段、1個字節的MSTI字段 和2個字節的UDP校驗和字段組成，MSTI字段在RTP的RTP序列號的一次 差分deltaSN、 RTP時間戳的 一次差分deltaTS 、 IPv4序號字段的 一次差分deltaID 或RTP頭的標志位M字段發生變化時可自動擴展壓縮報頭長而不需要使用其 他類型報文。如果現有的CRTP報文能夠進一步得到壓縮，則可以更加節省帶 寬資源。
發明內容
本發明提供一種傳輸報文的方法和裝置，以使現有技術中的CRTP報文能 夠進一步得到壓縮，以更加節省帶寬資源。
為解決上述問題，本發明提供如下的技術方案 一種傳輸報文的方法，包括
監測待發送的壓縮實時傳送協議CRTP報文的M、 S、 T標志位的值； 在M、 S、 T標志位都為0時，根據會話上下文標識CID、用戶數據才艮文
協議UDP校驗和以及實時傳送協議RTP數據，構造壓縮寺艮文并發送。
所述監測待發送的壓縮實時傳送協議CRTP報文的M、 S、 T標志位之前
還包括根據預設的準則，確認用于發送所述壓縮報文的鏈路的傳輸質量允許
傳輸該壓縮纟艮文。
一種傳輸"R文的裝置，包括
監測模塊，用于監測待發送的壓縮實時傳送協議CRTP報文的M、 S、 T 標志位的值；
壓縮模塊，用于當監測模塊確認待發送的壓縮實時傳送協議CRTP報文的 M、 S、 T標志位都為0時，根據會話上下文標識CID、用戶數據報文協議UDP 校驗和以及實時傳送協議RTP數據，構造壓縮才艮文；
發送模塊，用于發送壓縮模塊構造的壓縮報文。
所述的裝置進一步包括評估模塊，用于根據預設的準則，確認用于發送所 述壓縮報文的鏈路的傳輸質量允許傳輸該壓縮報文。
根據本實施例的技術方案，當確認待發送的壓縮實時傳送協議CRTP報文 的M、 S、 T標志位都為0時，根據CID、 UDP校驗和以及RTP數據構造壓縮 報文。通過這樣的方式，使得在鏈路傳輸質量較好的情況下構造得到的報文比 現有的CRTP報文減少了 l個字節，由此提高了報文的壓縮效率，從而進一步 節省了系統的帶寬資源。
圖1為現有的CRTP報文結構示意圖2為本實施例中的壓縮報文結構示意圖3為IP層、CRTP層、PPP層的關系示意圖4為本實施例中報文壓縮端處理流程圖5為本實施例中報文解壓端處理流程圖6為本實施例中的報文傳輸裝置結構示意圖。
具體實施例方式
下面結合附圖對本發明實施例中的技術方案作出說明。附圖用于幫助理解 實施例的技術方案，在實現中可以不限于附圖所示的形式。
在本實施例中，對于待發送的CRTP報文，對其M、 S、 T標志位進行監 測，如果這些標志位都為0，則根據CID、 UDP校驗和以及RTP數據構造壓縮 報文然后發送。在發送這種壓縮報文之前，可以先對傳輸報文所用的鏈路的質 量進行評估，當確認該鏈路質量較好時再發送這種壓縮報文。另一方面，如果 鏈路的質量較差，則仍然發送現有的4字節CRTP壓縮報文。也就是說本實施 例中的報文傳輸方法可以和現有方法相結合使用。
本實施例中才艮據CID、 UDP 4交—瞼和以及RTP凄史據構造的壓縮凈艮文的結構 如圖2所示，在這里將這種結構的報文稱作COMPRESSED_RTP_X—8或 COMPRESSED—RTP_16報文。與圖1所示的報文結構相比，二者的差別在于 圖2中的壓縮報文不包括MSTI字段和SN字段，于是比圖1所示的報文要少 一個字節。以下對此差別作進一步說明。
在鏈路傳輸質量較好的情況下，報文丟包和亂序不嚴重，傳輸的報文很有 規律，此時M值為O,且報文序號SN、時間戳TS的二次差分為0，于是M、 S、 T標志位都為0，所以在這種的情況下可不必傳輸M、 S、 T標志位。I標志 位因ID字段只用于IP分片用，且CRTP又不處理分片報文，原始CRTP方案
7只是為了實現無損壓縮而被攜帶，并無實際意義，因此可被壓縮端直接舍棄而
不傳輸，至于解壓端則自行根據上下文中最后報文的ID值自動+1或+N處理 即可。4-bit SN字段主要用于丟包統計和Twice算法使用，但因其只占4-bit, 能表示的數值范圍有限，即區間
,解壓端完全可以直接進4亍Twice算法 處理，因沒有具體次數的指示，最多估算16次，帶來的不利影響僅僅是多占 用運算元件的資源。丟包數也能夠通過間接推算得到，所以4-bitSN字段也可 以直接舍棄。
從上面的分析可知，如果M、 S、 T標志位都為0，那么M、 S、 T可以不 必傳輸，而且由于I和壓縮才艮文序號SN也可以不必傳^T, >^人圖1可以看出， M、 S、 T、 I和SN正好占用一個字節，所以在壓縮端可以采用圖2所示的結 構來構造壓縮報文，而在解壓端則有相應的處理方式保證"t艮文的正確傳輸。以 圖3為例，來自IP層的原始的RTP報文在CRTP層的壓縮端被壓縮，壓縮方 式可以選用現有壓縮方式或本實施例中的壓縮方式，然后傳遞l^點到點協i義 PPP層，壓縮報文在PPP層傳輸之后，在CRTP層的解壓端恢復為RTP 4艮文然 后傳遞給IP層作后續處理。另一方面，如果M、 S、 T三個標志位不全為O, 則應當根據圖1的結構來壓縮報文。以下對本實施例中CRTP層的壓縮端以及 解壓端的處理流程作出說明。圖4和圖5分別示出了 CRTP層的壓縮端和解壓 端處理流程的主要步驟。
步驟41:進行PPP鏈路協商。具體地，PPP鏈路的NCP協商字段suboptions 采用新類型值例如3或4，或者是其他新類型值，其他參數采用系統的配置值 或默認值進行協商。對于支持本實施例方法的系統，使用上述新類型值能夠協 商成功。
步驟42:如鏈路協商不成功，則用suboptions為l或2作為協商字l殳重新 發起協商，其后根據現有的CRTP的處理流程進行處理；若鏈路協商成功則轉 入步驟43。
步驟43:當壓縮端收到RTP報文后，構建上下文，然后發送全頭l艮文。可以看出此時系統的工作狀態采用傳統模式。
步驟44:壓縮端開始鏈路質量探測，對當前鏈路傳輸質量進行評估。
步驟45:如果評估結果為鏈路傳輸質量較差，則保持工作狀態為傳統模式， 按照傳統CRTP才幾制運行，否則在步驟44之后轉入步驟46。
步驟46:在評估結果為鏈路傳輸質量較好的情況下，系統工作狀態遷移為 激進模式，在此狀態下系統的做法是監測要發送CRTP報文的M、 S、 T標志 位是否都為0，如果都為0，轉入步驟48，否則轉入步驟47。
步驟47:構造COMPRESSED_RTP_8或COMPRESSED—RTP—16報文， 然后轉入步驟49。在本步驟中，系統的工作狀態與傳統模式有所不同，在此稱 為激進才莫式。
步驟48:構造COMPRESSED—RTP—X_8或COMPRESSED—RTP—X—16報 文。此步驟中即根據圖2所示的結構進行報文構造。 步驟49:調用PPP數據通信接口發送數據包。
從上述流程可以看出，系統的運行可以有兩種模式，分別是傳統模式和激 進模式，二者區別在于按照不同的結構進行報文的構造。系統的運行具體處于 哪種模式中則由鏈路質量探測的結果來決定，并且如果鏈路質量是動態變化， 則系統的運行也可以隨之在兩種狀態之間切換。步驟46中的監測是持續進行 的， 一旦監測到M、 SN、 TS的二次差分為0,則系統立即切換到激進才莫式， 也就是此時要構造COMPRESSED—RTP—8或COMPRESSED—RTP—16報文，以 達到提高壓縮效率，節省帶寬資源的目的。如果在某種環境下能夠保證鏈路質 量持續較好，那么也可以省略對于鏈路質量的監測，也就是系統持續地在激進 模式下運行，直接對M、 SN、 TS的二次差分進行監測。
對于步驟44中的鏈路傳輸質量評估，以下再作出說明。這里對于評估采 用的方法可根據具體系統運行環境，采用任何已有的對于鏈路質量進行評估的 方法，如類似于RFC3545中2.3. Achieving robust operation描述的"N"的 獲取方法，也可以是自定義的方法，如利用過去3或5分鐘內統計到的報文丟失個數，是否達到評定質量好壞的閾值等。而衡量鏈路質量是較好還是較差 的標準，也是與鏈路質量進行評估的方法相對應。比如是單位時間內丟包個數， 也可能是抖動值或者更復雜的計算公式的結果。具有實際意義的評判斷準則需 要根據實際環境進行測試，得出 一個符合系統實際運行狀態的經-驗值。
解壓端處理流程的主要步驟如圖5所示，其中以PPP鏈路的NCP協商新 壓縮類型成功為前提，這里的新壓縮類型指的是^l姿照圖2所示的結構來構造壓 縮報文。
步驟51:接收PPP層傳送的報文。
步驟52 :判斷接收的報文類型，若是現有的CRTP報文即 COMPRESSED—RTP—8或COMPRESSED—RTP— 16類型則4安RFC2508和 RFC3545規范處理，若是新型才艮文即COMPRESSED_RTP_X—8或 COMPRESSED—RTP—X—l6類型，則轉入步驟53 。
步驟53:根據CID查找相應解壓上下文控制塊，如找不到則丟棄該報文， 結束流程；如找到，則轉入步驟54。
步驟54:根據上下文內容的IP/UDP/RTP頭信息、DeltaSN和DeltaTS構 造解壓后的RTP才艮文。
步驟55:對解壓出的RTP報文進行校驗和檢查。校驗可采取對收到的所 有報文都校驗，也可以采取每隔若干報文進行一次校驗，如每隔.6個報文校 驗一次。如果校驗成功則轉入步驟56,否則轉入步驟57。
步驟56:將恢復出的RTP報文交由IP層繼續處理，結束流程。
步驟57:多次啟用Twice算法，對收到的報文進行猜測，直到成功或達到 猜測次數上限。猜測的次數可視處理器性能而定，推薦2-6次之間，而且盡量 猜測后續報文，因PPP作為點到點鏈路，報文亂序的概率通常不高，很可能是 錯誤幀或傳輸過程其他原因導致的偶然丟包。如猜測成功則轉入步驟58，否則 轉入步驟59。
步驟58:將^1文上交IP層繼續處理，結束流程。步驟59:丟棄當前報文，并發送狀態回饋報文請求全頭報文。這里不推薦 每丟失1個報文就發送一次回饋報文，而是至少連續丟失2或3個才發送回饋， 同一會話連續發送回々貴才艮文的速率也要控制，防止形成溢出(Flood )。
基于上述方法，以下對本實施例中的裝置作出說明。本實施例中的裝置可 以利用軟件、硬件或者二者結合的方式實現。以下按功能模塊來劃分裝置結構， 在實現中各模塊可以各自成為設備，或為同一設備的組成部分。本領域普通技
指令相關的硬件來完成，所述的程序可以存儲于一計算機可讀取存儲介質中， 如ROM/RAM、磁碟、光盤等。
如圖6所示，本實施例中的報文傳輸裝置60可以應用在圖3所示的CRTP 層，該裝置包括監測模塊61、壓縮模塊62和發送模塊63。其中，監測模塊61 用于監測待發送的CRTP報文的M、 S、 T標志位的值；壓縮模塊62用于當監 測模塊確認待發送的CRTP報文的M、 S、 T標志位都為0時，根據會話上下 文標識CID、用戶數據報文協議UDP校驗和以及實時傳送協議RTP數據構造 壓縮報文；發送模塊63用于發送壓縮模塊62構造的壓縮報文。
可以看出報文傳輸裝置60可以應用在CRTP層的壓縮端。該裝置還可以 包含一個評估模塊，用于根據預設的準則，確認用于發送壓縮模塊62構造的 壓縮報文的鏈路的傳輸質量允許傳輸該壓縮報文。
報文傳輸裝置60可以進一步包括解壓端的模塊。解壓端的模塊可以是包 括恢復模塊和校驗模塊，其中恢復模塊用于根據CID得出解壓后的RTP報文； 校驗模塊用于對恢復模塊得出的RTP報文進行校驗，以及當確認校驗成功時， 將所述RTP報文交由IP層繼續處理。
解壓端的模塊也可以是包括恢復模塊、校驗模塊和猜測模塊，其中恢復模 塊用于根據CID得出解壓后的RTP報文；校驗模塊用于對該RTP報文進行校 驗，以及當確認校驗不成功時，將該RTP報文交由猜測模塊繼續處理；猜測模 塊用于使用Twice算法對該RTP報文進行猜測，以及當確認在預^i次數內猜測成功時，將該RTP凈艮文交由IP層繼續處理。
解壓端的模塊還可以是包括恢復模塊、校驗模塊、猜測模塊和反饋模塊， 其中恢復模塊用于根據CID得出解壓后的RTP報文；校驗模塊用于對該RTP 報文進行校驗，以及當確認校驗不成功時，將該RTP報文交由猜測模塊繼續處 理；猜測模塊用于使用Twice算法對該RTP報文按照預設的次數進行猜測；反 饋模塊用于當猜測模塊在預設次數內猜測全部失敗時，向報文發送端請求全頭 報文。
根據本實施例的技術方案，當確認待發送的壓縮實時傳送協議CRTP報文 的M、 S、 T標志位都為0時，在構造的壓縮報文中省略M、 S、 T、 I字段和 SN字段，根據CID、 UDP校驗和以及RTP數據構造壓縮報文。在解壓端對報 文進行校驗，在校驗失敗時使用Twice算法進行猜測，若猜測失敗再請求全頭 報文。通過這樣的方式，能夠一方面使得在鏈路傳輸質量較好的情況下提高報 文的壓縮效率，節省帶寬資源，另一方面又能保證"R文的完整、正確傳送。并 且通過鏈路的協商和對收到的報文的類型進行判斷等機制，使本實施例的方案 能與現有的傳輸CRTP報文的技術相兼容，于是能夠充分利用原有CRTP系統 的資源，并提高系統的運行效率。
明的精神和范圍。這樣，倘若本發明的這些修改和變型屬于本發明權利要求及 其等同技術的范圍之內，則本發明也意圖包含這些改動和變型在內。
權利要求
1、一種傳輸報文的方法，其特征在于，監測待發送的壓縮實時傳送協議CRTP報文的M、S、T標志位的值；在M、S、T標志位都為0時，根據會話上下文標識CID、用戶數據報文協議UDP校驗和以及實時傳送協議RTP數據，構造壓縮報文并發送。
2、 根據權利要求1所述的方法，其特征在于，所述監測待發送的壓縮實 時傳送協議CRTP報文的M、 S、 T標志位之前還包括根據預設的準則，確 認用于發送所述壓縮報文的鏈路的傳輸質量允許傳輸該壓縮報文。
3、 根據權利要求1或2所述的方法，其特征在于，發送所述壓縮報文之 后還包括根據所述CID得出解壓后的RTP報文；對所述RTP報文進行校驗，以及當確認校驗成功時，將所述RTP報文交 由IP層繼續處理。
4、 根據權利要求1或2所述的方法，其特征在于，發送所述壓縮報文之 后還包括根據所述CID得出解壓后的RTP報文；對所述RTP報文進行校驗，當確認校驗不成功時，使用Twice算法對所述 RTP報文進行猜測，以及當確認在預設次數內猜測成功時，將所述RTP才艮文交 由IP層繼續處理。
5、 根據權利要求1或2所述的方法，其特征在于，發送所述壓縮報文之 后還包括才艮據所述CID得出解壓后的RTP報文；對所述RTP報文進行校驗，當確認校驗不成功時，使用Twice算法對所述 RTP報文進行猜測，以及當確認在預設次數內猜測全部失敗時，向報文發送端 請求全頭報文。
6、 一種傳輸"f艮文的裝置，其特征在于，監測模塊，用于監測待發送的壓縮實時傳送協議CRTP報文的M、 S、 T 標志4立的4直；壓縮模塊，用于當監測模塊確認待發送的CRTP報文的M、 S、 T標志位 都為0時，4艮據會話上下文標識CID、用戶凄t據才艮文協i義UDP 4交-瞼和以及實 時傳送協議RTP數據，構造壓縮報文；發送模塊，用于發送壓縮模塊構造的壓縮報文。
7、 根據權利要求6所述的裝置，其特征在于，還包括評估模塊，用于根 據預設的準則，確認用于發送所述壓縮報文的鏈路的傳輸質量允許傳輸該壓縮 報文。
8、 根據權利要求6或7所述的裝置，其特征在于，還包括 恢復模塊，用于根據所述CID得出解壓后的RTP報文；校驗模塊，用于對恢復模塊得出的RTP報文進行校驗，以及當確認校驗成 功時，將所述RTP報文交由IP層繼續處理。
9、 根據權利要求6或7所述的裝置，其特征在于，進一步包括恢復模塊、 校驗模塊和猜測模塊，其中恢復模塊，用于根據所述CID得出解壓后的RTP報文；校驗模塊，用于對所述RTP報文進行校驗，以及當確認校驗不成功時，將所述RTP報文交由猜測模塊繼續處理；猜測模塊，用于使用Twice算法對所述RTP報文進行猜測，以及當確認在預設次數內猜測成功時，將所述RTP報文交由IP層繼續處理。
10、 根據權利要求6或7所述的裝置，其特征在于，還包括恢復模塊、校 驗模塊、猜測模塊和反饋模塊，其中恢復模塊，用于根據所述CID得出解壓后的RTP報文； 校驗模塊，用于對所述RTP報文進行校驗，以及當確認校驗不成功時，將 所述RTP報文交由猜測模塊繼續處理；猜測模塊，用于使用Twice算法對所述RTP報文按照預設的次數進行猜觀'j;反饋模塊，用于當猜測模塊在預設次數內猜測全部失敗時，向"R文發送端 請求全頭報文。
全文摘要
本發明提供一種傳輸報文的方法和裝置，以使現有技術中的CRTP報文能夠進一步得到壓縮，以更加節省帶寬資源。實施例中的方法包括監測待發送的壓縮實時傳送協議CRTP報文的M、S、T標志位的值；在M、S、T標志位都為0時，根據會話上下文標識CID、用戶數據報文協議UDP校驗和數據以及實時傳送協議RTP數據，構造壓縮報文并發送。實施例同時給出了相應的裝置。根據實施例的技術方案，使得在鏈路傳輸質量較好的情況下構造得到的報文比現有的CRTP報文減少了1個字節，由此提高了報文的壓縮效率，從而進一步節省了系統的帶寬資源。
文檔編號H04L29/06GK101616164SQ20091016562
公開日2009年12月30日 申請日期2009年8月12日 優先權日2009年8月12日
發明者宇 楊 申請人:中興通訊股份有限公司