CN101843054A - 通信方法及通信终端、数据传送装置及控制装置 - Google Patents

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

Info

Publication number
CN101843054A
CN101843054A CN200780101398A CN200780101398A CN101843054A CN 101843054 A CN101843054 A CN 101843054A CN 200780101398 A CN200780101398 A CN 200780101398A CN 200780101398 A CN200780101398 A CN 200780101398A CN 101843054 A CN101843054 A CN 101843054A
Authority
CN
China
Prior art keywords
communication terminal
enb
header
information
handling part
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200780101398A
Other languages
English (en)
Other versions
CN101843054B (zh
Inventor
佐藤出
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of CN101843054A publication Critical patent/CN101843054A/zh
Application granted granted Critical
Publication of CN101843054B publication Critical patent/CN101843054B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

本发明提供通信方法及通信终端、数据传送装置及控制装置。第1通信终端在对发给第2通信终端的数据报头进行压缩得到的压缩数据中，附加识别是否需要报头解压缩处理和通往第2通信终端的传送路径所使用的信息并发送到网络，接收到所述压缩数据的网络侧的装置根据所述信息识别是否需要所述压缩数据的报头解压缩处理和所述传送路径，对不需要所述报头解压缩处理的压缩数据不进行报头解压缩处理而发送到识别出的传送路径。

Description

通信方法及通信终端、数据传送装置及控制装置
技术领域
本发明涉及通信方法及通信终端，数据传送装置及控制装置。本发明例如适合用于例如以下的通信系统：在发送侧压缩数据(分组)的一部分(报头)来进行发送，在接收侧进行被压缩的报头的解压缩。
背景技术
在下述的专利文献1(日本特开2003-224610号公报)中，公开了涉及报头压缩分组传送系统及报头压缩分组传送方法的技术。
该技术的目的如下：不进行分组传送途中的报头信息的解压缩/压缩，在压缩了报头的状态下传送信息，消除解压缩/压缩处理，还提高线路使用效率。
因此，在该专利文献1中，记载了如下的技术：在从移动终端对网关节点有连接请求时，在网关节点中，根据该连接请求将移动终端和请求发送目的地终端的连接路径信息关联起来进行存储，并根据该存储信息将之后的报头压缩分组传送到请求发送目的地终端。
此外，作为与分组通信技术关联的文献，有下述的非专利文献1～7。
专利文献1：日本特开2003-224610号公报
非专利文献1：3GPP TR 23.882 V1.10.0、[online]、平成19年9月27日、[平成19年10月25日检索]、インタ一ネツト<URL：http://www.3gpp.org/ftp/Specs/html-info/23882.htm>
非专利文献2：3GPP TS 23.401 V1.0.0、[online]、平成19年6月13日、[平成19年10月25日检索]、インタ一ネツト<URL：http://www.3gpp.org/ftp/Specs/html-info/23401.htm>
非专利文献3：3GPP TS 36.300 V1.0.0、[online]、平成19年3月19日、[平成19年10月25日检索]、インタ一ネツト<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日检索]、インタ一ネツト<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日检索]、インタ一ネツト<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日检索]、インタ一ネツト<URL：http://www.3gpp.org/ftp/Specs/html-info/25323.htm>
非专利文献7：IETF RFC 3095、[online]、平成13年7月、[平成19年10月25日检索]、インタ一ネツト<URL：http://www.itef.org/rfc/rfc3095.txt>
发明内容
本发明的一个目的在于在网络侧不对报头压缩的数据进行解压缩而削减送出(传送)到适当的目的地所需的处理量。
此外，不限于所述目的，作为本发明的另一目的，能够定得到起到通过用于实施后述的发明的优选方式所示的各结构引导的、通过现有技术不能得到的作用效果。
为了达到上述目的，在本说明书中，公开如下所示的“通信方法及通信终端，数据传送装置及控制装置”。
(1)即，此处公开的通信方法为第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：GW；31：承载管理部；32：信号处理部；33：上层处理部；331：过滤数据(列表)；332：路由表；34：下层处理部；30-1：MME；30-2：S-GW；30-3：PDN-GW；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 V1.10.0)、非专利文献2(3GPP TS23.401 V1.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-GW 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-GW 30-2是成为对下一代体系结构的无线接入网络的E-UTRAN(Evolved Universal Terrestrial Radio Access Network：演进的通用陆地无线接入网)的接口的实体，在与E-UTRAN内的eNB 20之间收发用户分组。此外，S-GW 30-2与GPRS(General Packet Radio Service：通用分组无线服务)中的称作SGSN(Serving GPRS Support Node：服务GPRS支持节点)的实体大致相当。关于E-UTRAN，在所述的非专利文献3(3GPP TS 36.300 V1.0.0)中有记载。
PDN-GW 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之间的接口名称被表记为“S1-MME”，eNB 20与S-GW 30-2之间的接口名称被表记为“S1-U”。
此外，S-GW 30-2和PDN-GW 30-3之间的接口名称被表记为“S5”，PDN-GW 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-GW 30-2和PDN-GW 30-3之间，分别定义了与各个接口名称对应的名称的承载、即无线承载(Radio bearer)、S1承载(S1 bearer)、S5承载(S5 bearer)。在这些接口中，使用了各个独立的协议的组合。
例如，在无线承载上送出的数据使用无线协议上和上位的数据传送协议的组合来发送，该承载用无线承载标识符(RBID)来识别。
在S1承载中，在数据传送中能够使用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个无线承载、S1承载、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)消息，当了解(响应)时，将表示该意思的响应消息(200OK)发送给IMS服务器50。
(4)在从UE 10-2接收所述了解时，IMS服务器50建立UE 10-1和UE 10-2之间的承载，分别向UE 10-1、UE 10-2通知已准备完毕。
此处，例如如图3所示，从IMS服务器50，按照PCRF 40、GW 30(PDN-GW 30-3、S-GW 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、GW 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-GW 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)报头压缩技术
在便携电话网中，有效使用无线区间的资源非常重要。因此，在UE10和eNB 20之间的分组通信中，使用被称作ROHCOLE_LINK1(RobustHeader Compression：鲁棒性报头压缩)OLE_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章中有记述。此外，关于ROHC，在所述的非专利文献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等的网络侧的实体(以下，还称作网络实体)中的省略(绕过)解压缩和压缩处理的流程的压缩分组(ROHC分组)进行发送时，对该压缩分组附加表示不需要(可省略)解压缩处理的信息(旁路标识符；第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所示，使用多种分组格式。
即，UE 10-1在将分组发送到支持ROHC协议的UE 10-2时，通过ROHC处理栈，依照ROHC协议压缩分组报头。此时，使用在连接开始时作为从网络侧(IMS服务器50)指示的所述旁路标识符的一例的CID。
此外，UE 10-1对压缩分组(包括所述CID的ROHC分组)附加TEID(第2信息要素)，该TEID被分配到连接有目的地UE 10-2的eNB20-2的S1接口。该TEID为从eNB 20-2向目的地UE 10-2的方向即下行链路(DL)用，因此在图7中被表记为“DL TEID”。
如图7(1)所示，TEID作为PDCP分组的有效载荷，优选附加到ROHC分组的末尾。如果这样，能够使接收该分组的eNB 20-1的协议处理栈中的、从已有的分组格式脱离的部分停留在ROHC(PDCP)处理栈中。
即，呼出侧的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(Radio Link Control：无线链路控制)报头并发送到eNB 20-1。
eNB 20-1对从UE 10-1接收到的分组(RLC分组)进行分析。即，eNB 20-1通过RLC及PDCP的处理栈端接接收分组的RLC报头及PDCP报头。此外，PDCP处理栈起动ROHC处理栈，ROHC处理栈读取所述端接后的ROHC分组所包括的所述CID。
eNB 20-1(ROHC处理栈)根据该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报头的内容将从eNB20-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。此时，存在能够采取不使用S1接口的上位的承载的方式的优点。但是，此时，在eNB 20-2中必须进行与现有的处理不同的处理。此外，在承载设定步骤中需要变更。
与此相对，在如上所述使用TEID的情况下，目的地侧的eNB 20-2能够对在呼出侧的eNB 20-1中实施解压缩处理而传送的隧道分组、和不实施解压缩处理而传送的非隧道分组实施相同的处理来确定目的地UE 10-2。
即，目的地侧的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经由S1接口接收到分组时相同的处理来处理接收分组。因此，可以说从简单进行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消息(步骤S1)。
IMS服务器50在接收该INVITE消息时，根据包括在该消息中的目的地IP地址，向目的地UE 10-2发送INVITE消息(步骤S2)。
UE 10-2在从IMS服务器50接收所述INVITE消息，并对来自UE 10-1的呼叫进行响应时，将表示呼叫成功的意思的响应消息(200OK)回送到IMS服务器50(步骤S3)。此外，“200”表示消息的状态代码(响应代码)，另外，还具有表示发送处理中(Trying)的代码(100)、和表示呼叫中(ringing)的代码(180)等。但是，在图8中，省略了这些过程的图示。
IMS服务器50在从目的地UE 10-2接收所述响应消息(200OK)时，执行图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的响应消息(200OK)将所确定的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-d1-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(步骤S9、S10)，eNB 20-2在对所接收的隧道分组进行解封装后发送到UE 10-2(步骤S11)。
(2.3)CID的选择方法
如下确定CID。首先，针对实施所述旁路处理的eNB 20，分别分配不重复的CID的范围。
例如，如果在存在100台eNB 20的区域内实施所述绕过处理，则如下表1所示，能够以在eNB#1中CID＝100-199、在eNB#2中CID＝200-299、在eNB#3中CID＝300-399的方式，分配每隔100个彼此不重复的范围的CID。
[表1]
CID(的范围)与eNB的对应(eNB)
  CID   传送目的地(eNBID)
  100-199   eNB#1
  200-299   eNB#2
  300-399   eNB#3
  ...   ...
此外，IMS服务器50保有例如如下表2所示的CID管理表(CID管理数据)，并按照每个eNB 20预先登记、管理可使用的CID的范围。IMS服务器50根据该CID管理表，按照每个eNB 20，从可使用的CID的范围选择未使用的CID(关于双向通信为1个)并通知到呼出侧的UE 10。
[表2]
CID管理表(IMS服务器)
  传送目的地(eNBID)   CID
  eNB#1   100-199
  eNB#2   200-299
  eNB#3   300-399
  ...   ...
此外，GW 30保有例如如下表3所示的路由表，登记、管理每个隧道路径(TEID)的目的地(传送目的地)eNB 20的信息(eNBID)。GW30能够根据该路由表，识别与接收分组的TEID对应的传送目的地eNB20，向该传送目的地eNB 20封装接收分组并进行隧道传输。即，即使为在eNB 20间不能直接传送分组的网络形式，也可以进行适当的分组传送。
[表3]
路由表(GW)
  接收侧隧道ID(TEID)   目的地eNB(eNBID)   备注
  1020   eNB#2   eNB#1→eNB#2传送
  2010   eNB#1   eNB#2→eNB#1传送
  1030   eNB#3   eNB#1→eNB#3传送
  3010   eNB#1   eNB#3→eNB#1传送
  2030   eNB#3   eNB#2→eNB#3传送
  3020   eNB#2   eNB#3→eNB#2传送
  ...   ...   ...
此外，如上所述，在eNB 20之间存在能够直接传送的路径的情况下，能够不经由GW 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附加到压缩分组的CID。
IMS服务器50在分别向UE 10-1、UE 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的压缩分组。
通过以上，根据本例的系统，能够得到如下的任意一个效果或优点。
(1)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、GW 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的发送数据流。
即，用A表示的信号流示出了以下情况：依次经由下层处理部15、IMS处理部12、承载管理部11、上层处理部13、ROHC处理部14、下层处理部15，在该过程中针对上层处理部13、ROHC处理部14、下层处理部15进行与承载设定相应的设定。此外，用B表示的信号流示出了在IMS处理部12中生成的信令消息在下层处理部15中受到所需的协议处理并发送到eNB 20。用C表示的数据流示出了经由上层处理部13、ROHC处理部14、下层处理部15并分别在其中实施必要的协议处理的情况。
此处，承载管理部11具有以下功能：对与eNB 20之间的DL及UL的承载(无线承载)进行管理，根据来自应用部16的请求，与IMS处理部12协作，实施承载的建立处理(消息的生成、收发)。
IMS处理部12具有以下功能：生成与来自承载管理部11的请求相应的消息(INVITE、200OK等的ISP消息、用于承载建立处理的消息(无线承载设置响应)等)，将所生成的消息发送到eNB 20，接收eNB 20所发送的消息等。
上层处理部13在PDCP(ROHC)层的上层中实施规定的处理，具有对例如IP、UDP或RTP(RTCP)等各种协议的数据进行处理(报头的端接、替换等)的功能(处理栈)。
ROHC处理部14具有依据定位为PDCP层的协议栈之一的ROHC协议进行的发送分组的报头压缩及接收分组的报头解压缩功能(ROHC处理栈)。本例的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(步骤A1)。这与图8的步骤S1的处理相当。
之后，在呼入侧的UE 10-2针对INVITE消息将响应(200OK)发送到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消息(200OK)时(步骤A5)，UE 10-1通过IMS处理部12，确认在该SIP消息中，是否设定了CID和TEID作为参数(步骤A6)。
其结果，如果未设定(如果在步骤A6中为“否”)，则UE 10-1(IMS处理部12)生成对所接收的所述SIP消息(200OK)的确认响应(ACK)消息，并通过下层处理部15向呼入侧的UE 10-2进行发送(步骤A9)。
另一方面，如果在所述SIP消息(200OK)中设定了CID和TEID(即，如果接收到在图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消息(步骤A11)，如果了解到与呼出侧的UE 10-1的通信开始，则通过IMS处理部12，生成对该INVITE消息的响应消息(200OK)，并通过下层处理部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所示的流程图实施发送分组的报头压缩处理。
即，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结束报头压缩处理。
即，本例的ROHC处理部14作为以下的附加单元发挥作用：在发给目的地UE 10-2的压缩数据中，附加识别是否需要报头解压缩处理和对目的地UE 10-2的隧道路径中所使用的信息(CID、TEID)。此外，下层处理部15作为向网络发送附加了所述信息的压缩数据的发送单元发挥作用。
此外，关于接收分组的报头解压缩处理，与现有的处理相同，因此省略说明。
(3.1)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、ROHC处理部24、下层处理部25进行与承载设定相应的设定。此外，用B表示的信号流示出了在信号处理部22中生成的信令消息在下层处理部25中受到所需的协议处理并发送到UE 10或eNB 20的情况。
用C表示的数据流示出了从eNB 20接收到的分组依次经由下层处理部25、上层处理部23、下层处理部25，在各个中实施必要的协议处理并发送到其他eNB 20的情况。用D表示的数据流表示从GW 30接收到的分组依次经由下层处理部25、上层处理部23、ROHC处理部24、下层处理部25来进行处理的情况。用E表示的数据流表示从UE 10接收到的分组依次经由下层处理部25、ROHC处理部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等)以外，还按照UE10间的承载单位登记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)消息时(步骤B1)，与承载管理部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在压缩分组中附加PCDP报头并作为PDCP分组与TEID一起，经由上层处理部23传送到下层处理部25。下层处理部25在传送来的TEID和PDCP分组中，附加隧道用的GTP报头。在隧道用的GTP报头中，包括例如具有通过TEID识别的S1接口的入侧eNB20的地址信息。由此，建立图7(2)所示的格式的GTP分组(隧道分组)，并发送到GW 30(步骤B18、B19)。该处理与在图8的步骤S9中示出的处理相当。
即，本例的下层处理部25作为从UE 10-1接收在呼出侧的UE 10-1中附加了特定的CID和TEID的压缩数据的接收单元发挥作用，ROHC处理部24作为根据所述CID、TEID，识别是否需要所接收的压缩数据的报头解压缩处理和对目的地UE 10-2的传送路径的识别单元发挥作用。此外，下层处理部25还作为对识别为不需要报头解压缩处理的压缩数据不进行报头解压缩处理而发送到所述识别的传送路径的发送单元发挥作用。
(从GW接收到DL的分组的情况)
如图16所示，eNB 20在上述的承载建立处理完成、在UE 10之间开始通信，并从GW 30接收到DL的分组(GTP分组)时，通过下层处理部25，端接并分析GTP报头，从而确认在该GTP报头中设定的TEID(DL_TEID)是否为隧道用(步骤B20)。
即，如果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的步骤S11中示出的处理相当。
另一方面，在从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的数据流。
即，用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是对接收到隧道分组时的动作进行说明的流程图。
(连接开始时的动作)
GW 30在从IMS服务器50接收到在图3的步骤S41中示出的PCC确定通知(PCC decision proposition)消息时(步骤C1)，与承载管理部31和信号处理部32协作，生成发给出侧eNB 20-1的专用承载建立请求(Create Dedicated Bearer Request)消息，并通过下层处理部34向出侧eNB 20-1进行发送(步骤C2)。这与图3的步骤S42的处理相当。
之后，GW 30(承载管理部31和信号处理部32)在接收到在图3的步骤S45中示出的响应消息(Radio Bearer Setup Response)时(步骤C3)，读出在该响应消息中设定的TEID(步骤C4)，并设定与出侧eNB 20-1之间的专用承载(步骤C5)。此外，TEID的读出和专用承载的设定可以为相反顺序，也可以并行实施。
接着，GW 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的处理相当。
之后，GW 30(承载管理部31和信号处理部32)在从入侧eNB 20-2接收到在图3的步骤S51中示出的专用承载建立响应(Create DedicatedBearer Response)消息时(步骤C8)，读出在该响应消息中设定的TEID(步骤C9)，并设定与入侧eNB 20-2之间的专用承载(步骤C10)。此外，此时，TEID的读出和专用承载的设定可以为相反顺序，也可以并行实施。
此外，GW 30(承载管理部31和信号处理部32)在对IMS服务器50报告承载设定完成的PCC确定通知确认(PCC decision PropositionACK)消息中，赋予所述读出的各TEID(呼出侧及呼入侧)，并将该消息发送到IMS服务器50(步骤C11)。对该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)。
即，上层处理部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消息(200OK消息)和来自GW 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的步骤S1所示，IMS服务器50在通过下层处理部52在IMS处理部51中，从呼出侧的UE 10-1接收到SIP的INVITE消息时(步骤D1)，根据包括在该INVITE消息中的目的地信息，确定呼入侧的UE 10-2，并通过下层处理部52，向该UE 10-2发送SIP的INVITE消息(步骤D2)。该处理与图8的步骤S2所示的处理相当。
之后，IMS服务器50(IMS处理部51)在从呼入侧的UE 10-2接收到对所述INVITE消息的响应消息(200OK)时(步骤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消息(200OK)，并进行发送(步骤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、GW 30和IMS服务器50，能够实现在项目[2]中所述的动作、效果。
[4]其他
此外，在上述实施方式中，着眼于在UE 10和GW 30之间有1台eNB20的路径进行了说明，但是关于有2台以上的eNB20的路径，也与上述的例子同样地，针对具有特定的CID(旁路标识符)的分组，能够不需要出侧eNB20中的报头解压缩处理、和入侧eNB20中的报头解压缩处理。

Claims (8)

1.一种第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通信终端。
CN200780101398.6A 2007-10-31 2007-10-31 通信方法及通信终端、数据传送装置及控制装置 Expired - Fee Related CN101843054B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2007/071216 WO2009057204A1 (ja) 2007-10-31 2007-10-31 通信方法並びに通信端末、データ転送装置及び制御装置

Publications (2)

Publication Number Publication Date
CN101843054A true CN101843054A (zh) 2010-09-22
CN101843054B CN101843054B (zh) 2014-12-17

Family

ID=40590614

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200780101398.6A Expired - Fee Related CN101843054B (zh) 2007-10-31 2007-10-31 通信方法及通信终端、数据传送装置及控制装置

Country Status (5)

Country Link
US (1) US8331363B2 (zh)
EP (1) EP2209265B1 (zh)
JP (1) JP5018890B2 (zh)
CN (1) CN101843054B (zh)
WO (1) WO2009057204A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103428181A (zh) * 2012-05-22 2013-12-04 中国科学院声学研究所 一种应用于IP over DVB的UDP报文传输优化方法
CN105765929A (zh) * 2013-11-25 2016-07-13 三星电子株式会社 电子设备中用于处理报头压缩的分组的装置和方法
CN105874872A (zh) * 2014-09-16 2016-08-17 华为技术有限公司 通信方法和装置
CN106416356A (zh) * 2015-05-20 2017-02-15 华为技术有限公司 上行数据包处理方法、装置和基站
CN106716951A (zh) * 2014-06-26 2017-05-24 吉来特卫星网络有限公司 用于优化隧道流量的方法和装置
US11671868B2 (en) 2014-06-26 2023-06-06 Gilat Satellite Networks Ltd. Methods and apparatus for optimizing tunneled traffic

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2209265B1 (en) * 2007-10-31 2015-08-26 Fujitsu Limited Communication method and communication terminal, data transfer device, and controller
EP2454896A1 (en) * 2009-07-14 2012-05-23 Nokia Siemens Networks Oy Apparatus and method of providing end-to-end call services
US9674311B2 (en) 2009-08-14 2017-06-06 Qualcomm Incorporated Robust header compression for relay nodes
DE102012101973B4 (de) * 2011-03-08 2016-10-06 Electronics And Telecommunications Research Institute Integrierte Zugangsvorrichtung für ein All-lP-konvergiertes Netz
CN106937329B (zh) * 2011-12-20 2021-04-20 华为技术有限公司 网际协议头置换映射关系的获取方法及网络节点
US10390259B2 (en) * 2012-02-28 2019-08-20 Nokia Solutions And Networks Oy Data forwarding in a mobile communications network system with centralized gateway apparatus controlling distributed gateway elements
US8867447B2 (en) * 2012-08-28 2014-10-21 Verizon Patent And Licensing Inc. Dynamic header compression based on attributes of traffic
KR20140134998A (ko) * 2013-05-15 2014-11-25 삼성전자주식회사 통신 시스템에서 음성 서비스 성능 향상을 위한 방법 및 장치
KR20140135000A (ko) * 2013-05-15 2014-11-25 삼성전자주식회사 소프트웨어정의네트워킹 기반 통신시스템의 서비스 처리 방법 및 장치
US20160212042A1 (en) * 2013-08-19 2016-07-21 Lg Electronics Inc. Broadcast transmitting device, broadcast receiving device, operating method of the broadcast transmitting device, and operating method of the broadcast receiving device
RU2637471C2 (ru) * 2013-10-09 2017-12-04 Нек Корпорейшн Система связи, аппаратура связи и способ управления связью
WO2015182255A1 (ja) * 2014-05-28 2015-12-03 ソニー株式会社 装置及び方法
US9408124B2 (en) * 2014-07-21 2016-08-02 Verizon Patent And Licensing Inc. Call initiation message delay during handoff process
US20180234891A1 (en) * 2015-08-07 2018-08-16 Huawei Technologies Co., Ltd. Data Transmission Method, Method for Accessing Network, Related Device, and System
JP6320458B2 (ja) * 2016-06-09 2018-05-09 ソフトバンク株式会社 移動体通信システム
US10205802B2 (en) * 2017-06-01 2019-02-12 Institute For Information Industry Transmission system and transmission method
US10673649B2 (en) * 2017-10-24 2020-06-02 Cisco Technology, Inc. Method and device for quality of service regulation
JP2019140498A (ja) * 2018-02-08 2019-08-22 日本電信電話株式会社 通信システムおよび通信方法
JP2020113895A (ja) * 2019-01-11 2020-07-27 シャープ株式会社 送信装置および受信装置
US11792302B2 (en) 2019-03-27 2023-10-17 Apple Inc. Ethernet header compression

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5131016A (en) * 1991-01-09 1992-07-14 International Business Machines Corporation Communications network data compression control system and method
US5535199A (en) * 1994-09-06 1996-07-09 Sun Microsystems, Inc. TCP/IP header compression X.25 networks
FI105760B (fi) * 1997-10-30 2000-09-29 Nokia Mobile Phones Ltd Matkaviestinverkon aliverkkoriippuvainen konvergenssiprotokolla
JP3530099B2 (ja) * 2000-02-25 2004-05-24 日本電信電話株式会社 パケット転送装置
JP4592935B2 (ja) * 2000-09-11 2010-12-08 パナソニック株式会社 ヘッダ復元装置およびヘッダ復元方法
FI110739B (fi) * 2000-10-18 2003-03-14 Nokia Corp Otsikkokenttien kompressoinnin määrittäminen datapakettiyhteydelle
FI118244B (fi) * 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
JP2003224610A (ja) 2002-01-29 2003-08-08 Mitsubishi Electric Corp ヘッダ圧縮パケット転送システム及びヘッダ圧縮パケット転送方法
JP2004194232A (ja) * 2002-12-13 2004-07-08 Mitsubishi Electric Corp パケット通信装置
US20050169270A1 (en) * 2003-03-19 2005-08-04 Ryoichi Mutou Router, frame forwarding method, and lower layer frame virtual forwarding system
KR100770857B1 (ko) * 2004-02-12 2007-10-26 삼성전자주식회사 멀티미디어 방송/멀티캐스트 서비스 시스템에서 헤더 복원 동작을 재개하는 방법
JP4882959B2 (ja) * 2007-10-26 2012-02-22 富士通株式会社 パケット通信方法並びにパケット通信システム、管理装置、無線端末及びパケット通信装置
EP2209265B1 (en) * 2007-10-31 2015-08-26 Fujitsu Limited Communication method and communication terminal, data transfer device, and controller

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103428181A (zh) * 2012-05-22 2013-12-04 中国科学院声学研究所 一种应用于IP over DVB的UDP报文传输优化方法
CN105765929A (zh) * 2013-11-25 2016-07-13 三星电子株式会社 电子设备中用于处理报头压缩的分组的装置和方法
US10257323B2 (en) 2013-11-25 2019-04-09 Samsung Electronics Co., Ltd. Apparatus and method for processing header compressed packet in electronic device
CN105765929B (zh) * 2013-11-25 2020-08-14 三星电子株式会社 电子设备中用于处理报头压缩的分组的装置和方法
US10863008B2 (en) 2013-11-25 2020-12-08 Samsung Electronics Co., Ltd. Apparatus and method for processing header compressed packet in electronic device
CN106716951A (zh) * 2014-06-26 2017-05-24 吉来特卫星网络有限公司 用于优化隧道流量的方法和装置
US11671868B2 (en) 2014-06-26 2023-06-06 Gilat Satellite Networks Ltd. Methods and apparatus for optimizing tunneled traffic
CN105874872A (zh) * 2014-09-16 2016-08-17 华为技术有限公司 通信方法和装置
CN105874872B (zh) * 2014-09-16 2019-05-24 华为技术有限公司 通信方法和装置
US10575343B2 (en) 2014-09-16 2020-02-25 Huawei Technologies Co., Ltd. Communication method and apparatus
CN106416356A (zh) * 2015-05-20 2017-02-15 华为技术有限公司 上行数据包处理方法、装置和基站

Also Published As

Publication number Publication date
EP2209265A4 (en) 2013-09-04
WO2009057204A1 (ja) 2009-05-07
CN101843054B (zh) 2014-12-17
JP5018890B2 (ja) 2012-09-05
JPWO2009057204A1 (ja) 2011-03-10
EP2209265A1 (en) 2010-07-21
EP2209265B1 (en) 2015-08-26
US20100202458A1 (en) 2010-08-12
US8331363B2 (en) 2012-12-11

Similar Documents

Publication Publication Date Title
CN101843054B (zh) 通信方法及通信终端、数据传送装置及控制装置
AU2003248437B2 (en) Packet Transmission System and Packet Reception System
EP2099179B1 (en) Method and system for negotiating flow rate in a network
CN103856995B (zh) 用于移动性管理的伪线
CN110536262A (zh) 一种直通链路通信方法、装置和存储介质
US7397819B2 (en) Packet compression system, packet restoration system, packet compression method, and packet restoration method
CN1819580B (zh) 通信装置、通信控制装置和通信系统
CN105791165B (zh) 一种业务承载方法、通信终端、控制网元s-cscf以及系统
US11387895B2 (en) Communication method and communication system
CN106465230A (zh) 控制接入的装置、系统和方法
CN106716951A (zh) 用于优化隧道流量的方法和装置
JP5406715B2 (ja) 陸上移動無線（ｌｍｒ）コンテンツを通信する方法、無線通信システム及び陸上移動無線ユニット
CN106102018B (zh) 一种宽带集群通信中的通信配置方法和装置
WO2012079396A1 (zh) 一种带宽控制的方法、设备和系统
JP2008546251A (ja) セルラーデータネットワークを使用して陸上移動無線コンテンツを提供するシステム
WO2006052117A1 (en) Apparatus and method for compressing headers in a broadband wireless communication system
CN107172662A (zh) 一种通信方法及装置
CN107438993A (zh) 用于基于tcp通道和原生tcp信息在集束情景中调度分组的方法和系统
CN101517990B (zh) 数据包分配系统、数据包分配方法
CN112136305A (zh) 虚拟联网环境中的协调数据共享
WO2019137242A1 (zh) 建立承载方法、装置、处理器及存储介质
CN101026545B (zh) 一种实时多媒体传输系统和方法
CN105874872B (zh) 通信方法和装置
JP2002101112A (ja) 無線通信システムにおいてｉｐトラフィックを伝送する方法およびシステム
CN106332179B (zh) 一种报文压缩方法及移动终端

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20141217

Termination date: 20181031

CF01 Termination of patent right due to non-payment of annual fee