JP5088091B2 - 基地局装置、通信方法及び移動通信システム - Google Patents

Description

本発明は、複数の基地局装置と基地局制御装置とを有する移動通信システムにおける通信技術に関する。

３ＧＰＰ（3rd Generation Partnership Project）により現在標準化が進められている移動体の高速データ通信方式として、ＬＴＥ（Long Term Evolution）と総称されるもの
がある。ＬＴＥは、３Ｇと呼ばれるＷ−ＣＤＭＡ方式等、３．５Ｇと呼ばれるＨＳＤＰＡ方式等を更に進化させ次世代（４Ｇ）への円滑な移行を図るため段階として位置づけられている。

ＬＴＥを採用する移動通信システムでは、従来のＲＮＣ（Radio Network Controller）機能が基地局装置であるｅｖｏｌｖｅｄ ＮｏｄｅＢ（以降、ｅＮＢと表記する）やコアネットワーク系の基地局制御装置であるＭＭＥ（Mobility Management Entity）及びサービングゲートウェイ（以降、サービングＧＷと表記する）（ＳＡＥ ＧＷとも呼ばれる）等に分散され、ＲＮＣ装置自体は削除される。このようなＬＴＥ移動通信システムでは、ｅＮＢ、ＭＭＥ及びサービングＧＷの接続形態は多様化する。

図１５は、従来のＬＴＥ移動通信システムのシステム構成例を示す図である。図１５の例に示すように、ＬＴＥ移動通信システムでは、公衆網向けで通信エリアの広いｅＮＢ５０１、個人ユーザ向けで通信エリアの小さいホームｅＮＢ５０２が同一移動通信システムに収容される。すなわち、相当数のｅＮＢ５０１及びホームｅＮＢ５０２がＩＰ網５００を介してＭＭＥ５０５及びサービングＧＷ５０６に接続される。

ところで、ＬＴＥ移動通信システムにおける通信プロトコルは、ユーザ間のユーザデータの送受信を司るユーザプレーン（以降、Ｕ−プレーンと表記する）とＵ−プレーンを制御するためにユーザ呼の制御やコネクションの制御等を司る制御プレーン（以降、Ｃ−プレーンと表記する）とから構成される。ＬＴＥ移動通信システムでは、Ｃ−プレーンのトランスポート層プロトコルには、ＳＣＴＰ（Stream Control Transmission Protocol）が利用され、Ｕ−プレーンのトランスポート層プロトコルには、ＧＴＰ（GPRS(General Packet Radio Service) Tunneling Protocol）とＵＤＰ（User Datagram Protocol）が利用
される。

ＳＣＴＰは、エンドポイント間にＳＣＴＰアソシエーションと呼ばれるコネクションを確立し、そのＳＣＴＰアソシエーション内に複数のユーザメッセージのストリームを独立転送させることができる。ＧＴＰは、ＧＴＰトンネルを利用することにより、ＩＰ網５００を含む移動通信システム網上で移動端末（ＵＥ）間でやりとりされるべきデータパケットを透過的に転送する。

図１６及び１７は、従来のＬＴＥ移動通信システムのＣ−プレーン及びＵ−プレーンのそれぞれの接続形態を示す概念図である。図１６及び１７に示すように、従来のＬＴＥ移動通信システムでは、各ｅＮＢ５０１、５０２及び５０３はそれぞれＭＭＥ５０５に接続され、各ｅＮＢ５０１、５０２及び５０３間もそれぞれ接続される。ここで、ＳＣＴＰ層又はＧＴＰ層を利用する各ノードのアプリケーション層で利用されるインタフェースのうち、各ｅＮＢとＭＭＥとを結ぶインタフェースはＳ１インタフェース（図１６及び１７の実線矢印）と呼ばれ、各ｅＮＢ間を結ぶインタフェースはＸ２インタフェース（図１６及び１７の破線矢印）と呼ばれる。以降、このＳ１インタフェースでやりとりされるアプリ
ケーション層メッセージをＳ１−ＡＰメッセージと表記し、Ｘ２インタフェースでやりとりされるアプリケーション層メッセージをＸ２−ＡＰメッセージと表記する。

また、図１６及び１７の例には、Ｃ−プレーンに関し各ノード間に２本のアウトバウンドストリーム（送信用のＳＣＴＰストリーム）と２本のインバウンドストリーム（受信用のＳＣＴＰストリーム）とがそれぞれ設定され、Ｕ−プレーンに関し各ノード間に１本のアウトバウンドＧＴＰトンネル（送信用のＧＴＰトンネル）と１本のインバウンドＧＴＰトンネル（受信用のＧＴＰトンネル）が設定される例が示される。

このような場合、図１６に示されるように、Ｃ−プレーンに関する従来の接続形態では、ＭＭＥ５０５と各ｅＮＢ５０１、５０２及び５０３との間、各ｅＮＢ５０１、５０２及び５０３の間にそれぞれ４本のＳＣＴＰストリームが設定されたＳＣＴＰアソシエーション５１０から５１７が確立される。ＳＣＴＰアソシエーション５１０、５１１及び５１２にはそれぞれＳ１インタフェース用の４本のＳＣＴＰストリームが設定され、ＳＣＴＰアソシエーション５１５、５１６及び５１７にはそれぞれＸ２インタフェース用の４本のＳＣＴＰストリームが設定される。

Ｕ−プレーンに関する従来の接続形態では、図１７に示されるように、サービングＧＷ５０６と各ｅＮＢ５０１、５０２及び５０３との間、各ｅＮＢ５０１、５０２及び５０３の間に、インバウンド用のセキュリティアソシエーション及びアウトバウンド用のセキュリティアソシエーションがそれぞれ確立されている。このセキュリティアソシエーションは、ＩＰＳｅｃ（Security Architecture for Internet Protocol）、ＩＰｖ６等により
、暗号化方式や暗号鍵等の情報を交換し確立された論理的通信路を意味する。

更に、各セキュリティアソシエーションには、１本のＧＴＰトンネルがそれぞれ設定される。具体的には、ＧＴＰトンネル群５２０、５２１及び５２２にはそれぞれＳ１インタフェース用の２本のＧＴＰトンネルが設定され、ＧＴＰトンネル群５２５、５２６及び５２７にはそれぞれＸ２インタフェース用の２本のＧＴＰトンネルが設定される。

図１５に示されるようなＬＴＥ移動通信システムでは、公衆網向けのｅＮＢ５０１及びホームｅＮＢ５０２を収容する事が想定されているため、ＭＭＥ５０５及びサービングＧＷ５０６は、相当な数のｅＮＢとの間にＳＣＴＰアソシエーション及びＧＴＰトンネルのためのセキュリティアソシエーションを確立する必要がある。

従って、多数のＳＣＴＰアソシエーション及びセキュリティアソシエーションを管理する必要があるため、ＭＭＥ５０５及びサービングＧＷ５０６の処理負荷が高くなる。また、これらを確立するのに所定のトラフィックが発生するため、移動通信システム内のトラフィック量が増大する。

個人ユーザ向けとして使用される事が想定される、ｅＮＢ５０２は頻繁に電源のＯＮ、ＯＦＦ操作が行われる恐れがあるため、この操作によりＳＣＴＰアソシエーションの確立処理及び解放処理、並びにＩＰｓｅｃのキー交換手順といった負荷の高い処理が頻繁に発生する。

従って、このような負荷の高い処理を頻繁に発生させるホームｅＮＢの収容数が多くなると、これらを制御するＭＭＥ及びサービングＧＷの処理負荷が高くなる。また、このような処理は複数のトラフィックを伴うため、各ｅＮＢとＭＭＥ又はサービングＧＷを接続するＩＰ網５００に流れるトラフィックが増大する。

本発明は、基地局制御装置の処理負荷を軽減し、移動通信システム内のトラフィック量を抑える技術を提供することを目的とする。

本発明は、上述した課題を解決するために以下の構成を採用する。即ち、本発明の第一態様は、基地局制御装置と接続されており、この基地局制御装置との間に第一論理通信路を確立させる第一確立手段と、他の基地局装置との間に第二論理通信路を確立させる第二確立手段と、上記他の基地局装置と上記基地局制御装置とを終端として送受されるデータを他基地局装置データとして上記第一論理通信路及び上記第二論理通信路を介して転送する転送手段と、を備える基地局装置についてのものである。

本発明の第一態様に係る基地局装置は、他の基地局装置と基地局制御装置とを終端として送受されるデータ（他基地局装置データ）を他の基地局装置から第二論理通信路を介して受け、第一論理通信路を介して基地局制御装置へ転送する。一方で、当該基地局装置は、他基地局装置データを基地局制御装置から第一論理通信路を介して受け、第二論理通信路を介して他の基地局装置へ転送する。

従来、上記他基地局装置データは、他の基地局装置と基地局制御装置との間に確立される論理通信路を利用して直接やりとりされていた。つまり、従来は、基地局制御装置は、接続される基地局装置の数分、論理通信路を確立し管理する必要があった。

本発明の第一態様によれば、上記他基地局装置データも本基地局装置を経由するため、基地局制御装置は、他の基地局装置との間に論理通信路を確立する必要がなく、本基地局装置との間に確立される第一論理通信路のみを管理すればよい。

従って、本発明の第一態様によれば、基地局制御装置により管理されるべき論理通信路の数を減らすことができるため、基地局制御装置の処理負荷を軽減させることができる。更に、通常、論理通信路を確立及び解放するためには所定量のトラフィックが必要となるところ、これを減らすことができるため、本発明の第一態様に係る基地局装置を備えるシステムではこのシステム内のトラフィック量を軽減させることができる。

本発明の第一態様における基地局装置は、このような構成を有するために好ましくは、上記第一確立手段が、第一論理通信路内に、本第一態様に係る基地局装置と基地局制御装置とを終端として送受されるデータを通すための通信パイプと上記他基地局装置データを通すための通信パイプとを設定し、上記第二確立手段が、第二論理通信路内に、本第一態様に係る基地局装置と他の基地局装置とを終端として送受されるデータを基地局間データとして通すための通信パイプと上記他基地局装置データを通すための通信パイプとを設定し、上記転送手段が、第一論理通信路内に設定された他基地局装置データを通すための通信パイプを示す識別情報と、第二論理通信路内に設定された他基地局装置データを通すための通信パイプを示す識別情報との組み合わせを転送テーブルに格納するテーブル生成手段を有し、受信されるデータに設定される通信パイプ識別情報及びこの転送テーブルに基づいて、受信されたデータのうちの他基地局装置データを転送するように構成する。

従来、他基地局装置データを通すための通信パイプは、他の基地局装置と基地局制御装置との間に確立される論理通信路に設定されていたところ、本第一態様では、この論理通信路を削除したため、本第一実施形態に係る基地局装置を経由するための第二論理通信路及び第一論理通信路に他基地局装置データを通すための通信パイプが設定される。この通信パイプを通るデータにはその通信パイプを示す通信パイプ識別情報が設定される。

本第一態様に係る基地局装置は、受信されたデータに設定される通信パイプ識別情報及び他基地局装置データを通すための各通信パイプを示す識別情報の組み合わせが格納される転送テーブルに基づいて、その受信されたデータが他基地局装置データであるか判別し、この他基地局装置データを転送する。

従って、本発明の第一態様によれば、受信されたデータが転送する必要のあるデータであるか否かをそのデータに設定される通信パイプ識別情報及び転送テーブルにより容易に判別することができる。

更に、本発明の第一態様では、上記第一論理通信路及び第二論理通信路がＳＣＴＰアソシエーションであり、通信パイプがＳＣＴＰストリームであり、通信パイプを示す識別情報がストリームＩＤである場合には、好ましくは、上記第二確立手段が、第二ＳＣＴＰアソシエーションにおける他基地局装置データを通すためのＳＣＴＰストリームのストリームＩＤの最下位ビットを他基地局装置データであることを示す判別ビットとし、上記転送手段が、受信されたデータに設定されるストリームＩＤの判別ビットを検査することにより、受信されたデータが他基地局装置データか否かを判断するように構成する。

これによれば、本発明の第一態様に係る基地局装置は、ストリームＩＤの判別ビットにより即座に他基地局装置データを判別することが可能となる。

また、上記本発明の第一態様における構成において、好ましくは、上記第一確立手段が、第一ＳＣＴＰアソシエーションにおける他基地局装置データを通すためのＳＣＴＰストリームのうちの送信用ＳＣＴＰストリームのストリームＩＤと受信用ＳＣＴＰストリームのストリームＩＤとを同じ値に割り当てるように構成する。

これにより、本発明の第一態様に係る基地局装置は、基地局制御装置から送られる他基地局装置データを上記転送テーブルを参照することで適切に転送することができる。さらに、このような構成により、転送テーブルを作成するにあたり、基地局装置と基地局制御装置との間で他基地局装置データを通すためのストリームＩＤを通知しあう必要がない。

また、本発明の第一態様では、上記第一論理通信路及び第二論理通信路が、セキュリティアソシエーションであり、上記通信パイプが、ＧＴＰトンネルであり、上記通信パイプを示す識別情報が、トンネルエンドポイントＩＤである場合には、好ましくは、上記テーブル生成手段が、自身で生成した基地局制御装置方向のトンネルエンドポイントＩＤ及び他の基地局装置方向のトンネルエンドポイントＩＤ、基地局間データとして他の基地局装置から送られる基地局制御装置により生成されたトンネルエンドポイントＩＤ及び他の基地局装置により生成されたトンネルエンドポイントＩＤに基づいて、上記転送テーブルを生成するように構成する。

なお、本発明の他の態様としては、上記第一態様に係る基地局装置及び基地局制御装置を有する通信システムであってもよいし、上記第一態様に係る基地局装置において実行される通信方法であってもよいし、上記第一態様に係る基地局装置の何れかの機能をコンピュータに実現させるプログラムであってもよいし、このようなプログラムを記録したコンピュータが読み取り可能な記憶媒体であってもよい。

本発明によれば、基地局制御装置の処理負荷を軽減し、移動通信システム内のトラフィック量を抑える技術を実現することができる。

以下、図面を参照して、本発明の実施形態における移動通信システムについて説明する。なお、以下に述べる実施形態の構成は例示であり、本発明は以下の実施形態の構成に限定されない。

〔システム構成〕
まず、本実施形態における移動通信システムのシステム構成について、図１を用いて説明する。図１は、本実施形態における移動通信システムのシステム構成例を示す図である。

