JP4375461B2 - クライアント装置、情報通信システム及びクライアント装置の制御処理方法 - Google Patents

クライアント装置、情報通信システム及びクライアント装置の制御処理方法 Download PDF

Info

Publication number
JP4375461B2
JP4375461B2 JP2007213918A JP2007213918A JP4375461B2 JP 4375461 B2 JP4375461 B2 JP 4375461B2 JP 2007213918 A JP2007213918 A JP 2007213918A JP 2007213918 A JP2007213918 A JP 2007213918A JP 4375461 B2 JP4375461 B2 JP 4375461B2
Authority
JP
Japan
Prior art keywords
content data
resource reservation
network
asp
data
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.)
Expired - Fee Related
Application number
JP2007213918A
Other languages
English (en)
Other versions
JP2008029019A (ja
Inventor
秀介 内海
隆介 猿渡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2007213918A priority Critical patent/JP4375461B2/ja
Publication of JP2008029019A publication Critical patent/JP2008029019A/ja
Application granted granted Critical
Publication of JP4375461B2 publication Critical patent/JP4375461B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5665—Interaction of ATM with other protocols
    • H04L2012/5667—IP over ATM

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、クライアント装置、情報通信システム及びクライアント装置の制御処理方法に関し、特に、通信網内のサーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置、情報通信システム及びクライアント装置の制御処理方法に関する。
例えば、各家庭まで敷設された光ファイバーケーブルを介して、電話やＩＳＤＮなど各種の通信サービスを提供するＦＴＴＨ（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）等の他の資源を予約する場合にも本発明を適用することができる。
この例においては、ＩＰアドレスとソケットポート番号を組み合わせることより、サーバまたはクライアント端末を特定するようにしたが、他の方法を利用することもできる。
なお、上記したような処理を行うコンピュータプログラムをユーザに提供する提供媒体としては、磁気ディスク、ＣＤ−ＲＯＭ、固体メモリなどの記録媒体の他、ネットワーク、衛星などの通信媒体を利用することができる。
上述したような本発明の実施の形態によれば、サービスが選択されると、資源予約および資源予約解除に必要な処理を行うするようにしたので、ユーザが意識することなく、資源の予約またはその解除を行うことができる。
なお、本発明は上述した実施の形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。
本発明を適用したクライアント端末のネットワークの構成例を表す図である。 クライアント端末の内部の構成例を表す図である。 ビデオサーバの内部の構成例を表す図である。 クライアントＩ／Ｆの画面の表示例を表す図である。 クライアント設定ファイルに設定されているデータ（資源予約パラメータ）の一例を表す図である。 クライアント端末の動作例を説明するためのフローチャートである。 クライアントＩ／Ｆの画面の他の表示例を表す図である。 ビデオサーバの動作例を説明するためのフローチャートである。 資源予約要求メッセージを受信側が発行している様子の説明に用いる図である。 ＡＳＰの一構成例を示す図である。 ＡＳＰのヘッダのフォーマットの一例を示す図である。 バックボーンルータの構成例を示す図である。 エッジルータの構成例を示す図である。 ネットワークの構成例を示す図である。 ＡＳＰ内部テーブルを示す図である。 レシーバがＱｏＳを知っている場合のＡＳＰメッセージの流れと単方向のＶＣが確立されるまでの手順の説明に用いる図である。 センダしかＱｏＳを知らない場合のＡＳＰメッセージの流れと、ＶＣが張られていく手順の説明に用いる図である。 センダが予約を開始する場合のＡＳＰメッセージの流れと、ＶＣが張られていく手順の説明に用いる図である。 センダ、レシーバの各々がＱｏＳを知っている場合の双方向通信が行われる手順の説明に用いる図である。 センダおよびレシーバの各々がＱｏＳを知っている場合の各ＡＳＰメッセージの流れと、その逆方向にＶＣが張られていく手順の説明に用いる図である。 レシーバが双方向の通信に必要とされるＱｏＳを知っている場合にＶＣが確立される手順の説明に用いる図である。
符号の説明
１１，１２ クライアント端末、２１，２２ ルータ、２２ ネットワーク、３２ ビデオサーバ、５０ 制御部、５１ 操作部、５２ 表示部、５３ 通信部、５４ データベース

Claims (6)

  1. ネットワーク内のサーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置であって、
    前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信手段と、
    前記通信手段を制御する制御手段と、
    前記通信手段より受信した前記コンテンツデータに基づく処理を実行する処理手段とを備え、
    前記制御手段は、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とするクライアント装置。
  2. 前記制御手段は、前記入力がなされた際に前記第１コンテンツデータを受信するためのコネクションを開放した後、前記ネットワークの資源を予約するための処理を実行することを特徴とする請求項１記載のクライアント装置。
  3. 前記制御手段は、前記ネットワークの資源を予約するための処理として、
    前記第２コンテンツデータの属性に該第２コンテンツデータの配信に必要なネットワークの資源を特定するための資源予約パラメータが含まれている場合、該資源予約パラメータに従いネットワークの資源を予約するための資源予約要求メッセージを送信し、
    前記資源予約パラメータが含まれていない場合、第２コンテンツデータの配信のみを要求するメッセージを送信し、ネットワークの資源を予約を前記サーバ装置に委ねることを特徴とする請求項１又は２記載のクライアント装置。
  4. 前記制御手段は、所定の入力が行われた場合に、予め設定された時間間隔で、ネットワークの資源を予約するための処理を実行し、受信対象コンテンツの切換を行うことを特徴とする請求項１乃至３の何れかに記載のクライアント装置。
  5. ネットワークに接続されたサーバ装置と、該サーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置とを有する情報通信システムであって、
    前記クライアント装置は、
    前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信手段と、
    前記通信手段を制御する制御手段と、
    前記通信手段より受信した前記コンテンツデータに基づく処理を実行する処理手段とを備え、
    前記制御手段は、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とする情報通信システム。
  6. ネットワーク内のサーバ装置によって提供されるコンテンツデータを取得し、該コンテンツデータに基づく処理を実行するクライアント装置の制御処理方法であって、
    前記ネットワークを介して、少なくとも前記コンテンツデータ及び前記サーバ装置が提供可能なコンテンツデータの属性を示す属性情報を受信する通信ステップと、
    前記通信ステップを制御する制御ステップと、
    前記通信ステップにより受信した前記コンテンツデータに基づく処理を実行する処理ステップとを備え、
    前記制御ステップは、第１コンテンツデータの受信中に受信対象コンテンツを第２コンテンツデータに切り替える旨の入力がなされると、前記属性情報に含まれている該第２コンテンツデータの資源予約パラメータに従い、ネットワークの資源を予約するための処理を実行することを特徴とするクライアント装置の制御処理方法。
JP2007213918A 1998-05-13 2007-08-20 クライアント装置、情報通信システム及びクライアント装置の制御処理方法 Expired - Fee Related JP4375461B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007213918A JP4375461B2 (ja) 1998-05-13 2007-08-20 クライアント装置、情報通信システム及びクライアント装置の制御処理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP12997198 1998-05-13
JP2007213918A JP4375461B2 (ja) 1998-05-13 2007-08-20 クライアント装置、情報通信システム及びクライアント装置の制御処理方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2000549000A Division JP4341181B2 (ja) 1998-05-13 1999-05-13 情報受信装置及び方法、情報配信装置、情報通信システム

Publications (2)

Publication Number Publication Date
JP2008029019A JP2008029019A (ja) 2008-02-07
JP4375461B2 true JP4375461B2 (ja) 2009-12-02

Family

ID=15022973

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2000549000A Expired - Fee Related JP4341181B2 (ja) 1998-05-13 1999-05-13 情報受信装置及び方法、情報配信装置、情報通信システム
JP2007213918A Expired - Fee Related JP4375461B2 (ja) 1998-05-13 2007-08-20 クライアント装置、情報通信システム及びクライアント装置の制御処理方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2000549000A Expired - Fee Related JP4341181B2 (ja) 1998-05-13 1999-05-13 情報受信装置及び方法、情報配信装置、情報通信システム

Country Status (3)

Country Link
US (3) US6693896B1 (ja)
JP (2) JP4341181B2 (ja)
WO (1) WO1999059295A1 (ja)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6693896B1 (en) * 1998-05-13 2004-02-17 Sony Corporation Information receiving device and method, information release device, and information communication system
US7685520B2 (en) * 2000-06-22 2010-03-23 Intel Corporation Electronic programming guide with selectable categories
US7111163B1 (en) 2000-07-10 2006-09-19 Alterwan, Inc. Wide area network using internet with quality of service
JP4548930B2 (ja) * 2000-11-15 2010-09-22 富士通株式会社 ラベル・スイッチング・ルータ
KR100442425B1 (ko) * 2000-11-15 2004-07-30 엘지전자 주식회사 이동통신 시스템에서 인터넷 아이피멀티캐스팅/브로드캐스팅 방법
US20020107939A1 (en) * 2001-02-07 2002-08-08 Ford Daniel E. System and method for accessing software components in a distributed network environment
US20030005455A1 (en) * 2001-06-29 2003-01-02 Bowers J. Rob Aggregation of streaming media to improve network performance
FR2829891B1 (fr) * 2001-09-18 2004-01-16 France Telecom Procede de reception par un terminal de contenus diffuses par une pluralite de canaux a travers un reseau informatique
JP4443833B2 (ja) * 2002-02-27 2010-03-31 パナソニック株式会社 情報再生方法、送信装置および受信装置
ES2303607T3 (es) * 2002-09-03 2008-08-16 NOKIA SIEMENS NETWORKS GMBH & CO. KG Procedimiento y aparato para proporcionar capacidad de multidifusion dentro de una red atm.
US7450501B2 (en) * 2002-12-11 2008-11-11 Broadcom Corporation Media processing system based on satellite set top box platform with telephony downstream and upstream data paths
US9357256B2 (en) * 2002-12-11 2016-05-31 Broadcom Corporation Third party media channel access in a media exchange network
US7496665B2 (en) * 2002-12-11 2009-02-24 Broadcom Corporation Personal access and control of media peripherals on a media exchange network
US7483985B2 (en) * 2002-12-11 2009-01-27 Broadcom Corporation Media search engine for a personal media network
US7424535B2 (en) * 2002-12-11 2008-09-09 Broadcom Corporation Management of multimedia display content in a media exchange network
US7593530B2 (en) 2002-12-11 2009-09-22 Broadcom Corporation Secure legacy media peripheral association with authentication in a media exchange network
US8589548B2 (en) * 2002-12-11 2013-11-19 Broadcom Corporation Remote management of TV viewing options in a media exchange network
US7496647B2 (en) * 2002-12-11 2009-02-24 Broadcom Corporation Personal inter-home media exchange network
US7475243B2 (en) 2002-12-11 2009-01-06 Broadcom Corporation Preventing a non-head end based service provider from sending media to a media processing system
US7424534B2 (en) * 2002-12-11 2008-09-09 Broadcom Corporation Common media consumption across multiple media processing systems via single user control
US8209382B2 (en) * 2002-12-11 2012-06-26 Broadcom Corporation Media exchange network supporting consumption of broadcast and user captured media
US8028093B2 (en) * 2002-12-11 2011-09-27 Broadcom Corporation Media processing system supporting adaptive digital media parameters based on end-user viewing capabilities
US8599779B2 (en) * 2003-05-15 2013-12-03 At&T Intellectual Property I, L.P. Methods, systems, and products for a metering application
US7912001B2 (en) * 2003-05-15 2011-03-22 At&T Intellectual Property I, L.P. Methods, systems, and products for a metering application
US7437458B1 (en) * 2003-06-13 2008-10-14 Juniper Networks, Inc. Systems and methods for providing quality assurance
IL159838A0 (en) * 2004-01-13 2004-06-20 Yehuda Binder Information device
GB0407144D0 (en) * 2004-03-30 2004-05-05 British Telecomm Networks
KR100735300B1 (ko) * 2005-01-04 2007-07-03 삼성전자주식회사 디지털 방송 채널정보 표시방법과 그에 따른 디지털 방송수신장치
JP4705786B2 (ja) * 2005-01-06 2011-06-22 株式会社日立製作所 ビデオクリップ表示装置
US20060206600A1 (en) * 2005-03-08 2006-09-14 Wong Allen T Method of operating a video-on-demand system that prevents congestion
US7889636B2 (en) * 2005-05-24 2011-02-15 Cisco Technology, Inc. System and method for implementing a mid-call policy in a RSVP environment
JP5243871B2 (ja) * 2008-07-18 2013-07-24 シャープ株式会社 映像再生装置
US8452148B2 (en) 2008-08-29 2013-05-28 Corning Cable Systems Llc Independently translatable modules and fiber optic equipment trays in fiber optic equipment
US11294135B2 (en) 2008-08-29 2022-04-05 Corning Optical Communications LLC High density and bandwidth fiber optic apparatuses and related equipment and methods
WO2010148195A1 (en) * 2009-06-19 2010-12-23 Corning Cable Systems Llc High capacity fiber optic connection infrastructure apparatus
CN106918885B (zh) 2009-06-19 2021-09-21 康宁光缆系统有限责任公司 高密度和带宽光纤装置以及相关设备和方法
US8948108B2 (en) * 2009-10-21 2015-02-03 Telefonaktiebolaget L M Ericsson (Publ) Resource reservation in multiple accesses
US9519118B2 (en) 2010-04-30 2016-12-13 Corning Optical Communications LLC Removable fiber management sections for fiber optic housings, and related components and methods
CN103415797B (zh) 2011-02-02 2016-01-27 康宁光缆系统有限责任公司 适用于为设备机架中的光学底板建立光学连接的稠密光纤连接器总成及相关的连接器与缆线
US8972526B2 (en) 2012-10-17 2015-03-03 Wal-Mart Stores, Inc. HTTP parallel processing router
US20150334063A1 (en) * 2014-05-15 2015-11-19 The Button Corporation Oy Trigger event based response execution with unintentional button press prevention
US10284900B2 (en) 2016-03-15 2019-05-07 Sony Corporation Multiview as an application for physical digital media

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03164837A (ja) * 1989-11-22 1991-07-16 Hitachi Ltd 通信制御処理装置の切替方法
JP3086075B2 (ja) 1992-07-10 2000-09-11 富士通株式会社 Ａｔｍ交換機における帯域予約方式
US5930473A (en) * 1993-06-24 1999-07-27 Teng; Peter Video application server for mediating live video services
JPH0832601A (ja) * 1994-07-21 1996-02-02 Hitachi Ltd 画像情報分配システム
US5757798A (en) 1994-07-21 1998-05-26 Hitachi, Ltd. Image information distribution system
US5818438A (en) * 1995-04-25 1998-10-06 Bellsouth Corporation System and method for providing television services
US5991811A (en) * 1995-09-04 1999-11-23 Kabushiki Kaisha Toshiba Information transmission system utilizing both real-time data transmitted in a normal-in-time direction and in a retrospective-in-time direction
JPH09121337A (ja) 1995-10-26 1997-05-06 Fujitsu Ltd ビデオ・オン・デマンド方法及びセンターシステム
US6094431A (en) * 1995-11-30 2000-07-25 Kabushiki Kaisha Toshiba Node device and network resource reservation method for data packet transfer using ATM networks
JP2933272B2 (ja) 1996-08-23 1999-08-09 株式会社村田製作所 共振器の製造方法
JPH10145395A (ja) * 1996-09-10 1998-05-29 Fujitsu Ltd ソース情報制御方法並びにソース情報受信装置及びソース情報送信装置並びにソース情報送受信システム
US6167025A (en) * 1996-09-11 2000-12-26 Telcordia Technologies, Inc. Methods and apparatus for restoring connections in an ATM network
US5963547A (en) * 1996-09-18 1999-10-05 Videoserver, Inc. Method and apparatus for centralized multipoint conferencing in a packet network
JP3825099B2 (ja) * 1996-09-26 2006-09-20 富士通株式会社 映像データ転送方式およびビデオサーバ装置
JP2892993B2 (ja) * 1996-09-30 1999-05-17 株式会社日立製作所 弾性表面波装置
US5850218A (en) * 1997-02-19 1998-12-15 Time Warner Entertainment Company L.P. Inter-active program guide with default selection control
US6006264A (en) * 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server
JP4352471B2 (ja) * 1998-02-19 2009-10-28 ソニー株式会社 通信システムおよび通信方法
US6170014B1 (en) * 1998-03-25 2001-01-02 Community Learning And Information Network Computer architecture for managing courseware in a shared use operating environment
US6693896B1 (en) * 1998-05-13 2004-02-17 Sony Corporation Information receiving device and method, information release device, and information communication system
JP4876758B2 (ja) 2006-07-31 2012-02-15 東レ株式会社 中空糸膜モジュールの検査方法および検査装置

Also Published As

Publication number Publication date
WO1999059295A1 (fr) 1999-11-18
USRE42204E1 (en) 2011-03-08
JP4341181B2 (ja) 2009-10-07
JP2008029019A (ja) 2008-02-07
USRE44554E1 (en) 2013-10-22
US6693896B1 (en) 2004-02-17

Similar Documents

Publication Publication Date Title
JP4375461B2 (ja) クライアント装置、情報通信システム及びクライアント装置の制御処理方法
US6496479B1 (en) Network resource reservation control method and apparatus, receiving terminal, sending terminal, and relay apparatus
JP3649367B2 (ja) パケット伝送制御方法および装置
US6751221B1 (en) Data transmitting node and network inter-connection node suitable for home network environment
US5862329A (en) Method system and article of manufacture for multi-casting audio visual material
JP3660443B2 (ja) データ転送制御システム及び中継装置
JP4389605B2 (ja) マルチキャスト情報配信システムおよびマルチキャスト情報配信方法
JP3719789B2 (ja) 通信端末装置及び中継装置
JP2003158543A (ja) 中継装置及び中継方法
JPH1065693A (ja) オンデマンド・システム
US5651005A (en) System and methods for supplying continuous media data over an ATM public network
US7154851B1 (en) Application-aware resource reservation in multiservice networks
US6359889B1 (en) Cell switching device for controlling a fixed rate connection
JP2003309832A (ja) テレビ会議予約システムおよびそのシステムに使用する会議予約サーバとネットワーク管理サーバ
JPH10308758A (ja) 通信装置
KR100333679B1 (ko) 멀티캐스트 통신 서비스 제공 시스템 및 멀티캐스트 서비스제어방법
JP3394430B2 (ja) ネットワークシステム及び交換機
JP2002118593A (ja) 設定されたＱｏＳカテゴリを有するサービスまたはアプリケーションの供給
JPH10308764A (ja) ネットワーク間接続装置および通信装置および通信方法
JP2000059392A (ja) Ａｔｍ交換機及びａｔｍコネクションの帯域及び品質制御方法
JP3607402B2 (ja) マルチメディア通信サービス制御装置
JPH11331155A (ja) 情報受信装置および方法、情報送信装置および方法、情報送受信装置および方法、並びに提供媒体
Shacham et al. Conducting a multiparty multimedia session over ATM: using hierarchically encoded data
JPH11103294A (ja) パケット伝送制御方法および装置
JP3512629B2 (ja) 帯域共用制御回路と帯域制御回路及び通信システム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090803

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090818

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090831

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120918

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120918

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130918

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees