WO2014125777A1

WO2014125777A1 - 移動通信システム、通信制御方法、及び非一時的なコンピュータ可読媒体

Info

Publication number: WO2014125777A1
Application number: PCT/JP2014/000453
Authority: WO
Inventors: 孝法岩井
Original assignee: 日本電気株式会社
Priority date: 2013-02-18
Filing date: 2014-01-29
Publication date: 2014-08-21

Abstract

　加入者サーバ（６）は、移動端末グループに属する各移動端末（１）のユーザプレーン・アドレスを移動管理ノード（３）に通知する。移動管理ノード（３）は、ユーザプレーン・アドレスに対応するユーザパケットが共用コアネットワークベアラ（ＣＮＢ）（３０）において転送されるよう共用ＣＮＢ（３０）の設定を制御する。共用ＣＮＢ（３０）は、転送ノード（４）と外部ゲートウェイ（５）の間に設定され、移動端末グループに属する複数の移動端末（１）のユーザパケット転送のために共用される。これにより、例えば、異なる移動管理ノードに帰属する複数の移動端末が１つの共用コアネットワークベアラを利用できる。

Description

移動通信システム、通信制御方法、及び非一時的なコンピュータ可読媒体

　本出願は、移動通信システムに関し、例えば、ユーザパケット転送のための通信制御に関する。

　多元接続方式の移動通信システムは、時間、周波数、及び送信電力のうち少なくとも１つを含む無線リソースを複数の移動端末の間で共有することで、複数の移動端末が実質的に同時に無線通信を行うことを可能としている。代表的な多元接続方式は、ＴＤＭＡ（Time Division Multiple Access）、ＦＤＭＡ（Frequency Division Multiple Access）、ＣＤＭＡ（Code Division Multiple Access）、若しくはＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access）又はこれらの組み合わせである。本明細書で用いる移動通信システムの用語は、特に断らない限り多元接続方式の移動通信システムを意味する。

　移動通信システムは、移動端末及びネットワークを含む。ネットワークは、無線アクセスネットワーク（Radio Access Network（ＲＡＮ））及びコアネットワーク（Mobile Core Network（ＣＮ））を含む。移動端末は、ＲＡＮ及びＣＮを介して外部ネットワーク（例えば、インターネット、パケットデータネットワーク、Public Switched Telephone Networks（ＰＳＴＮ））と通信する。移動通信システムは、例えば、3rd Generation Partnership Project（３ＧＰＰ）のUniversal Mobile Telecommunications System（ＵＭＴＳ）又はEvolved Packet System（ＥＰＳ）である。ＲＡＮは、例えば、Universal Terrestrial Radio Access Network（ＵＴＲＡＮ）、又はEvolved UTRAN（Ｅ－ＵＴＲＡＮ）である。ＣＮは、例えば、General Packet Radio Service（ＧＰＲＳ）パケットコア、又はEvolved Packet Core（ＥＰＣ）である。

　移動通信システムは、一般的に、外部ネットワークと移動端末との間でユーザパケットを転送するためのデータベアラを移動端末毎に作成する必要がある。なぜなら、移動端末のモビリティを提供するためにパケット転送ルートの速やかな切り替え・再配置が必要とされるためである。データベアラは、例えば、ＵＭＴＳベアラ（General Packet Radio Service（ＧＰＲＳ）ベアラ）、又はＥＰＳベアラである。データベアラは、ＣＮに設定されるコアネットワークベアラ（以下、ＣＮＢと呼ぶ）及びＲＡＮに設定される無線アクセスベアラ（以下、ＲＡＢと呼ぶ）を含む。

　ＣＮＢは、ＣＮに配置される外部ゲートウェイと転送ノードの間に設定されるトンネル、つまり論理的な伝送路、である。外部ゲートウェイは、外部ネットワークとの境界に配置されるゲートウェイノードである。転送ノードは、ＲＡＮとの境界に配置されるノードである。ＣＮＢは、例えば、ＵＭＴＳのＣＮＢ（つまり、GPRS Tunneling Protocol（ＧＴＰ）トンネル）、又はＥＰＳのＳ５／Ｓ８ベアラ（つまり、ＧＴＰトンネル）である。また、外部ゲートウェイは、例えば、Gateway GPRS Support Node（ＧＧＳＮ）、又はPacket Data Network Gateway（Ｐ－ＧＷ）である。転送ノードは、例えば、Serving GPRS Support Node（ＳＧＳＮ）のユーザプレーン機能、又はServing Gateway（Ｓ－ＧＷ）である。

　ＲＡＢは、ＣＮの転送ノードと移動端末の間に設定されるベアラである。ＲＡＢは、ＲＡＮとＣＮの間に設定されるベアラと、無線ベアラを含む。ＲＡＮとＣＮの間に設定されるベアラは、Radio Link Control（ＲＬＣ）及びRadio Resource Control（ＲＲＣ）を担うＲＡＮノードとＣＮの転送ノードの間に設定される。無線ベアラは、ＲＡＮ内において、上述のＲＡＮノードと移動端末の間に設定される。ＲＬＣ及びＲＲＣを担うＲＡＮノードは、例えば、ＵＭＴＳのRadio Network Controller（ＲＮＣ）、又はＥＰＳの基地局（evolved NodeB（ｅＮＢ））である。ＲＡＮとＣＮの間に設定されるベアラは、例えば、ＵＭＴＳのＩｕベアラ（つまり、ＧＴＰトンネル）、又はＥＰＳのＳ１ベアラ（つまり、ＧＴＰトンネル）である。無線ベアラは、例えば、ＵＭＴＳのＵｕベアラ、又はＥＰＳのＬＴＥ－Ｕｕベアラである。

　つまり、ＣＮは、ＣＮＢを移動端末毎に確立する必要がある。転送ノードは、ＣＮＢに関するトンネル設定として、トンネル識別子（トンネルエンドポイント識別子）及び外部ゲートウェイのユーザプレーン・アドレス（e.g. Internet Protocol（ＩＰ）アドレス）などを記憶し管理しなければならない。外部ゲートウェイは、例えば、ＣＮにアタッチする移動端末に対して外部ネットワークに接続するためのユーザプレーン・アドレス（e.g. ＩＰアドレス）を割り当てるとともに、ＣＮＢに関するトンネル設定、課金制御、及びQuality of Service（ＱｏＳ）制御など行う。

　例えば、非特許文献１は、ＥＰＳにおいて、移動端末のＣＮへのアタッチ、又はサービス要求等に応じて、移動端末のユーザパケットを転送するためのデータベアラ（つまり、ＥＰＳベアラ）を確立・復旧する手順を記載している。

3GPP TS 23.401 V9.13.0, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 2012年6月

　上述したように、ＣＮは、ＣＮＢを移動端末毎に生成し、これらを管理しなければならない。例えば、ＣＮＢ数の増大に対応可能とするためには、外部ゲートウェイ及び転送ノードは、トンネル設定・管理、及びＩＰアドレス割当等の処理の増大に対応可能な能力が求められる。具体的には、転送ノードの性能増強、又は追加設置等が必要となる。この問題に対処するために、本件発明者は、過去の２件の日本特許出願特願２０１１－２１７３８３号及び特願２０１２－２１４０５０号において、複数の移動端末のユーザパケット転送のために１つのＣＮＢを共用することが可能なアーキテクチャ及び方法を提案している。

　本出願は、日本特許出願特願２０１１－２１７３８３号及び特願２０１２－２１４０５０号で提案したアーキテクチャ及び方法の改良を提供するものである。具体的には、本出願に示される目的の１つは、複数の移動端末のユーザパケット転送のために１つのＣＮＢを共用するアーキテクチャにおいて、共用ＣＮＢの利用効率の向上に寄与することである。本出願に示される他の目的は、複数の移動端末のユーザパケット転送のために１つのＣＮＢを共用するアーキテクチャにおいて、異なる移動管理ノードに帰属する複数の移動端末が１つの共用ＣＮＢを利用できるようにするための改良を提供することである。これらの課題を含む幾つかの課題に対処するために発明者により得られた技術思想は、後述する実施形態の記述及び図面によって明らかにされる。

　第１の態様では、移動通信システムは、移動管理ノード、複数の転送ノード、及び外部ゲートウェイを含むコアネットワークを含む。前記移動管理ノードは、移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）の管理を行うよう構成される。前記共用ＣＮＢの前記管理は、前記共用ＣＮＢが前記複数の転送ノードのうちの第１の転送ノードと前記外部ゲートウェイの間に既に設定されている間に前記移動端末グループに属する第１の移動端末から新たなベアラ確立要求を受信した場合に、前記第１の転送ノードを前記第１の移動端末のために選択することを含む。

　第２の態様では、移動通信システムは、加入者サーバ、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを含む。前記加入者サーバは、移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記移動管理ノードに通知する。前記移動管理ノードは、前記ユーザプレーン・アドレスに対応するユーザパケットが共用コアネットワークベアラ（ＣＮＢ）において転送されるよう前記共用ＣＮＢの設定を制御する。前記共用ＣＮＢは、前記転送ノードと前記外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される。

　第３の態様では、移動通信システムは、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを含む。前記移動管理ノードは、移動端末グループに属する第１の移動端末からの要求に応答して、共用コアネットワークベアラ（ＣＮＢ）を前記第１の移動端末のために設定するよう前記転送ノードに要求メッセージを送信する。前記共用ＣＮＢは、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用されるコアネットワークベアラである。前記外部ゲートウェイは、前記要求メッセージに基づく制御メッセージを前記転送ノードから受信し、前記第１の移動端末にユーザプレーン・アドレスを割り当てるとともに、前記ユーザプレーン・アドレスが宛先に指定されたユーザパケットを前記共用ＣＮＢに流すためのパケットフィルタを設定する。

　第４の態様では、移動通信システムは、加入者サーバ、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを含む。前記転送ノード及び前記外部ゲートウェイは、移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）を前記転送ノードと前記外部ゲートウェイの間に設定する。前記加入者サーバは、前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを示す通知を前記移動管理ノードに送信する。前記移動管理ノードは、前記通知を受信し、前記移動端末グループに属する第１の移動端末のためのベアラ設定を制御する。

　第５の態様では、移動通信システムは、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを含む。前記転送ノード及び前記外部ゲートウェイは、移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）を前記転送ノードと前記外部ゲートウェイの間に設定する。前記転送ノードは、前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを示す通知を前記移動管理ノードに送信する。前記移動管理ノードは、前記通知を受信し、前記移動端末グループに属する第１の移動端末のためのベアラ設定を制御する。

　上述した第１の態様は、複数の移動端末のユーザパケット転送のために１つのＣＮＢを共用するアーキテクチャにおいて、共用ＣＮＢの利用効率の向上に寄与することができる。また、上述した第２～第５の態様は、複数の移動端末のユーザパケット転送のために１つのＣＮＢを共用するアーキテクチャにおいて、異なる移動管理ノードに帰属する複数の移動端末が１つの共用ＣＮＢを利用できるようにするための改良を提供することができる。

実施形態に係る移動通信システムの構成例を示すブロック図である。実施形態に係る外部ゲートウェイのベアラ管理表の一例を示す図である（参考例１）。実施形態に係る転送ノードのベアラ管理表の一例を示す図である（参考例１）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例１、最初の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例１、最初の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例１、２台目以降の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例１、２台目以降の移動端末）。実施形態に係るベアラ復旧手順の一例を示すシーケンス図である（参考例１）。実施形態に係る外部ゲートウェイのベアラ管理表の一例を示す図である（参考例２）。実施形態に係る転送ノードのベアラ管理表の一例を示す図である（参考例２）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例２、最初の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例２、最初の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例２、２台目以降の移動端末、通信中の移動端末なし）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例２、２台目以降の移動端末、通信中の移動端末なし）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例２、２台目以降の移動端末、通信中の移動端末あり）。実施形態に係るベアラ復旧手順の一例を示すシーケンス図である（参考例２、通信中の移動端末なし）。実施形態に係るベアラ復旧手順の一例を示すシーケンス図である（参考例２、通信中の移動端末あり）。実施形態に係る移動通信システムの構成例を示すブロック図である（参考例３）。実施形態に係るベアラ確立又はベアラ復旧の手順の一例を示すフローチャートである（参考例３）。実施形態に係る外部ゲートウェイのベアラ管理表の一例を示す図である（参考例３）。実施形態に係る転送ノードのベアラ管理表の一例を示す図である（参考例３）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例３、２台目以降の移動端末、通信中の移動端末あり）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例３、２台目以降の移動端末、通信中の移動端末あり）。実施形態に係るベアラ復旧手順の一例を示すシーケンス図である（参考例３、通信中の移動端末あり）。実施形態に係る移動通信システムの構成例を示すブロック図である（参考例４）。実施形態に係るベアラ確立手順の一例を示すフローチャートである（参考例４）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例４）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例４）。実施形態に係る外部ゲートウェイのベアラ管理表の一例を示す図である（参考例４）。実施形態に係る転送ノードのベアラ管理表の一例を示す図である（参考例４）。実施形態に係る移動端末の通信開始時の動作例を示すフローチャートである（参考例４）。実施形態に係る移動通信システムの構成例を示すブロック図である（参考例５）。実施形態に係るベアラ確立手順の一例を示すフローチャートである（参考例５）。実施形態に係る外部ゲートウェイのベアラ管理表の一例を示す図である（参考例５）。実施形態に係る転送ノードのベアラ管理表の一例を示す図である（参考例５）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例５、２台目以降の移動端末、通信中の移動端末あり）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（参考例５、２台目以降の移動端末、通信中の移動端末あり）。実施形態に係るベアラ復旧手順の一例を示すシーケンス図である（参考例５、通信中の移動端末あり）。実施形態に係るベアラ復旧手順の一例を示すシーケンス図である（参考例５、通信中の移動端末あり）。実施形態に係る移動管理ノードの動作を示すフローチャートである（改良Ａ）。実施形態に係る移動通信システムの構成例を示すブロック図である（改良Ｂ－１）。実施形態に係る移動通信システムの構成例を示すブロック図である（改良Ｂ－２）。実施形態に係る移動通信システムの構成例を示すブロック図である（改良Ｂ－３）。実施形態に係る移動通信システムの構成例を示すブロック図である（改良Ｂ－４）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－１、最初の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－１、最初の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－１、２台目以降の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－１、２台目以降の移動端末）。実施形態に係るベアラ復旧手順の一例を示すシーケンス図である（改良Ｂ－１）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－２、２台目以降の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－２、２台目以降の移動端末）。実施形態に係るベアラ復旧手順の一例を示すシーケンス図である（改良Ｂ－２）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－３、最初の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－３、最初の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－３、２台目以降の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－３、２台目以降の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－４、２台目以降の移動端末）。実施形態に係るベアラ確立手順の一例を示すシーケンス図である（改良Ｂ－４、２台目以降の移動端末）。

　以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

＜第１の実施形態＞
　図１は、本実施形態を含む幾つかの実施形態に係る移動通信システムの構成例を示している。移動通信システムは、ＲＡＮ１０及びＣＮ２０を含む。ＲＡＮ１０は、基地局２を含む。基地局２は、無線アクセス技術により移動端末（ＵＥ）１と接続する。移動端末１は、無線インタフェースを有し、無線アクセス技術により基地局２に接続し、ＲＡＮ１０を介してＣＮ２０へ接続する。そして、移動端末１は、ＲＡＮ１０及びＣＮ２０を介して外部ネットワーク９と通信する。外部ネットワーク９は、インターネット、パケットデータネットワーク若しくはＰＳＴＮ、又はこれらの組み合わせである。ＲＡＮ１０は、例えば、ＵＴＲＡＮ若しくはＥ－ＵＴＲＡＮ、又はこれらの組み合わせである。ＵＴＲＡＮにおいては、基地局２はＮｏｄｅＢ及びＲＮＣに対応する。Ｅ－ＵＴＲＡＮにおいては、基地局２はｅＮＢに対応する。

　基地局２は、移動端末１のユーザパケット転送のために、移動端末１との間で無線ベアラ５０を確立し、転送ノード４との間でベアラ４０を確立する。ベアラ４０は、ＵＴＲＡＮではＩｕベアラに対応し、Ｅ－ＵＴＲＡＮではＳ１ベアラに対応する。ベアラ４０及び無線ベアラ５０の組み合わせは、無線アクセスベアラ（ＲＡＢ）に相当する。

　ＣＮ２０は、主に移動通信サービスを提供するオペレータによって管理されるネットワークである。ＣＮ２０は、Packet Switched（ＰＳ）コアを含む。ＣＮ２０は、例えば、ＥＰＣ若しくはＧＰＲＳパケットコア、又はこれらの組み合わせである。図１の例では、ＣＮ２０は、移動管理ノード３、転送ノード４、外部ゲートウェイ５、及び加入者情報データベース６を含む。また、ＣＮ２０は、通信管理ユニット７を含んでもよい。

　移動管理ノード３は、コントロールプレーンのノードであり、移動端末１のモビリティ管理（e.g. 位置登録）、及びベアラ管理（e.g. ベアラ確立、ベアラ構成変更、ベアラ解放）などを行う。制御部３０１は、少なくともベアラ管理のためにコアネットワーク２０及び基地局２を制御する。例えば、ＵＭＴＳの場合、移動管理ノード３は、ＳＧＳＮのコントロールプレーン機能を含む。また、ＥＰＳの場合、移動管理ノード３は、ＭＭＥを含む。移動管理ノード３は、基地局２との間で制御メッセージ（e.g. Ｓ１ＡＰメッセージ）を送受信し、移動端末１との間でNon-Access Stratum（ＮＡＳ）メッセージを送受信する。ＮＡＳメッセージは、ＲＡＮ１０で終端されず、ＲＡＮ１０の無線アクセス方式に依存することなく、移動端末１とＣＮ２０の間で透過的に送受信される制御メッセージである。移動端末１からＣＮ２０に送られるＮＡＳメッセージは、アタッチ要求、ベアラ確立要求、ベアラ復旧要求、及び位置更新要求などのＮＡＳ要求メッセージを含む。例えば、ＥＰＳの場合、移動端末１からのＮＡＳ要求メッセージは、Attach Request、Service Request、PDN connectivity request、Bearer Resource Allocation Request、Bearer Resource Modification Request、TAU (Tracking Area Update) Request、及びRAU (Routing Area Update) Request等を含む。ＥＰＳでのアタッチ要求（Attach Request）は、移動端末１のＣＮ２０への接続だけでなく、デフォルトベアラの確立を引き起こす。したがって、ＥＰＳでのアタッチ要求（Attach Request）は、ベアラ確立要求を含むと言うことができる。

　転送ノード４は、ＲＡＮ１０（具体的には基地局２）と外部ゲートウェイ５の間で移動端末１のユーザパケットを転送する。転送ノード４は、移動端末１のユーザパケット転送のために、基地局２との間でベアラを確立し、外部ゲートウェイ５との間でコアネットワークベアラ（ＣＮＢ）３０を確立する。制御部４０１は、移動管理ノード３及び外部ゲートウェイ５と制御メッセージを交換し、基地局２とのベアラの設定およびＣＮＢ３０の設定を行う。転送ノード４（制御部４０１）は、一例において、移動端末１に付与すべきユーザプレーン・アドレス（e.g. ＩＰアドレス）の払い出しを行ってもよい。例えば、ＵＭＴＳの場合、転送ノード４は、ＳＧＳＮのユーザプレーン機能を含む。また、ＥＰＳの場合、転送ノード４は、Ｓ－ＧＷを含む。ＣＮＢ３０は、例えば、ＵＭＴＳにおけるＣＮＢ、又はＥＰＳにおけるＳ５／Ｓ８ベアラに対応する。なお、後述するように、本実施形態におけるＣＮＢ３０は、複数の移動端末１のユーザパケット転送のために共用される。以下では、移動端末単位で設定される（又は１つの移動端末のためだけに使用される）通常のＣＮＢと区別するために、ＣＮＢ３０を「共用ＣＮＢ」と呼ぶ。また、以下では、共用ＣＮＢ３０を共用する複数の移動端末１を「移動端末グループ」と呼ぶことがある。共用ＣＮＢ３０は、１つの基地局２に接続する複数の移動端末１の間で共用される場合もあるし、複数の基地局２に接続する複数の移動端末１の間で共用される場合もある。

　外部ゲートウェイ５は、転送ノード４と外部ネットワーク９の間で移動端末１のユーザパケットを転送する。外部ゲートウェイ５は、転送ノード４との間で共用ＣＮＢ３０を確立する。制御部５０１は、転送ノード４と制御メッセージを交換し、共用ＣＮＢ３０の設定を行う。外部ゲートウェイ５（制御部５０１）は、一例において、移動端末１に付与すべきユーザプレーン・アドレス（e.g. ＩＰアドレス）の払い出しを行ってもよい。例えば、ＵＭＴＳの場合、外部ゲートウェイ５は、ＧＧＳＮを含む。また、ＥＰＳの場合、外部ゲートウェイ５は、Ｐ－ＧＷを含む。

　加入者情報データベース６は、移動端末１の加入者情報を保持するデータベースであり、例えばHome Subscriber Server（ＨＳＳ）又はHome Location Server（ＨＬＲ）がこれに相当する。加入者情報データベース６は、移動管理ノード３等に加入者情報を提供する機能を有する。加入者情報データベース６は、加入者サーバと呼ぶこともできる。管理部６０１は、移動管理ノード３の要求に応答して、移動管理ノード３に加入者情報を送信する。加入者情報データベース６（管理部６０１）は、一例において、移動端末１に付与すべきユーザプレーン・アドレス（e.g. ＩＰアドレス）の払い出しを行ってもよい。

　続いて以下では、本実施形態の前提となる本件発明者等によって考案されたＣＮＢ共用のアーキテクチャ及び方法を含む「参考例１～５」について図２～３２を用いて説明する。参考例１及び２は、本件発明者の過去の日本特許出願特願２０１１－２１７３８３号に記載されている。参考例３～５は、本件発明者の過去の日本特許出願特願２０１２－２１４０５０号に記載されている。なお、参考例１～５は、本件出願時点において公知なものではなく、本件発明者によって所有されている技術思想である。

（参考例１）
　参考例１では、ＣＮ２０は、１又は複数の基地局２に接続する複数の移動端末１のユーザパケット転送のために共用される共用ＣＮＢ３０を、転送ノード４と外部ゲートウェイ５の間に設定する。複数の移動端末１は、共用ＣＮＢ３０を利用して同時に通信することができる。そのために、参考例１では、転送ノード４は、共用ＣＮＢ３０から得られたダウンリンク・ユーザパケットの宛先を検閲し、宛先に指定された移動端末１に対応する無線アクセスベアラ（ＲＡＢ）にダウンリンク・ユーザパケットを転送する。つまり、転送ノード４は、１つの共用ＣＮＢ３０を複数のＲＡＢと対応付ける。

　外部ゲートウェイ５は、１つの共用ＣＮＢ４０を共用する複数の移動端末１（つまり、端末グループ）に対してユーザプレーン・アドレス帯域を払い出し、各移動端末１へのユーザプレーン・アドレスの払い出しの権限を転送ノード４に移譲する。転送ノード４は、外部ゲートウェイ５により指定されたユーザプレーン・アドレス帯域から各移動端末１にユーザプレーン・アドレスを払い出す。ユーザプレーン・アドレスは、ユーザプレーンのプロトコルに依存するが、典型的にはＩＰアドレスである。以下では、ユーザプレーン・アドレスがＩＰアドレスである場合を例にとって説明する。

　転送ノード４は、guaranteed bit rate（ＧＢＲ）等のQuality of service（QoS）を保証するために、１つの共用ＣＮＢ３０に対応付けられる移動端末１（アイドル状態の移動端末１も含む）の上限数、若しくは１つの共用ＣＮＢ３０において同時に通信する移動端末１の上限数、又はこれら両方を設定してもよい。転送ノード４は、これらいずれかの上限数を超えた場合、新たな共用ＣＮＢ３０を追加設定してもよいし、ベアラ確立又はベアラ復旧を拒否してもよい。

　図２は、参考例１における外部ゲートウェイ５のベアラ管理表の一例を示している。図２の例では、共用ＣＮＢ３０を識別するための情報（つまり、転送ノード４のＩＰアドレス、ＣＮＢ識別子）は、移動端末１に払いだしたＩＰアドレスではなく、移動端末グループに払いだしたＩＰアドレス帯域と対応付けられる。図２に示された２つの移動端末グループのＩＰアドレス帯域は、ＩＰｖ６アドレスで表されており、プレフィックス長が６０ビットであるサブネット番号を示している。例えば、サブネット番号“2001:DB8:1::/60”で示されるアドレス帯域に含まれるＩＰｖ６アドレスが割り当てられた複数の移動端末１のユーザパケットの全ては、転送ノード４のＩＰｖ４アドレス“10.0.0.1”及びＣＮＢ識別子“00001”によって特定される共用ＣＮＢ３０に転送される。

　図３は、参考例１における転送ノード４のベアラ管理表の一例を示している。転送ノード４のベアラ管理表は、ＣＮＢとＲＡＢを対応付けるために使用され、さらに各移動端末１のＩＰアドレスとＲＡＢを対応付けるために使用される。例えば、３つの移動端末１のＩＰｖ６アドレス“2001:DB8:1:1:/64”、“2001:DB8:1:2:/64”、及び“2001:DB8:1:3:/64”は、外部ゲートウェイ５のＩＰｖ４アドレス“10.1.0.1”及びＣＮＢ識別子“00001”によって特定される同じ共用ＣＮＢ３０に対応付けられている。さらに、３つの移動端末１のＩＰｖ６アドレス“2001:DB8:1:1:/64”、“2001:DB8:1:2:/64”、及び“2001:DB8:1:3:/64”は、それぞれ異なるＲＡＢと対応付けられている。したがって、例えば、転送ノード４は、宛先が“2001:DB8:1:1:/64”であるダウンリンク・ユーザパケットを、基地局２のＩＰｖ４アドレス“10.0.1.1”及びＲＡＢ識別子“00001”によって特定されるベアラ４０に転送する。

　続いて以下では、参考例１におけるデータベアラの確立及び復旧の手順について説明する。なお、既に述べた通り、本明細書でのデータベアラの用語は、ユーザデータ転送のために外部ゲートウェイ５と移動端末１の間に設定される通信路を意味する。データベアラは、例えば、ＵＭＴＳベアラまたはＥＰＳベアラである。また、データベアラの“確立”は、ＲＡＮ１０及びＣＮ２０のいずれのノードにも正しいベアラコンテキストが保持されておらず、データベアラが最初に設定されることを意味する。一方、データベアラの“復旧”は、過去に設定されたデータベアラの再設定、特にＲＡＢの再設定、を意味する。ＵＭＴＳ及びＥＰＳ等の移動通信システムは、プリザベーション機能を有しており、移動端末１のＩＤＬＥ状態（例えば、ＥＣＭ－ＩＤＬＥ）への遷移に応じてＲＡＢを解放するが、移動端末１及びＣＮ２０内のノード（つまり、移動管理ノード３、転送ノード４、外部ゲートウェイ５）はデータベアラのコンテキストを維持している。したがって、データベアラの復旧では、プリザベーション機能で維持されているベアラコンテキストに基づいてＲＡＢが再設定される。

　図４Ａ及び図４Ｂのシーケンス図は、共用ＣＮＢ３０が設定されていないときに、移動端末グループに属するいずれかの移動端末１（最初の移動端末）からの要求に応答して共用ＣＮＢ３０を含むデータベアラを確立する手順を示している。ステップＳ１０１では、移動端末１は、ベアラ確立要求を送信する。ステップＳ１０２では、基地局２は、移動端末１から受信したベアラ確立要求を移動管理ノード３に転送する。ベアラ確立要求は、例えば、ＥＰＳにおけるAttach Request、又はＵＭＴＳにおけるActivate PDP Context Requestである。ステップＳ１０３では、移動管理ノード３は、ベアラ確立要求の受信に応答して、移動端末１の認証処理を起動する。認証処理は、加入者情報データベース６へのアクセスを含む。つまり、移動管理ノード３は、ベアラ確立要求の送信元端末の識別子（e.g. International Mobile Subscriber Identity（ＩＭＳＩ））をデータベース６に送信し、移動端末１の加入者情報をデータベース６から受信する。ここで、加入者情報は、端末グループ情報を含む。端末グループ情報は、ベアラ確立要求の送信元端末がある移動端末グループに帰属する端末であることを示す。端末グループ情報は、例えば、移動端末１が属する移動端末グループの識別子、グループ収容端末数（必要なＩＰアドレス数、又は必要なＩＰアドレス帯域）、共用ＣＮＢの同時利用上限数、などを含む。

　移動管理ノード３は、端末グループ情報に基づいて、移動端末１のデータベアラ共用の要否を判断する。ベアラ共用を行う場合、移動管理ノード３は、ベアラ共用が必要であることを示すベアラ確立要求を転送ノード４に送信する（ステップＳ１０４）。移動管理ノード３は、例えば、通常のベアラ確立要求にベアラ共用情報を含めればよい。転送ノード４に送られる通常のベアラ確立要求は、例えば、ＥＰＳにおけるCreate Session Request、又はＵＭＴＳにおけるCreate PDP Context Requestである。ベアラ共用情報は、共用ベアラの確立が必要であることを示す。転送ノード４及び外部ゲートウェイ５は、ベアラ確立要求がベアラ共用情報を含むことによって、共用ＣＮＢの設定が必要であることを認識することができる。ベアラ共用情報は、例えば、端末グループに必要なＩＰアドレス数の決定に必要な情報を示してもよい。具体的には、ベアラ共用情報は、移動端末グループ識別子およびグループ収容端末数（必要ＩＰアドレス数、又は必要なＩＰアドレス帯域）であってもよい。

　ステップＳ１０５において、転送ノード４は、移動管理ノード３からのベアラ確立要求の受信に応答して、新たなデータベアラに関するエントリをベアラ管理表に生成し、ベアラ確立要求（ベアラ共用情報を含む）を外部ゲートウェイ５に送信する。ステップＳ１０６では、外部ゲートウェイ５は、ベアラ共用情報を含むベアラ確立要求の受信に応答して、必要ＩＰアドレス数を満足するアドレス帯域を移動端末グループのために払い出す。また、外部ゲートウェイ５は、必要に応じて、移動端末グループに応じたＱｏＳを共用ＣＮＢ３０に設定する。外部ゲートウェイ５は、転送ノード４から受信した転送ノード４側のトンネルエンドポイント識別子、及び移動端末グループに払い出したＩＰアドレス帯域などに基づいて、新たな共用ＣＮＢ３０に関するエントリをベアラ管理表に生成する。その後、ステップＳ１０７では、外部ゲートウェイ５は、ベアラ確立応答を転送ノード４に送信する。このベアラ確立応答は、ＩＰアドレス帯域、外部ゲートウェイ５側のトンネルエンドポイント識別子を含む。また、ベアラ確立応答は、データベアラＱｏＳ等の追加情報を含んでもよい。ベアラ確立応答は、例えば、ＥＰＳにおけるCreate Session Response、又はＵＭＴＳにおけるCreate PDP Context Responseである。

　ステップＳ１０８において、転送ノード４は、外部ゲートウェイ５からのベアラ確立応答により示されるＩＰアドレス帯域の中から、移動端末１に割り当てるＩＰアドレスを決定する。さらに、ステップＳ１０８において、転送ノード４は、外部ゲートウェイ５からのベアラ確立応答の受信に応答して、ベアラ管理表における共用ＣＮＢ３０の情報を更新する。そして、ステップＳ１０９において、転送ノード４は、ベアラ確立応答を移動管理ノード３に送信する。このベアラ確立応答は、転送ノード４において共用ＣＮＢ３０と対応付けられるＲＡＢ（ベアラ４０を含む）の転送ノード４側のトンネルエンドポイント識別子を含む。さらに、ベアラ確立応答は、移動端末１に払い出されたＩＰアドレスを示す。なお、ＵＭＴＳの場合、移動管理ノード３の機能と転送ノードの機能４はＳＧＳＮに集約されているから、ステップＳ１０９におけるベアラ確立応答は、ＳＧＳＮ内の内部メッセージに相当する。

　ステップＳ１１０では、移動管理ノード３は、転送ノード４からベアラ確立応答を受信し、移動端末１に関するベアラコンテキストを更新する。さらに、ステップＳ１１０では、移動管理ノード３は、ベアラ確立応答を含む制御メッセージを基地局２に送信する。ステップＳ１１０のベアラ確立応答は、移動端末１に通知される情報であり、移動端末１に割り当てられたＩＰアドレス、データベアラ識別子などを含む。また、ステップＳ１１０のベアラ確立応答を含む制御メッセージは、ベアラ４０の転送ノード４側のトンネルエンドポイント識別子、データベアラＱｏＳ等を含む。ステップＳ１１０のベアラ確立応答は、例えば、ＥＰＳにおけるAttach Accept、又はＵＭＴＳにおけるActivate PDP Context Acceptである。また、ベアラ確立応答を含む制御メッセージは、例えば、ＥＰＳにおけるS1-APメッセージ（具体的には、Initial Context Setup Request）である。

　ステップＳ１１１及びＳ１１２では、基地局２は、ベアラ確立応答を移動端末１に転送するとともに、移動端末１のための無線リンク（つまり、無線ベアラ５０）を確立する処理を実行する。ステップＳ１１３では、基地局２は、ベアラ確立完了通知を移動管理ノード３に送信する。ベアラ確立完了通知は、基地局２でのベアラ設定完了と、移動端末１でのベアラ設定完了を示す。ベアラ確立完了通知は、２つのメッセージに分けて送信されてもよい。例えば、ベアラ確立完了通知は、ＥＰＳにおけるInitial Context Response及びAttach Completeであってもよい。

　ステップＳ１１４では、移動管理ノード３は、ベアラ確立完了通知の受信に応答して、ベアラ更新要求を転送ノード４に送信する。ベアラ更新要求は、ベアラ４０の基地局２側のトンネルエンドポイント識別子を含む。転送ノード４は、ベアラ更新要求に基づいて、ベアラ管理表を更新する。ベアラ更新要求は、例えば、ＥＰＳにおけるModify Bearer Requestである。ＵＭＴＳの場合、移動管理ノード３の機能と転送ノードの機能４はＳＧＳＮに集約されているから、ステップＳ１１４におけるベアラ更新要求は、ＳＧＳＮ内の内部メッセージに相当する。ステップＳ１１５では、転送ノード４は、ベアラ更新応答を移動管理ノード３に送信する。ベアラ更新応答は、例えば、ＥＰＳにおけるModify Bearer Response、又はＵＭＴＳにおけるUpdate PDP Context Responseである。

　続いて以下では、同一移動端末グループ内の２台目以降の移動端末１からのベアラ確立要求の処理について説明する。２台目以降の移動端末１からのベアラ確立要求の処理では、転送ノード４と外部ゲートウェイ５の間のシグナリングが省略される。図５Ａ及び図５Ｂは、２台目以降の移動端末１からのベアラ確立要求の処理手順の例を示すシーケンス図である。ステップＳ２０１～Ｓ２０４における処理は、図４ＡのステップＳ１０１～Ｓ１０４における処理と同様である。ステップＳ２０５では、転送ノード４は、移動管理ノード３からのベアラ確立要求に含まれるベアラ共用情報（例えば、移動端末グループの識別子など）に基づいて、共用ＣＮＢ３０が確立済みであることを認識し、外部ゲートウェイ５から払い出し済みのＩＰアドレス帯域の中から、２台目以降の移動端末１に割り当てるＩＰアドレスを決定する。ステップＳ２０６～Ｓ２１２における処理は、図４Ａ及び４ＢのステップＳ１０９～Ｓ１１５における処理と同様である。

　なお、ステップＳ２０５では、転送ノード４は、グループ収容端末数をチェックしてもよい。１つの共用ＣＮＢ３０に集約される移動端末１の数が上限数を超えた場合、例えば、転送ノード４は、図４Ａ及び４Ｂに示した最初の移動端末１に対する共用ＣＮＢ確立手順に従って、新たな共用ＣＮＢ３０を確立してもよい。あるいは、転送ノード４は、共用ＣＮＢではない通常のＣＮＢを確立してもよい。また、１つの共用ＣＮＢ３０において同時に通信する移動端末１の上限数を超える場合にも、転送ノード４は、新たな集約ベアラを確立してもよいし、通常のＣＭＢを確立してもよいし、ベアラ確立を拒否してもよい。

　次に、図６を用いて参考例１に係るデータベアラの復旧手順を説明する。図６のステップＳ３０１では、移動端末１は、ベアラ復旧要求を送信する。ステップＳ３０２では、基地局２は、移動端末１から受信したベアラ復旧要求を移動管理ノード３に転送する。ベアラ復旧要求は、例えば、ＥＰＳにおけるService Request、又はＵＭＴＳにおけるService Requestである。

　ステップＳ３０３～Ｓ３０６では、ＲＡＢ（ベアラ４０及び無線ベアラ５０）が確立される。つまり、移動管理ノード３は、ＲＡＢ確立要求を基地局２に送信する（ステップＳ３０３）。ＲＡＢ確立要求は、例えば、ＥＰＳにおけるS1-AP Initial Context Setup Request、又はＵＭＴＳにおけるRadio Access Bearer Assignment Requestである。ステップＳ３０４では、基地局２は、移動端末１との間の無線リンク（無線ベアラ５０）を確立する。ステップＳ３０６では、基地局２は、ＲＡＢ（ベアラ４０及び無線ベアラ５０）の設定完了を示すＲＡＢ確立完了通知を移動管理ノード３に送信する。ＲＡＢ確立完了通知は、例えば、ＥＰＳにおけるS1-AP Initial Context Setup Complete、又はＵＭＴＳにおけるRadio Access Bearer Assignment Responseである。

