JP2008085686A - 予約受付制御システムと方法およびプログラム - Google Patents

Abstract

【課題】電話等の即時呼とＴＶ会議等の事前予約呼の２形態の呼が混在したＩＰネットワークにおける呼の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行う。
【解決手段】経路特定手段６は新規接続に用いるリンクを特定し、受付判定手段は、新規接続が例えば即時呼であれば、当該リンクで使用中のリソース量と該即時呼で要求されるリソース量とを加算し、加算した値が、時間の経過に伴い推移するリソース使用推移値を、過去の通信履歴情報を用いて算出し、算出したリソース使用量推移値と、当該リンクの他の事前予約呼による予約済リソース使用量とを加算し、この加算した値と、予め当該リンクに設定されたリソース使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可することを特徴とする。
【選択図】図１

Description

本発明は、ＩＰネットワークにおける呼の受付制御技術に係り、特に、電話等の即時呼とＴＶ会議等の事前予約呼が混在する際の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行うのに好適な技術に関するものである。

ＩＰネットワークなどのパケット通信では、複数の利用者が共通のネットワークを用いてそれぞれパケットの送受信を行う。ネットワークは有限の通信リソース（回線の帯域幅、ルータ等のノードのバッファ量など）を持っているため、利用者数が大きくなってネットワークの転送能力を超える量のパケットが流入すると、パケットの到着の遅延が大きくなったり、廃棄（パケットロス）が発生したりして、通信サービスの品質が劣化してしまう。

特に、ＩＰネットワーク上での映像・音声などの多くのリソース容量を用いる通信サービスでは、ネットワークのリソース容量を超える利用要求によって輻輳が発生し、品質劣化となる。このような通信品質の劣化に対しては、再送制御などのアプリケーションレベルの品質向上技術があるが、このようなアプリケーションレベルの品質向上技術では大きな効果が望めず、ＯＳＩ参照モデルのネットワークレイヤ（ネットワーク層）にて、各フローに対して排他的に利用リソースを確保する必要がある。

このような技術として、ネットワークを構成するルータ等のノードにおいて、パケット転送時に「優先制御」を行う技術が普及している。例えば、ＩＰネットワークにおけるＤｉｆｆｓｅｒｖという技術は、パケットのヘッダに優先度をつけておき、ルータにおいて、転送能力を超えるパケットが流入した際には優先度の低いパケットを廃棄したり後回しにしたりして優先度の高いパケットを優先的に転送するものであり、これによってパケットの遅延や廃棄確率などの品質条件を相対的に高く保つことが可能となる。近年のルータにはこの機能が実装されているものが多い。

尚、パケット通信においては、利用者が転送したい情報を１つまたは複数のパケットを使用して送信する。一般的に、あるネットワークの利用（あるデータの転送開始から終了まで、ある電話の通話開始から終了まで、など）をセッションと呼び、そのセッションのために連続的に転送されるパケットの集合のことをフローと呼ぶ。優先制御の主な利用技術としては、パケットごとに転送優先度を決定するのではなく、フロー単位で優先度をつける。

上述の優先制御についての技術では、転送優先度の高いフローと低いフローが混在している場合、高優先フローの転送品質の確保に効果があるが、高優先度フロー数が増加し、それだけでネットワークリソースを使い切ってしまうような場合には高優先フローであっても転送品質の劣化は免れない。高優先フローをネットワークのリソース容量以上に収容することは可能だが、サービス品質の劣化が全利用者に及んでしまう。

このような問題に対処して、転送品質を維持するために、ネットワークのリソース容量以上の利用要求を拒絶するという制御を行う技術が有効であり、このような技術は受付制御（Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ）と呼ばれる。

非特許文献１では、ＩＰネットワークにおいて、ネットワーク中の全てのリンクのリソース容量と、利用されているリソース量とをリソース管理サーバにおいて把握しておくことで、新たなセッションの発生による利用要求を受信した際に受付判定を行う技術が記載されている。

このリソース管理サーバでは、管理対象のネットワーク中の全てのリンクについて、高優先フローが使用しているリソース量をリアルタイムに管理している。これは、高優先フローの利用開始時に利用要求を受信し、それを記録することによって行われる。

また、リソース管理サーバは、ネットワークからの情報収集によって経路（リンク）情報と各リンクのリソース容量を把握している。そして、利用要求の受信時には、そのフローが通過する全てのリンクを経路（リンク）情報から検索し、各リンクの使用リソース量を加算して記録する。

このとき、使用量がリソース容量を超えてしまう場合は、この利用要求に対して利用すること自体を、または優先フローとして扱うことを拒絶する。後者の場合、該当する要求の通信は非優先フローとして許容される。

このようなリソース管理・受付制御技術により、高優先フローは、ネットワークのリソース容量が許す限り収容され、容量を超えることは防止されるので、利用を許容されたフローはその品質が確保される。

以下、このような受付制御の適用例を説明する。このような受付制御機能を持つリソース管理・受付制御サーバは、通信キャリアがＩＰ技術でさまざまな通信サービスを統合して大規模に展開する次世代ネットワーク（「ＮＧＮ」）の国際標準化の中でもその必要性を認識させており、ＩＴＵ−ＴやＥＴＳＩ ＴＩＳＰＡＮにおいてＲＡＣＳ（Ｒｅｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂｓｙｓｔｅｍ）としてネットワークアーキテクテャ内に定義されている。

このような適用例の中で、リソース管理・受付制御サーバは、ＩＰ電話、ＴＶ電話、ＶｏＤ（Ｖｉｄｅｏ ｏｎ Ｄｅｍａｎｄ）などの様々なセッションベースの通信サービスの発信時に、アプリケーションサーバやセッション制御サーバから受付制御機能として呼びだされ、応答を行う。

具体的には、呼の生起（利用者からサービス利用開始の意思を通知する）時に利用者からの接続要求がアプリケーションサーバやセッション制御サーバに通知され、各サーバが接続処理を行う中で、求められる品質で接続することが可能かを受付制御サーバに問い合わせる。問い合わせを受けた受付制御サーバは、リソースの空き状況を確認し、空きがあると判断すれば受付許可を、空きがないと判断すれば受け付け拒否を通知する。

受付を許可した接続が確立された後、その呼を切断する際には、当該アプリケーションサーバやセッション制御サーバは、受付制御サーバに対して該当呼の処理を通知し、受付制御サーバは、該当呼のために確保していたリソースを開放する処理を行い、切断処理の完了通知を応答する。

次に、呼損率について説明する。サービス提供システムの故障などの要因も含め、利用要求呼が拒絶されることは呼損と呼ばれる。上述のように、サービスリソースが不足している時に呼を収容したり待たせたりせずに即時拒絶するタイプのサービスは「呼損モデル」と呼ばれる。また、全体の利用要求数に対する呼損の割合を呼損率と呼ぶ。