本実施形態における移動通信システムは、ＭＭＥ１０、サービングＧＷ２０、ｅＮＢ３１及び３２等から構成され、本システムに接続される移動端末（以降、ＵＥと表記する）３に所定の移動通信サービスを提供する。ＵＥ３は、その位置に応じてｅＮＢ３１及び３２の少なくとも１つと無線リンクにより接続することにより、本移動通信システムに接続する。なお、本実施態様は、移動通信システムがＵＥ３へ提供する移動通信サービスを限定するものではない。

本実施形態における移動通信システムでは、ｅＮＢを機能的にマスタｅＮＢ３１とスレーブｅＮＢ３２とに分けて定義する。本実施形態における移動通信システムでは、例えば、図１に示されるように、ＭＭＥ１０、サービングＧＷ２０、マスタｅＮＢ３１及びスレーブｅＮＢ３２がそれぞれＩＰ網５を介して接続され、マスタｅＮＢ３１とスレーブｅＮＢ３２とはＩＰ網６を介して接続される。マスタｅＮＢ３１は、本発明の第一態様に係る基地局装置に相当し、ＭＭＥ１０及びサービングＧＷ２０は、本発明の第一態様における基地局制御装置に相当する。

〔接続形態〕
次に、本実施形態における移動通信システムを構成する各装置（以降、ノードとも表記する）の接続形態について図２、３及び４を用いて説明する。図２は、本実施形態における移動通信システムを構成する各装置の接続形態例を示す概念図である。

本実施形態における移動通信システムでは、上述のＬＴＥ通信システムと同様に、Ｃ−プレーンのトランスポート層プロトコルには、ＳＣＴＰが利用され、Ｕ−プレーンのトランスポート層プロトコルには、ＧＴＰが利用される。また、ＧＴＰトンネルは、ＩＰＳｅｃ等により確立されるセキュリティアソシエーション上に設定される。

本実施形態における移動通信システムでは、このようなＣ−プレーン及びＵ−プレーン上で送受される制御信号及びユーザデータ信号が、図２に示すように、必ずマスタｅＮＢ３１を経由して、宛先のスレーブｅＮＢ３２、ＭＭＥ１０又はサービングＧＷ２０へ送り届けられる。このとき、マスタｅＮＢ３１は、ＳＣＴＰ層及びＧＴＰ層でのルーティング処理を実施する。従って、スレーブｅＮＢ３２とＭＭＥ１０及びサービングＧＷ２０との間のネットワーク接続は利用されない。

以降、Ｃ−プレーンにおいて、ｅＮＢ３２及び３３のようなスレーブｅＮＢ及びＭＭＥ１０をそれぞれエンドポイントとしてＳ１インタフェースでやりとりされるメッセージをスレーブデータチャンクと表記し、マスタｅＮＢ３１、スレーブｅＮＢ３２及び３３間でＸ２インタフェースでやりとりされるメッセージをＸ２データチャンクと表記する。

また、Ｕ−プレーンにおいて、ｅＮＢ３２及び３３のようなスレーブｅＮＢ及びサービングＧＷ２０をそれぞれエンドポイントとしてＳ１インタフェースでやりとりされるメッセージをスレーブＧＴＰパケットと表記し、マスタｅＮＢ３１、スレーブｅＮＢ３２及び３３間でＸ２インタフェースでやりとりされるメッセージをＸ２ＧＴＰパケットと表記す
る。

これにより、例えば、マスタｅＮＢ３１は、Ｃ−プレーン（ＳＣＴＰ層）においては、スレーブｅＮＢ３２から送信されＩＰ網６を介して受信されたスレーブデータチャンクをＭＭＥ１０とマスタｅＮＢ３１との間に確立されるＳＣＴＰアソシエーションに多重させることによりＭＭＥ１０へ送る。

また、本移動通信システムでは、Ｃ−プレーンでは各ノード間に２本のアウトバウンドストリーム（送信用のＳＣＴＰストリーム）と２本のインバウンドストリーム（受信用のＳＣＴＰストリーム）とがそれぞれ設定され、Ｕ−プレーンでは各ノード間に１本のアウトバウンド用ＧＴＰトンネルと１本のインバウンド用ＧＴＰトンネルが設定されるものとする。これにより、Ｃ−プレーンにおいては、共通制御情報と個別制御情報とを別ストリームとして送受することができる。なお、上記ＳＣＴＰストリームおよびＧＴＰトンネルを通信パイプと呼ぶこともある。

以下、図１及び２で示した本実施形態における移動通信システムの構成とは別の例により、本実施形態の接続形態の概念を説明する。図３は、本実施形態におけるＣ−プレーン接続形態の概念を示す図である。図４は、本実施形態におけるＵ−プレーン接続形態の概念を示す図である。図３及び４の例では、３台のｅＮＢ３１、３２及び３３、ＭＭＥ１０、サービングＧＷ２０により構成される移動通信システムの接続形態が示される。

図３に示されるように、Ｃ−プレーンに関する本実施形態における接続形態では、ＭＭＥ１０と各ｅＮＢ３１、３２及び３３との間の接続は、ＭＭＥ１０とマスタｅＮＢ３１との間のＳＣＴＰアソシエーション４０に全て収容される。これにより、ＳＣＴＰアソシエーション４０には、図１６に示される従来の接続形態におけるＳＣＴＰアソシエーション５１０、５１１及び５１２に設定されていた１２本（＝４×３）のＳＣＴＰストリームが設定される。

一方、各ｅＮＢ３１、３２及び３３の間の接続に関しては、マスタｅＮＢ３１とスレーブｅＮＢ３２及び３３との間の接続は、図１６に示される従来の接続形態における各ｅＮＢを接続するＳＣＴＰアソシエーション及び各ｅＮＢとＭＭＥ１０とを接続するＳＣＴＰアソシエーションに設定されていた８本（＝４×２）のＳＣＴＰストリームで実現される。具体的には、アソシエーション４１は、従来のアソシエーション５１５及び５１２に設定されていた８本のＳＣＴＰストリームを含み、アソシエーション４２は、従来のアソシエーション５１６及び５１１に設定されていた８本のＳＣＴＰストリームを含む。なお、スレーブｅＮＢ３２及び３３の間の接続は従来どおりである（ＳＣＴＰアソシエーション４３）。

以上より、Ｃ−プレーンに関し、各ノード間に設定する必要のあるストリーム数は以下のように表すことができる。

マスタｅＮＢとＭＭＥとの間のストリーム数 ＝（マスタｅＮＢとＭＭＥとの間に必要なストリーム数）＋（各スレーブｅＮＢとＭＭＥとの間に必要なストリーム数の総数）
マスタｅＮＢとスレーブｅＮＢとの間のストリーム数 ＝（マスタｅＮＢとスレーブｅＮＢとの間に必要なストリーム数）＋（スレーブｅＮＢとＭＭＥとの間に必要なストリーム数）
なお、以降、マスタｅＮＢ３１とＭＭＥ１０との間に確立されるＳＣＴＰアソシエーションをＭＭＥアソシエーションとも表記し、マスタｅＮＢ３１とスレーブｅＮＢ３２との間に確立されるＳＣＴＰアソシエーションをＮＢ（NodeB）アソシエーションとも表記す
る。

このように、本実施形態によれば、従来では図１６に示すようにＭＭＥにはｅＮＢの数分ＳＣＴＰアソシエーションが確立されていたところ、図３に示すようにマスタｅＮＢ３１とＭＭＥ１０との間にのみＳＣＴＰアソシエーションを確立すればよくなる。従って、本実施形態によれば、ＭＭＥで確立及び管理されるＳＣＴＰアソシエーションの数を減らすことができる。

図４に示されるように、Ｕ−プレーンに関する本実施形態における接続形態では、サービングＧＷ２０と各ｅＮＢ３１、３２及び３３との間の接続は、サービングＧＷ２０とマスタｅＮＢ３１との間に確立されるＧＴＰトンネル群５０により実現される。ＧＴＰトンネル群５０には、図１７に示される従来の接続形態におけるＧＴＰトンネル群５２０、５２１及び５２２に含まれる６本（＝２×３）のＧＴＰトンネルが含まれる。

各ｅＮＢ３１、３２及び３３の間の接続に関しては、マスタｅＮＢ３１とスレーブｅＮＢ３２及び３３との間の接続は、図１７に示される従来の接続形態における各ｅＮＢを接続するＧＴＰトンネル群及び各ｅＮＢとＭＭＥ１０とを接続するＧＴＰトンネル群に含まれる４本（＝２×２）のＧＴＰトンネルにより実現される。具体的には、ＧＴＰトンネル群５１は、従来のＧＴＰトンネル群５２５及び５２２に含まれる４本のＧＴＰトンネルを含み、ＧＴＰトンネル群５２は、従来のＧＴＰトンネル群５２１及び５２６に含まれる４本のＧＴＰトンネルを含む。

本実施形態では、各ＧＴＰトンネルは、各通信方向についてそれぞれ確立されるセキュリティアソシエーション上に設定されるものとする。従って、ＧＴＰトンネルが設定される各ノード間には、２本のセキュリティアソシエーションがそれぞれ確立される。なお、本実施形態では、サービングＧＷ２０とｅＮＢとの間で確立されるセキュリティアソシエーションをマスタｅＮＢ３１とサービングＧＷ２０との間にのみに確立するように制限すること以外、セキュリティアソシエーションに関する処理を限定するものではないため、ここでは説明を省略する。

以上より、Ｕ−プレーンに関し、各ノード間に設定する必要のあるＧＴＰトンネル数は以下のように表すことができる。

マスタｅＮＢとＭＭＥとの間のＧＴＰトンネル数 ＝（マスタｅＮＢとＭＭＥとの間に必要なＧＴＰトンネル数）＋（各スレーブｅＮＢとＭＭＥとの間に必要なＧＴＰトンネル数の総数）
マスタｅＮＢとスレーブｅＮＢとの間のＧＴＰトンネル数 ＝（マスタｅＮＢとスレーブｅＮＢとの間に必要なＧＴＰトンネル数）＋（スレーブｅＮＢとＭＭＥとの間に必要なＧＴＰトンネル数）
なお、以降、マスタｅＮＢ３１とサービングＧＷ２０との間に確立されるＧＴＰトンネルをサービングＧＷトンネルとも表記し、マスタｅＮＢ３１とスレーブｅＮＢ３２との間に確立されるＧＴＰトンネルをＮＢ（NodeB）トンネルとも表記する。

このように、本実施形態によれば、従来では図１７に示すようにＭＭＥにはｅＮＢの数分セキュリティアソシエーションが確立されていたところ、図４に示すようにマスタｅＮＢとＭＭＥ１０との間にのみセキュリティアソシエーションを確立すればよくなる。従って、本実施形態によれば、ＭＭＥで確立及び管理されるセキュリティアソシエーションの数を減らすことができる。

〔装置構成〕
以下、本実施形態における移動通信システムを構成する各装置（以降、ノードとも表記
する）の機能についてそれぞれ説明する。なお、ＵＥ３０については本実施形態における移動通信システムのようなＬＴＥ移動通信システムに接続可能な機能を有していればよいため、ここでは説明を省略する。また、各ノードについても、Ｃ−プレーンにおけるスレーブデータチャンク及びＵ−プレーンにおけるスレーブＧＴＰパケットに関連しない機能については従来と変わるところがないためここでは説明を省略する。

〈ＭＭＥ〉
図５は、本実施形態におけるＭＭＥ１０の機能構成を示すブロック図である。図５に示されるように、ＭＭＥ１０は、ＳＣＴＰインタフェース部６１、ストリームＩＤ管理部６２、Ｃ−プレーン制御部６３、Ｕ−プレーン情報管理部６４、サービングＧＷインタフェース部６５等を有する。これら図５に示すＭＭＥ１０の各機能部は、それぞれハードウェア回路で実現されるようにしてもよいし、メモリに記憶された制御プログラムがＣＰＵ（Central Processing Unit）にロードされ実行されることにより実現されるようにしても
よい。なお、図５は、本実施形態として特徴ある機能部を主に示しているため、ＭＭＥ１０は、図５に示す機能部以外の機能部を更に備えるようにしてもよい。

ＳＣＴＰインタフェース部６１は、ＩＰ網５に接続され、Ｃ−プレーンに関する通信処理を実行する。ＳＣＴＰインタフェース部６１は、Ｃ−プレーン制御部６３からＳ１−ＡＰメッセージを含むスレーブデータチャンク及びＩＮＩＴ−ＡＣＫチャンク等の制御チャンクを受け、それらをＩＰ網５へ送出する。一方、ＳＣＴＰインタフェース部６１は、ＩＰ網５からＳＣＴＰデータチャンクを受信すると、それに設定されているストリームＩＤ及びそのデータチャンクをＣ−プレーン制御部６３に送る。

Ｃ−プレーン制御部６３は、呼制御、リソース制御等を行う。Ｃ−プレーン制御部６３は、ＳＣＴＰアソシエーション確立時にはマスタｅＮＢ３１から送信されたＩＮＩＴチャンクをＳＣＴＰインタフェース部６１を介して受信し、このＩＮＩＴチャンクに含まれるアウトバウンドストリーム数及びインバウンドストリーム数を満たすようにストリームＩＤの割り当てを行う。ＳＣＴＰのストリームＩＤは各アソシエーションにおいてそれぞれユニークであればよいため、ＭＭＥ１０は、例えば、ＭＭＥアソシエーションに関し、０（ゼロ）から要求ストリーム数まで１ずつインクリメントするようにストリームＩＤを割り当ててもよい。Ｃ−プレーン制御部６３は、ストリームＩＤの割り当てを行うと、割り当てに成功したアウトバウンドストリーム数及びインバウンドストリーム数を含めたＩＮＩＴ−ＡＣＫチャンクをＳＣＴＰインタフェース部６１へ送る。

Ｃ−プレーン制御部６３は、スレーブデータチャンク及びそれに設定されていたストリームＩＤをＳＣＴＰインタフェース部６１を介して受信すると、このスレーブデータチャンクの対象となるＵＥコンテキスト又はｅＮＢに関する情報とこのストリームＩＤとをストリームＩＤ管理部６２へ送る。

また、Ｃ−プレーン制御部６３は、Ｓ１−ＡＰメッセージを生成する。Ｃ−プレーン制御部６３は、生成されたＳ１−ＡＰメッセージの宛先に対応するストリームＩＤをストリームＩＤ管理部６２から取得し、そのＳ１−ＡＰメッセージを含むデータチャンクにそのストリームＩＤを設定し、ＳＣＴＰインタフェース部６１へ送る。

