(57)【要約】  第１の通信端末は、第２の通信端末宛のデータのヘッダを圧縮した圧縮データに、ヘッダ伸張処理の要否と、前記第２の通信端末への転送経路とを識別するのに用いられる情報を付加してネットワークへ送信し、前記圧縮データを受信したネットワーク側の装置は、前記情報に基づいて前記圧縮データのヘッダ伸張処理の要否と前記転送経路とを識別し、前記ヘッダ伸張処理が不要な圧縮データをヘッダ伸張処理せずに前記識別した転送経路へ送信する。
2009057204.tif 000002
【特許請求の範囲】
【請求項１】
第１の通信端末と第２の通信端末とがネットワークを介して通信を行なう通信システムにおける通信方法であって、
前記第１の通信端末は、
前記第２の通信端末宛のデータのヘッダを圧縮した圧縮データに、ヘッダ伸張処理の要否と、前記第２の通信端末への転送経路とを識別するのに用いられる情報を付加して前記ネットワークへ送信し、
前記ネットワークを構成するデータ転送装置であって前記第１の通信端末から前記圧縮データを受信した装置は、
前記情報に基づいて前記圧縮データのヘッダ伸張処理の要否と前記転送経路とを識別し、
前記ヘッダ伸張処理が不要な圧縮データをヘッダ伸張処理せずに前記識別した転送経路へ送信する、
ことを特徴とする、通信方法。
【請求項２】
前記情報は、前記データのヘッダ圧縮に用いるコンテキストを識別するコンテキスト識別情報であって前記ヘッダ伸張の要否に応じて予め定められた第１の情報要素と、前記データ転送装置に対して予め定められた前記転送経路の識別情報である第２の情報要素との組み合わせにより成る、ことを特徴とする、請求項１記載の通信方法。
【請求項３】
前記第１の通信端末は、
前記圧縮データを送信する際に、前記第１の情報要素と前記第２の情報要素とを、前記ヘッダ伸張処理の属するレイヤで処理される情報として前記圧縮データに付加し、
前記データ転送装置は、
前記圧縮データを前記転送経路に送信する際に、前記第２の情報要素を、前記伸張処理の属するレイヤよりも下位のレイヤで処理される情報として前記圧縮データに付加する、ことを特徴とする、請求項２記載の通信方法。
【請求項４】
前記情報は、前記第１の通信端末と前記第２の通信端末との間の通信路の設定を制御する制御装置から通知される、ことを特徴とする、請求項１〜３のいずれか１項に記載の通信方法。
【請求項５】
前記制御装置は、
前記通知に、前記通信路を設定する際に送受されるメッセージを用いる、ことを特徴とする、請求項４記載の通信方法。
【請求項６】
ネットワークを介して他の通信端末と通信を行なう通信端末であって、
前記他の通信端末宛のデータのヘッダを圧縮した圧縮データに、ヘッダ伸張処理の要否と前記他の通信端末への転送経路とを識別するのに用いられる情報を付加する付加手段と、
前記情報が付加された圧縮データを前記ネットワークへ送信する送信手段と、
をそなえたことを特徴とする、通信端末。
【請求項７】
第１の通信端末と第２の通信端末とがネットワークを介して通信を行なう通信システムにおける前記ネットワークを構成するデータ転送装置であって、
前記第１の通信端末でヘッダ圧縮されるとともに、ヘッダ伸張処理の要否と前記第２の通信端末への転送経路とを識別するのに用いられる情報が付加された圧縮データを前記第１の通信端末から受信する受信手段と、
前記情報に基づいて、前記圧縮データのヘッダ伸張処理の要否と前記転送経路とを識別する識別手段と、
前記識別手段にて前記ヘッダ伸張処理が不要と識別された圧縮データをヘッダ伸張処理せずに前記識別した転送経路へ送信する送信手段と、
をそなえたことを特徴とする、データ転送装置。
【請求項８】
第１の通信端末と第２の通信端末とがネットワークを介して通信を行なう通信システムにおける前記通信を制御する制御装置であって、
前記第１の通信端末がヘッダ圧縮して前記第２の通信端末宛に送信するデータに付加する情報であって、ヘッダ伸張処理の要否と前記第２の通信端末への転送経路とを識別するのに用いられる情報を生成する生成手段と、
前記通信の通信路を設定する過程において、前記生成手段で生成した情報を前記第１の通信端末に通知する通知手段と、
をそなえたことを特徴とする、制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信方法並びに通信端末、データ転送装置及び制御装置に関する。本発明は、例えば、送信側においてデータ（パケット）の一部（ヘッダ）を圧縮して送信し、受信側において圧縮されたヘッダの伸張を行なう通信システムに用いると好適である。
【背景技術】
【０００２】
下記の特許文献１（特開２００３−２２４６１０号公報）には、ヘッダ圧縮パケット転送システム及びヘッダ圧縮パケット転送方法に関する技術が開示されている。【０００３】
この技術は、パケット転送途中でのヘッダ情報の伸張／圧縮を行なわないで、ヘッダ圧縮したままで情報を転送して、伸張／圧縮処理を無くし、回線使用効率も上げることを目的としている。【０００４】
そのため、この特許文献１には、移動体端末から関門ノードに対して接続要求があると、関門ノードにおいて、その接続要求に基づいて移動体端末と要求送信先端末の接続経路情報を関連付けて記憶し、その記憶情報に基づいて以後のヘッダ圧縮パケットを要求送信先端末へ転送することが記載されている。【０００５】
なお、パケット通信技術に関連する文献として、下記の非特許文献１〜７がある。
【特許文献１】特開２００３−２２４６１０号公報
【非特許文献１】3GPP TR 23.882 V1.10.0、［online］、平成１９年９月２７日、［平成１９年１０月２５日検索］、インターネット＜URL:http://www.3gpp.org/ftp/Specs/html-info/23882.htm＞
【非特許文献２】3GPP TS 23.401 V1.0.0、［online］、平成１９年６月１３日、［平成１９年１０月２５日検索］、インターネット＜URL:http://www.3gpp.org/ftp/Specs/html-info/23401.htm＞
【非特許文献３】3GPP TS 36.300 V1.0.0、［online］、平成１９年３月１９日、［平成１９年１０月２５日検索］、インターネット＜URL:http://www.3gpp.org/ftp/Specs/html-info/36300.htm＞
【非特許文献４】3GPP TS 23.228 V8.1.0、［online］、平成１９年６月１９日、［平成１９年１０月２５日検索］、インターネット＜URL:http://www.3gpp.org/ftp/Specs/html-info/23228.htm＞
【非特許文献５】3GPP TS 29.060 V7.5.1、［online］、平成１９年３月２３日、［平成１９年１０月２５日検索］、インターネット＜URL:http://www.3gpp.org/ftp/Specs/html-info/29060.htm＞
【非特許文献６】3GPP TS 25.323 V7.4.0、［online］、平成１９年４月６日、［平成１９年１０月２５日検索］、インターネット＜URL:http://www.3gpp.org/ftp/Specs/html-info/25323.htm＞
【非特許文献７】IETF RFC 3095、［online］、平成１３年７月、［平成１９年１０月２５日検索］、インターネット＜URL:http://www.ietf.org/rfc/rfc3095.txt＞
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明の目的の一つは、ヘッダ圧縮されたデータをネットワーク側で伸張せずに適切な宛先に送る（転送する）のに要する処理量を削減することにある。【０００７】
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の一つとして位置付けることができる。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、本明細書では、以下に示す「通信方法並びに通信端末、データ転送装置及び制御装置」を開示する。【０００９】
（１）即ち、ここで開示する通信方法は、第１の通信端末と第２の通信端末とがネットワークを介して通信を行なう通信システムにおける通信方法であって、前記第１の通信端末は、前記第２の通信端末宛のデータのヘッダを圧縮した圧縮データに、ヘッダ伸張処理の要否と、前記第２の通信端末への転送経路とを識別するのに用いられる情報を付加して前記ネットワークへ送信し、前記ネットワークを構成するデータ転送装置であって前記第１の通信端末から前記圧縮データを受信した装置は、前記情報に基づいて前記圧縮データのヘッダ伸張処理の要否と前記転送経路とを識別し、前記ヘッダ伸張処理が不要な圧縮データをヘッダ伸張処理せずに前記識別した転送経路へ送信する。【００１０】
（２）ここで、前記情報は、前記データのヘッダ圧縮に用いるコンテキストを識別するコンテキスト識別情報であって前記ヘッダ伸張の要否に応じて予め定められた第１の情報要素と、前記データ転送装置に対して予め定められた前記転送経路の識別情報である第２の情報要素との組み合わせにより成る、こととしてもよい。【００１１】
（３）また、前記第１の通信端末は、前記圧縮データを送信する際に、前記第１の情報要素と前記第２の情報要素とを、前記ヘッダ伸張処理の属するレイヤで処理される情報として前記圧縮データに付加し、前記データ転送装置は、前記圧縮データを前記転送経路に送信する際に、前記第２の情報要素を、前記伸張処理の属するレイヤよりも下位のレイヤで処理される情報として前記圧縮データに付加する、こととしてもよい。【００１２】
（４）さらに、前記情報は、前記第１の通信端末と前記第２の通信端末との間の通信路の設定を制御する制御装置から通知される、こととしてもよい。【００１３】
（５）また、前記制御装置は、前記通知に、前記通信路を設定する際に送受されるメッセージを用いる、こととしてもよい。【００１４】
（６）さらに、ここで開示する通信端末は、ネットワークを介して他の通信端末と通信を行なう通信端末であって、前記他の通信端末宛のデータのヘッダを圧縮した圧縮データに、ヘッダ伸張処理の要否と前記他の通信端末への転送経路とを識別するのに用いられる情報を付加する付加手段と、前記情報が付加された圧縮データを前記ネットワークへ送信する送信手段と、をそなえる。【００１５】
（７）また、ここで開示するデータ転送装置は、第１の通信端末と第２の通信端末とがネットワークを介して通信を行なう通信システムにおける前記ネットワークを構成するデータ転送装置であって、前記第１の通信端末でヘッダ圧縮されるとともに、ヘッダ伸張処理の要否と前記第２の通信端末への転送経路とを識別するのに用いられる情報が付加された圧縮データを前記第１の通信端末から受信する受信手段と、前記情報に基づいて、前記圧縮データのヘッダ伸張処理の要否と前記転送経路とを識別する識別手段と、前記識別手段にて前記ヘッダ伸張処理が不要と識別された圧縮データをヘッダ伸張処理せずに前記識別した転送経路へ送信する送信手段と、をそなえる。【００１６】
（８）さらに、ここで開示する制御装置は、第１の通信端末と第２の通信端末とがネットワークを介して通信を行なう通信システムにおける前記通信を制御する制御装置であって、前記第１の通信端末がヘッダ圧縮して前記第２の通信端末宛に送信するデータに付加する情報であって、ヘッダ伸張処理の要否と前記第２の通信端末への転送経路とを識別するのに用いられる情報を生成する生成手段と、前記通信の通信路を設定する過程において、前記生成手段で生成した情報を前記第１の通信端末に通知する通知手段と、をそなえる。
【発明の効果】
【００１７】
前記開示技術によれば、第１の通信端末においてヘッダ圧縮されたデータをネットワーク側で伸張せずに適切な宛先（第２の通信端末）に転送するのに要する処理量を削減することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態に関連するＳＡＥ（Systems Architecture Evolution）でのシステム構成例を示す図である。
【図２】ＳＡＥベアラ構成を説明する図である。
【図３】ベアラ確立処理のシグナリングシーケンスの一例を示す図である。
【図４】本発明の一実施形態に関連するＲＯＨＣ（RObust Header Compression）によるヘッダ圧縮の一例を説明する図である。
【図５】ＲＯＨＣの概念を説明する図である。
【図６】本発明の一実施形態のパケット転送を説明する図である。
【図７】本実施形態で用いるパケットフォーマット例を示す図である。
【図８】本実施形態に係る無線通信システムの通信シーケンスの一例を示す図である。
【図９】本実施形態に係るユーザ端末（ＵＥ）の構成（機能）を示すブロック図である。
【図１０】図９に示すＵＥ（発呼側）の接続開始時の動作を説明するフローチャートである。
【図１１】図９に示すＵＥ（着呼側）の接続開始時の動作を説明するフローチャートである。
【図１２】図９に示すＵＥでのヘッダ圧縮動作を説明するフローチャートである。
【図１３】本実施形態に係る無線基地局（ｅＮＢ）の構成（機能）を示すブロック図である。
【図１４】図１３に示すｅＮＢの接続開始時の動作を説明するフローチャートである。
【図１５】図１３に示すｅＮＢのアップリンク（ＵＬ）パケット受信時の動作を説明するフローチャートである。
【図１６】図１３に示すｅＮＢのダウンリンク（ＤＬ）パケット受信時の動作を説明するフローチャートである。
【図１７】本実施形態に係るゲートウェイ（ＧＷ）の構成（機能）を示すブロック図である。
【図１８】図１７に示すＧＷの接続開始時の動作を説明するフローチャートである。
【図１９】図１７に示すＧＷが外部（インターネット等）からパケットを受信した時の動作を説明するフローチャートである。
【図２０】図１７に示すＧＷが外部（インターネット等）へのパケットを受信した時の動作を説明するフローチャートである。
【図２１】図１７に示すＧＷがトンネルパケットを受信した時の動作を説明するフローチャートである。
【図２２】本実施形態に係るＩＭＳ（IP Multimedia Subsystem）サーバの構成（機能）を示すブロック図である。
【図２３】図２２に示すＩＭＳサーバの接続開始時の動作を説明するフローチャートである。
【符号の説明】
【００１９】
１０，１０−１，１０−２  ユーザ端末（ＵＥ）
１１  ベアラ管理部
１２  ＩＭＳ処理部
１３  上位層処理部
１４  ＲＯＨＣ処理部
１４１  フィルタデータ（リスト）
１４２  コンテキストデータ
１５  下位層処理部
１６  アプリケーション部
２０，２０−１，２０−２  無線基地局（ｅＮＢ）
２１  ベアラ管理部
２２  シグナル処理部
２３  上位層処理部
２４  ＲＯＨＣ処理部
２４１  フィルタデータ（リスト）
２４２，２４２ａ，２４２ｂ  コンテキストデータ
２５  下位層処理部
２５１  TEID-RBID対応表
３０  ＧＷ
３１  ベアラ管理部
３２  シグナル処理部
３３  上位層処理部
３３１  フィルタデータ（リスト）
３３２  ルーティングテーブル
３４  下位層処理部
３０−１  ＭＭＥ
３０−２  Ｓ−ＧＷ
３０−３  ＰＤＮ−ＧＷ
４０  ＰＣＲＦ
５０  ＣＳＣＦ〔アプリケーションサーバ（ＩＭＳサーバ）〕
５１  ＩＭＳ処理部
５１１，５１１ａ，５１１ｂ  ＣＩＤ管理表
５２  下位層処理部
【発明を実施するための最良の形態】
【００２０】
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも一例であり、以下に明示的に記載しない技術を排除する意図はない。本発明は、以下に示す実施形態に限定されず、本発明の趣旨を逸脱しない範囲で種々変形して実施できることはいうまでもない。【００２１】
〔１〕本実施形態に関連する技術
（１．１）３ＧＰＰ  ＳＡＥ／ＬＴＥでのベアラ構成
３ＧＰＰでは、既存の様々な無線アクセス方式（アクセス網）を収容可能とし、コア網の完全ＩＰ化（All IP）を可能とする次世代システム（Release 8）が検討されている。その内容は、前記の非特許文献１（3GPP TR 23.882 V1.10.0）、非特許文献２（3GPP TS 23.401 V1.0.0）に説明されている。ここで検討されている次世代アーキテクチャは、Systems Architecture Evolution（ＳＡＥ）と呼ばれている。なお、ＳＡＥでの無線技術がＬＴＥ（Long Term Evolution）と呼ばれる。【００２２】
図１にＳＡＥでのシステム構成例を示す。この図１に示すように、ＳＡＥは、例えば、ユーザ端末（ＵＥ）１０と、無線基地局としてのeNodeB（ｅＮＢ）２０と、ＭＭＥ（Mobility Management Entity）３０−１と、Ｓ−ＧＷ（Serving Gateway）３０−２と、ＰＤＮ−ＧＷ３０−３と、ＰＣＲＦ（Policy and Charging Rules Function）４０と、ＣＳＣＦ（Call Session Control Function）５０と、を具備するシステムとして定義される。【００２３】
ＵＥ１０は、無線インタフェースを具備し、ｅＮＢ２０のサービスエリア内において当該ｅＮＢ２０と無線リンクにより接続し、当該ｅＮＢ２０を介して他のＵＥ１０やサーバ装置等と通信する。無線リンクには、ＵＥ１０からｅＮＢ２０への方向であるアップリンク（ＵＬ）と、その逆の方向であるダウンリンク（ＤＬ）とが含まれる。なお、ＵＥ１０には、携帯電話やＰＤＡ、ノート型ＰＣ等が含まれる。また、ＵＥ１０は、有線インタフェースによりｅＮＢ２０と接続する通信端末であってもよい。【００２４】
ｅＮＢ２０は、ＵＥ１０との間の無線インタフェースを終端するエンティティ（ノード）であり、ＵＥ１０からの無線パケットの受信、ＵＥ１０宛の無線パケットの送信を行なう。なお、ｅＮＢ２０は、ＵＴＲＡＮ（Universal Terrestrial Radio Access Network）における無線基地局（ＢＳ）とＲＮＣ（Radio Network Controller）の機能の一部とを統合したエンティティに相当する。【００２５】
ＭＭＥ３０−１は、ＵＥ１０の位置（モビリティ）を管理し、ベアラ管理、ＮＡＳ（Non-Access-Stratum）シグナリング等を行なうエンティティ（論理ノード）である。【００２６】
Ｓ−ＧＷ３０−２は、次世代アーキテクチャの無線アクセスネットワークであるE-UTRAN（Evolved Universal Terrestrial Radio Access Network）に対するインタフェースとなるエンティティであり、E-UTRAN内のｅＮＢ２０との間でユーザパケットを送受信する。なお、Ｓ−ＧＷ３０−２は、ＧＰＲＳ（General Packet Radio Service）におけるＳＧＳＮ（Serving GPRS Support Node）と呼ばれるエンティティにおおよそ相当する。E-UTRANについては、前記の非特許文献３（3GPP TS 36.300 V1.0.0）に記載がある。【００２７】
ＰＤＮ−ＧＷ３０−３は、ＰＤＮ（Packet Data Network）へのインタフェースを終端する関門（ゲートウェイ）ノードである。ＰＤＮは、インターネットや、オペレータ内のネットワーク、プライベートパケットデータネットワーク、オペレータ間のパケットデータネットワーク（ＩＭＳサービス提供用等）のいずれでもよい。なお、ＰＤＮ−ＧＷ３０−３は、ＧＰＲＳにおけるＧＧＳＮ（Gateway GPRS Support Node）と呼ばれるエンティティにおおよそ相当する。ＩＭＳ（IP Multimedia Subsystem）については、前記の非特許文献４（3GPP TS 23.228 V8.1.0）に定義がある。【００２８】
ＰＣＲＦ４０は、ＣＳＣＦ５０からの要求に応じて、ベアラのＱｏＳ（Quality of Service）等の各種ポリシや課金を管理、制御するエンティティ（論理ノード）である。【００２９】
ＣＳＣＦ５０は、ＩＭＳでのセッション（ベアラ）を管理、制御するエンティティ（論理ノード）である。ただし、ＣＳＣＦ５０は、ＰＤＮ−ＧＷ３０−３を直接制御するのではなく、前記ＰＣＲＦ４０を介してベアラの設定（確立）を行なう。ＣＳＣＦ５０は、例えば、ＰＤＮを構成するＩＭＳサーバ等のアプリケーションサーバの一機能として実現される。【００３０】
なお、図１中に示すように、ＵＥ１０とｅＮＢ２０との間のインタフェース名は「LTE-Uu」、ｅＮＢ２０とＭＭＥ３０−１との間のインタフェース名は「S1-MME」、ｅＮＢ２０とＳ−ＧＷ３０−２との間のインタフェース名は「S1-U」とそれぞれ表記される。【００３１】
また、Ｓ−ＧＷ３０−２とＰＤＮ−ＧＷ３０−３との間のインタフェース名は「Ｓ５」、ＰＤＮ−ＧＷ３０−３とＰＣＲＦ４０との間のインタフェース名は「Ｓ７」、ＰＤＮ−ＧＷ３０−３からＰＤＮ（ＣＳＣＦ５０）へのインタフェース名は「SGi」、ＣＳＣＦ５０とＰＣＲＦ４０との間のインタフェース名は「Rx+」とそれぞれ表記される。【００３２】
ＳＡＥでのベアラ（ＳＡＥベアラ）は、ＵＥ１０からＰＤＮ内の通信装置（ＰＤＮ−ＧＷ３０−３）までの区間で定義される。通信相手、ＱｏＳ等が定義されたデータ転送経路を「ベアラ」と呼ぶ。【００３３】
そして、例えば図２に示すように、ＵＥ１０とｅＮＢ２０との間、ｅＮＢ２０とＳ−ＧＷ３０−２との間、Ｓ−ＧＷ３０−２とＰＤＮ−ＧＷ３０−３との間では、それぞれのインタフェース名に応じた名称のベアラ、即ち、無線ベアラ（Radio bearer）、Ｓ１ベアラ（S1 bearer）、Ｓ５ベアラ（S5 bearer）がそれぞれ定義される。これらのインタフェースでは、それぞれ個別のプロトコルの組み合わせが使われる。【００３４】
例えば、無線ベアラ上で送られるデータは、無線プロトコル上と上位のデータ転送プロトコルとの組み合わせを使って送信され、そのベアラは無線ベアラ識別子（ＲＢＩＤ）で識別される。【００３５】
Ｓ１ベアラでは、ＧＰＲＳ（General Packet Radio Service）トンネリングプロトコル（ＧＴＰ）をデータ転送に使うことができる。なお、ＧＴＰについては、前記の非特許文献５（3GPP TS 29.060 V7.5.1）に定義がある。ＧＴＰで受信するエンドポイントを識別するトンネルエンドポイント識別子（Tunnel Endpoint Identifier：TEID）をベアラ識別子として使うことができる。なお、ＴＥＩＤについては非特許文献５の第６章に記載がある。Ｓ５ベアラでも同様に、ＴＥＩＤでベアラを識別することができる。【００３６】
そして、図２に示すように、１つのＳＡＥベアラにつき無線ベアラ、Ｓ１ベアラ、Ｓ５ベアラは１つずつ使用され、各ノード（エンティティ）で１対１に対応付けられる。【００３７】
従って、例えば、ｅＮＢ２０は、Ｓ−ＧＷ３０−２からパケットを受信し、当該パケットを無線リンクに送信する場合、受信パケットのＴＥＩＤを参照し、当該ＴＥＩＤをキーとして図２に示すような対応関係を基に、どのＲＢＩＤを受信パケットに付加すればよいかがわかる。【００３８】
なお、ＳＡＥベアラを確立するには、各インタフェースでのベアラを確立することが必要になる。ベアラ確立は、ＵＥ１０から起動することもできるし、ネットワーク側のエンティティから起動することもできる。後者の場合、ＵＥ１０間で通話（ＶｏＩＰサービス）等を行なうためにベアラの確立が必要になると、次のような手順でベアラが確立される。【００３９】
（１）発呼側のＵＥ１０−１は、ＩＭＳサーバ（ＣＳＣＦ）５０宛にベアラの確立を要求するＳＩＰ（Session Initiation Protocol）メッセージ（I NVITE）を送る。このINVITEメッセージには、宛先のＵＥ１０−２を特定する情報（ＩＰアドレス）が含まれる。
（２）ＩＭＳサーバ５０は、前記ＩＰアドレスを基に宛先のＵＥ１０−２宛にＳＩＰメッセージ（INVITE）を送る。
（３）ＵＥ１０−２は、前記ＳＩＰ（INVITE）メッセージを受信し、了解（応答）するならその旨を表す応答メッセージ（２００  ＯＫ）をＩＭＳサーバ５０宛に送信する。
（４）ＩＭＳサーバ５０は、前記了解をＵＥ１０−２から受信すると、ＵＥ１０−１とＵＥ１０−２との間のベアラを確立し、ＵＥ１０−１、ＵＥ１０−２にそれぞれ準備ができたことを知らせる。【００４０】
ここで、ＵＥ１０−１とＵＥ１０−２との間のベアラ確立は、例えば図３に示すように、ＩＭＳサーバ５０から、ＰＣＲＦ４０、ＧＷ３０（ＰＤＮ−ＧＷ３０−３、Ｓ−ＧＷ３０−２、ＭＭＥ３０−１）、ｅＮＢ２０−１及び２０−２、ＵＥ１０−１及び１０−２の順にベアラ確立を要求するメッセージを送信し（ステップＳ４１〜Ｓ４３、Ｓ４８〜Ｓ５０）、これに対する応答メッセージが、ＵＥ１０−１及び１０−２から、ｅＮＢ２０−１及び２０−２、ＧＷ３０、ＩＭＳサーバ５０の順に送られることで完了する（ステップＳ４４〜Ｓ４７、Ｓ５１〜Ｓ５２）。【００４１】
図３に示す例では、ベアラ確立を要求するメッセージとして、ＰＣＣ決定通知（Policy and Charging Control decision proposition）、個別ベアラ生成要求（Create Dedicated Bearer Request）、無線ベアラ確立要求（Radio Bearer Setup Response）〕が送信され、それぞれのメッセージに対する応答として、無線ベアラ確立応答（Ra dio Bearer Setup Response）、個別ベアラ生成応答（Create Dedicated Bearer Response），ＰＣＣ決定通知確認（PCC decision proposition ACKnowledgement）〕が送信される様子を示している。【００４２】
ただし、図３に示す例では、ＭＭＥ３０−１、Ｓ−ＧＷ３０−２及びＰＤＮ−ＧＷ３０−３の各エンティティをまとめてＧＷ３０と表記している（以降、同様）。また、ＰＣＲＦ４０の図示は省略している。さらに、図３に示す例において、ｅＮＢ２０−１は発呼側のＵＥ１０−１が接続しているｅＮＢ、ｅＮＢ２０−２は宛先（着呼側）のＵＥ１０−２が接続しているｅＮＢである。「接続している」とは、ベアラが確立されている状態を意味する。【００４３】
以降の説明において、ＵＥ１０−１とＵＥ１０−２とを区別しない場合には、単に「ＵＥ１０」と表記し、同様に、ｅＮＢ２０−１とｅＮＢ２０−２とを区別しない場合には、単に「ｅＮＢ２０」と表記する。また、発呼側のＵＥ１０−１が接続しているｅＮＢ２０−１は発側ｅＮＢ２０−１と、着呼側のＵＥ１０−２が接続しているｅＮＢ２０−２は着側ｅＮＢ２０−２とそれぞれ表記することがある。さらに、逆方向の通信に着目すれば、発呼側と着呼側とは上記の例とは逆の関係になる。【００４４】
また、ＵＥ１０とＣＳＣＦ（ＩＭＳサーバ）５０とを除く各エンティティは、無線アクセス網及びコア網の一部又は全部を含むネットワークの構成要素（エンティティ）と位置付けることができる。そして、ｅＮＢ２０及びＧＷ３０は、いずれも当該ネットワークにおいてデータ（パケット）を転送するデータ（パケット）転送装置として位置付けることができ、ＩＭＳサーバ５０は、当該ネットワークにおける通信（セッション、ベアラ）を管理、制御する制御装置として位置付けることができる。【００４５】
（１．２）ヘッダ圧縮技術
携帯電話網では、無線区間のリソースを有効に使うことが重要である。そのため、ＵＥ１０とｅＮＢ２０との間のパケット通信には、ＲＯＨＣOLE_LINK1（RObust Header Compression）OLE_LINK1と呼ばれるヘッダ圧縮技術を用いることが有効である。【００４６】
ＲＯＨＣでは、ＰＤＣＰ（Packet Data Convergence Protocol）パケットのペイロードに収容されるユーザデータ（ＩＰパケット）のヘッダを動的に圧縮する。例えば、ユーザデータがＲＴＰ（Real Time Protocol）パケットの場合、図４に示すように、ＩＰヘッダ、ＵＤＰ（User Datagram Protocol）ヘッダ、ＲＴＰヘッダが圧縮対象となる。なお、図４に示す例では、ＲＯＨＣによってＲＴＰ／ＵＤＰ／ＩＰヘッダがＲＯＨＣヘッダに置き換えられる様子を示している。【００４７】
ＰＤＣＰについては、前記の非特許文献６（3GPP TS 25.323 V7.4.0）に定義があり、ヘッダ圧縮については、同文献６の第５．１章に記述がある。また、ＲＯＨＣについては、前記の非特許文献７（IETF RFC 3095）に定義がある。【００４８】
ＲＯＨＣのプロトコルでは、コンテキスト識別子（ＣＩＤ）と呼ばれる識別子が規定されており、１つの通信路で複数のフローを管理できる。【００４９】
ＲＯＨＣの概念図を図５に示す。この図５に示すように、パケットヘッダを圧縮して送信する側（圧縮側）は、フロー（パケットの宛先）、パケットヘッダ中のフィールド値等を、コンテキストと呼ばれる圧縮に関する内部状態のデータで管理する。受信側（伸張側、）も同様にコンテキストを管理する。【００５０】
送信側（圧縮側）は、このコンテキスト毎にＣＩＤを割り当て、ヘッダ圧縮済みのパケット（以下、圧縮パケットあるいはＲＯＨＣパケットともいう）に付加して送信する。受信側（伸張側）は、受信した圧縮パケットに付加されたＣＩＤを基に、どのコンテキストを使って伸張処理を行なえばよいかを識別することができる。【００５１】
〔２〕一実施形態
（２．１）全体的な動作概要
以下に説明する実施形態では、前記ＳＡＥにおいてＵＥ１０−１とＵＥ１０−２とが通信（例えば、ＶｏＩＰ通信）を行なう場合に、図６に示すような動作（パケット転送）を可能とする。ただし、ＵＥ１０−１（第１の通信端末）を発呼側、ＵＥ１０−２を着呼側（第２の通信端末）と仮定する。【００５２】
（１）発呼側のＵＥ１０−１は、ｅＮＢ２０やＧＷ３０等のネットワーク側のエンティティ（以下、ネットワークエンティティともいう）での伸張及び圧縮処理を省略（バイパス）するフローの圧縮パケット（ＲＯＨＣパケット）を送信する際、その圧縮パケットについては伸張処理が不要（省略可）であることを表す情報（バイパス識別子；第１の情報要素）を付加して送信する（図６の符号Ｂ参照）。【００５３】
前記バイパス識別子は、好ましくは、後述するように使用可能な複数のＣＩＤのうちの特定（範囲）のＣＩＤとして定義（設定）する。そうすれば、ＣＩＤとは個別の識別子を用いる必要がない。その設定は、ネットワークエンティティ（ｅＮＢ２０、ＧＷ３０等）間で転送されるフロー間で重複しないように行なうのが望ましい。【００５４】
また、バイパス識別子としてのＣＩＤは、ネットワークエンティティ（例えば、ＩＭＳサーバ５０）から割り当てる（指定する）ことができる。その割り当てのタイミングは、少なくともＵＥ１０−１が圧縮パケットの送信を開始する前であればよい。【００５５】
好ましくは、例えば、ＵＥ１０−１のアプリケーション（ＶｏＩＰの通信アプリケーション等）が接続処理を開始してＩＭＳサーバ５０がベアラ確立処理を実施する過程でＩＭＳサーバ５０からＵＥ１０−１に指示する（図６中の符号Ａ参照）。その際、好ましくは、ベアラ確立処理で用いるメッセージを利用する。そうすれば、メッセージ数、処理量、通信開始までの時間を増大させることがない。【００５６】
（２）発呼側のＵＥ１０−１が接続しているネットワークエンティティ（ｅＮＢ２０−１）は、ＵＥ１０−１から受信した圧縮パケットのＣＩＤが特定のＣＩＤ（バイパス識別子）であるか否かを判定することにより、ヘッダ伸張処理の要否を判定する。なお、「接続している」とは、ベアラが確立されている状態を意味する。【００５７】
その結果、ヘッダ伸張処理が不要であれば、当該ネットワークエンティティ（ｅＮＢ２０−１）は、前記圧縮パケットをヘッダ伸張せずにカプセル化（トンネル用のＧＴＰヘッダを付加）して、宛先ＵＥ１０−２が接続しているネットワークエンティティ（ｅＮＢ２０−２）へ転送（トンネル）する（図６の符号Ｃ，Ｄ参照）。なお、図６には、トンネル経路へ送るパケット（以下、トンネルパケットともいう）がＧＷ３０にてＵＥ１０−２へ折り返される様子を示しているが、トンネル経路が設定できるなら、このような折り返しでなくてもよい。【００５８】
トンネルパケットには、好ましくは、宛先ＵＥ１０−２の接続しているネットワークエンティティ（ｅＮＢ２０−２）がその宛先ＵＥ１０−２を特定（識別）できる情報を付加する。そうすれば、トンネルパケットを受信したネットワークエンティティ（ｅＮＢ２０−２）は、他の装置に問い合わせ等を行なうことなく、宛先ＵＥ１０−２を特定することが可能となる。例えば、ｅＮＢ２０−２から宛先ＵＥ１０−２へのＤＬの無線ベアラを識別するＲＢＩＤや、このＲＢＩＤと関連付けられた情報（ＤＬのＴＥＩＤ）を用いることができる。【００５９】
（３）トンネルパケットを受信したネットワークエンティティ（ｅＮＢ２０−２）は、当該パケットをデカプセル化（ＧＴＰヘッダを除去）して圧縮データを取り出し、宛先ＵＥ１０−２に送信する。【００６０】
なお、宛先ＵＥ１０−２がＲＯＨＣのプロトコルをサポートしていない場合は、３ＧＰＰで規定されている動作どおり、ｅＮＢ２０−１で圧縮パケットを伸張し、伸張したＩＰパケットを宛先ＵＥ１０−２に送信する。【００６１】
以上の、発呼側ＵＥ１０−１から宛先ＵＥ１０−２にパケットが到達するまでの過程（パケット送信過程）において、本実施形態では、例えば図７に示すように、複数種類のパケットフォーマットを使用する。【００６２】
即ち、ＵＥ１０−１は、ＲＯＨＣプロトコルをサポートするＵＥ１０−２にパケットを送信するとき、ＲＯＨＣ処理スタックにより、ＲＯＨＣプロトコルに従ってパケットヘッダを圧縮する。このとき、接続開始時にネットワーク側（ＩＭＳサーバ５０）から指示された前記バイパス識別子の一例としてのＣＩＤを使用する。【００６３】
そして、ＵＥ１０−１は、圧縮パケット（前記ＣＩＤを含むＲＯＨＣパケット）に、宛先ＵＥ１０−２が接続しているｅＮＢ２０−２のＳ１インタフェースに割り当てられたＴＥＩＤ（第２の情報要素）を付加する。このＴＥＩＤは、ｅＮＢ２０−２から宛先ＵＥ１０−２への方向であるダウンリンク（ＤＬ）用であるから、図７では「DL TEID」と表記している。【００６４】
ＴＥＩＤは、図７の（１）に示すように、ＰＤＣＰパケットのペイロードとして、好ましくは、ＲＯＨＣパケットの末尾に付加する。そうすれば、このパケットを受信するｅＮＢ２０−１のプロトコル処理スタックのうち、既存のパケットフォーマットから逸脱する部分をＲＯＨＣ（ＰＤＣＰ）処理スタックにとどめることが可能となる。【００６５】
つまり、発呼側のＵＥ１０−１は、圧縮データを送信する際に、第１の情報要素であるＣＩＤと、第２の情報要素であるＴＥＩＤとを、ＲＯＨＣプロトコル（ヘッダ伸張処理）の属するレイヤ（ＰＤＣＰ層）で処理される情報（ＰＤＣＰペイロード）として前記圧縮データに付加する。【００６６】
なお、前記ＣＩＤとＴＥＩＤとは、それぞれ、ＩＭＳサーバ５０から事前に発呼側のＵＥ１０−１に指示（通知）する。例えば、宛先ＵＥ１０−２がＲＯＨＣプロトコルをサポートしている場合、ＩＭＳサーバ５０は、発呼側のＵＥ１０−１に対して、予め決められた範囲内からＣＩＤと、宛先ＵＥ１０−２が接続しているｅＮＢ２０−２とＧＷ３０との間のベアラのＴＥＩＤを選んで送信する。その詳細については図８により後述する。【００６７】
発呼側のＵＥ１０−１は、ＰＤＣＰ及びＲＬＣの処理スタックにより、図７の（１）に示すように、これらのＲＯＨＣパケットとＴＥＩＤとをＰＤＣＰパケットのペイロードに格納し、ＰＤＣＰヘッダ及びＲＬＣ（Radio Link Control）ヘッダを付加してｅＮＢ２０−１に送信する。【００６８】
ｅＮＢ２０−１は、ＵＥ１０−１から受信したパケット（ＲＬＣパケット）を解析する。即ち、ｅＮＢ２０−１は、ＲＬＣ及びＰＤＣＰの処理スタックにより受信パケットのＲＬＣヘッダ及びＰＤＣＰヘッダを終端する。そして、ＰＤＣＰ処理スタックが、ＲＯＨＣ処理スタックを起動し、ＲＯＨＣ処理スタックは、前記終端後のＲＯＨＣパケットに含まれる前記ＣＩＤを読み取る。【００６９】
ｅＮＢ２０−１（ＲＯＨＣ処理スタック）は、このＣＩＤを基に、ｅＮＢ２０−１が保有、管理する対応表（コンテキストデータ）を参照し、受信したＲＯＨＣパケットが伸張処理を省略（バイパス）すべきパケットかどうかを判定する。【００７０】
ＣＩＤが伸張処理を省略すべきことを示していた場合、ｅＮＢ２０−１のＲＯＨＣ処理スタックは、前記ＣＩＤを基にｅＮＢ２０−１が保有、管理する対応表（コンテキストデータ）を参照し、転送先（ｅＮＢ２０−２へのＧＴＰトンネル）を特定する。【００７１】
そして、ｅＮＢ２０−１は、ＰＤＣＰペイロードの末尾から前記ＴＥＩＤを読み出し、ＰＤＣＰパケットの前に当該ＴＥＩＤを配置し直し、さらにｅＮＢ２０−２宛のＧＴＰトンネルを表す情報を含むヘッダ（ＧＴＰヘッダ）を付けて（カプセル化して）ＧＷ３０に送信する（図７の（２）参照）。【００７２】
つまり、データ転送装置としてのｅＮＢ２０は、圧縮データをトンネル経路に送信する際に、第２の情報要素であるＴＥＩＤを、ＲＯＨＣプロトコル（ヘッダ伸張処理）の属するレイヤ（ＰＤＣＰ層）よりも下位のレイヤで処理される情報（ＧＴＰペイロード）として前記圧縮データに付加する。なお、このようにＴＥＩＤを配置し直す理由については後述する。【００７３】
ＧＷ３０では、ＧＴＰ処理スタックにより、ｅＮＢ２０−１から受信したＧＴＰパケット（トンネルパケット）をそのＧＴＰヘッダの内容に従ってｅＮＢ２０−２に転送する（図７の（３）参照）。なお、トンネル経路についての情報はＧＷ３０に予め登録されているものとする。詳細については後述する。また、ｅＮＢ２０−１からｅＮＢ２０−２へ直接転送が可能な経路が存在する場合は、ＧＷ３０を経由せずにｅＮＢ２０−１からｅＮＢ２０−２へＧＴＰパケットを直接転送することも可能である。【００７４】
ｅＮＢ２０−２は、ＧＴＰ処理スタックにより、ＧＷ３０から（あるいはｅＮＢ２０−１から直接）受信したＧＴＰパケットをデカプセル化してＧＴＰペイロードとして含まれているＴＥＩＤとＰＤＣＰパケットとを読み出す。【００７５】
そして、ｅＮＢ２０−２は、ＰＤＣＰ処理スタックによりＲＯＨＣ処理スタックを起動し、ｅＮＢ２０−２が保有、管理する対応表を基に前記読み出したＴＥＩＤに対応するＲＢＩＤを特定し、当該ＲＢＩＤをＲＬＣヘッダに含むＵＥ１０−２宛のＲＬＣパケットをＲＬＣ処理スタックにより生成してＵＥ１０−２へ送信する（図７の（４）参照）。【００７６】
ＵＥ１０−２は、ｅＮＢ２０−２から受信したＲＬＣパケットのＲＬＣヘッダをＲＬＣ処理スタックにより終端してＰＤＣＰパケットを取り出し、ＰＤＣＰ処理スタックによりＰＤＣＰヘッダを終端してＲＯＨＣパケットを取り出し、ＲＯＨＣ処理スタックによりＲＯＨＣパケットを伸張し、復元したパケットをＵＥ１０−２のアプリケーション層に渡す。【００７７】
なお、バイパス識別子としては、ＣＩＤを用いる他に、下位のプロトコルの識別子、例えば送信側ＲＢＩＤ等を用いることも可能である。この場合は発呼側のＵＥ１０−１が自由にＲＯＨＣのＣＩＤを選べることになる。ただし、この場合、ＲＯＨＣの圧縮パケットが宛先側のｅＮＢ２０−２から宛先ＵＥ１０−２に送られるとき、ベアラに多重される他のフローとの関係で同じＣＩＤを付加しないことを保証する必要がある。そのため、ＲＢＩＤとＣＩＤの両方で識別子の範囲を予約する必要があり、非効率といえる。したがって、上述のごとく上位層の識別子であるＣＩＤをバイパス識別子として使用する方が好ましいといえる。【００７８】
また、宛先側のｅＮＢ２０−２が受信パケットを転送するＵＥ１０−２を発見（識別）するには、ＴＥＩＤを用いる他に、宛先ＵＥ１０−２側のＲＢＩＤを用いることも可能である。この場合、Ｓ１インタフェースよりも上位のベアラを使用しない形態がとれるという利点がある。ただし、この場合は、ｅＮＢ２０−２において既存の処理とは異なる処理をしなければならない。また、ベアラ設定手順に変更が必要になる。【００７９】
これに対して、上述のごとくＴＥＩＤを用いる場合、宛先側のｅＮＢ２０−２は、発呼側のｅＮＢ２０−１で伸張処理を施されて転送されたトンネルパケットと伸張処理を施されずに転送された非トンネルパケットとを同じ処理で宛先ＵＥ１０−２を特定することが可能となる。【００８０】
即ち、宛先側のｅＮＢ２０−２は、ＧＷ３０からパケットを受信した場合、そのパケットがトンネルパケットかそうでないかに関わらず、当該パケットに付加されているＴＥＩＤを基に宛先ＵＥ１０−２へのベアラを識別し、識別したベアラに対応するＲＢＩＤを付加して宛先ＵＥ１０−２への無線リンクに送信することができる。そして、この処理の間に、ｅＮＢ２０−２は、ベアラのＱｏＳに従って待ち行列にパケットを入れる等の、ベアラ毎の処理をすることができる。【００８１】
換言するなら、ＴＥＩＤを用いることで、ｅＮＢ２０−２は、Ｓ−ＧＷ３０−２からＳ１インタフェース経由でパケットを受信したときと同じ処理で受信パケットを扱うことが可能となる。そのため、ｅＮＢ２０−２での処理を簡単にするという観点から、トンネルパケットにはＴＥＩＤを付加することとするのが好ましいといえる。【００８２】
（２．２）ベアラ設定（確立）シーケンス
次に、前記パケット送信過程で使用するＣＩＤ、ＴＥＩＤを、ネットワーク側（ＩＭＳサーバ５０）から発呼側のＵＥ１０−１に指示（指定）する例について説明する。【００８３】
本例では、発呼側のＵＥ１０−１が宛先ＵＥ１０−２に対する接続処理を開始した際に、ＩＭＳサーバ５０を経由して発呼側のＵＥ１０−１と宛先（着呼側）のＵＥ１０−２との間（エンド−エンド間）でベアラ確立処理（ベアラセットアップ）のために送受されるメッセージを用いて、ＣＩＤ、ＴＥＩＤを発呼側のＵＥ１０−１に通知する。【００８４】
例えば図８に示すように、ＵＥ１０−１がＵＥ１０−２への接続を開始する場合、ＵＥ１０−１は、ＳＩＰのINVITEメッセージをＩＭＳサーバ（ＣＳＣＦ）５０宛に送信する（ステップＳ１）。【００８５】
ＩＭＳサーバ５０は、当該INVITEメッセージを受信すると、そのメッセージに含まれる宛先ＩＰアドレスを基に、宛先ＵＥ１０−２宛にINVITEメッセージを送信する（ステップＳ２）。【００８６】
ＵＥ１０−２は、ＩＭＳサーバ５０から前記INVITEメッセージを受信し、ＵＥ１０−１からの呼び出しに対して応答すると、呼び出し成功の旨を表す応答メッセージ（２００ ＯＫ）をＩＭＳサーバ５０に返信する（ステップＳ３）。なお、「２００」はメッセージの状態コード（レスポンスコード）を表し、他に、発信処理中（Trying）を表すコード（１００）や、呼び出し中（ringing）を表すコード（１８０）等がある。ただし、図８において、これらのシーケンスの図示は省略している。【００８７】
ＩＭＳサーバ５０は、宛先ＵＥ１０−２から前記応答メッセージ（２００ ＯＫ）を受信すると、図３に示したベアラ確立プロシージャを実行して、発呼側のＵＥ１０−１と着呼側のＵＥ１０−２との間のセッション（ベアラ）を確立する（ステップＳ４）。【００８８】
本例では、このベアラ確立処理の過程で送受信される各応答メッセージ（ACKnowledgement，Response）を使って、ＴＥＩＤをＩＭＳサーバ５０まで伝える。これにより、ＩＭＳサーバ５０は、ｅＮＢ２０−１，２０−２のＴＥＩＤ（DL_TEID）を知ることができる。また、ｅＮＢ２０−１，２０−２は、前記応答メッセージにて、自局の識別情報（ｅＮＢＩＤ）をＩＭＳサーバ５０に伝える。これにより、ＩＭＳサーバ５０は、ｅＮＢ２０−１，２０−２毎に、伸張処理をバイパスするＣＩＤを管理することが可能となる。【００８９】
ＩＭＳサーバ５０は、ベアラの確立が完了すると、ＵＥ１０−１，１０−２がそれぞれＲＯＨＣで使用するＣＩＤを決定する（ステップＳ５）。即ち、双方向通信の場合であれば、ＵＥ１０−１用（ＵＥ１０−１からＵＥ１０−２への方向について）のＣＩＤと、ＵＥ１０−２用（逆方向について）のＣＩＤとを決定する。【００９０】
その際、ＵＥ１０−１用のＣＩＤは、通信相手であるＵＥ１０−２が接続しているｅＮＢ２０−２に対して割り当てられた範囲内から選択し、ＵＥ１０−２用のＣＩＤは通信相手であるＵＥ１０−１が接続しているｅＮＢ２０−１に対して割り当てられた範囲内からそれぞれ選択する。その詳細については後述する。【００９１】
ＩＭＳサーバ５０は、決定したＵＥ１０−１，１０−２用のＣＩＤと、ＴＥＩＤとを、ＳＩＰの応答メッセージ（２００ ＯＫ）で発呼側のＵＥ１０−１に伝える（ステップＳ６）。ＵＥ１０−１は、ＵＥ１０−２用のＣＩＤと、ＴＥＩＤとをＳＩＰのＡＣＫメッセージで宛先ＵＥ１０−２に伝える（ステップＳ７）。【００９２】
その際、これらのパラメータ（ＣＩＤ、ＴＥＩＤ）は、例えば、ＳＤＰ（Session Description Protocol）により、ＳＩＰメッセージのペイロードにアトリビュート（a=peer-dl-teid:xxx等）として記述することで、ＵＥ１０−１，１０−２にそれぞれ伝えることができる。【００９３】
ＵＥ１０−１、ＵＥ１０−２は、それぞれ、上述のごとく指定されたＴＥＩＤとＣＩＤとに基づいてＲＯＨＣ処理を行なって通信を開始する。即ち、ＵＥ１０−１からＵＥ１０−２への方向の通信に着目すれば、図７により前述したように、ＵＥ１０−１は、ＲＯＨＣによりヘッダ圧縮（以下、単に「圧縮」ともいう）したパケットをｅＮＢ２０−１に送信し（ステップＳ８）、ｅＮＢ２０−１は、受信したパケットをヘッダ伸張（以下、単に「伸張」ともいう）せずにＴＥＩＤを用いてカプセル化してｅＮＢ２０−２にトンネルし（ステップＳ９，Ｓ１０）、ｅＮＢ２０−２は、受信したトンネルパケットをデカプセル化した上でＵＥ１０−２に送信する（ステップＳ１１）。【００９４】
（２．３）ＣＩＤの選択方法
ＣＩＤは、次のようにして決める。まず、前記バイパス処理を実施するｅＮＢ２０に対して、それぞれ重複しないＣＩＤの範囲を割り当てる。【００９５】
例えば、ｅＮＢ２０が１００台存在するエリアで前記バイパス処理を実施するならば、次表１に示すように、ｅＮＢ＃１にはＣＩＤ＝１００−１９９、ｅＮＢ＃２にはＣＩＤ＝２００−２９９、ｅＮＢ＃３にはＣＩＤ＝３００−３９９、というように１００個ずつの互いに重複しない範囲のＣＩＤを割り当てることができる。【００９６】
【表１】
2009057204.tif 000003
【００９７】
また、ＩＭＳサーバ５０は、例えば次表２に示すようなＣＩＤ管理表（ＣＩＤ管理データ）を保有し、ｅＮＢ２０毎に、使用可能なＣＩＤの範囲を予め登録、管理する。ＩＭＳサーバ５０は、このＣＩＤ管理表を基に、ｅＮＢ２０毎に、使用可能なＣＩＤの範囲から未使用のＣＩＤ（双方向の通信に関して１つずつ）を選択して発呼側のＵＥ１０に通知することになる。【００９８】
【表２】
2009057204.tif 000004
【００９９】
さらに、ＧＷ３０は、例えば次表３に示すようなルーティングテーブルを保有し、トンネル経路（ＴＥＩＤ）毎の宛先（転送先）ｅＮＢ２０の情報（ｅＮＢＩＤ）を登録、管理する。ＧＷ３０は、このルーティングテーブルに基づいて、受信パケットのＴＥＩＤに対応する転送先ｅＮＢ２０を識別して、その転送先ｅＮＢ２０宛に受信パケットをカプセル化してトンネルすることが可能となる。つまり、ｅＮＢ２０間で直接パケットを転送できないネットワーク形態であっても適切なパケット転送が可能となる。【０１００】
【表３】
2009057204.tif 000005
【０１０１】
なお、既述のとおり、ｅＮＢ２０間で直接転送が可能な経路が存在する場合は、ＧＷ３０を経由せずにパケットを直接転送することが可能であるから、その直接転送可能な経路についてのデータは不要としてよい。【０１０２】
以上の状況において、ＵＥ１０−１がｅＮＢ２０−１に、ＵＥ１０−２がｅＮＢ２０−２にそれぞれ接続していて（ベアラが確立されていて）、ＵＥ１０−１とＵＥ１０−２との間の双方向の通信（例えば、ＶｏＩＰによる音声通話）を開始する、つまりユーザデータ（音声データ）パケットの送受信を開始する場合を考える。【０１０３】
ＩＭＳサーバ５０は、前記表２のＣＩＤ管理表を基に、ＵＥ１０−１が圧縮パケットに付加するＣＩＤとして例えば着側ｅＮＢ２０−２に割り当てられたＣＩＤの範囲のうち未使用の「２００」を選択し、ＵＥ１０−２が圧縮パケットに付加するＣＩＤとして例えば着側ｅＮＢ２０−１に割り当てられたＣＩＤの範囲のうち未使用の「１００」を選択する。【０１０４】
ＩＭＳサーバ５０は、これらＣＩＤをＵＥ１０−１、ＵＥ１０−２にそれぞれ通知して使用させると、ＵＥ１０−１が送信した圧縮パケットを受信したｅＮＢ２０−１は、前記表１を基に、ＣＩＤ＝２００の圧縮パケットはｅＮＢ２０−２へのトンネル経路に転送することが可能となる。同様に、ＵＥ１０−２が送信した圧縮パケットを受信したｅＮＢ２０−２は、前記表１を基に、ＣＩＤ＝１００の圧縮パケットはｅＮＢ２０−１へのトンネル経路に転送することが可能となる。【０１０５】
以上により、本例のシステムによれば、次のようないずれかの効果ないし利点が得られる。
（１）ＵＥ１０は、パケットを圧縮して送信しようとするとき、伸張処理が不要なフローのパケットであることを示す情報（バイパス識別子の一例としてのＣＩＤ）を当該パケットに付加することができる。【０１０６】
（２）ｅＮＢ２０において、ある通信路でＵＥ１０から送られてくる圧縮パケットの中から、ネットワーク内で伸張処理せずに宛先ＵＥ１０に送ることができるものを識別することが可能となる。【０１０７】
（３）特定の識別子（バイパス識別子の一例としてのＣＩＤ）が付加された圧縮パケットについてはネットワーク側の装置（ｅＮＢ２０、ＧＷ３０）での伸張処理と圧縮処理とが省略されるので、ネットワーク側でパケットを宛先（ＵＥ１０）に送るのに要する処理量を削減することができる。【０１０８】
（４）ネットワーク側の装置（エンティティ）間で圧縮パケットを伸張せずに転送する際、ネットワーク側の装置間でのトンネル転送時の多重化を行なうことができる。この目的に使う識別子として、ＵＥ１０が付加した識別子（ＣＩＤ）を利用することができる。したがって、ネットワーク側の装置で新たに識別子を生成して管理する必要がない。【０１０９】
（５）発呼側のＵＥ１０は、バイパス識別子の一例としての前記ＣＩＤを、接続開始時にＩＭＳサーバ５０から指示されるので、ネットワーク側のエンティティ（ｅＮＢ２０、ＧＷ３０）および宛先ＵＥ１０−２と折衝する必要がなく、指示されたＣＩＤを付加するだけでよいので、通信開始までに必要な処理量を増やすことがない。【０１１０】
（６）ネットワーク側のエンティティ（ｅＮＢ２０、ＧＷ３０）は、発呼側のＵＥ１０−１が付加したＣＩＤに従って受信パケットを伸張／圧縮することなく転送（トンネル）するだけでよいので、接続毎の変換表のような動的に管理する情報を不要にすることができる。【０１１１】
（７）宛先ＵＥ１０が接続しているネットワーク側のエンティティ（着側ｅＮＢ２０）は、パケットに付加されたＴＥＩＤから宛先ＵＥ１０−２を識別することができるので、他装置に問い合わせ等をすることなく、トンネル経路で転送されてきたパケットを適切な宛先ＵＥ１０に正しく送信することができる。【０１１２】
（８）発呼側のＵＥ１０は、宛先ＵＥ１０への接続開始時にネットワーク側（ＩＭＳサーバ５０）から指定された識別子をＲＯＨＣの圧縮機能に設定するだけでよいので、ＵＥ１０のヘッダ圧縮／伸張処理機能の変更を最小限に抑えることができる。【０１１３】
なお、前記特許文献１では、ＧＧＳＮがＲＯＨＣプロトコルを終端し、受信側と送信側のコンテキストを関門ノード（ＧＧＳＮ）において生成し、これらを関連付けることでＧＧＳＮ上でのＲＯＨＣ処理の負担を軽減しようとしている。しかし、特許文献１の方法では、ネットワーク側の単一の装置（ＧＧＳＮ）内でＵＬとＤＬのＲＯＨＣプロトコルを終端する構成でなければならない。【０１１４】
〔３〕システム構成要素の構成（機能）及び動作
次に、上述した動作を実現する、ＵＥ１０、ｅＮＢ２０、ＧＷ３０、ＩＭＳサーバ５０の各エンティティの詳細な構成（機能）及び動作の一例について、図９〜図２３を用いて詳述する。【０１１５】
（３．１）ＵＥの説明
図９はＵＥ１０の構成例を示すブロック図である。この図９に示すＵＥ１０は、例えば、ベアラ管理部１１と、ＩＭＳ処理部１２と、上位層処理部１３と、ＲＯＨＣ処理部１４と、下位層処理部１５と、アプリケーション部１６と、をそなえる。【０１１６】
なお、図９において、点線矢印Ａ、Ｂ，Ｃは、ＵＥ１０内の信号転送経路（フロー）を示しており、Ａはベアラ設定要求時のシグナルフロー、ＢはｅＮＢ２０へのシグナルフロー（送信）、ＣはｅＮＢ２０からの受信データフロー及びＵＥ１０のアプリケーション部１６からの送信データフローをそれぞれ表している。【０１１７】
即ち、Ａで示すシグナルフローは、下位層処理部１５、ＩＭＳ処理部１２、ベアラ管理部１１、上位層処理部１３、ＲＯＨＣ処理部１４、下位層処理部１５の順に経由し、その過程で上位層処理部１３、ＲＯＨＣ処理部１４、下位層処理部１５に対してベアラ設定に応じた設定を行なうことができることを示している。また、Ｂで示すシグナルフローは、ＩＭＳ処理部１２で生成されたシグナリングメッセージが下位層処理部１５で所要のプロトコル処理を受けてｅＮＢ２０へ送信されることを示している。Ｃで示すデータフローは、上位層処理部１３、ＲＯＨＣ処理部１４、下位層処理部１５を経由してそれぞれにおいて必要なプロトコル処理が施されることを示している。【０１１８】
ここで、ベアラ管理部１１は、ｅＮＢ２０との間のＤＬ及びＵＬのベアラ（無線ベアラ）を管理し、アプリケーション部１６からの要求に応じて、ＩＭＳ処理部１２と連携して、ベアラの確立処理（メッセージの生成、送受）を実施する機能を具備する。【０１１９】
ＩＭＳ処理部１２は、ベアラ管理部１１からの要求に応じたメッセージ（INV ITE、２００ ＯＫ等のＩＳＰメッセージ、ベアラ確立処理のためのメッセージ（無線ベアラ確立応答）等）の生成、生成したメッセージのｅＮＢ２０への送信、ｅＮＢ２０が送信したメッセージの受信等を行なう機能を具備する。【０１２０】
上位層処理部１３は、ＰＤＣＰ（ＲＯＨＣ）層よりも上位層で規定される処理を実施するもので、例えば、ＩＰやＵＤＰ、ＲＴＰ（ＲＴＣＰ）等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能（処理スタック）を具備する。【０１２１】
ＲＯＨＣ処理部１４は、ＰＤＣＰ層のプロトコルスタックの一つとして位置付けられるＲＯＨＣプロトコルによる送信パケットのヘッダ圧縮及び受信パケットのヘッダ伸張機能（ＲＯＨＣ処理スタック）を具備する。本例のＲＯＨＣ処理部１４は、図９中に示すような、前記バイパス処理の適否（有効／無効）を識別するフィルタデータ（リスト）１４１と、ＲＯＨＣの圧縮処理に用いるコンテキストを識別するコンテキストデータ１４２とを図示しないメモリ等に保持し、これらのデータ１４１，１４２に基づいてヘッダ圧縮処理を実施する。【０１２２】
フィルタデータ１４１には、既述のとおりＩＭＳサーバ５０から通知されたＣＩＤとＴＥＩＤとが登録される。図１の例では、特定の宛先（ＵＥ１０−２）との間の特定のプロトコル（ＲＴＰ）による通信には、ＲＯＨＣのＣＩＤとしてバイパス識別子を表すＣＩＤ＝２０１を用い、トンネル経路の識別情報（DL_TEID）＝「３３３」を付加すべきことを示すエントリが先頭に登録されている様子を示している。なお、その他のエントリについては、バイパス処理が不適（FALSE）であり、DL_TEIDも未定義となっている。【０１２３】
一方、コンテキストデータ１４２には、プロファイル（ＵＤＰ／ＩＰ、ＴＣＰ／ＩＰ、非圧縮、ＲＴＰ／ＵＤＰ／ＩＰ等）別に、ＲＯＨＣの圧縮処理に用いるＣＩＤとシーケンス番号（ＳＮ）、圧縮に関する内部状態（状態マシン）等が登録される。したがって、ＲＯＨＣ処理部１４は、このコンテキストデータ１４２を基に、前記プロファイルに応じたヘッダ圧縮処理を実施することが可能となる。【０１２４】
下位層処理部１５は、ＰＤＣＰ層よりも下位層で規定されるプロトコル処理を担当する。例えば、ＲＬＣ層やＭＡＣ（Media Access Control）層、物理（ＰＨＹ）層等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能（処理スタック）を具備する。【０１２５】
アプリケーション部１６は、ＶｏＩＰによる音声通信やＨＴＴＰやＦＴＰ等のデータ通信、その他の各種アプリケーションプログラム（ソフトウェア）を具備し、当該プログラムに応じた処理（パケットの生成、送受信等）を行なうものである。【０１２６】
（動作説明）
以下、上述のごとく構成された本例のＵＥ１０の動作について、図１０〜図１２を用いて説明する。なお、図１０はＵＥ１０が発呼側であった場合の接続開始時の動作を説明するフローチャート、図１１はＵＥ１０が着呼側であった場合の接続開始時の動作を説明するフローチャート、図１２はヘッダ圧縮動作を説明するフローチャートである。【０１２７】
（発呼側ＵＥの接続開始時の動作）
図１０に示すように、発呼側のＵＥ１０（１０−１）は、着呼側のＵＥ１０（１０−２）との通信（例えば、ＶｏＩＰによる音声通話）を行なう場合、ベアラ管理１１とＩＭＳ処理部１２とが連携して、ＳＩＰのINVITEメッセージを生成し、下位層処理部１５を通じて当該INVITEメッセージをＩＭＳサーバ５０宛に送信する（ステップＡ１）。これは、図８のステップＳ１の処理に相当する。【０１２８】
その後、ＵＥ１０−１は、着呼側のＵＥ１０−２がINVITEメッセージに対して応答（２００ ＯＫ）をＩＭＳサーバ５０に送信し、ＩＭＳサーバ５０が、ベアラ確立処理を開始することにより、ＩＭＳサーバ５０が送信した無線ベアラ確立要求（Radio Bearer Setup Request）（図３のステップＳ４３参照）を、ＵＥ１０−１が接続しているｅＮＢ２０−１から受信すると（ステップＡ２）、ベアラ管理部１１により無線ベアラの設定を行なう（ステップＡ３）。【０１２９】
次いで、ＵＥ１０−１は、ＩＭＳ処理部１２により、前記無線ベアラ確立要求（Radio Bearer Setup Request）に対する応答（Radio Bearer Setup Response）を生成し、ｅＮＢ２０−１に送信する（ステップＡ４）。これは、図３のステップＳ４４の処理に相当する。【０１３０】
その後、ＩＭＳサーバ５０主導のベアラの確立処理が完了して、ＩＭＳサーバ５０からＳＩＰメッセージ（２００ ＯＫ）を受信すると（ステップＡ５）、ＵＥ１０−１は、ＩＭＳ処理部１２により、当該ＳＩＰメッセージに、ＣＩＤとＴＥＩＤとがパラメータとして設定されているか否かを確認する（ステップＡ６）。【０１３１】
その結果、設定されていなければ（ステップＡ６でＮＯなら）、ＵＥ１０−１（ＩＭＳ処理部１２）は、受信した前記ＳＩＰメッセージ（２００ ＯＫ）に対する確認応答（ＡＣＫ）メッセージを生成し、下位層処理部１５を通じて着呼側のＵＥ１０−２宛に送信する（ステップＡ９）。【０１３２】
一方、前記ＳＩＰメッセージ（２００ ＯＫ）にＣＩＤとＴＥＩＤとが設定されていれば（つまり、図８のステップＳ６で述べたＳＩＰメッセージを受信すれば）、ＵＥ１０−１（ＩＭＳ処理部１２）は、これらのパラメータをＲＯＨＣのヘッダ圧縮に使用するＣＩＤ及びＴＥＩＤとして、ベアラ管理部１１及び上位層処理部１３を介してＲＯＨＣ処理部１４に設定する（ステップＡ６のＹＥＳルートからステップＡ７）。【０１３３】
次いで、ＵＥ１０−１（ＩＭＳ処理部１２）は、着呼側のＵＥ１０−２が送信パケットを圧縮するときに使用するＣＩＤ及びＴＥＩＤをパラメータとして含むＳＩＰのＡＣＫメッセージを生成し、下位層処理部１５を通じて着呼側のＵＥ１０−２宛に送信する（ステップＡ８）。これは、図８のステップＳ７で述べた処理に相当する。【０１３４】
（着呼側ＵＥの接続開始時の動作）
これに対し、図１１に示すように、着呼側のＵＥ１０−２は、図８のステップＳ３で示したＳＩＰのINVITEメッセージをＩＭＳサーバ５０から受信し（ステップＡ１１）、発呼側のＵＥ１０−１との通信開始を了解するなら、ＩＭＳ処理部１２により、当該INVITEメッセージに対する応答メッセージ（２００ ＯＫ）を生成し、下位層処理部１５を通じてＩＭＳサーバ５０宛に送信する（ステップＡ１２）。これは、図８のステップＳ３での処理に相当する。【０１３５】
その後、ＩＭＳサーバ５０が、ベアラ確立処理を開始することにより、ＩＭＳサーバ５０が送信した無線ベアラ確立要求（Radio Bearer Setup Request）（図３のステップＳ５０参照）を、ＵＥ１０−２が接続しているｅＮＢ２０−２から受信すると（ステップＡ１３）、ベアラ管理部１１により無線ベアラの設定を行なう（ステップＡ１４）。【０１３６】
次いで、ＵＥ１０−２は、ＩＭＳ処理部１２により、前記無線ベアラ確立要求（Radio Bearer Setup Request）に対する応答（Radio Bearer Setup Response）を生成し、ｅＮＢ２０−２に送信する（ステップＡ１５）。これは、図３のステップＳ５１の処理に相当する。【０１３７】
その後、ＵＥ１０−２は、図８のステップＳ７（図１０のステップＡ８又はＡ９）で示した、発呼側のＵＥ１０−１が送信したＳＩＰのＡＣＫメッセージを受信すると（ステップＡ１６）、ＩＭＳ処理部１２により、当該ＡＣＫメッセージに、自局１０−２が使用するＴＥＩＤとＣＩＤとがパラメータとして設定されているか否かを確認する（ステップＡ１７）。【０１３８】
その結果、前記パラメータが設定されていなければ、ＵＥ１０−２は、接続開始処理を終了して、既述のバイパス処理を行なわない通常通りの通信をＵＥ１０−１との間で実施する（ステップＡ１７のＮＯルート）。【０１３９】
一方、前記パラメータが設定されていれば（つまり、図８のステップＳ７に示したＳＩＰメッセージを受信すれば）、ＵＥ１０−２（ＩＭＳ処理部１２）は、これらのパラメータをＲＯＨＣのヘッダ圧縮に使用するＣＩＤ及びＴＥＩＤとして、ベアラ管理部１１及び上位層処理部１３を介してＲＯＨＣ処理部１４に設定する（ステップＡ１７のＹＥＳルートからステップＡ１８）。【０１４０】
（ＵＥのヘッダ圧縮動作）
前記のように、発呼側のＵＥ１０−１、着呼側のＵＥ１０−２のそれぞれにおけるＲＯＨＣ処理部１４に対して前記パラメータ（ＣＩＤ及びＴＥＩＤ）が設定されると、ＲＯＨＣ処理部１４は、図１２に示すフローチャートに従って送信パケットのヘッダ圧縮処理を実施する。【０１４１】
即ち、ＲＯＨＣ処理部１４は、送信パケットが存在すると、前記フィルタデータ１４１を参照、検索し（ステップＡ２１）、設定されたＣＩＤ及びＴＥＩＤに該当するエントリが存在するか否かを確認する（ステップＡ２２）。【０１４２】
その結果、該当エントリが存在しなければ、ＲＯＨＣ処理部１４は、送信パケットのアドレス、プロトコルを基に、APPLY＝FALSE、DL_TEID＝未定義、CID＝未定義とした新規エントリを作成する（ステップA２２のＮＯルートからステップＡ２３）。【０１４３】
一方、該当エントリが存在していれば、ＲＯＨＣ処理部１４は、当該送信パケットのヘッダ圧縮処理について使用する一時変数として、当該エントリの内容（APPLY、DL_TEID、CID）をストアし（ステップＡ２４）、ＣＩＤが定義済みであるか否かを確認する（ステップＡ２５）。【０１４４】
その結果、未定義であれば（ステップＡ２５でＮＯなら）、ＲＯＨＣ処理部１４は、バイパス（トンネル）対象のパケットについてのＣＩＤ以外の未使用のＣＩＤを割り当ててフィルタリスト１４１にストアし（ステップＡ２６）、そのＣＩＤのコンテキストでヘッダ圧縮を行なう（ステップＡ２７）。一方、ＣＩＤが定義済みであれば（ステップＡ２５でＹＥＳなら）、ＲＯＨＣ処理部１４は、そのＣＩＤのコンテキストでヘッダ圧縮を行なう（ステップＡ２７）。なお、当該ＣＩＤは、ＲＯＨＣパケットのヘッダ情報要素となる。【０１４５】
そして、ＲＯＨＣ処理部１４は、前記一時変数「APPLY」が「TRUE」となっているか否かを確認し（ステップＡ２８）、「TRUE」であれば（ステップＡ２８でＹＥＳなら）、DL_TEIDを送信パケットの末尾に付加（連結）して（ステップＡ２９）、ヘッダ圧縮処理を完了する。一方、「FALSE」であれば（ステップＡ２８でＮＯなら）、ＲＯＨＣ処理部１４は、ヘッダ圧縮処理を終了する。【０１４６】
つまり、本例のＲＯＨＣ処理部１４は、宛先ＵＥ１０−２宛の圧縮データに、ヘッダ伸張処理の要否と宛先ＵＥ１０−２へのトンネル経路とを識別するのに用いられる情報（ＣＩＤ，ＴＥＩＤ）を付加する付加手段として機能する。また、下位層処理部１５は、前記情報が付加された圧縮データをネットワークへ送信する送信手段として機能する。【０１４７】
なお、受信パケットのヘッダ伸張処理については、既存の処理と同様であるので、説明を省略する。【０１４８】
（３．２）ｅＮＢの説明
図１３はｅＮＢ２０の構成を示すブロック図である。この図１３に示すｅＮＢ２０は、例えば、ベアラ管理部２１と、シグナル処理部２２と、上位層処理部２３と、ＲＯＨＣ処理部２４と、下位層処理部２５と、をそなえる。【０１４９】
この図１３においても、点線矢印Ａ〜Ｅは、ｅＮＢ２０内の信号転送経路（フロー）を示しており、Ａはベアラ設定要求時のシグナルフロー、ＢはＵＥ１０又はＧＷ３０へのシグナルフロー、Ｃは他のｅＮＢ２０からのデータフロー、ＤはＧＷ３０からのデータフロー、ＥはＵＥ１０からのユーザデータフローをそれぞれ表している。【０１５０】
即ち、Ａで示すシグナルフローは、下位層処理部２５、シグナル処理部２２、ベアラ管理部２１、上位層処理部２３、ＲＯＨＣ処理部２４、下位層処理部２５の順に経由し、その過程で上位層処理部２３、ＲＯＨＣ処理部２４、下位層処理部２５に対してベアラ設定に応じた設定を行なうことができることを示している。また、Ｂで示すシグナルフローは、シグナル処理部２２で生成されたシグナリングメッセージが下位層処理部２５で所要のプロトコル処理を受けてＵＥ１０又はｅＮＢ２０へ送信されることを示している。【０１５１】
Ｃで示すデータフローは、ｅＮＢ２０から受信したパケットが下位層処理部２５、上位層処理部２３、下位層処理部２５の順に経由してそれぞれにおいて必要なプロトコル処理が施されて他のｅＮＢ２０へ送信されることを示している。Ｄで示すデータフローは、ＧＷ３０から受信したパケットが、下位層処理部２５、上位層処理部２３、ＲＯＨＣ処理部２４、下位層処理部２５の順に経由して処理されることを表している。Ｅで示すデータフローは、ＵＥ１０から受信したパケットが、下位層処理部２５、ＲＯＨＣ処理部２４、上位層処理部２３、下位層処理部２５の順に経由して処理されることを示している。【０１５２】
ここで、ベアラ管理部２１は、ＵＥ１０側（ＤＬ）及びＧＷ３０側（ＵＬ）のベアラを管理し、シグナル処理部２２と連携して、ＤＬ及びＵＬのベアラ確立処理（メッセージの生成、送受）を実施する機能を具備する。【０１５３】
シグナル処理部２２は、ベアラ管理部２１からの要求に応じたメッセージ（ＵＥ１０宛の無線ベアラ確立要求、ＧＷ３０宛の個別ベアラ生成応答等）の生成、生成したメッセージのＵＥ１０又はＧＷ３０への送信、ＵＥ１０又はＧＷ３０が送信したメッセージ（無線ベアラ確立応答、個別ベアラ生成要求等）の受信等を行なう機能を具備する。【０１５４】
上位層処理部２３は、ＰＤＣＰ（ＲＯＨＣ）層よりも上位層で規定される処理を実施するもので、例えば、ＩＰやＵＤＰ、ＲＴＰ（ＲＴＣＰ）等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能を具備する。この上位層処理部２３は、ＲＯＨＣ処理部２４で伸張処理を施されずに転送されてきた受信パケット（トンネルパケット）を、下位層処理部２５を通じてＧＷ３０へ転送する役割を担う。【０１５５】
ＲＯＨＣ処理部２４は、ＲＯＨＣによる送信パケットのヘッダ圧縮及び受信パケットのヘッダ伸張機能を具備する。本例のＲＯＨＣ処理部２４は、図１３中に示すような、フィルタデータ（リスト）２４１と、コンテキストデータ２４２とを図示しないメモリ等に保持し、これらのデータ２４１，２４２に基づいてＲＯＨＣパケットのヘッダ圧縮、伸張処理を実施する。【０１５６】
ここで、フィルタリスト２４１は、ＵＥ１０におけるフィルタリスト１４１と同じ内容のリストであり、前記バイパス処理の適否（有効／無効）を識別するのに用いられるデータである。ただし、ｅＮＢ２０において、バイパス処理を適用するＣＩＤと、ＴＥＩＤとは予め登録される。【０１５７】
したがって、ＲＯＨＣ処理部２４は、ＵＥ１０から受信したＲＯＨＣパケットに、フィルタリスト２４１に登録されているエントリのＣＩＤ，ＴＥＩＤが設定されていると、当該ＲＯＨＣパケットをヘッダ伸張せずに上位層処理部２３に転送することとなる。【０１５８】
コンテキストデータ２４２は、ＲＯＨＣのヘッダ圧縮処理に用いるコンテキストを識別するのに用いられるデータであり、図１３中に示すように、各ｅＮＢ２０に共通の対応表２４２ａと、ＵＥ１０のベアラ毎の対応表２４２ｂとを具備する。【０１５９】
対応表２４２ａは、既述の表１に相当するもので、受信パケットに付加されているＣＩＤを基にこの対応表２４２ａを参照、検索することで、転送（トンネル）先（着呼側のＵＥ１０が接続しているｅＮＢ２０）を特定することができる。【０１６０】
もう一つの対応表２４２ｂは、ＵＥ１０におけるコンテキストデータ１４１の内容と同様のもので、プロファイル（ＵＤＰ／ＩＰ、ＴＣＰ／ＩＰ、非圧縮、ＲＴＰ／ＵＤＰ／ＩＰ等）別に、ＲＯＨＣの圧縮処理に用いるＣＩＤとシーケンス番号（ＳＮ）、圧縮に関する内部状態（状態マシン）等がＵＥ１０間のベアラ単位に登録される。したがって、ＲＯＨＣ処理部２４は、この対応表２４２ｂを基に、ベアラ別に前記プロファイルに応じたヘッダ圧縮処理を実施することが可能となる。【０１６１】
下位層処理部２５は、ＰＤＣＰ層よりも下位層で規定される処理を実施するもので、例えば、ＲＬＣ層やＭＡＣ層、物理（ＰＨＹ）層等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能を具備する。【０１６２】
なお、トンネルパケットの組み立て（ＴＥＩＤの付加）は、ＴＥＩＤの特定が可能となるＲＯＨＣ処理部２４で行なう（つまり、ＰＤＣＰパケットのペイロードとしてＴＥＩＤを含める）こととしてもよいが、図７の（２）で示したフォーマットを構成する（ＧＴＰパケットのペイロードとしてＴＥＩＤを含める）場合には、下位層処理部２５でトンネルパケットの組み立てを行なうことになる。【０１６３】
その場合は、ＲＯＨＣ処理部２４で特定されたＴＥＩＤを、トンネルするＲＯＨＣパケットとともに下位層処理部２４に転送することとする。この場合には、トンネルパケットを受信した着側ｅＮＢ２０−２において、より下位層の処理（下位層処理部２５）でＴＥＩＤを特定することが可能となるから、着呼側のＵＥ１０−２へのパケット転送を早期に行なえる。【０１６４】
下位層処理部２５は、ＰＤＣＰ層よりも下位層で規定される処理を実施するもので、例えば、ＲＬＣ層やＭＡＣ層、物理（ＰＨＹ）層等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能を具備する。また、この下位層処理部２５は、図１３中に示すように、ＴＥＩＤとＲＢＩＤとの対応表（テーブル）２５１を図示しないメモリ等に保持しており、ＧＷ３０から受信したトンネルパケットに付加されている前記ＴＥＩＤを基に、この対応表２５１を参照、検索することにより、当該トンネルパケットを送信すべきＲＢＩＤ（つまり、着呼側のＵＥ１０−２への無線（ＤＬ）リンク）を識別することが可能である。【０１６５】
（動作説明）
以下、上述のごとく構成された本例のｅＮＢ２０の動作について、図１４〜図１６を用いて説明する。なお、図１４はｅＮＢ２０における接続（呼接続）開始時の動作を説明するフローチャート、図１５はＵＥ１０からＵＬのパケットを受信した場合の動作を説明するフローチャート、図１６はＧＷ３０からＤＬのパケットを受信した場合の動作を説明するフローチャートである。【０１６６】
（接続開始時の動作）
ｅＮＢ２０は、ＧＷ３０から図３のステップＳ４２又はＳ４９に示した個別ベアラ生成要求（Create Dedicated Bearer Request）メッセージを受信すると（ステップＢ１）、ベアラ管理部２１とシグナル処理部２２とが連携して、ＵＥ１０宛の前記無線ベアラ確立要求（Radio Bearer Setup Request）メッセージを生成し、下位層処理部２５を通じてＵＥ１０へ送信する（ステップＢ２）。これは、図３のステップＳ４３又はＳ５０の処理に相当する。【０１６７】
その後、ｅＮＢ２０（ベアラ管理部２１及びシグナル処理部２２）は、図３のステップＳ４４又はＳ５１に示した応答メッセージ（Radio Bearer Setup Response）を受信すると（ステップＢ３）、ＵＥ１０との間の無線ベアラを設定し（ステップＢ４）、さらに、ＧＷ３０との間の個別ベアラを設定する（ステップＢ５）。なお、これらのベアラの設定順序は逆でもよいし、並行して実施してもよい。【０１６８】
次いで、ｅＮＢ２０（ベアラ管理部２１及びシグナル処理部２２）は、個別ベアラ生成応答（Breate Dedicated Bearer Response）メッセージを生成し、下位層処理部２５を通じてＧＷ３０へ送信する（ステップＢ６）。このメッセージには、図８のステップＳ４にて述べたように、ＤＬのＴＥＩＤ（DL_TEID）と自局２０の識別情報（ｅＮＢＩＤ）とが含められる。なお、この処理は、図３のステップＳ４６又はＳ５２に示した処理に相当する。また、当該ＴＥＩＤは、ＧＷ３０から受信したＧＴＰパケットがトンネルパケットかそうでないかを判断するために、ｅＮＢ２０において記憶される。【０１６９】
（ＵＥからＵＬのパケットを受信した場合）
図１５に示すように、ｅＮＢ２０は、上述のベアラ確立処理が完了して、ＵＥ１０間で通信が開始され、ＵＥ１０からＵＬのパケットを受信すると（ステップＢ１１）、ＲＯＨＣ処理部２４にて、その受信パケットに付加されているＣＩＤを検出し、当該ＣＩＤを基にフィルタリスト２４１を参照、検索し（ステップＢ１２）、伸張処理の要否（トンネル対象のパケットか否か）を確認する（ステップＢ１３）。【０１７０】
その結果、伸張処理が不要なトンネル対象のパケットでなければ（ステップＢ１３でＮＯなら）、ＲＯＨＣ処理部２４は、コンテキストデータ２４２の対応表２４２ｂを基に、当該圧縮パケットの伸張に用いるコンテキストを特定し、特定したコンテキストを用いてパケット（圧縮パケット）の伸張処理を実施し（ステップＢ１４）、下位層処理部２５を通じてＩＰパケットとして外部（ＧＷ３０）へ転送する（ステップＢ１５）。【０１７１】
一方、受信パケットが伸張処理の不要なトンネル対象のパケットであれば（ステップＢ１３でＹＥＳなら）、ＲＯＨＣ処理部２４は、そのパケットの末尾に付加されているＴＥＩＤを読み出し（ステップＢ１６）、当該パケットの処理について使用する一時変数に、転送先（トンネルＩＤ＝ｅＮＢＩＤ）、読み出した前記ＴＥＩＤをストアする（ステップＢ１７）。なお、転送先（ｅＮＢＩＤ）は、コンテキストデータ２４２ａの対応表２４２ａから得られる。図１３中の例であれば、ＣＩＤ＝２０１のパケットはｅＮＢＩＤ＝＃２で識別される着側ｅＮＢ２０−２へ転送すべきことがわかる。【０１７２】
そして、ＲＯＨＣ処理部２４は、圧縮パケットにＰＤＣＰヘッダを付加してＰＤＣＰパケットとしてＴＥＩＤとともに、上位層処理部２３経由で下位層処理部２５へ転送する。下位層処理部２５は、転送されてきたＴＥＩＤ及びＰＤＣＰパケットに、トンネル用のＧＴＰヘッダを付加する。トンネル用のＧＴＰヘッダには、例えば、ＴＥＩＤにより識別されるＳ１インタフェースを具備する着側ｅＮＢ２０のアドレス情報を含める。これにより、図７の（２）に示したフォーマットのＧＴＰパケット（トンネルパケット）が組み立てられ、ＧＷ３０へ送信される（ステップＢ１８，Ｂ１９）。この処理は、図８のステップＳ９に示した処理に相当する。【０１７３】
つまり、本例の下位層処理部２５は、発呼側のＵＥ１０−１において特定のＣＩＤとＴＥＩＤとが付加された圧縮データをＵＥ１０−１から受信する受信手段として機能し、ＲＯＨＣ処理部２４は、前記ＣＩＤ，ＴＥＩＤに基づいて、受信した圧縮データのヘッダ伸張処理の要否と宛先ＵＥ１０−２への転送経路とを識別する識別手段として機能する。そして、下位層処理部２５は、ヘッダ伸張処理が不要と識別された圧縮データをヘッダ伸張処理せずに前記識別した転送経路へ送信する送信手段としても機能する。【０１７４】
（ＧＷからＤＬのパケットを受信した場合）
図１６に示すように、ｅＮＢ２０は、上述のベアラ確立処理が完了して、ＵＥ１０間で通信が開始され、ＧＷ３０からＤＬのパケット（ＧＴＰパケット）を受信すると、下位層処理部２５にて、ＧＴＰヘッダを終端、解析し、当該ＧＴＰヘッダに設定されているＴＥＩＤ（DL_TEID）がトンネル用のものか否かを確認する（ステップＢ２０）。【０１７５】
即ち、ＧＴＰヘッダにおけるＴＥＩＤが、既述のベアラ確立処理時に通知され記憶しておいたＴＥＩＤと一致すれば、受信パケットがトンネルパケットであり、不一致ならば通常の（伸張処理をバイパスされていない）パケットであると判断する。【０１７６】
その結果、受信パケットがトンネルパケットであれば、ｅＮＢ２０（下位層処理部２５）は、当該ＧＴＰパケットのペイロードに付加されているＴＥＩＤ（DL_TEID）を基にTEID-RBID対応表２５１を参照、検索して、宛先ＵＥ１０へのＲＢＩＤを特定する（ステップＢ２０のＹＥＳルートからステップＢ２３）。【０１７７】
そして、下位層処理部２５は、前記ＴＥＩＤを除去することで通常のＰＤＣＰパケットを生成し、当該ＰＤＣＰパケットに、前記特定したＲＢＩＤを含むＲＬＣヘッダを付加して、図７の（４）に示したフォーマットのＲＬＣパケットを生成し、これを宛先ＵＥ１０へ送信する（ステップＢ２５）。この処理は、図８のステップＳ１１に示した処理に相当する。【０１７８】
一方、ＧＷ３０から受信したＤＬのパケットがトンネルパケットでなかった場合（ステップＢ２０でＮＯの場合）、ｅＮＢ２０（下位層処理部２５）は、受信ＧＴＰパケットのＧＴＰヘッダに設定されているＴＥＩＤを基に宛先ＵＥ１０へのＲＢＩＤを特定し（ステップＢ２１）、ＧＴＰペイロード（ＰＤＣＰパケット）をＲＯＨＣ処理部２４に転送する。【０１７９】
ＲＯＨＣ処理部２４は、転送されてきたＰＤＣＰパケットについて、未使用のＣＩＤを割り当てて通常のヘッダ圧縮処理を実施する（ステップＢ２２）。得られた圧縮パケットは、上位層処理部２３を経由して下位層処理部２５に転送され、下位層処理部２５にて、特定した前記ＲＢＩＤをＲＬＣヘッダに含むＲＬＣパケットが組み立てられて、宛先ＵＥ１０へ送信される（ステップＢ２５）。【０１８０】
（３．３）ＧＷの説明
図１７はＧＷ３０の構成を示すブロック図である。この図１７に示すＧＷ３０は、例えば、ベアラ管理部３１と、シグナル処理部３２と、上位層処理部３３と、下位層処理部３４と、をそなえる。【０１８１】
この図１７においても、点線矢印Ａ〜Ｄは、ＧＷ３０内の信号転送経路（フロー）を示しており、Ａはベアラ設定要求時のシグナルフロー、ＢはＩＭＳサーバ５０又はｅＮＢ２０へのシグナルフロー、ＣはｅＮＢ２０からのトンネルフロー、ＤはＵＥ１０からインターネット等の外部網及び外部網からＵＥ１０へのデータフローをそれぞれ表している。【０１８２】
即ち、Ａで示すシグナルフローは、下位層処理部３４、シグナル処理部３２、ベアラ管理部３１、上位層処理部３３、下位層処理部３４の順に経由し、その過程で上位層処理部３３、下位層処理部３４に対してベアラ設定に応じた設定を行なうことができることを示している。また、Ｂで示すシグナルフローは、シグナル処理部３２で生成されたシグナリングメッセージが下位層処理部３４にて所要のプロトコル処理を受けてＩＭＳサーバ５０又はｅＮＢ２０へ送信されることを示している。【０１８３】
Ｃで示すデータフローは、ｅＮＢ２０から受信したトンネルパケットが下位層処理部３４、上位層処理部３３、下位層処理部３４の順に経由してそれぞれにおいて必要なプロトコル処理が施されて他のｅＮＢ２０へ送信されることを示している。Ｄで示すデータフローは、例えば、受信パケットが、下位層処理部３４、上位層処理部３３、下位層処理部３４の順に経由して処理されることを表している。【０１８４】
ここで、ベアラ管理部３１は、ｅＮＢ２０（発側ｅＮＢ２０−１及び着側ｅＮＢ２０−２の双方）との間のベアラを管理し、シグナル処理部３２と連携して、ベアラ確立処理（メッセージの生成、送受）を実施する機能を具備する。【０１８５】
シグナル処理部３２は、ベアラ管理部３１からの要求に応じたメッセージ（ｅＮＢ２０宛の個別ベアラ生成要求、ＩＭＳサーバ５０宛のＰＣＣ決定通知応答等）の生成、生成したメッセージのｅＮＢ２０又はＩＭＳサーバ５０への送信、ｅＮＢ２０又はＩＭＳサーバ５０が送信したメッセージ（個別ベアラ生成応答、ＰＣＣ決定通知等）の受信等を行なう機能を具備する。【０１８６】
上位層処理部３３は、ＰＤＣＰ（ＲＯＨＣ）層よりも上位層で規定される処理を実施するもので、例えば、ＩＰやＵＤＰ、ＲＴＰ（ＲＴＣＰ）等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能を具備する。この上位層処理部３３は、図１７中に示すような、フィルタデータ（リスト）３３１とルーティングテーブル３３２とを図示しないメモリ等に保持しており、これらに基づいて受信パケットの転送先を決定（制御）する。【０１８７】
フィルタリスト３３１は、インターネット等の外部から転送されてきたパケットの転送先を識別するのに用いられるデータである。このフィルタリスト３３１には、図１７中に示すように、例えば、宛先ＵＥ１０毎に、そのＵＥ１０が接続しているｅＮＢ２０を識別する情報（ｅＮＢＩＤ）と、そのｅＮＢ２０へのトンネル経路を識別するＴＥＩＤ（DL_TEID）とが登録される。【０１８８】
上位層処理部３３は、外部から受信したＤＬのパケットを処理する際に、当該パケットの宛先アドレス情報を基に当該リスト３３１のエントリを参照することで、宛先ＵＥ１０がどのｅＮＢ２０に接続しており、そのｅＮＢ２０へパケットを転送するにはどのＴＥＩＤをＧＴＰヘッダに付与して転送すべきか、を認識することができる。このフィルタリスト３３１は、例えば図８に示したベアラ確立処理の過程で通知される情報を基にエントリが登録されて構築される。【０１８９】
ルーティングテーブル３３２は、ｅＮＢ２０から受信したパケットの転送先（宛先ｅＮＢ２０）を特定するのに用いられるデータである。このルーティングテーブル３３２には、ｅＮＢ２０から受信されるパケットのトンネル経路を識別する情報（トンネルＩＤ）毎に、宛先ｅＮＢ２０の情報（例えば、ｅＮＢＩＤ）が登録される。【０１９０】
例えば、図１７中に示す例では、４つのエントリのうち、下２つのエントリに、発側ｅＮＢ２０にてヘッダ伸張処理をバイパスされたパケットの転送先ｅＮＢ２０の情報（ｅＮＢＩＤ）が登録されている。これらのトンネル転送分のエントリは、例えば、ネットワーク構築時に予め割り当て、ＧＷ３０の起動時に自動設定する。残り２つのエントリは、ｅＮＢ２０からヘッダ伸張処理を施されて転送されてきた通常のパケットについてのエントリを表している。【０１９１】
上位層処理部３３は、ｅＮＢ２０から受信したパケットのＴＥＩＤを基に、当該ルーティングテーブル３３２のエントリを参照、検索することで、受信パケットの転送先（宛先ｅＮＢ２０）を識別することができる。【０１９２】
下位層処理部３４は、ＰＤＣＰ層よりも下位層で規定される処理を実施するもので、例えば、物理（ＰＨＹ）層やイーサネット（登録商標）層等の各種プロトコルのデータを処理（ヘッダの終端、付け替え等）する機能を具備する。例えば、前記上位層処理部３３で識別した転送先の情報を基に転送パケットのヘッダの付け替え等を行なう。【０１９３】
（動作説明）
以下、上述のごとく構成された本例のＧＷ３０の動作について、図１８〜図２１を用いて説明する。なお、図１８はＧＷ３０における接続（呼接続）開始時の動作を説明するフローチャート、図１９は外部からパケットを受信した場合の動作を説明するフローチャート、図２０はＧＷ３０から外部へ転送すべきパケットを受信した場合の動作を説明するフローチャート、図２１はトンネルパケットを受信した場合の動作を説明するフローチャートである。【０１９４】
（接続開始時の動作）
ＧＷ３０は、ＩＭＳサーバ５０から図３のステップＳ４１に示したＰＣＣ決定通知（PCC decision proposition）メッセージを受信すると（ステップＣ１）、ベアラ管理部３１とシグナル処理部３２とが連携して、発側ｅＮＢ２０−１宛の個別ベアラ生成要求（Create Dedicated Bearer Request）メッセージを生成し、下位層処理部３４を通じて発側ｅＮＢ２０−１宛に送信する（ステップＣ２）。これは、図３のステップＳ４２の処理に相当する。【０１９５】
その後、ＧＷ３０（ベアラ管理部３１及びシグナル処理部３２）は、図３のステップＳ４５に示した応答メッセージ（Radio Bearer Setup Response）を受信すると（ステップＣ３）、その応答メッセージに設定されているＴＥＩＤを読み出し（ステップＣ４）、発側ｅＮＢ２０−１との間の個別ベアラを設定する（ステップＣ５）。なお、ＴＥＩＤの読み出しと個別ベアラの設定とは、逆順でもよいし、並行して実施してもよい。【０１９６】
次いで、ＧＷ３０（ベアラ管理部３１及びシグナル処理部３２）は、ＩＭＳサーバ５０から図３のステップＳ４７に示したＰＣＣ決定通知（PCC decision proposition）メッセージを受信すると（ステップＣ６）、着側ｅＮＢ２０−２宛の個別ベアラ生成要求（Create Dedicated Bearer Request）メッセージを生成し、下位層処理部３４を通じて着側ｅＮＢ２０−２宛に送信する（ステップＣ７）。これは、図３のステップＳ４８の処理に相当する。【０１９７】
その後、ＧＷ３０（ベアラ管理部３１及びシグナル処理部３２）は、着側ｅＮＢ２０−２から図３のステップＳ５１に示した個別ベアラ生成応答（Create Dedicated Bearer Response）メッセージを受信すると（ステップＣ８）、その応答メッセージに設定されているＴＥＩＤを読み出し（ステップＣ９）、着側ｅＮＢ２０−２との間の個別ベアラを設定する（ステップＣ１０）。なお、この場合も、ＴＥＩＤの読み出しと個別ベアラの設定とは、逆順でもよいし、並行して実施してもよい。【０１９８】
そして、ＧＷ３０（ベアラ管理部３１及びシグナル処理部３２）は、ＩＭＳサーバ５０に対してベアラ設定完了を報告するＰＣＣ決定通知確認メッセージ（PCC decision proposition ACK）メッセージに、前記読み出した各ＴＥＩＤ（発呼側及び着呼側）を付与し、当該メッセージをＩＭＳサーバ５０に送信する（ステップＣ１１）。このＴＥＩＤのＩＭＳサーバ５０への通知は、図３に示すステップＳ４６及びＳ５２でそれぞれ発呼側又は着呼側の片方向ずつについて実施してもよい。【０１９９】
（外部からパケットを受信した場合）
図１９に示すように、ＧＷ３０は、インターネット等の外部からＤＬ（ＵＥ１０宛）のパケットを受信すると（ステップＣ２１）、下位層処理部３４にて当該受信パケットのヘッダ終端処理等を行なった後、上位層処理部３３へ転送する。上位層処理部３３は、転送された受信パケットのＩＰヘッダを解析し、その宛先アドレス情報を読み取り、当該宛先アドレス情報を基に、フィルタリスト３３１の該当エントリを参照して、宛先ＵＥ１０が接続しているｅＮＢ２０及びＤＬのＴＥＩＤを検索、特定する（ステップＣ２２）。【０２００】
上位層処理部３３は、受信パケットと特定した前記情報とを下位層処理部３４に転送し、下位層処理部３４は、前記特定した情報を含むＧＴＰヘッダを生成し、受信パケットに付加してＤＬのＴＥＩＤにより識別されるトンネル経路へ送信する（ステップＣ２３）。【０２０１】
つまり、上位層処理部３３及び下位層処理部３４は、外部から受信したパケットを宛先ＵＥ１０が接続しているｅＮＢ２０へ転送するのに適したフォーマットに変換（カプセル化）して、ｅＮＢ２０へ送信する。【０２０２】
（外部へ送信すべきパケットをｅＮＢから受信した場合）
図２０に示すように、ＧＷ３０は、ｅＮＢ２０から、インターネット等の外部宛のパケットを受信すると（ステップＣ３１）、下位層処理部３４及び上位層処理部３３を通じて、外部へ送信する際に不要なヘッダを除去する等して、外部へ送信すべきＩＰパケットを読み出し（ステップＣ３２）、読み出したＩＰパケットを外部へ送信する（ステップＣ３３）。【０２０３】
つまり、上位層処理部３３及び下位層処理部３４は、ｅＮＢ２０から受信した外部へのパケットを、外部への転送に適したフォーマットに変換した上で、受信パケットを外部へ送信する。【０２０４】
（トンネルパケットを受信した場合）
図２１に示すように、ＧＷ３０は、発側ｅＮＢ２０にてヘッダ伸張処理をバイパスされてトンネル経路を転送されてきたパケットを受信すると（ステップＣ４１）、当該パケットは下位層処理部３４から上位層処理部３３へ転送され、上位層処理部３３は、ＧＴＰペイロードに付与されているＤＬのＴＥＩＤを基に、ルーティングテーブル３３２を参照して該当エントリを検索し、転送先（宛先）ｅＮＢ２０（ＤＬのトンネル経路）を特定する（ステップＣ４２）。【０２０５】
そして、上位層処理部３３は、特定した情報とともに受信パケット（ＧＴＰペイロード）を下位層処理部３４へ転送し、下位層処理部３４は、前記特定したＤＬのトンネル経路（宛先ｅＮＢ２０）を示す情報（ｅＮＢＩＤ）を含むヘッダを付加した上で前記トンネル経路へ送信する（ステップＣ４３）。【０２０６】
つまり、上位層処理部３３及び下位層処理部３４は、発側ｅＮＢ２０にてヘッダ伸張処理をバイパスされて転送されたパケットを受信すると、その受信パケットがＧＴＰペイロードに付与されたＴＥＩＤが示すトンネル先へ転送されるように必要なヘッダ付け替え処理を施した上で、パケット送信を行なう。【０２０７】
（３．４）ＩＭＳサーバの説明
図２２はＩＭＳサーバ５０の構成を示すブロック図である。この図２２に示すＩＭＳサーバ５０は、例えば、ＩＭＳ処理部５１と、下位層処理部５２と、をそなえる。なお、この図２２において、点線矢印Ａは、ＩＭＳサーバ５０内の信号転送経路（フロー）を示している。即ち、Ａで示すシグナルフローは、下位層処理部５２及びＩＭＳ処理部５１を経由して、ＳＩＰメッセージやベアラ確立時のメッセージの送受信が行なわれることを示している。【０２０８】
ここで、ＩＭＳ処理部５１は、例えば、ＵＥ１０宛のＳＩＰメッセージ（INVITEメッセージ等）やベアラ確立処理時のＧＷ３０宛のメッセージ（ＰＣＣ決定通知等）を生成する機能、ＵＥ１０が送信したＳＩＰメッセージ（２００ ＯＫメッセージ）やＧＷ３０からの応答メッセージ（ＰＣＣ決定通知確認等）を受信する機能を具備する。【０２０９】
このＩＭＳ処理部５１は、図２２中に示すような、既述の表２の内容に相当するＣＩＤ管理表（テーブル）５１１を図示しないメモリ等に保持する。【０２１０】
ＣＩＤ管理表５１１は、符号５１１ａ，５１１ｂで示すように転送先ｅＮＢ２０へのトンネル経路（DL_TEID）毎に、発側ｅＮＢ２０でのヘッダ伸張処理が不要な情報の一例としてのＣＩＤの使用状況（使用／未使用）を管理するためのデータであり、図３のステップＳ４に示したベアラ確立処理の過程で通知されるＴＥＩＤ，ｅＮＢＩＤを基に構築される。【０２１１】
ＩＭＳ処理部５１は、このＣＩＤ管理表５１１を基に、発側ｅＮＢ２０でのヘッダ伸張処理が不要なＣＩＤを、同じトンネル経路内で重複しないように管理し、ＵＥ１０に割り当てる。【０２１２】
下位層処理部５２は、前記のＳＩＰメッセージやベアラ確立処理時に用いるメッセージを、ＧＷ３０との間のインタフェースに適したフォーマット（プロトコル）に変換する機能等）を具備する。【０２１３】
（動作説明）
以下、上述のごとく構成された本例のＩＭＳサーバ５０の動作について、図２３を用いて説明する。なお、図２３はＩＭＳサーバ５０における接続（呼接続）開始時の動作を説明するフローチャートである。【０２１４】
ＩＭＳサーバ５０は、下位層処理部５２を通じてＩＭＳ処理部５１にて、図８のステップＳ１に示したように発呼側のＵＥ１０−１からＳＩＰのINVITEメッセージを受信すると（ステップＤ１）、当該INVITEメッセージに含まれる宛先情報を基に着呼側のＵＥ１０−２を特定し、下位層処理部５２を通じて、当該ＵＥ１０−２宛にＳＩＰのINVITEメッセージを送信する（ステップＤ２）。この処理は、図８のステップＳ２に示した処理に相当する。【０２１５】
その後、ＩＭＳサーバ５０（ＩＭＳ処理部５１）は、着呼側のＵＥ１０−２から前記INVITEメッセージに対する応答メッセージ（２００ ＯＫ）を受信すると（ステップＤ３）、発呼側ＵＥ１０−１とＧＷ３０との間のベアラ確立を要求するメッセージ（ＰＣＣ決定通知）を生成し、ＧＷ３０へ送信する（ステップＤ４）。この処理は、図３のステップＳ４１に示した処理に相当する。【０２１６】
ＩＭＳサーバ５０は、図３のステップＳ４６に示したように、当該メッセージに対する応答メッセージ（ＰＣＣ決定通知確認）を受信すると、当該応答メッセージに設定されているＤＬのＴＥＩＤを抽出する（ステップＤ５）。【０２１７】
また、ＩＭＳサーバ５０は、着呼側ＵＥ１０−２とＧＷ３０との間のベアラ確立を要求するメッセージ（ＰＣＣ決定通知）を生成し、ＧＷ３０へ送信する（ステップＤ６）。この処理は、図３のステップＳ４７に示した処理に相当する。【０２１８】
ＩＭＳサーバ５０は、図３のステップＳ５２に示したように、当該メッセージに対する応答メッセージ（ＰＣＣ決定通知確認）を受信すると、当該応答メッセージに設定されているＤＬのＴＥＩＤを抽出する（ステップＤ７）。【０２１９】
なお、発呼側ＵＥ１０−１とＧＷ３０との間のベアラ確立要求と、着呼側ＵＥ１０−２とＧＷ３０との間のベアラ確立要求とは、並行して実施してもよい。【０２２０】
その後、ＩＭＳサーバ５０（ＩＭＳ処理部５１）は、発呼側のＵＥ１０−１及び着呼側のＵＥ１０−２のそれぞれがＲＯＨＣのヘッダ圧縮に用いるべきＣＩＤを、前記ＣＩＤ管理表５１１（５１１ａ，５１１ｂ）における未使用のＣＩＤの中から選択する（ステップＤ８）。なお、ＩＭＳ処理部５１は、選択したＣＩＤの前記ＣＩＤ管理表５１１における使用状況を「使用中」に更新する。【０２２１】
そして、ＩＭＳサーバ５０（ＩＭＳ処理部５１）は、選択した各ＣＩＤと、前記のステップＤ５及びＤ７でそれぞれ受信したＴＥＩＤとを含む、発呼側ＵＥ１０−１宛のＳＩＰメッセージ（２００ ＯＫ）を生成し、送信する（ステップＤ９）。この処理は、図８のステップＳ６に示した処理に相当する。【０２２２】
つまり、本例のＩＭＳ処理部５１は、発呼側のＵＥ１０−１がヘッダ圧縮して宛先ＵＥ１０−２宛に送信するデータに付加する情報であって、ヘッダ伸張処理の要否と宛先ＵＥ１０−２への転送経路とを識別するのに用いられる情報（ＣＩＤ，ＴＥＩＤ）を生成する生成手段として機能し、下位層処理部５２は、前記生成した情報をＵＥ１０−１とＵＥ１０−２との間の通信路（ベアラ）を設定する過程において、発呼側のＵＥ１０−１に通知する通知手段として機能する。【０２２３】
以上説明したＵＥ１０、ｅＮＢ２０、ＧＷ３０、ＩＭＳサーバ５０を具備することで、項目〔２〕で述べた動作、効果を実現することができる。【０２２４】
〔４〕その他
なお、上述した実施形態では、ＵＥ１０とＧＷ３０との間にｅＮＢ２０が１台介在する経路に着目して説明を行なったが、２台以上のｅＮＢ２０が介在する経路についても、上述した例と同様に、特定のＣＩＤ（バイパス識別子）を有するパケットについて、発側ｅＮＢ２０でのヘッダ伸張処理、着側ｅＮＢ２０でのヘッダ圧縮処理を不要にすることが可能である。
【図１】
2009057204.tif 000006
【図２】
2009057204.tif 000007
【図３】
2009057204.tif 000008
【図４】
2009057204.tif 000009
【図５】
2009057204.tif 000010
【図６】
2009057204.tif 000011
【図７】
2009057204.tif 000012
【図８】
2009057204.tif 000013
【図９】
2009057204.tif 000014
【図１０】
2009057204.tif 000015
【図１１】
2009057204.tif 000016
【図１２】
2009057204.tif 000017
【図１３】
2009057204.tif 000018
【図１４】
2009057204.tif 000019
【図１５】
2009057204.tif 000020
【図１６】
2009057204.tif 000021
【図１７】
2009057204.tif 000022
【図１８】
2009057204.tif 000023
【図１９】
2009057204.tif 000024
【図２０】
2009057204.tif 000025
【図２１】
2009057204.tif 000026
【図２２】
2009057204.tif 000027
【図２３】
2009057204.tif 000028
【国際調査報告】
2009057204.tif 000029
2009057204.tif 000030
2009057204.tif 000031
2009057204.tif 000032