　ステップＳ３０６では、移動管理ノード３は、ベアラ確立完了通知の受信に応答して、ベアラ更新要求を転送ノード４に送信する。ベアラ更新要求は、ベアラ４０の基地局２側のトンネルエンドポイント識別子を含む。

　ステップＳ３０７では、転送ノード４は、共用ＣＮＢ３０において同時に通信中である移動端末１の数が上限数を超えないかをチェックする。共用ＣＮＢ３０において同時通信中の移動端末数が上限数を超えない場合、転送ノード４は、ベアラ更新要求に基づいてベアラ管理表を更新し、ベアラ更新応答を移動管理ノード３に送信する（ステップＳ３０８）。一方、共用ＣＮＢ３０において同時通信中の移動端末数が上限数を超える場合、ベアラ復旧を拒絶することを示す否定応答を移動管理ノード３に送信すればよい。このとき、移動管理ノード３又は基地局２は、バックオフ通知を移動端末１に送信してもよい。バックオフ通知は、例えば、バックオフタイマ値を含む。この場合、移動端末１は、バックオフタイマ値の間、又はランダムに決定されたバックオフ時間の間、次のアタッチ要求、ベアラ確立要求、又はベアラ復旧要求の送信を待機すればよい。

　以上に述べたように参考例１に係るアーキテクチャ及び方法は、共用ＣＮＢ３０を複数の移動端末１に関するユーザパケット転送のために共用している。参考例１では、共用ＣＮＢ３０のエンドポイント設定は、複数の移動端末１のユーザパケット転送のために共通的に使用される。このため、特に外部ゲートウェイ５が管理すべきベアラコンテキストの数が少なくて済む。つまり、外部ゲートウェイ５は、複数の移動端末１に対して１つの共用ＣＮＢ３０に関するコンテキストを維持すればよい。したがって、参考例１に係るアーキテクチャ及び方法は、特に外部ゲートウェイ５においてベアラ維持に要する処理負荷を低減できる。

（参考例２）
　参考例２では、ＣＮ２０は、転送ノード４において共用ＣＮＢ３０をＲＡＢ（具体的にはベアラ４０）と一対一に対応付ける。ＣＮ２０は、移動端末グループに属する複数の移動端末１のうち任意の１台が通信を行う際に、この任意の１台のために共用ＣＮＢ３０及びベアラ４０を使用する。つまり、参考例２では、共用ＣＮＢ３０において同時に通信可能な移動端末の数が１台に制限される。後述するように、移動管理ノード３は、複数の移動端末１が共用ＣＮＢ３０を同時に使用しないように、複数の移動端末１からのベアラ確立要求（e.g. Attach Request）及びベアラ復旧要求（e.g. Service Request）を調停する。また、外部ゲートウェイ５は、複数の移動端末１に関するユーザデータが共用ＣＮＢ３０に流入しないように、共用ＣＮＢ３０のパケットフィルタ（e.g. traffic Flow Template（ＴＦＴ））を適切に設定する。これにより、転送ノード４が特別な動作を行うこと無く、共用ＣＮＢ３０を複数の移動端末１のユーザパケット転送のために利用できる。

　参考例２では、転送ノード４は、複数の移動端末１のユーザパケット転送のために、１つの共用ＣＮＢ３０と１つのベアラ４０の対応関係を管理しておけばよく、移動端末１単位でのユーザパケットの振り分けを行わなくてもよい。したがって、転送ノード４が管理すべきベアラ管理表の容量を削減でき、転送ノード４の処理量を削減できる。また、参考例１と同様に、外部ゲートウェイ５が扱うＣＮＢ数も減少するため、外部ゲートウェイ５が管理すべきベアラ管理表の容量を削減できる。

　図７は、参考例２における外部ゲートウェイ５のベアラ管理表の一例を示している。図７のベアラ管理表は、図２に示した参考例１のベアラ管理表と同様である。

　図８は、参考例２における転送ノード４のベアラ管理表の一例を示している。参考例２において、転送ノード４のベアラ管理表は、ＣＮＢとＲＡＢを対応付けるために使用される。例えば、外部ゲートウェイ５のＩＰｖ４アドレス“10.1.0.1”及びＣＮＢ識別子“00001”によって特定される共用ＣＮＢ３０は、基地局２のＩＰｖ４アドレス“10.0.1.1”及びＲＡＢ識別子“00001”によって特定されるベアラ４０と対応付けられる。図８のベアラ管理表は、転送ノード４（e.g. ＳＧＳＮ、Ｓ－ＧＷ）が持つ一般的な管理表と同様である。

　続いて以下では、参考例２におけるデータベアラの確立及び復旧の手順について説明する。図９Ａ及び図９Ｂのシーケンス図は、共用ＣＮＢ３０が設定されていないときに、移動端末グループに属するいずれかの移動端末１（最初の移動端末）からの要求に応答して共用ＣＮＢ３０を含むデータベアラを確立する手順を示している。ステップＳ４０１～Ｓ４０７における処理は、図４Ａに示したステップＳ１０１～Ｓ１０７における処理と同様である。

　ステップＳ４０８では、転送ノード４は、外部ゲートウェイ５からのベアラ確立応答の受信に応答して、ベアラ管理表における共用ＣＮＢ３０の情報を更新し、ベアラ確立応答を移動管理ノード３に送信する。このベアラ確立応答は、転送ノード４において共用ＣＮＢ３０と対応付けられるＲＡＢ（ベアラ４０を含む）の転送ノード４側のトンネルエンドポイント識別子を含む。さらに、ベアラ確立応答は、端末グループに払い出されたＩＰアドレス帯域を示す。なお、ＵＭＴＳの場合、移動管理ノード３の機能と転送ノードの機能４はＳＧＳＮに集約されているから、ステップＳ４０８におけるベアラ確立応答は、ＳＧＳＮ内の内部メッセージに相当する。

　ステップＳ４０９では、移動管理ノード３は、転送ノード４からベアラ確立応答を受信する。そして、移動管理ノード３は、外部ゲートウェイ５により移動端末グループに払い出されたＩＰアドレス帯域の中から、移動端末１に割り当てる１つのＩＰアドレスを決定する。

　ステップＳ４１０～Ｓ４１３における処理は、図４ＢのステップＳ１１０～Ｓ１１３における処理と同様である。ステップＳ４１４では、移動管理ノード３は、ベアラ確立完了通知の受信に応答して、ベアラ更新要求を転送ノード４に送信する。ベアラ更新要求は、ベアラ４０の基地局２側のトンネルエンドポイント識別子を含む。転送ノード４は、ベアラ更新要求に基づいて、ベアラ管理表を更新する。ベアラ更新要求は、例えば、ＥＰＳにおけるModify Bearer Requestである。ＵＭＴＳの場合、移動管理ノード３の機能と転送ノードの機能４はＳＧＳＮに集約されているから、ステップＳ１１４におけるベアラ更新要求は、ＳＧＳＮ内の内部メッセージに相当する。

　さらに、ステップＳ４１４では、転送ノード４は、外部ゲートウェイ５のパケットフィルタを更新するために、ベアラ更新要求を外部ゲートウェイ５に送信する。このベアラ更新要求は、移動管理ノード３によって移動端末１に払い出されたＩＰアドレス以外の他のアドレスを宛先とするユーザパケットを破棄するパケットフィルタを共用ＣＮＢ３０に設定することを外部ゲートウェイ５に要求する。転送ノード４から外部ゲートウェイ５に送られるベアラ更新要求は、例えば、ＥＰＳにおけるModify Bearer Request、又はＵＭＴＳにおけるUpdate PDP Context Requestである。

　ステップＳ４１５では、外部ゲートウェイ５は、共用ＣＮＢ３０に適用されるパケットフィルタを更新する。これにより、外部ゲートウェイ５は、移動端末グループに属する複数の移動端末１のうち実際に通信を行う１台のみに関するユーザパケットを共用ＣＮＢ３０で転送する。ステップＳ４１６では、外部ゲートウェイ５が転送ノード４にベアラ更新応答を送信し、転送ノード４が移動管理ノード３にベアラ更新応答を送信する。ベアラ更新応答は、例えば、ＥＰＳにおけるModify Bearer Response、又はＵＭＴＳにおけるUpdate PDP Context Responseである。

　続いて以下では、基地局２に接続する同じ移動端末グループ内の２台目以降の移動端末１からのベアラ確立要求の処理について説明する。図１０Ａ及び図１０Ｂ、並びに図１１は、２台目以降の移動端末１からのベアラ確立要求の処理手順の例を示すシーケンス図である。図１０Ａ及び図１０Ｂは、共用ＣＮＢ３０において通信中の移動端末１が存在しない場合の処理手順を示している。一方、図１１は、共用ＣＮＢ３０において通信中の移動端末１が存在する場合の処理手順を示している。

　まず、図１０Ａ及び図１０Ｂの手順について説明する。ステップＳ５０１～Ｓ５０３における処理は、図９ＡのステップＳ４０１～Ｓ４０３と同様である。ステップＳ５０４では、移動管理ノード３は、端末グループ情報に基づいて、移動端末１のデータベアラ共用の要否を判断する。そして、移動管理ノード３は、ベアラ確立要求の送信元の移動端末１が属する移動端末グループに関して現在通信中の移動端末１が存在するかを確認する。この確認は、移動管理ノード３が保持しているベアラコンテキストに基づいて行えばよい。また、この確認は、通信管理ユニット７に問い合わせることにより行なってもよい。図１０Ａの例では、移動管理ノード３は、現在通信中の移動端末１が存在しないことを判定し、移動管理ノード３は、２台目以降の移動端末１に対して、プールしているＩＰアドレス帯域の中からＩＰアドレスを割り当てる。ステップＳ５０６～Ｓ５１２における処理は、図９Ｂに示したステップＳ４１０～Ｓ４１６における処理と同様である。

　次に、通信中の移動端末１が存在する場合のベアラ確立手順を説明する。図１１のステップＳ６０１～Ｓ６０５における処理は、図１０ＡのステップＳ５０１～Ｓ５０５と同様である。ただし、図１１のステップＳ６０４では、移動管理ノード３は、ベアラ確立要求の送信元の移動端末１が属する移動端末グループに関して現在通信中の移動端末１が存在することを判定する。既に述べたように、参考例２では、１つの基地局２に接続する同じ移動端末グループ内の複数の移動端末１は、同時通信を行うことができない。このため、移動管理ノード３は、ベアラ確立拒否応答を基地局２を介して移動端末１に送信する（ステップＳ６０６及びＳ６０７）。図１１の例では、ベアラ確立拒否応答は、移動端末１に割り当てられたＩＰアドレスを含む。したがって、ベアラ確立拒否応答を受信した移動端末１は、デタッチ状態に戻るのではなく、ＣＮ２０に登録されているがＲＡＢが解放されているＩＤＬＥ状態に遷移してもよい。また、移動管理ノード３は、次のベアラ確立要求（又はベアラ復旧要求）の送信をバックオフすることを移動端末１に要求するバックオフ通知をベアラ確立拒否応答に含めてもよい。バックオフ通知は、例えば、バックオフタイマ値を含む。この場合、移動端末１は、バックオフタイマ値の間、又はランダムに決定されたバックオフ時間の間、次のベアラ確立要求（又はベアラ復旧要求）の送信を待機すればよい。

　続いて以下では、図１２及び図１３を用いて参考例２に係るデータベアラの復旧手順を説明する。図１２は、共用ＣＮＢ３０において通信中の移動端末１が存在しない場合の処理手順を示している。一方、図１３は、共用ＣＮＢ３０において通信中の移動端末１が存在する場合の処理手順を示している。図１２のステップＳ７０１では、移動端末１は、ベアラ復旧要求を送信する。ステップＳ７０２では、基地局２は、移動端末１から受信したベアラ復旧要求を移動管理ノード３に転送する。ベアラ復旧要求は、例えば、ＥＰＳにおけるService Request、又はＵＭＴＳにおけるService Requestである。ステップＳ７０３では、移動管理ノード３は、ベアラ復旧要求の送信元の移動端末１と同じ移動端末グループに属し且つ同じ基地局２に接続する移動端末１が通信中であるか否か、すなわち既に共用ＣＮＢ３０及びベアラ４０を使用中であるか否かを確認する。この確認は、ステップＳ７０４に示されるように、通信管理ユニット７に問い合わせることにより行われてもよい。

　ステップＳ７０３において現在通信中の移動端末１が存在しないと判定された場合、移動管理ノード３は、ＲＡＢ（ベアラ４０及び無線ベアラ５０）を確立する手順を実行する（ステップＳ７０５～Ｓ７０７）。つまり、移動管理ノード３は、ＲＡＢ確立要求を基地局２に送信する（ステップＳ７０５）。ＲＡＢ確立要求は、例えば、ＥＰＳにおけるS1-AP Initial Context Setup Request、又はＵＭＴＳにおけるRadio Access Bearer Assignment Requestである。ステップＳ７０６では、基地局２は、移動端末１との間の無線リンク（無線ベアラ５０）を確立する。ステップＳ７０７では、基地局２は、ＲＡＢ（ベアラ４０及び無線ベアラ５０）の設定完了を示すＲＡＢ確立完了通知を移動管理ノード３に送信する。ＲＡＢ確立完了通知は、例えば、ＥＰＳにおけるS1-AP Initial Context Setup Complete、又はＵＭＴＳにおけるRadio Access Bearer Assignment Responseである。

　ステップＳ７０８～Ｓ７１０における処理は、図９ＢのステップＳ４１４～Ｓ４１６、又は図１０ＢのステップＳ５１０～Ｓ５１２と同様である。つまり、ステップＳ７０８～Ｓ７１０では、転送ノード４は、ベアラ４０の基地局側のエンドポイント識別子を更新する。ステップＳ７０９では、外部ゲートウェイ５は、通信中に遷移する移動端末１以外の他の移動端末１宛てのパケットが共用ＣＮＢ３０を流れないように、パケットフィルタ（e.g. ＴＦＴ）を更新する。

　次に、通信中の移動端末１が存在する場合のベアラ復旧手順を説明する。図１３のステップＳ８０１～Ｓ８０４の処理は、図１２のステップＳ７０１～Ｓ７０４と同様である。ただし、図１３のステップＳ８０３では、現在通信中の移動端末１が存在することが判定される。参考例２では、同じ基地局２に接続する同じ移動端末グループ内の複数の端末１は、同時通信を行うことができない。このため、移動管理ノード３は、ベアラ復旧拒否応答を基地局２を介して移動端末１に送信する（ステップＳ８０５、及びＳ８０６）。ベアラ復旧拒否応答は、例えば、ＥＰＳにおけるService Reject、又はＵＭＴＳにおけるservice rejectである。移動管理ノード３は、移動端末１の次のベアラ復旧要求の送信をバックオフするための通知をベアラ復旧拒否応答に含めてもよい。この場合、移動端末１は、予め定められた又はランダムに決定されたバックオフ時間のあいだ次のベアラ復旧要求の送信を抑止する。

　以上に述べたように参考例２に係るアーキテクチャ及び方法は、共用ＣＮＢ３０を複数の移動端末１に関するユーザパケット転送のために共用している。さらに、共用ＣＮＢ３０のエンドポイント設定だけでなく、転送ノード４で管理されるベアラ４０のエンドポイント設定も複数の移動端末１のユーザパケット転送のために共通的に使用される。このため、転送ノード４及び外部ゲートウェイ５が管理すべきベアラコンテキストの数が少なくて済む。つまり、典型的には、転送ノード４及び外部ゲートウェイ５は、複数の移動端末１に対して１つの共用ＣＮＢ３０に関するコンテキストを維持すればよい。したがって、参考例２に係るアーキテクチャ及び方法は、転送ノード４及び外部ゲートウェイ５においてベアラ維持に要する処理負荷を低減できる。

　ただし、参考例２に係るＣＮＢ共用のアーキテクチャ及び方法は、同じ基地局２に接続する同じ移動端末グループ内の複数の移動端末１が同時通信を行うことができない。具体的には、移動管理ノード３は、同じ基地局２に接続する同じ移動端末グループ内の複数の移動端末１に対して同時に共用ＣＮＢ３０を割り当てないように、複数の移動端末１からのベアラ確立要求及びベアラ復旧要求を調停する。同時通信を行えないことは、（ａ）移動端末グループに属する複数の移動端末１の通信頻度が低い場合、（ｂ）移動端末１の通信時間が短い場合、又は（ｃ）移動端末１が通信遅延を許容する場合には、特に問題とならないと考えられる。したがって、参考例２に係るアーキテクチャ及び方法は、このような通信特性を有するアプリケーション、例えば、一部のMachine Type Communication（ＭＴＣ）アプリケーションへの応用において顕著な効果を奏すると考えられる。

　しかしながら、移動端末１の通信頻度がそれほど低くなく、複数の移動端末１の通信タイミングがある程度の確立で衝突する状況では、呼損の発生を抑制できることが好ましい。以下に説明される参考例３～５は、複数の移動端末１のユーザパケット転送のために共用ＣＮＢ３０を使用するアーキテクチャにおいて、呼損の発生を抑制するための改良を示す。

（参考例３）
　図１４は、参考例３に係る同時通信時のネットワーク及びベアラ構成を示す図である。同じ基地局２に接続する同じ移動端末グループ内の２台以上の移動端末１の通信タイミングが重ならない場合、参考例３に係る移動通信システムの動作は、参考例２のものと同様である。すなわち、参考例３に係る移動通信システムは、２台以上の移動端末１の通信タイミングが重ならない限り、共用ＣＮＢ３０のみを用いてデータパケット転送を行うことができる。この場合、外部ゲートウェイ５及び転送ノード４にて管理される共用ＣＮＢ３０のエンドポイント設定だけでなく、転送ノード４にて管理されるベアラ４０のエンドポイント設定も複数の移動端末１のユーザパケット転送のために共通的に使用される。このため、転送ノード４及び外部ゲートウェイ５が管理すべきベアラコンテキストの数が少なくて済み、ベアラ維持に要する処理負荷が低減される。

　一方、２台以上の移動端末１の通信タイミングが重なる場合、参考例３に係るＣＮ２０は、２台目以降の各移動端末１のために追加データベアラ（i.e. 追加ＣＮＢ３１、追加ベアラ４１、及び追加無線ベアラ５１）を設定して使用する。追加データベアラは、共用ＣＮＢ３０を用いない通常のデータベアラとすればよい。つまり、同じ移動端末グループ内の２台以上の移動端末１の通信タイミングが偶発的に重なった場合には、参考例３に係る移動通信システムは、一時的に通常のデータベアラを生成して対処する。これにより、参考例３に係る移動通信システムは、同じ移動端末グループに属する複数の移動端末１の同時通信を可能とできるため、呼損の発生を抑制できる。