Ｃ−プレーン制御部６３は、更に、Ｕ−プレーンのＧＴＰトンネル確立のための処理を実行する。Ｃ−プレーン制御部６３は、サービングＧＷ２０に関するトンネルエンドポイント情報を生成する。具体的には、Ｃ−プレーン制御部６３は、サービングＧＷ２０に関し、スレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤを生成する。生成されたサービングＧＷ２０に関するトンネルエンドポイント情報は、Ｕ−プレーン情報管理部６４へ送られる。

Ｃ−プレーン制御部６３は、ＧＴＰトンネル確立のための処理として、Ｓ１−ＡＰメッセージ（INITIAL CONTEXT SETUP REQUEST又はRAB SETUP REQUEST）を含むスレーブデータチャンクを生成する。Ｃ−プレーン制御部６３は、このスレーブデータチャンクに、対象のＵＥコンテキスト若しくは対象のノードに対応するスレーブデータチャンク転送用のストリームＩＤを設定し、かつ上記サービングＧＷ２０に関するトンネルエンドポイント情報を設定する。Ｃ−プレーン制御部６３は、このように生成されたスレーブデータチャンクをＳＣＴＰインタフェース部６１へ送る。

Ｃ−プレーン制御部６３は、応答としてのＳ１−ＡＰメッセージ（INITIAL CONTEXT SETUP RESPONSE又はRAB SETUP RESPONSE）を含むスレーブデータチャンクをＳＣＴＰインタフェース部６１を介して受信する。Ｃ−プレーン制御部６３は、このスレーブデータチャンクに設定されているトンネルエンドポイント情報を抽出し、このトンネルエンドポイント情報をＵ−プレーン情報管理部６４へ送る。

ストリームＩＤ管理部６２は、ＵＥコンテキスト又はｅＮＢ毎に、それに利用される各ストリームＩＤをそれぞれ保持する。ストリームＩＤ管理部６２は、Ｃ−プレーン制御部６３から所定のＵＥコンテキスト又はｅＮＢに関するストリームＩＤを要求されると、保持される情報の中からこの要求に合致するストリームＩＤをＣ−プレーン制御部６３に送る。

Ｕ−プレーン情報管理部６４は、Ｃ−プレーン制御部６３により生成されたサービングＧＷ２０に関するトンネルエンドポイント情報、及びＳ１−ＡＰメッセージ（INITIAL CONTEXT SETUP RESPONSE又はRAB SETUP RESPONSE）を含むスレーブデータチャンクに設定されていたトンネルエンドポイント情報を保持する。これらの情報は、一方のトンネルエンドポイント情報が設定されたスレーブデータチャンクを受信した場合に、これに対する応答となるスレーブデータチャンクにもう１方のトンネルエンドポイント情報が設定されるという対向関係にある。Ｕ−プレーン情報管理部６４は、このように対向するトンネルエンドポイント情報を保持すると共に、それらをサービングＧＷインタフェース部６５に送る。

サービングＧＷインタフェース部６５は、Ｕ−プレーン情報管理部６４から送られるトンネルエンドポイント情報をＩＰ網５を介してサービングＧＷ２０へ送信する。

〈サービングＧＷ〉
図６は、本実施形態におけるサービングＧＷ２０の機能構成を示すブロック図である。図６に示されるように、サービングＧＷ２０は、ＧＴＰインタフェース部７１、Ｕ−プレーン制御部７２、トンネルエンドポイント情報管理部７３、ＭＭＥインタフェース部７４等を有する。これら図６に示すサービングＧＷ２０の各機能部は、それぞれハードウェア回路で実現されるようにしてもよいし、メモリに記憶された制御プログラムがＣＰＵにロードされ実行されることにより実現されるようにしてもよい。なお、図６は、本実施形態として特徴ある機能部を主に示しているため、サービングＧＷ２０は、図６に示す機能部以外の機能部を更に備えるようにしてもよい。

ＧＴＰインタフェース部７１は、ＩＰ網５に接続され、Ｕ−プレーンに関する通信処理を実行する。ＧＴＰインタフェース部７１は、Ｕ−プレーン制御部７２からＧＴＰデータパケット（スレーブＧＴＰパケットを含む）を受け、それらをＩＰ網５へ送出する。一方、ＧＴＰインタフェース部７１は、ＩＰ網５からＧＴＰデータパケットを受信すると、それをＵ−プレーン制御部７２に送る。

ＭＭＥインタフェース部７４は、ＩＰ網５に接続され、ＭＭＥ１０との間の通信処理を実行する。ＭＭＥインタフェース部７４は、ＭＭＥ１０のサービングＧＷインタフェース部６５から送られるトンネルエンドポイント情報を受信し、これをトンネルエンドポイント情報管理部７３に送る。

トンネルエンドポイント情報管理部７３は、ＭＭＥ１０から送られる自身（サービングＧＷ２０）に関するトンネルエンドポイント情報及びそれに対向するトンネルエンドポイント情報を受け、これらを保持する。

Ｕ−プレーン制御部７２は、Ｕ−プレーンに関する通信処理を行う。具体的には、Ｕ−プレーン制御部７２は、ＧＴＰデータパケットを生成する。このとき、Ｕ−プレーン制御部７２は、トンネルエンドポイント情報管理部７３で保持されているトンネルエンドポイント情報に基づいて、このスレーブＧＴＰパケットに設定するＴＥ−ＩＤを決定する。Ｕ−プレーン制御部７２は、このようにＴＥ−ＩＤが設定されたスレーブＧＴＰパケットをＧＴＰインタフェース部７１へ送る。

〈マスタｅＮＢ〉
図７は、本実施形態におけるマスタｅＮＢ３１の機能構成を示すブロック図である。図７に示すように、マスタｅＮＢ３１は、無線処理部８１、ベースバンド処理部８２、Ｃ−プレーン処理部８３、Ｕ−プレーン処理部８４、ルーティングテーブル８５、ＧＴＰトンネル変換テーブル８６、ＳＣＴＰインタフェース部８７、ＧＴＰインタフェース部８８等を有する。Ｃ−プレーン処理部８３は、本発明の第一態様における第一確立手段、第二確立手段、テーブル生成手段等に相当する。ルーティングテーブル８５は、本発明の第一態様における転送テーブルに相当する。ＳＣＴＰインタフェース部８７及びＧＴＰインタフェース部８８は、本発明の第一態様における転送手段に相当する。

これらマスタｅＮＢ３１の各機能部は、それぞれハードウェア回路で実現されるようにしてもよいし、メモリに記憶された制御プログラムがＣＰＵにロードされ実行されることにより実現されるようにしてもよい。なお、図７は、本実施形態として特徴ある機能部を中心に示しているため、マスタｅＮＢ３１は、図７に示す機能部以外の機能部も更に備えるようにしてもよい。

無線処理部８１及びベースバンド処理部８２は、本実施形態における移動通信システムと接続するＵＥ３との間で送受される信号を処理する。但し、無線処理部８１及びベースバンド処理部８２は、特に本実施形態として特徴を有する機能部ではないため、ここでは簡単に概略を説明する。

無線処理部８１は、アンテナに接続され、このアンテナからＵＥ３へ送信されるべき信号及びアンテナにより受信されたＵＥ３からの信号を処理する。無線処理部８１は、ベースバンド処理部８２から送られるベースバンド信号から無線信号を生成し、生成された無線信号をアンテナから送出する。一方、無線処理部８１は、アンテナにより受信された無線信号をベースバンド信号へ周波数変換し、このベースバンド信号をベースバンド処理部８２へ送る。

ベースバンド処理部８２は、スケジューラ、多重化部（図示せず）等から構成され、ＵＥ３から送信されたデータパケット及び制御データ等を処理する。ここで処理されたデータパケット及び制御データ等は、Ｃ−プレーン処理部８３及びＵ−プレーン処理部８４へ送られる。また、ベースバンド処理部８２は、ＵＥ３へ送信されるべきデータパケット等をＣ−プレーン処理部８３及びＵ−プレーン処理部８４から受け、これらを多重化させたベースバンド信号を生成し、無線処理部８１へ送る。

Ｃ−プレーン処理部８３は、Ｃ−プレーン（ＳＣＴＰ層）に関する処理を行う。具体的には、Ｃ−プレーン処理部８３は、ＳＣＴＰアソシエーション確立処理、ルーティングテーブル８５の設定、更新及び解放処理を実行する。

Ｃ−プレーン処理部８３は、ＭＭＥアソシエーションを確立するべく、マスタｅＮＢ３１とＭＭＥ１０との間に必要なアウトバウンドストリーム数及びインバウンドストリーム数を決定する。これらは、予めシステム内で固定的に決められた最大数に決定されてもよいし、実際に稼動しているスレーブｅＮＢ３２及びマスタｅＮＢ３１の台数に基づいて決定するようにしてもよい。本実施形態では、各ノード間に２本のアウトバウンドストリームと２本のインバウンドストリームとがそれぞれ設定されるため、アウトバウンドストリーム数が４（＝２＋（２×Ｎ））（Ｎ：スレーブｅＮＢの数）に決定され、インバウンドストリーム数が４（＝２＋（２×Ｎ））（Ｎ：スレーブｅＮＢの数）に決定される。Ｃ−プレーン処理部８３は、このように決定されたアウトバウンドストリーム数及びインバウンドストリーム数を設定したＩＮＩＴチャンクを生成し、ＳＣＴＰインタフェース部８７へ送る。

Ｃ−プレーン処理部８３は、このＩＮＩＴチャンクの応答となるＩＮＩＴ−ＡＣＫチャンクをＳＣＴＰインタフェース部６１を介して受信する。このＩＮＩＴ−ＡＣＫチャンクには、ＩＮＩＴチャンクを受信したＭＭＥ１０において確保することのできたストリーム数が設定されている。Ｃ−プレーン処理部８３は、このＩＮＩＴ−ＡＣＫチャンクに設定されているストリーム数に基づいて、要求したストリーム数がＭＭＥ１０において確保されたか否かを判断する。ここで、ＩＮＩＴ−ＡＣＫチャンクに含まれるストリーム数がＩＮＩＴチャンクで要求したストリーム数よりも少ない場合には、スレーブｅＮＢ３２に関するスレーブデータチャンク転送用のストリームが確保されなかったと判断するようにしてもよい。この場合には、スレーブｅＮＢ３２には、通常の接続形態として図１５に示すように直接ＭＭＥ１０へＩＮＩＴチャンクを送信しアソシエーションの確立を要求するようにしてもよい。Ｃ−プレーン処理部８３は、ＩＮＩＴ−ＡＣＫチャンクを受けると、それに含まれるストリーム数分、ＭＭＥアソシエーションのためのストリームＩＤを割り当てる。

一方で、Ｃ−プレーン処理部８３は、スレーブｅＮＢ３２からのＩＮＩＴチャンクを受けた場合には、それに設定されているアウトバウンドストリーム数及びインバウンドストリーム数を取得する。このとき、このＩＮＩＴチャンクでは、アウトバウンド及びインバウンド双方に関し、マスタｅＮＢ３１とスレーブｅＮＢ３２との間で送受されるＸ２データチャンクのための各２本のストリーム、及びＭＭＥ１０とスレーブｅＮＢ３２との間で送受されるスレーブデータチャンクのための各２本のストリームを設定するよう要求されている。Ｃ−プレーン処理部８３は、この設定要求に応じて、ＮＢアソシエーションに要求された数分のストリームＩＤを割り当てる。

ＮＢアソシエーションに設定されるストリームのうち、スレーブデータチャンク転送用のストリームＩＤについては、システムとして予め固定的に決められるようにしてもよい。ストリームＩＤのみでスレーブデータチャンクか否かを判別可能とするために、２バイトで定義されるストリームＩＤのうちの最下位ビットを判別ビットとみなし、この判別ビットが１となるストリームＩＤがスレーブデータチャンク転送用として決められ、この判別ビットが０となるストリームＩＤがスレーブデータチャンク以外のデータチャンク転送用に決められるようにしてもよい。この例によれば、本実施形態では、マスタｅＮＢ３１とスレーブｅＮＢ３２との間で設定される４本のＳＣＴＰストリームのうち２本のＳＣＴＰストリームのストリームＩＤが１に決められる。

Ｃ−プレーン処理部８３は、このようにＮＢアソシエーションに所定数のストリームを設定すると、確保されたアウトバウンドストリーム数及びインバウンドストリーム数を設定したＩＮＩＴ−ＡＣＫチャンクを生成し、ＳＣＴＰインタフェース部８７へ送る。

Ｃ−プレーン処理部８３は、このようにスレーブｅＮＢ３２のスレーブデータチャンク転送用のストリームＩＤをＭＭＥアソシエーション及びＮＢアソシエーションについてそれぞれ割り当てると、これらの情報をルーティングテーブル８５に設定する。また、Ｃ−プレーン処理部８３は、スレーブｅＮＢ３２からＸ２データチャンクとしてＳＨＵＴ−ＤＯＷＮチャンクを受信した場合には、そのスレーブｅＮＢ３２のためのスレーブデータチャンク転送用のストリームＩＤをこのルーティングテーブルから削除する。

ルーティングテーブル８５は、スレーブデータチャンク転送時に、ＳＣＴＰインタフェース部８７により参照される。図８は、スレーブデータチャンク転送用ルーティングテーブルの例を示す図である。図８に示されるように、ルーティングテーブル８５には、受信されたデータチャンク情報と転送先データチャンク情報とが対になって格納される。各データチャンク情報には、そのデータチャンクが送られるアソシエーションを示すアソシエーションＩＤ及びストリームを示すストリームＩＤがそれぞれ設定される。

具体的には、Ｃ−プレーン処理部８３が、ＭＭＥから送られるスレーブデータチャンクをスレーブｅＮＢ３２に転送するために、ＭＭＥアソシエーションのアソシエーションＩＤ（図８の「Ａ」）とスレーブデータチャンク転送用のインバウンドストリームＩＤ（図８の「ａ」）とを受信データチャンク情報として設定し、それに対する転送先データチャンク情報としてＮＢアソシエーションのアソシエーションＩＤ（図８の「Ｂ」）とスレーブデータチャンク転送用のアウトバウンドストリームＩＤ（図８の「ｂ」）とを設定する。このとき、例えば、ＮＢアソシエーション内のスレーブデータチャンク転送用のアウトバウンドストリームＩＤの最下位ビットは１となる。