サービス提供者は呼損率が大きくならないようにネットワークシステムのリソース設計を行うが、利用者の急増や、利用機会の急増（チケット予約の電話や災害時の見舞電話、話題性の高いＷｅｂコンテンツヘの接続など）時には呼損率が想定以上となってしまうことがある。

また、本来のリソース容量を有効に活用できないようなリソース管理技術では、この呼損率が高くなってしまう。そのため、如何に有限なリソースを有効に活用し、呼損率を抑えるかが、ネットワーク上の通信サービスにおいて、高い品質（ＱｏＳ）を実現するための重要な技術課題となる。

このように、ネットワーク上の通信サービスにおいて高い品質（ＱｏＳ）を実現するために、リンクの帯域などのリソース量の使用状況を管理し、使用量がリンクのリソース容量を超えないように管理することによって品質を制御する受付制御が有効である。

この受付制御によって実現されるサービスの利用形態として、電話のように、利用したいときに即座に利用する即時型と、ＴＶ会議やＴＶ番組視聴などのように、決められた時刻から利用するために事前に予約をしておく事前予約型の２形態が想定される。

即時型の要求（即時呼）はサービスの終了時刻が不明であるため、そこで使用しているリソースが何時開放されるかも不明であり、当該リソースを、未来の時刻を指定する事前予約型の要求で利用する場合、この事前予約型の要求（事前予約呼）に対して正確な受付判定を行うことができない。

従来、前者の即時呼に対する受付判定については、さまざまな技術が論じられて実現されてきているが、上述のように、即時呼に加え予約呼も混在した場合の受付制御については、呼損率とリソースの利用効率に有効な技術がまだ確立されていない。

最も単純な技術として、リソース量を「即時用」と「事前予約用」に分割して独立管理するリソース分割技術が考えられるが、設備設計によってなされたリソースの分割割合と、実際の即時呼と事前予約呼の割合に隔たりが大きい場合には、リソースの利用効率は大きく劣化してしまう。

これに対して、例えば、即時呼の割合と事前予約呼の割合が、一日の午前・午後といった時間帯、週の曜日によっても異なると考え、即時呼と事前予約呼でリソースを共有する技術が、非特許文献２，３に記載されている。

例えば、非特許文献２においては、即時呼に無関係に事前予約を受け付け、競合した場合は優先順位に従って強制切断する技術が提案されている。しかし、この技術では、リソースの利用効率は高いが、提供するサービスの種別によっては突然強制切断される可能性があり、ユーザに対してのサービス的な問題が内在している。

また、非特許文献３においては、保護時間を設定した制御技術が提案されている。この技術では保護時間Ｔを設定し、即時呼は、開始後、設定した保護時間Ｔ秒経過時に強制切断し、事前予約は、保護時間Ｔ秒より後に開始する時間帯のもののみを受け付け、開始Ｔ秒前からリソースを占有させる。

しかし、この技術では、呼損率を低く抑えるのには有効であるが、事前予約呼について保護時間分だけ余計にリソースを必要とするため、事前予約呼の割合に影響を受け、リソース分割方式よりリソース効率が悪いケースがある。

笠原，他："パーフローＱｏＳを実現するエージェント型リソース制御システム，"情報処理学会論文誌，Ｖｏｌ．４６ Ｎｏ．２， ｐｐ．５１７−５２４， Ｆｅｂ．２００５． Ｏ．Ｓｃｈｅｌｅｎ， ｅｔ， ａｌ："Ａｎ Ａｇｅｎｔ−ｂａｓｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ａｄｖａｎｃｅ Ｒｅｓｅｒｖａｔｉｏｎｓ，"Ｐｒｏｃ．ＩＥＥＥ ２２ｎｄ Ａｎｎｕａｌ Ｃｏｎｆ． ｏｎ Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋｓ（ＬＣＮ’９７），（１９９７）． 北村，他："受付制御型品質制御における時間指定予約要求についての一考察，"２００３ 信学ソ大，Ｂ−６−７９（２００３）．

解決しようとする問題点は、従来の技術では、ネットワークの受付制御において、現時刻から通信サービスの利用を開始する即時型の要求と、利用時刻を指定して予約を行う予約型の要求とが混在する場合には、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら受付制御を行うことができない点である。

本発明の目的は、これら従来技術の課題を解決し、電話等の即時呼とＴＶ会議等の事前予約呼の２形態の呼が混在した場合の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行うことを可能とし、ＩＰネットワークを利用した映像・音声通信などのストリーム型通信サービスを高品質に提供することである。

上記目的を達成するため、本発明では、即時呼と事前予約呼とが混在するＩＰネットワークにおける新たな呼の受付制御を行う際、新規の接続要求の接続に用いるリンクを特定し、新規の接続要求が即時呼であれば、特定したリンクで現在使用中のリソース量と、当該即時呼で要求されるリソース量とを加算し、この加算値が、時間の経過に伴い推移するリソース使用推移値を、過去の即時呼の通信履歴情報を用いて算出し、算出したリソース使用量推移値と、特定したリンクの、他の事前予約呼により予約されたリソース使用量とを加算し、加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可し、また、新規の接続要求が事前予約呼であれば、特定したリンクで現在使用中のリソース量値が、時間の経過に伴い推移するリソース使用推移値を、過去の即時呼の通信履歴情報を用いて算出し、算出したリソース使用量推移値と、特定したリンクの、他の事前予約呼により予約されたリソース使用量と、当該事前予約呼で要求されるリソース量とを加算し、加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可することを特徴とする。

本発明によれば、電話等の即時呼とＴＶ会議等の事前予約呼の２形態の呼が混在したＩＰネットワークにおける呼の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行うことが可能である。

以下、図を用いて本発明を実施するための最良の形態例を説明する。図１は、本発明に係るＩＰネットワークにおける呼の受付制御を行うシステム（受付制御サーバ）の構成例を示すブロック図であり、図２は、図１における受付制御サーバで記憶・管理される各情報の内容を示す説明図、図３は、図１における受付制御サーバが設けられたネットワークの第１の構成例を示すブロック図、図４は、図１における受付判定手段の処理動作例を示すフローチャートである。

図１における受付制御サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Pｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）や主メモリ、表示装置、入力装置、外部記憶装置等を備えたコンピュータ構成からなり、光ディスク駆動装置等を介してＣＤ−ＲＯＭ等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みＣＰＵで処理することにより、各処理を実行する機能を有する。

すなわち、受付制御サーバ１は、プログラムに基づくＣＰＵの処理で実現する機能として、統計データ作成手段２、通信履歴管理手段３、リソース管理手段４、受付判定手段５、経路（リンク）特定手段６、メッセージ送受信手段７を有している。

統計データ作成手段２、通信履歴管理手段３、リソース管理手段４、受付判定手段５、経路（リンク）特定手段６のそれぞれは、図２にそれぞれの詳細を示す各テーブル（経路（リンク）テーブル２１、通信履歴テーブル２２、現時刻リソース管理テーブル２３、未来時刻リソース管理テーブル２４、統計データ管理テーブル２５）の参照、生成を行い、本発明に関わる処理を実行する。

