專利名稱：通信方法及通信終端、數(shù)據(jù)傳送裝置及控制裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信方法及通信終端，數(shù)據(jù)傳送裝置及控制裝置。本發(fā)明例如適合用 于例如以下的通信系統(tǒng)在發(fā)送側(cè)壓縮數(shù)據(jù)(分組)的一部分(報(bào)頭)來進(jìn)行發(fā)送，在接收 側(cè)進(jìn)行被壓縮的報(bào)頭的解壓縮。
背景技術(shù)：
在下述的專利文獻(xiàn)1(日本特開2003-224610號(hào)公報(bào))中，公開了涉及報(bào)頭壓縮分 組傳送系統(tǒng)及報(bào)頭壓縮分組傳送方法的技術(shù)。該技術(shù)的目的如下不進(jìn)行分組傳送途中的報(bào)頭信息的解壓縮/壓縮，在壓縮了 報(bào)頭的狀態(tài)下傳送信息，消除解壓縮/壓縮處理，還提高線路使用效率。因此，在該專利文獻(xiàn)1中，記載了如下的技術(shù)在從移動(dòng)終端對網(wǎng)關(guān)節(jié)點(diǎn)有連接 請求時(shí)，在網(wǎng)關(guān)節(jié)點(diǎn)中，根據(jù)該連接請求將移動(dòng)終端和請求發(fā)送目的地終端的連接路徑信 息關(guān)聯(lián)起來進(jìn)行存儲(chǔ)，并根據(jù)該存儲(chǔ)信息將之后的報(bào)頭壓縮分組傳送到請求發(fā)送目的地終 端。此外，作為與分組通信技術(shù)關(guān)聯(lián)的文獻(xiàn)，有下述的非專利文獻(xiàn)1 7。專利文獻(xiàn)1 日本特開2003-224610號(hào)公報(bào)非專利文獻(xiàn)1 :3GPP TR 23. 882 VI. 10. 0、[online]、平成 19 年 9 月 27 日、[平 成 19 年 10 月 25 日檢索]、^ > 夕一本 7 卜 <URL :http://www. 3gpp. org/ftp/Specs/ html-info/23882. htm>非專利文獻(xiàn)2:3GPP TS 23.401 VL 0. 0、[online]、平成 19 年 6 月 13 日、[平 成 19 年 10 月 25 日檢索]、^ > 夕一才、7 卜 <URL :http://www. 3gpp. org/ftp/Specs/ html-info/23401. htm>非專利文獻(xiàn)3:3GPP TS 36.300 VL 0. 0、[online]、平成 19 年 3 月 19 日、[平 成 19 年 10 月 25 日檢索]、^ > 夕一才、7 卜 <URL :http://www. 3gpp. org/ftp/Specs/ html-info/36300. htm>非專利文獻(xiàn)4:3GPP TS 23.228 V8. 1. 0、[online]、平成 19 年 6 月 19 日、[平 成 19 年 10 月 25 日檢索]、^ > 夕一才、7 卜 <URL :http://www. 3gpp. org/ftp/Specs/ html-info/23228. htm>非專利文獻(xiàn)5:3GPP TS 29.060 V7. 5. 1、[online]、平成 19 年 3 月 23 日、[平 成 19 年 10 月 25 日檢索]、^ > 夕一才、7 卜 <URL :http://www. 3gpp. org/ftp/Specs/ html-info/29060. htm>非專利文獻(xiàn)6:3GPP TS 25.323 V7. 4. 0、[online]、平成 19 年 4 月 6 日、[平 成 19 年 10 月 25 日檢索]、^ > 夕一才、7 卜 <URL :http://www. 3gpp. org/ftp/Specs/ html-info/25323. htm>非專利文獻(xiàn)7 =IETF RFC 3095、[online]、平成13年7月、[平成19年10月25日 檢索]、4 > 夕一才、7 卜 <URL :http://www. itef. org/rfc/rfc3095. txt>

發(fā)明內(nèi)容
本發(fā)明的一個(gè)目的在于在網(wǎng)絡(luò)側(cè)不對報(bào)頭壓縮的數(shù)據(jù)進(jìn)行解壓縮而削減送出 (傳送)到適當(dāng)?shù)哪康牡厮璧奶幚砹?。此外，不限于所述目的，作為本發(fā)明的另一目的，能夠定得到起到通過用于實(shí)施后 述的發(fā)明的優(yōu)選方式所示的各結(jié)構(gòu)引導(dǎo)的、通過現(xiàn)有技術(shù)不能得到的作用效果。為了達(dá)到上述目的，在本說明書中，公開如下所示的“通信方法及通信終端，數(shù)據(jù)傳送裝置及控制裝置”。(1) S卩，此處公開的通信方法為第1通信終端和第2通信終端經(jīng)由網(wǎng)絡(luò)進(jìn)行通信的 通信系統(tǒng)中的通信方法，其中，所述第1通信終端向?qū)Πl(fā)給所述第2通信終端的數(shù)據(jù)報(bào)頭進(jìn) 行壓縮得到的壓縮數(shù)據(jù)附加識(shí)別是否需要報(bào)頭解壓縮處理和通往所述第2通信終端的傳 送路徑所使用的信息并發(fā)送到所述網(wǎng)絡(luò)，作為構(gòu)成所述網(wǎng)絡(luò)的數(shù)據(jù)傳送裝置的、從所述第1 通信終端接收到所述壓縮數(shù)據(jù)的裝置根據(jù)所述信息識(shí)別是否需要所述壓縮數(shù)據(jù)的報(bào)頭解 壓縮處理和所述傳送路徑，對不需要所述報(bào)頭解壓縮處理的壓縮數(shù)據(jù)不進(jìn)行報(bào)頭解壓縮處 理而發(fā)送到所述識(shí)別出的傳送路徑。(2)此處，也可以是所述信息由第1信息要素和第2信息要素的組合構(gòu)成，所述第 1信息要素為識(shí)別所述數(shù)據(jù)的報(bào)頭壓縮所使用的上下文的上下文識(shí)別信息，并根據(jù)是否需 要所述報(bào)頭解壓縮來預(yù)先確定，所述第2信息要素為對所述數(shù)據(jù)傳送裝置預(yù)先確定的所述 傳送路徑的識(shí)別信息。(3)此外，也可以是所述第1通信終端在發(fā)送所述壓縮數(shù)據(jù)時(shí)，將所述第1信息要 素和所述第2信息要素作為在所述報(bào)頭解壓縮處理所屬的層中處理的信息附加到所述壓 縮數(shù)據(jù)中，所述數(shù)據(jù)傳送裝置在將所述壓縮數(shù)據(jù)發(fā)送到所述傳送路徑時(shí)，將所述第2信息 要素作為在所述解壓縮處理所屬的層的下層中處理的信息附加到所述壓縮數(shù)據(jù)中。(4)此外，也可以是從對所述第1通信終端和所述第2通信終端之間的通信路的設(shè)定進(jìn)行控制的控制裝置通知所述信息。(5)此外，也可以是所述控制裝置在所述通知中，使用在設(shè)定所述通信路時(shí)收發(fā)的消息。(6)此外，此處公開的通信終端為經(jīng)由網(wǎng)絡(luò)與另外的通信終端進(jìn)行通信的通信終 端，該通信終端具有附加單元，其向?qū)Πl(fā)給所述另外的通信終端的數(shù)據(jù)報(bào)頭進(jìn)行壓縮得到 的壓縮數(shù)據(jù)，附加識(shí)別是否需要報(bào)頭解壓縮處理和通往所述另外的通信終端的傳送路徑所 使用的信息；以及發(fā)送單元，其將附加了所述信息的壓縮數(shù)據(jù)發(fā)送到所述網(wǎng)絡(luò)。(7)此外，此處公開的數(shù)據(jù)傳送裝置為構(gòu)成第1通信終端和第2通信終端經(jīng)由網(wǎng)絡(luò) 進(jìn)行通信的通信系統(tǒng)中的所述網(wǎng)絡(luò)的數(shù)據(jù)傳送裝置，該數(shù)據(jù)傳送裝置具有接收單元，其從 所述第1通信終端接收壓縮數(shù)據(jù)，該壓縮數(shù)據(jù)在所述第1通信終端中進(jìn)行報(bào)頭壓縮，并且附 加了識(shí)別是否需要報(bào)頭解壓縮處理和通往所述第2通信終端的傳送路徑所使用的信息；識(shí) 別單元，其根據(jù)所述信息，識(shí)別是否需要所述壓縮數(shù)據(jù)的報(bào)頭解壓縮處理和所述傳送路徑； 以及發(fā)送單元，其對由所述識(shí)別單元識(shí)別為不需要所述報(bào)頭解壓縮處理的壓縮數(shù)據(jù)不進(jìn)行 報(bào)頭解壓縮處理而發(fā)送到所述識(shí)別出的傳送路徑。(8)此外，此處公開的控制裝置為對第1通信終端和第2通信終端經(jīng)由網(wǎng)絡(luò)進(jìn)行通信的通信系統(tǒng)中的所述通信進(jìn)行控制的控制裝置，該控制裝置具有生成單元，其生成附加 到所述第1通信終端進(jìn)行報(bào)頭壓縮并發(fā)送給所述第2通信終端的、識(shí)別是否需要報(bào)頭解壓 縮處理和通往所述第2通信終端的傳送路徑所使用的信息；以及通知單元，其在設(shè)定所述 通信的通信路的過程中，將所述生成單元所生成的信息通知給所述第1通信終端。根據(jù)所述公開技術(shù)，能夠在網(wǎng)絡(luò)側(cè)對在第1通信終端中進(jìn)行了報(bào)頭壓縮的數(shù)據(jù)不 進(jìn)行解壓縮而削減傳送到適當(dāng)?shù)哪康牡?第2通信終端)所需的處理量。


圖1是示出與本發(fā)明的一個(gè)實(shí)施方式關(guān)聯(lián)的SAE (SystemsArchitecture Evolution 系統(tǒng)架構(gòu)演進(jìn))中的系統(tǒng)結(jié)構(gòu)例的圖。圖2是對SAE承載結(jié)構(gòu)進(jìn)行說明的圖。圖3是示出承載建立處理的信令過程的一例的圖。圖4是對與本發(fā)明的一個(gè)實(shí)施方式關(guān)聯(lián)的ROHC (RObust HeaderCompression 魯 棒性報(bào)頭壓縮)的報(bào)頭壓縮的一例進(jìn)行說明的圖。圖5是對ROHC的概念進(jìn)行說明的圖。圖6是對本發(fā)明的一個(gè)實(shí)施方式的分組傳送進(jìn)行說明的圖。圖7是示出在本實(shí)施方式中使用的分組格式例的圖。圖8是示出本實(shí)施方式的無線通信系統(tǒng)的通信過程的一例的圖。圖9是示出本實(shí)施方式的用戶終端(UE)的結(jié)構(gòu)(功能)的框圖。圖10是對圖9所示的UE (呼出側(cè))的連接開始時(shí)的動(dòng)作進(jìn)行說明的流程圖。圖11是對圖9所示的UE (呼入側(cè))的連接開始時(shí)的動(dòng)作進(jìn)行說明的流程圖。圖12是對圖9所示的UE中的報(bào)頭壓縮動(dòng)作進(jìn)行說明的流程圖。圖13是示出本實(shí)施方式的無線基站(eNB)的結(jié)構(gòu)(功能)的框圖。圖14是對圖13所示的eNB的連接開始時(shí)的動(dòng)作進(jìn)行說明的流程圖。圖15是對圖13所示的eNB的上行鏈路(UL)分組接收時(shí)的動(dòng)作進(jìn)行說明的流程 圖。圖16是對圖13所示的eNB的下行鏈路(DL)分組接收時(shí)的動(dòng)作進(jìn)行說明的流程圖。圖17是示出本實(shí)施方式的網(wǎng)關(guān)(GW)的結(jié)構(gòu)(功能)的框圖。圖18是對圖17所示的GW連接開始時(shí)的動(dòng)作進(jìn)行說明的流程圖。圖19是對圖17所示的GW從外部(因特網(wǎng)等)接收到分組時(shí)的動(dòng)作進(jìn)行說明的 流程圖。圖20是對圖17所示的GW接收到發(fā)給外部(因特網(wǎng)等)的分組時(shí)的動(dòng)作進(jìn)行說 明的流程圖。圖21是對圖17所示的GW接收到隧道分組時(shí)的動(dòng)作進(jìn)行說明的流程圖。圖22是示出本實(shí)施方式的IMS(IP Multimedia Subsytem =IP多媒體子系統(tǒng))服務(wù)器的結(jié)構(gòu)(功能)的框圖。圖23是對圖22所示的IMS服務(wù)器的連接開始時(shí)的動(dòng)作進(jìn)行說明的流程圖。標(biāo)號(hào)說明
10、10-1、10-2 用戶終端(UE) ；11 承載管理部；12 :IMS處理部；13 上層處理部； 14 =ROHC處理部；141 過濾數(shù)據(jù)(列表)；142 上下文數(shù)據(jù)；15 下層處理部；16 應(yīng)用部； 20,20-1,20-2 無線基站(eNB) ；21 承載管理部；22 信號(hào)處理部；23 上層處理部；24 ROHC處理部；241 過濾數(shù)據(jù)(列表)；242.242a.242b 上下文數(shù)據(jù)；25 下層處理部；251 TEID-RBID對應(yīng)表；30 =Gff ；31 承載管理部；32 信號(hào)處理部；33 上層處理部；331 過濾數(shù) 據(jù)(列表)；332 路由表；34 下層處理部；30-1 =MME ；30-2 =S-Gff ；30-3 =PDN-Gff ；40 =PCRF ； 50 :CSCF[應(yīng)用服務(wù)器(IMS服務(wù)器)]；51 :IMS處理部；511、511a、511b :CID管理表；52 下 層處理部。
具體實(shí)施方式
以下，參照

