(57)【要約】【課題】通信システムの配信サービスに用いるベアラの種別を判断するために生じるトラフィックを低減する技術を提供する。【解決手段】端末管理手段は、端末の情報を管理するためのコンテキストに、各セルで提供される配信サービスへ参加する端末の情報を保持する。端末計数手段は、端末管理手段で保持されているコンテキストを利用して、各セル内で配信サービスに参加している端末の個数である端末数をサービス単位で計数する。ベアラ判定手段は、端末計数手段で計数された端末数に基づいて、各セルにおいて、配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定する。【選択図】図１
2010093480.tif 000002
【特許請求の範囲】
【請求項１】
端末の情報を管理するためのコンテキストに、各セルで提供される配信サービスへ参加する端末の情報を保持する端末管理手段と、
前記端末管理手段で保持されている前記コンテキストを利用して、前記各セル内で前記配信サービスに参加している端末の個数である端末数をサービス単位で計数する端末計数手段と、
前記端末計数手段で計数された前記端末数に基づいて、前記各セルにおいて、前記配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定するベアラ判定手段と、
を有するネットワークコントローラ。
【請求項２】
前記端末計数手段は、前記セルにおいて前記配信サービスに参加している端末として前記コンテキストに記録されている端末の個数であるコンテキスト内端末数を計数し、
前記ベアラ判定手段は、前記端末計数手段により計数された前記コンテキスト内端末数が第１のしきい値以上であれば、前記セルにおいて前記配信サービスにポイントツーマルチポイントのベアラを用いることを決定する、
請求項１に記載のネットワークコントローラ。
【請求項３】
前記ベアラ判定手段が、前記端末計数手段により計数された前記コンテキスト内端末数が前記第１のしきい値より小さいと判定したら、前記端末管理手段の前記コンテキストでは、所在しているセルにおける計数ができない端末に対して、所定の応答確率を設定した、前記配信サービスへの参加の有無の問い合わせを行う問い合わせ手段を更に有し、
前記端末管理手段は、前記問い合わせ手段からの問い合わせに対する前記端末からの応答に基づいて前記コンテキストを更新し、
前記ベアラ判定手段は、更新された前記コンテキストによるコンテキスト内端末数を利用して、前記配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定する、
請求項２に記載のネットワークコントローラ。
【請求項４】
前記端末管理手段は、前記問い合わせ手段からの問い合わせに対して、前記配信サービスへの参加を示す応答をした端末のうち、前記コンテキストを基に計数できる状態である端末の所在するセルと前記配信サービスへの参加の旨とを記録するように前記コンテキストを更新するとともに、前記コンテキストを基に計数できる状態でない端末の所在するセルと前記配信サービスへの参加の旨とに基づき、前記コンテキスト内端末数に計数されない端末のセルおよびサービス単位の個数であるコンテキスト外端末数を計数し、
前記ベアラ判定手段は、更新された前記コンテキストにおけるコンテキスト内端末数と、計数された前記コンテキスト外端末数との合計数が第２のしきい値以上であれば、前記セルにおいて前記配信サービスにポイントツーマルチポイントのベアラを用いることを決定する、
請求項３に記載のネットワークコントローラ。
【請求項５】
前記ベアラ判定手段は、前記合計数が前記第２のしきい値より小さければ、前記問い合わせ手段に対して、前記応答確率を上げて再び問い合わせを行うように促し、前記応答確率が１となっても前記合計数が前記第２のしきい値より小さければ、前記セルにおいて前記配信サービスにポイントツーポイントのベアラを用いることを決定する、
請求項４に記載のネットワークコントローラ。
【請求項６】
前記問い合わせに対する前記端末からの応答には、該問い合わせの対象とされた配信サービスを特定する情報が含まれる、請求項３に記載のネットワークコントローラ。
【請求項７】
前記ベアラ判定手段は、前記合計数が前記第２のしきい値より小さければ、前記問い合わせを行う前の合計数と、前記問い合わせによって前記合計数に加算された端末数と、前記応答確率とに基づいて、次の問い合わせに用いる応答確率を選択する、請求項５に記載のネットワークコントローラ。
【請求項８】
データの配信が開始されている配信サービスに用いるベアラの種別をポイントツーポイントからポイントツーマルチポイントへ切り替えることを判定するときに用いるしきい値が、前記配信サービスに用いるベアラの種別をポイントツーマルチポイントからポイントツーポイントへ切り替えることを判定するときに用いるしきい値よりも大きな値である、請求項２から７のいずれか１項に記載のネットワークコントローラ。
【請求項９】
前記端末管理手段、前記端末計数手段、および前記ベアラ判定手段を備える制御用ネットワークコントローラと、前記問い合わせ手段を備えるサービング用ネットワークコントローラとを含んで構成される、請求項３に記載のネットワークコントローラ。
【請求項１０】
前記コンテキストを基に計数できる状態は、３ＧＰＰにて規定されたＣＥＬＬ＿ＤＣＨ、ＣＥＬＬ＿ＦＡＣＨ、およびＣＥＬＬ＿ＰＣＨであり、そうでない状態は、ＵＲＡ＿ＰＣＨおよびＩＤＬＥである、請求項４に記載のネットワークコントローラ。
【請求項１１】
前記所在しているセルにおける計数ができない端末は、所在しているセルが不明な状態の端末である、請求項３に記載のネットワークコントローラ。
【請求項１２】
セルを形成し、該セルのベアラで端末に配信サービスのデータを送信する複数の基地局装置と、
端末の情報を管理するためのコンテキストに、前記各セルで提供される配信サービスへ参加する端末の情報を保持し、保持している前記コンテキストを利用して、前記各セル内で前記配信サービスに参加している端末の個数である端末数をサービス単位で計数し、計数した前記端末数に基づいて、前記各セルにおいて、前記配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定するネットワークコントローラと、
を有する通信システム。
【請求項１３】
前記ネットワークコントローラは、前記セルにおいて前記配信サービスに参加している端末として前記コンテキストに記録されている端末の個数であるコンテキスト内端末数を計数し、計数された前記コンテキスト内端末数が第１のしきい値以上であれば、前記セルにおいて前記配信サービスにポイントツーマルチポイントのベアラを用いることを決定する、
請求項１２に記載の通信システム。
【請求項１４】
端末の情報を管理するためのコンテキストに、各セルで提供される配信サービスへ参加する端末の情報を保持し、
保持している前記コンテキストを利用して、前記各セル内で前記配信サービスに参加している端末の個数である端末数をサービス単位で計数し、
計数した前記端末数に基づいて、前記各セルにおいて、前記配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定する、ベアラ種別決定方法。
【請求項１５】
前記セルにおいて前記配信サービスに参加している端末として前記コンテキストに記録されている端末の個数であるコンテキスト内端末数を計数し、
計数した前記コンテキスト内端末数が第１のしきい値以上であれば、前記セルにおいて前記配信サービスにポイントツーマルチポイントのベアラを用いることを決定する、
請求項１４に記載のベアラ種別決定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信サービスに用いるベアラの種別を選択することができる通信システムに関する。
【背景技術】
【０００２】
移動通信システムにおけるＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）では、ブロードキャストあるいはマルチキャストでデータを複数の移動端末（ＵＥ）に配信する。データ配信は、ｐ−ｔ−ｐ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ）方式あるいはｐ−ｔ−ｍ（Ｐｏｉｎｔ−ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）方式で行われる。ｐ−ｔ−ｐ方式は１対１の通信方式であり、ｐ−ｔ−ｍ方式は１対多の通信方式である。
【０００３】
データ通信に用いられる無線回線上のベアラの種別として、ｐ−ｔ−ｐ通信のためのベアラ（ｐ−ｔ−ｐベアラ）とｐ−ｔ−ｍ通信のためのベアラ（ｐ−ｔ−ｍベアラ）とがある。ＭＢＭＳでは、サービス中に状況に応じてベアラの種別を切り替えることもできる。
【０００４】
ｐ−ｔ−ｍベアラは無線回線上に共通チャネルとして確立される。したがって、ｐ−ｔ−ｍベアラを用いた場合には、サービスを受けるＵＥの個数に関わらず共通リソースが消費されることになる。一方、ｐ−ｔ−ｐベアラは個別チャネルとして確立される。具体的には、ｐ−ｔ−ｐベアラは既存の個別転送チャネル（Ｄｅｄｉｃａｔｅｄ  Ｔｒａｎｓｐｏｒｔ  ＣＨａｎｎｅｌ；  ＤＴＣＨ）として確立される。個別チャネルは各ＵＥに対して設定されるので、ｐ−ｔ−ｐベアラを用いた場合、サービスを受けるＵＥの個数分の個別チャネルのリソースが消費されることになる。
【０００５】
例えば、セル内における特定のＭＢＭＳサービスの受信を希望しているＵＥの個数が０もしくは極少である場合、ｐ−ｔ−ｐベアラを用いて各ＵＥに個別にデータを配信する方が、共通のｐ−ｔ−ｍベアラを用いてＵＥにデータを配信するよりも、消費される無線リソースが少ない。
【０００６】
一方、セル内における特定のＭＢＭＳサービスの受信を希望しているＵＥの個数が一定数以上である場合には、ｐ−ｔ−ｍベアラでデータを配信する方がｐ−ｔ−ｐベアラでデータを配信するよりも、無線リソースの消費が少ない。また、ｐ−ｔ−ｍベアラを用いることにはＵＥにとっても利点がある。例えば、ｐ−ｔ−ｍベアラの共通チャネルでＭＢＭＳのサービスを受けながら、個別チャネルで他の通信を同時に行うことができる。
【０００７】
以上のように、ＭＢＭＳサービスにｐ−ｔ−ｐベアラとｐ−ｔ−ｍベアラのどちらを用いるかを適切に選択することによって無線リソースを有効利用することができる。ベアラの種別を適切に選択するために、標準規格においては、ＭＢＭＳの受信を希望しているＵＥの個数をカウントするためのカウティング手順が定義されている。また、ＭＢＭＳの受信を希望しているＵＥの個数を正しく把握するための様々な技術が提案されている（例えば特許文献１参照）。カウンティング手順は、基本的には、ネットワークからＵＥに対して問合せを行い、ＵＥからの応答に基づいてＵＥ数をカウントするというものである。
【特許文献１】特表２００７−５３３２１７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
カウンティングにおいては、多数のＵＥからの応答が短時間に集中すると、無線環境の悪化、ネットワークあるいは管理装置の過負荷などの問題が生じる。そのため、標準規格では、ＵＥからの応答が過剰とならないような配慮がなされている。具体的には、ＵＥのうち問合せを行う対象とするＵＥの割合として応答確率を設け、その応答確率を低い値から徐々に上げて行きながらベアラの判定を行っている。これによって、ある程度は上記諸問題が緩和される。
【０００９】
しかしながら、無線環境やネットワークあるいは管理装置に対する負荷およびそれらについてのマージンを考慮すると、ベアラの種別を判断するために生じるトラフィックはできるだけ低く抑えることが好ましい。
【００１０】
本発明の目的は、通信システムの配信サービスに用いるベアラの種別を判断するために生じるトラフィックを低減する技術を提供することである。
【課題を解決するための手段】
【００１１】
上記目的を達成するために、本発明の一態様によるネットワークコントローラは、
端末の情報を管理するためのコンテキストに、各セルで提供される配信サービスへ参加する端末の情報を保持する端末管理手段と、
前記端末管理手段で保持されている前記コンテキストを利用して、前記各セル内で前記配信サービスに参加している端末の個数である端末数をサービス単位で計数する端末計数手段と、
前記端末計数手段で計数された前記端末数に基づいて、前記各セルにおいて、前記配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定するベアラ判定手段と、
を有している。
【００１２】
本発明の一態様による通信システムは、
セルを形成し、該セルのベアラで端末に配信サービスのデータを送信する複数の基地局装置と、
端末の情報を管理するためのコンテキストに、前記各セルで提供される配信サービスへ参加する端末の情報を保持し、保持している前記コンテキストを利用して、前記各セル内で前記配信サービスに参加している端末の個数である端末数をサービス単位で計数し、計数した前記端末数に基づいて、前記各セルにおいて、前記配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定するネットワークコントローラと、
を有している。
【００１３】
本発明の一態様によるベアラ種別決定方法は、
端末の情報を管理するためのコンテキストに、各セルで提供される配信サービスへ参加する端末の情報を保持し、
保持している前記コンテキストを利用して、前記各セル内で前記配信サービスに参加している端末の個数である端末数をサービス単位で計数し、
計数した前記端末数に基づいて、前記各セルにおいて、前記配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定する、方法である。
【発明の効果】
【００１４】
本発明によれば、カウンティングを行わなくてもコンテキストから判断が可能な場合にはカウティングを行わずにベアラ種別を判断するので、通信システムの配信サービスに用いるベアラの種別を判断するために生じるトラフィックが低減される。
【発明を実施するための最良の形態】
【００１５】
本発明を実施するための形態について図面を参照して詳細に説明する。
【００１６】
本実施形態の通信システムは、ＭＢＭＳを提供する３ＧＰＰ移動通信システムである。図１は、３ＧＰＰ移動通信システムの構成を示すブロック図である。図１を参照すると、３ＧＰＰ移動通信システムはコアネットワーク（ＣＮ）１１と、アクセスネットワーク（ＵＴＲＡＮ；ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１２で構成されている。
【００１７】
ＣＮ１１は、パケット網１３によるパケット通信を実現するネットワークであり、パケット網１３に接続されたＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）１４と、ＧＧＳＮ１４に接続されたＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）１５とを有している。
【００１８】
ＵＴＲＡＮ１２は、無線による移動通信のアクセス網であり、ＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）１６と基地局装置（ＮｏｄｅＢ）１７を有している。
【００１９】
ＵＥ１８に対して実際に無線電波を送信するのはＮｏｄｅＢ１７であるが、ＵＥ１８に対して、無線通信やサービスにおいて使用する設定値をＲＲＣメッセージで通知するのはＲＮＣ１６である。
【００２０】
ＲＮＣ１６は、管理下にあるセル内の通信中のＵＥ１８に関する情報を把握している。ＲＮＣ１６は、例えば、各セル内の通信中のＵＥ１８の個数と、各ＵＥ１８が使用するベアラの種別とを把握している。ＲＮＣ１６の機能は、Ｃｏｎｔｒｏｌ  ＲＮＣおよびＳｅｒｖｉｎｇ  ＲＮＣで、あるいはさらにＤｒｉｆｔ  ＲＮＣとで分担されてもよい。
【００２１】
図２は、ＲＮＣ１６の構成を示すブロック図である。図２を参照すると、ＲＮＣ１６は、端末管理部２１、端末計数部２２、ベアラ判定部２３、および問い合わせ部２４を有している。例えば、上述のＣｏｎｔｒｏｌ  ＲＮＣが端末管理部２１、端末計数部２２、およびベアラ判定部２３を備え、Ｓｅｒｖｉｎｇ  ＲＮＣが問い合わせ部２４を備えるような分担が可能である。
【００２２】
端末管理部２１は、ＵＥ１８の情報を管理するためのコンテキストに、各セルで提供される配信サービスへ参加するＵＥ１８の情報を保持する。
【００２３】
端末計数部２２は、端末管理部２１で管理されているコンテキストを利用して、各セル内で配信サービスに参加しているＵＥ１８の個数である端末数をサービス単位で計数する。これにより、配信サービスに参加するＵＥ１８の個数がセル単位およびサービス単位で計数されることになる。
【００２４】
ベアラ判定部２３は、端末計数部２２で計測された端末数に基づいて、各セルにおける各配信サービスに、ポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定する。
【００２５】
以上より、本実施形態によれば、カウンティングを行わなくてもコンテキストから判断が可能な場合にはカウティングを行わずにベアラ種別を判断するので、通信システムの配信サービスに用いるベアラの種別を判断するために生じるトラフィックが低減される。
【００２６】
上記の判定に際して、まず、端末計数部２２は、各セルにおいて各配信サービスに参加しているＵＥ１８としてコンテキストに記録されているＵＥ１８の個数であるコンテキスト内端末数を計数する。ベアラ判定部２３は、あるセルにおける、ある配信サービスについて、端末計数部２２により計数されたコンテキスト内端末数が所定のしきい値（第１の閾値）以上であれば、そのセルにおいてその配信サービスにポイントツーマルチポイントのベアラを用いることを決定する。
【００２７】
端末計数２２により計数されたコンテキスト内端末数がしきい値より小さいとベアラ判定部２３が判定した場合のみ、問い合わせ部２４が、端末管理部２１のコンテキストにおいて、所在しているセルにおける計数ができないＵＥ１８に対して、所定の応答確率を設定した、配信サービスへの参加の有無の問い合わせを行う。例えば、所在しているセルが不明な状態のＵＥ１８を、所在しているセルにおける計数ができないＵＥ１８として扱うことにしてもよい。
【００２８】
コンテキストにおけるＵＥ１８の状態として、ＣＥＬＬ＿ＤＣＨ状態、ＣＥＬＬ＿ＦＡＣＨ状態、およびＣＥＬＬ＿ＰＣＨ状態がある。それ以外のＵＥ１８の状態として、ＵＲＡ＿ＰＣＨ状態およびＩＤＬＥ状態がある。
【００２９】
ＣＥＬＬ＿ＤＣＨ状態は、セル単位で所在が特定されており、かつＤＣＨ（Ｄｅｄｉｃａｔｅｄ  Ｃｈａｎｎｅｌ）を割り当てられた状態である。ＣＥＬＬ＿ＦＡＣＨ状態は、セル単位で所在が特定されており、かつＦＡＣＨ（Ｆｏｒｗａｒｄ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）を受信できる状態である。ＣＥＬＬ＿ＰＣＨ状態は、セル単位で所在が特定されており、かつＰＣＨ（Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）を受信できる状態である。ＵＲＡ＿ＰＣＨ状態は、セル単位で所在が特定されていないが、ＰＣＨを受信できる状態である。ＩＤＬＥ状態は、トランスポートチャネルに接続していない状態である。例えば、これらの状態の中でＵＲＡ＿ＰＣＨ状態あるいはＩＤＬＥ状態のＵＥ１８を、所在しているセルが不明な状態のＵＥ１８とすればよい。
【００３０】
問い合わせ部２４からの問い合わせに対するＵＥ１８からの応答には、その問い合わせの対象とされた配信サービスを特定する情報が含まれる。これにより応答の対象となる配信サービスが明確となり適切なベアラの決定が可能となる。
【００３１】
ＵＥ１８からの応答により、そのＵＥ１８の配信サービスへ参加（あるいは選択）と、そのＵＥ１８の所在するセルとが分かる場合には、端末管理部２１は、ＵＥ１８からの応答に基づいてコンテキストを更新する。ベアラ判定部２３は、更新されたコンテキストによるコンテキスト内端末数を利用して、配信サービスにおいてポイントツーポイントのベアラとポイントツーマルチポイントのベアラのいずれを用いるかを判定する。
【００３２】
問い合わせ部２４からの問い合わせに対するＵＥ１８からの応答により、そのＵＥ１８の配信サービスへ参加（あるいは選択）と、そのＵＥ１８の所在するセルとが分かる場合というのは、例えば、応答により確定するＵＥ１８の状態が、ＣＥＬＬ＿ＤＣＨ状態、ＣＥＬＬ＿ＦＡＣＨ状態、あるいはＣＥＬＬ＿ＰＣＨ状態の場合である。それらの状態のＵＥ１８は、更新されたコンテキストを基に計数できる。
【００３３】
端末管理部２１は、配信サービスへの参加を示す応答をしたＵＥ１８のうち、コンテキストを基に計数できる状態であるＵＥ１８の所在するセルと配信サービスへの参加の旨とを記録することにより、コンテキストを更新する。また、それとともに、端末管理部２１は、コンテキストを基に計数できる状態でないＵＥ１８の所在するセルと配信サービスへの参加の旨とに基づき、コンテキスト内端末数に計数されないＵＥ１８のセルおよびサービス単位の個数であるコンテキスト外端末数を計数する。
【００３４】
ベアラ判定部２３は、更新されたコンテキストにおけるコンテキスト内端末数と、計数されたコンテキスト外端末数との合計数が所定のしきい値（第２のしきい値）以上であれば、セルにおいて配信サービスにポイントツーマルチポイントのベアラを用いることを決定する。また、ベアラ判定部２３は、合計数がしきい値より小さければ、問い合わせ部２４に対して、応答確率を上げて再び問い合わせを行うように促す。応答確率を１まで上げても合計数がしきい値より小さければ、ベアラ判定部２３は、最終的に、ポイントツーポイントのベアラを用いることを決定する。なお、ここで用いられる、しきい値（第２のしきい値）は、上記説明においてコンテキスト内端末数と比較されるしきい値（第１の閾値）と同じ値であってもよく、また異なる値であってもよい。
【００３５】
図３は、本実施形態によるＲＮＣ１６の動作を示すフローチャートである。図３を参照すると、ＲＮＣ１６は、コンテキスト内端末数を計数する（ステップＳ０１）。次に、ＲＮＣ１６は、そのコンテキスト内端末数が第１の閾値以上であるか否かによって、配信サービスにポイントツーマルチポイントのベアラを用いるか否か判定する（ステップＳ０２）。コンテキスト内端末数が第１の閾値以上であれば、ＲＮＣ１６は、ポイントツーマルチポイントのベアラを用いることを決定する（ステップＳ０８）。
【００３６】
コンテキスト内端末数が第１のしきい値より小さければ、ＲＮＣ１６は、所定の応答確率を設定した、配信サービスへの参加の有無の問い合わせをセルに送信する（ステップＳ０３）。
【００３７】
ＲＮＣ１６は、問い合わせに対する応答を受信してコンテキストを更新し、コンテキスト内端末数とコンテキスト外端末数を計数する（ステップＳ０４）。そして、ＲＮＣ１６は、コンテキスト内端末数とコンテキスト外端末数の合計数が第２のしきい値以上であるか否かにより、配信サービスにポイントツーマルチポイントのベアラを用いるか否か判定する（ステップＳ０５）。合計数が第２の閾値以上であれば、ＲＮＣ１６は、ポイントツーマルチポイントのベアラを用いることを決定する（ステップＳ０８）。
【００３８】
合計数が第２のしきい値より小さければ、ＲＮＣ１６は応答確率が１か否か判定する（ステップＳ０６）。応答確率が１であれば、ＲＮＣ１６は、配信サービスにポイントツーポイントのベアラを用いることを決定する（ステップＳ０９）。応答確率が１でなければ、ＲＮＣ１６は、応答確率を上げて再び問い合わせを行う（ステップＳ０７）。
【００３９】
なお、本実施形態において、データの配信が開始されている配信サービスに用いるベアラの種別を途中で切り替える場合、ポイントツーポイントからポイントツーマルチポイントの方向の切り替えを判定するときのしきい値と、その逆方向の切り替えを判定するときのしきい値との間にマージンを設けてもよい。
【００４０】
具体的には、ポイントツーポイントからポイントツーマルチポイントへの切り替えに用いるしきい値を、ポイントツーマルチポイントからポイントツーポイントへ切り替えに用いるしきい値よりも大きな値とすればよい。これにより、判定の境界付近でベアラの種別が頻繁に切り替わるのを防止することができる。
【００４１】
以下、上述した本実施形態のＲＮＣ１６の動作例を詳細に説明する。
【００４２】
１．ベアラ判定
ベアラの種別が決定されるタイミングは以下のように分類できる。分類されたそれぞれについて順に説明する。なお、セッションは個々のＭＢＭＳサービスを表している。
（１）  セッション開始時の使用ベアラ判定
（２）  セッション送信中のベアラ切り替え判定
（２−１）  ｐ−ｔ−ｍベアラでセッション送信中
（２−２）  ｐ−ｔ−ｐベアラでセッション送信中
図４は、セッション開始時のベアラ判定の一例を示すシーケンス図である。このシーケンスは上記（１）に相当する。セッション開始時には、そのセッションに使用するベアラの種別が決定される。
【００４３】
図５は、セッション送信中のベアラ判定の一例を示すシーケンス図である。このシーケンスは上記（２）に相当する。セッション送信中にも、セッションに参加するＵＥ１８の個数の変動により、ベアラの種別が変更されることがある。
【００４４】
ここで使用する記号について説明する。
【００４５】
ｐ−ｔ−ｐベアラとｐ−ｔ−ｍベアラのいずれを使用するか判定するための端末数のしきい値をｈ［個］とする。しきい値ｈは予め適切な値に設定される。このしきい値ｈに対するマージンをｍ［個］とする。マージンｍも予め適切な値に設定される。
【００４６】
（１）  セッション開始時の使用ベアラ判定
図４を参照すると、ＳＧＳＮからＲＮＣへのＳＥＳＳＩＯＮ  ＳＴＡＲＴメッセージにより（ステップＳ１０１）、ＭＢＭＳサービスのセッションが開始される。ＳＥＳＳＩＯＮ  ＳＴＡＲＴメッセージを受信したＲＮＣは、コンテキストを基に計数できるＵＥ数を用いてベアラ判定を行う（ステップＳ１０２）。この判定でＭＢＭＳサービスにｐ−ｔ−ｍベアラを使用することが確定しなければ、ＲＮＣは、コンテキストに記録されていないＵＥに対してＭＢＭＳアクセス情報ＲＲＣメッセージを送ることにより問い合わせを行う（ステップＳ１０３）。
【００４７】
コンテキストに記録されていないＵＥのうちＩＤＬＥ状態のＵＥは、ＲＲＣ確立要求ＲＲＣメッセージをＲＮＣに応答する（ステップＳ１０４）。コンテキストに記録されていないＵＥのうちＵＲＡ＿ＰＣＨ状態のＵＥは、セルアップデートＲＲＣメッセージをＲＮＣに応答する（ステップＳ１０５）。
【００４８】
それらの応答メッセージを受信したＲＮＣは、セル単位およびサービス単位でコンテキスト内端末数とコンテキスト外端末数の合計数を計数し、ベアラ判定を行う（ステップＳ１０６）。
【００４９】
ベアラ判定において、ｐ−ｔ−ｍベアラを使用することが確定されなければ、応答確率を上げながら、応答確率が１となるまで、あるいはｐ−ｔ−ｍベアラを使用することが確定されるまで、ステップＳ１０３〜Ｓ１０６の処理が繰り返される。
【００５０】
以下にて詳細に説明する。
【００５１】
（１−１）  Ｃｏｎｔｒｏｌ  ＲＮＣ（以下、ＣＲＮＣと称する）は、自身の管理するＵＥに関する情報をコンテキストにて管理している。ここではコンテキストの第１キーがセルに関する情報であり、第２キーがサービスに関する情報であり、第３キーがＵＥに関する情報である。
【００５２】
具体的には、第１キーとして、ＣＲＮＣの管理下のセルのＣｅｌｌ番号が保持される。第２キーとしては、第１キーの単位で、提供されるサービスを識別するためのサービス番号と、そのサービスの種別とが保持される。第３キーとしては、第２キーの単位で、ＵＥの識別情報（IＤ；Ｉｄｅｎｔｉｆｉｅｒ）およびＵＥの状態が保持されている。なお、ＵＥの状態としては、ＣＥＬＬ＿ＤＣＨ／ＣＥＬＬ＿ＦＡＣＨ／ＣＥＬＬ＿ＰＣＨがある。またコンテキストには、その他の情報が含まれていてもよい。
【００５３】
ただし、Ｓｅｒｖｉｎｇ  ＲＮＣ（以下、ＳＲＮＣと称する）ではなく、Ｄｒｉｆｔ  ＲＮＣ（以下、ＤＲＮＣと称する）の配下のセルに在圏しているＵＥに関しては、第３キーにおいてＣＥＬＬ＿ＤＣＨ状態のＵＥのみしかセル単位で所在を管理できないという制限がある。
【００５４】
ＣＲＮＣは、コンテキストにおける第３キーからＵＥの個数を計数し、ＵＥの個数がｈ以上であれば、ｐ−ｔ−ｍベアラを使用することを決定する。一方、ＵＥの個数がｈ未満であれば、ＣＲＮＣは、使用するベアラの種別を確定せずに（１−２）の処理に移行する。
【００５５】
（１−２）  ＵＲＡ＿ＰＣＨ状態あるいはＩＤＬＥ状態のＵＥはセル単位で所在を把握ができない。そのため、それらのＵＥはコンテキストにて管理されない。そこで、ＭＢＭＳサービスへの参加と所在しているセルとを問い合わせるために、ＳＲＮＣがＵＲＡ＿ＰＣＨ状態あるいはＩＤＬＥ状態のＵＥに対するＭＢＭＳアクセス情報ＲＲＣメッセージをサービスエリア内の各セルに送信する。
【００５６】
コンテキストにおいてＣＥＬＬ＿ＦＡＣＨ状態のＵＥおよびＣＥＬＬ＿ＰＣＨ状態のＵＥはセル単位で所在が把握されているので、ＭＢＭＳアクセス情報ＲＲＣメッセージによる問い合わせの対象はＵＲＡ＿ＰＣＨ状態のＵＥとＩＤＬＥ状態のＵＥのみでよい。これによりＵＥから応答の数を低減することができ、無線環境やネットワークの負荷への影響が低減される。
【００５７】
（１−３）  ＭＢＭＳアクセス情報ＲＲＣメッセージによる問い合わせに対する応答として、ＵＲＡ＿ＰＣＨ状態のＵＥはセルアップデートＲＲＣメッセージを送信する。一方、ＩＤＬＥ状態のＵＥはＲＲＣ確立要求ＲＲＣメッセージを送信する。
【００５８】
なお、本実施形態では、これらの応答メッセージには、どのＭＢＭＳサービスに関する応答であるかを示す情報が含まれているものとする。具体的には、現在既に標準化されているこれらの応答メッセージに、理由情報『カウンティングに対する応答』に関連付けて、ＭＢＭＳアクセス情報ＲＲＣメッセージによって問い合わせされた、どのＭＢＭＳサービスに対する応答かを示すＭＢＭＳ  Ｓｈｏｒｔ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｉｄｅｎｔｉｔｙのリストが新たに追加される。ＭＢＭＳアクセス情報ＲＲＣメッセージへの応答の対象となるＭＢＭＳサービスが明確となり適切なベアラの決定が可能となる。
【００５９】
追加された情報（追加情報）は、ＭＢＭＳアクセス情報ＲＲＣメッセージに含まれている応答要請対象のＭＢＭＳサービスリストを示すＭＢＭＳ  Ｓｈｏｒｔ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｉｄｅｎｔｉｔｙと対応している。追加情報は、理由情報が『カウンティングに対する応答』である場合にのみ含まれる。また、ＵＥがサービスにジョイン（参加）もしくは選択していたとしても、セッションの送信回数が複数回である場合、ＵＥが既にセッションを正しく受信できているのであれば更にセッションを受信する必要が無い。その場合には追加情報は必要ない。あるいは、ＵＥが応答メッセージを送信しなくてもよい場合もある。
【００６０】
（１−４）  （１−２）の問い合わせ時においてＩＤＬＥ状態であったＵＥは、（１−３）の応答によって、コンテキストにて管理可能なＲＲＣ  Ｃｏｎｎｅｃｔｅｄ状態に遷移できる。ＲＲＣ  Ｃｏｎｎｅｄｔｅｄ状態とは、ＣＥＬＬ＿ＤＣＨ状態、ＣＥＬＬ＿ＦＡＣＨ状態、ＣＥＬＬ＿ＰＣＨ状態、あるいはＵＲＡ＿ＰＣＨ状態である。ＵＥがＣＥＬＬ＿ＤＣＨ状態、ＣＥＬＬ＿ＦＡＣＨ状態、あるいはＣＥＬＬ＿ＰＣＨ状態へ遷移するのであれば、ＣＲＣは、そのＵＥの情報を、ＭＢＭＳサービスに関する情報と関連づけて、コンテキストに追加する。
【００６１】
（１−５）  （１−３）の問い合わせ時においてＵＲＡ＿ＰＣＨ状態であったＵＥについては、応答によって、応答時に在圏していたセルと、応答の対象とされたＭＢＭＳサービスとが明らかとなる。ＵＥがセルアップデートによりＣＥＬＬ＿ＦＡＣＨまたはＣＥＬＬ＿ＰＣＨに遷移するのであれば、ＣＲＮＣは、（１−４）のＵＥと同様に、そのＵＥの情報をコンテキストに追加する。
【００６２】
一方、ＵＲＡ＿ＰＣＨ状態であるＵＥがセルアップデートにおいてＵＲＡ＿ＰＣＨ状態に留まる場合、そのＵＥの情報をコンテキストに追加することはできない。そこで、ＣＲＮＣは、そのような応答をしたＵＥの個数をセル単位およびサービス単位で計数し、一時的にストアする。このときストアされるＵＥの個数が、上述したコンテキスト外端末数である。
【００６３】
（１−６）  セル単位およびサービス単位で、ＣＲＮＣが管理しているコンテキストの第３キーから計数されるＵＥ数（コンテキスト内端末数）と、（１−４）あるいは（１−５）でストアしたコンテキスト外端末数との合計数がしきい値ｈ以上であれば、ＣＲＮＣは、そのＭＢＭＳサービスに対してｐ−ｔ−ｍベアラを使用することを決定する。一方、合計数がｈ未満であれば、ＣＲＮＣはまだ、そのＭＢＭＳサービスに使用するベアラの種別を決定しない。ＣＲＮＣおよびＳＲＮＣは、ＭＢＭＳアクセス情報ＲＲＣメッセージに設定する応答確率を増加させて、再び（１−２）からの処理を繰り返す。
【００６４】
（１−７）  応答確率を上げながら（１−２）〜（１−６）の処理を繰り返し、応答確率を１としても、すなわち全てのＵＥに対して問い合わせを行っても、合計数がｈ未満であれば、ＣＲＮＣは、最終的に、そのＭＢＭＳサービスにｐ−ｔ−ｐベアラを使用することを決定する。例えば、合計数が０であれば、セル内でそのＭＢＭＳサービスにベアラが割り当てないということもできる。
【００６５】
（２）  セッション送信中のベアラ切り替え判定
図５を参照すると、ＲＮＣは、セッション送信中にベアラ判定の起動契機を検出すると（ステップＳ２０１）、ベアラ判定を起動する。例えば、ＵＥがセル間を移動することによりＣＲＮＣの管理化のＵＥ数が一定数を上回ったこと、あるいは下回ったことを起動契機としてもよい。あるいは、ＵＥがセル間を移動することによりＣＲＮＣの管理化のＵＥ数が一定以上変動したことを起動契機としてもよい。あるいは、一定時間間隔でベアラ判定を起動することにしてもよい。
【００６６】
ＲＮＣは、コンテキストに記録されていないＵＥに対してＭＢＭＳアクセス情報ＲＲＣメッセージを送ることにより問い合わせを行う（ステップＳ２０２）。
【００６７】
コンテキストに記録されていないＵＥのうちＩＤＬＥ状態のＵＥは、ＲＲＣ確立要求ＲＲＣメッセージをＲＮＣに応答する（ステップＳ２０３）。コンテキストに記録されていないＵＥのうちＵＲＡ＿ＰＣＨ状態のＵＥは、セルアップデートＲＲＣメッセージをＲＮＣに応答する（ステップＳ２０４）。
【００６８】
それらの応答メッセージを受信したＲＮＣは、セル単位およびサービス単位でコンテキスト内端末数とコンテキスト外端末数の合計数を計数し、ベアラ判定を行う（ステップＳ２０５）。
【００６９】
ベアラ判定において、ｐ−ｔ−ｍベアラを使用することが確定されなければ、応答確率を上げながら、応答確率が１となるまで、あるいはｐ−ｔ−ｍベアラを使用することが確定されるまで、ステップＳ２０２〜Ｓ２０５の処理が繰り返される。
【００７０】
以下にて詳細に説明する。
【００７１】
（２−１）  ｐ−ｔ−ｍベアラでセッション送信中
（２−１−１）  ＣＲＮＣは、ｐ−ｔ−ｍベアラでセッション送信中には、コンテキストの第３キーを基に計数できるＵＥの個数がｈ−ｍ以上であればｐ−ｔ−ｍベアラでセッションの送信を継続し、ｈ−ｍ未満であれば（２−１−２）の処理に移行する。
【００７２】
（２−１−２）  （１−２）と同様に、ＳＲＮＣがＭＢＭＳアクセス情報ＲＲＣメッセージをサービスエリア内の各セルに送信する。
【００７３】
（２−１−３）  （１−３）〜（１−５）と同様に、ＣＲＮＣは、コンテキストを更新すると共に、コンテキスト外端末数を計数し、ストアする。
【００７４】
（２−１−４）  ＣＲＮＣは、セル単位およびサービス単位で、コンテキストの第３キーを基に計数されるコンテキスト内端末数と、（２−１−３）でストアしたコンテキスト外端末数とを加算して得られた合計数がｈ−ｍ以上であれば、そのＭＢＭＳサービスにｐ−ｔ−ｍベアラを使用することを継続する。一方、合計数がｈ−ｍ未満であれば、ＣＲＮＣおよびＳＲＮＣは、ＭＢＭＳアクセス情報ＲＲＣメッセージに設定する応答確率を増加させて、再び（２−１−２）からの処理を行う。
【００７５】
（２−１−５）  応答確率を上げながら（２−１−２）〜（２−１−４）の処理を繰り返し、応答確率を１にしても、すなわち全てのＵＥに対して問い合わせを行っても、合計数がｈ−ｍ未満であれば、ＣＲＮＣは、最終的に、そのＭＢＭＳサービスにｐ−ｔ−ｐベアラを使用することを決定する。例えば、合計数が０であれば、セル内でそのＭＢＭＳサービスが行われないことも可能である。
【００７６】
（２−２）  ｐ−ｔ−ｐベアラでセッション送信中
（２−２−１）  ＣＲＮＣは、ｐ−ｔ−ｐベアラでセッション送信中には、しきい値としてｈ＋ｍを用いる。具体的には、コンテキスト内端末数あるいはそれとコンテキスト外端末数の合計数がｈ＋ｍ以上であれば、ＣＲＮＣは、ＭＢＭＳサービスのベアラをｐ−ｔ−ｐベアラからｐ−ｔ−ｍベアラに切り替える。一方、コンテキスト内端末数とコンテキスト外端末数の合計数がｈ＋ｍ未満であれば、ＣＲＮＣは、ｐ−ｔ−ｐベアラでサービスを継続する。
【００７７】
なお、ＣＥＬＬ＿ＤＣＨ状態のＵＥは、複数のセルにおいて個別チャネルを割り当てられているかも知れない。したがって、ＣＥＬＬ＿ＤＣＨ状態のＵＥは、物理的な個数ではなく、セルにおいてそのＵＥが持っている無線リンク毎に計数される。これは、１個のＵＥが複数のセルでの計数の対象となりうることを意味している。
【００７８】
（２−２−２）  （２−２−１）で計数された合計数が０である場合、ＭＢＭＳサービスに使用するベアラはｐ−ｔ−ｐと判定される。しかし、実際には、そのＭＢＭＳサービスのセッションを送信するためのベアラが、そのセルに存在しないことになる。その場合、それ以後、ＳＲＮＣは、ＣＲＮＣのコンテキストにＵＥが登録されるまで定期的にＭＢＭＳアクセス情報ＲＲＣメッセージをそのセルに送信する。問い合わせの対象は、ＵＲＡ＿ＰＣＨ状態のＵＥとＩＤＬＥ状態のＵＥだけである。
【００７９】
２．  問い合わせにおける応答確率
次に、問い合わせにおける応答確率の制御について説明する。応答確率は、ＭＢＭＳアクセス情報ＲＲＣメッセージに設定される。
【００８０】
標準において、ＭＢＭＳアクセス情報ＲＲＣメッセージに設定する応答確率ＡＰは、応答確率係数ＡＰＦを使って式（１）で表されることが定義されている。
【００８１】
【数１】
2010093480.tif 000003
【００８２】
標準では、ＡＰＦの値を調節することにより、ＡＰを徐々に増加させていき、カウンティングに対して応答するＵＥの個数を適切な数に抑える。これにより、ＵＥからの応答による上り信号が一時に集中しないようにしている。
【００８３】
本実施形態は、ＲＮＣがコンテキストとして管理しているＵＥの情報から計数されるＵＥの個数をベアラ判定に利用し、問い合わせに応答するＵＥの個数を推定することにより応答確率を適切に選択する。それにより、無線環境への影響やネットワークおよび装置の負荷が低減される。また、コンテキストから計数されるＵＥの個数だけでベアラ判定ができるのであれば、ＵＥに対する問い合わせを行う必要もない。本実施形態によれば、無線環境への影響やネットワークおよび装置の負荷が低減されるとともに、ベアラ判定の時間を短縮することもできる。
【００８４】
上記（１−１）のようにＣＲＮＣで管理しているコンテキストにおいて、ベアラ判定の対象となるＭＢＭＳサービスに関する情報のあるＣＥＬＬ＿ＤＣＨ状態、ＣＥＬＬ＿ＦＡＣＨ状態、あるいはＣＥＬＬ＿ＰＣＨ状態のＵＥの合計の個数をｋとする。
【００８５】
（１−１）ではｋ＜ｈの場合に、ＭＢＭＳアクセス情報ＲＲＣメッセージによる問い合わせを使用したプロセスが開始される。同様に、（２−１−１）ではｋ＜ｈ−ｍの場合に、ＭＢＭＳアクセス情報ＲＲＣメッセージによる問い合わせを使用したプロセスが開始される。問い合わせの対象となるＵＥは、ＵＲＡ＿ＰＣＨ状態のＵＥとＩＤＬＥ状態のＵＥのみである。
【００８６】
ＵＲＡ＿ＰＣＨ状態のＵＥとＩＤＬＥ状態のＵＥのうち、ベアラ判定においてコンテキスト内端末数あるいはコンテキスト外端末数として計数される全てのＵＥの個数を“カウンティング対象ＵＥ数”とする。すなわち、カウンティング対象ＵＥ数は、応答確率を“１”に設定して問合せを行ったならば、応答するＵＥの個数である。
【００８７】
応答確率を設定した問い合わせに応答するＵＥの個数（応答ＵＥ数）は、式（２）の左辺の値で近似される。
【００８８】
【数２】
2010093480.tif 000004
【００８９】
上り回線の輻輳を避ける観点より、応答ＵＥ数が、式（２）を満たす範囲で最小の個数となるように応答確率を設定するのが好ましい。
【００９０】
ここでは、まず初期値ＡＰＦ_i0を用いた応答確率ＡＰ（ＡＰＦ_i0）を設定して問い合わせを行い、そのときの応答ＵＥ数をｎとする。ベアラ判定で得られた結果がｋ＋ｎ≧ｈであれば、ＲＮＣは、そのＭＢＭＳサービスにｐ−ｔ−ｍベアラを用いると確定できる。一方、得られた結果がｋ＋ｎ＜ｈであれば、ＲＮＣは、そのＭＢＭＳサービスに用いるベアラの種別を確定するために、応答確率を更新してカウンティングを継続する。
【００９１】
カウンティング対象ＵＥ数≒ｎ／ＡＰ（ＡＰＦ_i0）であったと推定できるので、次の問い合わせには、そのカウンティング対象ＵＥ数を用いて、応答ＵＥ数ｎが式（２）を満たす範囲で最小の個数となるような応答確率を選択すればよい。
【００９２】
ｋ＋ｎ／ＡＰ（ＡＰＦ_i0）≧ｈであれば、ＭＢＭＳサービスにｐ−ｔ−ｍベアラが用いられることが暗示される。次の応答確率としては、式（２）に基づいて、ＡＰ（ＡＰＦ_i0）と１の間にある値が選択される。
【００９３】
一方、ｋ＋ｎ／ＡＰ（ＡＰＦ_i0）＜ｈであれば、ｋとカウンティング対象ＵＥ数との合計値が、最後まで、ｈに満たないことが暗示される。その場合、次の問い合わせでは、ＡＰＦ＝０に設定、つまりＡＰ（ＡＰＦ）＝１に設定すればよい。
【００９４】
そして、ＭＢＭＳサービスの受信を希望する全ＵＥからの応答を得て、ＵＥ数を計数し、ベアラの種別を決定すればよい。
【００９５】
３．  ＡＰＦの初期値ＡＰＦ_i0の値の設定
上述したＰＦの初期値ＡＰＦ_i0をどのように設定するかについて説明する。
ベアラの種別を判定するためのしきい値ｈは、ｐ−ｔ−ｍベアラのビットレートより推定することができる。標準化されているｐ−ｔ−ｍベアラのビットレートより推定すると、しきい値ｈは２〜８程度が適切と推定できる。
【００９６】
ｋ＜ｈである場合、ＭＢＭＳサービスに関連するＣＥＬＬ＿ＤＣＨ状態、ＣＥＬＬ＿ＦＡＣＨ状態、およびＣＥＬＬ＿ＰＣＨ状態のＵＥの個数の合計数がしきい値ｈに満たない。ｈとｋの差が大きい場合には、問い合わせに応答するＵＥの個数が少ない可能性が高い。そのような場合に、小さい応答確率ＡＰ（ＡＰＦ＿i0）を設定すると、カウンティング対象ＵＥ数の推定が適切に行えなくなる。そのため、初期値ＡＰＦ＿i0は、カウンティング対象ＵＥ数の推定が適切に行える程度に高い値にすべきである。
【００９７】
実際のシステムではシステム構成やＵＥの在圏状況などによって適切な初期値ＡＰＦ＿i0が変わるので、システムに合わせて初期値の算出式あるいは初期値決定用テーブルが設定される。
【００９８】
なお、本実施形態では、コンテキストから計数するＵＥをＣＥＬＬ＿ＤＣＨ状態、ＣＥＬＬ＿ＦＡＣＨ状態、またはＣＥＬＬ＿ＰＣＨ状態のＵＥとし、ＭＢＭＳアクセス情報ＲＲＣメッセージによる問い合わせの対象とするＵＥをＵＲＡ＿ＰＣＨ状態またはＩＤＬＥ状態のＵＥとした。しかし、本発明はこれに限定されるものではない。
【００９９】
コンテキストから計数するＵＥの状態と、ＭＢＭＳアクセス情報ＲＲＣメッセージによる問い合わせの対象とするＵＥの状態との組み合わせを他の組み合わせにしてもよい。例えば、カウンティング対象となるＭＢＭＳサービスについて情報のあるＣＥＬＬ＿ＤＣＨ状態のＵＥの個数をｋとし、ＭＢＭＳアクセス情報ＲＲＣメッセージを使用したプロセスによるカウンティング対象のＵＥをＣＥＬＬ＿ＤＣＨ状態以外の全ての状態のＵＥとしてもよい。ＭＢＭＳセッション開始ＲＡＮＡＰメッセージ内に示されるセッション繰り返し数が２回目以上もしくはセッション繰り返し数が不明な場合、１回目のセッション送信でサービスを受信完了している可能性を考慮したものとなる。
【０１００】
以上、本発明の実施形態について述べてきたが、本発明は、これらの実施形態だけに限定されるものではなく、本発明の技術思想の範囲内において、これらの実施形態を組み合わせて使用したり、一部の構成を変更したりしてもよい。
【図面の簡単な説明】
【０１０１】
【図１】３ＧＰＰ移動通信システムの構成を示すブロック図である。
【図２】ＲＮＣ１６の構成を示すブロック図である。
【図３】本実施形態によるＲＮＣ１６の動作を示すフローチャートである。
【図４】セッション開始時のベアラ判定の一例を示すシーケンス図である。
【図５】セッション送信中のベアラ判定の一例を示すシーケンス図である。
【符号の説明】
【０１０２】
１１    ＣＮ
１２    ＵＴＲＡＮ
１３    パケット網
１４    ＧＧＳＮ
１５    ＳＧＳＮ
１６    ＲＮＣ
１７    ＮｏｄｅＢ
１８    ＵＥ
２１    端末管理部
２２    端末計数部
２３    ベアラ判定部
２４    問い合わせ部
【図１】
2010093480.tif 000005
【図２】
2010093480.tif 000006
【図３】
2010093480.tif 000007
【図４】
2010093480.tif 000008
【図５】
2010093480.tif 000009