図２における、経路（リンク）テーブル２１、通信履歴テーブル２２、現時刻リソース管理テーブル２３、未来時刻リソース管理テーブル２４、統計データ管理テーブル２５は、磁気ディスク装置や主メモリ等の記憶装置に記憶されたものである。

例えば、経路（リンク）テーブル２１には、予め入力された、発側エッジノードと着側エッジノードの組と、当該発側エッジノードと着側エッジノード間を接続するリンク群とが対応付けて登録されており、経路（リンク）特定手段６は、メッセージ送受信手段７が受信した接続要求メッセージで示される発側エッジノード（例えばＲ１１）と着側エッジノード（例えばＲ３２３）を受け取り（Ａ）、これらをキーに、経路（リンク）テーブル２１を参照して、対応付けられたリンク群（Ｌｉｎｋ２−Ｌｉｎｋ７）を特定する。

このような経路（リンク）テーブル２１における登録内容は、図３に示すネットワーク構成例を表しており、例えば、端末（１）と端末（２）が接続されたエッジルータＲ１１と、端末（６）が接続されたエッジルータＲ３２間は、ルータＲ２２を中継してリンク２（Ｌｉｎｋ２），リンク７（Ｌｉｎｋ７）経由で接続されることが登録されている。

そして、通信履歴管理手段３は、図２の通信履歴テーブル２２においてリンク１（Ｌｉｎｋ１）に関して例示すように、各通信サービス毎に、サービス開始時刻、サービス終了時刻、サービス内容、要求リソース（ｂｐｓ）等の情報を、各リンク別に登録する。

図３に示すネットワークにおいては、各端末から要求される接続として、電話のように、利用したいときに即座に利用する即時型と、ＴＶ会議やＴＶ番組視聴などのように、決められた時刻から利用するために事前に予約をしておく事前予約型の２形態が混在する。そして、本例のネットワークでは、リソースを上述の即時型と事前予約型に、完全に分割して独立使用するのではなく、即時型と事前予約型でリソースを共用する。

リソース管理手段４は、受付判定手段５が要求を受け付けた各通信で消費（使用）されるリソースを、例えば図２に詳細を示す現時刻リソース管理テーブル２３と未来リソース管理テーブル２４の内容で、現在のリソースの使用状況と事前予約型で将来において使用されるリソースの使用予約状況とを登録して管理する。

例えば、図２に示す現時刻リソース管理テーブル２３においては、各リンク毎に、当該リンクを使用している帯域量（使用中リソース）と共に、予め当該リンクに設定された受付可能な最大帯域量（使用可能リソース（ｂｐｓ））が対応付けて設定されている。

この現時刻リソース管理テーブル２３において設定されている使用可能リソース（ｂｐｓ）を超えた当該リンク経由の接続要求は受け付けられない。

また、未来リソース管理テーブル２４においては、図２においてリンク１に関して例示しているように、各リンク別に、予約されている時間帯（時刻帯）毎に、予約されたリソース使用量（使用中リソース）が対応付けて設定されている。

統計データ作成手段２は、記憶装置から通信履歴テーブル２２を読み込み、その登録内容を用いて、各リンク別に、図２に詳細を示す内容の統計データ管理テーブル２５を生成して記憶装置に格納する。

この統計データ管理テーブル２５は、各リンク別に生成され、例えば図２に示す統計データ管理２５は、リンク１（Ｌｉｎｋ１）に関してのデータであり、時刻帯毎に、通信継続時間（分）とリソース使用率（％）が対応付けて登録されている。

すなわち、統計データ作成手段２は、通信履歴テーブル２２において登録されているリンク１に関しての通信サービス情報（サービス開始時刻とサービス終了時刻）から、各時刻帯、例えば１０時−１８時に渡っての、通信継続時間（分）、リソース使用率（％）を求めて、統計データ管理テーブル２５に登録する。

受付判定手段５は、経路（リンク）特定手段６で特定したリンクの情報を受け取り（Ｂ）、当該リンクでの接続要求（即時呼もしくは事前予約呼）を受け付けることができるか否かを、記録装置から現時刻リソース管理テーブル２３、未来リソース管理テーブル２４、統計データ管理テーブル２５を読み込み、それぞれの登録内容を参照して判定し、その結果をリソース管理手段４とメッセージ送受信手段７に通知する（Ｃ，Ｄ）。

ここで、即時型の接続要求（即時呼）に関して説明する。この即時呼は、サービスの終了時刻が不明であるため、そこで使用しているリソースが、いつ開放されるかも不明である。そのため、従来技術では、当該リソースを、未来の時刻を指定する事前予約型の要求で利用する場合、この事前予約型の要求（事前予約呼）に対して正確な受付判定を行うことができないが、本例の受付判定手段５では、これが可能となる。

また、事前予約呼を近未来の時刻に既に受け付けている状態で、新たな即時呼の要求があった場合、この新たな即時呼を受け付けることによって、先に受け付けた事前予約呼のサービス開始時に、当該事前予約呼に当該リソースを振り分けることができないケースがあり、従来の技術では、このようなケースに対処できないが、本例の受付判定手段５では、これも可能となる。

さらに、即時呼を受け付けている状態で、かつ、事前予約呼を近未来の時刻に既に受け付けている状態で、新たな事前予約呼の要求があった場合、従来の技術では、受付済みの即時呼の終了時刻が不明のため、この新たな事前予約呼を受け付けることができるか否かを判断することができないが、本例の受付判定手段５では、これも可能となる。

以下、このような本例の経路（リンク）特定手段６と受付判定手段５の処理動作を図４を用いて説明する。

まず、本例の経路（リンク）特定手段６は、新たな接続要求があるとその通信経路（どのリンクを通るか）を特定する（ステップＳ４０１）。次に受付判定手段５は、新たな接続要求が即時呼であるか事前予約呼であるかを判別する（ステップＳ４０２）。

続いて、当該未来リソース管理テーブル２４と現時刻リソース管理テーブル２３および統計データ管理テーブル２５のそれぞれの登録内容を参照して、本発明に係る受付判定処理を行う。

すなわち、ステップＳ４０４、ステップＳ４０５で行われる現時刻リソース管理テーブル２３で示される現時刻で使用中のリソース量に、新たな即時呼で要求されたリソース量を加えた使用リソース量が、時間の経過に伴いどのように推移するかを計算して、近未来の時刻での使用リソースの推定量を算出する（ステップＳ４０７）。

そして、未来リソース管理テーブル２４に登録されている当該リンクの当該近未来の時刻での使用予定リソース量を取得（ステップＳ４０８）し、算出した推定リソース量とを加えた値が、当該リンクに対応付けられた使用可能リソースの値を超えるか否かを判定する（ステップＳ４０９）。

