專利名稱：寬帶無線通信系統(tǒng)中用于壓縮首標的裝置和方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及在無線通信系統(tǒng)中用于壓縮首標的裝置和方法。特別地，本發(fā)明涉及在寬帶無線通信系統(tǒng)中用于壓縮首標的裝置和方法。
背景技術(shù)：
通常，無線通信系統(tǒng)提供使用戶無論在何處都能夠利用用戶站(SS)執(zhí)行通信的方法。已經(jīng)利用各種多址方案開發(fā)了所述的無線通信系統(tǒng)以適應(yīng)多個用戶。碼分多址(CDMA)方案是用于所述無線通信系統(tǒng)的典型多址方案。所述的CDMA方案已經(jīng)從用于語音通信的早期版本演變到用于高速數(shù)據(jù)處理的最新版本。所述CDMA方案得到發(fā)展的部分原因是由于對高速數(shù)據(jù)傳輸不斷增加的用戶需求以及通信技術(shù)的快速進步。隨著其技術(shù)的發(fā)展，所述的CDMA方案現(xiàn)在已經(jīng)被采納為大部分第三代(3G)移動通信系統(tǒng)的標準，并且已經(jīng)進入商業(yè)化階段。
然而，所述的CDMA方案由于有限的資源而在高速數(shù)據(jù)傳輸方面受到限制。但是，用戶所需要的數(shù)據(jù)速率顯示出增加的趨勢。因此，在無線通信領(lǐng)域，人們正在開展各種研究和嘗試以便高速地傳輸數(shù)據(jù)。
作為實例，現(xiàn)在正在開展基于寬帶無線通信技術(shù)的正交頻分多址(OFDMA)方案的研究。所述的OFDMA方案利用正交頻率配置多個信道，并且將一個或多個信道分配給單個用戶用于數(shù)據(jù)傳輸。IEEE 802.16系統(tǒng)是基于OFDMA方案的典型系統(tǒng)。
在起初旨在提供高速數(shù)據(jù)業(yè)務(wù)的所述IEEE 802.16系統(tǒng)中，人們在提供數(shù)據(jù)業(yè)務(wù)的方法方面正在開展大量的研究工作。然而，所述無線通信系統(tǒng)提供語音業(yè)務(wù)作為它的基本通信業(yè)務(wù)。因此，也允許所述的IEEE 802.16系統(tǒng)基于因特網(wǎng)協(xié)議(IP)提供語音業(yè)務(wù)?，F(xiàn)在將對IEEE 802.16系統(tǒng)中提供基于IP的語音業(yè)務(wù)的協(xié)議配置進行描述。
圖1是IEEE 802.16系統(tǒng)中提供基于IP的分組語音業(yè)務(wù)的無線通信網(wǎng)絡(luò)協(xié)議配置的圖示?，F(xiàn)在將參考圖1對IEEE 802.16系統(tǒng)中提供基于IP的分組語音業(yè)務(wù)的無線通信網(wǎng)絡(luò)協(xié)議配置進行描述。
將從它的上一層開始對所述的協(xié)議配置進行描述。如圖1所示，從多媒體應(yīng)用層遞送到較低層的數(shù)據(jù)包括語音、視頻和文本數(shù)據(jù)。以有效載荷格式108配置這樣的純數(shù)據(jù)，然后將其遞送到實時傳輸協(xié)議(RTP)層107。然后RTP層107把RTP首標添加到所接收的有效載荷格式數(shù)據(jù)上，并且把已添加RTP首標的數(shù)據(jù)提供給用戶數(shù)據(jù)報協(xié)議(UDP)層106。RTP控制協(xié)議(RTCP)層109用于提供RTP層107的控制信息。UDP層106把UDP首標添加到所收集的數(shù)據(jù)上，將其轉(zhuǎn)換為UDP格式數(shù)據(jù)。將已添加UDP首標的數(shù)據(jù)遞送給IP層105，IP層105進一步在其上添加IP首標并將已添加IP首標的數(shù)據(jù)遞送給匯聚子層業(yè)務(wù)接入點(CS-SAP)104。
CS-SAP 104將所接收數(shù)據(jù)遞送到匯聚子層(CS)103。匯聚子層103根據(jù)預(yù)定準則對從其上層接收的分組進行分類。用于所述分組分類的準則包括發(fā)送者的IP地址、接收者的IP地址、UDP端口、IP服務(wù)類型等。在所述的IP和UDP首標中包含了這些值，匯聚子層103從上層提供的分組數(shù)據(jù)單元(PDU)中提取這些值，并用所提取的值對分組進行分類。在對所接收分組進行分類以后，匯聚子層103將已分類的分組映射給它們的適當?shù)牧?，在其上添加連接標識符(ID)，并且將已添加連接ID的分組通過媒介訪問控制-服務(wù)訪問點(MAC-SAP)102遞送給其下面的媒介訪問控制(MAC)子層101。
在前述的協(xié)議配置中，以與前述過程相反的過程執(zhí)行接收數(shù)據(jù)和處理所述接收數(shù)據(jù)的過程。
上層(諸如IP層105、UDP層106和RTP層107)的首標字段包含呼叫建立期間所確定的值，這些值保持不變直到所述呼叫結(jié)束。因此，發(fā)送者和接收者可能都存儲了這些值，并且在無線區(qū)段中，僅僅發(fā)送除這些值以外的隨每個分組變化的值。在這種情況下，所述接收者用以前存儲的值來恢復(fù)所接收的分組，從而重新配置它的原始首標。在這種方式中，不要求所述接收者讀取所述的首標信息，于是減小了在所述無線區(qū)段中發(fā)送的數(shù)據(jù)量?？s減所述首標信息的原因如下。
在語音編解碼中，每一幀產(chǎn)生20字節(jié)的數(shù)據(jù)。然而，通過RTP層107、UDP層106和IP層105所添加的首標信息量是40字節(jié)。因此，所述首標的大小是實際傳輸語音數(shù)據(jù)大小的兩倍。因而，為了提高無線區(qū)段中的資源利用效率，減小所述首標的長度非常重要。
為了減小首標的長度，當前的802.16標準定義了僅發(fā)送剩余部分的有效載荷首標抑制(PHS)方案，在無線區(qū)段，根據(jù)呼叫建立期間所預(yù)定的準則在發(fā)送時排除相應(yīng)部分的首標。
以下描述所述的PHS方案。在圖1的協(xié)議配置中，匯聚子層103是插在MAC子層101和諸如IP層105的其上層之間的協(xié)議。匯聚子層103根據(jù)諸如服務(wù)類型的所述準則對從上層協(xié)議接收的分組進行適當?shù)胤诸?，將已分類的分組映射到與它們相關(guān)聯(lián)的MAC流，并且經(jīng)由MAC-服務(wù)訪問點(MAC-SAP)102將已映射的分組遞送到MAC子層101。除了這個基本功能以外，所述的802.16標準把所謂的PHS功能添加到MAC子層103，以便匯聚子層103從由上層接收的PDU中的上層首標部分去掉由于交疊所產(chǎn)生的不必要部分，并且僅發(fā)送剩余部分，因此增加了資源利用效率。
現(xiàn)在將參考圖2A和2B對所述的PHS方案的操作過程進行詳細地描述。圖2A和2B是針對IEEE 802.16系統(tǒng)中提出的基于PHS的首標壓縮/解壓縮的發(fā)送者和接收者的操作流程。以下將參考圖2A首先描述發(fā)送者的操作。
如果在步驟201中從上層來了分組，發(fā)送者前進到步驟202中，它對所述分組進行分類并且讀取以下五種值以便壓縮相應(yīng)分組的首標。
a.PHSF(PHS字段)b.PHSI(PHS索引)c.PHSM(PHS掩碼)d.PHSS(PHS大小)e.PHSV(PHS驗證)基站(BS)和用戶站(SS)在呼叫建立期間預(yù)定所述的五種值。當設(shè)置了所述的PHSV值時，所述的發(fā)送者執(zhí)行分組驗證。然而，當沒有設(shè)置這個值時，所述發(fā)送者不使用所述的驗證過程。因此，所述發(fā)送者在步驟203中檢查所述PHSV值以確定是否有必要進行分組驗證。如果所述的分組驗證有必要，所述發(fā)送者前進到步驟204，否則前進到步驟206。
在步驟204中，所述發(fā)送者用PHSF和PHSM值驗證所述分組。在所述驗證之后，所述發(fā)送者在步驟205中確定所述分組是否已經(jīng)通過所述驗證。如果在步驟205中確定所述驗證是成功的，即所述分組已經(jīng)通過了所述驗證，所述發(fā)送者前進到步驟206。否則，所述發(fā)送者前進到步驟207。
就是說，當所述發(fā)送者不執(zhí)行所述的分組驗證或者當所述驗證成功(如果執(zhí)行)時，它前進到步驟206。在步驟206中，所述發(fā)送者利用所述的PHSM值去除與所述首標相應(yīng)的字節(jié)并且設(shè)置PHSI值。然而，在步驟207中，所述發(fā)送者設(shè)置所述的PHSI值為‘0’并且不執(zhí)行所述的首標去除(或首標壓縮)。在步驟206或207中設(shè)置了所述的PHSI值之后，所述發(fā)送者前進到步驟208，將所述的PHSI值添加到從上層接收的所述分組，并且在步驟209中將已添加PHSI的分組提供給MAC-SAP 102。
接下來，以下將參考圖2B描述接收者的操作。
如果以前述方式配置的所述分組無線地到達了接收者，在步驟210中，MAC-SAP 102接收所述分組，利用所接收的分組配置PDU，并且將所述PDU遞送給它上面的匯聚子層103。一旦所述的PDU分組到達，匯聚子層103前進到步驟211，檢查所述分組的連接ID，并且從中提取PHSI值。之后，在步驟212中，所述接收者讀取接收分組的PHSF、PHSI、PHSM、PHSS、PHSV值。之后，在步驟213中，所述接收者利用所讀取的值重新配置在發(fā)送期間從所述首標去除的所述內(nèi)容。以這種方式，即使所述發(fā)送者去除首標，所述接收者也能夠完全接收相應(yīng)分組。在重新配置所述首標后，所述接收者前進到步驟214，經(jīng)由CS-SAP 104將已恢復(fù)首標的分組提供給上層。
現(xiàn)在將參考圖3對去除和恢復(fù)首標的方法進行描述。圖3是基于IEEE802.16系統(tǒng)中的PHS方案描述首標去除/恢復(fù)方案的概念圖。
發(fā)送者利用其PHSM值302去除發(fā)送分組301中的首標311的一部分。例如，如果設(shè)置所述PHSM的特定比特為‘1’，圖3中所述的方案去除所述首標311的相應(yīng)字節(jié)，并且僅發(fā)送剩余部分。因此，所述發(fā)送者利用所述的PHSM值確定是否發(fā)送所述的首標。首標去除后的所述剩余部分，即實際發(fā)送首標303，包括PHSM比特沒有設(shè)置為‘1’的部分。
因此，在無線區(qū)段所發(fā)送的分組變成具有簡化首標的分組304。一旦接收了所發(fā)送的分組，接收者必須恢復(fù)所述首標。
一旦通過所述無線區(qū)段接收了具有簡化首標的分組304，所述接收者必須恢復(fù)所述的首標。因此，所述接收者利用以前存儲在其中的PHSM 305確定要恢復(fù)的部分。即，所述PHSM比特設(shè)置為‘1’的部分成為要恢復(fù)的部分。在確定了要恢復(fù)的所述部分之后，所述接收者通過把以前在其中存儲的部分306和所接收部分304組合起來能夠獲得恢復(fù)的原始首標317。所述接收者在傳輸分組307中將所恢復(fù)的首標317遞送給上層。
圖4中給出了匯聚子層103的不同分組格式，一種情況是執(zhí)行所述首標去除，另一種情況是不執(zhí)行所述首標去除。
當不執(zhí)行所述首標去除時，匯聚子層103將PHSI＝0401附加到IP分組402的頭部，并且將所得分組遞送給MAC層。然而，當執(zhí)行所述首標去除時，匯聚子層103將PHSI設(shè)置為適當?shù)姆橇阒?PHSI≠0)，將PHSI≠0403附加到首標已去除(或首標已壓縮)的IP分組404的頭部，并且將所得分組遞送給MAC層。
然而，當前IEEE 802.16標準所定義的匯聚子層103有以下兩個問題。第一，所述的PHS方案(它是匯聚子層103所支持的首標長度減小方案)能夠減小所述首標的量是非常小的，使得很難有效利用無線資源。第二，除了在匯聚子層103中執(zhí)行的所述PHS方案以外，不支持其它的首標壓縮方案。下面將詳細描述這些問題。
PHS性能問題IEEE 802.16標準中支持的所述PHS方案也能減小無線區(qū)段中所發(fā)送的IP/UDP/RTP首標的長度。然而，通過所述PHS方案所能減小的首標量不大于通過諸如魯棒首標壓縮(ROHC)或增強壓縮實時協(xié)議(ECRTP)的首標壓縮方案所能減小的首標量?，F(xiàn)在將描述利用所述PHS方案在具有圖5格式的RTP協(xié)議首標上執(zhí)行首標去除的方法。
圖5是一般RTP首標的內(nèi)部格式圖。圖6是在利用所述PHS方案在一般RTP首標上執(zhí)行首標去除之后所獲得的內(nèi)部格式圖。
現(xiàn)在將描述如圖6所示利用所述PHS方案去除圖5的RTP首標部分的方法。在所述的RTP首標中，不能去除與具有在以前分組相應(yīng)字段值上增加1的值的‘序列號’字段607和可能具有與以前分組不同值的‘時間戳’字段608相對應(yīng)的部分。因此，應(yīng)當一直發(fā)送這些部分。雖然理論上能夠去除‘有效載荷類型’字段606，因為一旦建立了因特網(wǎng)協(xié)議之上的語音(VoIP)呼叫，它的值保持不變，但是仍不可能去除‘有效載荷類型’字段606，因為與‘有效載荷類型’字段606共用相同的字節(jié)并且對應(yīng)于最高有效比特(MSB)的‘標記’字段605的值可能經(jīng)歷在逐個分組的基礎(chǔ)上的改變。
因此，利用在逐個字節(jié)基礎(chǔ)上操作的所述PHS方案不可能去除‘有效載荷類型’字段606。
結(jié)果，通過所述PHS方案能夠去除的所述字段包括總共5個字節(jié)‘版本’字段601、‘P’字段602、‘X’字段603、‘CC’字段604和‘同步源標識符’字段609。在去除了由PHSM表示的所述首標之后，通過所述無線區(qū)段實際發(fā)送的所述RTP首標的長度為7字節(jié)。
現(xiàn)有的首標壓縮方案支持問題為了增加在無線區(qū)段的傳輸效率，有必要使用其它的首標壓縮方案代替IEEE 802.16標準中定義的所述PHS方案。然而，當前IEEE 802.16標準中定義的匯聚子層103不能支持這種首標壓縮方案。在接收了來自上面的IP層的分組之后，匯聚子層103從IP、UDP和RTP首標中提取諸如IP地址、UDP端口號和服務(wù)類型(TOS或DSCP)等信息，并且基于所提取的信息將從其上層接收的分組映射到MAC層101的適當?shù)牧?。從所述首標中提取必要信息、辨別分組并且將所述分組映射到MAC層的流的過程被稱為“分類過程”。當不應(yīng)用所述PHS方案或其它首標壓縮方案而發(fā)送所述全首標時，匯聚子層103從自上層接收的IP/UDP/RTP首標中提取必要的信息，并且將所述首標和所述有效載荷都提供給MAC層101，以便允許MAC層101在無線區(qū)段發(fā)送所述分組。然而，當使用所述PHS方案時，匯聚子層103在所述分類過程中從自上層接收的IP/UDP/RTP首標中提取必要信息，根據(jù)在呼叫建立期間預(yù)先定義的PHSM值去除不必要的首標部分，并且將所述剩余首標和所述有效載荷提供給MAC層101，以便允許MAC層101在無線區(qū)段發(fā)送所述分組。
因為匯聚子層103使用前述的首標壓縮方案，所以難以應(yīng)用另一個首標壓縮方案。即，如果匯聚子層103使用另一個首標壓縮方案，它不能確定所接收分組是否是壓縮分組。即使匯聚子層103能夠確定所接收分組是否為壓縮分組，匯聚子層103在所述分類過程中不能從壓縮首標提取必要的信息，除非它解壓縮了壓縮首標。