　参考例３に係るＣＮ２０は、２台目以降の各移動端末１の通信終了に応じて、追加データベアラ（追加ＣＮＢ３１、追加ベアラ４１、及び追加無線ベアラ５１）に関するＣＮ２０における設定を解放してもよい。より具体的に述べると、通常のプリザベーション機能ではＣＮ２０においてベアラコンテキストが維持されるのに対して、参考例３に係るＣＮ２０は、２台目以降の各移動端末１が通信を終了してＩＤＬＥ状態に遷移する際に、追加データベアラに関するＣＮ２０における設定を解放してもよい。ＩＤＬＥ状態に遷移した移動端末１の次の通信では、共用ＣＮＢ３０が未使用であれば共用ＣＮＢ３０が使用される。

　続いて以下では、参考例３を実現するための処理手順の詳細について説明する。図１５は、参考例３に係る移動管理ノード３の動作例を示すフローチャートである。ステップＳ１１では、移動管理ノード３（制御部３０１）は、共用ＣＮＢ３０を設定済みの端末グループに属する移動端末１から、ベアラ確立要求又はベアラ復旧要求を受信する。ステップＳ１２では、移動管理ノード３（制御部３０１）は、ベアラ復旧要求の送信元端末と同じ移動端末グループに属し且つ同じ基地局２に接続する移動端末（ＵＥ）１が通信中であるか否かを判定する。通信中の移動端末１が存在しない場合（ステップＳ１２でＹＥＳ）、移動管理ノード３（制御部３０１）は、参考例２に関する図１０Ａ及び図１０Ｂ又は図１２と同様に、設定済みの共用ＣＮＢ３０と関連付けられたＲＡＢを生成して移動端末１に割り当てるように、移動端末１、基地局２、及び転送ノード４を制御する（ステップＳ１３）。一方、通信中の移動端末１が存在する場合（ステップＳ１２でＮＯ）、移動管理ノード３（制御部３０１）は、ベアラ確立手順を実行して追加データベアラ（ＣＮＢ３１、ベアラ４１、及び無線ベアラ５１）を新たに作成し、この追加データベアラを移動端末１に割り当てるように、移動端末１、基地局２、転送ノード４、及び外部ゲートウェイ５を制御する（ステップＳ１４）。

　図１６は、参考例３に係る外部ゲートウェイ５のベアラ管理表の一例を示している。外部ゲートウェイ５は、２つの移動端末１が同時に通信を行う際に、２台目の移動端末１に割り当てられたＩＰアドレスを宛先とするユーザパケットを追加ＣＮＢ３１に流すようにベアラ管理表（及びベアラ管理表に基づくパケットフィルタ）を修正する。つまり、外部ゲートウェイ５は、追加ＣＮＢ３１に関するエントリをベアラ管理表に追加する。図１６と図７の比較から理解されるように、図１６の管理表は追加ＣＮＢ３１に関する第３のエントリを含む。図１６の第３のエントリでは、ＩＰｖ６アドレス“2001:DB8:3:1::/64”は、転送ノード４のＩＰｖ４アドレス“10.0.0.1”及びＣＮＢ識別子“00003”によって特定される追加ＣＮＢ３１と対応付けられる。ＩＰｖ６アドレス“2001:DB8:1:1::/64”は、アドレス帯域としてのサブネット番号ではなく、１つの移動端末１に払い出されたＩＰｖ６アドレスである。

　外部ゲートウェイ５は、図１６の管理表を用いて最長一致（Longest matching）を行うことによって、ユーザパケットを振り分けるＣＮＢを決定すればよい。これにより、外部ゲートウェイ５は、ＩＰｖ６アドレス“2001:DB8:1:1::/64”を割り当てられた２台目の移動端末１のユーザパケットを共用ＣＮＢ３０ではなく追加ＣＮＢ３１に振り分けることができる。

　図１７は、参考例３に係る転送ノード４のベアラ管理表の一例を示している。図１７と図８の比較から理解されるように、図１７では、追加ＣＮＢ３１と追加ベアラ４１の対応関係を示す第３のエントリが追加されている。図１７の例では、追加ベアラ４１は、基地局２のＩＰアドレス“10.0.1.1”及びＲＡＢ識別子“00002”によって特定される。

　続いて以下では、参考例３に係る追加データベアラ確立手順の具体例を説明する。図１８Ａ及び図１８Ｂは、基地局２に接続する同じ移動端末グループ内の２台目以降の移動端末１からのベアラ確立要求の処理例を示すシーケンス図であり、通信中の移動端末１が存在する場合の処理手順を示している。なお、通信中の移動端末１が存在しない場合は、図１０Ａ及び図１０Ｂに示した参考例に係るシーケンスと同様の手順でベアラ確立要求を処理すればよい。

　図１８ＡのステップＳ９０１～Ｓ９０５における処理は、図１１に示したステップＳ６０１～Ｓ６０５と同様である。図１８ＡのステップＳ９０４では、移動管理ノード３は、ベアラ確立要求の送信元の移動端末１が属する端末グループに関して現在通信中の移動端末１が存在することを判定する。この後、図１１に示した参考例２では、移動管理ノード３はベアラ確立を拒否する。これに対して、図１８Ａに示す参考例３では、移動管理ノード３は、追加ベアラを生成するためにベアラ確立要求を転送ノード４に送信する（ステップＳ９０６）。ステップＳ９０６でのベアラ確立要求は、共用ＣＮＢではなく通常のＣＮＢを用いたデータベアラを確立するためのメッセージである。したがって、ステップＳ９０６でのベアラ確立要求は、移動管理ノード３が移動端末１に払い出したＩＰアドレスを含むが、ベアラ共用情報を含まない。

　ステップＳ９０７では、転送ノード４は、ベアラ確立要求の受信に応答して、新たなデータベアラに関するエントリをベアラ管理表に追加し、ベアラ確立要求（移動端末１のＩＰアドレスを含む）を外部ゲートウェイ５に送信する。ステップＳ９０８では、外部ゲートウェイ５は、ベアラ確立要求で指定された移動端末１のＩＰアドレスに対して通常のＣＮＢ（つまり、追加ＣＮＢ）を設定し、ベアラ管理表に新たなエントリを追加する。そして、外部ゲートウェイ５は、ベアラ確立応答を転送ノード４に送信する。その後のステップＳ９０９～Ｓ９１５における処理は、通常のデータベアラの確立手順、例えば非特許文献１のセクション5.3.1 “Attach procedure” に記載されている手順、と同様とすればよい。

　続いて、参考例３に係るベアラ復旧手順の具体例について図１９を用いて説明する。図１９のステップＳ１００１～Ｓ１００３における処理は、参考例２に係る図１３のステップＳ８０１～Ｓ８０３と同様である。図１９のステップＳ１００３では、移動管理ノード３は、ベアラ復旧要求の送信元の移動端末１と同じ基地局２に接続し且つ同じ移動端末グループに属する他の移動端末１が通信中であることを判定する。この後、図１３に示した参考例２では、移動管理ノード３は、ベアラ復旧を拒否する。これに対して、図１９に示す参考例３では、移動管理ノード３は、ベアラ復旧を拒否すると共に、移動端末１にデタッチ（つまり、ＣＮ２０との接続切断）を要求する（ステップＳ１００４及びＳ１００５）。図１９のステップＳ１００４及びＳ１００５で送信されるベアラ復旧拒否メッセージは、デタッチ要求を含む。これにより、移動端末１はベアラ復旧要求ではなくアタッチ要求を送信するため、移動管理ノード３は、アタッチ要求の受信に応答して図１８Ａ及び図１８Ｂに示したシーケンスに従って追加データベアラを設定する（ステップＳ１００６）。

　なお、図１９の手順は一例に過ぎない。例えば、図１９のＳ１００３において通信中の移動端末１が存在することが判定された場合に、ＣＮ２０及びＲＡＮ１０は、ベアラ復旧手順の代わりにベアラ確立手順又はベアラ追加手順と同様の手順を実行することで追加データベアラを確立してもよい。例えば、ＣＮ２０及びＲＡＮ１０は、図１９のステップＳ１００３の後に、図１８Ａ及び図１８Ｂに示されたベアラ確立手順のうちステップＳ９０６～Ｓ９１５と同様の処理を行なってもよい。また、データベアラの“追加”は、既存のデータベアラと同じコネクション（e.g. Packet Data Network（ＰＤＮ）コネクション）に個別データベアラを追加設定することを意味する。既存のコネクションにデータベアラを追加する手順は、例えば非特許文献１のセクション5.4.5 “UE requested bearer resource modification” に記載されている。

　既に述べたように、ＣＮ２０及びＲＡＮ１０は、図１８Ａ及び図１８Ｂ又は図１９等の手順に従って生成された追加データベアラを、移動端末１の通信が終了したことに応じて解放してもよい。例えば、移動管理ノード３は、移動端末１がＩＤＬＥ状態に遷移することに応じて、追加ＲＡＢ（ベアラ４１及び無線ベアラ５１）だけでなく追加ＣＮＢ３１の設定も消去するように、基地局２、転送ノード４、及び外部ゲートウェイ５を制御すればよい。

（参考例４）
　参考例３では、複数の移動端末１のユーザパケット転送のために共用ＣＮＢ３０を使用する場合に、呼損の発生を抑制することが可能な改良されたアーキテクチャ及び方法の１つについて説明した。参考例４では、他の改良されたアーキテクチャ及び方法について説明する。

　図２０は、参考例４に係る同時通信時のネットワーク及びベアラ構成を示す図である。参考例４では、ＣＮ２０は、基地局２に接続する同じ移動端末グループ内の複数の移動端末１のユーザパケット転送のために、複数の共用ＣＮＢを転送ノード４と外部ゲートウェイ５の間に設定する。ＣＮ２０は、複数の共用ＣＮＢの各々をＲＡＢと一対一に対応づける。図２０では、第１及び第２の共用ＣＮＢ３０及び３２が設定され、これらは第１のＲＡＢ（ベアラ４０及び無線ベアラ５０）及び第２のＲＡＢ（ベアラ４２及び無線ベアラ５２）にそれぞれ対応付けられる。そして、ＣＮ２０は、移動端末グループに属する任意の２台が通信を行う際に、これら任意の２台の一方のために第１の共用ＣＮＢ３０を使用し、他方のために第２の共用ＣＮＢ３２を使用する。これにより、参考例４に係る移動通信システムは、同じ移動端末グループに属する複数の移動端末１の同時通信を可能とできるため、呼損の発生を抑制できる。

　なお、共用ＣＮＢ３０及び３２は、参考例２で説明したように、複数の移動端末１のユーザパケット転送のために使用される。図２０の例では共用ＣＮＢ３０及び３２を用いて２台の移動端末１が同時に通信できる。例えば、基地局２に３台以上の移動端末１が接続している場合、移動管理ノード３は、２台の移動端末１に共用ＣＮＢ３０及び３２を割り当て、これら２台が通信中である間は３台目以降の移動端末１に共用ＣＮＢ３０及び３２を割り当てないように、３台目以降の移動端末１からのベアラ確立要求及びベアラ復旧要求を調停する。

　続いて以下では、参考例４を実現するための処理手順の詳細について説明する。参考例４では、ＣＮ２０にアタッチした移動端末１は、少なくとも２つのデータベアラに関するベアラコンテキストを維持する。移動端末１が複数のデータベアラを維持する機能は、例えば、ＥＰＳにおけるマルチプルＰＤＮ機能として既に知られている。マルチプルＰＤＮ機能を用いる場合、移動端末１は、同一の外部ゲートウェイ５を経由する複数のＰＤＮコネクションを維持すればよい。これら複数のＰＤＮコネクションは、同一のAccess Point Name（ＡＰＮ）に関連付けられてもよいし、異なるＡＰＮに関連付けられてもよい。

　図２１は、参考例４に係るベアラ確立手順の一例を示すシーケンス図である。ステップＳ１１０１では、移動端末１は、第１のベアラ確立要求を送信する。第１のベアラ確立要求は、ＣＮ２０に対して第１のＰＤＮコネクションの生成をトリガーする。ステップＳ１１０２では、移動管理ノード３は、第１のベアラ確立要求に応答して、第１の共用ＣＮＢ３０を用いるデータベアラを確立するよう、移動端末１、基地局２、転送ノード４、及び外部ゲートウェイ５を制御する。ステップＳ１１０２での処理は、参考例２に係る共用ＣＮＢを用いるデータベアラの確立手順（図９Ａ及び図９Ｂ）と同様とすればよい。ステップＳ１１０３では、移動端末１は、第２のベアラ確立要求を送信する。第２のベアラ確立要求は、ＣＮ２０に対して第２のＰＤＮコネクションの生成をトリガーする。ステップＳ１１０４では、移動管理ノード３は、第２のベアラ確立要求に応答して、第２の共用ＣＮＢ３２を用いるデータベアラを確立するよう、移動端末１、基地局２、転送ノード４、及び外部ゲートウェイ５を制御する。図２１の手順で生成される第１及び第２のデータベアラは、異なるＡＰＮに関連付けられてもよいし、同じＡＰＮに関連付けられてもよい。

　なお、図２１では、移動端末１が明示的に２つのベアラ確立要求を送信することによって、複数のデータベアラを生成する例を示した。これに代えて、参考例４に係るＣＮ２０は、移動端末１から送信される１つのベアラ確立要求に応答して、複数のデータベアラを生成する手順を起動してもよい。具体的には、移動管理ノード３は、１つのベアラ確立要求に応答して、同一の外部ゲートウェイ５を経由する複数のＰＤＮコネクションを生成する制御を行えばよい。

　図２２のシーケンス図は、異なるＡＰＮに関連付けられる第１及び第２のデータベアラ（第１及び第２のＰＤＮコネクション）を、１つのベアラ確立要求に応答して生成する手順の一例を示している。図２２のステップＳ１２０１及びＳ１２０２における処理は、図９Ａに示したステップＳ４０１及びＳ４０２、又は図１０Ａに示したステップＳ５０１及びＳ５０２と同様である。ステップＳ１２０３では、移動管理ノード３は、ベアラ確立要求の送信元の移動端末１に関する加入者情報を加入者情報データベース６から取得する。図２２の例では、加入者情報は、端末グループ情報並びに第１及び第２のＡＰＮを含む。そして、移動管理ノード３は、端末グループ情報並びに第１及び第２のＡＰＮを参照することによって、第１及び第２のＡＰＮに関する２つのＰＤＮコネクションの各々を、共用ＣＮＢを用いて生成する。すなわち、ステップＳ１２０４では、移動管理ノード３は、第１の共用ＣＮＢ３０を用いるデータベアラを第１のＡＰＮに関して確立するよう、移動端末１、基地局２、転送ノード４、及び外部ゲートウェイ５を制御する。ステップＳ１２０５では、移動管理ノード３は、第２の共用ＣＮＢ３２を用いるデータベアラを第２のＡＰＮに関して確立するよう、移動端末１、基地局２、転送ノード４、及び外部ゲートウェイ５を制御する。

　図２３のシーケンス図は、同一ＡＰＮに関連付けられる第１及び第２のデータベアラ（第１及び第２のＰＤＮコネクション）を、１つのベアラ確立要求に応答して生成する手順の一例を示している。図２３のステップＳ１３０１及びＳ１３０２における処理は、図９Ａに示したステップＳ４０１及びＳ４０２、又は図１０Ａに示したステップＳ５０１及びＳ５０２と同様である。ステップＳ１３０３では、移動管理ノード３は、移動端末１に関する加入者情報を加入者情報データベース６から取得する。図２３の例では、加入者情報は、第１及び第２の端末グループ情報を含む。つまり、加入者情報は、移動端末１が複数の端末グループに属することを示す。移動管理ノード３は、第１及び第２の端末グループ情報を参照することによって、第１及び第２の端末グループそれぞれに関連付けられる第１及び第２のＰＤＮコネクションを、共用ＣＮＢを用いて生成する。すなわち、ステップＳ１３０４では、移動管理ノード３は、第１の共用ＣＮＢ３０を用いるデータベアラを第１の端末グループに関して確立するよう、移動端末１、基地局２、転送ノード４、及び外部ゲートウェイ５を制御する。ステップＳ１３０５では、移動管理ノード３は、第２の共用ＣＮＢ３２を用いるデータベアラを第２の端末グループに関して確立するよう、移動端末１、基地局２、転送ノード４、及び外部ゲートウェイ５を制御する。

　図２４は、参考例４に係る外部ゲートウェイ５のベアラ管理表の一例を示している。外部ゲートウェイ５は、転送ノード４を介して受信した移動管理ノード３からの要求に応じて、１つの移動端末１に対して複数の共用ＣＮＢ３０及び３２を生成する。つまり、外部ゲートウェイ５は、２つの共用ＣＮＢ３０及び３２に関するエントリをベアラ管理表に追加する。図２４と図７の比較から理解されるように、図２４の管理表は第２の共用ＣＮＢ３２に関する第３のエントリを含む。図２４の第３のエントリでは、ＩＰｖ６アドレス帯域としてのサブネット番号“2001:DB8:3::/60”は、転送ノード４のＩＰｖ４アドレス“10.0.0.1”及びＣＮＢ識別子“00003”によって特定される第２の共用ＣＮＢ３２と対応付けられる。

　図２５は、参考例４に係る転送ノード４のベアラ管理表の一例を示している。図２５と図８の比較から理解されるように、図２５では、第２の共用ＣＮＢ３２とベアラ４２の対応関係を示す第３のエントリが追加されている。図２５の例では、ベアラ４２は、基地局２のＩＰアドレス“10.0.1.1”及びＲＡＢ識別子“00002”によって特定される。

　図２６は、参考例４に係る移動端末１の通信開始時の動作例を示すフローチャートである。図２６は、ＣＮ２０にアタッチ済みでＩＤＬＥ状態の移動端末１がサービス復旧要求を送信する動作を示している。ステップＳ２１では、移動端末１は、共用ＣＮＢ３０を用いる第１のデータベアラに関するベアラ復旧要求を送信する。ステップＳ２１では、第１のデータベアラの復旧要求が移動管理ノード３によって拒否されたか否かを判定する。第１のデータベアラの復旧が許可された場合（ステップＳ２２でＮＯ）、移動端末１は、第１のデータベアラを用いて通信を行う。一方、第１のデータベアラの復旧が拒否された場合（ステップＳ２２でＹＥＳ）、移動端末１は、共用ＣＮＢ３２を用いる第２のデータベアラに関するベアラ復旧要求を送信する（ステップＳ２３）。ステップＳ２２では、第２のデータベアラの復旧要求が移動管理ノード３によって拒否されたか否かを判定する。第１のデータベアラの復旧が許可された場合（ステップＳ２４でＮＯ）、移動端末１は、第２のデータベアラを用いて通信を行う。一方、第２のデータベアラの復旧も拒否された場合（ステップＳ２４でＹＥＳ）、移動端末１は、ステップＳ２１に戻って処理を繰り返せばよい。移動管理ノード３は、次のベアラ確立要求（又はベアラ復旧要求）の送信をバックオフすることを移動端末１に要求するバックオフ通知をベアラ復旧拒否メッセージとともに送信してもよい。