逆に、Ｃ−プレーン処理部８３は、スレーブｅＮＢ３２から送られるスレーブデータチャンクをＭＭＥ１０に転送するために、ＮＢアソシエーションのアソシエーションＩＤ（図８の「Ｂ」）とスレーブデータチャンク転送用のインバウンドストリームＩＤ（図８の「ｂ」）とを受信データチャンク情報として設定し、それに対する転送先データチャンク情報としてＭＭＥアソシエーションのアソシエーションＩＤ（図８の「Ａ」）とスレーブデータチャンク転送用のアウトバウンドストリームＩＤ（図８の「ａ」）とを設定する。

なお、図８の例では、ＮＢアソシエーションにおけるスレーブデータチャンク転送用のストリームＩＤは、インバウンド及びアウトバウンド共に同一のストリームＩＤが利用されているが、異なるストリームＩＤが利用されるようにしてもよい。この場合、スレーブｅＮＢ３２においてそのストリームＩＤがスレーブデータチャンク転送用のものであると判断できる値に決定されるようにすればよい。

ＳＣＴＰインタフェース部８７は、ＩＰ網５及び６に接続され、Ｃ−プレーンに関する通信処理を実行する。具体的には、ＳＣＴＰインタフェース部８７は、Ｃ−プレーン処理部８３から送られるＩＮＩＴチャンク、ＩＮＩＴ−ＡＣＫチャンク、Ｘ２−ＡＰメッセージ（GTP TUNNEL SETUP RESPONSE）又は（GTP TUNNEL RELEASE RESPONSE）を含むＸ２データチャンク等を受け、ＩＰ網５又は６へ送出する。一方、ＳＣＴＰインタフェース部８７は、ＩＰ網５又は６からＩＮＩＴチャンク、ＩＮＩＴ−ＡＣＫチャンク、Ｘ２−ＡＰメッセージ（GTP TUNNEL SETUP REQUEST）又は（GTP TUNNEL RELEASE REQUEST）を含むＸ２データチャンクを受け、これらをＣ−プレーン処理部８３へ送る。

更に、ＳＣＴＰインタフェース部８７は、ルーティングテーブル８５を参照することに
より、スレーブデータチャンクの転送処理を実行する。ＳＣＴＰインタフェース部８７は、ＩＰ網５又は６からデータチャンクを受信すると、このデータチャンクに設定されているストリームＩＤに基づいてそのデータチャンクがスレーブデータチャンクか否かを判断する。このとき、ストリームＩＤに判別ビットが定義されている場合にはその判別ビットにより判断されてもよいし、そのストリームＩＤがルーティングテーブル８５に格納されているか否かにより判断されるようにしてもよい。ストリームＩＤがルーティングテーブル８５に格納されている場合には、それはスレーブデータチャンク転送用のストリームＩＤとして判断できる。

ＳＣＴＰインタフェース部８７は、受信されたスレーブデータチャンクに設定されているストリームＩＤがルーティングテーブル８５の受信データチャンク情報フィールドに設定されているレコードを検索し、このレコードの転送先データチャンク情報フィールドに設定されているＳＣＴＰアソシエーションＩＤ及びストリームＩＤを抽出する。ＳＣＴＰインタフェース部８７は、受信されたスレーブデータチャンクのアソシエーションＩＤ及びストリームＩＤをこのように抽出されたＳＣＴＰアソシエーションＩＤ及びストリームＩＤに書き換え、転送する。

なお、スレーブデータチャンク以外のデータチャンクについては、受信時には、その受信データチャンクをＣ−プレーン処理部８３へ送り、送信時には、Ｘ２データチャンクの場合にはそれ用のストリームＩＤを利用してスレーブｅＮＢ３２へ送信し、マスタｅＮＢ３１とＭＭＥ１０との間のＳ１インタフェースのデータチャンクの場合にはそれ用のストリームＩＤを利用してＭＭＥ１０へ送信する。

Ｕ−プレーン処理部８４は、Ｕ−プレーン（ＧＴＰ層）に関する処理を行う。具体的には、まず、Ｕ−プレーン処理部８４は、マスタｅＮＢ３１とスレーブｅＮＢ３２との間に確立されるセキュリティアソシエーションに関しそれぞれトンネルエンドポイント情報（ＴＥ−ＩＤ）を生成する。すなわち、Ｕ−プレーン処理部８４は、自身のトランスポートアドレス及びサービングＧＷ方向のスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤと、自身のトランスポートアドレス及びスレーブｅＮＢ３２方向のスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤとを生成する。

Ｕ−プレーン処理部８４は、これら生成された２つのトンネルエンドポイント情報をＣ−プレーン処理部８３へ送り、これらトンネルエンドポイント情報が設定されたＸ２データチャンク（Ｘ２−ＡＰメッセージ（GTP TUNNEL SETUP RESPONSE））をスレーブｅＮＢ
３２へ送信するように要求する。

Ｕ−プレーン処理部８４は、更に、Ｃ−プレーン処理部８３からＸ２−ＡＰメッセージ（GTP TUNNEL SETUP REQUEST）を含むＸ２データチャンクに設定されていたトンネルエンドポイント情報を受ける。このトンネルエンドポイント情報は、サービングＧＷ２０におけるトランスポートアドレス及びスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤとスレーブｅＮＢ３２におけるトランスポートアドレス及びスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤとを含んでいる。

Ｕ−プレーン処理部８４は、自身で生成したサービングＧＷ２０方向のトンネルエンドポイント情報及びスレーブｅＮＢ３２方向のトンネルエンドポイント情報と、Ｃ−プレーン処理部８３から送られたサービングＧＷ２０及びスレーブｅＮＢ３２のトンネルエンドポイント情報と、を対応付け、ＧＴＰトンネル変換テーブル８６に設定する。また、Ｕ−プレーン処理部８４は、Ｃ−プレーン処理部８３からＸ２−ＡＰメッセージ（GTP TUNNEL
RELEASE REQUEST）と共に対象となるトンネルエンドポイント情報を受けるとそのスレー
ブＧＴＰパケット転送用のトンネルエンドポイント情報をこのＧＴＰトンネル変換テーブル８６から削除する。

ＧＴＰトンネル変換テーブル８６は、スレーブＧＴＰパケット転送時に、ＧＴＰインタフェース部８８により参照される。図９は、スレーブＧＴＰパケット転送用のＧＴＰトンネル変換テーブルの例を示す図である。図９に示されるように、ＧＴＰトンネル変換テーブル８６には、受信されたＧＴＰトンネル情報と転送先ＧＴＰトンネル情報とが対になって格納される。各ＧＴＰトンネル情報には、スレーブＧＴＰパケット転送用のＧＴＰトンネルに関するトランスポートアドレス及びＴＥ−ＩＤがそれぞれ設定される。

具体的には、Ｕ−プレーン処理部８４が、このＧＴＰトンネル変換テーブル８６に対し、自身で生成した、自身のトランスポートアドレス及びスレーブｅＮＢ３２方向のインバウンドＧＴＰトンネルのＴＥ−ＩＤを受信ＧＴＰトンネル情報として設定し、これに対する転送先ＧＴＰトンネル情報としてＣ−プレーン処理部８３から送られたサービングＧＷ２０のトランスポートアドレス及びインバウンドＧＴＰトンネルのＴＥ−ＩＤを設定する。更に、Ｕ−プレーン処理部８４が、このＧＴＰトンネル変換テーブル８６に対し、自身で生成した、自身のトランスポートアドレス及びサービングＧＷ２０方向のインバウンドＧＴＰトンネルのＴＥ−ＩＤを受信ＧＴＰトンネル情報として設定し、これに対する転送先ＧＴＰトンネル情報としてＣ−プレーン処理部８３から送られたスレーブｅＮＢ３２のトランスポートアドレス及びインバウンドＧＴＰトンネルのＴＥ−ＩＤを設定する。

ＧＴＰインタフェース部８８は、ＩＰ網５及び６に接続され、Ｕ−プレーンに関する通信処理を実行する。具体的には、ＧＴＰインタフェース部８８は、Ｕ−プレーン処理部８４から送られるＧＴＰデータパケットを受け、ＩＰ網５又は６へ送出する。一方、ＧＴＰインタフェース部８８は、ＩＰ網５又は６からスレーブＧＴＰパケットを含むＧＴＰデータパケットを受け、スレーブＧＴＰパケット以外のＧＴＰデータパケットをＵ−プレーン処理部８４へ送る。

スレーブＧＴＰパケットを受信した場合には、ＧＴＰインタフェース部８８は、ＧＴＰトンネル変換テーブル８６を参照することにより、スレーブＧＴＰデータパケットの転送処理を実行する。ＧＴＰインタフェース部８８は、ＩＰ網５又は６からＧＴＰデータパケットを受信すると、このＧＴＰデータパケットに設定されているトランスポートアドレス及びＴＥ−ＩＤに基づいてそのＧＴＰデータパケットがスレーブＧＴＰパケットか否かを判断する。このとき、ＧＴＰインタフェース部８８は、そのトンネルエンドポイント情報がＧＴＰトンネル変換テーブル８６に格納されている場合には、そのＧＴＰデータパケットがスレーブＧＴＰパケットであると判断する。

ＧＴＰインタフェース部８８は、受信されたスレーブＧＴＰパケットに設定されているＴＥ−ＩＤ及びトランスポートアドレスがＧＴＰトンネル変換テーブル８６の受信ＧＴＰトンネル情報フィールドに設定されているレコードを検索し、このレコードの転送先ＧＴＰトンネル情報フィールドに設定されているトランスポートアドレス及びＴＥ−ＩＤを抽出する。ＧＴＰインタフェース部８８は、受信されたスレーブＧＴＰパケットのトランスポートアドレス及びＴＥ−ＩＤをこのように抽出されたトランスポートアドレス及びＴＥ−ＩＤに書き換え、転送する。

〈スレーブｅＮＢ〉
図１０は、本実施形態におけるスレーブｅＮＢ３２の機能構成を示すブロック図である。図１０に示すように、スレーブｅＮＢ３２は、図７に示されるマスタｅＮＢ３１の有する機能部のうち、ルーティングテーブル８５及びＧＴＰトンネル変換テーブル８６を持たないこと以外、上述のマスタｅＮＢ３１と略同様の機能部を有する。以下、マスタｅＮＢ
３１と異なる機能についてのみ説明する。

ＳＣＴＰインタフェース部９７及びＧＴＰインタフェース部９８は、スレーブデータチャンクの転送機能を持つ必要がない。同様に、Ｃ−プレーン処理部９３及びＵ−プレーン処理部９４は、ルーティングテーブル８５及びＧＴＰトンネル変換テーブル８６の管理機能を持つ必要がない。

Ｃ−プレーン処理部９３は、ＮＢアソシエーションに設定すべきアウトバウンドストリーム数及びインバウンドストリーム数を決定し、これらを設定したＩＮＩＴチャンクを生成する。また、Ｃ−プレーン処理部９３は、ＮＢアソシエーションに設定されるスレーブデータチャンク転送用のストリームＩＤを保持し、Ｓ１−ＡＰメッセージを送信する際にそれを含むスレーブデータチャンクにそのストリームＩＤを設定する。

Ｕ−プレーン処理部９４は、スレーブＧＴＰパケット転送用のＧＴＰトンネルを確立するために、自身（スレーブｅＮＢ３２）に関するトンネルエンドポイント情報を生成する。具体的には、Ｕ−プレーン処理部９４は、マスタｅＮＢ３１とスレーブｅＮＢ３２との間に確立されているセキュリティアソシエーションに関し、スレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤを生成する。Ｕ−プレーン処理部９４は、このように生成された自身のトンネルエンドポイント情報と共に、スレーブｅＮＢ３２から送られるスレーブｅＮＢ３２におけるトランスポートアドレス及びスレーブｅＮＢ３２方向のスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤ（以降、ＧＴＰＩＤ＃２と表記する）をそれぞれ対向するトンネルエンドポイント情報として保持する。これにより、Ｕ−プレーン処理部９４は、生成されたスレーブＧＴＰパケットのＴＥ−ＩＤにこの保持されるＴＥ−ＩＤを設定すれ。

〔動作例〕
以下、本発明の実施形態における移動通信システムの動作例について、Ｃ−プレーンとＵ−プレーンとに区別してそれぞれ説明する。

〈Ｃ−プレーンの動作例〉
Ｃ−プレーンに関する本移動通信システムの動作は、大きくＳＣＴＰ初期手順とＳＣＴＰデータチャンク転送手順とに分けることができる。以下、ＳＣＴＰ初期手順について図１１を用いて説明し、ＳＣＴＰデータチャンク転送手順について図１２を用いて説明する。

図１１は、本実施形態における移動通信システムのＳＣＴＰ初期手順を示すシーケンス図である。Ｃ−プレーンに関し、本移動通信システムは、上述の〔接続形態〕の項で説明したような各ノード間に所定数のＳＣＴＰストリームが設定されたＳＣＴＰアソシエーションを確立する必要がある。これにより、本移動通信システムは、以下に示すＳＣＴＰ初期手順を実行することにより、各ノード間にＳＣＴＰアソシエーションを確立する。

このＳＣＴＰの初期手順では、まず、マスタｅＮＢ３１が、マスタｅＮＢ３１とＭＭＥ１０との間にＳＣＴＰアソシエーション（ＭＭＥアソシエーション）を確立するべく、ＳＣＴＰのＩＮＩＴチャンクをＭＭＥ１０に送信する（Ｓ７１）。このＩＮＩＴチャンクには、マスタｅＮＢ３１とＭＭＥ１０との間に必要なアウトバウンドストリーム数及びインバウンドストリーム数が含まれる。

図２に示す本実施形態では、各ノード間に２本のアウトバウンドストリームと２本のインバウンドストリームとがそれぞれ設定されるため、マスタｅＮＢ３１とＭＭＥ１０との間には各４本のアウトバウンドストリームとインバウンドストリームとが必要になる。こ
れは、アウトバウンド及びインバウンド双方に関し、マスタｅＮＢ３１とＭＭＥ１０との間で送受されるＳ１−ＡＰメッセージのための各２本のストリーム、及びスレーブｅＮＢ３２とＭＭＥ１０との間で送受されるスレーブデータチャンクのための各２本のストリームから構成される。

以上から、このＩＮＩＴチャンクには、アウトバウンドストリーム数として４（＝２＋（２×Ｎ））（Ｎ：スレーブｅＮＢの数）が設定され、インバウンドストリーム数として４（＝２＋（２×Ｎ））（Ｎ：スレーブｅＮＢの数）が設定される。

