(57)【特許請求の範囲】
【請求項１】
マルチメディアデータまたはコンピュータデータのストリームを統合して扱う情報通信ネットワークに接続された情報通信端末装置におけるストリーム帯域制御方法において，
通信アプリケーションと独立に帯域制御手段を設け，
ユーザの希望する帯域と通信アプリケーションの必要とする帯域とを，それぞれ最大値と最小値の２つの値で表される範囲で持ち，
前記帯域制御手段は，ユーザからの通信要求発生時に前記最大値と最小値の２つのパラメータの範囲を調べ，
２つの範囲に重なる領域があれば，その重なった範囲を本端末装置の要求帯域として算出し，
その重なった範囲で伝送路の利用可能帯域以下となる値があるかどうかをチェックし，
もしあれば，その範囲に入る最大値を予約帯域として伝送路の帯域を予約した後，通信アプリケーションのストリームの送受信を開始し，もしなければ，ユーザからの通信要求を拒絶し，
前記２つのパラメータの範囲に重なる領域がなければ，ユーザからの通信要求を拒絶する
ことを特徴とするストリーム帯域制御方法。
【請求項２】
請求項１記載のストリーム帯域制御方法において，
算出した端末装置の要求帯域がネットワークの利用可能帯域より大きかったとき，前記帯域制御手段は，所定の時間間隔で伝送路の帯域をチェックし，
もし必要な要求帯域の空きがあれば，伝送路の帯域を予約した後，通信アプリケーションのストリームの送受信を開始する
ことを特徴とするストリーム帯域制御方法。
【請求項３】
請求項１記載のストリーム帯域制御方法において，
算出した端末装置の要求帯域の範囲がネットワークの利用可能帯域を間に含むとき，
前記帯域制御手段は，ネットワークの利用可能帯域で伝送路の帯域を予約した後，通信アプリケーションのストリームの送受信を開始するとともに，
帯域検出機能を持つプロセスに前記端末装置の要求帯域の最大値で示される帯域が空きとなったときに通知するように登録しておき，
この通知を受けたとき，端末装置の要求帯域の最大値で伝送路の帯域を予約するように変更した後，通信アプリケーションのストリームの送受信を継続する
ことを特徴とするストリーム帯域制御方法。
【請求項４】
請求項１記載のストリーム帯域制御方法において，
算出した端末装置の要求帯域の範囲がネットワークの利用可能帯域を間に含むとき，
前記帯域制御手段は，ネットワークの利用可能帯域で伝送路の帯域を予約した後，通信アプリケーションのストリームの送受信を開始するとともに，
所定の時間間隔で伝送路の帯域をチェックし，
端末装置の要求帯域の最大値で示される帯域の空きを検出したとき，端末装置の要求帯域の最大値で伝送路の帯域を予約するように変更した後，通信アプリケーションのストリームの送受信を継続する
ことを特徴とするストリーム帯域制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は，インターネットやＡＴＭ(Asyncronous Transfer Mode）などの情報通信ネットワークに接続された情報通信端末装置において，音声・画像などのマルチメディアデータ，コンピュータデータなどのストリーム型通信を行おうとする際，ユーザの希望する帯域・利用しようとする通信アプリケーションの必要とする帯域・その時点で利用できるネットワークの帯域，から算出した最適な通信帯域でネットワークの資源を予約した後，通信アプリケーションのストリームの送受信を開始することで，その時点で利用できる最適な通信の品質を保証することを可能にしたストリーム帯域制御方法に関する。
【０００２】
さらに，本発明は，もしアプリケーションおよびユーザが必要とする端末装置の要求帯域がネットワークで確保できないときには，ユーザの通信要求を拒絶することで不必要なストリームのネットワークへの流入を阻止し，利用者全体から見たネットワーク資源の有効利用を実現する。
【０００３】
なお，利用するネットワークはインターネットでＲＳＶＰ(Resource ReSerVation Protocol）やＳＴ２(STream protocol version.2）などの資源予約機能を備えたものを主眼とするが，ＡＴＭなどのＭＡＣ層で帯域保証機能を備えたネットワークを適用対象とすることも可能である。また利用するストリームは主として音声・画像などのマルチメディアデータを対象とするが，コンピュータデータを扱うことも可能である。
【０００４】
【従来の技術】
インターネットなどの情報通信ネットワークでは，情報をパケットと呼ぶ単位に分割して伝送するが，ネットワークでのパケットの処理は基本的にベスト・エフォートと呼ぶ先着順の処理方式で伝送される。しかしながら，このような処理方式ではすべてのパケットを平等に扱うため，音声や画像などのリアルタイム伝送を必要とするマルチメディア・トラフィックに対しては十分な伝送帯域が保証されず，受信側でリアルタイムに的確に再生できないなど，一定の品質が保証できなかった。
【０００５】
これに対して，ＩＥＴＦ(Internet Engineering Task Force）では，ＲＳＶＰ(Resource ReSerVation Protocol）などの資源予約プロトコルをインターネット標準として規定している。ＲＳＶＰを用いれば，通信を開始する前にストリームごとに必要な帯域を確保でき，一定の品質を保証した通信が行える。
【０００６】
しかし，従来，アプリケーション（応用プログラム）からＲＳＶＰなどの帯域予約機能を利用する際には，アプリケーション毎に帯域予約のリクエスト機能を組み込み，アプリケーションが必要とする帯域のみを単独のパラメータとして，ネットワークに帯域予約をリクエストするのみであり，ユーザ毎の通信要求やネットワークの現在の利用可能な帯域などの外的要素は考慮されていなかった。従って，帯域の予約設定に関して，これらのパラメータを総合的に評価した最適化が行われているとは言えない。
【０００７】
【発明が解決しようとする課題】
以上述べたように，従来の帯域予約機能の利用は，アプリケーションに帯域予約のリクエスト機能を組み込むため，個々のアプリケーションを直接意識した個別の帯域予約機能の開発が必要であり，アプリケーション開発の効率が非常に悪い。
【０００８】
またネットワークへの帯域予約のリクエストはアプリケーションの必要とする帯域のみを単独のパラメータとしており，ユーザ毎の要求やネットワークの現在の利用可能な帯域などを考慮しておらず，ユーザが望まない帯域すなわち通信品質を予約したり，不必要に大きな帯域を予約したりして，ネットワークの利用者全体での資源の有効利用が図られていない。
【０００９】
本発明は，このような状況において，帯域制御機能をアプリケーションから分離して独立した機能として動作させることによりアプリケーションの開発を効率化するとともに，ユーザの要求・アプリケーションの必要とする帯域・ネットワークの利用可能帯域を総合的に判断して最適な帯域をネットワークに予約して，その時点で利用できる最適な通信の品質を保証できるようにすることを目的とする。
【００１０】
【課題を解決するための手段】
図１は本発明の原理説明図である。
情報通信ネットワーク７に接続された情報通信端末装置１において，通信アプリケーション６と独立に帯域制御手段２を設け，これと併せて，通信を行おうとする相手端末装置との間の利用可能帯域を検出する帯域検出手段３と，伝送路の帯域を予約する帯域予約手段４と，ユーザ単位の個人情報管理手段５を設ける。帯域制御手段２は，個別のアプリケーション６のためのストリーム帯域の制御を行う中心部分である。
【００１１】
ユーザからの通信要求が発生したとき，帯域制御手段２がこれを受け付ける。そして相手端末装置の帯域制御機能と通信の意志確認を行った後，起動しようとするアプリケーション６に対して，個人情報管理手段５からユーザの希望する帯域を，使おうとする通信アプリケーション６から必要とする帯域を，それぞれ検索して，これらの値の小さくない方として得られる値を端末装置の要求帯域として算出する。
【００１２】
さらに，帯域検出手段３によりその時点の利用可能帯域を調べて算出した端末装置の要求帯域が，伝送路の利用可能帯域以下であるかどうかをチェックする。もしそれ以下であれば，帯域予約手段４を用いて伝送路の帯域を予約した後，通信アプリケーション６のストリームの送受信を開始し，もしそれ以上であればユーザからの通信要求を拒絶する。
【００１３】
また，ユーザの希望する帯域と通信アプリケーション６の必要とする帯域を，それぞれ最大値と最小値の２つの値で与えて範囲を持たせることもできる。この場合，帯域制御手段２は，ユーザからの通信要求発生時にこれらの２つのパラメータの範囲を調べて，２つの範囲に重なる領域があればその重なった範囲を端末装置の要求帯域として算出する。その範囲で伝送路の利用可能帯域以下となる値があるかどうかをチェックして，もしあれば，その範囲に入る最大値を予約帯域として，帯域予約手段４を用いて伝送路の帯域を予約した後，通信アプリケーション６のストリームの送受信を開始し，もしなければ，ユーザからの通信要求を拒絶し，また２つのパラメータの範囲に重なる領域がなければ，ユーザからの通信要求を拒絶する。
【００１４】
なお，算出した端末装置の要求帯域がネットワーク７の利用可能帯域より大きかったとき，帯域制御手段２は，帯域検出手段３に必要な帯域が空きとなったときに通知するように登録しておいて帯域検出手段３からの通知を待ち，この通知を受けたとき，帯域制御手段２が帯域予約手段４を用いて伝送路の帯域を予約した後，通信アプリケーション６のストリームの送受信を開始するようにすることもできる。
【００１５】
また，算出した端末装置の要求帯域がネットワーク７の利用可能帯域より大きかったときには，帯域制御手段２が一定時間間隔で帯域検出手段３を用いて伝送路の帯域をチェックし，もし必要な要求帯域の空きがあれば，帯域制御手段２が帯域予約手段４を用いて伝送路の帯域を予約した後，通信アプリケーション６のストリームの送受信を開始するようにすることもできる。
【００１６】
また，ユーザの希望する帯域と通信アプリケーション６の必要とする帯域を最大値と最小値の２つの値で与えて範囲を持たせる場合，端末装置の要求帯域の範囲がネットワーク７の利用可能帯域を間に含むとき，ネットワーク７の利用可能帯域で伝送路の帯域を予約した後，通信アプリケーション６のストリームの送受信を開始するとともに，帯域制御手段２は帯域検出手段３に算出した端末装置の要求帯域の最大値で示される帯域が空きとなったときに通知するように登録しておき，この通知を受けたとき，帯域制御手段２が帯域予約手段４を用いて要求帯域の最大値で伝送路の帯域を予約するように変更した後，通信アプリケーション６のストリームの送受信を継続するようにすることもできる。
【００１７】
また，ユーザの希望する帯域と通信アプリケーション６の必要とする帯域を最大値と最小値の２つの値で与えて範囲を持たせる場合，アプリケーション６とユーザの必要とする要求帯域の範囲がネットワーク７の利用可能帯域を間に含むとき，ネットワーク７の利用可能帯域で伝送路の帯域を予約した後，通信アプリケーション６のストリームの送受信を開始するとともに，帯域制御手段２は一定時間間隔で帯域検出手段３を用いて伝送路の待機をチェックし，算出した端末装置の要求帯域の最大値で示される帯域の空きを検出したときに，帯域制御手段２が帯域予約手段４を用いて要求帯域の最大値で伝送路の帯域を予約するように変更した後，通信アプリケーション６のストリームの送受信を継続するようにすることもできる。
【００１８】
本発明の作用は，以下のとおりである。
本発明では，ユーザの希望する帯域・利用しようとする通信アプリケーション６の必要とする帯域・その時点で利用できるネットワーク７の帯域，から割り出した最適な通信帯域でネットワーク７の資源を予約した後，通信アプリケーション６のストリームの送受信を開始することで，その時点で利用できる最適な通信の品質を保証することが可能となる。
【００１９】
また，もしアプリケーション６およびユーザが必要とする要求帯域がネットワーク７で確保できないときには，ユーザの通信要求を拒絶することで不必要なトラフィックの流入を阻止し，利用者全体から見たネットワーク資源の有効利用が可能となる。
【００２０】
さらに，帯域制御手段２をアプリケーション６から分離して独立した機能として提供するため，アプリケーション開発を効率化することが可能となる。
【００２１】
【発明の実施の形態】
図２に，本発明の実施の形態を示す。これは，図１に示す情報通信端末装置１における機能モジュールの構成を表すものである。さらに，この例に対する帯域制御のシーケンス図を図３に，ユーザ要求帯域テーブルの構成を図４に，アプリ別必要帯域テーブルの構成を図５に示す。
【００２２】
情報通信端末装置１は，ストリーム帯域制御の制御を行う帯域制御機能を提供する帯域制御モジュール２１を中心に，ネットワーク７の利用可能帯域の検出機能とストリーム毎の帯域予約機能を提供するＲＳＶＰ機能を備えたＲＳＶＰデーモン８，ユーザ毎にアプリケーション６の要求帯域を記述したユーザ要求帯域テーブル５１，アプリケーション６毎の必要帯域を記述したアプリ別必要帯域テーブル６１，および各種のアプリケーション（アプリ−Ａ，アプリ−Ｂ，…）６からなる。
【００２３】
なお，図３のシーケンス例では，相手端末装置側での内部制御信号を省略しているが，当該端末装置と同様の内部制御信号のやりとりが行われる。
ＲＳＶＰデーモン８は，ＲＳＶＰプロトコルを実行するモジュールであり，シグナリングを通してストリームの経路に沿ったルータに帯域予約を設定していく。この際，受信側主導で帯域の予約が行われる。また，併せて制御用のアプリケーションプログラム・インタフェース（ＡＰＩ）を帯域制御モジュール２１に提供する。
【００２４】
ユーザは，ストリーム通信を行おうとする場合，通信相手の端末装置アドレス（インターネットを想定した場合，ＩＰアドレス）と，使おうとするアプリケーション６の識別名を記して，帯域制御モジュール２１にリクエストを伝える。帯域制御モジュール２１は，まずＴＣＰソケットコネクションを用いて制御メッセージで相手端末装置との通信意志確認を行う。
【００２５】
相手端末装置からＡＣＫの応答が返ってくれば，次に，利用しようとするアプリケーション６について，ユーザ要求帯域テーブル５１からユーザの要求帯域を，アプリ別必要帯域テーブル６１からアプリケーション６の必要帯域をチェックする。これらの値をそれぞれ，Ｂｕ［ｂｐｓ］，Ｂａ［ｂｐｓ］としたとき，Ｂｕａ＝ｍａｘ（Ｂｕ，Ｂａ）［ｂｐｓ］で表される値を端末装置の要求帯域とする。
【００２６】
例えば，図４のユーザ要求帯域テーブル５１と図５のアプリ別必要帯域テーブル６１を参照すると，アプリ−Ａに対して，Ｂｕ＝２５６ｋｂｐｓ，Ｂａ＝１２８ｋｂｐｓであるから，Ｂｕａ＝２５６ｋｂｐｓである。なお，ユーザ要求帯域テーブル５１への登録は各ユーザが行い，アプリ別必要帯域テーブル６１への登録はアプリケーション提供者が行う。登録を省略した場合には，適当なシステムのディフォルト値が用いられる。
【００２７】
次に，ＲＳＶＰデーモン８を通して現在利用可能，すなわち帯域予約が可能な帯域を調べる。この値をＢｎ［ｂｐｓ］とするとき，Ｂｕａ≦Ｂｎであれば必要な帯域が確保できるので，ＲＳＶＰデーモン８を使ってＢｕａ［ｂｐｓ］の帯域予約を行い，その後アプリケーション６を起動してストリームの送信を開始する。もしＢｕａ＞Ｂｎであれば，必要な帯域は確保できないので，ユーザに通信拒絶のメッセージを表示して終了する。
【００２８】
上記の変形として，ユーザの要求帯域とアプリケーション６の必要帯域とを，それぞれ最大値と最小値の２つの値で与えることもできる。この場合のユーザ要求帯域テーブル５１とアプリ別必要帯域テーブル６１の構成を，図６，図７に示す。
【００２９】
端末装置の要求帯域は，それぞれの範囲の重なる領域として算出できる。例えば，図６のユーザ要求帯域テーブル５１と図７のアプリ別必要帯域テーブル６１とから，アプリ−Ｂに対して，Ｂｕ＝３２〜１２８ｋｂｐｓ，Ｂａ＝３２〜６４ｋｂｐｓであるから，Ｂｕａ＝３２〜６４ｋｂｐｓである。この範囲で，伝送路の利用可能帯域以下となる値があるかどうかを調べ，もしあれば，その値を予約帯域として帯域予約機能を用いて伝送路の帯域を予約した後，通信アプリケーション（アプリ−Ｂ）６のストリームの送受信を開始する。例えば，Ｂｎ＝４８ｋｂｐｓであれば予約帯域は４８ｋｂｐｓ，Ｂｎ＝１２８ｋｂｐｓであれば予約帯域は６４ｋｂｐｓ，Ｂｎ＝１６ｋｂｐｓであれば予約可能な帯域は「なし」である。
【００３０】
また，算出した端末装置の要求帯域が，ネットワーク７の利用可能帯域より大きかったとき，帯域制御モジュール２１はＲＳＶＰデーモン８に必要な帯域が空きとなったときに通知するように登録しておいて，ＲＳＶＰデーモン８からの通知を待ち，この通知を受けたとき，帯域制御モジュール２１がＲＳＶＰデーモン８を用いて伝送路の帯域を予約した後，通信アプリケーション６のストリームの送受信を開始するようにすることもできる。
【００３１】
この場合の帯域制御のシーケンス図を図８に示す。帯域制御モジュール２１内でのチェックまでは図３のシーケンスと同じである。ここで帯域チェックの結果，Ｂｕａ＞Ｂｎであったので帯域予約は行わずに，ＲＳＶＰデーモン８に通知予約の設定，すなわちＢｕａの空き帯域ができたときに帯域制御モジュール２１に通知するように設定しておく。その後，ＲＳＶＰデーモン８が十分な空き帯域を検出すると，帯域制御モジュール２１に検出通知を送る。これを受けて帯域制御モジュール２１は，Ｂｕａの帯域予約をＲＳＶＰデーモン８を通して行い，アプリケーション６を起動してストリームの送信を開始する。
【００３２】
また，アプリケーション６とユーザの必要とする要求帯域の範囲がネットワーク７の利用可能帯域を間に含むとき，ネットワーク７の利用可能帯域で伝送路の帯域を予約した後，通信アプリケーション６のストリームの送受信を開始するとともに，帯域制御モジュール２１はＲＳＶＰデーモン８にアプリケーション６とユーザの要求帯域の最大値で示される帯域が空きとなったときに通知するように登録しておき，この通知を受けたとき，帯域制御モジュール２１がＲＳＶＰデーモン８を用いて要求帯域の最大値で伝送路の帯域を予約するように変更した後，通信アプリケーション６のストリームの送受信を継続するようにすることもできる。
【００３３】
この場合の帯域制御のシーケンス図を図９に示す。帯域制御モジュール２１内でのチェックまでは図３のシーケンスと同じである。ここで帯域チェックの結果，Ｂｎの値がＢｕａの範囲内，すなわち最小値Ｂｕａ＿ｍｉｎと最大値Ｂｕａ＿ｍａｘの間であった（Ｂｕａ＿ｍｉｎ＜Ｂｎ＜Ｂｕａ＿ｍａｘ）ので，Ｂｎで帯域予約を行い，併せて通知予約，つまりＢｕａ＿ｍａｘの帯域が利用可能となったときに帯域制御モジュール２１に通知するように設定しておき，アプリケーション６を起動してストリームの送信を開始する。その後，ＲＳＶＰデーモン８が十分な空き帯域を検出すると，帯域制御モジュール２１に検出通知を送る。これを受けて帯域制御モジュール２１は，Ｂｕａ＿ｍａｘの帯域予約をＲＳＶＰデーモン８を通して行い，十分な帯域を確保してストリームの送信を継続する。
【００３４】
【発明の効果】
本発明では，ユーザの希望する帯域・利用しようとする通信アプリケーションの必要とする帯域・その時点で利用できるネットワークの帯域，から割り出した最適な通信帯域でネットワークの資源を予約した後，通信アプリケーションのストリームの送受信を開始することで，その時点で利用できる最適な通信の品質を保証することが可能となる。また，もしアプリケーションおよびユーザが必要とする要求帯域がネットワークで確保できないときには，ユーザの通信要求を拒絶することで不必要なトラフィックの流入を阻止し，利用者全体から見たネットワーク資源の有効利用が可能となる。
【００３５】
さらに，帯域制御機能をアプリケーションから分離して独立した機能として提供するため，アプリケーション開発を効率化することが可能となる。
【図面の簡単な説明】
【図１】本発明の原理説明図である。
【図２】本発明の実施の形態を示す図である。
【図３】第１のストリーム帯域制御のシーケンスを示す図である。
【図４】ユーザ要求帯域テーブルの例を示す図である。
【図５】アプリ別必要帯域テーブルの例を示す図である。
【図６】ユーザ要求帯域テーブルの例を示す図である。
【図７】アプリ別必要帯域テーブルの例を示す図である。
【図８】第２のストリーム帯域制御のシーケンスを示す図である。
【図９】第３のストリーム帯域制御のシーケンスを示す図である。
【符号の説明】
１    情報通信端末装置
２    帯域制御手段
３    帯域検出手段
４    帯域予約手段
５    個人情報管理手段
６    アプリケーション
７    ネットワーク
【図１】
0003776573.tif 000002
【図２】
0003776573.tif 000003
【図３】
0003776573.tif 000004
【図４】
0003776573.tif 000005
【図５】
0003776573.tif 000006
【図６】
0003776573.tif 000007
【図７】
0003776573.tif 000008
【図８】
0003776573.tif 000009
【図９】
0003776573.tif 000010