（参考例５）
　参考例５では、複数の移動端末１のユーザパケット転送のために共用ＣＮＢ３０を使用する場合に、呼損の発生を抑制することが可能な更に他のアーキテクチャ及び方法について説明する。

　図２７は、参考例５に係る同時通信時のネットワーク及びベアラ構成を示す図である。同じ基地局２に接続する同じ移動端末グループ内の２台以上の移動端末１の通信タイミングが重ならない場合、参考例５に係る移動通信システムの動作は、参考例２のものと同様である。すなわち、参考例５に係る移動通信システムは、２台以上の移動端末１の通信タイミングが重ならない限り、第１のＲＡＢ（ベアラ４０及び無線ベアラ５０）及び共用ＣＮＢ３０のみを用いてデータパケット転送を行うことができる。この場合、外部ゲートウェイ５及び転送ノード４にて管理される共用ＣＮＢ３０のエンドポイント設定だけでなく、転送ノード４にて管理されるベアラ４０のエンドポイント設定も複数の移動端末１のユーザパケット転送のために共通的に使用される。このため、転送ノード４及び外部ゲートウェイ５が管理すべきベアラコンテキストの数が少なくて済み、ベアラ維持に要する処理負荷が低減される。

　一方、２台以上の移動端末１の通信タイミングが重なる場合、参考例５に係るＣＮ２０は、２台目以降の各移動端末１のために追加の第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）を生成し、第１のＲＡＢ（ベアラ４０及び無線ベアラ５０）に加えて第２のＲＡＢも共用ＣＮＢ３０と対応付ける。この対応付けは、転送ノード４のベアラ対応表を更新することにより行えばよい。そして、参考例５に係るＣＮ２０は、１台目の移動端末１のために第１のＲＡＢ（ベアラ４０及び無線ベアラ５０）及び共用ＣＮＢ３０を使用し、２台目の移動端末１のために第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）及び共用ＣＮＢ３０を使用する。具体的には、転送ノード４は、共用ＣＮＢ３０を介して受信されたユーザパケットの宛先アドレスを参照し、１台目の移動端末１宛てのユーザパケットを第１のＲＡＢ（つまり、ベアラ４０）に振り分け、２台目の移動端末１宛てのユーザパケットを第２のＲＡＢ（つまり、ベアラ４３）に振り分ける。つまり、２台以上の移動端末１の通信タイミングが偶発的に重なった場合には、参考例５に係る移動通信システムは、一時的に追加のＲＡＢを生成し、転送ノード４においてユーザパケット単位での振り分け処理を実行する。これにより、参考例５に係る移動通信システムは、呼損の発生を抑制しつつ、転送ノード４及び外部ゲートウェイ５においてベアラ維持に要する処理負荷の増加も抑制できる。

　また、参考例５に係るアーキテクチャ及び方法は、同じ移動端末グループに属する２台以上の移動端末１が同時通信を行う場合に、共用ＣＮＢ３０の設定変更、ＣＮＢの追加、及び外部ゲートウェイ５におけるパケットフィルタ（ＴＦＴ）の変更をいずれも必要としない。転送ノード４が、第２のＲＡＢを追加し、ユーザパケット単位での振り分けを行うことで同時通信に対処するためである。したがって、参考例５に係るアーキテクチャ及び方法は、２台以上の移動端末１が同時通信を行う場合に、外部ゲートウェイ５が管理すべきＣＮＢコンテキストの増加を抑制でき、外部ゲートウェイ５の処理負荷を軽減できる。

　参考例５に係るＣＮ２０は、２台目以降の各移動端末１の通信終了に応じて、第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）のＣＮ２０における設定、例えば、移動管理ノード３及び転送ノード４が保持するベアラコンテキスト、を解放してもよい。より具体的に述べると、通常のプリザベーション機能ではＣＮ２０においてベアラコンテキストが維持されるのに対して、参考例５に係るＣＮ２０は、２台目以降の各移動端末１が通信を終了してＩＤＬＥ状態に遷移する際に、第２のＲＡＢに関するＣＮ２０における設定を解放してもよい。なお、共用ＣＮＢ３０に関するコンテキストは、ＣＮ２０において維持される。ＩＤＬＥ状態に遷移した移動端末１の次の通信では、他に通信中の端末が存在しなければ、第１のＲＡＢ（ベアラ４０及び無線ベアラ５０）及び共用ＣＮＢ３０が使用される。

　続いて以下では、参考例５を実現するための処理手順の詳細について説明する。図２８は、参考例５に係る移動管理ノードの動作例を示すフローチャートである。ステップＳ３１～Ｓ３３における処理は、図１５に示した参考例３に関するステップＳ１１～Ｓ１３と同様であるから説明を省略する。ベアラ復旧要求の送信元端末と同じ移動端末グループに属し且つ同じ基地局２に接続する他の移動端末（ＵＥ）１が通信中であると判定された場合（ステップＳ３２でＮＯ）、移動管理ノード３（制御部３０１）は、ベアラ確立手順を実行して第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）を新たに作成し、この追加データベアラを移動端末１に割り当てるように、移動端末１、基地局２、転送ノード４、及び外部ゲートウェイ５を制御する（ステップＳ３４）。

　図２９は、参考例５に係る外部ゲートウェイ５のベアラ管理表の一例を示している。図２９のベアラ管理表は、図７に示した参考例２に係るベアラ管理表と同一である。参考例５では、２つの移動端末１が同時に通信を行う際の追加ベアラは第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）のみであり、ＣＮＢの追加は必要ではない。したがって、外部ゲートウェイ５のベアラ管理表の更新は必要ではない。

　図３０は、参考例５に係る転送ノード４のベアラ管理表の一例を示している。図３０の対応表は、共用ＣＮＢ３０を流れるユーザパケットフロー（Service Data Flow（ＳＤＦ）とも呼ばれる）を識別するために、端末ＩＰアドレス又は端末グループＩＰアドレス帯域を示すカラムが追加されている。図３０の例では、ユーザパケットフローは、端末ＩＰアドレス（又は端末グループＩＰアドレス帯域）、外部ゲートウェイ５のＩＰアドレス、及びＣＮＢ識別子によって特定される。さらに、図３０の例では、第２の移動端末１に関するパケットフローと第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）の対応関係を示す第３のエントリが追加されている。具体的には、第２の移動端末１のＩＰｖ６アドレス“2001:DB8:1:1::/64”、外部ゲートウェイ５のＩＰｖ４アドレス“10.0.0.1”、及びＣＮＢ識別子“00001”によって特定されるユーザパケットフローが、基地局２のＩＰｖ４アドレス“10.0.1.1”及びＲＡＢ識別子“0002”によって特定される第２のＲＡＢ（ベアラ４２）と対応付けられている。

　転送ノード４は、図３０の管理表を用いて最長一致（Longest matching）を行うことによって、ユーザパケットを振り分けるＲＡＢを決定すればよい。これにより、転送ノード４は、ＩＰｖ６アドレス“2001:DB8:1:1::/64”を割り当てられた２台目の移動端末１のユーザパケットを第１のＲＡＢ（ベアラ４０及び無線ベアラ５０）ではなく第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）に振り分けることができる。

　続いて以下では、参考例５に係る第２のＲＡＢの確立手順の具体例を説明する。図３１Ａ及び図３１Ｂのシーケンス図は、２台目以降の移動端末１からのベアラ確立要求に応答して第２のＲＡＢを生成する例を示している。図３１ＡのステップＳ１４０１～Ｓ１４０５における処理は、図１１に示したステップＳ６０１～Ｓ６０５と同様である。図３１ＡのステップＳ１４０４では、移動管理ノード３は、ベアラ確立要求の送信元の移動端末１が属する移動端末グループに関して現在通信中の移動端末１が存在することを判定する。この後、図１１に示した参考例では、移動管理ノード３はベアラ確立を拒否する。これに対して、図３１Ａに示す参考例５では、移動管理ノード３は、追加の第２ＲＡＢ（ベアラ４３及び無線ベアラ５３）を生成するためにベアラ確立要求を転送ノード４に送信する（ステップＳ１４０６）。ステップＳ１４０６でのベアラ確立要求は、ベアラ４３の追加生成を転送ノード４に要求するとともに、第２の移動端末に関するユーザパケットフローとベアラ４３を関連付けて管理することを転送ノード４に要求する。したがって、ステップＳ１４０６でのベアラ確立要求は、２台目の移動端末１に割り当てたＩＰアドレス、及びベアラ共用情報を含めばよい。ここでのベアラ共用情報は、例えば、共用ＣＮＢ３０の識別子であってもよい。

　ステップＳ１４０７では、転送ノード４は、ベアラ確立要求の受信に応答して、第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）に関するエントリをベアラ管理表に追加し、共用ＣＮＢ３０で転送される２台目の移動端末１のパケットフローに第２のＲＡＢを関連付ける。そして、転送ノード４は、ベアラ確立応答を移動管理ノード３に返信する。その後のステップＳ１４０８～Ｓ１４１３における処理は、通常のデータベアラの確立手順、例えば非特許文献１のセクション5.3.1 “Attach procedure” に記載されている手順、と同様とすればよい。

　続いて、参考例５に係るベアラ復旧手順の具体例について図３２Ａ及び図３２Ｂを用いて説明する。図３２ＡのステップＳ１５０１～Ｓ１５０３における処理は、参考例２に係る図１３のステップＳ８０１～Ｓ８０３と同様である。図３２ＡのステップＳ１５０３では、移動管理ノード３は、ベアラ復旧要求の送信元の移動端末１と同じ基地局２に接続し且つ同じ移動端末グループに属する他の移動端末が通信中であることを判定する。この後、図１３に示した参考例２では、移動管理ノード３は、ベアラ復旧を拒否する。これに対して、図３２Ａ及び図３２Ｂに示す参考例５では、移動管理ノード３は、ベアラ確立要求を転送ノード４に送信する（ステップＳ１５０４）。ステップＳ１５０４でのベアラ確立要求は、上述した図３１のステップＳ１４０６でのベアラ確立要求と同様の役割を果たす。ステップＳ１５０４でのベアラ確立要求は、２台目の移動端末１に割り当てたＩＰアドレス、及びベアラ共用情報を含めばよい。ここでのベアラ共用情報は、例えば、共用ＣＮＢ３０の識別子であってもよい。

　ステップＳ１５０５では、転送ノード４は、ベアラ確立要求の受信に応答して、第２のＲＡＢ（ベアラ４３及び無線ベアラ５３）に関するエントリをベアラ管理表に追加し、共用ＣＮＢ３０で転送される２台目の移動端末１のパケットフローに第２のＲＡＢを関連付ける。そして、転送ノード４は、ベアラ確立応答を移動管理ノード３に返信する。その後のステップＳ１５０６～Ｓ１５１０における処理は、通常のベアラ復旧手順、例えば非特許文献１のセクション5.3.4 “Service Request procedure” に記載されている手順、と同様とすればよい。

（改良Ａ）
　本件発明者は、上述した参考例１～５の更なる改良を得た。以下では、発明者によって得られた改良Ａ及び改良Ｂについて順に説明する。本実施形態では、改良Ａについて説明し、第２の実施形態において改良Ｂを説明する。

　改良Ａは、上述した参考例１～５に関する。改良Ａに係る移動通信システムの構成例は、図１、図１４、図２０、及び図２７に示した参考例１～５の構成例と同様である。改良Ａにおいて、移動管理ノード３（制御部３０１）は、参考例１～５で説明したのと同様に、移動端末グループに属する複数の移動端末１のユーザパケット転送のために共用される共用ＣＮＢ３０の管理を行う。

　図１、図１４、図２０、及び図２７の構成例には示されていないが、移動通信システムは、一般的に複数の転送ノード４を含む。移動管理ノード３は、移動端末１からのベアラ確立要求（e.g. ＥＰＳにおけるattach request、ＵＭＴＳにおけるActivate PDP Context Request）に応答して、ベアラを確立するべき転送ノードを選択する。いずれかの転送ノード４において既に共用ＣＮＢ３０が設定されているときに、移動管理ノード３が他の転送ノード４を選択すると、共用ＣＮＢ３０の利用効果が低下する。したがって、改良Ａに係る移動管理ノード３（制御部３０１）は、複数の転送ノード４のうちの第１の転送ノードと外部ゲートウェイ５の間に既に共用ＣＮＢ３０が設定されている間に移動端末グループに属する第１の移動端末から新たなベアラ確立要求を受信した場合に、既に共用ＣＮＢを設定済みの第１の転送ノードを第１の移動端末のために選択するよう動作する。第１の転送ノード４を選択した後、移動管理ノード３は、参考例１～５において説明した同一移動端末グループ内の２台目以降の移動端末１のためのベアラ確立手順又はベアラ修正手順（例えば、図５Ａ及び５Ｂ、又は図１０Ａ及び１０Ｂ）を実行すればよい。これにより、共用ＣＮＢ３０を設定済みの転送ノード４が移動管理ノード３によって優先的に選択される。したがって、改良Ａは、共用ＣＮＢ３０の利用効果を向上に寄与できる。

　図３３は、改良Ａに係る移動管理ノード３の転送ノード選択動作の一例を示すフローチャートである。ステップＳ４１では、移動管理ノード３は、共用ＣＮＢ３０を設定済みの移動端末グループに属する移動端末１からベアラ確立要求を受信する。ステップＳ４２では、移動管理ノード３は、設定済みの共用ＣＮＢ３０を終端している（設定している）転送ノード４を選択する。ステップＳ４３では、移動管理ノード３は、ＣＮＢの確立要求又は共用ＣＮＢ３０の修正要求を示す制御メッセージを、ステップＳ４２にて選択された転送ノード４に送信する。

　一例において、移動管理ノード３による転送ノード４の選択は、domain name system（ＤＮＳ）を利用して行われてもよい。ＤＮＳを利用する場合、例えば、移動端末グループ識別子を含むFully Qualified Domain Name（ＦＱＤＮ）を転送ノード４のＩＰアドレスを関連付けたＤＮＳエントリを設定しておけばよい。移動管理ノード３は、移動端末グループ識別子を含むＦＱＤＮをＤＮＳに問合せることで、１つの移動端末グループに対して同一の転送ノード４を選択することができる。

＜第２の実施形態＞
　本実施形態では、改良Ｂについて説明する。

（改良Ｂ）
　改良Ｂは、上述した参考例２～５に関する。改良Ｂに係る移動通信システムの構成例は、図１、図１４、図２０、及び図２７に示した参考例２～５の構成例と同様である。なお、図１、図１４、図２０、及び図２７の構成例には示されていないが、移動通信システムは、一般的に複数の移動管理ノード３を含む。したがって、改良Ｂは、異なる移動管理ノード３に帰属する複数の移動端末１が１つの共用ＣＮＢ３０を利用可能なアーキテクチャ及び方法を提供する。

　参考例２～５は、外部ゲートウェイ５が移動端末グループへのユーザプレーン・アドレス帯域の払い出しを行い、移動管理ノード３が各移動端末１へのユーザプレーン・アドレス（e.g. ＩＰアドレス）の割り当てを行うアーキテクチャを採用した。また、参考例２～５は、移動管理ノード３が共用ＣＮＢの利用状況を管理するアーキテクチャを示した。しかしながら、異なる移動管理ノード３が１つの共用ＣＮＢ３０を扱う場合、移動端末グループのＩＰアドレス管理と、共用ＣＮＢ３０の使用状況の管理をどこに配置するかが問題となる。以下では、ＩＰアドレスの管理及び共用ＣＮＢ３０の管理の配置に関する４つの例（つまり、改良Ｂ－１、改良Ｂ－２、改良Ｂ－３、及び改良Ｂ－４）について説明する。

　改良Ｂ－１では、加入者情報データベース６が移動端末グループのＩＰアドレス管理と共用ＣＮＢ３０の使用状況の管理を共に担う。図３４は、改良Ｂ－１に係るＩＰアドレスの管理及び共用ＣＮＢ３０の管理の配置を示す構成例である。図３４の構成例では、１つの移動端末グループに属する複数の移動端末１は、複数の基地局２Ａ及び２Ｂを介してＣＮ２０に接続する。移動管理ノード３Ａ及び３Ｂは、１つの移動端末グループに関する１つの共用ＣＮＢ３０を管理する。すなわち、移動管理ノード３Ａ及び３Ｂは、移動端末１からのベアラ確立要求又はベアラ復旧要求を受信した際に、移動端末１へのＩＰアドレスの割り当て、及び共用ＣＮＢ３０においていずれかの移動端末１が通信中であるかの問い合わせのために、加入者情報データベース６と通信する。

　改良Ｂ－２では、加入者情報データベース６が移動端末グループのＩＰアドレス管理を行い、転送ノード４が共用ＣＮＢ３０の使用状況の管理を行う。図３５は、改良Ｂ－２に係るＩＰアドレスの管理及び共用ＣＮＢ３０の管理の配置を示す構成例である。移動管理ノード３Ａ及び３Ｂは、移動端末１からのベアラ確立要求を受信した際に、移動端末１へのＩＰアドレスの割り当てのために、加入者情報データベース６と通信する。また、移動管理ノード３Ａ及び３Ｂは、移動端末１からのベアラ確立要求又はベアラ復旧要求を受信した際に、共用ＣＮＢ３０においていずれかの移動端末１が通信中であるかの問い合わせのために、転送ノード４と通信する。

　改良Ｂ－３では、外部ゲートウェイ５が移動端末グループのＩＰアドレス管理を行い、転送ノード４が共用ＣＮＢ３０の使用状況の管理を行う。図３６は、改良Ｂ－３に係るＩＰアドレスの管理及び共用ＣＮＢ３０の管理の配置を示す構成例である。移動管理ノード３Ａ及び３Ｂは、移動端末１からのベアラ確立要求を受信した際に、移動端末１へのＩＰアドレスの割り当てのために、転送ノード４を介して外部ゲートウェイ５と通信する。また、移動管理ノード３Ａ及び３Ｂは、移動端末１からのベアラ確立要求又はベアラ復旧要求を受信した際に、共用ＣＮＢ３０においていずれかの移動端末１が通信中であるかの問い合わせのために、転送ノード４と通信する。

