專利名稱：帶有標(biāo)題壓縮的無(wú)線通信設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及無(wú)線通信設(shè)備并且涉及操作該無(wú)線通信設(shè)備的方法，特別涉及基于分組的無(wú)線通信設(shè)備以及操作該基于分組的無(wú)線通信設(shè)備的方法，其中使用標(biāo)題壓縮。本發(fā)明還涉及在這樣的設(shè)備中使用的通信單元和軟件產(chǎn)品。
基于無(wú)線電單元和用于將它們至少臨時(shí)地組成共享資源網(wǎng)的連接的無(wú)線通信系統(tǒng)是已知的。這種一般類型的目前的一個(gè)實(shí)現(xiàn)是采用短射程、跳頻網(wǎng)絡(luò)的形式并且在本領(lǐng)域中被稱為藍(lán)牙TM通信。這種設(shè)備由藍(lán)牙TM標(biāo)準(zhǔn)控制并且與藍(lán)牙TM通信符合的完整規(guī)范和目前的藍(lán)牙TM標(biāo)準(zhǔn)以及相關(guān)信息可以通過(guò)藍(lán)牙TM特殊興趣組(SIG)找到，其網(wǎng)站可在“www.bluetooth.com”找到。
藍(lán)牙TM通信的有用論述可以在由Jennifer Bray和CharlesF.Sturman寫(xiě)的“BluetoothTM，Connect Without Wires(藍(lán)牙TM，無(wú)線連接)”的文本書(shū)格式中找到，其由Prentice Hall PTR出版，ISBN 0-13-089840-6。
更多的現(xiàn)有技術(shù)可以在，例如WO 01/20940，US5940431以及在美國(guó)公開(kāi)的申請(qǐng)2001/0005368A1和2001/0033601A1中找到，其中這個(gè)領(lǐng)域的目前技術(shù)發(fā)展水平的某些方面也被論述。
對(duì)于通用藍(lán)牙TM背景信息以及例如，對(duì)于這里用到并且沒(méi)有明確定義的技術(shù)術(shù)語(yǔ)的說(shuō)明，讀者可參考上述來(lái)源。
藍(lán)牙TM網(wǎng)絡(luò)中的每個(gè)接入點(diǎn)與一個(gè)或多個(gè)移動(dòng)終端，例如移動(dòng)電信手機(jī)組成一個(gè)藍(lán)牙TM微微網(wǎng)。這個(gè)藍(lán)牙TMPAN可以傳送VoIP流以及其他類型的IP業(yè)務(wù)量。因?yàn)樵S多手機(jī)(或者其他終端)可被連接到相同的接入點(diǎn)，所以可以看到在有限的可用帶寬(每個(gè)微微網(wǎng)1Mbps總?cè)萘?的使用方面使效率最大化很重要。
藍(lán)牙TM的一個(gè)新出現(xiàn)的應(yīng)用是互聯(lián)網(wǎng)協(xié)議上的語(yǔ)音(VoIP)的傳遞，其被部署在互聯(lián)網(wǎng)上以及企業(yè)通信網(wǎng)/內(nèi)聯(lián)網(wǎng)中。在后一種情況下，VoIP的主要優(yōu)點(diǎn)是其被典型地用于數(shù)據(jù)的已有的網(wǎng)絡(luò)基礎(chǔ)設(shè)施的語(yǔ)音業(yè)務(wù)量使用。但是，當(dāng)VoIP業(yè)務(wù)量需要在具有有限帶寬的無(wú)線鏈路上被傳送時(shí)，因?yàn)閂oIP流是延遲敏感的并且顯示出相當(dāng)大的標(biāo)題額外開(kāi)銷，所以最小化帶寬浪費(fèi)很重要。


