JP2008085686A - 予約受付制御システムと方法およびプログラム - Google Patents
予約受付制御システムと方法およびプログラム Download PDFInfo
- Publication number
- JP2008085686A JP2008085686A JP2006263725A JP2006263725A JP2008085686A JP 2008085686 A JP2008085686 A JP 2008085686A JP 2006263725 A JP2006263725 A JP 2006263725A JP 2006263725 A JP2006263725 A JP 2006263725A JP 2008085686 A JP2008085686 A JP 2008085686A
- Authority
- JP
- Japan
- Prior art keywords
- resource
- link
- call
- amount
- storage means
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】電話等の即時呼とTV会議等の事前予約呼の2形態の呼が混在したIPネットワークにおける呼の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行う。
【解決手段】経路特定手段6は新規接続に用いるリンクを特定し、受付判定手段は、新規接続が例えば即時呼であれば、当該リンクで使用中のリソース量と該即時呼で要求されるリソース量とを加算し、加算した値が、時間の経過に伴い推移するリソース使用推移値を、過去の通信履歴情報を用いて算出し、算出したリソース使用量推移値と、当該リンクの他の事前予約呼による予約済リソース使用量とを加算し、この加算した値と、予め当該リンクに設定されたリソース使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可することを特徴とする。
【選択図】図1
【解決手段】経路特定手段6は新規接続に用いるリンクを特定し、受付判定手段は、新規接続が例えば即時呼であれば、当該リンクで使用中のリソース量と該即時呼で要求されるリソース量とを加算し、加算した値が、時間の経過に伴い推移するリソース使用推移値を、過去の通信履歴情報を用いて算出し、算出したリソース使用量推移値と、当該リンクの他の事前予約呼による予約済リソース使用量とを加算し、この加算した値と、予め当該リンクに設定されたリソース使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可することを特徴とする。
【選択図】図1
Description
本発明は、IPネットワークにおける呼の受付制御技術に係り、特に、電話等の即時呼とTV会議等の事前予約呼が混在する際の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行うのに好適な技術に関するものである。
IPネットワークなどのパケット通信では、複数の利用者が共通のネットワークを用いてそれぞれパケットの送受信を行う。ネットワークは有限の通信リソース(回線の帯域幅、ルータ等のノードのバッファ量など)を持っているため、利用者数が大きくなってネットワークの転送能力を超える量のパケットが流入すると、パケットの到着の遅延が大きくなったり、廃棄(パケットロス)が発生したりして、通信サービスの品質が劣化してしまう。
特に、IPネットワーク上での映像・音声などの多くのリソース容量を用いる通信サービスでは、ネットワークのリソース容量を超える利用要求によって輻輳が発生し、品質劣化となる。このような通信品質の劣化に対しては、再送制御などのアプリケーションレベルの品質向上技術があるが、このようなアプリケーションレベルの品質向上技術では大きな効果が望めず、OSI参照モデルのネットワークレイヤ(ネットワーク層)にて、各フローに対して排他的に利用リソースを確保する必要がある。
このような技術として、ネットワークを構成するルータ等のノードにおいて、パケット転送時に「優先制御」を行う技術が普及している。例えば、IPネットワークにおけるDiffservという技術は、パケットのヘッダに優先度をつけておき、ルータにおいて、転送能力を超えるパケットが流入した際には優先度の低いパケットを廃棄したり後回しにしたりして優先度の高いパケットを優先的に転送するものであり、これによってパケットの遅延や廃棄確率などの品質条件を相対的に高く保つことが可能となる。近年のルータにはこの機能が実装されているものが多い。
尚、パケット通信においては、利用者が転送したい情報を1つまたは複数のパケットを使用して送信する。一般的に、あるネットワークの利用(あるデータの転送開始から終了まで、ある電話の通話開始から終了まで、など)をセッションと呼び、そのセッションのために連続的に転送されるパケットの集合のことをフローと呼ぶ。優先制御の主な利用技術としては、パケットごとに転送優先度を決定するのではなく、フロー単位で優先度をつける。
上述の優先制御についての技術では、転送優先度の高いフローと低いフローが混在している場合、高優先フローの転送品質の確保に効果があるが、高優先度フロー数が増加し、それだけでネットワークリソースを使い切ってしまうような場合には高優先フローであっても転送品質の劣化は免れない。高優先フローをネットワークのリソース容量以上に収容することは可能だが、サービス品質の劣化が全利用者に及んでしまう。
このような問題に対処して、転送品質を維持するために、ネットワークのリソース容量以上の利用要求を拒絶するという制御を行う技術が有効であり、このような技術は受付制御(Admission Control)と呼ばれる。
非特許文献1では、IPネットワークにおいて、ネットワーク中の全てのリンクのリソース容量と、利用されているリソース量とをリソース管理サーバにおいて把握しておくことで、新たなセッションの発生による利用要求を受信した際に受付判定を行う技術が記載されている。
このリソース管理サーバでは、管理対象のネットワーク中の全てのリンクについて、高優先フローが使用しているリソース量をリアルタイムに管理している。これは、高優先フローの利用開始時に利用要求を受信し、それを記録することによって行われる。
また、リソース管理サーバは、ネットワークからの情報収集によって経路(リンク)情報と各リンクのリソース容量を把握している。そして、利用要求の受信時には、そのフローが通過する全てのリンクを経路(リンク)情報から検索し、各リンクの使用リソース量を加算して記録する。
このとき、使用量がリソース容量を超えてしまう場合は、この利用要求に対して利用すること自体を、または優先フローとして扱うことを拒絶する。後者の場合、該当する要求の通信は非優先フローとして許容される。
このようなリソース管理・受付制御技術により、高優先フローは、ネットワークのリソース容量が許す限り収容され、容量を超えることは防止されるので、利用を許容されたフローはその品質が確保される。
以下、このような受付制御の適用例を説明する。このような受付制御機能を持つリソース管理・受付制御サーバは、通信キャリアがIP技術でさまざまな通信サービスを統合して大規模に展開する次世代ネットワーク(「NGN」)の国際標準化の中でもその必要性を認識させており、ITU−TやETSI TISPANにおいてRACS(Reurce and Admission Control Subsystem)としてネットワークアーキテクテャ内に定義されている。
このような適用例の中で、リソース管理・受付制御サーバは、IP電話、TV電話、VoD(Video on Demand)などの様々なセッションベースの通信サービスの発信時に、アプリケーションサーバやセッション制御サーバから受付制御機能として呼びだされ、応答を行う。
具体的には、呼の生起(利用者からサービス利用開始の意思を通知する)時に利用者からの接続要求がアプリケーションサーバやセッション制御サーバに通知され、各サーバが接続処理を行う中で、求められる品質で接続することが可能かを受付制御サーバに問い合わせる。問い合わせを受けた受付制御サーバは、リソースの空き状況を確認し、空きがあると判断すれば受付許可を、空きがないと判断すれば受け付け拒否を通知する。
受付を許可した接続が確立された後、その呼を切断する際には、当該アプリケーションサーバやセッション制御サーバは、受付制御サーバに対して該当呼の処理を通知し、受付制御サーバは、該当呼のために確保していたリソースを開放する処理を行い、切断処理の完了通知を応答する。
次に、呼損率について説明する。サービス提供システムの故障などの要因も含め、利用要求呼が拒絶されることは呼損と呼ばれる。上述のように、サービスリソースが不足している時に呼を収容したり待たせたりせずに即時拒絶するタイプのサービスは「呼損モデル」と呼ばれる。また、全体の利用要求数に対する呼損の割合を呼損率と呼ぶ。
サービス提供者は呼損率が大きくならないようにネットワークシステムのリソース設計を行うが、利用者の急増や、利用機会の急増(チケット予約の電話や災害時の見舞電話、話題性の高いWebコンテンツヘの接続など)時には呼損率が想定以上となってしまうことがある。
また、本来のリソース容量を有効に活用できないようなリソース管理技術では、この呼損率が高くなってしまう。そのため、如何に有限なリソースを有効に活用し、呼損率を抑えるかが、ネットワーク上の通信サービスにおいて、高い品質(QoS)を実現するための重要な技術課題となる。
このように、ネットワーク上の通信サービスにおいて高い品質(QoS)を実現するために、リンクの帯域などのリソース量の使用状況を管理し、使用量がリンクのリソース容量を超えないように管理することによって品質を制御する受付制御が有効である。
この受付制御によって実現されるサービスの利用形態として、電話のように、利用したいときに即座に利用する即時型と、TV会議やTV番組視聴などのように、決められた時刻から利用するために事前に予約をしておく事前予約型の2形態が想定される。
即時型の要求(即時呼)はサービスの終了時刻が不明であるため、そこで使用しているリソースが何時開放されるかも不明であり、当該リソースを、未来の時刻を指定する事前予約型の要求で利用する場合、この事前予約型の要求(事前予約呼)に対して正確な受付判定を行うことができない。
従来、前者の即時呼に対する受付判定については、さまざまな技術が論じられて実現されてきているが、上述のように、即時呼に加え予約呼も混在した場合の受付制御については、呼損率とリソースの利用効率に有効な技術がまだ確立されていない。
最も単純な技術として、リソース量を「即時用」と「事前予約用」に分割して独立管理するリソース分割技術が考えられるが、設備設計によってなされたリソースの分割割合と、実際の即時呼と事前予約呼の割合に隔たりが大きい場合には、リソースの利用効率は大きく劣化してしまう。
これに対して、例えば、即時呼の割合と事前予約呼の割合が、一日の午前・午後といった時間帯、週の曜日によっても異なると考え、即時呼と事前予約呼でリソースを共有する技術が、非特許文献2,3に記載されている。
例えば、非特許文献2においては、即時呼に無関係に事前予約を受け付け、競合した場合は優先順位に従って強制切断する技術が提案されている。しかし、この技術では、リソースの利用効率は高いが、提供するサービスの種別によっては突然強制切断される可能性があり、ユーザに対してのサービス的な問題が内在している。
また、非特許文献3においては、保護時間を設定した制御技術が提案されている。この技術では保護時間Tを設定し、即時呼は、開始後、設定した保護時間T秒経過時に強制切断し、事前予約は、保護時間T秒より後に開始する時間帯のもののみを受け付け、開始T秒前からリソースを占有させる。
しかし、この技術では、呼損率を低く抑えるのには有効であるが、事前予約呼について保護時間分だけ余計にリソースを必要とするため、事前予約呼の割合に影響を受け、リソース分割方式よりリソース効率が悪いケースがある。
笠原,他:"パーフローQoSを実現するエージェント型リソース制御システム,"情報処理学会論文誌,Vol.46 No.2, pp.517−524, Feb.2005.
O.Schelen, et, al:"An Agent−based Architecture for Advance Reservations,"Proc.IEEE 22nd Annual Conf. on Computer Networks(LCN’97),(1997).
北村,他:"受付制御型品質制御における時間指定予約要求についての一考察,"2003 信学ソ大,B−6−79(2003).
解決しようとする問題点は、従来の技術では、ネットワークの受付制御において、現時刻から通信サービスの利用を開始する即時型の要求と、利用時刻を指定して予約を行う予約型の要求とが混在する場合には、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら受付制御を行うことができない点である。
本発明の目的は、これら従来技術の課題を解決し、電話等の即時呼とTV会議等の事前予約呼の2形態の呼が混在した場合の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行うことを可能とし、IPネットワークを利用した映像・音声通信などのストリーム型通信サービスを高品質に提供することである。
上記目的を達成するため、本発明では、即時呼と事前予約呼とが混在するIPネットワークにおける新たな呼の受付制御を行う際、新規の接続要求の接続に用いるリンクを特定し、新規の接続要求が即時呼であれば、特定したリンクで現在使用中のリソース量と、当該即時呼で要求されるリソース量とを加算し、この加算値が、時間の経過に伴い推移するリソース使用推移値を、過去の即時呼の通信履歴情報を用いて算出し、算出したリソース使用量推移値と、特定したリンクの、他の事前予約呼により予約されたリソース使用量とを加算し、加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可し、また、新規の接続要求が事前予約呼であれば、特定したリンクで現在使用中のリソース量値が、時間の経過に伴い推移するリソース使用推移値を、過去の即時呼の通信履歴情報を用いて算出し、算出したリソース使用量推移値と、特定したリンクの、他の事前予約呼により予約されたリソース使用量と、当該事前予約呼で要求されるリソース量とを加算し、加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可することを特徴とする。
本発明によれば、電話等の即時呼とTV会議等の事前予約呼の2形態の呼が混在したIPネットワークにおける呼の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行うことが可能である。
以下、図を用いて本発明を実施するための最良の形態例を説明する。図1は、本発明に係るIPネットワークにおける呼の受付制御を行うシステム(受付制御サーバ)の構成例を示すブロック図であり、図2は、図1における受付制御サーバで記憶・管理される各情報の内容を示す説明図、図3は、図1における受付制御サーバが設けられたネットワークの第1の構成例を示すブロック図、図4は、図1における受付判定手段の処理動作例を示すフローチャートである。
図1における受付制御サーバ1は、CPU(Central Processing Unit)や主メモリ、表示装置、入力装置、外部記憶装置等を備えたコンピュータ構成からなり、光ディスク駆動装置等を介してCD−ROM等の記憶媒体に記録されたプログラムやデータを外部記憶装置内にインストールした後、この外部記憶装置から主メモリに読み込みCPUで処理することにより、各処理を実行する機能を有する。
すなわち、受付制御サーバ1は、プログラムに基づくCPUの処理で実現する機能として、統計データ作成手段2、通信履歴管理手段3、リソース管理手段4、受付判定手段5、経路(リンク)特定手段6、メッセージ送受信手段7を有している。
統計データ作成手段2、通信履歴管理手段3、リソース管理手段4、受付判定手段5、経路(リンク)特定手段6のそれぞれは、図2にそれぞれの詳細を示す各テーブル(経路(リンク)テーブル21、通信履歴テーブル22、現時刻リソース管理テーブル23、未来時刻リソース管理テーブル24、統計データ管理テーブル25)の参照、生成を行い、本発明に関わる処理を実行する。
図2における、経路(リンク)テーブル21、通信履歴テーブル22、現時刻リソース管理テーブル23、未来時刻リソース管理テーブル24、統計データ管理テーブル25は、磁気ディスク装置や主メモリ等の記憶装置に記憶されたものである。
例えば、経路(リンク)テーブル21には、予め入力された、発側エッジノードと着側エッジノードの組と、当該発側エッジノードと着側エッジノード間を接続するリンク群とが対応付けて登録されており、経路(リンク)特定手段6は、メッセージ送受信手段7が受信した接続要求メッセージで示される発側エッジノード(例えばR11)と着側エッジノード(例えばR323)を受け取り(A)、これらをキーに、経路(リンク)テーブル21を参照して、対応付けられたリンク群(Link2−Link7)を特定する。
このような経路(リンク)テーブル21における登録内容は、図3に示すネットワーク構成例を表しており、例えば、端末(1)と端末(2)が接続されたエッジルータR11と、端末(6)が接続されたエッジルータR32間は、ルータR22を中継してリンク2(Link2),リンク7(Link7)経由で接続されることが登録されている。
そして、通信履歴管理手段3は、図2の通信履歴テーブル22においてリンク1(Link1)に関して例示すように、各通信サービス毎に、サービス開始時刻、サービス終了時刻、サービス内容、要求リソース(bps)等の情報を、各リンク別に登録する。
図3に示すネットワークにおいては、各端末から要求される接続として、電話のように、利用したいときに即座に利用する即時型と、TV会議やTV番組視聴などのように、決められた時刻から利用するために事前に予約をしておく事前予約型の2形態が混在する。そして、本例のネットワークでは、リソースを上述の即時型と事前予約型に、完全に分割して独立使用するのではなく、即時型と事前予約型でリソースを共用する。
リソース管理手段4は、受付判定手段5が要求を受け付けた各通信で消費(使用)されるリソースを、例えば図2に詳細を示す現時刻リソース管理テーブル23と未来リソース管理テーブル24の内容で、現在のリソースの使用状況と事前予約型で将来において使用されるリソースの使用予約状況とを登録して管理する。
例えば、図2に示す現時刻リソース管理テーブル23においては、各リンク毎に、当該リンクを使用している帯域量(使用中リソース)と共に、予め当該リンクに設定された受付可能な最大帯域量(使用可能リソース(bps))が対応付けて設定されている。
この現時刻リソース管理テーブル23において設定されている使用可能リソース(bps)を超えた当該リンク経由の接続要求は受け付けられない。
また、未来リソース管理テーブル24においては、図2においてリンク1に関して例示しているように、各リンク別に、予約されている時間帯(時刻帯)毎に、予約されたリソース使用量(使用中リソース)が対応付けて設定されている。
統計データ作成手段2は、記憶装置から通信履歴テーブル22を読み込み、その登録内容を用いて、各リンク別に、図2に詳細を示す内容の統計データ管理テーブル25を生成して記憶装置に格納する。
この統計データ管理テーブル25は、各リンク別に生成され、例えば図2に示す統計データ管理25は、リンク1(Link1)に関してのデータであり、時刻帯毎に、通信継続時間(分)とリソース使用率(%)が対応付けて登録されている。
すなわち、統計データ作成手段2は、通信履歴テーブル22において登録されているリンク1に関しての通信サービス情報(サービス開始時刻とサービス終了時刻)から、各時刻帯、例えば10時−18時に渡っての、通信継続時間(分)、リソース使用率(%)を求めて、統計データ管理テーブル25に登録する。
受付判定手段5は、経路(リンク)特定手段6で特定したリンクの情報を受け取り(B)、当該リンクでの接続要求(即時呼もしくは事前予約呼)を受け付けることができるか否かを、記録装置から現時刻リソース管理テーブル23、未来リソース管理テーブル24、統計データ管理テーブル25を読み込み、それぞれの登録内容を参照して判定し、その結果をリソース管理手段4とメッセージ送受信手段7に通知する(C,D)。
ここで、即時型の接続要求(即時呼)に関して説明する。この即時呼は、サービスの終了時刻が不明であるため、そこで使用しているリソースが、いつ開放されるかも不明である。そのため、従来技術では、当該リソースを、未来の時刻を指定する事前予約型の要求で利用する場合、この事前予約型の要求(事前予約呼)に対して正確な受付判定を行うことができないが、本例の受付判定手段5では、これが可能となる。
また、事前予約呼を近未来の時刻に既に受け付けている状態で、新たな即時呼の要求があった場合、この新たな即時呼を受け付けることによって、先に受け付けた事前予約呼のサービス開始時に、当該事前予約呼に当該リソースを振り分けることができないケースがあり、従来の技術では、このようなケースに対処できないが、本例の受付判定手段5では、これも可能となる。
さらに、即時呼を受け付けている状態で、かつ、事前予約呼を近未来の時刻に既に受け付けている状態で、新たな事前予約呼の要求があった場合、従来の技術では、受付済みの即時呼の終了時刻が不明のため、この新たな事前予約呼を受け付けることができるか否かを判断することができないが、本例の受付判定手段5では、これも可能となる。
以下、このような本例の経路(リンク)特定手段6と受付判定手段5の処理動作を図4を用いて説明する。
まず、本例の経路(リンク)特定手段6は、新たな接続要求があるとその通信経路(どのリンクを通るか)を特定する(ステップS401)。次に受付判定手段5は、新たな接続要求が即時呼であるか事前予約呼であるかを判別する(ステップS402)。
続いて、当該未来リソース管理テーブル24と現時刻リソース管理テーブル23および統計データ管理テーブル25のそれぞれの登録内容を参照して、本発明に係る受付判定処理を行う。
すなわち、ステップS404、ステップS405で行われる現時刻リソース管理テーブル23で示される現時刻で使用中のリソース量に、新たな即時呼で要求されたリソース量を加えた使用リソース量が、時間の経過に伴いどのように推移するかを計算して、近未来の時刻での使用リソースの推定量を算出する(ステップS407)。
そして、未来リソース管理テーブル24に登録されている当該リンクの当該近未来の時刻での使用予定リソース量を取得(ステップS408)し、算出した推定リソース量とを加えた値が、当該リンクに対応付けられた使用可能リソースの値を超えるか否かを判定する(ステップS409)。
超える場合には、当該即時呼の要求の受付を拒否し(ステップS410)、超えなければ、ステップS411からステップS406に戻り、予め定められた時間帯の間でステップS406からステップS411を繰り返し、各時刻での受付判定をおこなう。
ステップS401で特定された該当リンク全てについて受付判定をおこなう、すなわちステップS403からステップS412を繰り返し受付判定をおこなう。最終的に全ての条件を満足する場合のみ受付を許可する。(ステップS413)
また、ステップS402での判別処理において、新たな接続要求が事前予約呼であれば、未来リソース管理テーブル24に登録されている同時刻での使用予定リソース量を取得し(ステップS416)、この新たな事前予約呼で要求されるリソース量とを加え(ステップS417)、この加算値が、現時刻リソース管理テーブル23において当該リンクに対応付けられた使用可能リソースの値を超えるか否かを判定する(ステップS418)。
超える場合には、当該即時呼の要求の受付を拒否し(ステップS410)、超えなければ、当該未来リソース管理テーブル24と現時刻リソース管理テーブル23および統計データ管理テーブル25のそれぞれの登録内容を参照して、本発明に係る受付判定処理を行う。
すなわち、現時刻リソース管理テーブル23で示される現時刻で使用中のリソース量が、時間の経過に伴いどのように推移するかを計算して、近未来の時刻での使用リソースの推定量を算出する(ステップS412)。
そして、算出した推定リソース量と、ステップS417での処理で算出した加算値とを加え、この再加算値が、現時刻リソース管理テーブル23において当該リンクに対応付けられた使用可能リソースの値を超えるか否かを判定する(ステップS421)。
超える場合には、当該即時呼の要求の受付を拒否し(ステップS410)、超えなければ、ステップS422からステップS415に戻り、予め定められた時間帯の間でステップS415からステップS422を繰り返し、各時刻での受付判定をおこなう。
ステップS401で特定された該当リンク全てについて受付判定をおこなう。すなわちステップS414からステップS423を繰り返し受付判定をおこなう。最終的に全ての条件を満足する場合のみ受付を許可する。(ステップS413)
次に、このような受付判定手段5による、ステップS407での処理、すなわち、現時刻リソース管理テーブル23で示される現時刻で使用中のリソース量に、新たな即時呼で要求されたリソース量を加えた使用リソース量が、時間の経過に伴いどのように推移するかを計算して、近未来の時刻での使用リソースの推定量を算出する処理、および、ステップS420での処理、すなわち、現時刻リソース管理テーブル23で示される現時刻で使用中のリソース量が、時間の経過に伴いどのように推移するかを計算して、近未来の時刻での使用リソースの推定量を算出する処理の詳細を説明する。
受付判定手段5においては、現在までに受け付けた呼のリソース使用量に基づいて、将来の使用量を推定し、その推定値と新規呼の要求リソース量の和を、使用可能リソース量(上限リソース容量)と比較することにより受付の判定を行う。
すなわち、現時刻の使用リソース量はサービスの終了に伴い確保していたリソース分だけ減少するため、現時刻の使用リソース量は、時間の経過とともに減少することは保証されている。また、どのように減少推移するかは過去の使用リソース量の推移を基に推定する。
よって、統計データ作成手段2により、通信履歴テーブル22に登録される過去の使用リソース量を基に算出され統計データ管理テーブル25に登録された、当該リンクの通信継続時間、リソース使用率の統計データから算出される平均通信継続時間、平均リソース使用率などをパラメータとして利用することにより受付判定を行う。
ここで、新たな要求の受け付け現時刻をtnow、事前予約呼によるサービス開始時刻と終了時刻をそれぞれtstartとtend、新たな要求リソース量をx、現時刻での使用リソース量をx’、当該リンクの上限リソース容量(現時刻リソース管理テーブル23における使用可能リソース)をBmax、任意の時刻tの推定リソース使用量をB(t)、当該時刻tの事前予約呼で既に確保されているリソースをR(t)、呼の平均通信継続時間をhとした場合の受付判定手順例を以下に示す。
まず、新たな接続要求が即時呼の場合における受付判定例を説明する。下記の式(1)を用いて、任意の時刻tの推定使用リソース量B(t)を求め、下記の式(2)を用いて、新たな即時呼の接続要求の受付判定を行う。
B(t)=(x+x’)e−α(t−tnow)/h+β (α,βは定数) …(1)
B(t)+R(t)<Bmax …(2)
即時呼は、時刻tnow〜t’内で上記(2)式を全て満たす場合、受付を許可する。尚、この「t’」は予め設定される定数であり、例えば、統計データ管理テーブル25における通信継続時間から算出される平均通信継続時間等から決定される。
また、式(1)における定数αと定数βは、推定処理結果の安全確保のために、算出する推定使用リソース量B(t)を意図的に大きくするためのものパラメータであり、これらの定数α,βの値を変えて推定使用リソース量B(t)を大きくすることにより、式(2)による判定時に、上限リソース容量Bmaxとの比較による受付許可条件を厳しくすることができる。
また、これらの定数α,βは、統計データ管理テーブル25における通信継続時間やリソース使用率の各情報に基づき、予め定められた任意の計算式により自動的に算出することでも、人手により設定することでも良い。例えば、定数αとして、統計データ管理テーブル25における通信継続時間履歴から算出される平均通信継続時間を用いることでも良い。
次に、新たな接続要求が事前予約呼の場合における受付判定例を説明する。下記の式(3)を用いて、任意の時刻tの推定使用リソース量B(t)を求め、下記の式(4)を用いて、新たな事前予約呼の接続要求の受付判定を行う。
B(t)=x’e−α(t−tstart)/h+β …(3)
B(t)+R(t)+x<Bmax …(4)
B(t)+R(t)+x<Bmax …(4)
事前予約呼は、tstart〜tend内で上記(4)式を全て満たす場合、受付を許可し、それ以外は拒否する。
尚、上述の推定使用リソース量B(t)等の関数は指数関数などにとどまらず、統計データ管理テーブル25の通信状況の分布などを基に、時間帯や曜日等に合わせて、適した関数を適用することが可能である。
また、呼の平均通信継続時間hは、統計データ管理テーブル25から直前までの平均通信継続時間を取得して適用することも、固定値にすることも可能である。
このようにして、式(1)と式(2)による即時呼に対する受付判定処理例、および、式(3)と式(4)による事前予約呼に対する受付判定処理例を図5および図6に示す。
図5は、図4における受付判定手段による即時呼に対する受付判定処理例を示す説明図であり、図6は、図4における受付判定手段による事前予約呼に対する受付判定処理例を示す説明図である。
図5に示すように、即時呼を受信した現時刻における使用リソース(帯域)量x’に、即時呼で要求されるリソース量xを加えた値(x+ x’)の時刻tにおける推定使用リソース量B(t)は、時間の経過と共に減少する。
ここで、当該時刻tの事前予約呼で既に確保されている予約リソース量がR(t)の場合、B(t)+R(t)<Bmaxの条件を満たしており、新たに要求されたリソース量xの即時呼は受付許可されるが、当該時刻tの事前予約呼で既に確保されている予約リソース量がR’(t)の場合、B(t)+R’(t)の値は、1時間経過前に、Bmaxよりも大きくなってしまうので、新たに要求されたリソース量xの即時呼は受付拒否される。
また、図6に示すように、事前予約呼を受信した現時刻における使用リソース(帯域)量x’の時刻tにおける推定使用リソース量B(t)は、時間の経過と共に減少する。
そして、新たなリソース量xの事前予約呼が時刻t1startをサービス開始時刻として要求された場合には、時刻t1において既存の事前予約呼で確保されている予約リソース量R(t)と、要求されたリソース量x、および、時刻t1における推定使用リソース量B(t1)とを加算した値は、B(t1)+R(t1)+x>Bmaxとなり、このような、時刻t1を含む時刻t1startを開始時刻としたリソース量xの新たな事前予約呼は受付拒否される。一方、新たなリソース量xの事前予約呼が時刻t2startをサービス開示時刻として要求された場合には、時刻t2の時刻で既存の事前予約呼で確保されている予約リソース量R(t)と、要求されたリソース量x、および、時刻t2における推定使用使用リソース量B(t2)とを加算した値は、B(t2)+R(t)+x<Bmaxとなるように、どの時刻においても条件式を満たすため、この時刻t2を含む時刻t2startをサービス開始時刻としたリソース量xの新たな事前予約呼は受付許可される。
図7は、本発明に係るリソース管理技術と従来のリソース管理技術との比較例を示す説明図である。従来の「即時呼」と「事前予約呼]で完全に分離した技術の場合は、各々の専用リソースで独立に管理すればよく、上述の式(1)と式(2)、および式(3)と(4)を用いてリソース(帯域)の時刻t等における推定量を計算する必要はないが、設備設計によってなされたリソースの分割割合と、実際の即時呼と事前予約呼との割合に隔たりが大きい場合には、リソースの利用効率は大きく劣化してしまう。
これに対して、本例によれば、リソースを「即時呼」と「事前予約呼]で共用することができ、上述のようなリソースの利用効率が大きく劣化してしまうようなことはない。
尚、本例のように、共有リソースの場合においても、事前予約呼は全体の50%まで、即時呼は100%利用することが可能(言い換えると、全体の50%は即時呼専用として利用し、残りの50%は即時呼と事前予約呼で共有する)などのように、事前予約呼に一定の制限をもたせることにより、予約がいっぱいで即時呼が全く受け付けられない状態を防ぐことも可能である。
図8は、図1における受付制御サーバが設けられたネットワークの第2の構成例を示すブロック図であり、ここでは、2つのネットワーク35,36が設けられており、発信側の利用者端末(1)33はネットワーク35側に収容され、着信側の利用者端末(2)34はネットワーク36側に収容されている。
さらに、ネットワーク35側におけるリソース管理および受付制御は、受付制御サーバ1aにより、ネットワーク36側におけるリソース管理および受付制御は、受付制御サーバ1bにより行われる。
利用者端末(1)33からの利用者端末(2)34への通信要求時の利用開始要求は、ネットワーク35側を管理するセッション制御サーバ31で受信し(図中、丸1)、セッション制御サーバ31は受信した利用開始要求に対するネットワーク35側での受付可否(リソース確保の可否)の判定を受付制御サーバ1aに要求し、受付許可の応答が得られたならば、受信した利用開始要求をネットワーク36側を管理するセッション制御サーバ32に転送する(図中、丸2)。
セッション制御サーバ31からの利用開始要求を受信したセッション制御サーバ32は、当該利用開始要求に対するネットワーク36側での受付可否(リソース確保の可否)の判定を受付制御サーバ1bに要求し、受付許可の応答が得られたならば、利用者端末(2)34に対して着信の通知を行うと共に(図中、丸3)、セッション制御サーバ31に対して、利用開始要求応答を送信する(図中、丸4)。
利用開始要求応答を受けたセッション制御サーバ31は、利用者端末(1)33に対して、当該利用開始要求応答を通知し(図中、丸5)。これにより、ネットワーク35,36を介しての利用者端末(1)33と利用者端末(2)34の通信が開始される。
以上、説明した本例の受付制御技術によれば、リソースの利用効率を高めることができると共に、呼損率を常に小さく抑えることが可能である。例えば、図9および図10に示
すように、従来のリソース分割方式での設計値(リソース容量の分割の割合)が適切であっても、本例によるリソース推定による受付制御技術の方が呼損率を小さく抑えることができ、即時/事前予約呼の割合によらず有効である。
すように、従来のリソース分割方式での設計値(リソース容量の分割の割合)が適切であっても、本例によるリソース推定による受付制御技術の方が呼損率を小さく抑えることができ、即時/事前予約呼の割合によらず有効である。
図9は、リソース呼量と呼損率の第1の関係例を示す説明図であり、全体のリソース容量に対する単位時間当たりの要求呼の総リソース要求量の割合をリソース呼量(%)とし、リソース呼量を占める即時呼と事前予約呼の割合を変動させた時の呼損率を示す。
図9に示すように、従来の保護時間方式では、即時呼の割合が例えば70%以下の場合、呼損率(事前予約呼の受付拒否も呼損とみなす)が非常に大きくなり、また、従来のリソース分割方式でも、即時呼と事前予約呼の割合が設計値(本シミュレーションでは1:1に均等にリソース容量を分割)と異なる場合、即時呼の割合が小さいとき(例えば30%以下)場合には、呼損率が非常に大きくなる。これに対して、本例の受付制御技術では、呼損率が常に小さく抑えられていることが分かる。
図10は、リソース呼量と呼損率の第2の関係例を示す説明図であり、ここでは、呼種の割合を一定(1:1)にし、リソース呼量を増加させた場合の呼損率を示している。
この図10に示すように、従来のリソース分割方式での、設計値(リソース容量の分割の割合)が適切であっても、本例のリソース推定による受付制御技術の方が呼損率を小さく抑えることができ、本例の受付制御技術が呼種の割合によらず有効であるといえる。
以上、図1〜図10を用いて説明したように、本例の受付制御技術では、即時呼と事前予約呼とが混在するIPネットワークにおける新たな呼の受付制御を行う際、当該新規呼の接続に用いる各リンク毎に、現在までに当該リンクで受け付けた呼のリソース使用量に基づき、当該リンクにおける将来のリソース使用量を推定し、その推定値と新規呼の要求リソース量との和を、予め当該リンクに対応付けて設定・登録された使用上限値と比較することにより受付の判定を行う。
すなわち、新規の接続要求の接続に用いるリンクを特定し、新規の接続要求が即時呼であれば、特定したリンクで現在使用中のリソース量と、当該即時呼で要求されるリソース量とを加算し、この加算値が、時間の経過に伴い推移するリソース使用推移値を、過去の当該リンクでの通信履歴統計情報を用いて算出し、算出したリソース使用量推移値と、特定したリンクの、他の事前予約呼により予約済みのリソース使用量とを加算し、この加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可し、また、新規の接続要求が事前予約呼であれば、特定したリンクで現在使用中のリソース量値が、時間の経過に伴い推移するリソース使用推移値を、過去の当該リンクでの通信履歴統計情報を用いて算出し、算出したリソース使用量推移値と、特定したリンクの、他の事前予約呼により予約済みのリソース使用量と、当該事前予約呼で要求されるリソース量とを加算し、このようにして加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可する。
より詳細には、予め入力された、発側エッジノードと着側エッジノードの組と、当該発側エッジノードと着側エッジノード間を接続するリンク群とを対応付けた経路情報を経路(リンク)テーブル21に登録して記憶装置に記憶すると共に、リンク群の各リンク毎に、予め定められた当該リンクで使用可能な最大リソース量と、当該リンクで使用中のリソース量とを、現時刻リソース管理テーブル24に登録して記憶装置に記憶し、また、リンク群の各リンク毎に、事前予約呼で要求された予約リソース量を予め設定された予約時間帯に対応付けて未来リソース管理テーブル24に登録して記憶装置に記憶し、さらに、各リンク毎に、当該リンクを使用した通信の開始時刻と終了時刻および使用リソース量を少なくとも含む履歴情報を収集して通信履歴テーブル22に登録して記憶装置に格納する。そして、統計データ作成手段2により、各リンク毎に、通信履歴テーブル22から履歴情報を読み込み、予め定められた時間帯における当該リンクでの通信継続時間とリソース使用率を算出して、当該時間帯に対応付けた統計情報を生成して統計データ管理テーブル25に登録して記憶装置に格納する。この状態で、メッセージ送受信手段7が、新たな接続要求を受けると、まず、経路(リンク)特定手段6が、経路(リンク)テーブル21から経路情報を読み込み、要求された接続に用いるリンクを特定し、次に、受付判定手段5が、特定したリンクをキーに現時刻リソース管理テーブル23と未来リソース管理テーブル24および統計データ管理テーブル25を検索して、現時刻リソース管理テーブル23から当該リンクの使用可能な最大リソース量と当該リンクの使用中リソース量を、未来リソース管理テーブル24から当該リンクの予約リソース量を、統計データ管理テーブル25から当該リンクの統計情報を読み込み、新たな接続要求が即時呼であれば、新たな即時呼で要求されるリソース量と現時刻リソース管理テーブル23から読み込んだ使用中リソース量とを加算し、加算した第1の加算値が時間の経過に伴い推移する値(リソース使用量推移値)を、統計データ管理テーブル25から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出し、算出したリソース使用量推移値と未来リソース管理テーブル24から読み込んだ予約リソース量を加算し、加算した第2の加算値と、現時刻リソース管理テーブル23から読み込んだ最大リソース量とを比較し、第2の加算値が最大リソース量より大きくなることがあれば、新たな接続要求の受付を拒否し、第2の加算値が最大リソース量より大きくなることがなければ、新たな接続要求の受付を許可し、また、新たな接続要求が事前予約呼であれば、現時刻リソース管理テーブル23から読み込んだ使用中リソース量が時間の経過に伴い推移する値(リソース使用量推移値)を、統計データ管理テーブル25から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出し、算出したリソース使用量推移値と新たな事前予約呼で要求されるリソース量および未来リソース管理テーブル24から読み込んだ予約リソース量を加算し、加算した第3の加算値と、現時刻リソース管理テーブル23から読み込んだ最大リソース量とを比較し、第3の加算値が最大リソース量より大きくなることがあれば、新たな接続要求の受付を拒否し、第3の加算値が最大リソース量より大きくなることがなければ、新たな接続要求の受付を許可する。
また、新規の接続要求が事前予約呼で、かつ、この事前予約呼の開始時刻が、予め定められた時間(例えば1週間)を超えていれば、特定したリンクの他の事前予約呼により予約済みのリソース使用量と、当該事前予約呼で要求されるリソース量のみを加算し、加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可する。
このように、本例では、過去の利用状況からリソースの使用状況を推定し、予約型と即時型でリソースを共用して、リソースの有効利用を図ることができ、電話等の即時呼とTV会議等の事前予約呼の2形態の呼が混在したIPネットワークにおける呼の受付制御を、高いリソースの利用効率で、かつ、呼損率を小さく抑えながら行うことができる。
尚、本発明は、図1〜図10を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、上述したように、式(1)〜(4)における推定使用リソース量B(t)等の関数は指数関数などにとどまらず、統計データ管理テーブル25の通信状況の分布などを基に、時間帯や曜日等に合わせて、適した関数を適用することが可能である。
また、図4における例では、ステップS402からS409の処理の流れにおける即時呼の受付可否の判定に際して、未来リソース管理テーブル24に該当する時間帯の事前予約呼が無いと判断できた場合は、現時刻リソース管理テーブル23に登録された現在使用中のリソース量と新たな即時呼で要求されたリソース量とを加えて、その加算値と、使用可能リソース値との比較により、受付の可否を判定のみをおこない、それ以後の時刻でのループ(ステップS411)を省略する(ループを抜ける)ことも可能とすることでも良い。
さらに、ステップS402において、接続要求が即時呼であるか事前予約呼であるかを判定するのではなく、例えば、接続要求を受信した時点で、現時刻リソース管理テーブル23と未来リソース管理テーブル24および統計データ管理テーブル25から、当該リンクに関するそれぞれの登録内容を読み込み、その後、即時呼と事前予約呼の判別を行い、即時呼であればステップS403からステップS412の処理を、事前予約呼であればステップS414〜S423の処理を、それぞれ読み込んだ情報を用いて行うことでも良い。
また、コンピュータ構成例にしても、キーボードや光ディスクの駆動装置の無いコンピュータ構成としても良い。また、本例では、光ディスクを記録媒体として用いているが、FD(Flexible Disk)等を記録媒体として用いることでも良い。また、プログラムのインストールに関しても、通信装置を介してネットワーク経由でプログラムをダウンロードしてインストールすることでも良い。
1:受付制御サーバ、2:統計データ作成手段、3:通信履歴管理手段、4:リソース管理手段、5:受付判定手段、6:経路(リンク)特定手段、7:メッセージ送受信手段、21:経路(リンク)テーブル、22:通信履歴テーブル、23:現時刻リソース管理テーブル、24:未来リソース管理テーブル、25:統計データ管理テーブル、31,32:セッション制御サーバ、33,34:利用者端末、35,36:ネットワーク。
Claims (7)
- 要求時点で即時に接続開始を要求する即時呼でのIPパケット転送、および、予約した時刻からの接続開始を要求する事前予約呼でのIPパケット転送を、リソースを共用して行うネットワークにおける、上記即時呼および上記事前予約呼に対する受付可否の判定を、リソースの空き状況に基づき行う受付制御システムであって、
予め入力された、発側エッジノードと着側エッジノードの組と、当該発側エッジノードと着側エッジノード間を接続するリンク群とを対応付けた経路情報を記憶する経路記憶手段と、
上記リンク群の各リンク毎に、予め定められた当該リンクで使用可能な最大リソース量を記憶する第1のリソース情報記憶手段と、
上記リンク群の各リンク毎に、当該リンクで使用中のリソース量を記憶する第2のリソース情報記憶手段と、
上記リンク群の各リンク毎に、上記事前予約呼で要求された予約リソース量を予め設定された予約時間帯に対応付けて記憶する第3のリソース情報記憶手段と、
各リンク毎に、当該リンクを使用した通信の開始時刻と終了時刻および使用リソース量を少なくとも含む履歴情報を収集して通信履歴記憶手段に格納する通信履歴管理手段と、
各リンク毎に、上記通信履歴記憶手段から上記履歴情報を読み込み、予め定められた時間帯における当該リンクでの通信継続時間とリソース使用率を算出して、当該時間帯に対応付けた統計情報を生成して統計データ記憶手段に格納する統計データ管理手段と、
新たな接続要求があれば、上記経路記憶手段から上記経路情報を読み込み、要求された接続に用いるリンクを特定する経路特定手段と、
該経路特定手段が特定したリンクをキーに上記第1のリソース情報記憶手段と上記第2のリソース情報記憶手段および上記第3のリソース情報記憶手段と上記統計データ記憶手段を検索して、
上記第1のリソース情報記憶手段から当該リンクの使用可能な最大リソース量を、
上記第2のリソース情報記憶手段から当該リンクの使用中リソース量を、
上記第3のリソース情報記憶手段から当該リンクの予約リソース量を、
上記統計データ記憶手段から当該リンクの統計情報を読み込み、
上記新たな接続要求が即時呼であれば、
該新たな即時呼で要求されるリソース量と上記第2のリソース情報記憶手段から読み込んだ使用中リソース量とを加算し、
該加算した第1の加算値が時間の経過に伴い推移する値を、上記統計データ記憶手段から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出し、
該算出した推移値と上記第3のリソース情報記憶手段から読み込んだ予約リソース量を加算し、該加算した第2の加算値と、上記第1のリソース情報記憶手段から読み込んだ最大リソース量とを比較し、
上記第2の加算値が上記最大リソース量より大きくなることがあれば、上記新たな接続要求の受付を拒否し、
上記第2の加算値が上記最大リソース量より大きくなることがなければ、上記新たな接続要求の受付を許可し、
上記新たな接続要求が事前予約呼であれば、
上記第2のリソース情報記憶手段から読み込んだ使用中リソース量が時間の経過に伴い推移する値を、上記統計データ記憶手段から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出し、
該算出した推移値と上記新たな事前予約呼で要求されるリソース量および上記第3のリソース情報記憶手段から読み込んだ予約リソース量を加算し、該加算した第3の加算値と、上記第1のリソース情報記憶手段から読み込んだ最大リソース量とを比較し、
上記第3の加算値が上記最大リソース量より大きくなることがあれば、上記新たな接続要求の受付を拒否し、
上記第3の加算値が上記最大リソース量より大きくなることがなければ、上記新たな接続要求の受付を許可する判定手段と
を有することを特徴とする受付制御システム。 - 要求時点で即時に接続開始を要求する即時呼でのIPパケット転送、および、予約した時刻からの接続開始を要求する事前予約呼でのIPパケット転送を、リソースを共用して行うネットワークにおける、上記即時呼および上記事前予約呼に対する受付可否の判定を、リソースの空き状況に基づき行う受付制御方法であって、
新規の接続要求の接続に用いるリンクを特定するステップと、
上記新規の接続要求が即時呼であれば、上記特定したリンクで現在使用中のリソース量と、当該即時呼で要求されるリソース量とを加算し、該加算値が、時間の経過に伴い推移するリソース使用推移値を、過去の当該リンクでの通信履歴統計情報を用いて算出し、該算出したリソース使用量推移値と、上記特定したリンクの、他の事前予約呼により予約済みのリソース使用量とを加算し、該加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該即時呼の受付を拒否し、大きくなることがなければ当該即時呼の受付を許可するステップと、
上記新規の接続要求が事前予約呼であれば、上記特定したリンクで現在使用中のリソース量値が、時間の経過に伴い推移するリソース使用推移値を、過去の当該リンクでの通信履歴統計情報を用いて算出し、該算出したリソース使用量推移値と、上記特定したリンクの、他の事前予約呼により予約済みのリソース使用量と、当該事前予約呼で要求されるリソース量とを加算し、該加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可するステップと
を有することを特徴とする受付制御方法。 - 要求時点で即時に接続開始を要求する即時呼でのIPパケット転送、および、予約した時刻からの接続開始を要求する事前予約呼でのIPパケット転送を、リソースを共用して行うネットワークにおける、上記即時呼および上記事前予約呼に対する受付可否の判定を、リソースの空き状況に基づき行う受付制御方法であって、
予め入力された、発側エッジノードと着側エッジノードの組と、当該発側エッジノードと着側エッジノード間を接続するリンク群とを対応付けた経路情報を経路記憶手段に記憶するステップと、
上記リンク群の各リンク毎に、予め定められた当該リンクで使用可能な最大リソース量を第1のリソース情報記憶手段に記憶するステップと、
上記リンク群の各リンク毎に、当該リンクで使用中のリソース量を第2のリソース情報記憶手段に記憶するステップと、
上記リンク群の各リンク毎に、上記事前予約呼で要求された予約リソース量を予め設定された予約時間帯に対応付けて第3のリソース情報記憶手段に記憶するステップと、
各リンク毎に、当該リンクを使用した通信の開始時刻と終了時刻および使用リソース量を少なくとも含む履歴情報を収集して通信履歴記憶手段に格納するステップと、
各リンク毎に、上記通信履歴記憶手段から上記履歴情報を読み込み、予め定められた時間帯における当該リンクでの通信継続時間とリソース使用率を算出して、当該時間帯に対応付けた統計情報を生成して統計データ記憶手段に格納するステップと、
新たな接続要求があれば、上記経路記憶手段から上記経路情報を読み込み、要求された接続に用いるリンクを特定するステップと、
該特定したリンクをキーに上記第1のリソース情報記憶手段と上記第2のリソース情報記憶手段および上記第3のリソース情報記憶手段と上記統計データ記憶手段を検索して、
上記第1のリソース情報記憶手段から当該リンクの使用可能な最大リソース量を、
上記第2のリソース情報記憶手段から当該リンクの使用中リソース量を、
上記第3のリソース情報記憶手段から当該リンクの予約リソース量を、
上記統計データ記憶手段から当該リンクの統計情報を読み込むステップと、
上記新たな接続要求が即時呼であれば、
該新たな即時呼で要求されるリソース量と上記第2のリソース情報記憶手段から読み込んだ使用中リソース量とを加算するステップと、
該加算した第1の加算値が時間の経過に伴い推移する値(リソース使用量推移値)を、上記統計データ記憶手段から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出するステップと、
該算出したリソース使用量推移値と上記第3のリソース情報記憶手段から読み込んだ予約リソース量を加算するステップと、
該加算した第2の加算値と、上記第1のリソース情報記憶手段から読み込んだ最大リソース量とを比較するステップと、
上記第2の加算値が上記最大リソース量より大きくなることがあれば、上記新たな接続要求の受付を拒否し、
上記第2の加算値が上記最大リソース量より大きくなることがなければ、上記新たな接続要求の受付を許可するステップと、
上記新たな接続要求が事前予約呼であれば、
上記第2のリソース情報記憶手段から読み込んだ使用中リソース量が時間の経過に伴い推移する値(リソース使用量推移値)を、上記統計データ記憶手段から読み込んだ統計情報に含まれる通信継続時間とリソース使用率等の過去と現在の使用状況情報を用いて算出するステップと、
該算出したリソース使用量推移値と上記新たな事前予約呼で要求されるリソース量および上記第3のリソース情報記憶手段から読み込んだ予約リソース量を加算するステップと、
該加算した第3の加算値と、上記第1のリソース情報記憶手段から読み込んだ最大リソース量とを比較するステップと、
上記第3の加算値が上記最大リソース量より大きくなることがあれば、上記新たな接続要求の受付を拒否し、
上記第3の加算値が上記最大リソース量より大きくなることがなければ、上記新たな接続要求の受付を許可するステップと
を有することを特徴とする受付制御方法。 - 請求項2もしくは請求項3のいずれかに記載の受付制御方法であって、
任意の時刻t上記リソース使用量推移値をB(t)、新たな接続要求の受け付け現時刻をtnow、事前予約呼によるサービス開始時刻と終了時刻をそれぞれtstartとtend、新たな要求リソース量をx、現時刻での使用リソース量をx’、当該リンクの使用上限リソース容量をBmax、当該時刻tの事前予約呼で既に確保されている予約済みリソース量をR(t)、呼の平均通信継続時間をhとし、
新たな接続要求が即時呼の場合には、
式(1)「B(t)=(x+x’)e−α(t−tnow)/h+β (α,βは予め定められる定数)」等、使用量推定値B(t)を関数により算出する式を用いて、上記任意の時刻tのリソース使用量推移値B(t)を求め、式(2)「B(t)+R(t)<Bmax」を、時刻tnow〜予め定められた時間t’内で全て満たす場合、当該即時呼の受付を許可するステップと、
新たな接続要求が事前予約呼の場合には、
式(3)「B(t)=x’e−α(t−tstart)/h+β (α,βは予め定められる定数)」等、使用量推定値B(t)を関数により算出する式を用いて、上記任意の時刻tの推定リソース使用量B(t)を求め、式(4)「B(t)+R(t)+x<Bmax」を、時刻tstart〜tend内で全て満たす場合、当該事前予約呼の受付を許可するステップと、
それ以外は拒否するステップとを有することを特徴とする受付制御方法。 - 請求項2から請求項4のいずれかに記載の受付制御方法であって、
新規の接続要求が事前予約呼で、かつ、該事前予約呼の開始時刻が、予め定められた時間を超えていれば、
上記特定したリンクの他の事前予約呼により予約済みのリソース使用量と、当該事前予約呼で要求されるリソース量のみを加算し、
該加算した値と、予め当該特定リンクに対応付けて設定されたリソースの使用上限値と比較し、加算値が使用上限値より大きくなることがあれば当該事前予約呼の受付を拒否し、大きくなることがなければ当該事前予約呼の受付を許可するステップを有する
ことを特徴とする受付制御方法。 - 請求項2から請求項5のいずれかに記載の受付制御方法であって、
上記リソースの予め定められた割合を即時呼に専用に割り当て、
残りを即時呼と事前予約呼で共用することを特徴とする受付制御方法。 - コンピュータに、請求項2から請求項6のいずれかに記載の受付制御方法における各ステップを実行させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006263725A JP2008085686A (ja) | 2006-09-28 | 2006-09-28 | 予約受付制御システムと方法およびプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006263725A JP2008085686A (ja) | 2006-09-28 | 2006-09-28 | 予約受付制御システムと方法およびプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2008085686A true JP2008085686A (ja) | 2008-04-10 |
Family
ID=39356077
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006263725A Pending JP2008085686A (ja) | 2006-09-28 | 2006-09-28 | 予約受付制御システムと方法およびプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2008085686A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010068221A (ja) * | 2008-09-10 | 2010-03-25 | Kddi Corp | 発信規制方法およびシステム |
JP2010153986A (ja) * | 2008-12-24 | 2010-07-08 | Hitachi Ltd | スケジューラサーバ、プログラム、会議システム及び会議設定方法 |
JP2013016994A (ja) * | 2011-07-01 | 2013-01-24 | Nippon Telegr & Teleph Corp <Ntt> | 通信ノード装置及びパス割当方法 |
EP2924933A1 (en) | 2014-03-26 | 2015-09-30 | Fujitsu Limited | Data reception apparatus, method for controlling data reception apparatus, and data transmission and reception system including data transmission apparatus and data reception apparatus |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0630021A (ja) * | 1992-07-10 | 1994-02-04 | Fujitsu Ltd | Atm交換機における帯域予約方式 |
JPH11308231A (ja) * | 1998-04-21 | 1999-11-05 | Mitsubishi Electric Corp | 通信リソース予約方法 |
-
2006
- 2006-09-28 JP JP2006263725A patent/JP2008085686A/ja active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0630021A (ja) * | 1992-07-10 | 1994-02-04 | Fujitsu Ltd | Atm交換機における帯域予約方式 |
JPH11308231A (ja) * | 1998-04-21 | 1999-11-05 | Mitsubishi Electric Corp | 通信リソース予約方法 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010068221A (ja) * | 2008-09-10 | 2010-03-25 | Kddi Corp | 発信規制方法およびシステム |
JP2010153986A (ja) * | 2008-12-24 | 2010-07-08 | Hitachi Ltd | スケジューラサーバ、プログラム、会議システム及び会議設定方法 |
JP2013016994A (ja) * | 2011-07-01 | 2013-01-24 | Nippon Telegr & Teleph Corp <Ntt> | 通信ノード装置及びパス割当方法 |
EP2924933A1 (en) | 2014-03-26 | 2015-09-30 | Fujitsu Limited | Data reception apparatus, method for controlling data reception apparatus, and data transmission and reception system including data transmission apparatus and data reception apparatus |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0986216B1 (en) | Transmission system, bandwidth management apparatus, and bandwidth management method | |
EP1841167B1 (en) | Relay apparatus for Selecting a Multimedia Type of a Communication | |
US7397778B2 (en) | Method and apparatus for predicting the quality of packet data communications | |
US5881050A (en) | Method and system for non-disruptively assigning link bandwidth to a user in a high speed digital network | |
US5461611A (en) | Quality of service management for source routing multimedia packet networks | |
EP1887745B1 (en) | Relay apparatus, relay method, and relay program | |
US7327681B2 (en) | Admission control method in internet differentiated service network | |
JP4838309B2 (ja) | データフローのための統合的リソース予約 | |
JP3394394B2 (ja) | ネットワーク接続品質制御方式 | |
CN101160805B (zh) | 保障多业务服务质量的资源管理设备、接入***及方法 | |
US7024202B2 (en) | Method of processing UMTS calls in a packet transmission network and node for the UMTS network and for implementing said method | |
US20060165224A1 (en) | Apparatus and method for managing network resources | |
JP4627461B2 (ja) | 通信サービス制御システムと方法およびプログラム | |
EP2648371A1 (en) | Quality-of-service management system and method | |
US20160112742A1 (en) | Managing wireless transmission capacity | |
US20120221706A1 (en) | Method and arrangement for network resource management | |
CN109819477A (zh) | 一种处理请求的方法以及相应实体 | |
JP2008085686A (ja) | 予約受付制御システムと方法およびプログラム | |
US7158508B2 (en) | Setting up calls over circuit and packet-switched resources on a network | |
JP4444214B2 (ja) | リソース管理方法および装置 | |
US8797853B2 (en) | System and method for checking the permissibility of a use of a service | |
JP2006246119A (ja) | 優先制御を用いて品質保証サービスを実現するネットワークシステムおよび呼受付判定方法、ならびにそのプログラム | |
JP4959601B2 (ja) | トラヒック統計情報に基づく受付制御方法および制御システム、ならびにそのプログラム | |
JPH08237271A (ja) | 仮想パスの動的帯域変更制御方法 | |
JP4146831B2 (ja) | VoIPサービスシステム、呼制御サーバ、および呼制御方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080725 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100531 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100604 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20101008 |