(57)【特許請求の範囲】
【請求項１】
情報配信装置から通信コネクションを介してコンテンツ情報を受信する情報受信装置において、
前記通信コネクションを介した通信を行う通信手段と、
前記通信手段を制御する制御手段と、
前記通信手段より受信した前記コンテンツ情報に基づく処理を実行する実行手段とを備え、
前記制御手段は、第１のコンテンツ情報の受信中に受信対象コンテンツの切り換えを要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１の通信コネクションとは異なる第２のコネクションを確立させた後、当該第２の通信コネクションにより第２のコンテンツ情報の受信を開始させ、前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報及び前記第２の通信コネクションの確立を要求する第２の情報の双方を含む通信予約メッセージを前記通信手段に送信させる
情報受信装置。
【請求項２】
前記制御手段は、前記通信コネクションの形成に先立ち、前記通信予約メッセージとして、通信網の通信帯域資源の予約を行う予約指令情報を含むメッセージを送信させる請求項１記載の情報受信装置。
【請求項３】
前記制御手段は、
（ａ）受信する前記コンテンツ情報が必要とする前記通信帯域資源を前記制御手段が認識している場合は、前記予約指令情報に前記通信帯域資源を示す資源情報を含めて、前記通信予約メッセージを送信させる一方、
（ｂ）受信する前記コンテンツ情報が必要とする前記通信帯域資源を前記制御手段が認識していない場合は、前記予約指令情報に前記資源情報を含まずに前記通信予約メッセージを送信させる請求項２記載の情報受信装置。
【請求項４】
前記コンテンツ情報を通信するために必要となる通信帯域資源の予約に使用する所定の資源情報を記憶する記憶手段をさらに備え、
前記制御手段は、前記記憶手段に記憶されている前記所定の資源情報を含めて、前記コネクションを形成する際の前記第２の情報を生成する請求項１記載の情報受信装置。
【請求項５】
前記記憶手段は、前記所定の資源情報として、少なくとも１対１或いは１対多にて配信される前記コンテンツ情報を通信するために必要となる通信帯域資源の予約に使用する情報を記憶する請求項４記載の情報受信装置。
【請求項６】
情報配信装置から通信コネクションを介してコンテンツ情報を受信する情報受信装置において、
前記通信コネクションを介した通信を行う通信手段と、
前記通信手段を制御する制御手段と、
前記通信手段より受信した前記コンテンツ情報に基づく処理を実行する実行手段とを備え、
前記制御手段は、第１のコンテンツ情報の受信中に受信対象コンテンツの切り換えを要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１の通信コネクションとは異なる第２のコネクションを確立させた後、当該第２の通信コネクションにより第２のコンテンツ情報の受信を開始させ、前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報を含む通信開放メッセージ、及び前記第２の通信コネクションの確立を要求する第２の情報を含む通信予約メッセージを、各々独立のメッセージとして、または１つのメッセージとして、前記通信手段に送信させ、
前記制御手段は、予め設定された時間間隔で、現在受信中のコンテンツ情報の前記コネクションの切断を指示する前記第１の情報を出力した後、予め設定された順番のコンテンツ情報を通信するための前記コネクションの形成を指示する前記形成指令を出力するよう制御する
情報受信装置。
【請求項７】
情報配信装置から通信コネクションを介してコンテンツ情報を受信する際の情報受信方法において、
前記通信コネクションを介した通信を行う通信ステップと、
前記通信を制御する制御ステップと、
前記通信ステップにおいて受信した前記コンテンツ情報に基づく処理を実行するステップとを備え、
前記制御ステップは、第１のコンテンツ情報の受信中に受信対象コンテンツの切替を要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１のコネクションとは異なる第２のコネクションを確立させた後、当該第２のコネクションにより第２のコンテンツ情報の受信を開始させ、
前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報及び前記第２の通信コネクションの確立を要求する第２の情報の双方を含む通信予約メッセージを前記通信ステップにて送信させる
情報受信方法。
【請求項８】
前記制御ステップは、前記コネクションの形成に先立ち、前記通信予約メッセージとして、前記通信網の通信帯域資源の予約を行う予約指令情報を含むメッセージを送信させる請求項７記載の情報受信方法。
【請求項９】
前記制御ステップは、
（ａ）受信する前記コンテンツ情報が必要とする前記通信帯域資源を制御手段が認識している場合は、前記予約指令情報に前記通信帯域資源を示す資源情報を含めて、前記通信予約メッセージを送信させる一方、
（ｂ）受信する前記コンテンツ情報が必要とする前記通信帯域資源を制御手段が認識していない場合は、前記予約指令情報に前記資源情報を含まずに前記通信予約メッセージを送信させる請求項８記載の情報受信方法。
【請求項１０】
前記コンテンツ情報を通信するために必要となる通信帯域資源の予約に使用する所定の資源情報を記憶する記憶ステップをさらに備え、
前記制御ステップでは、前記記憶ステップにて記憶している前記所定の資源情報を含めて、前記コネクションを形成する際の前記第２の情報を生成する請求項７記載の情報受信方法。
【請求項１１】
前記記憶ステップでは、前記所定の資源情報として、少なくとも１対１或いは１対多にて配信される前記コンテンツ情報を通信するために必要となる通信帯域資源の予約に使用する情報を記憶する請求項１０記載の情報受信方法。
【請求項１２】
情報配信装置から通信コネクションを介してコンテンツ情報を受信する際の情報受信方法において、
前記通信コネクションを介した通信を行う通信ステップと、
前記通信を制御する制御ステップと、
前記通信ステップにおいて受信した前記コンテンツ情報に基づく処理を実行するステップとを備え、
前記制御ステップは、第１のコンテンツ情報の受信中に受信対象コンテンツの切替を要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１のコネクションとは異なる第２のコネクションを確立させた後、当該第２のコネクションにより第２のコンテンツ情報の受信を開始させ、
前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報を含む通信開放メッセージ、及び前記第２の通信コネクションの確立を要求する第２の情報を含む通信予約メッセージを、各々独立のメッセージとして、または１つのメッセージとして、前記通信ステップにて送信させ、
前記制御ステップでは、予め設定された時間間隔で、現在受信中のコンテンツ情報の前記コネクションの切断を指示する前記第１の情報を出力した後、予め設定された順番のコンテンツ情報を通信するための前記コネクションの形成を指示する前記形成指令を出力するよう制御する
情報受信方法。
【請求項１３】
通信コネクションを介してコンテンツ情報を受信する情報受信装置に接続され、コンテンツ情報の配信に先だって予約された通信網の通信帯域資源を用いて前記情報受信装置に前記コンテンツ情報を配信する情報配信装置において、
前記通信コネクションを介した通信を行う通信手段と、
前記コンテンツ情報を記憶する記憶手段と、
前記情報受信装置より前記通信手段が指令信号を受信したとき、受信した前記指令信号に前記通信帯域資源を示す資源情報が含まれるか否かを検出する検出手段と、
前記検出手段の検出結果に基づいて、前記通信帯域資源を予約する帯域予約命令を出力し、前記情報受信装置に前記コンテンツ情報を出力するように前記通信手段を制御する第１のモードと、前記資源情報で示される前記通信帯域資源を用いて前記コンテンツ情報を出力するように前記通信手段を制御する第２のモードとを選択するよう制御する制御手段とを備え、
前記制御手段は、前記指令信号に前記資源情報が含まれない場合は前記第１のモードを、前記指令信号に前記資源情報が含まれる場合は前記第２のモードを選択するよう制御する
情報配信装置。
【請求項１４】
情報配信装置と、前記情報配信装置から通信コネクションを介してコンテンツ情報を受信する情報受信装置を備え、前記コンテンツ情報の通信に先立って予約された通信網の通信帯域資源を用いて、前記情報配信装置と前記情報受信装置が前記コンテンツ情報を通信する情報通信システムにおいて、
前記情報配信装置は、前記通信コネクションを介した通信を行う配信通信手段と、前記コンテンツ情報を記憶する記憶手段と、
前記コンテンツ情報を出力するように前記配信通信手段を制御する配信制御手段とを備え、
前記情報受信装置は、
前記通信コネクションを介した通信を行う通信手段と、
前記通信手段を制御する制御手段と、
前記通信手段より受信した前記コンテンツ情報に基づく処理を実行する実行手段とを備え、
前記制御手段は、第１のコンテンツ情報の受信中に受信対象コンテンツの切り換えを要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１の通信コネクションとは異なる第２のコネクションを確立させた後、当該第２の通信コネクションにより第２のコンテンツ情報の受信を開始させ、前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報及び前記第２の通信コネクションの確立を要求する第２の情報の双方を含む通信予約メッセージを前記通信手段に送信させる
情報通信システム。
【請求項１５】
前記情報配信装置と前記情報受信装置の間に中継装置をさらに備え、
前記中継装置は、前記配信制御手段及び前記受信制御手段からの指令に基づいて、前記通信帯域資源を予約する請求項１４記載の情報通信システム。
【請求項１６】
前記中継装置は、前記情報配信装置から前記情報受信装置への通信に用いる前記通信帯域資源を予約する請求項１５記載の情報通信システム。
【請求項１７】
情報配信装置と、前記情報配信装置から通信コネクションを介してコンテンツ情報を受信する情報受信装置を備え、前記コンテンツ情報の通信に先立って予約された通信網の通信帯域資源を用いて、前記情報配信装置と前記情報受信装置が前記コンテンツ情報を通信する情報通信システムにおいて、
前記情報配信装置は、
前記通信コネクションを介した通信を行う配信通信手段と、前記コンテンツ情報を記憶する記憶手段と、
前記コンテンツ情報を出力するように前記配信通信手段を制御する配信制御手段と、
前記情報受信装置より前記配信通信手段が指令信号を受信したとき、受信した前記指令信号に前記通信帯域資源を示す資源情報が含まれるか否かを検出する検出手段とを備え、
前記情報受信装置は、
前記通信コネクションを介した通信を行う通信手段と、
前記通信手段を制御する制御手段と、
前記通信手段より受信した前記コンテンツ情報に基づく処理を実行する実行手段とを備え、
前記配信制御手段は、前記検出手段の検出結果に基づいて、前記指令信号に前記資源情報が含まれない場合は、前記通信帯域資源を予約する帯域予約命令を出力し、前記情報受信装置に前記コンテンツ情報を出力するように前記通信手段を制御する第１のモードと、前記指令信号に前記資源情報が含まれる場合は、前記資源情報で示される前記通信帯域資源を用いて前記コンテンツ情報を出力するように前記通信手段を制御する第２のモードと、を選択するよう制御し、
前記制御手段は、第１のコンテンツ情報の受信中に受信対象コンテンツの切り換えを要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１の通信コネクションとは異なる第２のコネクションを確立させた後、当該第２の通信コネクションにより第２のコンテンツ情報の受信を開始させ、
前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報を含む通信開放メッセージ、及び前記第２の通信コネクションの確立を要求する第２の情報を含む通信予約メッセージを、各々独立のメッセージとして、または１つのメッセージとして、前記通信手段に送信させる
情報通信システム。
【請求項１８】
前記配信制御手段は、
前記情報受信装置から前記通信開放メッセージおよび前記通信予約メッセージを受信すると、前記第１の通信コネクションに利用するための資源予約を解除する処理を行った後に、前記第２の通信コネクション確立に向けた前記第１のモードまたは前記第２のモードによる前記通信手段の制御を行う請求項１７記載の情報通信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報受信装置及び方法、情報配信装置、情報通信システムに関し、特に、ユーザが意識することなく、資源を予約または開放することができるようにした情報受信装置及び方法、情報配信装置、情報通信システムに関する。
【０００２】
【従来の技術】
例えば、各家庭まで敷設された光ファイバーケーブルを介して、電話やＩＳＤＮなど各種の通信サービスを提供するＦＴＴＨ（Ｆｉｂｅｒ ｔｏ ｔｈｅ Ｈｏｍｅ）技術の進歩により、近い将来、ユーザは、家庭でも高速ネットワークを利用できるようになると考えられている。このような環境下で普及すると予想されるデータ配信サービス、例えば、インターネットテレビジョンサービス（以下、インターネットＴＶと略称する）や、インターネットビデオオンデマンド（以下、インターネットＶｏＤと略称する）などのサービスを実現する場合、そのサービス提供者は、ユーザに対して配信するデータの品質すなわちサービスの品質（ＱｏＳ）を保証しなければならない。このようにデータ配信サービスにおける品質を保証するためには、データ配信サービスに際してネットワーク上で使用する帯域資源の予約を行う必要がある。すなわち例えば、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）を用いたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを例に挙げて説明すると、上記サービスに品質を保証するためには、コネクションレスであるＩＰパケットを、品質を保証するコネクションオリエンテッドな技術であるＡＴＭのバーチャルコネクション（Ｖｉｒｔｕａｌ Ｃｏｎｎｅｃｔｉｏｎ：以下、適宜ＶＣと略記する）で伝送することが必要となる。
【０００３】
【発明が解決しようとする課題】
ところで、従来より、バーチャルコネクション（ＶＣ）等の資源を予約するためのプロトコルとしては、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ ｒｅＳｅｒ Ｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などが知られている。ＲＳＶＰでは、ユーザ自身が、例えばＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークに接続されている端末を操作することによって資源の予約を行い、コネクションを確立する。これにより、ユーザは、データ配信サービスを受けることができるようになる。また、ＲＳＶＰでは、データ配信サービスを受けた後、ユーザ自身が再び端末を操作することによって資源の開放を行い、コネクションを切断しなければならない。
【０００４】
このように、ＲＳＶＰなどの従来の資源を予約するためのプロトコルにおいては、ユーザ自身が例えば端末を操作して、資源の予約及び開放を行なわなければならず、ユーザに負荷がかかるという課題がある。
【０００５】
また、例えば、インターネットＴＶにおいては、多チャンネルによる番組放送が予想されており、したがって、このインターネットＴＶのデータ配信サービス（番組放送サービス）においても一般的なテレビジョン放送の視聴時と同様に、ユーザがチャンネルを切り換えてどのような番組が放送されているかを見る、いわゆるザッピングによってチャンネルの切り換えが頻繁に行われることが考えられる。しかし、この場合、ユーザは、ザッピングを行う度に端末を操作して資源の予約または開放を行わなければならなくなり、その作業はユーザにとって多大な負担になる。
【０００６】
そこで、本発明は、このような状況に鑑みてなされたものであり、ユーザが意識することなく、ネットワーク資源を予約または開放することができるようにする情報受信装置及び方法、情報配信装置、情報通信システムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
本発明に係る情報受信装置は、情報配信装置から通信コネクションを介してコンテンツ情報を受信する情報受信装置において、前記通信コネクションを介した通信を行う通信手段と、前記通信手段を制御する制御手段と、前記通信手段より受信した前記コンテンツ情報に基づく処理を実行する実行手段とを備え、前記制御手段は、第１のコンテンツ情報の受信中に受信対象コンテンツの切り換えを要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１の通信コネクションとは異なる第２のコネクションを確立させた後、当該第２の通信コネクションにより第２のコンテンツ情報の受信を開始させ、前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報及び前記第２の通信コネクションの確立を要求する第２の情報の双方を含む通信予約メッセージを前記通信手段に送信させる。
【０００９】
さらに、前記制御手段は、前記通信コネクションの形成に先立ち、前記通信予約メッセージとして、通信網の通信帯域資源の予約を行う予約指令情報を含むメッセージを送信させる。
【００１０】
この情報受信装置の前記制御手段は、受信する前記コンテンツ情報が必要とする前記通信帯域資源を前記制御手段が認識している場合は、前記予約指令情報に前記通信帯域資源を示す資源情報を含めて、前記通信予約メッセージを送信させる一方、受信する前記コンテンツ情報が必要とする前記通信帯域資源を前記制御手段が認識していない場合は、前記予約指令情報に前記資源情報を含まずに前記通信予約メッセージを送信させる。
【００１１】
本発明に係る情報受信装置は、前記コンテンツ情報を通信するために必要となる通信帯域資源の予約に使用する所定の資源情報を記憶する記憶手段をさらに備え、前記制御手段は、前記記憶手段に記憶されている前記所定の資源情報を含めて、前記コネクションを形成する際の前記第２の情報を生成する。
【００１２】
次に、本発明の情報受信方法は、情報配信装置から通信コネクションを介してコンテンツ情報を受信する際の情報受信方法において、前記通信コネクションを介した通信を行う通信ステップと、前記通信を制御する制御ステップと、前記通信ステップにおいて受信した前記コンテンツ情報に基づく処理を実行するステップとを備え、前記制御ステップは、第１のコンテンツ情報の受信中に受信対象コンテンツの切替を要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１のコネクションとは異なる第２のコネクションを確立させた後、当該第２のコネクションにより第２のコンテンツ情報の受信を開始させ、前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報及び前記第２の通信コネクションの確立を要求する第２の情報の双方を含む通信予約メッセージを前記通信ステップにて送信させる。
【００１３】
さらに、本発明に係る情報配信装置は、通信コネクションを介してコンテンツ情報を受信する情報受信装置に接続され、コンテンツ情報の配信に先だって予約された通信網の通信帯域資源を用いて前記情報受信装置に前記コンテンツ情報を配信する情報配信装置において、前記通信コネクションを介した通信を行う通信手段と、前記コンテンツ情報を記憶する記憶手段と、前記情報受信装置より前記通信手段が指令信号を受信したとき、受信した前記指令信号に前記通信帯域資源を示す資源情報が含まれるか否かを検出する検出手段と、前記検出手段の検出結果に基づいて、前記通信帯域資源を予約する帯域予約命令を出力し、前記情報受信装置に前記コンテンツ情報を出力するように前記通信手段を制御する第１のモードと、前記資源情報で示される前記通信帯域資源を用いて前記コンテンツ情報を出力するように前記通信手段を制御する第２のモードとを選択するよう制御する制御手段とを備え、前記制御手段は、前記指令信号に前記資源情報が含まれない場合は前記第１のモードを、前記指令信号に前記資源情報が含まれる場合は前記第２のモードを選択するよう制御する。
【００１４】
さらにまた、本発明に係る情報通信システムは、情報配信装置と、前記情報配信装置から通信コネクションを介してコンテンツ情報を受信する情報受信装置を備え、前記コンテンツ情報の通信に先立って予約された通信網の通信帯域資源を用いて、前記情報配信装置と前記情報受信装置が前記コンテンツ情報を通信する情報通信システムにおいて、前記情報配信装置は、前記通信コネクションを介した通信を行う配信通信手段と、前記コンテンツ情報を記憶する記憶手段と、前記コンテンツ情報を出力するように前記配信通信手段を制御する配信制御手段とを備え、前記情報受信装置は、前記通信コネクションを介した通信を行う通信手段と、前記通信手段を制御する制御手段と、前記通信手段より受信した前記コンテンツ情報に基づく処理を実行する実行手段とを備え、前記制御手段は、第１のコンテンツ情報の受信中に受信対象コンテンツの切り換えを要求するコマンドが入力されると、当該要求に応じて前記第１のコンテンツを受信するための第１の通信コネクションとは異なる第２のコネクションを確立させた後、当該第２の通信コネクションにより第２のコンテンツ情報の受信を開始させ、前記第２の通信コネクションを確立するに際して、前記第１の通信コネクションの開放を要求する第１の情報及び前記第２の通信コネクションの確立を要求する第２の情報の双方を含む通信予約メッセージを前記通信手段に送信させる。
【００１６】
本発明に係る情報通信システムは、前記情報配信装置と前記情報受信装置の間に中継装置をさらに備え、前記中継装置は、前記配信制御手段及び前記受信制御手段からの指令に基づいて、前記通信帯域資源を予約する。
【００１７】
【発明の実施の形態】
以下、本発明の好ましい実施の形態について、図面を参照しながら説明する。
【００１８】
図１は、本発明を適用したクライアント端末のネットワークの接続例を表している。
【００１９】
クライアント端末１１およびクライアント端末１２は、例えば加入者が使用するパーソナルコンピュータにて構成され、これらクライアント端末１１，１２は回線を介してルータに接続されている。なお、図１の例では、クライアント端末として端末１１，１２の２台のみを図示しているが、これは一例であり複数台の端末がルータに接続されていてもよい。
【００２０】
以下の説明では、当該クライアント端末１１，１２が接続されている回線（加入者線）の一例として光ファイバを使用した回線を挙げている。さらに、以下の説明では、当該光ファイバを使用した回線にて接続されたネットワークの一例として、後述するＡＭＩｎｅｔと呼ぶネットワークを使用している。クライアント端末１１，１２は、上記光ファイバを使用した加入者線を介して、ＡＭＩｎｅｔ２０のＡＭＩｎｅｔルータ２１に接続されている。
【００２１】
ここで、ＡＭＩｎｅｔは、インターネットに上位互換するネットワークであり、既存のネットワークアーキテクチャがもつ問題を解決する次世代ネットワークアーキテクチャである。ＡＭＩｎｅｔアーキテクチャは、ＦＴＴＨ（Ｔ．Ｍｉｋｉ．Ｔｏｗａｒｄ ｔｈｅ Ｓｅｒｖｉｃｅ−Ｒｉｃｈ Ｅｒａ．ＩＥＥＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｇａｚｉｎｅ，Ｖｏｌ．３２，ＮＯ．２，Ｆｅｂｒｕａｒｙ １９９４）やｘＤＳＬ（Ｇ．Ｔ．Ｈａｗｌｅｙ．Ｓｙｓｔｅｍｓ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ ｆｏｒ ｔｈｅ Ｕｓｅ ｏｆ ｘＤＳＬ Ｔｅｃｈｎｏｌｏｇｙ ｆｏｒ Ｄａｔａ Ａｃｃｅｓｓ．ＩＥＥＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｇａｚｉｎｅ，Ｖｏｌ．３５，Ｎｏ．３，Ｍａｒｃｈ １９９７）の実現によって家庭や企業が超高速ネットワークに対称／準対称型で常時接続される時代を見据え、インターネットアーキテクチャが持つ本質的な問題点を解決するものである。
【００２２】
すなわち、ＡＭＩｎｅｔアーキテクチャの特徴は、最適なプロトコルスタックの動的構築、ＩＰを用いた独自の高速資源予約、ノード間の同位階層間およびフード内の上下階層間のネゴシェーション、コネクション指向のＱｏＳ保証、ノードの識別子とアドレスの分離、非エンド間制御、通信媒体に依存しないアーキテクチャ等を可能とすることである。なお、以下、ＡＭＩｎｅｔにおける高速資源予約プロトコルをＡＳＰ（ＡＭＩｎｅｔ Ｓｅｔ−ｕｐ Ｐｒｏｔｏｃｏｌ）と呼ぶことにする。ＡＭＩｎｅｔ及びＡＳＰについての、より詳細な説明は後述する。
【００２３】
ＡＭＩｎｅｔ２０は、ＡＭＩｎｅｔルータ２１、ＡＴＭネットワーク２２（一例であり他のネットワークであってもよい）、およびＡＭＩｎｅｔルータ２３により構成される。ＡＭＩｎｅｔ２０を構成するＡＭＩｎｅｔルータ２１は、ＡＭＩｎｅｔ独自の機能が拡張された、ＡＴＭネットワークインターフェイスを有するルータである。このＡＭＩｎｅｔルータ２１は、加入者線を集線して、回線網の一例としてのＡＴＭネットワーク２２に接続される。ＡＴＭネットワーク２２には、ＡＭＩｎｅｔルータ２１の他、ＡＭＩｎｅｔルータ２３が接続されている。ＡＭＩｎｅｔルータ２３は、ＡＭＩｎｅｔルータ２１と同様に、ＡＭＩｎｅｔ独自の機能が拡張された、ＡＴＭネットワークインターフェイスを有するルータであり、この例では、光ファイバを介してＮ個のサーバに接続されている。なお、図１には、Ｎ個のサーバとして、それぞれが例えば映像データや音声データを配信可能なＮ個のビデオサーバ３２−１乃至３２−Ｎを一例として挙げている。以下において、ビデオサーバ３２−１乃至３２−Ｎを特に区別する必要がない場合は、これらを単にビデオサーバ３２と称する。
【００２４】
ビデオサーバ３２は、例えば、インターネットＴＶ、またはインターネットＶｏＤに対応可能なビデオサーバであり、クライアント端末１１およびクライアント端末１２に対して少なくとも映像データ及び音声データを供給可能な（映像データ及び音声データの供給サービスを行う）サーバである。
【００２５】
図２は、クライアント端末１１の内部の構成例を表している。
操作部５１は、例えば、マウスやキーボードで構成され、制御部５０に所定の指令を入力するとき、適宜ユーザにより操作される。表示部５２は、例えば、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）やＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、その他の表示装置により構成され、様々な情報を表示する。
【００２６】
通信部５３は、加入者線を介してＡＭＩｎｅｔルータ２１に接続されており、ＡＭＩｎｅｔルータ２１と通信するようになされている。データベース５４には、インターネットＴＶおよびインターネットＶｏＤに対応するクライアントインターフェイス（以下、クライアントＩ／Ｆと記述する）プログラムや、当該クライアントＩ／Ｆに必要な所定のデータが保存され、また、ＡＭＩｎｅｔ２０を介して通信部５３が通信を行うのに必要なアプリケーションプログラムが保存されている。さらにデータベース５４には、ＡＭＩｎｅｔ２０を介して供給されるデータが適宜保存されるようになされている。なお、インターネットＴＶおよびインターネットＶｏＤに対応するクライアントＩ／Ｆに必要な所定のデータとしては、サーバから例えば映像データや音声データ等の各種データの配信サービスを受ける際に、ネットワーク帯域資源予約のために必要となる、資源予約パラメータ等を挙げることができる。この資源予約パラメータは、例えばサービス提供者側であるサーバとの接続時に、当該サーバ側から配信されてデータベース５４に保存される。また、資源予約パラメータは、何らかの媒体によって予め配布することも可能であり、この場合は当該配布された媒体から取り出した資源予約パラメータをデータベース５４に保存しておく。資源予約パラメータの詳細については後述する。
【００２７】
制御部５０は、データベース５４に保存されているクライアントＩ／Ｆプログラムやアプリケーションプログラムに従って、操作部５１乃至データベース５４を制御し、各種の動作を実行するようになされている。
【００２８】
なお、クライアント端末１２の内部は、クライアント端末１１と基本的に同様に構成されているので、その図示と説明は省略する。
【００２９】
図３は、ビデオサーバ３２−１の構成例を表している。
【００３０】
ＣＰＵ６１は、ＲＯＭ６２またはハードディスク６４に記録されているプログラムに従って、各種の動作を実行するようになされている。ＲＡＭ６３は、ＣＰＵ６１が各種の処理を実行する上において必要な各種のデータを適宜記憶する。
【００３１】
ハードディスク６４は、ＡＭＩｎｅｔ２０を介して伝送されてくる所定の要求に対応するサーバプログラムを保存している他、クライアント端末に対して配信するクライアントＩ／Ｆプログラムやそれに必要な所定のデータ（資源予約パラメータ）を保存し、さらに、必要に応じて、加入者（クライアント端末）にサービスとして提供するデータ（例えば映像データや音声データなど）を保存可能となされている。
【００３２】
クライアント端末にサービスデータとして提供されることになる映像データや音声データは、ハードディスク６４或いはＩ／Ｏ部６６を介して接続された各種機器から供給される。当該各種機器から供給される映像データや音声データは、クライアント端末側からの要求に応じて、直接、通信部６５からＡＭＩｎｅｔ２０に送信され、或いは、ハードディスク６４に保存され後にクライアント端末側からの要求に応じて読み出されて通信部６５からＡＭＩｎｅｔ２０に送信される。
【００３３】
Ｉ／Ｏ部６６は、例えばＩＥＥＥ１３９４ネットワーク６７に接続され、当該ＩＥＥＥ１３９４ネットワーク６７には、クライアント端末にサービスデータとして提供されることになる映像データや音声データの供給源として、例えばディジタルＶＴＲ６８、メディアコンバータ６９、テレビジョンカメラ７０、ＴＶチューナ７１、ラジオチューナ７２等の各種機器が接続されている。また、メディアコンバータ６９には、例えば複数のアナログＶＴＲ７３，７４，・・・が接続され、このメディアコンバータ６９は、これらアナログＶＴＲからのアナログ映像，音声信号をディジタル映像，音声データに変換して、ＩＥＥＥ１３９４ネットワーク６７上に供給する。すなわち、サーバ側からクライアント端末側に提供されるデータは、録画された映像データに限らず、例えば、テレビジョンカメラ７０によって現在撮影されている生の映像データや、放送局からの放送をＴＶチューナ７１にて受信した映像データ、メディアコンバータ６９を介した映像や音声データなどが考えられる。なお、配信される映像データとしては、例えばＭＰＥＧ規格に対応した圧縮画像データとすることができる。
【００３４】
通信部６５は、光ファイバによりＡＭＩｎｅｔルータ２３に接続されており、ＡＭＩｎｅｔルータ２３と通信を行うようになされている。
【００３５】
なお、ビデオサーバ３２−２乃至３２−Ｎの内部は、ビデオサーバ３２−１と基本的に同様に構成されているので、その図示と説明は省略する。
【００３６】
上述した構成により、クライアント端末は、ビデオサーバからインターネットＴＶまたはインターネットＶｏＤによる映像データや音声データの提供サービスを受けることができる。以下に、クライアント端末がインターネットＴＶまたはインターネットＶｏＤとしてビデオサーバから映像データや音声データの提供サービスを受ける場合の処理手順を説明する。
【００３７】
図４は、例えばクライアント端末１１の表示部５２の画面上にＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）として表示される、クライアントＩ／Ｆの初期画面の表示例を表している。
【００３８】
この図４の例において、表示部５２の画面の左側には、サービス提供内容としての例えば複数の番組名が表示される番組選択ボタン１０１−１乃至１０１−９が配置され、番組選択ボタン１０１−９の下側には、終了ボタン１０２、ザッピングボタン１０３、１０ｓ設定ボタン１０４及び２０ｓ設定ボタン１０５が配置され、そして画面右側中央には映像表示部１０６が配置されている。
【００３９】
この例におけるクライアントＩ／Ｆは、インターネットＴＶとインターネットＶｏＤに対応するＩ／Ｆの例であり、この図４の例の場合、番組選択ボタン１０１−１乃至１０１−８には、インターネットＶｏＤにおいて提供可能なサービス名（番組名）が表示され、また、番組選択ボタン１０１−９には、インターネットＴＶにおいて提供可能なサービス名（番組名）が表示されている。
【００４０】
図５には、インターネットＴＶおよびインターネットＶｏＤに対応するクライアントＩ／Ｆに必要な所定のデータである、資源予約パラメータの一例を示す。この資源予約パラメータは、インターネットＴＶやインターネットＶｏＤとして提供される各番組の情報を受信する際のネットワーク資源予約に必要とされ、例えばクライアント端末がサービス提供者側のサーバと接続した時に当該サーバ側から配信され、クライアント端末のデータベース５４中にクライアント設定ファイル５４Ａとして保存される。
【００４１】
この図５の例では、資源予約パラメータとして、サービス内容を指定するためのサービス番号、サービスとして提供可能な番組名、例えばインターネットＴＶやインターネットＶｏＤの放送局アドレスであるサーバアドレス（具体的にはネットワーク層のＩＰアドレス）、及びサーバにおけるサービスを特定するポート番号（具体的にはトランスポート層のＴＣＰ／ＵＤＰポート番号）、サービス提供の際にネットワーク上で必要となる帯域資源を特定するための転送レート、サーバのアプリケーションがＯＳ（オペレーティングシステム）に対して読み書きするデータの単位であるソケットに対する読み書きサイズ、ソケット用のバッファの大きさであるソケットバッファサイズ、ネットワーク上で転送されるデータ（バイト単位）の転送最大サイズと最小サイズ、いわゆるトークンバケットアルゴリズムにおけるパラメータの一つであるトークンバケットサイズ（ネットワーク上のデータに一時に出力できる最大データ量）、およびマルチキャスト配信を行う際に用いられるマルチキャストＩＰアドレスとポート番号が設定される。
【００４２】
なお、インターネットＶｏＤの場合は、一つのクライアント端末に対して一つのサービス（番組の映像データ及び音声データ）が提供されるので、サーバからはユニキャストの形態で当該サービス（番組の映像データ及び音声データ）が配信されることになる。したがって、この場合、図５の資源予約パラメータのマルチキャストＩＰアドレス／ポート番号は無視される（即ち０／０とされる）ことになる。また、インターネットＶｏＤにおいて、提供される映像データが例えば動画データであり、当該動画データがＭＰＥＧ規格に対応するような場合、ユーザ（クライアント端末）は、その動画データの転送レートとして、例えば６Ｍｂｐｓや３Ｍｂｐｓのような何種類かの転送レートの中から所望の転送レートを選択することができる。
【００４３】
一方、インターネットＴＶの場合は、一つのサービス（番組）に対して複数のクライアント端末が存在することになるので、サーバからはマルチキャストの形態で当該サービス（番組）が配信されることになる。
【００４４】
図４に戻り、各番組選択ボタン１０１には、図５に示した資源予約パラメータのうちの各番組名が表示される。したがって、ユーザ（クライアント端末）は、これら各番組選択ボタン１０１から所望の番組名が表示されたボタンを選択することにより、インターネットＴＶまたはインターネットＶｏＤにおいてその選択された番組に対応する映像データ及び音声データのサービスを享受することが可能となる。
【００４５】
終了ボタン１０２は、ユーザがクライアントＩ／Ｆプログラムを終了させるときに選択されるボタンである。
【００４６】
ザッピングボタン１０３は、ザッピングモードをオンに設定するか、またはオフに設定するときにユーザが操作するボタンである。ザッピングモードがオンに設定された場合は、各番組選択ボタン１０１に対応する複数の番組の映像が、所定の時間（この例の場合、１０秒間または２０秒間）だけ、自動的に順次、画像表示部１０６に表示される。これにより、ユーザは各番組の映像を確認することができ、興味のある番組を容易に見つけ出すことができる。
【００４７】
１０ｓ設定ボタン１０４は、ザッピングモードがオンのときに自動的に順次表示される各番組の映像の表示時間（ザッピング時間）を、１０秒間に設定するときにユーザが選択するボタンであり、２０ｓ設定ボタン１０５は、ザッピングモードがオンのときに自動的に順次表示される各番組の映像の表示時間（ザッピング時間）を、２０秒間に設定するときにユーザが選択するボタンである。
【００４８】
なお、初期画面が表示部５２に表示された時、すなわちクライアントＩ／Ｆプログラムが新たに立ち上げられたときには、当該クライアントＩ／Ｆの所定の設定が初期化される。例えば、ザッピングモードがオンになされたときのザッピング時間は、１０秒間または２０秒間のうち、いずれか一方に初期設定される。
【００４９】
次に、図６には、サーバからインターネットＴＶまたはインターネットＶｏＤのサービスを受ける場合の、クライアント端末１１の制御部５０の処理手順を示す。
【００５０】
この図６において、クライアント端末１１の制御部５０は、ステップＳ４０としてクライアントＩ／Ｆプログラムが立ち上げられると、ステップＳ４１として通信部５３を制御してサーバと接続し、資源予約パラメータを含むデータを受信して、例えばデータベース５４に保存させる。これにより、表示部５２には、図４に示したクライアントＩ／Ｆの初期画面が表示されることになる。
【００５１】
このようにクライアントＩ／Ｆプログラムが立ち上がり、図４に示したクライアントＩ／Ｆの初期画面が表示部５２に表示されている状態において、クライアント端末１１の制御部５０は、ステップＳ１として、操作部５１から何らかの指令が入力されるまで待機している。制御部５０は、ステップＳ１の待機時に、操作部５１から何らかの指令が入力されると、ステップＳ２以降の処理に進む。
【００５２】
制御部５０は、ステップＳ２の処理として、ステップＳ１で操作部５１から入力された指令がクライアントＩ／Ｆの終了を指令するものか否かを判定する。制御部５０は、ステップＳ２の判定処理においてクライアントＩ／Ｆの終了指令が入力されたと判定した場合、すなわち、ユーザによって操作部５１が操作されて終了ボタン１０２が選択された場合、当該クライアントＩ／Ｆプログラムの終了処理を行う。
【００５３】
制御部５０は、ステップＳ２の判定処理において、ステップＳ１で操作部５１から入力された指令がクライアントＩ／Ｆの終了を指令するものではないと判定した場合、ステップＳ３の処理に進む。制御部５０は、ステップＳ３の処理に進むと、操作部５１から入力された指令が番組選択ボタン１０１の操作指令であるか否かを判定し、番組選択ボタン１０１の操作指令でないと判定した場合、ステップＳ４の処理に進む。
【００５４】
制御部５０は、ステップＳ４の処理に進むと、ステップＳ１で操作部５１から入力された指令がザッピングボタン１０３の操作指令であるか否かを判定し、ザッピングボタン１０３の操作指令でないと判定した場合、ステップＳ５の処理に進む。制御部５０は、ステップＳ５の処理に進むと、操作部５１から入力された指令が１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の操作指令であるか否かを判定する。
【００５５】
制御部５０は、ステップＳ５の判定処理において、ステップＳ１で操作部５１から入力された指令が１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の操作指令でないと判定した場合、ステップＳ１の処理に戻り、操作部５１から指令が入力されるまで待機する。また、制御部５０は、ステップＳ５の判定処理において、操作部５１から入力された指令が１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の何れか一方を選択した操作指令であると判定した場合、ステップＳ６の処理に進む。
【００５６】
制御部５０は、ステップＳ６の処理に進むと、ステップＳ５にて１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の何れか選択されたボタンに対応する時間に、ザッピング時間を設定した後、ステップＳ１の処理に戻り、操作部５１から指令が入力されるまで待機する。
【００５７】
次に、制御部５０は、ステップＳ３の判定処理において、操作部５１から入力された指令が番組選択ボタン１０１の操作指令であると判定した場合、ステップＳ７の処理に進む。また、制御部５０は、ステップＳ４の判定処理において、操作部５１から入力された指令がザッピングボタン１０３の操作指令であると判定した場合、ステップＳ４２の処理としてザッピングモードをＯＮにした後、ステップＳ７の処理に進む。
【００５８】
制御部５０は、ステップＳ７の処理として、資源予約を要求するためのメッセージを作成する。このメッセージは、前述した高速資源予約プロトコル（ＡＳＰ）によるメッセージであるため、ここではＡＳＰメッセージと呼ぶことにする。例えば、ステップＳ１において番組選択ボタン１０１−１乃至１０１−９のうちの何れか１つが操作された場合、制御部５０は、当該操作された番組選択ボタン１０１に対応する番組の資源予約パラメータをデータベース５４から読み出して解釈し、そのコネクションで用いられる識別子、例えば、ＶＣＩ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｉｄｅｎｔｉｆｉｅｒ）／ＶＰＩ（Ｖｉｒｔｕａｌ Ｐａｔｈ Ｉｄｅｎｔｉｆｉｅｒ）を決定し、その資源予約パラメータと共に資源予約を要求するためのＡＳＰメッセージ（資源予約要求メッセージ）を作成する。また、ステップＳ１においてザッピングボタン１０３が操作され、ステップＳ４２にてザッピングモードがＯＮとなされると、制御部５０は、予め決められた番組の資源予約パラメータをデータベース５４から読み出して解釈し、ＶＣＩ／ＶＰＩを決定し、その資源予約パラメータと共に資源予約を要求するためのＡＳＰメッセージ（資源予約要求メッセージ）を作成する。
【００５９】
ステップＳ７にて資源予約を要求するためのＡＳＰメッセージを生成すると、制御部５０は、ステップＳ８として通信部５３を制御し、そのＡＳＰメッセージをＡＭＩｎｅｔルータ２１に送信させる。
【００６０】
通信部５３から送信された資源予約を要求するためのＡＳＰメッセージは、図１のＡＭＩｎｅｔルータ２１およびＡＭＩｎｅｔルータ２３により、ビデオサーバ３２−１乃至３２−Ｎのうち、指定されたサービスを提供することができるビデオサーバ３２に向かって転送される。
【００６１】
ここで、ネットワークの資源予約の処理は、ＡＳＰメッセージの送信方向と同じ方向に資源予約が成されていく順方向の資源予約と、ＡＳＰメッセージの送信方向とは逆方向に資源予約が成されていく逆方向の資源予約とが考えられる。このネットワーク資源予約の具体的な流れの詳細については後述するが、一例として、クライアント端末１１からビデオサーバ３２に資源予約を要求するためのＡＳＰメッセージを送信する過程において、先ずＡＭＩｎｅｔルータ２１からクライアント端末１１の方向に、次に、ＡＭＩｎｅｔルータ２３からＡＭＩｎｅｔルータ２１の方向に、次にビデオサーバ３２からＡＭＩｎｅｔルータ２３の方向に資源予約を行うようにＡＳＰメッセージの送信方向とは逆方向に資源予約がなされる場合や、例えばクライアント端末から送信された資源予約を要求するためのメッセージをビデオサーバ３２が受け取り、このビデオサーバ３２からクライアント端末１１に対してその応答のためのＡＳＰメッセージを返信する過程において、先ずビデオサーバ３２からＡＭＩｎｅｔルータ２３の方向に、次にＡＭＩｎｅｔルータ２３からＡＭＩｎｅｔルータ２１の方向に、次にＡＭＩｎｅｔ２１からクライアント端末１１の方向に資源予約を行うようにＡＳＰメッセージの送信方向と同一の方向（順方向）に資源予約がなされる場合などが考えられる。
【００６２】
例えば、クライアント端末１１がサービスデータ（映像データ及び音声データ）を受信するために必要なネットワークの資源の量を知っている場合、ＡＳＰメッセージの送信方向とは逆方向に資源予約がなされる予約方法が用いられる。例えば、ユニキャスト配信を行うインターネットＶｏＤの場合、予めサーバ３２からクライアント端末１１に、サービスデータ（映像データ及び音声データ）に対する必要な資源の量が通知されており、クライアント端末１１がサービスデータ（映像データ及び音声データ）を受信するために必要な資源の量を予約するので、逆方向の資源予約方法が用いられる。
【００６３】
また、クライアント端末１１がサービスデータ（映像データ及び音声データ）を受信するために必要なネットワークの資源の量を知らない場合、ＡＳＰメッセージの送信方向と同一方向（順方向）に資源予約がなされる予約方法が用いられる。例えば、マルチキャスト配信を行うインターネットＴＶの場合、クライアント端末１１が操作され、サーバ３２に対してサービスデータ（映像データ及び音声データ）の配信の要求が出されてから、サーバ３２がサービスデータ（映像データ及び音声データ）を配信するために必要な資源の量を予約するので、同一方向（順方向）の資源予約方法が用いられる。
【００６４】
ステップＳ８にて資源予約を要求するためのＡＳＰメッセージを送信した後、制御部５０は、ステップＳ９として資源予約が成功したか否かを判定する。すなわち、制御部５０は、逆方向の資源予約或いは順方向の資源予約の結果、資源予約が成功或いは失敗した旨を示すメッセージを受け取ると、そのメッセージによって資源予約が成功したか否かを判定する。制御部５０は、ステップＳ９にて資源予約に失敗したと判定した場合、ステップＳ１０の処理として、表示部５２を制御して資源予約の失敗の原因等を表示させ、ステップＳ１の処理に戻り、ユーザに対して番組選択のための再度の操作を促す。
【００６５】
制御部５０は、ステップＳ９において資源予約が成功したと判定した場合、ステップＳ１１の処理として、通信部５３を制御し、ビデオサーバ３２から転送されてくるサービスデータ（番組の映像データや音声データなど）を受信させ、次にステップＳ１２の処理に進み、表示部５２を制御し、その受信したサービスデータの映像をクライアントＩ／Ｆの映像表示部１０６に表示させる。これにより、映像表示部１０６には、例えば図７に示すように番組選択ボタン１０１−１に対応する番組、例えば「野球１」の映像が表示されることになる。
【００６６】
次に、制御部５０は、ステップＳ４３として、ザッピングモードがＯＮとなっているか否かを判定する。ステップＳ４３にてザッピングモードがＯＮとなっていると判定した場合、制御部５０は、ステップＳ４４として、操作部５１から何らかの指令が入力されたか否かを判定し、操作部５１から何も指令が入力されていないと判定した場合には、ステップＳ１５として、ザッピングの設定時間（ザッピング時間）が経過したか否かの判定を行う。すなわち、制御部５０は、ステップＳ６において１０ｓ設定ボタン１０４が操作されて１０秒のザッピング時間が設定されている場合には１０秒経過したか否かの判定を行い、ステップＳ６において２０ｓ設定ボタン１０５が操作されて２０秒のザッピング時間が設定されている場合には２０秒経過したか否かの判定を行い、また、ザッピング時間が初期設定の時間となっている場合には、その初期設定の時間が経過したか否かの判定を行う。
【００６７】
一方、制御部５０は、ステップＳ１５において、設定されているザッピング時間が経過していないと判定した場合にはステップＳ１１の処理に戻り、設定されているザッピング時間が経過するまでステップＳ１１からステップＳ１５までの処理を行う。
【００６８】
制御部５０は、ステップＳ１５において、設定されているザッピング時間が経過したと判定した場合、ステップ８４６の処理に進む。制御部５０は、ステップＳ４６の処理に進むと、現在予約している資源を開放するために、その予約の解除を要求するためのＡＳＰメッセージ（資源予約解除要求メッセージ）を生成し、通信部５３を制御して、このＡＳＰメッセージをＡＭＩｎｅｔルータ２１に送信させる。当該資源予約解除を要求するためのＡＳＰメッセージには、終了したいサービスを特定する情報、例えばサーバを特定する情報、クライアント端末を特定する情報などが含まれている。
【００６９】
このときのネットワークの資源予約の解除処理の流れは、資源予約要求時とは異なり、ＡＳＰメッセージの送信方向とは逆方向に資源予約解除が成される逆方向の資源予約解除のみが用いられる。一例としては、クライアント端末１１からビデオサーバ３２に資源予約解除を要求するためのＡＳＰメッセージが送信される過程において、先ずＡＭＩｎｅｔルータ２１からクライアント端末１１の方向に、次にＡＭＩｎｅｔルータ２３からＡＭＩｎｅｔルータ２１の方向に、次にビデオサーバ３２からＡＭＩｎｅｔルータ２３の方向に資源予約解除を行うようにＡＳＰメッセージの送信方向とは逆方向に資源予約解除が成される場合が考えられる。
【００７０】
ステップＳ４６にて資源予約解除を要求するためのＡＳＰメッセージを送信した後、制御部５０は、ステップＳ４７として、ＡＭＩｎｅｔ２１から資源予約の解除の結果を表すメッセージを受信させ、そのメッセージによって資源予約解除が成功したか否かを判定する。すなわち、制御部５０は、逆方向の資源予約解除の結果、資源予約解除が成功或いは失敗した旨を示すメッセージを受け取ると、そのメッセージによって資源予約解除が成功したか否かを判定する。例えば、ネットワークの切断等により資源予約の解除に失敗し、その旨を表すメッセージが受信された場合、制御部５０は、ステップＳ４７にて資源予約解除に失敗したと判定し、次いで、ステップＳ１８の処理として、表示部５２を制御して資源予約解除の失敗の原因等を表示させ、ステップＳ１の処理に戻り、番組選択或いはザッピングのための再度の操作を促す。
【００７１】
一方、制御部５０は、ステップＳ４７において資源予約の解除が成功したと判定した場合、ステップＳ４８の処理として、ザッピングにより次に表示すべきチャンネル（番組）の設定を行う。すなわち、このときの制御部５０は、クライアントＩ／Ｆの映像表示部１０６に現在表示されている番組の次の番組、例えば、１つ下の段の番組選択ボタン１０１に対応する番組を設定し、ステップＳ７の処理に戻って、その番組に対応する資源予約パラメータをデータベース５４から読み出し、資源予約を要求するためのＡＳＰメッセージを作成する。以下、この再設定したチャンネルについてステップＳ８からステップＳ４８までの処理を行うことにより、各番組選択ボタン１０１に対応する番組が順次映像表示部１０６に表示され、ザッピングが実行されることになる。
【００７２】
また、制御部５０は、ステップＳ４３において、ザッピングモードがＯＮとなっていないと判定した場合、ステップＳ１３の処理に進む。制御部５０は、ステップＳ１３の処理に進むと、操作部５１から何らかの指令が入力されたか否かを判定し、操作部５１から何も指令が入力されていないと判定した場合には、ステップＳ１１に戻り、サービスデータの受信処理を続ける。一方、制御部５０は、ステップＳ１３にて操作部５１から何らかの入力がなされたと判定した場合、ステップＳ１６の処理に進む。
【００７３】
ここで、ステップＳ１３において、操作部５１から入力された指令がクライアントＩ／Ｆの映像表示部１０６に表示されている番組を変更する指令であると判定された場合、すなわち、ユーザが操作部５１を操作し、他の番組に対応する番組選択ボタン１０１を選択した場合、制御部５０は、ステップＳ１６以降の処理として、いま現在予約されている資源の解除を行う。
【００７４】
すなわち、ステップＳ１６の処理に進むと、制御部５０は、資源予約の解除を要求するためのＡＳＰメッセージを生成し、通信部５３を制御して、このＡＳＰメッセージをＡＭＩｎｅｔルータ２１に送信させる。このときの資源予約の解除を要求するためのＡＳＰメッセージには、サーバを特定する情報、クライアント端末を特定する情報、および終了したいサービスを特定する情報が含まれている。なお、このときのネットワークの資源予約の解除処理の流れも、逆方向の資源予約解除と順方向の資源予約解除とがある。
【００７５】
ステップＳ１６にて資源予約解除を要求するためのＡＳＰメッセージ（資源予約解除要求メッセージ）を送信した後、制御部５０は、ステップＳ１７として資源予約解除が成功したか否かを判定する。制御部５０は、ステップＳ１７にて資源予約解除に失敗したと判定した場合は、ステップＳ１８の処理として、表示部５２を制御して資源予約解除の失敗の原因等を表示させ、ステップＳ１の処理に戻り、番組選択のための再度の操作を促す。
【００７６】
一方、制御部５０は、ステップＳ１７にて資源予約解除に成功したと判定した場合、ステップＳ２に戻り、ステップＳ２でクライアントＩ／Ｆの終了が指令されていないと判断すると、ステップＳ３を介してステップＳ７に進み、このステップＳ７において、新たに選択された（ステップＳ１３で選択された）番組の資源予約パラメータが読み出される。以下、制御部５０では、ステップＳ８以降の処理が実行され、これにより別の番組の映像が映像表示部１０６に表示されることになる。本実施の形態では、制御部５０は、このようにして、クライアントＩ／Ｆの映像表示部１０６に表示させる番組を切り換えることができる。
【００７７】
また、制御部５０は、ステップＳ４４において、操作部５１から何らかの指令が入力されたと判定した場合には、ステップＳ５０として１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の何れかが押されたか否かの判断を行い、当該ステップＳ５０にて１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５の何れかが押されたと判断した場合には、ステップＳ５１として当該押された設定ボタンに応じてザッピング時間の設定を行った後、ステップＳ１１に戻る。また、制御部５０は、ステップＳ５０にて１０ｓ設定ボタン１０４または２０ｓ設定ボタン１０５が押されていないと判断した場合は、ステップＳ４９として、ザッピングモードをＯＦＦにした後、ステップＳ５２の処理に進む。制御部５０は、ステップＳ５２の処理に進むと、ザッピングボタン１０３が押されたか否か判断し、押されたときにはステップＳ１１に戻り、押されていないときにはステップＳ１６の処理に進む。このステップＳ１６の処理に進んだ場合の制御部５０の処理は、上述同様である。
【００７８】
以上のことから、ユーザは、資源の予約またはその解除を意識せずに、テレビジョン受像機のチャンネルを選択する場合と同様に、容易に番組を選択し、視聴することができる。
次に、図８には、サービスデータを提供するビデオサーバ（例えばビデオサーバ３２−１）のＣＰＵ６１の処理手順を説明する。
【００７９】
ビデオサーバのハードディスク６４に保存されているサーバプログラムが起動されている状態において、ＣＰＵ６１は、ステップＳ２１の処理として、通信部６５がＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２からＡＳＰメッセージを受信するまで待機し、ＡＳＰメッセージが受信されると、ステップＳ２２に進む。
【００８０】
ＣＰＵ６１は、ステップＳ２２の処理に進むと、受信したＡＳＰメッセージが資源予約を要求するためのメッセージであるかまたは資源予約解除を要求するためのメッセージであるかを判定し、資源予約を要求するためのメッセージであると判定した場合、ステップＳ２４に進む。
【００８１】
ここで、ネットワークの資源予約は、前述したようにＡＳＰメッセージの送信方向と同じ方向に資源予約が行われる順方向の資源予約と、ＡＳＰメッセージの送信方向とは逆方向に資源予約が行われる逆方向の資源予約がある。ビデオサーバ３２のＣＰＵ６１は、ステップＳ２４の処理に進むと、各ＡＭＩｎｅｔルータから資源予約に成功或いは失敗した旨を示すメッセージを受け取り、このメッセージによって資源予約が成功したか否かを判定する。
【００８２】
ＣＰＵ６１は、ステップＳ２４において資源予約に成功したと判定した場合、ステップＳ２５の処理として、通信部６５を制御して資源予約に成功した旨を表すメッセージを、そして、ステップＳ２６において、ハードディスク６４に記録されているサービスデータ、或いはＩ／Ｏ部６６に接続された機器より出力されるデータを、ＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２に送信させ、その後、ステップＳ２１に戻る。
【００８３】
一方、ステップＳ２４において資源予約に失敗したと判定した場合、ＣＰＵ６１は、ステップＳ２７の処理として、通信部６５を制御して資源予約に失敗した旨を表すメッセージを、ＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２に送信させ、その後、ステップＳ２１に戻る。
【００８４】
また、ＣＰＵ６１は、ステップＳ２２の判定処理において、受信したＡＳＰメッセージが資源予約解除を要求するためのメッセージであると判定した場合、ステップＳ２９に進む。
【００８５】
ネットワークの資源予約の解除は、前述したようにＡＳＰメッセージの方向とは逆方向に行われる逆方向の資源予約解除のみがある。ビデオサーバ３２のＣＰＵ６１は、ステップＳ２９の処理に進むと、各ＡＭＩｎｅｔルータから資源予約解除に成功或いは失敗した旨を示すメッセージを受け取り、このメッセージによって資源予約の解除が成功したか否かを判定する。
【００８６】
ＣＰＵ６１は、ステップＳ２９において資源予約の解除に成功したと判定した場合、ステップＳ３０の処理として、通信部６５を制御して資源予約解除に成功した旨を表すメッセージをＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２に送信させ、その後、ステップＳ２１に戻る。
【００８７】
また、ステップＳ２９において資源予約解除に失敗したと判定した場合、ＣＰＵ６１は、ステップＳ３１の処理として、通信部６５を制御して資源予約解除に失敗した旨を表すメッセージを、ＡＭＩｎｅｔ２０を介して、クライアント端末１１またはクライアント端末１２に送信させ、その後、ステップＳ２１に戻る。
【００８８】
次に、上述したＡＭＩｎｅｔにおけるＡＴＭとＩＰの統合によるリアルタイム通信の実現（ＡＴＭ Ｃｏｎｔｒｏｌ ｔｈｒｏｕｇｈ ＩＰ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｉｎ ＡＭｌｎｅｔ）について説明する。ここでは、ＡＭＩｎｅｔが前提としているバックボーン、および家庭を接続する広域ネットワークで利用される資源予約プロトコルＡＳＰ（ＡＭＩｎｅｔ Ｓｅｔ−ｕｐ Ｐｒｏｔｏｃｏｌ）について述べる。本技術は、日本国特許出願 特願平９−２７９８２６号（１９９７年９月２６日出願、出願人は本願と同じ、優先日において未公開）、及び米国特許出願０８／１６０，４７２（１９９８年９月２４日出願、権利継承人は本願と同じ）で開示されている。
【００８９】
ＡＳＰは、ＩＰの柔軟性および適応性、また回線指向型データリンクであるＡＴＭに注目し、それらを統合することによって、高速で柔軟な資源予約を実現する。ＡＳＰは、通常のＡＴＭのシグナリングは利用せず、ＩＰによって転送されるメッセージを利用してＡＴＭ ＶＣ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ）を動的に確立する。
【００９０】
ＡＳＰ（ＡＭｌｎｅｔ Ｓｅｔ ｕｐ Ｐｒｏｔｏｃｏｌ）は、広域ネットワーク、特にＡＭＩｎｅｔアーキテクチャに基づくルータからなる環境で動作する資源予約プロトコルである。ＡＭＩｎｅｔはＡＴＭスイッチング機能をもつルータからなり、バックボーンルータとその境界にあるエッジルータとから構成されている。予約する資源は、ＡＴＭ ＶＣ、またはパケット処理時に利用されるキューなどである。特にＡＴＭとの統合の場合、ＡＳＰでは、通常のＡＴＭシグナリングを利用せず、ＡＴＭスイッチまたはＡＴＭ機能をもつルータにおいてＶＣが確立される。また、ＡＳＰでは、ＩＰを使って資源予約のためのセットアップメッセージを転送するので、高速資源予約が実現できる。したがって、ＡＴＭスイッチでは、ＡＴＭのＳＶＣ（Ｓｗｉｔｃｈｅｄ Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ）と呼ばれるＶＣは全く利用せず、ＩＰを利用したメッセージによって、ＶＣを動的に確立する。なお、このようなＶＣのことをＰＶＣ（Ｐｅｒｍａｎｅｎｔ ＶＣ）オンデマンド（ＰＶＣ−ｏｎ−ｄｅｍａｎｄ）と呼ぶ。このＰＶＣオンデマンドは、ＡＳＰを利用することによって、通常のＳＶＣとは異なる形態でＶＣを動的に確立、または切断できる。
【００９１】
ＡＳＰを利用する場合でも、データは通常のＩＰで転送される。そこで、ＩＰパケットは、特定の予約された資源にマッピングされる。そのため、今まで利用されてきたアプリケーションから今後出て来る可能性のある新しいアプリケーションにもＡＳＰは簡単に対応できる。このマッピングは、ソースとデスティネーションＩＰアドレス、ソースとデスティネーションポート番号、およびプロトコル識別子フィールドなどを参照することによって行われる。通常のＩＰトラフイック、すなわちベストエフォートトラフィック（ＢＥ）は、予め設定されたデフォルトＢＥ ＶＣを通して転送される。ＡＳＰを使って予約された資源は、ＢＥトラフィックによって影響されない。また、資源の節約などを考えて１つのＶＣにまとめられたフローも、ＢＥトラフィックに影響されず共存できる。
【００９２】
次に、柔軟なセットアップ機構について説明する。ＡＳＰでは、効率良く資源を利用するために、またはアプリケーションの要求にあった資源予約を行うため、様々な形態で資源を予約できる。すなわち、インターネットやＡＴＭ環境では、様々な種類のアプリケーション、例えば、テレビ会議、遠隔診断、ビデオオンデマンド（ＶｏＤ）、ＭＢｏｎｅを利用するマルチキャストアプリケーションなどの放送型のアプリケーションから、双方向にデータを送信する対話型のアプリケーションがあり、ＡＳＰによれば、何れの場合も、ＱｏＳパラメータを下位層の資源予約パラメータに効率良く、且つスケーラブルにマッピングすることが可能である。
【００９３】
例えば、ＶｏＤの場合、データは必ずサーバからクライアント端末に向かって流れるため、サーバとクライアント端末の間においてＶＣを双方向に確立する必要はない。すなわち、ＡＳＰを用いた場合、ＡＳＰ固有のメッセージのやりとり、アプリケーションが必要とするデータ転送以外の制御のやりとり（ＶｏＤの場合だと見る映画を途中で変更するためのクライアント端末側からの要求など）、さらに上位層（例えば、トランスポート層）などが必要とするやりとりは、デフォルトＢＥ ＶＣ又は他の専用ＶＣを利用するだけで実現できる。ＡＳＰメッセージはデフォルトＢＥ ＶＣまたは指定された専用ＶＣを通して転送される， 一方、対話型であるテレビ会議アプリケーションの場合は、双方向ＶＣが必要であるが、ＡＳＰは一方向だけでなく、この対話型アプリケーションのような双方向のＶＣにも対応している。さらに、対話型アプリケーションの場合、ＡＳＰは上流と下流トラフィックに対して、異なるＱｏＳを設定できる非対象なモデルをサポートする。
【００９４】
また、ＡＳＰではＲＳＶＰまたはＳＴ−２＋（Ｓｔｒｅａｍ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ−２＋）の場合と同様に、資源予約要求は受信側からも可能である上、送信側からの発行も可能である。すなわち、資源予約を行う際に必要なＱｏＳ情報は、アプリケーションまたは環境により、送信側が持っている場合と受信側が持っている場合とがあるが、ＡＳＰはそのどちらの場合でも１パスで全ての予約を行うように設定できる。さらに、ＡＳＰは、必要に応じて予約が完了したことを伝える応答メッセージを持つことも可能である。
【００９５】
次に、柔軟なセットアップ機構について説明する。ＡＳＰでは、効率良く資源を利用するために、またはアプリケーションの要求にあった資源予約を行うため、様々な形態で資源を予約できる。すなわち、インターネットやＡＴＭ環境では、様々な種類のアプリケーション、例えば、テレビ会議、遠隔診断、ビデオオンデマンド（ＶｏＤ）、ＭＢｏｎｅを利用するマルチキャストアプリケーションなどの放送型のアプリケーションから、双方向にデータを送信する対話型のアプリケーションがあり、ＡＳＰによれば、何れの場合も、ＱｏＳパラメータを下位層の資源予約パラメータに効率良く、且つスケーラブルにマッピングすることが可能である。
【００９６】
例えば、ＶｏＤの場合、データは必ずサーバからクライアント端末に向かって流れるため、サーバとクライアント端末の間においてＶＣを双方向に確立する必要はない。すなわち、ＡＳＰを用いた場合、ＡＳＰ固有のメッセージのやりとり、アプリケーションが必要とするデータ転送以外の制御のやりとり（ＶｏＤの場合だと見る映画を途中で変更するためのクライアント端末側からの要求など）、さらに上位層（例えば、トランスポート層）などが必要とするやりとりは、デフォルトＢＥ ＶＣ又は他の専用ＶＣを利用するだけで実現できる。ＡＳＰメッセージはデフォルトＢＥ ＶＣまたは指定された専用ＶＣを通して転送される， 一方、対話型であるテレビ会議アプリケーションの場合は、双方向ＶＣが必要であるが、ＡＳＰは一方向だけでなく、この対話型アプリケーションのような双方向のＶＣにも対応している。さらに、対話型アプリケーションの場合、ＡＳＰは上流と下流トラフィックに対して、異なるＱｏＳを設定できる非対象なモデルをサポートする。
【００９７】
また、ＡＳＰではＲＳＶＰまたはＳＴ−２＋（Ｓｔｒｅａｍ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ−２＋）の場合と同様に、資源予約要求は受信側からも可能である上、送信側からの発行も可能である。すなわち、資源予約を行う際に必要なＱｏＳ情報は、アプリケーションまたは環境により、送信側が持っている場合と受信側が持っている場合とがあるが、ＡＳＰはそのどちらの場合でも１パスで全ての予約を行うように設定できる。さらに、ＡＳＰは、必要に応じて予約が完了したことを伝える応答メッセージを持つことも可能である。
【００９８】
図９には、ＡＳＰメッセージとして資源予約を要求するためのメッセージを受信側が発行している例を示す。
【００９９】
これは、ビデオの放送型アプリケーションなどがＡＳＰを利用した場合を表す。すなわち、データは送信側であるサーバ（以下、センダとする）１から受信側であるクライアント端末（以下、レシーバとする）７の方向にしか転送されない。図中のルータ２〜６のうち、ルータ２と６はエッジルータであり、ルータ３，４，５はバックボーンルータである。
【０１００】
レシーバ７は、先ず、ＱｏＳパラメータが解釈され、このコネクションで用いられるＶＰＩ／ＶＣＩを決定し、必要に応じてＡＴＭ ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）を設定する。また、レシーバ７は、この情報を含むＡＳＰメッセージ（資源予約要求メッセージ）を作成し、バックボーン（バックボーンルータ５）に隣接しているエッジルータ６に向けてこのＡＳＰメッセージを転送する。このＡＳＰメッセージは、ＩＰで転送され、ＩＰのホップ毎に処理される。図９の例の場合、エッジルータ６にメッセージが届くと、当該エッジルータ６では、レシーバ７に向けてＶＰＩ／ＶＣＩパラメータを設定する。ＶＰＩ／ＶＣＩは各ノードで個別に管理されている。このようにＡＳＰメッセージは、センダ１に向かって上流に転送され、各ルータ２乃至６では、このＡＳＰメッセージが転送される方向と逆方向に向けてＶＣが設定（逆方向の資源予約）される。なお、図には示されていないが、センダ１にＡＳＰメッセージが転送され、予約が実質的に完了すると、必要に応じて、センダ１からレシーバ７に対して返答メッセージが転送される。この時点で、最低限バックボーンルータにおいては、センダ１からレシーバ７に向けてＶＣが確立される。すなわち、この図３の構成では、エッジルータを結ぶこのＶＣを利用することによって、データ転送時にＩＰをカットスルーし、ＡＴＭのみで通信できるようになる。
【０１０１】
なお、図９はＡＳＰにおける柔軟なセットアップの一形態のみを表している。例えば、センダ１のみがＱｏＳ情報を持っていて、しかもマルチキャストアプリケーションでレシーバ７から資源予約要求を発行する場合は、上記の例の返答メッセージが返る第２パスでＶＣの設定を行うようにメッセージを作成することもでき、さらに、双方向のＶＣを第１パスのみで確立してしまうことも可能となる。
【０１０２】
次に、ＡＳＰでは独自のセットアップ機構によりＡＴＭ ＶＣを確立するので、予め他のＶＣを用意する必要がなく、既に予約された資源のＱｏＳを動的に変更可能となっており、また、アプリケーションは簡単にサービスレベルをアップグレードすることも可能となっている。例えば、単純にＢＥからインテグレーティッドサービス（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ：ＩＳ）に移行する場合、データフローは、デフォルトＢＥ ＶＣから図９などに示す新たなＶＣにマップし直すことも容易にできる。
【０１０３】
次に、ＱｏＳルーティングとの統合について説明する。ＡＳＰでは、ＶＣセットアップ時にＱｏＳルーティングによる経路選択のサポートが考慮されている。具体的には、資源を予約する時に、従来のＩＰレベルでのルーティングテーブルを利用するのではなく、ＩＳを必要とするフローのための独自ルーティングテーブルを管理するモジュールより経路情報の提供を受ける。これにより、ＡＳＰでは、ＱｏＳ要求やネットワークの利用可能な資源状況に合わせて、フロー毎に異なる経路を利用できる。
【０１０４】
また、従来の資源予約プロトコルとルーティング機構はそれぞれ独立したものを前提として考えられてきたが、ＡＳＰではＱｏＳルーティングとの統合を実現している。これは、ＱｏＳルーティングのモジュールに対して、ＡＳＰが保持している資源予約情報をフィードバックすることによって行う。したがって、ＡＳＰでは、予約が失敗した場合の代替経路の選択が容易であり、また、予約する資源をネットワーク中に分散させることができ、１つの経路に資源予約を集中させることなくネットワーク全体を効率良く利用できる。
【０１０５】
次に、ＡＳＰは、一例としてＵＮＩＸのデーモンブロセス（ａｓｐｄ）としてユーザ空間で実装されている。プロトタイプはＦｒｅｅＢＳＤ２．２．１で動作中であり、ＡＴＭスイッチを制御するためのライブラリ（ｓｗｃｔｌ ｌｉｂ）とＡＴＭ ＮＩＣの設定を行うモジュール（ａｆｍａｐ）と統合されている（図１０参照）。現在は、３つのタイプのルータがサポートされており、ホームルータは１００Ｂａｓｅ−Ｔ ＥｔｈｅｒｎｅｔとＡＴＭインターフェイスをもつ。エッジルータは現在は複数のＡＴＭインターフェイスを持つルータとして実現されている。バックボーンルータは、ＡＴＭスイッチとそれを制御するためのＩＰエンジンを含むＰＣからなる。現在のプロトタイプでは、Ａｄａｐｔｅｃ社とＥｆｆｉｃｉｅｎｔ Ｎｅｔｗｏｒｋｓ社のＰＣＩバス用ＡＴＭインターフェイスカードと、Ｆｏｒｅ ＡＳＸ−２００ＷＧ ＡＴＭスイッチを利用している。ＡＳＰメッセージは、ｒａｗＩＰを使って実装されている。
【０１０６】
バックボーンルータは、装備されているスイッチにおいてＰＶＣオンデマンド（ＰＶＣ−ｏｎ−ｄｅｍａｎｄ）を設定するため前述したスイッチ制御ライブラリを利用する。ＩＳを必要とするＩＰフローはＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）のＶＣにマッピングされる。また、現在、ＡＳＰはＡＴＭスイッチで一対多のマルチキャストＶＣを作成することによって、マルチキャストに対応している。さらに、ＡＳＰは、リーフによるジョイン、および資源予約もサポートしている。
【０１０７】
なお、ＶＣＩなどの識別子をはじめとするＡＴＭ資源のスケーラビリティを考慮すると、ＩＰフローをアプリケーション単位でＶＣにマッピングすることは効率が悪いが、この場合は、ＡＳＰを利用することにより、動的にフローをＶＣにまとめることが容易になる。
【０１０８】
以上、ＡＭＩｎｅｔにおける資源予約プロトコルＡＳＰについて述べており、ＡＳＰは独自のセットアップ機構を導入し、ＩＰの柔軟性とＡＴＭのＶＣによるＱｏＳ保証を統合している。したがって、ＡＭＩｎｅｔでは、動的ＱｏＳ変更、ＱｏＳルーティングとの統合、柔軟なセットアップを実現し、プロトタイプ実装により高速セットアップを実現できる。
【０１０９】
次に、ＡＭＩｎｅｔにおける資源予約を行うためのプロトコルであるＡＳＰ（ＡＭＩｎｅｔ Ｓｅｔ−ｕｐ Ｐｒｏｔｏｃｏｌ）の詳細について説明する。なお、この場合のセットアップ（ｓｅｔ−ｕｐ）とは、資源予約を行うときに、レシーバおよびセンダ、または経路中経由するルータにおいて、資源予約のために状態／情報を設定することを意味する。
【０１１０】
ＡＳＰは、回線交換機能をもつ下位層のＶＣ、またはパケットスケジューラが提供することのできるキューの割り当て（ＣＢＱ（Ｃｌａｓｓ Ｂａｓｅｄ Ｑｕｅｕｅｉｎｇ）のクラスなど）を資源として抽象化し、ＩＰネットワークに流れるデータが他のデータに影響なく転送されるように対応付けを行う。一具体例として、ＡＳＰではＡＴＭのＶＣおよびＵＰＣ（Ｕｓａｇｅ Ｐａｒａｍｅｔｅｒ Ｃｏｎｔｒｏｌ）によって制御される資源として抽象化し、その資源を予約し、ＩＰのフローにそのＶＣを対応させる。なお、ここでのフローとは、以下の情報を表す。すなわち、アドレスファミリー（ａｄｄｒｅｓｓ ｆａｍｉｌｙ）、プロトコル識別子であるプロトコル（ｐｒｏｔｏｃｏｌ）、レシーバのＩＰアドレスであるデスティネーションＩＰアドレス（ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ）とセンダのＩＰアドレスであるソースＩＰアドレス（ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ）、レシーバのポートアドレス（ｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ ａｄｄｒｅｓｓ）とセンダのポートアドレス（ｓｏｕｒｃｅ ｐｏｒｔ ａｄｄｒｅｓｓ）などである。
【０１１１】
ＡＳＰのセットアップ、すなわち、ＡＳＰのプロトコルメッセージのやりとりは、ＩＰの上に実装される。従って、ＡＴＭのＶＣなどをオンデマンドで作成する場合は、実際にＡＴＭが用意しているシグナリング機構を利用する必要はなく、この制約がないので柔軟でかつ効率の良い資源予約が可能となる。
【０１１２】
また、ＡＳＰは、主にＲＳＶＰやＳＴ−２などと同等な機能を持つが、柔軟にＡＴＭのＶＣに対応し、次のような機能を有する。すなわち、資源の予約は、レシーバ側主導およびセンダ側主導の何れも可能であること、ハードステートおよびソフトステートの何れも可能であること、ＡＴＭのＶＣを考慮した柔軟なセットアップが可能であること、プロトコル制御（予約制御）専用帯域（資源）の割り当てが可能であることなどの機能を有する。
図１１は、ＡＳＰのヘッダのフォーマットの例を表している。図１１中のフラグ（ｆｌａｇｓ）フィールドには、資源を予約する方向が単方向であるか双方向であるかを指示する情報がセットされる。ｐｒｅｖ＿ｈｏｐフィールドには、メッセージのやりとりがレシーバとセンダとで往復する場合に、メッセージが同一経路を通るようにするための情報がセットされる。次のＶＰＩフィールドには、ＶＰＩ（Ｖｉｒｔｕａｌ Ｐａｔｈ Ｉｄｅｎｔｉｆｉｅｒ）がセットされ、ＶＣＩフィールドには、ＶＣＩ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ Ｉｄｅｎｔｉｆｉｅｒ）がセットされる。
【０１１３】
その次のフィールドに、上記フローの情報（ｆｌｏｗｉｎｆｏ）がセットされる。このフローの情報は、レングス（ｌｅｎｇｔｈ）、アドレスファミリー（ａｄｄｒｅｓｓ ｆａｍｉｌｙ）、リザーブ（ｒｅｓｅｒｖｅｄ）、プロトコル識別子であるプロトコル（ｐｒｏｔｏｃｏｌ）、レシーバのＩＰアドレスであるデスティネーションＩＰアドレス（ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ）とセンダのＩＰアドレスであるソースＩＰアドレス（ｓｏｕｒｃｅ ＩＰ ａｄｄｒｅｓｓ）、レシーバのポートアドレス（ｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ ａｄｄｒｅｓｓ）とセンダのポートアドレス（ｓｏｕｒｃｅ ｐｏｒｔ ａｄｄｒｅｓｓ）などである。
【０１１４】
その後に、センダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）とレシーバのフロースペック（ｒ＿ｆｌｏｗｓｐｅｃ）がセットされる。センダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）は、センダが送るデータに必要なＱｏＳを示し、レシーバのフロースペック（ｒ＿ｆｔｏｗｓｐｅｃ）は、レシーバが送るデータに必要なＱｏＳを示している。現在のプロトタイプでは、各々のフロースペックフィールドには、ＡＴＭのＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）サービスを設定するためのピークセルレート（Ｐｅａｋ Ｃｅｌｌ Ｒａｔｅ）が含まれるのみである。
【０１１５】
主にＡＳＰを実装する形態のルータとしては、図１２に示すようなバックボーンルータ（ｂａｃｋｂｏｎｅ ｒｏｕｔｅｒ）、図１３に示すようなエッジルータ（ｅｄｇｅ ｒｏｕｔｅｒ）、およびホームルータがある。これらに加えて、エンドホストもＡＳＰメッセージのやりとりをする必要がある。
【０１１６】
バックボーンルータ１４は、大規模なネットワークを構成するための中間ノードであって、その実体はＴＣＰ／ＩＰを理解するソフトウェアエンジン（ＩＰ ｅｎｇｉｎｅ）１５、およびＶＣ機構を提供するスイッチ部（例えばＡＴＭ ＳＷ）（ｓｗｉｔｃｈｉｎｇ ｅｎｇｉｎｅ）１６から構成される。すなわち、この場合は、バックボーンルータ同士が接続されることにより、ＩＰネットワークが構築されるが、ＶＣを設定することにより、カットスルーも可能となる。
【０１１７】
エッジルータ８１は、複数のバックボーンルータから構成される網に対する入出口に設置される。バックボーンに対する反対側には、他のネットワーク、または他のルータが接続される可能性がある。エッジルータ８１は、通常のＩＰのプロトコルスタックを持ち、１つ以上のＡＴＭインターフェイス８２乃至８４を有する。
【０１１８】
図１４は、ネットワーク全体の接続例を示している。同図に示すように、大容量のデータをネットワークに流すサーバ（センダ）９１，９７が、複数のバックボーンルータ１４からなるバックボーン９２に直接接続されていても構わないが、通常のエンドノード９４乃至９６は、エッジルータ９３を介してバックボーン９２に接続される。また、エッジルータ９３の先には、更にルータを設置することが可能である。エンドノード（レシーバ）９４は、ＡＴＭインターフェイス９４ａを介してエッジルータ９３に接続されている。エンドノード（レシーバ）９５は、ＡＴＭインターフェイス９５ａを介してエッジルータ９３に接続されている。エンドノード（レシーバ）９６は、ＡＴＭインターフェイス９６ａを介してエッジルータ９６に接続されている。
【０１１９】
ここで、ＡＳＰにとって重要なのは、各ルータで予約する資源、およびその方法である。バックボーンルータでは、スイッチ内のＶＣの設定が必要である。
【０１２０】
また、バックボーンルータ９２は、バックボーンにデータが流れる入り口において、特定のフローを新たに作成したＶＣ（資源）に対してマッピングする必要がある。ＶＣに対するマッピングはエッジルータが行う。サーバが直接バックボーンに接続されている場合は、そのノードのバックボーンに対するＡＴＭインターフェイスがＶＣに対するマッピングを行う必要がある。
【０１２１】
各ノードのＡＳＰモジュールには、図１５に示すような資源の予約状況を管理するための状態テーブルが維持される。
【０１２２】
このテーブルは、入力用のＶＣの情報と出力用のＶＣの情報を管理し、ＶＣとフロー情報（ｆｌｏｗｉｎｆｏ）を対応付けている。また、エッジルータの場合は、入力用と出力用のネットワークインターフェイスの情報も必要であるので、そのためのフィールドを設けるようにしている。この場合、対応するＶＣ情報のポート（ｐｏｒｔ）部は利用されなくなる。
【０１２３】
通常の通信、例えばＩＰの通信を行うためには、ＡＴＭのＶＣは双方向に作成する必要がある。しかし、ＡＳＰを用いることにより、柔軟にＶＣを確立することができる。
【０１２４】
アプリケーションによっては、通信が単方向であったり、双方向のものが存在する。例えば、ＶｏＤ（Ｖｉｄｅｏ ｏｎ Ｄｅｍａｎｄ）形式のアプリケーションの場合は、ビデオデータはサーバ（センダ）からクライアント端末（レシーバ）までの単方向にしか流れないが、例えばレシーバが画像の要求を行う場合などのようにサーバに向かう通信は起こり得る。すなわちこの場合は、例えば資源予約メッセージは、ＡＳＰに要求することによって資源予約メッセージが専用のＶＣを通してやりとりされる。また、それ以外の必要なやりとりは、デフォルトデータＶＣ（通常のＩＰの経路）を流れる。従って、このような場合においては、ＡＳＰに資源を要求するアプリケーションは、単方向通信を指定することによって単一方向のみのＶＣを張るだけで済み、識別子、およびバンド幅を節約することができる。また、放送側マルチキャストの場合の資源予約も、このような予約方式で十分実現可能である。
【０１２５】
ただし、ビデオコンファレンスなどの対話型のアプリケーションの場合は、双方向にデータが流れる。双方向にデータが流れる必要があることは、通常の通信と変わりがないが、ＡＳＰを用いた場合、アプリケーションは、各方向に流れるデータに対して各々異なるＱｏＳを設定することができる。各方向のデータの流れに対するＱｏＳの設定は、ＡＳＰヘッダ内にある２つのフロースペック（ｆｌｏｗｓｐｅｃ）フィールドの値（ｓ＿ｆｌｏｗｓｐｅｃとｒ＿ｆｌｏｗｓｐｅｃ）に基づいて行われる。何れかのフロースペックフィールドにヌル（ＮＵＬＬ）値が含まれる場合、その方向のＶＣの予約は行われない。
【０１２６】
図１６は、レシーバ４７がＱｏＳを知っている場合、単方向のＶＣが確立される手順を示している。なお、ルータ４２，４６はエッジルータ、ルータ４３，４４，４５はバックボーンルータである。すなわち、レシーバ４７は、ＡＳＰヘッダのフラグ（ｆｌａｇｓ）フィールドに、ＶＣを確立する方向が単方向であることを示す例えば値０をセットし、ＡＳＰヘッダのセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドにＶＣのバンド幅（例えば、５Ｍｂｐｓ（メガビット／秒））等を表す情報を設定し、センダ４１に送信する。ＡＳＰのメッセージがレシーバ４７からセンダ４１に流れていくと、各ルータでは、ＡＳＰメッセージが流れる方向とは逆方向にＶＣを確立していく。
【０１２７】
先ず、エッジルータ（ｅｄｇｅ ｒｏｕｔｅｒ）４６は、ＡＳＰメッセージが流れる方向とは逆方向のＶＣを確立する。同様に、ＶＣは、バックボーンルータ（ｂａｃｋｂｏｎｅ ｒｏｕｔｅｒ）４５，４４，４３、エッジルータ４２により、それぞれＡＳＰメッセージが流れる方向とは逆方向に確立されていく。
【０１２８】
このとき、バックボーンルータ４３乃至４５を構成するスイッチングエンジンＳＷ（ｓｗｉｔｃｈｉｎｇ ｅｎｇｉｎｅ）においては、それぞれ所定の入力ポートと出力ポートが結ばれ、上記ＶＣが確立される。
【０１２９】
図１７は、センダしかＱｏＳを知らない場合にＶＣが張られていく手順を示している。
【０１３０】
先ず、レシーバ４７は、ＡＳＰヘッダのセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドにヌル（ＮＵＬＬ）値を設定したＡＳＰメッセージをセンダ４１に送信し、ＶＣの確立を要求する。このＡＳＰメッセージを受け取ったセンダ４１は、このメッセージを解釈し、ＡＳＰヘッダのセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドに所定のバンド幅に対応する値をセットしたＡＳＰメッセージをレシーバ４７に返送する。各ルータは、このＡＳＰメッセージが流れる方向と同一の方向にＶＣを張ることになる。すなわち、ＶＣは、エッジルータ４２、バックボーンルータ４３，４４，４５、エッジルータ４６により、それぞれＡＳＰメッセージが流れる方向と同一の方向に張られていく。
【０１３１】
図１８は、センダ４１が予約を開始する場合にＶＣが張られていく手順を示している。この場合も、ＡＳＰメッセージは一方方向に流れ、ルータはＶＣを確立していく。すなわち、センダ４１は、ＡＳＰヘッダのセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドに所定のバンド幅に対応する値をセットしたＡＳＰメッセージをレシーバ４７に送信する。
【０１３２】
このＡＳＰメッセージに基づいて、先ず、エッジルータ４２は、ＡＳＰメッセージが流れる方向と同一方向にＶＣを確立する。次にＶＣは、バックボーンルータ４３，４４，４５、エッジルータ４６の順で確立されていく。
【０１３３】
また、大抵の場合、予約が終了したことを確認しないとセンダはデータを送ることができないので、この後、図示はしていないが、確認のためのＡＳＰメッセージがレシーバ４７からセンダ４１に向かって送られる。
【０１３４】
図１９は、センダ、レシーバの各々が自分がデータを送信するときに必要とするＱｏＳを知っている場合において、双方向通信が行われる手順を示している。この場合は、各方向にＡＳＰメッセージ（資源予約要求メッセージ）が流れると、各方向にＶＣが張られていく。
【０１３５】
すなわち、センダ４１は、ＡＳＰヘッダのセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドに下り方向（センダ４１からレシーバ４７に向かう方向）のＶＣのバンド幅に対応する値をセットしたＡＳＰメッセージをレシーバ４７に送信する。これにより、エッジルータ４２、バックボーンルータ４３，４４，４５、エッジルータ４６においては、この順で、ＡＳＰメッセージが流れる方向と同一方向である下り方向のＶＣが確立されていく。
【０１３６】
一方、レシーバ４７は、ＡＳＰヘッダのレシーバのフロースペック（ｒ＿ｆｌｏｗｓｐｅｃ）フィールドに上り方向（レシーバ４７からセンダ４１に向かう方向）のＶＣのバンド幅に対応する値をセットしたＡＳＰメッセージをセンダ４１に送信する。これにより、エッジルータ４６、バックボーンルータ４５，４４，４３、エッジルータ４２においては、この順で、ＡＳＰメッセージが流れる方向と同一方向である上り方向のＶＣが確立されていく。
【０１３７】
また、図２０に示すように、センダおよびレシーバの各々が自分がデータを受信するときに必要とするＱｏＳを知っている場合においては、図１９に示した場合とは逆に、各方向にＡＳＰメッセージ（資源予約要求メッセージ）が流れると、各ＡＳＰメッセージが流れる方向とは逆の方向にＶＣが張られていく。
【０１３８】
すなわち、センダ４１は、ＡＳＰヘッダのレシーバのフロースペック（ｒ＿ｆｌｏｗｓｐｅｃ）フィールドに上り方向（レシーバ４７からセンダ４１に向かう方向）のＶＣのバンド幅に対応する値をセットしたＡＳＰメッセージをレシーバ４７に送信する。これにより、エッジルータ４２、バックボーンルータ４３，４４，４５、エッジルータ４６においては、この順で、ＡＳＰメッセージが流れる方向とは逆の方向である上り方向のＶＣが確立されていく。
【０１３９】
一方、レシーバ４７は、ＡＳＰヘッダのセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドに下り方向（センダ４１からレシーバ４７に向かう方向）のＶＣのバンド幅に対応する値をセットしたＡＳＰメッセージをセンダ４１に送信する。これにより、エッジルータ４６、バックボーンルータ４５，４４，４３、エッジルータ４２においては、この順で、ＡＳＰメッセージが流れる方向とは逆の方向である下り方向のＶＣが確立されていく。
【０１４０】
図２１は、レシーバが双方向の通信に必要とされるＱｏＳを知っている場合にＶＣが確立される手順を示している。この場合、双方向のＶＣの作成は１つの資源予約要求メッセージで行われる。
【０１４１】
すなわち、レシーバ４７は、ＡＳＰヘッダのフラグ（ｆｌａｇｓ）フィールドに、ＶＣを確立する方向が双方向であることを示す例えば値１をセットする。そして、ＡＳＰヘッダのセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドに下り方向のＶＣのバンド幅に対応する値をセットし、レシーバのフロースペック（ｒ＿ｆｌｏｗｓｐｅｃ）フィールドに上り方向のＶＣのバンド幅に対応する値をセットし、そのＡＳＰヘッダを含むＡＳＰメッセージをセンダ４１に送信する。これにより、先ず、エッジルータ４６においては、レシーバのフロースペック（ｒ＿ｆｌｏｗｓｐｅｃ）フィールドに設定されたバンド幅を有する上り方向のＶＣ、およびセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドに設定されたバンド幅を有する下り方向のＶＣが確立される。次に、バックボーンルータ４５，４４，４３、エッジルータ４２においては、この順で、レシーバのフロースペック（ｒ＿ｆｌｏｗｓｐｅｃ）フィールドに設定されたバンド幅を有する上り方向のＶＣ、およびセンダのフロースペック（ｓ＿ｆｌｏｗｓｐｅｃ）フィールドに設定されたバンド幅を有する下り方向のＶＣがそれぞれ確立されていく。
【０１４２】
このように、ＡＳＰは、様々な方法でＶＣを確立することができ、また、上位レイヤがこれらの方法を選択することができるようになっているので、効率の良い、また、アプリケーションに適したセットアップを可能とすることができる。
【０１４３】
以上は、ＡＴＭとＩＰを統合化して、ＡＴＭシグナリングを利用しないで、オンデマンドにＶＣをセットアップするＡＳＰについて説明した。
【０１４４】
ここでは、それに加えて、ＡＳＰの機能を用いて、ＶＣ（資源）とフローの開係を動的に変更する機構について説明する。現在、ＶＣに対するデータは、エッジルータからレシーバまで潜ること、すなわちカットスルー（ｃｕｔ ｔｈｒｏｕｇｈ）することになる。従って、ＶＣに対するデータは、複数のバックボーンルータのスイッチを経由して、レシーバ側のエッジルータまでＡＴＭのＶＣを直接経由していく。
【０１４５】
エッジルータでデータが潜ることに注目すると、ここにフィードバックがかかるようにＡＳＰメッセージを発行するようにすれば、すでに作成されているＶＣに他のＶＣを利用している既存の通信を、通信に影響がないように移行させることができる。すなわち、通信中に、バックボーンに対する入口においては、ＶＣを変更させ、途中経路などを動的に変更することができる。
【０１４６】
以下、この機構をＡＳＰに組み込むことによって生じる利点について説明する。この機構は、ＡＳＰに限定されるものではなく、ＲＳＶＰなどと達動させる場合にも有効に利用できる。
【０１４７】
例えば、ＡＴＭシグナリングの場合は、ＶＣのセットアップが完了すると、その経路を変更するのは難しい。これは、ＶＣをエンドツーエンドで再度張らなければならないからである。一方、ＲＳＶＰは、丈夫（ｒｏｂｕｓｔ）で環境に適応することを利点として挙げているが、結局、現在のＩＰルーティングに従うと、経路が変わってしまうので、実時間通信には適切ではない場合がある。これを解決するために、ＲＳＶＰはルートピニング（ｒｏｕｔｅ ｐｉｎｎｉｎｇ）を導入し、明示的に予約された経路に対して、ルーティングによる変更を許可しないように設定することができるようになっている。
【０１４８】
この方法を利用することにより、通信が継続中であっても、経路を簡単に変更できるようになる。また、通常は経路は変更されないが、ＱｏＳルーティング（ｒｏｕｔｉｎｇ）などを導入することによって、経路変更を許可することも簡単にできる。
【０１４９】
また、この方法によれば、通信している最中にレシーブされたフロー（ｆｌｏｗ）を所定のＶＣにまとめることができ、ＶＣＩなどの資源を節約することができる。
【０１５０】
さらに、この方法によれば、ある組織、アプリケーションなどのリザベーション（ｒｅｓｅｒｖａｔｉｏｎ）をまとめることができる。
【０１５１】
また、この方法によれば、所定のデスティネーションに対して複数の通信路があり、新規セッションなどの通信がある程度の資源容量を必要とする場合、他のセッションの経路／資源を集めることができる。
【０１５２】
また、この方法によれば、通信中のセッションの資源予約状況を動的に変更することができる。
【０１５３】
ここでは、特に、エッジルータに注目しているが、この機構はバックボーンルータにおいても実現可能である。実装としては、注目しているフロー（ｆｌｏｗ）をリマップ（ｒｅｍａｐ）するためのＶＣの準備が整った後、エッジルータで高速にこの切り換えを行う。同等なことは、バックボーンルータで行っても構わないが、そのために必要とする情報を収集することがより困難であって、且つこのような機構を設けてバックボーンルータ自身の機能を複雑化することは望ましくない。
【０１５４】
エッジルータの場合は、末端側で集約している端末、またはホームルータなどの数をある程度把握することは可能であるので、それに応じた適切なルーティングを行うことができ、バックボーンルータよりも情報収集が限定されて簡単になる。
【０１５５】
この方法では、エッジの操作によって、流れるデータに影響があるということを注意しなければならない。先ず、センダ側のＶＣを切り替えることによって、送信するデータにロスが生じる可能性がある。
【０１５６】
また、レシーバ側のエッジでは、一時的に２つのＶＣからデータが送信されることになるので、受信側はデータを重複して受け取る可能性がある。
【０１５７】
このような点において、データの正当性を保証するために、信頼性の高いトランスポートプロトコルを利用することが望ましい。
【０１５８】
なお、上記実施の形態においては、ＶＣを予約する場合について説明したが、ＵＰＣ（Ｕｓａｇｅ Ｐａｒａｍｅｔｅｒ Ｃｏｎｔｒｏｌ）等の他の資源を予約する場合にも本発明を適用することができる。
【０１５９】
この例のおいては、ＩＰアドレスとソケットポート番号を組み合わせることより、サーバまたはクライアント端末を特定するようにしたが、他の方法を利用することもできる。
【０１６０】
なお、上記したような処理を行うコンピュータプログラムをユーザに提供する提供媒体としては、磁気ディスク、ＣＤ−ＲＯＭ、固体メモリなどの記録媒体の他、ネットワーク、衛星などの通信媒体を利用することができる。
【０１６１】
本発明の情報受信装置及び方法、情報提供装置、情報通信システムによれば、サービスが選択されると、資源予約および資源予約解除に必要な処理を行うようにしたので、ユーザが意識することなく、資源の予約またはその解除を行うことができる。
【図面の簡単な説明】
【図１】図１は、本発明を適用したクライアント端末のネットワークの構成例を表す図である。
【図２】図２は、クライアント端末の内部の構成例を表す図である。
【図３】図３は、ビデオサーバの内部の構成例を表す図である。
【図４】図４は、クライアントＩ／Ｆの画面の表示例を表す図である。
【図５】図５は、クライアント設定ファイルに設定されているデータ（資源予約パラメータ）の一例を表す図である。
【図６】図６は、クライアント端末の動作例を説明するためのフローチャートである。
【図７】図７は、クライアントＩ／Ｆの画面の他の表示例を表す図である。
【図８】図８は、ビデオサーバの動作例を説明するためのフローチャートである。
【図９】図９は、資源予約要求メッセージを受信側が発行している様子の説明に用いる図である。
【図１０】図１０は、ＡＳＰの一構成例を示す図である。
【図１１】図１１は、ＡＳＰのヘッダのフォーマットの一例を示す図である。
【図１２】図１２は、バックボーンルータの構成例を示す図である。
【図１３】図１３は、エッジルータの構成例を示す図である。
【図１４】図１４は、ネットワークの構成例を示す図である。
【図１５】図１５は、ＡＳＰ内部テーブルを示す図である。
【図１６】図１６は、レシーバがＱｏＳを知っている場合のＡＳＰメッセージの流れと単方向のＶＣが確立されるまでの手順の説明に用いる図である。
【図１７】図１７は、センダしかＱｏＳを知らない場合のＡＳＰメッセージの流れと、ＶＣが張られていく手順の説明に用いる図である。
【図１８】図１８は、センダが予約を開始する場合のＡＳＰメッセージの流れと、ＶＣが張られていく手順の説明に用いる図である。
【図１９】図１９は、センダ、レシーバの各々がＱｏＳを知っている場合の双方向通信が行われる手順の説明に用いる図である。
【図２０】図２０は、センダおよびレシーバの各々がＱｏＳを知っている場合の各ＡＳＰメッセージの流れと、その逆方向にＶＣが張られていく手順の説明に用いる図である。
【図２１】図２１は、レシーバが双方向の通信に必要とされるＱｏＳを知っている場合にＶＣが確立される手順の説明に用いる図である。
【符号の説明】
１１，１２  クライアント端末、２１，２２  ルータ、２２  ネットワーク、３２  ビデオサーバ、５０  制御部、５１  操作部、５２  表示部、５３  通信部、５４  データベース
【図１】
0004341181.tif 000002
【図２】
0004341181.tif 000003
【図３】
0004341181.tif 000004
【図４】
0004341181.tif 000005
【図５】
0004341181.tif 000006
【図６】
0004341181.tif 000007
【図７】
0004341181.tif 000008
【図８】
0004341181.tif 000009
【図９】
0004341181.tif 000010
【図１０】
0004341181.tif 000011
【図１１】
0004341181.tif 000012
【図１２】
0004341181.tif 000013
【図１３】
0004341181.tif 000014
【図１４】
0004341181.tif 000015
【図１５】
0004341181.tif 000016
【図１６】
0004341181.tif 000017
【図１７】
0004341181.tif 000018
【図１８】
0004341181.tif 000019
【図１９】
0004341181.tif 000020
【図２０】
0004341181.tif 000021
【図２１】
0004341181.tif 000022