超える場合には、当該即時呼の要求の受付を拒否し（ステップＳ４１０）、超えなければ、ステップＳ４１１からステップＳ４０６に戻り、予め定められた時間帯の間でステップＳ４０６からステップＳ４１１を繰り返し、各時刻での受付判定をおこなう。

ステップＳ４０１で特定された該当リンク全てについて受付判定をおこなう、すなわちステップＳ４０３からステップＳ４１２を繰り返し受付判定をおこなう。最終的に全ての条件を満足する場合のみ受付を許可する。（ステップＳ４１３）

また、ステップＳ４０２での判別処理において、新たな接続要求が事前予約呼であれば、未来リソース管理テーブル２４に登録されている同時刻での使用予定リソース量を取得し（ステップＳ４１６）、この新たな事前予約呼で要求されるリソース量とを加え（ステップＳ４１７）、この加算値が、現時刻リソース管理テーブル２３において当該リンクに対応付けられた使用可能リソースの値を超えるか否かを判定する（ステップＳ４１８）。

超える場合には、当該即時呼の要求の受付を拒否し（ステップＳ４１０）、超えなければ、当該未来リソース管理テーブル２４と現時刻リソース管理テーブル２３および統計データ管理テーブル２５のそれぞれの登録内容を参照して、本発明に係る受付判定処理を行う。

すなわち、現時刻リソース管理テーブル２３で示される現時刻で使用中のリソース量が、時間の経過に伴いどのように推移するかを計算して、近未来の時刻での使用リソースの推定量を算出する（ステップＳ４１２）。

そして、算出した推定リソース量と、ステップＳ４１７での処理で算出した加算値とを加え、この再加算値が、現時刻リソース管理テーブル２３において当該リンクに対応付けられた使用可能リソースの値を超えるか否かを判定する（ステップＳ４２１）。

超える場合には、当該即時呼の要求の受付を拒否し（ステップＳ４１０）、超えなければ、ステップＳ４２２からステップＳ４１５に戻り、予め定められた時間帯の間でステップＳ４１５からステップＳ４２２を繰り返し、各時刻での受付判定をおこなう。

ステップＳ４０１で特定された該当リンク全てについて受付判定をおこなう。すなわちステップＳ４１４からステップＳ４２３を繰り返し受付判定をおこなう。最終的に全ての条件を満足する場合のみ受付を許可する。（ステップＳ４１３）

次に、このような受付判定手段５による、ステップＳ４０７での処理、すなわち、現時刻リソース管理テーブル２３で示される現時刻で使用中のリソース量に、新たな即時呼で要求されたリソース量を加えた使用リソース量が、時間の経過に伴いどのように推移するかを計算して、近未来の時刻での使用リソースの推定量を算出する処理、および、ステップＳ４２０での処理、すなわち、現時刻リソース管理テーブル２３で示される現時刻で使用中のリソース量が、時間の経過に伴いどのように推移するかを計算して、近未来の時刻での使用リソースの推定量を算出する処理の詳細を説明する。

受付判定手段５においては、現在までに受け付けた呼のリソース使用量に基づいて、将来の使用量を推定し、その推定値と新規呼の要求リソース量の和を、使用可能リソース量（上限リソース容量）と比較することにより受付の判定を行う。

すなわち、現時刻の使用リソース量はサービスの終了に伴い確保していたリソース分だけ減少するため、現時刻の使用リソース量は、時間の経過とともに減少することは保証されている。また、どのように減少推移するかは過去の使用リソース量の推移を基に推定する。

よって、統計データ作成手段２により、通信履歴テーブル２２に登録される過去の使用リソース量を基に算出され統計データ管理テーブル２５に登録された、当該リンクの通信継続時間、リソース使用率の統計データから算出される平均通信継続時間、平均リソース使用率などをパラメータとして利用することにより受付判定を行う。

ここで、新たな要求の受け付け現時刻をｔｎｏｗ、事前予約呼によるサービス開始時刻と終了時刻をそれぞれｔｓｔａｒｔとｔｅｎｄ、新たな要求リソース量をｘ、現時刻での使用リソース量をｘ’、当該リンクの上限リソース容量（現時刻リソース管理テーブル２３における使用可能リソース）をＢｍａｘ、任意の時刻ｔの推定リソース使用量をＢ（ｔ）、当該時刻ｔの事前予約呼で既に確保されているリソースをＲ（ｔ）、呼の平均通信継続時間をｈとした場合の受付判定手順例を以下に示す。

まず、新たな接続要求が即時呼の場合における受付判定例を説明する。下記の式（１）を用いて、任意の時刻ｔの推定使用リソース量Ｂ（ｔ）を求め、下記の式（２）を用いて、新たな即時呼の接続要求の受付判定を行う。

Ｂ（ｔ）＝（ｘ＋ｘ’）ｅ^{−α（ｔ−ｔｎｏｗ）／ｈ}＋β （α，βは定数） …（１）

Ｂ（ｔ）＋Ｒ（ｔ）＜Ｂｍａｘ …（２）

即時呼は、時刻ｔｎｏｗ〜ｔ’内で上記（２）式を全て満たす場合、受付を許可する。尚、この「ｔ’」は予め設定される定数であり、例えば、統計データ管理テーブル２５における通信継続時間から算出される平均通信継続時間等から決定される。

また、式（１）における定数αと定数βは、推定処理結果の安全確保のために、算出する推定使用リソース量Ｂ（ｔ）を意図的に大きくするためのものパラメータであり、これらの定数α，βの値を変えて推定使用リソース量Ｂ（ｔ）を大きくすることにより、式（２）による判定時に、上限リソース容量Ｂｍａｘとの比較による受付許可条件を厳しくすることができる。

また、これらの定数α，βは、統計データ管理テーブル２５における通信継続時間やリソース使用率の各情報に基づき、予め定められた任意の計算式により自動的に算出することでも、人手により設定することでも良い。例えば、定数αとして、統計データ管理テーブル２５における通信継続時間履歴から算出される平均通信継続時間を用いることでも良い。

次に、新たな接続要求が事前予約呼の場合における受付判定例を説明する。下記の式（３）を用いて、任意の時刻ｔの推定使用リソース量Ｂ（ｔ）を求め、下記の式（４）を用いて、新たな事前予約呼の接続要求の受付判定を行う。

Ｂ（ｔ）＝ｘ’ｅ^{−α（ｔ−ｔｓｔａｒｔ）／ｈ}＋β …（３）
Ｂ（ｔ）＋Ｒ（ｔ）＋ｘ＜Ｂｍａｘ …（４）

事前予約呼は、ｔｓｔａｒｔ〜ｔｅｎｄ内で上記（４）式を全て満たす場合、受付を許可し、それ以外は拒否する。

尚、上述の推定使用リソース量Ｂ（ｔ）等の関数は指数関数などにとどまらず、統計データ管理テーブル２５の通信状況の分布などを基に、時間帯や曜日等に合わせて、適した関数を適用することが可能である。

