JP2004080612A - 帯域予約管理システム - Google Patents
帯域予約管理システム Download PDFInfo
- Publication number
- JP2004080612A JP2004080612A JP2002240693A JP2002240693A JP2004080612A JP 2004080612 A JP2004080612 A JP 2004080612A JP 2002240693 A JP2002240693 A JP 2002240693A JP 2002240693 A JP2002240693 A JP 2002240693A JP 2004080612 A JP2004080612 A JP 2004080612A
- Authority
- JP
- Japan
- Prior art keywords
- bandwidth
- reservation
- band
- reserved
- packet
- 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
【課題】特定クライアント間の通信帯域を予約することによって、必要な帯域幅、または可能な限り広い帯域幅を、必要な時間帯だけ確保し、さらに、確保した帯域幅に応じて課金する帯域予約管理システムを提供する。
【解決手段】クライアント４が帯域予約要求パケットを発信すると、その帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、通信回線の帯域予約を行い、さらに予約開始時刻から予約終了時刻の間は、帯域幅で通信回線を接続し、特定クライアント４間のルーティング機能６およびルータ２において個々に帯域予約が行われ、帯域予約要求に合致する特定クライアント４間の通信回線が確立予約された時点で予約情報を発信するルーティング機能６またはルータ２と、予約情報に基づいてクライアント４に対して料金情報を発信する管理サーバ３とを備える。
【選択図】 図７
【解決手段】クライアント４が帯域予約要求パケットを発信すると、その帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、通信回線の帯域予約を行い、さらに予約開始時刻から予約終了時刻の間は、帯域幅で通信回線を接続し、特定クライアント４間のルーティング機能６およびルータ２において個々に帯域予約が行われ、帯域予約要求に合致する特定クライアント４間の通信回線が確立予約された時点で予約情報を発信するルーティング機能６またはルータ２と、予約情報に基づいてクライアント４に対して料金情報を発信する管理サーバ３とを備える。
【選択図】 図７
Description
【０００１】
【発明の属する技術分野】
本発明は、特に広帯域幅を必要とする情報通信において、特定端末間の通信で行われる通信回線の帯域予約の予約情報を管理する帯域予約管理システムに関する。
【０００２】
【従来の技術】
近年、ブロードバンドの普及に伴い動画配信やテレビ会議等、ナローバンドでは不可能だったサービスが相次いで登場している。そのため、ブロードバンドが浸透したネットワーク環境下においては、ユーザ間、またはユーザとサーバ間の通信肥大化が予想され、ＱｏＳ （Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）維持のためにバックボーン回線の増強等の対策が不可欠となる。
【０００３】
【発明が解決しようとする課題】
ただバックボーン回線の増強は実際には多くの費用と時間がかかるため、通信品質が維持されないままサービスが展開されることも多いに予想される。また、従来のＩＰネットワークはコネクションレス・ベストエフォート型ネットワークであり、リアルタイム性が要求される情報伝達などに対して十分なＱｏＳを保証できなかった。
【０００４】
そこで、端末間のＱｏＳを保証するために、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ ＥｎｇｉｎｅｅｒｉｎｇＴａｓｋ Ｆｏｒｃｅ）ではＲＳＶＰ（Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ） などの帯域予約プロトコルが提案されている。
【０００５】
このＲＳＶＰは、帯域予約要求をすべての経路に伝達することによって帯域予約を実現しており、ソフトステートと呼ばれる構造を持ち、帯域予約状態の生存時間を限定している。予約状態を維持するには、送信側からＰａｔｈメッセージを、受信側からＲｅｓｖメッセージを定期的に送信する必要があるが、予約状態の生存時間を過ぎると、予約状態は自動的に削除される。
【０００６】
この機能により、ネットワークがすでに使われなくなった帯域予約によって無駄に使用されることはない。しかし、要求された全ての帯域予約要求を保証するというものではない。
【０００７】
そこで上記の問題を解決するための手法として、電気通信大学の池邉隆（他３名）によって「ＩＰネットワークにおける待時式帯域予約通信方式」が提案されている。
【０００８】
この待時式帯域予約通信方式とは、帯域予約により予約可能な通信帯域が枯渇あるいは一定の負荷率に達した場合、それ以降の帯域予約通信要求をそれぞれのルータが持つ順番待ちリストに入れ順番待ちを行い、帯域が予約可能になった時に発行順序に（ＦＩＦＯで）帯域を予約する方式である。
【０００９】
この待時式帯域予約通信方式では、予約要求を「順番待ちリスト」に登録することにより、有限時間内に帯域予約を行うことができるが、特定の時刻に帯域を確保することができるかどうかは全く保障されない。そのためテレビ会議等、一定時間内に確実に帯域予約を行う必要があるサービスに対しては、ＱｏＳを保証することができない。
【００１０】
また、帯域予約を行う時間を指定する方式として、特開平９−２６１３４５号公報に「通信網資源予約方式」が開示されている。
【００１１】
この通信網資源予約方式では、特開平９−２６１３４５号公報の段落００３８に、帯域予約要求メッセージに記述されるパラメータとして「使用開始時刻、使用終了時刻、所要帯域」が上げられており、この使用開始時刻と使用終了時刻との間で帯域予約を行うというものである。
【００１２】
しかしながら、この通信網資源予約方式では、使用開始時刻と使用終了時刻との間で所要帯域の予約ができなかった場合、帯域予約要求に対してどの程度のＱｏＳが保証されるかについては記載が無く、全く不明である。そのためテレビ会議等、一定時間内に確実に帯域予約を行う必要があるサービスに対しては、この通信網資源予約方式ではＱｏＳを保証することができない。
【００１３】
本発明は上記事情に鑑み、動画配信やテレビ会議等、必要な時間帯のみ帯域を確保したい要求に応じて、帯域のスケジューリング、およびルーティング制御によりクライアント間の通信帯域を予約することによって、必要な帯域幅、または可能な限り広い帯域幅を、必要な時間帯だけ確保し、さらに、確保した帯域幅に応じて課金する帯域予約管理システムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、請求項１に記載の発明である帯域予約管理システムは、特定端末間の通信回線の帯域予約を行い、その予約情報を管理する帯域予約管理システムであって、前記特定端末間の通信回線の帯域を予約するために、帯域幅、予約開始時刻、および予約終了時刻を含む帯域予約要求を発信する帯域予約要求手段と、当該帯域予約要求を受信すると、当該帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、前記通信回線の帯域予約を行い、さらに当該予約開始時刻から当該予約終了時刻の間は、当該帯域幅で前記通信回線を接続する回線接続手段と、前記特定端末間の通信回線上に存在する任意の前記回線接続手段において個々に帯域予約が行われ、当該帯域予約要求に合致する前記特定端末間の通信回線の帯域予約が確立した時点で、その予約情報を発信する予約情報発信手段と、前記予約情報に応じて、帯域予約された当該通信回線の使用料を算出する料金算出手段とを備えることを特徴とする。
【００１５】
請求項１の発明によれば、帯域を確保する開始時刻と終了時刻を持って予約を行うので、ネットワークの混雑時においても安定したスループットを確実に得ることができ、ＱｏＳを保証することができる。
【００１６】
また、請求項２に記載の発明である帯域予約管理システムは、請求項１に記載の帯域予約管理システムであって、前記帯域予約要求手段は、前記回線接続手段において当該帯域幅で帯域予約できなかった場合、当該帯域幅より狭い帯域幅で帯域予約要求を発信することを特徴とする。
【００１７】
請求項２の発明によれば、要求された帯域幅で予約ができなかった場合、より狭い帯域幅で予約処理を繰り返すことによって、要求された帯域幅よりも狭い帯域幅ではあるが、開始時刻と終了時刻を持って帯域を予約するので、より確実にＱｏＳを保証することができる。
【００１８】
【発明の実施の形態】
本発明の実施形態を、図１〜図１０に基づいて説明する。
【００１９】
まず、帯域予約管理システム１の構成について、図１〜図６に基づいて説明する。
【００２０】
本実施形態における帯域予約管理システム１は、図１に示すように、ルータ２ａ，ｂ，ｃ…ｎ，ｚと、管理サーバ３と、ルーティング機能６を有するクライアント４ａ，ｂ…と、それらを相互に接続する通信回線５とから構成される。図１においては、接続元（Ｓｏｕｒｃｅ）と接続先（Ｄｅｓｔｉｎａｔｉｏｎ）のクライアント４として、クライアント４ａ，ｂの２つしか示していないが、それぞれのルータ２ａ，ｂ，ｃ…ｎ，ｚには複数のクライアント４が接続される。
【００２１】
また、クライアント４は、ルータ２ａ，ｂ，ｃ…ｎ，ｚを介して管理サーバ３に接続される。このルータ２ａ，ｂ，ｃ…ｎ，ｚと管理サーバ３を接続する通信回線５（図中、破線部）は、両者を直接接続する回線である必要は無い。クライアント４と管理サーバ３との間に何らかのルータ２ａ，ｂ，ｃ…ｎ，ｚや他の通信回線５が介在しても、両者間でパケット交換可能であれば良い。
【００２２】
図２は、ルータ２の機能ブロック図であり、図３は、クライアント４が有するルーティング機能６の機能ブロック図である。ルータ２は、図２に示すように、帯域予約プロセス７、ポリシー制御８、受付制御９、帯域予約テーブル１０、ルーティングプロセス１１、パケットクラス分け１２、パケットスケジューラ１３を有する。また、ルーティング機能６は、図３に示すように、帯域予約プロセス７、ポリシー制御８、受付制御９、帯域予約テーブル１０、パケットクラス分け１２、パケットスケジューラ１３を有し、上位のレイヤーから帯域予約要求の命令と送信するデータを受信する。
【００２３】
帯域予約プロセス７は、クライアント４、または前後段のルータ２から送信された帯域予約要求パケット、エラーパケット、および了承パケットを受け取ると、それらパケットに記述されている内容を判別し、その内容に応じて各機能部に対して動作指示を行う機能を有する。
【００２４】
また、受付制御９は、クライアント４、または前段のルータ２から送信された帯域予約要求を満たすのに十分なリソースを持っているか否か、帯域予約テーブル１０を参照し、判断する機能と、十分なリソースを持っていると判断した場合に、その帯域予約要求を帯域予約テーブル１０に仮予約し、後段のルータ２から帯域予約の了承情報を受信すると、仮予約を解除し、帯域予約要求を帯域予約テーブル１０に本登録する機能を有する。また、受付制御９は、帯域予約要求に指定された時刻に、帯域予約プロセス７に帯域予約および開放を指示する機能を有する。
【００２５】
また、ポリシー制御８は、受信者が帯域予約できる権限を持っているか否かを判断する機能を有し、パケットスケジューラ１３、ルーティングプロセス１１、パケットクラス分け１２は、それぞれ帯域予約プロセス７に指示に従ってデータパケットの流れを制御する機能、帯域が予約できなかった場合に、ルーティングテーブルを参照し（図示しない）、別の径路を検索する機能を有するが、その制御手法ついては従来のルータ２が有する機能と同じなので、詳細な説明については省略する。
【００２６】
図４は、帯域予約テーブル１０の構成と、記録される情報の例を示したものである。帯域予約テーブル１０は、シーケンス番号、Ｓｏｕｒｃｅ、Ｄｅｓｔｉｎａｔｉｏｎ、データ方向、年月日、開始時刻、終了時刻、帯域幅、およびフラグの項目を有する。
【００２７】
Ｓｏｕｒｃｅ（送信元）とＤｅｓｔｉｎａｔｉｏｎ（送信先）の項目には、帯域を確保する２つのクライアント４ａ、ｂのＩＰアドレスがそれぞれ記録される。また、データ方向の項目には、帯域を確保する通信回線５の方向が、例えば、Ｓｏｕｒｃｅ側を基準として、「上り」、「下り」、「双方向」のいずれかが記録される。
【００２８】
また、年月日、開始時刻、終了時刻の項目には、帯域を確保する日付、および時刻の情報が記録され、帯域幅の項目には、確保する帯域幅が記録される。
【００２９】
また、フラグの項目には通信回線５の確保の状態に応じて、決められた値が記録される。帯域予約テーブル１０のフラグの値が１の場合は、通信回線５の予約が確定している状態、フラグの値が−１の場合は、仮予約の状態、フラグの値が０の場合は、その予約が無効（または終了）の状態であることを示す。なお、無効（または終了）の場合は、記憶容量に応じて順次削除される。
【００３０】
図５は、管理サーバ３の機能ブロック図である。図５に示すように、本実施形態における管理サーバ３は、パケット送受信部１４、データベース管理部１５、料金算出部１６、および帯域管理データベース１７を有する。
【００３１】
パケット送受信部１４は、ルータ２からの了承パケットを受信し、帯域予約の要求元へ料金情報を有するパケットを送信する機能を有する。
【００３２】
また、データベース管理部１５は、パケット送受信部１４が受信した了承パケットに記述されている内容を判別し、その内容を帯域管理データベース１７に記録する機能を有する。
【００３３】
また、料金算出部１６は、データベース管理部１５が判別した内容に応じて、帯域予約に課金される料金を算出する機能を有する。
【００３４】
図６は、帯域管理データベース１７が有するデータテーブルの構成と、記録される情報の例を示したものである。帯域管理データベース１７は、シーケンス番号、Ｓｏｕｒｃｅ、Ｄｅｓｔｉｎａｔｉｏｎ、データ方向、年月日、開始時刻、終了時刻、帯域幅、および料金の項目を有するデータテーブルを備える。料金以外の各項目に記録される情報は、各ルータ２で確定した帯域予約の情報が記録される（詳細な説明については省略する）。また、料金の項目には、料金算出部１６が算出した料金が記録される。
【００３５】
次に、帯域予約管理システム１における一連の処理手順について、図７のフローチャートと、図８〜１０の画面表示例とを用いて説明する。
【００３６】
図８は、その帯域予約情報を入力するための入力画面の表示例である。クライアント４ａのユーザは、表示された項目にしたがって、接続先の情報（接続先のＩＰアドレス）、利用日、開始時刻、終了時刻、予約帯域幅、許容帯域幅、方向性を入力する。予約帯域幅と許容帯域幅とは、図８に示すように、予め設定された帯域幅から選択されるようにしても良い。
【００３７】
ここで許容帯域幅とは、予約帯域幅で帯域予約ができなかった場合に、クライアント４のユーザの利用目的に耐え得る（許容できる）帯域幅の下限値である。図７の例では、予約帯域幅が３Ｍｂｐｓ、許容帯域幅が１．５Ｍｂｐｓとなっているので、仮に８Ｍｂｐｓで予約できなかった場合は、８Ｍｂｐｓより狭い帯域幅で予約処理を繰り返し、１．５Ｍｂｐｓまでで帯域予約が可能であれば自動的に予約を行う。
【００３８】
まず、帯域予約の要求元から帯域予約情報が入力されると（ステップＳ０１）、クライアント４ａ（Ｓｏｕｒｃｅ）は帯域予約要求パケットを生成し、ルーティング機能６に送信する（ステップＳ０２）。帯域予約要求パケットには、帯域予約に関する要求であることを示す情報（ヘッダ）と、Ｓｏｕｒｃｅアドレス、Ｄｅｓｔｉｎａｔｉｏｎアドレス、日付、開始時刻、終了時刻、帯域幅、方向性、フラグの各情報を含む。この帯域予約要求パケットのフラグの値が０の場合は、帯域予約要求が継続中であることを示し、フラグの値が−１の場合は、そのパケットに記述されている帯域予約要求が、いずれかのルータ２で確保できなかったことを示す（エラーパケット）。また、フラグの値が１の場合は、帯域予約要求が確定したことを示す（了承パケット）。
【００３９】
ルーティング機能６（またはルータ２）の帯域予約プロセス７は、帯域予約要求パケットを受信すると（ステップＳ０３）、その帯域予約要求パケットに記述されている内容を判別し、受付制御９に帯域予約が可能であるか判定を行うよう指示を出す。受付制御９は、帯域予約テーブル１０を参照し（ステップＳ０４）、帯域予約が可能であるか判定を行う（ステップＳ０５）。判定の結果、帯域予約が可能であれば、受付制御９は、帯域予約テーブル１０にその帯域予約要求を仮予約する（ステップＳ０６）。仮予約の後、帯域予約プロセス７は、後段のルータ２へ帯域予約要求パケットを送信する（ステップＳ０７）。
【００４０】
また、判定の結果、帯域予約が不可能であれば、帯域予約プロセス７は、別の径路を検索する（ステップＳ０８）。そして別の径路が構築可能であるか判定し（ステップＳ０９）、別の径路が構築可能である場合は、その径路で帯域予約が可能であるか判定を行う処理（ステップＳ０５）に戻る。別の径路が構築不可能である場合は、帯域予約プロセス７は、帯域予約要求パケットのフラグの値を−１に変更してエラーパケットを作成し、前段のルータ２またはクライアント４ａへ送信する（ステップＳ１０）。
【００４１】
上記ステップＳ０３からステップＳ１０までの処理は、クライアント４ａのルーティング機能６で行われた後、Ｓｏｕｒｃｅ−Ｄｅｓｔｉｎａｔｉｏｎ間に介在するルータ２で同様に繰り返され、最終的にクライアント４ｂ（Ｄｅｓｔｉｎａｔｉｏｎ）のルーティング機能６に到達する。
【００４２】
なお、各ルータ２は、帯域予約要求パケットを受信するたびに、そのルータ２のＩＰアドレスを帯域予約要求パケットに追記し、通信径路を記録する。エラーパケット、了承パケットは、その記録されたＩＰアドレスを参照することによって、帯域予約要求パケットが通った径路で返送される。エラーパケットを受信したルータ２は、そのエラーパケットに記述されている帯域予約要求を帯域予約テーブル１０から検索し、その帯域予約要求のフラグを０に変更し、無効状態にする。
【００４３】
また、ルーティング機能６において、別径路の検索は、そのクライアント４にネットワークアダプタが複数存在する場合に行われる処理である。
【００４４】
次に、クライアント４ｂが有するルーティング機能６の帯域予約プロセス７は、帯域予約要求パケットを受信すると（ステップＳ１１）、その帯域予約要求パケットに記述されている内容を判別し、受付制御９に帯域予約が可能であるか判定を行うよう指示を出す。受付制御９は、帯域予約テーブル１０を参照し（ステップＳ１２）、帯域予約が可能であるか判定を行う（ステップＳ１３）。判定の結果、帯域予約が可能であれば、受付制御９は、帯域予約テーブル１０にその帯域予約要求を登録する（ステップＳ１４）。この時、帯域予約テーブル１０のフラグの値は１であり、予約確定となる。
【００４５】
次に、帯域予約プロセス７は、帯域予約要求パケットのフラグの値を１に変更して了承パケットを作成し、前段のルータ２またはクライアント４、および管理サーバ３へ送信する（ステップＳ１５）。
【００４６】
なお、ステップＳ１３で判定の結果、帯域予約が不可能であれば、帯域予約プロセス７は、帯域予約要求パケットのフラグの値を−１に変更してエラーパケットを作成し、前段のルータ２またはクライアント４へ送信する（ステップＳ１６）。
【００４７】
了承パケットは、帯域予約要求パケットが通った径路で返送される。各ルータ２の帯域予約プロセス７は、了承パケットを受信すると（ステップＳ１７）、その了承パケットに記述されている帯域予約要求を帯域予約テーブル１０から検索するよう受付制御９に指示を出し、受付制御９は、該当する帯域予約要求のフラグを１に変更し、予約確定状態にする（ステップＳ１８）。
【００４８】
管理サーバ３では、了承パケットを受信すると帯域管理データベース１７に予約情報を登録し料金を算出する。
【００４９】
まず、パケット送受信部１４は、了承パケットを受信すると（ステップＳ１９）、その了承パケットに記述されている内容を判別し、帯域管理データベース１７に登録する項目毎に情報を抽出し、データベース管理部１５に転送する（ステップＳ１９）。
【００５０】
データベース管理部１５は、パケット送受信部１４から転送された各種情報を帯域管理データベース１７に記録する（ステップＳ２０）。また、データベース管理部１５は、料金算出のために必要な情報を料金算出部１６へ転送する。
【００５１】
料金算出部１６は、データベース管理部１５から転送された各種情報を基に、料金を算出し（ステップＳ２１）、帯域管理データベース１７に記録する。本実施形態では、料金を算出する式は、
料金＝帯域幅×｛終了時刻−開始時刻（単位：時間）｝×方向性
ただし、１Ｍｂｐｓあたり１００円、方向性については、双方向は２、上りまたは下りは１として計算している。例えば、図６のシーケンス番号１番の予約要求では、
となる。なお料金の算出式は、これに限定されるものではない。
【００５２】
そして、パケット送受信部１４は、データベース管理部１５を介して料金情報を取得し、クライアント４ａへ送信する。
【００５３】
クライアント４ａは、了承パケットを受信し（ステップＳ２２）、管理サーバ３から料金情報を受信すると（ステップＳ２３）、帯域予約完了の旨をクライアント４ｂへ送信する（ステップＳ２４）。クライアント４ｂでは、帯域予約完了の旨を受信することによって、帯域が予約されたことを得ることができる（ステップＳ２５）。
【００５４】
クライアント４ａは、エラーパケットを受信すると、予約帯域幅より狭い帯域幅で、再度予約処理を行う。図８の例では、予約帯域幅は８Ｍｂｐｓに設定されているが、この８Ｍｂｐｓで帯域予約ができなかった場合、４Ｍｂｐｓ、１．５Ｍｂｐｓ、１Ｍｂｐｓ…６４ｋｂｐｓまで、予約帯域幅より狭い帯域幅から予め設定された下限の帯域幅まで、帯域予約ができるまで、繰り返し予約処理を行う。
【００５５】
クライアント４は、エラーパケットを受信すると（ステップＳ２６）、エラーパケットに記述されている帯域幅より狭い帯域幅に設定可能であるか判定し（ステップＳ２７）、エラーパケットに記述されている帯域幅より狭い帯域幅に設定可能である場合、その狭い帯域幅で帯域予約要求パケットを生成し、再度、帯域予約要求を行うステップＳ０２の処理に戻る（ステップＳ２８）。
【００５６】
ステップＳ２７で、下限の帯域幅で帯域予約ができなかった場合は、クライアント４ａユーザへ帯域予約ができなかった旨のエラーメッセージを通知する（ステップＳ２９）。
【００５７】
このように、予約帯域幅で帯域予約ができなかった場合には、自動的により狭い帯域幅で予約処理を繰り返す。図９は、予約帯域幅を８Ｍｂｐｓに設定したが８Ｍｂｐｓでは帯域予約ができず、４Ｍｂｐｓで帯域予約が確定した場合の画面表示例である。本実施形態では、帯域が確保された時点で、自動的に予約を確定させているが、図１０に示すように、予約帯域幅で帯域予約ができなかった場合、または、許容帯域幅より狭い帯域幅で予約処理を行う場合は、仮予約であることを示すフラグ値を帯域予約要求パケットに記録するようにして、予約可能な最大帯域幅をクライアント４ａに通知し、確認を促すようにしても良い。
【００５８】
具体的には、ステップＳ２８で仮予約であることを示すフラグ値を帯域予約要求パケットに設定し、ステップＳ２２で了承パケットを受信した時に、クライアント４ａユーザに確認を促し、仮予約中の帯域幅で良ければ、フラグ値を０に設定し、再度、帯域予約要求パケットを送信する。この場合、最大帯域幅で仮予約状態にしておくことによって、後からされた帯域予約要求に帯域を確保されてしまうことを防ぐことができる。
【００５９】
なお、本実施形態においては、帯域予約の要求元（クライアント４ａ）へ料金情報を送信するようになっているが、これに限定されるものではない。帯域管理データベース１７に料金情報の送信先を登録し、料金情報を送信する度にその送信先を参照するようにしてもよい。
【００６０】
また、本実施形態においては、ルータ２がエラーパケットを受信すると、フラグを変更して仮予約を解除するようにしているが、フラグを変更する前に、同じ帯域予約要求の内容で別の経路で帯域予約できるか検索を行うようにしても良い。この場合、別の径路で帯域予約できる場合は、帯域予約プロセス７は、エラーパケットのフラグを変更することによって帯域予約要求パケットを再生成し、後段のルータ２へ送信する。
【００６１】
また、本実施形態においては、クライアント４ａ（Ｓｏｕｒｃｅ）側から順にクライアント４ｂ（Ｄｅｓｔｉｎａｔｉｏｎ）側へ帯域予約が行われるが、これに限定されるものではない。一旦、クライアント４ａからクライアント４ｂへ帯域予約要求パケットを送信することによって、通信径路を確定した後、クライアント４ｂ側からクライアント４ａ側へ、確定した通信径路を逆向きに辿りつつ、ルータ２毎に帯域予約を行うようにしても良い。この場合、途中で帯域予約ができなかった場合は、クライアント４ａから別の径路でクライアント４ｂへ帯域予約要求パケットを再送信し、順次、逆向きに辿りつつ、ルータ２毎に帯域予約を行う。
【００６２】
また、本実施形態においては、帯域予約の要求元は確保された帯域を利用するクライアント４となっているが、これに限定されるものではない。任意の端末から、特定の２つのクライアント４を指定することによって、それらクライアント４間の通信回線５の帯域を予約するようにしても良い。さらに、この場合、料金情報は帯域予約を要求した端末に送信するようにしても良い。
【００６３】
また、本発明においては、ルータとは、広義の意味で通信回線を接続する機器のことを指し、一般的にルータと呼ばれるものに限定されず、ゲートウェイ等でも良い。
【００６４】
また、確保された帯域をどのように利用するかはクライアント４ユーザに委ねられる。例えばテレビ会議に利用する場合では、８Ｍｂｐｓで帯域予約できれば、ＤＶＤビデオ程度の画質で映像を配信することができ、１．５Ｍｂｐｓで帯域予約されても、ＶＨＳ標準程度の画質で映像を配信することができる。また、１２８ｋｂｐｓで帯域予約されても、音声だけならＭＰ３形式（ＭＰＧＥ−１ Ａｕｄｉｏ Ｌａｙｅｒ−３）で十分クリアな音声を配信することができる。
【００６５】
さらに映画配信等では、映像の圧縮形式やビットレートに応じて、確保された帯域幅で、複数本の映像を同時に配信することも可能である。例えば、８Ｍｂｐｓで帯域予約できれば、ＭＰＥＧ−１形式の映像であれば、５本程度は配信することができる。
【００６６】
【発明の効果】
以上説明したように、本発明によれば、帯域を確保する開始時刻と終了時刻を持って予約を行うので、ネットワークの混雑時においても安定したスループットを確実に得ることができ、ＱｏＳを保証することができる。
【００６７】
また、要求された帯域幅で予約ができなかった場合、より狭い帯域幅で予約処理を繰り返すことによって、要求された帯域幅よりも狭い帯域幅ではあるが、開始時刻と終了時刻を持って帯域を予約するので、より確実にＱｏＳを保証することができる。
【図面の簡単な説明】
【図１】帯域予約管理システムの構成図である。
【図２】ルータの機能ブロック図である。
【図３】クライアントが有するルーティング機能の機能ブロック図である。
【図４】帯域予約テーブルの構成と、記録される情報の例を示す図である。
【図５】管理サーバの機能ブロック図である。
【図６】帯域管理データベースが有するデータテーブルの構成を示す図である。
【図７】帯域予約管理システムにおける一連の処理手順を示すフローチャートである。
【図８】帯域予約情報を入力するための入力画面の表示例である。
【図９】帯域予約が確定した場合の画面表示例である。
【図１０】帯域予約が確定した場合の画面表示例である。
【符号の説明】
１ 帯域予約管理システム
２ ルータ
３ 管理サーバ
４ クライアント
５ 通信回線
６ ルーティング機能
７ 帯域予約プロセス
８ ポリシー制御
９ 受付制御
１０ 帯域予約テーブル
１１ ルーティングプロセス
１２ パケットクラス分け
１３ パケットスケジューラ
１４ パケット送受信部
１５ データベース管理部
１６ 料金算出部
１７ 帯域管理データベース
【発明の属する技術分野】
本発明は、特に広帯域幅を必要とする情報通信において、特定端末間の通信で行われる通信回線の帯域予約の予約情報を管理する帯域予約管理システムに関する。
【０００２】
【従来の技術】
近年、ブロードバンドの普及に伴い動画配信やテレビ会議等、ナローバンドでは不可能だったサービスが相次いで登場している。そのため、ブロードバンドが浸透したネットワーク環境下においては、ユーザ間、またはユーザとサーバ間の通信肥大化が予想され、ＱｏＳ （Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）維持のためにバックボーン回線の増強等の対策が不可欠となる。
【０００３】
【発明が解決しようとする課題】
ただバックボーン回線の増強は実際には多くの費用と時間がかかるため、通信品質が維持されないままサービスが展開されることも多いに予想される。また、従来のＩＰネットワークはコネクションレス・ベストエフォート型ネットワークであり、リアルタイム性が要求される情報伝達などに対して十分なＱｏＳを保証できなかった。
【０００４】
そこで、端末間のＱｏＳを保証するために、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ ＥｎｇｉｎｅｅｒｉｎｇＴａｓｋ Ｆｏｒｃｅ）ではＲＳＶＰ（Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ） などの帯域予約プロトコルが提案されている。
【０００５】
このＲＳＶＰは、帯域予約要求をすべての経路に伝達することによって帯域予約を実現しており、ソフトステートと呼ばれる構造を持ち、帯域予約状態の生存時間を限定している。予約状態を維持するには、送信側からＰａｔｈメッセージを、受信側からＲｅｓｖメッセージを定期的に送信する必要があるが、予約状態の生存時間を過ぎると、予約状態は自動的に削除される。
【０００６】
この機能により、ネットワークがすでに使われなくなった帯域予約によって無駄に使用されることはない。しかし、要求された全ての帯域予約要求を保証するというものではない。
【０００７】
そこで上記の問題を解決するための手法として、電気通信大学の池邉隆（他３名）によって「ＩＰネットワークにおける待時式帯域予約通信方式」が提案されている。
【０００８】
この待時式帯域予約通信方式とは、帯域予約により予約可能な通信帯域が枯渇あるいは一定の負荷率に達した場合、それ以降の帯域予約通信要求をそれぞれのルータが持つ順番待ちリストに入れ順番待ちを行い、帯域が予約可能になった時に発行順序に（ＦＩＦＯで）帯域を予約する方式である。
【０００９】
この待時式帯域予約通信方式では、予約要求を「順番待ちリスト」に登録することにより、有限時間内に帯域予約を行うことができるが、特定の時刻に帯域を確保することができるかどうかは全く保障されない。そのためテレビ会議等、一定時間内に確実に帯域予約を行う必要があるサービスに対しては、ＱｏＳを保証することができない。
【００１０】
また、帯域予約を行う時間を指定する方式として、特開平９−２６１３４５号公報に「通信網資源予約方式」が開示されている。
【００１１】
この通信網資源予約方式では、特開平９−２６１３４５号公報の段落００３８に、帯域予約要求メッセージに記述されるパラメータとして「使用開始時刻、使用終了時刻、所要帯域」が上げられており、この使用開始時刻と使用終了時刻との間で帯域予約を行うというものである。
【００１２】
しかしながら、この通信網資源予約方式では、使用開始時刻と使用終了時刻との間で所要帯域の予約ができなかった場合、帯域予約要求に対してどの程度のＱｏＳが保証されるかについては記載が無く、全く不明である。そのためテレビ会議等、一定時間内に確実に帯域予約を行う必要があるサービスに対しては、この通信網資源予約方式ではＱｏＳを保証することができない。
【００１３】
本発明は上記事情に鑑み、動画配信やテレビ会議等、必要な時間帯のみ帯域を確保したい要求に応じて、帯域のスケジューリング、およびルーティング制御によりクライアント間の通信帯域を予約することによって、必要な帯域幅、または可能な限り広い帯域幅を、必要な時間帯だけ確保し、さらに、確保した帯域幅に応じて課金する帯域予約管理システムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、請求項１に記載の発明である帯域予約管理システムは、特定端末間の通信回線の帯域予約を行い、その予約情報を管理する帯域予約管理システムであって、前記特定端末間の通信回線の帯域を予約するために、帯域幅、予約開始時刻、および予約終了時刻を含む帯域予約要求を発信する帯域予約要求手段と、当該帯域予約要求を受信すると、当該帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、前記通信回線の帯域予約を行い、さらに当該予約開始時刻から当該予約終了時刻の間は、当該帯域幅で前記通信回線を接続する回線接続手段と、前記特定端末間の通信回線上に存在する任意の前記回線接続手段において個々に帯域予約が行われ、当該帯域予約要求に合致する前記特定端末間の通信回線の帯域予約が確立した時点で、その予約情報を発信する予約情報発信手段と、前記予約情報に応じて、帯域予約された当該通信回線の使用料を算出する料金算出手段とを備えることを特徴とする。
【００１５】
請求項１の発明によれば、帯域を確保する開始時刻と終了時刻を持って予約を行うので、ネットワークの混雑時においても安定したスループットを確実に得ることができ、ＱｏＳを保証することができる。
【００１６】
また、請求項２に記載の発明である帯域予約管理システムは、請求項１に記載の帯域予約管理システムであって、前記帯域予約要求手段は、前記回線接続手段において当該帯域幅で帯域予約できなかった場合、当該帯域幅より狭い帯域幅で帯域予約要求を発信することを特徴とする。
【００１７】
請求項２の発明によれば、要求された帯域幅で予約ができなかった場合、より狭い帯域幅で予約処理を繰り返すことによって、要求された帯域幅よりも狭い帯域幅ではあるが、開始時刻と終了時刻を持って帯域を予約するので、より確実にＱｏＳを保証することができる。
【００１８】
【発明の実施の形態】
本発明の実施形態を、図１〜図１０に基づいて説明する。
【００１９】
まず、帯域予約管理システム１の構成について、図１〜図６に基づいて説明する。
【００２０】
本実施形態における帯域予約管理システム１は、図１に示すように、ルータ２ａ，ｂ，ｃ…ｎ，ｚと、管理サーバ３と、ルーティング機能６を有するクライアント４ａ，ｂ…と、それらを相互に接続する通信回線５とから構成される。図１においては、接続元（Ｓｏｕｒｃｅ）と接続先（Ｄｅｓｔｉｎａｔｉｏｎ）のクライアント４として、クライアント４ａ，ｂの２つしか示していないが、それぞれのルータ２ａ，ｂ，ｃ…ｎ，ｚには複数のクライアント４が接続される。
【００２１】
また、クライアント４は、ルータ２ａ，ｂ，ｃ…ｎ，ｚを介して管理サーバ３に接続される。このルータ２ａ，ｂ，ｃ…ｎ，ｚと管理サーバ３を接続する通信回線５（図中、破線部）は、両者を直接接続する回線である必要は無い。クライアント４と管理サーバ３との間に何らかのルータ２ａ，ｂ，ｃ…ｎ，ｚや他の通信回線５が介在しても、両者間でパケット交換可能であれば良い。
【００２２】
図２は、ルータ２の機能ブロック図であり、図３は、クライアント４が有するルーティング機能６の機能ブロック図である。ルータ２は、図２に示すように、帯域予約プロセス７、ポリシー制御８、受付制御９、帯域予約テーブル１０、ルーティングプロセス１１、パケットクラス分け１２、パケットスケジューラ１３を有する。また、ルーティング機能６は、図３に示すように、帯域予約プロセス７、ポリシー制御８、受付制御９、帯域予約テーブル１０、パケットクラス分け１２、パケットスケジューラ１３を有し、上位のレイヤーから帯域予約要求の命令と送信するデータを受信する。
【００２３】
帯域予約プロセス７は、クライアント４、または前後段のルータ２から送信された帯域予約要求パケット、エラーパケット、および了承パケットを受け取ると、それらパケットに記述されている内容を判別し、その内容に応じて各機能部に対して動作指示を行う機能を有する。
【００２４】
また、受付制御９は、クライアント４、または前段のルータ２から送信された帯域予約要求を満たすのに十分なリソースを持っているか否か、帯域予約テーブル１０を参照し、判断する機能と、十分なリソースを持っていると判断した場合に、その帯域予約要求を帯域予約テーブル１０に仮予約し、後段のルータ２から帯域予約の了承情報を受信すると、仮予約を解除し、帯域予約要求を帯域予約テーブル１０に本登録する機能を有する。また、受付制御９は、帯域予約要求に指定された時刻に、帯域予約プロセス７に帯域予約および開放を指示する機能を有する。
【００２５】
また、ポリシー制御８は、受信者が帯域予約できる権限を持っているか否かを判断する機能を有し、パケットスケジューラ１３、ルーティングプロセス１１、パケットクラス分け１２は、それぞれ帯域予約プロセス７に指示に従ってデータパケットの流れを制御する機能、帯域が予約できなかった場合に、ルーティングテーブルを参照し（図示しない）、別の径路を検索する機能を有するが、その制御手法ついては従来のルータ２が有する機能と同じなので、詳細な説明については省略する。
【００２６】
図４は、帯域予約テーブル１０の構成と、記録される情報の例を示したものである。帯域予約テーブル１０は、シーケンス番号、Ｓｏｕｒｃｅ、Ｄｅｓｔｉｎａｔｉｏｎ、データ方向、年月日、開始時刻、終了時刻、帯域幅、およびフラグの項目を有する。
【００２７】
Ｓｏｕｒｃｅ（送信元）とＤｅｓｔｉｎａｔｉｏｎ（送信先）の項目には、帯域を確保する２つのクライアント４ａ、ｂのＩＰアドレスがそれぞれ記録される。また、データ方向の項目には、帯域を確保する通信回線５の方向が、例えば、Ｓｏｕｒｃｅ側を基準として、「上り」、「下り」、「双方向」のいずれかが記録される。
【００２８】
また、年月日、開始時刻、終了時刻の項目には、帯域を確保する日付、および時刻の情報が記録され、帯域幅の項目には、確保する帯域幅が記録される。
【００２９】
また、フラグの項目には通信回線５の確保の状態に応じて、決められた値が記録される。帯域予約テーブル１０のフラグの値が１の場合は、通信回線５の予約が確定している状態、フラグの値が−１の場合は、仮予約の状態、フラグの値が０の場合は、その予約が無効（または終了）の状態であることを示す。なお、無効（または終了）の場合は、記憶容量に応じて順次削除される。
【００３０】
図５は、管理サーバ３の機能ブロック図である。図５に示すように、本実施形態における管理サーバ３は、パケット送受信部１４、データベース管理部１５、料金算出部１６、および帯域管理データベース１７を有する。
【００３１】
パケット送受信部１４は、ルータ２からの了承パケットを受信し、帯域予約の要求元へ料金情報を有するパケットを送信する機能を有する。
【００３２】
また、データベース管理部１５は、パケット送受信部１４が受信した了承パケットに記述されている内容を判別し、その内容を帯域管理データベース１７に記録する機能を有する。
【００３３】
また、料金算出部１６は、データベース管理部１５が判別した内容に応じて、帯域予約に課金される料金を算出する機能を有する。
【００３４】
図６は、帯域管理データベース１７が有するデータテーブルの構成と、記録される情報の例を示したものである。帯域管理データベース１７は、シーケンス番号、Ｓｏｕｒｃｅ、Ｄｅｓｔｉｎａｔｉｏｎ、データ方向、年月日、開始時刻、終了時刻、帯域幅、および料金の項目を有するデータテーブルを備える。料金以外の各項目に記録される情報は、各ルータ２で確定した帯域予約の情報が記録される（詳細な説明については省略する）。また、料金の項目には、料金算出部１６が算出した料金が記録される。
【００３５】
次に、帯域予約管理システム１における一連の処理手順について、図７のフローチャートと、図８〜１０の画面表示例とを用いて説明する。
【００３６】
図８は、その帯域予約情報を入力するための入力画面の表示例である。クライアント４ａのユーザは、表示された項目にしたがって、接続先の情報（接続先のＩＰアドレス）、利用日、開始時刻、終了時刻、予約帯域幅、許容帯域幅、方向性を入力する。予約帯域幅と許容帯域幅とは、図８に示すように、予め設定された帯域幅から選択されるようにしても良い。
【００３７】
ここで許容帯域幅とは、予約帯域幅で帯域予約ができなかった場合に、クライアント４のユーザの利用目的に耐え得る（許容できる）帯域幅の下限値である。図７の例では、予約帯域幅が３Ｍｂｐｓ、許容帯域幅が１．５Ｍｂｐｓとなっているので、仮に８Ｍｂｐｓで予約できなかった場合は、８Ｍｂｐｓより狭い帯域幅で予約処理を繰り返し、１．５Ｍｂｐｓまでで帯域予約が可能であれば自動的に予約を行う。
【００３８】
まず、帯域予約の要求元から帯域予約情報が入力されると（ステップＳ０１）、クライアント４ａ（Ｓｏｕｒｃｅ）は帯域予約要求パケットを生成し、ルーティング機能６に送信する（ステップＳ０２）。帯域予約要求パケットには、帯域予約に関する要求であることを示す情報（ヘッダ）と、Ｓｏｕｒｃｅアドレス、Ｄｅｓｔｉｎａｔｉｏｎアドレス、日付、開始時刻、終了時刻、帯域幅、方向性、フラグの各情報を含む。この帯域予約要求パケットのフラグの値が０の場合は、帯域予約要求が継続中であることを示し、フラグの値が−１の場合は、そのパケットに記述されている帯域予約要求が、いずれかのルータ２で確保できなかったことを示す（エラーパケット）。また、フラグの値が１の場合は、帯域予約要求が確定したことを示す（了承パケット）。
【００３９】
ルーティング機能６（またはルータ２）の帯域予約プロセス７は、帯域予約要求パケットを受信すると（ステップＳ０３）、その帯域予約要求パケットに記述されている内容を判別し、受付制御９に帯域予約が可能であるか判定を行うよう指示を出す。受付制御９は、帯域予約テーブル１０を参照し（ステップＳ０４）、帯域予約が可能であるか判定を行う（ステップＳ０５）。判定の結果、帯域予約が可能であれば、受付制御９は、帯域予約テーブル１０にその帯域予約要求を仮予約する（ステップＳ０６）。仮予約の後、帯域予約プロセス７は、後段のルータ２へ帯域予約要求パケットを送信する（ステップＳ０７）。
【００４０】
また、判定の結果、帯域予約が不可能であれば、帯域予約プロセス７は、別の径路を検索する（ステップＳ０８）。そして別の径路が構築可能であるか判定し（ステップＳ０９）、別の径路が構築可能である場合は、その径路で帯域予約が可能であるか判定を行う処理（ステップＳ０５）に戻る。別の径路が構築不可能である場合は、帯域予約プロセス７は、帯域予約要求パケットのフラグの値を−１に変更してエラーパケットを作成し、前段のルータ２またはクライアント４ａへ送信する（ステップＳ１０）。
【００４１】
上記ステップＳ０３からステップＳ１０までの処理は、クライアント４ａのルーティング機能６で行われた後、Ｓｏｕｒｃｅ−Ｄｅｓｔｉｎａｔｉｏｎ間に介在するルータ２で同様に繰り返され、最終的にクライアント４ｂ（Ｄｅｓｔｉｎａｔｉｏｎ）のルーティング機能６に到達する。
【００４２】
なお、各ルータ２は、帯域予約要求パケットを受信するたびに、そのルータ２のＩＰアドレスを帯域予約要求パケットに追記し、通信径路を記録する。エラーパケット、了承パケットは、その記録されたＩＰアドレスを参照することによって、帯域予約要求パケットが通った径路で返送される。エラーパケットを受信したルータ２は、そのエラーパケットに記述されている帯域予約要求を帯域予約テーブル１０から検索し、その帯域予約要求のフラグを０に変更し、無効状態にする。
【００４３】
また、ルーティング機能６において、別径路の検索は、そのクライアント４にネットワークアダプタが複数存在する場合に行われる処理である。
【００４４】
次に、クライアント４ｂが有するルーティング機能６の帯域予約プロセス７は、帯域予約要求パケットを受信すると（ステップＳ１１）、その帯域予約要求パケットに記述されている内容を判別し、受付制御９に帯域予約が可能であるか判定を行うよう指示を出す。受付制御９は、帯域予約テーブル１０を参照し（ステップＳ１２）、帯域予約が可能であるか判定を行う（ステップＳ１３）。判定の結果、帯域予約が可能であれば、受付制御９は、帯域予約テーブル１０にその帯域予約要求を登録する（ステップＳ１４）。この時、帯域予約テーブル１０のフラグの値は１であり、予約確定となる。
【００４５】
次に、帯域予約プロセス７は、帯域予約要求パケットのフラグの値を１に変更して了承パケットを作成し、前段のルータ２またはクライアント４、および管理サーバ３へ送信する（ステップＳ１５）。
【００４６】
なお、ステップＳ１３で判定の結果、帯域予約が不可能であれば、帯域予約プロセス７は、帯域予約要求パケットのフラグの値を−１に変更してエラーパケットを作成し、前段のルータ２またはクライアント４へ送信する（ステップＳ１６）。
【００４７】
了承パケットは、帯域予約要求パケットが通った径路で返送される。各ルータ２の帯域予約プロセス７は、了承パケットを受信すると（ステップＳ１７）、その了承パケットに記述されている帯域予約要求を帯域予約テーブル１０から検索するよう受付制御９に指示を出し、受付制御９は、該当する帯域予約要求のフラグを１に変更し、予約確定状態にする（ステップＳ１８）。
【００４８】
管理サーバ３では、了承パケットを受信すると帯域管理データベース１７に予約情報を登録し料金を算出する。
【００４９】
まず、パケット送受信部１４は、了承パケットを受信すると（ステップＳ１９）、その了承パケットに記述されている内容を判別し、帯域管理データベース１７に登録する項目毎に情報を抽出し、データベース管理部１５に転送する（ステップＳ１９）。
【００５０】
データベース管理部１５は、パケット送受信部１４から転送された各種情報を帯域管理データベース１７に記録する（ステップＳ２０）。また、データベース管理部１５は、料金算出のために必要な情報を料金算出部１６へ転送する。
【００５１】
料金算出部１６は、データベース管理部１５から転送された各種情報を基に、料金を算出し（ステップＳ２１）、帯域管理データベース１７に記録する。本実施形態では、料金を算出する式は、
料金＝帯域幅×｛終了時刻−開始時刻（単位：時間）｝×方向性
ただし、１Ｍｂｐｓあたり１００円、方向性については、双方向は２、上りまたは下りは１として計算している。例えば、図６のシーケンス番号１番の予約要求では、
【００５２】
そして、パケット送受信部１４は、データベース管理部１５を介して料金情報を取得し、クライアント４ａへ送信する。
【００５３】
クライアント４ａは、了承パケットを受信し（ステップＳ２２）、管理サーバ３から料金情報を受信すると（ステップＳ２３）、帯域予約完了の旨をクライアント４ｂへ送信する（ステップＳ２４）。クライアント４ｂでは、帯域予約完了の旨を受信することによって、帯域が予約されたことを得ることができる（ステップＳ２５）。
【００５４】
クライアント４ａは、エラーパケットを受信すると、予約帯域幅より狭い帯域幅で、再度予約処理を行う。図８の例では、予約帯域幅は８Ｍｂｐｓに設定されているが、この８Ｍｂｐｓで帯域予約ができなかった場合、４Ｍｂｐｓ、１．５Ｍｂｐｓ、１Ｍｂｐｓ…６４ｋｂｐｓまで、予約帯域幅より狭い帯域幅から予め設定された下限の帯域幅まで、帯域予約ができるまで、繰り返し予約処理を行う。
【００５５】
クライアント４は、エラーパケットを受信すると（ステップＳ２６）、エラーパケットに記述されている帯域幅より狭い帯域幅に設定可能であるか判定し（ステップＳ２７）、エラーパケットに記述されている帯域幅より狭い帯域幅に設定可能である場合、その狭い帯域幅で帯域予約要求パケットを生成し、再度、帯域予約要求を行うステップＳ０２の処理に戻る（ステップＳ２８）。
【００５６】
ステップＳ２７で、下限の帯域幅で帯域予約ができなかった場合は、クライアント４ａユーザへ帯域予約ができなかった旨のエラーメッセージを通知する（ステップＳ２９）。
【００５７】
このように、予約帯域幅で帯域予約ができなかった場合には、自動的により狭い帯域幅で予約処理を繰り返す。図９は、予約帯域幅を８Ｍｂｐｓに設定したが８Ｍｂｐｓでは帯域予約ができず、４Ｍｂｐｓで帯域予約が確定した場合の画面表示例である。本実施形態では、帯域が確保された時点で、自動的に予約を確定させているが、図１０に示すように、予約帯域幅で帯域予約ができなかった場合、または、許容帯域幅より狭い帯域幅で予約処理を行う場合は、仮予約であることを示すフラグ値を帯域予約要求パケットに記録するようにして、予約可能な最大帯域幅をクライアント４ａに通知し、確認を促すようにしても良い。
【００５８】
具体的には、ステップＳ２８で仮予約であることを示すフラグ値を帯域予約要求パケットに設定し、ステップＳ２２で了承パケットを受信した時に、クライアント４ａユーザに確認を促し、仮予約中の帯域幅で良ければ、フラグ値を０に設定し、再度、帯域予約要求パケットを送信する。この場合、最大帯域幅で仮予約状態にしておくことによって、後からされた帯域予約要求に帯域を確保されてしまうことを防ぐことができる。
【００５９】
なお、本実施形態においては、帯域予約の要求元（クライアント４ａ）へ料金情報を送信するようになっているが、これに限定されるものではない。帯域管理データベース１７に料金情報の送信先を登録し、料金情報を送信する度にその送信先を参照するようにしてもよい。
【００６０】
また、本実施形態においては、ルータ２がエラーパケットを受信すると、フラグを変更して仮予約を解除するようにしているが、フラグを変更する前に、同じ帯域予約要求の内容で別の経路で帯域予約できるか検索を行うようにしても良い。この場合、別の径路で帯域予約できる場合は、帯域予約プロセス７は、エラーパケットのフラグを変更することによって帯域予約要求パケットを再生成し、後段のルータ２へ送信する。
【００６１】
また、本実施形態においては、クライアント４ａ（Ｓｏｕｒｃｅ）側から順にクライアント４ｂ（Ｄｅｓｔｉｎａｔｉｏｎ）側へ帯域予約が行われるが、これに限定されるものではない。一旦、クライアント４ａからクライアント４ｂへ帯域予約要求パケットを送信することによって、通信径路を確定した後、クライアント４ｂ側からクライアント４ａ側へ、確定した通信径路を逆向きに辿りつつ、ルータ２毎に帯域予約を行うようにしても良い。この場合、途中で帯域予約ができなかった場合は、クライアント４ａから別の径路でクライアント４ｂへ帯域予約要求パケットを再送信し、順次、逆向きに辿りつつ、ルータ２毎に帯域予約を行う。
【００６２】
また、本実施形態においては、帯域予約の要求元は確保された帯域を利用するクライアント４となっているが、これに限定されるものではない。任意の端末から、特定の２つのクライアント４を指定することによって、それらクライアント４間の通信回線５の帯域を予約するようにしても良い。さらに、この場合、料金情報は帯域予約を要求した端末に送信するようにしても良い。
【００６３】
また、本発明においては、ルータとは、広義の意味で通信回線を接続する機器のことを指し、一般的にルータと呼ばれるものに限定されず、ゲートウェイ等でも良い。
【００６４】
また、確保された帯域をどのように利用するかはクライアント４ユーザに委ねられる。例えばテレビ会議に利用する場合では、８Ｍｂｐｓで帯域予約できれば、ＤＶＤビデオ程度の画質で映像を配信することができ、１．５Ｍｂｐｓで帯域予約されても、ＶＨＳ標準程度の画質で映像を配信することができる。また、１２８ｋｂｐｓで帯域予約されても、音声だけならＭＰ３形式（ＭＰＧＥ−１ Ａｕｄｉｏ Ｌａｙｅｒ−３）で十分クリアな音声を配信することができる。
【００６５】
さらに映画配信等では、映像の圧縮形式やビットレートに応じて、確保された帯域幅で、複数本の映像を同時に配信することも可能である。例えば、８Ｍｂｐｓで帯域予約できれば、ＭＰＥＧ−１形式の映像であれば、５本程度は配信することができる。
【００６６】
【発明の効果】
以上説明したように、本発明によれば、帯域を確保する開始時刻と終了時刻を持って予約を行うので、ネットワークの混雑時においても安定したスループットを確実に得ることができ、ＱｏＳを保証することができる。
【００６７】
また、要求された帯域幅で予約ができなかった場合、より狭い帯域幅で予約処理を繰り返すことによって、要求された帯域幅よりも狭い帯域幅ではあるが、開始時刻と終了時刻を持って帯域を予約するので、より確実にＱｏＳを保証することができる。
【図面の簡単な説明】
【図１】帯域予約管理システムの構成図である。
【図２】ルータの機能ブロック図である。
【図３】クライアントが有するルーティング機能の機能ブロック図である。
【図４】帯域予約テーブルの構成と、記録される情報の例を示す図である。
【図５】管理サーバの機能ブロック図である。
【図６】帯域管理データベースが有するデータテーブルの構成を示す図である。
【図７】帯域予約管理システムにおける一連の処理手順を示すフローチャートである。
【図８】帯域予約情報を入力するための入力画面の表示例である。
【図９】帯域予約が確定した場合の画面表示例である。
【図１０】帯域予約が確定した場合の画面表示例である。
【符号の説明】
１ 帯域予約管理システム
２ ルータ
３ 管理サーバ
４ クライアント
５ 通信回線
６ ルーティング機能
７ 帯域予約プロセス
８ ポリシー制御
９ 受付制御
１０ 帯域予約テーブル
１１ ルーティングプロセス
１２ パケットクラス分け
１３ パケットスケジューラ
１４ パケット送受信部
１５ データベース管理部
１６ 料金算出部
１７ 帯域管理データベース
Claims (2)
- 特定端末間の通信回線の帯域予約を行い、その予約情報を管理する帯域予約管理システムであって、
前記特定端末間の通信回線の帯域を予約するために、帯域幅、予約開始時刻、および予約終了時刻を含む帯域予約要求を発信する帯域予約要求手段と、
当該帯域予約要求を受信すると、当該帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、前記通信回線の帯域予約を行い、さらに当該予約開始時刻から当該予約終了時刻の間は、当該帯域幅で前記通信回線を接続する回線接続手段と、
前記特定端末間の通信回線上に存在する任意の前記回線接続手段において個々に帯域予約が行われ、当該帯域予約要求に合致する前記特定端末間の通信回線の帯域予約が確立した時点で、その予約情報を発信する予約情報発信手段と、
前記予約情報に応じて、帯域予約された当該通信回線の使用料を算出する料金算出手段と、
を備えることを特徴とする帯域予約管理システム。 - 前記帯域予約要求手段は、前記回線接続手段において当該帯域幅で帯域予約できなかった場合、当該帯域幅より狭い帯域幅で帯域予約要求を発信することを特徴とする請求項１に記載の帯域予約管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002240693A JP2004080612A (ja) | 2002-08-21 | 2002-08-21 | 帯域予約管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002240693A JP2004080612A (ja) | 2002-08-21 | 2002-08-21 | 帯域予約管理システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004080612A true JP2004080612A (ja) | 2004-03-11 |
Family
ID=32023413
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002240693A Pending JP2004080612A (ja) | 2002-08-21 | 2002-08-21 | 帯域予約管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004080612A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006319849A (ja) * | 2005-05-16 | 2006-11-24 | Kddi Corp | エンドユーザ間帯域保証通信システム |
| WO2008062621A1 (fr) * | 2006-11-20 | 2008-05-29 | Sharp Kabushiki Kaisha | Système de communication à transmission en continu |
| JP2011040053A (ja) * | 2009-07-15 | 2011-02-24 | Toshiba Corp | 医用画像表示システム及び医用画像通信方法 |
| JP2012100355A (ja) * | 2012-02-16 | 2012-05-24 | Sharp Corp | ストリーミング通信システムおよびストリーミング通信装置 |
-
2002
- 2002-08-21 JP JP2002240693A patent/JP2004080612A/ja active Pending
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006319849A (ja) * | 2005-05-16 | 2006-11-24 | Kddi Corp | エンドユーザ間帯域保証通信システム |
| WO2008062621A1 (fr) * | 2006-11-20 | 2008-05-29 | Sharp Kabushiki Kaisha | Système de communication à transmission en continu |
| US8228945B2 (en) | 2006-11-20 | 2012-07-24 | Sharp Kabushiki Kaisha | Streaming communication system |
| JP2011040053A (ja) * | 2009-07-15 | 2011-02-24 | Toshiba Corp | 医用画像表示システム及び医用画像通信方法 |
| US8918481B2 (en) | 2009-07-15 | 2014-12-23 | Kabushiki Kaisha Toshiba | Medical image display system and medical image communication method |
| JP2012100355A (ja) * | 2012-02-16 | 2012-05-24 | Sharp Corp | ストリーミング通信システムおよびストリーミング通信装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2000032048A (ja) | ネットワーク装置 | |
| ES2557892T3 (es) | Control de admisión y planificación de tráfico de datos por paquetes | |
| EP1841167B1 (en) | Relay apparatus for Selecting a Multimedia Type of a Communication | |
| US8773998B2 (en) | Technique for reducing resources allocated to an existing reservation in a data network | |
| JP2007507931A (ja) | 帯域内シグナリングメカニズムにおける双方向ＱｏＳ予約 | |
| JP2004508739A (ja) | ネットワークにおける価格設定ベースのサービス品質（ＰＱｏＳ）コントロールのためのシステム | |
| US20150127843A1 (en) | Multiple Pathway Session Setup to Support QOS Services | |
| Schelén et al. | Resource sharing in advance reservation agents | |
| WO2004064325A1 (fr) | Systeme et procede de distribution des ressources dans un reseau de communications | |
| JP2002319970A (ja) | 通信ネットワーク | |
| JP2005502275A (ja) | Ｉｐ通信網における方法及び装置 | |
| JP2003158543A (ja) | 中継装置及び中継方法 | |
| EP1803263A1 (fr) | Procede et dispositif de controle d'admission a un service a qualite de service garantie dans un reseau mpls | |
| JP2003521199A (ja) | 通信ネットワークの方法、サーバ及び構成 | |
| MX2007011168A (es) | Metodo y aparato para implementar control de admision de flujo de trafico basado en trayectoria en una red de malla inalambrica. | |
| US20070217340A1 (en) | QoS information notification method, communication apparatus and inter-domain signaling apparatus for transmitting QoS information over a multi-domain network | |
| WO2007082448A1 (fr) | Procédé de qualité de service (qos) garantie, dispositif de gestion de ressources et système d'accès multi-services | |
| WO2008079915A2 (en) | Reserving resources for data streams in a communication network | |
| Reinhardt | Advance resource reservation and its impact on reservation protocols | |
| JP5496353B2 (ja) | ネットワークリソース管理の方法および配置構成 | |
| JP2003309832A (ja) | テレビ会議予約システムおよびそのシステムに使用する会議予約サーバとネットワーク管理サーバ | |
| JP2004080612A (ja) | 帯域予約管理システム | |
| Norden et al. | DRES: Network resource management using deferred reservations | |
| JP2008085686A (ja) | 予約受付制御システムと方法およびプログラム | |
| JP4199575B2 (ja) | ネットワークシステム，同システムにおけるパス設定方法並びに同システムに用いられるネットワーク管理装置及びネットワーク装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050817 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070419 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070626 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071106 |