　改良Ｂ－４では、外部ゲートウェイ５が移動端末グループのＩＰアドレス管理を行い、加入者情報データベース６が共用ＣＮＢ３０の使用状況の管理を行う。図３７は、改良Ｂ－２に係るＩＰアドレスの管理及び共用ＣＮＢ３０の管理の配置を示す構成例である。移動管理ノード３Ａ及び３Ｂは、移動端末１からのベアラ確立要求を受信した際に、移動端末１へのＩＰアドレスの割り当てのために、転送ノード４を介して外部ゲートウェイ５と通信する。また、移動管理ノード３Ａ及び３Ｂは、移動端末１からのベアラ確立要求又はベアラ復旧要求を受信した際に、共用ＣＮＢ３０においていずれかの移動端末１が通信中であるかの問い合わせのために、加入者情報データベース６と通信する。

　改良Ｂ－１～Ｂ－４によれば、複数の移動管理ノード３が共に直接的に又は他のノードを介して間接的にアクセス可能な１又は複数のノード（つまり、加入者情報データベース６、転送ノード４、若しくは外部ゲートウェイ５、又はこれらの組み合わせ）において、移動端末グループのＩＰアドレス管理及び共用ＣＮＢ３０の使用状況の管理が行われる。したがって、移動管理ノード３（例えばノード３Ａ）は、他の移動管理ノード３（例えば、ノード３Ｂ）に帰属する移動端末１に割り当て済みのＩＰアドレスを自身に帰属する移動端末１に重複して割り当ててしまう不具合を回避できる。また、移動管理ノード３（例えばノード３Ａ）は、他の移動管理ノード３（例えば、ノード３Ｂ）に帰属する移動端末１が共用ＣＮＢ３０において通信中であるかを把握できない不具合を回避できる。

　なお、改良Ｂ－１は、転送ノード４及び外部ゲートウェイ５における共用ＣＮＢ３０の設定及び修正処理を簡潔な手順で行える利点がある。なぜなら、加入者情報データベース６が移動端末グループのＩＰアドレス管理及び共用ＣＮＢ３０の使用状況管理を行うため、転送ノード４及び外部ゲートウェイ５はこれらの管理を行う必要がなく、ＩＰアドレス払い出し及び共用ＣＮＢ３０の使用状況問い合わせのための信号を転送ノード４又は外部ゲートウェイ５に送る必要がないためである。

　また、改良Ｂ－２及び改良Ｂ－３は、加入者情報データベース６において共用ＣＮＢ３０の使用状況を管理する形態（改良Ｂ－１、改良Ｂ－４）に比べて、共用ＣＮＢ３０を管理するための信号量の増加を抑えることができる利点がある。なぜなら、ベアラ確立（例えば、アタッチ）、ベアラ復旧、デタッチ、ＲＡＢの解放などの手順を実行する際に、移動管理ノード３と転送ノード４の間のシグナリングに基づいて転送ノード４における管理情報を更新すればよいためである。

　また、改良Ｂ－３及び改良Ｂ－４は、加入者情報データベース６において移動端末グループのＩＰアドレスを管理する形態（改良Ｂ－１、改良Ｂ－２）に比べて、ＩＰアドレスの払い出しをＥＰＳ等にて一般的に採用されているアーキテクチャ、つまり外部ゲートウェイ５がＩＰアドレスの払い出しを行うアーキテクチャ、に近づけることができる利点がある。

　続いて以下では、改良Ｂ－１～Ｂ－４におけるベアラ確立手順及びベアラ復旧手順について順に説明する。図３８Ａ及び図３８Ｂのシーケンス図は、改良Ｂ－１に関し、共用ＣＮＢ３０が設定されていないときの移動端末グループ内の最初の移動端末１からの要求に応答して共用ＣＮＢ３０を含むデータベアラを確立する手順を示している。ステップＳ１６０１では、移動端末１は、ベアラ確立要求を送信する。ステップＳ１６０２では、基地局２は、移動端末１から受信したベアラ確立要求を移動管理ノード３に転送する。ベアラ確立要求は、例えば、ＥＰＳにおけるAttach Request、又はＵＭＴＳにおけるActivate PDP Context Requestである。

　ステップＳ１６０３では、移動管理ノード３は、ベアラ確立要求の受信に応答して、移動端末１の認証処理を起動する。認証処理は、加入者情報データベース６へのアクセスを含む。つまり、移動管理ノード３は、ベアラ確立要求の送信元端末の識別子（e.g. International Mobile Subscriber Identity（ＩＭＳＩ））をデータベース６に送信する。既に述べたように、改良Ｂ－１では、加入者情報データベース６が、移動端末グループのＩＰアドレス管理を行う。したがって、加入者情報データベース６は、ベアラ確立要求の送信元端末の識別子（e.g. ＩＭＳＩ）に基づいて当該端末が特定の移動端末グループに属することを判定し、移動端末グループに対してＩＰアドレス帯域を払い出し、移動端末１にＩＰアドレスを払い出す。そして、加入者情報データベース６は、加入者情報を移動管理ノード３に送信する。ここで、加入者情報は、端末グループ情報、ＩＰアドレス帯域、及び移動端末１のＩＰアドレスを含む。

　なお、移動端末グループに対して予めＩＰアドレス帯域が割り当てられている場合、ステップＳ１６０３において、加入者情報データベース６は、ＩＰアドレス帯域の払い出しを行わなくてよい。

　また、ステップＳ１６０３における加入者情報は、ＩＰアドレス帯域を示さなくてもよい。つまり、加入者情報データベース６は、共用ＣＮＢ３０が既に設定されているか否かを移動管理ノード３に通知できればよい。したがって、ステップＳ１６０３における加入者情報は、共用ＣＮＢ３０が既に設定されているか否かを示す何らかの情報要素を含んでいればよい。当該情報要素の一例は、移動端末グループに割り当てられたＩＰアドレス帯域情報であるが、これに限られない。例えば、ステップＳ１６０３における加入者情報は、移動端末グループに属するいずれかの移動端末１がＣＮ２０に既にアタッチしているか否かを示してもよい。

　ステップＳ１６０４では、移動管理ノード３は、端末グループ情報に基づいて、移動端末１のデータベアラ共用の要否を判断する。ベアラ共用を行う場合、移動管理ノード３は、ベアラ共用が必要であることを示すベアラ確立要求を転送ノード４に送信する（ステップＳ１６０４）。ベアラ確立要求は、例えば、ＥＰＳにおけるCreate Session Request、又はＵＭＴＳにおけるCreate PDP Context Requestである。このベアラ確立要求は、ベアラ共用情報、および加入者情報データベース６から通知された移動端末１のＩＰアドレスを含む。また、このベアラ確立要求は、端末グループに割り当てられたＩＰアドレス帯域を示してもよい。これにより、外部ゲートウェイ５は、移動端末グループ単位（ＩＰアドレス帯域単位）で共用ＣＮＢ３０を管理することができ、図７に示したベアラ管理表と同様にベアラ管理表のエントリ数を削減できる。

　ステップＳ１６０５において、転送ノード４は、移動管理ノード３からのベアラ確立要求の受信に応答して、新たなデータベアラに関するエントリをベアラ管理表に生成し、ベアラ確立要求（ベアラ共用情報を含む）を外部ゲートウェイ５に送信する。ステップＳ１６０６では、外部ゲートウェイ５は、ベアラ共用情報を含むベアラ確立要求の受信に応答して、転送ノード４から受信した転送ノード４側のトンネルエンドポイント識別子、移動端末グループのＩＰアドレス帯域などに基づいて、新たな共用ＣＮＢ３０に関するエントリをベアラ管理表に生成する。さらに、外部ゲートウェイ５は、共用ＣＮＢ３０に適用されるパケットフィルタ（e.g. ＴＦＴ）を更新する。つまり、外部ゲートウェイ５は、通信を行う１台の移動端末１のＩＰアドレスが宛先に指定されたダウンリンク・ユーザパケットのみを共用ＣＮＢ３０に流し、他のＩＰアドレスが宛先に指定されたダウンリンク・ユーザパケットを破棄するようにパケットフィルタを更新すればよい。これにより、外部ゲートウェイ５は、移動端末グループに属する複数の移動端末１のうち実際に通信を行う１台のみに関するユーザパケットを共用ＣＮＢ３０で転送する。

　ステップＳ１６０７では、外部ゲートウェイ５は、ベアラ確立応答を転送ノード４に送信する。このベアラ確立応答は、ＩＰアドレス帯域、及び外部ゲートウェイ５側のトンネルエンドポイント識別子を含む。また、ベアラ確立応答は、データベアラＱｏＳ等の追加情報を含んでもよい。ベアラ確立応答は、例えば、ＥＰＳにおけるCreate Session Response、又はＵＭＴＳにおけるCreate PDP Context Responseである。ステップＳ１６０８では、移動管理ノード３は、加入者情報データベース６における共用ＣＮＢ３０の使用状況管理のために、移動端末グループに対して共用ＣＮＢ３０が設定されて使用開始されたことを加入者情報データベース６に通知する。なお、共用ＣＮＢ３０の使用通知は、例えば、ステップＳ１６０５の後に移動管理ノード３から加入者情報データベース６に送信されてもよい。その後のステップＳ１６０９～Ｓ１６１５における処理は、通常のデータベアラの確立手順、例えば非特許文献１のセクション5.3.1 “Attach procedure” に記載されている手順、と同様とすればよい。

　次に、図３９Ａ及び図３９Ｂについて説明する。図３９Ａ及び図３９Ｂのシーケンス図は、改良Ｂ－１に関し、移動端末グループ内の２台目以降の移動端末１からのベアラ確立要求の処理手順を示している。ステップＳ１７０１及びＳ１７０２における処理は、図３８ＡのステップＳ１６０１及びＳ１６０２における処理と同様である。ステップＳ１７０３では、加入者情報データベース６は、ベアラ確立要求の送信元端末の識別子（e.g. ＩＭＳＩ）に基づいて当該端末が特定の移動端末グループに属することを判定し、移動端末１に対するＩＰアドレスの払い出しを行い、この移動端末グループに対して共用ＣＮＢ３０が設定済みであることを判定し、さらに、移動端末グループに属するいずれかの移動端末１のために共用ＣＮＢ３０が使用中であるかを判定する。そして、加入者情報データベース６は、加入者情報を移動管理ノード３に送信する。ここで、加入者情報は、端末グループ情報、移動端末１のＩＰアドレス、及び共用ＣＮＢ３０の使用状況を含む。

　移動端末グループに対して共用ＣＮＢ３０が設定済みであるか否かは、例えば、移動端末グループに属する少なくとも１つの移動端末１がアタッチ済みであるか否かによって判定してもよい。移動端末グループに属するいずれかの移動端末１のために共用ＣＮＢ３０が使用中であるか否か、言い換えると、移動端末グループに属するいずれかの移動端末１が通信中であるか否かは、例えば、移動端末グループ内にＩＤＬＥ状態（e.g. ECM-IDLE）ではなくＣＯＮＮＥＣＴＥＤ状態（e.g. ECM-CONNECTED）の移動端末１が存在するか否かを判定してもよい。そのために、移動管理ノード３は、移動端末グループ内の移動端末１がＣＯＮＮＥＣＴＥＤ状態（e.g. ECM-CONNECTED）からＩＤＬＥ状態（e.g. ECM-IDLE）に遷移するときに、この状態遷移の発生を加入者情報データベース６に通知すればよい。図３９Ａの例では、ステップＳ１７０４において、移動管理ノード３は、加入者情報データベース６における共用ＣＮＢ３０の使用状況管理のために、共用ＣＮＢ３０の使用を開始することを示す通知を加入者情報データベース６に送信する。

　移動管理ノード３は、加入者情報データベース６から通知された共用ＣＮＢ３０の使用状況を確認し、共用ＣＮＢ３０が未使用であれば共用ＣＮＢ３０を使用するベアラ確立手順を継続すればよい。一方、共用ＣＮＢ３０が使用中である場合、移動管理ノード３は、例えば、ベアラ確立を拒否してもよいし（上述の参考例２又は参考例４に類似）、追加の通常ベアラを設定してもよいし（上述の参考例３に類似）、又は共用ＣＮＢ４０に追加のＲＡＢを対応付けて転送ノードでユーザパケット振り分けを行なってもよい（上述の参考例５に類似）。図３９ＢのステップＳ１７０５～Ｓ１７１１は、共用ＣＮＢ３０が未使用であるときの手順を示している。図３９ＢのステップＳ１７０５～Ｓ１７１１における処理は、参考例２において図１０Ｂに示したステップＳ５０６～Ｓ５１２における処理と同様である。

　次に、図４０について説明する。図４０のシーケンス図は、改良Ｂ－１に関し、データベアラの復旧手順を示している。ステップＳ１８０１では、移動端末１は、ベアラ復旧要求を送信する。ステップＳ１８０２では、基地局２は、移動端末１から受信したベアラ復旧要求を移動管理ノード３に転送する。ベアラ復旧要求は、例えば、ＥＰＳにおけるService Request、又はＵＭＴＳにおけるService Requestである。

　ステップＳ１８０３では、移動管理ノード３は、ベアラ復旧要求の送信元の移動端末１に関して自身が管理しているベアラコンテキストを参照し、送信元の移動端末１が共用ＣＮＢ３０に関連付けられている場合に共用ＣＮＢ３０の使用状況を加入者情報データベース６に問い合わせる。移動管理ノード３は、加入者情報データベース６から通知された共用ＣＮＢ３０の使用状況を確認し、共用ＣＮＢ３０が未使用であれば共用ＣＮＢ３０を使用するベアラ復旧手順を継続すればよい。一方、共用ＣＮＢ３０が使用中である場合、移動管理ノード３は、例えば、ベアラ復旧を拒否してもよいし（上述の参考例２又は参考例４に類似）、追加の通常ベアラを設定してもよいし（上述の参考例３に類似）、又は共用ＣＮＢ４０に追加のＲＡＢを対応付けて転送ノードでユーザパケット振り分けを行なってもよい（上述の参考例５に類似）。

　図４０の例では、ステップＳ１８０４において、移動管理ノード３は、加入者情報データベース６における共用ＣＮＢ３０の使用状況管理のために、共用ＣＮＢ３０の使用を開始することを示す通知を加入者情報データベース６に送信する。図４０のステップＳ１８０５～Ｓ１８１０は、共用ＣＮＢ３０が未使用であるときのベアラ復旧手順を示している。図４０のステップＳ１８０５～Ｓ１８１０における処理は、参考例２において図１２に示したステップＳ７０５～Ｓ７１０における処理と同様である。

　次に、改良Ｂ－２におけるベアラ確立手順及びベアラ復旧手順について説明する。改良Ｂ－２において移動端末グループ内の最初の移動端末１からの要求に応答して共用ＣＮＢ３０を含むデータベアラを確立する手順は、図３８Ａ及び図３８Ｂのシーケンス図を用いて説明した改良Ｂ－１の手順と同様である。

　図４１Ａ及び図４１Ｂのシーケンス図は、改良Ｂ－２に関し、移動端末グループ内の２台目以降の移動端末１からのベアラ確立要求の処理手順を示している。改良Ｂ－２では、共用ＣＮＢ３０の使用状況の確認ステップが改良Ｂ－１（図３９Ａ及び図３９Ｂ）と異なる。図４１ＡのステップＳ１９０１及びＳ１９０２における処理は、図３９ＡのステップＳ１７０１及びＳ１７０２における処理と同様である。ステップＳ１９０３では、加入者情報データベース６は、ベアラ確立要求の送信元端末の識別子（e.g. ＩＭＳＩ）に基づいて当該端末が特定の移動端末グループに属することを判定し、この移動端末グループに対して共用ＣＮＢ３０が設定済みであることを判定する。そして、加入者情報データベース６は、加入者情報を移動管理ノード３に送信する。ここで、加入者情報は、端末グループ情報、及び移動端末１のＩＰアドレスを含む。

　移動管理ノード３は、加入者情報データベース６から通知された端末グループ情報を確認し、共用ＣＮＢ３０が使用中であるか否かを転送ノード４に問い合わせる（ステップＳ１９０４）。ステップＳ１９０５では、転送ノード４は、移動端末グループに属するいずれかの移動端末１のために共用ＣＮＢ３０が使用されているか否かを示す通知を移動管理ノード３に送信する。移動管理ノード３は、共用ＣＮＢ３０の使用状況を示す通知を受信し、移動端末１のためのベアラ設定を制御する。つまり、移動管理ノード３は、共用ＣＮＢ３０が未使用であれば共用ＣＮＢ３０を使用するベアラ確立手順を継続すればよい。一方、共用ＣＮＢ３０が使用中である場合、移動管理ノード３は、例えば、ベアラ確立を拒否してもよいし（上述の参考例２又は参考例４に類似）、追加の通常ベアラを設定してもよいし（上述の参考例３に類似）、又は共用ＣＮＢ４０に追加のＲＡＢを対応付けて転送ノードでユーザパケット振り分けを行なってもよい（上述の参考例５に類似）。図４１ＢのステップＳ１９０６～Ｓ１９１２は、共用ＣＮＢ３０が未使用であるときの手順を示している。図４１ＢのステップＳ１９０６～Ｓ１９１２における処理は、参考例２において図１０Ｂに示したステップＳ５０６～Ｓ５１０における処理と同様である。

　次に、図４２について説明する。図４２のシーケンス図は、改良Ｂ－２に関し、データベアラの復旧手順を示している。改良Ｂ－２では、共用ＣＮＢ３０の使用状況の確認ステップが改良Ｂ－１（図４０）と異なる。図４２のステップＳ２００１及びＳ２００２における処理は、図４０のステップＳ１８０１及びＳ１８０２における処理と同様である。

　ステップＳ２００３では、移動管理ノード３は、ベアラ復旧要求の送信元の移動端末１に関して自身が管理しているベアラコンテキストを参照し、送信元の移動端末１が共用ＣＮＢ３０に関連付けられている場合に共用ＣＮＢ３０の使用状況を転送ノード４に問い合わせる。転送ノード４は、共用ＣＮＢ３０の使用状況を示す通知を移動管理ノード３に送信する（ステップＳ２００４）。移動管理ノード３は、転送ノード４から通知された共用ＣＮＢ３０の使用状況を確認し、共用ＣＮＢ３０が未使用であれば共用ＣＮＢ３０を使用するベアラ復旧手順を継続すればよい。一方、共用ＣＮＢ３０が使用中である場合、移動管理ノード３は、例えば、ベアラ復旧を拒否してもよいし（上述の参考例２又は参考例４に類似）、追加の通常ベアラを設定してもよいし（上述の参考例３に類似）、又は共用ＣＮＢ４０に追加のＲＡＢを対応付けて転送ノードでユーザパケット振り分けを行なってもよい（上述の参考例５に類似）。図４２のステップＳ２００５～Ｓ２０１０は、共用ＣＮＢ３０が未使用であるときのベアラ復旧手順を示している。図４２のステップＳ２００５～Ｓ２０１０における処理は、参考例２において図１２に示したステップＳ７０５～Ｓ７１０における処理と同様である。