また、呼の平均通信継続時間ｈは、統計データ管理テーブル２５から直前までの平均通信継続時間を取得して適用することも、固定値にすることも可能である。

このようにして、式（１）と式（２）による即時呼に対する受付判定処理例、および、式（３）と式（４）による事前予約呼に対する受付判定処理例を図５および図６に示す。

図５は、図４における受付判定手段による即時呼に対する受付判定処理例を示す説明図であり、図６は、図４における受付判定手段による事前予約呼に対する受付判定処理例を示す説明図である。

図５に示すように、即時呼を受信した現時刻における使用リソース（帯域）量ｘ’に、即時呼で要求されるリソース量ｘを加えた値（ｘ＋ ｘ’）の時刻ｔにおける推定使用リソース量Ｂ（ｔ）は、時間の経過と共に減少する。

ここで、当該時刻ｔの事前予約呼で既に確保されている予約リソース量がＲ（ｔ）の場合、Ｂ（ｔ）＋Ｒ（ｔ）＜Ｂｍａｘの条件を満たしており、新たに要求されたリソース量ｘの即時呼は受付許可されるが、当該時刻ｔの事前予約呼で既に確保されている予約リソース量がＲ’（ｔ）の場合、Ｂ（ｔ）＋Ｒ’（ｔ）の値は、１時間経過前に、Ｂｍａｘよりも大きくなってしまうので、新たに要求されたリソース量ｘの即時呼は受付拒否される。

また、図６に示すように、事前予約呼を受信した現時刻における使用リソース（帯域）量ｘ’の時刻ｔにおける推定使用リソース量Ｂ（ｔ）は、時間の経過と共に減少する。

そして、新たなリソース量ｘの事前予約呼が時刻ｔ１ｓｔａｒｔをサービス開始時刻として要求された場合には、時刻ｔ１において既存の事前予約呼で確保されている予約リソース量Ｒ（ｔ）と、要求されたリソース量ｘ、および、時刻ｔ１における推定使用リソース量Ｂ（ｔ１）とを加算した値は、Ｂ（ｔ１）＋Ｒ（ｔ１）＋ｘ＞Ｂｍａｘとなり、このような、時刻ｔ１を含む時刻ｔ１ｓｔａｒｔを開始時刻としたリソース量ｘの新たな事前予約呼は受付拒否される。一方、新たなリソース量ｘの事前予約呼が時刻ｔ２ｓｔａｒｔをサービス開示時刻として要求された場合には、時刻ｔ２の時刻で既存の事前予約呼で確保されている予約リソース量Ｒ（ｔ）と、要求されたリソース量ｘ、および、時刻ｔ２における推定使用使用リソース量Ｂ（ｔ２）とを加算した値は、Ｂ（ｔ２）＋Ｒ（ｔ）＋ｘ＜Ｂｍａｘとなるように、どの時刻においても条件式を満たすため、この時刻ｔ２を含む時刻ｔ２ｓｔａｒｔをサービス開始時刻としたリソース量ｘの新たな事前予約呼は受付許可される。

図７は、本発明に係るリソース管理技術と従来のリソース管理技術との比較例を示す説明図である。従来の「即時呼」と「事前予約呼］で完全に分離した技術の場合は、各々の専用リソースで独立に管理すればよく、上述の式（１）と式（２）、および式（３）と（４）を用いてリソース（帯域）の時刻ｔ等における推定量を計算する必要はないが、設備設計によってなされたリソースの分割割合と、実際の即時呼と事前予約呼との割合に隔たりが大きい場合には、リソースの利用効率は大きく劣化してしまう。

これに対して、本例によれば、リソースを「即時呼」と「事前予約呼］で共用することができ、上述のようなリソースの利用効率が大きく劣化してしまうようなことはない。

尚、本例のように、共有リソースの場合においても、事前予約呼は全体の５０％まで、即時呼は１００％利用することが可能（言い換えると、全体の５０％は即時呼専用として利用し、残りの５０％は即時呼と事前予約呼で共有する）などのように、事前予約呼に一定の制限をもたせることにより、予約がいっぱいで即時呼が全く受け付けられない状態を防ぐことも可能である。

図８は、図１における受付制御サーバが設けられたネットワークの第２の構成例を示すブロック図であり、ここでは、２つのネットワーク３５，３６が設けられており、発信側の利用者端末（１）３３はネットワーク３５側に収容され、着信側の利用者端末（２）３４はネットワーク３６側に収容されている。

さらに、ネットワーク３５側におけるリソース管理および受付制御は、受付制御サーバ１ａにより、ネットワーク３６側におけるリソース管理および受付制御は、受付制御サーバ１ｂにより行われる。

利用者端末（１）３３からの利用者端末（２）３４への通信要求時の利用開始要求は、ネットワーク３５側を管理するセッション制御サーバ３１で受信し（図中、丸１）、セッション制御サーバ３１は受信した利用開始要求に対するネットワーク３５側での受付可否（リソース確保の可否）の判定を受付制御サーバ１ａに要求し、受付許可の応答が得られたならば、受信した利用開始要求をネットワーク３６側を管理するセッション制御サーバ３２に転送する（図中、丸２）。

セッション制御サーバ３１からの利用開始要求を受信したセッション制御サーバ３２は、当該利用開始要求に対するネットワーク３６側での受付可否（リソース確保の可否）の判定を受付制御サーバ１ｂに要求し、受付許可の応答が得られたならば、利用者端末（２）３４に対して着信の通知を行うと共に（図中、丸３）、セッション制御サーバ３１に対して、利用開始要求応答を送信する（図中、丸４）。

利用開始要求応答を受けたセッション制御サーバ３１は、利用者端末（１）３３に対して、当該利用開始要求応答を通知し（図中、丸５）。これにより、ネットワーク３５，３６を介しての利用者端末（１）３３と利用者端末（２）３４の通信が開始される。

以上、説明した本例の受付制御技術によれば、リソースの利用効率を高めることができると共に、呼損率を常に小さく抑えることが可能である。例えば、図９および図１０に示
すように、従来のリソース分割方式での設計値（リソース容量の分割の割合）が適切であっても、本例によるリソース推定による受付制御技術の方が呼損率を小さく抑えることができ、即時／事前予約呼の割合によらず有効である。

図９は、リソース呼量と呼損率の第１の関係例を示す説明図であり、全体のリソース容量に対する単位時間当たりの要求呼の総リソース要求量の割合をリソース呼量（％）とし、リソース呼量を占める即時呼と事前予約呼の割合を変動させた時の呼損率を示す。

図９に示すように、従来の保護時間方式では、即時呼の割合が例えば７０％以下の場合、呼損率（事前予約呼の受付拒否も呼損とみなす）が非常に大きくなり、また、従来のリソース分割方式でも、即時呼と事前予約呼の割合が設計値（本シミュレーションでは１：１に均等にリソース容量を分割）と異なる場合、即時呼の割合が小さいとき（例えば３０％以下）場合には、呼損率が非常に大きくなる。これに対して、本例の受付制御技術では、呼損率が常に小さく抑えられていることが分かる。