ＭＭＥ１０は、このＩＮＩＴチャンクを受信すると、ＭＭＥアソシエーションについて、ＩＮＩＴチャンクに含まれていたアウトバウンドストリーム数及びインバウンドストリーム数を満たすようにストリームＩＤの割り当てを行う。ＭＭＥ１０は、ストリームＩＤの割り当てを行うと、割り当てに成功したアウトバウンドストリーム数及びインバウンドストリーム数を含めたＩＮＩＴ−ＡＣＫチャンクをマスタｅＮＢ３１へ返信する（Ｓ７２）。

マスタｅＮＢ３１は、このＩＮＩＴ−ＡＣＫチャンクを受けると、そのＩＮＩＴ−ＡＣＫチャンクに含まれるアウトバウンドストリーム数及びインバウンドストリーム数を確認し、ＩＮＩＴチャンクで要求したストリーム数が割り当てられたか否かを判断する。全てのストリームが割り当てられている場合には、ＭＭＥアソシエーションの確立処理は完了する。

ここで、ＩＮＩＴ−ＡＣＫチャンクに含まれるストリーム数がＩＮＩＴチャンクで要求したストリーム数よりも少ない場合には、マスタｅＮＢ３１は、スレーブｅＮＢ３２のスレーブデータチャンク用のストリームが確保されなかったと判断し、これにより、以降のマスタｅＮＢ３１とスレーブｅＮＢ３２との間に割り当てるストリーム数を判断するようにしてもよい。この場合には、例えば、スレーブデータチャンク用のストリームが確保できなかったスレーブｅＮＢについては、通常の接続形態として図１５に示すようにスレーブｅＮＢから直接ＭＭＥ１０へ接続するように動作してもよい。

一方、スレーブｅＮＢ３２もまた、マスタｅＮＢ３１とスレーブｅＮＢ３２との間にＳＣＴＰアソシエーション（ＮＢアソシエーション）を確立するべく、ＳＣＴＰのＩＮＩＴチャンクをマスタｅＮＢ３１に送信する（Ｓ７３）。このＩＮＩＴチャンクには、マスタｅＮＢ３１とスレーブｅＮＢ３２との間に必要なアウトバウンドストリーム数及びインバウンドストリーム数が含まれる。

ここでは、マスタｅＮＢ３１とスレーブｅＮＢ３２との間には各４本のアウトバウンドストリームとインバウンドストリームとがそれぞれ必要になる。これは、アウトバウンド及びインバウンド双方に関し、マスタｅＮＢ３１とスレーブｅＮＢ３２との間で送受されるＸ２データチャンクのための各２本のストリーム、及びＭＭＥ１０とスレーブｅＮＢ３２との間で送受されるスレーブデータチャンクのための各２本のストリームから構成される。従って、このＩＮＩＴチャンクには、アウトバウンドストリーム数として４（＝２＋２）が設定され、インバウンドストリーム数として４（＝２＋２）が設定される。

マスタｅＮＢ３１は、このＩＮＩＴチャンクを受信すると、ＮＢアソシエーションに関し、ＩＮＩＴチャンクに含まれていたアウトバウンドストリーム数及びインバウンドストリーム数を満たすようにストリームＩＤの割り当てを行う。

マスタｅＮＢ３１は、ストリームＩＤの割り当てを行うと、割り当てに成功したアウトバウンドストリーム数及びインバウンドストリーム数を含めたＩＮＩＴ−ＡＣＫチャンク
をスレーブｅＮＢ３２へ返信する（Ｓ７４）。ここで、ＩＮＩＴ−ＡＣＫチャンクに含まれるストリーム数がＩＮＩＴチャンクで要求したストリーム数よりも少ない場合には、スレーブｅＮＢ３２は、自身のスレーブデータチャンク用のストリームが確保されなかったと判断するようにしてもよい。この場合には、例えば、スレーブｅＮＢ３２は、通常の接続形態として図１５に示すように直接ＭＭＥ１０へＩＮＩＴチャンクを送信しアソシエーションの確立を要求するようにしてもよい。

マスタｅＮＢ３１は、ＩＮＩＴ−ＡＣＫチャンクの返信を終えると、ＮＢアソシエーションに割り当てられたストリームＩＤのうちスレーブデータチャンク転送用のストリームＩＤを取得し、ＭＭＥアソシエーションに割り当てられたストリームＩＤのうちスレーブデータチャンク転送用のストリームＩＤを取得する。マスタｅＮＢ３１は、これら取得されたストリームＩＤ等の情報に基づいて、スレーブデータチャンク転送用のルーティングテーブル（以降、単にルーティングテーブルと表記する）を更新する（Ｓ７５）。

一方、ＭＭＥアソシエーションのストリームについては、マスタｅＮＢ３１は、割り当てられたＳＣＴＰストリームのうちのいずれかをスレーブｅＮＢ３２のスレーブデータチャンク転送用に決める。この決定方法は特に限定されるものではない。

マスタｅＮＢ３１は、このようにスレーブｅＮＢ３２のスレーブデータチャンク転送用のストリームＩＤをＭＭＥアソシエーション及びＮＢアソシエーションについてそれぞれ取得すると、これらの情報をルーティングテーブル８５に格納する。

マスタｅＮＢ３１は、スレーブｅＮＢ３２から送られるデータチャンク及びＭＭＥ１０から送られるデータチャンクをそれぞれ受信し、これら受信されるデータチャンクのうちスレーブデータチャンクを検出し、検出されたスレーブデータチャンクを図８に示されるルーティングテーブル８５に基づいて転送する。

次に、Ｃ−プレーンに関する本移動通信システムの動作としてＳＣＴＰデータチャンク転送手順について、図１２を用いて説明する。図１２は、本実施形態における移動通信システムのＳＣＴＰデータチャンクの転送手順を示すシーケンス図である。上述のＳＣＴＰ初期手順により各ノード間にＳＣＴＰアソシエーションが確立されると、各ノードは、ＳＣＴＰデータチャンクの送受を開始することができる。

例えば、マスタｅＮＢ３１に接続されるＵＥから発呼等があった場合には、マスタｅＮＢ３１は、ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥとして定義されるＳ１−ＡＰメッセージをＭＭＥ１０へ送信する（Ｓ８１）。なお、本実施形態は、アプリケーション層で処理されるＳ１−ＡＰメッセージ自体を限定するものではないため、ここではＳ１−ＡＰメッセージの詳細及びアプリケーション層の処理についての説明は省略する。

ＭＭＥ１０は、マスタｅＮＢ３１から送られるＳ１−ＡＰメッセージの含まれるＳＣＴＰデータチャンクを受信すると、ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴとして定義されるＳ１−ＡＰメッセージをマスタｅＮＢ３１へ返信する（Ｓ８２）。このとき、Ｓ１−ＡＰメッセージは、スレーブデータチャンク転送用のストリームではなくマスタｅＮＢ３１とＭＭＥ１０との間のＳ１インタフェースで利用されるべく確保されるストリームにより送信される。

このように、マスタｅＮＢ３１が、ＭＭＥ１０宛て又はスレーブｅＮＢ３２宛てにＳＣＴＰデータチャンクを送信する場合には、従来と変わるところがない。スレーブｅＮＢ３２がマスタｅＮＢ３１宛て又は他のスレーブｅＮＢ宛てにＳＣＴＰデータチャンクを送信する場合も同様である。

以下、スレーブｅＮＢ３２が、スレーブデータチャンクを送信する場合、すなわちＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥとして定義されるＳ１−ＡＰメッセージをＭＭＥ１０宛てに送信する場合の動作を以下に説明する。

スレーブｅＮＢ３２は、上述のようなシステム固定のルールに基づいて、ＮＢアソシエーションのスレーブデータチャンク転送用のストリームＩＤを取得し、上記Ｓ１−ＡＰメッセージを含みこの取得されたストリームＩＤが設定されたスレーブデータチャンクをＮＢアソシエーションを利用することによりマスタｅＮＢ３１へ送信する（Ｓ８３）。図８のルーティングテーブル８５の例によれば、このスレーブデータチャンクには、アソシエーションＩＤとして「Ｂ」が設定され、ストリームＩＤとして「ｂ」が設定される。

マスタｅＮＢ３１は、このスレーブデータチャンクを受信すると、このスレーブデータチャンクに設定されているアソシエーションＩＤ及びストリームＩＤを取得する。マスタｅＮＢ３１は、ルーティングテーブルからこの取得された情報が受信データチャンク情報として設定されているレコードを抽出し、このレコードの転送先データチャンク情報を取得する（Ｓ８４）。図８のルーティングテーブルの例によれば、マスタｅＮＢ３１は、転送先データチャンク情報として、アソシエーションＩＤ「Ａ」及びストリームＩＤ「ａ」を抽出する。

マスタｅＮＢ３１は、スレーブｅＮＢ３２から受信されたスレーブデータチャンクのアソシエーションＩＤ及びストリームＩＤをそれぞれルーティングテーブルから抽出された情報に書き換え、この書き換えられたスレーブデータチャンクをＭＭＥ１０へ送信する（Ｓ８５）。なお、マスタｅＮＢ３１は、スレーブｅＮＢ３２から受信されたデータチャンクから抽出されるストリームＩＤがスレーブデータチャンク転送用の値でないと判断するか、或いは、当該抽出されるアソシエーションＩＤ及びストリームＩＤの組み合わせがルーティングテーブルにないと判断した場合には、そのデータチャンクがＸ２データチャンクであると判断し、転送処理を行わない。

ＭＭＥ１０は、マスタｅＮＢ３１を経由してＭＭＥアソシエーションから上記スレーブデータチャンクを受信すると、このスレーブデータチャンクに格納されるスレーブデータチャンク転送用のストリームＩＤを保持する（Ｓ８６）。このとき、ＭＭＥ１０は、スレーブデータチャンクに格納されるＵＥコンテキスト或いはｅＮＢ情報と対になるようにこのストリームＩＤを保持する。

ＭＭＥ１０は、このＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥとして定義されるＳ１−ＡＰメッセージを含むスレーブデータチャンクを受けると、このＳ１−ＡＰメッセージの応答となるＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴとして定義されるＳ１−ＡＰメッセージを生成し、これをスレーブｅＮＢ３２へ返信する。ＭＭＥ１０は、この生成されたＳ１−ＡＰメッセージを含み、先に保持したストリームＩＤとＭＭＥアソシエーションを示すアソシエーションＩＤが設定されたスレーブデータチャンクを生成し、これをマスタｅＮＢ３１へ送信する（Ｓ８７）。この場合、図８のルーティングテーブルの例によれば、このスレーブデータチャンクには、アソシエーションＩＤとして「Ａ」が設定され、ストリームＩＤとして「ａ」が設定される。

マスタｅＮＢ３１は、このスレーブデータチャンクを受信すると、このスレーブデータチャンクに設定されているアソシエーションＩＤ及びストリームＩＤを取得する。マスタｅＮＢ３１は、ルーティングテーブルからこの取得された情報が受信データチャンク情報として設定されているレコードを抽出し、このレコードの転送先データチャンク情報を取得する（Ｓ８８）。図８のルーティングテーブルの例によれば、マスタｅＮＢ３１は、転
送先データチャンク情報として、アソシエーションＩＤ「Ｂ」及びストリームＩＤ「ｂ」を抽出する。

マスタｅＮＢ３１は、スレーブｅＮＢ３２から受信されたスレーブデータチャンクのアソシエーションＩＤ及びストリームＩＤをそれぞれルーティングテーブルから抽出された情報に書き換え、この書き換えられたスレーブデータチャンクをスレーブｅＮＢ３２へ送信する（Ｓ８９）。なお、マスタｅＮＢ３１は、ＭＭＥ１０から受信されたデータチャンクから抽出されるアソシエーションＩＤ及びストリームＩＤの組み合わせがルーティングテーブルにないと判断した場合には、そのデータチャンクがスレーブデータチャンクではなくマスタｅＮＢ３１とＭＭＥ１０との間のＳ１インタフェース用のデータチャンクであると判断し、転送処理を行わない。

〈Ｕ−プレーンの動作例〉
Ｕ−プレーンに関する本移動通信システムの動作は、大きくＧＴＰトンネル確立手順、ＧＴＰデータパケット転送手順及びＧＴＰトンネルの解放手順に分けることができる。以下、ＧＴＰトンネル確立手順について図１３を用いて説明し、ＧＴＰデータパケット転送手順及びＧＴＰトンネルの解放手順について図１４を用いて説明する。

図１３は、本実施形態における移動通信システムのＧＴＰトンネル確立手順を示すシーケンス図である。Ｕ−プレーンに関し、本移動通信システムは、上述の〔接続形態〕の項で説明したような各ノード間に所定数のＧＴＰトンネルを確立する必要がある。これにより、本移動通信システムは、以下に示すＧＴＰトンネル確立手順を実行することにより、各ノード間にＧＴＰトンネルを確立する。なお、このとき、ＩＰＳｅｃ等のシーケンスが実行され、各ノード間には〔接続形態〕の項で説明したような２本のセキュリティアソシエーションがそれぞれ確立されているものとする。本実施形態では、このセキュリティアソシエーション確立手法を限定するものではないため、ここでは説明を省略する。

なお、図１３は、本実施形態において各ノード間に確立されるＧＴＰトンネルのうち、スレーブＧＴＰパケット転送用に利用されるＧＴＰトンネルを確立する手順を示している。その他のＧＴＰデータパケット転送用に利用されるＧＴＰトンネルについては従来と同様の手法により確立されればよいため、ここでは説明を省略する。

ＧＴＰトンネル確立時には、各エンドポイントは、自身のトランスポートアドレス及びトンネルエンドポイントＩＤ（以降、ＴＥ−ＩＤと表記する）をそれぞれ決め、これら決定された情報を相互に通知し合う。スレーブＧＴＰパケットについてのエンドポイントは、本来、サービングＧＷ２０及びスレーブｅＮＢ３２である。しかしながら、本実施形態では、スレーブＧＴＰパケットがマスタｅＮＢ３１を経由するため、マスタｅＮＢ３１におけるスレーブｅＮＢ３２方向のエンドポイントとサービングＧＷ２０方向のエンドポイントが存在する。