　次に、改良Ｂ－３におけるベアラ確立手順及びベアラ復旧手順について説明する。図４３Ａ及び図４３Ｂのシーケンス図は、改良Ｂ－３に関し、共用ＣＮＢ３０が設定されていないときの移動端末グループ内の最初の移動端末１からの要求に応答して共用ＣＮＢ３０を含むデータベアラを確立する手順を示している。図４３ＡのステップＳ２１０１～Ｓ２１０６は、参考例２に関する図９ＡのステップＳ４０１～Ｓ４０６と同様である。

　ステップＳ２１０７では、外部ゲートウェイ５は、移動端末グループに払い出したＩＰアドレス帯域の中から、移動端末１に割り当てる１つのＩＰアドレスを決定する。そして、外部ゲートウェイ５は、転送ノード４から受信した転送ノード４側のトンネルエンドポイント識別子、移動端末グループに払い出したＩＰアドレス帯域、及び移動端末１に払い出したＩＰアドレスなどに基づいて、新たな共用ＣＮＢ３０に関するエントリをベアラ管理表に生成する。さらに、ステップＳ２１０８では、外部ゲートウェイ５は、共用ＣＮＢ３０に適用されるパケットフィルタ（e.g. ＴＦＴ）を更新する。つまり、外部ゲートウェイ５は、通信を行う１台の移動端末１のＩＰアドレスが宛先に指定されたダウンリンク・ユーザパケットのみを共用ＣＮＢ３０に流し、他のＩＰアドレスが宛先に指定されたダウンリンク・ユーザパケットを破棄するようにパケットフィルタを更新すればよい。これにより、外部ゲートウェイ５は、移動端末グループに属する複数の移動端末１のうち実際に通信を行う１台のみに関するユーザパケットを共用ＣＮＢ３０で転送する。

　ステップＳ２１０９では、外部ゲートウェイ５は、ベアラ確立応答を転送ノード４に送信する。このベアラ確立応答は、移動端末１に払い出したＩＰアドレス、及び外部ゲートウェイ５側のトンネルエンドポイント識別子を含む。また、ベアラ確立応答は、データベアラＱｏＳ等の追加情報を含んでもよい。ベアラ確立応答は、例えば、ＥＰＳにおけるCreate Session Response、又はＵＭＴＳにおけるCreate PDP Context Responseである。その後のステップＳ２１１０～Ｓ２１１６における処理は、通常のデータベアラの確立手順、例えば非特許文献１のセクション5.3.1 “Attach procedure” に記載されている手順、と同様とすればよい。

　次に、図４４Ａ及び図４４Ｂについて説明する。図４４Ａ及び図４４Ｂのシーケンス図は、改良Ｂ－３に関し、移動端末グループ内の２台目以降の移動端末１からのベアラ確立要求の処理手順を示している。ステップＳ２２０１～Ｓ２２０４における処理は、図４３ＡのステップＳ２１０１～Ｓ２１０４における処理と同様である。ステップＳ２２０５では、転送ノード４は、ベアラ共用情報に基づいてこの移動端末グループに対して共用ＣＮＢ３０が設定済みであることを判定し、さらに、移動端末グループに属するいずれかの移動端末１のために共用ＣＮＢ３０が使用中であるかを判定する。

　共用ＣＮＢ３０が使用中であるか否か、言い換えると、移動端末グループに属するいずれかの移動端末１が通信中であるか否かは、例えば、転送ノード４のベアラ管理表において共用ＣＮＢ３０が有効なベアラ４０（e.g. S１ベアラ）と対応付けられているか否かによって判定してもよい。そのために、移動管理ノード３は、移動端末グループ内の移動端末１がＣＯＮＮＥＣＴＥＤ状態（e.g. ECM-CONNECTED）からＩＤＬＥ状態（e.g. ECM-IDLE）に遷移するときに、この状態遷移の発生を転送ノード４に通知すればよい。

　転送ノード４は、共用ＣＮＢ３０が未使用であれば共用ＣＮＢ３０を使用するベアラ確立手順を継続すればよい。一方、共用ＣＮＢ３０が使用中である場合、転送ノード４は、例えば、ベアラ確立の拒否を移動管理ノード３に返信してもよいし（上述の参考例２又は参考例４に類似）、追加の通常ＣＮＢを設定してもよいし（上述の参考例３に類似）、又は共用ＣＮＢ４０に追加のＲＡＢを対応付けて転送ノードでユーザパケット振り分けを行なってもよい（上述の参考例５に類似）。図４４Ａ及び図４４ＢのステップＳ２２０６～Ｓ２２１６は、共用ＣＮＢ３０が未使用であるときの手順を示している。ステップＳ２２０６では、転送ノード４は、ベアラ共用情報を含むベアラ確立要求を外部ゲートウェイ５に送信する。なお、共用ＣＮＢ３０は既に設定済みであるから、共用ＣＮＢ３０のコンテキスト（e.g. ＴＥＩＤ、ベアラＱｏＳ）に変更がなければ、ステップＳ２２０６のベアラ確立要求は、これらのコンテキストを示す情報要素が省略されてもよい。代わりに、ステップＳ２２０６のベアラ確立要求は、移動端末１へのＩＰアドレスの払い出し要求を示してもよい。

　ステップＳ２２０７では、外部ゲートウェイ５は、移動端末グループに払い出したＩＰアドレス帯域の中から、移動端末１に割り当てる１つのＩＰアドレスを決定する。ステップＳ２２０８では、外部ゲートウェイ５は、共用ＣＮＢ３０に適用されるパケットフィルタ（e.g. ＴＦＴ）を更新する。つまり、外部ゲートウェイ５は、通信を行う１台の移動端末１のＩＰアドレスが宛先に指定されたダウンリンク・ユーザパケットのみを共用ＣＮＢ３０に流し、他のＩＰアドレスが宛先に指定されたダウンリンク・ユーザパケットを破棄するようにパケットフィルタを更新すればよい。図４４ＢのステップＳ２２０９～Ｓ２２１６における処理は、図４３ＢのステップＳ２２０９～Ｓ２２１６における処理と同様である。

　改良Ｂ－３におけるデータベアラ復旧手順は、図４２のシーケンス図を用いて説明した改良Ｂ－２のデータベアラ復旧手順と同様である。

　次に、改良Ｂ－４におけるベアラ確立手順及びベアラ復旧手順について説明する。改良Ｂ－４において移動端末グループ内の最初の移動端末１からの要求に応答して共用ＣＮＢ３０を含むデータベアラを確立する手順は、図４３Ａ及び図４３Ｂのシーケンス図を用いて説明した改良Ｂ－１の手順と同様である。

　図４５Ａ及び図４５Ｂのシーケンス図は、改良Ｂ－４に関し、移動端末グループ内の２台目以降の移動端末１からのベアラ確立要求の処理手順を示している。ステップＳ２３０１及びＳ２３０２における処理は、例えば、改良Ｂ－１の図３９ＡにおけるステップＳ１７０１及びＳ１７０２と同様である。ステップＳ２３０３では、加入者情報データベース６は、ベアラ確立要求の送信元端末の識別子（e.g. ＩＭＳＩ）に基づいて当該端末が特定の移動端末グループに属することを判定し、この移動端末グループに対して共用ＣＮＢ３０が設定済みであることを判定し、さらに、移動端末グループに属するいずれかの移動端末１のために共用ＣＮＢ３０が使用中であるかを判定する。そして、加入者情報データベース６は、加入者情報を移動管理ノード３に送信する。ここで、加入者情報は、端末グループ情報、及び共用ＣＮＢ３０の使用状況を含む。

　移動管理ノード３は、加入者情報データベース６から通知された共用ＣＮＢ３０の使用状況を確認し、共用ＣＮＢ３０が未使用であれば共用ＣＮＢ３０を使用するベアラ確立手順を継続すればよい。一方、共用ＣＮＢ３０が使用中である場合、移動管理ノード３は、例えば、ベアラ確立を拒否してもよいし（上述の参考例２又は参考例４に類似）、追加の通常ベアラを設定してもよいし（上述の参考例３に類似）、又は共用ＣＮＢ４０に追加のＲＡＢを対応付けて転送ノードでユーザパケット振り分けを行なってもよい（上述の参考例５に類似）。

　図４５Ａ及び図４５ＢのステップＳ２３０４～Ｓ２３１６は、共用ＣＮＢ３０が未使用であるときの手順を示している。ステップＳ２３０４では、移動管理ノード３は、ベアラ共用情報を含むベアラ確立要求を転送ノード４に送信する。ステップＳ２３０５では、転送ノード４は、ベアラ確立要求を外部ゲートウェイ５に送信する。ステップＳ２３０６～Ｓ２３０９、及びＳ２３１１～Ｓ２３１６における処理は、改良Ｂ－３に関して図４４Ａ及び図４４Ｂに示したステップＳ２２０７～Ｓ２２１６における処理と同様である。図４５ＢのステップＳ２３１０では、移動管理ノード３は、加入者情報データベース６における共用ＣＮＢ３０の使用状況管理のために、共用ＣＮＢ３０の使用を開始することを示す通知を加入者情報データベース６に送信する。

　改良Ｂ－４におけるデータベアラ復旧手順は、図４０のシーケンス図を用いて説明した改良Ｂ－１のデータベアラ復旧手順と同様である。

　上述した改良Ｂ－３及び改良Ｂ－４において、移動端末グループのＩＰアドレス管理は、外部ゲートウェイ５に接続されたサーバ（例えば、Remote Authentication Dial In User Service（ＲＡＤＩＵＳ）サーバ）において行われてもよい。この場合、外部ゲートウェイ５は、サーバ（e.g. ＲＡＤＩＵＳサーバ）と通信し、移動端末グループへのＩＰアドレス帯域の払い出し及び各移動端末１へのＩＰアドレスの払い出しを要求し、移動端末グループのＩＰアドレス帯域及び各移動端末１へのＩＰアドレスをサーバから受信すればよい。

　また、上述した改良Ｂ－１及びＢ－４は、共用ＣＮＢ３０の使用状況管理が加入者情報データベース６に配置されている点において、参考例２～５において説明した通信管理ユニット７が加入者情報データベース６に配置されている形態であると言うことができる。

＜その他の実施形態＞
　第１及び第２の実施形態は、適宜組み合わせて実施されてもよい。

　第１及び第２の実施形態において説明した参考例１～５、並びに改良Ａ及びＢにおける移動端末１、基地局２、移動管理ノード３、転送ノード４、外部ゲートウェイ５、及び加入者情報データベース６等の処理及び動作は、少なくとも１つのプロセッサを含むコンピュータシステムにプログラムを実行させることによって実現されてもよい。具体的には、シーケンス図及びフローチャート等を用いて説明したベアラ制御等の動作に関するアルゴリズムをコンピュータシステムに行わせるための命令群を含む１又は複数のプログラムをコンピュータシステムに供給すればよい。

　これらのプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ－ＲＯＭ（Read Only Memory）、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

　また、上述した第１及び第２の実施形態では、主にＥＰＳ及びＵＭＴＳに関する具体例を用いて説明した。しかしながら、第１及び第２の実施形態に係る移動通信システムは、その他の移動通信システムであってもよい。

　さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

　上述した実施形態に示された技術思想は、例えば、以下の付記のように記載することもできる。

（付記Ａ１）
　移動管理ノード、複数の転送ノード、及び外部ゲートウェイを含むコアネットワークを備え、
　前記移動管理ノードは、移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）の管理を行うよう構成され、
　前記共用ＣＮＢの前記管理は、前記共用ＣＮＢが前記複数の転送ノードのうちの第１の転送ノードと前記外部ゲートウェイの間に既に設定されている間に前記移動端末グループに属する第１の移動端末から新たなベアラ確立要求を受信した場合に、前記第１の転送ノードを前記第１の移動端末のために選択することを含む、
移動通信システム。
（付記Ａ２）
　前記共用ＣＮＢの前記管理は、前記第１の移動端末のためのベアラの確立要求または前記共用ＣＮＢの修正要求を示す制御メッセージを前記第１の転送ノードに送信することをさらに含む、付記Ａ１に記載の移動通信システム。
（付記Ａ３）
　コアネットワークに配置される移動管理ノードであって、
　移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）の管理を行う制御部を備え、
　前記共用ＣＮＢの前記管理は、前記共用ＣＮＢが前記コアネットワーク内の複数の転送ノードのうちの第１の転送ノードと外部ゲートウェイの間に既に設定されている間に前記移動端末グループに属する第１の移動端末から新たなベアラ確立要求を受信した場合に、前記第１の転送ノードを前記第１の移動端末のために選択することを含む、
制御装置。
（付記Ａ４）
　前記共用ＣＮＢの前記管理は、前記第１の移動端末のためのベアラの確立要求または前記共用ＣＮＢの修正要求を示す制御メッセージを前記第１の転送ノードに送信することをさらに含む、付記Ａ３に記載の制御装置。
（付記Ａ５）
　コアネットワークに配置される移動管理ノードにおける通信制御方法であって、
　移動端末グループに属する第１の移動端末からのベアラ確立要求に応答して、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）を、前記コアネットワーク内の複数の転送ノードのうちの第１の転送ノードと外部ゲートウェイの間に設定するよう前記コアネットワークを制御すること、及び
　前記第１の転送ノードと前記外部ゲートウェイの間に前記共用ＣＮＢが既に設定されている間に前記移動端末グループに属する第２の移動端末から新たなベアラ確立要求を受信した場合に、前記第１の転送ノードを前記第２の移動端末のために選択すること、
を備える、通信制御方法。
（付記Ａ６）
　前記第２の移動端末のためのベアラの確立要求または前記共用ＣＮＢの修正要求を示す制御メッセージを前記第１の転送ノードに送信することをさらに備える、
付記Ａ５に記載の通信制御方法。
（付記Ａ７）
　コアネットワークに配置される移動管理ノードにおける通信制御方法をコンピュータに行わせるためのプログラムであって、
　前記通信制御方法は、
　移動端末グループに属する第１の移動端末からのベアラ確立要求に応答して、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）を、前記コアネットワーク内の複数の転送ノードのうちの第１の転送ノードと外部ゲートウェイの間に設定するよう前記コアネットワークを制御すること、及び
　前記第１の転送ノードと前記外部ゲートウェイの間に前記共用ＣＮＢが既に設定されている間に前記移動端末グループに属する第２の移動端末から新たなベアラ確立要求を受信した場合に、前記第１の転送ノードを前記第２の移動端末のために選択すること、
を含む、
プログラム。

（付記Ｂ１）
　加入者サーバ、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを備え、
　前記加入者サーバは、移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記移動管理ノードに通知し、
　前記移動管理ノードは、前記ユーザプレーン・アドレスに対応するユーザパケットが共用コアネットワークベアラ（ＣＮＢ）において転送されるよう前記共用ＣＮＢの設定を制御し、
　前記共用ＣＮＢは、前記転送ノードと前記外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
移動通信システム。
（付記Ｂ２）
　前記加入者サーバは、前記共用ＣＮＢが既に設定されているか否かを前記移動管理ノードにさらに通知する、付記Ｂ１に記載の移動通信システム。
（付記Ｂ３）
　前記共用ＣＮＢが既に設定されているか否かの通知は、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域を前記移動管理ノードに通知するか否かによって行われる、付記Ｂ２に記載の移動通信システム。
（付記Ｂ４）
　前記共用ＣＮＢが既に設定されているか否かの通知は、前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを前記移動管理ノードに通知することにより行われる、付記Ｂ２に記載の移動通信システム。
（付記Ｂ５）
　前記移動管理ノードは、前記移動端末グループに属する第１の移動端末からのアタッチ要求を契機として、前記第１の移動端末のユーザプレーン・アドレス、及び前記共用ＣＮＢが既に設定されているか否かの通知を前記加入者サーバから受信する、付記Ｂ１～Ｂ４のいずれか１項に記載の移動通信システム。
（付記Ｂ６）
　前記移動管理ノードは、前記共用ＣＮＢが既に設定されている間に前記第１の移動端末からの前記アタッチ要求を受信した場合に、前記第１の移動端末のユーザプレーン・アドレスを含み且つ前記共用ＣＮＢの修正要求を示す制御メッセージを前記転送ノードに送信する、付記Ｂ５に記載の移動通信システム。
（付記Ｂ７）
　前記加入者サーバは、前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを前記移動管理ノードにさらに通知する、付記Ｂ１～Ｂ６のいずれか１項に記載の移動通信システム。
（付記Ｂ８）
　加入者サーバ、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークにおける通信制御方法であって、
　前記加入者サーバによって、移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記移動管理ノードに通知すること、及び
　前記前記移動管理ノードによって、前記ユーザプレーン・アドレスに対応するユーザパケットが共用コアネットワークベアラ（ＣＮＢ）において転送されるよう前記共用ＣＮＢの設定を制御すること、
を備え、
　前記共用ＣＮＢは、前記転送ノードと前記外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
通信制御方法。
（付記Ｂ９）
　前記加入者サーバによって、前記共用ＣＮＢが既に設定されているか否かを前記移動管理ノードに通知することをさらに備える、付記Ｂ８に記載の通信制御方法。
（付記Ｂ１０）
　前記共用ＣＮＢが既に設定されているか否かの通知は、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域を通知するか否かによって行われる、付記Ｂ９に記載の通信制御方法。
（付記Ｂ１１）
　前記共用ＣＮＢが既に設定されているか否かの通知は、前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを通知することにより行われる、付記Ｂ９に記載の通信制御方法。
（付記Ｂ１２）
　前記ユーザプレーン・アドレスを通知すること及び前記共用ＣＮＢが既に設定されているか否かを通知することは、前記移動端末グループに属する第１の移動端末からのアタッチ要求を契機として、前記第１の移動端末のユーザプレーン・アドレス、及び前記共用ＣＮＢが既に設定されているか否かの通知を前記移動管理ノードにおいて前記加入者サーバから受信することを含む、付記Ｂ８～Ｂ１１のいずれか１項に記載の通信制御方法。
（付記Ｂ１３）
　前記制御することは、前記共用ＣＮＢが既に設定されている間に前記第１の移動端末からの前記アタッチ要求を受信した場合に、前記第１の移動端末のユーザプレーン・アドレスを含み且つ前記共用ＣＮＢの修正要求を示す制御メッセージを前記移動管理ノードから前記転送ノードに送信することを含む、付記Ｂ１２に記載の通信制御方法。
（付記Ｂ１４）
　前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを前記加入者サーバから前記移動管理ノードに通知することをさらに備える、付記Ｂ８～Ｂ１３のいずれか１項に記載の通信制御方法。
（付記Ｂ１５）
　コアネットワークに配置される加入者サーバであって、
　移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記コアネットワーク内の移動管理ノードに通知すると共に、前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを前記移動管理ノードに通知するアドレス管理部を備える、
加入者サーバ。
（付記Ｂ１６）
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かの通知は、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域を通知するか否かによって行われる、付記Ｂ１５に記載の加入者サーバ。
（付記Ｂ１７）
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かの通知は、共用コアネットワークベアラ（ＣＮＢ）が既に設定されているか否かを通知することによって行われ、
　前記共用ＣＮＢは、前記コアネットワーク内の転送ノードと外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
付記Ｂ１５又はＢ１６に記載の加入者サーバ。
（付記Ｂ１８）
　前記アドレス管理部は、前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを前記移動管理ノードにさらに通知する、付記Ｂ１５～Ｂ１７のいずれか１項に記載の加入者サーバ。
（付記Ｂ１９）
　コアネットワークに配置される加入者サーバにおける通信制御方法であって、
　移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記コアネットワーク内の移動管理ノードに通知すること、及び
前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを前記移動管理ノードに通知すること、
を備える、通信制御方法。
（付記Ｂ２０）
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かの通知は、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域を通知するか否かによって行われる、付記Ｂ１９に記載の通信制御方法。
（付記Ｂ２１）
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かの通知は、共用コアネットワークベアラ（ＣＮＢ）が既に設定されているか否かを通知することによって行われ、
　前記共用ＣＮＢは、前記コアネットワーク内の転送ノードと外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
付記Ｂ１９又はＢ２０に記載の通信制御方法。
（付記Ｂ２２）
　前記移動端末グループに属するいずれかの移動端末によって前記共用ＣＮＢが使用中であるか否かを前記移動管理ノードに通知することをさらに備える、付記Ｂ１９～Ｂ２１のいずれか１項に記載の通信制御方法。
（付記Ｂ２３）
　コアネットワークに配置される加入者サーバにおける通信制御方法をコンピュータに行わせるためのプログラムであって、
　前記通信制御方法は、
　移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記コアネットワーク内の移動管理ノードに通知すること、及び
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを前記移動管理ノードに通知すること、
を含む、
プログラム。

