專利名稱：分組發(fā)送裝置、分組接收裝置和分組傳輸方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種分組發(fā)送裝置、一種分組接收裝置和一種分組傳輸方法。尤其是，本發(fā)明涉及一種壓縮分組的首標(biāo)(header)并執(zhí)行發(fā)送的分組發(fā)送裝置、一種解壓縮接收分組的首標(biāo)的分組接收裝置以及一種分組傳輸方法。
背景技術(shù)：
目前，用于在因特網(wǎng)上發(fā)送分組的典型協(xié)議(通信規(guī)則)包括RTP(實(shí)時(shí)傳輸協(xié)議)、UDP(用戶數(shù)據(jù)協(xié)議)和IP(因特網(wǎng)協(xié)議)。在分組發(fā)送中，這些協(xié)議通常被結(jié)合起來使用。此外，這些協(xié)議被IETF(因特網(wǎng)工程任務(wù)組)標(biāo)準(zhǔn)化。
在上述每一協(xié)議中，諸如下面所描述的信息被作為首標(biāo)附加在發(fā)送數(shù)據(jù)上以生成分組。即，根據(jù)如圖1A中所示出的RPT，在數(shù)據(jù)上附加表示數(shù)據(jù)順序的序列號(下文中為“SN”)和作為時(shí)間信息的時(shí)間戳(timestamp)以產(chǎn)生RTP分組。隨后，根據(jù)如圖1B中所示出的UDP，在RTP分組上附加接收端的端口號以生成UDP分組。而且，根據(jù)如圖1C中所示出的IP，在UDP分組上附加因特網(wǎng)(IP地址)的接收端地址以產(chǎn)生IP分組。隨后，該IP分組被發(fā)送到接收端。
首標(biāo)壓縮技術(shù)是通過壓縮首標(biāo)和執(zhí)行發(fā)送以改善分組發(fā)送效率的技術(shù)。在IETF的RFC 2508(Request For Comments，請求注解)中規(guī)定了在RTP、UDP和IP中附加相應(yīng)首標(biāo)的壓縮方法。在RFC2508規(guī)定的首標(biāo)壓縮方法主要是用于諸如因特網(wǎng)的有線分組發(fā)送。
與此形成對照，當(dāng)前IETF建議的用于諸如在蜂窩式電話網(wǎng)絡(luò)的無線分組發(fā)送中的首標(biāo)壓縮方法是ROHC(Robust Header Compression，魯棒首標(biāo)壓縮)。在無線區(qū)域的錯(cuò)誤發(fā)生率傾向于比有線區(qū)域的錯(cuò)誤發(fā)生率要高，ROHC是一種對發(fā)生在傳送期間的錯(cuò)誤具有高容錯(cuò)特征的首標(biāo)壓縮方法。
而且，考慮到在無線區(qū)域中可使用的帶寬比有線區(qū)域要窄，ROHC設(shè)置比在RFC 2508中規(guī)定的壓縮方法更高的壓縮率，順便提及，在RFC 3095中，IETF將ROHC標(biāo)準(zhǔn)化。
更具體地，ROHC如下壓縮首標(biāo)。也就是說，并非每次而是在預(yù)定時(shí)間間隔發(fā)送包含IP地址和端口號等的未壓縮的首標(biāo)。如果在SN的增加和TN的增加之間出現(xiàn)某種規(guī)律性，則只單獨(dú)發(fā)送SN。而且，對于SN，只發(fā)送低位的幾個(gè)比特，并且只有當(dāng)發(fā)生進(jìn)位時(shí)才發(fā)送所有的比特。在發(fā)送端，首標(biāo)壓縮是參照稱為上下文(context)的參考信息來執(zhí)行的，并且，在接收端，首標(biāo)解壓縮是參照與發(fā)送端的相同的上下文來執(zhí)行的。
而且，在ROHC中，有如圖2A-2C所示的三種類型的首標(biāo)，分別稱為UPDATE_FULLHEADER、UPDATE和NON_UPDATE。
在圖2A中示出的UPDATE_FULLHEADER中，除了包含在接收端解壓縮首標(biāo)時(shí)用于檢查解壓縮是否成功的SN和CRC(循環(huán)冗余校驗(yàn))比特之外，還包含IP地址、端口號，TS和△TS，該△TS是對應(yīng)于SN中的增量的TS中的增量。這樣就構(gòu)成了未壓縮的首標(biāo)。該UPDATE_FULLHEADER在每個(gè)間隔或每當(dāng)△TS發(fā)生變化時(shí)被更新。在圖2B中示出的UPDATE不包含IP地址、端口號、TS和△TS，但是包含SN和CRC比特。而且，在圖2C中示出的NON_UPDATE不包含IP地址、端口號、TS和△TS，但是包含由SN的低位的一些比特表示的SN′和CRC比特。
對于每個(gè)UPDATE_FULLHEADER、UPDATE和NON_UPDATE，接收端變化以更新或不更新上下文。即在接收端，當(dāng)接收到UPDATE_FULLHEADER時(shí)，使用所接收首標(biāo)的內(nèi)容原封不動地作為上下文來更新上下文。當(dāng)接收到UPDATE時(shí)，參照上下文解壓縮首標(biāo)，并且隨后使用所解壓縮的首標(biāo)的內(nèi)容來更新上下文。此外，當(dāng)接收到NON-UPDATE時(shí)，雖然參照上下文解壓縮首標(biāo)，但并不對上下文進(jìn)行更新。
下面將參照時(shí)序圖說明使用ROHC的分組發(fā)送/接收步驟的例子。圖3是說明使用ROHC的分組發(fā)送/接收的傳統(tǒng)步驟的時(shí)序圖。
參照圖3，發(fā)送端(即首標(biāo)壓縮端)在通信開始后首先發(fā)送SN＝1的UPDATE_FULLHEADER。在發(fā)送端，當(dāng)UPDATE_FULLHEADER被發(fā)送時(shí)上下文被更新。類似的，在接收端(即首標(biāo)解壓縮端)，當(dāng)接收到UPDATE_FULLHEADER時(shí)上下文被更新。通過這種方式，發(fā)送端和接收端的上下文匹配了。
當(dāng)發(fā)送SN＝2和SN＝3時(shí)，發(fā)送端參照(with reference to)由SN＝1的UPDATE_FULLHEADER更新的上下文產(chǎn)生和發(fā)送NON-UPDATE?；诒话l(fā)送的SN和上下文的SN之間的比較結(jié)果，發(fā)送端確定在SN中未產(chǎn)生進(jìn)位，并且發(fā)送NON-UPDATE。當(dāng)接收到SN＝2和SN＝3時(shí)，接收端參照由SN＝1的UPDATE_FULLHEADER更新的上下文對首標(biāo)進(jìn)行解壓縮。
當(dāng)發(fā)送SN＝4時(shí)，發(fā)送端參照由SN＝1的UPDATE_FULLHEADER更新的上下文發(fā)送UPDATE?；诒话l(fā)送的SN和上下文的SN之間的比較結(jié)果，發(fā)送端確定在SN中發(fā)生了進(jìn)位(carry)，并且發(fā)送UPDATE。當(dāng)發(fā)送UPDATE時(shí)，發(fā)送端更新上下文。當(dāng)接收SN＝4時(shí)，接收端參照由SN＝1的UPDATE_FULLHEADER更新的上下文對首標(biāo)解壓縮，并且隨后使用解壓縮的首標(biāo)的內(nèi)容來更新上下文。通過這種方式，發(fā)送端和接收端的上下文就匹配了。
順便提及，此處的進(jìn)位是指假定使用預(yù)定個(gè)數(shù)的二進(jìn)制比特表示SN′時(shí)，上下文的SN的最高有效位和分組的SN的最高有效位之間的不匹配。例如，參照圖3中示出的SN＝1到SN＝4，如果SN用3個(gè)比特表示而SN′用2個(gè)比特表示，當(dāng)從SN＝3變到SN＝4時(shí)，“011”變成“100”，則發(fā)生進(jìn)位，這里SN′從“11”變成“00”，這使得難以判斷在解壓縮前的SN究竟是“100”還是“000”。因此，每當(dāng)發(fā)生進(jìn)位時(shí)，發(fā)送一個(gè)UPDATE并且更新上下文。
在SN＝5到SN＝99，重復(fù)上面相同的步驟。當(dāng)發(fā)送SN＝100的時(shí)，發(fā)送端發(fā)送UPDATE_FULLHEADER。即在該例子中，每一百次會發(fā)送一次UPDATE_FULLHEADER。
當(dāng)接收到UPDATE_FULLHEADER時(shí)，接收端無論上下文怎樣，使用所接收首標(biāo)的內(nèi)容原封不動地更新上下文，并且通過這樣規(guī)則地發(fā)送UPDATE_FULLHEADER，可以防止接收端參照錯(cuò)誤的上下文和解壓縮錯(cuò)誤的首標(biāo)。
順便談及，如圖2A到2C所示，發(fā)送的分組均被附加CRC比特，所以，在首標(biāo)被解壓縮后，接收端可以檢測在解壓縮的首標(biāo)中的錯(cuò)誤和丟棄有錯(cuò)誤的分組。然而，當(dāng)出現(xiàn)超過錯(cuò)誤檢測能力的錯(cuò)誤時(shí)，就有可能出現(xiàn)CRC不能檢測到錯(cuò)誤的情況。
例如，如圖4所示，當(dāng)在SN＝4的UPDATE的發(fā)送期間發(fā)生錯(cuò)誤并且當(dāng)接收端不能檢測到錯(cuò)誤時(shí)，將使用錯(cuò)誤的首標(biāo)更新上下文。這樣，由SN＝4的首標(biāo)更新的上下文變成了錯(cuò)誤的上下文。在SN＝5到SN＝99，接收端參照這個(gè)錯(cuò)誤的上下文解壓縮首標(biāo)，所以SN＝5到SN＝99的首標(biāo)全部變成錯(cuò)誤的(即CRC＝NG)，并且SN＝5到SN＝99的分組被全部丟棄。也就是說，這將導(dǎo)致在接收端SN＝5到SN＝99的數(shù)據(jù)被丟失的情況。
所以，如圖5所示，可以采用下面步驟，當(dāng)在首標(biāo)中檢測到錯(cuò)誤(即CRC＝NG)時(shí)，接收端向發(fā)送端發(fā)出用于更新上下文的請求，并且發(fā)送端響應(yīng)該更新請求發(fā)送UPDATE_FULLHEADER。通過采用上述步驟，在接收端的上下文被SN＝7的UPDATE_FULLHEADER更新為正確的上下文，所以可以縮短丟失數(shù)據(jù)的時(shí)間周期。
接收端還可以通過CRC的方式檢測到錯(cuò)誤，但還是不能知道錯(cuò)誤的原因。換句話說，當(dāng)在首標(biāo)中檢測到錯(cuò)誤時(shí)，接收端無法判斷該錯(cuò)誤究竟是特定于首標(biāo)并且發(fā)生在發(fā)送分組期間，還是由于錯(cuò)誤的上下文導(dǎo)致的錯(cuò)誤。換句話說，不能判定上下文是否是錯(cuò)誤的。
當(dāng)上下文正確時(shí)，接收端即使是在首標(biāo)中檢測到錯(cuò)誤的情況下也不需要請求更新上下文。然而，在圖5所示的步驟中，當(dāng)在首標(biāo)中檢測到錯(cuò)誤時(shí)，總是請求上下文的更新。因此，在圖5所示的步驟中，可能會出現(xiàn)盡管發(fā)送UPDATE或NON-UPDATE就夠了而仍然發(fā)送UPDATE_FULLHEADER的情況。
UPDATE_FULLHEADER在首標(biāo)域中攜帶比UPDATE或NON-UPDATE數(shù)據(jù)量更大的數(shù)據(jù)。因此，采用如圖5中所示的步驟降低了首標(biāo)壓縮的效率。換句話說，分組發(fā)送的效率降低了。