圖1中描述的基礎(chǔ)結(jié)構(gòu)顯示一種可能的情景，其中一組移動(dòng)終端MT1-n中的一個(gè)MT1包括藍(lán)牙TM使能的第三代(3G)移動(dòng)電話，其有一個(gè)嵌入的IP棧并且能夠通過(guò)在如內(nèi)聯(lián)網(wǎng)的企業(yè)通信網(wǎng)中建立VoIP連接來(lái)象無(wú)繩電話手機(jī)一樣操作。移動(dòng)手機(jī)MT1使用內(nèi)聯(lián)網(wǎng)中的一組接入點(diǎn)AP1...n通過(guò)到電話網(wǎng)的專用網(wǎng)關(guān)(PABX/VoIP GW)或者在內(nèi)聯(lián)網(wǎng)里，建立與一個(gè)或者更多其他手機(jī)MTn的IP上語(yǔ)音(VoIP)連接。
根據(jù)VoIP范例，語(yǔ)音采樣被壓縮成分組，其長(zhǎng)度依賴于使用的語(yǔ)音編碼器。這樣的有效負(fù)荷長(zhǎng)度必須被限制以避免在會(huì)話中引入長(zhǎng)延遲。為了GSM質(zhì)量，5.3kb/s的G；723.1編碼器可被使用，其生成20字節(jié)的語(yǔ)音分組。利用實(shí)時(shí)協(xié)議(RTP)為這個(gè)有效負(fù)荷打上時(shí)間戳，其引入12字節(jié)的標(biāo)題并且所得到的段在UDP數(shù)據(jù)報(bào)中被傳送，其增加了自己的另外8個(gè)字節(jié)的標(biāo)題。雖然RTP提供用于時(shí)間同步的功能，但是UDP允許幾個(gè)流被一起多路復(fù)用成無(wú)連接的邏輯信道。然后這個(gè)RTP/UDP分組被封裝成IP數(shù)據(jù)報(bào)，其增加一個(gè)20字節(jié)的IP標(biāo)題。如果使用IP版本6(IPv6)，則因?yàn)镮P標(biāo)題從20字節(jié)增加到40字節(jié)，給出只有20個(gè)字節(jié)有效負(fù)荷的60個(gè)字節(jié)的可能的整體標(biāo)題，所以情況會(huì)更壞。當(dāng)VoIP分組在有線LAN上被傳送時(shí)帶寬利用的這一低效率可能不是主要問(wèn)題，但是當(dāng)無(wú)線LAN被替代使用時(shí)會(huì)導(dǎo)致嚴(yán)重的限制。
在藍(lán)牙TM通信的特殊情況下，個(gè)人區(qū)域網(wǎng)(PAN)工作組標(biāo)準(zhǔn)化了藍(lán)牙TM上的IP并且，為這個(gè)目的，已經(jīng)開(kāi)發(fā)了稱作“藍(lán)牙TM網(wǎng)絡(luò)封裝協(xié)議”(BNEP)的新協(xié)議。這個(gè)協(xié)議為用于在藍(lán)牙TM介質(zhì)上傳輸通用聯(lián)網(wǎng)協(xié)議的藍(lán)牙TM網(wǎng)絡(luò)封裝定義了分組格式。BNEP為藍(lán)牙TM提供以太網(wǎng)仿真，利用它把IP數(shù)據(jù)報(bào)封裝成以太網(wǎng)幀并且發(fā)送到下面的L2CAP層。通過(guò)引入以太網(wǎng)仿真層，可能例如在網(wǎng)絡(luò)接入點(diǎn)或者在藍(lán)牙TM特設(shè)網(wǎng)中實(shí)現(xiàn)廣播、組播以及層2橋接功能。BNEP的完整細(xì)節(jié)可通過(guò)藍(lán)牙TMSIG和上面提到的其網(wǎng)站獲得。
雖然非常靈活，但是，盡管有其自己的標(biāo)題壓縮機(jī)制，BNEP還是引入了很大的額外開(kāi)銷。當(dāng)將BNEP合計(jì)到更高層協(xié)議的額外開(kāi)銷中時(shí)，對(duì)于有些應(yīng)用會(huì)導(dǎo)致相當(dāng)大的帶寬浪費(fèi)。例如，在上述VoIP應(yīng)用的情況下，利用BNEP封裝RTP/UDP/IP分組將向已經(jīng)很長(zhǎng)的標(biāo)題中增加3到15個(gè)更多字節(jié)，因此對(duì)于20字節(jié)的有效負(fù)荷導(dǎo)致至少(12+8+20+3＝43)直到可能的(12+8+40+15＝75)字節(jié)的整體標(biāo)題。類似的考慮應(yīng)用于其他類型的IP業(yè)務(wù)量，例如如音頻和/或視頻信號(hào)的介質(zhì)。在后面這些情況中，由音頻/視覺(jué)應(yīng)用生成的分組可能比VoIP分組更大，但是最小化標(biāo)題額外開(kāi)銷仍然很重要。事實(shí)上，當(dāng)使用藍(lán)牙系統(tǒng)時(shí)，通常由音頻/視覺(jué)編碼器生成可被一對(duì)一地映射到L2CAP幀的分組。這使得無(wú)論何時(shí)有用的分組使用期限到期時(shí)能夠進(jìn)行更好的重傳控制以及減輕緩存刷新。如果標(biāo)題的尺寸被最小化，給定基帶分組的有用有效負(fù)荷，則更多的帶寬被預(yù)留用于實(shí)際的音頻/視覺(jué)有效負(fù)荷。
本發(fā)明的一個(gè)目的是提供改良的無(wú)線通信設(shè)備以及操作該設(shè)備的改良的方法。本發(fā)明的另一個(gè)目的是提供一種改良的基于分組的無(wú)線通信設(shè)備，以及操作該無(wú)線通信設(shè)備設(shè)備的改良的方法，其中使用標(biāo)題壓縮。本發(fā)明的另一個(gè)目的是提供與這些改良的通信設(shè)備和方法相關(guān)聯(lián)使用的改良的通信單元以及軟件產(chǎn)品。照這樣，本發(fā)明的一個(gè)特殊目的是提供減少的歸因于在藍(lán)牙TM個(gè)人區(qū)域網(wǎng)中對(duì)于如VoIP、音頻和/或視頻的互聯(lián)網(wǎng)協(xié)議(IP)比特流的RTP/UDP/IP/BNEP標(biāo)題的額外開(kāi)銷。
因此，本發(fā)明提供用于第一個(gè)單元和第二個(gè)單元之間無(wú)線傳輸?shù)姆椒?，該方法包括一個(gè)所述單元a)將實(shí)時(shí)比特流轉(zhuǎn)換成預(yù)定的最大長(zhǎng)度的一個(gè)或多個(gè)有效負(fù)荷；b)將一個(gè)或多個(gè)預(yù)定義標(biāo)題應(yīng)用于所述或每個(gè)所述有效負(fù)荷以便生成適合于根據(jù)預(yù)定的通信協(xié)議在所述單元之間傳輸?shù)姆纸M；c)將所述或每個(gè)所述分組封裝在適合于跨越所述單元之間的無(wú)線連接傳送所述或每個(gè)所述分組的封裝協(xié)議幀中；以及d)將預(yù)定義標(biāo)題壓縮技術(shù)應(yīng)用于所述或每個(gè)所述封裝的分組。
該方法包括從包括如互聯(lián)網(wǎng)上語(yǔ)音(VoIP)、音頻或視覺(jué)流的互聯(lián)網(wǎng)協(xié)議(IP)業(yè)務(wù)量的所述實(shí)時(shí)比特流生成所述或每個(gè)所述有效負(fù)荷。
該方法包括在所述第一個(gè)和第二個(gè)單元之間執(zhí)行業(yè)務(wù)發(fā)現(xiàn)過(guò)程以及在所述業(yè)務(wù)發(fā)現(xiàn)過(guò)程期間通告所述標(biāo)題壓縮技術(shù)。
該方法包括配置一個(gè)或多個(gè)分段，重新組裝以及多路復(fù)用所述預(yù)定義信協(xié)議的業(yè)務(wù)以便運(yùn)送壓縮的比特流。
該方法包括通過(guò)向適合于應(yīng)用所述標(biāo)題壓縮技術(shù)的壓縮器和解壓縮器的上下文中增加封裝協(xié)議信息來(lái)應(yīng)用所述標(biāo)題壓縮，所述信息包括例如所述封裝協(xié)議的靜態(tài)標(biāo)題域。
所述單元包括諸如藍(lán)牙TM網(wǎng)的無(wú)線電通信網(wǎng)的一部分并且所述方法包括利用包括藍(lán)牙TM網(wǎng)封裝協(xié)議(BNEP)的封裝協(xié)議來(lái)封裝所述或每個(gè)所述分組。
該方法包括優(yōu)選地通過(guò)將所述預(yù)定標(biāo)題和BNEP標(biāo)題的組合縮短到例如3字節(jié)的預(yù)定長(zhǎng)度來(lái)利用所述標(biāo)題壓縮技術(shù)將所述或每個(gè)所述封裝的分組壓縮成單一時(shí)隙藍(lán)牙TM基帶分組。
該方法包括以諸如由互聯(lián)網(wǎng)工程任務(wù)組(IETF)通過(guò)的ROHC的健壯標(biāo)題壓縮(ROHC)框架的形式應(yīng)用所述標(biāo)題壓縮技術(shù)。
該方法包括下述的一個(gè)或多個(gè)a)對(duì)于所述分組使用實(shí)時(shí)協(xié)議(RTP)概況(profile)；b)使用IETF ROHC雙向最有利方法(o模式)；c)使用小ROHC上下文識(shí)別符(R-CID)，空R-CID是缺省值；d)不傳輸通用數(shù)據(jù)報(bào)協(xié)議(UDP)校驗(yàn)和，可選地在解壓縮器處對(duì)其重新計(jì)算；e)在任何一個(gè)分組流期間將整個(gè)封裝協(xié)議標(biāo)題考慮成靜態(tài)上下文的一部分；f)僅傳輸實(shí)時(shí)協(xié)議(RTP)序列號(hào)和/或互聯(lián)網(wǎng)協(xié)議身份；g)定義壓縮器中“初始化和刷新”(IR)、“第一級(jí)”(FO)和“第二級(jí)”(SO)狀態(tài)之間的轉(zhuǎn)移以及解壓縮器中“沒(méi)有上下文”(NC)、“靜態(tài)上下文”(SC)以及“全上下文”(FC)狀態(tài)之間的轉(zhuǎn)移。
該方法包括將封裝幀分類因此只有預(yù)定的所述幀被利用所述標(biāo)題壓縮技術(shù)進(jìn)行壓縮。
該方法包括根據(jù)實(shí)時(shí)協(xié)議(RTP)、通用數(shù)據(jù)報(bào)協(xié)議(UDP)以及互聯(lián)網(wǎng)協(xié)議中的一個(gè)或多個(gè)來(lái)將標(biāo)題應(yīng)用于所述有效負(fù)荷。
該方法包括所述單元配置多個(gè)邏輯信道用于這些單元之間的通信，至少一個(gè)所述信道專用于所述壓縮的封裝分組的傳送。
該方法包括將所述標(biāo)題壓縮技術(shù)基于窗口-最低有效位編碼(W-LSB)。
該方法包括通過(guò)提供適合于錯(cuò)誤恢復(fù)請(qǐng)求以及優(yōu)選地，適合于上下文更新確認(rèn)的所述單元之間的反饋信道來(lái)管理壓縮器和解壓縮器狀態(tài)之間的轉(zhuǎn)換。
該方法包括所述單元接收被分段成基帶分組的一連串所述壓縮的封裝幀，在下一個(gè)所述分組被傳輸之前肯定地確認(rèn)每個(gè)所述分組以及，如果在最近的所述分組或者確認(rèn)消息中出現(xiàn)傳輸錯(cuò)誤，則所述最近的分組被重傳。
該方法包括如果下列情況的至少一種發(fā)生，則重傳所述分組a)基帶分組存取碼沒(méi)有被接收到；b)在基帶分組標(biāo)題中出現(xiàn)無(wú)法糾正的錯(cuò)誤；或者c)在所述分組的所述有效負(fù)荷中存在無(wú)法糾正的錯(cuò)誤。
該方法包括例如，通過(guò)設(shè)置所述幀的成功傳遞的超時(shí)，限制對(duì)于所述壓縮的封裝幀的多個(gè)重傳。
本發(fā)明還提供用于在第一個(gè)通信單元和第二個(gè)通信單元之間執(zhí)行基于分組的無(wú)線通信的軟件產(chǎn)品，所述產(chǎn)品包括用于執(zhí)行下列操作的代碼a)將實(shí)時(shí)比特流轉(zhuǎn)換成預(yù)定最大長(zhǎng)度的一個(gè)或多個(gè)有效負(fù)荷；b)將一個(gè)或多個(gè)預(yù)定義標(biāo)題應(yīng)用于所述或每個(gè)所述有效負(fù)荷以便生成適合于根據(jù)預(yù)定義的通信協(xié)議在所述單元之間傳輸?shù)姆纸M；c)將所述或每個(gè)所述分組封裝在適合于跨越所述單元之間的無(wú)線連接傳送所述或每個(gè)所述分組的封裝協(xié)議的幀中；以及d)將預(yù)定義標(biāo)題壓縮技術(shù)應(yīng)用于所述或每個(gè)所述封裝的分組。
所述軟件產(chǎn)品可與組成所述通信單元的一部分的藍(lán)牙TM網(wǎng)接口軟件驅(qū)動(dòng)器關(guān)聯(lián)運(yùn)行。
本發(fā)明還提供包括適合于基本實(shí)時(shí)地向第二個(gè)單元發(fā)送信息的第一個(gè)單元的基于分組的無(wú)線通信設(shè)備，所述第一個(gè)單元適合于a)將實(shí)時(shí)比特流轉(zhuǎn)換成一個(gè)或多個(gè)預(yù)定最大長(zhǎng)度的有效負(fù)荷；b)將一個(gè)或多個(gè)預(yù)定義標(biāo)題應(yīng)用于所述或每個(gè)所述有效負(fù)荷以便生成適合于根據(jù)預(yù)定義的通信協(xié)議在所述單元之間傳輸?shù)姆纸M；c)將所述或每個(gè)所述分組封裝在適合于跨越所述單元之間的無(wú)線連接傳送所述或每個(gè)所述分組的封裝協(xié)議的幀中；以及d)將預(yù)定義的標(biāo)題壓縮技術(shù)應(yīng)用于所述或每個(gè)所述封裝分組。
所述第一個(gè)單元根據(jù)藍(lán)牙TM協(xié)議操作，所述封裝協(xié)議優(yōu)選地包括藍(lán)牙網(wǎng)封裝協(xié)議(BNEP)并且所述標(biāo)題壓縮技術(shù)優(yōu)選地與互聯(lián)網(wǎng)工程任務(wù)組(IETF)健壯標(biāo)題壓縮(ROHC)技術(shù)兼容。
本發(fā)明還提供適合于依照根據(jù)本發(fā)明的一種方法來(lái)操作的通信單元，所述單元優(yōu)選地包括藍(lán)牙網(wǎng)的主單元或者從單元，如接入點(diǎn)或者移動(dòng)終端。封裝的分組的標(biāo)題壓縮和/或解壓縮可以以在與所述通信單元相關(guān)的藍(lán)牙TM網(wǎng)接口軟件驅(qū)動(dòng)器中運(yùn)行的軟件產(chǎn)品的形式來(lái)實(shí)現(xiàn)。這個(gè)軟件產(chǎn)品包括藍(lán)牙網(wǎng)封裝協(xié)議(BNEP)和邏輯鏈路控制和適配協(xié)議(L2CAP)層、幀分類器、健壯標(biāo)題壓縮(ROHC)編解碼器以及用于協(xié)調(diào)的管理實(shí)體(ME)。管理實(shí)體可通過(guò)主控制器接口(HCI)與藍(lán)牙TM基帶通信以及利用操作系統(tǒng)特定的機(jī)制與上面的協(xié)議層通信。每次例如具體化為移動(dòng)終端MT1-n的從通信單元連接到例如具體化為接入點(diǎn)AP1-n的主單元時(shí)，管理實(shí)體都登記其介質(zhì)訪問(wèn)地址(MAC)并且為所述從單元配置邏輯信道。
圖1是通信系統(tǒng)的示意圖；圖2是用于根據(jù)本發(fā)明的實(shí)施方案的通信單元的協(xié)議棧并且其適合于用于根據(jù)圖1的系統(tǒng)；圖3是用于圖2的通信單元的網(wǎng)絡(luò)配置的流程圖；圖4a是用于實(shí)現(xiàn)本發(fā)明的標(biāo)題壓縮器的流程圖；圖4b是用于實(shí)現(xiàn)本發(fā)明的標(biāo)題解壓縮器的流程圖；圖5是本發(fā)明的實(shí)施方案的功能圖；圖6a是標(biāo)題壓縮和解壓縮鏈的示意圖；圖6b是壓縮器狀態(tài)的框圖；圖6c是解壓縮器的框圖；并且圖7是圖4a的標(biāo)題壓縮器的狀態(tài)機(jī)。
現(xiàn)在將參考特定實(shí)施方案并且參考上述附圖描述本發(fā)明。這些描述僅作為例子并且本發(fā)明不限于此。特別地將參考分組以及基于分組的通信系統(tǒng)。本領(lǐng)域的技術(shù)人員應(yīng)該理解，本發(fā)明不限于分組交換系統(tǒng)而是可被用于將分組用作傳輸數(shù)據(jù)的手段的任何系統(tǒng)，也就是與它是分組交換、電路交換或另一種系統(tǒng)無(wú)關(guān)。對(duì)于“無(wú)線”的參考應(yīng)該被理解成其最廣泛的含義。例如，它可包括其某些傳輸不依賴于有線網(wǎng)絡(luò)的任何系統(tǒng)，例如它包括如漫射紅外的光傳輸方法。但是，應(yīng)該注意，本發(fā)明的所有實(shí)施方案可與藍(lán)牙TM協(xié)議一起被使用。這樣的系統(tǒng)的特性包括下列的一個(gè)或多個(gè)-作為擴(kuò)頻技術(shù)的慢跳頻；
-主單元和從單元，由此主單元可以設(shè)置跳頻序列；-每個(gè)設(shè)備有其自己的時(shí)鐘和其自己的地址；-主單元的跳頻序列可從其地址被確定；-與一個(gè)主單元通信的一組從單元都有(主單元的)相同的跳頻并組成一個(gè)微微網(wǎng)；-微微網(wǎng)可通過(guò)公共從單元被鏈接以便組成分散網(wǎng)；-從單元和主單元之間的時(shí)分復(fù)用傳輸(TDMA)；-從單元和主單元之間的時(shí)分雙工(TDD)傳輸；-從單元和主單元之間的傳輸可以同步或者異步；-主單元確定何時(shí)從單元可以傳輸；-從單元僅當(dāng)被主單元尋址時(shí)才應(yīng)答；-時(shí)鐘自由運(yùn)行；-不對(duì)等的網(wǎng)絡(luò)，特別是在2.4GHz無(wú)拍照ISM頻段運(yùn)行的那些網(wǎng)絡(luò)；-使得應(yīng)用能夠找到該區(qū)域中其它藍(lán)牙TM設(shè)備的軟件堆棧；-其它設(shè)備通過(guò)發(fā)現(xiàn)/查詢過(guò)程被找到；以及-硬或軟的切換。
關(guān)于跳頻，“慢跳頻”指比調(diào)制速率慢的跳頻，“快跳頻”指跳頻速率比調(diào)制速率快。本發(fā)明不限于慢或者快跳頻。
下面將參考的用戶終端是移動(dòng)終端，但是本發(fā)明不限于此而是還包括諸如計(jì)算機(jī)的固定用戶終端。
這里將參考標(biāo)題壓縮技術(shù)，并且特別是健壯標(biāo)題壓縮(ROHC)。提供這些技術(shù)的某些方面的概述被認(rèn)為很有用，但是為了更詳細(xì)地理解，讀者可參考2001年7月的文章C.Borman等人的“Robust Header Compression(ROHC)Framework and four profilesRTP，UDP，BSP anduncompressed(健壯標(biāo)題壓縮(ROHC)框架和四個(gè)概況RTP，UDP，BSP以及未壓縮的”)，這篇文章可以通過(guò)“互聯(lián)網(wǎng)工程任務(wù)組”(IETF)網(wǎng)站在參考“RFC3095”下找到并且通過(guò)以下URL可以訪問(wèn)http://www.ietf.org/rfc/rfc3095.txt通常，標(biāo)題壓縮機(jī)制利用因?yàn)殪o態(tài)標(biāo)題域在會(huì)話期間不改變，所以無(wú)需在每個(gè)分組中發(fā)送靜態(tài)標(biāo)題域的事實(shí)而減少了標(biāo)題額外開(kāi)銷，這樣的靜態(tài)標(biāo)題域包括例如IP地址和UDP端口。而且，有效地處理在會(huì)話期間變化的域(例如RTP時(shí)間戳、RTP序號(hào)以及IP標(biāo)識(shí))是可能的，因此標(biāo)題額外開(kāi)銷可以被減少得更多。在某些情況下，這些所謂的“變化的域”可以利用簡(jiǎn)單的線性外推法從以前的分組中預(yù)測(cè)。其它標(biāo)題域(例如IP標(biāo)題長(zhǎng)度和UDP長(zhǎng)度)可以從數(shù)據(jù)鏈路級(jí)推斷出來(lái)并且沒(méi)必要發(fā)送他們，這些域被稱為“推斷域”。
標(biāo)題壓縮方案由S.Casner和V.Jacobson在其1999年2月的文章“Compressing IP/UDP/RTP Headers for Low-Speed Serial Links(對(duì)于低速串行鏈路壓縮IP/UDP/RTP標(biāo)題)”中被建議(互聯(lián)網(wǎng)RFC2508)。這個(gè)方案壓縮RTP/UDp/IP標(biāo)題，但是沒(méi)有被設(shè)計(jì)來(lái)處理在典型的無(wú)線鏈路上遇到的錯(cuò)誤率以及往返行程延遲。
使標(biāo)題壓縮適用于無(wú)線環(huán)境的技術(shù)被建議，例如“ACE”(適應(yīng)性標(biāo)題壓縮)以及“ROCCO”(健壯的基于校驗(yàn)和的標(biāo)題壓縮)。“ACE”介紹了使用可變的滑動(dòng)窗口(VSW)中包含的多個(gè)參考值的域編碼方案“變化域”(“基于窗口的最低有效位”W-LSB)，這些值被發(fā)送給解壓縮器。ROCCO使用CRC來(lái)驗(yàn)證解壓縮器中正確的重建以及避免錯(cuò)誤傳播。
IETF ROHC工作組目前正在研究在具有高錯(cuò)誤率和長(zhǎng)往返行程時(shí)間的鏈路上很好工作的新的壓縮方案。所述方案對(duì)于使用如WCDMA、EDGE以及CDMA-2000技術(shù)建立的蜂窩鏈路必須能夠很好執(zhí)行。但是，所述方案還應(yīng)該適用于具有高損耗和長(zhǎng)往返行程時(shí)間的其它未來(lái)的鏈路技術(shù)，使得壓縮可以在單向鏈路上被獲得。IETF ROHC使用并且組合了ACE和ROCCO研究的所有技術(shù)并且細(xì)節(jié)可以通過(guò)以下的IETF ROHC工作組URL找到http://www.ietf.org/html.charters/rohc-charter.htmlROHC提供對(duì)于適用于無(wú)線信道上RTP/UDP/IP流的健壯標(biāo)題壓縮的可擴(kuò)展框架。對(duì)TCP/IP標(biāo)題和其它類型協(xié)議(例如移動(dòng)Ipv6)的壓縮的支持也被加入并且到此為止四個(gè)概況被ROHC RFC定義0 未壓縮的IP分組1 RTP/UDP/IP2 UDP/IP3 ESP/IP本發(fā)明集中在概況1上。
ROHC壓縮器和解壓縮器需要維護(hù)上下文信息，以便實(shí)時(shí)流的動(dòng)態(tài)域被正確地處理并且標(biāo)題因此被重建，而靜態(tài)標(biāo)題域，也就是在給定上下文中保持不變的那些根本不被傳輸。壓縮和解壓縮鏈的圖可以特別參考圖6a看到。
對(duì)于RTP/UDP/IP流，動(dòng)態(tài)域如下列出
-IP標(biāo)識(shí)(16比特) IP-ID-UDP校驗(yàn)和(16比特)-RTP標(biāo)記(1比特) M-bit-RTP序號(hào)(16比特)SN-RTP時(shí)間戳(32比特) TS所有其它標(biāo)題域或者是靜態(tài)的或者被推斷。
最初，壓縮器在“初始化和刷新”(IR)狀態(tài)，其中標(biāo)題未壓縮的被發(fā)送以便解壓縮器可以為IP流創(chuàng)建上下文。在“第一級(jí)”(FO)狀態(tài)，壓縮器僅向解壓縮器發(fā)送靜態(tài)域的更新來(lái)補(bǔ)償可能破壞上下文的流中的不規(guī)則。因此，在這種狀態(tài)下，壓縮器僅發(fā)送上下文更新。在“第二級(jí)”(SO)狀態(tài)下，因?yàn)榭梢钥隙ń鈮嚎s器已經(jīng)接收到合法的上下文，因此壓縮器發(fā)送壓縮標(biāo)題。請(qǐng)?zhí)貏e地參見(jiàn)圖6b。
解壓縮器以“沒(méi)有上下文(NC)”狀態(tài)開(kāi)始。一成功地對(duì)標(biāo)題解壓縮，其就轉(zhuǎn)到“完整上下文”(FC)狀態(tài)，這是正常的運(yùn)行狀態(tài)。只有重復(fù)地解壓縮標(biāo)題之后其才轉(zhuǎn)入“靜止上下文”(SC)狀態(tài)，其中其等待由在FO狀態(tài)的壓縮器發(fā)送的上下文更新分組。如果合法的上下文不能被恢復(fù)，則解壓縮器返回NC狀態(tài)。請(qǐng)?zhí)貏e地參見(jiàn)圖6c。
狀態(tài)之間的轉(zhuǎn)移由運(yùn)行模式來(lái)管理，其中ROHC定義了三種模式“單向”(U-模式)，“雙向最有利”(O-模式)以及“雙向可靠”(R-模式)。在U模式中，從解壓縮器到壓縮器的反饋信道不存在(或者不能被使用)因此壓縮器狀態(tài)之間的轉(zhuǎn)移僅基于輸入分組標(biāo)題的周期性超時(shí)和不規(guī)則。在這種情況下，需要上下文的周期性刷新。在O模式中，反饋信道被用于錯(cuò)誤恢復(fù)請(qǐng)求以及(可選地)上下文更新的確認(rèn)。這種運(yùn)行模式背后的合理性是最小化反饋信道的使用。最后，R模式密集地使用反饋信道以便最大化健壯性防止損耗傳播和損壞傳播。
W-LSB編碼給定標(biāo)題域值來(lái)壓縮“v”，如果合適的參考值(v_ref)在壓縮器和解壓縮器都被保持，則W-LSB算法僅發(fā)送其最低有效位。為了避免“v_ref”值之間的不匹配，合適的健壯算法被定義，其在可變滑動(dòng)窗口VSW中選擇“v_ref”。發(fā)送要被壓縮的值“v”的最低有效位的數(shù)量“k”按如下說(shuō)明的被選擇。
令f(v_ref，k)＝[v_ref-p，v_ref+(2k-1)-p] (1)是其中v預(yù)期會(huì)變化的間隔。偏移參數(shù)p可根據(jù)要壓縮的特定域的行為來(lái)被選擇。
現(xiàn)在，在壓縮器中值k可以按如下的方式被選擇k＝g(v_ref，v)＝min kv∈f(v_ref，k)(2)所以k可以是最小值因此v落在間隔f(v_ref，k)中。
但是，因?yàn)閴嚎s器不知道解壓縮器正在使用相同的參考值(因傳輸錯(cuò)誤其可能實(shí)際上不相同)，所以這個(gè)方案可能對(duì)預(yù)防錯(cuò)誤不夠健壯。替代地，可變滑動(dòng)窗口被引入VSW＝{vi-w，vi}(3)其包含被發(fā)送的最近的w值。無(wú)論何時(shí)新值進(jìn)入壓縮器，其就被附加到VSW。當(dāng)壓縮器充分確信VSW中某些較舊的值已經(jīng)被正確地接收時(shí)，那些值從VSW中被刪除。
我們定義vmin＝min(VSW)，vmax＝max(VSW) (4)作為VSW中的最小和最大值。
在W-LSB編碼方案中，根據(jù)下列公式進(jìn)行k的選擇k＝max(g(v，vmin)，g(v，vmax)) (5)其中g(shù)()在(2)中已經(jīng)被定義。
這樣，歸因于解壓縮器具有用于解碼傳輸?shù)膍比特的好的參考間隔的不確定性，更多數(shù)量的比特被用于對(duì)該域編碼。事實(shí)上，解壓縮器處的解碼技術(shù)基于下列算法。
給定最近被正確解壓縮的值v_ref_d和接收的比特?cái)?shù)m，令I(lǐng)d＝f(v_ref_d，m) (6)被定義為解釋間隔。通過(guò)在上述解釋間隔中選取其m個(gè)最低有效位與接收的m個(gè)比特匹配的值，被解壓縮的域被簡(jiǎn)單地獲得。
可變滑動(dòng)窗口的大小w依賴于壓縮器對(duì)解壓縮器狀態(tài)的信任，其進(jìn)而又依賴于選擇的ROHC模式。對(duì)于U和O模式，w是與實(shí)現(xiàn)相關(guān)的。ROHC壓縮分組的語(yǔ)法(后面定義)設(shè)置允許的w尺寸。事實(shí)上，因?yàn)槊總€(gè)分組類型有確定的數(shù)量的比特預(yù)留用于被編碼的標(biāo)題域，因此這自動(dòng)地定義了窗口的尺寸。例如，RTP-SN是UO-0分組中被預(yù)留的4比特，其意味著窗口長(zhǎng)度被設(shè)置為16(也就是多達(dá)15個(gè)分組可以被丟失。)在R模式中，來(lái)自解壓縮器的明確的反饋可被用于最小化滑動(dòng)窗口尺寸并且因此最大化壓縮率。
W-LSB算法還可以通過(guò)簡(jiǎn)單的例子被進(jìn)一步解釋。我們假設(shè)壓縮器已經(jīng)發(fā)送了值151、152、153、154以及155并且因?yàn)闊o(wú)線鏈路上的傳輸錯(cuò)誤，最近的三個(gè)值沒(méi)有被接收。因此，在壓縮器中
VSW＝[151，152，153，154，155]，vmin＝151并且vmax＝155。
現(xiàn)在值156進(jìn)入壓縮器。要傳輸?shù)淖畹陀行坏臄?shù)量k由(5)給出，其生成k＝max(3，1)＝3。因此值156＝‘10011100’的最近三個(gè)LSB被傳輸(‘100’)。
在解壓縮器中，因?yàn)橹?53、154和155已經(jīng)被丟失，因此最近的好的參考值是152。根據(jù)(6)，解壓縮器有解釋間隔Id＝[152，159]，其被如下說(shuō)明。
應(yīng)該注意，在這個(gè)間隔中其三個(gè)LSB與樣式‘100’匹配的唯一值是156。為了避免未檢測(cè)到的傳輸錯(cuò)誤導(dǎo)致錯(cuò)誤的解壓縮值，其進(jìn)而可能在后面被用做參考值，導(dǎo)致?lián)p壞傳播，解壓縮的正確性可以通過(guò)將小的CRC應(yīng)用于原始標(biāo)題(例如依據(jù)模式的3-8個(gè)比特)被檢查。CRC檢測(cè)被損壞值的失敗還可以在ROHC框架中被補(bǔ)償。
其它編碼方案W-LSB編碼算法不是可被用于ROHC框架中的唯一算法。利用例如通常隨時(shí)間按規(guī)則的步幅增加(TS_STRIDE值的倍數(shù))的RTP時(shí)間戳之類的某些標(biāo)題域的特定特征的其它方案也存在。這個(gè)特征由“成比例的RTP時(shí)間戳”編碼使用。
還可利用以固定速率被生成的業(yè)務(wù)量的時(shí)刻、固定采樣頻率以及何時(shí)分組生成被鎖定到采樣頻率的線性函數(shù)來(lái)近似RTP時(shí)間戳。在這種情況下應(yīng)用“RTP時(shí)間戳的基于定時(shí)器的壓縮”。
IP標(biāo)識(shí)域(IP-ID)通過(guò)僅考慮IP-ID和RTP序號(hào)之間的偏移(后者對(duì)于每個(gè)新分組增加1)并且將W-LSB編碼應(yīng)用于這樣的偏移而被編碼。
ROHC RTP概況要被壓縮的RTP/UDP/IP流的固定標(biāo)題域可以被構(gòu)建為有序列表。ROHC框架提供方法以這樣的方式來(lái)處理這些列表，即解壓縮器中的列表項(xiàng)(組成上下文)可以被壓縮器靈活地插入、刪除或者變更。
RTP標(biāo)題的動(dòng)態(tài)域根據(jù)表1被編碼。
表1-RTP標(biāo)題動(dòng)態(tài)域編碼。
因?yàn)楫?dāng)序號(hào)和時(shí)間戳增加相同的增量乘以一個(gè)固定值時(shí)，IP-ID通常增加該相同的增量，所以RTP TS和IP-ID域經(jīng)?？梢詠?lái)自RTPSN。因此，當(dāng)這些條件應(yīng)用時(shí)，只有RTP SN被包括在壓縮標(biāo)題中并且推斷其它域的函數(shù)被包括在上下文中。
ROHC分組具有下列格式
可選的，變長(zhǎng)0或者多個(gè)反饋元素可變，具有CID信息表2-ROHC分組除了有效負(fù)荷之外，表2中的每個(gè)分組元素都從唯一的位模式開(kāi)始。
標(biāo)題運(yùn)送上下文ID(CID)信息其對(duì)于1到15之間的小CID包括1字節(jié)‘a(chǎn)dd-CID’八位字節(jié)(以模式‘1110’開(kāi)始)或者當(dāng)CID空間很大時(shí)運(yùn)送嵌入的CID信息(多達(dá)2字節(jié))。ROHC上下文標(biāo)識(shí)符被稱為R-CID。如果CID＝0沒(méi)有被發(fā)送，則該分組以分組類型開(kāi)始，其是不同于‘1110’的唯一的位模式并且空CID被暗示。
反饋信息可被捎帶確認(rèn)到任何ROHC分組并且運(yùn)送對(duì)于上下文更新和標(biāo)題解壓縮的否定和肯定確認(rèn)。反饋分組還可被解壓縮器用于請(qǐng)求模式之間的轉(zhuǎn)移(例如從U模式到O模式)。
分組類型幾種分組類型由ROHC根據(jù)其功能、使用的模式以及哪些域被運(yùn)送而被定義。ROHC分組的表示是<模式>-<類型>-<可選域>
例如，UOR-2分組可在U模式、O模式或者R模式被使用并且是類型2。
在RTP概況中，三種分組類型被用于識(shí)別壓縮標(biāo)題并且兩種用于初始化和刷新，如下所示0.(R-0，R-0-CRC，UO-0)這是最小分組類型，其中只有W-LSB編碼的RTP-SN被發(fā)送，這是因?yàn)橛糜讷@得其他域的所有函數(shù)在解壓縮器處都已知。
1.(R-1，R-1-ID，R-1-TS，UO-1，UO-1-ID，UO-1-TS)當(dāng)對(duì)RTP-SN編碼所需的比特?cái)?shù)超過(guò)分組類型0中可用的那些時(shí)或者當(dāng)用于從RTPSN獲得RTP TS和IP-ID的函數(shù)變化時(shí)，這個(gè)分組被使用。
2.(UOR-2，UOR-2-ID，UOR-2-TS)被用于修改任何的SN函數(shù)的參數(shù)。
3.IR這個(gè)分組被用于發(fā)送上下文的靜態(tài)部分，也就是不變的SN函數(shù)4.IR-DYN這一分組類型被用于發(fā)送上下文的動(dòng)態(tài)部分，也就是不固定的SN函數(shù)。
為每種分組類型組成唯一前綴的位模式在表3中顯示。
表3-分組前綴。
一接收到分組，解壓縮器就解析第一個(gè)字節(jié)并且因此驅(qū)動(dòng)其狀態(tài)機(jī)。
IR分組初始化和刷新(IR)分組允許解壓縮器為RTP/UDP/IP流創(chuàng)建上下文。其結(jié)構(gòu)在下面表4中顯示。
0 7
110-2大CID11可變可變?nèi)绻鸇＝1，則出現(xiàn)表4-IR分組格式。
Add-CID八位字節(jié)能夠?qū)⑸舷挛臉?biāo)識(shí)符與在分組的剩余部分中運(yùn)送的靜態(tài)標(biāo)題信息關(guān)聯(lián)。D比特是概況特定的，在RTP概況的情況下，其指示正好在靜態(tài)鏈之后的動(dòng)態(tài)子標(biāo)題信息的存在。只有需要使用大上下文標(biāo)識(shí)符時(shí)，CID信息域才出現(xiàn)。概況域是ROHC概況的標(biāo)識(shí)符。8位CRC跟隨著，為這個(gè)目的讀者可參考C.Borman等人的“RobustHeader Compression(ROHC)Framework and four profilesRTP，UDP，ESP and uncompressed(健壯標(biāo)題壓縮(ROHC)框架和四個(gè)概況RTP，UDP，ESP和未壓縮的)”，其可通過(guò)“互聯(lián)網(wǎng)工程任務(wù)組”(IETF)網(wǎng)站在參考“RFC3095”下找到。對(duì)于所述值在其域上被計(jì)算的生成多項(xiàng)式參見(jiàn)5.9.1節(jié)。
靜態(tài)鏈包含靜態(tài)標(biāo)題域的有序列表。例如，IPv4標(biāo)題應(yīng)該用包括版本、協(xié)議、源地址和目的地地址的靜態(tài)部分初始化。IPv4標(biāo)題的動(dòng)態(tài)部分包括業(yè)務(wù)類型、生存時(shí)間、標(biāo)識(shí)、DF、RND、NBO、擴(kuò)展標(biāo)題列表。
IR-DYN分組這種分組類型被用于更新上下文的動(dòng)態(tài)部分并且其格式在下面的表5中顯示。在這種情況下只有動(dòng)態(tài)鏈被發(fā)送。
0 7
111可變表5-IR-DYN分組格式。
通用分組格式表6中顯示壓縮的分組格式。應(yīng)該注意其結(jié)構(gòu)依賴于許多條件(Cx)，因此其處理可能不明顯。
0 7
1字節(jié)，類型指示1可變，C02字節(jié)，C1可變2字節(jié)，C22字節(jié)，C3可變2字節(jié)，C42字節(jié)，C5表6-通用壓縮的分組格式。
條件依賴于以前解碼的標(biāo)記域的值。標(biāo)題擴(kuò)展可選地出現(xiàn)來(lái)運(yùn)送額外的ROHC信息(四個(gè)不同的擴(kuò)展類型被定義)。如果上下文指示這個(gè)域隨機(jī)變化，則IP-ID域可以出現(xiàn)。
AH數(shù)據(jù)涉及認(rèn)證標(biāo)題，其包含安全相關(guān)的值。GRE校驗(yàn)和涉及GRE隧道(RFC2784，RFC2890)。UDP校驗(yàn)和僅當(dāng)在上下文中被明確地指示時(shí)才出現(xiàn)。
對(duì)藍(lán)牙TM的健壯標(biāo)題壓縮
本發(fā)明集中在兩個(gè)主要問(wèn)題上a)將健壯標(biāo)題壓縮(ROHC)應(yīng)用于藍(lán)牙TM協(xié)通信系統(tǒng)；以及b)將ROHC擴(kuò)展到BNEP。
本發(fā)明提供一種能夠壓縮VoIP幀、視頻/音頻流或者等價(jià)物的新協(xié)議，因此其適合單一時(shí)隙藍(lán)牙TM基帶分組，這個(gè)協(xié)議在這里為方便被稱為“ROHC-BNEP”。
本發(fā)明不僅限于語(yǔ)音應(yīng)用，還可應(yīng)用于其他IP業(yè)務(wù)量，如涉及藍(lán)牙TM微微網(wǎng)中實(shí)時(shí)IP業(yè)務(wù)的傳送的音頻/視頻流式應(yīng)用。根據(jù)本發(fā)明，BNEP信息被加入到ROHC壓縮器和解壓縮器的上下文中。這樣，不僅IP分組被壓縮，而且層2幀也被壓縮。
根據(jù)本發(fā)明的實(shí)施方案的對(duì)于移動(dòng)手機(jī)MT1-n的協(xié)議?？梢蕴貏e參考圖2來(lái)看。對(duì)于語(yǔ)音編碼器生成的每個(gè)分組，12字節(jié)的RTP標(biāo)題被加入以便允許時(shí)間同步。8字節(jié)UDP標(biāo)題被加入，其允許應(yīng)用流被多路復(fù)用在一起并且增加標(biāo)題校驗(yàn)和。UDP數(shù)據(jù)報(bào)被封裝在IP分組中，其依賴是使用IP版本4還是版本6有20字節(jié)或40字節(jié)的標(biāo)題。用于將IP分組封裝到藍(lán)牙TM幀中的BNEP標(biāo)題的范圍從3字節(jié)到15字節(jié)。可以看到健壯標(biāo)題壓縮(ROHC)被應(yīng)用于運(yùn)送RTP/UDP/IP流的BNEP幀。
為了在單一時(shí)隙DH1基帶分組中運(yùn)送壓縮幀，其具有27字節(jié)的有效負(fù)荷并且考慮4字節(jié)L2CAP標(biāo)題額外開(kāi)銷，RTP/UDP/IP/BNEP標(biāo)題需要被ROHC壓縮器縮短到3字節(jié)。如果BT系統(tǒng)和ROHC壓縮器如下面說(shuō)明的被正確地配置，則這個(gè)目標(biāo)可以達(dá)到。
建議的解決方案包括幾步-利用標(biāo)準(zhǔn)的藍(lán)牙TM業(yè)務(wù)發(fā)現(xiàn)協(xié)議來(lái)通告ROHC壓縮能力；-配置L2CAP信道來(lái)運(yùn)送被壓縮的比特流；-將BNEP靜態(tài)標(biāo)題域添加到ROHC上下文中(在單一VoIP會(huì)話中所有的BNEP標(biāo)題域是靜態(tài)的)；-使ROHC框架適合藍(lán)牙TM基帶重傳方案；以及-將BNEP幀分類，使得只有那些運(yùn)送VoIP分組的幀利用建議的ROHC-BNEP算法被壓縮。
通用的ROHC框架在上面被提到。在下一節(jié)中，其對(duì)于藍(lán)牙TM情況的應(yīng)用將被詳細(xì)描述，包括使用的分組類型，如何選擇分組類型以及壓縮器狀態(tài)之間的轉(zhuǎn)移如何被管理。ROHC-BNEP使用下列工具-RTP概況被使用；-ROHC雙向最有利模式是被使用的方法；在不成功解壓縮的情況下只有NACKS被反饋并且每當(dāng)可能的時(shí)候，我們都設(shè)法最小化其使用。
-只有小的R-CID，不需要大的CID空間，空的R-CID作為缺省被使用，這是因?yàn)槠洳恍枰粋鬏敗?br> -沒(méi)有UDP校驗(yàn)和被傳輸(只有當(dāng)有效負(fù)荷沒(méi)有被加密時(shí)，其可選地可在解壓縮器處被重新計(jì)算)。
-因?yàn)閷?duì)于相同的VoIP流整個(gè)BNEP標(biāo)題從不改變，所以其必須被考慮成靜態(tài)上下文的一部分。
-只有RTP序號(hào)和/或IP-ID被傳輸，這是因?yàn)橛糜讷@得RTP TS的函數(shù)是已知的(基于定時(shí)器的編碼被應(yīng)用來(lái)補(bǔ)償寂靜抑制)。
-反饋信道利用被最小化以便僅將上下文更新請(qǐng)求從解壓縮器運(yùn)送到壓縮器。
-在壓縮器中的“初始化和刷新”(IR)、“第一級(jí)”(FO)和“第二級(jí)”(SO)狀態(tài)之間的轉(zhuǎn)移以及在解壓縮器中的“沒(méi)有上下文”(NC)、“靜態(tài)上下文”(SC)以及“全上下文”(FC)狀態(tài)之間的轉(zhuǎn)移被定義。
藍(lán)牙TM上的ROHC利用圖7的狀態(tài)機(jī)進(jìn)一步被規(guī)定。對(duì)于每種壓縮器狀態(tài)，表明哪些信息被傳輸(頂)，哪些分組被使用(底)以及對(duì)于標(biāo)題信息多少字節(jié)被發(fā)送(括號(hào)之間)。狀態(tài)之間的轉(zhuǎn)移也被表明并且下面給出其解釋。
最初，壓縮器在IR狀態(tài)并且上下文的所有靜態(tài)和動(dòng)態(tài)部分在解壓縮器處被傳輸。只有在觀察時(shí)間t 1p(t)里丟失的分組數(shù)小于在觀察時(shí)間t-1 1p(t-1)里丟失的分組數(shù)時(shí)，才進(jìn)行從IR到FO的轉(zhuǎn)移。這些觀察時(shí)間是壓縮器記錄在可設(shè)置的時(shí)間閾值內(nèi)不能成功地被傳送到解壓縮器的VoIP幀的數(shù)量的固定時(shí)間點(diǎn)。對(duì)于在間隔(t-1，t)期間在藍(lán)牙TM堆棧中L2CAP層接收的每個(gè)L2CAP超時(shí)事件，1p(t)被增加1。僅當(dāng)壓縮器記錄輸入的VoIP流沒(méi)有顯示不規(guī)則(例如，語(yǔ)音編碼器中的寂靜抑制)時(shí)，從FO到SO的轉(zhuǎn)移才發(fā)生。一旦在SO狀態(tài)，如果IP流顯示不規(guī)則，壓縮器就返回FO。當(dāng)在FO狀態(tài)時(shí)，如果指示靜態(tài)上下文已經(jīng)被破壞的NAK分組通過(guò)反饋信道被接收，則壓縮器返回到IR狀態(tài)。
在藍(lán)牙TM上映射ROHC RTP在下一節(jié)中描述的ROHC-BNEP算法屬于ROHC雙向最有利算法，其在上面提到的C.Borman等人的“Robust Header Compression(ROHC)Framework and four profilesRTP，UDP，BSP anduncompressed(健壯標(biāo)題壓縮(ROHC)框架和四個(gè)概況RTP，UDP，BSP以及未壓縮的”)中被明確描述。
反饋信道利用被最小化以便僅將上下文更新請(qǐng)求從解壓縮器運(yùn)送到壓縮器。在ROHC RTP概況中使用的分組類型可在C.Borman等人的文章的5.2.7節(jié)中找到。解壓縮器在單向模式開(kāi)始并且將指示其在獲得上下文信息后想要轉(zhuǎn)換到最有利模式的反饋分組發(fā)送回壓縮器。壓縮器一接收到這樣的請(qǐng)求，其就停止發(fā)送周期性的IR更新并且進(jìn)入O模式，因此節(jié)省了帶寬。
為了評(píng)估藍(lán)牙TM系統(tǒng)中ROHC-BNEP RTP/UDP/IP標(biāo)題壓縮算法的效果，需要進(jìn)行某些考慮。首先，藍(lán)牙TM邏輯鏈路控制和適配層(L2CAP)將被考慮，然后基帶錯(cuò)誤處理機(jī)制將被再訪問(wèn)。
鏈路層成幀L2CAP層為藍(lán)牙TM堆棧提供邏輯信道和分段以及重新組裝(SAR)功能。邏輯信道由信道ID(CID)識(shí)別并且由對(duì)等實(shí)體之間的專用L2CAP信令消息利用已有的基帶連接來(lái)建立。相同的基帶連接上的兩個(gè)BT設(shè)備之間的幾個(gè)邏輯信道可以被建立。對(duì)于每個(gè)邏輯信道，鏈路層最大傳輸單元(MTU)被定義，其限制了L2CAP最大幀的尺寸。L2CAP SAR功能使得L2CAP幀被分段成多個(gè)基帶分組，這些基帶分組被順次傳輸。
因?yàn)榛鶐硬辉试S我們?cè)贚2CAP連接之間區(qū)分，因此屬于不同L2CAP幀的基帶分組不能被交織。換句話說(shuō)，一旦L2CAP幀的第一個(gè)分組已經(jīng)被傳輸，則相同邏輯連接的所有剩余分組必須跟隨。
這個(gè)特征暗示如果兩個(gè)應(yīng)用正在使用相同的邏輯信道(或者即使它們使用兩個(gè)不同的邏輯信道)，則具有低優(yōu)先級(jí)的較長(zhǎng)的幀可以延遲具有較高優(yōu)先級(jí)的較短的幀的傳輸。
因此建議正確地使用L2CAP MTU參數(shù)來(lái)避免這些阻塞效果。作為例子我們考慮具有VoIP應(yīng)用的BT客戶端以及一個(gè)或多個(gè)TCP/IP連接。所述兩個(gè)應(yīng)用有不同的特征，這是因?yàn)榈谝粋€(gè)是延遲敏感的并且具有短分組而第二個(gè)沒(méi)有延遲約束但是分組可以多達(dá)1500字節(jié)長(zhǎng)。為了避免延遲實(shí)時(shí)業(yè)務(wù)量，小的MTU也必須被用于TCP/IP連接，即使這在IP層引入大的分段存儲(chǔ)額外開(kāi)銷。
上面的兩種應(yīng)用有不同的可靠性要求對(duì)于實(shí)時(shí)業(yè)務(wù)量，因超過(guò)某個(gè)閾值的傳輸錯(cuò)誤而被延遲的分組不再有用并且可以被丟棄，而對(duì)于TCP/IP數(shù)據(jù)連接則不是這樣。
利用一個(gè)可設(shè)置的值可以把自動(dòng)的刷新超時(shí)應(yīng)用于每個(gè)L2CAP邏輯信道。在我們的仿真中，12.5毫秒的超時(shí)被用于丟棄VoIP幀。
在如我們上面的例子中TCP/IP和RTP/UDP/IP在相同的BT鏈路上同時(shí)出現(xiàn)的情況中，需要評(píng)估是否也允許丟棄TCP/IP幀以便改良VoIP應(yīng)用的質(zhì)量。這個(gè)選擇依賴于許多因素并且在實(shí)時(shí)和數(shù)據(jù)業(yè)務(wù)量上都有暗示(在后一種情況中，必須考慮TCP/IP重傳)。
當(dāng)在藍(lán)牙TM系統(tǒng)中應(yīng)用ROHC-BT算法時(shí)，延遲敏感的邏輯信道的L2CAP超時(shí)的數(shù)量對(duì)于增加標(biāo)題壓縮機(jī)制的錯(cuò)誤健壯性扮演重要的角色。事實(shí)上，L2CAP超時(shí)事件指示幀被丟失，因此標(biāo)題壓縮器可以例如通過(guò)選擇合適的ROHC分組類型，利用這個(gè)信息來(lái)增大窗口。
錯(cuò)誤處理藍(lán)牙TM基帶中的ARQ機(jī)制使得接收機(jī)必須在下一個(gè)分組被傳輸之前肯定地確認(rèn)每個(gè)基帶分組。如果在數(shù)據(jù)分組或者在確認(rèn)消息中出現(xiàn)傳輸錯(cuò)誤，則該分組必須被重傳。導(dǎo)致分組重傳的錯(cuò)誤條件包括-基帶分組存取碼沒(méi)有被接收；-基帶分組標(biāo)題中不可糾正的錯(cuò)誤；-分組有效負(fù)荷中不可糾正的錯(cuò)誤(只要這樣的錯(cuò)誤條件在確認(rèn)分組中出現(xiàn)，就不觸發(fā)重傳，這是因?yàn)锳CK域在分組標(biāo)題中被運(yùn)送)。
在接收機(jī)處組裝的幀被傳遞到上層之前，作為相同的L2CAP幀的一部分的所有的基帶分組必須被正確地接收。在發(fā)送機(jī)中，L2CAP幀被分段成的所有的基帶分組在可設(shè)置的時(shí)間里必須被肯定地確認(rèn)以避免L2CAP超時(shí)事件。
當(dāng)出現(xiàn)L2CAP超時(shí)事件時(shí)，發(fā)送機(jī)利用HCI_Flush命令(參見(jiàn)藍(lán)牙TMSIG，“Core Specifications，vl.1(核心規(guī)范vl.1)”，H1部分，4.7.4節(jié))刷新L2CAP層和主控制器中的所有剩余的基帶分組。這個(gè)命令對(duì)于特定的連接處理來(lái)重置所有等待狀態(tài)的重傳。只有當(dāng)被標(biāo)記為新的一幀的開(kāi)始的新的HCI數(shù)據(jù)分組被接收時(shí)，正常的操作才被恢復(fù)。
利用L2CAP信道配置中的Flush_Timeout選項(xiàng)來(lái)通知L2CAP連接的接受者關(guān)于發(fā)送機(jī)的L2CAP超時(shí)(參見(jiàn)藍(lán)牙TMSIG，“CoreSpecifications，vl.1(核心規(guī)范vl.1)”，D部分，6.2節(jié))。
點(diǎn)到多點(diǎn)當(dāng)VoIP發(fā)送機(jī)在藍(lán)牙TM從單元上運(yùn)行并且主單元具有連接到其上的其他從單元時(shí)，對(duì)于輪詢?cè)L問(wèn)方案應(yīng)該給予某些考慮。
首先，從單元應(yīng)該以與VoIP分組的生成相匹配的速率來(lái)請(qǐng)求要被輪詢的主單元(例如每30毫秒)。這通過(guò)用命令HCI_QoS_setup協(xié)商合適的Tpol1來(lái)實(shí)現(xiàn)，其被翻譯為L(zhǎng)MP_quality_of_service_request。
但是，在點(diǎn)到多點(diǎn)配置的情況下，藍(lán)牙TM基帶的未編號(hào)的ARQ方案指示下次主單元輪詢從單元時(shí)由從節(jié)點(diǎn)向主節(jié)點(diǎn)發(fā)送的分組可被確認(rèn)(參見(jiàn)藍(lán)牙TMSIG，“Core Specifications，vl.1(核心規(guī)范vl.1)”，B部分，5.3.1節(jié))。這意味著在從單元中可以依賴于主單元的調(diào)度策略來(lái)觸發(fā)L2CAP超時(shí)。
配置初始配置過(guò)程如圖3所示，其中流在個(gè)人區(qū)域網(wǎng)用戶(PANU)和網(wǎng)絡(luò)接入點(diǎn)NAP(AP1-n)之間。一旦首先連接到接入點(diǎn)AP1-n，手機(jī)MT就執(zhí)行SDP查詢來(lái)獲得關(guān)于接入點(diǎn)AP1-n支持的業(yè)務(wù)的信息。接入點(diǎn)AP1-n必須分別為標(biāo)準(zhǔn)的BNEP協(xié)議(PSM值被分配)以及在本文檔中規(guī)定的新的ROHC-BNEP協(xié)議(為此必須使用動(dòng)態(tài)PSM)來(lái)通告PAN和ROHC-BNEP能力。
首先通過(guò)請(qǐng)求BNEP特定的PSM來(lái)創(chuàng)建L2CAP可靠連接。然后利用在SDP記錄中被通告的對(duì)于ROHC-BNEP的動(dòng)態(tài)PSM值來(lái)創(chuàng)建第二個(gè)L2CAP連接。將利用L2CAP業(yè)務(wù)質(zhì)量(QoS)建立消息把這第二個(gè)連接配置為不可靠的。這使得對(duì)于VoIP分組的重傳數(shù)量被限制事實(shí)上，如果分組在某個(gè)時(shí)間量?jī)?nèi)沒(méi)有被成功地傳送，則其對(duì)于接收機(jī)將變得無(wú)用并且可以被丟棄，由此節(jié)省了帶寬。為此目的，L2CAP超時(shí)需要與基帶刷新命令相耦合，其暫停分組重傳并且釋放BT鏈路管理器中所有涉及的緩存。概括地說(shuō)，移動(dòng)手機(jī)需要配置兩個(gè)邏輯信道，一個(gè)用于運(yùn)送標(biāo)準(zhǔn)的IP業(yè)務(wù)量并且另一個(gè)用于運(yùn)送壓縮的VoIP流。一旦L2CAP邏輯信道被建立，移動(dòng)終端和接入點(diǎn)就必須始終如一地使用它們，如下面的小節(jié)所述。
如果只有一個(gè)L2CAP信道在接入點(diǎn)AP和移動(dòng)終端MT之間可以被建立，則“不可靠的”信道還應(yīng)該被用于數(shù)據(jù)連接以便保護(hù)VoIP流。在不可靠邏輯信道上數(shù)據(jù)分組的丟失可通過(guò)更高層的協(xié)議(例如TCP/IP)來(lái)處理。
發(fā)送機(jī)和接收機(jī)邏輯在發(fā)送機(jī)中，每當(dāng)BNEP幀需要被遞送到L2CAP時(shí)，就可以使用圖4a中描述的算法。
首先，BNEP幀必須被分類以便理解其是否必須被壓縮。事實(shí)上，只有運(yùn)送RTP/UDP/IP分組的BNEP幀必須用建議的ROHC-BNEP算法來(lái)處理。
下面的BNEP標(biāo)題域被檢查-BNEP目的地地址(對(duì)端必須有ROHC功能)
-BNEP協(xié)議類型(必須是“IP”或“IPv6”，對(duì)于以太網(wǎng)幀標(biāo)記，IEEE802.1p和IEEE802.1q也必須被解釋，這是因?yàn)樗鼈円脖挥糜诰哂蠶oS支持的LAN中)-IP協(xié)議類型(必須是UDP)-UDP端口(必須對(duì)應(yīng)于H.323)如果BNEP幀必須被壓縮，則其ROHC上下文被檢索并且所得到的壓縮幀需要利用對(duì)應(yīng)于不可靠信道的L2CAP CID(L-CID)被發(fā)送到L2CAP層。如果該幀不是必須被壓縮，則替代地使用可靠信道的L-CID。
在接收機(jī)中，如圖4b所描述，如果幀從對(duì)應(yīng)于ROHC-BNEP L-CID的不可靠信道到達(dá)，則假設(shè)ROHC-BNEP解壓縮必須被應(yīng)用。在成功重建之后，該幀被遞送到BNEP層。
在壓縮幀不能被正確地重建的情況下，其在解壓縮器中被丟棄。在N2個(gè)連續(xù)壓縮分組不能被重建之后，利用不可靠信道和ROHC反饋分組類型，否定ACK被發(fā)送回對(duì)端ROHC壓縮器(對(duì)于ROHC算法的描述參見(jiàn)后面章節(jié))。N2被設(shè)置為例如15。
對(duì)于ROHC-over-BNEP方案的框圖如圖5所描述。ROHC編解碼器和所有相關(guān)的邏輯可以用軟件產(chǎn)品的形式被實(shí)現(xiàn)，該軟件產(chǎn)品與藍(lán)牙TM網(wǎng)接口軟件驅(qū)動(dòng)器關(guān)聯(lián)運(yùn)行。這個(gè)軟件產(chǎn)品包括BNEP和L2CAP層、幀分類器、ROHC編解碼器以及管理實(shí)體(ME)，其協(xié)調(diào)各種塊。ME可以通過(guò)標(biāo)準(zhǔn)的HCI接口(當(dāng)存在時(shí))與BT基帶通信以及利用操作系統(tǒng)特定機(jī)制與上層通信。
每次移動(dòng)終端MT1-n連接到AP1-n，ME就登記其MAC地址并且為其配置邏輯信道。在藍(lán)牙TM中，邏輯信道以兩個(gè)稱作L2CAP信道ID(L-CID)的信道端點(diǎn)為特征。一旦信道建立，每個(gè)對(duì)等端就指定其自己的本地L-CID并且將其發(fā)送到遠(yuǎn)程設(shè)備。因此，為了ROHC，下表可以被建立。
表9-AP的ROHC-BNEP示例配置在表9的例子中，AP1連接有兩個(gè)移動(dòng)終端MT1，2。MT1配置了兩個(gè)邏輯信道，一個(gè)用于正常IP業(yè)務(wù)量并且一個(gè)用于VoIP。這第二個(gè)信道將使用空的ROHC上下文ID。當(dāng)MT2連接到接入點(diǎn)AP1時(shí)，其為VoIP配置信道在這種情況下空R-CID也可被使用。但是，當(dāng)MT1為第二個(gè)RTP/UDP/IP/BNEP流配置另一個(gè)信道時(shí)(第4行)，因?yàn)楝F(xiàn)在MT1有兩個(gè)必須被單獨(dú)處理的實(shí)時(shí)流(例如一個(gè)語(yǔ)音信道以及一個(gè)視頻信道)，所以不同的ROHC上下文必須被使用。
通過(guò)在移動(dòng)終端和接入點(diǎn)之間應(yīng)用這里公開(kāi)的建議的健壯標(biāo)題壓縮技術(shù)，可能節(jié)省帶寬，從而處理相同微微網(wǎng)中更多數(shù)量的連接。
雖然本發(fā)明關(guān)于優(yōu)選實(shí)施方案被特別顯示和描述，但是本領(lǐng)域的技術(shù)人員應(yīng)該理解在不背離本發(fā)明的范圍和精神的情況下可以有形式和細(xì)節(jié)的改變。
詞匯表
權(quán)利要求
1.一種用于在第一個(gè)單元和第二個(gè)單元之間的基于分組的無(wú)線傳輸?shù)姆椒ǎ龇椒òㄒ粋€(gè)所述單元a) 將實(shí)時(shí)比特流轉(zhuǎn)換成預(yù)定最大長(zhǎng)度的一個(gè)或多個(gè)有效負(fù)荷；b) 將一個(gè)或多個(gè)預(yù)定義標(biāo)題應(yīng)用于所述或每個(gè)所述有效負(fù)荷以便生成適合于根據(jù)預(yù)定義通信協(xié)議在所述單元之間傳輸?shù)姆纸M；c) 將所述或每個(gè)所述分組封裝在適合于跨越所述單元之間的無(wú)線連接傳送所述或每個(gè)所述分組的封裝協(xié)議的幀里；以及d) 將預(yù)定義的標(biāo)題壓縮技術(shù)應(yīng)用于所述或每個(gè)所述封裝的分組中。
2.根據(jù)權(quán)利要求1所述的方法，包括從包含諸如互聯(lián)網(wǎng)協(xié)議上的語(yǔ)音(VoIP)、音頻或視覺(jué)流之類的互聯(lián)網(wǎng)協(xié)議(IP)業(yè)務(wù)量的一個(gè)所述實(shí)時(shí)比特流中生成所述或每個(gè)所述有效負(fù)荷。
3.根據(jù)權(quán)利要求1或者權(quán)利要求2所述的方法，包括執(zhí)行所述第一和第二個(gè)單元之間的業(yè)務(wù)發(fā)現(xiàn)過(guò)程以及在所述業(yè)務(wù)發(fā)現(xiàn)過(guò)程期間通告所述標(biāo)題壓縮技術(shù)。
4.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括配置一個(gè)或多個(gè)分段，重新組裝以及多路復(fù)用所述預(yù)定義通信協(xié)議的業(yè)務(wù)以便運(yùn)送壓縮的比特流。
5.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括通過(guò)向適合于應(yīng)用所述標(biāo)題壓縮技術(shù)的壓縮器和解壓縮器的上下文中添加封裝協(xié)議信息來(lái)應(yīng)用所述標(biāo)題壓縮，所述信息包括例如所述封裝協(xié)議的靜態(tài)標(biāo)題域。
6.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，所述單元包括藍(lán)牙TM網(wǎng)的一部分并且所述方法包括利用包括藍(lán)牙TM網(wǎng)封裝協(xié)議(BNEP)的封裝協(xié)議來(lái)封裝所述或每個(gè)所述分組。
7.根據(jù)權(quán)利要求6所述的方法，包括優(yōu)選地通過(guò)將所述預(yù)定的標(biāo)題和BNEP標(biāo)題的組合縮短到例如3字節(jié)的預(yù)定長(zhǎng)度，來(lái)用所述標(biāo)題壓縮技術(shù)將所述或每個(gè)所述封裝的分組壓縮到單一時(shí)隙藍(lán)牙TM基帶分組中。
8.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括以諸如由互聯(lián)網(wǎng)工程任務(wù)組(IETF)通過(guò)的ROHC之類的健壯標(biāo)題壓縮(ROHC)框架的形式來(lái)應(yīng)用所述標(biāo)題壓縮技術(shù)。
9.根據(jù)權(quán)利要求8所述的方法，包括下列的一個(gè)或多個(gè)a) 為所述分組使用實(shí)時(shí)協(xié)議(RTP)概況；b) 使用IETF ROHC雙向最有利方法(o模式)；c) 使用小ROHC上下文標(biāo)識(shí)符(R-CID)，空R-CID是缺省值；d) 不發(fā)送通用數(shù)據(jù)報(bào)協(xié)議(UDP)校驗(yàn)和，可選地在解壓縮器中對(duì)其重新計(jì)算；e) 在任何一個(gè)分組流期間將整個(gè)封裝協(xié)議標(biāo)題考慮作為靜態(tài)上下文的一部分；f) 僅發(fā)送實(shí)時(shí)協(xié)議(RTP)序號(hào)和/或互聯(lián)網(wǎng)協(xié)議身份；g) 定義壓縮器中的“初始化和刷新”(IR)、“第一級(jí)”(FO)和“第二級(jí)”(SO)狀態(tài)之間以及解壓縮器中的“沒(méi)有上下文”(NC)、“靜態(tài)上下文”(SC)以及“全上下文”(FC)狀態(tài)之間的轉(zhuǎn)移。
10.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括將封裝幀分類使得只有預(yù)定的所述幀利用所述標(biāo)題壓縮技術(shù)被壓縮。
11.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括根據(jù)實(shí)時(shí)協(xié)議(RTP)、通用數(shù)據(jù)報(bào)協(xié)議(UDP)以及互聯(lián)網(wǎng)協(xié)議中的一個(gè)或多個(gè)將標(biāo)題應(yīng)用于所述有效負(fù)荷。
12.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括所述單元配置多個(gè)邏輯信道用于這些單元之間的通信，至少一個(gè)所述信道專用于所述壓縮的封裝的分組的傳送。
13.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括將所述標(biāo)題壓縮技術(shù)基于窗口一最低有效位編碼(W-LSB)。
14.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括通過(guò)提供適合于錯(cuò)誤恢復(fù)請(qǐng)求以及可選地地適合于上下文更新確認(rèn)的所述單元之間的反饋信道來(lái)管理壓縮器和解壓縮器狀態(tài)之間的轉(zhuǎn)換。
15.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括一個(gè)所述單元接收被分段成基帶分組的一連串所述壓縮的封裝的幀，在下一個(gè)所述分組被傳輸之前肯定確認(rèn)每個(gè)所述分組，以及如果在最近的所述分組或者確認(rèn)消息中出現(xiàn)傳輸錯(cuò)誤，則所述最近的分組被重傳。
16.根據(jù)權(quán)利要求15所述的方法，包括如果下列情況的至少一種發(fā)生，則重傳所述分組a)基帶分組存取碼沒(méi)有被接收；b)在基帶分組標(biāo)題中出現(xiàn)無(wú)法糾正的錯(cuò)誤；或者c)在所述分組的所述有效負(fù)荷中存在無(wú)法糾正的錯(cuò)誤。
17.根據(jù)前面任何一個(gè)權(quán)利要求所述的方法，包括例如通過(guò)設(shè)置所述幀的成功遞送的超時(shí)來(lái)限制對(duì)于一個(gè)所述壓縮的封裝的幀的多個(gè)重傳。
18.一種用于執(zhí)行第一個(gè)單元和第二個(gè)單元之間的基于分組的無(wú)線傳輸?shù)能浖a(chǎn)品，所述產(chǎn)品包括執(zhí)行以下操作的代碼a)將實(shí)時(shí)比特流轉(zhuǎn)換成預(yù)定的最大長(zhǎng)度的一個(gè)或多個(gè)有效負(fù)荷；b)將一個(gè)或多個(gè)預(yù)定義標(biāo)題應(yīng)用于所述或每個(gè)所述有效負(fù)荷以便生成適合于根據(jù)預(yù)定義的通信協(xié)議在所述單元之間傳輸?shù)姆纸M；c)將所述或每個(gè)所述分組封裝在適合于跨越所述單元之間的無(wú)線連接傳送所述或每個(gè)所述分組的封裝協(xié)議的幀中；以及d)將預(yù)定義標(biāo)題壓縮技術(shù)應(yīng)用于所述或每個(gè)所述封裝的分組。
19.一種基于分組的無(wú)線通信設(shè)備，包括適合于基本上實(shí)時(shí)地向第二個(gè)單元發(fā)送信息的第一個(gè)單元，所述第一個(gè)單元適合于a)將實(shí)時(shí)比特流轉(zhuǎn)換成一個(gè)或多個(gè)預(yù)定最大長(zhǎng)度的有效負(fù)荷；b)將一個(gè)或多個(gè)預(yù)定義標(biāo)題應(yīng)用于所述或者每個(gè)所述有效負(fù)荷以便生成適合于根據(jù)預(yù)定義的通信協(xié)議在所述單元之間傳輸?shù)姆纸M；c)將所述或每個(gè)所述分組封裝在適合于跨越所述單元之間的無(wú)線連接傳送所述或每個(gè)所述分組的封裝協(xié)議的幀中；以及d)將預(yù)定義標(biāo)題壓縮技術(shù)應(yīng)用于所述或每個(gè)所述封裝的分組。
20.根據(jù)權(quán)利要求20所述的無(wú)線通信設(shè)備，所述第一個(gè)單元根據(jù)藍(lán)牙TM協(xié)議操作，所述封裝協(xié)議優(yōu)選地包括藍(lán)牙網(wǎng)封裝協(xié)議(BNEP)并且所述標(biāo)題壓縮技術(shù)優(yōu)選地與互聯(lián)網(wǎng)工程任務(wù)組(IETF)健壯標(biāo)題壓縮(ROHC)技術(shù)兼容。
21.一種適合于根據(jù)權(quán)利要求1到19的任何一個(gè)所述的方法來(lái)操作并且優(yōu)選地至少臨時(shí)地被配置為藍(lán)牙TM通信網(wǎng)的主單元和從單元中的至少一個(gè)的無(wú)線通信單元。
全文摘要
一種用于第一個(gè)單元AP和第二個(gè)單元MT之間的無(wú)線傳輸?shù)姆椒ū还_(kāi)。所述方法包括所述單元AP、MT將實(shí)時(shí)比特流(例如VoIP、音頻和視頻)轉(zhuǎn)換成預(yù)定最大長(zhǎng)度的一個(gè)或多個(gè)有效負(fù)荷。一個(gè)或多個(gè)預(yù)定義標(biāo)題(RTP/UDP/IP)被應(yīng)用于所述或每個(gè)所述有效負(fù)荷以便生成適合于根據(jù)預(yù)定義的通信協(xié)議在所述單元AP、MT之間傳輸?shù)姆纸M。然后所述或者每個(gè)分組被封裝在適合于跨越在所述單元MT、AP之間的無(wú)線連接發(fā)送所述或每個(gè)分組的封裝協(xié)議(BNEP)的幀里。然后預(yù)定義的標(biāo)題壓縮技術(shù)(IETF ROHC)被應(yīng)用于所述或者每個(gè)封裝的分組。
文檔編號(hào)H04L12/56GK1636374SQ02822036
公開(kāi)日2005年7月6日 申請(qǐng)日期2002年10月24日 優(yōu)先權(quán)日2001年11月6日
發(fā)明者D·梅皮納諾 申請(qǐng)人:皇家飛利浦電子股份有限公司