図１０は、リソース呼量と呼損率の第２の関係例を示す説明図であり、ここでは、呼種の割合を一定（１：１）にし、リソース呼量を増加させた場合の呼損率を示している。

この図１０に示すように、従来のリソース分割方式での、設計値（リソース容量の分割の割合）が適切であっても、本例のリソース推定による受付制御技術の方が呼損率を小さく抑えることができ、本例の受付制御技術が呼種の割合によらず有効であるといえる。

以上、図１〜図１０を用いて説明したように、本例の受付制御技術では、即時呼と事前予約呼とが混在するＩＰネットワークにおける新たな呼の受付制御を行う際、当該新規呼の接続に用いる各リンク毎に、現在までに当該リンクで受け付けた呼のリソース使用量に基づき、当該リンクにおける将来のリソース使用量を推定し、その推定値と新規呼の要求リソース量との和を、予め当該リンクに対応付けて設定・登録された使用上限値と比較することにより受付の判定を行う。

すなわち、新規の接続要求の接続に用いるリンクを特定し、新規の接続要求が即時呼であれば、特定したリンクで現在使用中のリソース量と、当該即時呼で要求されるリソース量とを加算し、この加算値が、時間の経過に伴い推移するリソース使用推移値を、過去の当該リンクでの通信履歴統計情報を用いて算出し、算出したリソース使用量推移値と、特定したリンクの、他の事前予約呼により予約済みのリソース使用量とを加算し、この加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可し、また、新規の接続要求が事前予約呼であれば、特定したリンクで現在使用中のリソース量値が、時間の経過に伴い推移するリソース使用推移値を、過去の当該リンクでの通信履歴統計情報を用いて算出し、算出したリソース使用量推移値と、特定したリンクの、他の事前予約呼により予約済みのリソース使用量と、当該事前予約呼で要求されるリソース量とを加算し、このようにして加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可する。

より詳細には、予め入力された、発側エッジノードと着側エッジノードの組と、当該発側エッジノードと着側エッジノード間を接続するリンク群とを対応付けた経路情報を経路（リンク）テーブル２１に登録して記憶装置に記憶すると共に、リンク群の各リンク毎に、予め定められた当該リンクで使用可能な最大リソース量と、当該リンクで使用中のリソース量とを、現時刻リソース管理テーブル２４に登録して記憶装置に記憶し、また、リンク群の各リンク毎に、事前予約呼で要求された予約リソース量を予め設定された予約時間帯に対応付けて未来リソース管理テーブル２４に登録して記憶装置に記憶し、さらに、各リンク毎に、当該リンクを使用した通信の開始時刻と終了時刻および使用リソース量を少なくとも含む履歴情報を収集して通信履歴テーブル２２に登録して記憶装置に格納する。そして、統計データ作成手段２により、各リンク毎に、通信履歴テーブル２２から履歴情報を読み込み、予め定められた時間帯における当該リンクでの通信継続時間とリソース使用率を算出して、当該時間帯に対応付けた統計情報を生成して統計データ管理テーブル２５に登録して記憶装置に格納する。この状態で、メッセージ送受信手段７が、新たな接続要求を受けると、まず、経路（リンク）特定手段６が、経路（リンク）テーブル２１から経路情報を読み込み、要求された接続に用いるリンクを特定し、次に、受付判定手段５が、特定したリンクをキーに現時刻リソース管理テーブル２３と未来リソース管理テーブル２４および統計データ管理テーブル２５を検索して、現時刻リソース管理テーブル２３から当該リンクの使用可能な最大リソース量と当該リンクの使用中リソース量を、未来リソース管理テーブル２４から当該リンクの予約リソース量を、統計データ管理テーブル２５から当該リンクの統計情報を読み込み、新たな接続要求が即時呼であれば、新たな即時呼で要求されるリソース量と現時刻リソース管理テーブル２３から読み込んだ使用中リソース量とを加算し、加算した第１の加算値が時間の経過に伴い推移する値（リソース使用量推移値）を、統計データ管理テーブル２５から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出し、算出したリソース使用量推移値と未来リソース管理テーブル２４から読み込んだ予約リソース量を加算し、加算した第２の加算値と、現時刻リソース管理テーブル２３から読み込んだ最大リソース量とを比較し、第２の加算値が最大リソース量より大きくなることがあれば、新たな接続要求の受付を拒否し、第２の加算値が最大リソース量より大きくなることがなければ、新たな接続要求の受付を許可し、また、新たな接続要求が事前予約呼であれば、現時刻リソース管理テーブル２３から読み込んだ使用中リソース量が時間の経過に伴い推移する値（リソース使用量推移値）を、統計データ管理テーブル２５から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出し、算出したリソース使用量推移値と新たな事前予約呼で要求されるリソース量および未来リソース管理テーブル２４から読み込んだ予約リソース量を加算し、加算した第３の加算値と、現時刻リソース管理テーブル２３から読み込んだ最大リソース量とを比較し、第３の加算値が最大リソース量より大きくなることがあれば、新たな接続要求の受付を拒否し、第３の加算値が最大リソース量より大きくなることがなければ、新たな接続要求の受付を許可する。

また、新規の接続要求が事前予約呼で、かつ、この事前予約呼の開始時刻が、予め定められた時間（例えば１週間）を超えていれば、特定したリンクの他の事前予約呼により予約済みのリソース使用量と、当該事前予約呼で要求されるリソース量のみを加算し、加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可する。

このように、本例では、過去の利用状況からリソースの使用状況を推定し、予約型と即時型でリソースを共用して、リソースの有効利用を図ることができ、電話等の即時呼とＴＶ会議等の事前予約呼の２形態の呼が混在したＩＰネットワークにおける呼の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行うことができる。

尚、本発明は、図１〜図１０を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、上述したように、式（１）〜（４）における推定使用リソース量Ｂ（ｔ）等の関数は指数関数などにとどまらず、統計データ管理テーブル２５の通信状況の分布などを基に、時間帯や曜日等に合わせて、適した関数を適用することが可能である。

また、図４における例では、ステップＳ４０２からＳ４０９の処理の流れにおける即時呼の受付可否の判定に際して、未来リソース管理テーブル２４に該当する時間帯の事前予約呼が無いと判断できた場合は、現時刻リソース管理テーブル２３に登録された現在使用中のリソース量と新たな即時呼で要求されたリソース量とを加えて、その加算値と、使用可能リソース値との比較により、受付の可否を判定のみをおこない、それ以後の時刻でのループ（ステップＳ４１１）を省略する（ループを抜ける）ことも可能とすることでも良い。