ＭＭＥ１０は、Ｃ−プレーンにおいてＳ１−ＡＰメッセージ（INITIAL CONTEXT SETUP REQUEST又はRAB SETUP REQUEST）を送信するタイミングにおいて、そのＳ１−ＡＰメッセージのエンドポイントとなるスレーブｅＮＢ３２のためのスレーブＧＴＰパケット転送用のＧＴＰトンネルに関する確立処理を開始する。

まず、ＭＭＥ１０は、サービングＧＷ２０に関するトンネルエンドポイント情報を生成する（Ｓ９０）。具体的には、ＭＭＥ１０は、サービングＧＷ２０に関し、トランスポートアドレス及びスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤ（以降、ＧＴＰＩＤ＃１と表記する）を生成する。ＭＭＥ１０により生成されたこのサービングＧＷ２０のトンネルエンドポイント情報は、サービングＧＷ２０へ通知される。
なお、このサービングＧＷ２０のトンネルエンドポイント情報は、サービングＧＷ２０で生成され、ＭＭＥ１０へ通知されるようにしてもよい。

ＭＭＥ１０は、Ｓ１−ＡＰメッセージ（INITIAL CONTEXT SETUP REQUEST又はRAB SETUP
REQUEST）を含むスレーブデータチャンクを生成する。ＭＭＥ１０は、このスレーブデータチャンクに、図８の（Ｓ８６）で示されるように対象のＵＥコンテキスト若しくは対象のノードに対応するように保持されるスレーブデータチャンク転送用のストリームＩＤを設定し、かつＧＴＰＩＤ＃１を設定する。このように生成されたスレーブデータチャンクは、マスタｅＮＢ３１へ送信される（Ｓ９１）。

マスタｅＮＢ３１は、このスレーブデータチャンクを受信すると、上述のＣ−プレーンに関するルーティングテーブルに基づき転送処理を実行する。これにより、このスレーブデータチャンクは、所定のアソシエーションＩＤ及びストリームＩＤに書き換えられ、スレーブｅＮＢ３２へ届けられる（Ｓ９２）。

スレーブｅＮＢ３２は、このスレーブデータチャンクを受信すると、そのスレーブデータチャンクに設定されているＧＴＰＩＤ＃１を抽出し保持する。続いて、スレーブｅＮＢ３２は、自身のトンネルエンドポイント情報を生成する（Ｓ９３）。具体的には、スレーブｅＮＢ３２は、自身のトランスポートアドレス及びスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤ（以降、ＧＴＰＩＤ＃４と表記する）を生成する。

続いて、スレーブｅＮＢ３２は、スレーブＧＴＰパケット転送用のＧＴＰトンネルの確立要求であるＸ２−ＡＰメッセージ（GTP TUNNEL SETUP REQUEST）含むＸ２データチャンクを生成する。スレーブｅＮＢ３２は、このＸ２データチャンクにスレーブデータチャンク用以外のストリームＩＤを設定し、かつ、自身のトンネルエンドポイント情報（ＧＴＰＩＤ＃４）及び先に保持されるＧＴＰＩＤ＃１を設定する。スレーブｅＮＢ３２は、このように生成されたＸ２データチャンクをマスタｅＮＢ３１へ送る（Ｓ９４）。

マスタｅＮＢ３１は、このＸ２データチャンクを受けると、それに設定されるＧＴＰＩＤ＃１及び＃４をそれぞれ取得する。なお、このとき、マスタｅＮＢ３１は、このデータチャンクのストリームＩＤがルーティングテーブルに格納されていないため、このＸ２データチャンクを転送する必要がないと判断する。

マスタｅＮＢ３１は、続いて、自身のトンネルエンドポイント情報を生成する（Ｓ９５）。具体的には、マスタｅＮＢ３１は、自身のトランスポートアドレス及びスレーブｅＮＢ３２方向のスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤ（以降、ＧＴＰＩＤ＃２と表記する）と、自身のトランスポートアドレス及びサービングＧＷ２０方向のスレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤ（以降、ＧＴＰＩＤ＃３と表記する）とを生成する。

更に、マスタｅＮＢ３１は、生成されたＧＴＰＩＤ＃２及び＃３と、Ｘ２データチャンクから取得されたＧＴＰＩＤ＃１及び＃４とをＧＴＰトンネル変換テーブル８６に設定する。なお、マスタｅＮＢ３１は、このとき、無線側のリソースを確保する必要はない。すなわち、マスタｅＮＢ３１は、単に、転送処理をするのみである。

マスタｅＮＢ３１は、上記ＧＴＰトンネル変換テーブル８６の更新が完了すると、上記Ｘ２−ＡＰメッセージ（GTP TUNNEL SETUP REQUEST）の応答となるＸ２−ＡＰメッセージ（GTP TUNNEL SETUP RESPONSE）を含むＸ２データチャンクを生成する。マスタｅＮＢ３
２は、このＸ２データチャンクにスレーブデータチャンク用以外のストリームＩＤを設定
し、かつ、自身により生成したトンネルエンドポイント情報（ＧＴＰＩＤ＃２及び＃３）を設定する。マスタｅＮＢ３１は、このように生成されたＸ２データチャンクをスレーブｅＮＢ３２へ返信する（Ｓ９６）。

スレーブｅＮＢ３２は、このＸ２データチャンクを受信し、このＸ２データチャンクに設定されるトンネルエンドポイント情報（ＧＴＰＩＤ＃２及び＃３）を抽出する。このＧＴＰＩＤ＃２は、マスタｅＮＢ３１から見た際のスレーブｅＮＢ３２方向からのインバウンドＧＴＰトンネルに関する情報であることから、スレーブｅＮＢ３２にとってはマスタｅＮＢ３１方向へのアウトバウンドＧＴＰトンネルに関する情報となる。

従って、スレーブｅＮＢ３２は、先に自身で生成した、スレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤ（ＧＴＰＩＤ＃４）に対向するトンネルエンドポイント情報として、このＧＴＰＩＤ＃２を保持する（Ｓ９７）。これにより、スレーブｅＮＢ３２は、スレーブｅＮＢ３２からスレーブＧＴＰパケットを送信する際には、このスレーブＧＴＰパケットのＴＥ−ＩＤにこのＧＴＰＩＤ＃２を設定すればよい。

その後、スレーブｅＮＢ３２は、先に受信されているＳ１−ＡＰメッセージ（INITIAL CONTEXT SETUP REQUEST又はRAB SETUP REQUEST）の応答となるＳ１−ＡＰメッセージ（INITIAL CONTEXT SETUP RESPONSE又はRAB SETUP RESPONSE）を含むスレーブデータチャンクを生成する。スレーブｅＮＢ３２は、このスレーブデータチャンクにスレーブデータチャンク転送用のストリームＩＤを設定すると共に、Ｘ２データチャンクから抽出されたＧＴＰＩＤ＃３を設定する。スレーブｅＮＢ３２は、このスレーブデータチャンクをマスタｅＮＢ３１へ送信する（Ｓ９８）。

マスタｅＮＢ３１は、このスレーブデータチャンクを受信すると、上述のＣ−プレーンに関するルーティングテーブルに基づき転送処理を実行する。これにより、このスレーブデータチャンクは、所定のアソシエーションＩＤ及びストリームＩＤに書き換えられ、ＭＭＥ１０へ届けられる（Ｓ９９）。

ＭＭＥ１０は、このスレーブデータチャンクを受信すると、そのスレーブデータチャンクに設定されているＧＴＰＩＤ＃３を抽出し保持する。このＧＴＰＩＤ＃３は、マスタｅＮＢ３１から見た際のサービングＧＷ２０方向からのインバウンドＧＴＰトンネルに関する情報であることから、サービングＧＷ２０にとってはマスタｅＮＢ３１方向へのアウトバウンドＧＴＰトンネルに関する情報となる。

従って、ＭＭＥ１０は、先に自身で生成した、スレーブＧＴＰパケット転送用のインバウンドＧＴＰトンネルのＴＥ−ＩＤ（ＧＴＰＩＤ＃１）に対向するトンネルエンドポイント情報として、このＧＴＰＩＤ＃３を保持する（Ｓ１００）。このＧＴＰＩＤ＃１及び＃３は、サービングＧＷ２０へ通知される。これにより、サービングＧＷ２０は、スレーブＧＴＰパケットを送信する際には、このスレーブＧＴＰパケットのＴＥ−ＩＤにこのＧＴＰＩＤ＃３を設定すればよい。

ここで、各ノードで保持されるスレーブＧＴＰパケット転送用のＧＴＰトンネルのトンネルエンドポイント情報は、そのＧＴＰトンネルを利用するＵＥコンテキストと関連付けて保持されるようにしてもよい。このようにすれば、ＵＥコンテキスト情報に基づいて、そのＵＥコンテキストに関するＡＰメッセージを送受するためのトンネルエンドポイント情報を取得することができる。

次に、Ｕ−プレーンに関する本移動通信システムの動作としてＧＴＰデータパケット転送手順及びＧＴＰトンネルの解放手順について、図１４を用いて説明する。図１４は、本
実施形態における移動通信システムのＧＴＰデータパケットの転送手順及びＧＴＰトンネルの解放手順を示すシーケンス図である。上述のようなＧＴＰトンネル確立手順により各ノード間にＧＴＰトンネルが確立されると、各ノードは、ＧＴＰデータパケットの送受を開始することができる。なお、スレーブＧＴＰパケット以外のＧＴＰデータパケットについては、従来と同様の処理となるため、ここでは説明を省略する。

以下、スレーブｅＮＢ３２が、スレーブＧＴＰパケットを送信する場合の動作を以下に説明する。

スレーブｅＮＢ３２に接続されるＵＥからデータパケットの送信要求等があった場合には、スレーブｅＮＢ３２は、スレーブＧＴＰパケット（Ｇ−ＰＤＵ）をマスタｅＮＢ３１へ送信する（Ｓ１０１）。このとき、このスレーブＧＴＰパケットのＴＥ−ＩＤには、スレーブｅＮＢ３２において自身で生成したスレーブＧＴＰパケット転送用のトンネルエンドポイント情報（ＧＴＰＩＤ＃４）に対し、この対向トンネルエンドポイント情報として保持されているＧＴＰＩＤ＃２が設定される。

マスタｅＮＢ３１は、このスレーブＧＴＰパケットを受信すると、上述のＧＴＰトンネル変換テーブルに基づいて、そのスレーブＧＴＰパケットのＴＥ−ＩＤを転送先ＧＴＰトンネル情報（ＧＴＰＩＤ＃１）に変換する（Ｓ１０２）。マスタｅＮＢ３１は、このようにＴＥ−ＩＤの変換されたスレーブＧＴＰパケットをサービングＧＷ２０へ送信する（Ｓ１０３）。なお、マスタｅＮＢ３１におけるスレーブＧＴＰパケットの転送処理（Ｓ１０２及び１０３）は、ｅＮＢにおけるハンドオーバ手順の所定タイミングで行われる処理と同様であってもよい（文献（"LTE Stage 2", 3rd Generation Partnership Project, 3GPP TS 36.300, June 2007, 10.1.2.）参照）。但し、本実施形態では、ハンドオーバ契機
で実施するわけではなく、転送処理を行うマスタｅＮＢ３１では無線リソースを獲得する必要がない等の点においてこの文献に記載される技術とは異なるため、転送処理の部分のみ利用する。

サービングＧＷ２０は、このスレーブＧＴＰパケットを受けると、それの応答となるスレーブＧＴＰパケット（Ｇ−ＰＤＵ）を生成する。この応答となるスレーブＧＴＰパケットのＴＥ−ＩＤには、サービングＧＷ２０のスレーブＧＴＰパケット転送用のトンネルエンドポイント情報（ＧＴＰＩＤ＃１）に対し、この対向トンネルエンドポイント情報として保持されているＧＴＰＩＤ＃３が設定される。サービングＧＷ２０は、このスレーブＧＴＰパケットをマスタｅＮＢ３１へ送信する（Ｓ１０４）。

マスタｅＮＢ３１は、このスレーブＧＴＰパケットを受信すると、上述のＧＴＰトンネル変換テーブルに基づいて、そのスレーブＧＴＰパケットのＴＥ−ＩＤを転送先ＧＴＰトンネル情報（ＧＴＰＩＤ＃４）に変換する（Ｓ１０５）。マスタｅＮＢ３１は、このようにＴＥ−ＩＤの変換されたスレーブＧＴＰパケットをスレーブｅＮＢ３２へ送信する（Ｓ１０６）。

最後に、このように利用されるスレーブＧＴＰパケット転送用のＧＴＰトンネルが解放される際の動作について説明する。なお、図１４は、本実施形態において各ノード間に確立されるＧＴＰトンネル群のうち、スレーブＧＴＰパケット転送用のＧＴＰトンネルを解放する手順を示している。その他のＧＴＰデータパケット送受用のＧＴＰトンネルについては従来と同様の手法により解放されればよいため、ここでは説明を省略する。

ＧＴＰトンネル解放時には、ＭＭＥ１０は、Ｃ−プレーンにおいてＳ１−ＡＰメッセージ（UE CONTEXT RELEASE REQUEST又はRAB RELEASE REQUEST）を含むスレーブデータチャ
ンクをマスタｅＮＢ３１へ送信する（Ｓ１１０）。このとき、スレーブデータチャンク転
送用のストリームＩＤがこのスレーブデータチャンクに設定される。

マスタｅＮＢ３１は、このスレーブデータチャンクを受信すると、上述のＣ−プレーンに関するルーティングテーブルに基づき転送処理を実行する。これにより、このスレーブデータチャンクは、所定のアソシエーションＩＤ及びストリームＩＤに書き換えられ、スレーブｅＮＢ３２へ届けられる（Ｓ１１１）。

スレーブｅＮＢ３２は、このスレーブデータチャンクを受信すると、スレーブＧＴＰパケット転送用のＧＴＰトンネルの解放要求となるＸ２−ＡＰメッセージ（GTP TUNNEL RELEASE REQUEST）を含むＸ２データチャンクを生成する。スレーブｅＮＢ３２は、このＸ２データチャンクにスレーブデータチャンク用以外のストリームＩＤを設定し、かつ、解放されるべきトンネルエンドポイント情報（ＧＴＰＩＤ＃２及び＃３）を設定する。このとき、スレーブｅＮＢ３２は、受信されたスレーブデータチャンクに含まれるＳ１−ＡＰメッセージのＵＥコンテキストに基づいて、解放されるべきトンネルエンドポイント情報を決定するようにしてもよい。また、Ｘ２データチャンクには、この解放されるべきＵＥコンテキストが設定されるようにしてもよい。スレーブｅＮＢ３２は、このように生成されたＸ２データチャンクをマスタｅＮＢ３１へ送る（Ｓ１１２）。