（付記Ｃ１）
　移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを備え、
　前記移動管理ノードは、移動端末グループに属する第１の移動端末からの要求に応答して、共用コアネットワークベアラ（ＣＮＢ）を前記第１の移動端末のために設定するよう前記転送ノードに要求メッセージを送信し、前記共用ＣＮＢは、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用されるコアネットワークベアラであり、
　前記外部ゲートウェイは、前記要求メッセージに基づく制御メッセージを前記転送ノードから受信し、前記第１の移動端末にユーザプレーン・アドレスを割り当てるとともに、前記ユーザプレーン・アドレスが宛先に指定されたユーザパケットを前記共用ＣＮＢに流すためのパケットフィルタを設定する、
移動通信システム。
（付記Ｃ２）
　前記外部ゲートウェイは、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域の中から前記第１の移動端末に割り当てる前記ユーザプレーン・アドレスを決定する、付記Ｃ１に記載の移動通信システム。
（付記Ｃ３）
　前記外部ゲートウェイは、前記制御メッセージを受信した際に前記共用ＣＮＢが未設定である場合、前記移動端末グループのために前記ユーザプレーン・アドレス帯域を決定し、前記共用ＣＮＢを設定する、付記Ｃ２に記載の移動通信システム。
（付記Ｃ４）
　コアネットワークに配置される外部ゲートウェイであって、
　移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）を使用してユーザパケットを転送する転送部と、
　前記共用ＣＮＢの設定を制御する制御部と、
を備え、
　前記制御部は、前記移動端末グループに属する第１の移動端末を示す制御メッセージを受信し、前記第１の移動端末にユーザプレーン・アドレスを割り当てるとともに、前記ユーザプレーン・アドレスが宛先に指定されたユーザパケットを前記共用ＣＮＢに流すためのパケットフィルタを設定する、
外部ゲートウェイ。
（付記Ｃ５）
　前記制御部は、前記移動端末グループに対応付けられたユーザプレーン・アドレス帯域の中から前記第１の移動端末に割り当てる前記ユーザプレーン・アドレスを決定する、付記Ｃ４に記載の外部ゲートウェイ。
（付記Ｃ６）
　前記制御部は、前記制御メッセージを受信した際に前記共用ＣＮＢが未設定である場合、前記移動端末グループのために前記ユーザプレーン・アドレス帯域を決定し、前記共用ＣＮＢを設定する、付記Ｃ５に記載の外部ゲートウェイ。
（付記Ｃ７）
　コアネットワークに配置される外部ゲートウェイにおける通信制御方法であって、
　移動端末グループに属する第１の移動端末を示す制御メッセージを受信すること、
　前記第１の移動端末にユーザプレーン・アドレスを割り当てること、及び
　前記ユーザプレーン・アドレスが宛先に指定されたユーザパケットを共用コアネットワークベアラに流すためのパケットフィルタを設定すること、前記共用ＣＮＢは、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用されるコアネットワークベアラである、
を備える通信制御方法。
（付記Ｃ８）
　前記割り当てることは、前記移動端末グループに対応付けられたユーザプレーン・アドレス帯域の中から前記第１の移動端末に割り当てる前記ユーザプレーン・アドレスを決定することを含む、付記Ｃ７に記載の通信制御方法。
（付記Ｃ９）
　前記制御メッセージを受信した際に前記共用ＣＮＢが未設定である場合、前記移動端末グループのために前記ユーザプレーン・アドレス帯域を決定し、前記共用ＣＮＢを設定することをさらに備える、付記Ｃ８に記載の通信制御方法。
（付記Ｃ１０）
　コアネットワークに配置される外部ゲートウェイにおける通信制御方法をコンピュータに行わせるためのプログラムであって、
　前記通信制御方法は、
　移動端末グループに属する第１の移動端末を示す制御メッセージを受信すること、
　前記第１の移動端末にユーザプレーン・アドレスを割り当てること、及び
　前記ユーザプレーン・アドレスが宛先に指定されたユーザパケットを共用コアネットワークベアラに流すためのパケットフィルタを設定すること、
を含み、
　前記共用ＣＮＢは、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用されるコアネットワークベアラである、
プログラム。

（付記Ｄ１）
　加入者サーバ、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを備え、
　前記転送ノード及び前記外部ゲートウェイは、移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）を前記転送ノードと前記外部ゲートウェイの間に設定し、
　前記加入者サーバは、前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを示す通知を前記移動管理ノードに送信し、
　前記移動管理ノードは、前記通知を受信し、前記移動端末グループに属する第１の移動端末のためのベアラ設定を制御する、
移動管理システム。
（付記Ｄ２）
　前記通知は、前記移動管理ノードとは異なる他の移動管理ノードに接続する移動端末のために前記共用ＣＮＢが使用されているか否かを示す、付記Ｄ１に記載の移動管理システム。
（付記Ｄ３）
　前記移動管理ノードは、前記共用ＣＮＢが未使用であるときに、前記第１の移動端末のユーザパケットを前記共用ＣＮＢにおいて転送するための前記共用ＣＮＢの修正を前記転送ノードに要求する、付記Ｄ１又はＤ２に記載の移動管理システム。
（付記Ｄ４）
　前記移動管理ノードは、前記共用ＣＮＢが使用中であるときに、前記第１の移動端末のユーザパケットを転送するための新たなコアネットワークベアラの設定を制御する、付記Ｄ１～Ｄ３のいずれか１項に記載の移動管理システム。
（付記Ｄ５）
　コアネットワークに配置される加入者サーバであって、
　移動端末グループに属するいずれかの移動端末のために共用コアネットワークベアラ（ＣＮＢ）が使用されているか否かを示す通知を前記コアネットワーク内の移動管理ノードに送信する管理部を備え、
　前記共用ＣＮＢは、前記コアネットワーク内の転送ノードと外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
加入者サーバ。
（付記Ｄ６）
　前記通知は、前記移動管理ノードとは異なる他の移動管理ノードに接続する移動端末のために前記共用ＣＮＢが使用されているか否かを示す、付記Ｄ５に記載の加入者サーバ。
（付記Ｄ７）
　コアネットワークに配置される加入者サーバにおける通信制御方法であって、
　移動端末グループに属するいずれかの移動端末のために共用コアネットワークベアラ（ＣＮＢ）が使用されているか否かを示す通知を前記コアネットワーク内の移動管理ノードに送信することを備え、
　前記共用ＣＮＢは、前記コアネットワーク内の転送ノードと外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
通信制御方法。
（付記Ｄ８）
　前記通知は、前記移動管理ノードとは異なる他の移動管理ノードに接続する移動端末のために前記共用ＣＮＢが使用されているか否かを示す、付記Ｄ７に記載の通信制御方法。
（付記Ｄ９）
　コアネットワークに配置される加入者サーバにおける通信制御方法をコンピュータに行わせるためのプログラムであって、
　前記通信制御方法は、移動端末グループに属するいずれかの移動端末のために共用コアネットワークベアラ（ＣＮＢ）が使用されているか否かを示す通知を前記コアネットワーク内の移動管理ノードに送信することを含み、
　前記共用ＣＮＢは、前記コアネットワーク内の転送ノードと外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
プログラム。

（付記Ｅ１）
　移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを備え、
　前記転送ノード及び前記外部ゲートウェイは、移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）を前記転送ノードと前記外部ゲートウェイの間に設定し、
　前記転送ノードは、前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを示す通知を前記移動管理ノードに送信し、
　前記移動管理ノードは、前記通知を受信し、前記移動端末グループに属する第１の移動端末のためのベアラ設定を制御する、
移動管理システム。
（付記Ｅ２）
　前記通知は、前記移動管理ノードとは異なる他の移動管理ノードに接続する移動端末のために前記共用ＣＮＢが使用されているか否かを示す、付記Ｅ１に記載の移動管理システム。
（付記Ｅ３）
　前記移動管理ノードは、前記共用ＣＮＢが未使用であるときに、前記第１の移動端末のユーザパケットを前記共用ＣＮＢにおいて転送するための前記共用ＣＮＢの修正を前記転送ノードに要求する、付記Ｅ１又はＥ２に記載の移動管理システム。
（付記Ｅ４）
　前記移動管理ノードは、前記共用ＣＮＢが使用中であるときに、前記第１の移動端末のユーザパケットを転送するための新たなコアネットワークベアラの設定を制御する、付記Ｅ１～Ｅ３のいずれか１項に記載の移動管理システム。
（付記Ｅ５）
　コアネットワークに配置される転送ノードであって、
　移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される共用コアネットワークベアラ（ＣＮＢ）を使用してユーザパケットを転送する転送部と、
　前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを示す通知を前記コアネットワーク内の移動管理ノードに送信する制御部と、
を備え、
　前記共用ＣＮＢは、前記転送ノードと前記コアネットワーク内の外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
転送ノード。
（付記Ｅ６）
　前記通知は、前記移動管理ノードとは異なる他の移動管理ノードに接続する移動端末のために前記共用ＣＮＢが使用されているか否かを示す、付記Ｅ５に記載の転送ノード。
（付記Ｅ７）
　コアネットワークに配置される転送ノードにおける通信制御方法であって、
　移動端末グループに属するいずれかの移動端末のために共用コアネットワークベアラ（ＣＮＢ）が使用されているか否かを示す通知を前記コアネットワーク内の移動管理ノードに送信することを備え、
　前記共用ＣＮＢは、前記転送ノードと前記コアネットワーク内の外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
転送ノード。
（付記Ｅ８）
　前記通知は、前記移動管理ノードとは異なる他の移動管理ノードに接続する移動端末のために前記共用ＣＮＢが使用されているか否かを示す、付記Ｅ７に記載の通信制御方法。
（付記Ｅ９）
　コアネットワークに配置される転送ノードにおける通信制御方法をコンピュータに行わせるためのプログラムであって、
　前記通信制御方法は、移動端末グループに属するいずれかの移動端末のために共用コアネットワークベアラ（ＣＮＢ）が使用されているか否かを示す通知を前記コアネットワーク内の移動管理ノードに送信することを含み、
　前記共用ＣＮＢは、前記転送ノードと前記コアネットワーク内の外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
プログラム。

　この出願は、２０１３年２月１８日に出願された日本出願特願２０１３－０２９５１２を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１　移動端末（ＵＥ）
２　基地局
３　移動管理ノード
４　転送ノード
５　外部ゲートウェイ
６　加入者情報データベース
７　通信管理ユニット
９　外部ネットワーク
１０　無線アクセスネットワーク（ＲＡＮ）
２０　コアネットワーク（ＣＮ）
３０　共用コアネットワークベアラ（共用ＣＮＢ）
３１　追加コアネットワークベアラ（追加ＣＮＢ）
３２　共用ＣＮＢ（共用ＣＮＢ）
４０～４３　ベアラ
５０～５３　無線ベアラ
３０１　制御部
４０１　制御部
５０１　制御部
６０１　管理部

Claims

　加入者サーバ、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークを備え、
　前記加入者サーバは、移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記移動管理ノードに通知し、
　前記移動管理ノードは、前記ユーザプレーン・アドレスに対応するユーザパケットが共用コアネットワークベアラ（ＣＮＢ）において転送されるよう前記共用ＣＮＢの設定を制御し、
　前記共用ＣＮＢは、前記転送ノードと前記外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
移動通信システム。
　前記加入者サーバは、前記共用ＣＮＢが既に設定されているか否かを前記移動管理ノードにさらに通知する、請求項１に記載の移動通信システム。
　前記共用ＣＮＢが既に設定されているか否かの通知は、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域を前記移動管理ノードに通知するか否かによって行われる、請求項２に記載の移動通信システム。
　前記共用ＣＮＢが既に設定されているか否かの通知は、前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを前記移動管理ノードに通知することにより行われる、請求項２に記載の移動通信システム。
　前記移動管理ノードは、前記移動端末グループに属する第１の移動端末からのアタッチ要求を契機として、前記第１の移動端末のユーザプレーン・アドレス、及び前記共用ＣＮＢが既に設定されているか否かの通知を前記加入者サーバから受信する、請求項１～４のいずれか１項に記載の移動通信システム。
　前記移動管理ノードは、前記共用ＣＮＢが既に設定されている間に前記第１の移動端末からの前記アタッチ要求を受信した場合に、前記第１の移動端末のユーザプレーン・アドレスを含み且つ前記共用ＣＮＢの修正要求を示す制御メッセージを前記転送ノードに送信する、請求項５に記載の移動通信システム。
　前記加入者サーバは、前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを前記移動管理ノードにさらに通知する、請求項１～６のいずれか１項に記載の移動通信システム。
　加入者サーバ、移動管理ノード、転送ノード、及び外部ゲートウェイを含むコアネットワークにおける通信制御方法であって、
　前記加入者サーバによって、移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記移動管理ノードに通知すること、及び
　前記前記移動管理ノードによって、前記ユーザプレーン・アドレスに対応するユーザパケットが共用コアネットワークベアラ（ＣＮＢ）において転送されるよう前記共用ＣＮＢの設定を制御すること、
を備え、
　前記共用ＣＮＢは、前記転送ノードと前記外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
通信制御方法。
　前記加入者サーバによって、前記共用ＣＮＢが既に設定されているか否かを前記移動管理ノードに通知することをさらに備える、請求項８に記載の通信制御方法。
　前記共用ＣＮＢが既に設定されているか否かの通知は、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域を通知するか否かによって行われる、請求項９に記載の通信制御方法。
　前記共用ＣＮＢが既に設定されているか否かの通知は、前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを通知することにより行われる、請求項９に記載の通信制御方法。
　前記ユーザプレーン・アドレスを通知すること及び前記共用ＣＮＢが既に設定されているか否かを通知することは、前記移動端末グループに属する第１の移動端末からのアタッチ要求を契機として、前記第１の移動端末のユーザプレーン・アドレス、及び前記共用ＣＮＢが既に設定されているか否かの通知を前記移動管理ノードにおいて前記加入者サーバから受信することを含む、請求項８～１１のいずれか１項に記載の通信制御方法。
　前記制御することは、前記共用ＣＮＢが既に設定されている間に前記第１の移動端末からの前記アタッチ要求を受信した場合に、前記第１の移動端末のユーザプレーン・アドレスを含み且つ前記共用ＣＮＢの修正要求を示す制御メッセージを前記移動管理ノードから前記転送ノードに送信することを含む、請求項１２に記載の通信制御方法。
　前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを前記加入者サーバから前記移動管理ノードに通知することをさらに備える、請求項８～１３のいずれか１項に記載の通信制御方法。
　コアネットワークに配置される加入者サーバであって、
　移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記コアネットワーク内の移動管理ノードに通知すると共に、前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを前記移動管理ノードに通知するアドレス管理部を備える、
加入者サーバ。
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かの通知は、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域を通知するか否かによって行われる、請求項１５に記載の加入者サーバ。
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かの通知は、共用コアネットワークベアラ（ＣＮＢ）が既に設定されているか否かを通知することによって行われ、
　前記共用ＣＮＢは、前記コアネットワーク内の転送ノードと外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
請求項１５又は１６に記載の加入者サーバ。
　前記アドレス管理部は、前記移動端末グループに属するいずれかの移動端末のために前記共用ＣＮＢが使用されているか否かを前記移動管理ノードにさらに通知する、請求項１５～１７のいずれか１項に記載の加入者サーバ。
　コアネットワークに配置される加入者サーバにおける通信制御方法であって、
　移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記コアネットワーク内の移動管理ノードに通知すること、及び
前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを前記移動管理ノードに通知すること、
を備える、通信制御方法。
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かの通知は、前記移動端末グループに割り当てられたユーザプレーン・アドレス帯域を通知するか否かによって行われる、請求項１９に記載の通信制御方法。
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かの通知は、共用コアネットワークベアラ（ＣＮＢ）が既に設定されているか否かを通知することによって行われ、
　前記共用ＣＮＢは、前記コアネットワーク内の転送ノードと外部ゲートウェイの間に設定され、前記移動端末グループに属する複数の移動端末のユーザパケット転送のために共用される、
請求項１９又は２０に記載の通信制御方法。
　前記移動端末グループに属するいずれかの移動端末によって前記共用ＣＮＢが使用中であるか否かを前記移動管理ノードに通知することをさらに備える、請求項１９～２１のいずれか１項に記載の通信制御方法。
　コアネットワークに配置される加入者サーバにおける通信制御方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
　前記通信制御方法は、
　移動端末グループに属する各移動端末のユーザプレーン・アドレスを前記コアネットワーク内の移動管理ノードに通知すること、及び
　前記移動端末グループに属するいずれかの移動端末が前記コアネットワークに既にアタッチしているか否かを前記移動管理ノードに通知すること、
を含む、
非一時的なコンピュータ可読媒体。