發(fā)明內(nèi)容
因此本發(fā)明的一個(gè)目的是提供一種分組發(fā)送裝置、一種分組接收裝置和一種分組傳輸方法，它們不降低首標(biāo)壓縮效率和分組發(fā)送效率并且能縮短接收端丟失數(shù)據(jù)的時(shí)間周期。
當(dāng)上下文錯(cuò)誤時(shí)，所有根據(jù)該上下文解壓縮的首標(biāo)都變成錯(cuò)誤的。相反，當(dāng)上下文沒有錯(cuò)誤時(shí)，根據(jù)該上下文解壓縮的首標(biāo)可能是錯(cuò)誤的，也可能不是錯(cuò)誤的。即當(dāng)上下文錯(cuò)誤時(shí)，在首標(biāo)中連續(xù)出現(xiàn)錯(cuò)誤并且錯(cuò)誤發(fā)生的頻率因此增加，而當(dāng)上下文沒有錯(cuò)誤時(shí)，發(fā)生錯(cuò)誤的頻率減小。
在對出錯(cuò)頻率的長時(shí)間思考后，發(fā)明人得出了本發(fā)明并且發(fā)現(xiàn)可以基于錯(cuò)誤發(fā)生的頻率增加或減小來判定上下文是否出錯(cuò)。
現(xiàn)在，為了達(dá)到上面的目標(biāo)，本發(fā)明被構(gòu)造成當(dāng)錯(cuò)誤發(fā)生頻率高時(shí)，判定上下文是錯(cuò)誤的并且更新上下文，而當(dāng)錯(cuò)誤發(fā)生的頻率低時(shí)，判定錯(cuò)誤不是由上下文造成的而是特定于分組的首標(biāo)在發(fā)送分組期間發(fā)生的，并且不更新上下文。