本發(fā)明的實(shí)施方式。但是，以下說明的實(shí)施方式只不過一個(gè)例 子，而并不排除以下沒有明確記載的技術(shù)。本發(fā)明不限于以下所示的實(shí)施方式，在不脫離本 發(fā)明的主旨范圍內(nèi)當(dāng)然能夠進(jìn)行各種變形來實(shí)施。[1]與本實(shí)施方式關(guān)聯(lián)的技術(shù)(1. 1) 3GPP SAE/LTE 中的承載結(jié)構(gòu)在3GPP中，研究了能夠容納已有的各種無線接入方式(接入網(wǎng))，能夠進(jìn)行核心網(wǎng) 的完全I(xiàn)P化(All IP)的下一代系統(tǒng)(Release 8)。在所述的非專利文獻(xiàn)1 (3GPP TR 23.882 VI. 10.0)、非專利文獻(xiàn)2 (3GPP TS23.401 VI. 0. 0)中說明了該內(nèi)容。此處所研究的下一代 體系結(jié)構(gòu)被稱作SAE (Systems Architecture Evolution 系統(tǒng)架構(gòu)演進(jìn))。此外，SAE中的 無線技術(shù)被稱作LTE (Long Term Evolution 長期演進(jìn))。在圖1中示出SAE中的系統(tǒng)結(jié)構(gòu)例。如該圖1所示，SAE例如被定義為具有用 戶終端(UE) 10、作為無線基站的 eNodeB(eNB)20、MME(Mobility Management Entity 移 動(dòng)管理實(shí)體)30-1、S-GW(ServingGateway 服務(wù)網(wǎng)關(guān))30_2、PDN-Gff 30-3, PCRF(Policy and ChargingRules Function 策略和計(jì)費(fèi)規(guī)則功能)40 和 CSCF(Call Session ControlFunction 呼叫會(huì)話控制功能)50的系統(tǒng)。UE 10具有無線接口，在eNB 20的服務(wù)區(qū)域內(nèi)通過無線鏈路與該eNB 20連接，經(jīng) 由該eNB 20與其他UE 10和服務(wù)器裝置等進(jìn)行通信。在無線鏈路中，包括從UE 10到eNB 20的方向的上行鏈路(UL)、和其相反方向的下行鏈路(DL)。此外，在UE 10中，包括便攜 電話、PDA或筆記本型PC等。此外，UE 10也可以是通過有線接口與eNB 20連接的通信終端。eNB 20是端接與UE 10之間的無線接口的實(shí)體(節(jié)點(diǎn))，進(jìn)行來自UE 10的無 線分組的接收、發(fā)給UE 10的無線分組的發(fā)送。此外，eNB 20與綜合了 UTRAN(Universal Terrestrial Radio Access Network 通用陸地?zé)o線接入網(wǎng))中的無線基站(BS)和 RNC(Radio Network Controller 無線網(wǎng)絡(luò)控制器)的功能的一部分的實(shí)體相當(dāng)。MME 30-1對UE 10的位置(移動(dòng)性)進(jìn)行管理，是進(jìn)行承載管理、 NAS (Non-Access-Stratum 非接入層)信令等的實(shí)體(邏輯節(jié)點(diǎn))。S-Gff 30-2是成為對下一代體系結(jié)構(gòu)的無線接入網(wǎng)絡(luò)的E-UTRAN (Evolved Universal Terrestrial Radio Access Network 演進(jìn)的通用陸地?zé)o線接入網(wǎng))的接口的 實(shí)體,在與E-UTRAN內(nèi)的eNB 20之間收發(fā)用戶分組。此外，S-GW 30-2與GPRS (GeneralPacket Radio Service 通用分組無線服務(wù))中的稱作SGSN(Serving GPRS Support Node 服務(wù)GPRS支持節(jié)點(diǎn))的實(shí)體大致相當(dāng)。關(guān)于E-UTRAN，在所述的非專利文獻(xiàn)3(3GPP TS 36. 300 VI. 0. 0)中有記載。 PDN-Gff 30-3 是端接到 PDN(Packet Data Network 分組數(shù)據(jù)網(wǎng)絡(luò))的接口的 網(wǎng)關(guān)(gateway)節(jié)點(diǎn)。PDN可以是因特網(wǎng)、運(yùn)營商內(nèi)的網(wǎng)絡(luò)、私有分組數(shù)據(jù)網(wǎng)絡(luò)、運(yùn)營商 間的分組數(shù)據(jù)網(wǎng)絡(luò)(IMS服務(wù)提供用等)的任意一個(gè)。此外，PDN-GW 30-3與GPRS中的 稱作GGSN (GatewayGPRS Support Node 網(wǎng)關(guān)GPRS支持節(jié)點(diǎn))的實(shí)體大致相當(dāng)。關(guān)于 IMS(IP Multimedia Subsytem IP多媒體子系統(tǒng))，在所述的非專利文獻(xiàn)4 (3GPP TS 23.228 V8. 1.0)中有定義。
PCRF 40為根據(jù)來自CSCF 50的請求，管理并控制承載的QoS (Quality of Service 服務(wù)質(zhì)量)等的各種策略和計(jì)費(fèi)的實(shí)體(邏輯節(jié)點(diǎn))。CSCF 50為管理并控制IMS中的會(huì)話(承載)的實(shí)體(邏輯節(jié)點(diǎn))。其中，CSCF 50不直接控制PDN-GW 30-3，而經(jīng)由所述PCRF 40進(jìn)行承載的設(shè)定(建立)。CSCF 50實(shí)現(xiàn) 為例如構(gòu)成PDN的IMS服務(wù)器等的應(yīng)用服務(wù)器的一個(gè)功能。此外，如圖1中所示，UE 10和eNB 20之間的接口名稱被表記為“ LTE-Uu ”，eNB 20 禾口 MME 30-1之間的接口名稱被表記為“Sl-MME”，eNB 20與S-GW 30_2之間的接口名稱被 表記為“S1-U”。此外，S-Gff30-2 和 PDN-GW 30-3 之間的接口 名稱被表記為 “S5，，，PDN-Gff 30-3 禾口 PCRF 40之間的接口名稱被表記為“ S7 ”，從PDN-GW 30-3到PDN (CSCF 50)的接口名稱被表 記為“SGi”，CSCF50和PCRF 40之間的接口名稱被表記為“Rx+”。在從UE 10到PDN內(nèi)的通信裝置(PDN-GW 30-3)之間的區(qū)間中定義SAE中的承載 (SAE承載)。通信對方將定義了 QoS等的數(shù)據(jù)傳送路徑稱作“承載”。此外，例如如圖2所示，在UE 10和eNB 20之間、eNB 20和S-GW 30-2之間、及 S-Gff 30-2和PDN-GW 30-3之間，分別定義了與各個(gè)接口名稱對應(yīng)的名稱的承載、即無線承 載(Radio bearer)、S1 承載(Si bearer)、S5 承載(S5 bearer) 在這些接口中，使用了各 個(gè)獨(dú)立的協(xié)議的組合。例如，在無線承載上送出的數(shù)據(jù)使用無線協(xié)議上和上位的數(shù)據(jù)傳送協(xié)議的組合來 發(fā)送，該承載用無線承載標(biāo)識(shí)符(RBID)來識(shí)別。在Sl承載中，在數(shù)據(jù)傳送中能夠使用GPRS (General Packet RadioService 通 用分組無線服務(wù))隧道協(xié)議(GTP)。此外，關(guān)于GTP，在所述非專利文獻(xiàn)5(3GPP TS 29.060 V7. 5. 1)中有定義。能夠?qū)⒆R(shí)別用GTP接收的端點(diǎn)的隧道端點(diǎn)標(biāo)識(shí)符(Tunnel Endpoint Identifier =TEID)用作承載標(biāo)識(shí)符。此外，關(guān)于TEID，在非專利文獻(xiàn)5的第6章中有記載。 S5承載也同樣地，能夠用TEID識(shí)別承載。此外，如圖2所示，針對1個(gè)SAE承載逐一使用1個(gè)無線承載、Sl承載、S5承載，在 各節(jié)點(diǎn)(實(shí)體)中1對1對應(yīng)。由此，例如在eNB 20從S-GW 30_2接收分組，并將該分組發(fā)送到無線鏈路的情況 下，參照接收分組的TEID，以該TEID為關(guān)鍵字，根據(jù)圖2所示的對應(yīng)關(guān)系，可知向接收分組 附加哪個(gè)RBID為好。此外，在建立SAE承載中，需要建立各接口中的承載。承載建立能夠從UE 10起動(dòng)，還能夠從網(wǎng)絡(luò)側(cè)的實(shí)體起動(dòng)。在后者的情況下，為了在UE 10之間進(jìn)行通話(VoIP服務(wù))等而需要承載的建立時(shí)，按以下的步驟建立承載。(1)呼出側(cè)的UE 10-1向IMS服務(wù)器(CSCF) 50發(fā)送請求承載的建立的 SIP (Session Initiation Protocol 會(huì)話初始化協(xié)議)消息(INVITE)。在該 INVITE 消息 中，包括確定目的地的UE 10-2的信息(IP地址)。(2) IMS服務(wù)器50根據(jù)所述IP地址向目的地的UE 10-2發(fā)送SIP消息(INVITE)。(3) UE 10-2接收所述SIP (INVITE)消息，當(dāng)了解(響應(yīng))時(shí)，將表示該意思的響應(yīng) 消息(2000K)發(fā)送給IMS服務(wù)器50。(4)在從UE 10-2接收所述了解時(shí)，IMS服務(wù)器50建立UE 10-1和UE 10-2之間 的承載，分別向UE 10-UUE 10-2通知已準(zhǔn)備完畢。此處，例如如圖3所示，從IMS服務(wù)器50，按照PCRF 40,Gff 30 (PDN-GW 30-3,S-Gff 30-2,MME 30-1)、eNB 20-1和20-2,UE 10-1和10-2的順序發(fā)送請求承載建立的消息(步 驟S41 S43、S48 S50)，將對此響應(yīng)消息從UE 10-1和10_2按照eNB 20-1和20_2、Gff 30、IMS服務(wù)器50的順序進(jìn)行發(fā)送(步驟S44 S47、S51 S52)，由此完成UE 10-1和UE 10-2之間的承載建立。在圖3所示的例子中，示出了以下的情況作為請求承載建立的消息，發(fā)送PCC確 定通知(Policy and Charging Control decision propositon 策略和計(jì)費(fèi)控制確定通 知)、專用承載建立請求(Create Dedicated BearerRequest)、無線承載設(shè)置請求(Radio Bearer Setup Request)，作為對各個(gè)消息的響應(yīng)，發(fā)送無線承載設(shè)置響應(yīng)(Radio Bearer Setup Response)、專用承載建立口向應(yīng)(Create Dedicated Bearer Response)、PCC 確定通 知石角認(rèn)(PCC decision proposition ACKnowledgement)。其中，在圖3所示的例子中，將MME 30-1、S-Gff 30-2及PDN-GW 30-3的各實(shí)體綜 合表記為GW 30(以后同樣)。此外，省略了 PCRF40的圖示。此外，在圖3所示的例子中， eNB 20-1為連接有呼出側(cè)的UE 10-1的eNB，eNB 20-2為連接有目的地(呼入側(cè))的UE 10-2的eNB?！斑B接有”是指建立了承載的狀態(tài)。在以后的說明中，在不區(qū)別UE 10-1和UE 10_2的情況下，簡記為“UE 10”，同樣 地，在不區(qū)別eNB 20-1和eNB 20_2的情況下，簡記為“eNB 20”。此外，有時(shí)將連接有呼出 側(cè)的UE 10-1的eNB 20-1表記為出側(cè)eNB 20_1，將連接有呼入側(cè)的UE 10-2的eNB 20-2 表記為入側(cè)eNB 20-2。此外，當(dāng)著眼于反方向的通信時(shí)，呼出側(cè)和呼入側(cè)的例子變成與上述 例子相反的關(guān)系。此外，除了 UE 10和CSCF (IMS服務(wù)器)50外的各實(shí)體能夠定位為包括無線接入網(wǎng) 和核心網(wǎng)的一部分或全部的網(wǎng)絡(luò)的結(jié)構(gòu)要素(實(shí)體)。此外，eNB 20和GW 30均能夠定位 為在該網(wǎng)絡(luò)中傳送數(shù)據(jù)(分組)的數(shù)據(jù)(分組)傳送裝置，IMS服務(wù)器50能夠定位為管理、 控制該網(wǎng)絡(luò)中的通信(會(huì)話、承載)的控制裝置。(1.2)報(bào)頭壓縮技術(shù)在便攜電話網(wǎng)中，有效使用無線區(qū)間的資源非常重要。因此，在UElO和eNB 20之 間的分組通信中，使用被稱作R0HC0LE_LINK1 (RobustHeader Compression 魯棒性報(bào)頭壓 縮)0LE_LINK1的報(bào)頭壓縮技術(shù)非常有效。在ROHC 中，對 PDCP (Packet Data Convergence Protocol 分組數(shù)據(jù)集中協(xié)議)分組的有效載荷中所容納的用戶數(shù)據(jù)(IP分組)的報(bào)頭進(jìn)行動(dòng)態(tài)壓縮。例如，在用戶數(shù)據(jù) 為RTP(Real Time Protocol 實(shí)時(shí)協(xié)議)分組的情況下，如圖4所示，IP報(bào)頭、UDP(User Datagram Protocol 用戶數(shù)據(jù)報(bào)協(xié)議)報(bào)頭、RTP報(bào)頭成為壓縮對象。此外，在圖4所示的 例子中，示出了通過ROHC將RTP/UDP/IP報(bào)頭置換成ROHC報(bào)頭的情況。關(guān)于PDCP，在所述的非專利文獻(xiàn)6 (3GPP TS 25. 323 V7. 4. 0)中存在有定義，關(guān)于報(bào)頭壓縮，在該文獻(xiàn)6的第5. 1章中有記述。此外，關(guān)于R0HC，在所述的非專利文獻(xiàn)7 (IETF RFC 3095)中有定義。在ROHC的協(xié)議中，規(guī)定了稱作上下文標(biāo)識(shí)符(CID)的標(biāo)識(shí)符，能夠在1個(gè)通信路
中管理多個(gè)流程。圖5示出ROHC的概念圖。如該圖5所示，壓縮分組報(bào)頭并進(jìn)行發(fā)送的一側(cè)(壓縮 側(cè))用被稱作上下文的與壓縮相關(guān)的內(nèi)部狀態(tài)的數(shù)據(jù)管理流程(分組的目的地)、分組報(bào)頭 中的字段值等。接收側(cè)(解壓縮側(cè))也同樣管理上下文。發(fā)送側(cè)(壓縮側(cè))按照該每個(gè)上下文分配CID，并附加到報(bào)頭壓縮完成的分組(以 下，還稱作壓縮分組或ROHC分組)進(jìn)行發(fā)送。接收側(cè)(解壓縮側(cè))根據(jù)附加到所接收的壓 縮分組的CID，能夠識(shí)別使用哪個(gè)上下文進(jìn)行解壓縮處理為好。[2] 一個(gè)實(shí)施方式(2. 1)整體動(dòng)作概要在以下說明的實(shí)施方式中，在所述SAE中UE 10-1和UE 10_2進(jìn)行通信(例如VoIP 通信)的情況下，能夠進(jìn)行圖6所示的動(dòng)作(分組傳送)。其中，將UE 10-1(第1通信終 端)假定為呼出側(cè)，將UE 10-2(第2通信終端)假定為呼入側(cè)。(1)呼出側(cè)的UE 10-1在對eNB 20或GW 30等的網(wǎng)絡(luò)側(cè)的實(shí)體(以下，還稱作網(wǎng) 絡(luò)實(shí)體)中的省略(繞過)解壓縮和壓縮處理的流程的壓縮分組(R0HC分組)進(jìn)行發(fā)送 時(shí)，對該壓縮分組附加表示不需要(可省略)解壓縮處理的信息(旁路標(biāo)識(shí)符；第1信息要 素)來進(jìn)行發(fā)送(參照圖6的符號(hào)B)。所述旁路標(biāo)識(shí)符優(yōu)選定義(設(shè)定)為能夠如后所述使用的多個(gè)CID中的特定(范 圍)的CID。如果這樣，則沒有必要使用與CID不同的標(biāo)識(shí)符。期望以在網(wǎng)絡(luò)實(shí)體(eNB 20、 GW 30等)之間傳送的流之間不進(jìn)行重復(fù)的方式進(jìn)行該設(shè)定。此外，作為旁路標(biāo)識(shí)符的CID能夠從網(wǎng)絡(luò)實(shí)體(例如IMS服務(wù)器50)進(jìn)行分配(指 定)。該分配的定時(shí)至少在UE 10-1開始?jí)嚎s分組的發(fā)送前即可。優(yōu)選例如在UE 10-1的應(yīng)用程序(VoIP的通信應(yīng)用程序等)開始連接處理而IMS 服務(wù)器50實(shí)施承載建立處理的過程中從IMS服務(wù)器50向UE 10-1進(jìn)行指示(參照圖6的 符號(hào)A)。此時(shí)，優(yōu)選利用在承載建立處理中使用的消息。如果這樣，則不會(huì)增大消息數(shù)量、 處理量、通信開始之前的時(shí)間。(2)連接有呼出側(cè)的UE 10-1的網(wǎng)絡(luò)實(shí)體(eNB 20-1)通過判定從UE 10_1接收到 的壓縮分組的CID是否為特定的CID (旁路標(biāo)識(shí)符)，來判定是否需要報(bào)頭解壓縮處理。此 外，“連接有”是指建立了承載的狀態(tài)。其結(jié)果，如果不需要報(bào)頭解壓縮處理，則該網(wǎng)絡(luò)實(shí)體(eNB 20_1)對所述壓縮分組 不進(jìn)行報(bào)頭解壓縮而進(jìn)行封裝(附加隧道用的GTP報(bào)頭)，并傳送(隧道)到連接有目的地 UE 10-2的網(wǎng)絡(luò)實(shí)體(eNB 20_2)(參照圖6的符號(hào)C、D)。此外，在圖6中，示出了送出到隧道路徑的分組(以下也稱作隧道分組)用GW 30返回到UE 10-2的情況，但是如果能夠設(shè) 定隧道路徑，則也可以不進(jìn)行這種返回。在隧道分組中，優(yōu)選附加連接有目的地UE 10-2的網(wǎng)絡(luò)實(shí)體(eNB20_2)能夠確定 (識(shí)別)該目的地UE 10-2的信息。如果這樣，則接收到隧道分組的網(wǎng)絡(luò)實(shí)體(eNB 20-2) 能夠確定目的地UE 10-2，而不對其他裝置進(jìn)行詢問等。例如，能夠使用識(shí)別從eNB 20_2到 目的地UE 10-2的DL的無線承載的RBID、或與該RBID相關(guān)聯(lián)的信息(DL的TEID)。(3)接收到隧道分組的網(wǎng)絡(luò)實(shí)體(eNB 20-2)對該分組進(jìn)行封裝(去除GTP報(bào)頭)來取出壓縮數(shù)據(jù)，并發(fā)送到目的地UE 10-2。此外，在目的地UE 10-2不支持ROHC的協(xié)議的情況下，按照在3GPP中規(guī)定的動(dòng) 作那樣，在eNB 20-1中對壓縮分組進(jìn)行解壓縮，并將解壓縮后的IP分組發(fā)送到目的地UE 10-2。在以上的從呼出側(cè)UE 10-1到達(dá)目的地UE 10-2的過程(分組發(fā)送過程)中，在 本實(shí)施方式中，例如如圖7所示，使用多種分組格式。Bp, UE 10-1在將分組發(fā)送到支持ROHC協(xié)議的UE 10_2時(shí)，通過ROHC處理?xiàng)＃?照ROHC協(xié)議壓縮分組報(bào)頭。此時(shí)，使用在連接開始時(shí)作為從網(wǎng)絡(luò)側(cè)(IMS服務(wù)器50)指示 的所述旁路標(biāo)識(shí)符的一例的CID。此外，UE 10-1對壓縮分組(包括所述CID的ROHC分組)附加TEID (第2信息 要素)，該TEID被分配到連接有目的地UE 10-2的ΘΝΒ20-2的Sl接口。該TEID為從eNB 20-2向目的地UE 10-2的方向即下行鏈路(DL)用，因此在圖7中被表記為“DL TEID”。如圖7 (1)所示，TEID作為PDCP分組的有效載荷，優(yōu)選附加到ROHC分組的末尾。 如果這樣，能夠使接收該分組的eNB 20-1的協(xié)議處理?xiàng)Ｖ械摹囊延械姆纸M格式脫離的部 分停留在ROHC (PDCP)處理?xiàng)Ｖ?。S卩，呼出側(cè)的UE 10-1在發(fā)送壓縮數(shù)據(jù)時(shí)，將作為第1信息要素的CID、和作為第2 信息要素的TEID，作為在ROHC協(xié)議(報(bào)頭解壓縮處理)所屬的層(PDCP層)中處理的信息 (PDCP有效載荷)附加到所述壓縮數(shù)據(jù)中。此外，所述CID和TEID分別從IMS服務(wù)器50事先對呼出側(cè)的UE10-1進(jìn)行指示 (通知)。例如，在目的地UE 10-2支持ROHC協(xié)議的情況下，IMS服務(wù)器50針對呼出側(cè)的 UE 10-1，從預(yù)先確定的范圍內(nèi)，選擇CID和連接有目的地UE 10-2的eNB 20_2與GW 30之 間的承載的TEID并進(jìn)行發(fā)送。關(guān)于其詳細(xì)情況，將通過圖8后述。如圖7(1)所示，呼出側(cè)的UE 10-1通過PDCP及RLC的處理?xiàng)?，將這些ROHC分組 和TEID存儲(chǔ)到PDCP分組的有效載荷中，附加PDCP報(bào)頭及RLC(Radic) Link Control 無線 鏈路控制)報(bào)頭并發(fā)送到eNB 20-1。eNB 20-1對從UE 10-1接收到的分組(RLC分組)進(jìn)行分析。S卩，eNB 20-1通過 RLC及PDCP的處理?xiàng)６私咏邮辗纸M的RLC報(bào)頭及PDCP報(bào)頭。此外，PDCP處理?xiàng)Ｆ饎?dòng)ROHC 處理?xiàng)?，ROHC處理?xiàng)Ｗx取所述端接后的ROHC分組所包括的所述CID。eNB 20-1 (R0HC處理?xiàng)?根據(jù)該CID，參照eNB 20-1所保有、管理的對應(yīng)表(上下 文數(shù)據(jù))，判定所接收的ROHC分組是否為應(yīng)該省略(繞過)解壓縮處理的分組。在CID示出了應(yīng)該省略解壓縮處理的情況下，eNB 20-1的ROHC處理?xiàng)８鶕?jù)所述 CID，參照eNB 20-1所保有、管理的對應(yīng)表(上下文數(shù)據(jù))，確定傳送目的地(對eNB 20-2的GTP隧道)。此外，eNB 20-1從PDCP有效載荷的末尾讀出所述TEID，將該TEID重新配置到PDCP分組之前，再附加(封裝)包括表示發(fā)給eNB 20-2的GTP隧道的信息的報(bào)頭(GTP報(bào) 頭)來發(fā)送到GW 30(參照圖7(2))。即，作為數(shù)據(jù)傳送裝置的eNB 20在將壓縮數(shù)據(jù)發(fā)送到隧道路徑時(shí)，將作為第2信 息要素的TEID作為在ROHC協(xié)議(報(bào)頭解壓縮處理)所屬的層(PDCP層)的下位層中處理 的信息(GTP有效載荷)附加到所述壓縮數(shù)據(jù)中。此外，由此關(guān)于重新配置TEID的理由將 后述。在GW 30中，通過GTP處理?xiàng)?，依照其GTP報(bào)頭的內(nèi)容將從ΘΝΒ20-1接收到的GTP 分組(隧道分組)傳送到eNB 20-2(參照圖7(3))。此外，設(shè)為將關(guān)于隧道路徑的信息預(yù)先 登記在GW 30中。詳細(xì)情況將后述。此外，在存在能夠直接從eNB 20_1傳送到eNB 20-2 的路徑的情況下，還能夠不經(jīng)由GW 30而將GTP分組從eNB 20-1直接傳送到eNB20_2。eNB 20-2通過GTP處理?xiàng)?，讀出對從GW 30 (或者直接從eNB 20-1)接收到的GTP 分組進(jìn)行解封裝并作為GTP有效載荷而包括的TEID和PDCP分組。此外，eNB 20-2通過PDCP處理?xiàng)Ｆ饎?dòng)ROHC處理?xiàng)＃鶕?jù)eNB 20-2所保有、管理 的對應(yīng)表，確定與所述讀出的TEID對應(yīng)的RBID，通過RLC處理?xiàng)Ｉ砂l(fā)給將該RBID包括在 RLC報(bào)頭中的UE 10-2的RLC分組并發(fā)送到UE 10_2 (參照圖7 (4))。UE 10-2通過RLC處理?xiàng)６私訌膃NB 20_2接收到的RLC分組的RLC報(bào)頭并取出 PDCP分組，通過PDCP處理?xiàng)６私覲DCP報(bào)頭并取出ROHC分組，通過ROHC處理?xiàng)OHC分 組進(jìn)行解壓縮，并將還原的分組傳遞到UE 10-2的應(yīng)用層。此外，作為旁路標(biāo)識(shí)符，除了使用CID以外，還能夠使用下位協(xié)議的標(biāo)識(shí)符，例如 發(fā)送側(cè)RBID等。此時(shí)，呼出側(cè)的UE 10-1自由選擇ROHC的CID。但是，此時(shí)，在ROHC的壓 縮分組從目的地側(cè)的eNB 20-2送出到目的地UE 10_2時(shí)，需要保證與在承載中復(fù)用的其他 流的關(guān)系中不附加相同的CID。因此，需要在RBID和CID兩者中預(yù)約標(biāo)識(shí)符的范圍，可以說 沒有效率。由此，可以說如上所述將上層的標(biāo)識(shí)符即CID用作旁路標(biāo)識(shí)符的做法是優(yōu)選的。此外，為了使目的地側(cè)的eNB 20_2發(fā)現(xiàn)(識(shí)別)傳送接收分組的UE 10_2，除了使 用TEID以外，還能夠使用目的地UE 10-2側(cè)的RBID。此時(shí)，存在能夠采取不使用Sl接口的 上位的承載的方式的優(yōu)點(diǎn)。但是，此時(shí)，在eNB 20-2中必須進(jìn)行與現(xiàn)有的處理不同的處理。 此外，在承載設(shè)定步驟中需要變更。與此相對，在如上所述使用TEID的情況下，目的地側(cè)的eNB 20-2能夠?qū)υ诤舫鰝?cè) 的eNB 20-1中實(shí)施解壓縮處理而傳送的隧道分組、和不實(shí)施解壓縮處理而傳送的非隧道 分組實(shí)施相同的處理來確定目的地UE 10-2。S卩，目的地側(cè)的eNB 20-2在從GW 30接收到分組的情況下，能夠與該分組是否為 隧道分組無關(guān)地，根據(jù)附加到該分組的TEID識(shí)別對目的地UE 10-2的承載，附加與所識(shí)別 的承載對應(yīng)的RBID來發(fā)送到目的地UE 10-2的無線鏈路。此外，在該處理期間，eNB 20-2 能夠進(jìn)行依照承載的QoS將分組放入到等待矩陣等的、每個(gè)承載的處理。換言之，通過使用TEID，eNB 20-2能夠用與從S_GW 30-2經(jīng)由Sl接口接收到分組 時(shí)相同的處理來處理接收分組。因此，可以說從簡單進(jìn)行eNB 20-2中的處理的觀點(diǎn)出發(fā)， 優(yōu)選在隧道分組中附加TEID。
(2. 2)承載設(shè)定(建立)序列接著，關(guān)于從網(wǎng)絡(luò)側(cè)(IMS服務(wù)器50)對呼出側(cè)的UE 10_1進(jìn)行指示(指定)的例子說明在所述分組發(fā)送過程中使用的CID、TEID。在本例中，在呼出側(cè)的UE 10-1開始對目的地UE 10_2的連接處理時(shí)，經(jīng)由IMS服 務(wù)器50在呼出側(cè)的UE 10-1和目的地(呼入側(cè))的UE 10-2之間(端點(diǎn)與端點(diǎn)之間)使 用為了承載建立處理(承載設(shè)置)而收發(fā)的消息，將CID、TEID通知給呼出側(cè)的UE 10-1。例如如圖8所示，在UE 10-1開始向UE 10-2進(jìn)行連接的情況下，UE 10-1向IMS 服務(wù)器(CSCF) 50發(fā)送SIP的INVITE消息(步驟Si)。IMS服務(wù)器50在接收該INVITE消息時(shí)，根據(jù)包括在該消息中的目的地IP地址，向 目的地UE 10-2發(fā)送INVITE消息(步驟S2)。UE 10-2在從IMS服務(wù)器50接收所述INVITE消息，并對來自UE 10-1的呼叫進(jìn)行 響應(yīng)時(shí)，將表示呼叫成功的意思的響應(yīng)消息(2000K)回送到IMS服務(wù)器50 (步驟S3)。此 外，“200”表示消息的狀態(tài)代碼(響應(yīng)代碼)，另外，還具有表示發(fā)送處理中(Trying)的代 碼(100)、和表示呼叫中(ringing)的代碼(180)等。但是，在圖8中，省略了這些過程的圖
7J\ οIMS服務(wù)器50在從目的地UE 10-2接收所述響應(yīng)消息(2000K)時(shí)，執(zhí)行圖3所示 的承載建立過程，建立呼出側(cè)的UE 10-1和呼入側(cè)的UE 10-2之間的會(huì)話(承載)(步驟 S4)。在本例中，使用在該承載建立處理的過程中收發(fā)的各響應(yīng)消息 (ACKknowledgement、Response)，將 TEID 傳遞到 IMS 服務(wù)器 50。由此，IMS 服務(wù)器 50 能夠 獲知eNB 20-1、20-2的TEID(DL_TEID)。此外，eNB 20_1、20_2通過所述響應(yīng)消息，將本站 的識(shí)別信息(eNBID)傳遞到IMS服務(wù)器50。由此，IMS服務(wù)器50能夠按照每個(gè)eNB 20-1, 20-2，管理繞過解壓縮處理的CID。IMS服務(wù)器50在承載建立完成時(shí)，確定UE 10_1、10_2分別在ROHC中使用的 CID (步驟S5)。即，如果為雙向通信的情況，則確定UE10-1用(關(guān)于從UE 10-1到UE 10-2 的方向)的CID、和UE 10-2用(關(guān)于反方向)的CID。此時(shí)，UE 10-1用的CID在對連接有作為通信對方的UE 10-2的eNB 20-2分配的 范圍內(nèi)進(jìn)行選擇，UE 10-2用的CID在對連接有作為通信對方的UE 10-1的eNB 20-1分配 的范圍內(nèi)進(jìn)行選擇。其詳細(xì)情況將后述。IMS服務(wù)器50用SIP的響應(yīng)消息(2000K)將所確定的UE 10-1、10-2用的CID、 TEID傳遞到呼出側(cè)的UE 10-1 (步驟S6)。UE 10_1用SIP的ACK消息將UE 10_2用的CID、 TEID傳遞到目的地UE 10-2 (步驟S7)。此時(shí)，這些參數(shù)(CID、TEID)例如能夠通過SDP(Session DescriptionProtocol 會(huì)話描述協(xié)議)，作為屬性(a = peer-dl-teid :XXX等)記述到SIP消息的有效載荷中，由 此分別傳遞到UE 10-1、10-2。UE 10-1、10-2分別根據(jù)如上所述所指定的TEID和CID進(jìn)行ROHC處理來開始通 信。即，在著眼于UE 10-1向UE 10-2的方向的通信時(shí)，根據(jù)圖7如前所述，UE 10_1將通 過ROHC進(jìn)行了報(bào)頭壓縮(以下還簡稱作“壓縮”)的分組發(fā)送到eNB 20_1 (步驟S8)，eNB 20-1對所接收的分組不進(jìn)行報(bào)頭解壓縮(以下還簡稱作“解壓縮”)而使用TEID進(jìn)行封裝并隧道傳輸?shù)絜NB 20-2(步驟39、310)，州8 20_2在對所接收的隧道分組進(jìn)行解封裝后發(fā) 送到UE 10-2 (步驟Sll)。(2. 3) CID的選擇方法如下確定CID。首先，針對實(shí)施所述旁路處理的eNB 20，分別分配不重復(fù)的CID的 范圍。例如，如果在存在100臺(tái)eNB 20的區(qū)域內(nèi)實(shí)施所述繞過處理，則如下表1所示，能 夠以在 eNB#l 中 CID = 100-199、在 eNB#2 中 CID = 200-299、在 eNB#3 中 CID = 300-399 的方式，分配每隔100個(gè)彼此不重復(fù)的范圍的CID。[表1]CID (的范圍)與eNB的對應(yīng)(eNB) 此外，IMS服務(wù)器50保有例如如下表2所示的CID管理表(CID管理數(shù)據(jù))，并按 照每個(gè)eNB 20預(yù)先登記、管理可使用的CID的范圍。IMS服務(wù)器50根據(jù)該CID管理表，按 照每個(gè)eNB 20，從可使用的CID的范圍選擇未使用的CID(關(guān)于雙向通信為1個(gè))并通知到 呼出側(cè)的UE 10。[表2]CID管理表(IMS服務(wù)器) 此外，GW 30保有例如如下表3所示的路由表，登記、管理每個(gè)隧道路徑(TEID)的 目的地(傳送目的地)eNB 20的信息(eNBID)。GW30能夠根據(jù)該路由表，識(shí)別與接收分組的TEID對應(yīng)的傳送目的地eNB20，向該傳送目的地eNB 20封裝接收分組并進(jìn)行隧道傳輸。 即，即使為在eNB 20間不能直接傳送分組的網(wǎng)絡(luò)形式，也可以進(jìn)行適當(dāng)?shù)姆纸M傳送。[表 3]路由表(GW) 此外，如上所述，在eNB 20之間存在能夠直接傳送的路徑的情況下，能夠不經(jīng)由 Gff 30而直接傳送分組，因此可以不需要關(guān)于該能夠直接傳送的路徑的數(shù)據(jù)。在以上的狀況下，考慮以下的情況UE 10-1與eNB 20_1連接，UE 10_2與eNB 20-2連接(建立了承載)，開始UE 10-1和UE 10-2之間的雙向通信(例如，利用VoIP進(jìn) 行的聲音通話)、即開始用戶數(shù)據(jù)(聲音數(shù)據(jù))分組的收發(fā)。IMS服務(wù)器50根據(jù)所述表2的CID管理表，選擇分配到例如入側(cè)eNB 20-2的CID 范圍中的未使用的“200”作為UE 10-1附加到壓縮分組的CID，選擇分配到例如入側(cè)eNB 20-1的CID范圍中的未使用的“100”作為UE 10-2附加到壓縮分組的CID0IMS服務(wù)器50在分別向UE 10-UUE 10_2通知這些CID并進(jìn)行使用時(shí)，接收到UE 10-1發(fā)送的壓縮分組的eNB 20-1能夠根據(jù)所述表1，在向eNB 20_2的隧道路徑上傳送CID =200的壓縮分組。同樣地，接收到UE 10-2發(fā)送的壓縮分組的eNB 20_2能夠根據(jù)所述表 1，在向eNB 20-1的隧道路徑上傳送CID = 100的壓縮分組。通過以上，根據(jù)本例的系統(tǒng)，能夠得到如下的任意一個(gè)效果或優(yōu)點(diǎn)。(I)UE 10在要壓縮分組進(jìn)行發(fā)送時(shí)，能夠?qū)⒈硎静恍枰鈮嚎s處理的流程的分組 的信息(作為旁路標(biāo)識(shí)符的一例的CID)附加到該分組。(2)在eNB 20中，能夠針對通過某個(gè)通信路從UE 10送出的壓縮分組，在網(wǎng)絡(luò)內(nèi)不 進(jìn)行解壓縮處理而識(shí)別送出到目的地UE 10的分組。(3)關(guān)于附加了特定的標(biāo)識(shí)符(作為旁路標(biāo)識(shí)符的一例的CID)的壓縮分組，省略 了網(wǎng)絡(luò)側(cè)的裝置(eNB 20、GW 30)中的解壓縮處理和壓縮處理，因此在網(wǎng)絡(luò)側(cè)能夠削減將 分組送出到目的地(UE 10)所需的處理量。(4)在網(wǎng)絡(luò)側(cè)的裝置(實(shí)體)之間對壓縮分組不進(jìn)行解壓縮而進(jìn)行傳送時(shí)，能夠進(jìn)行網(wǎng)絡(luò)側(cè)的裝置之間的隧道傳送時(shí)的復(fù)用。作為以該目的而使用的標(biāo)識(shí)符，能夠使用UE 10所附加的標(biāo)識(shí)符(CID)。由此，不需要在網(wǎng)絡(luò)側(cè)的裝置中重新生成并管理標(biāo)識(shí)符。(5)呼出側(cè)的UE 10在連接開始時(shí)從IMS服務(wù)器50指示作為旁路標(biāo)識(shí)符的一例的 所述CID，因此不需要與網(wǎng)絡(luò)側(cè)的實(shí)體(eNB 20、GW 30)以及目的地UE 10_2進(jìn)行交涉，而 只附加所指示的CID即可，因此在通信開始之前不會(huì)增加所需的處理量。(6)網(wǎng)絡(luò)側(cè)的實(shí)體(eNB 20、GW 30)不依照呼出側(cè)的UE 10_1所附加的CID對接 收分組進(jìn)行解壓縮/壓縮而僅進(jìn)行傳送(隧道傳輸)即可，因此能夠不需要每個(gè)連接的轉(zhuǎn) 換表那樣的動(dòng)態(tài)管理的信息。
(7)連接有目的地UE 10的網(wǎng)絡(luò)側(cè)的實(shí)體(入側(cè)eNB 20)能夠從附加到分組的 TEID識(shí)別目的地UE 10-2，因此能夠?qū)⒂盟淼缆窂絺魉蛠淼姆纸M正確發(fā)送到適當(dāng)?shù)哪康牡?UE 10，而不對其他裝置進(jìn)行詢問等。(8)呼出側(cè)的UE 10僅在對目的地UE 10的連接開始時(shí)，在ROHC的壓縮功能中設(shè) 定從網(wǎng)絡(luò)側(cè)(IMS服務(wù)器50)指定的標(biāo)識(shí)符即可，因此能夠?qū)E 10的報(bào)頭壓縮/解壓縮處 理功能的變更抑制到最小限度。此外，在所述專利文獻(xiàn)1中，GGSN端接ROHC協(xié)議，在網(wǎng)關(guān)節(jié)點(diǎn)(GGSN)中生成接收 側(cè)和發(fā)送側(cè)的上下文，并將它們關(guān)聯(lián)起來，由此要減輕GGSN上的ROHC處理的負(fù)擔(dān)。但是， 在專利文獻(xiàn)1的方法中，必須為在網(wǎng)絡(luò)側(cè)的單一裝置(GGSN)內(nèi)對UL和DL的ROHC協(xié)議進(jìn) 行端接的結(jié)構(gòu)。[3]系統(tǒng)結(jié)構(gòu)要素的結(jié)構(gòu)(功能)及動(dòng)作接著，使用圖9 圖23對實(shí)現(xiàn)上述動(dòng)作的UE 10,eNB 20,Gff 30、IMS服務(wù)器50的 各實(shí)體的詳細(xì)結(jié)構(gòu)(功能)及動(dòng)作的一例進(jìn)行詳細(xì)敘述。(3. 1)UE 的說明圖9是示出UE 10的結(jié)構(gòu)例的框圖。該圖9所示的UE 10具有例如承載管理部 11、IMS處理部12、上層處理部13、ROHC處理部14、下層處理部15以及應(yīng)用部16。此外，在圖9中，虛線箭頭A、B、C表示UE 10內(nèi)的信號(hào)傳送路徑(流)，A表示承 載設(shè)定請求時(shí)的信號(hào)流，B表示到eNB 20的信號(hào)流(發(fā)送)，C表示來自eNB 20的接收數(shù) 據(jù)流以及來自UE 10的應(yīng)用部16的發(fā)送數(shù)據(jù)流。S卩，用A表示的信號(hào)流示出了以下情況依次經(jīng)由下層處理部15、IMS處理部12、 承載管理部11、上層處理部13、ROHC處理部14、下層處理部15，在該過程中針對上層處理 部13、R0HC處理部14、下層處理部15進(jìn)行與承載設(shè)定相應(yīng)的設(shè)定。此外，用B表示的信號(hào) 流示出了在IMS處理部12中生成的信令消息在下層處理部15中受到所需的協(xié)議處理并發(fā) 送到eNB 20。用C表示的數(shù)據(jù)流示出了經(jīng)由上層處理部13、R0HC處理部14、下層處理部15 并分別在其中實(shí)施必要的協(xié)議處理的情況。此處，承載管理部11具有以下功能對與eNB 20之間的DL及UL的承載(無線 承載)進(jìn)行管理，根據(jù)來自應(yīng)用部16的請求，與IMS處理部12協(xié)作，實(shí)施承載的建立處理 (消息的生成、收發(fā))。IMS處理部12具有以下功能生成與來自承載管理部11的請求相應(yīng)的消息 (INVITE、2000K等的ISP消息、用于承載建立處理的消息(無線承載設(shè)置響應(yīng))等)，將所 生成的消息發(fā)送到eNB 20，接收eNB 20所發(fā)送的消息等。
上層處理部13在PDCP (ROHC)層的上層中實(shí)施規(guī)定的處理，具有對例如IP、UDP或 RTP(RTCP)等各種協(xié)議的數(shù)據(jù)進(jìn)行處理(報(bào)頭的端接、替換等)的功能(處理?xiàng)?。ROHC處理部14具有依據(jù)定位為PDCP層的協(xié)議棧之一的ROHC協(xié)議進(jìn)行的發(fā)送分組的報(bào)頭壓縮及接收分組的報(bào)頭解壓縮功能(R0HC處理?xiàng)?。本例的ROHC處理部14將在 圖9中示出那樣的、識(shí)別所述繞過處理是否合適(有效/無效)的過濾數(shù)據(jù)(列表)141、和 識(shí)別在ROHC的壓縮處理中使用的上下文的上下文數(shù)據(jù)142保持在未圖示的存儲(chǔ)器等中，并 根據(jù)這些數(shù)據(jù)141、142實(shí)施報(bào)頭壓縮處理。在過濾數(shù)據(jù)141中，登記有如上所述從IMS服務(wù)器50通知的CID和TEID。在圖 1的例子中，示出了以下情況在與確定的目的地(UE 10-2)之間的利用特定的協(xié)議(RTP) 的通信中，作為ROHC的CID，使用表示旁路標(biāo)識(shí)符的CID = 201，最先登記了表示應(yīng)該附加 隧道路徑的識(shí)別信息(DL_TEID) = “333”的項(xiàng)目。此外，關(guān)于其他項(xiàng)目，旁路處理不適合 (FLASE)，DL_TEID也成為未定義。另一方面，在上下文數(shù)據(jù)142中，除了協(xié)議類(UDP/IP、TCP/IP、不壓縮、RTP/UDP/ IP等)以外，還登記有在ROHC的壓縮處理中使用的CID和序列號(hào)(SN)、與壓縮相關(guān)的內(nèi)部 狀態(tài)(狀態(tài)機(jī))等。由此，ROHC處理部14能夠根據(jù)該上下文數(shù)據(jù)142，實(shí)施與所述協(xié)議相 應(yīng)的報(bào)頭壓縮處理。下層處理部15負(fù)責(zé)PDCP層的下層中規(guī)定的協(xié)議處理。具有對例如RLC層、 MAC(MediaAccess Control 媒體訪問控制)層、物理(PHY)層等的各種協(xié)議的數(shù)據(jù)進(jìn)行處 理(報(bào)頭的端接、替換等)的功能(處理?xiàng)?。應(yīng)用部16具有利用VoIP進(jìn)行的聲音通信、HTTP、FTP等的數(shù)據(jù)通信、其他各種應(yīng) 用程序(軟件)，進(jìn)行與該程序相應(yīng)的處理(分組的生成、收發(fā)等)。(動(dòng)作說明)以下，使用圖10 圖12說明如上所述所構(gòu)成的本例的UE 10的動(dòng)作。此外，圖10 是對UE 10為呼出側(cè)時(shí)的連接開始時(shí)的動(dòng)作進(jìn)行說明的流程圖，圖11是對UE 10為呼入側(cè) 的連接開始時(shí)的動(dòng)作進(jìn)行說明的流程圖，圖12是對報(bào)頭壓縮動(dòng)作進(jìn)行說明的流程圖。(呼出側(cè)UE的連接開始時(shí)的動(dòng)作)如圖10所示，呼出側(cè)的UE 10(10-1)在進(jìn)行與呼入側(cè)的UE 10(10-2)的通信(例 如利用VoIP進(jìn)行的聲音通話)的情況下，與承載管理部11和IMS處理部12協(xié)作，生成SIP 的INVITE消息，通過下層處理部15將該INVITE消息發(fā)送給IMS服務(wù)器50 (步驟Al)。這 與圖8的步驟Sl的處理相當(dāng)。之后，在呼入側(cè)的UE 10-2針對INVITE消息將響應(yīng)(2000K)發(fā)送到IMS服務(wù)器50， IMS服務(wù)器50通過開始承載建立處理，從連接有UE 10-1的eNB 20-1接收IMS服務(wù)器50 發(fā)送的無線承載設(shè)置請求(Radio Bearer Setup Request)(參照圖3的步驟S43)時(shí)(步 驟A2)，UE10-1通過承載管理部11進(jìn)行無線承載的設(shè)定(步驟A3)。接著，UE 10-1通過IMS處理部12，生成對所述無線承載設(shè)置請求(Radio Bearer Setup Request)的響應(yīng)(Radio Bearer Setup Response)，并發(fā)送到 eNB 20_1(步驟 A4)。 這與圖3的步驟S44的處理相當(dāng)。之后，在IMS服務(wù)器50主導(dǎo)的承載的建立處理完成、從IMS服務(wù)器50接收SIP消 息(2000K)時(shí)(步驟A5)，UE 10-1通過IMS處理部12，確認(rèn)在該SIP消息中，是否設(shè)定了CID和TEID作為參數(shù)(步驟A6)。其結(jié)果，如果未設(shè)定(如果在步驟A6中為“否”)，則UE 10-1 (IMS處理部12)生 成對所接收的所述SIP消息(2000K)的確認(rèn)響應(yīng)(ACK)消息，并通過下層處理部15向呼入 側(cè)的UE 10-2進(jìn)行發(fā)送(步驟A9)。另一方面，如果在所述SIP消息(2000K)中設(shè)定了 CID和TEID ( S卩，如果接收到在 圖8的步驟S6中記述的SIP消息)，則UE 10-1 (IMS處理部12)經(jīng)由承載管理部11和上 層處理部13在ROHC處理部14中設(shè)定這些參數(shù)，作為在ROHC的報(bào)頭壓縮中使用的CID和 TEID (從步驟A6的“是”路線到步驟A7)。接著，UE 10-1 (IMS處理部12)生成將在呼入側(cè)的UE 10_2壓縮發(fā)送分組時(shí)使用 的CID和TEID作為參數(shù)包括的SIP的ACK消息，并通過下層處理部15向呼入側(cè)的UE 10-2 進(jìn)行發(fā)送(步驟A8)。這與在圖8的步驟S7中所述的處理相當(dāng)。(呼入側(cè)UE的連接開始時(shí)的動(dòng)作)與此相對，如圖11所示，呼入側(cè)的UE 10-2從IMS服務(wù)器50接收在圖8的步驟 S3中示出的SIP的INVITE消息(步驟All)，如果了解到與呼出側(cè)的UE 10-1的通信開始， 則通過IMS處理部12，生成對該INVITE消息的響應(yīng)消息(2000K)，并通過下層處理部15向 IMS服務(wù)器50進(jìn)行發(fā)送(步驟A12)。這與圖8的步驟S3中的處理相當(dāng)。之后，IMS服務(wù)器50通過開始承載建立處理，從連接有UE 10-2的eNB 20-2接收IMS服務(wù)器50發(fā)送的無線承載設(shè)置請求(Radio BearerSetup Request)(參照圖3的步驟 S50)時(shí)(步驟A13)，通過承載管理部11進(jìn)行無線承載的設(shè)定(步驟A14)。接著，UE 10-2通過IMS處理部12，生成對所述無線承載設(shè)置請求(Radio Bearer Setup Request)的響應(yīng)(Radio Bearer Setup Response)，并發(fā)送到 eNB 20_2(步驟A15)。 這與圖3的步驟S51的處理相當(dāng)。之后，UE 10-2在接收到在圖8的步驟S7(圖10的步驟A8或A9)中示出的、呼出 側(cè)的UE 10-1所發(fā)送的SIP的ACK消息時(shí)(步驟A16)，通過IMS處理部12，確認(rèn)在該ACK 消息中，是否設(shè)定了本站10-2使用的TEID和CID作為參數(shù)(步驟A17)。其結(jié)果，如果未設(shè)定所述參數(shù)，則UE 10-2結(jié)束連接開始處理，在與UE 10_1之間 實(shí)施不進(jìn)行已有的繞過處理的通常那樣的通信(步驟A17的“否”路線)。另一方面，如果設(shè)定了所述參數(shù)(即，如果接收到在圖8的步驟S7中示出的SIP 消息)，則UE 10-2 (IMS處理部12)經(jīng)由承載管理部11和上層處理部13在ROHC處理部14 中設(shè)定這些參數(shù)，作為在ROHC的報(bào)頭壓縮中使用的CID和TEID (從步驟A17的“是”路線 到步驟A18)。(UE的報(bào)頭壓縮動(dòng)作)如前所述，在針對呼出側(cè)的UE 10-1、呼入側(cè)的UE 10_2各自中的ROHC處理部14 設(shè)定所述參數(shù)(CID和TEID)時(shí)，ROHC處理部14依照圖12所示的流程圖實(shí)施發(fā)送分組的 報(bào)頭壓縮處理。S卩，ROHC處理部14在存在發(fā)送分組時(shí)，參照并檢索所述過濾數(shù)據(jù)141(步驟A21)， 確認(rèn)是否存在與所設(shè)定的CID和TEID相應(yīng)的項(xiàng)目(步驟A22)。其結(jié)果，如果不存在相應(yīng)項(xiàng)目，則ROHC處理部14根據(jù)發(fā)送分組的地址、協(xié)議，生成 設(shè)為APPLY = FALSE、DL_TEID =未定義、CID =未定義的新項(xiàng)目(從步驟A22的“否”路線到步驟A23)。
另一方面，如果存在相應(yīng)項(xiàng)目，則ROHC處理部14存儲(chǔ)該項(xiàng)目的內(nèi)容(APPLY、DL_ TEID、CID)，作為關(guān)于該發(fā)送分組的報(bào)頭壓縮處理使用的臨時(shí)變量(步驟A24)，確認(rèn)CID是 否定義完成(步驟A25)。其結(jié)果，如果為未定義(如果在步驟A25中為“否”)，則ROHC處理部14分配關(guān)于 旁路(隧道)對象的分組的CID以外的未使用的CID并存儲(chǔ)到過濾列表141中(步驟A26)， 用該CID的上下文進(jìn)行報(bào)頭壓縮(步驟A27)。另一方面，如果CID為定義完成(如果在步 驟A25中為“是”)，則ROHC處理部14用該CID的上下文進(jìn)行報(bào)頭壓縮(步驟A27)。此外， 該CID成為ROHC分組的報(bào)頭信息要素。此外，ROHC處理部14確認(rèn)所述臨時(shí)變量“APPLY”是否為“TRUE” (步驟A28)，如果 為“TRUE”(如果在步驟A28中為“是”)，則將DL_TEID附加(連接)到發(fā)送分組的末尾(步 驟A29)，從而完成報(bào)頭壓縮處理。另一方面，如果為“FALSE”(如果在步驟28中為“否”)， 則ROHC處理部14結(jié)束報(bào)頭壓縮處理。S卩，本例的ROHC處理部14作為以下的附加單元發(fā)揮作用在發(fā)給目的地UE 10-2 的壓縮數(shù)據(jù)中，附加識(shí)別是否需要報(bào)頭解壓縮處理和對目的地UE 10-2的隧道路徑中所使 用的信息(CID、TEID)。此外，下層處理部15作為向網(wǎng)絡(luò)發(fā)送附加了所述信息的壓縮數(shù)據(jù) 的發(fā)送單元發(fā)揮作用。此外，關(guān)于接收分組的報(bào)頭解壓縮處理，與現(xiàn)有的處理相同，因此省略說明。(3. l)eNB 的說明圖13是示出eNB 20的結(jié)構(gòu)的框圖。該圖13所示的eNB 20具有例如承載管理部 21、信號(hào)處理部22、上層處理部23、ROHC處理部24以及下層處理部25。在該圖13中，虛線箭頭A E也表示eNB 20內(nèi)的信號(hào)傳送路徑(流)，A表示承 載設(shè)定請求時(shí)的信號(hào)流，B表示對UE 10或GW 30的信號(hào)流，C表示來自其他eNB 20的數(shù)據(jù) 流，D表示來自GW 30的數(shù)據(jù)流，E表示來自UE 10的用戶數(shù)據(jù)流。即，用A表示的信號(hào)流示出了以下情況依次經(jīng)由下層處理部25、信號(hào)處理部22、 承載管理部21、上層處理部23、ROHC處理部24、下層處理部25，在該過程中能夠針對上層 處理部23、R0HC處理部24、下層處理部25進(jìn)行與承載設(shè)定相應(yīng)的設(shè)定。此外，用B表示的 信號(hào)流示出了在信號(hào)處理部22中生成的信令消息在下層處理部25中受到所需的協(xié)議處理 并發(fā)送到UE 10或eNB 20的情況。用C表示的數(shù)據(jù)流示出了從eNB 20接收到的分組依次經(jīng)由下層處理部25、上層處 理部23、下層處理部25，在各個(gè)中實(shí)施必要的協(xié)議處理并發(fā)送到其他eNB 20的情況。用D 表示的數(shù)據(jù)流表示從GW 30接收到的分組依次經(jīng)由下層處理部25、上層處理部23、R0HC處 理部24、下層處理部25來進(jìn)行處理的情況。用E表示的數(shù)據(jù)流表示從UE 10接收到的分 組依次經(jīng)由下層處理部25、R0HC處理部24、上層處理部23、下層處理部25來進(jìn)行處理的情 況。此處，承載管理部21具有以下功能對UE 10側(cè)(DL)及GW 30側(cè)(UL)的承載進(jìn) 行管理，與信號(hào)處理部22協(xié)作，實(shí)施DL及UL的承載建立處理(消息的生成、收發(fā))。信號(hào)處理部22具有以下功能生成與來自承載管理部21的請求相應(yīng)的消息(發(fā) 給UE 10的無線承載設(shè)置請求、以發(fā)給GW 30的專用承載建立響應(yīng)等)，將所生成的消息發(fā)送到UE 10或GW 30，接收UE 10或GW 30所發(fā)送的消息(無線承載設(shè)置響應(yīng)、專用承載建
立請求等)等。上層處理部23實(shí)施在PDCP(ROHC)層的上層中規(guī)定的處理，具有對例如IP、UDP、RTP(RTCP)等各種協(xié)議的數(shù)據(jù)進(jìn)行處理(報(bào)頭的端接、替換等)的功能。該上層處理部23 發(fā)揮以下的作用通過下層處理部25將在ROHC處理部24不實(shí)施解壓縮處理而傳送來的接 收分組(隧道分組)傳送到GW 30。ROHC處理部24具有利用ROHC進(jìn)行的發(fā)送分組的報(bào)頭壓縮及接收分組的報(bào)頭解壓 縮功能。本例的ROHC處理部24將在圖13中示出那樣的過濾數(shù)據(jù)(列表)241和上下文數(shù) 據(jù)242保持在未圖示的存儲(chǔ)器等中，并根據(jù)這些數(shù)據(jù)241、242實(shí)施ROHC分組的報(bào)頭壓縮、 解壓縮處理。此處，過濾列表241是與UE 10中的過濾列表141為相同內(nèi)容的列表，為用于識(shí)別 所述繞過處理是否合適(有效/無效)的數(shù)據(jù)。其中，在eNB 20中，預(yù)先登記有使用繞過 處理的CID、TEID。由此，ROHC處理部24在從UE 10接收到的ROHC分組中，設(shè)定了登記在過濾列表 241中的項(xiàng)目的CID、TEID時(shí)，對該ROHC分組不進(jìn)行報(bào)頭解壓縮而傳送到上層處理部23。上下文數(shù)據(jù)242為用于識(shí)別ROHC的報(bào)頭壓縮處理中所使用的上下文的數(shù)據(jù)，如在 圖13中所示，具有在各eNB 20中共用的對應(yīng)表242a、和UE 10的每個(gè)承載的對應(yīng)表242b。對應(yīng)表242a與已述的表1相當(dāng)，能夠根據(jù)附加到接收分組的CID，參照、檢索該對 應(yīng)表242a，由此確定傳送(隧道)目的地(連接有呼入側(cè)的UE 10的eNB 20)。另一個(gè)對應(yīng)表242b與UE 10中的上下文數(shù)據(jù)141為相同內(nèi)容，除了協(xié)議類(UDP/ IP、TCP/IP、不壓縮、RTP/UDP/IP等)以外，還按照UElO間的承載單位登記ROHC的壓縮處 理中所使用的CID和序列號(hào)(SN)、與壓縮相關(guān)的內(nèi)部狀態(tài)(狀態(tài)機(jī))等。由此，ROHC處理 部24能夠根據(jù)該對應(yīng)表242b，按照承載實(shí)施與所述協(xié)議相應(yīng)的報(bào)頭壓縮處理。下層處理部25實(shí)施在PDCP層的下層中規(guī)定的處理，具有對例如RLC層、MAC層、 物理(PHY)層等的各種協(xié)議的數(shù)據(jù)進(jìn)行處理(報(bào)頭的端接、替換等)的功能。此外，也可以在能夠進(jìn)行TEID的確定的ROHC處理部24中進(jìn)行隧道分組的建立 (附加TEID)(即，包括TEID作為PDCP分組的有效載荷)，但是在構(gòu)成圖7(2)所示的格式 (包括TEID作為GTP分組的有效載荷)的情況下，在下層處理部25中進(jìn)行隧道分組的建 立。此時(shí)，將ROHC處理部24所確定的TEID與隧道傳輸?shù)腞OHC分組一起傳送到下層 處理部24。此時(shí)，在接收到隧道分組的入側(cè)eNB 20-2中，能夠通過更下層的處理(下層處 理部25)確定TEID，因此能夠提前進(jìn)行對呼入側(cè)的UE 10-2的分組傳送。下層處理部25實(shí)施在PDCP層的下層中規(guī)定的處理，具有對例如RLC層、MAC層、 物理(PHY)層等的各種協(xié)議的數(shù)據(jù)進(jìn)行處理(報(bào)頭的端接、替換等)的功能。此外，如在圖 13中所示，該下層處理部25能夠?qū)EID和RBID的對應(yīng)表(表)251保持在未圖示的存儲(chǔ) 器等中，根據(jù)附加到從GW 30接收到的隧道分組的所述TEID，參照并檢索該對應(yīng)表251，由 此識(shí)別應(yīng)該發(fā)送該隧道分組的RBID(即，對呼入側(cè)的UE 10-2的無線(DL)鏈路)。(動(dòng)作說明)以下，使用圖14 圖16說明如上所述所構(gòu)成的本例的eNB 20的動(dòng)作。此夕卜，圖14是對eNB 20中的連接(呼叫連接)開始時(shí)的動(dòng)作進(jìn)行說明的流程圖，圖15是對從UE 10 接收到UL的分組時(shí)的動(dòng)作進(jìn)行說明的流程圖，圖16是對從GW 30接收到DL的分組時(shí)的動(dòng) 作進(jìn)行說明的流程圖。(連接開始時(shí)的動(dòng)作)
eNB 20在從GW 30接收到在圖3的步驟S42或S49中示出的專用承載建立請求 (Create Dedicated Bearer Request)消息時(shí)(步驟Bi)，與承載管理部21和信號(hào)處理部 22協(xié)作，生成發(fā)給UE 10的所述無線承載設(shè)置請求(Radio Bearer Setup Request)消息， 并通過下層處理部25發(fā)送到UE 10(步驟B2)。這與圖3的步驟S43或S50的處理相當(dāng)。之后，eNB 20 (承載管理部21和信號(hào)處理部22)在接收到在圖3的步驟S44或S51 中示出的響應(yīng)消息(Radio Bearer Setup Response)時(shí)(步驟B3)，設(shè)定與UE 10之間的無 線承載(步驟B4)，此外，設(shè)定與GW 30之間的專用承載(步驟B5)。此外，這些承載的設(shè)定 順序可以相反，也可以并行實(shí)施。接著，eNB 20 (承載管理部21和信號(hào)處理部22)生成專用承載建立響應(yīng)(Create Dedicated Bearer Response)消息，并通過下層處理部25發(fā)送到GW 30 (步驟B6)。如在 圖8的步驟S4中所述那樣，在該消息中包括有DL的TEID (DL_TEID)和本站20的識(shí)別信息 (eNBID)。此外，該處理與圖3的步驟S46或S52所示的處理相當(dāng)。此外，為了判斷從GW30 接收到的GTP分組是否為隧道分組，在eNB 20中存儲(chǔ)該TEID。(從UE接收UL的分組的情況)如圖15所示，eNB 20在上述的承載建立處理完成、在UE 10之間開始通信，并從 UE 10接收到UL的分組時(shí)(步驟B11)，通過ROHC處理部24，檢測附加到該接收分組的CID， 根據(jù)該CID，參照并檢索過濾列表241 (步驟B12)，確認(rèn)是否需要解壓縮處理(是否為隧道 對象的分組)(步驟B13)。其結(jié)果，如果不是不需要解壓縮處理的隧道對象的分組(在步驟B13中為“否” 時(shí))，則ROHC處理部24根據(jù)上下文數(shù)據(jù)242的對應(yīng)表242b，確定在該壓縮分組的解壓縮中 使用的上下文，并使用所確定的上下文實(shí)施分組(壓縮分組)的解壓縮處理(步驟B14)，通 過下層處理部25作為IP分組向外部(GW 30)進(jìn)行傳送(步驟B15)。另一方面，如果接收分組是不需要解壓縮處理的隧道對象的分組(在步驟B13中 為“是”時(shí))，則ROHC處理部24讀出附加到該分組的末尾的TEID (步驟B16)，將傳送目的 地(隧道ID = eNBID)、所讀出的所述TEID存儲(chǔ)到對該分組處理使用的臨時(shí)變量中(步驟 B17)。此外，傳送目的地(eNBID)能夠從上下文數(shù)據(jù)242a的對應(yīng)表242a得到。如果為圖 13中的例子，可知應(yīng)該將CID = 201的分組傳送到eNBID = #2所識(shí)別的入側(cè)eNB 20_2。接著，ROHC處理部24在壓縮分組中附加P⑶P報(bào)頭并作為PDCP分組與TEID —起， 經(jīng)由上層處理部23傳送到下層處理部25。下層處理部25在傳送來的TEID和PDCP分組 中，附加隧道用的GTP報(bào)頭。在隧道用的GTP報(bào)頭中，包括例如具有通過TEID識(shí)別的Sl接 口的入側(cè)eNB20的地址信息。由此，建立圖7 (2)所示的格式的GTP分組(隧道分組)，并發(fā) 送到GW 30(步驟附8、819)。該處理與在圖8的步驟S9中示出的處理相當(dāng)。S卩，本例的下層處理部25作為從UE 10-1接收在呼出側(cè)的UE 10_1中附加了特定 的CID和TEID的壓縮數(shù)據(jù)的接收單元發(fā)揮作用，ROHC處理部24作為根據(jù)所述CID、TEID， 識(shí)別是否需要所接收的壓縮數(shù)據(jù)的報(bào)頭解壓縮處理和對目的地UE 10-2的傳送路徑的識(shí)別單元發(fā)揮作用。此外，下層處理部25還作為對識(shí)別為不需要報(bào)頭解壓縮處理的壓縮數(shù)據(jù) 不進(jìn)行報(bào)頭解壓縮處理而發(fā)送到所述識(shí)別的傳送路徑的發(fā)送單元發(fā)揮作用。(從GW接收到DL的分組的情況) 如圖16所示，eNB 20在上述的承載建立處理完成、在UE 10之間開始通信，并從 Gff 30接收到DL的分組(GTP分組)時(shí)，通過下層處理部25，端接并分析GTP報(bào)頭，從而確 認(rèn)在該GTP報(bào)頭中設(shè)定的TEID (DL_TEID)是否為隧道用(步驟B20)。S卩，如果GTP報(bào)頭中的TEID與在已述的承載建立處理時(shí)通知并存儲(chǔ)的TEID —致， 則接收分組為隧道分組，如果不一致，則判斷為通常的(不繞過解壓縮處理)的分組。其結(jié)果，如果接收分組為隧道分組，則eNB 20 (下層處理部25)根據(jù)附加到該GTP 分組的有效載荷的TEID (DL_TEID)，參照并檢索TEID-BRID對應(yīng)表251，確定對目的地UE 10 的RBID (從步驟B20的“是”到步驟B23)。此外，下層處理部25通過去除所述TEID來生成的通常的PDCP分組，并對該P(yáng)DCP 分組附加包括所述確定的RBID的RLC報(bào)頭，從而生成圖7 (4)所示的格式的RLC分組，并將 其發(fā)送到目的地UE 10(步驟B25)。該處理與在圖8的步驟Sll中示出的處理相當(dāng)。另一方面，在從GW 30接收到的DL的分組不是隧道分組的情況下(在步驟B20中 為“否”的情況)，eNB 20 (下層處理部25)根據(jù)在接收GTP分組的GTP報(bào)頭中設(shè)定的TEID， 確定對目的地UE 10的RBID (步驟B21)，并將GTP有效載荷(PDCP分組)傳送到ROHC處理 部24。ROHC處理部24對于傳送來的PDCP分組，分配未使用的CID并實(shí)施通常的報(bào)頭壓 縮處理(步驟B22)。所得到的壓縮分組經(jīng)由上層處理部23傳送到下層處理部25，通過下 層處理部25建立在RLC報(bào)頭中包括所確定的所述RBID的RLC分組，并發(fā)送到目的地UE 10 (步驟 B25)。(3. 3) GW 的說明圖17是示出GW 30的結(jié)構(gòu)的框圖。該圖17所示的GW 30具有例如承載管理部 31、信號(hào)處理部32、上層處理部33以及下層處理部35。在該圖17中，虛線箭頭A D也表示GW 30內(nèi)的信號(hào)傳送路徑(流)，A表示承載 設(shè)定請求時(shí)的信號(hào)流，B表示對IMS服務(wù)器50或eNB 20的信號(hào)流，C表示來自eNB 20的隧 道流，D表示從UE 10到因特網(wǎng)等外部網(wǎng)及從外部網(wǎng)到UE 10的數(shù)據(jù)流。S卩，用A表示的信號(hào)流示出了以下情況依次經(jīng)由下層處理部34、信號(hào)處理部32、 承載管理部31、上層處理部33、下層處理部34，在該過程中能夠針對上層處理部23、下層處 理部34進(jìn)行與承載設(shè)定相應(yīng)的設(shè)定。此外，用B表示的信號(hào)流示出了在信號(hào)處理部32中 生成的信令消息在下層處理部34中受到所需的協(xié)議處理并發(fā)送到IMS服務(wù)器50或eNB20 的情況。用C表示的數(shù)據(jù)流示出了從eNB 20接收到的隧道分組依次經(jīng)由下層處理部34、上 層處理部33、下層處理部34，在各個(gè)中實(shí)施必要的協(xié)議處理并發(fā)送到其他eNB 20的情況。 用D表示的數(shù)據(jù)流表示例如接收分組依次經(jīng)由下層處理部34、上層處理部33、下層處理部 34來進(jìn)行處理的情況。此處，承載管理部31具有以下功能對與eNB 20 (出側(cè)eNB 20-1和入側(cè)eNB 20-2 雙方)之間的承載進(jìn)行管理，與信號(hào)處理部32協(xié)作，實(shí)施承載建立處理(消息的生成、收發(fā))。
信號(hào)處理部32具有以下功能生成與來自承載管理部31的請求相應(yīng)的消息(發(fā) 給eNB 20的專用承載建立請求、發(fā)給IMS服務(wù)器50的PCC確定通知響應(yīng)等)，將所生成的 消息發(fā)送到eNB 20或IMS服務(wù)器50，接收eNB 20或IMS服務(wù)器50所發(fā)送的消息(專用承 載建立請求、PCC確定通知等)等。上層處理部33實(shí)施在PDCP(ROHC)層的上層中規(guī)定的處理，具有對例如IP、UDP、 RTP(RTCP)等各種協(xié)議的數(shù)據(jù)進(jìn)行處理(報(bào)頭的端接、替換等)的功能。該上層處理部33 將在圖17中示出那樣的過濾數(shù)據(jù)(列表)331和路由表332保持在未圖示的存儲(chǔ)器等中， 并根據(jù)這些確定(控制)接收分組的傳送目的地。過濾列表331是識(shí)別從因特網(wǎng)等外部傳送來的分組的傳送目的地所使用的數(shù)據(jù)。 在該過濾列表331中，如在圖17所示那樣，例如按照每個(gè)目的地UE 10，登記識(shí)別連接有該 UE 10的eNB 20的信息(eNBID)、和識(shí)別對該eNB 20的隧道路徑的TEID (DL_TEID)。上層處理部33在對從外部接收到的DL的分組進(jìn)行處理時(shí)，根據(jù)該分組的目的地 地址信息，參照該列表331的項(xiàng)目，由此能夠識(shí)別目的地UE 10與哪個(gè)eNB 20連接，為向該 eNB 20傳送分組，應(yīng)該對GTP報(bào)頭賦予哪個(gè)TEID來進(jìn)行傳送。該過濾列表331根據(jù)在例如 圖8所示的承載建立處理的過程通知的信息登記項(xiàng)目來得到構(gòu)建。路由表332為在確定從eNB 20接收到的分組的傳送目的地(目的地eNB 20)中 使用的數(shù)據(jù)。在該路由表332中，按照對從eNB 20接收的分組的隧道路徑進(jìn)行識(shí)別的每個(gè) 信息(隧道ID)，登記目的地eNB 20的信息(例如eNBID)。例如，在圖17中所示的例子中，在4個(gè)項(xiàng)目中的下面2個(gè)項(xiàng)目中，登記有在出側(cè) eNB 20中繞過報(bào)頭解壓縮處理的分組的傳送目的地eNB20的信息(eNBID)。這些隧道傳送 的項(xiàng)目例如在網(wǎng)絡(luò)構(gòu)建時(shí)預(yù)先分配，在GW 30的起動(dòng)時(shí)自動(dòng)設(shè)定。剩下的2個(gè)項(xiàng)目表示關(guān) 于從eNB 20實(shí)施報(bào)頭解壓縮處理而傳送來的通常的分組的項(xiàng)目。上層處理部33能夠根據(jù)從eNB 20接收到的分組的TEID，參照并檢索該路由表 332的項(xiàng)目，由此識(shí)別接收分組的傳送目的地(目的地eNB20)。下層處理部34實(shí)施在PDCP層的下層中規(guī)定的處理，具有對例如物理(PHY)層、以 太網(wǎng)(注冊商標(biāo))層等的各種協(xié)議的數(shù)據(jù)進(jìn)行處理(報(bào)頭的端接、替換等)的功能。例如， 根據(jù)在所述上層處理部33中識(shí)別的傳送目的地的信息進(jìn)行傳送分組的報(bào)頭替換等。(動(dòng)作說明)以下，使用圖18 圖21說明如上所述構(gòu)成的本例的GW 30的動(dòng)作。此夕卜，圖18 是對GW 30中的連接(呼叫連接)開始時(shí)的動(dòng)作進(jìn)行說明的流程圖，圖19是對從外部接收 到分組時(shí)的動(dòng)作進(jìn)行說明的流程圖，圖20是對從GW 30接收到應(yīng)該傳送到外部的分組時(shí)的 動(dòng)作進(jìn)行說明的流程圖，圖21是對接收到隧道分組時(shí)的動(dòng)作進(jìn)行說明的流程圖。(連接開始時(shí)的動(dòng)作)Gff 30在從IMS服務(wù)器50接收到在圖3的步驟S41中示出的PCC確定通知(PCC decision proposition)消息時(shí)(步驟Cl)，與承載管理部31和信號(hào)處理部32協(xié)作，生成 發(fā)給出側(cè)eNB 20-1的專用承載建立請求(Create Dedicated Bearer Request)消息，并通 過下層處理部34向出側(cè)eNB 20-1進(jìn)行發(fā)送(步驟C2)。這與圖3的步驟S42的處理相當(dāng)。之后，Gff 30 (承載管理部31和信號(hào)處理部32)在接收到在圖3的步驟S45中示出的響應(yīng)消息(Radio Bearer Setup Response)時(shí)(步驟C3)，讀出在該響應(yīng)消息中設(shè)定的 TEID (步驟C4)，并設(shè)定與出側(cè)eNB 20-1之間的專用承載(步驟C5)。此外，TEID的讀出和 專用承載的設(shè)定可以為相反順序，也可以并行實(shí)施。接著，Gff 30 (承載管理部31和信號(hào)處理部32)在從IMS服務(wù)器50接收到在圖3 的步驟S47中示出的PCC確定通知(PCC decisionproposition)消息時(shí)(步驟C6)，生成發(fā) 給入側(cè)eNB 20-2的專用承載建立請求(Create Dedicated Bearer Request)消息，并通過 下層處理部34向入側(cè)eNB 20-2進(jìn)行發(fā)送(步驟C7)。這與圖3的步驟S48的處理相當(dāng)。
之后，Gff 30 (承載管理部31和信號(hào)處理部32)在從入側(cè)eNB 20-2接收到在圖3 的步驟S51中示出的專用承載建立響應(yīng)(Create DedicatedBearer Response)消息時(shí)(步 驟C8)，讀出在該響應(yīng)消息中設(shè)定的TEID (步驟C9)，并設(shè)定與入側(cè)eNB 20-2之間的專用承 載(步驟C10)。此外，此時(shí)，TEID的讀出和專用承載的設(shè)定可以為相反順序，也可以并行實(shí) 施。此外，Gff 30 (承載管理部31和信號(hào)處理部32)在對IMS服務(wù)器50報(bào)告承載設(shè) 定完成的PCC確定通知確認(rèn)(PCC decision PropositionACK)消息中，賦予所述讀出的各 TEID (呼出側(cè)及呼入側(cè))，并將該消息發(fā)送到IMS服務(wù)器50(步驟Cll)。對該TEID的IMS 服務(wù)器50的通知也可以在圖3所示的步驟S46及S52中分別關(guān)于呼出側(cè)或呼入側(cè)的一個(gè) 方向?qū)嵤?從外部接收到分組的情況)如圖19所示，GW 30在從因特網(wǎng)等外部接收到DL(發(fā)給UE 10)的分組時(shí)(步驟 C21)，在下層處理部34中進(jìn)行該接收分組的報(bào)頭終端處理等后，傳送到上層處理部33。上 層處理部33對所傳送的接收分組的IP報(bào)頭進(jìn)行分析，讀取其目的地地址信息，并根據(jù)該目 的地地址信息，參照過濾列表331的相應(yīng)項(xiàng)目，檢索并確定連接有目的地UE 10的eNB 20 及DL的TEID (步驟C22)。上層處理部33將接收分組和所確定的所述信息傳送到下層處理部34，下層處理 部34生成包括所述確定的信息的GTP報(bào)頭，附加到接收分組中并發(fā)送到通過DL的TEID識(shí) 別的隧道路徑(步驟C23)。S卩，上層處理部33和下層處理部34將從外部接收到的分組轉(zhuǎn)換(封裝)為適于 傳送到連接有目的地UE 10的eNB 20的格式，并發(fā)送到eNB20。(從eNB接收到應(yīng)該發(fā)送到外部的分組的情況)如圖20所示，GW 30在從eNB 20接收到發(fā)給因特網(wǎng)等外部的分組時(shí)(步驟C31)， 通過下層處理部34和上層處理部33，去除發(fā)送到外部時(shí)不需要的報(bào)頭等，讀出應(yīng)該發(fā)送到 外部的IP分組(步驟C32)，并將所讀出的IP分組發(fā)送到外部(步驟C33)。即，上層處理部33和下層處理部34在將從eNB 20接收到的針對外部的分組轉(zhuǎn)換 為適于向外部傳送的格式后，將接收分組發(fā)送到外部。(接收到隧道分組的情況)如圖21所示，GW 30在接收到在出側(cè)eNB 20中繞過報(bào)頭解壓縮處理而通過隧道 路徑傳送來的分組時(shí)(步驟C41)，該分組從下層處理部34傳送到上層處理部33，上層處理 部33根據(jù)賦予到GTP有效載荷的DL的TEID，參照路由表332檢索相應(yīng)項(xiàng)目，并確定傳送目 的地(目的地)eNB 20 (DL的隧道路徑)(步驟C42)。
此外，上層處理部33將接收分組(GTP有效載荷)與所確定的信息一起傳送到下 層處理部34，下層處理部34在附加了包括表示所述確定的DL的隧道路徑(目的地eNB 20) 的信息(eNBID)的報(bào)頭后發(fā)送到所述隧道路徑(步驟C43)。即，上層處理部33和下層處理部34在接收到在出側(cè)eNB 20中繞過報(bào)頭解壓縮處 理而傳送來的分組時(shí)，實(shí)施必要的報(bào)頭替換處理，以將該接收分組傳送給賦予到GTP有效 載荷中的TEID所示的隧道目的地，然后進(jìn)行分組發(fā)送。(3. 4) IMS服務(wù)器的說明圖22是示出IMS服務(wù)器50的結(jié)構(gòu)的框圖。該圖22所示的IMS服務(wù)器50具有例 如IMS處理部51和下層處理部52。此外，在該圖22中，虛線箭頭A示出了 IMS服務(wù)器50 內(nèi)的信號(hào)傳送路徑(流)。即，用A表示的信號(hào)流示出了經(jīng)由下層處理部52和IMS處理部 51，進(jìn)行SIP消息或承載建立時(shí)的消息的收發(fā)的情況。此處，IMS處理部51具有例如生成發(fā)給UE 10的SIP消息(INVITE消息等)和承 載建立處理時(shí)的發(fā)給GW 30的消息(PCC確定通知等)的功能、接收UE 10所發(fā)送的SIP消 息(2000K消息)和來自Gff 30的響應(yīng)消息(PCC確定通知確認(rèn)等)的功能。該IMS處理部51將在圖22中示出那樣的與已述表2的內(nèi)容相當(dāng)?shù)腃ID管理表 (表)511保持在未圖示的存儲(chǔ)器等中。CID管理表511如符號(hào)511、511b所示，其為用于按照對傳送目的地eNB 20的每 個(gè)隧道路徑(DL_TEID)，對作為不需要在出側(cè)eNB 20中的報(bào)頭解壓縮處理的信息的一例的 CID的使用狀況(使用/未使用)進(jìn)行管理的數(shù)據(jù)，根據(jù)在圖3的步驟S4中示出的承載建 立過程中通知的TEID、eNBID來構(gòu)建。IMS處理部51根據(jù)該CID管理表511，以在相同的隧道路徑內(nèi)不重復(fù)的方式管理 不需要在出側(cè)eNB 20中的報(bào)頭解壓縮處理的CID，并分配到UE 10。下層處理部52具有將所述SIP消息或在承載建立處理時(shí)使用的消息轉(zhuǎn)換為適于 與GW 30之間的接口的格式(協(xié)議)的功能等。(動(dòng)作說明)以下，使用圖23說明如上所述構(gòu)成的本例的IMS服務(wù)器50的動(dòng)作。此外，圖23 是對IMS服務(wù)器50中的連接(呼叫連接)開始時(shí)的動(dòng)作進(jìn)行說明的流程圖。如圖8的步驟Sl所示，IMS服務(wù)器50在通過下層處理部52在IMS處理部51中， 從呼出側(cè)的UE 10-1接收到SIP的INVITE消息時(shí)(步驟Dl)，根據(jù)包括在該INVITE消息 中的目的地信息，確定呼入側(cè)的UE 10-2，并通過下層處理部52，向該UE 10_2發(fā)送SIP的 INVITE消息(步驟D2)。該處理與圖8的步驟S2所示的處理相當(dāng)。之后，IMS服務(wù)器50 (IMS處理部51)在從呼入側(cè)的UE 10-2接收到對所述INVITE 消息的響應(yīng)消息(2000K)時(shí)(步驟D3)，生成請求呼出側(cè)的UE 10-1和GW 30之間的承載建 立的消息(PCC確定通知)，并發(fā)送到GW 30 (步驟D4)。該處理與圖3的步驟S41所示的處 理相當(dāng)。如圖3的步驟S46所示，IMS服務(wù)器50在接收到對該消息的響應(yīng)消息(PCC確定 通知確認(rèn))時(shí)，提取在該響應(yīng)消息中設(shè)定的DL的TEID (步驟D5)。此外，IMS服務(wù)器50生成請求呼入側(cè)UE 10-2和GW 30之間的承載建立的消息 (PCC確定通知)，并發(fā)送到GW 30(步驟D6)。該處理與圖3的步驟S47所示的處理相當(dāng)。
如圖3的步驟S52所示，IMS服務(wù)器50在接收到對該消息的響應(yīng)消息(PCC確定 通知確認(rèn))時(shí)，提取在該響應(yīng)消息中設(shè)定的DL的TEID (步驟D7)。此外，也可以并行實(shí)施呼出側(cè)UE 10-1和GW 30之間的承載建立請求、以及呼入側(cè)UE 10-2和GW 30之間的承載建立請求。之后，IMS服務(wù)器50 (IMS處理部51)從所述CID管理表511 (511a、511b)中的未 使用的CID中選擇呼出側(cè)的UE 10-1及呼入側(cè)的UE 10-2各自在ROHC的報(bào)頭中應(yīng)該使用 的CID (步驟D8)。此外，IMS處理部51將所選擇的CID在所述CID管理表511中的使用狀 況更新為“使用中”。此外，IMS服務(wù)器50 (IMS處理部51)生成包括所選擇的各CID、及在所述步驟D5和 D7中分別接收到的TEID的、發(fā)給呼出側(cè)的UE 10-1的SIP消息(2000K)，并進(jìn)行發(fā)送(步 驟D9)。該處理與圖8的步驟S6所示的處理相當(dāng)。即，本例的IMS處理部51作為生成以下的信息的生成單元發(fā)揮作用附加到呼出 側(cè)的UE 10-1進(jìn)行報(bào)頭壓縮并發(fā)送到目的地UE 10-2的數(shù)據(jù)中、且識(shí)別是否需要報(bào)頭解壓 縮處理和對目的地UE 10-2的傳送路徑中所使用的信息(CID、TEID)，下層處理部52作為 在設(shè)定UE 10-1和UE10-2之間的通信路(承載)的過程中，將所述生成的信息通知給呼出 側(cè)的UE 10-1的通知單元發(fā)揮作用。通過具有以上所說明的UE 10、eNB 20、Gff 30和IMS服務(wù)器50，能夠?qū)崿F(xiàn)在項(xiàng)目 [2]中所述的動(dòng)作、效果。[4]其他此外，在上述實(shí)施方式中，著眼于在UE 10和GW 30之間有1臺(tái)eNB20的路徑進(jìn) 行了說明，但是關(guān)于有2臺(tái)以上的eNB20的路徑，也與上述的例子同樣地，針對具有特定的 CID (旁路標(biāo)識(shí)符)的分組，能夠不需要出側(cè)eNB20中的報(bào)頭解壓縮處理、和入側(cè)eNB20中的 報(bào)頭解壓縮處理。
權(quán)利要求
一種第1通信終端和第2通信終端經(jīng)由網(wǎng)絡(luò)進(jìn)行通信的通信系統(tǒng)中的通信方法，其特征在于，所述第1通信終端向?qū)Πl(fā)給所述第2通信終端的數(shù)據(jù)報(bào)頭進(jìn)行壓縮得到的壓縮數(shù)據(jù)，附加識(shí)別是否需要報(bào)頭解壓縮處理和通往所述第2通信終端的傳送路徑所使用的信息，并發(fā)送到所述網(wǎng)絡(luò)，作為構(gòu)成所述網(wǎng)絡(luò)的數(shù)據(jù)傳送裝置的、從所述第1通信終端接收到所述壓縮數(shù)據(jù)的裝置根據(jù)所述信息識(shí)別是否需要所述壓縮數(shù)據(jù)的報(bào)頭解壓縮處理和所述傳送路徑，對不需要所述報(bào)頭解壓縮處理的壓縮數(shù)據(jù)不進(jìn)行報(bào)頭解壓縮處理而發(fā)送到所述識(shí)別出的傳送路徑。
2.根據(jù)權(quán)利要求1所述的通信方法，其特征在于，所述信息由第1信息要素和第2信息 要素的組合構(gòu)成，所述第1信息要素為對所述數(shù)據(jù)的報(bào)頭壓縮所使用的上下文進(jìn)行識(shí)別的 上下文識(shí)別信息，且根據(jù)是否需要所述報(bào)頭解壓縮而預(yù)先確定，所述第2信息要素為對所 述數(shù)據(jù)傳送裝置預(yù)先確定的所述傳送路徑的識(shí)別信息。
3.根據(jù)權(quán)利要求2所述的通信方法，其特征在于，所述第1通信終端在發(fā)送所述壓縮數(shù)據(jù)時(shí)，將所述第1信息要素和所述第2信息要素作為在所述報(bào)頭解 壓縮處理所屬的層中處理的信息附加到所述壓縮數(shù)據(jù)中，所述數(shù)據(jù)傳送裝置在將所述壓縮數(shù)據(jù)發(fā)送到所述傳送路徑時(shí)，將所述第2信息要素作為在所述解壓縮處 理所屬的層的下層中處理的信息附加到所述壓縮數(shù)據(jù)中。
4.根據(jù)權(quán)利要求1 3中的任意一項(xiàng)所述的通信方法，其特征在于，從對所述第1通信 終端與所述第2通信終端之間的通信路的設(shè)定進(jìn)行控制的控制裝置通知所述信息。
5.根據(jù)權(quán)利要求4所述的通信方法，其特征在于，所述控制裝置在所述通知中，使用在設(shè)定所述通信路時(shí)收發(fā)的消息。
6.一種經(jīng)由網(wǎng)絡(luò)與另外的通信終端進(jìn)行通信的通信終端，其特征在于具有附加單元，其向?qū)Πl(fā)給所述另外的通信終端的數(shù)據(jù)報(bào)頭進(jìn)行壓縮得到的壓縮數(shù)據(jù)，附 加識(shí)別是否需要報(bào)頭解壓縮處理和通往所述另外的通信終端的傳送路徑所使用的信息；以 及發(fā)送單元，其將附加了所述信息的壓縮數(shù)據(jù)發(fā)送到所述網(wǎng)絡(luò)。
7.一種構(gòu)成第1通信終端和第2通信終端經(jīng)由網(wǎng)絡(luò)進(jìn)行通信的通信系統(tǒng)中的所述網(wǎng)絡(luò) 的數(shù)據(jù)傳送裝置，其特征在于具有接收單元，其從所述第1通信終端接收壓縮數(shù)據(jù)，該壓縮數(shù)據(jù)通過由所述第1通信終端 進(jìn)行報(bào)頭壓縮而得到，并且附加了識(shí)別是否需要報(bào)頭解壓縮處理和通往所述第2通信終端 的傳送路徑所使用的信息；識(shí)別單元，其根據(jù)所述信息，識(shí)別是否需要所述壓縮數(shù)據(jù)的報(bào)頭解壓縮處理和所述傳 送路徑；以及發(fā)送單元，其對由所述識(shí)別單元識(shí)別為不需要所述報(bào)頭解壓縮處理的壓縮數(shù)據(jù)不進(jìn)行報(bào)頭解壓縮處理而發(fā)送到所述識(shí)別出的傳送路徑。
8. 一種對第1通信終端和第2通信終端經(jīng)由網(wǎng)絡(luò)進(jìn)行通信的通信系統(tǒng)中的所述通信進(jìn) 行控制的控制裝置，其特征在于具有生成單元，其生成如下信息附加到所述第1通信終端進(jìn)行報(bào)頭壓縮并發(fā)送給所述第2 通信終端的數(shù)據(jù)中，且在識(shí)別是否需要報(bào)頭解壓縮處理和通往所述第2通信終端的傳送路 徑時(shí)使用；以及通知單元，其在設(shè)定所述通信的通信路的過程中，將所述生成單元所生成的信息通知 給所述第1通信終端。
全文摘要
本發(fā)明提供通信方法及通信終端、數(shù)據(jù)傳送裝置及控制裝置。第1通信終端在對發(fā)給第2通信終端的數(shù)據(jù)報(bào)頭進(jìn)行壓縮得到的壓縮數(shù)據(jù)中，附加識(shí)別是否需要報(bào)頭解壓縮處理和通往第2通信終端的傳送路徑所使用的信息并發(fā)送到網(wǎng)絡(luò)，接收到所述壓縮數(shù)據(jù)的網(wǎng)絡(luò)側(cè)的裝置根據(jù)所述信息識(shí)別是否需要所述壓縮數(shù)據(jù)的報(bào)頭解壓縮處理和所述傳送路徑，對不需要所述報(bào)頭解壓縮處理的壓縮數(shù)據(jù)不進(jìn)行報(bào)頭解壓縮處理而發(fā)送到識(shí)別出的傳送路徑。
文檔編號(hào)H04L12/56GK101843054SQ200780101398
公開日2010年9月22日 申請日期2007年10月31日 優(yōu)先權(quán)日2007年10月31日
發(fā)明者佐藤出 申請人:富士通株式會(huì)社