(57)【要約】【課題】  ネットワークの資源の予約またはその開放をユーザが意識することなく、容易にコンテンツを切り替えることを可能にする。【解決手段】  クライアント端末は、ネットワークを介して、サーバ装置が提供可能なコンテンツデータの資源予約パラメータを含むデータを受信し（ステップＳ４１）、保存する。ユーザにより操作部の番組選択ボタンやザッピングボタンが操作される（ステップＳ３，Ｓ４）と、資源予約パラメータに従い、ネットワークの資源を予約するためのＡＳＰメッセージ（資源予約要求メッセージ）を作成し（ステップＳ７）、送信する（ステップＳ８）ことにより、ネットワークの資源を予約するための処理を実行する。【選択図】  図６
2008029019.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク内のサーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置であって、
前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信手段と、
前記通信手段を制御する制御手段と、
前記通信手段より受信した前記コンテンツデータに基づく処理を実行する処理手段とを備え、
前記制御手段は、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とするクライアント装置。
【請求項２】
前記制御手段は、前記入力がなされた際に前記第１コンテンツデータを受信するためのコネクションを開放した後、前記ネットワークの資源を予約するための処理を実行することを特徴とする請求項１記載のクライアント装置。
【請求項３】
前記制御手段は、前記ネットワークの資源を予約するための処理として、
前記第２コンテンツデータの属性に該第２コンテンツデータの配信に必要なネットワークの資源を特定するための資源予約パラメータが含まれている場合、該資源予約パラメータに従いネットワークの資源を予約するための資源予約要求メッセージを送信し、
前記資源予約パラメータが含まれていない場合、第２コンテンツデータの配信のみを要求するメッセージを送信し、ネットワークの資源を予約を前記サーバ装置に委ねることを特徴とする請求項１又は２記載のクライアント装置。
【請求項４】
前記制御手段は、所定の入力が行われた場合に、予め設定された時間間隔で、ネットワークの資源を予約するための処理を実行し、受信対象コンテンツの切換を行うことを特徴とする請求項１乃至３の何れかに記載のクライアント装置。
【請求項５】
ネットワークに接続されたサーバ装置と、該サーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置とを有する情報通信システムであって、
前記クライアント装置は、
前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信手段と、
前記通信手段を制御する制御手段と、
前記通信手段より受信した前記コンテンツデータに基づく処理を実行する処理手段とを備え、
前記制御手段は、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とする情報通信システム。
【請求項６】
ネットワーク内のサーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置の制御処理方法であって、
前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信ステップと、
前記通信ステップを制御する制御ステップと、
前記通信ステップにより受信した前記コンテンツデータに基づく処理を実行する処理ステップとを備え、
前記制御ステップは、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とするクライアント装置の制御処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置、情報通信システム及びクライアント装置の制御処理方法に関し、特に、通信網内のサーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置、情報通信システム及びクライアント装置の制御処理方法に関する。
【背景技術】
【０００２】
例えば、各家庭まで敷設された光ファイバーケーブルを介して、電話やＩＳＤＮなど各種の通信サービスを提供するＦＴＴＨ（Fiber to the Home）技術の進歩により、近い将来、ユーザは、家庭でも高速ネットワークを利用できるようになると考えられている。このような環境下で普及すると予想されるデータ配信サービス、例えば、インターネットテレビジョンサービス（以下、インターネットＴＶと略称する）や、インターネットビデオオンデマンド（以下、インターネットＶｏＤと略称する）などのサービスを実現する場合、そのサービス提供者は、ユーザに対して配信するデータの品質すなわちサービスの品質（ＱｏＳ）を保証しなければならない。このようにデータ配信サービスにおける品質を保証するためには、データ配信サービスに際してネットワーク上で使用する帯域資源の予約を行う必要がある。すなわち例えば、ＡＴＭ（Asynchronous Transfer Mode）を用いたＩＰ（Internet Protocol）ネットワークを例に挙げて説明すると、上記サービスに品質を保証するためには、コネクションレスであるＩＰパケットを、品質を保証するコネクションオリエンテッドな技術であるＡＴＭのバーチャルコネクション（Virtual Connection：以下、適宜ＶＣと略記する）で伝送することが必要となる。
【０００３】
従来技術として、特許文献１、２が知られている。
【０００４】
【特許文献１】特開平８−３２６０１号公報
【特許文献２】特開平６−３００２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、従来より、バーチャルコネクション（ＶＣ）等の資源を予約するためのプロトコルとしては、ＲＳＶＰ（Resource reSerVation Protocol）などが知られている。ＲＳＶＰでは、ユーザ自身が、例えばＩＰ（Internet Protocol）ネットワークに接続されている端末を操作することによって資源の予約を行い、コネクションを確立する。これにより、ユーザは、データ配信サービスを受けることができるようになる。また、ＲＳＶＰでは、データ配信サービスを受けた後、ユーザ自身が再び端末を操作することによって資源の開放を行い、コネクションを切断しなければならない。
【０００６】
このように、ＲＳＶＰなどの従来の資源を予約するためのプロトコルにおいては、ユーザ自身が例えば端末を操作して、資源の予約及び開放を行なわなければならず、ユーザに負荷がかかるという課題がある。
【０００７】
また、例えば、インターネットＴＶにおいては、多チャンネルによる番組放送が予想されており、したがって、このインターネットＴＶのデータ配信サービス（番組放送サービス）においても一般的なテレビジョン放送の視聴時と同様に、ユーザがチャンネルを切り換えてどのような番組が放送されているかを見る、いわゆるザッピングによってチャンネルの切り換えが頻繁に行われることが考えられる。しかし、この場合、ユーザは、ザッピングを行う度に端末を操作して資源の予約または開放を行わなければならなくなり、その作業はユーザにとって多大な負担になる。
【０００８】
そこで、本発明はこのような状況に鑑みてなされたものであり、ユーザが意識することなく、ネットワーク資源を予約または開放することができるようにするクライアント装置、情報通信システム及びクライアント装置の制御処理方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述の課題を解決するために、本発明は、ネットワーク内のサーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置であって、前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信手段と、前記通信手段を制御する制御手段と、前記通信手段より受信した前記コンテンツデータに基づく処理を実行する処理手段とを備え、前記制御手段は、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とする。
【００１０】
ここで、前記制御手段は、前記入力がなされた際に前記第１コンテンツ情報を受信するためのコネクションを開放した後、前記ネットワークの資源を予約するための処理を実行することが好ましい。また、前記制御手段は、前記ネットワークの資源を予約するための処理として、前記第２コンテンツデータの属性に該第２コンテンツデータの配信に必要なネットワークの資源を特定するための資源予約パラメータが含まれている場合、該資源予約パラメータに従いネットワークの資源を予約するための資源予約要求メッセージを送信し、前記資源予約パラメータが含まれていない場合、第２コンテンツデータの配信のみを要求するメッセージを送信し、ネットワークの資源を予約を前記サーバ装置に委ねることが好ましい。さらに、前記制御手段は、所定の入力が行われた場合に、予め設定された時間間隔で、ネットワークの資源を予約するための処理を実行し、受信対象コンテンツの切換を行うことが好ましい。
【００１１】
また、本発明に係る情報通信システムは、上述の課題を解決するために、ネットワークに接続されたサーバ装置と、該サーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置とを有する情報通信システムであって、前記クライアント装置は、前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信手段と、前記通信手段を制御する制御手段と、前記通信手段より受信した前記コンテンツデータに基づく処理を実行する処理手段とを備え、前記制御手段は、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とする。
【００１２】
さらに、本発明に係るクライアント装置の制御処理方法は、上述の課題を解決するために、ネットワーク内のサーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置の制御処理方法であって、前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信ステップと、前記通信ステップを制御する制御ステップと、前記通信ステップにより受信した前記コンテンツデータに基づく処理を実行する処理ステップとを備え、前記制御ステップは、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することにより、ユーザは、ネットワークの資源の予約またはその開放を意識せずに、容易にコンテンツを切り替えることが可能となる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
【００１５】
図１は、本発明を適用したクライアント端末のネットワークの接続例を表している。
【００１６】
クライアント端末１１およびクライアント端末１２は、例えば加入者が使用するパーソナルコンピュータにて構成され、これらクライアント端末１１，１２は回線を介してルータに接続されている。なお、図１の例では、クライアント端末として端末１１，１２の２台のみを図示しているが、これは一例であり複数台の端末がルータに接続されていてもよい。また、以下の説明では、当該クライアント端末１１，１２が接続されている回線（加入者線）の一例として光ファイバを使用した回線を挙げている。さらに、以下の説明では、当該光ファイバを使用した回線にて接続されたネットワークの一例として、後述するＡＭＩｎｅｔと呼ぶネットワークを使用している。クライアント端末１１，１２は、上記光ファイバを使用した加入者線を介して、ＡＭＩｎｅｔ２０のＡＭＩｎｅｔルータ２１に接続されている。
【００１７】
ここで、ＡＭＩｎｅｔは、インターネットに上位互換するネットワークであり、既存のネットワークアーキテクチャがもつ問題を解決する次世代ネットワークアーキテクチャである。ＡＭＩｎｅｔアーキテクチャは、ＦＴＴＨ（T.Miki.Toward the Service-Rich Era. IEEE Communications Magazine, Vol.32，N0.2, February 1994）やｘＤＳＬ（G.T. Hawley. Systems Considerations for the Use of xDSL Technology for Data Access.IEEE Communications Magazine, Vol.35, No.3, March 1997）の実現によって家庭や企業が超高速ネットワークに対称／準対称型で常時接続される時代を見据え、インターネットアーキテクチャが持つ本質的な問題点を解決するものである。
【００１８】
すなわち、ＡＭＩｎｅｔアーキテクチャの特徴は、最適なプロトコルスタックの動的構築、ＩＰを用いた独自の高速資源予約、ノード間の同位階層間およびノード内の上下階層間のネゴシェーション、コネクション指向のＱｏＳ保証、ノードの識別子とアドレスの分離、非エンド間制御、通信媒体に依存しないアーキテクチャ等を可能とすることである。なお、以下、ＡＭＩｎｅｔにおける高速資源予約プロトコルをＡＳＰ（AMInet Set-up Protocol）と呼ぶことにする。ＡＭＩｎｅｔ及びＡＳＰについての、より詳細な説明は後述する。
【００１９】
ＡＭＩｎｅｔ２０は、ＡＭＩｎｅｔルータ２１、ＡＴＭネットワーク２２（一例であり他のネットワークであってもよい）、およびＡＭＩｎｅｔルータ２３により構成される。
【００２０】
ＡＭＩｎｅｔ２０を構成するＡＭＩｎｅｔルータ２１は、ＡＭＩｎｅｔ独自の機能が拡張された、ＡＴＭネットワークインターフェイスを有するルータである。このＡＭＩｎｅｔルータ２１は、加入者線を集線して、回線網の一例としてのＡＴＭネットワーク２２に接続される。ＡＴＭネットワーク２２には、ＡＭＩｎｅｔルータ２１の他、ＡＭＩｎｅｔルータ２３が接続されている。ＡＭＩｎｅｔルータ２３は、ＡＭＩｎｅｔルータ２１と同様に、ＡＭＩｎｅｔ独自の機能が拡張された、ＡＴＭネットワークインターフェイスを有するルータであり、この例では、光ファイバを介してＮ個のサーバに接続されている。なお、図１には、Ｎ個のサーバとして、それぞれが例えば映像データや音声データを配信可能なＮ個のビデオサーバ３２−１乃至３２−Ｎを一例として挙げている。以下において、ビデオサーバ３２−１乃至３２−Ｎを特に区別する必要がない場合は、これらを単にビデオサーバ３２と称する。
【００２１】
ビデオサーバ３２は、例えば、インターネットＴＶ、またはインターネットＶｏＤに対応可能なビデオサーバであり、クライアント端末１１およびクライアント端末１２に対して少なくとも映像データ及び音声データを供給可能な（映像データ及び音声データの供給サービスを行う）サーバである。
【００２２】
図２は、クライアント端末１１の内部の構成例を表している。
【００２３】
操作部５１は、例えば、マウスやキーボードで構成され、制御部５０に所定の指令を入力するとき、適宜ユーザにより操作される。表示部５２は、例えば、ＬＣＤ（Liquid Crystal Display）やＣＲＴ（Cathode Ray Tube）、その他の表示装置により構成され、様々な情報を表示する。
【００２４】
通信部５３は、加入者線を介してＡＭＩｎｅｔルータ２１に接続されており、ＡＭＩｎｅｔルータ２１と通信するようになされている。データベース５４には、インターネットＴＶおよびインターネットＶｏＤに対応するクライアントインターフェイス（以下、クライアントＩ／Ｆと記述する）プログラムや、当該クライアントＩ／Ｆに必要な所定のデータが保存され、また、ＡＭＩｎｅｔ２０を介して通信部５３が通信を行うのに必要なアプリケーションプログラムが保存されている。さらにデータベース５４には、ＡＭＩｎｅｔ２０を介して供給されるデータが適宜保存されるようになされている。なお、インターネットＴＶおよびインターネットＶｏＤに対応するクライアントＩ／Ｆに必要な所定のデータとしては、サーバから例えば映像データや音声データ等の各種データの配信サービスを受ける際に、ネットワーク帯域資源予約のために必要となる、資源予約パラメータ等を挙げることができる。この資源予約パラメータは、例えばサービス提供者側であるサーバとの接続時に、当該サーバ側から配信されてデータベース５４に保存される。また、資源予約パラメータは、何らかの媒体によって予め配布することも可能であり、この場合は当該配布された媒体から取り出した資源予約パラメータをデータベース５４に保存しておく。資源予約パラメータの詳細については後述する。
【００２５】
制御部５０は、データベース５４に保存されているクライアントＩ／Ｆプログラムやアプリケーションプログラムに従って、操作部５１乃至データベース５４を制御し、各種の動作を実行するようになされている。
【００２６】
なお、クライアント端末１２の内部は、クライアント端末１１と基本的に同様に構成されているので、その図示と説明は省略する。
【００２７】
図３は、ビデオサーバ３２−１の構成例を表している。
【００２８】
ＣＰＵ６１は、ＲＯＭ６２またはハードディスク６４に記録されているプログラムに従って、各種の動作を実行するようになされている。ＲＡＭ６３は、ＣＰＵ６１が各種の処理を実行する上において必要な各種のデータを適宜記憶する。
【００２９】
ハードディスク６４は、ＡＭＩｎｅｔ２０を介して伝送されてくる所定の要求に対応するサーバプログラムを保存している他、クライアント端末に対して配信するクライアントＩ／Ｆプログラムやそれに必要な所定のデータ（資源予約パラメータ）を保存し、さらに、必要に応じて、加入者（クライアント端末）にサービスとして提供するデータ（例えば映像データや音声データなど）を保存可能となされている。
【００３０】
クライアント端末にサービスデータとして提供されることになる映像データや音声データは、ハードディスク６４或いはＩ／Ｏ部６６を介して接続された各種機器から供給される。当該各種機器から供給される映像データや音声データは、クライアント端末側からの要求に応じて、直接、通信部６５からＡＭＩｎｅｔ２０に送信され、或いは、ハードディスク６４に保存され後にクライアント端末側からの要求に応じて読み出されて通信部６５からＡＭＩｎｅｔ２０に送信される。
【００３１】
Ｉ／Ｏ部６６は、例えばＩＥＥＥ１３９４ネットワーク６７に接続され、当該ＩＥＥＥ１３９４ネットワーク６７には、クライアント端末にサービスデータとして提供されることになる映像データや音声データの供給源として、例えばディジタルＶＴＲ６８、メディアコンバータ６９、テレビジョンカメラ７０、ＴＶチューナ７１、ラジオチューナ７２等の各種機器が接続されている。また、メディアコンバータ６９には、例えば複数のアナログＶＴＲ７３，７４，・・・が接続され、このメディアコンバータ６９は、これらアナログＶＴＲからのアナログ映像，音声信号をディジタル映像，音声データに変換して、ＩＥＥＥ１３９４ネットワーク６７上に供給する。すなわち、サーバ側からクライアント端末側に提供されるデータは、録画された映像データに限らず、例えば、テレビジョンカメラ７０によって現在撮影されている生の映像データや、放送局からの放送をＴＶチューナ７１にて受信した映像データ、メディアコンバータ６９を介した映像や音声データなどが考えられる。なお、配信される映像データとしては、例えばＭＰＥＧ規格に対応した圧縮画像データとすることができる。
【００３２】
通信部６５は、光ファイバによりＡＭＩｎｅｔルータ２３に接続されており、ＡＭＩｎｅｔルータ２３と通信を行うようになされている。
【００３３】
なお、ビデオサーバ３２−２乃至３２−Ｎの内部は、ビデオサーバ３２−１と基本的に同様に構成されているので、その図示と説明は省略する。
【００３４】
上述した構成により、クライアント端末は、ビデオサーバからインターネットＴＶまたはインターネットＶｏＤによる映像データや音声データの提供サービスを受けることができる。以下に、クライアント端末がインターネットＴＶまたはインターネットＶｏＤとしてビデオサーバから映像データや音声データの提供サービスを受ける場合の処理手順を説明する。
【００３５】
図４は、例えばクライアント端末１１の表示部５２の画面上にＧＵＩ（Graphical User Interface）として表示される、クライアントＩ／Ｆの初期画面の表示例を表している。
【００３６】
この図４の例において、表示部５２の画面の左側には、サービス提供内容としての例えば複数の番組名が表示される番組選択ボタン１０１−１乃至１０１−９が配置され、番組選択ボタン１０１−９の下側には、終了ボタン１０２、ザッピングボタン１０３、１０ｓ設定ボタン１０４及び２０ｓ設定ボタン１０５が配置され、そして画面右側中央には映像表示部１０６が配置されている。
【００３７】
この例におけるクライアントＩ／Ｆは、インターネットＴＶとインターネットＶｏＤに対応するＩ／Ｆの例であり、この図４の例の場合、番組選択ボタン１０１−１乃至１０１−８には、インターネットＶｏＤにおいて提供可能なサービス名（番組名）が表示され、また、番組選択ボタン１０１−９には、インターネットＴＶにおいて提供可能なサービス名（番組名）が表示されている。
【００３８】
図５には、インターネットＴＶおよびインターネットＶｏＤに対応するクライアントＩ／Ｆに必要な所定のデータである、資源予約パラメータの一例を示す。この資源予約パラメータは、インターネットＴＶやインターネットＶｏＤとして提供される各番組の情報を受信する際のネットワーク資源予約に必要とされ、例えばクライアント端末がサービス提供者側のサーバと接続した時に当該サーバ側から配信され、クライアント端末のデータベース５４中にクライアント設定ファイル５４Ａとして保存される。
【００３９】
この図５の例では、資源予約パラメータとして、サービス内容を指定するためのサービス番号、サービスとして提供可能な番組名、例えばインターネットＴＶやインターネットＶｏＤの放送局アドレスであるサーバアドレス（具体的にはネットワーク層のＩＰアドレス）、及びサーバにおけるサービスを特定するポート番号（具体的にはトランスポート層のＴＣＰ／ＵＤＰポート番号）、サービス提供の際にネットワーク上で必要となる帯域資源を特定するための転送レート、サーバのアプリケーションがＯＳ（オペレーティングシステム）に対して読み書きするデータの単位であるソケットに対する読み書きサイズ、ソケット用のバッファの大きさであるソケットバッファサイズ、ネットワーク上で転送されるデータ（バイト単位）の転送最大サイズと最小サイズ、いわゆるトークンパケットアルゴリズムにおけるパラメータの一つであるトークンバケットサイズ（ネットワーク上のデータに一時に出力できる最大データ量）、およびマルチキャスト配信を行う際に用いられるマルチキャストＩＰアドレスとポート番号が設定される。
【００４０】
なお、インターネットＶｏＤの場合は、一つのクライアント端末に対して一つのサービス（番組の映像データ及び音声データ）が提供されるので、サーバからはユニキャストの形態で当該サービス（番組の映像データ及び音声データ）が配信されることになる。したがって、この場合、図５の資源予約パラメータのマルチキャストＩＰアドレス／ポート番号は無視される（即ち０／０とされる）ことになる。また、インターネットＶｏＤにおいて、提供される映像データが例えば動画データであり、当該動画データがＭＰＥＧ規格に対応するような場合、ユーザ（クライアント端末）は、その動画データの転送レートとして、例えば６Ｍｂｐｓや３Ｍｂｐｓのような何種類かの転送レートの中から所望の転送レートを選択することができる。
【００４１】
一方、インターネットＴＶの場合は、一つのサービス（番組）に対して複数のクライアント端末が存在することになるので、サーバからはマルチキャストの形態で当該サービス（番組）が配信されることになる。
【００４２】
図４に戻り、各番組選択ボタン１０１には、図５に示した資源予約パラメータのうちの各番組名が表示される。したがって、ユーザ（クライアント端末）は、これら各番組選択ボタン１０１から所望の番組名が表示されたボタンを選択することにより、インターネットＴＶまたはインターネットＶｏＤにおいてその選択された番組に対応する映像データ及び音声データのサービスを享受することが可能となる。
【００４３】
終了ボタン１０２は、ユーザがクライアントＩ／Ｆプログラムを終了させるときに選択されるボタンである。
【００４４】
ザッピングボタン１０３は、ザッピングモードをオンに設定するか、またはオフに設定するときにユーザが操作するボタンである。ザッピングモードがオンに設定された場合は、各番組選択ボタン１０１に対応する複数の番組の映像が、所定の時間（この例の場合、１０秒間または２０秒間）だけ、自動的に順次、画像表示部１０６に表示される。これにより、ユーザは各番組の映像を確認することができ、興味のある番組を容易に見つけ出すことができる。
【００４５】
１０ｓ設定ボタン１０４は、ザッピングモードがオンのときに自動的に順次表示される各番組の映像の表示時間（ザッピング時間）を、１０秒間に設定するときにユーザが選択するボタンであり、２０ｓ設定ボタン１０５は、ザッピングモードがオンのときに自動的に順次表示される各番組の映像の表示時間（ザッピング時間）を、２０秒間に設定するときにユーザが選択するボタンである。
【００４６】
なお、初期画面が表示部５２に表示された時、すなわちクライアントＩ／Ｆプログラムが新たに立ち上げられたときには、当該クライアントＩ／Ｆの所定の設定が初期化される。例えば、ザッピングモードがオンになされたときのザッピング時間は、１０秒間または２０秒間のうち、いずれか一方に初期設定される。
【００４７】
次に、図６には、サーバからインターネットＴＶまたはインターネットＶｏＤのサービスを受ける場合の、クライアント端末１１の制御部５０の処理手順を示す。
【００４８】
この図６において、クライアント端末１１の制御部５０は、ステップＳ４０としてクライアントＩ／Ｆプログラムが立ち上げられると、ステップＳ４１として通信部５３を制御してサーバと接続し、資源予約パラメータを含むデータを受信して、例えばデータベース５４に保存させる。これにより、表示部５２には、図４に示したクライアントＩ／Ｆの初期画面が表示されることになる。
【００４９】
このようにクライアントＩ／Ｆプログラムが立ち上がり、図４に示したクライアントＩ／Ｆの初期画面が表示部５２に表示されている状態において、クライアント端末１１の制御部５０は、ステップＳ１として、操作部５１から何らかの指令が入力されるまで待機している。制御部５０は、ステップＳ１の待機時に、操作部５１から何らかの指令が入力されると、ステップＳ２以降の処理に進む。
【００５０】
制御部５０は、ステップＳ２の処理として、ステップＳ１で操作部５１から入力された指令がクライアントＩ／Ｆの終了を指令するものか否かを判定する。制御部５０は、ステップＳ２の判定処理においてクライアントＩ／Ｆの終了指令が入力されたと判定した場合、すなわち、ユーザによって操作部５１が操作されて終了ボタン１０２が選択された場合、当該クライアントＩ／Ｆプログラムの終了処理を行う。
【００５１】
制御部５０は、ステップＳ２の判定処理において、ステップＳ１で操作部５１から入力された指令がクライアントＩ／Ｆの終了を指令するものではないと判定した場合、ステップＳ３の処理に進む。制御部５０は、ステップＳ３の処理に進むと、操作部５１から入力された指令が番組選択ボタン１０１の操作指令であるか否かを判定し、番組選択ボタン１０１の操作指令でないと判定した場合、ステップＳ４の処理に進む。
【００５２】
制御部５０は、ステップＳ４の処理に進むと、ステップＳ１で操作部５１から入力された指令がザッピングボタン１０３の操作指令であるか否かを判定し、ザッピングボタン１０３の操作指令でないと判定した場合、ステップＳ５の処理に進む。制御部５０は、ステップＳ５の処理に進むと、操作部５１から入力された指令が１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の操作指令であるか否かを判定する。
【００５３】
制御部５０は、ステップＳ５の判定処理において、ステップＳ１で操作部５１から入力された指令が１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の操作指令でないと判定した場合、ステップＳ１の処理に戻り、操作部５１から指令が入力されるまで待機する。また、制御部５０は、ステップＳ５の判定処理において、操作部５１から入力された指令が１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の何れか一方を選択した操作指令であると判定した場合、ステップＳ６の処理に進む。
【００５４】
制御部５０は、ステップＳ６の処理に進むと、ステップＳ５にて１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の何れか選択されたボタンに対応する時間に、ザッピング時間を設定した後、ステップＳ１の処理に戻り、操作部５１から指令が入力されるまで待機する。
【００５５】
次に、制御部５０は、ステップＳ３の判定処理において、操作部５１から入力された指令が番組選択ボタン１０１の操作指令であると判定した場合、ステップＳ７の処理に進む。また、制御部５０は、ステップＳ４の判定処理において、操作部５１から入力された指令がザッピングボタン１０３の操作指令であると判定した場合、ステップＳ４２の処理としてザッピングモードをＯＮにした後、ステップＳ７の処理に進む。
【００５６】
制御部５０は、ステップＳ７の処理として、資源予約を要求するためのメッセージを作成する。このメッセージは、前述した高速資源予約プロトコル（ＡＳＰ）によるメッセージであるため、ここではＡＳＰメッセージと呼ぶことにする。例えば、ステップＳ１において番組選択ボタン１０１−１乃至１０１−９のうちの何れか１つが操作された場合、制御部５０は、当該操作された番組選択ボタン１０１に対応する番組の資源予約パラメータをデータベース５４から読み出して解釈し、そのコネクションで用いられる識別子、例えば、ＶＣＩ(Virtual Channel Identifier)／ＶＰＩ（Virtual Path Identifier)を決定し、その資源予約パラメータと共に資源予約を要求するためのＡＳＰメッセージ（資源予約要求メッセージ）を作成する。また、ステップＳ１においてザッピングボタン１０３が操作され、ステップＳ４２にてザッピングモードがＯＮとなされると、制御部５０は、予め決められた番組の資源予約パラメータをデータベース５４から読み出して解釈し、ＶＣＩ／ＶＰＩを決定し、その資源予約パラメータと共に資源予約を要求するためのＡＳＰメッセージ（資源予約要求メッセージ）を作成する。
【００５７】
ステップＳ７にて資源予約を要求するためのＡＳＰメッセージを生成すると、制御部５０は、ステップＳ８として通信部５３を制御し、そのＡＳＰメッセージをＡＭＩｎｅｔルータ２１に送信させる。
【００５８】
通信部５３から送信された資源予約を要求するためのＡＳＰメッセージは、図１のＡＭＩｎｅｔルータ２１およびＡＭＩｎｅｔルータ２３により、ビデオサーバ３２−１乃至３２−Ｎのうち、指定されたサービスを提供することができるビデオサーバ３２に向かって転送される。
【００５９】
ここで、ネットワークの資源予約の処理は、ＡＳＰメッセージの送信方向と同じ方向に資源予約が成されていく順方向の資源予約と、ＡＳＰメッセージの送信方向とは逆方向に資源予約が成されていく逆方向の資源予約とが考えられる。このネットワーク資源予約の具体的な流れの詳細については後述するが、一例として、クライアント端末１１からビデオサーバ３２に資源予約を要求するためのＡＳＰメッセージを送信する過程において、先ずＡＭＩｎｅｔルータ２１からクライアント端末１１の方向に、次に、ＡＭＩｎｅｔルータ２３からＡＭＩｎｅｔルータ２１の方向に、次にビデオサーバ３２からＡＭＩｎｅｔルータ２３の方向に資源予約を行うようにＡＳＰメッセージの送信方向とは逆方向に資源予約がなされる場合や、例えばクライアント端末から送信された資源予約を要求するためのメッセージをビデオサーバ３２が受け取り、このビデオサーバ３２からクライアント端末１１に対してその応答のためのＡＳＰメッセージを返信する過程において、先ずビデオサーバ３２からＡＭＩｎｅｔルータ２３の方向に、次にＡＭＩｎｅｔルータ２３からＡＭＩｎｅｔルータ２１の方向に、次にＡＭＩｎｅｔ２１からクライアント端末１１の方向に資源予約を行うようにＡＳＰメッセージの送信方向と同一の方向（順方向）に資源予約がなされる場合などが考えられる。
【００６０】
例えば、クライアント端末１１がサービスデータ（映像データ及び音声データ）を受信するために必要なネットワークの資源の量を知っている場合、ＡＳＰメッセージの送信方向とは逆方向に資源予約がなされる予約方法が用いられる。例えば、ユニキャスト配信を行うインターネットＶｏＤの場合、予めサーバ３２からクライアント端末１１に、サービスデータ（映像データ及び音声データ）に対する必要な資源の量が通知されており、クライアント端末１１がサービスデータ（映像データ及び音声データ）を受信するために必要な資源の量を予約するので、逆方向の資源予約方法が用いられる。
【００６１】
また、クライアント端末１１がサービスデータ（映像データ及び音声データ）を受信するために必要なネットワークの資源の量を知らない場合、ＡＳＰメッセージの送信方向と同一方向（順方向）に資源予約がなされる予約方法が用いられる。例えば、マルチキャスト配信を行うインターネットＴＶの場合、クライアント端末１１が操作され、サーバ３２に対してサービスデータ（映像データ及び音声データ）の配信の要求が出されてから、サーバ３２がサービスデータ（映像データ及び音声データ）を配信するために必要な資源の量を予約するので、同一方向（順方向）の資源予約方法が用いられる。
【００６２】
ステップＳ８にて資源予約を要求するためのＡＳＰメッセージを送信した後、制御部５０は、ステップＳ９として資源予約が成功したか否かを判定する。すなわち、制御部５０は、逆方向の資源予約或いは順方向の資源予約の結果、資源予約が成功或いは失敗した旨を示すメッセージを受け取ると、そのメッセージによって資源予約が成功したか否かを判定する。制御部５０は、ステップＳ９にて資源予約に失敗したと判定した場合、ステップＳ１０の処理として、表示部５２を制御して資源予約の失敗の原因等を表示させ、ステップＳ１の処理に戻り、ユーザに対して番組選択のための再度の操作を促す。
【００６３】
制御部５０は、ステップＳ９において資源予約が成功したと判定した場合、ステップＳ１１の処理として、通信部５３を制御し、ビデオサーバ３２から転送されてくるサービスデータ（番組の映像データや音声データなど）を受信させ、次にステップＳ１２の処理に進み、表示部５２を制御し、その受信したサービスデータの映像をクライアントＩ／Ｆの映像表示部１０６に表示させる。これにより、映像表示部１０６には、例えば図７に示すように番組選択ボタン１０１−１に対応する番組、例えば「野球１」の映像が表示されることになる。
【００６４】
次に、制御部５０は、ステップＳ４３として、ザッピングモードがＯＮとなっているか否かを判定する。ステップＳ４３にてザッピングモードがＯＮとなっていると判定した場合、制御部５０は、ステップＳ４４として、操作部５１から何らかの指令が入力されたか否かを判定し、操作部５１から何も指令が入力されていないと判定した場合には、ステップＳ１５として、ザッピングの設定時間（ザッピング時間）が経過したか否かの判定を行う。すなわち、制御部５０は、ステップＳ６において１０ｓ設定ボタン１０４が操作されて１０秒のザッピング時間が設定されている場合には１０秒経過したか否かの判定を行い、ステップＳ６において２０ｓ設定ボタン１０５が操作されて２０秒のザッピング時間が設定されている場合には２０秒経過したか否かの判定を行い、また、ザッピング時間が初期設定の時間となっている場合には、その初期設定の時間が経過したか否かの判定を行う。
【００６５】
一方、制御部５０は、ステップＳ１５において、設定されているザッピング時間が経過していないと判定した場合にはステップＳ１１の処理に戻り、設定されているザッピング時間が経過するまでステップＳ１１からステップＳ１５までの処理を行う。
【００６６】
制御部５０は、ステップＳ１５において、設定されているザッピング時間が経過したと判定した場合、ステップＳ４６の処理に進む。制御部５０は、ステップＳ４６の処理に進むと、現在予約している資源を開放するために、その予約の解除を要求するためのＡＳＰメッセージ（資源予約解除要求メッセージ）を生成し、通信部５３を制御して、このＡＳＰメッセージをＡＭＩｎｅｔルータ２１に送信させる。当該資源予約解除を要求するためのＡＳＰメッセージには、終了したいサービスを特定する情報、例えばサーバを特定する情報、クライアント端末を特定する情報などが含まれている。
【００６７】
このときのネットワークの資源予約の解除処理の流れは、資源予約要求時とは異なり、ＡＳＰメッセージの送信方向とは逆方向に資源予約解除が成される逆方向の資源予約解除のみが用いられる。一例としては、クライアント端末１１からビデオサーバ３２に資源予約解除を要求するためのＡＳＰメッセージが送信される過程において、先ずＡＭＩｎｅｔルータ２１からクライアント端末１１の方向に、次にＡＭＩｎｅｔルータ２３からＡＭＩｎｅｔルータ２１の方向に、次にビデオサーバ３２からＡＭＩｎｅｔルータ２３の方向に資源予約解除を行うようにＡＳＰメッセージの送信方向とは逆方向に資源予約解除が成される場合が考えられる。
【００６８】
ステップＳ４６にて資源予約解除を要求するためのＡＳＰメッセージを送信した後、制御部５０は、ステップＳ４７として、ＡＭＩｎｅｔ２１から資源予約の解除の結果を表すメッセージを受信させ、そのメッセージによって資源予約解除が成功したか否かを判定する。すなわち、制御部５０は、逆方向の資源予約解除の結果、資源予約解除が成功或いは失敗した旨を示すメッセージを受け取ると、そのメッセージによって資源予約解除が成功したか否かを判定する。例えば、ネットワークの切断等により資源予約の解除に失敗し、その旨を表すメッセージが受信された場合、制御部５０は、ステップＳ４７にて資源予約解除に失敗したと判定し、次いで、ステップＳ１８の処理として、表示部５２を制御して資源予約解除の失敗の原因等を表示させ、ステップＳ１の処理に戻り、番組選択或いはザッピングのための再度の操作を促す。
【００６９】
一方、制御部５０は、ステップＳ４７において資源予約の解除が成功したと判定した場合、ステップＳ４８の処理として、ザッピングにより次に表示すべきチャンネル（番組）の設定を行う。すなわち、このときの制御部５０は、クライアントＩ／Ｆの映像表示部１０６に現在表示されている番組の次の番組、例えば、１つ下の段の番組選択ボタン１０１に対応する番組を設定し、ステップＳ７の処理に戻って、その番組に対応する資源予約パラメータをデータベース５４から読み出し、資源予約を要求するためのＡＳＰメッセージを作成する。以下、この再設定したチャンネルについてステップＳ８からステップＳ４８までの処理を行うことにより、各番組選択ボタン１０１に対応する番組が順次映像表示部１０６に表示され、ザッピングが実行されることになる。
【００７０】
また、制御部５０は、ステップＳ４３において、ザッピングモードがＯＮとなっていないと判定した場合、ステップＳ１３の処理に進む。制御部５０は、ステップＳ１３の処理に進むと、操作部５１から何らかの指令が入力されたか否かを判定し、操作部５１から何も指令が入力されていないと判定した場合には、ステップＳ１１に戻り、サービスデータの受信処理を続ける。一方、制御部５０は、ステップＳ１３にて操作部５１から何らかの入力がなされたと判定した場合、ステップＳ１６の処理に進む。
【００７１】
ここで、ステップＳ１３において、操作部５１から入力された指令がクライアントＩ／Ｆの映像表示部１０６に表示されている番組を変更する指令であると判定された場合、すなわち、ユーザが操作部５１を操作し、他の番組に対応する番組選択ボタン１０１を選択した場合、制御部５０は、ステップＳ１６以降の処理として、いま現在予約されている資源の解除を行う。
【００７２】
すなわち、ステップＳ１６の処理に進むと、制御部５０は、資源予約の解除を要求するためのＡＳＰメッセージを生成し、通信部５３を制御して、このＡＳＰメッセージをＡＭＩｎｅｔルータ２１に送信させる。このときの資源予約の解除を要求するためのＡＳＰメッセージには、サーバを特定する情報、クライアント端末を特定する情報、および終了したいサービスを特定する情報が含まれている。なお、このときのネットワークの資源予約の解除処理の流れも、逆方向の資源予約解除と順方向の資源予約解除とがある。
【００７３】
ステップＳ１６にて資源予約解除を要求するためのＡＳＰメッセージ（資源予約解除要求メッセージ）を送信した後、制御部５０は、ステップＳ１７として資源予約解除が成功したか否かを判定する。制御部５０は、ステップＳ１７にて資源予約解除に失敗したと判定した場合は、ステップＳ１８の処理として、表示部５２を制御して資源予約解除の失敗の原因等を表示させ、ステップＳ１の処理に戻り、番組選択のための再度の操作を促す。
【００７４】
一方、制御部５０は、ステップＳ１７にて資源予約解除に成功したと判定した場合、ステップＳ２に戻り、ステップＳ２でクライアントＩ／Ｆの終了が指令されていないと判断すると、ステップＳ３を介してステップＳ７に進み、このステップＳ７において、新たに選択された（ステップＳ１３で選択された）番組の資源予約パラメータが読み出される。以下、制御部５０では、ステップＳ８以降の処理が実行され、これにより別の番組の映像が映像表示部１０６に表示されることになる。本実施の形態では、制御部５０は、このようにして、クライアントＩ／Ｆの映像表示部１０６に表示させる番組を切り換えることができる。
【００７５】
また、制御部５０は、ステップＳ４４において、操作部５１から何らかの指令が入力されたと判定した場合には、ステップＳ５０として１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の何れかが押されたか否かの判断を行い、当該ステップＳ５０にて１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の何れかが押されたと判断した場合には、ステップＳ５１として当該押された設定ボタンに応じてザッピング時間の設定を行った後、ステップＳ１１に戻る。また、制御部５０は、ステップＳ５０にて１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５が押されていないと判断した場合は、ステップＳ４９として、ザッピングモードをＯＦＦにした後、ステップＳ５２の処理に進む。制御部５０は、ステップＳ５２の処理に進むと、ザッピングボタン１０３が押されたか否か判断し、押されたときにはステップＳ１１に戻り、押されていないときにはステップＳ１６の処理に進む。このステップＳ１６の処理に進んだ場合の制御部５０の処理は、上述同様である。
【００７６】
以上のことから、ユーザは、資源の予約またはその解除を意識せずに、テレビジョン受像機のチャンネルを選択する場合と同様に、容易に番組を選択し、視聴することができる。
【００７７】
次に、図８には、サービスデータを提供するビデオサーバ（例えばビデオサーバ３２−１）のＣＰＵ６１の処理手順を説明する。
【００７８】
ビデオサーバのハードディスク６４に保存されているサーバプログラムが起動されている状態において、ＣＰＵ６１は、ステップＳ２１の処理として、通信部６５がＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２からＡＳＰメッセージを受信するまで待機し、ＡＳＰメッセージが受信されると、ステップＳ２２に進む。
【００７９】
ＣＰＵ６１は、ステップＳ２２の処理に進むと、受信したＡＳＰメッセージが資源予約を要求するためのメッセージであるかまたは資源予約解除を要求するためのメッセージであるかを判定し、資源予約を要求するためのメッセージであると判定した場合、ステップＳ２４に進む。
【００８０】
ここで、ネットワークの資源予約は、前述したようにＡＳＰメッセージの送信方向と同じ方向に資源予約が行われる順方向の資源予約と、ＡＳＰメッセージの送信方向とは逆方向に資源予約が行われる逆方向の資源予約がある。ビデオサーバ３２のＣＰＵ６１は、ステップＳ２４の処理に進むと、各ＡＭＩｎｅｔルータから資源予約に成功或いは失敗した旨を示すメッセージを受け取り、このメッセージによって資源予約が成功したか否かを判定する。
【００８１】
ＣＰＵ６１は、ステップＳ２４において資源予約に成功したと判定した場合、ステップＳ２５の処理として、通信部６５を制御して資源予約に成功した旨を表すメッセージを、そして、ステップＳ２６において、ハードディスク６４に記録されているサービスデータ、或いはＩ／Ｏ部６６に接続された機器より出力されるデータを、ＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２に送信させ、その後、ステップＳ２１に戻る。
【００８２】
一方、ステップＳ２４において資源予約に失敗したと判定した場合、ＣＰＵ６１は、ステップＳ２７の処理として、通信部６５を制御して資源予約に失敗した旨を表すメッセージを、ＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２に送信させ、その後、ステップＳ２１に戻る。
【００８３】
また、ＣＰＵ６１は、ステップＳ２２の判定処理において、受信したＡＳＰメッセージが資源予約解除を要求するためのメッセージであると判定した場合、ステップＳ２９に進む。
【００８４】
ネットワークの資源予約の解除は、前述したようにＡＳＰメッセージの方向とは逆方向に行われる逆方向の資源予約解除のみがある。ビデオサーバ３２のＣＰＵ６１は、ステップＳ２９の処理に進むと、各ＡＭＩｎｅｔルータから資源予約解除に成功或いは失敗した旨を示すメッセージを受け取り、このメッセージによって資源予約の解除が成功したか否かを判定する。
【００８５】
ＣＰＵ６１は、ステップＳ２９において資源予約の解除に成功したと判定した場合、ステップＳ３０の処理として、通信部６５を制御して資源予約解除に成功した旨を表すメッセージをＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２に送信させ、その後、ステップＳ２１に戻る。
【００８６】
また、ステップＳ２９において資源予約解除に失敗したと判定した場合、ＣＰＵ６１は、ステップＳ３１の処理として、通信部６５を制御して資源予約解除に失敗した旨を表すメッセージを、ＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２に送信させ、その後、ステップＳ２１に戻る。
【００８７】
次に、上述したＡＭＩｎｅｔにおけるＡＴＭとＩＰの統合によるリアルタイム通信の実現（ATM Control through IP for Rea1‐Time Communication in AMlnet）について説明する。ここでは、ＡＭＩｎｅｔが前提としているバックボーン、および家庭を接続する広域ネットワークで利用される資源予約プロトコルＡＳＰ（AMInet Set-up Protocol）について述べる。本技術は、日本国特許出願  特願平９−２７９８２６号（１９９７年９月２６日出願、出願人は本願と同じ、優先日において未公開）、及び米国特許出願０８／１６０，４７２（１９９８年９月２４日出願、権利継承人は本願と同じ）で開示されている。
【００８８】
ＡＳＰは、ＩＰの柔軟性および適応性、また回線指向型データリンクであるＡＴＭに注目し、それらを統合することによって、高速で柔軟な資源予約を実現する。ＡＳＰは、通常のＡＴＭのシグナリングは利用せす、ＩＰによって転送されるメッセージを利用してＡＴＭ  ＶＣ（Virtual Channel）を動的に確立する。
【００８９】
ＡＳＰ（AMlnet Set up Protocol）は、広域ネットワーク、特にＡＭＩｎｅｔアーキテクチャに基づくルータからなる環境で動作する資源予約プロトコルである。ＡＭＩｎｅｔはＡＴＭスイッチング機能をもつルータからなり、バックボーンルータとその境界にあるエッジルータとから構成されている。予約する資源は、ＡＴＭ  ＶＣ、またはパケット処理時に利用されるキューなどである。特にＡＴＭとの統合の場合、ＡＳＰでは、通常のＡＴＭシグナリングを利用せず、ＡＴＭスイッチまたはＡＴＭ機能をもつルータにおいてＶＣが確立される。また、ＡＳＰでは、ＩＰを使って資源予約のためのセットアップメッセ−ジを転送するので、高速資源予約が実現できる。したがって、ＡＴＭスイッチでは、ＡＴＭのＳＶＣ（Switched Virtual Channel）と呼ばれるＶＣは全く利用せず、ＩＰを利用したメッセージによって、ＶＣを動的に確立する。なお、このようなＶＣのことをＰＶＣ（Permanent VC）オンデマンド（PVC-on‐demand）と呼ぶ。このＰＶＣオンデマンドは、ＡＳＰを利用することによって、通常のＳＶＣとは異なる形態でＶＣを動的に確立、または切断できる。
【００９０】
ＡＳＰを利用する場合でも、データは通常のＩＰで転送される。そこで、ＩＰパケットは、特定の予約された資源にマッピングされる。そのため、今まで利用されてきたアプリケーションから今後出て来る可能性のある新しいアプリケーションにもＡＳＰは簡単に対応できる。このマッピングは、ソースとデスティネーションＩＰアドレス、ソースとデスティネーションポート番号、およびプロトコル識別子フィールドなどを参照することによって行われる。通常のＩＰトラフイック、すなわちベストエフォートトラフィック（ＢＥ）は、予め設定されたデフォルトＢＥ  ＶＣを通して転送される。ＡＳＰを使って予約された資源は、ＢＥトラフィックによって影響されない。また、資源の節約などを考えて１つのＶＣにまとめられたフローも、ＢＥトラフィックに影響されず共存できる。
【００９１】
次に、柔軟なセットアップ機構について説明する。ＡＳＰでは、効率良く資源を利用するために、またはアプリケーションの要求にあった資源予約を行うため、様々な形態で資源を予約できる。すなわち、インターネットやＡＴＭ環境では、様々な種類のアプリケーション、例えば、テレビ会議、遠隔診断、ビデオオンデマンド（ＶｏＤ）、ＭＢｏｎｅを利用するマルチキャストアプリケーションなどの放送型のアプリケーションから、双方向にデータを送信する対話型のアプリケーションがあり、ＡＳＰによれば、何れの場合も、ＱｏＳパラメータを下位層の資源予約パラメータに効率良く、且つスケーラブルにマッピングすることが可能である。
【００９２】
例えば、ＶｏＤの場合、データは必ずサーバからクライアント端末に向かって流れるため、サーバとクライアント端末の間においてＶＣを双方向に確立する必要はない。すなわち、ＡＳＰを用いた場合、ＡＳＰ固有のメッセージのやりとり、アプリケーションが必要とするデータ転送以外の制御のやりとリ（ＶｏＤの場合だと見る映画を途中で変更するためのクライアント端末側からの要求など）、さらに上位層（例えば、トランスポート層）などが必要とするやりとりは、デフォルトＢＥ  ＶＣ又は他の専用ＶＣを利用するだけで実現できる。ＡＳＰメッセージはデフォルトＢＥ  ＶＣまたは指定された専用ＶＣを通して転送される。
【００９３】
一方、対話型であるテレビ会議アプリケーションの場合は、双方向ＶＣが必要であるが、ＡＳＰは一方向だけでなく、この対話型アプリケーションのような双方向のＶＣにも対応している。さらに、対話型アプリケーションの場合、ＡＳＰは上流と下流トラフィックに対して、異なるＱｏＳを設定できる非対象なモデルをサポートする。
【００９４】
また、ＡＳＰではＲＳＶＰまたはＳＴ−２＋（Stream Transport Protocol‐2+）の場合と同様に、資源予約要求は受信側からも可能である上、送信側からの発行も可能である。すなわち、資源予約を行う際に必要なＱｏＳ情報は、アプリケーションまたは環境により、送信側が持っている場合と受信側が持っている場合とがあるが、ＡＳＰはそのどちらの場合でも１パスで全ての予約を行うように設定できる。さらに、ＡＳＰは、必要に応じて予約が完了したことを伝える応答メッセージを持つことも可能である。
【００９５】
図９には、ＡＳＰメッセージとして資源予約を要求するためのメッセージを受信側が発行している例を示す。
【００９６】
これは、ビデオの放送型アプリケーションなどがＡＳＰを利用した場合を表す。すなわち、データは送信側であるサーバ（以下、センダとする）１から受信側であるクライアント端末（以下、レシーバとする）７の方向にしか転送されない。図中のルータ２〜６のうち、ルータ２と６はエッジルータであり、ルータ３，４，５はバックボーンルータである。
【００９７】
レシーバ７は、先ず、ＱｏＳパラメータが解釈され、このコネクションで用いられるＶＰＩ／ＶＣＩを決定し、必要に応じてＡＴＭ  ＮＩＣ（Network lnterface Card）を設定する。また、レシーバ７は、この情報を含むＡＳＰメッセージ（資源予約要求メッセージ）を作成し、バックボーン（バックボーンルータ５）に隣接しているエッジルータ６に向けてこのＡＳＰメッセージを転送する。このＡＳＰメッセ−ジは、ＩＰで転送され、ＩＰのホップ毎に処理される。図９の例の場合、エッジルータ６にメッセージが届くと、当該エッジルータ６では、レシーバ７に向けてＶＰＩ／ＶＣＩパラメータを設定する。ＶＰＩ／ＶＣＩは各ノードで個別に管理されている。このようにＡＳＰメッセージは、センダ１に向かって上流に転送され、各ルータ２乃至６では、このＡＳＰメッセージが転送される方向と逆方向に向けてＶＣが設定（逆方向の資源予約）される。なお、図には示されていないが、センダ１にＡＳＰメッセージが転送され、予約が実質的に完了すると、必要に応じて、センダ１からレシーバ７に対して返答メッセージが転送される。この時点で、最低限バックボーンルータにおいては、センダ１からレシーバ７に向けてＶＣが確立される。すなわち、この図３の構成では、エッジルータを結ぶこのＶＣを利用することによって、データ転送時にＩＰをカットスルーし、ＡＴＭのみで通信できるようになる。
【００９８】
なお、図９はＡＳＰにおける柔軟なセットアップの一形態のみを表している。例えば、センダ１のみがＱｏＳ情報を持っていて、しかもマルチキャストアプリケーションでレシーバ７から資源予約要求を発行する場合は、上記の例の返答メッセージが返る第２パスでＶＣの設定を行うようにメッセージを作成することもでき、さらに、双方向のＶＣを第１パスのみで確立してしまうことも可能となる。
【００９９】
次に、ＡＳＰでは独自のセットアップ機構によりＡＴＭ  ＶＣを確立するので、予め他のＶＣを用意する必要がなく、既に予約された資源のＱｏＳを動的に変更可能となっており、また、アプリケーションは簡単にサービスレベルをアップグレードすることも可能となっている。例えば、単純にＢＥからインテグレーティッドサービス（Integrated Services：ＩＳ）に移行する場合、データフローは、デフォルトＢＥ  ＶＣから図９などに示す新たなＶＣにマップし直すことも容易にできる。
【０１００】
次に、ＱｏＳルーティングとの統合について説明する。ＡＳＰでは、ＶＣセットアップ時にＱｏＳルーティングによる経路選択のサポートが考慮されている。具体的には、資源を予約する時に、従来のＩＰレベルでのルーティングテーブルを利用するのではなく、ＩＳを必要とするフローのための独自ルーティングテーブルを管理するモジュールよリ経路情報の提供を受ける。これにより、ＡＳＰでは、ＱｏＳ要求やネットワークの利用可能な資源状況に合わせて、フロー毎に異なる経路を利用できる。
【０１０１】
また、従来の資源予約プロトコルとルーティング機構はそれぞれ独立したものを前提として考えられてきたが、ＡＳＰではＱｏＳルーティングとの統合を実現している。これは、ＱｏＳルーティングのモジュールに対して、ＡＳＰが保持している資源予約情報をフィードバックすることによって行う。したがって、ＡＳＰでは、予約が失敗した場合の代替経路の選択が容易であり、また、予約する資源をネットワーク中に分散させることができ、１つの経路に資源予約を集中させることなくネットワーク全体を効率良く利用できる。
【０１０２】
次に、ＡＳＰは、一例としてＵＮＩＸのデーモンブロセス（aspd）としてユーザ空間で実装されている。プロトタイプはＦｒｅｅＢＳＤ２．２．１で動作中であり、ＡＴＭスイッチを制御するためのライブラリ（swctl lib）とＡＴＭ  ＮＩＣの設定を行うモジュール（afmap）と統合されている（図１０参照）。現在は、３つのタイプのルータがサポートされており、ホームルータは100Base-T EthernetとＡＴＭインターフェイスをもつ。エッジルータは現在は複数のＡＴＭインターフェイスを持つルータとして実現されている。バックボーンルータは、ＡＴＭスイッチとそれを制御するためのＩＰエンジンを含むＰＣからなる。現在のプロトタイプでは、Adaptec社とEfficient Networks社のＰＣＩバス用ＡＴＭインターフェイスカードと、Fore ASX-200WGＡＴＭスイッチを利用している。ＡＳＰメツセージは、ｒａｗＩＰを使って実装されている。
【０１０３】
バックボーンルータは、装備されているスイッチにおいてＰＶＣオンデマンド（PVC-on-demand）を設定するため前述したスイッチ制御ライブラリを利用する。ＩＳを必要とするＩＰフローはＣＢＲ（Constant Bit Rate）のＶＣにマッピングされる。また、現在、ＡＳＰはＡＴＭスイッチで一対多のマルチキャストＶＣを作成することによって、マルチキャストに対応している。さらに、ＡＳＰは、リーフによるジョイン、および資源予約もサポートしている。
【０１０４】
なお、ＶＣＩなどの識別子をはじめとするＡＴＭ資源のスケーラビリティを考慮すると、ＩＰフローをアプリケーション単位でＶＣにマッピングすることは効率が悪いが、この場合は、ＡＳＰを利用することにより、動的にフローをＶＣにまとめることが容易になる。
【０１０５】
以上、ＡＭＩｎｅｔにおける資源予約プロトコルＡＳＰについて述べており、ＡＳＰは独自のセットアップ機構を導入し、ＩＰの柔軟性とＡＴＭのＶＣによるＱｏＳ保証を統合している。したがって、ＡＭＩｎｅｔでは、動的ＱｏＳ変更、ＱｏＳルーティングとの統合、柔軟なセットアップを実現し、プロトタイプ実装により高速セットアップを実現できる。
【０１０６】
次に、ＡＭＩｎｅｔにおける資源予約を行うためのプロトコルであるＡＳＰ（AMInet Set-up Protocol）の詳細について説明する。なお、この場合のセットアップ（set-up）とは、資源予約を行うときに、レシーバおよびセンダ、または経路中経由するルータにおいて、資源予約のために状態／情報を設定することを意味する。
【０１０７】
ＡＳＰは、回線交換機能をもつ下位層のＶＣ、またはパケットスケジューラが提供することのできるキューの割り当て（ＣＢＱ（Class Based Queueing）のクラスなど）を資源として抽象化し、ＩＰネットワークに流れるデータが他のデータに影響なく転送されるように対応付けを行う。一具体例として、ＡＳＰではＡＴＭのＶＣおよびＵＰＣ（Usage Parameter Control）によって制御される資源として抽象化し、その資源を予約し、ＩＰのフローにそのＶＣを対応させる。なお、ここでのフローとは、以下の情報を表す。すなわち、アドレスファミリー（address family）、プロトコル識別子であるプロトコル（protocol）、レシーバのＩＰアドレスであるデスティネーションＩＰアドレス（destination IP address）とセンダのＩＰアドレスであるソースＩＰアドレス（source IP address）、レシーバのポートアドレス（destination port address）とセンダのポートアドレス（source port address）などである。
【０１０８】
ＡＳＰのセットアップ、すなわち、ＡＳＰのプロトコルメッセージのやりとりは、ＩＰの上に実装される。従って、ＡＴＭのＶＣなどをオンデマンドで作成する場合は、実際にＡＴＭが用意しているシグナリング機構を利用する必要はなく、この制約がないので柔軟でかつ効率の良い資源予約が可能となる。
【０１０９】
また、ＡＳＰは、主にＲＳＶＰやＳＴ−２などと同等な機能を持つが、柔軟にＡＴＭのＶＣに対応し、次のような機能を有する。すなわち、資源の予約は、レシーバ側主導およびセンダ側主導の何れも可能であること、ハードステートおよびソフトステートの何れも可能であること、ＡＴＭのＶＣを考慮した柔軟なセットアップが可能であること、プロトコル制御（予約制御）専用帯域（資源）の割り当てが可能であることなどの機能を有する。
【０１１０】
図１１は、ＡＳＰのヘッダのフォーマットの例を表している。図１１中のフラグ（flags）フィールドには、資源を予約する方向が単方向であるか双方向であるかを指示する情報がセットされる。prev_hopフィールドには、メッセージのやりとりがレシーバとセンダとで往復する場合に、メッセージが同一経路を通るようにするための情報がセットされる。次のＶＰＩフィールドには、ＶＰＩ（Virtual Path Identifier）がセットされ、ＶＣＩフィールドには、ＶＣＩ（Virtual Channel Identifier）がセットされる。
【０１１１】
その次のフィールドに、上記フローの情報（flowinfo）がセットされる。このフローの情報は、レングス（length）、アドレスファミリー（address family）、リザーブ（reserved）、プロトコル識別子であるプロトコル（protocol）、レシーバのＩＰアドレスであるデスティネーションＩＰアドレス（destination IP address）とセンダのＩＰアドレスであるソースＩＰアドレス（source IP address）、レシーバのポートアドレス（destination port address）とセンダのポートアドレス（source port address）などである。
【０１１２】
その後に、センダのフロースペック（s_flowspec）とレシーバのフロースペック（r_flowspec）がセットされる。センダのフロースペック（s_flowspec）は、センダが送るデータに必要なＱｏＳを示し、レシーバのフロースペック（r_ftowspec）は、レシーバが送るデータに必要なＱｏＳを示している。現在のプロトタイプでは、各々のフロースペックフィールドには、ＡＴＭのＣＢＲ（Constant Bit Rate）サービスを設定するためのピークセルレート（Peak Cell Rate）が含まれるのみである。
【０１１３】
主にＡＳＰを実装する形態のルータとしては、図１２に示すようなバックボーンルータ（backbone router）、図１３に示すようなエッジルータ（edge router）、およびホームルータがある。これらに加えて、エンドホストもＡＳＰメッセージのやりとりをする必要がある。
【０１１４】
バックボーンルータ１４は、大規模なネットワークを構成するための中間ノードであって、その実体はＴＣＰ／ＩＰを理解するソフトウェアエンジン（IP engine）１５、およびＶＣ機構を提供するスイッチ部（例えばＡＴＭ  ＳＷ）（switching engine）１６から構成される。すなわち、この場合は、バックボーンルータ同士が接続されることにより、ＩＰネットワークが構築されるが、ＶＣを設定することにより、カットスルーも可能となる。
【０１１５】
エッジルータ８１は、複数のバックボーンルータから構成される網に対する入出口に設置される。バックボーンに対する反対側には、他のネットワーク、または他のルータが接続される可能性がある。エッジルータ８１は、通常のＩＰのプロトコルスタックを持ち、１つ以上のＡＴＭインターフェイス８２乃至８４を有する。
【０１１６】
図１４は、ネットワーク全体の接続例を示している。同図に示すように、大容量のデータをネットワークに流すサーバ（センダ）９１，９７が、複数のバックボーンルータ１４からなるバックボーン９２に直接接続されていても構わないが、通常のエンドノード９４乃至９６は、エッジルータ９３を介してバックボーン９２に接続される。また、エッジルータ９３の先には、更にルータを設置することが可能である。エンドノード（レシーバ）９４は、ＡＴＭインターフェイス９４ａを介してエッジルータ９３に接続されている。エンドノード（レシーバ）９５は、ＡＴＭインターフェイス９５ａを介してエッジルータ９３に接続されている。エンドノード（レシーバ）９６は、ＡＴＭインターフェイス９６ａを介してエッジルータ９６に接続されている。
【０１１７】
ここで、ＡＳＰにとって重要なのは、各ルータで予約する資源、およびその方法である。バックボーンルータでは、スイッチ内のＶＣの設定が必要である。
【０１１８】
また、バックボーンルータ９２は、バックボーンにデータが流れる入り口において、特定のフローを新たに作成したＶＣ（資源）に対してマッピングする必要がある。ＶＣに対するマッピングはエッジルータが行う。サーバが直接バックボーンに接続されている場合は、そのノードのバックボーンに対するＡＴＭインターフェイスがＶＣに対するマッピングを行う必要がある。
【０１１９】
各ノードのＡＳＰモジュールには、図１５に示すような資源の予約状況を管理するための状態テーブルが維持される。
【０１２０】
このテーブルは、入力用のＶＣの情報と出力用のＶＣの情報を管理し、ＶＣとフロー情報（flowinfo）を対応付けている。また、エッジルータの場合は、入力用と出力用のネットワークインターフェイスの情報も必要であるので、そのためのフィールドを設けるようにしている。この場合、対応するＶＣ情報のポート（port）部は利用されなくなる。
【０１２１】
通常の通信、例えばＩＰの通信を行うためには、ＡＴＭのＶＣは双方向に作成する必要がある。しかし、ＡＳＰを用いることにより、柔軟にＶＣを確立することができる。
【０１２２】
アプリケーションによっては、通信が単方向であったり、双方向のものが存在する。例えば、ＶｏＤ（Video on Demand）形式のアプリケーションの場合は、ビデオデータはサーバ（センダ）からクライアント端末（レシーバ）までの単方向にしか流れないが、例えばレシーバが画像の要求を行う場合などのようにサーバに向かう通信は起こり得る。すなわちこの場合は、例えば資源予約メッセージは、ＡＳＰに要求することによって資源予約メッセージが専用のＶＣを通してやりとりされる。また、それ以外の必要なやりとりは、デフォルトデータＶＣ（通常のＩＰの経路）を流れる。従って、このような場合においては、ＡＳＰに資源を要求するアプリケーションは、単方向通信を指定することによって単一方向のみのＶＣを張るだけで済み、識別子、およびバンド幅を節約することができる。また、放送側マルチキャストの場合の資源予約も、このような予約方式で十分実現可能である。
【０１２３】
ただし、ビデオコンファレンスなどの対話型のアプリケーションの場合は、双方向にデータが流れる。双方向にデータが流れる必要があることは、通常の通信と変わりがないが、ＡＳＰを用いた場合、アプリケーションは、各方向に流れるデータに対して各々異なるＱｏＳを設定することができる。各方向のデータの流れに対するＱｏＳの設定は、ＡＳＰヘッダ内にある２つのフロースペック（flowspec）フィールドの値（s_flowspecとr_flowspec）に基づいて行われる。何れかのフロースペックフィールドにヌル（NULL）値が含まれる場合、その方向のＶＣの予約は行われない。
【０１２４】
図１６は、レシーバ４７がＱｏＳを知っている場合、単方向のＶＣが確立される手順を示している。なお、ルータ４２，４６はエッジルータ、ルータ４３，４４，４５はバックボーンルータである。すなわち、レシーバ４７は、ＡＳＰヘッダのフラグ（flags）フィールドに、ＶＣを確立する方向が単方向であることを示す例えば値０をセットし、ＡＳＰヘッダのセンダのフロースペック（s_flowspec）フィールドにＶＣのバンド幅（例えば、５Ｍｂｐｓ（メガビット／秒））等を表す情報を設定し、センダ４１に送信する。ＡＳＰのメッセージがレシーバ４７からセンダ４１に流れていくと、各ルータでは、ＡＳＰメッセージが流れる方向とは逆方向にＶＣを確立していく。
【０１２５】
先ず、エッジルータ（edge router）４６は、ＡＳＰメッセージが流れる方向とは逆方向のＶＣを確立する。同様に、ＶＣは、バックボーンルータ（backbone router）４５，４４，４３、エッジルータ４２により、それぞれＡＳＰメッセージが流れる方向とは逆方向に確立されていく。
【０１２６】
このとき、バックボーンルータ４３乃至４５を構成するスイッチングエンジンＳＷ（switching engine）においては、それぞれ所定の入力ポートと出力ポートが結ばれ、上記ＶＣが確立される。
【０１２７】
図１７は、センダしかＱｏＳを知らない場合にＶＣが張られていく手順を示している。
【０１２８】
先ず、レシーバ４７は、ＡＳＰヘッダのセンダのフロースペック（s_flowspec）フィールドにヌル（NULL）値を設定したＡＳＰメッセージをセンダ４１に送信し、ＶＣの確立を要求する。このＡＳＰメッセージを受け取ったセンダ４１は、このメッセージを解釈し、ＡＳＰヘッダのセンダのフロースペック（s_flowspec）フィールドに所定のバンド幅に対応する値をセットしたＡＳＰメッセージをレシーバ４７に返送する。各ルータは、このＡＳＰメッセージが流れる方向と同一の方向にＶＣを張ることになる。すなわち、ＶＣは、エッジルータ４２、バックボーンルータ４３，４４，４５、エッジルータ４６により、それぞれＡＳＰメッセージが流れる方向と同一の方向に張られていく。
【０１２９】
図１８は、センダ４１が予約を開始する場合にＶＣが張られていく手順を示している。この場合も、ＡＳＰメッセージは一方方向に流れ、ルータはＶＣを確立していく。すなわち、センダ４１は、ＡＳＰヘッダのセンダのフロースペック（s_flowspec）フィールドに所定のバンド幅に対応する値をセットしたＡＳＰメッセージをレシーバ４７に送信する。
【０１３０】
このＡＳＰメッセージに基づいて、先ず、エッジルータ４２は、ＡＳＰメッセージが流れる方向と同一方向にＶＣを確立する。次にＶＣは、バックボーンルータ４３，４４，４５、エッジルータ４６の順で確立されていく。
【０１３１】
また、大抵の場合、予約が終了したことを確認しないとセンダはデータを送ることができないので、この後、図示はしていないが、確認のためのＡＳＰメッセージがレシーバ４７からセンダ４１に向かって送られる。
【０１３２】
図１９は、センダ、レシーバの各々が自分がデータを送信するときに必要とするＱｏＳを知っている場合において、双方向通信が行われる手順を示している。この場合は、各方向にＡＳＰメッセージ（資源予約要求メッセージ）が流れると、各方向にＶＣが張られていく。
【０１３３】
すなわち、センダ４１は、ＡＳＰヘッダのセンダのフロースペック（s_flowspec）フィールドに下り方向（センダ４１からレシーバ４７に向かう方向）のＶＣのバンド幅に対応する値をセットしたＡＳＰメッセージをレシーバ４７に送信する。これにより、エッジルータ４２、バックボーンルータ４３，４４，４５、エッジルータ４６においては、この順で、ＡＳＰメッセージが流れる方向と同一方向である下り方向のＶＣが確立されていく。
【０１３４】
一方、レシーバ４７は、ＡＳＰヘッダのレシーバのフロースペック（r_flowspec）フィールドに上り方向（レシーバ４７からセンダ４１に向かう方向）のＶＣのバンド幅に対応する値をセットしたＡＳＰメッセージをセンダ４１に送信する。これにより、エッジルータ４６、バックボーンルータ４５，４４，４３、エッジルータ４２においては、この順で、ＡＳＰメッセージが流れる方向と同一方向である上り方向のＶＣが確立されていく。
【０１３５】
また、図２０に示すように、センダおよびレシーバの各々が自分がデータを受信するときに必要とするＱｏＳを知っている場合においては、図１９に示した場合とは逆に、各方向にＡＳＰメッセージ（資源予約要求メッセージ）が流れると、各ＡＳＰメッセージが流れる方向とは逆の方向にＶＣが張られていく。
【０１３６】
すなわち、センダ４１は、ＡＳＰヘッダのレシーバのフロースペック（r_flowspec）フィールドに上り方向（レシーバ４７からセンダ４１に向かう方向）のＶＣのバンド幅に対応する値をセットしたＡＳＰメッセージをレシーバ４７に送信する。これにより、エッジルータ４２、バックボーンルータ４３，４４，４５、エッジルータ４６においては、この順で、ＡＳＰメッセージが流れる方向とは逆の方向である上り方向のＶＣが確立されていく。
【０１３７】
一方、レシーバ４７は、ＡＳＰヘッダのセンダのフロースペック（s_flowspec）フィールドに下り方向（センダ４１からレシーバ４７に向かう方向）のＶＣのバンド幅に対応する値をセットしたＡＳＰメッセージをセンダ４１に送信する。これにより、エッジルータ４６、バックボーンルータ４５，４４，４３、エッジルータ４２においては、この順で、ＡＳＰメッセージが流れる方向とは逆の方向である下り方向のＶＣが確立されていく。
【０１３８】
図２１は、レシーバが双方向の通信に必要とされるＱｏＳを知っている場合にＶＣが確立される手順を示している。この場合、双方向のＶＣの作成は１つの資源予約要求メッセージで行われる。
【０１３９】
すなわち、レシーバ４７は、ＡＳＰヘッダのフラグ（flags）フィールドに、ＶＣを確立する方向が双方向であることを示す例えば値１をセットする。そして、ＡＳＰヘッダのセンダのフロースペック（s_flowspec）フィールドに下リ方向のＶＣのバンド幅に対応する値をセットし、レシーバのフロースペック（r_flowspec）フィールドに上り方向のＶＣのバンド幅に対応する値をセットし、そのＡＳＰヘッダを含むＡＳＰメッセージをセンダ４１に送信する。これにより、先ず、エッジルータ４６においては、レシーバのフロースペック（r_flowspec）フィールドに設定されたバンド幅を有する上り方向のＶＣ、およびセンダのフロースペック（s_flowspec）フィールドに設定されたバンド幅を有する下り方向のＶＣが確立される。次に、バックボーンルータ４５，４４，４３、エッジルータ４２においては、この順で、レシーバのフロースペック（r_flowspec）フィールドに設定されたバンド幅を有する上り方向のＶＣ、およびセンダのフロースペック（s_flowspec）フィールドに設定されたバンド幅を有する下り方向のＶＣがそれぞれ確立されていく。
【０１４０】
このように、ＡＳＰは、様々な方法でＶＣを確立することができ、また、上位レイヤがこれらの方法を選択することができるようになっているので、効率の良い、また、アプリケーションに適したセットアップを可能とすることができる。
【０１４１】
以上は、ＡＴＭとＩＰを統合化して、ＡＴＭシグナリングを利用しないで、オンデマンドにＶＣをセットアップするＡＳＰについて説明した。
【０１４２】
ここでは、それに加えて、ＡＳＰの機能を用いて、ＶＣ（資源）とフローの開係を動的に変更する機構について説明する。現在、ＶＣに対するデータは、エッジルータからレシーバまで潜ること、すなわちカットスルー（cut through）することになる。従って、ＶＣに対するデータは、複数のバックボーンルータのスイッチを経由して、レシーバ側のエッジルータまでＡＴＭのＶＣを直接経由していく。
【０１４３】
エッジルータでデータが潜ることに注目すると、ここにフィードバックがかかるようにＡＳＰメッセージを発行するようにすれば、すでに作成されているＶＣに他のＶＣを利用している既存の通信を、通信に影響がないように移行させることができる。すなわち、通信中に、バックボーンに対する入口においては、ＶＣを変更させ、途中経路などを動的に変更することができる。
【０１４４】
以下、この機構をＡＳＰに組み込むことによって生じる利点について説明する。この機構は、ＡＳＰに限定されるものではなく、ＲＳＶＰなどと達動させる場合にも有効に利用できる。
【０１４５】
例えば、ＡＴＭシグナリングの場合は、ＶＣのセットアップが完了すると、その経路を変更するのは難しい。これは、ＶＣをエンドツーエンドで再度張らなければならないからである。一方、ＲＳＶＰは、丈夫（robust）で環境に適応することを利点として挙げているが、結局、現在のＩＰルーティングに従うと、経路が変わってしまうので、実時間通信には適切ではない場合がある。これを解決するために、ＲＳＶＰはルートピニング（route pinning）を導入し、明示的に予約された経路に対して、ルーティングによる変更を許可しないように設定することができるようになっている。
【０１４６】
この方法を利用することにより、通信が継続中であっても、経路を簡単に変更できるようになる。また、通常は経路は変更されないが、ＱｏＳルーティング（routing）などを導入することによって、経路変更を許可することも簡単にできる。
【０１４７】
また、この方法によれば、通信している最中にレシーブされたフロー（flow）を所定のＶＣにまとめることができ、ＶＣＩなどの資源を節約することができる。
【０１４８】
さらに、この方法によれば、ある組織、アプリケーションなどのリザベーション（reservation）をまとめることができる。
【０１４９】
また、この方法によれば、所定のデスティネーションに対して複数の通信路があり、新規セッションなどの通信がある程度の資源容量を必要とする場合、他のセッションの経路／資源を集めることができる。
【０１５０】
また、この方法によれば、通信中のセッションの資源予約状況を動的に変更することができる。
【０１５１】
ここでは、特に、エッジルータに注目しているが、この機構はバツクボーンルータにおいても実現可能である。実装としては、注目しているフロー（flow）をリマップ（remap）するためのＶＣの準備が整った後、エッジルータで高速にこの切リ替えを行う。同等なことは、バックボーンルータで行っても構わないが、そのために必要とする情報を収集することがより困難であって、且つこのような機構を設けてバックボーンルータ自身の機能を複雑化することは望ましくない。
【０１５２】
エッジルータの場合は、末端側で集約している端末、またはホームルータなどの数をある程度把握することは可能であるので、それに応じた適切なルーティングを行うことができ、バックボーンルータよりも情報収集が限定されて簡単になる。
【０１５３】
この方法では、エッジの操作によって、流れるデータに影響があるということを注意しなければならない。先ず、センダ側のＶＣを切り替えることによって、送信するデータにロスが生じる可能性がある。
【０１５４】
また、レシーバ側のエッジでは、一時的に２つのＶＣからデータが送信されることになるので、受信側はデータを重複して受け取る可能性がある。
【０１５５】
このような点において、データの正当性を保証するために、信頼性の高いトランスポートプロトコルを利用することが望ましい。
【０１５６】
なお、上記実施の形態においては、ＶＣを予約する場合について説明したが、ＵＰＣ（Usage Parameter Control）等の他の資源を予約する場合にも本発明を適用することができる。
【０１５７】
この例においては、ＩＰアドレスとソケットポート番号を組み合わせることより、サーバまたはクライアント端末を特定するようにしたが、他の方法を利用することもできる。
なお、上記したような処理を行うコンピュータプログラムをユーザに提供する提供媒体としては、磁気ディスク、ＣＤ−ＲＯＭ、固体メモリなどの記録媒体の他、ネットワーク、衛星などの通信媒体を利用することができる。
【０１５８】
上述したような本発明の実施の形態によれば、サービスが選択されると、資源予約および資源予約解除に必要な処理を行うするようにしたので、ユーザが意識することなく、資源の予約またはその解除を行うことができる。
【０１５９】
なお、本発明は上述した実施の形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。
【図面の簡単な説明】
【０１６０】
【図１】本発明を適用したクライアント端末のネットワークの構成例を表す図である。
【図２】クライアント端末の内部の構成例を表す図である。
【図３】ビデオサーバの内部の構成例を表す図である。
【図４】クライアントＩ／Ｆの画面の表示例を表す図である。
【図５】クライアント設定ファイルに設定されているデータ（資源予約パラメータ）の一例を表す図である。
【図６】クライアント端末の動作例を説明するためのフローチャートである。
【図７】クライアントＩ／Ｆの画面の他の表示例を表す図である。
【図８】ビデオサーバの動作例を説明するためのフローチャートである。
【図９】資源予約要求メッセージを受信側が発行している様子の説明に用いる図である。
【図１０】ＡＳＰの一構成例を示す図である。
【図１１】ＡＳＰのヘッダのフォーマットの一例を示す図である。
【図１２】バックボーンルータの構成例を示す図である。
【図１３】エッジルータの構成例を示す図である。
【図１４】ネットワークの構成例を示す図である。
【図１５】ＡＳＰ内部テーブルを示す図である。
【図１６】レシーバがＱｏＳを知っている場合のＡＳＰメッセージの流れと単方向のＶＣが確立されるまでの手順の説明に用いる図である。
【図１７】センダしかＱｏＳを知らない場合のＡＳＰメッセージの流れと、ＶＣが張られていく手順の説明に用いる図である。
【図１８】センダが予約を開始する場合のＡＳＰメッセージの流れと、ＶＣが張られていく手順の説明に用いる図である。
【図１９】センダ、レシーバの各々がＱｏＳを知っている場合の双方向通信が行われる手順の説明に用いる図である。
【図２０】センダおよびレシーバの各々がＱｏＳを知っている場合の各ＡＳＰメッセージの流れと、その逆方向にＶＣが張られていく手順の説明に用いる図である。
【図２１】レシーバが双方向の通信に必要とされるＱｏＳを知っている場合にＶＣが確立される手順の説明に用いる図である。
【符号の説明】
【０１６１】
１１，１２  クライアント端末、２１，２２  ルータ、２２  ネットワーク、３２  ビデオサーバ、５０  制御部、５１  操作部、５２  表示部、５３  通信部、５４  データベース
【図１】
2008029019.tif 000003
【図２】
2008029019.tif 000004
【図３】
2008029019.tif 000005
【図４】
2008029019.tif 000006
【図５】
2008029019.tif 000007
【図６】
2008029019.tif 000008
【図７】
2008029019.tif 000009
【図８】
2008029019.tif 000010
【図９】
2008029019.tif 000011
【図１０】
2008029019.tif 000012
【図１１】
2008029019.tif 000013
【図１２】
2008029019.tif 000014
【図１３】
2008029019.tif 000015
【図１４】
2008029019.tif 000016
【図１５】
2008029019.tif 000017
【図１６】
2008029019.tif 000018
【図１７】
2008029019.tif 000019
【図１８】
2008029019.tif 000020
【図１９】
2008029019.tif 000021
【図２０】
2008029019.tif 000022
【図２１】
2008029019.tif 000023