マスタｅＮＢ３１は、このＸ２データチャンクを受信すると、それに設定されるトンネルエンドポイント情報を抽出し、この情報により特定されるトンネルエンドポイントを解放する（Ｓ１１３）。このとき、マスタｅＮＢ３１は、ＧＴＰトンネル変換テーブル内のその解放されたトンネルエンドポイント情報が格納されるレコードを削除する。

〈本実施形態の作用及び効果〉
ここで、上述した本実施形態における移動通信システムの作用及び効果について述べる。

本実施形態における移動通信システムでは、ｅＮＢがマスタｅＮＢ３１とスレーブｅＮＢ３２とに機能的に分けて定義され、スレーブｅＮＢ３２とＭＭＥ１０又はサービングＧＷ２０とをエンドポイントとし相互にＳ１インタフェースで送受されるデータチャンク（スレーブデータチャンク）及びＧＴＰデータパケット（スレーブＧＴＰパケット）がマスタｅＮＢ３１を経由して送受される。これにより、マスタｅＮＢ３１とＭＭＥ及びサービングＧＷ２０との間においてのみＳＣＴＰアソシエーション及びＧＴＰのためのセキュリティアソシエーションが確立され、スレーブｅＮＢ３２とＭＭＥ及びサービングＧＷ２０との間にはこれらを確立する必要がない。

従って、本実施形態によれば、従来、全てのｅＮＢとＭＭＥ及びサービングＧＷとの間で個々に確立する必要のあったＳＣＴＰアソシエーション及びＧＴＰのためのセキュリティアソシエーションをマスタｅＮＢ３１とＭＭＥ１０及びサービングＧＷ２０との間のみに集約することができる。図２に示す本実施形態の例（２台のｅＮＢ）では、従来、ＭＭＥ及びサービングＧＷは、２本のＳＣＴＰアソシエーション又は４本のセキュリティアソシエーションを管理する必要があったところ、１本のＳＣＴＰアソシエーション又は２本のセキュリティアソシエーションを管理すればよい。また、図３及び４の例（３台のｅＮＢ）では、従来、ＭＭＥ及びサービングＧＷは、３本のＳＣＴＰアソシエーション又は６本のセキュリティアソシエーションを管理する必要があったところ、１本のＳＣＴＰアソシエーション又は２本のセキュリティアソシエーションを管理すればよい。

すなわち、本実施形態によれば、ＭＭＥ１０及びサービングＧＷ２０により管理されるべきＳＣＴＰアソシエーション又はセキュリティアソシエーションの数を減らすことができるため、ＭＭＥ１０及びサービングＧＷ２０の処理負荷を軽減することができる。更に
、本実施形態によれば、ＭＭＥ及びサービングＧＷとｅＮＢとの間に確立すべきＳＣＴＰアソシエーション又はセキュリティアソシエーションを減らすことができるため、これらの確立手順により送受されるトラフィックを軽減させることができる。これらの効果は、ｅＮＢの数が多い程、電源ＯＮ／ＯＦＦ等により通信リソース確立手順が頻繁に発生し得るホームｅＮＢの数が多い程、顕著となる。

このような構成を実現するために、本実施形態では、マスタｅＮＢ３１とＭＭＥ１０との間のＳＣＴＰアソシエーション（ＭＭＥアソシエーション）には、マスタｅＮＢ３１とＭＭＥ１０とをエンドポイントとしＳ１インタフェースで送受されるデータチャンクのためのストリームと共に、スレーブｅＮＢ３２のスレーブデータチャンクのためのストリームも加味されたストリーム数が確保される。また、マスタｅＮＢ３１とＭＭＥ１０との間のセキュリティアソシエーションには、マスタｅＮＢ３１とＭＭＥ１０とをエンドポイントとしＳ１インタフェースで送受されるＧＴＰデータパケットのためのＧＴＰトンネルと共に、スレーブｅＮＢ３２のスレーブＧＴＰパケットのためのＧＴＰトンネルも確保される。

これにより、本実施形態によれば、システム稼働後にスレーブｅＮＢが増設された場合、稼働中のスレーブｅＮＢが故障した場合等においても、マスタｅＮＢ３１とＭＭＥ１０又はサービングＧＷ２０との間のＳＣＴＰアソシエーション及びセキュリティアソシエーションを再確立する必要はない。この点においても、本実施形態によれば、ＭＭＥ１０及びサービングＧＷ２０の処理負荷を下げることができ、システム内トラフィック量を低減させることができる。

本実施形態では、マスタｅＮＢ３１において、ＳＣＴＰ層及びＧＴＰ層の転送処理、すなわちスレーブデータチャンク及びスレーブＧＴＰパケットのルーティング処理が実行される。マスタｅＮＢ３１では、ＳＣＴＰアソシエーション確立処理時及びＧＴＰトンネル確立処理時に、スレーブデータチャンクのルーティングに利用するためのルーティングテーブル、及びスレーブＧＴＰパケットのルーティングに利用するためのＧＴＰトンネル変換テーブルが生成される。

Ｃ−プレーンにおけるスレーブデータチャンクのルーティングにはＳＣＴＰのストリームＩＤが利用される。これにより、ルーティングテーブルには、受信されたスレーブデータチャンクのストリームＩＤと転送時のスレーブデータチャンクに設定すべきストリームＩＤとの組が格納される。

これにより、マスタｅＮＢ３１は、受信されたデータチャンクに設定されるストリームＩＤがルーティングテーブルに格納されているか否かにより、この受信されたデータチャンクがスレーブデータチャンクかそれ以外のＳＣＴＰデータチャンク（Ｘ２インタフェース用或いはマスタｅＮＢ３１とＭＭＥ１０との間のＳ１インタフェース用のデータチャンク）かを識別することができる。また、スレーブデータチャンクとそれ以外のＳＣＴＰデータチャンクを区別するために、最下位ビットを１にセットしたストリームＩＤをスレーブデータチャンク用のストリームＩＤと決定するようにすれば、マスタｅＮＢ３１は、このストリームＩＤを判別するだけで即座にスレーブデータチャンクか否かを判断することができる。

本実施形態では、マスタｅＮＢ３１が独自にルーティングテーブルを生成する。このとき、ＭＭＥ１０からマスタｅＮＢ３１により受信されるデータチャンクに設定されるストリームＩＤが逆にマスタｅＮＢ３１からＭＭＥ１０へ転送されるデータチャンクに設定されるストリームＩＤと同じものとなるように、ルーティングテーブルは生成される。

これにより、ルーティングテーブルを生成するための特別なメッセージのやりとりを行うことなく、独自にマスタｅＮＢ３１でルーティングテーブルを設定することができるため、本実施形態を実現する上で、システム内のトラフィックが増加することを防ぐことができる。

Ｕ−プレーンにおけるスレーブＧＴＰパケットのルーティングには、ＧＴＰのトンネルエンドポイントＩＤ（ＴＥ−ＩＤ）が利用される。これにより、マスタｅＮＢ３１により管理されるＧＴＰトンネル変換テーブルには、受信されたスレーブＧＴＰパケットのＴＥ−ＩＤと転送時のスレーブＧＴＰパケットに設定すべきＴＥ−ＩＤとの組が格納される。また、エンドポイントとなるサービングＧＷ２０及びスレーブｅＮＢ３２では、各自で生成されるトンネルエンドポイント情報と共に、そのエンドポイントで受信されたスレーブＧＴＰパケットの応答となるスレーブＧＴＰパケットの宛先となる対向トンネルエンドポイント情報が保持される。

各ノードにこのような情報を保持させるために、ＧＴＰトンネル確立のために利用されるＳＣＴＰのＳ１−ＡＰメッセージ（INITIAL CONTEXT SETUP REQUEST又はRAB SETUP REQUEST）及び（INITIAL CONTEXT SETUP RESPONSE又はRAB SETUP RESPONSE）、スレーブｅＮＢ３２とマスタｅＮＢ３１との間やりとりされるＸ２―ＡＰメッセージ（GTP TUNNEL SETUP REQUEST）及び（GTP TUNNEL SETUP RESPONSE）により、各ノードで生成された各トン
ネルエンドポイント情報が相互に通知される。

[その他]
本実施形態は次の発明態様を開示する。各項に開示される態様は、必要に応じて可能な限り組み合わせることができる。

（付記１）
基地局制御装置と接続される基地局装置において、
前記基地局制御装置との間に第一論理通信路を確立させる第一確立手段と、
他の基地局装置との間に第二論理通信路を確立させる第二確立手段と、
前記他の基地局装置と前記基地局制御装置とを終端として送受されるデータを他基地局装置データとして前記第一論理通信路及び前記第二論理通信路を介して転送する転送手段と、
を備える基地局装置。（１）
（付記２）
前記第一確立手段は、前記第一論理通信路内に、前記基地局装置と前記基地局制御装置とを終端として送受されるデータを通すための通信パイプと前記他基地局装置データを通すための通信パイプとを設定し、
前記第二確立手段は、前記第二論理通信路内に、前記基地局装置と前記他の基地局装置とを終端として送受されるデータを基地局間データとして通すための通信パイプと前記他基地局装置データを通すための通信パイプとを設定し、
前記転送手段は、
前記第一論理通信路内に設定された他基地局装置データを通すための通信パイプを示す識別情報と、前記第二論理通信路内に設定された他基地局装置データを通すための通信パイプを示す識別情報との組み合わせを転送テーブルに格納するテーブル生成手段を、有し、
受信されるデータに設定される通信パイプ識別情報及び前記転送テーブルに基づいて、この受信されたデータのうちの前記他基地局装置データを転送する、
付記１に記載の基地局装置。（２）
（付記３）
前記第一論理通信路及び第二論理通信路はＳＣＴＰアソシエーションであり、
前記通信パイプはＳＣＴＰストリームであり、
前記通信パイプを示す識別情報はストリームＩＤであり、
前記第二確立手段は、前記第二ＳＣＴＰアソシエーションにおける前記他基地局装置データを通すためのＳＣＴＰストリームのストリームＩＤの最下位ビットを他基地局装置データであることを示す判別ビットとし、
前記転送手段は、受信されたデータに設定される前記ストリームＩＤの判別ビットを検査することにより、受信されたデータが他基地局装置データか否かを判断する、
付記２に記載の基地局装置。（３）
（付記４）
前記第一論理通信路及び第二論理通信路はＳＣＴＰアソシエーションであり、
前記通信パイプはＳＣＴＰストリームであり、
前記通信パイプを示す識別情報はストリームＩＤであり、
前記第一確立手段は、前記第一ＳＣＴＰアソシエーションにおける前記他基地局装置データを通すためのＳＣＴＰストリームのうちの送信用ＳＣＴＰストリームのストリームＩＤと受信用ＳＣＴＰストリームのストリームＩＤとを同じ値に割り当てる、
付記２に記載の基地局装置。（４）
（付記５）
前記第一論理通信路及び第二論理通信路は、セキュリティアソシエーションであり、
前記通信パイプは、ＧＴＰトンネルであり、
前記通信パイプを示す識別情報は、トンネルエンドポイントＩＤであり、
前記テーブル生成手段は、自身で生成した前記基地局制御装置方向のトンネルエンドポイントＩＤ及び前記スレーブ装置方向のトンネルエンドポイントＩＤ、前記基地局間データとして前記他の基地局装置から送られる前記基地局制御装置により生成されたトンネルエンドポイントＩＤ及び前記他の基地局装置により生成されたトンネルエンドポイントＩＤに基づいて、前記転送テーブルを生成する、
付記２に記載の基地局装置。（５）
（付記６）
複数の基地局装置と基地局制御装置とを有する移動通信システムで実行される通信方法であって、
前記複数の基地局装置のうちのマスタ装置と前記基地局制御装置との間に第一論理通信路を確立させる第一確立ステップと、
前記マスタ装置と前記複数の基地局装置のうちのスレーブ装置との間に第二論理通信路を確立させる第二確立ステップと、
前記マスタ装置が、前記スレーブ装置と前記基地局制御装置とを終端として送受されるデータをスレーブ用データとして前記第一論理通信路及び前記第二論理通信路を介して転送する転送ステップと、
を実行する通信方法。（６）
（付記７）
前記第一確立ステップは、前記第一論理通信路内に、前記マスタ装置と前記基地局制御装置とを終端として送受されるデータをマスタ用データとして通すための通信パイプと前記スレーブ用データを通すための通信パイプとを設定し、
前記第二確立ステップは、前記第二論理通信路内に、前記マスタ装置と前記スレーブ装置とを終端として送受される基地局間データを通すための通信パイプと前記スレーブ用データを通すための通信パイプとを設定し、
前記転送ステップは、
前記第一論理通信路内に設定されたスレーブ用データを通すための通信パイプを示す識別情報と、前記第二論理通信路内に設定されたスレーブ用データを通すための通信パイプを示す識別情報との組み合わせを転送テーブルに格納するテーブル生成ステップを、実行し、
受信されるデータに設定される通信パイプ識別情報及び前記転送テーブルに基づいて、
この受信されたデータのうちの前記スレーブ用データを転送する、
付記６に記載の通信方法。（７）
（付記８）
前記第一論理通信路及び第二論理通信路はＳＣＴＰアソシエーションであり、
前記通信パイプはＳＣＴＰストリームであり、
前記通信パイプを示す識別情報はストリームＩＤであり、
前記第二確立ステップは、前記第二ＳＣＴＰアソシエーションにおける前記スレーブ用データを通すためのＳＣＴＰストリームのストリームＩＤの最下位ビットをスレーブ用データであることを示す判別ビットとし、
前記転送ステップは、受信されたデータに設定される前記ストリームＩＤの判別ビットを検査することにより、受信されたデータがスレーブ用データか否かを判断する、
付記７に記載の通信方法。（８）
（付記９）
前記第一論理通信路及び第二論理通信路はＳＣＴＰアソシエーションであり、
前記通信パイプはＳＣＴＰストリームであり、
前記通信パイプを示す識別情報はストリームＩＤであり、
前記第一確立ステップは、前記第一ＳＣＴＰアソシエーションにおける前記スレーブ用データを通すためのＳＣＴＰストリームのうちの送信用ＳＣＴＰストリームのストリームＩＤと受信用ＳＣＴＰストリームのストリームＩＤとを同じ値に割り当てる、
付記７に記載の通信方法。
（付記１０）
前記第一論理通信路及び第二論理通信路は、セキュリティアソシエーションであり、
前記通信パイプは、ＧＴＰトンネルであり、
前記通信パイプを示す識別情報は、トンネルエンドポイントＩＤであり、
前記テーブル生成ステップは、自身で生成した前記基地局制御装置方向のトンネルエンドポイントＩＤ及び前記スレーブ装置方向のトンネルエンドポイントＩＤ、前記基地局間データとして前記スレーブ装置から送られる前記基地局制御装置により生成されたトンネルエンドポイントＩＤ及び前記スレーブ装置により生成されたトンネルエンドポイントＩＤに基づいて、前記転送テーブルを生成する、
付記７に記載の通信方法。（９）
（付記１１）
複数の基地局装置と基地局制御装置とを有する移動通信システムにおいて、
前記複数の基地局装置のうちのマスタ装置が、
前記基地局制御装置との間に第一論理通信路を確立させる第一確立手段と、
前記複数の基地局装置のうちのスレーブ装置との間に第二論理通信路を確立させる第二確立手段と、
前記スレーブ装置と前記基地局制御装置とを終端として送受されるデータをスレーブ用データとして前記第一論理通信路及び前記第二論理通信路を介して転送する転送手段と、
を備える移動通信システム。（１０）
（付記１２）
前記第一確立手段は、前記第一論理通信路内に、前記マスタ装置と前記基地局制御装置とを終端として送受されるデータマスタ用データとして通すための通信パイプと前記スレーブ用データを通すための通信パイプとを設定し、
前記第二確立手段は、前記第二論理通信路内に、前記マスタ装置と前記スレーブ装置とを終端として送受される基地局間データを通すための通信パイプと前記スレーブ用データを通すための通信パイプとを設定し、
前記転送手段は、
前記第一論理通信路内に設定されたスレーブ用データを通すための通信パイプを示す識別情報と、前記第二論理通信路内に設定されたスレーブ用データを通すための通信パイ
プを示す識別情報との組み合わせを転送テーブルに格納するテーブル生成手段を、有し、
受信されるデータに設定される通信パイプ識別情報及び前記転送テーブルに基づいて、この受信されたデータのうちの前記スレーブ用データを転送する、
付記１１に記載の移動通信システム。
（付記１３）
前記第一論理通信路及び第二論理通信路はＳＣＴＰアソシエーションであり、
前記通信パイプはＳＣＴＰストリームであり、
前記通信パイプを示す識別情報はストリームＩＤであり、
前記第二確立手段は、前記第二ＳＣＴＰアソシエーションにおける前記スレーブ用データを通すためのＳＣＴＰストリームのストリームＩＤの最下位ビットをスレーブ用データであることを示す判別ビットとし、
前記転送手段は、受信されたデータに設定される前記ストリームＩＤの判別ビットを検査することにより、受信されたデータがスレーブ用データか否かを判断する、
付記１２に記載の移動通信システム。
（付記１４）
前記第一論理通信路及び第二論理通信路はＳＣＴＰアソシエーションであり、
前記通信パイプはＳＣＴＰストリームであり、
前記通信パイプを示す識別情報はストリームＩＤであり、
前記第一確立手段は、前記第一ＳＣＴＰアソシエーションにおける前記スレーブ用データを通すためのＳＣＴＰストリームのうちの送信用ＳＣＴＰストリームのストリームＩＤと受信用ＳＣＴＰストリームのストリームＩＤとを同じ値に割り当てる、
付記１２に記載の移動通信システム。
（付記１５）
前記第一論理通信路及び第二論理通信路は、セキュリティアソシエーションであり、
前記通信パイプは、ＧＴＰトンネルであり、
前記通信パイプを示す識別情報は、トンネルエンドポイントＩＤであり、
前記テーブル生成手段は、自身で生成した前記基地局制御装置方向のトンネルエンドポイントＩＤ及び前記スレーブ装置方向のトンネルエンドポイントＩＤ、前記基地局間データとして前記スレーブ装置から送られる前記基地局制御装置により生成されたトンネルエンドポイントＩＤ及び前記スレーブ装置により生成されたトンネルエンドポイントＩＤに基づいて、前記転送テーブルを生成する、
付記１２に記載の移動通信システム。