發(fā)明內(nèi)容
因此，本發(fā)明的目的是提供具有能夠支持可比IEEE 802.16系統(tǒng)高的首標壓縮率的協(xié)議層配置的首標壓縮裝置和方法。
本發(fā)明的另一個目的是提供與IEEE 802.16系統(tǒng)中其它首標壓縮方案兼容的首標壓縮裝置和方法。
本發(fā)明的進一步目的是提供在寬帶無線通信系統(tǒng)中通過首標壓縮來提高無線帶寬效率的裝置和方法。
根據(jù)本發(fā)明的一個方面，提供在寬帶無線通信系統(tǒng)中壓縮首標的發(fā)送裝置。所述裝置包括首標壓縮協(xié)議層，用于在初始發(fā)送時，一旦從上層接收到添加了實時傳輸協(xié)議(RTP)首標、用戶數(shù)據(jù)報協(xié)議(UDP)首標和因特網(wǎng)協(xié)議(IP)首標的分組，則在不壓縮所述首標的情況下發(fā)送所述接收分組，并且在下一次發(fā)送時，根據(jù)在因特網(wǎng)技術(shù)中提供的壓縮方案壓縮所述首標；以及首標壓縮匯聚子層，用于根據(jù)從所述首標壓縮協(xié)議層接收的初始首標信息對所述分組進行分類，存儲所述分組分類的映射信息，并且利用所述映射信息對首標壓縮的分組執(zhí)行分組分類。
根據(jù)本發(fā)明的另一個方面，提供一種在寬帶無線通信系統(tǒng)中壓縮首標的發(fā)送方法。所述方法包括，在初始發(fā)送期間，一旦從上層接收到添加了實時傳輸協(xié)議(RTP)首標、用戶數(shù)據(jù)報協(xié)議(UDP)首標和因特網(wǎng)協(xié)議(IP)首標的分組，則在不壓縮所述首標的情況下發(fā)送所述接收分組。根據(jù)在初始發(fā)送期間的首標信息對所述分組進行分類，并且存儲用于所述分組分類的映射信息。根據(jù)在因特網(wǎng)技術(shù)中提供的壓縮方案壓縮所述首標。該壓縮方案在所述初始發(fā)送之后在從上層接收的所述首標信息中提取不隨每個分組而改變的信息，并且根據(jù)所提取的信息去除首標。利用所存儲的映射信息對所述壓縮的首標執(zhí)行分組分類，并且發(fā)送所述分類的分組。