さらに、ステップＳ４０２において、接続要求が即時呼であるか事前予約呼であるかを判定するのではなく、例えば、接続要求を受信した時点で、現時刻リソース管理テーブル２３と未来リソース管理テーブル２４および統計データ管理テーブル２５から、当該リンクに関するそれぞれの登録内容を読み込み、その後、即時呼と事前予約呼の判別を行い、即時呼であればステップＳ４０３からステップＳ４１２の処理を、事前予約呼であればステップＳ４１４〜Ｓ４２３の処理を、それぞれ読み込んだ情報を用いて行うことでも良い。

また、コンピュータ構成例にしても、キーボードや光ディスクの駆動装置の無いコンピュータ構成としても良い。また、本例では、光ディスクを記録媒体として用いているが、ＦＤ（Fｌｅｘｉｂｌｅ Ｄｉｓk）等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。

本発明に係るＩＰネットワークにおける呼の受付制御を行うシステム（受付制御サーバ）の構成例を示すブロック図である。 図１における受付制御サーバで記憶・管理される各情報の内容を示す説明図である。 図１における受付制御サーバが設けられたネットワークの第１の構成例を示すブロック図である。 図１における受付判定手段の処理動作例を示すフローチャートである。 図４における受付判定手段による即時呼に対する受付判定処理例を示す説明図である。 図４における受付判定手段による事前予約呼に対する受付判定処理例を示す説明図である。 本発明に係るリソース管理技術と従来のリソース管理技術との比較例を示す説明図である。 図１における受付制御サーバが設けられたネットワークの第２の構成例を示すブロック図である。 リソース呼量と呼損率の第１の関係例を示す説明図である。 リソース呼量と呼損率の第２の関係例を示す説明図である。

符号の説明

１：受付制御サーバ、２：統計データ作成手段、３：通信履歴管理手段、４：リソース管理手段、５：受付判定手段、６：経路（リンク）特定手段、７：メッセージ送受信手段、２１：経路（リンク）テーブル、２２：通信履歴テーブル、２３：現時刻リソース管理テーブル、２４：未来リソース管理テーブル、２５：統計データ管理テーブル、３１，３２：セッション制御サーバ、３３，３４：利用者端末、３５，３６：ネットワーク。

Claims (7)

1. 要求時点で即時に接続開始を要求する即時呼でのＩＰパケット転送、および、予約した時刻からの接続開始を要求する事前予約呼でのＩＰパケット転送を、リソースを共用して行うネットワークにおける、上記即時呼および上記事前予約呼に対する受付可否の判定を、リソースの空き状況に基づき行う受付制御システムであって、
   予め入力された、発側エッジノードと着側エッジノードの組と、当該発側エッジノードと着側エッジノード間を接続するリンク群とを対応付けた経路情報を記憶する経路記憶手段と、
   上記リンク群の各リンク毎に、予め定められた当該リンクで使用可能な最大リソース量を記憶する第１のリソース情報記憶手段と、
   上記リンク群の各リンク毎に、当該リンクで使用中のリソース量を記憶する第２のリソース情報記憶手段と、
   上記リンク群の各リンク毎に、上記事前予約呼で要求された予約リソース量を予め設定された予約時間帯に対応付けて記憶する第３のリソース情報記憶手段と、
   各リンク毎に、当該リンクを使用した通信の開始時刻と終了時刻および使用リソース量を少なくとも含む履歴情報を収集して通信履歴記憶手段に格納する通信履歴管理手段と、
   各リンク毎に、上記通信履歴記憶手段から上記履歴情報を読み込み、予め定められた時間帯における当該リンクでの通信継続時間とリソース使用率を算出して、当該時間帯に対応付けた統計情報を生成して統計データ記憶手段に格納する統計データ管理手段と、
   新たな接続要求があれば、上記経路記憶手段から上記経路情報を読み込み、要求された接続に用いるリンクを特定する経路特定手段と、
   該経路特定手段が特定したリンクをキーに上記第１のリソース情報記憶手段と上記第２のリソース情報記憶手段および上記第３のリソース情報記憶手段と上記統計データ記憶手段を検索して、
   上記第１のリソース情報記憶手段から当該リンクの使用可能な最大リソース量を、
   上記第２のリソース情報記憶手段から当該リンクの使用中リソース量を、
   上記第３のリソース情報記憶手段から当該リンクの予約リソース量を、
   上記統計データ記憶手段から当該リンクの統計情報を読み込み、
   上記新たな接続要求が即時呼であれば、
   該新たな即時呼で要求されるリソース量と上記第２のリソース情報記憶手段から読み込んだ使用中リソース量とを加算し、
   該加算した第１の加算値が時間の経過に伴い推移する値を、上記統計データ記憶手段から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出し、
   該算出した推移値と上記第３のリソース情報記憶手段から読み込んだ予約リソース量を加算し、該加算した第２の加算値と、上記第１のリソース情報記憶手段から読み込んだ最大リソース量とを比較し、
   上記第２の加算値が上記最大リソース量より大きくなることがあれば、上記新たな接続要求の受付を拒否し、
   上記第２の加算値が上記最大リソース量より大きくなることがなければ、上記新たな接続要求の受付を許可し、
   上記新たな接続要求が事前予約呼であれば、
   上記第２のリソース情報記憶手段から読み込んだ使用中リソース量が時間の経過に伴い推移する値を、上記統計データ記憶手段から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出し、
   該算出した推移値と上記新たな事前予約呼で要求されるリソース量および上記第３のリソース情報記憶手段から読み込んだ予約リソース量を加算し、該加算した第３の加算値と、上記第１のリソース情報記憶手段から読み込んだ最大リソース量とを比較し、
   上記第３の加算値が上記最大リソース量より大きくなることがあれば、上記新たな接続要求の受付を拒否し、
   上記第３の加算値が上記最大リソース量より大きくなることがなければ、上記新たな接続要求の受付を許可する判定手段と
   を有することを特徴とする受付制御システム。
2. 要求時点で即時に接続開始を要求する即時呼でのＩＰパケット転送、および、予約した時刻からの接続開始を要求する事前予約呼でのＩＰパケット転送を、リソースを共用して行うネットワークにおける、上記即時呼および上記事前予約呼に対する受付可否の判定を、リソースの空き状況に基づき行う受付制御方法であって、
   新規の接続要求の接続に用いるリンクを特定するステップと、
   上記新規の接続要求が即時呼であれば、上記特定したリンクで現在使用中のリソース量と、当該即時呼で要求されるリソース量とを加算し、該加算値が、時間の経過に伴い推移するリソース使用推移値を、過去の当該リンクでの通信履歴統計情報を用いて算出し、該算出したリソース使用量推移値と、上記特定したリンクの、他の事前予約呼により予約済みのリソース使用量とを加算し、該加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可するステップと、
   上記新規の接続要求が事前予約呼であれば、上記特定したリンクで現在使用中のリソース量値が、時間の経過に伴い推移するリソース使用推移値を、過去の当該リンクでの通信履歴統計情報を用いて算出し、該算出したリソース使用量推移値と、上記特定したリンクの、他の事前予約呼により予約済みのリソース使用量と、当該事前予約呼で要求されるリソース量とを加算し、該加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可するステップと
   を有することを特徴とする受付制御方法。
