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
【課題】特定クライアント間の通信帯域を予約することによって、必要な帯域幅、または可能な限り広い帯域幅を、必要な時間帯だけ確保し、さらに、確保した帯域幅に応じて課金する帯域予約管理システムを提供する。
【解決手段】クライアント4が帯域予約要求パケットを発信すると、その帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、通信回線の帯域予約を行い、さらに予約開始時刻から予約終了時刻の間は、帯域幅で通信回線を接続し、特定クライアント4間のルーティング機能6およびルータ2において個々に帯域予約が行われ、帯域予約要求に合致する特定クライアント4間の通信回線が確立予約された時点で予約情報を発信するルーティング機能6またはルータ2と、予約情報に基づいてクライアント4に対して料金情報を発信する管理サーバ3とを備える。
【選択図】 図7
【解決手段】クライアント4が帯域予約要求パケットを発信すると、その帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、通信回線の帯域予約を行い、さらに予約開始時刻から予約終了時刻の間は、帯域幅で通信回線を接続し、特定クライアント4間のルーティング機能6およびルータ2において個々に帯域予約が行われ、帯域予約要求に合致する特定クライアント4間の通信回線が確立予約された時点で予約情報を発信するルーティング機能6またはルータ2と、予約情報に基づいてクライアント4に対して料金情報を発信する管理サーバ3とを備える。
【選択図】 図7
Description
【0001】
【発明の属する技術分野】
本発明は、特に広帯域幅を必要とする情報通信において、特定端末間の通信で行われる通信回線の帯域予約の予約情報を管理する帯域予約管理システムに関する。
【0002】
【従来の技術】
近年、ブロードバンドの普及に伴い動画配信やテレビ会議等、ナローバンドでは不可能だったサービスが相次いで登場している。そのため、ブロードバンドが浸透したネットワーク環境下においては、ユーザ間、またはユーザとサーバ間の通信肥大化が予想され、QoS (Quality of Service)維持のためにバックボーン回線の増強等の対策が不可欠となる。
【0003】
【発明が解決しようとする課題】
ただバックボーン回線の増強は実際には多くの費用と時間がかかるため、通信品質が維持されないままサービスが展開されることも多いに予想される。また、従来のIPネットワークはコネクションレス・ベストエフォート型ネットワークであり、リアルタイム性が要求される情報伝達などに対して十分なQoSを保証できなかった。
【0004】
そこで、端末間のQoSを保証するために、IETF(Internet EngineeringTask Force)ではRSVP(Reservation Protocol) などの帯域予約プロトコルが提案されている。
【0005】
このRSVPは、帯域予約要求をすべての経路に伝達することによって帯域予約を実現しており、ソフトステートと呼ばれる構造を持ち、帯域予約状態の生存時間を限定している。予約状態を維持するには、送信側からPathメッセージを、受信側からResvメッセージを定期的に送信する必要があるが、予約状態の生存時間を過ぎると、予約状態は自動的に削除される。
【0006】
この機能により、ネットワークがすでに使われなくなった帯域予約によって無駄に使用されることはない。しかし、要求された全ての帯域予約要求を保証するというものではない。
【0007】
そこで上記の問題を解決するための手法として、電気通信大学の池邉隆(他3名)によって「IPネットワークにおける待時式帯域予約通信方式」が提案されている。
【0008】
この待時式帯域予約通信方式とは、帯域予約により予約可能な通信帯域が枯渇あるいは一定の負荷率に達した場合、それ以降の帯域予約通信要求をそれぞれのルータが持つ順番待ちリストに入れ順番待ちを行い、帯域が予約可能になった時に発行順序に(FIFOで)帯域を予約する方式である。
【0009】
この待時式帯域予約通信方式では、予約要求を「順番待ちリスト」に登録することにより、有限時間内に帯域予約を行うことができるが、特定の時刻に帯域を確保することができるかどうかは全く保障されない。そのためテレビ会議等、一定時間内に確実に帯域予約を行う必要があるサービスに対しては、QoSを保証することができない。
【0010】
また、帯域予約を行う時間を指定する方式として、特開平9−261345号公報に「通信網資源予約方式」が開示されている。
【0011】
この通信網資源予約方式では、特開平9−261345号公報の段落0038に、帯域予約要求メッセージに記述されるパラメータとして「使用開始時刻、使用終了時刻、所要帯域」が上げられており、この使用開始時刻と使用終了時刻との間で帯域予約を行うというものである。
【0012】
しかしながら、この通信網資源予約方式では、使用開始時刻と使用終了時刻との間で所要帯域の予約ができなかった場合、帯域予約要求に対してどの程度のQoSが保証されるかについては記載が無く、全く不明である。そのためテレビ会議等、一定時間内に確実に帯域予約を行う必要があるサービスに対しては、この通信網資源予約方式ではQoSを保証することができない。
【0013】
本発明は上記事情に鑑み、動画配信やテレビ会議等、必要な時間帯のみ帯域を確保したい要求に応じて、帯域のスケジューリング、およびルーティング制御によりクライアント間の通信帯域を予約することによって、必要な帯域幅、または可能な限り広い帯域幅を、必要な時間帯だけ確保し、さらに、確保した帯域幅に応じて課金する帯域予約管理システムを提供することを目的とする。
【0014】
【課題を解決するための手段】
上記目的を達成するために、請求項1に記載の発明である帯域予約管理システムは、特定端末間の通信回線の帯域予約を行い、その予約情報を管理する帯域予約管理システムであって、前記特定端末間の通信回線の帯域を予約するために、帯域幅、予約開始時刻、および予約終了時刻を含む帯域予約要求を発信する帯域予約要求手段と、当該帯域予約要求を受信すると、当該帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、前記通信回線の帯域予約を行い、さらに当該予約開始時刻から当該予約終了時刻の間は、当該帯域幅で前記通信回線を接続する回線接続手段と、前記特定端末間の通信回線上に存在する任意の前記回線接続手段において個々に帯域予約が行われ、当該帯域予約要求に合致する前記特定端末間の通信回線の帯域予約が確立した時点で、その予約情報を発信する予約情報発信手段と、前記予約情報に応じて、帯域予約された当該通信回線の使用料を算出する料金算出手段とを備えることを特徴とする。
【0015】
請求項1の発明によれば、帯域を確保する開始時刻と終了時刻を持って予約を行うので、ネットワークの混雑時においても安定したスループットを確実に得ることができ、QoSを保証することができる。
【0016】
また、請求項2に記載の発明である帯域予約管理システムは、請求項1に記載の帯域予約管理システムであって、前記帯域予約要求手段は、前記回線接続手段において当該帯域幅で帯域予約できなかった場合、当該帯域幅より狭い帯域幅で帯域予約要求を発信することを特徴とする。
【0017】
請求項2の発明によれば、要求された帯域幅で予約ができなかった場合、より狭い帯域幅で予約処理を繰り返すことによって、要求された帯域幅よりも狭い帯域幅ではあるが、開始時刻と終了時刻を持って帯域を予約するので、より確実にQoSを保証することができる。
【0018】
【発明の実施の形態】
本発明の実施形態を、図1〜図10に基づいて説明する。
【0019】
まず、帯域予約管理システム1の構成について、図1〜図6に基づいて説明する。
【0020】
本実施形態における帯域予約管理システム1は、図1に示すように、ルータ2a,b,c…n,zと、管理サーバ3と、ルーティング機能6を有するクライアント4a,b…と、それらを相互に接続する通信回線5とから構成される。図1においては、接続元(Source)と接続先(Destination)のクライアント4として、クライアント4a,bの2つしか示していないが、それぞれのルータ2a,b,c…n,zには複数のクライアント4が接続される。
【0021】
また、クライアント4は、ルータ2a,b,c…n,zを介して管理サーバ3に接続される。このルータ2a,b,c…n,zと管理サーバ3を接続する通信回線5(図中、破線部)は、両者を直接接続する回線である必要は無い。クライアント4と管理サーバ3との間に何らかのルータ2a,b,c…n,zや他の通信回線5が介在しても、両者間でパケット交換可能であれば良い。
【0022】
図2は、ルータ2の機能ブロック図であり、図3は、クライアント4が有するルーティング機能6の機能ブロック図である。ルータ2は、図2に示すように、帯域予約プロセス7、ポリシー制御8、受付制御9、帯域予約テーブル10、ルーティングプロセス11、パケットクラス分け12、パケットスケジューラ13を有する。また、ルーティング機能6は、図3に示すように、帯域予約プロセス7、ポリシー制御8、受付制御9、帯域予約テーブル10、パケットクラス分け12、パケットスケジューラ13を有し、上位のレイヤーから帯域予約要求の命令と送信するデータを受信する。
【0023】
帯域予約プロセス7は、クライアント4、または前後段のルータ2から送信された帯域予約要求パケット、エラーパケット、および了承パケットを受け取ると、それらパケットに記述されている内容を判別し、その内容に応じて各機能部に対して動作指示を行う機能を有する。
【0024】
また、受付制御9は、クライアント4、または前段のルータ2から送信された帯域予約要求を満たすのに十分なリソースを持っているか否か、帯域予約テーブル10を参照し、判断する機能と、十分なリソースを持っていると判断した場合に、その帯域予約要求を帯域予約テーブル10に仮予約し、後段のルータ2から帯域予約の了承情報を受信すると、仮予約を解除し、帯域予約要求を帯域予約テーブル10に本登録する機能を有する。また、受付制御9は、帯域予約要求に指定された時刻に、帯域予約プロセス7に帯域予約および開放を指示する機能を有する。
【0025】
また、ポリシー制御8は、受信者が帯域予約できる権限を持っているか否かを判断する機能を有し、パケットスケジューラ13、ルーティングプロセス11、パケットクラス分け12は、それぞれ帯域予約プロセス7に指示に従ってデータパケットの流れを制御する機能、帯域が予約できなかった場合に、ルーティングテーブルを参照し(図示しない)、別の径路を検索する機能を有するが、その制御手法ついては従来のルータ2が有する機能と同じなので、詳細な説明については省略する。
【0026】
図4は、帯域予約テーブル10の構成と、記録される情報の例を示したものである。帯域予約テーブル10は、シーケンス番号、Source、Destination、データ方向、年月日、開始時刻、終了時刻、帯域幅、およびフラグの項目を有する。
【0027】
Source(送信元)とDestination(送信先)の項目には、帯域を確保する2つのクライアント4a、bのIPアドレスがそれぞれ記録される。また、データ方向の項目には、帯域を確保する通信回線5の方向が、例えば、Source側を基準として、「上り」、「下り」、「双方向」のいずれかが記録される。
【0028】
また、年月日、開始時刻、終了時刻の項目には、帯域を確保する日付、および時刻の情報が記録され、帯域幅の項目には、確保する帯域幅が記録される。
【0029】
また、フラグの項目には通信回線5の確保の状態に応じて、決められた値が記録される。帯域予約テーブル10のフラグの値が1の場合は、通信回線5の予約が確定している状態、フラグの値が−1の場合は、仮予約の状態、フラグの値が0の場合は、その予約が無効(または終了)の状態であることを示す。なお、無効(または終了)の場合は、記憶容量に応じて順次削除される。
【0030】
図5は、管理サーバ3の機能ブロック図である。図5に示すように、本実施形態における管理サーバ3は、パケット送受信部14、データベース管理部15、料金算出部16、および帯域管理データベース17を有する。
【0031】
パケット送受信部14は、ルータ2からの了承パケットを受信し、帯域予約の要求元へ料金情報を有するパケットを送信する機能を有する。
【0032】
また、データベース管理部15は、パケット送受信部14が受信した了承パケットに記述されている内容を判別し、その内容を帯域管理データベース17に記録する機能を有する。
【0033】
また、料金算出部16は、データベース管理部15が判別した内容に応じて、帯域予約に課金される料金を算出する機能を有する。
【0034】
図6は、帯域管理データベース17が有するデータテーブルの構成と、記録される情報の例を示したものである。帯域管理データベース17は、シーケンス番号、Source、Destination、データ方向、年月日、開始時刻、終了時刻、帯域幅、および料金の項目を有するデータテーブルを備える。料金以外の各項目に記録される情報は、各ルータ2で確定した帯域予約の情報が記録される(詳細な説明については省略する)。また、料金の項目には、料金算出部16が算出した料金が記録される。
【0035】
次に、帯域予約管理システム1における一連の処理手順について、図7のフローチャートと、図8〜10の画面表示例とを用いて説明する。
【0036】
図8は、その帯域予約情報を入力するための入力画面の表示例である。クライアント4aのユーザは、表示された項目にしたがって、接続先の情報(接続先のIPアドレス)、利用日、開始時刻、終了時刻、予約帯域幅、許容帯域幅、方向性を入力する。予約帯域幅と許容帯域幅とは、図8に示すように、予め設定された帯域幅から選択されるようにしても良い。
【0037】
ここで許容帯域幅とは、予約帯域幅で帯域予約ができなかった場合に、クライアント4のユーザの利用目的に耐え得る(許容できる)帯域幅の下限値である。図7の例では、予約帯域幅が3Mbps、許容帯域幅が1.5Mbpsとなっているので、仮に8Mbpsで予約できなかった場合は、8Mbpsより狭い帯域幅で予約処理を繰り返し、1.5Mbpsまでで帯域予約が可能であれば自動的に予約を行う。
【0038】
まず、帯域予約の要求元から帯域予約情報が入力されると(ステップS01)、クライアント4a(Source)は帯域予約要求パケットを生成し、ルーティング機能6に送信する(ステップS02)。帯域予約要求パケットには、帯域予約に関する要求であることを示す情報(ヘッダ)と、Sourceアドレス、Destinationアドレス、日付、開始時刻、終了時刻、帯域幅、方向性、フラグの各情報を含む。この帯域予約要求パケットのフラグの値が0の場合は、帯域予約要求が継続中であることを示し、フラグの値が−1の場合は、そのパケットに記述されている帯域予約要求が、いずれかのルータ2で確保できなかったことを示す(エラーパケット)。また、フラグの値が1の場合は、帯域予約要求が確定したことを示す(了承パケット)。
【0039】
ルーティング機能6(またはルータ2)の帯域予約プロセス7は、帯域予約要求パケットを受信すると(ステップS03)、その帯域予約要求パケットに記述されている内容を判別し、受付制御9に帯域予約が可能であるか判定を行うよう指示を出す。受付制御9は、帯域予約テーブル10を参照し(ステップS04)、帯域予約が可能であるか判定を行う(ステップS05)。判定の結果、帯域予約が可能であれば、受付制御9は、帯域予約テーブル10にその帯域予約要求を仮予約する(ステップS06)。仮予約の後、帯域予約プロセス7は、後段のルータ2へ帯域予約要求パケットを送信する(ステップS07)。
【0040】
また、判定の結果、帯域予約が不可能であれば、帯域予約プロセス7は、別の径路を検索する(ステップS08)。そして別の径路が構築可能であるか判定し(ステップS09)、別の径路が構築可能である場合は、その径路で帯域予約が可能であるか判定を行う処理(ステップS05)に戻る。別の径路が構築不可能である場合は、帯域予約プロセス7は、帯域予約要求パケットのフラグの値を−1に変更してエラーパケットを作成し、前段のルータ2またはクライアント4aへ送信する(ステップS10)。
【0041】
上記ステップS03からステップS10までの処理は、クライアント4aのルーティング機能6で行われた後、Source−Destination間に介在するルータ2で同様に繰り返され、最終的にクライアント4b(Destination)のルーティング機能6に到達する。
【0042】
なお、各ルータ2は、帯域予約要求パケットを受信するたびに、そのルータ2のIPアドレスを帯域予約要求パケットに追記し、通信径路を記録する。エラーパケット、了承パケットは、その記録されたIPアドレスを参照することによって、帯域予約要求パケットが通った径路で返送される。エラーパケットを受信したルータ2は、そのエラーパケットに記述されている帯域予約要求を帯域予約テーブル10から検索し、その帯域予約要求のフラグを0に変更し、無効状態にする。
【0043】
また、ルーティング機能6において、別径路の検索は、そのクライアント4にネットワークアダプタが複数存在する場合に行われる処理である。
【0044】
次に、クライアント4bが有するルーティング機能6の帯域予約プロセス7は、帯域予約要求パケットを受信すると(ステップS11)、その帯域予約要求パケットに記述されている内容を判別し、受付制御9に帯域予約が可能であるか判定を行うよう指示を出す。受付制御9は、帯域予約テーブル10を参照し(ステップS12)、帯域予約が可能であるか判定を行う(ステップS13)。判定の結果、帯域予約が可能であれば、受付制御9は、帯域予約テーブル10にその帯域予約要求を登録する(ステップS14)。この時、帯域予約テーブル10のフラグの値は1であり、予約確定となる。
【0045】
次に、帯域予約プロセス7は、帯域予約要求パケットのフラグの値を1に変更して了承パケットを作成し、前段のルータ2またはクライアント4、および管理サーバ3へ送信する(ステップS15)。
【0046】
なお、ステップS13で判定の結果、帯域予約が不可能であれば、帯域予約プロセス7は、帯域予約要求パケットのフラグの値を−1に変更してエラーパケットを作成し、前段のルータ2またはクライアント4へ送信する(ステップS16)。
【0047】
了承パケットは、帯域予約要求パケットが通った径路で返送される。各ルータ2の帯域予約プロセス7は、了承パケットを受信すると(ステップS17)、その了承パケットに記述されている帯域予約要求を帯域予約テーブル10から検索するよう受付制御9に指示を出し、受付制御9は、該当する帯域予約要求のフラグを1に変更し、予約確定状態にする(ステップS18)。
【0048】
管理サーバ3では、了承パケットを受信すると帯域管理データベース17に予約情報を登録し料金を算出する。
【0049】
まず、パケット送受信部14は、了承パケットを受信すると(ステップS19)、その了承パケットに記述されている内容を判別し、帯域管理データベース17に登録する項目毎に情報を抽出し、データベース管理部15に転送する(ステップS19)。
【0050】
データベース管理部15は、パケット送受信部14から転送された各種情報を帯域管理データベース17に記録する(ステップS20)。また、データベース管理部15は、料金算出のために必要な情報を料金算出部16へ転送する。
【0051】
料金算出部16は、データベース管理部15から転送された各種情報を基に、料金を算出し(ステップS21)、帯域管理データベース17に記録する。本実施形態では、料金を算出する式は、
料金=帯域幅×{終了時刻−開始時刻(単位:時間)}×方向性
ただし、1Mbpsあたり100円、方向性については、双方向は2、上りまたは下りは1として計算している。例えば、図6のシーケンス番号1番の予約要求では、
となる。なお料金の算出式は、これに限定されるものではない。
【0052】
そして、パケット送受信部14は、データベース管理部15を介して料金情報を取得し、クライアント4aへ送信する。
【0053】
クライアント4aは、了承パケットを受信し(ステップS22)、管理サーバ3から料金情報を受信すると(ステップS23)、帯域予約完了の旨をクライアント4bへ送信する(ステップS24)。クライアント4bでは、帯域予約完了の旨を受信することによって、帯域が予約されたことを得ることができる(ステップS25)。
【0054】
クライアント4aは、エラーパケットを受信すると、予約帯域幅より狭い帯域幅で、再度予約処理を行う。図8の例では、予約帯域幅は8Mbpsに設定されているが、この8Mbpsで帯域予約ができなかった場合、4Mbps、1.5Mbps、1Mbps…64kbpsまで、予約帯域幅より狭い帯域幅から予め設定された下限の帯域幅まで、帯域予約ができるまで、繰り返し予約処理を行う。
【0055】
クライアント4は、エラーパケットを受信すると(ステップS26)、エラーパケットに記述されている帯域幅より狭い帯域幅に設定可能であるか判定し(ステップS27)、エラーパケットに記述されている帯域幅より狭い帯域幅に設定可能である場合、その狭い帯域幅で帯域予約要求パケットを生成し、再度、帯域予約要求を行うステップS02の処理に戻る(ステップS28)。
【0056】
ステップS27で、下限の帯域幅で帯域予約ができなかった場合は、クライアント4aユーザへ帯域予約ができなかった旨のエラーメッセージを通知する(ステップS29)。
【0057】
このように、予約帯域幅で帯域予約ができなかった場合には、自動的により狭い帯域幅で予約処理を繰り返す。図9は、予約帯域幅を8Mbpsに設定したが8Mbpsでは帯域予約ができず、4Mbpsで帯域予約が確定した場合の画面表示例である。本実施形態では、帯域が確保された時点で、自動的に予約を確定させているが、図10に示すように、予約帯域幅で帯域予約ができなかった場合、または、許容帯域幅より狭い帯域幅で予約処理を行う場合は、仮予約であることを示すフラグ値を帯域予約要求パケットに記録するようにして、予約可能な最大帯域幅をクライアント4aに通知し、確認を促すようにしても良い。
【0058】
具体的には、ステップS28で仮予約であることを示すフラグ値を帯域予約要求パケットに設定し、ステップS22で了承パケットを受信した時に、クライアント4aユーザに確認を促し、仮予約中の帯域幅で良ければ、フラグ値を0に設定し、再度、帯域予約要求パケットを送信する。この場合、最大帯域幅で仮予約状態にしておくことによって、後からされた帯域予約要求に帯域を確保されてしまうことを防ぐことができる。
【0059】
なお、本実施形態においては、帯域予約の要求元(クライアント4a)へ料金情報を送信するようになっているが、これに限定されるものではない。帯域管理データベース17に料金情報の送信先を登録し、料金情報を送信する度にその送信先を参照するようにしてもよい。
【0060】
また、本実施形態においては、ルータ2がエラーパケットを受信すると、フラグを変更して仮予約を解除するようにしているが、フラグを変更する前に、同じ帯域予約要求の内容で別の経路で帯域予約できるか検索を行うようにしても良い。この場合、別の径路で帯域予約できる場合は、帯域予約プロセス7は、エラーパケットのフラグを変更することによって帯域予約要求パケットを再生成し、後段のルータ2へ送信する。
【0061】
また、本実施形態においては、クライアント4a(Source)側から順にクライアント4b(Destination)側へ帯域予約が行われるが、これに限定されるものではない。一旦、クライアント4aからクライアント4bへ帯域予約要求パケットを送信することによって、通信径路を確定した後、クライアント4b側からクライアント4a側へ、確定した通信径路を逆向きに辿りつつ、ルータ2毎に帯域予約を行うようにしても良い。この場合、途中で帯域予約ができなかった場合は、クライアント4aから別の径路でクライアント4bへ帯域予約要求パケットを再送信し、順次、逆向きに辿りつつ、ルータ2毎に帯域予約を行う。
【0062】
また、本実施形態においては、帯域予約の要求元は確保された帯域を利用するクライアント4となっているが、これに限定されるものではない。任意の端末から、特定の2つのクライアント4を指定することによって、それらクライアント4間の通信回線5の帯域を予約するようにしても良い。さらに、この場合、料金情報は帯域予約を要求した端末に送信するようにしても良い。
【0063】
また、本発明においては、ルータとは、広義の意味で通信回線を接続する機器のことを指し、一般的にルータと呼ばれるものに限定されず、ゲートウェイ等でも良い。
【0064】
また、確保された帯域をどのように利用するかはクライアント4ユーザに委ねられる。例えばテレビ会議に利用する場合では、8Mbpsで帯域予約できれば、DVDビデオ程度の画質で映像を配信することができ、1.5Mbpsで帯域予約されても、VHS標準程度の画質で映像を配信することができる。また、128kbpsで帯域予約されても、音声だけならMP3形式(MPGE−1 Audio Layer−3)で十分クリアな音声を配信することができる。
【0065】
さらに映画配信等では、映像の圧縮形式やビットレートに応じて、確保された帯域幅で、複数本の映像を同時に配信することも可能である。例えば、8Mbpsで帯域予約できれば、MPEG−1形式の映像であれば、5本程度は配信することができる。
【0066】
【発明の効果】
以上説明したように、本発明によれば、帯域を確保する開始時刻と終了時刻を持って予約を行うので、ネットワークの混雑時においても安定したスループットを確実に得ることができ、QoSを保証することができる。
【0067】
また、要求された帯域幅で予約ができなかった場合、より狭い帯域幅で予約処理を繰り返すことによって、要求された帯域幅よりも狭い帯域幅ではあるが、開始時刻と終了時刻を持って帯域を予約するので、より確実にQoSを保証することができる。
【図面の簡単な説明】
【図1】帯域予約管理システムの構成図である。
【図2】ルータの機能ブロック図である。
【図3】クライアントが有するルーティング機能の機能ブロック図である。
【図4】帯域予約テーブルの構成と、記録される情報の例を示す図である。
【図5】管理サーバの機能ブロック図である。
【図6】帯域管理データベースが有するデータテーブルの構成を示す図である。
【図7】帯域予約管理システムにおける一連の処理手順を示すフローチャートである。
【図8】帯域予約情報を入力するための入力画面の表示例である。
【図9】帯域予約が確定した場合の画面表示例である。
【図10】帯域予約が確定した場合の画面表示例である。
【符号の説明】
1 帯域予約管理システム
2 ルータ
3 管理サーバ
4 クライアント
5 通信回線
6 ルーティング機能
7 帯域予約プロセス
8 ポリシー制御
9 受付制御
10 帯域予約テーブル
11 ルーティングプロセス
12 パケットクラス分け
13 パケットスケジューラ
14 パケット送受信部
15 データベース管理部
16 料金算出部
17 帯域管理データベース
【発明の属する技術分野】
本発明は、特に広帯域幅を必要とする情報通信において、特定端末間の通信で行われる通信回線の帯域予約の予約情報を管理する帯域予約管理システムに関する。
【0002】
【従来の技術】
近年、ブロードバンドの普及に伴い動画配信やテレビ会議等、ナローバンドでは不可能だったサービスが相次いで登場している。そのため、ブロードバンドが浸透したネットワーク環境下においては、ユーザ間、またはユーザとサーバ間の通信肥大化が予想され、QoS (Quality of Service)維持のためにバックボーン回線の増強等の対策が不可欠となる。
【0003】
【発明が解決しようとする課題】
ただバックボーン回線の増強は実際には多くの費用と時間がかかるため、通信品質が維持されないままサービスが展開されることも多いに予想される。また、従来のIPネットワークはコネクションレス・ベストエフォート型ネットワークであり、リアルタイム性が要求される情報伝達などに対して十分なQoSを保証できなかった。
【0004】
そこで、端末間のQoSを保証するために、IETF(Internet EngineeringTask Force)ではRSVP(Reservation Protocol) などの帯域予約プロトコルが提案されている。
【0005】
このRSVPは、帯域予約要求をすべての経路に伝達することによって帯域予約を実現しており、ソフトステートと呼ばれる構造を持ち、帯域予約状態の生存時間を限定している。予約状態を維持するには、送信側からPathメッセージを、受信側からResvメッセージを定期的に送信する必要があるが、予約状態の生存時間を過ぎると、予約状態は自動的に削除される。
【0006】
この機能により、ネットワークがすでに使われなくなった帯域予約によって無駄に使用されることはない。しかし、要求された全ての帯域予約要求を保証するというものではない。
【0007】
そこで上記の問題を解決するための手法として、電気通信大学の池邉隆(他3名)によって「IPネットワークにおける待時式帯域予約通信方式」が提案されている。
【0008】
この待時式帯域予約通信方式とは、帯域予約により予約可能な通信帯域が枯渇あるいは一定の負荷率に達した場合、それ以降の帯域予約通信要求をそれぞれのルータが持つ順番待ちリストに入れ順番待ちを行い、帯域が予約可能になった時に発行順序に(FIFOで)帯域を予約する方式である。
【0009】
この待時式帯域予約通信方式では、予約要求を「順番待ちリスト」に登録することにより、有限時間内に帯域予約を行うことができるが、特定の時刻に帯域を確保することができるかどうかは全く保障されない。そのためテレビ会議等、一定時間内に確実に帯域予約を行う必要があるサービスに対しては、QoSを保証することができない。
【0010】
また、帯域予約を行う時間を指定する方式として、特開平9−261345号公報に「通信網資源予約方式」が開示されている。
【0011】
この通信網資源予約方式では、特開平9−261345号公報の段落0038に、帯域予約要求メッセージに記述されるパラメータとして「使用開始時刻、使用終了時刻、所要帯域」が上げられており、この使用開始時刻と使用終了時刻との間で帯域予約を行うというものである。
【0012】
しかしながら、この通信網資源予約方式では、使用開始時刻と使用終了時刻との間で所要帯域の予約ができなかった場合、帯域予約要求に対してどの程度のQoSが保証されるかについては記載が無く、全く不明である。そのためテレビ会議等、一定時間内に確実に帯域予約を行う必要があるサービスに対しては、この通信網資源予約方式ではQoSを保証することができない。
【0013】
本発明は上記事情に鑑み、動画配信やテレビ会議等、必要な時間帯のみ帯域を確保したい要求に応じて、帯域のスケジューリング、およびルーティング制御によりクライアント間の通信帯域を予約することによって、必要な帯域幅、または可能な限り広い帯域幅を、必要な時間帯だけ確保し、さらに、確保した帯域幅に応じて課金する帯域予約管理システムを提供することを目的とする。
【0014】
【課題を解決するための手段】
上記目的を達成するために、請求項1に記載の発明である帯域予約管理システムは、特定端末間の通信回線の帯域予約を行い、その予約情報を管理する帯域予約管理システムであって、前記特定端末間の通信回線の帯域を予約するために、帯域幅、予約開始時刻、および予約終了時刻を含む帯域予約要求を発信する帯域予約要求手段と、当該帯域予約要求を受信すると、当該帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、前記通信回線の帯域予約を行い、さらに当該予約開始時刻から当該予約終了時刻の間は、当該帯域幅で前記通信回線を接続する回線接続手段と、前記特定端末間の通信回線上に存在する任意の前記回線接続手段において個々に帯域予約が行われ、当該帯域予約要求に合致する前記特定端末間の通信回線の帯域予約が確立した時点で、その予約情報を発信する予約情報発信手段と、前記予約情報に応じて、帯域予約された当該通信回線の使用料を算出する料金算出手段とを備えることを特徴とする。
【0015】
請求項1の発明によれば、帯域を確保する開始時刻と終了時刻を持って予約を行うので、ネットワークの混雑時においても安定したスループットを確実に得ることができ、QoSを保証することができる。
【0016】
また、請求項2に記載の発明である帯域予約管理システムは、請求項1に記載の帯域予約管理システムであって、前記帯域予約要求手段は、前記回線接続手段において当該帯域幅で帯域予約できなかった場合、当該帯域幅より狭い帯域幅で帯域予約要求を発信することを特徴とする。
【0017】
請求項2の発明によれば、要求された帯域幅で予約ができなかった場合、より狭い帯域幅で予約処理を繰り返すことによって、要求された帯域幅よりも狭い帯域幅ではあるが、開始時刻と終了時刻を持って帯域を予約するので、より確実にQoSを保証することができる。
【0018】
【発明の実施の形態】
本発明の実施形態を、図1〜図10に基づいて説明する。
【0019】
まず、帯域予約管理システム1の構成について、図1〜図6に基づいて説明する。
【0020】
本実施形態における帯域予約管理システム1は、図1に示すように、ルータ2a,b,c…n,zと、管理サーバ3と、ルーティング機能6を有するクライアント4a,b…と、それらを相互に接続する通信回線5とから構成される。図1においては、接続元(Source)と接続先(Destination)のクライアント4として、クライアント4a,bの2つしか示していないが、それぞれのルータ2a,b,c…n,zには複数のクライアント4が接続される。
【0021】
また、クライアント4は、ルータ2a,b,c…n,zを介して管理サーバ3に接続される。このルータ2a,b,c…n,zと管理サーバ3を接続する通信回線5(図中、破線部)は、両者を直接接続する回線である必要は無い。クライアント4と管理サーバ3との間に何らかのルータ2a,b,c…n,zや他の通信回線5が介在しても、両者間でパケット交換可能であれば良い。
【0022】
図2は、ルータ2の機能ブロック図であり、図3は、クライアント4が有するルーティング機能6の機能ブロック図である。ルータ2は、図2に示すように、帯域予約プロセス7、ポリシー制御8、受付制御9、帯域予約テーブル10、ルーティングプロセス11、パケットクラス分け12、パケットスケジューラ13を有する。また、ルーティング機能6は、図3に示すように、帯域予約プロセス7、ポリシー制御8、受付制御9、帯域予約テーブル10、パケットクラス分け12、パケットスケジューラ13を有し、上位のレイヤーから帯域予約要求の命令と送信するデータを受信する。
【0023】
帯域予約プロセス7は、クライアント4、または前後段のルータ2から送信された帯域予約要求パケット、エラーパケット、および了承パケットを受け取ると、それらパケットに記述されている内容を判別し、その内容に応じて各機能部に対して動作指示を行う機能を有する。
【0024】
また、受付制御9は、クライアント4、または前段のルータ2から送信された帯域予約要求を満たすのに十分なリソースを持っているか否か、帯域予約テーブル10を参照し、判断する機能と、十分なリソースを持っていると判断した場合に、その帯域予約要求を帯域予約テーブル10に仮予約し、後段のルータ2から帯域予約の了承情報を受信すると、仮予約を解除し、帯域予約要求を帯域予約テーブル10に本登録する機能を有する。また、受付制御9は、帯域予約要求に指定された時刻に、帯域予約プロセス7に帯域予約および開放を指示する機能を有する。
【0025】
また、ポリシー制御8は、受信者が帯域予約できる権限を持っているか否かを判断する機能を有し、パケットスケジューラ13、ルーティングプロセス11、パケットクラス分け12は、それぞれ帯域予約プロセス7に指示に従ってデータパケットの流れを制御する機能、帯域が予約できなかった場合に、ルーティングテーブルを参照し(図示しない)、別の径路を検索する機能を有するが、その制御手法ついては従来のルータ2が有する機能と同じなので、詳細な説明については省略する。
【0026】
図4は、帯域予約テーブル10の構成と、記録される情報の例を示したものである。帯域予約テーブル10は、シーケンス番号、Source、Destination、データ方向、年月日、開始時刻、終了時刻、帯域幅、およびフラグの項目を有する。
【0027】
Source(送信元)とDestination(送信先)の項目には、帯域を確保する2つのクライアント4a、bのIPアドレスがそれぞれ記録される。また、データ方向の項目には、帯域を確保する通信回線5の方向が、例えば、Source側を基準として、「上り」、「下り」、「双方向」のいずれかが記録される。
【0028】
また、年月日、開始時刻、終了時刻の項目には、帯域を確保する日付、および時刻の情報が記録され、帯域幅の項目には、確保する帯域幅が記録される。
【0029】
また、フラグの項目には通信回線5の確保の状態に応じて、決められた値が記録される。帯域予約テーブル10のフラグの値が1の場合は、通信回線5の予約が確定している状態、フラグの値が−1の場合は、仮予約の状態、フラグの値が0の場合は、その予約が無効(または終了)の状態であることを示す。なお、無効(または終了)の場合は、記憶容量に応じて順次削除される。
【0030】
図5は、管理サーバ3の機能ブロック図である。図5に示すように、本実施形態における管理サーバ3は、パケット送受信部14、データベース管理部15、料金算出部16、および帯域管理データベース17を有する。
【0031】
パケット送受信部14は、ルータ2からの了承パケットを受信し、帯域予約の要求元へ料金情報を有するパケットを送信する機能を有する。
【0032】
また、データベース管理部15は、パケット送受信部14が受信した了承パケットに記述されている内容を判別し、その内容を帯域管理データベース17に記録する機能を有する。
【0033】
また、料金算出部16は、データベース管理部15が判別した内容に応じて、帯域予約に課金される料金を算出する機能を有する。
【0034】
図6は、帯域管理データベース17が有するデータテーブルの構成と、記録される情報の例を示したものである。帯域管理データベース17は、シーケンス番号、Source、Destination、データ方向、年月日、開始時刻、終了時刻、帯域幅、および料金の項目を有するデータテーブルを備える。料金以外の各項目に記録される情報は、各ルータ2で確定した帯域予約の情報が記録される(詳細な説明については省略する)。また、料金の項目には、料金算出部16が算出した料金が記録される。
【0035】
次に、帯域予約管理システム1における一連の処理手順について、図7のフローチャートと、図8〜10の画面表示例とを用いて説明する。
【0036】
図8は、その帯域予約情報を入力するための入力画面の表示例である。クライアント4aのユーザは、表示された項目にしたがって、接続先の情報(接続先のIPアドレス)、利用日、開始時刻、終了時刻、予約帯域幅、許容帯域幅、方向性を入力する。予約帯域幅と許容帯域幅とは、図8に示すように、予め設定された帯域幅から選択されるようにしても良い。
【0037】
ここで許容帯域幅とは、予約帯域幅で帯域予約ができなかった場合に、クライアント4のユーザの利用目的に耐え得る(許容できる)帯域幅の下限値である。図7の例では、予約帯域幅が3Mbps、許容帯域幅が1.5Mbpsとなっているので、仮に8Mbpsで予約できなかった場合は、8Mbpsより狭い帯域幅で予約処理を繰り返し、1.5Mbpsまでで帯域予約が可能であれば自動的に予約を行う。
【0038】
まず、帯域予約の要求元から帯域予約情報が入力されると(ステップS01)、クライアント4a(Source)は帯域予約要求パケットを生成し、ルーティング機能6に送信する(ステップS02)。帯域予約要求パケットには、帯域予約に関する要求であることを示す情報(ヘッダ)と、Sourceアドレス、Destinationアドレス、日付、開始時刻、終了時刻、帯域幅、方向性、フラグの各情報を含む。この帯域予約要求パケットのフラグの値が0の場合は、帯域予約要求が継続中であることを示し、フラグの値が−1の場合は、そのパケットに記述されている帯域予約要求が、いずれかのルータ2で確保できなかったことを示す(エラーパケット)。また、フラグの値が1の場合は、帯域予約要求が確定したことを示す(了承パケット)。
【0039】
ルーティング機能6(またはルータ2)の帯域予約プロセス7は、帯域予約要求パケットを受信すると(ステップS03)、その帯域予約要求パケットに記述されている内容を判別し、受付制御9に帯域予約が可能であるか判定を行うよう指示を出す。受付制御9は、帯域予約テーブル10を参照し(ステップS04)、帯域予約が可能であるか判定を行う(ステップS05)。判定の結果、帯域予約が可能であれば、受付制御9は、帯域予約テーブル10にその帯域予約要求を仮予約する(ステップS06)。仮予約の後、帯域予約プロセス7は、後段のルータ2へ帯域予約要求パケットを送信する(ステップS07)。
【0040】
また、判定の結果、帯域予約が不可能であれば、帯域予約プロセス7は、別の径路を検索する(ステップS08)。そして別の径路が構築可能であるか判定し(ステップS09)、別の径路が構築可能である場合は、その径路で帯域予約が可能であるか判定を行う処理(ステップS05)に戻る。別の径路が構築不可能である場合は、帯域予約プロセス7は、帯域予約要求パケットのフラグの値を−1に変更してエラーパケットを作成し、前段のルータ2またはクライアント4aへ送信する(ステップS10)。
【0041】
上記ステップS03からステップS10までの処理は、クライアント4aのルーティング機能6で行われた後、Source−Destination間に介在するルータ2で同様に繰り返され、最終的にクライアント4b(Destination)のルーティング機能6に到達する。
【0042】
なお、各ルータ2は、帯域予約要求パケットを受信するたびに、そのルータ2のIPアドレスを帯域予約要求パケットに追記し、通信径路を記録する。エラーパケット、了承パケットは、その記録されたIPアドレスを参照することによって、帯域予約要求パケットが通った径路で返送される。エラーパケットを受信したルータ2は、そのエラーパケットに記述されている帯域予約要求を帯域予約テーブル10から検索し、その帯域予約要求のフラグを0に変更し、無効状態にする。
【0043】
また、ルーティング機能6において、別径路の検索は、そのクライアント4にネットワークアダプタが複数存在する場合に行われる処理である。
【0044】
次に、クライアント4bが有するルーティング機能6の帯域予約プロセス7は、帯域予約要求パケットを受信すると(ステップS11)、その帯域予約要求パケットに記述されている内容を判別し、受付制御9に帯域予約が可能であるか判定を行うよう指示を出す。受付制御9は、帯域予約テーブル10を参照し(ステップS12)、帯域予約が可能であるか判定を行う(ステップS13)。判定の結果、帯域予約が可能であれば、受付制御9は、帯域予約テーブル10にその帯域予約要求を登録する(ステップS14)。この時、帯域予約テーブル10のフラグの値は1であり、予約確定となる。
【0045】
次に、帯域予約プロセス7は、帯域予約要求パケットのフラグの値を1に変更して了承パケットを作成し、前段のルータ2またはクライアント4、および管理サーバ3へ送信する(ステップS15)。
【0046】
なお、ステップS13で判定の結果、帯域予約が不可能であれば、帯域予約プロセス7は、帯域予約要求パケットのフラグの値を−1に変更してエラーパケットを作成し、前段のルータ2またはクライアント4へ送信する(ステップS16)。
【0047】
了承パケットは、帯域予約要求パケットが通った径路で返送される。各ルータ2の帯域予約プロセス7は、了承パケットを受信すると(ステップS17)、その了承パケットに記述されている帯域予約要求を帯域予約テーブル10から検索するよう受付制御9に指示を出し、受付制御9は、該当する帯域予約要求のフラグを1に変更し、予約確定状態にする(ステップS18)。
【0048】
管理サーバ3では、了承パケットを受信すると帯域管理データベース17に予約情報を登録し料金を算出する。
【0049】
まず、パケット送受信部14は、了承パケットを受信すると(ステップS19)、その了承パケットに記述されている内容を判別し、帯域管理データベース17に登録する項目毎に情報を抽出し、データベース管理部15に転送する(ステップS19)。
【0050】
データベース管理部15は、パケット送受信部14から転送された各種情報を帯域管理データベース17に記録する(ステップS20)。また、データベース管理部15は、料金算出のために必要な情報を料金算出部16へ転送する。
【0051】
料金算出部16は、データベース管理部15から転送された各種情報を基に、料金を算出し(ステップS21)、帯域管理データベース17に記録する。本実施形態では、料金を算出する式は、
料金=帯域幅×{終了時刻−開始時刻(単位:時間)}×方向性
ただし、1Mbpsあたり100円、方向性については、双方向は2、上りまたは下りは1として計算している。例えば、図6のシーケンス番号1番の予約要求では、
となる。なお料金の算出式は、これに限定されるものではない。
【0052】
そして、パケット送受信部14は、データベース管理部15を介して料金情報を取得し、クライアント4aへ送信する。
【0053】
クライアント4aは、了承パケットを受信し(ステップS22)、管理サーバ3から料金情報を受信すると(ステップS23)、帯域予約完了の旨をクライアント4bへ送信する(ステップS24)。クライアント4bでは、帯域予約完了の旨を受信することによって、帯域が予約されたことを得ることができる(ステップS25)。
【0054】
クライアント4aは、エラーパケットを受信すると、予約帯域幅より狭い帯域幅で、再度予約処理を行う。図8の例では、予約帯域幅は8Mbpsに設定されているが、この8Mbpsで帯域予約ができなかった場合、4Mbps、1.5Mbps、1Mbps…64kbpsまで、予約帯域幅より狭い帯域幅から予め設定された下限の帯域幅まで、帯域予約ができるまで、繰り返し予約処理を行う。
【0055】
クライアント4は、エラーパケットを受信すると(ステップS26)、エラーパケットに記述されている帯域幅より狭い帯域幅に設定可能であるか判定し(ステップS27)、エラーパケットに記述されている帯域幅より狭い帯域幅に設定可能である場合、その狭い帯域幅で帯域予約要求パケットを生成し、再度、帯域予約要求を行うステップS02の処理に戻る(ステップS28)。
【0056】
ステップS27で、下限の帯域幅で帯域予約ができなかった場合は、クライアント4aユーザへ帯域予約ができなかった旨のエラーメッセージを通知する(ステップS29)。
【0057】
このように、予約帯域幅で帯域予約ができなかった場合には、自動的により狭い帯域幅で予約処理を繰り返す。図9は、予約帯域幅を8Mbpsに設定したが8Mbpsでは帯域予約ができず、4Mbpsで帯域予約が確定した場合の画面表示例である。本実施形態では、帯域が確保された時点で、自動的に予約を確定させているが、図10に示すように、予約帯域幅で帯域予約ができなかった場合、または、許容帯域幅より狭い帯域幅で予約処理を行う場合は、仮予約であることを示すフラグ値を帯域予約要求パケットに記録するようにして、予約可能な最大帯域幅をクライアント4aに通知し、確認を促すようにしても良い。
【0058】
具体的には、ステップS28で仮予約であることを示すフラグ値を帯域予約要求パケットに設定し、ステップS22で了承パケットを受信した時に、クライアント4aユーザに確認を促し、仮予約中の帯域幅で良ければ、フラグ値を0に設定し、再度、帯域予約要求パケットを送信する。この場合、最大帯域幅で仮予約状態にしておくことによって、後からされた帯域予約要求に帯域を確保されてしまうことを防ぐことができる。
【0059】
なお、本実施形態においては、帯域予約の要求元(クライアント4a)へ料金情報を送信するようになっているが、これに限定されるものではない。帯域管理データベース17に料金情報の送信先を登録し、料金情報を送信する度にその送信先を参照するようにしてもよい。
【0060】
また、本実施形態においては、ルータ2がエラーパケットを受信すると、フラグを変更して仮予約を解除するようにしているが、フラグを変更する前に、同じ帯域予約要求の内容で別の経路で帯域予約できるか検索を行うようにしても良い。この場合、別の径路で帯域予約できる場合は、帯域予約プロセス7は、エラーパケットのフラグを変更することによって帯域予約要求パケットを再生成し、後段のルータ2へ送信する。
【0061】
また、本実施形態においては、クライアント4a(Source)側から順にクライアント4b(Destination)側へ帯域予約が行われるが、これに限定されるものではない。一旦、クライアント4aからクライアント4bへ帯域予約要求パケットを送信することによって、通信径路を確定した後、クライアント4b側からクライアント4a側へ、確定した通信径路を逆向きに辿りつつ、ルータ2毎に帯域予約を行うようにしても良い。この場合、途中で帯域予約ができなかった場合は、クライアント4aから別の径路でクライアント4bへ帯域予約要求パケットを再送信し、順次、逆向きに辿りつつ、ルータ2毎に帯域予約を行う。
【0062】
また、本実施形態においては、帯域予約の要求元は確保された帯域を利用するクライアント4となっているが、これに限定されるものではない。任意の端末から、特定の2つのクライアント4を指定することによって、それらクライアント4間の通信回線5の帯域を予約するようにしても良い。さらに、この場合、料金情報は帯域予約を要求した端末に送信するようにしても良い。
【0063】
また、本発明においては、ルータとは、広義の意味で通信回線を接続する機器のことを指し、一般的にルータと呼ばれるものに限定されず、ゲートウェイ等でも良い。
【0064】
また、確保された帯域をどのように利用するかはクライアント4ユーザに委ねられる。例えばテレビ会議に利用する場合では、8Mbpsで帯域予約できれば、DVDビデオ程度の画質で映像を配信することができ、1.5Mbpsで帯域予約されても、VHS標準程度の画質で映像を配信することができる。また、128kbpsで帯域予約されても、音声だけならMP3形式(MPGE−1 Audio Layer−3)で十分クリアな音声を配信することができる。
【0065】
さらに映画配信等では、映像の圧縮形式やビットレートに応じて、確保された帯域幅で、複数本の映像を同時に配信することも可能である。例えば、8Mbpsで帯域予約できれば、MPEG−1形式の映像であれば、5本程度は配信することができる。
【0066】
【発明の効果】
以上説明したように、本発明によれば、帯域を確保する開始時刻と終了時刻を持って予約を行うので、ネットワークの混雑時においても安定したスループットを確実に得ることができ、QoSを保証することができる。
【0067】
また、要求された帯域幅で予約ができなかった場合、より狭い帯域幅で予約処理を繰り返すことによって、要求された帯域幅よりも狭い帯域幅ではあるが、開始時刻と終了時刻を持って帯域を予約するので、より確実にQoSを保証することができる。
【図面の簡単な説明】
【図1】帯域予約管理システムの構成図である。
【図2】ルータの機能ブロック図である。
【図3】クライアントが有するルーティング機能の機能ブロック図である。
【図4】帯域予約テーブルの構成と、記録される情報の例を示す図である。
【図5】管理サーバの機能ブロック図である。
【図6】帯域管理データベースが有するデータテーブルの構成を示す図である。
【図7】帯域予約管理システムにおける一連の処理手順を示すフローチャートである。
【図8】帯域予約情報を入力するための入力画面の表示例である。
【図9】帯域予約が確定した場合の画面表示例である。
【図10】帯域予約が確定した場合の画面表示例である。
【符号の説明】
1 帯域予約管理システム
2 ルータ
3 管理サーバ
4 クライアント
5 通信回線
6 ルーティング機能
7 帯域予約プロセス
8 ポリシー制御
9 受付制御
10 帯域予約テーブル
11 ルーティングプロセス
12 パケットクラス分け
13 パケットスケジューラ
14 パケット送受信部
15 データベース管理部
16 料金算出部
17 帯域管理データベース
Claims (2)
- 特定端末間の通信回線の帯域予約を行い、その予約情報を管理する帯域予約管理システムであって、
前記特定端末間の通信回線の帯域を予約するために、帯域幅、予約開始時刻、および予約終了時刻を含む帯域予約要求を発信する帯域予約要求手段と、
当該帯域予約要求を受信すると、当該帯域予約要求の内容に応じて前記通信回線の帯域予約が可能であるか判定し、可能である場合は、前記通信回線の帯域予約を行い、さらに当該予約開始時刻から当該予約終了時刻の間は、当該帯域幅で前記通信回線を接続する回線接続手段と、
前記特定端末間の通信回線上に存在する任意の前記回線接続手段において個々に帯域予約が行われ、当該帯域予約要求に合致する前記特定端末間の通信回線の帯域予約が確立した時点で、その予約情報を発信する予約情報発信手段と、
前記予約情報に応じて、帯域予約された当該通信回線の使用料を算出する料金算出手段と、
を備えることを特徴とする帯域予約管理システム。 - 前記帯域予約要求手段は、前記回線接続手段において当該帯域幅で帯域予約できなかった場合、当該帯域幅より狭い帯域幅で帯域予約要求を発信することを特徴とする請求項1に記載の帯域予約管理システム。
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) | 帯域内シグナリングメカニズムにおける双方向QoS予約 | |
JP2004508739A (ja) | ネットワークにおける価格設定ベースのサービス品質(PQoS)コントロールのためのシステム | |
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) | Ip通信網における方法及び装置 | |
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 |