(57)【要約】【課題】  ベストエフォート型のネットワーク技術を用いて、カメラと映像出力装置を接続して監視システムを構築する場合や、連続して送信される画像データをプリント出力するプリントシステムを構築する場合に、管理主体なしにリアルタイムデータの送受信端のみで、アイソクロナスチャネルが成立するか否かを判断することができるようにする。【解決手段】  アイソクロナスチャネルを確立する送信側端末は、アイソクロナスチャネルの受信側端末にアイソクロナスチャネルのストリーム経路の確認を行う手段と、得られた経路と既設のアイソクロナスチャネル経路との比較に基づいて、チャネル開設可否判断する手段と、そこで判断された該当チャネル開設可否に関する判断結果を受信端末に伝える手段と、アイソクロナス性のあるリアルタイムストリーム送信終了時に受信端末にアイソクロナスチャネル開放を伝える手段とを有する。【選択図】  図１
2005260779.tif 000002
【特許請求の範囲】
【請求項１】
ステーション間をノードによって相互に繋ぐネットワークに、等時性を要するリアルタイムなデータストリームを送受信するネットワーク端末が接続されるネットワークシステムであって、
送信装置と受信装置との間に送受信されるリアルタイムデータストリームのチャネルを、等時性を保証して確立する際に、送信装置と受信装置と以外に、第３のネットワーク管理主体を設置せずに、複数のリアルタイムデータストリーム送受信対を提供することを特徴とするリアルタイムデータストリーム送受信ネットワークシステム。
【請求項２】
ネットワークに接続され、リアルタイムストリームチャネルを確立したい送信端末であって、
上記リアルタイムストリームチャネルの受信側端末に、リアルタイムストリームチャネルのストリーム経路を確認する経路確認手段と；
上記経路確認手段が確認した経路と、既設のリアルタイムストリームチャネル経路との比較に基づいて、チャネル開設の可否を判断するチャネル開設可否判断手段と；
上記チャネル開設可否判断手段が判断した該当チャネル開設可否の判断結果を、受信端末に伝える判断結果伝達手段と；
リアルタイムストリーム送信終了時に、リアルタイムストリームチャネル開放を、受信端末に伝える開放伝達手段と；
を有し、アイソクロナスチャネル確立に先立ち、ネットワークのＱＯＳ管理主体に、これから開設するアイソクロナスチャネルの成立不成立についての判断を問い合わせずに、上記アイソクロナス送信端末内で上記判断を行うことを特徴とするリアルタイムストリーム送信装置。
【請求項３】
ネットワークに接続され、リアルタイムストリームチャネルを確立したい受信端末であって、
送信端末側からのリアルタイムストリームチャネルのストリーム経路確認要求に応じて、リアルタイムストリームチャネルのストリーム経路を確認するストリーム経路確認手段と；
上記ストリーム経路確認手段が確認したストリーム経路を、送信端末側に通知する第１のストリーム経路通知手段と；
送信端末側からのリアルタイムストリームチャネルの成立可否判断に基づいて確立されたリアルタイムストリームチャネルのストリーム経路を、他のリアルタイムストリーム送信端末または受信端末に通知する第２のストリーム経路通知手段と；
送信端末から与えられたリアルタイムストリームチャネル開放指示に応じて、該チャネルのストリーム経路がそのリアルタイムストリームチャネルから開放されたことを、他のリアルタイムストリーム送信端末または受信端末に通知する開放通知手段と；
を有し、リアルタイムストリームチャネル確立時に、送信端末ＩＤ、受信端末ＩＤ、コネクションそのものに割り振られたＩＤを含む当該チャネルに関する情報を、管理または通知する必要がないことを特徴とするリアルタイムストリーム受信装置。
【請求項４】
ネットワークに接続され、リアルタイムストリームの送受信チャネルを確立したい送受信端末であって、
リアルタイムストリーム送信に際して、
リアルタイムストリームの受信側端末に、リアルタイムストリームチャネルのストリーム経路を確認する第１のストリーム経路確認手段と；
上記第１のストリーム経路確認手段が得たストリーム経路と、既設のリアルタイムストリームチャネル経路とを比較することによって、チャネル開設可否を判断するチャネル開設可否判断手段と；
上記チャネル開設可否判断手段が判断した該当チャネル開設可否に関する判断結果を、受信端末に伝える判断結果通知手段と；
リアルタイムストリーム送信終了時に、受信端末にリアルタイムストリームチャネル開放を伝える第１の開放通知手段と；
を有し、アイソクロナスチャネル確立に先立ち、ネットワークのＱＯＳ管理主体に、これから開設するアイソクロナスチャネルの成立不成立についての判断を問い合わせずに、該アイソクロナス送信端末内で、その判断を行い、
一方、リアルタイムストリーム受信に際して、
送信端末側からのリアルタイムストリームチャネルのストリーム経路確認要求に応じて、リアルタイムストリームチャネルのストリーム経路を確認する第２のストリーム経路確認手段と；
上記第２のストリーム経路確認手段が確認したストリーム経路を、送信端末側に通知する第１のストリーム経路通知手段と；
送信端末側からのリアルタイムストリームチャネルの成立可否判断に基づいて確立されたリアルタイムストリームチャネルのストリーム経路を、他のリアルタイムストリーム送信端末または受信端末に通知する第２のストリーム経路通知手段と；
送信端末から与えられたリアルタイムストリームチャネル開放指示によって、該チャネルのストリーム経路が、そのリアルタイムストリームチャネルから開放されたことを、他のリアルタイムストリーム送信端末または受信端末に通知する第２の開放通知手段と；
を有し、リアルタイムストリームチャネル確立時に、送信端末ＩＤ、受信端末ＩＤ、コネクションそのものに割り振られたＩＤを含む当該チャネルに関する情報を、管理または通知する必要がないことを特徴とするリアルタイムストリーム送受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
ネットワークに接続され、このネットワークを経由し、映像や音声等のリアルタイムデータを送受信するＳＴＢや端末に関する技術である。
【背景技術】
【０００２】
ＣＳＭＡ／ＣＤ方式や、全２重方式によるベストエフォート型ネットワークにおいて、音声や映像等のリアルタイムデータのストリームを伝送するニーズが高まっている。
【０００３】
しかし、ベストエフォート型ネットワークの性質上、リアルタイムな映像や音声のストリーム（情報）を、決められた時間内で決められた量を、確実に伝送することは、そのままでは、困難性を有する。
【０００４】
この困難性は、リアルタイム性を必要とするアプリケーションに対するＱＯＳ（Ｑｕａｌｉｔｙ  Ｏｆ  Ｓｅｒｖｉｃｅ）を保証する課題として定義され、この課題を大きく分類すると、遅延保証、遅延分散保証、帯域保証、パケット損失率保証に分けられる。これらの課題を解決するための技術として、以下の（ａ）〜（ｂ）の４つの技術要素が挙げられる。
【０００５】
（ａ）クラス分類（Ｃｌａｓｓｉｆｉｅｒ）
ルータやスイッチにおいて、到着したパケットを、送信元や送信先、ＴＣＰ／ＵＤＰポート番号、Ｔｏｓフィールドに基づいてトラフィックを分類する。
【０００６】
（ｂ）アドミッション制御（Ａｄｍｉｔｉｏｎ  ｃｏｎｔｒｏｌ）
セッション毎に資源の予約をコントロールする方法であり、セッション開始時に、セットアッププロトコルによって、パス上の資源を確保し、確保に失敗すると、セッションは開始されない。
【０００７】
（ｃ）パケットスケジューラ（Ｐａｃｋｅｔ  ｓｃｈｅｄｕｌｅｒ）
グループ分類されたパケットを送出するスケジュールを調整する方法であり、キューイング方法やバッファ管理方法によって様々な方法がある。
【０００８】
（ｄ）トラフィックシェーピング（Ｓｈａｐｅｒ）
流入するバーストトラフィックを一定レートにならす技術であり、これらの技術を実現するための枠組みとして、Ｉｎｔ−ｓｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ）や、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）や、Ｄｉｆｆ−ｓｅｒｖ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ）が挙げられる。
【０００９】
リアルタイムな映像や音声等のストリームデータを扱いたいネットワーク端は、上記枠組みで決められた手順に従い、ネットワークまたはネットワークの管理主体に、リソース予約し、この予約を受けたネットワークは、ネットワークを構成するルータやスイッチの内部において、上記技術要素であるクラス分類やアドミッション制御やパケットスケジュールを行い、ＱＯＳ保証を試みる（たとえば、特許文献１参照。）。
【００１０】
このときに、ネットワーク端は、予約したリソースの範囲内に、トラフィックをシェーピングする必要がある。
【００１１】
図５は、ネットワークのイメージを示す図である。
【００１２】
ストリームを送信したい端末（１１０）、（１１２）、（１１３）は、ネットワーク管理主体（１２６）に、上記枠組みに従ったリソース予約行為を行う。ＳＷネットワーク（１２５）は、管理主体（１２６）の指示に従い、実際には、ネットワークを構成するノードであるルータやスイッチにおいて、クラス分類、アドミッション制御、パケットスケジューリングを行い、ストリームを送信したい端末が予約した資源を保証する。
【００１３】
各端末（１１０）、（１１２）、（１１３）は、予約した資源の範囲内で、ストリームを送信するように、トラフィックシェーピング制御を行う。このように、ＱＯＳ保証を実現するためには、ネットワーク端（端末）と、ネットワーク管理主体と、ネットワーク構成ノード（スイッチやルータ）とが相互に協調しながら動作する必要がある。
【００１４】
次に、「アイソクロナス通信（等時性通信）」について説明する。
【００１５】
図２は、従来の映像ストリームを示す図である。
【００１６】
ルータやＳＷによって構成されるネットワーク（図２ではルータもＳＷも単にＳＷとして記述してある）に、映像のリアルタイムデータを送信するカメラ１（１１０）、カメラ２（１１２）、カメラ３（１１３）、映像を出力する映像出力装置１（１１６）、映像出力装置２（１１４）、映像出力装置３（１１５）が接続されている。
【００１７】
さらに、このネットワークには、ネットワークのリソースを管理する管理主体（１１１）が接続されている。このネットワーク構成は、ベストエフォート型ネットワークでＱＯＳを保証した伝送を行う場合において、一般的な構成である。
【００１８】
まず、カメラ１（１１０）が、映像出力装置１（１１６）に、映像のリアルタイムストリームデータを送信する場合について考える。実際に、映像ストリームが伝送されるコネクションの経路として、経路（２７０）が想定される。
【００１９】
カメラ１（１１０）が、映像出力装置１（１１６）に映像ストリームを送信するに先立ち、ＱＯＳ保証のための資源予約処理を行う必要があることは上記の通りである。ここでは、管理主体（１１１）やＳＷ（１０３）、（１０４）、（１０２）、（１００）の協調動作によって、遅延保証、遅延分散保証、帯域確保、パケット損失保証がなされていることを前提として説明する。
【００２０】
カメラ１（１１０）は、映像出力装置１（１１６）に、映像データパケット（２７５）（Ｉ１、Ｉ２、Ｉ３…Ｉｎ）を送信する。このパケットは、カメラ１（１１０）の送信制御によって決められたパケット長で、しかも決められた時間間隔で、送信されているとする。ネットワークが理想的なＱＯＳを保証したとすれば、このパケット長と時間間隔とは、一切変更されず、伝送経路（２７０）において保証された一定の伝送遅延時間後に、映像出力装置１（１１６）に、パケットストリーム（２７５）を、等しいパケット長と等しい時間間隔とで受信する。
【００２１】
このコネクションが実現されれば、映像出力装置１（１１６）において、遅延分散（伝送遅延揺らぎ）を吸収するためのバッファを用意する必要がなく、すなわち撮影から表示までに要する時間は、伝送遅延時間のみである。
【００２２】
ここで、カメラ１（１１０）と映像出力（１１６）との映像ストリームコネクション（２７０）を使用したまま、カメラ２（１１２）から、映像出力装置２（１１４）に、映像ストリームコネクション（２７２）を確立し、カメラ３（１１３）から、映像出力装置３（１１５）に、映像ストリームコネクション（２７１）を確立する場合を考える。
【００２３】
カメラ２（１１２）から、映像出力装置２（１１４）には、図２に示す映像ストリーム（２７６）が送信され、カメラ３（１１３）から、映像出力装置３（１１５）には、図２に示す映像ストリーム（２７７）が送信される場合、ＳＷ１（１００）とＳＷ３（１０２）とのリンク（２７９）には、図２に示す映像ストリーム（２７８）が送信される必要がある。
【００２４】
これが実現されれば、ＳＷ３（１０２）において、リンク（２７９）に流れるストリーム（２７８）を、映像出力装置１（１１６）と、映像出力装置２（１１４）と、映像出力装置３（１１５）とに分離することによって、映像出力装置１（１１６）には、映像ストリーム（２７５）を提供し、映像出力装置２（１１４）には、映像ストリーム（２７６）を提供し、映像出力装置３（１１５）には、映像ストリーム（２７７）を提供することができる。
【００２５】
ただし、上記のように、２つのネットワークノードを連結する１本のリンクに、複数のアイソクロナスチャネルを載せる場合、そこに載せることが可能なアイソクロナスチャネルの上限は、連結された２つのノードの処理能力と、連結する１本のリンクの帯域資源とを考慮して判断する必要がある。
【００２６】
この判断は、複数の送受信対による複数のコネクションが、ネットワーク上のどのリンクにおいて競合するかを、適正に判断することに他ならず、一般には、コネクション確立前に、既存の全コネクションとそのリンクとについて客観的に管理している管理主体に、ネットワーク資源の余裕について、各端末が問い合わす際に、管理主体によって、上記判断が行われる。
【００２７】
このように、アイソクロナスチャネル確立のためには、端末と、管理主体と、ネットワークとが協調動作する必要があることは、上記の通りである。
【特許文献１】特開２００３−３０９８３２号公報
【発明の開示】
【発明が解決しようとする課題】
【００２８】
しかし、折角、一般に普及したベストエフォート型のネットワーク技術を用いて、たとえばカメラと映像出力装置とを接続して簡単な監視システムを構築する場合や、連続して送信される画像データをプリント出力する簡単なプリントシステムを構築する場合に、これらアイソクロナス性（等時性）のあるリアルタイムデータを送受信することに先立ち、その成立、不成立を確認するために、管理主体を設置し、その管理主体に、端末から様々な問い合わせを行った後に、実際のリアルタイムデータを送受信する操作が煩雑であるという問題がある。
【００２９】
本発明は、ベストエフォート型のネットワーク技術を用いて、たとえばカメラと映像出力装置を接続して簡単な監視システムを構築する場合や、連続して送信される画像データをプリント出力する簡単なプリントシステムを構築する場合に、管理主体なしにリアルタイムデータの送受信端のみで、アイソクロナスチャネルが成立するか否かを判断することができる通信方法、リアルタイムストリーム送受信端末制御方法、リアルタイムストリーム送受信端末を提供することを目的とする。
【課題を解決するための手段】
【００３０】
本発明は、アイソクロナスチャネルを確立したい送信側端末は、アイソクロナスチャネルの受信側端末に、アイソクロナスチャネルのストリーム経路の確認を行う手段と、そこで得られた経路と既設のアイソクロナスチャネル経路との比較に基づいて、チャネル開設可否判断する手段と、そこで判断された該当チャネル開設可否に関する判断結果を受信端末に伝える手段と、アイソクロナス性（等時性）のあるリアルタイムストリーム送信終了時に受信端末に対してアイソクロナスチャネル開放を伝える手段とを有する。
【発明の効果】
【００３１】
本発明によれば、ベストエフォート型のネットワーク技術を用いて、たとえばカメラと映像出力装置とを接続して簡単な監視システムを構築する場合や、連続して送信される画像データをプリント出力する簡単なプリントシステムを構築する場合に、管理主体なしにリアルタイムデータの送受信端のみで、アイソクロナスチャネルが成立するか否かを判断することができるという効果を奏する。
【発明を実施するための最良の形態】
【００３２】
発明を実施するための最良の形態は、次の実施例である。
【実施例１】
【００３３】
図１は、本発明の実施例１である送受信端末がアイソクロナスチャネルを確立する場合の手順を示すフローチャートである。
【００３４】
アイソクロナスチャネルを確立したい送信側端末は、アイソクロナスチャネルの受信側端末に、アイソクロナスチャネルのストリーム経路の確認を行う手段と、そこで得られた経路と既設のアイソクロナスチャネル経路との比較に基づいて、チャネル開設可否判断する手段と、そこで判断された該当チャネル開設可否に関する判断結果を受信端末に伝える手段と、アイソクロナス性（等時性）のあるリアルタイムストリーム送信終了時に受信端末に対してアイソクロナスチャネル開放を伝える手段とを有し、これによって、アイソクロナス送信端末は、アイソクロナスチャネル確立に先立ち、ネットワークのＱＯＳ管理主体に、これから開設するアイソクロナスチャネルの成立、不成立についての判断を問い合わせること無しに、該アイソクロナス送信端末内でその判断を行う。
【００３５】
アイソクロナスチャネルを受信したい端末は、送信端末側からのアイソクロナスチャネルのストリーム経路確認要求に応えて、アイソクロナスチャネルのストリーム経路を確認する手段と、その経路について送信端末側に通知する手段と、送信端末側からのアイソクロナスチャネルの成立可否判断に基づいて確立されたアイソクロナスチャネルのストリーム経路を、他のアイソクロナス送信端末または受信端末に通知する手段と、送信端末から与えられたアイソクロナスチャネル開放指示によって該アイソクロナスチャネルのストリーム経路が、そのアイソクロナスチャネルから開放されたことを、他のアイソクロナス送信端末または受信端末に通知する手段とを有し、これによって、このアイソクロナス受信端末は、アイソクロナスチャネル確立時に、そのチャネルに関する情報、特にコネクション管理に当たり、一般に管理主体に通知する必要がある送信端末ＩＤや受信端末ＩＤやコネクションそのものに割り振られたＩＤについて、管理または通知する必要がない。
【００３６】
さらに、チャネルの成立不成立を判断するために、送信端末から受信端末に、実際のストリームに近い負荷情報を流すこともないので、その送受信端とは無関係の他のアイソクロナスチャネルのストリーム通信を邪魔することがなく、ネットワークに負荷をかける前に、当該アイソクロナスチャネルが成立するか否かについて、送受信端末間でネットワークに殆ど負荷をかけずに、判断することができる。
【００３７】
図３は、実施例１が想定するネットワークシステムの構成を示す図である。
【００３８】
本実施例では、ネットワーク端末として、アイソクロナスストリームデータを送信するカメラ１（１１０）、カメラ２（１１２）、カメラ３（１１３）と、アイソクロナスストリームデータを受信する映像出力装置１（１１６）、映像出力装置２（１１４）、映像出力装置３（１１５）とが、ネットワークに接続されている。
【００３９】
ネットワークは、ＳＷ１（１００）に、ＳＷ３（１０２）、ＳＷ４（１０３）、ＳＷ５（１０４）、ＳＷ６（１０５）が接続され、ＳＷ４（１０３）には、カメラ１（１１０）が接続され、ＳＷ５（１０４）には、カメラ３（１１３）とカメラ２（１１２）とが接続され、ＳＷ６（１０５）には、映像出力装置２（１１４）が接続され、ＳＷ３（１０２）には、映像出力装置３（１１５）と映像出力装置１（１１６）とが接続されている。
【００４０】
このネットワーク上で、カメラ１（１１０）と映像出力装置１（１１６）とが、アイソクロナス映像ストリームを送受信し、このコネクションを（１２０）に示す。さらに、カメラ２（１１２）と映像出力装置２（１１４）とが、アイソクロナス映像ストリームを送受信するとし、このコネクションが、（１２１）である。さらに、カメラ３（１１３）と映像出力装置３も、アイソクロナス映像ストリームを送受信しようとし、このコネクションが、（１２２）である。
【００４１】
図６は、上記実施例において、ストリーム送信端末（１５０）とストリーム受信端末（１５１）との間における交信を示す図である。
【００４２】
図６において、アイソクロナス映像ストリームを送信するストリーム送信端末（１５０）、すなわち図３に示すカメラ１（１１０）、カメラ２（１１２）、カメラ３（１１３）と、アイソクロナス映像ストリームを受信するストリーム受信端末（１５１）、すなわち図３に示す映像出力装置１（１１６）、映像出力装置２（１１４）、映像出力装置３（１１５）との間で発生する通信について説明する。
【００４３】
ストリーム送信端末（１５０）は、まず、ストリーム受信端末（１５１）に、ストリーム送信経路確認要求（１５５）を送信する。ストリーム受信端末は、このストリーム送信経路確認要求（１５５）から得られた情報に基づいて、ストリーム送信端末（１５０）とストリーム受信端末（１５１）との間におけるノードとリンクの経路とについて解析する。この解析方法については、後述する。
【００４４】
ストリーム送信端末と受信端末との間の経路分析が終了したストリーム受信端末は、ストリーム送信経路応答（１５６）として、これから開設されるであろうストリームの経路情報をストリーム送信端末（１５０）に送信する。
【００４５】
ストリーム送信端末（１５０）は、得られた経路情報に基づいて、その経路でのアイソクロナスチャネル確立可否を判断し（この判断についての詳細は後述する）、ストリーム送信成否通知（１５７）を、ストリーム受信端末（１５１）に送信する。
【００４６】
ストリーム送信成否通知を受けたストリーム受信端末（１５１）は、ストリーム送信が成立する場合、そのストリーム経路についてアイソクロナス通信が行われていることを、他のアイソクロナス送受信の可能性がある端末に通知する。この通知が終了すると、ストリーム受信端末（１５１）は、ストリームデータ送信成否応答（１５８）を、ストリーム送信端末（１５０）に送信する。
【００４７】
その後に、ストリーム送信端末（１５０）から、実際のアイソクロナス映像ストリームデータに相当するストリームデータが、送信される（１５９）、（１６０）、（１６１）。ストリーム送信端末（１５０）側で、ストリーム送信の完了が認められると、ストリーム送信端末（１５０）は、ストリーム送信終了通知（１６２）を、ストリーム受信端末（１５１）に送信する。
【００４８】
ストリーム受信端末（１５１）は、ストリーム送信終了通知を受け、他のアイソクロナス送受信の可能性がある端末に、当該アイソクロナスチャネルで使用されていた経路の開放を通知し、ストリーム送信終了応答（１６３）を、ストリーム送信端末（１５０）に返信する。
【００４９】
次に、上記実施例において、アイソクロナス通信を開始するに当たり、ストリーム送信を行う送信端と、ストリーム受信を行う受信端とが行う処理について説明する。
【００５０】
図１において、ストリーム送信を行おうとする端末が、ストリーム送信処理を開始（１７０）すると、まず、ストリーム受信相手に、ストリーム送信経路確認要求（１７１）を送信する。これは、ストリーム送信端末とストリーム受信端末との間の経路調査を、ストリーム受信端末に依頼する意味を持っている。
【００５１】
ストリーム受信待ち処理を開始（１９０）しているストリーム受信端末は、送信端末からのストリーム送信経路確認要求を受信待ちし（１９１）、要求を受信すると（２１０）、ストリーム経路の確認作業を行う（１９３）。これらの作業として、何通りかが考えられる。
【００５２】
本実施例において、通信経路上に存在しているネットワークノードを、トレースルートによって検出する。すなわち、ストリーム受信端末が、ストリーム送信端末からストリーム送信経路確認要求（２１０）を受けた場合、その送信元ＩＰアドレスに基づいて、そのＩＰアドレスに、ＩＣＭＰによるＥｃｈｏ  Ｒｅｑｕｅｓｔを行うが、このときに、ＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）を小さく設定し、ストリーム送信経路確認要求の送信元ＩＰアドレスに、Ｅｃｈｏ  Ｒｅｑｕｅｓｔを送信する。
【００５３】
すると、ネットワークノードには、上記ＴＴＬが０になったＩＰフレームを転送しない決まり、また、上記ＴＴＬが０になったためにそのフレームを転送しない場合は、そのフレームの送信元に、その旨を伝える義務がある。
【００５４】
すなわち、ストリーム受信端末は、上記ＴＴＬを１つずつ増やし、ストリーム送信端末から、Ｅｃｈｏ  Ｒｅｐｌｙがあるまで、ＩＣＭＰのＥｃｈｏ  Ｒｅｑｕｅｓｔを送り続ければ、ストリーム受信端末まで到達しなかったＩＣＭＰのＥｃｈｏ  Ｒｅｑｕｅｓｔの破棄通知が、経路上の経由ネットワークノードから得られる。つまり、ストリーム送受信経路上に存在しているネットワークノードのＩＰアドレスリストを得ることができる。このように、ＩＰパケットが経由する経路上のネットワークノードのＩＰアドレスを割り出す方法は、トレースルートという一般的な方法であり、ネットワーク管理の際等によく用いられている。
【００５５】
この他にも、ストリーム送信経路確認要求（２１０）を検出したネットワークノードが、ストリーム送信経路確認要求パケットに、ネットワークノードの存在とＩＤを示す印とを入れる方法等が考えられる。この場合、ストリーム受信端末は、ストリーム送信経路確認要求パケットの内容を解析することによって、経由ネットワークノードについて割り出すことができる。
【００５６】
ストリーム受信端末が、ストリーム送信経路確認要求（２１０）に応じて、上記方法によって、ストリーム経路確認を完了すると、ストリーム受信端末からストリーム送信端末に、検出したストリーム経路についての情報を載せたストリーム送信経路応答を送信する（１９４）。
【００５７】
これを受けたストリーム送信端末は、自分が持っている既設アイソクロナスチャネル経路情報と比較し（２１１）、（１７２）、これから開設しようとするアイソクロナスチャネルが開設可能であるかどうかを判断する（１７３）。
【００５８】
なお、この判断方法の詳細については、後述する（★２）。
【００５９】
ストリーム送信端末は、この判断に基づいて、そのアイソクロナスストリームチャネル開設可否に関する通知を、ストリーム受信端末に行う（２１２）、（２１３）、（１７４）、（１７９）。
【００６０】
これを受信したストリーム受信端末（１９５）は、そのチャネルの開設可否によって、以下の処理を行う。すなわち、そのストリームが開設成立通知を受信すれば（１９６）、先に確認したそのストリームのネットワークノード経路に関して、他のストリーム送信端末または受信端末に通知する（１９７）（★１）。
【００６１】
本実施例では、この通知方法として、ブロードキャストによる方法を採用する。すなわち、開設されるアイソクロナスチャネルで使用されているルータ経路情報は、チャネル開設可能の判断通知を受けた時点で、受信端末から全端末に向けてブロードキャストする。
【００６２】
図８は、上記実施例における既設チャネル保持動作を示すフローチャートである。
【００６３】
ブロードキャストを受信したストリーム送信端末は、図８に示す既設チャネル保持動作を常に行っている。すなわち、ストリーム受信端末から、チャネル経路に関する情報のブロードキャストを受けると（２３６）、チャネルが開設され、そのチャネルで使用される経路上のネットワークノードを、テーブルに保存する（２３８）。また、チャネル開放に伴い、その経路ノードから外れたブロードキャスト通知を、ストリーム受信端末から受ければ、それに従い、既存チャネルで使用される経路上のネットワークノードから外す処理を行う。
【００６４】
別の方法として、規模の小さいネットワークであれば、アイソクロナスストリームを送信する可能性のある端末の全てを、全ての受信端末に登録し、アイソクロナスチャネル開設が決まった時点で、受信端末からストリーム送信可能性のある全送信端末に、ユニキャストで通知する方法が考えられる。
【００６５】
図７は、上記実施例における既設チャネル保持動作を示すフローチャートである。
【００６６】
この場合、その通知を受けたストリーム送信端末は、図７に示す既設チャネル保持動作を常に行う。すなわち、ストリーム受信端末から、チャネル経路に関する情報を受け取ると（２３１）、チャネルが開設され、そのチャネルで使用される経路上のネットワークノードを、テーブルに保存する（２３３）。また、チャネル開放に伴い、経路ノードがチャネルから開放されたことを、ストリーム受信端末から検出すれば、経路上のネットワークノードから外すように、テーブルを更新する（２３３）。
【００６７】
一方、ストリーム送信端末が、既設チャネル経路と、これから開設しようとするチャネル経路とを比較した結果、チャネル開設不能であると判断した場合、ストリーム送信が不成立であることを、受信端末に通知し（１７９）、（２１３）、これを受けたストリーム受信端末（１９５）、（２０２）は、ストリーム送信不成立応答を送信し（２０３）、（２１４）、ストリーム受信待ち処理を終了し（２０４）、必要ならば、新たにストリーム受信待ち処理を再び開始する（１９０）。また、ストリーム送信不成立応答を受信したストリーム送信端末（２１４）、（１８０）は、ストリーム送信処理を終了し（１８１）、必要に応じて、ストリーム送信処理を再び開始する（１７０）。
【００６８】
上記（★１）においてストリーム受信端末が確立されたストリームの経路を、他のストリーム送信端末に通知した（１９７）後に、ストリーム受信端末が、ストリーム送信端末に、ストリーム送信成否応答を送信する（１９８）ことによって、上記通知が終了した旨を通知する（２１５）。これを受信した（１７５）ストリーム送信端末は、実際のアイソクロナスデータストリームの送信を、初めて開始する（１７６）。
【００６９】
ストリーム送信端末が、撮影の終了、送信データの終了を検出すると、ストリーム送信端末は、ストリーム送信終了通知を、ストリーム受信端末に送信する（１７７）。これを受信した（２１６）、（１９９）ストリーム受信端末は、ストリームチャネルの経路の開放を、全ストリーム送信端末に通知する（２００）。
【００７０】
このときの通知方法として、ブロードキャスト方式とユニキャスト方式とがあるが、本実施例では、ブロードキャスト方式を採用している。詳細は、上記の通りである。ストリーム受信端末は、経由情報の開放通知（２００）を終了すると、ストリーム送信終了応答通知を、ストリーム送信端末に送信し（２０１）、ストリーム受信待ち処理を終了する（２０４）。
【００７１】
ここで、ストリーム受信端末は、必要に応じて、ストリーム受信待ち処理を再び開始（１９０）する。ストリーム送信終了応答通知を受信（１７８）、（２１７）したストリーム送信端末は、ストリーム送信処理を終了する（１８１）。ストリーム送信端末は、再び撮影を開始し、ストリーム送信を開始する必要性を認識した時点で、ストリーム送信処理を再度開始する（１７０）。
【００７２】
次に、図１の（１７３）の説明において後述するとした判断方法（★２）、つまり、既設チャネル経路と、これから開設するチャネル経路とを比較することによって、そのチャネルの開設可否を判断する方法について説明する。
【００７３】
図９は、上記実施例において使用する経路の表現方法を示す図であり、図３におけるコネクション（１２０）、（１２１）、（１２２）を示す図である。
【００７４】
この全ての情報を、ストリーム送信端末で管理してもよいが、本実施例では、ここまで多くの情報は管理しない。
【００７５】
たとえば、図９に示すチャネルＩＤ１は、図３に示すコネクション（１２０）を示すが、このコネクションでは、ノードとノードとを接続する線であるリンクは、２つ存在している。つまり、ＳＷ４とＳＷ１とのリンクと、ＳＷ１とＳＷ３とのリンクとである。
【００７６】
これら２つのリンクが、既存のコネクションのリンクである場合、これら２つのリンクを、Ｌ１（４，１）、Ｌ２（１，３）と表現する。これから開設しようとする未確立のコネクションを構成するリンクである場合、たとえば、図９に示すチャネルＩＤ３は、図３に示すコネクション（１２２）が未設のコネクションである場合、Ｒ１（５，１）、Ｒ２（１，３）と示す。
【００７７】
Ｌｎ、Ｒｍ等のｎ、ｍの添え字は、そのリンクに対して、各ストリーム送信端末が付けた通し番号であり、ネットワークシステム全体としては、何ら意味を持たない。すなわち、図１の確立ストリーム経路通知（１９７）では、たとえば、図３に示すコネクション（１２０）が確立された場合、（３，１）、（１，４）という情報が送信されるとする。
【００７８】
ちなみに、ここでは、（３，１）と（１，３）とは、全く等価であると判断される。さらに、たとえば図３に示すコネクション（１２１）確立時には、経路通知（図１の（１９７））において、（５，１）、（１，６）という情報が送信される。
【００７９】
すなわち、図３に示すストリーム送信端末であるカメラ３（１１３）は、（１２０）、（１２１）のコネクション確立時に、それぞれ、（３，１）、（１，４）と、（５，１）、（１，６）という経路情報を受け取り、カメラ３（１１３）の内部では、Ｌ１（３，１）、Ｌ２（１，４）、Ｌ３（５，１）、Ｌ４（１，６）という既設チャネルの経路情報が蓄積される。
【００８０】
さらに、ここで、図３に示すコネクション（１２２）が、これから新たに開設されようとすると、図３に示すカメラ３（１１３）は、映像出力装置３（１１５）から、上記手順によって、これから開設されようとしているコネクション（１２２）の経路が、（５，１）、（１，３）であることが伝えられる。
【００８１】
これを受けたカメラ３（１１３）は、この経路情報については、これから開設されるリンクであると認識し、Ｒ１（５，１）、Ｒ２（１，３）を内部的に記憶する。すなわち、カメラ３（１１３）では、この段階（★３）で、図１に示す（１７３）におけるこれから開設するチャネル経路の比較と、チャネル開設判断とを行う。
【００８２】
次に、上記実施例におけるチャネル開設判断について、説明する。
【００８３】
図１０は、上記（１７３）におけるチャネル開設判断の動作を示すフローチャートである。
【００８４】
カメラ３（１１３）が、上記段階（★３）に至ると、カメラ３は、新チャネル開設可否判断を開始（２５０）する。まずは、検索リンクのインデクスについて、既存経路用インデクスｎと、これから開設するための経路用インデクスｍとを、それぞれ、１に初期化する（２５１）。
【００８５】
次に、これから開設しようとするチャネルの経路Ｒｍを読み込む（２５２）。ここで、経路用インデクスｍは、１に初期化されているので、Ｒ１（５，１）を読み込む。次に、既存チャネル経路Ｌｎを読み込む（２５３）。ここで、ｎは、１に初期化されているので、Ｌ１（３，１）を読み込む。
【００８６】
次に、既存チャネル経路Ｌｎと、これから開設しようとするチャネルの経路Ｒｍとを比較する。ここで、ｎ、ｍが、ともに１であるので、まずは、Ｒ１（５，１）と、Ｌ１（３，１）とを比較する（２５４）。Ｒ１とＬ１（ＳＷ５とＳＷ１のリンクと、ＳＷ３とＳＷ１のリンク）とは、経路としては異なると判断できるので、次のＬｎと比較するために、ｎをインクリメントし（２５６）、次の既存チャネルリンクＬ２（１，４）を読み込む。
【００８７】
Ｒ１とＬ２とは、経路としては異なるので、再び次のＬｎと比較するために、ｎをインクリメントする（２５６）。ここで、Ｌ３（５，１）を読み込む。Ｒ１（５，１）とＬ３（５，１）とを比較すると、この経路は同じ経路であると判断できる。すなわち、Ｒ１は、既存のアイソクロナスチャネル経路Ｌ３（５，１）で競合していることが判明する。
【００８８】
ここで、カメラ３は、Ｌ３（５，１）が、新設のアイソクロナスチャネルと競合していることを記憶する（２５５）。これと同様にして、新設チャネルの経路Ｒ１、Ｒ２と、既設チャネルの経路Ｌ１−Ｌ４とを比較し、既設チャネルと新設チャネルとが、どの経路で、いくつ競合しているかをカウントする。
【００８９】
ここで、新設チャネルの経路Ｒ１、Ｒ２の読み込みと比較とが完了した時点で、Ｌ３がカウント１になり、Ｌ２がカウント１になる。この数値に基づいて、アイソクロナスチャネル新設が可能であるかどうかを判断する（２５８）。
【００９０】
ここで、ストリームを送信する端末（この場合は、カメラ３）は、各経路に何本のアイソクロナスチャネルを開設可能であるかを、予め登録する必要がある。本実施例では、この許容カウントが３であると設定されている。Ｌ３もＬ２も、カウントが３以下であるので、カメラ３（１１３）は、映像出力装置３（１１５）へのアイソクロナスチャネルは、成立可能であると判断する（２５９）。
【００９１】
もし、各経路カウントのうちのひとつでも、許容カウントを上回っている場合、新設チャネル確立不能であると判断する（２６０）。このようにして、新設チャネル開設可否の判断を終了する（２６１）。その後に、アイソクロナスチャネル送信端末は、図１における（１７３）よりも先の手順へ進む。
【００９２】
上記実施例によれば、図４に示すように、ネットワーク（１２５）に接続されているカメラ１（１１０）、カメラ２（１１２）、カメラ３（１１３）と、映像出力装置１（１１６）、映像出力装置２（１１４）、映像出力装置３（１１５）等のストリーム端末のみの構成によって、管理主体を設置せずに、ベストエフォート型のネットワーク形態を用い、アイソクロナス性（等時性）のあるリアルタイムデータを送受信することができる。
【００９３】
また、そのアイソクロナス送信端末は、アイソクロナスチャネル確立に先立ち、ネットワークのＱＯＳ管理主体に、これから開設するアイソクロナスチャネルの成立、不成立についての判断を問い合わせることなく、該アイソクロナス送信端末内で、その判断を行うことができる。
【００９４】
さらに、このアイソクロナス受信端末は、アイソクロナスチャネル確立時に、そのチャネルに関する情報、特に、コネクション管理に当たり、一般に管理主体に通知する必要がある送信端末ＩＤ、受信端末ＩＤ、コネクションそのものに割り振られたＩＤについて、管理または通知をする必要がない。
【図面の簡単な説明】
【００９５】
【図１】本発明の実施例１である送受信端末がアイソクロナスチャネルを確立する場合の手順を示すフローチャートである。
【図２】従来例における映像ストリームを示す図である。
【図３】実施例１が想定するネットワークシステムの構成を示す図である。
【図４】ネットワークのイメージを示す図である。
【図５】ネットワークのイメージを示す図である。
【図６】上記実施例において、ストリーム送信端末（１５０）とストリーム受信端末（１５１）との間における交信を示す図である。
【図７】上記実施例における既設チャネル保持動作を示すフローチャートである。
【図８】上記実施例における既設チャネル保持動作を示すフローチャートである。
【図９】上記実施例において使用する経路の表現方法を示す図であり、図３におけるコネクション（１２０）、（１２１）、（１２２）を示す図である。
【図１０】上記（１７３）におけるチャネル開設判断の動作を示すフローチャートである。
【符号の説明】
【００９６】
１００…ＳＷ１、
１０２…ＳＷ３、
１０３…ＳＷ４、
１０４…ＳＷ５、
１０５…ＳＷ６、
１１０…カメラ１、
１１２…カメラ２、
１１３…カメラ３、
１１４…映像出力装置２、
１１５…映像出力装置３、
１１６…映像出力装置１、
１５０…ストリーム送信端末、
１５１…ストリーム受信端末。
【図１】
2005260779.tif 000003
【図２】
2005260779.tif 000004
【図３】
2005260779.tif 000005
【図４】
2005260779.tif 000006
【図５】
2005260779.tif 000007
【図６】
2005260779.tif 000008
【図７】
2005260779.tif 000009
【図８】
2005260779.tif 000010
【図９】
2005260779.tif 000011
【図１０】
2005260779.tif 000012