3. 要求時点で即時に接続開始を要求する即時呼でのＩＰパケット転送、および、予約した時刻からの接続開始を要求する事前予約呼でのＩＰパケット転送を、リソースを共用して行うネットワークにおける、上記即時呼および上記事前予約呼に対する受付可否の判定を、リソースの空き状況に基づき行う受付制御方法であって、
   予め入力された、発側エッジノードと着側エッジノードの組と、当該発側エッジノードと着側エッジノード間を接続するリンク群とを対応付けた経路情報を経路記憶手段に記憶するステップと、
   上記リンク群の各リンク毎に、予め定められた当該リンクで使用可能な最大リソース量を第１のリソース情報記憶手段に記憶するステップと、
   上記リンク群の各リンク毎に、当該リンクで使用中のリソース量を第２のリソース情報記憶手段に記憶するステップと、
   上記リンク群の各リンク毎に、上記事前予約呼で要求された予約リソース量を予め設定された予約時間帯に対応付けて第３のリソース情報記憶手段に記憶するステップと、
   各リンク毎に、当該リンクを使用した通信の開始時刻と終了時刻および使用リソース量を少なくとも含む履歴情報を収集して通信履歴記憶手段に格納するステップと、
   各リンク毎に、上記通信履歴記憶手段から上記履歴情報を読み込み、予め定められた時間帯における当該リンクでの通信継続時間とリソース使用率を算出して、当該時間帯に対応付けた統計情報を生成して統計データ記憶手段に格納するステップと、
   新たな接続要求があれば、上記経路記憶手段から上記経路情報を読み込み、要求された接続に用いるリンクを特定するステップと、
   該特定したリンクをキーに上記第１のリソース情報記憶手段と上記第２のリソース情報記憶手段および上記第３のリソース情報記憶手段と上記統計データ記憶手段を検索して、
   上記第１のリソース情報記憶手段から当該リンクの使用可能な最大リソース量を、
   上記第２のリソース情報記憶手段から当該リンクの使用中リソース量を、
   上記第３のリソース情報記憶手段から当該リンクの予約リソース量を、
   上記統計データ記憶手段から当該リンクの統計情報を読み込むステップと、
   上記新たな接続要求が即時呼であれば、
   該新たな即時呼で要求されるリソース量と上記第２のリソース情報記憶手段から読み込んだ使用中リソース量とを加算するステップと、
   該加算した第１の加算値が時間の経過に伴い推移する値（リソース使用量推移値）を、上記統計データ記憶手段から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出するステップと、
   該算出したリソース使用量推移値と上記第３のリソース情報記憶手段から読み込んだ予約リソース量を加算するステップと、
   該加算した第２の加算値と、上記第１のリソース情報記憶手段から読み込んだ最大リソース量とを比較するステップと、
   上記第２の加算値が上記最大リソース量より大きくなることがあれば、上記新たな接続要求の受付を拒否し、
   上記第２の加算値が上記最大リソース量より大きくなることがなければ、上記新たな接続要求の受付を許可するステップと、
   上記新たな接続要求が事前予約呼であれば、
   上記第２のリソース情報記憶手段から読み込んだ使用中リソース量が時間の経過に伴い推移する値（リソース使用量推移値）を、上記統計データ記憶手段から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出するステップと、
   該算出したリソース使用量推移値と上記新たな事前予約呼で要求されるリソース量および上記第３のリソース情報記憶手段から読み込んだ予約リソース量を加算するステップと、
   該加算した第３の加算値と、上記第１のリソース情報記憶手段から読み込んだ最大リソース量とを比較するステップと、
   上記第３の加算値が上記最大リソース量より大きくなることがあれば、上記新たな接続要求の受付を拒否し、
   上記第３の加算値が上記最大リソース量より大きくなることがなければ、上記新たな接続要求の受付を許可するステップと
   を有することを特徴とする受付制御方法。
4. 請求項２もしくは請求項３のいずれかに記載の受付制御方法であって、
   任意の時刻ｔ上記リソース使用量推移値をＢ（ｔ）、新たな接続要求の受け付け現時刻をｔｎｏｗ、事前予約呼によるサービス開始時刻と終了時刻をそれぞれｔｓｔａｒｔとｔｅｎｄ、新たな要求リソース量をｘ、現時刻での使用リソース量をｘ’、当該リンクの使用上限リソース容量をＢｍａｘ、当該時刻ｔの事前予約呼で既に確保されている予約済みリソース量をＲ（ｔ）、呼の平均通信継続時間をｈとし、
   新たな接続要求が即時呼の場合には、
   式（１）「Ｂ（ｔ）＝（ｘ＋ｘ’）ｅ^{−α（ｔ−ｔｎｏｗ）／ｈ}＋β （α，βは予め定められる定数）」等、使用量推定値Ｂ（ｔ）を関数により算出する式を用いて、上記任意の時刻ｔのリソース使用量推移値Ｂ（ｔ）を求め、式（２）「Ｂ（ｔ）＋Ｒ（ｔ）＜Ｂｍａｘ」を、時刻ｔｎｏｗ〜予め定められた時間ｔ’内で全て満たす場合、当該即時呼の受付を許可するステップと、
   新たな接続要求が事前予約呼の場合には、
   式（３）「Ｂ（ｔ）＝ｘ’ｅ^{−α（ｔ−ｔｓｔａｒｔ）／ｈ}＋β （α，βは予め定められる定数）」等、使用量推定値Ｂ（ｔ）を関数により算出する式を用いて、上記任意の時刻ｔの推定リソース使用量Ｂ（ｔ）を求め、式（４）「Ｂ（ｔ）＋Ｒ（ｔ）＋ｘ＜Ｂｍａｘ」を、時刻ｔｓｔａｒｔ〜ｔｅｎｄ内で全て満たす場合、当該事前予約呼の受付を許可するステップと、
   それ以外は拒否するステップとを有することを特徴とする受付制御方法。
5. 請求項２から請求項４のいずれかに記載の受付制御方法であって、
   新規の接続要求が事前予約呼で、かつ、該事前予約呼の開始時刻が、予め定められた時間を超えていれば、
   上記特定したリンクの他の事前予約呼により予約済みのリソース使用量と、当該事前予約呼で要求されるリソース量のみを加算し、
   該加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可するステップを有する
   ことを特徴とする受付制御方法。
6. 請求項２から請求項５のいずれかに記載の受付制御方法であって、
   上記リソースの予め定められた割合を即時呼に専用に割り当て、
   残りを即時呼と事前予約呼で共用することを特徴とする受付制御方法。
7. コンピュータに、請求項２から請求項６のいずれかに記載の受付制御方法における各ステップを実行させるためのプログラム。

Images