(57)【特許請求の範囲】
【請求項１】
ネットワーク上に置かれる無線ネットワーク制御装置であって、
前記無線ネットワーク制御装置に接続される各ユーザ信号データの変換処理を行う複数のユーザ信号データ変換部と、
各ユーザの特徴を抽出しトラヒック収集を行うトラヒック統計部と、
前記トラヒック統計部により収集された各ユーザの特徴を格納しておくユーザ情報管理データベースと、
前記複数のユーザ信号データ変換部に対し、要求される必要帯域確保のためのリソース制御を行うリソース制御部と、
前記ユーザ情報管理データベースに前記ユーザを特徴づける情報を格納して管理し、各ユーザの使用状況に応じた必要帯域の算出を行い、前記算出した必要帯域の確保を前記リソース制御部に要求し、要求された帯域確保の制御の際に、該当のユーザ信号データ変換部の帯域確保が不能である場合、他のユーザ信号データ変換部で新たに帯域を確保するように制御するユーザリソース管理部とを有する、
ことを特徴とする無線ネットワーク制御装置。
【請求項２】
請求項１において、
前記トラヒック統計部は、更に各ユーザの位置別のトラヒック統計を集計する位置統計手段を有し、前記ユーザ情報管理データベースに、前記位置統計手段により集計されたユーザ毎の位置別トラヒック統計を格納し、
前記ユーザリソース管理部は、前記ユーザ情報管理データベースに格納された各ユーザの集計された位置別トラヒックに適して前記リソース制御部に帯域確保の要求を行う帯域確保を行う
ことを特徴とする無線ネットワーク制御装置。
【請求項３】
請求項１において、
前記トラヒック統計部は、更に各ユーザの時刻別のトラヒック統計を集計する時刻統計手段を有し、前記ユーザ情報管理データベースに、前記時刻統計手段により集計されたユーザ毎の時刻別トラヒック統計を格納し、
前記ユーザリソース管理部は、前記ユーザ情報管理データベースに格納された各ユーザの集計された時刻別トラヒックに適した帯域確保を行う
ことを特徴とする無線ネットワーク制御装置。
【請求項４】
請求項１乃至３のいずれかにおいて、
前記ユーザリソース管理部から前記リソース制御部に対する帯域確保要求に判定回数閾値が付加され、
前記リソース制御部は、前記ユーザ信号データ変換部から一定周期でトラヒック報告を受け、トラヒック報告の都度、現トラヒックを維持可能な帯域と現在確保している帯域を比較し、前記判定回数閾値以上、現トラヒックを維持可能な帯域の方が小さいという比較判断が連続したときに、現在確保している帯域を、現トラヒックを維持可能な帯域に変更する制御を行う
ことを特徴とする無線ネットワーク制御装置。
【請求項５】
請求項１において、
前記リソース制御部は、ユーザが無通信状態に遷移する場合、前記複数のユーザ信号データ変換部の全てに収容される無通信状態ユーザの利用状況に基づき、呼数が均等となるように無通信状態呼を前記複数のユーザ信号データ変換部に分散するように制御することを特徴とする無線ネットワーク制御装置。
【請求項６】
請求項１及び４のいずれかにおいて、
前記ユーザリソース管理部は、位置統計管理手段を有し、前記ユーザ情報管理データベースに格納されたユーザ毎の位置別トラヒックから、その増減を予測し、
前記リソース制御部は、ユーザの移動先のトラヒックに応じた帯域を前記ユーザ信号データ変換部に確保するように制御することを特徴とする無線ネットワーク制御装置。
【請求項７】
請求項１及び５のいずれかにおいて、
前記ユーザリソース管理部は、時刻統計管理手段を有し、前記ユーザ情報管理データベースに格納されたユーザ毎の時刻別トラヒックから、その増減を予測し、
前記リソース制御部は、ユーザ毎の時刻別トラヒックに応じた帯域を前記ユーザ信号データ変換部に確保するように制御することを特徴とする無線ネットワーク制御装置。
【請求項８】
請求項１及び５のいずれかにおいて、
前記ユーザリソース管理部は、ユーザ契約情報管理手段を有し、前記ユーザ情報管理データベースに格納されたユーザ毎の契約内容に応じた必要帯域を予測し、
前記リソース制御部は、ユーザ毎の契約内容に応じた必要帯域を前記ユーザ信号データ変換部に確保するように制御することを特徴とする無線ネットワーク制御装置。
【発明の詳細な説明】
発明の背景
【技術分野】  本発明は、Ｗ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ−Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）ネットワーク上の無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）に関する。
【背景技術】  Ｗ−ＣＤＭＡのモバイルネットワークは、図１に示すように、移動端末（ＭＳ：Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）、無線基地局（ＢＴＳ：Ｂａｓｅ  Ｔｒａｎｓｃｅｉｖｅｒ  Ｓｔａｔｉｏｎ）、無線ネットワーク制御装置（ＲＮＣ）、無線パケット通信ノード（ＳＧＳＮ：Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｅｔｗｏｒｋ、ＧＧＳＮ：Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｅｔｗｏｒｋ）及びホームロケーションレジスタ（ＨＬＲ）等で構成されている。
無線ネットワーク制御装置ＲＮＣは、モバイルネットワーク即ち、一例として携帯電話システムにおいて、無線基地局ＢＴＳにおける制御即ち、発着信接続制御、終話制御、ダイバーシチハンドオーバー制御に対応する機能を果たしている。
また、無線ネットワーク制御装置ＲＮＣは、コアネットワーク（ＣＮ）側と無線区間（ＲＡＮ）側との間でプロトコル変換を行い、各区間に最適なユーザ信号（Ｕ−Ｐｌａｎｅ）を生成するという機能も果たしている。
従来技術における無線ネットワーク制御装置ＲＮＣの構成例を図２に示す。
第３世代パートナシップ（以下、３ＧＰＰという）勧告では無線区間におけるデータ転送を効率的に行う為に、トラヒックの変化に応じたパケット呼のチャネル切り替えを標準化しており、無線ネットワーク制御装置ＲＮＣにおいてチャネル種別において必要とする帯域を確保する。
Ｗ−ＣＤＭＡにおいて定義されているチャネル種別のうち、ユーザがパケット接続時に遷移するチャネルは以下の通りである。
・ＤＣＨ（個別ｃｈ）：最高帯域から、ある帯域以上のデータ転送状態
・ＦＡＣＨ／ＲＡＣＨ（共通ｃｈ）：ある帯域以下から、最低帯域のデータ転送状態
・ＰＣＨ（Ｐａｇｉｎｇ  ｃｈ）：無通信（データ転送無し）状態
無線ネットワーク制御装置ＲＮＣでは本勧告に準拠したチャネル切り替え制御を実施している。またこれに加え、各チャネル種別に応じた必要帯域の確保を行っている。
そして、データ転送量が多くなるに従い必要帯域も大きくなるため、チャネルの切り替えはユーザデータの転送量の増減を契機として行っている。
図２に示すように、無線ネットワーク制御装置ＲＮＣでは信頼性を高めるために、複数枚で構成されたユーザ信号（Ｕ−Ｐｌａｎｅ）データ変換部１００により冗長性を持たせ、帯域管理やプロトコル変換を実現している。Ｕ−Ｐｌａｎｅデータ変換部１００に収容される呼は、呼が切断されるまでの間、同一のＵ−Ｐｌａｎｅデータ変換部内において収容されて管理される。
さらに、上記の３つのチャネルに加えて、現行の最高帯域を超える、下り高速データ転送状態のチャネルとしてＤＳＣＨ（Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  ＣＨ）が３ＧＰＰ勧告に新たに標準化された。これは、ＨＳＤＰＡ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）という新たな通信方式を実現するためのチャネルであり、ＨＳＤＰＡは下りの速度が十数Ｍｂｐｓ以上という高速通信が可能になる通信方式である。
上記の通り、パケット呼のチャネル切り替えは、通常、ユーザデータの転送量の増減を契機に実施され、各ユーザのデータ転送量に適したチャネル切り替えを行っている。そして、無線ネットワーク制御装置ＲＮＣの装置内部の構成としては、システムの信頼性を高める為に、ユーザデータを変換するＵ−Ｐｌａｎｅデータ変換部１００を複数枚設置し、冗長性を持たせたシステム構成とするのが一般的な装置構成である。
しかしながら、各Ｕ−Ｐｌａｎｅデータ変換部１００において設定可能なチャネル数（ユーザ数）、及びＵ−Ｐｌａｎｅデータ変換部１００の各々において確保可能な帯域はそれぞれ有限である。
今後、パケット呼の最高帯域の拡大（ＨＳＤＰＡ）が予定されているが、これに伴い、常時接続等の新たなサービス形態が追加されると考えられる。
しかし、このサービス形態を利用するユーザは、常時に通信を行うわけではない為、接続はしていてもデータ転送は行っていないという、無通信状態（ＰＣＨ）のユーザが増大することが今後十分考えられる。かかる場合、従来技術においては下記のような不都合が生じる。
第１にユーザが使用するデータ転送量の増加に対し、必要な最大帯域の確保ができず、データ転送に遅延が生じる。
図３は、かかる第１の不都合を説明する図であり、Ｕ−Ｐｌａｎｅデータ変換部１００のリソースの状態を示す図である。図３Ａに示すように、個別チャネルＤｃｈと共通チャネルＣｃｈが使用されている状態において、所定の帯域幅を要するリソースの使用要求がある場合で、図３Ｂに示すように最大リソースＭａｘを超えてしまうと、要求があった所定の帯域幅の確保ができない。
かかる場合、データを分割して転送することになるが、このために遅延が生じてしまう。
また、別の不都合である第２の問題として、ユーザ数増大によりＵ−Ｐｌａｎｅデータ変換部１００では確保可能な総帯域に余裕があるにも関わらず、ユーザ数制限によって新たなユーザの使用が制限されるという問題がある。
図４は、かかる第２の不都合を説明する図である。図４において、無通信状態のユーザ数が多く、無通信状態呼Ｘを含めリソース未使用数が多く、結果としてリソースの最大値Ｍａｘを既に超えている場合、新たなユーザの使用が制限される。
今後最高帯域拡大の規格（例えばＨＳＤＰＡ）の導入により、上記不都合の第１の問題に示す、ユーザが使用するデータ転送量の急激な変化（増加）や、不都合の第２の問題に示す、装置が収容する無通信状態のパケット交換ユーザの急増が予測される。これにより、上記に示した問題が顕著に現れることになる。
上記問題を解決する１つの方法として、Ｕ−Ｐｌａｎｅデータ変換部１００の物理的な増加や無線ネットワーク制御装置ＲＮＣの増設により十分な帯域を確保することが考えられる。しかし、かかる場合は、コスト面において有効な手法とは言えず、現実的な問題解決方法とは言えない。
上記に関連して従来技術として、通信ネットワークにおけるパケット交換接続の管理に関する技術が知られている（特許文献１）。かかる従来技術は、リソースが不足のとき、アイドル状態に応じて、サービスノード（ＳＧＳＮ）と無線ネットワークサブシステム（ＲＮＣ）との通信接続を解除または再接続する技術が知られている（特許文献１）。
また、パケット方式の自動車電話において、トラフィックが多い場合に、チャネルを有効に利用して通信速度の低下を防止する技術が知られている（特許文献２）。
しかし、上記特許文献に記載される技術においては、Ｕ−Ｐｌａｎｅデータ変換部１００において設定可能なチャネル数（ユーザ数）、及びＵ−Ｐｌａｎｅデータ変換部１００の各々において確保可能な帯域はそれぞれ有限であること、更に、今後、パケット呼の最高帯域の拡大（ＨＳＤＰＡ）が予定されているが、これに伴い、常時接続等の新たなサービス形態が追加されることを考慮した解決手段を与えるものではない。
【特許文献１】      特許第３３９０７４３号公報
【特許文献２】      特開平８−３３０３４号公報
発明の概要
したがって、本発明の目的は、無線ネットワーク制御装置ＲＮＣにおいて、物理的実装の増加による解決ではなく、ユーザの利用形態等の特徴を考慮して使用帯域の有効的利用を行うことにより、ユーザが使用するデータ転送量の急激な変化（増加）や、装置が収容する無通信状態のパケット交換ユーザの急増に対応可能とするものである。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第１の態様は、ネットワーク上に置かれる無線ネットワーク制御装置であって、前記無線ネットワーク制御装置に接続されるユーザを特徴付ける情報を管理するユーザリソース管理部と、それぞれユーザ信号データの変換処理を行う複数のユーザ信号データ変換部と、前記複数のユーザ信号データ変換部に対し、帯域確保のためのリソース制御を行うリソース制御部を有し、前記リソース制御部は、前記複数のユーザ信号データ変換部の間で呼の移行を制御して前記ユーザの特徴に適した帯域確保を行うことを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第２の態様は、第１の態様において、さらに、各ユーザの特徴を抽出するトラヒック収集を行うトラヒック統計部と、前記トラヒック統計部により収集された各ユーザの特徴を前記ユーザリソース管理部の制御により格納するユーザ情報管理データベースを有し、前記ユーザリソース管理部は、前記ユーザ情報管理データベースに格納された各ユーザの特徴に対応して前記リソース制御部に帯域確保の要求を行うことを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第３の態様は、第２の態様において、前記トラヒック統計部は、更に各ユーザの位置別のトラヒック統計を集計する位置統計手段を有し、前記ユーザ情報管理データベースに、前記位置統計手段により集計されたユーザ毎の位置別トラヒック統計を格納し、前記ユーザリソース管理部は、前記ユーザ情報管理データベースに格納された各ユーザの集計された位置別トラヒックに適して前記リソース制御部に帯域確保の要求を行う帯域確保を行うことを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第４の態様は、第２の態様において、前記トラヒック統計部は、更に各ユーザの時刻別のトラヒック統計を集計する時刻統計手段を有し、前記ユーザ情報管理データベースに、前記時刻統計手段により集計されたユーザ毎の時刻別トラヒック統計を格納し、前記ユーザリソース管理部は、前記ユーザ情報管理データベースに格納された各ユーザの集計された時刻別トラヒックに適した帯域確保を行うことを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第５の態様は、第１乃至３のいずれかの態様において、前記ユーザリソース管理部は、前記ユーザ情報管理データベースに格納された各ユーザの使用状況に応じた必要帯域の算出を行い、前記算出した必要帯域の確保を前記リソース制御部に要求することを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第６の態様は、第５の態様において、前記ユーザリソース管理部から前記リソース制御部に要求された帯域確保の制御の際に、該当のユーザ信号データ変換部の帯域確保が不能である場合、他のユーザ信号データ変換部で新たに帯域を確保するように制御することを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第７の態様は、第６の態様において、前記ユーザリソース管理部から前記リソース制御部に対する帯域確保要求に判定回数閾値が付加され、前記リソース制御部は、前記ユーザ信号データ変換部から一定周期でトラフィック報告を受け、トラフィック報告の都度、現トラヒックを維持可能な帯域と現在確保している帯域を比較し、前記判定回数閾値以上、現トラヒックを維持可能な帯域の方が小さいという比較判断が連続したときに、現在確保している帯域を現トラヒックを維持可能な帯域に変更する制御を行うことを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第８の態様は、第１の態様において、前記リソース制御部は、ユーザが無通信状態に遷移する場合、前記複数のユーザ信号データ変換部の全てに収容される無通信状態ユーザの利用状況に基づき、呼数が均等となるように無通信状態呼を前記複数のユーザ信号データ変換部に分散するように制御することを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第９の態様は、第１−２及び５−７の態様のいずれかにおいて、前記ユーザリソース管理部は、位置統計管理手段を有し、前記ユーザ情報管理データベースに格納されたユーザ毎の位置別トラヒックから、その増減を予測し、前記リソース制御部は、ユーザの移動先のトラヒックに応じた帯域を前記ユーザ信号データ変換部に確保するように制御することを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第１０の態様は、第１−２及び５−７の態様のいずれかにおいて、前記ユーザリソース管理部は、時刻統計管理手段を有し、前記ユーザ情報管理データベースに格納されたユーザ毎の時刻別トラヒックから、その増減を予測し、前記リソース制御部は、ユーザ毎の時刻別トラヒックに応じた帯域を前記ユーザ信号データ変換部に確保するように制御することを特徴とする。
上記本発明の目的を達成する無線ネットワーク制御装置ＲＮＣの第１１の態様は、第１−２及び５−７の態様のいずれかにおいて、前記ユーザリソース管理部は、ユーザ契約情報管理手段を有し、前記ユーザ情報管理データベースに格納されたユーザ毎の契約内容に応じた必要帯域を予測し、前記リソース制御部は、ユーザ毎の契約内容に応じた必要帯域を前記ユーザ信号データ変換部に確保するように制御することを特徴とする。
本発明の特徴は、以下に図面に従い説明される発明の実施の形態例から更に明らかになる。
【図面の簡単な説明】  図１は、Ｗ−ＣＤＭＡのモバイルネットワークの構成例を示す図である。
図２は、従来技術における無線ネットワーク制御装置ＲＮＣの構成例を示す図である。
図３は、第１の不都合を説明する図であり、Ｕ−Ｐｌａｎｅデータ変換部１００のリソースの状態を示す図である。
図４は、第２の不都合を説明する図である。
図５は、本発明に従う無線ネットワーク制御装置の構成例ブロック図である。
図６は、位置別トラフィック予想に夜帯域制御の例を示すシーケンスフローである。
図７は、第４，１０の特徴である、時刻別トラヒック予想によって帯域制御を行うシーケンスを示す図である。時刻別トラヒック予想による帯域制御シーケンスである。
図８は、第１１の特徴である、契約別トラヒック予想によって帯域制御を行うシーケンスを示す図である。
図９は、呼を移行させることで、帯域の確保を実現することを説明する図である。
図１０は、第６の特徴を説明する処理フローである。
図１１は、第７の特徴を説明するシーケンスフローである。
図１２は、第７の特徴を説明する処理フローである。帯域解放時のフロー図である。
図１３は、第８の特徴を説明する処理フローである。
図１４は、トラヒック統計ＤＢ３７０の例を示す図である。
図１５は、位置別トラヒック統計データの一例である。
図１６は、トラフィックに応じた確保リソースの対応テーブルを示す図である。
図１７は、各ユーザ信号データ変換部での使用率と収容呼数を示す一例である。
図１８は、時刻別トラヒックデータである。
図１９は、加入者情報の例を示す図である。
図２０は、ユーザの契約種別毎に確保する帯域を示すテーブルである。
図２１は、ユーザの契約種別による帯域以上を確保するためのＵ−Ｐｌａｎｅリソース制御部３５０のリソース制御フローを示す図である。
図２２は、帯域の制御要求に対して優先度を設けることを説明する図である。
図２３は、Ｕ−Ｐｌａｎｅデータ変換部３６０が、Ｕ−Ｐｌａｎｅリソース制御部３５０に対して一定周期で行うユーザのトラヒック報告を示す図である。
図２４は、無通信状態呼を分散する処理シーケンスを示す図である。
図２５は、図２４のシーケンスに従う無通信状態呼の遷移を説明する図である。
発明の実施の形態例
以下に図面に従い、本発明の実施の形態例を説明する。なお、実施の形態例は、本発明の理解のためのものであって、本発明の適用がこれらに限定されるものではない。
図５に本発明に従う無線ネットワーク制御装置ＲＮＣの構成例ブロック図を示す。なお、図２に示した従来の無線ネットワーク制御装置ＲＮＣの構成に対し、本発明に従い新たに追加された機能部は、二重枠で囲い、更新された機能を有する部位は太枠で囲って示されている。
ここで、本発明の実施例の説明に先立って、図５に示す本発明を適用する無線ネットワーク制御装置ＲＮＣを構成する各機能ブロックの機能について、概略説明しておく、
１）外部ＩＦ部３１０：対向ノードとのメッセージの送受信をおこない、各部位への通知を行う。
２）主制御部３２０：無線ネットワーク制御装置の中心となる機能を果たす制御部である。さらに、主制御部３２０は次の機能部で構成される。
３２１呼処理部：呼の接続制御を行い、ユーザを特徴付けるデータとして必要となる加入者情報をトラヒック統計部３２３、ユーザリソース管理部３３０に通知する。また、トラヒックに応じたチャネル種別を決定し、切り替えるチャネルに対応するリソース確保の要求をＵ−Ｐｌａｎｅリソース制御部３５０に通知し、無線チャネル制御部３２２にチャネル切り替え命令を通知する。
無線チャネル制御部３２２：呼制御部３２１からのチャネル切り替え命令に応じて、呼のチャネル切り替え制御を行う。
トラヒック統計部３２３：位置統計手段３２４及び、時刻統計手段３２５を具備する。Ｕ−Ｐｌａｎｅデータ変換部３６０からのトラヒック報告を受け、トラヒック統計ＤＢ３７０へのデータの格納・管理を行う。
位置統計手段３２４：位置管理部３２６あるいは呼処理部３２１からユーザの位置登録情報を受信・管理し、トラヒック統計ＤＢ３７０のトラヒック統計データと位置情報との関連付けを行う。関連付けた位置別トラヒックデータをユーザリソース管理部３３０に通知する。
時刻統計手段３２５：トラヒック統計ＤＢ３７０のトラヒック統計データと現時刻との関連付けを行う。関連付けた時刻別トラヒックデータを一定周期毎にユーザリソース管理部３３０に通知する。
位置管理部３２６：一定周期、あるいは、ユーザの移動に伴い位置登録エリアが変化した場合に、位置登録情報の通知を受け、位置情報の更新を行う。また位置登録情報を管理し、位置統計手段３２４に必要なデータを抽出して通知する。
３）ユーザリソース管理部３３０：呼処理部３２１、位置統計手段３２４、時刻統計手段３２５からユーザの利用状況を特徴付けるデータを受信し、ユーザ情報管理ＤＢ３４０に格納・管理を行う。
ユーザ契約情報管理手段３３１：加入者の契約情報を管理し、契約内容に基づいた帯域制御条件をＵ−Ｐｌａｎｅリソース制御部３５０に通知する。
時刻統計管理手段３３２：ユーザ情報管理ＤＢ３４０の時刻別トラヒック統計データを管理し、ユーザの現時刻に対応するＤＢからのトラヒック統計に応じて現時刻のトラヒックを予測し、Ｕ−Ｐｌａｎｅリソース制御部３５０へ該ユーザ呼のリソース確保を要求する。
位置統計管理手段３３３：ユーザ情報管理ＤＢ３４０の位置別トラヒック統計データを管理し、位置統計手段３２４からユーザの現在位置を受け、その位置に対応するユーザ情報管理ＤＢ３４０のトラヒック統計に応じて現在位置のトラヒックを予測し、該ユーザ呼のリソース確保を要求する。
４）ユーザ情報管理ＤＢ３４０：ユーザ加入者情報のほか、ユーザ毎の時刻別トラヒック統計や位置別トラヒック統計のデータを格納する。
５）Ｕ−Ｐｌａｎｅリソース制御部３５０：呼処理部３２１、時刻統計管理手段３３２、位置統計管理手段３３３からの要求を受けてＵ−Ｐｌａｎｅデータ変換部３６０のリソース制御を行う。またこの場合、ユーザ契約情報管理手段３３１からユーザ毎のリソース制御条件を受け、前述の要求を受けた場合にはリソース制御条件に沿ってリソース制御を行う。
また、既に接続している呼がチャネル変更する時に、前記呼が収容されているＵ−Ｐｌａｎｅデータ変換部３６０内においてリソース確保が不可能な場合、前記呼を他のＵ−Ｐｌａｎｅデータ変換部３６０へ移行させる。
６）Ｕ−Ｐｌａｎｅデータ変換部３６０：ユーザデータの変換処理を行う。また、定期的にトラヒック報告をトラヒック統計部３２３に報告する。
７）トラヒック統計ＤＢ３７０：各ユーザのトラヒック統計を格納する。
次に、上記無線ネットワーク制御装置ＲＮＣの構成に基づく本発明の特徴を説明する。
［第１の特徴］
第１の特徴は、ユーザの位置別トラフィック予測に応じたリソースの確保を可能とするものである。
図６は、位置別トラフィック予想による帯域制御の例を示すシーケンスフローである。このシーケンスフローに従い、図５に示した無線ネットワーク制御装置ＲＮＣの動作を説明する。
無線ネットワーク制御装置ＲＮＣが対向（ノード）装置より加入者情報を含む呼設定要求を外部インターフェース（ＩＦ）部３１０で受信した場合（ステップＳ１）、外部インターフェース（ＩＦ）部３１０は、主制御部３２０の呼処理部３２１にメッセージ受信を通知する（ステップＳ２）。
呼処理部３２１は、呼設定要求が行われたことを位置管理部３２６に通知し（ステップＳ３）、位置管理部３２６はユーザの位置情報をトラフィック統計部３２３の位置統計手段３２４へ通知し（ステップＳ４）、同時にユーザリソース管理部３３０の位置統計管理手段３３３に通知する（ステップＳ５）。
これにより位置統計手段３２４はトラヒック収集を開始する。また、この時位置統計管理手段３３３は、ユーザ情報管理ＤＢ３４０を参照し（ステップＳ６）、現在位置に対する集計済のトラヒック統計の有無を確認し、現在の位置情報からトラヒックが予測できる場合、統計に応じたリソース確保要求をＵ−Ｐｌａｎｅリソース制御部３５０に通知する（ステップＳ７）。
要求を受けたＵ−Ｐｌａｎｅリソース制御部３５０はＵ−Ｐｌａｎｅデータ変換部３６０のリソース確保を実施する（ステップＳ８）。
さらに、無線ネットワーク制御装置ＲＮＣは、定期的あるいはユーザの位置に変化があった場合、ユーザの位置登録情報を外部ＩＦ部３１０より受信する（ステップＳ９）。外部ＩＦ部３１０は位置登録情報を位置管理部３２６に通知し（ステップＳ１０）、位置管理部３２６は位置情報を位置統計手段３２４に通知する（ステップＳ１１）。
位置統計手段３２４ではトラヒック統計ＤＢ３７０において変化前の位置情報におけるトラヒック統計を参照・集計し（ステップＳ１２）、ユーザリソース管理部３３０に通知する（ステップＳ１３）。位置別トラヒック統計を受信したユーザリソース管理部３３０はデータをユーザ情報管理ＤＢ３４０に格納する（ステップＳ１４）。
その後の処理は、上記呼設定要求が出された場合と同様である（ステップＳ５〜Ｓ８）。
上記の通り、ユーザの位置別トラヒックを随時、ユーザ情報管理ＤＢ３４０に格納していくことにより、ユーザの位置別トラヒック予測に応じたＵ−Ｐｌａｎｅデータ変換部３６０のリソース確保が可能となる。
［第２の特徴］
第２の特徴は、ユーザの時刻別トラフィック予測に応じたリソースの確保を可能とするものである。
図７は、第２の特徴である、時刻別トラヒック予想によって帯域制御を行うシーケンスを示す図である。無線ネットワーク制御装置ＲＮＣの装置構成は、図５に示したものと同様である。
無線ネットワーク制御装置ＲＮＣが対向ノードＳＧＳＮより加入者情報を含む呼設定要求を受信した場合（ステップＳ２１）、外部ＩＦ部３１０は呼処理部３２１にメッセージ受信を通知する（ステップＳ２２）。
呼処理部３２１は呼設定が行われたことを時刻統計手段３２５に通知し（ステップＳ２３）、時刻統計手段３２５は、時刻別でのトラヒック収集を開始する。
また、時刻統計手段３２５は呼接続中において、一定周期毎にトラヒック統計ＤＢ３７０を参照し（ステップＳ２４）、時刻別におけるトラヒック統計を参照・集計し、時刻別トラヒック統計をユーザリソース管理部３３０に通知する（ステップＳ２５）。したがって、ユーザリソース管理部３３０は通知された時刻別トラヒック統計をユーザ情報管理ＤＢ３４０に格納する（ステップＳ２６）。
また、時刻統計管理手段３３２は一定周期毎にユーザ情報管理ＤＢ３４０を参照し（ステップＳ２７）、現在の時刻からトラヒックの予測ができる場合、時刻別トラヒック統計に応じたリソース確保要求をＵ−Ｐｌａｎｅリソース制御部３５０に通知する（ステップＳ２８）。要求を受けたＵ−Ｐｌａｎｅリソース制御部３５０は、Ｕ−Ｐｌａｎｅデータ変換部３６０のリソース確保を実施する（ステップＳ２９）。
また、図６に示した位置別トラヒック統計による予測と同様、呼設定時にユーザリソース管理部３３０に過去の同時刻のトラヒック統計が既に存在する場合、呼設定時を契機に時刻別のトラヒック予測も行う。
上記のように、ユーザの時刻別トラヒックを随時、ユーザ情報管理ＤＢ３４０に格納していくことにより、ユーザの時刻別トラヒック予測に応じたＵ−Ｐｌａｎｅデータ変換部３６０のリソース確保が可能となる。
［第３の特徴］
第３の特徴は、ユーザの契約内容に応じたリソースの確保を可能とするものである。
図８は、第３の特徴である、契約別トラヒック予想によって帯域制御を行うシーケンスを示す図である。ここでも無線ネットワーク制御装置ＲＮＣの装置構成は、図５に示したものと同様である。
無線ネットワーク制御装置ＲＮＣが対向ノードより加入者情報を含む呼設定要求を受信した場合（ステップＳ３１）、外部ＩＦ部３１０は呼処理部３２１にメッセージ受信を通知する（ステップＳ３２）。呼処理部３２１は呼設定要求のうち、必要な加入者情報を抽出し、ユーザリソース管理部３３０に加入者情報を通知する（ステップＳ３３）。
受信したユーザリソース管理部３３０はこの通知されたデータをユーザ情報管理ＤＢ３４０に格納する（ステップＳ３４）。
また、ユーザ契約情報管理手段３３１はユーザの契約内容により、条件に応じたリソース確保要求をＵ−Ｐｌａｎｅリソース制御部３５０に通知する（ステップＳ３５）。要求を受けたＵ−Ｐｌａｎｅリソース制御部３５０は要求に応じたＵ−Ｐｌａｎｅデータ変換部３６０のリソース確保を実施する（ステップＳ３６）。
上記、ユーザの契約情報をユーザ情報管理ＤＢ３４０に格納することで、ユーザの契約内容に応じたＵ−Ｐｌａｎｅデータ変換部３６０のリソース確保が可能となる。
［第４の特徴］
第４の特徴は、帯域が確保可能なＵ−Ｐｌａｎｅデータ変換部３６０により帯域を確保することにより、確保帯域の拡大を行うものである。
トラヒック増加によるチャネル遷移や、予測による確保帯域の拡大を行う場合、図３において説明したように、呼を収容するＵ−Ｐｌａｎｅデータ変換部３６０において当該呼が必要とする帯域が不足する場合がある。
かかる場合、図９に示すように、Ｕ−Ｐｌａｎｅリソース制御部３５０により、呼の必要とする帯域を確保できる複数あるうちの他のＵ−Ｐｌａｎｅデータ変換部３６０を検索し、帯域が確保可能なＵ−Ｐｌａｎｅデータ変換部３６０に帯域を確保し、これに当該呼を移行させることで、帯域の確保が実現することが可能となる。
すなわち、図１０は、第４の特徴を説明する処理フローである。図９において、Ｕ−Ｐｌａｎｅデータ変換部３６０として、２つのＵ−Ｐｌａｎｅデータ変換部Ａ，Ｂを考える。Ｕ−Ｐｌａｎｅデータ変換部Ａはリソースの使用率が高く、他方のＵ−Ｐｌａｎｅデータ変換部Ｂはリソースの使用率が低い場合である。
リソース確保要求があると（ステップＳ４０）、第１のＵ−Ｐｌａｎｅデータ変換部Ａで帯域確保が可能か否かを判断する（ステップＳ４１）。帯域確保が可能であれば（ステップＳ４１、可能）そのまま、Ｕ−Ｐｌａｎｅデータ変換部Ａで帯域を確保する（ステップＳ４２）。
帯域確保ができなければ（ステップＳ４１、不可能）、複数のＵ−Ｐｌａｎｅデータ変換部のうちＵ−Ｐｌａｎｅデータ変換部Ｂを選択する（ステップＳ４３）。そして、選択されたＵ−Ｐｌａｎｅデータ変換部Ｂに帯域を確保する（ステップＳ４４）。
次いで、帯域確保を行ったＵ−Ｐｌａｎｅデータ変換部ＢにＵ−Ｐｌａｎｅデータ変換部Ａから呼を移動し（ステップＳ４５）、Ｕ−Ｐｌａｎｅデータ変換部Ａの呼を開放する（ステップＳ４６）。
［第５の特徴］
第５の特徴は、帯域解放を行うタイミングをユーザの特徴に応じて調整することを可能とすることにある。
図１１、図１２は、第５の特徴を説明するそれぞれシーケンスフローと処理フローである。無線ネットワーク制御装置ＲＮＣの装置構成は、図５に示したものと同様である。
Ｕ−Ｐｌａｎｅリソース制御部３５０はユーザリソース管理部３３０より、トラヒック予測によるリソース確保要求（リソースを拡大する要求）を受信する（ステップＳ５０）。その際、ユーザリソース管理部３３０はユーザ管理情報ＤＢ３４０を参照し、要求する帯域を維持する判定閾値も付加情報として通知する。
Ｕ−Ｐｌａｎｅリソース制御部３５０では要求の帯域確保を行った（ステップＳ５１）後で、Ｕ−Ｐｌａｎｅデータ変換部３６０より一定周期でトラヒック報告を受ける（ステップＳ５２−１〜Ｓ５２−３）。図１１の例では、使用帯域が予想帯域より小さい。
Ｕ−Ｐｌａｎｅリソース制御部３５０は、このトラヒック報告をもとに、報告を受ける都度、リソース開放判定を行う（ステップＳ５３−１〜Ｓ５３−３）。
このリソース開放判定の処理手順は図１２に示す如くである。図１２において、Ｕ−Ｐｌａｎｅデータ変換部３６０からトラック報告を受ける（ステップＳ５３０）と、閾値設定の有無を判断する（ステップＳ５３１）。
閾値設定があると（ステップＳ５３１、有）、現在のトラフィックを維持可能な帯域と確保帯域とを比較判定する（ステップＳ５３２）。この比較において、現在のトラフィックを維持可能な帯域が確保帯域より大きい場合（ステップＳ５３２、Ｎｏ）、判定カウンタの初期化を行う（ステップＳ５３３）。そして、図１１において、Ｕ−Ｐｌａｎｅデータ変換部３６０からトラック報告をトラフィック統計部３２３に通知し（ステップＳ５４−１〜Ｓ５４−３）、トラフィック統計部３２３から更に呼処理部３２１に通知が行われる（ステップＳ５５−１〜Ｓ５５−３）。
図１２に戻り、比較判定ステップＳ５３２において、現在のトラフィックを維持可能な帯域が確保帯域より小さいと判定される（ステップＳ５３２、Ｙｅｓ）と、判定カウンタをインクリメントする（ステップＳ５３３）。
この判定カウンタの計数値と、リソース確保要求に付加された閾値設定値と比較する（ステップＳ５３４）。この判定カウンタの計数値が、閾値設定値を超えたとき（ステップＳ５３４）、Ｕ−Ｐｌａｎｅデータ変換部３６０のリソース変更を決定する（ステップＳ５３５、図１１：ステップＳ５６）。
したがって、図１１において、予想により確保を行っていた帯域から現トラヒックを維持可能な帯域へと帯域削減の変更をＵ−Ｐｌａｎｅデータ変換部３６０に指示する（ステップＳ５７）。
呼処理部３２１ではトラヒック報告に対応してチャネル切替を行うとともにリソース確保要求をＵ−Ｐｌａｎｅリソース制御部３５０に通知するが、上記の様に、Ｕ−Ｐｌａｎｅリソース制御部３５０では確保している帯域よりも要求帯域の方が大きければ（ステップＳ５３２、Ｎｏ）、呼処理部３２１からの要求通りリソース確保を行い、逆に確保している帯域の方が大きい場合（ステップＳ５３２、Ｙｅｓ）は、閾値の方を優先する。
上記のとおり、ユーザ毎の特徴に応じて判定閾値を設けることにより、帯域解放を行うタイミングをユーザの特徴に応じて調整することが可能となる。
［第６の特徴］
第６の特徴は、無通信状態ユーザ呼の偏りによりチャネル数が制限されることを回避することを可能とするものである。
図１３は、第６の特徴を説明する処理フローである。無線ネットワーク制御装置ＲＮＣの装置構成は、図５に示したものと同様である。
ユーザのチャネルが遷移した場合、呼処理部３２１からのリソース確保要求（ステップＳ６０）をＵ−Ｐｌａｎｅリソース制御部３５０が受信し、チャネル状態に応じた帯域の確保をＵ−Ｐｌａｎｅデータ変換部３６０に確保させる。
この場合において、ユーザ呼が無通信状態に変更となる場合（図１３、ステップＳ６１、Ｙｅｓ）、Ｕ−Ｐｌａｎｅリソース制御部３５０は各Ｕ−Ｐｌａｎｅデータ変換部で収容している全無通信状態呼のユーザの特徴をユーザリソース管理部３３０へ無通信状態呼情報収集要求を行う。
ユーザリソース管理部３３０がユーザ情報管理ＤＢ３４０を参照して、該当ユーザの特徴を無通信状態呼情報収集応答としてＵ−Ｐｌａｎｅリソース制御部３５０に通知する。
これによりＵ−Ｐｌａｎｅリソース制御部３５０は無通信状態呼となっている全ユーザの数を算出し、その特徴を把握する（ステップＳ６２）。
全ユーザの特徴を把握に基づいて、今後トラヒックが高いと予測される無通信状態呼と他の無通信呼が均等に分散されるような移行に必要有無を判断する（ステップＳ６３）。
この判断に基づき、移行に必要有りである場合（ステップＳ６３、有）、Ｕ−Ｐｌａｎｅデータ変換部３６０においてユーザ呼移行処理を行う（ステップＳ６４）。
これにより、一部のＵ−Ｐｌａｎｅデータ変換部３６０への無通信状態ユーザ呼の偏りにより、Ｕ−Ｐｌａｎｅデータ変換部３６０のチャネル数制限を回避することが可能となる。
次に上記特徴を具備する本発明に従う具体的実施例動作を説明する。なお、説明において、先に使用したシーケンス及びフロー図を適宜に使用する。
［位置別トラヒック統計の登録と予測］
図６において、ある位置（Ａ１）に存在するユーザ（Ｕ１）が発呼した場合、無線ネットワーク制御装置ＲＮＣが対向ノードより加入者情報を含む呼設定要求を外部インターフェース（ＩＦ）部３１０で受信する（ステップＳ１）。
外部インターフェース（ＩＦ）部３１０は、主制御部３２０の呼処理部３２１に呼設定要求メッセージ受信を通知する（ステップＳ２）。
呼設定要求が呼処理部３２１に通知されると、呼処理部３２１はユーザ（Ｕ１）の呼設定処理を行うと共にユーザ（Ｕ１）に対する呼設定処理が行われたことを呼設定報告として位置管理部３２６に通知する（ステップＳ３）。
この通知を契機に位置管理部３２６は管理しているユーザ（Ｕ１）の位置が（Ａ１）であることを位置情報として位置統計手段３２４に通知する（ステップＳ４）。位置統計手段３２４は、次にユーザ（Ｕ１）の位置情報を受信するまでの間、（Ａ１）に存在しているという位置情報とその情報を受信した時刻（Ｔ１：２００３／６／１９  ２０：００）を管理する。
ユーザ（Ｕ１）の位置登録情報は定期的、あるいはユーザの位置に変化があった場合（例えば、Ａ１からＡ２に位置が変化した場合）に通知され（ステップＳ９）、外部ＩＦ部３１０で受信した位置登録情報を位置管理部３２６に通知する（ステップＳ１０）。
位置管理部３２６はユーザ（Ｕ１）がＡ２に存在しているという位置情報とその情報を受信した時刻（Ｔ２：２００３／６／１９  ２０：０３）を位置統計手段３２４に通知する（ステップＳ１１）。これを契機に位置統計手段３２４はユーザ（Ｕ１）のＴ１〜Ｔ２までの時間のトラヒック統計をトラヒック統計ＤＢ３７０を参照する（ステップＳ１２）。
トラヒック統計ＤＢ３７０の例が図１４に示される。なお、図１４において、実施例として１分間隔のトラヒックデータとしているが、この間隔は１分に限られるものではない。
位置統計手段３２４はトラヒック統計ＤＢ３７０を参照して得たユーザ（Ｕ１）に対するＴ１〜Ｔ２時間の平均トラヒック（１００Ｋｂｐｓ）と位置情報（Ａ１）を関連付けた位置別トラヒック統計データを生成する（ステップＳ１２−１）。この生成された位置別トラヒック統計データをユーザリソース管理部３３０に通知し（ステップＳ１３）、ユーザリソース管理部３３０は、これをユーザ情報管理ＤＢ３４０に格納する（ステップＳ１４）。
図１５は、位置別トラヒック統計データの一例であり、ユーザごとに位置別にトラフィックデータが登録されている。
上述のようにユーザ（Ｕ１）の位置別トラヒック統計が管理されている場合において、ユーザ（Ｕ１）が再度位置（Ａ１）へ移動した場合を考える。
再度位置（Ａ１）に移動した場合、位置管理部３２６では位置（Ａ１）の位置情報を位置統計管理手段３３３に通知する（ステップＳ５）。位置統計管理手段３３３ではユーザ情報管理ＤＢ３４０に格納されている位置別トラヒックデータ（図１５）よりユーザ（Ｕ１）の位置（Ａ１）に対するトラヒック統計を参照する（ステップＳ６）。
位置統計管理手段３３３は、更に図１５から位置（Ａ１）のトラヒック１００Ｋｂｐｓを求める。図１６は、トラフィックに応じた確保リソースの対応テーブルを示す。なお、図１６において、Ｒ１＜Ｒ２＜Ｒ３１＜Ｒ４である。
位置統計管理手段３３３は、図１５のトラヒック統計を参照して求めたトラヒック１００Ｋｂｐｓに応じた、図１６のテーブルに示されるリソースＲ２の帯域確保要求をＵ−Ｐｌａｎｅリソース制御部３５０へ通知する（ステップＳ７）。
帯域確保要求を受信したＵ−Ｐｌａｎｅリソース制御部３５０では現在確保しているユーザ（Ｕ１）の帯域よりも位置統計手段３３３から要求された帯域の方が高い場合、Ｕ−Ｐｌａｎｅデータ変換部３６０に対して要求された帯域制御を行い、ユーザ（Ｕ１）の位置に対応した帯域確保の制御を行う（ステップＳ８）。
反対に、ユーザ（Ｕ１）の呼が収容されるＵ−Ｐｌａｎｅデータ変換部３６０（ＵＰ−Ａ）のリソース未使用分が不足であるため要求されたリソースＲ２の帯域の確保できない場合（図１７に示す１つのトラフィックに応じた確保リソースの対応テーブルを示す。において、現時点のリソース使用率９８％で収容呼数が７４である場合）、Ｕ−Ｐｌａｎｅリソース制御部３５０では自己の管理する複数のＵ−Ｐｌａｎｅデータ変換部３６０の各リソース使用率を参照し、リソース使用率４０％で、呼数も収容可能（６３／１００呼）なＵ−Ｐｌａｎｅデータ変換部３６０（ＵＰ−Ｂ）を選定する。
Ｕ−Ｐｌａｎｅデータ変換部３６０（ＵＰ−Ｂ）に対してユーザ（Ｕ１）の呼のためのＲ２のリソース確保を行い、その後ユーザ（Ｕ１）の呼をＵ−Ｐｌａｎｅデータ変換部３６０（ＵＰ−Ａ）から（ＵＰ−Ｂ）へ移行させる。
［時刻別トラヒック統計の登録］
図７に示すフローにおいて、ある位置（Ａ１）に存在するユーザ（Ｕ１）が発呼した場合、無線ネットワーク制御装置ＲＮＣが対向ノードより加入者情報を含む呼設定要求を外部インターフェース（ＩＦ）部３１０で受信する（ステップＳ２１）。
外部インターフェース（ＩＦ）部３１０は、主制御部３２０の呼処理部３２１に呼設定要求メッセージ受信を通知する（ステップＳ２２）。
呼設定要求メッセージの通知を受けた呼処理部３２１は、ユーザ（Ｕ１）の呼設定処理を行うとともにユーザ（Ｕ１）に対する呼設定処理が行われたことを呼設定報告として時刻統計手段３２５に通知する（ステップＳ２３）。この報告を契機に時刻統計手段３２５では、通知された時刻（Ｔ１：２００３／６／１９  ２０：００）からの時刻別トラヒック収集を開始し、一定周期毎（ここでは６０分周期で設定されるとする）にトラヒック統計ＤＢ３７０（図１４参照）の参照・集計を行う（ステップＳ２４）。
図１４に示す例では、時刻統計手段３２５がユーザ（Ｕ１）の時刻別トラヒック収集を始めてから一定周期（６０分）経過後の時刻がＴ４（２００３／６／１９  ２１：００）である。したがって、ユーザ（Ｕ１）に対する時刻Ｔ１〜Ｔ３の時間（Ｔ１：２００３／６／１９  ２０：００〜Ｔ３：２００３／６／１９  ２０：５９の間の６０分）のトラヒック統計ＤＢを集計し、ユーザ（Ｕ１）に対する、Ｔ１〜Ｔ３の時間帯（２０時台）と平均トラヒック（１８０Ｋｂｐｓ）を関連付けた時刻別トラヒックデータ（図１８参照）をユーザリソース管理部３３０に通知し（ステップＳ２５）、ユーザ情報管理ＤＢ３４０に格納する（ステップＳ２６）。
また、上述のようにユーザ（Ｕ１）の時刻別トラヒック統計が管理されている場合において、別の日の同時間帯（この場合２０時台）にユーザが呼接続していた場合を考える。
時刻統計手段３３２は一定周期毎に時刻別トラヒックデータ（図１８）を参照しており（ステップＳ２７）、ユーザ（Ｕ１）の現時刻（２０時）に対する平均トラヒック（１８０Ｋｂｐｓ）が存在する為、このトラヒックに応じた帯域Ｒ３（図１６参照）の帯域確保要求をＵ−Ｐｌａｎｅリソース制御部３５０へ通知する（ステップＳ２７）。
帯域確保要求を受信したＵ−Ｐｌａｎｅリソース制御部３５０では、現在確保しているユーザ（Ｕ１）の帯域よりも時刻統計手段３３２から要求された帯域の方が高いと判断する場合、Ｕ−Ｐｌａｎｅデータ変換部３６０に対して帯域制御を行い、ユーザ（Ｕ１）の時刻に対応した帯域確保を行う（ステップＳ２９）。
ユーザ発呼時における帯域変更や、同一Ｕ−Ｐｌａｎｅデータ変換部における帯域不足の動作は上記位置別トラヒック統計の登録と予測の処理の場合と同様である。
［契約種別の登録と帯域制御］
図８において、ユーザ（Ｕ１）が発呼した場合、外部ＩＦ部３１０で対向装置ＳＧＳＮから呼設定要求を受信し（ステップＳ３１）、更に外部ＩＦ部３１０から通知されてユーザＵ１の加入者情報を含む呼設定要求を呼処理部３２１が受信する（ステップＳ３２）。
呼処理部３２１では、呼設定要求に含まれるユーザ（Ｕ１）の帯域制御に必要な加入者情報をユーザリソース管理部３３０に通知し（ステップＳ３３）、ユーザ情報管理ＤＢ３４０にユーザ（Ｕ１）の加入者情報を格納する（ステップＳ３４）。
図１９に通知される加入者情報の例を示す。ユーザ毎に契約種別と該当の契約種別に加入しているか否かが記録されている。
ユーザ契約情報手段３３１はユーザ情報管理ＤＢ３４０より、ユーザ（Ｕ１）の加入者情報のＵ−Ｐｌａｎｅリソース制御に必要となる帯域確保に関する契約種別（図１９）を参照し、ユーザ（Ｕ１）の契約種別（Ｃ１）をＵ−Ｐｌａｎｅリソース制御部３５０に通知する（ステップＳ３５）。
ユーザの契約種別毎に確保する帯域は図２０に示すように予め設定されている。この場合、ユーザ（Ｕ１）の契約種別（Ｃ１）を受信したＵ−Ｐｌａｎｅリソース制御部３５０は、トラヒック１５１〜３８４（Ｋｂｐｓ）に対応するリソース（Ｒ３）以上の常時確保を行う（ステップＳ３６）。
呼処理部３２１がユーザ（Ｕ１）のチャネル切替を実施した場合の処理として、呼処理部３２１からＵ−Ｐｌａｎｅリソース制御部３５０に対してチャネル状態に応じたリソースの確保要求を通知する。
但し、契約種別による帯域制御が実施されている場合、契約種別により指定された帯域以上の確保を優先的に行う。例として、契約内容に沿ったＵ−Ｐｌａｎｅリソース制御部３５０のリソース制御フローを図２１に示す。呼処理部３２１がＲ２を指定したリソース確保要求を行った場合、Ｕ−Ｐｌａｎｅリソース制御部３５０はＲ３とＲ２の大小判定を行う（ステップＳ７０）。
この場合Ｒ３＞Ｒ２であるため、呼処理部３２１からのリソース確保要求による制御は行わず（ステップＳ７０、Ｎｏ）、ユーザ（Ｕ１）の契約種別（Ｃ１）の契約内容に沿ってトラヒック１５１〜３８４（Ｋｂｐｓ）に対応するリソース（Ｒ３）以上の常時確保を行うことになる。
［位置別・時刻別・契約種別の複合による帯域制御］
各ユーザの使用状況を特徴付けるユーザ情報管理ＤＢ３４０からの情報により、位置情報や時刻情報、契約種別情報別の帯域管理を行う場合（図６，７，８参照）、Ｕ−Ｐｌａｎｅリソース制御部３５０はユーザリソース管理部３３０よりユーザ（Ｕ１）に対して複数の帯域制御要求を受信する場合がある。
ユーザ（Ｕ１）が位置（Ａ１）で呼の接続を行った場合、位置（Ａ１）において予測されるトラヒック１００Ｋｂｐｓ（図図１５参照）に対応するＲ２（図１６）のリソース確保要求を位置統計管理手段３３３によりＵ−Ｐｌａｎｅリソース制御部３５０に通知し、Ｕ−Ｐｌａｎｅデータ変換部３６０の制御を行う。この時、時刻（２０時）へと変化するとユーザ（Ｕ１）の時刻（２０時）に対するトラヒック１８０Ｋｂｐｓ（図１８参照）に対応するＲ３（図１６）のリソース確保要求が時刻統計管理手段３３２よりＵ−Ｐｌａｎｅリソース制御部３５０に通知される場合がある。
このように複数の帯域確保要求を受信した場合、Ｕ−Ｐｌａｎｅリソース制御部３５０では要求された帯域の高い方の要求を選択して帯域の制御を行う。この場合Ｒ２＜Ｒ３の為、時刻統計管理手段３３２からの要求によるＲ３のリソース確保を行う。また、図２２に示すように帯域の制御要求に対して優先度を設けることにより、複数の帯域確保要求からの選択を行うことも可能である。
［ユーザの利用状況を考慮した帯域解放］
ここで、ユーザ（Ｕ１）の時刻別トラヒック予測が既に行われ、図１６中のＲ３の帯域確保が行われているものとする。
前述のＲ３の帯域確保を行う場合、ユーザリソース管理部３３０がＵ−Ｐｌａｎｅリソース制御部３５０に対してリソース確保要求を送信する。この際、図１８の時刻別トラヒック統計より確保する帯域に応じた判定閾値３も同時に通知される。判定閾値はユーザの利用状況に応じて予め設定されている。
Ｕ−Ｐｌａｎｅデータ変換部３６０はＵ−Ｐｌａｎｅリソース制御部３５０に対して一定周期で図２３に示すユーザのトラヒック報告を行っている。本報告はＵ−Ｐｌａｎｅリソース制御部３５０において帯域変更の必要可否判断を行う材料として用いられている。上記のように帯域変更の判定閾値が設定されている場合、判定閾値に応じた帯域の変更を行う。
ユーザ（Ｕ１）に対するトラヒック予測ではＲ３の帯域を確保しているが、図２３の場合、２００３／６／１９  ２０：００：１０のトラヒック報告ではトラヒックは４８ＫｂｐｓでありＲ１の帯域分しか必要としないトラヒックであることがわかる。
この場合、図１２に示すフローに従い、先に説明したようにＵ−Ｐｌａｎｅリソース制御部３５０は判定を元にカウンタをインクリメント（ステップＳ５３４）し、判定カウンタが閾値を超える場合（ステップＳ５３４、Ｙｅｓ）、トラヒック報告に応じた帯域に変更する（ステップＳ５３５）。
なお、判定カウンタが閾値を超えない場合（ステップＳ５３４、Ｎｏ）は、帯域変更は実施されない。図２３に示す実施例の場合、ユーザ（Ｕ１）は２００３／６／１９  ２０：００：４０に判定閾値３を超過する為、Ｕ−Ｐｌａｎｅリソース制御部３５０はユーザ（Ｕ１）の確保リソースを２００３／６／１９  ２０：００：４０のトラヒック報告に応じたＲ１に変更することになる。
かかる実施例は、ユーザの利用状況に応じた予測制御による帯域確保を行ったが、予想に反してトラヒックが増加しない場合等に適用され、帯域再変更の際に判定閾値を設けることにより、帯域再変更の時期を調整することが可能となる。
また、本実施例では、時刻別トラヒック統計で予測を行った場合について説明しているが、位置別トラヒック統計においても同様の判定閾値をユーザ毎に設定することも可能である。
［ユーザの特徴を考慮した無通信状態呼の分散］
図２４は、無通信状態呼を分散する処理シーケンスである。Ｕ−Ｐｌａｎｅリソース制御部３５０においてユーザ（Ｕ１）の呼に対して無通信状態呼へのリソース変更要求を２０時台に受信した場合について説明する。
呼処理部３２１からＵ−Ｐｌａｎｅリソース制御部３５０にリソース変更要求があると（ステップＳ８０）、Ｕ−Ｐｌａｎｅリソース制御部３５０は、各Ｕ−Ｐｌａｎｅデータ変換部３６０の全無通信状態呼のユーザ（ユーザ（Ｕ１）を含む）に対する２０時台の時刻別トラヒック要求をユーザリソース管理部３３０へ問い合わせる（ステップＳ８１）。
ユーザリソース管理部３３０はユーザ情報管理ＤＢ３４０へトラヒックデータを参照し（ステップＳ８２）、全無通信状態ユーザの２０時台の予想トラヒックをＵ−Ｐｌａｎｅリソース管理部３５０へ通知する（ステップＳ８３）。
これにより、Ｕ−Ｐｌａｎｅリソース管理部３５０において、無通信状態呼の集計（ステップＳ８４−１）、全ム通信状態呼のリソース繊維予測判定（ステップＳ８４−２）及び該当この分散先Ｕ−Ｐｌａｎｅデータ変換部を決定し（ステップＳ８４−３）、予想トラヒックを把握することが可能となる。
したがって、この無通信状態呼のトラヒック予測に応じた、呼の移行処理を行い（ステップＳ８５）、無通信状態呼の分散が可能となる。
ここで、無通信状態呼の分散例について１５０Ｋｂｐｓに閾値があると仮定し、全無通信状態呼に対する予想トラヒックが閾値より多い場合、これを（Ａ）、少ない場合を（Ｂ）と設定し、各Ｕ−Ｐｌａｎｅにおいて（Ａ）、（Ｂ）それぞれの状態の呼数を管理した上で無通信状態呼の均等分散を行うものとする。
図１８の例ではユーザ（Ｕ１）の予想トラヒックは１８０Ｋｂｐｓである為、呼の状態は（Ａ）であるとＵ−Ｐｌａｎｅリソース管理部３５０は判断する。
一方、図２５に示す場合、ユーザ（Ｕ１）の呼がＵ−Ｐｌａｎｅデータ変換部（Ｉ）において無通信状態呼（Ａ）に遷移した場合、無通信状態呼の状態（Ａ）の数がＵ−Ｐｌａｎｅデータ変換部（Ｉ）は４呼、Ｕ−Ｐｌａｎｅデータ変換部（ＩＩ）では２呼となる。この為、各Ｕ−Ｐｌａｎｅデータ変換部３６０に収容される呼数が均等とならない。
この場合、状態（Ａ）の呼を均等にする為、ユーザ（Ｕ１）の呼をＵ−Ｐｌａｎｅデータ変換部（ＩＩ）に移行させ、Ｕ−Ｐｌａｎｅデータ変換部（Ｉ）、（ＩＩ）それぞれにおける状態（Ａ）の数を均等にする。
変更となった無通信状態呼が状態（Ｂ）と判断した場合においても各Ｕ−Ｐｌａｎｅデータ変換部３６０における状態（Ｂ）の無通信状態呼の数が均等となるような呼の移行を行う。
この様にして、各ユーザのトラヒック増減を考慮した無通信状態呼の均等分散が可能となる。
本実施例では時刻別トラヒック統計による予想トラヒックからユーザの特徴を判断し、無通信状態呼の分散を行っているが、その他、ユーザを特徴付けるデータを基にして、分散の判断を行うことも可能である。
この様に本発明により、無線ネットワーク制御装置において管理される帯域に対し、ユーザ毎の契約種別や使用状況に応じた帯域管理が可能となる。また、従来では無通信状態（ＰＣＨ）からＨＳ−ＤＳＣＨ状態の遷移時などのような急激なトラヒックの変化により、リソース不足のため最大帯域の確保が不可能となるような状況において、本発明ではユーザの特徴を蓄積することにより、呼毎にチャネル種別に応じた帯域確保や他Ｕ−Ｐｌａｎｅデータ変換部への分散をおこなうことが可能となる。
また、本発明ではＷ−ＣＤＭＡ方式について記述しているが、本発明の適用は、かかる方式に限定したものではなく、他の無線区間での帯域制御についても同様に適用可能である。
従って、本発明を適用した無線ネットワーク制御装置における帯域管理方法において、以下の効果がある。
第１に、本発明においてユーザ毎の利用形態やトラヒック使用状況などの特徴の情報が蓄積可能となる。その情報を利用してユーザ毎の特徴を加味した上で帯域の事前確保を行い、チャネル切り替え後、ユーザのデータ転送に遅延が生じる事無く通信が可能となる。
第２に、本発明を利用して複数Ｕ−Ｐｌａｎｅデータ変換部への呼の分散を均等におこなうことにより、一部のＵ−Ｐｌａｎｅデータ変換部への呼の偏りによりユーザ数制限を受けることを回避することが可能となる。また一つのＵ−Ｐｌａｎｅデータ変換部において帯域が不足する状況においても、他Ｕ−Ｐｌａｎｅデータ変換部への呼の分散により前記呼の帯域確保ができ、また、帯域全体の有効利用が可能となる。
具体的に会社員の場合を例にとると、個人利用の端末でデータの送受信を行う時間帯は、休憩時間や退社後が多くなる。使用場所については、自宅や通勤時の駅構内等がデータ量の多い場所としてとして考えられる。このように、ユーザ毎にパターン化することが可能な場合、利用形態に応じてユーザに最適な帯域を事前確保するようなことが可能となる。また、契約種別毎による組み合わせも可能である。
【産業上の利用可能性】  今後ＨＳＤＰＡの登場による最高帯域拡大に伴い、ユーザ数の増加や、常時接続のような新たなサービス形態による無通信状態呼の増加が予想されており、本発明に従い、物理的実装の増加による解決ではなく、ユーザの利用形態の特徴を考慮した使用帯域の有効的利用を実現することができる。
【図１】
0004291326.tif 000002
【図２】
0004291326.tif 000003
【図３】
0004291326.tif 000004
【図４】
0004291326.tif 000005
【図５】
0004291326.tif 000006
【図６】
0004291326.tif 000007
【図７】
0004291326.tif 000008
【図８】
0004291326.tif 000009
【図９】
0004291326.tif 000010
【図１０】
0004291326.tif 000011
【図１１】
0004291326.tif 000012
【図１２】
0004291326.tif 000013
【図１３】
0004291326.tif 000014
【図１４】
0004291326.tif 000015
【図１５】
0004291326.tif 000016
【図１６】
0004291326.tif 000017
【図１７】
0004291326.tif 000018
【図１８】
0004291326.tif 000019
【図１９】
0004291326.tif 000020
【図２０】
0004291326.tif 000021
【図２１】
0004291326.tif 000022
【図２２】
0004291326.tif 000023
【図２３】
0004291326.tif 000024
【図２４】
0004291326.tif 000025
【図２５】
0004291326.tif 000026