圖1A是示出RTP分組結(jié)構(gòu)的幀格式；圖1B是示出UDP分組結(jié)構(gòu)的幀格式；圖1C是示出IP分組結(jié)構(gòu)的幀格式；圖2A是示出UPDATE_FULLHEADER結(jié)構(gòu)的幀格式；圖2B是示出UPDATE結(jié)構(gòu)的幀格式；圖2C是示出NON-UPDATE結(jié)構(gòu)的幀格式；圖3是說明使用ROHC的分組通信的傳統(tǒng)步驟的時(shí)序圖；圖4是說明使用ROHC的分組通信的傳統(tǒng)步驟的時(shí)序圖；圖5是說明當(dāng)上下文被錯(cuò)誤更新時(shí)采用的步驟的例子的時(shí)序圖；圖6是示出根據(jù)本發(fā)明第一實(shí)施例的分組接收裝置的結(jié)構(gòu)的方框圖；圖7是示出根據(jù)本發(fā)明第一實(shí)施例的分組發(fā)送裝置的結(jié)構(gòu)的方框圖；圖8是示出根據(jù)本發(fā)明第一實(shí)施例的分組發(fā)送裝置中的發(fā)送分組發(fā)生器的結(jié)構(gòu)的方框圖；圖9是說明在根據(jù)本發(fā)明第一實(shí)施例的分組發(fā)送裝置和根據(jù)本發(fā)明第一實(shí)施例的分組接收裝置之間執(zhí)行的分組傳輸?shù)陌l(fā)送/接收步驟的時(shí)序圖；圖10是示出根據(jù)本發(fā)明第二實(shí)施例的分組接收裝置的結(jié)構(gòu)的方框圖；圖11是示出根據(jù)本發(fā)明第二實(shí)施例的分組發(fā)送裝置的發(fā)送分組產(chǎn)生器的結(jié)構(gòu)的方框圖；和圖12是說明在根據(jù)本發(fā)明第二實(shí)施例的分組發(fā)送裝置和根據(jù)本發(fā)明第二實(shí)施例的分組接收裝置之間執(zhí)行的分組傳輸?shù)陌l(fā)送/接收步驟的時(shí)序圖；具體實(shí)施方式
現(xiàn)在參照附圖詳細(xì)說明本發(fā)明的實(shí)施例。
在此使用本實(shí)施例說明其中當(dāng)連續(xù)檢測到錯(cuò)誤時(shí)，分組接收裝置(即首標(biāo)解壓縮端)請求上下文更新和分組發(fā)送裝置(即首標(biāo)壓縮端)響應(yīng)該更新請求發(fā)送UPDATE_FULLHEADER的情況。
圖6是示出根據(jù)本發(fā)明第一實(shí)施例的分組接收裝置的結(jié)構(gòu)的方框圖，而圖7是示出根據(jù)本發(fā)明第一實(shí)施例的分組發(fā)送裝置的結(jié)構(gòu)的方框圖。在此將說明其中通過無線信道傳輸分組的情況。
參照圖6示出的分組接收裝置，接收機(jī)102對通過天線101接收的分組執(zhí)行無線處理(包括下變頻和模/數(shù)轉(zhuǎn)換)和解調(diào)處理，并且隨后將所接收的分組輸出到首標(biāo)解壓縮器103。
首標(biāo)解壓縮器103參照在緩沖器106中保留的上下文對接收分組的首標(biāo)解壓縮，并且將首標(biāo)-解壓縮的分組輸出到CRC部分104。而且，首標(biāo)解壓縮器103向上下文更新器105報(bào)告所接收的分組的首標(biāo)類型。即，首標(biāo)解壓縮器103向上下文更新器105報(bào)告接收分組的首標(biāo)是UPDATE_FULLHEADER、UPDATE和NON_UPDATE中的哪一個(gè)。
CRC部分104具有從首標(biāo)解壓縮器103輸出的分組首標(biāo)的CRC，并且將循環(huán)冗余碼校驗(yàn)(CRC)后的分組輸出作為接收分組。而且，當(dāng)在首標(biāo)中檢測到錯(cuò)誤時(shí)，CRC部分104通過NG信號的方式向更新請求信號產(chǎn)生器107報(bào)告，而當(dāng)未檢測到錯(cuò)誤時(shí)，通過OK信號向更新請求信號產(chǎn)生器107報(bào)告。而且，當(dāng)在首標(biāo)中未檢測到錯(cuò)誤時(shí)，CRC部分104將由首標(biāo)解壓縮器103輸出的分組輸出到上下文更新器105。
根據(jù)由CRC部分104輸出的分組首標(biāo)的類型，上下文更新器105更新在緩沖器106中保留的上下文。即，當(dāng)由首標(biāo)解壓縮器103報(bào)告的類型是UPDATE_FULLHEADER或UPDATE時(shí)，上下文更新器105使用由CRC部分104輸出的分組首標(biāo)字段來更新上下文，而當(dāng)由首標(biāo)解壓縮器103報(bào)告的類型是NON_UPDATE時(shí)不更新上下文。
更新請求信號產(chǎn)生器107當(dāng)NG信號由CRC部分104連續(xù)輸出預(yù)定次數(shù)時(shí)產(chǎn)生更新請求信號，并且將產(chǎn)生的更新請求信號輸出到更新請求信號發(fā)射機(jī)108。具體來說，更新請求信號產(chǎn)生器107具有對檢測到的錯(cuò)誤次數(shù)進(jìn)行計(jì)數(shù)的計(jì)數(shù)器，并且每當(dāng)CRC部分104輸出一個(gè)NG信號時(shí)將計(jì)數(shù)器加1，而當(dāng)CRC部分104輸出一個(gè)OK信號或每當(dāng)計(jì)數(shù)器的值達(dá)到預(yù)定次數(shù)時(shí)重置計(jì)數(shù)器。隨后，當(dāng)計(jì)數(shù)器的值達(dá)到預(yù)定次數(shù)時(shí)，更新請求信號產(chǎn)生器107產(chǎn)生更新請求信號。
這里的更新請求信號指的是分組接收裝置借此向分組發(fā)送裝置請求上下文更新的信號。即所述更新請求信號是指分組接收裝置借此請求分組發(fā)送裝置發(fā)送UPDATE_FULLHEADER的信號。
更新請求信號發(fā)射機(jī)108對更新請求信號執(zhí)行調(diào)制處理和無線處理(包括D/A轉(zhuǎn)換和上變頻)并隨后通過天線101將更新請求信號發(fā)送到分組發(fā)送裝置。
同時(shí)，參照圖7所示的分組發(fā)送裝置，RTP分組產(chǎn)生器201把發(fā)送數(shù)據(jù)分割成預(yù)定的發(fā)送單元并隨后對分割的數(shù)據(jù)添加SN和TS，這樣就產(chǎn)生了RPT分組。隨后，RPT分組產(chǎn)生器201將RPT分組輸出到UDP分組產(chǎn)生器202。
UDP分組產(chǎn)生器202通過向RPT分組添加接收端的端口號產(chǎn)生UDP分組，并且將這個(gè)UDP分組輸出到IP分組產(chǎn)生器203。
IP分組產(chǎn)生器203向UDP分組添加因特網(wǎng)上的接收端的地址(IP地址)而產(chǎn)生IP分組，并且將所述IP分組輸出到CRC比特添加器204。
CRC比特添加器204向IP分組添加CRC比特，并且將所述分組輸出到發(fā)送分組產(chǎn)生器205。
發(fā)送分組產(chǎn)生器205對首標(biāo)進(jìn)行壓縮。隨后，發(fā)送分組產(chǎn)生器205將添加了壓縮的首標(biāo)的分組輸出到發(fā)射機(jī)206作為發(fā)送分組。后面將說明發(fā)送分組產(chǎn)生器205的配置。
發(fā)射機(jī)206對發(fā)送分組執(zhí)行調(diào)制處理和無線處理(包括D/A轉(zhuǎn)換和上變頻)并隨后通過天線207將發(fā)送分組發(fā)送到分組接收裝置。
更新請求信號接收機(jī)208對通過天線207接收的更新請求信號進(jìn)行無線處理(包括下變頻和模/數(shù)轉(zhuǎn)換)和解調(diào)處理，并且隨后將所述更新請求信號輸出到發(fā)送分組產(chǎn)生器205。
然后，將說明發(fā)送分組產(chǎn)生器205的結(jié)構(gòu)。圖8是示出根據(jù)本發(fā)明第一實(shí)施例的分組發(fā)送裝置中的發(fā)送分組發(fā)生器的配置的方框圖。
參照圖8中所示的發(fā)送分組產(chǎn)生器205，從CRC比特添加器204向壓縮方法選擇器301和首標(biāo)壓縮器303輸入已添加首標(biāo)和CRC比特的分組。
壓縮方法選擇器301選擇首標(biāo)壓縮方法，并向首標(biāo)壓縮器303報(bào)告所選的壓縮方法。也就是說，壓縮方法選擇器301從三種類型的首標(biāo)，即UPDATE_FULLHEADER、UPDATE和NON_UPDATE中選擇一個(gè)首標(biāo)，并向首標(biāo)壓縮器303報(bào)告所選的首標(biāo)類型。
當(dāng)從更新請求信號接收機(jī)208向壓縮方法選擇器301輸出一個(gè)更新請求信號時(shí)，壓縮方法選擇器301選擇UPDATE_FULLHEADER。另一方面，當(dāng)更新請求信號接收機(jī)208未向壓縮方法選擇器301輸出更新請求信號時(shí)，壓縮方法選擇器301如下所述從UPDATE_FULLHEADER、UPDATE和NON_UPDATE中選擇一個(gè)首標(biāo)。
即對于在通信開始后首先發(fā)送的分組來說，壓縮方法選擇器301選擇UPDATE_FULLHEADER。隨后，壓縮方法選擇器301定期選擇UPDATE_FULLHEADER。例如，壓縮方法選擇器301每一百次選擇一次UPDATE_FULLHEADER。
壓縮方法選擇器301比較首標(biāo)的SN和在緩沖器302中保留的上下文的SN，如果在SN中發(fā)生了進(jìn)位則選擇UPDATE，而如果在SN中未發(fā)生進(jìn)位則選擇NON_UPDATE。
而且，無論更新請求信號產(chǎn)生器208是否輸出更新請求信號，壓縮方法選擇器301在選擇UPDATE_FULLHEADER或UPDATE時(shí)，使用從CRC比特添加器204輸出的分組首標(biāo)更新在緩沖器302中保留的上下文，而當(dāng)選擇了NON_UPDATE時(shí)則不更新上下文。
緩沖器302是用于保留上下文的緩沖器。如上所述，在緩沖器302中保留的上下文不時(shí)地由壓縮方法選擇器301更新。
根據(jù)在壓縮方法選擇器301中所選首標(biāo)的類型，首標(biāo)壓縮器303壓縮從CRC比特添加器204輸出的首標(biāo)并將結(jié)果輸出到發(fā)射機(jī)206，在此，首標(biāo)壓縮器參照在緩沖器302中保留的上下文，并且所述首標(biāo)壓縮器303基于與該上下文的區(qū)別來壓縮首標(biāo)。
然后，將參照時(shí)序圖說明在上述結(jié)構(gòu)的分組發(fā)送裝置和上述結(jié)構(gòu)的分組接收裝置之間執(zhí)行的分組傳輸?shù)陌l(fā)送/接收步驟。圖9是說明在根據(jù)本發(fā)明第一實(shí)施例的分組發(fā)送裝置和根據(jù)本發(fā)明第一實(shí)施例的分組接收裝置之間執(zhí)行的分組傳輸?shù)陌l(fā)送/接收步驟的時(shí)序圖。順便提及，在圖9中，發(fā)送端是指上述結(jié)構(gòu)的分組發(fā)送裝置，而接收端是指上述結(jié)構(gòu)的分組接收裝置。
如圖9所示，現(xiàn)在假定在發(fā)送SN＝4的UPDATE期間發(fā)生了錯(cuò)誤并且分組接收裝置未檢測到該錯(cuò)誤。即，假定在分組接收裝置中，上下文被使用錯(cuò)誤的首標(biāo)更新，則上下文變成了錯(cuò)誤的上下文，并且SN＝5的分組首標(biāo)的CRC結(jié)果、SN＝6的分組首標(biāo)的CRC結(jié)果和SN＝7的分組首標(biāo)的CRC結(jié)果都將是NG。
在圖6所示的分組接收裝置中，連續(xù)從CRC部分104輸出SN＝5的分組首標(biāo)的NG信號和SN＝6的分組首標(biāo)的NG信號，并且更新請求信號產(chǎn)生器107的計(jì)數(shù)變成“2”。
現(xiàn)在，假定在更新請求信號產(chǎn)生器107中設(shè)置的預(yù)定次數(shù)是“2”，因此，更新請求信號產(chǎn)生器107當(dāng)計(jì)數(shù)器的值變成“2”時(shí)產(chǎn)生一個(gè)更新請求信號。通過這種方式，當(dāng)連續(xù)檢測到錯(cuò)誤時(shí)，即當(dāng)錯(cuò)誤發(fā)生的頻率為高時(shí)，所述分組接收裝置能夠發(fā)送一個(gè)更新請求信號。順便提及，如上所述，當(dāng)產(chǎn)生請求更新信號時(shí)，包括在更新請求信號產(chǎn)生器107中的計(jì)數(shù)器被重置。
當(dāng)接收到更新請求信號時(shí)，所述分組發(fā)送裝置使得UPDATE_FULLHEADER信號成為在接收到更新請求信號后首先發(fā)送的分組。所以，在圖9所示的例子中，SN＝8的分組變成UPDATE_FULLHEADER。隨后，在分組接收裝置，當(dāng)接收到SN＝8的分組時(shí)，上下文被正確地更新。
這樣，根據(jù)本實(shí)施例，當(dāng)連續(xù)檢測到錯(cuò)誤時(shí)，分組接收裝置請求上下文更新，而分組發(fā)送裝置響應(yīng)該更新請求發(fā)送UPDATE_FULLHEADER。通過這種方式，只有當(dāng)錯(cuò)誤發(fā)生的頻率為高時(shí)才發(fā)送UPDATE_FULLHEADER，所以可能在不降低首標(biāo)壓縮效率和分組發(fā)送效率的情況下縮短在分組接收裝置中的數(shù)據(jù)丟失周期。
在此將使用本實(shí)施例說明當(dāng)連續(xù)檢測到錯(cuò)誤時(shí)，分組接收裝置(即首標(biāo)解壓縮端)總是請求上下文更新，和當(dāng)在預(yù)定時(shí)間內(nèi)接收到多個(gè)更新請求時(shí)，分組發(fā)送裝置(即首標(biāo)壓縮端)發(fā)送UPDATE_FULLHEADER的情況。
圖10是示出根據(jù)本發(fā)明第二實(shí)施例的分組接收裝置的結(jié)構(gòu)的方框圖。在圖10中，與圖6相同的部件被分配相同的附圖標(biāo)號而且不作詳細(xì)說明。
而且，根據(jù)本發(fā)明第二實(shí)施例的分組發(fā)送裝置的結(jié)構(gòu)和第一實(shí)施例的區(qū)別僅在于發(fā)送分組產(chǎn)生器205的內(nèi)部結(jié)構(gòu)。因此，在這里只單獨(dú)說明發(fā)送分組產(chǎn)生器205。圖11是示出根據(jù)本發(fā)明第二實(shí)施例的分組發(fā)送裝置的發(fā)送分組產(chǎn)生器的結(jié)構(gòu)的方框圖。在圖11中，與圖8相同的部件被分配相同的附圖標(biāo)號而且不作詳細(xì)說明。
參照圖10中所示的分組接收裝置，當(dāng)從CRC部分104輸出NG信號時(shí)更新請求信號產(chǎn)生器401總是產(chǎn)生更新請求信號，并將所產(chǎn)生的更新請求信號輸出到更新請求信號發(fā)射機(jī)108。即，每當(dāng)在首標(biāo)中檢測到錯(cuò)誤時(shí)分組接收裝置發(fā)送更新請求信號。
參照圖11中所示的發(fā)送分組產(chǎn)生器205，更新請求信號計(jì)數(shù)器501包括計(jì)時(shí)器和計(jì)數(shù)器，并且對在預(yù)定時(shí)間內(nèi)接收到的錯(cuò)誤信號的次數(shù)進(jìn)行計(jì)數(shù)。即更新請求信號產(chǎn)生器501對在預(yù)定時(shí)間內(nèi)從更新請求信號接收機(jī)208輸出的更新請求信號的次數(shù)進(jìn)行計(jì)數(shù)。隨后，當(dāng)在預(yù)定時(shí)間內(nèi)接收的更新請求信號的次數(shù)達(dá)到預(yù)定數(shù)量時(shí)，更新請求信號產(chǎn)生器501指示壓縮方法選擇器502選擇UPDATE_FULLHEADER。
遵循更新請求信號產(chǎn)生器501的指示，壓縮方法選擇器502選擇UPDATE_FULLHEADER。
然后，將參照時(shí)序圖說明在上述結(jié)構(gòu)的分組發(fā)送裝置和上述結(jié)構(gòu)分組接收裝置之間執(zhí)行的分組發(fā)送的發(fā)送/接收步驟。圖12是說明在根據(jù)本發(fā)明第二實(shí)施例的分組發(fā)送裝置和根據(jù)本發(fā)明第二實(shí)施例的分組接收裝置之間執(zhí)行的分組傳輸?shù)陌l(fā)送/接收步驟的時(shí)序圖。順便提及，在圖12中，發(fā)送端是指上述結(jié)構(gòu)的分組發(fā)送裝置，而接收端是指上述結(jié)構(gòu)的分組接收裝置。
現(xiàn)在假定，如圖12所示，和圖9一樣，在發(fā)送SN＝4的UPDATE期間發(fā)生了錯(cuò)誤并且分組接收裝置未檢測到該錯(cuò)誤。即，假定在分組接收裝置中，上下文被使用錯(cuò)誤的首標(biāo)更新，則上下文變成了錯(cuò)誤的上下文，并且SN＝5的分組首標(biāo)的CRC結(jié)果、SN＝6的分組首標(biāo)的CRC結(jié)果和SN＝7的分組首標(biāo)的CRC結(jié)果都變成NG。因此，對于SN＝5、SN＝6和SN＝7的每一分組都發(fā)送一個(gè)更新請求信號。
在圖11所示的發(fā)送分組產(chǎn)生器205的更新請求信號計(jì)數(shù)器501中，當(dāng)從更新請求信號接收機(jī)208中輸出用于SN＝5的分組的更新請求信號時(shí)，計(jì)數(shù)器變成“1”并且計(jì)時(shí)器開始計(jì)時(shí)預(yù)定的時(shí)間。而且，在更新請求信號計(jì)數(shù)器501中，當(dāng)從更新請求接收機(jī)208輸出用于SN＝6的分組的更新請求信號時(shí)，計(jì)數(shù)器加“1”變成“2”。
現(xiàn)在，假定在更新請求信號計(jì)數(shù)器501中設(shè)置的預(yù)定次數(shù)是“2”，從而當(dāng)在預(yù)定時(shí)間內(nèi)檢測到2個(gè)錯(cuò)誤時(shí)，判定錯(cuò)誤發(fā)生的頻率為高。隨后，當(dāng)計(jì)數(shù)器的值在預(yù)定時(shí)間內(nèi)變成“2”時(shí)，更新請求信號計(jì)數(shù)器501指示壓縮方法選擇器502選擇UPDATE_FULLHEADER。壓縮方法選擇器502使得在更新請求信號計(jì)數(shù)器501發(fā)出指示后從CRC比特添加器204輸出的第一個(gè)分組變成UPDATE_FULLHEADER。在圖12所示的例子中，SN＝8的分組變成UPDATE_FULLHEADER。這樣，只有當(dāng)錯(cuò)誤發(fā)生的頻率為高時(shí)才發(fā)送UPDATE_FULLHEADER。順便提及，當(dāng)超過預(yù)定時(shí)間或當(dāng)更新請求信號計(jì)數(shù)器501指示壓縮方法選擇器 02選擇UPDATE_FULLHEADER時(shí)，更新請求信號計(jì)數(shù)器501中包括的計(jì)數(shù)器被重置。
隨后，在分組接收裝置中，當(dāng)接收到SN＝9的分組時(shí)，上下文被正確更新。
順便提及，在本實(shí)施例中，可以使用預(yù)先測量的RTT(Round Trip Time，雙程時(shí)間)作為在更新請求信號計(jì)數(shù)器501的計(jì)時(shí)器中設(shè)置的預(yù)定時(shí)間。IETF的RFC 1889中規(guī)定了RTT測量的詳細(xì)方法。
這樣，根據(jù)本實(shí)施例，當(dāng)檢測到錯(cuò)誤時(shí)，分組接收裝置總是請求上下文更新，而當(dāng)在預(yù)定的時(shí)間內(nèi)接收到多個(gè)更新的請求時(shí)，分組發(fā)送裝置發(fā)送UPDATE_FULLHEADER。通過這種方式，只有當(dāng)錯(cuò)誤發(fā)生的頻率為高時(shí)才發(fā)送UPDATE_FULLHEADER，所以可以在不降低首標(biāo)壓縮效率和分組發(fā)送效率的情況下縮短在分組接收裝置中的數(shù)據(jù)丟失的時(shí)間周期。
而且，根據(jù)本實(shí)施例，由于分組接收裝置不對檢測到錯(cuò)誤的次數(shù)進(jìn)行計(jì)數(shù)，和第一實(shí)施例相比，分組接收裝置的配置能夠被進(jìn)一步簡化。因此，當(dāng)分組接收裝置被安裝在移動通信系統(tǒng)中使用的通信終端裝置中時(shí)，與第一實(shí)施例相比，通信終端裝置的設(shè)備尺寸可以被制造得更小。
雖然上述實(shí)施例是關(guān)于在無線通信系統(tǒng)中使用的分組發(fā)送裝置和分組接收裝置的，本發(fā)明并不局限于此，而且可能在有線通信系統(tǒng)中使用上述實(shí)施例的分組發(fā)送裝置和分組接收裝置。
而且，雖然是參照通過分組發(fā)送裝置和分組接收裝置的方式執(zhí)行分組發(fā)送和分組接收來說明上述實(shí)施例，但本發(fā)明并不局限于此，并且可以通過軟件方式來執(zhí)行這些分組發(fā)送和分組接收。例如，可以預(yù)先在ROM(只讀存儲器)中存儲執(zhí)行上述分組發(fā)送和分組接收的程序并使用CPU(中央處理單元)運(yùn)行該程序。同樣地，也可以在計(jì)算機(jī)可讀存儲介質(zhì)中存儲執(zhí)行上述分組發(fā)送和接收的程序，在計(jì)算機(jī)的RAM(隨機(jī)存取存儲器)中紀(jì)錄存儲在存儲介質(zhì)中的程序并使用該程序來操作所述計(jì)算機(jī)。在這些例子中，可以實(shí)現(xiàn)和上述實(shí)施例相同的功能和優(yōu)點(diǎn)。
還可以在服務(wù)器中存儲執(zhí)行上述分組發(fā)送和上述分組接收的程序，以根據(jù)來自客戶的請求將存儲在服務(wù)器的程序發(fā)送到客戶，和在客戶端執(zhí)行所述程序。在這種情況下，可以實(shí)現(xiàn)和上述實(shí)施例相同的功能和優(yōu)點(diǎn)。
還可以在執(zhí)行圖像分發(fā)(image distribution)的圖像分發(fā)裝置中安裝根據(jù)上述實(shí)施例的分組發(fā)送裝置。同樣地，可以在用于移動通信系統(tǒng)的通信終端設(shè)備中安裝根據(jù)上述實(shí)施例的分組接收裝置。在這種情況下，可以實(shí)現(xiàn)和上述實(shí)施例相同的功能和優(yōu)點(diǎn)。
雖然RTP、UDP和IP被結(jié)合使用作為上述實(shí)施例的協(xié)議，但本發(fā)明不局限于此，并且適用于使用其它協(xié)議的分組通信。
如上所述，可以在不降低首標(biāo)壓縮效率和分組發(fā)送效率的情況下縮短在分組接收裝置中的數(shù)據(jù)丟失的時(shí)間周期。
本發(fā)明基于2000年9月12日提交的日本專利申請第2000-277075號，其全部內(nèi)容引用于此作為參考。
權(quán)利要求
1.一種在分組通信系統(tǒng)中使用的分組接收裝置，其中，使用參考信息執(zhí)行首標(biāo)壓縮和解壓縮，所述分組接收裝置包含檢測器，用于檢測在分組的首標(biāo)中是否有錯(cuò)誤；和發(fā)射機(jī)，用于當(dāng)所述檢測器在多個(gè)分組的首標(biāo)中連續(xù)檢測到錯(cuò)誤時(shí)發(fā)送用于參考信息的更新的請求。
2.一種具有分組接收裝置的通信終端裝置，其中，所述分組接收裝置用于分組通信系統(tǒng)，在其中，使用參考信息執(zhí)行首標(biāo)壓縮和解壓縮，并且包括檢測器，用于檢測在分組的首標(biāo)中是否有錯(cuò)誤；和發(fā)射機(jī)，用于當(dāng)所述檢測器在多個(gè)分組的首標(biāo)中連續(xù)檢測到錯(cuò)誤時(shí)發(fā)送用于參考信息的更新的請求。
3.一種在分組通信系統(tǒng)中使用的分組發(fā)送裝置，其中，使用參考信息執(zhí)行首標(biāo)壓縮和解壓縮，所述分組發(fā)送裝置包括接收機(jī)，接收用于參考信息更新的請求，所述請求是由分組接收裝置發(fā)送的；和發(fā)射機(jī)，當(dāng)在預(yù)定時(shí)間內(nèi)接收到多個(gè)請求時(shí)，在分組接收裝置中執(zhí)行首標(biāo)解壓縮后發(fā)送具有用于參考信息更新的首標(biāo)的分組而不管參考信息如何。
4.一種具有分組發(fā)送裝置的圖像分發(fā)裝置，其中，所述分組發(fā)送裝置由于分組通信系統(tǒng)，在其中，使用參考信息執(zhí)行首標(biāo)壓縮和解壓縮，并包括接收機(jī)，接收用于參考信息更新的請求，所述請求是由分組接收裝置發(fā)送的；和發(fā)射機(jī)，當(dāng)在預(yù)定時(shí)間內(nèi)接收到多個(gè)請求時(shí)，在分組接收裝置中執(zhí)行首標(biāo)解壓縮后發(fā)送具有用于參考信息更新的首標(biāo)的分組而不管參考信息如何。
5.一種使計(jì)算機(jī)執(zhí)行下列操作的程序檢測步驟，用于檢測在分組的首標(biāo)中是否存在錯(cuò)誤；和發(fā)送步驟，當(dāng)在多個(gè)分組的首標(biāo)中連續(xù)檢測到錯(cuò)誤時(shí)向通信伙伴發(fā)送用于參考信息更新的請求。
6.一種使計(jì)算機(jī)執(zhí)行下列操作的程序接收步驟，接收在通信伙伴端用于首標(biāo)解壓縮的參考信息的更新的請求；和發(fā)送步驟，用于在預(yù)定時(shí)間內(nèi)接收到多個(gè)請求時(shí)，在通信伙伴端執(zhí)行首標(biāo)解壓縮后發(fā)送具有用于參考信息更新的首標(biāo)的分組而不管參考信息如何。
7.一種在分組通信系統(tǒng)中使用的分組傳輸方法，在其中，使用參考信息執(zhí)行首標(biāo)壓縮和解壓縮，所述方法包括在分組接收端，當(dāng)在多個(gè)接收的分組中連續(xù)檢測到錯(cuò)誤時(shí)向分組發(fā)送端發(fā)送用于參考信息更新的請求；和在分組發(fā)送端，當(dāng)接收到請求時(shí)，在分組接收端執(zhí)行首標(biāo)解壓縮后發(fā)送具有用于參考信息更新的首標(biāo)的分組而不管參考信息如何。
8.一種在分組通信系統(tǒng)中使用的分組傳輸方法，在其中，使用參考信息執(zhí)行首標(biāo)壓縮和解壓縮，所述方法包括在分組接收端，當(dāng)在分組的首標(biāo)中檢測到錯(cuò)誤時(shí)，發(fā)送用于參考信息更新的請求；和在分組發(fā)送端，當(dāng)在預(yù)定時(shí)間內(nèi)接收到多個(gè)請求時(shí)，在分組接收端執(zhí)行首標(biāo)解壓縮后發(fā)送具有用于參考信息更新的首標(biāo)的分組而不管參考信息如何。
全文摘要
當(dāng)從CRC部分(104)連續(xù)輸出NG信號預(yù)定次數(shù)時(shí)，更新請求信號發(fā)生器(107)產(chǎn)生一個(gè)更新請求信號。更具體地講，更新請求信號發(fā)生器(107)包括對檢測到的錯(cuò)誤的次數(shù)進(jìn)行計(jì)數(shù)的計(jì)數(shù)器，每當(dāng)從CRC部分(104)輸出NG信號時(shí)，將計(jì)數(shù)器加1，并且當(dāng)CRC部分(104)輸出OK信號或每當(dāng)達(dá)到特定計(jì)數(shù)值時(shí)重置計(jì)數(shù)器。隨后，在達(dá)到特定計(jì)數(shù)值時(shí)，更新請求信號發(fā)生器(107)產(chǎn)生一個(gè)更新請求信號。
文檔編號H04L29/06GK1516936SQ0281224
公開日2004年7月28日 申請日期2002年3月7日 優(yōu)先權(quán)日2000年9月12日
發(fā)明者井戶大治, 井村康治, 宮崎秋弘, 畑幸一, 弘, 治 申請人:松下電器產(chǎn)業(yè)株式會社