專利名稱：通信方法及通信終端、數(shù)據(jù)傳送裝置及控制裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信方法及通信終端，數(shù)據(jù)傳送裝置及控制裝置。本發(fā)明例如適合用 于例如以下的通信系統(tǒng)在發(fā)送側(cè)壓縮數(shù)據(jù)(分組)的一部分(報頭)來進行發(fā)送，在接收 側(cè)進行被壓縮的報頭的解壓縮。
背景技術(shù)：
在下述的專利文獻1(日本特開2003-224610號公報)中，公開了涉及報頭壓縮分 組傳送系統(tǒng)及報頭壓縮分組傳送方法的技術(shù)。該技術(shù)的目的如下不進行分組傳送途中的報頭信息的解壓縮/壓縮，在壓縮了 報頭的狀態(tài)下傳送信息，消除解壓縮/壓縮處理，還提高線路使用效率。因此，在該專利文獻1中，記載了如下的技術(shù)在從移動終端對網(wǎng)關(guān)節(jié)點有連接 請求時，在網(wǎng)關(guān)節(jié)點中，根據(jù)該連接請求將移動終端和請求發(fā)送目的地終端的連接路徑信 息關(guān)聯(lián)起來進行存儲，并根據(jù)該存儲信息將之后的報頭壓縮分組傳送到請求發(fā)送目的地終 端。此外，作為與分組通信技術(shù)關(guān)聯(lián)的文獻，有下述的非專利文獻1 7。專利文獻1 日本特開2003-224610號公報非專利文獻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>非專利文獻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>非專利文獻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>非專利文獻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>非專利文獻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>非專利文獻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>非專利文獻7 =IETF RFC 3095、[online]、平成13年7月、[平成19年10月25日 檢索]、4 > 夕一才、7 卜 <URL :http://www. itef. org/rfc/rfc3095. txt>

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


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

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