通信方法及通信终端、数据传送装置及控制装置的制作方法

专利名称：通信方法及通信终端、数据传送装置及控制装置的制作方法
技术领域：
本发明涉及通信方法及通信终端，数据传送装置及控制装置。本发明例如适合用 于例如以下的通信系统在发送侧压缩数据(分组)的一部分(报头)来进行发送，在接收 侧进行被压缩的报头的解压缩。
背景技术：
在下述的专利文献1(日本特开2003-224610号公报)中，公开了涉及报头压缩分 组传送系统及报头压缩分组传送方法的技术。该技术的目的如下不进行分组传送途中的报头信息的解压缩/压缩，在压缩了 报头的状态下传送信息，消除解压缩/压缩处理，还提高线路使用效率。因此，在该专利文献1中，记载了如下的技术在从移动终端对网关节点有连接 请求时，在网关节点中，根据该连接请求将移动终端和请求发送目的地终端的连接路径信 息关联起来进行存储，并根据该存储信息将之后的报头压缩分组传送到请求发送目的地终 端。此外，作为与分组通信技术关联的文献，有下述的非专利文献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>

发明内容
本发明的一个目的在于在网络侧不对报头压缩的数据进行解压缩而削减送出 (传送)到适当的目的地所需的处理量。此外，不限于所述目的，作为本发明的另一目的，能够定得到起到通过用于实施后 述的发明的优选方式所示的各结构引导的、通过现有技术不能得到的作用效果。为了达到上述目的，在本说明书中，公开如下所示的“通信方法及通信终端，数据传送装置及控制装置”。(1) S卩，此处公开的通信方法为第1通信终端和第2通信终端经由网络进行通信的 通信系统中的通信方法，其中，所述第1通信终端向对发给所述第2通信终端的数据报头进 行压缩得到的压缩数据附加识别是否需要报头解压缩处理和通往所述第2通信终端的传 送路径所使用的信息并发送到所述网络，作为构成所述网络的数据传送装置的、从所述第1 通信终端接收到所述压缩数据的装置根据所述信息识别是否需要所述压缩数据的报头解 压缩处理和所述传送路径，对不需要所述报头解压缩处理的压缩数据不进行报头解压缩处 理而发送到所述识别出的传送路径。(2)此处，也可以是所述信息由第1信息要素和第2信息要素的组合构成，所述第 1信息要素为识别所述数据的报头压缩所使用的上下文的上下文识别信息，并根据是否需 要所述报头解压缩来预先确定，所述第2信息要素为对所述数据传送装置预先确定的所述 传送路径的识别信息。(3)此外，也可以是所述第1通信终端在发送所述压缩数据时，将所述第1信息要 素和所述第2信息要素作为在所述报头解压缩处理所属的层中处理的信息附加到所述压 缩数据中，所述数据传送装置在将所述压缩数据发送到所述传送路径时，将所述第2信息 要素作为在所述解压缩处理所属的层的下层中处理的信息附加到所述压缩数据中。(4)此外，也可以是从对所述第1通信终端和所述第2通信终端之间的通信路的设定进行控制的控制装置通知所述信息。(5)此外，也可以是所述控制装置在所述通知中，使用在设定所述通信路时收发的消息。(6)此外，此处公开的通信终端为经由网络与另外的通信终端进行通信的通信终 端，该通信终端具有附加单元，其向对发给所述另外的通信终端的数据报头进行压缩得到 的压缩数据，附加识别是否需要报头解压缩处理和通往所述另外的通信终端的传送路径所 使用的信息；以及发送单元，其将附加了所述信息的压缩数据发送到所述网络。(7)此外，此处公开的数据传送装置为构成第1通信终端和第2通信终端经由网络 进行通信的通信系统中的所述网络的数据传送装置，该数据传送装置具有接收单元，其从 所述第1通信终端接收压缩数据，该压缩数据在所述第1通信终端中进行报头压缩，并且附 加了识别是否需要报头解压缩处理和通往所述第2通信终端的传送路径所使用的信息；识 别单元，其根据所述信息，识别是否需要所述压缩数据的报头解压缩处理和所述传送路径； 以及发送单元，其对由所述识别单元识别为不需要所述报头解压缩处理的压缩数据不进行 报头解压缩处理而发送到所述识别出的传送路径。(8)此外，此处公开的控制装置为对第1通信终端和第2通信终端经由网络进行通信的通信系统中的所述通信进行控制的控制装置，该控制装置具有生成单元，其生成附加 到所述第1通信终端进行报头压缩并发送给所述第2通信终端的、识别是否需要报头解压 缩处理和通往所述第2通信终端的传送路径所使用的信息；以及通知单元，其在设定所述 通信的通信路的过程中，将所述生成单元所生成的信息通知给所述第1通信终端。根据所述公开技术，能够在网络侧对在第1通信终端中进行了报头压缩的数据不 进行解压缩而削减传送到适当的目的地(第2通信终端)所需的处理量。


图1是示出与本发明的一个实施方式关联的SAE (SystemsArchitecture Evolution 系统架构演进)中的系统结构例的图。图2是对SAE承载结构进行说明的图。图3是示出承载建立处理的信令过程的一例的图。图4是对与本发明的一个实施方式关联的ROHC (RObust HeaderCompression 鲁 棒性报头压缩)的报头压缩的一例进行说明的图。图5是对ROHC的概念进行说明的图。图6是对本发明的一个实施方式的分组传送进行说明的图。图7是示出在本实施方式中使用的分组格式例的图。图8是示出本实施方式的无线通信系统的通信过程的一例的图。图9是示出本实施方式的用户终端(UE)的结构(功能)的框图。图10是对图9所示的UE (呼出侧)的连接开始时的动作进行说明的流程图。图11是对图9所示的UE (呼入侧)的连接开始时的动作进行说明的流程图。图12是对图9所示的UE中的报头压缩动作进行说明的流程图。图13是示出本实施方式的无线基站(eNB)的结构(功能)的框图。图14是对图13所示的eNB的连接开始时的动作进行说明的流程图。图15是对图13所示的eNB的上行链路(UL)分组接收时的动作进行说明的流程 图。图16是对图13所示的eNB的下行链路(DL)分组接收时的动作进行说明的流程图。图17是示出本实施方式的网关(GW)的结构(功能)的框图。图18是对图17所示的GW连接开始时的动作进行说明的流程图。图19是对图17所示的GW从外部(因特网等)接收到分组时的动作进行说明的 流程图。图20是对图17所示的GW接收到发给外部(因特网等)的分组时的动作进行说 明的流程图。图21是对图17所示的GW接收到隧道分组时的动作进行说明的流程图。图22是示出本实施方式的IMS(IP Multimedia Subsytem =IP多媒体子系统)服务器的结构(功能)的框图。图23是对图22所示的IMS服务器的连接开始时的动作进行说明的流程图。标号说明
10、10-1、10-2 用户终端(UE) ；11 承载管理部；12 :IMS处理部；13 上层处理部； 14 =ROHC处理部；141 过滤数据(列表)；142 上下文数据；15 下层处理部；16 应用部； 20,20-1,20-2 无线基站(eNB) ；21 承载管理部；22 信号处理部；23 上层处理部；24 ROHC处理部；241 过滤数据(列表)；242.242a.242b 上下文数据；25 下层处理部；251 TEID-RBID对应表；30 =Gff ；31 承载管理部；32 信号处理部；33 上层处理部；331 过滤数 据(列表)；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 下 层处理部。
具体实施方式
以下，参照