在所述附圖中，相似的參考標號應(yīng)當理解為指相似的部件、元件和結(jié)構(gòu)。從結(jié)合所述附圖的以下詳細描述中，本發(fā)明的以上和其它的示例目的、特征和優(yōu)點將變得更加顯而易見。其中圖1是在IEEE 802.16系統(tǒng)中用于提供基于IP的分組語音業(yè)務(wù)的無線通信網(wǎng)絡(luò)的協(xié)議配置圖；圖2A和2B是在IEEE 802.16系統(tǒng)中建議的基于PHS的首標壓縮/解壓縮的發(fā)送者和接收者的操作流程圖；
圖3是描述在IEEE 802.16系統(tǒng)中基于PHS方案的首標去除/恢復(fù)方案的概念圖；圖4是根據(jù)現(xiàn)有技術(shù)的在IEEE 802.16系統(tǒng)中匯聚子層的分組格式圖；圖5是一般RTP首標的內(nèi)部格式圖；圖6是在利用所述PHS方案對所述一般RTP首標執(zhí)行首標去除之后獲得的內(nèi)部格式圖；圖7是利用ROHC或ECRTP方案對圖5的所述一般RTP首標執(zhí)行首標去除之后獲得的內(nèi)部格式圖；圖8是根據(jù)本發(fā)明示例實施例的在寬帶無線通信系統(tǒng)中用于首標壓縮的協(xié)議配置圖；圖9是根據(jù)本發(fā)明示例實施例的首標已壓縮的分組的格式圖；圖10A和10B是根據(jù)本發(fā)明示例實施例的說明首標壓縮/解壓縮過程的流程圖；具體實施方式
現(xiàn)在將參考附圖詳細描述本發(fā)明的某些示例實施例。在所述圖中，相同或相似的元件被記為相同的參考標號即使它們是在不同的圖中。在以下描述中，為了清楚和簡潔起見省略了對其中眾所周知功能和配置的詳細描述。
本發(fā)明示例實施例提供了支持各種首標壓縮技術(shù)的新匯聚子層的功能、分組格式和操作過程。
圖8是根據(jù)本發(fā)明實施例的在寬帶無線通信系統(tǒng)中用于首標壓縮的協(xié)議配置圖。
將從它的上層開始對所述的協(xié)議配置進行描述。結(jié)合圖1所述，從多媒體應(yīng)用層遞送到它的下層的數(shù)據(jù)包括語音、視頻和文本數(shù)據(jù)。以有效載荷格式809配置這樣的純數(shù)據(jù)，然后將其遞送到實時傳輸協(xié)議(RTP)層808。然后RTP層808將RTP首標添加到所接收的有效載荷格式數(shù)據(jù)上，并且把已添加RTP首標的數(shù)據(jù)提供給用戶數(shù)據(jù)報協(xié)議(UDP)層807。RTP控制協(xié)議(RTCP)層810用來提供RTP層808的控制信息。UDP層807通過在其上添加UDP首標將所接收數(shù)據(jù)轉(zhuǎn)換為UDP格式數(shù)據(jù)。將已添加UDP首標的數(shù)據(jù)遞送給IP層806，根據(jù)本發(fā)明的示例實施例，IP層806進一步在其上添加IP首標并將已添加IP首標的數(shù)據(jù)遞送給首標壓縮協(xié)議層805。首標壓縮協(xié)議層805可以使用任何一個具有比PHS方案首標壓縮比高的首標壓縮比的首標壓縮方案。這樣的首標壓縮方案可以包括(但不限于)由另一個標準組織-因特網(wǎng)工程任務(wù)組(IETF)建議的增強壓縮RTP(ECRTP)方案或者魯棒首標壓縮(ROHC)方案。在給出圖8的進一步描述之前，將參考圖7簡要描述根據(jù)ROHC方案或ECRTP方案的首標壓縮方法。將對圖7做簡要描述，因為本領(lǐng)域技術(shù)人員非常熟悉這里說明的所述實例(但不限于此)首標壓縮方法。
圖7是利用ROHC或ECRTP方案對圖5的所述一般RTP首標執(zhí)行首標去除之后獲得的內(nèi)部格式圖；在圖7中，使用基于ROHC首標壓縮方案的RTP壓縮方案。最小能夠?qū)D7中所示的12字節(jié)RTP首標壓縮為2字節(jié)的首標。在圖7中所示的字段中，一旦在VoIP呼叫建立期間設(shè)置了‘版本’字段701、‘P’字段702、‘X’字段703、‘CC’字段704、‘同步源標識符’字段709以及‘有效載荷類型’字段706，它們保持不變。因此，忽略這些字段以便在無線區(qū)段不發(fā)送，它們能夠在目的ROHC協(xié)議實體中利用預(yù)定數(shù)值恢復(fù)出來。
對于經(jīng)歷改變數(shù)值的字段，例如‘序列號’字段707、‘時間戳’字段708和‘標記’字段705，所述的RTP壓縮方案發(fā)送表示它們的相應(yīng)字段值是否被改變的標志。當所述的三個字段值變?yōu)榕c所期望值不同的值時，如果有必要的話，所述方案將新改變的值添加到它的后部。例如，‘序列號’字段707通常每個分組增加1。在這種情況下，將壓縮RTP首標的‘S’標志設(shè)置為‘0’。因此，一旦接收到這樣的分組，接收者在ROHC協(xié)議實體內(nèi)用‘以前序列號+1’的值恢復(fù)所述字段。然而，如果由于某些原因所述‘序列號’的增加值大于1，所述方案設(shè)置‘S’標志為‘1’并且進一步把表示相應(yīng)增量的字段添加到所述首標。
所述ECRTP方案在操作上類似于所述ROHC方案，但是把標志添加到所述的壓縮首標格式中。當使用所述的ECRTP方案壓縮RTP首標時，最小將所述的12字節(jié)RTP首標壓縮為2字節(jié)的首標，并且當使用附加標志時，將所述12字節(jié)RTP首標壓縮為3字節(jié)首標。與表現(xiàn)出最大41.67％的RTP首標壓縮比的所述PHS方案相比，所述ROHC或ECRTP首標壓縮技術(shù)表現(xiàn)出最大83.33％的期望首標壓縮比。
返回到圖8，本發(fā)明實施例的示例實現(xiàn)利用具有高壓縮比的首標壓縮方案之一來壓縮分組首標。將首標已壓縮的數(shù)據(jù)遞送給匯聚子層業(yè)務(wù)接入點(CS-SAP)804。根據(jù)本發(fā)明的示例實施例，CS-SAP 804把首標壓縮的分組遞送給新定義的首標壓縮匯聚子層803。新的首標壓縮匯聚子層803根據(jù)預(yù)定準則對從上層接收的分組進行分類。配置新的首標壓縮匯聚子層803以便即使對已壓縮數(shù)據(jù)也能夠分類所接收的分組。
用于所述分組分類的準則包括(但不限于)發(fā)送者的IP地址、接收者的IP地址、UDP端口、IP服務(wù)類型等等。在IP和UDP首標中包括這些值，以下描述在新的首標壓縮匯聚子層803中對分組進行分類的示例方法。在對所接收分組進行分類后，新的首標壓縮匯聚子層803將分類的分組映射到它們合適的流，在其上增加連接標識符(ID)，并且將已增加連接ID的分組遞送給它下面的媒介訪問控制(MAC)公共部分子層801。
新的首標壓縮匯聚子層803支持在IP網(wǎng)絡(luò)中使用的首標壓縮技術(shù)。根據(jù)示例實現(xiàn)，在經(jīng)過RTP層808、UDP層807以及IP層806時，根據(jù)圖8的協(xié)議配置，其中首標被附加到在語音編解碼中產(chǎn)生的有效載荷809的分組在通過首標壓縮協(xié)議子層803進行首標壓縮之后被遞送到較低的層。該分組被遞送到新的首標壓縮匯聚子層803。
新的首標壓縮匯聚子層803通過參考分類器對經(jīng)由所述首標壓縮協(xié)議接收的分組進行分類。
當使用所述的首標壓縮協(xié)議時，因為所述的IP/UDP/RTP首標被壓縮，首標壓縮匯聚子層803不能直接從所述首標中提取信息用作所述分類器。因此，首標壓縮匯聚子層803使用所述分組的會話上下文ID、服務(wù)流ID和連接ID之間的映射關(guān)系。就是說，在所述首標壓縮協(xié)議的情況下，首先，首標壓縮匯聚子層803必須應(yīng)當通過所述無線區(qū)段發(fā)送所述的全首標。因此，此時，首標壓縮匯聚子層803提取分類器需要的信息，即IP地址、UDP端口號、IP服務(wù)類型等，并將它們映射到適當?shù)姆?wù)流。進一步，首標壓縮匯聚子層803將連接ID添加到新生成的分組呼叫。
當使用所述首標壓縮方案時，首標壓縮匯聚子層803將上下文ID添加到壓縮的首標上以便在每個會話中識別分組。首標壓縮匯聚子層803事先存儲由第一分組首標所確定的服務(wù)流ID、連接ID和上下文ID之間的映射關(guān)系。在對從上層接收的下一個首標壓縮的分組進行分類的過程中，首標壓縮匯聚子層803僅提取首標壓縮的分組的上下文ID，代替提取分類器信息，根據(jù)以前所存儲的映射關(guān)系信息將所提取的上下文ID映射到適當?shù)姆?wù)流ID和連接ID，并且經(jīng)由MAC業(yè)務(wù)接入點(MAC-SAP)802將所述映射結(jié)果遞送給MAC公共部分子層801。
通過這個過程，MAC公共部分子層801能夠從空中遞送首標壓縮的分組。類似地，在前述過程的逆過程中執(zhí)行所述接收者的操作，并且將參考圖10A和10B對它進行描述，其中為了簡明起見，對本領(lǐng)域普通技術(shù)人員可以理解的某些細節(jié)不再重復(fù)描述。
圖9是根據(jù)本發(fā)明的示例實施例的首標已壓縮的分組的格式圖。
因為新的首標壓縮匯聚子層803支持所述的首標壓縮協(xié)議，它不是單獨支持所述的PHS方案。因此，首標壓縮匯聚子層803設(shè)置“PHSI＝0”901，將PHSI＝0附加到首標壓縮的IP分組902的頭上，并且將所述結(jié)果分組提供給MAC公共部分子層801。在如圖9所示的示例實現(xiàn)中，如上所述，參考編號901指示是否有必要進行數(shù)據(jù)驗證，并且參考編號902指示首標已壓縮的PDU。圖9是通過ROHC方案壓縮的首標的示例。因此，首標壓縮的PDU902包括ROHC首標和音碼器有效載荷。
圖10A和10B是說明根據(jù)本發(fā)明示例實施例的首標壓縮/解壓縮過程的流程圖。現(xiàn)在將參考圖10A和10B詳細描述根據(jù)本發(fā)明示例實施例的首標壓縮/解壓縮過程。
在步驟1001中一旦從上層接收到發(fā)送分組數(shù)據(jù)，發(fā)送者在步驟1002中確定所接收分組數(shù)據(jù)是否針對新的呼叫。如果所接收分組數(shù)據(jù)是針對新的呼叫，所述發(fā)送者前進到步驟1003。否則，如果所接收分組數(shù)據(jù)不是針對新的呼叫，所述發(fā)送者前進到步驟1004。如果從上層接收的分組是針對新的呼叫，在步驟1003中，新的首標壓縮匯聚子層803提取IP地址、UDP端口號和IP服務(wù)類型。首標壓縮匯聚子層803提取這種信息以便對服務(wù)進行分類。在提取了所述信息之后，首標壓縮匯聚子層803前進到步驟1005，在步驟1005中，它對所述分組進行分類并且將已分類的分組映射到相關(guān)聯(lián)的服務(wù)流ID和上下文ID。之后在步驟1006中，首標壓縮匯聚子層803將PHSI的值設(shè)為‘0’。即，因為首標壓縮匯聚子層803不使用傳統(tǒng)的PHS方案，所以它增加首標或?qū)HSI值設(shè)置為“0”。之后在步驟1007中，首標壓縮匯聚子層803將所生成的PHSI值添加到PDU上。已添加PHSI的PDU的格式如圖9所示。之后在步驟1008中，首標壓縮匯聚子層803將所生成的分組遞送給MAC-SAP層802。
然而，如果在步驟1002中確定所接收分組不是針對新的呼叫，首標壓縮匯聚子層803前進到步驟1004，在步驟1004中，它提取通過前述過程所生成的上下文ID。之后首標壓縮匯聚子層803執(zhí)行步驟1005以及它的后續(xù)步驟。
接下來，現(xiàn)在將參考圖10B描述根據(jù)本發(fā)明示例實施例的接收者的操作。
接收者通過下層接收從空中發(fā)送來的數(shù)據(jù)。在步驟1009中一旦接收到來自下層的分組數(shù)據(jù)，首標壓縮匯聚子層803前進到步驟1010，在步驟1010中，它識別連接ID并從所接收分組數(shù)據(jù)中提取PHSI值。就是說，首標壓縮匯聚子層803在不重新配置所接收分組首標的情況下將所接收分組經(jīng)由CS-SAP 804遞送給上層。然后根據(jù)本發(fā)明的示例實施例，包含在上層中的首標壓縮協(xié)議層805恢復(fù)所述的已壓縮首標。
正如從前面描述所理解，本發(fā)明的示例實現(xiàn)允許提供基于IP網(wǎng)絡(luò)的分組語音業(yè)務(wù)的無線通信系統(tǒng)使用各種首標壓縮方案。以這種方式，所述無線通信系統(tǒng)通過使用具有比PHS的傳統(tǒng)首標壓縮技術(shù)更高性能的首標壓縮方案，能夠在質(zhì)量不惡化的情況下減少在無線區(qū)段所發(fā)送的首標信息量。通過減少在無線區(qū)段所發(fā)送的首標信息量，能夠減少在無線區(qū)段的資源浪費。在無線區(qū)段所發(fā)送的首標信息量的減少也有助于提高資源的利用效率。
雖然參考本發(fā)明的某些示例實施例已經(jīng)說明和描述了本發(fā)明，但本領(lǐng)域的技術(shù)人員應(yīng)當理解在不脫離由所附權(quán)利要求書所定義的本發(fā)明的精神和范圍的情況下，可以在形式和細節(jié)上進行各種修改。
權(quán)利要求
1.一種在寬帶無線通信系統(tǒng)中壓縮首標的發(fā)送裝置，所述裝置包括首標壓縮協(xié)議層，用于在初始發(fā)送時發(fā)送所接收分組而不壓縮至少一個從上層添加到所述接收分組的首標，并且從下一次發(fā)送開始，根據(jù)壓縮方案壓縮所述至少一個首標；以及首標壓縮匯聚子層，用于根據(jù)從所述首標壓縮協(xié)議層接收的初始首標信息對所述分組進行分類，存儲用于所述分組分類的映射信息，并且利用所述映射信息對首標壓縮的分組執(zhí)行分組分類。
2.如權(quán)利要求1所述的發(fā)送裝置，其中，所述壓縮方案包括魯棒首標壓縮ROHC方案。
3.如權(quán)利要求1所述的發(fā)送裝置，其中，所述壓縮方案包括增強壓縮RTP方案，即ECRTP方案。
4.如權(quán)利要求1所述的發(fā)送裝置，其中，所述首標壓縮匯聚子層在初始分組發(fā)送期間存儲上下文標識符ID、服務(wù)流ID和連接ID之間的映射關(guān)系信息，針對下一個分組從所述至少一個壓縮首標中提取所述連接ID，并且根據(jù)所存儲的映射信息對所述分組進行分類。
5.如權(quán)利要求1所述的發(fā)送裝置，其中，所述首標壓縮協(xié)議層給有效載荷首標抑制標識符PHSI設(shè)置一值，該值表示至少一個首標沒有被壓縮。
6.一種用于接收包含根據(jù)壓縮方案壓縮的首標的分組的裝置，所述裝置包括首標壓縮匯聚子層，用于在通過無線區(qū)段發(fā)送之后從下層所接收的信息中提取連接標識符ID，并且提取在寬帶無線通信系統(tǒng)中使用的有效載荷首標壓縮索引值；以及首標壓縮協(xié)議層，用于事先存儲在初始分組接收期間接收的首標信息中每個分組不經(jīng)歷改變的信息，通過將事先存儲的信息添加到從首標壓縮匯聚子層遞送的首標信息上來解壓縮下一個接收分組，并且將所述解壓縮的分組遞送給上層。
7.一種在寬帶無線通信系統(tǒng)中壓縮首標的發(fā)送方法，所述方法包括以下步驟一旦從上層接收到添加至少一個首標的分組，在初始發(fā)送期間不壓縮所述至少一個首標而發(fā)送所接收分組；在初始發(fā)送期間根據(jù)首標信息分類所述分組，并且存儲用于所述分組分類的映射信息；根據(jù)以下壓縮方案壓縮至少一個首標在所述初始發(fā)送之后在從上層接收的首標信息中提取每個分組不經(jīng)歷改變的信息，并且根據(jù)所提取的信息去除所述至少一個首標；利用所存儲的映射信息對所述至少一個壓縮首標執(zhí)行分組分類；以及發(fā)送所述分類的分組。
8.如權(quán)利要求7所述的發(fā)送方法，其中，所述壓縮方案包括魯棒首標壓縮ROHC方案。
9.如權(quán)利要求7所述的發(fā)送方法，其中，所述壓縮方案包括增強壓縮RTP方案，即ECRTP方案。
10.如權(quán)利要求7所述的發(fā)送方法，其中，在初始分組發(fā)送期間，用于所述分組分類的映射信息包括上下文標識符ID、服務(wù)流ID和連接ID間的映射關(guān)系信息。
11.如權(quán)利要求10所述的發(fā)送方法，其中，所述利用所存儲的映射信息對所述壓縮首標執(zhí)行分組分類包括根據(jù)通過從壓縮首標中提取所述連接ID所獲得的映射信息分類所述分組。
12.如權(quán)利要求7所述的發(fā)送方法，其中，有效載荷首標抑制標識符PHSI包括表示所述首標沒有被壓縮的值。
13.一種接收包含根據(jù)壓縮方案壓縮的首標的分組的方法，所述方法包括以下步驟在通過無線區(qū)段發(fā)送之后從下層所接收的信息中提取連接標識符ID，并且提取在寬帶無線通信系統(tǒng)中使用的有效載荷首標壓縮索引值；以及事先存儲在初始分組接收期間所接收的首標信息中每個分組不經(jīng)歷改變的信息，通過將事先存儲的信息添加到從首標壓縮匯聚子層提供的首標信息上來解壓縮下一個接收分組，并且將所述解壓縮的分組發(fā)送給上層。
14.如權(quán)利要求1所述的發(fā)送裝置，其中，至少一個首標包括實時傳輸協(xié)議RTP首標、用戶數(shù)據(jù)報協(xié)議UDP首標和因特網(wǎng)協(xié)議IP首標中的至少之一。
15.如權(quán)利要求7所述的發(fā)送方法，其中，至少一個首標包括實時傳輸協(xié)議RTP首標、用戶數(shù)據(jù)報協(xié)議UDP首標和因特網(wǎng)協(xié)議IP首標中的至少之一。
全文摘要
提供了一種在寬帶無線通信系統(tǒng)中壓縮首標的發(fā)送裝置和方法。一旦從上層接收到添加了實時傳輸協(xié)議(RTP)首標、用戶數(shù)據(jù)報協(xié)議(UDP)首標和因特網(wǎng)協(xié)議(IP)首標的分組，首標壓縮協(xié)議層在初始發(fā)送時不壓縮所述首標而發(fā)送所接收分組，并且從下次發(fā)送開始，根據(jù)在因特網(wǎng)技術(shù)中提供的壓縮方案壓縮所述首標。首標壓縮匯聚子層根據(jù)從所述首標壓縮協(xié)議層接收的初始首標信息對所述分組分類，存儲用于所述分組分類的映射信息，并且利用所述映射信息對首標壓縮的分組執(zhí)行分組分類。
文檔編號H04L12/56GK101057461SQ200580038434
公開日2007年10月17日 申請日期2005年11月15日 優(yōu)先權(quán)日2004年11月15日
發(fā)明者張容, 張洪成, 林根輝, 金俊亨, 趙東浩, 宋知映 申請人:三星電子株式會社