本実施形態における移動通信システムのシステム構成例を示す図である。 本実施形態における移動通信システムを構成する各装置の接続形態例を示す概念図である。 本実施形態におけるＣ−プレーン接続形態の概念を示す図である。 本実施形態におけるＵ−プレーン接続形態の概念を示す図である。 本実施形態におけるＭＭＥ１０の機能構成を示すブロック図である。 本実施形態におけるサービングＧＷ２０の機能構成を示すブロック図である。 本実施形態におけるマスタｅＮＢ３１の機能構成を示すブロック図である。 スレーブデータチャンク転送用ルーティングテーブルの例を示す図である。 スレーブＧＴＰパケット転送用のＧＴＰトンネル変換テーブルの例を示す図である。 本実施形態におけるスレーブｅＮＢ３２の機能構成を示すブロック図である。 本実施形態における移動通信システムのＳＣＴＰ初期手順を示すシーケンス図である。 本実施形態における移動通信システムのＳＣＴＰデータチャンクの転送手順を示すシーケンス図である。 本実施形態における移動通信システムのＧＴＰトンネル確立手順を示すシーケンス図である。 本実施形態における移動通信システムのＧＴＰデータパケットの転送手順及びＧＴＰトンネルの解放手順を示すシーケンス図である。 従来のＬＴＥ移動通信システムのシステム構成例を示す図である。 従来のＬＴＥ移動通信システムのＣ−プレーンの接続形態を示す概念図である。 従来のＬＴＥ移動通信システムのＵ−プレーンの接続形態を示す概念図である。

符号の説明

５ ＩＰ網
１０ ＭＭＥ
２０ サービングＧＷ（ＳＥＲＶＩＮＧ−ＧＷ）
３１ マスタｅＮＢ
３２、３３ スレーブｅＮＢ
４０、４１、４２、４３ ＳＣＴＰアソシエーション
５０、５１、５２、５３ ＧＴＰトンネル群
６１、８７、９７ ＳＣＴＰインタフェース部
６２ ストリームＩＤ管理部
６３ Ｃ−プレーン制御部
６４ Ｕ−プレーン情報管理部
６５ サービングＧＷインタフェース部
７１、８８、９８ ＧＴＰインタフェース部
７２ Ｕ−プレーン制御部
７３ トンネルエンドポイント情報管理部
７４ ＭＭＥインタフェース部
８３、９３ Ｃ−プレーン処理部
８４、９４ Ｕ−プレーン処理部
８５ ルーティングテーブル
８６ ＧＴＰトンネル変換テーブル

Claims (8)

1. 基地局制御装置と接続される基地局装置において、
   前記基地局制御装置との間に第一論理通信路を確立させる第一確立手段と、
   他の基地局装置との間に第二論理通信路を確立させる第二確立手段と、
   前記他の基地局装置と前記基地局制御装置とを終端として送受されるデータを他基地局装置データとして前記第一論理通信路及び前記第二論理通信路を介して転送する転送手段と、を備え、
   前記第一確立手段は、前記第一論理通信路内に、前記基地局装置と前記基地局制御装置とを終端として送受されるデータを通すための通信パイプと前記他基地局装置データを通すための通信パイプとを設定し、
   前記第二確立手段は、前記第二論理通信路内に、前記基地局装置と前記他の基地局装置とを終端として送受されるデータを基地局間データとして通すための通信パイプと前記他基地局装置データを通すための通信パイプとを設定し、
   前記転送手段は、
   前記第一論理通信路内に設定された他基地局装置データを通すための通信パイプを示す識別情報と、前記第二論理通信路内に設定された他基地局装置データを通すための通信パイプを示す識別情報との組み合わせを転送テーブルに格納するテーブル生成手段を、有し、
   受信されたデータに設定される通信パイプ識別情報及び前記転送テーブルに基づいて、この受信されたデータのうちの前記他基地局装置データを転送する、
   基地局装置。
2. 前記第一論理通信路及び第二論理通信路はＳＣＴＰ（Stream Control Transmission Protocol）アソシエーションであり、
   前記通信パイプはＳＣＴＰストリームであり、
   前記通信パイプを示す識別情報はストリームＩＤであり、
   前記第二確立手段が、前記第二ＳＣＴＰアソシエーションにおける前記他基地局装置データを通すためのＳＣＴＰストリームのストリームＩＤの最下位ビットを他基地局装置データであることを示す判別ビットとし、
   前記転送手段は、受信されたデータに設定される前記ストリームＩＤの判別ビットを検
   査することにより、受信されたデータが他基地局装置データか否かを判断する、
   請求項１に記載の基地局装置。
3. 前記第一論理通信路及び第二論理通信路はＳＣＴＰ（Stream Control Transmission Protocol）アソシエーションであり、
   前記通信パイプはＳＣＴＰストリームであり、
   前記通信パイプを示す識別情報はストリームＩＤであり、
   前記第一確立手段は、前記第一ＳＣＴＰアソシエーションにおける前記他基地局装置データを通すためのＳＣＴＰストリームのうちの送信用ＳＣＴＰストリームのストリームＩＤと受信用ＳＣＴＰストリームのストリームＩＤとを同じ値に割り当てる、
   請求項１に記載の基地局装置。
4. 前記第一論理通信路及び第二論理通信路は、セキュリティアソシエーションであり、
   前記通信パイプは、ＧＴＰ（GPRS(General Packet Radio Service) Tunneling Protocol）トンネルであり、
   前記通信パイプを示す識別情報は、トンネルエンドポイントＩＤであり、
   前記テーブル生成手段は、自身で生成した前記基地局制御装置方向のトンネルエンドポイントＩＤ及び前記他の基地局装置方向のトンネルエンドポイントＩＤ、前記基地局間データとして前記他の基地局装置から送られる前記基地局制御装置により生成されたトンネルエンドポイントＩＤ及び前記他の基地局装置により生成されたトンネルエンドポイントＩＤに基づいて、前記転送テーブルを生成する、
   請求項１に記載の基地局装置。
5. 複数の基地局装置と基地局制御装置とを有する移動通信システムで実行される通信方法であって、
   前記複数の基地局装置のうちのマスタ装置と前記基地局制御装置との間に第一論理通信路を確立させる第一確立ステップと、
   前記マスタ装置と前記複数の基地局装置のうちのスレーブ装置との間に第二論理通信路を確立させる第二確立ステップと、
   前記マスタ装置が、前記スレーブ装置と前記基地局制御装置とを終端として送受されるデータをスレーブ用データとして前記第一論理通信路及び前記第二論理通信路を介して転送する転送ステップと、を実行し、
   前記第一確立ステップは、前記第一論理通信路内に、前記マスタ装置と前記基地局制御装置とを終端として送受されるマスタ用データを通すための通信パイプと前記スレーブ用データを通すための通信パイプとを設定し、
   前記第二確立ステップは、前記第二論理通信路内に、前記マスタ装置と前記スレーブ装置とを終端として送受される基地局間データを通すための通信パイプと前記スレーブ用データを通すための通信パイプとを設定し、
   前記転送ステップは、
   前記第一論理通信路内に設定されたスレーブ用データを通すための通信パイプを示す識別情報と、前記第二論理通信路内に設定されたスレーブ用データを通すための通信パイプを示す識別情報との組み合わせを転送テーブルに格納するテーブル生成ステップを、実行し、
   受信されるデータに設定される通信パイプ識別情報及び前記転送テーブルに基づいて、この受信されたデータのうちの前記スレーブ用データを転送する、
   通信方法。
6. 前記第一論理通信路及び第二論理通信路はＳＣＴＰ（Stream Control Transmission Protocol）アソシエーションであり、
   前記通信パイプはＳＣＴＰストリームであり、
   前記通信パイプを示す識別情報はストリームＩＤであり、
   前記第二確立ステップは、前記第二ＳＣＴＰアソシエーションにおける前記スレーブ用データを通すためのＳＣＴＰストリームのストリームＩＤの最下位ビットをスレーブ用データであることを示す判別ビットとし、
   前記転送ステップは、受信されたデータに設定される前記ストリームＩＤの判別ビットを検査することにより、受信されたデータがスレーブ用データか否かを判断する、
   請求項５に記載の通信方法。
7. 前記第一論理通信路及び第二論理通信路は、セキュリティアソシエーションであり、
   前記通信パイプは、ＧＴＰ（GPRS(General Packet Radio Service) Tunneling Protocol）トンネルであり、
   前記通信パイプを示す識別情報は、トンネルエンドポイントＩＤであり、
   前記テーブル生成ステップは、自身で生成した前記基地局制御装置方向のトンネルエンドポイントＩＤ及び前記スレーブ装置方向のトンネルエンドポイントＩＤ、前記基地局間データとして前記スレーブ装置から送られる前記基地局制御装置により生成されたトンネルエンドポイントＩＤ及び前記スレーブ装置により生成されたトンネルエンドポイントＩＤに基づいて、前記転送テーブルを生成する、
   請求項５に記載の通信方法。
8. 複数の基地局装置と基地局制御装置とを有する移動通信システムにおいて、
   前記複数の基地局装置のうちのマスタ装置が、
   前記基地局制御装置との間に第一論理通信路を確立させる第一確立手段と、
   前記複数の基地局装置のうちのスレーブ装置との間に第二論理通信路を確立させる第二確立手段と、
   前記スレーブ装置と前記基地局制御装置とを終端として送受されるデータをスレーブ用データとして前記第一論理通信路及び前記第二論理通信路を介して転送する転送手段と、を備え、
   前記第一確立手段は、前記第一論理通信路内に、前記マスタ装置と前記基地局制御装置とを終端として送受されるデータマスタ用データとして通すための通信パイプと前記スレーブ用データを通すための通信パイプとを設定し、
   前記第二確立手段は、前記第二論理通信路内に、前記マスタ装置と前記スレーブ装置とを終端として送受される基地局間データを通すための通信パイプと前記スレーブ用データを通すための通信パイプとを設定し、
   前記転送手段は、
   前記第一論理通信路内に設定されたスレーブ用データを通すための通信パイプを示す識別情報と、前記第二論理通信路内に設定されたスレーブ用データを通すための通信パイプを示す識別情報との組み合わせを転送テーブルに格納するテーブル生成手段を、有し、
   受信されるデータに設定される通信パイプ識別情報及び前記転送テーブルに基づいて、この受信されたデータのうちの前記スレーブ用データを転送する、
   移動通信システム。

Images