本发明的实施方式。但是，以下说明的实施方式只不过一个例 子，而并不排除以下没有明确记载的技术。本发明不限于以下所示的实施方式，在不脱离本 发明的主旨范围内当然能够进行各种变形来实施。[1]与本实施方式关联的技术(1. 1) 3GPP SAE/LTE 中的承载结构在3GPP中，研究了能够容纳已有的各种无线接入方式(接入网)，能够进行核心网 的完全IP化(All IP)的下一代系统(Release 8)。在所述的非专利文献1 (3GPP TR 23.882 VI. 10.0)、非专利文献2 (3GPP TS23.401 VI. 0. 0)中说明了该内容。此处所研究的下一代 体系结构被称作SAE (Systems Architecture Evolution 系统架构演进)。此外，SAE中的 无线技术被称作LTE (Long Term Evolution 长期演进)。在图1中示出SAE中的系统结构例。如该图1所示，SAE例如被定义为具有用 户终端(UE) 10、作为无线基站的 eNodeB(eNB)20、MME(Mobility Management Entity 移 动管理实体)30-1、S-GW(ServingGateway 服务网关)30_2、PDN-Gff 30-3, PCRF(Policy and ChargingRules Function 策略和计费规则功能)40 和 CSCF(Call Session ControlFunction 呼叫会话控制功能)50的系统。UE 10具有无线接口，在eNB 20的服务区域内通过无线链路与该eNB 20连接，经 由该eNB 20与其他UE 10和服务器装置等进行通信。在无线链路中，包括从UE 10到eNB 20的方向的上行链路(UL)、和其相反方向的下行链路(DL)。此外，在UE 10中，包括便携 电话、PDA或笔记本型PC等。此外，UE 10也可以是通过有线接口与eNB 20连接的通信终端。eNB 20是端接与UE 10之间的无线接口的实体(节点)，进行来自UE 10的无 线分组的接收、发给UE 10的无线分组的发送。此外，eNB 20与综合了 UTRAN(Universal Terrestrial Radio Access Network 通用陆地无线接入网)中的无线基站(BS)和 RNC(Radio Network Controller 无线网络控制器)的功能的一部分的实体相当。MME 30-1对UE 10的位置(移动性)进行管理，是进行承载管理、 NAS (Non-Access-Stratum 非接入层)信令等的实体(逻辑节点)。S-Gff 30-2是成为对下一代体系结构的无线接入网络的E-UTRAN (Evolved Universal Terrestrial Radio Access Network 演进的通用陆地无线接入网)的接口的 实体,在与E-UTRAN内的eNB 20之间收发用户分组。此外，S-GW 30-2与GPRS (GeneralPacket Radio Service 通用分组无线服务)中的称作SGSN(Serving GPRS Support Node 服务GPRS支持节点)的实体大致相当。关于E-UTRAN，在所述的非专利文献3(3GPP TS 36. 300 VI. 0. 0)中有记载。 PDN-Gff 30-3 是端接到 PDN(Packet Data Network 分组数据网络)的接口的 网关(gateway)节点。PDN可以是因特网、运营商内的网络、私有分组数据网络、运营商 间的分组数据网络(IMS服务提供用等)的任意一个。此外，PDN-GW 30-3与GPRS中的 称作GGSN (GatewayGPRS Support Node 网关GPRS支持节点)的实体大致相当。关于 IMS(IP Multimedia Subsytem IP多媒体子系统)，在所述的非专利文献4 (3GPP TS 23.228 V8. 1.0)中有定义。
PCRF 40为根据来自CSCF 50的请求，管理并控制承载的QoS (Quality of Service 服务质量)等的各种策略和计费的实体(逻辑节点)。CSCF 50为管理并控制IMS中的会话(承载)的实体(逻辑节点)。其中，CSCF 50不直接控制PDN-GW 30-3，而经由所述PCRF 40进行承载的设定(建立)。CSCF 50实现 为例如构成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内的通信装置(PDN-GW 30-3)之间的区间中定义SAE中的承载 (SAE承载)。通信对方将定义了 QoS等的数据传送路径称作“承载”。此外，例如如图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) 在这些接口中，使用了各 个独立的协议的组合。例如，在无线承载上送出的数据使用无线协议上和上位的数据传送协议的组合来 发送，该承载用无线承载标识符(RBID)来识别。在Sl承载中，在数据传送中能够使用GPRS (General Packet RadioService 通 用分组无线服务)隧道协议(GTP)。此外，关于GTP，在所述非专利文献5(3GPP TS 29.060 V7. 5. 1)中有定义。能够将识别用GTP接收的端点的隧道端点标识符(Tunnel Endpoint Identifier =TEID)用作承载标识符。此外，关于TEID，在非专利文献5的第6章中有记载。 S5承载也同样地，能够用TEID识别承载。此外，如图2所示，针对1个SAE承载逐一使用1个无线承载、Sl承载、S5承载，在 各节点(实体)中1对1对应。由此，例如在eNB 20从S-GW 30_2接收分组，并将该分组发送到无线链路的情况 下，参照接收分组的TEID，以该TEID为关键字，根据图2所示的对应关系，可知向接收分组 附加哪个RBID为好。此外，在建立SAE承载中，需要建立各接口中的承载。承载建立能够从UE 10起动，还能够从网络侧的实体起动。在后者的情况下，为了在UE 10之间进行通话(VoIP服务)等而需要承载的建立时，按以下的步骤建立承载。(1)呼出侧的UE 10-1向IMS服务器(CSCF) 50发送请求承载的建立的 SIP (Session Initiation Protocol 会话初始化协议)消息(INVITE)。在该 INVITE 消息 中，包括确定目的地的UE 10-2的信息(IP地址)。(2) IMS服务器50根据所述IP地址向目的地的UE 10-2发送SIP消息(INVITE)。(3) UE 10-2接收所述SIP (INVITE)消息，当了解(响应)时，将表示该意思的响应 消息(2000K)发送给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的顺序发送请求承载建立的消息(步 骤S41 S43、S48 S50)，将对此响应消息从UE 10-1和10_2按照eNB 20-1和20_2、Gff 30、IMS服务器50的顺序进行发送(步骤S44 S47、S51 S52)，由此完成UE 10-1和UE 10-2之间的承载建立。在图3所示的例子中，示出了以下的情况作为请求承载建立的消息，发送PCC确 定通知(Policy and Charging Control decision propositon 策略和计费控制确定通 知)、专用承载建立请求(Create Dedicated BearerRequest)、无线承载设置请求(Radio Bearer Setup Request)，作为对各个消息的响应，发送无线承载设置响应(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为连接有呼出侧的UE 10-1的eNB，eNB 20-2为连接有目的地(呼入侧)的UE 10-2的eNB。“连接有”是指建立了承载的状态。在以后的说明中，在不区别UE 10-1和UE 10_2的情况下，简记为“UE 10”，同样 地，在不区别eNB 20-1和eNB 20_2的情况下，简记为“eNB 20”。此外，有时将连接有呼出 侧的UE 10-1的eNB 20-1表记为出侧eNB 20_1，将连接有呼入侧的UE 10-2的eNB 20-2 表记为入侧eNB 20-2。此外，当着眼于反方向的通信时，呼出侧和呼入侧的例子变成与上述 例子相反的关系。此外，除了 UE 10和CSCF (IMS服务器)50外的各实体能够定位为包括无线接入网 和核心网的一部分或全部的网络的结构要素(实体)。此外，eNB 20和GW 30均能够定位 为在该网络中传送数据(分组)的数据(分组)传送装置，IMS服务器50能够定位为管理、 控制该网络中的通信(会话、承载)的控制装置。(1.2)报头压缩技术在便携电话网中，有效使用无线区间的资源非常重要。因此，在UElO和eNB 20之 间的分组通信中，使用被称作R0HC0LE_LINK1 (RobustHeader Compression 鲁棒性报头压 缩)0LE_LINK1的报头压缩技术非常有效。在ROHC 中，对 PDCP (Packet Data Convergence Protocol 分组数据集中协议)分组的有效载荷中所容纳的用户数据(IP分组)的报头进行动态压缩。例如，在用户数据 为RTP(Real Time Protocol 实时协议)分组的情况下，如图4所示，IP报头、UDP(User Datagram Protocol 用户数据报协议)报头、RTP报头成为压缩对象。此外，在图4所示的 例子中，示出了通过ROHC将RTP/UDP/IP报头置换成ROHC报头的情况。关于PDCP，在所述的非专利文献6 (3GPP TS 25. 323 V7. 4. 0)中存在有定义，关于报头压缩，在该文献6的第5. 1章中有记述。此外，关于R0HC，在所述的非专利文献7 (IETF RFC 3095)中有定义。在ROHC的协议中，规定了称作上下文标识符(CID)的标识符，能够在1个通信路
中管理多个流程。图5示出ROHC的概念图。如该图5所示，压缩分组报头并进行发送的一侧(压缩 侧)用被称作上下文的与压缩相关的内部状态的数据管理流程(分组的目的地)、分组报头 中的字段值等。接收侧(解压缩侧)也同样管理上下文。发送侧(压缩侧)按照该每个上下文分配CID，并附加到报头压缩完成的分组(以 下，还称作压缩分组或ROHC分组)进行发送。接收侧(解压缩侧)根据附加到所接收的压 缩分组的CID，能够识别使用哪个上下文进行解压缩处理为好。[2] 一个实施方式(2. 1)整体动作概要在以下说明的实施方式中，在所述SAE中UE 10-1和UE 10_2进行通信(例如VoIP 通信)的情况下，能够进行图6所示的动作(分组传送)。其中，将UE 10-1(第1通信终 端)假定为呼出侧，将UE 10-2(第2通信终端)假定为呼入侧。(1)呼出侧的UE 10-1在对eNB 20或GW 30等的网络侧的实体(以下，还称作网 络实体)中的省略(绕过)解压缩和压缩处理的流程的压缩分组(R0HC分组)进行发送 时，对该压缩分组附加表示不需要(可省略)解压缩处理的信息(旁路标识符；第1信息要 素)来进行发送(参照图6的符号B)。所述旁路标识符优选定义(设定)为能够如后所述使用的多个CID中的特定(范 围)的CID。如果这样，则没有必要使用与CID不同的标识符。期望以在网络实体(eNB 20、 GW 30等)之间传送的流之间不进行重复的方式进行该设定。此外，作为旁路标识符的CID能够从网络实体(例如IMS服务器50)进行分配(指 定)。该分配的定时至少在UE 10-1开始压缩分组的发送前即可。优选例如在UE 10-1的应用程序(VoIP的通信应用程序等)开始连接处理而IMS 服务器50实施承载建立处理的过程中从IMS服务器50向UE 10-1进行指示(参照图6的 符号A)。此时，优选利用在承载建立处理中使用的消息。如果这样，则不会增大消息数量、 处理量、通信开始之前的时间。(2)连接有呼出侧的UE 10-1的网络实体(eNB 20-1)通过判定从UE 10_1接收到 的压缩分组的CID是否为特定的CID (旁路标识符)，来判定是否需要报头解压缩处理。此 外，“连接有”是指建立了承载的状态。其结果，如果不需要报头解压缩处理，则该网络实体(eNB 20_1)对所述压缩分组 不进行报头解压缩而进行封装(附加隧道用的GTP报头)，并传送(隧道)到连接有目的地 UE 10-2的网络实体(eNB 20_2)(参照图6的符号C、D)。此外，在图6中，示出了送出到隧道路径的分组(以下也称作隧道分组)用GW 30返回到UE 10-2的情况，但是如果能够设 定隧道路径，则也可以不进行这种返回。在隧道分组中，优选附加连接有目的地UE 10-2的网络实体(eNB20_2)能够确定 (识别)该目的地UE 10-2的信息。如果这样，则接收到隧道分组的网络实体(eNB 20-2) 能够确定目的地UE 10-2，而不对其他装置进行询问等。例如，能够使用识别从eNB 20_2到 目的地UE 10-2的DL的无线承载的RBID、或与该RBID相关联的信息(DL的TEID)。(3)接收到隧道分组的网络实体(eNB 20-2)对该分组进行封装(去除GTP报头)来取出压缩数据，并发送到目的地UE 10-2。此外，在目的地UE 10-2不支持ROHC的协议的情况下，按照在3GPP中规定的动 作那样，在eNB 20-1中对压缩分组进行解压缩，并将解压缩后的IP分组发送到目的地UE 10-2。在以上的从呼出侧UE 10-1到达目的地UE 10-2的过程(分组发送过程)中，在 本实施方式中，例如如图7所示，使用多种分组格式。Bp, UE 10-1在将分组发送到支持ROHC协议的UE 10_2时，通过ROHC处理栈，依 照ROHC协议压缩分组报头。此时，使用在连接开始时作为从网络侧(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分组的有效载荷，优选附加到ROHC分组的末尾。 如果这样，能够使接收该分组的eNB 20-1的协议处理栈中的、从已有的分组格式脱离的部 分停留在ROHC (PDCP)处理栈中。S卩，呼出侧的UE 10-1在发送压缩数据时，将作为第1信息要素的CID、和作为第2 信息要素的TEID，作为在ROHC协议(报头解压缩处理)所属的层(PDCP层)中处理的信息 (PDCP有效载荷)附加到所述压缩数据中。此外，所述CID和TEID分别从IMS服务器50事先对呼出侧的UE10-1进行指示 (通知)。例如，在目的地UE 10-2支持ROHC协议的情况下，IMS服务器50针对呼出侧的 UE 10-1，从预先确定的范围内，选择CID和连接有目的地UE 10-2的eNB 20_2与GW 30之 间的承载的TEID并进行发送。关于其详细情况，将通过图8后述。如图7(1)所示，呼出侧的UE 10-1通过PDCP及RLC的处理栈，将这些ROHC分组 和TEID存储到PDCP分组的有效载荷中，附加PDCP报头及RLC(Radic) Link Control 无线 链路控制)报头并发送到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处理栈)根据该CID，参照eNB 20-1所保有、管理的对应表(上下 文数据)，判定所接收的ROHC分组是否为应该省略(绕过)解压缩处理的分组。在CID示出了应该省略解压缩处理的情况下，eNB 20-1的ROHC处理栈根据所述 CID，参照eNB 20-1所保有、管理的对应表(上下文数据)，确定传送目的地(对eNB 20-2的GTP隧道)。此外，eNB 20-1从PDCP有效载荷的末尾读出所述TEID，将该TEID重新配置到PDCP分组之前，再附加(封装)包括表示发给eNB 20-2的GTP隧道的信息的报头(GTP报 头)来发送到GW 30(参照图7(2))。即，作为数据传送装置的eNB 20在将压缩数据发送到隧道路径时，将作为第2信 息要素的TEID作为在ROHC协议(报头解压缩处理)所属的层(PDCP层)的下位层中处理 的信息(GTP有效载荷)附加到所述压缩数据中。此外，由此关于重新配置TEID的理由将 后述。在GW 30中，通过GTP处理栈，依照其GTP报头的内容将从ΘΝΒ20-1接收到的GTP 分组(隧道分组)传送到eNB 20-2(参照图7(3))。此外，设为将关于隧道路径的信息预先 登记在GW 30中。详细情况将后述。此外，在存在能够直接从eNB 20_1传送到eNB 20-2 的路径的情况下，还能够不经由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处理栈，根据eNB 20-2所保有、管理 的对应表，确定与所述读出的TEID对应的RBID，通过RLC处理栈生成发给将该RBID包括在 RLC报头中的UE 10-2的RLC分组并发送到UE 10_2 (参照图7 (4))。UE 10-2通过RLC处理栈端接从eNB 20_2接收到的RLC分组的RLC报头并取出 PDCP分组，通过PDCP处理栈端接PDCP报头并取出ROHC分组，通过ROHC处理栈对ROHC分 组进行解压缩，并将还原的分组传递到UE 10-2的应用层。此外，作为旁路标识符，除了使用CID以外，还能够使用下位协议的标识符，例如 发送侧RBID等。此时，呼出侧的UE 10-1自由选择ROHC的CID。但是，此时，在ROHC的压 缩分组从目的地侧的eNB 20-2送出到目的地UE 10_2时，需要保证与在承载中复用的其他 流的关系中不附加相同的CID。因此，需要在RBID和CID两者中预约标识符的范围，可以说 没有效率。由此，可以说如上所述将上层的标识符即CID用作旁路标识符的做法是优选的。此外，为了使目的地侧的eNB 20_2发现(识别)传送接收分组的UE 10_2，除了使 用TEID以外，还能够使用目的地UE 10-2侧的RBID。此时，存在能够采取不使用Sl接口的 上位的承载的方式的优点。但是，此时，在eNB 20-2中必须进行与现有的处理不同的处理。 此外，在承载设定步骤中需要变更。与此相对，在如上所述使用TEID的情况下，目的地侧的eNB 20-2能够对在呼出侧 的eNB 20-1中实施解压缩处理而传送的隧道分组、和不实施解压缩处理而传送的非隧道 分组实施相同的处理来确定目的地UE 10-2。S卩，目的地侧的eNB 20-2在从GW 30接收到分组的情况下，能够与该分组是否为 隧道分组无关地，根据附加到该分组的TEID识别对目的地UE 10-2的承载，附加与所识别 的承载对应的RBID来发送到目的地UE 10-2的无线链路。此外，在该处理期间，eNB 20-2 能够进行依照承载的QoS将分组放入到等待矩阵等的、每个承载的处理。换言之，通过使用TEID，eNB 20-2能够用与从S_GW 30-2经由Sl接口接收到分组 时相同的处理来处理接收分组。因此，可以说从简单进行eNB 20-2中的处理的观点出发， 优选在隧道分组中附加TEID。
(2. 2)承载设定(建立)序列接着，关于从网络侧(IMS服务器50)对呼出侧的UE 10_1进行指示(指定)的例子说明在所述分组发送过程中使用的CID、TEID。在本例中，在呼出侧的UE 10-1开始对目的地UE 10_2的连接处理时，经由IMS服 务器50在呼出侧的UE 10-1和目的地(呼入侧)的UE 10-2之间(端点与端点之间)使 用为了承载建立处理(承载设置)而收发的消息，将CID、TEID通知给呼出侧的UE 10-1。例如如图8所示，在UE 10-1开始向UE 10-2进行连接的情况下，UE 10-1向IMS 服务器(CSCF) 50发送SIP的INVITE消息(步骤Si)。IMS服务器50在接收该INVITE消息时，根据包括在该消息中的目的地IP地址，向 目的地UE 10-2发送INVITE消息(步骤S2)。UE 10-2在从IMS服务器50接收所述INVITE消息，并对来自UE 10-1的呼叫进行 响应时，将表示呼叫成功的意思的响应消息(2000K)回送到IMS服务器50 (步骤S3)。此 外，“200”表示消息的状态代码(响应代码)，另外，还具有表示发送处理中(Trying)的代 码(100)、和表示呼叫中(ringing)的代码(180)等。但是，在图8中，省略了这些过程的图
7J\ οIMS服务器50在从目的地UE 10-2接收所述响应消息(2000K)时，执行图3所示 的承载建立过程，建立呼出侧的UE 10-1和呼入侧的UE 10-2之间的会话(承载)(步骤 S4)。在本例中，使用在该承载建立处理的过程中收发的各响应消息 (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用(关于从UE 10-1到UE 10-2 的方向)的CID、和UE 10-2用(关于反方向)的CID。此时，UE 10-1用的CID在对连接有作为通信对方的UE 10-2的eNB 20-2分配的 范围内进行选择，UE 10-2用的CID在对连接有作为通信对方的UE 10-1的eNB 20-1分配 的范围内进行选择。其详细情况将后述。IMS服务器50用SIP的响应消息(2000K)将所确定的UE 10-1、10-2用的CID、 TEID传递到呼出侧的UE 10-1 (步骤S6)。UE 10_1用SIP的ACK消息将UE 10_2用的CID、 TEID传递到目的地UE 10-2 (步骤S7)。此时，这些参数(CID、TEID)例如能够通过SDP(Session DescriptionProtocol 会话描述协议)，作为属性(a = peer-dl-teid :XXX等)记述到SIP消息的有效载荷中，由 此分别传递到UE 10-1、10-2。UE 10-1、10-2分别根据如上所述所指定的TEID和CID进行ROHC处理来开始通 信。即，在着眼于UE 10-1向UE 10-2的方向的通信时，根据图7如前所述，UE 10_1将通 过ROHC进行了报头压缩(以下还简称作“压缩”)的分组发送到eNB 20_1 (步骤S8)，eNB 20-1对所接收的分组不进行报头解压缩(以下还简称作“解压缩”)而使用TEID进行封装并隧道传输到eNB 20-2(步骤39、310)，州8 20_2在对所接收的隧道分组进行解封装后发 送到UE 10-2 (步骤Sll)。(2. 3) CID的选择方法如下确定CID。首先，针对实施所述旁路处理的eNB 20，分别分配不重复的CID的 范围。例如，如果在存在100台eNB 20的区域内实施所述绕过处理，则如下表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管理数据)，并按 照每个eNB 20预先登记、管理可使用的CID的范围。IMS服务器50根据该CID管理表，按 照每个eNB 20，从可使用的CID的范围选择未使用的CID(关于双向通信为1个)并通知到 呼出侧的UE 10。[表2]CID管理表(IMS服务器) 此外，GW 30保有例如如下表3所示的路由表，登记、管理每个隧道路径(TEID)的 目的地(传送目的地)eNB 20的信息(eNBID)。GW30能够根据该路由表，识别与接收分组的TEID对应的传送目的地eNB20，向该传送目的地eNB 20封装接收分组并进行隧道传输。 即，即使为在eNB 20间不能直接传送分组的网络形式，也可以进行适当的分组传送。[表 3]路由表(GW) 此外，如上所述，在eNB 20之间存在能够直接传送的路径的情况下，能够不经由 Gff 30而直接传送分组，因此可以不需要关于该能够直接传送的路径的数据。在以上的状况下，考虑以下的情况UE 10-1与eNB 20_1连接，UE 10_2与eNB 20-2连接(建立了承载)，开始UE 10-1和UE 10-2之间的双向通信(例如，利用VoIP进 行的声音通话)、即开始用户数据(声音数据)分组的收发。IMS服务器50根据所述表2的CID管理表，选择分配到例如入侧eNB 20-2的CID 范围中的未使用的“200”作为UE 10-1附加到压缩分组的CID，选择分配到例如入侧eNB 20-1的CID范围中的未使用的“100”作为UE 10-2附加到压缩分组的CID0IMS服务器50在分别向UE 10-UUE 10_2通知这些CID并进行使用时，接收到UE 10-1发送的压缩分组的eNB 20-1能够根据所述表1，在向eNB 20_2的隧道路径上传送CID =200的压缩分组。同样地，接收到UE 10-2发送的压缩分组的eNB 20_2能够根据所述表 1，在向eNB 20-1的隧道路径上传送CID = 100的压缩分组。通过以上，根据本例的系统，能够得到如下的任意一个效果或优点。(I)UE 10在要压缩分组进行发送时，能够将表示不需要解压缩处理的流程的分组 的信息(作为旁路标识符的一例的CID)附加到该分组。(2)在eNB 20中，能够针对通过某个通信路从UE 10送出的压缩分组，在网络内不 进行解压缩处理而识别送出到目的地UE 10的分组。(3)关于附加了特定的标识符(作为旁路标识符的一例的CID)的压缩分组，省略 了网络侧的装置(eNB 20、GW 30)中的解压缩处理和压缩处理，因此在网络侧能够削减将 分组送出到目的地(UE 10)所需的处理量。(4)在网络侧的装置(实体)之间对压缩分组不进行解压缩而进行传送时，能够进行网络侧的装置之间的隧道传送时的复用。作为以该目的而使用的标识符，能够使用UE 10所附加的标识符(CID)。由此，不需要在网络侧的装置中重新生成并管理标识符。(5)呼出侧的UE 10在连接开始时从IMS服务器50指示作为旁路标识符的一例的 所述CID，因此不需要与网络侧的实体(eNB 20、GW 30)以及目的地UE 10_2进行交涉，而 只附加所指示的CID即可，因此在通信开始之前不会增加所需的处理量。(6)网络侧的实体(eNB 20、GW 30)不依照呼出侧的UE 10_1所附加的CID对接 收分组进行解压缩/压缩而仅进行传送(隧道传输)即可，因此能够不需要每个连接的转 换表那样的动态管理的信息。
(7)连接有目的地UE 10的网络侧的实体(入侧eNB 20)能够从附加到分组的 TEID识别目的地UE 10-2，因此能够将用隧道路径传送来的分组正确发送到适当的目的地 UE 10，而不对其他装置进行询问等。(8)呼出侧的UE 10仅在对目的地UE 10的连接开始时，在ROHC的压缩功能中设 定从网络侧(IMS服务器50)指定的标识符即可，因此能够将UE 10的报头压缩/解压缩处 理功能的变更抑制到最小限度。此外，在所述专利文献1中，GGSN端接ROHC协议，在网关节点(GGSN)中生成接收 侧和发送侧的上下文，并将它们关联起来，由此要减轻GGSN上的ROHC处理的负担。但是， 在专利文献1的方法中，必须为在网络侧的单一装置(GGSN)内对UL和DL的ROHC协议进 行端接的结构。[3]系统结构要素的结构(功能)及动作接着，使用图9 图23对实现上述动作的UE 10,eNB 20,Gff 30、IMS服务器50的 各实体的详细结构(功能)及动作的一例进行详细叙述。(3. 1)UE 的说明图9是示出UE 10的结构例的框图。该图9所示的UE 10具有例如承载管理部 11、IMS处理部12、上层处理部13、ROHC处理部14、下层处理部15以及应用部16。此外，在图9中，虚线箭头A、B、C表示UE 10内的信号传送路径(流)，A表示承 载设定请求时的信号流，B表示到eNB 20的信号流(发送)，C表示来自eNB 20的接收数 据流以及来自UE 10的应用部16的发送数据流。S卩，用A表示的信号流示出了以下情况依次经由下层处理部15、IMS处理部12、 承载管理部11、上层处理部13、ROHC处理部14、下层处理部15，在该过程中针对上层处理 部13、R0HC处理部14、下层处理部15进行与承载设定相应的设定。此外，用B表示的信号 流示出了在IMS处理部12中生成的信令消息在下层处理部15中受到所需的协议处理并发 送到eNB 20。用C表示的数据流示出了经由上层处理部13、R0HC处理部14、下层处理部15 并分别在其中实施必要的协议处理的情况。此处，承载管理部11具有以下功能对与eNB 20之间的DL及UL的承载(无线 承载)进行管理，根据来自应用部16的请求，与IMS处理部12协作，实施承载的建立处理 (消息的生成、收发)。IMS处理部12具有以下功能生成与来自承载管理部11的请求相应的消息 (INVITE、2000K等的ISP消息、用于承载建立处理的消息(无线承载设置响应)等)，将所 生成的消息发送到eNB 20，接收eNB 20所发送的消息等。
上层处理部13在PDCP (ROHC)层的上层中实施规定的处理，具有对例如IP、UDP或 RTP(RTCP)等各种协议的数据进行处理(报头的端接、替换等)的功能(处理栈)。ROHC处理部14具有依据定位为PDCP层的协议栈之一的ROHC协议进行的发送分组的报头压缩及接收分组的报头解压缩功能(R0HC处理栈)。本例的ROHC处理部14将在 图9中示出那样的、识别所述绕过处理是否合适(有效/无效)的过滤数据(列表)141、和 识别在ROHC的压缩处理中使用的上下文的上下文数据142保持在未图示的存储器等中，并 根据这些数据141、142实施报头压缩处理。在过滤数据141中，登记有如上所述从IMS服务器50通知的CID和TEID。在图 1的例子中，示出了以下情况在与确定的目的地(UE 10-2)之间的利用特定的协议(RTP) 的通信中，作为ROHC的CID，使用表示旁路标识符的CID = 201，最先登记了表示应该附加 隧道路径的识别信息(DL_TEID) = “333”的项目。此外，关于其他项目，旁路处理不适合 (FLASE)，DL_TEID也成为未定义。另一方面，在上下文数据142中，除了协议类(UDP/IP、TCP/IP、不压缩、RTP/UDP/ IP等)以外，还登记有在ROHC的压缩处理中使用的CID和序列号(SN)、与压缩相关的内部 状态(状态机)等。由此，ROHC处理部14能够根据该上下文数据142，实施与所述协议相 应的报头压缩处理。下层处理部15负责PDCP层的下层中规定的协议处理。具有对例如RLC层、 MAC(MediaAccess Control 媒体访问控制)层、物理(PHY)层等的各种协议的数据进行处 理(报头的端接、替换等)的功能(处理栈)。应用部16具有利用VoIP进行的声音通信、HTTP、FTP等的数据通信、其他各种应 用程序(软件)，进行与该程序相应的处理(分组的生成、收发等)。(动作说明)以下，使用图10 图12说明如上所述所构成的本例的UE 10的动作。此外，图10 是对UE 10为呼出侧时的连接开始时的动作进行说明的流程图，图11是对UE 10为呼入侧 的连接开始时的动作进行说明的流程图，图12是对报头压缩动作进行说明的流程图。(呼出侧UE的连接开始时的动作)如图10所示，呼出侧的UE 10(10-1)在进行与呼入侧的UE 10(10-2)的通信(例 如利用VoIP进行的声音通话)的情况下，与承载管理部11和IMS处理部12协作，生成SIP 的INVITE消息，通过下层处理部15将该INVITE消息发送给IMS服务器50 (步骤Al)。这 与图8的步骤Sl的处理相当。之后，在呼入侧的UE 10-2针对INVITE消息将响应(2000K)发送到IMS服务器50， IMS服务器50通过开始承载建立处理，从连接有UE 10-1的eNB 20-1接收IMS服务器50 发送的无线承载设置请求(Radio Bearer Setup Request)(参照图3的步骤S43)时(步 骤A2)，UE10-1通过承载管理部11进行无线承载的设定(步骤A3)。接着，UE 10-1通过IMS处理部12，生成对所述无线承载设置请求(Radio Bearer Setup Request)的响应(Radio Bearer Setup Response)，并发送到 eNB 20_1(步骤 A4)。 这与图3的步骤S44的处理相当。之后，在IMS服务器50主导的承载的建立处理完成、从IMS服务器50接收SIP消 息(2000K)时(步骤A5)，UE 10-1通过IMS处理部12，确认在该SIP消息中，是否设定了CID和TEID作为参数(步骤A6)。其结果，如果未设定(如果在步骤A6中为“否”)，则UE 10-1 (IMS处理部12)生 成对所接收的所述SIP消息(2000K)的确认响应(ACK)消息，并通过下层处理部15向呼入 侧的UE 10-2进行发送(步骤A9)。另一方面，如果在所述SIP消息(2000K)中设定了 CID和TEID ( S卩，如果接收到在 图8的步骤S6中记述的SIP消息)，则UE 10-1 (IMS处理部12)经由承载管理部11和上 层处理部13在ROHC处理部14中设定这些参数，作为在ROHC的报头压缩中使用的CID和 TEID (从步骤A6的“是”路线到步骤A7)。接着，UE 10-1 (IMS处理部12)生成将在呼入侧的UE 10_2压缩发送分组时使用 的CID和TEID作为参数包括的SIP的ACK消息，并通过下层处理部15向呼入侧的UE 10-2 进行发送(步骤A8)。这与在图8的步骤S7中所述的处理相当。(呼入侧UE的连接开始时的动作)与此相对，如图11所示，呼入侧的UE 10-2从IMS服务器50接收在图8的步骤 S3中示出的SIP的INVITE消息(步骤All)，如果了解到与呼出侧的UE 10-1的通信开始， 则通过IMS处理部12，生成对该INVITE消息的响应消息(2000K)，并通过下层处理部15向 IMS服务器50进行发送(步骤A12)。这与图8的步骤S3中的处理相当。之后，IMS服务器50通过开始承载建立处理，从连接有UE 10-2的eNB 20-2接收IMS服务器50发送的无线承载设置请求(Radio BearerSetup Request)(参照图3的步骤 S50)时(步骤A13)，通过承载管理部11进行无线承载的设定(步骤A14)。接着，UE 10-2通过IMS处理部12，生成对所述无线承载设置请求(Radio Bearer Setup Request)的响应(Radio Bearer Setup Response)，并发送到 eNB 20_2(步骤A15)。 这与图3的步骤S51的处理相当。之后，UE 10-2在接收到在图8的步骤S7(图10的步骤A8或A9)中示出的、呼出 侧的UE 10-1所发送的SIP的ACK消息时(步骤A16)，通过IMS处理部12，确认在该ACK 消息中，是否设定了本站10-2使用的TEID和CID作为参数(步骤A17)。其结果，如果未设定所述参数，则UE 10-2结束连接开始处理，在与UE 10_1之间 实施不进行已有的绕过处理的通常那样的通信(步骤A17的“否”路线)。另一方面，如果设定了所述参数(即，如果接收到在图8的步骤S7中示出的SIP 消息)，则UE 10-2 (IMS处理部12)经由承载管理部11和上层处理部13在ROHC处理部14 中设定这些参数，作为在ROHC的报头压缩中使用的CID和TEID (从步骤A17的“是”路线 到步骤A18)。(UE的报头压缩动作)如前所述，在针对呼出侧的UE 10-1、呼入侧的UE 10_2各自中的ROHC处理部14 设定所述参数(CID和TEID)时，ROHC处理部14依照图12所示的流程图实施发送分组的 报头压缩处理。S卩，ROHC处理部14在存在发送分组时，参照并检索所述过滤数据141(步骤A21)， 确认是否存在与所设定的CID和TEID相应的项目(步骤A22)。其结果，如果不存在相应项目，则ROHC处理部14根据发送分组的地址、协议，生成 设为APPLY = FALSE、DL_TEID =未定义、CID =未定义的新项目(从步骤A22的“否”路线到步骤A23)。
另一方面，如果存在相应项目，则ROHC处理部14存储该项目的内容(APPLY、DL_ TEID、CID)，作为关于该发送分组的报头压缩处理使用的临时变量(步骤A24)，确认CID是 否定义完成(步骤A25)。其结果，如果为未定义(如果在步骤A25中为“否”)，则ROHC处理部14分配关于 旁路(隧道)对象的分组的CID以外的未使用的CID并存储到过滤列表141中(步骤A26)， 用该CID的上下文进行报头压缩(步骤A27)。另一方面，如果CID为定义完成(如果在步 骤A25中为“是”)，则ROHC处理部14用该CID的上下文进行报头压缩(步骤A27)。此外， 该CID成为ROHC分组的报头信息要素。此外，ROHC处理部14确认所述临时变量“APPLY”是否为“TRUE” (步骤A28)，如果 为“TRUE”(如果在步骤A28中为“是”)，则将DL_TEID附加(连接)到发送分组的末尾(步 骤A29)，从而完成报头压缩处理。另一方面，如果为“FALSE”(如果在步骤28中为“否”)， 则ROHC处理部14结束报头压缩处理。S卩，本例的ROHC处理部14作为以下的附加单元发挥作用在发给目的地UE 10-2 的压缩数据中，附加识别是否需要报头解压缩处理和对目的地UE 10-2的隧道路径中所使 用的信息(CID、TEID)。此外，下层处理部15作为向网络发送附加了所述信息的压缩数据 的发送单元发挥作用。此外，关于接收分组的报头解压缩处理，与现有的处理相同，因此省略说明。(3. l)eNB 的说明图13是示出eNB 20的结构的框图。该图13所示的eNB 20具有例如承载管理部 21、信号处理部22、上层处理部23、ROHC处理部24以及下层处理部25。在该图13中，虚线箭头A E也表示eNB 20内的信号传送路径(流)，A表示承 载设定请求时的信号流，B表示对UE 10或GW 30的信号流，C表示来自其他eNB 20的数据 流，D表示来自GW 30的数据流，E表示来自UE 10的用户数据流。即，用A表示的信号流示出了以下情况依次经由下层处理部25、信号处理部22、 承载管理部21、上层处理部23、ROHC处理部24、下层处理部25，在该过程中能够针对上层 处理部23、R0HC处理部24、下层处理部25进行与承载设定相应的设定。此外，用B表示的 信号流示出了在信号处理部22中生成的信令消息在下层处理部25中受到所需的协议处理 并发送到UE 10或eNB 20的情况。用C表示的数据流示出了从eNB 20接收到的分组依次经由下层处理部25、上层处 理部23、下层处理部25，在各个中实施必要的协议处理并发送到其他eNB 20的情况。用D 表示的数据流表示从GW 30接收到的分组依次经由下层处理部25、上层处理部23、R0HC处 理部24、下层处理部25来进行处理的情况。用E表示的数据流表示从UE 10接收到的分 组依次经由下层处理部25、R0HC处理部24、上层处理部23、下层处理部25来进行处理的情 况。此处，承载管理部21具有以下功能对UE 10侧(DL)及GW 30侧(UL)的承载进 行管理，与信号处理部22协作，实施DL及UL的承载建立处理(消息的生成、收发)。信号处理部22具有以下功能生成与来自承载管理部21的请求相应的消息(发 给UE 10的无线承载设置请求、以发给GW 30的专用承载建立响应等)，将所生成的消息发送到UE 10或GW 30，接收UE 10或GW 30所发送的消息(无线承载设置响应、专用承载建
立请求等)等。上层处理部23实施在PDCP(ROHC)层的上层中规定的处理，具有对例如IP、UDP、RTP(RTCP)等各种协议的数据进行处理(报头的端接、替换等)的功能。该上层处理部23 发挥以下的作用通过下层处理部25将在ROHC处理部24不实施解压缩处理而传送来的接 收分组(隧道分组)传送到GW 30。ROHC处理部24具有利用ROHC进行的发送分组的报头压缩及接收分组的报头解压 缩功能。本例的ROHC处理部24将在图13中示出那样的过滤数据(列表)241和上下文数 据242保持在未图示的存储器等中，并根据这些数据241、242实施ROHC分组的报头压缩、 解压缩处理。此处，过滤列表241是与UE 10中的过滤列表141为相同内容的列表，为用于识别 所述绕过处理是否合适(有效/无效)的数据。其中，在eNB 20中，预先登记有使用绕过 处理的CID、TEID。由此，ROHC处理部24在从UE 10接收到的ROHC分组中，设定了登记在过滤列表 241中的项目的CID、TEID时，对该ROHC分组不进行报头解压缩而传送到上层处理部23。上下文数据242为用于识别ROHC的报头压缩处理中所使用的上下文的数据，如在 图13中所示，具有在各eNB 20中共用的对应表242a、和UE 10的每个承载的对应表242b。对应表242a与已述的表1相当，能够根据附加到接收分组的CID，参照、检索该对 应表242a，由此确定传送(隧道)目的地(连接有呼入侧的UE 10的eNB 20)。另一个对应表242b与UE 10中的上下文数据141为相同内容，除了协议类(UDP/ IP、TCP/IP、不压缩、RTP/UDP/IP等)以外，还按照UElO间的承载单位登记ROHC的压缩处 理中所使用的CID和序列号(SN)、与压缩相关的内部状态(状态机)等。由此，ROHC处理 部24能够根据该对应表242b，按照承载实施与所述协议相应的报头压缩处理。下层处理部25实施在PDCP层的下层中规定的处理，具有对例如RLC层、MAC层、 物理(PHY)层等的各种协议的数据进行处理(报头的端接、替换等)的功能。此外，也可以在能够进行TEID的确定的ROHC处理部24中进行隧道分组的建立 (附加TEID)(即，包括TEID作为PDCP分组的有效载荷)，但是在构成图7(2)所示的格式 (包括TEID作为GTP分组的有效载荷)的情况下，在下层处理部25中进行隧道分组的建 立。此时，将ROHC处理部24所确定的TEID与隧道传输的ROHC分组一起传送到下层 处理部24。此时，在接收到隧道分组的入侧eNB 20-2中，能够通过更下层的处理(下层处 理部25)确定TEID，因此能够提前进行对呼入侧的UE 10-2的分组传送。下层处理部25实施在PDCP层的下层中规定的处理，具有对例如RLC层、MAC层、 物理(PHY)层等的各种协议的数据进行处理(报头的端接、替换等)的功能。此外，如在图 13中所示，该下层处理部25能够将TEID和RBID的对应表(表)251保持在未图示的存储 器等中，根据附加到从GW 30接收到的隧道分组的所述TEID，参照并检索该对应表251，由 此识别应该发送该隧道分组的RBID(即，对呼入侧的UE 10-2的无线(DL)链路)。(动作说明)以下，使用图14 图16说明如上所述所构成的本例的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协作，生成发给UE 10的所述无线承载设置请求(Radio Bearer Setup Request)消息， 并通过下层处理部25发送到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发送到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， 根据该CID，参照并检索过滤列表241 (步骤B12)，确认是否需要解压缩处理(是否为隧道 对象的分组)(步骤B13)。其结果，如果不是不需要解压缩处理的隧道对象的分组(在步骤B13中为“否” 时)，则ROHC处理部24根据上下文数据242的对应表242b，确定在该压缩分组的解压缩中 使用的上下文，并使用所确定的上下文实施分组(压缩分组)的解压缩处理(步骤B14)，通 过下层处理部25作为IP分组向外部(GW 30)进行传送(步骤B15)。另一方面，如果接收分组是不需要解压缩处理的隧道对象的分组(在步骤B13中 为“是”时)，则ROHC处理部24读出附加到该分组的末尾的TEID (步骤B16)，将传送目的 地(隧道ID = eNBID)、所读出的所述TEID存储到对该分组处理使用的临时变量中(步骤 B17)。此外，传送目的地(eNBID)能够从上下文数据242a的对应表242a得到。如果为图 13中的例子，可知应该将CID = 201的分组传送到eNBID = #2所识别的入侧eNB 20_2。接着，ROHC处理部24在压缩分组中附加P⑶P报头并作为PDCP分组与TEID —起， 经由上层处理部23传送到下层处理部25。下层处理部25在传送来的TEID和PDCP分组 中，附加隧道用的GTP报头。在隧道用的GTP报头中，包括例如具有通过TEID识别的Sl接 口的入侧eNB20的地址信息。由此，建立图7 (2)所示的格式的GTP分组(隧道分组)，并发 送到GW 30(步骤附8、819)。该处理与在图8的步骤S9中示出的处理相当。S卩，本例的下层处理部25作为从UE 10-1接收在呼出侧的UE 10_1中附加了特定 的CID和TEID的压缩数据的接收单元发挥作用，ROHC处理部24作为根据所述CID、TEID， 识别是否需要所接收的压缩数据的报头解压缩处理和对目的地UE 10-2的传送路径的识别单元发挥作用。此外，下层处理部25还作为对识别为不需要报头解压缩处理的压缩数据 不进行报头解压缩处理而发送到所述识别的传送路径的发送单元发挥作用。(从GW接收到DL的分组的情况) 如图16所示，eNB 20在上述的承载建立处理完成、在UE 10之间开始通信，并从 Gff 30接收到DL的分组(GTP分组)时，通过下层处理部25，端接并分析GTP报头，从而确 认在该GTP报头中设定的TEID (DL_TEID)是否为隧道用(步骤B20)。S卩，如果GTP报头中的TEID与在已述的承载建立处理时通知并存储的TEID —致， 则接收分组为隧道分组，如果不一致，则判断为通常的(不绕过解压缩处理)的分组。其结果，如果接收分组为隧道分组，则eNB 20 (下层处理部25)根据附加到该GTP 分组的有效载荷的TEID (DL_TEID)，参照并检索TEID-BRID对应表251，确定对目的地UE 10 的RBID (从步骤B20的“是”到步骤B23)。此外，下层处理部25通过去除所述TEID来生成的通常的PDCP分组，并对该PDCP 分组附加包括所述确定的RBID的RLC报头，从而生成图7 (4)所示的格式的RLC分组，并将 其发送到目的地UE 10(步骤B25)。该处理与在图8的步骤Sll中示出的处理相当。另一方面，在从GW 30接收到的DL的分组不是隧道分组的情况下(在步骤B20中 为“否”的情况)，eNB 20 (下层处理部25)根据在接收GTP分组的GTP报头中设定的TEID， 确定对目的地UE 10的RBID (步骤B21)，并将GTP有效载荷(PDCP分组)传送到ROHC处理 部24。ROHC处理部24对于传送来的PDCP分组，分配未使用的CID并实施通常的报头压 缩处理(步骤B22)。所得到的压缩分组经由上层处理部23传送到下层处理部25，通过下 层处理部25建立在RLC报头中包括所确定的所述RBID的RLC分组，并发送到目的地UE 10 (步骤 B25)。(3. 3) GW 的说明图17是示出GW 30的结构的框图。该图17所示的GW 30具有例如承载管理部 31、信号处理部32、上层处理部33以及下层处理部35。在该图17中，虚线箭头A D也表示GW 30内的信号传送路径(流)，A表示承载 设定请求时的信号流，B表示对IMS服务器50或eNB 20的信号流，C表示来自eNB 20的隧 道流，D表示从UE 10到因特网等外部网及从外部网到UE 10的数据流。S卩，用A表示的信号流示出了以下情况依次经由下层处理部34、信号处理部32、 承载管理部31、上层处理部33、下层处理部34，在该过程中能够针对上层处理部23、下层处 理部34进行与承载设定相应的设定。此外，用B表示的信号流示出了在信号处理部32中 生成的信令消息在下层处理部34中受到所需的协议处理并发送到IMS服务器50或eNB20 的情况。用C表示的数据流示出了从eNB 20接收到的隧道分组依次经由下层处理部34、上 层处理部33、下层处理部34，在各个中实施必要的协议处理并发送到其他eNB 20的情况。 用D表示的数据流表示例如接收分组依次经由下层处理部34、上层处理部33、下层处理部 34来进行处理的情况。此处，承载管理部31具有以下功能对与eNB 20 (出侧eNB 20-1和入侧eNB 20-2 双方)之间的承载进行管理，与信号处理部32协作，实施承载建立处理(消息的生成、收发)。
信号处理部32具有以下功能生成与来自承载管理部31的请求相应的消息(发 给eNB 20的专用承载建立请求、发给IMS服务器50的PCC确定通知响应等)，将所生成的 消息发送到eNB 20或IMS服务器50，接收eNB 20或IMS服务器50所发送的消息(专用承 载建立请求、PCC确定通知等)等。上层处理部33实施在PDCP(ROHC)层的上层中规定的处理，具有对例如IP、UDP、 RTP(RTCP)等各种协议的数据进行处理(报头的端接、替换等)的功能。该上层处理部33 将在图17中示出那样的过滤数据(列表)331和路由表332保持在未图示的存储器等中， 并根据这些确定(控制)接收分组的传送目的地。过滤列表331是识别从因特网等外部传送来的分组的传送目的地所使用的数据。 在该过滤列表331中，如在图17所示那样，例如按照每个目的地UE 10，登记识别连接有该 UE 10的eNB 20的信息(eNBID)、和识别对该eNB 20的隧道路径的TEID (DL_TEID)。上层处理部33在对从外部接收到的DL的分组进行处理时，根据该分组的目的地 地址信息，参照该列表331的项目，由此能够识别目的地UE 10与哪个eNB 20连接，为向该 eNB 20传送分组，应该对GTP报头赋予哪个TEID来进行传送。该过滤列表331根据在例如 图8所示的承载建立处理的过程通知的信息登记项目来得到构建。路由表332为在确定从eNB 20接收到的分组的传送目的地(目的地eNB 20)中 使用的数据。在该路由表332中，按照对从eNB 20接收的分组的隧道路径进行识别的每个 信息(隧道ID)，登记目的地eNB 20的信息(例如eNBID)。例如，在图17中所示的例子中，在4个项目中的下面2个项目中，登记有在出侧 eNB 20中绕过报头解压缩处理的分组的传送目的地eNB20的信息(eNBID)。这些隧道传送 的项目例如在网络构建时预先分配，在GW 30的起动时自动设定。剩下的2个项目表示关 于从eNB 20实施报头解压缩处理而传送来的通常的分组的项目。上层处理部33能够根据从eNB 20接收到的分组的TEID，参照并检索该路由表 332的项目，由此识别接收分组的传送目的地(目的地eNB20)。下层处理部34实施在PDCP层的下层中规定的处理，具有对例如物理(PHY)层、以 太网(注册商标)层等的各种协议的数据进行处理(报头的端接、替换等)的功能。例如， 根据在所述上层处理部33中识别的传送目的地的信息进行传送分组的报头替换等。(动作说明)以下，使用图18 图21说明如上所述构成的本例的GW 30的动作。此夕卜，图18 是对GW 30中的连接(呼叫连接)开始时的动作进行说明的流程图，图19是对从外部接收 到分组时的动作进行说明的流程图，图20是对从GW 30接收到应该传送到外部的分组时的 动作进行说明的流程图，图21是对接收到隧道分组时的动作进行说明的流程图。(连接开始时的动作)Gff 30在从IMS服务器50接收到在图3的步骤S41中示出的PCC确定通知(PCC decision proposition)消息时(步骤Cl)，与承载管理部31和信号处理部32协作，生成 发给出侧eNB 20-1的专用承载建立请求(Create Dedicated Bearer Request)消息，并通 过下层处理部34向出侧eNB 20-1进行发送(步骤C2)。这与图3的步骤S42的处理相当。之后，Gff 30 (承载管理部31和信号处理部32)在接收到在图3的步骤S45中示出的响应消息(Radio Bearer Setup Response)时(步骤C3)，读出在该响应消息中设定的 TEID (步骤C4)，并设定与出侧eNB 20-1之间的专用承载(步骤C5)。此外，TEID的读出和 专用承载的设定可以为相反顺序，也可以并行实施。接着，Gff 30 (承载管理部31和信号处理部32)在从IMS服务器50接收到在图3 的步骤S47中示出的PCC确定通知(PCC decisionproposition)消息时(步骤C6)，生成发 给入侧eNB 20-2的专用承载建立请求(Create Dedicated Bearer Request)消息，并通过 下层处理部34向入侧eNB 20-2进行发送(步骤C7)。这与图3的步骤S48的处理相当。
之后，Gff 30 (承载管理部31和信号处理部32)在从入侧eNB 20-2接收到在图3 的步骤S51中示出的专用承载建立响应(Create DedicatedBearer Response)消息时(步 骤C8)，读出在该响应消息中设定的TEID (步骤C9)，并设定与入侧eNB 20-2之间的专用承 载(步骤C10)。此外，此时，TEID的读出和专用承载的设定可以为相反顺序，也可以并行实 施。此外，Gff 30 (承载管理部31和信号处理部32)在对IMS服务器50报告承载设 定完成的PCC确定通知确认(PCC decision PropositionACK)消息中，赋予所述读出的各 TEID (呼出侧及呼入侧)，并将该消息发送到IMS服务器50(步骤Cll)。对该TEID的IMS 服务器50的通知也可以在图3所示的步骤S46及S52中分别关于呼出侧或呼入侧的一个 方向实施。(从外部接收到分组的情况)如图19所示，GW 30在从因特网等外部接收到DL(发给UE 10)的分组时(步骤 C21)，在下层处理部34中进行该接收分组的报头终端处理等后，传送到上层处理部33。上 层处理部33对所传送的接收分组的IP报头进行分析，读取其目的地地址信息，并根据该目 的地地址信息，参照过滤列表331的相应项目，检索并确定连接有目的地UE 10的eNB 20 及DL的TEID (步骤C22)。上层处理部33将接收分组和所确定的所述信息传送到下层处理部34，下层处理 部34生成包括所述确定的信息的GTP报头，附加到接收分组中并发送到通过DL的TEID识 别的隧道路径(步骤C23)。S卩，上层处理部33和下层处理部34将从外部接收到的分组转换(封装)为适于 传送到连接有目的地UE 10的eNB 20的格式，并发送到eNB20。(从eNB接收到应该发送到外部的分组的情况)如图20所示，GW 30在从eNB 20接收到发给因特网等外部的分组时(步骤C31)， 通过下层处理部34和上层处理部33，去除发送到外部时不需要的报头等，读出应该发送到 外部的IP分组(步骤C32)，并将所读出的IP分组发送到外部(步骤C33)。即，上层处理部33和下层处理部34在将从eNB 20接收到的针对外部的分组转换 为适于向外部传送的格式后，将接收分组发送到外部。(接收到隧道分组的情况)如图21所示，GW 30在接收到在出侧eNB 20中绕过报头解压缩处理而通过隧道 路径传送来的分组时(步骤C41)，该分组从下层处理部34传送到上层处理部33，上层处理 部33根据赋予到GTP有效载荷的DL的TEID，参照路由表332检索相应项目，并确定传送目 的地(目的地)eNB 20 (DL的隧道路径)(步骤C42)。
此外，上层处理部33将接收分组(GTP有效载荷)与所确定的信息一起传送到下 层处理部34，下层处理部34在附加了包括表示所述确定的DL的隧道路径(目的地eNB 20) 的信息(eNBID)的报头后发送到所述隧道路径(步骤C43)。即，上层处理部33和下层处理部34在接收到在出侧eNB 20中绕过报头解压缩处 理而传送来的分组时，实施必要的报头替换处理，以将该接收分组传送给赋予到GTP有效 载荷中的TEID所示的隧道目的地，然后进行分组发送。(3. 4) IMS服务器的说明图22是示出IMS服务器50的结构的框图。该图22所示的IMS服务器50具有例 如IMS处理部51和下层处理部52。此外，在该图22中，虚线箭头A示出了 IMS服务器50 内的信号传送路径(流)。即，用A表示的信号流示出了经由下层处理部52和IMS处理部 51，进行SIP消息或承载建立时的消息的收发的情况。此处，IMS处理部51具有例如生成发给UE 10的SIP消息(INVITE消息等)和承 载建立处理时的发给GW 30的消息(PCC确定通知等)的功能、接收UE 10所发送的SIP消 息(2000K消息)和来自Gff 30的响应消息(PCC确定通知确认等)的功能。该IMS处理部51将在图22中示出那样的与已述表2的内容相当的CID管理表 (表)511保持在未图示的存储器等中。CID管理表511如符号511、511b所示，其为用于按照对传送目的地eNB 20的每 个隧道路径(DL_TEID)，对作为不需要在出侧eNB 20中的报头解压缩处理的信息的一例的 CID的使用状况(使用/未使用)进行管理的数据，根据在图3的步骤S4中示出的承载建 立过程中通知的TEID、eNBID来构建。IMS处理部51根据该CID管理表511，以在相同的隧道路径内不重复的方式管理 不需要在出侧eNB 20中的报头解压缩处理的CID，并分配到UE 10。下层处理部52具有将所述SIP消息或在承载建立处理时使用的消息转换为适于 与GW 30之间的接口的格式(协议)的功能等。(动作说明)以下，使用图23说明如上所述构成的本例的IMS服务器50的动作。此外，图23 是对IMS服务器50中的连接(呼叫连接)开始时的动作进行说明的流程图。如图8的步骤Sl所示，IMS服务器50在通过下层处理部52在IMS处理部51中， 从呼出侧的UE 10-1接收到SIP的INVITE消息时(步骤Dl)，根据包括在该INVITE消息 中的目的地信息，确定呼入侧的UE 10-2，并通过下层处理部52，向该UE 10_2发送SIP的 INVITE消息(步骤D2)。该处理与图8的步骤S2所示的处理相当。之后，IMS服务器50 (IMS处理部51)在从呼入侧的UE 10-2接收到对所述INVITE 消息的响应消息(2000K)时(步骤D3)，生成请求呼出侧的UE 10-1和GW 30之间的承载建 立的消息(PCC确定通知)，并发送到GW 30 (步骤D4)。该处理与图3的步骤S41所示的处 理相当。如图3的步骤S46所示，IMS服务器50在接收到对该消息的响应消息(PCC确定 通知确认)时，提取在该响应消息中设定的DL的TEID (步骤D5)。此外，IMS服务器50生成请求呼入侧UE 10-2和GW 30之间的承载建立的消息 (PCC确定通知)，并发送到GW 30(步骤D6)。该处理与图3的步骤S47所示的处理相当。
如图3的步骤S52所示，IMS服务器50在接收到对该消息的响应消息(PCC确定 通知确认)时，提取在该响应消息中设定的DL的TEID (步骤D7)。此外，也可以并行实施呼出侧UE 10-1和GW 30之间的承载建立请求、以及呼入侧UE 10-2和GW 30之间的承载建立请求。之后，IMS服务器50 (IMS处理部51)从所述CID管理表511 (511a、511b)中的未 使用的CID中选择呼出侧的UE 10-1及呼入侧的UE 10-2各自在ROHC的报头中应该使用 的CID (步骤D8)。此外，IMS处理部51将所选择的CID在所述CID管理表511中的使用状 况更新为“使用中”。此外，IMS服务器50 (IMS处理部51)生成包括所选择的各CID、及在所述步骤D5和 D7中分别接收到的TEID的、发给呼出侧的UE 10-1的SIP消息(2000K)，并进行发送(步 骤D9)。该处理与图8的步骤S6所示的处理相当。即，本例的IMS处理部51作为生成以下的信息的生成单元发挥作用附加到呼出 侧的UE 10-1进行报头压缩并发送到目的地UE 10-2的数据中、且识别是否需要报头解压 缩处理和对目的地UE 10-2的传送路径中所使用的信息(CID、TEID)，下层处理部52作为 在设定UE 10-1和UE10-2之间的通信路(承载)的过程中，将所述生成的信息通知给呼出 侧的UE 10-1的通知单元发挥作用。通过具有以上所说明的UE 10、eNB 20、Gff 30和IMS服务器50，能够实现在项目 [2]中所述的动作、效果。[4]其他此外，在上述实施方式中，着眼于在UE 10和GW 30之间有1台eNB20的路径进 行了说明，但是关于有2台以上的eNB20的路径，也与上述的例子同样地，针对具有特定的 CID (旁路标识符)的分组，能够不需要出侧eNB20中的报头解压缩处理、和入侧eNB20中的 报头解压缩处理。
权利要求
一种第1通信终端和第2通信终端经由网络进行通信的通信系统中的通信方法，其特征在于，所述第1通信终端向对发给所述第2通信终端的数据报头进行压缩得到的压缩数据，附加识别是否需要报头解压缩处理和通往所述第2通信终端的传送路径所使用的信息，并发送到所述网络，作为构成所述网络的数据传送装置的、从所述第1通信终端接收到所述压缩数据的装置根据所述信息识别是否需要所述压缩数据的报头解压缩处理和所述传送路径，对不需要所述报头解压缩处理的压缩数据不进行报头解压缩处理而发送到所述识别出的传送路径。
2.根据权利要求1所述的通信方法，其特征在于，所述信息由第1信息要素和第2信息 要素的组合构成，所述第1信息要素为对所述数据的报头压缩所使用的上下文进行识别的 上下文识别信息，且根据是否需要所述报头解压缩而预先确定，所述第2信息要素为对所 述数据传送装置预先确定的所述传送路径的识别信息。
3.根据权利要求2所述的通信方法，其特征在于，所述第1通信终端在发送所述压缩数据时，将所述第1信息要素和所述第2信息要素作为在所述报头解 压缩处理所属的层中处理的信息附加到所述压缩数据中，所述数据传送装置在将所述压缩数据发送到所述传送路径时，将所述第2信息要素作为在所述解压缩处 理所属的层的下层中处理的信息附加到所述压缩数据中。
4.根据权利要求1 3中的任意一项所述的通信方法，其特征在于，从对所述第1通信 终端与所述第2通信终端之间的通信路的设定进行控制的控制装置通知所述信息。
5.根据权利要求4所述的通信方法，其特征在于，所述控制装置在所述通知中，使用在设定所述通信路时收发的消息。
6.一种经由网络与另外的通信终端进行通信的通信终端，其特征在于具有附加单元，其向对发给所述另外的通信终端的数据报头进行压缩得到的压缩数据，附 加识别是否需要报头解压缩处理和通往所述另外的通信终端的传送路径所使用的信息；以 及发送单元，其将附加了所述信息的压缩数据发送到所述网络。
7.一种构成第1通信终端和第2通信终端经由网络进行通信的通信系统中的所述网络 的数据传送装置，其特征在于具有接收单元，其从所述第1通信终端接收压缩数据，该压缩数据通过由所述第1通信终端 进行报头压缩而得到，并且附加了识别是否需要报头解压缩处理和通往所述第2通信终端 的传送路径所使用的信息；识别单元，其根据所述信息，识别是否需要所述压缩数据的报头解压缩处理和所述传 送路径；以及发送单元，其对由所述识别单元识别为不需要所述报头解压缩处理的压缩数据不进行报头解压缩处理而发送到所述识别出的传送路径。
8. 一种对第1通信终端和第2通信终端经由网络进行通信的通信系统中的所述通信进 行控制的控制装置，其特征在于具有生成单元，其生成如下信息附加到所述第1通信终端进行报头压缩并发送给所述第2 通信终端的数据中，且在识别是否需要报头解压缩处理和通往所述第2通信终端的传送路 径时使用；以及通知单元，其在设定所述通信的通信路的过程中，将所述生成单元所生成的信息通知 给所述第1通信终端。
全文摘要
本发明提供通信方法及通信终端、数据传送装置及控制装置。第1通信终端在对发给第2通信终端的数据报头进行压缩得到的压缩数据中，附加识别是否需要报头解压缩处理和通往第2通信终端的传送路径所使用的信息并发送到网络，接收到所述压缩数据的网络侧的装置根据所述信息识别是否需要所述压缩数据的报头解压缩处理和所述传送路径，对不需要所述报头解压缩处理的压缩数据不进行报头解压缩处理而发送到识别出的传送路径。
文档编号H04L12/56GK101843054SQ200780101398
公开日2010年9月22日 申请日期2007年10月31日 优先权日2007年10月31日
发明者佐藤出 申请人:富士通株式会社