JP4323986B2 - 送信装置、受信装置およびそれらの制御方法 - Google Patents

Description

ネットワークに接続され、このネットワークを経由し、映像や音声等のリアルタイムデータを送受信するＳＴＢや端末に関する技術である。

ＣＳＭＡ／ＣＤ方式や、全２重方式によるベストエフォート型ネットワークにおいて、音声や映像等のリアルタイムデータのストリームを伝送するニーズが高まっている。

しかし、ベストエフォート型ネットワークの性質上、リアルタイムな映像や音声のストリーム（情報）を、決められた時間内で決められた量を、確実に伝送することは、そのままでは、困難性を有する。

この困難性は、リアルタイム性を必要とするアプリケーションに対するＱＯＳ（Ｑｕａｌｉｔｙ Ｏｆ Ｓｅｒｖｉｃｅ）を保証する課題として定義され、この課題を大きく分類すると、遅延保証、遅延分散保証、帯域保証、パケット損失率保証に分けられる。これらの課題を解決するための技術として、以下の（ａ）〜（ｂ）の４つの技術要素が挙げられる。

（ａ）クラス分類（Ｃｌａｓｓｉｆｉｅｒ）
ルータやスイッチにおいて、到着したパケットを、送信元や送信先、ＴＣＰ／ＵＤＰポート番号、Ｔｏｓフィールドに基づいてトラフィックを分類する。

（ｂ）アドミッション制御（Ａｄｍｉｔｉｏｎ ｃｏｎｔｒｏｌ）
セッション毎に資源の予約をコントロールする方法であり、セッション開始時に、セットアッププロトコルによって、パス上の資源を確保し、確保に失敗すると、セッションは開始されない。

（ｃ）パケットスケジューラ（Ｐａｃｋｅｔ ｓｃｈｅｄｕｌｅｒ）
グループ分類されたパケットを送出するスケジュールを調整する方法であり、キューイング方法やバッファ管理方法によって様々な方法がある。

（ｄ）トラフィックシェーピング（Ｓｈａｐｅｒ）
流入するバーストトラフィックを一定レートにならす技術であり、これらの技術を実現するための枠組みとして、Ｉｎｔ−ｓｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ）や、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）や、Ｄｉｆｆ−ｓｅｒｖ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）が挙げられる。

リアルタイムな映像や音声等のストリームデータを扱いたいネットワーク端は、上記枠組みで決められた手順に従い、ネットワークまたはネットワークの管理主体に、リソース予約し、この予約を受けたネットワークは、ネットワークを構成するルータやスイッチの内部において、上記技術要素であるクラス分類やアドミッション制御やパケットスケジュールを行い、ＱＯＳ保証を試みる（たとえば、特許文献１参照。）。

このときに、ネットワーク端は、予約したリソースの範囲内に、トラフィックをシェーピングする必要がある。

図５は、ネットワークのイメージを示す図である。

ストリームを送信したい端末（１１０）、（１１２）、（１１３）は、ネットワーク管理主体（１２６）に、上記枠組みに従ったリソース予約行為を行う。ＳＷネットワーク（１２５）は、管理主体（１２６）の指示に従い、実際には、ネットワークを構成するノードであるルータやスイッチにおいて、クラス分類、アドミッション制御、パケットスケジューリングを行い、ストリームを送信したい端末が予約した資源を保証する。

各端末（１１０）、（１１２）、（１１３）は、予約した資源の範囲内で、ストリームを送信するように、トラフィックシェーピング制御を行う。このように、ＱＯＳ保証を実現するためには、ネットワーク端（端末）と、ネットワーク管理主体と、ネットワーク構成ノード（スイッチやルータ）とが相互に協調しながら動作する必要がある。

次に、「アイソクロナス通信（等時性通信）」について説明する。

図２は、従来の映像ストリームを示す図である。

ルータやＳＷによって構成されるネットワーク（図２ではルータもＳＷも単にＳＷとして記述してある）に、映像のリアルタイムデータを送信するカメラ１（１１０）、カメラ２（１１２）、カメラ３（１１３）、映像を出力する映像出力装置１（１１６）、映像出力装置２（１１４）、映像出力装置３（１１５）が接続されている。

さらに、このネットワークには、ネットワークのリソースを管理する管理主体（１１１）が接続されている。このネットワーク構成は、ベストエフォート型ネットワークでＱＯＳを保証した伝送を行う場合において、一般的な構成である。

まず、カメラ１（１１０）が、映像出力装置１（１１６）に、映像のリアルタイムストリームデータを送信する場合について考える。実際に、映像ストリームが伝送されるコネクションの経路として、経路（２７０）が想定される。

カメラ１（１１０）が、映像出力装置１（１１６）に映像ストリームを送信するに先立ち、ＱＯＳ保証のための資源予約処理を行う必要があることは上記の通りである。ここでは、管理主体（１１１）やＳＷ（１０３）、（１０４）、（１０２）、（１００）の協調動作によって、遅延保証、遅延分散保証、帯域確保、パケット損失保証がなされていることを前提として説明する。

カメラ１（１１０）は、映像出力装置１（１１６）に、映像データパケット（２７５）（Ｉ１、Ｉ２、Ｉ３…Ｉｎ）を送信する。このパケットは、カメラ１（１１０）の送信制御によって決められたパケット長で、しかも決められた時間間隔で、送信されているとする。ネットワークが理想的なＱＯＳを保証したとすれば、このパケット長と時間間隔とは、一切変更されず、伝送経路（２７０）において保証された一定の伝送遅延時間後に、映像出力装置１（１１６）に、パケットストリーム（２７５）を、等しいパケット長と等しい時間間隔とで受信する。

このコネクションが実現されれば、映像出力装置１（１１６）において、遅延分散（伝送遅延揺らぎ）を吸収するためのバッファを用意する必要がなく、すなわち撮影から表示までに要する時間は、伝送遅延時間のみである。

ここで、カメラ１（１１０）と映像出力（１１６）との映像ストリームコネクション（２７０）を使用したまま、カメラ２（１１２）から、映像出力装置２（１１４）に、映像ストリームコネクション（２７２）を確立し、カメラ３（１１３）から、映像出力装置３（１１５）に、映像ストリームコネクション（２７１）を確立する場合を考える。

カメラ２（１１２）から、映像出力装置２（１１４）には、図２に示す映像ストリーム（２７６）が送信され、カメラ３（１１３）から、映像出力装置３（１１５）には、図２に示す映像ストリーム（２７７）が送信される場合、ＳＷ１（１００）とＳＷ３（１０２）とのリンク（２７９）には、図２に示す映像ストリーム（２７８）が送信される必要がある。

これが実現されれば、ＳＷ３（１０２）において、リンク（２７９）に流れるストリーム（２７８）を、映像出力装置１（１１６）と、映像出力装置２（１１４）と、映像出力装置３（１１５）とに分離することによって、映像出力装置１（１１６）には、映像ストリーム（２７５）を提供し、映像出力装置２（１１４）には、映像ストリーム（２７６）を提供し、映像出力装置３（１１５）には、映像ストリーム（２７７）を提供することができる。

ただし、上記のように、２つのネットワークノードを連結する１本のリンクに、複数のアイソクロナスチャネルを載せる場合、そこに載せることが可能なアイソクロナスチャネルの上限は、連結された２つのノードの処理能力と、連結する１本のリンクの帯域資源とを考慮して判断する必要がある。

この判断は、複数の送受信対による複数のコネクションが、ネットワーク上のどのリンクにおいて競合するかを、適正に判断することに他ならず、一般には、コネクション確立前に、既存の全コネクションとそのリンクとについて客観的に管理している管理主体に、ネットワーク資源の余裕について、各端末が問い合わす際に、管理主体によって、上記判断が行われる。

このように、アイソクロナスチャネル確立のためには、端末と、管理主体と、ネットワークとが協調動作する必要があることは、上記の通りである。
特開２００３−３０９８３２号公報

しかし、折角、一般に普及したベストエフォート型のネットワーク技術を用いて、たとえばカメラと映像出力装置とを接続して簡単な監視システムを構築する場合や、連続して送信される画像データをプリント出力する簡単なプリントシステムを構築する場合に、これらアイソクロナス性（等時性）のあるリアルタイムデータを送受信することに先立ち、その成立、不成立を確認するために、管理主体を設置し、その管理主体に、端末から様々な問い合わせを行った後に、実際のリアルタイムデータを送受信する操作が煩雑であるという問題がある。

本発明は、ベストエフォート型のネットワーク技術を用いて、たとえばカメラと映像出力装置を接続して監視システムを構築する場合や、連続して送信される画像データをプリント出力するプリントシステムを構築する場合に、ネットワークのチャネルを管理する管理主体がなくても、データの送信装置が受信装置までの経路上のノードのチャネルの開設の可否を判定することを目的とする。

上記課題を解決するために、本発明の送信装置は、ノードを介して受信装置にデータを送信する送信装置であって、他の送信装置が他の受信装置にノードを介してデータを送信するために使用している、前記他の送信装置から前記他の受信装置までのノードを介した第１の経路の経路情報を前記他の受信装置から取得する取得手段と、前記送信装置が前記受信装置にノードを介してデータを送信するために使用する、前記送信装置から前記受信装置までのノードを介した第２の経路を前記受信装置に確認する確認手段と、前記取得手段により取得した前記第１の経路の経路情報と前記確認手段により確認した前記第２の経路の経路情報とに基づいて、前記送信装置から前記第２の経路上のノードを介して前記受信装置に至るチャネルの開設の可否を判定する判定手段とを有する。
また、本発明の受信装置は、ノードを介して送信装置からのデータを受信する受信装置であって、前記送信装置が前記受信装置にノードを介してデータを送信するために使用する、前記送信装置から前記受信装置までの経路を、前記送信装置からの要求に応じて確認する確認手段と、前記確認手段により確認した前記経路の経路情報を前記送信装置に送信する送信手段と、前記送信装置から前記経路上のノードを介して前記受信装置に至るチャネルの開設が可能であると前記送信装置が判定したことを前記送信装置から通知されると、前記経路を使用することを報知する報知手段とを有する。

本発明によれば、データの送信装置と受信装置とが連携することによって、送信装置が中継ノードから情報を直接得なくても、経路上のノードを介して、送信装置から受信装置に至るチャネルの開設の可否を、データの送信装置が判定することができるという効果を奏する。この結果、中継ノードを含む各ノードでのチャネル管理の負荷が増大することを抑制することができる。

発明を実施するための最良の形態は、次の実施例である。

図１は、本発明の実施例１である送受信端末がアイソクロナスチャネルを確立する場合の手順を示すフローチャートである。

アイソクロナスチャネルを確立したい送信側端末は、アイソクロナスチャネルの受信側端末に、アイソクロナスチャネルのストリーム経路の確認を行う手段と、そこで得られた経路と既設のアイソクロナスチャネル経路との比較に基づいて、チャネル開設可否判断する手段と、そこで判断された該当チャネル開設可否に関する判断結果を受信端末に伝える手段と、アイソクロナス性（等時性）のあるリアルタイムストリーム送信終了時に受信端末に対してアイソクロナスチャネル開放を伝える手段とを有し、これによって、アイソクロナス送信端末は、アイソクロナスチャネル確立に先立ち、ネットワークのＱＯＳ管理主体に、これから開設するアイソクロナスチャネルの成立、不成立についての判断を問い合わせること無しに、該アイソクロナス送信端末内でその判断を行う。

アイソクロナスチャネルを受信したい端末は、送信端末側からのアイソクロナスチャネルのストリーム経路確認要求に応えて、アイソクロナスチャネルのストリーム経路を確認する手段と、その経路について送信端末側に通知する手段と、送信端末側からのアイソクロナスチャネルの成立可否判断に基づいて確立されたアイソクロナスチャネルのストリーム経路を、他のアイソクロナス送信端末または受信端末に通知する手段と、送信端末から与えられたアイソクロナスチャネル開放指示によって該アイソクロナスチャネルのストリーム経路が、そのアイソクロナスチャネルから開放されたことを、他のアイソクロナス送信端末または受信端末に通知する手段とを有し、これによって、このアイソクロナス受信端末は、アイソクロナスチャネル確立時に、そのチャネルに関する情報、特にコネクション管理に当たり、一般に管理主体に通知する必要がある送信端末ＩＤや受信端末ＩＤやコネクションそのものに割り振られたＩＤについて、管理または通知する必要がない。

さらに、チャネルの成立不成立を判断するために、送信端末から受信端末に、実際のストリームに近い負荷情報を流すこともないので、その送受信端とは無関係の他のアイソクロナスチャネルのストリーム通信を邪魔することがなく、ネットワークに負荷をかける前に、当該アイソクロナスチャネルが成立するか否かについて、送受信端末間でネットワークに殆ど負荷をかけずに、判断することができる。

図３は、実施例１が想定するネットワークシステムの構成を示す図である。

本実施例では、ネットワーク端末として、アイソクロナスストリームデータを送信するカメラ１（１１０）、カメラ２（１１２）、カメラ３（１１３）と、アイソクロナスストリームデータを受信する映像出力装置１（１１６）、映像出力装置２（１１４）、映像出力装置３（１１５）とが、ネットワークに接続されている。

ネットワークは、ＳＷ１（１００）に、ＳＷ３（１０２）、ＳＷ４（１０３）、ＳＷ５（１０４）、ＳＷ６（１０５）が接続され、ＳＷ４（１０３）には、カメラ１（１１０）が接続され、ＳＷ５（１０４）には、カメラ３（１１３）とカメラ２（１１２）とが接続され、ＳＷ６（１０５）には、映像出力装置２（１１４）が接続され、ＳＷ３（１０２）には、映像出力装置３（１１５）と映像出力装置１（１１６）とが接続されている。

このネットワーク上で、カメラ１（１１０）と映像出力装置１（１１６）とが、アイソクロナス映像ストリームを送受信し、このコネクションを（１２０）に示す。さらに、カメラ２（１１２）と映像出力装置２（１１４）とが、アイソクロナス映像ストリームを送受信するとし、このコネクションが、（１２１）である。さらに、カメラ３（１１３）と映像出力装置３も、アイソクロナス映像ストリームを送受信しようとし、このコネクションが、（１２２）である。

図６は、上記実施例において、ストリーム送信端末（１５０）とストリーム受信端末（１５１）との間における交信を示す図である。

図６において、アイソクロナス映像ストリームを送信するストリーム送信端末（１５０）、すなわち図３に示すカメラ１（１１０）、カメラ２（１１２）、カメラ３（１１３）と、アイソクロナス映像ストリームを受信するストリーム受信端末（１５１）、すなわち図３に示す映像出力装置１（１１６）、映像出力装置２（１１４）、映像出力装置３（１１５）との間で発生する通信について説明する。

ストリーム送信端末（１５０）は、まず、ストリーム受信端末（１５１）に、ストリーム送信経路確認要求（１５５）を送信する。ストリーム受信端末は、このストリーム送信経路確認要求（１５５）から得られた情報に基づいて、ストリーム送信端末（１５０）とストリーム受信端末（１５１）との間におけるノードとリンクの経路とについて解析する。この解析方法については、後述する。

ストリーム送信端末と受信端末との間の経路分析が終了したストリーム受信端末は、ストリーム送信経路応答（１５６）として、これから開設されるであろうストリームの経路情報をストリーム送信端末（１５０）に送信する。

ストリーム送信端末（１５０）は、得られた経路情報に基づいて、その経路でのアイソクロナスチャネル確立可否を判断し（この判断についての詳細は後述する）、ストリーム送信成否通知（１５７）を、ストリーム受信端末（１５１）に送信する。

ストリーム送信成否通知を受けたストリーム受信端末（１５１）は、ストリーム送信が成立する場合、そのストリーム経路についてアイソクロナス通信が行われていることを、他のアイソクロナス送受信の可能性がある端末に通知する。この通知が終了すると、ストリーム受信端末（１５１）は、ストリームデータ送信成否応答（１５８）を、ストリーム送信端末（１５０）に送信する。

その後に、ストリーム送信端末（１５０）から、実際のアイソクロナス映像ストリームデータに相当するストリームデータが、送信される（１５９）、（１６０）、（１６１）。ストリーム送信端末（１５０）側で、ストリーム送信の完了が認められると、ストリーム送信端末（１５０）は、ストリーム送信終了通知（１６２）を、ストリーム受信端末（１５１）に送信する。

ストリーム受信端末（１５１）は、ストリーム送信終了通知を受け、他のアイソクロナス送受信の可能性がある端末に、当該アイソクロナスチャネルで使用されていた経路の開放を通知し、ストリーム送信終了応答（１６３）を、ストリーム送信端末（１５０）に返信する。

次に、上記実施例において、アイソクロナス通信を開始するに当たり、ストリーム送信を行う送信端と、ストリーム受信を行う受信端とが行う処理について説明する。

図１において、ストリーム送信を行おうとする端末が、ストリーム送信処理を開始（１７０）すると、まず、ストリーム受信相手に、ストリーム送信経路確認要求（１７１）を送信する。これは、ストリーム送信端末とストリーム受信端末との間の経路調査を、ストリーム受信端末に依頼する意味を持っている。

ストリーム受信待ち処理を開始（１９０）しているストリーム受信端末は、送信端末からのストリーム送信経路確認要求を受信待ちし（１９１）、要求を受信すると（２１０）、ストリーム経路の確認作業を行う（１９３）。これらの作業として、何通りかが考えられる。

本実施例において、通信経路上に存在しているネットワークノードを、トレースルートによって検出する。すなわち、ストリーム受信端末が、ストリーム送信端末からストリーム送信経路確認要求（２１０）を受けた場合、その送信元ＩＰアドレスに基づいて、そのＩＰアドレスに、ＩＣＭＰによるＥｃｈｏ Ｒｅｑｕｅｓｔを行うが、このときに、ＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）を小さく設定し、ストリーム送信経路確認要求の送信元ＩＰアドレスに、Ｅｃｈｏ Ｒｅｑｕｅｓｔを送信する。

すると、ネットワークノードには、上記ＴＴＬが０になったＩＰフレームを転送しない決まり、また、上記ＴＴＬが０になったためにそのフレームを転送しない場合は、そのフレームの送信元に、その旨を伝える義務がある。

すなわち、ストリーム受信端末は、上記ＴＴＬを１つずつ増やし、ストリーム送信端末から、Ｅｃｈｏ Ｒｅｐｌｙがあるまで、ＩＣＭＰのＥｃｈｏ Ｒｅｑｕｅｓｔを送り続ければ、ストリーム受信端末まで到達しなかったＩＣＭＰのＥｃｈｏ Ｒｅｑｕｅｓｔの破棄通知が、経路上の経由ネットワークノードから得られる。つまり、ストリーム送受信経路上に存在しているネットワークノードのＩＰアドレスリストを得ることができる。このように、ＩＰパケットが経由する経路上のネットワークノードのＩＰアドレスを割り出す方法は、トレースルートという一般的な方法であり、ネットワーク管理の際等によく用いられている。

この他にも、ストリーム送信経路確認要求（２１０）を検出したネットワークノードが、ストリーム送信経路確認要求パケットに、ネットワークノードの存在とＩＤを示す印とを入れる方法等が考えられる。この場合、ストリーム受信端末は、ストリーム送信経路確認要求パケットの内容を解析することによって、経由ネットワークノードについて割り出すことができる。

ストリーム受信端末が、ストリーム送信経路確認要求（２１０）に応じて、上記方法によって、ストリーム経路確認を完了すると、ストリーム受信端末からストリーム送信端末に、検出したストリーム経路についての情報を載せたストリーム送信経路応答を送信する（１９４）。

これを受けたストリーム送信端末は、自分が持っている既設アイソクロナスチャネル経路情報と比較し（２１１）、（１７２）、これから開設しようとするアイソクロナスチャネルが開設可能であるかどうかを判断する（１７３）。

なお、この判断方法の詳細については、後述する（★２）。

ストリーム送信端末は、この判断に基づいて、そのアイソクロナスストリームチャネル開設可否に関する通知を、ストリーム受信端末に行う（２１２）、（２１３）、（１７４）、（１７９）。

これを受信したストリーム受信端末（１９５）は、そのチャネルの開設可否によって、以下の処理を行う。すなわち、そのストリームが開設成立通知を受信すれば（１９６）、先に確認したそのストリームのネットワークノード経路に関して、他のストリーム送信端末または受信端末に通知する（１９７）（★１）。

本実施例では、この通知方法として、ブロードキャストによる方法を採用する。すなわち、開設されるアイソクロナスチャネルで使用されているルータ経路情報は、チャネル開設可能の判断通知を受けた時点で、受信端末から全端末に向けてブロードキャストする。

図８は、上記実施例における既設チャネル保持動作を示すフローチャートである。

ブロードキャストを受信したストリーム送信端末は、図８に示す既設チャネル保持動作を常に行っている。すなわち、ストリーム受信端末から、チャネル経路に関する情報のブロードキャストを受けると（２３６）、チャネルが開設され、そのチャネルで使用される経路上のネットワークノードを、テーブルに保存する（２３８）。また、チャネル開放に伴い、その経路ノードから外れたブロードキャスト通知を、ストリーム受信端末から受ければ、それに従い、既存チャネルで使用される経路上のネットワークノードから外す処理を行う。

別の方法として、規模の小さいネットワークであれば、アイソクロナスストリームを送信する可能性のある端末の全てを、全ての受信端末に登録し、アイソクロナスチャネル開設が決まった時点で、受信端末からストリーム送信可能性のある全送信端末に、ユニキャストで通知する方法が考えられる。

図７は、上記実施例における既設チャネル保持動作を示すフローチャートである。

この場合、その通知を受けたストリーム送信端末は、図７に示す既設チャネル保持動作を常に行う。すなわち、ストリーム受信端末から、チャネル経路に関する情報を受け取ると（２３１）、チャネルが開設され、そのチャネルで使用される経路上のネットワークノードを、テーブルに保存する（２３３）。また、チャネル開放に伴い、経路ノードがチャネルから開放されたことを、ストリーム受信端末から検出すれば、経路上のネットワークノードから外すように、テーブルを更新する（２３３）。

一方、ストリーム送信端末が、既設チャネル経路と、これから開設しようとするチャネル経路とを比較した結果、チャネル開設不能であると判断した場合、ストリーム送信が不成立であることを、受信端末に通知し（１７９）、（２１３）、これを受けたストリーム受信端末（１９５）、（２０２）は、ストリーム送信不成立応答を送信し（２０３）、（２１４）、ストリーム受信待ち処理を終了し（２０４）、必要ならば、新たにストリーム受信待ち処理を再び開始する（１９０）。また、ストリーム送信不成立応答を受信したストリーム送信端末（２１４）、（１８０）は、ストリーム送信処理を終了し（１８１）、必要に応じて、ストリーム送信処理を再び開始する（１７０）。

上記（★１）においてストリーム受信端末が確立されたストリームの経路を、他のストリーム送信端末に通知した（１９７）後に、ストリーム受信端末が、ストリーム送信端末に、ストリーム送信成否応答を送信する（１９８）ことによって、上記通知が終了した旨を通知する（２１５）。これを受信した（１７５）ストリーム送信端末は、実際のアイソクロナスデータストリームの送信を、初めて開始する（１７６）。

ストリーム送信端末が、撮影の終了、送信データの終了を検出すると、ストリーム送信端末は、ストリーム送信終了通知を、ストリーム受信端末に送信する（１７７）。これを受信した（２１６）、（１９９）ストリーム受信端末は、ストリームチャネルの経路の開放を、全ストリーム送信端末に通知する（２００）。

このときの通知方法として、ブロードキャスト方式とユニキャスト方式とがあるが、本実施例では、ブロードキャスト方式を採用している。詳細は、上記の通りである。ストリーム受信端末は、経由情報の開放通知（２００）を終了すると、ストリーム送信終了応答通知を、ストリーム送信端末に送信し（２０１）、ストリーム受信待ち処理を終了する（２０４）。

ここで、ストリーム受信端末は、必要に応じて、ストリーム受信待ち処理を再び開始（１９０）する。ストリーム送信終了応答通知を受信（１７８）、（２１７）したストリーム送信端末は、ストリーム送信処理を終了する（１８１）。ストリーム送信端末は、再び撮影を開始し、ストリーム送信を開始する必要性を認識した時点で、ストリーム送信処理を再度開始する（１７０）。

次に、図１の（１７３）の説明において後述するとした判断方法（★２）、つまり、既設チャネル経路と、これから開設するチャネル経路とを比較することによって、そのチャネルの開設可否を判断する方法について説明する。

図９は、上記実施例において使用する経路の表現方法を示す図であり、図３におけるコネクション（１２０）、（１２１）、（１２２）を示す図である。

この全ての情報を、ストリーム送信端末で管理してもよいが、本実施例では、ここまで多くの情報は管理しない。

たとえば、図９に示すチャネルＩＤ１は、図３に示すコネクション（１２０）を示すが、このコネクションでは、ノードとノードとを接続する線であるリンクは、２つ存在している。つまり、ＳＷ４とＳＷ１とのリンクと、ＳＷ１とＳＷ３とのリンクとである。

これら２つのリンクが、既存のコネクションのリンクである場合、これら２つのリンクを、Ｌ１（４，１）、Ｌ２（１，３）と表現する。これから開設しようとする未確立のコネクションを構成するリンクである場合、たとえば、図９に示すチャネルＩＤ３は、図３に示すコネクション（１２２）が未設のコネクションである場合、Ｒ１（５，１）、Ｒ２（１，３）と示す。

Ｌｎ、Ｒｍ等のｎ、ｍの添え字は、そのリンクに対して、各ストリーム送信端末が付けた通し番号であり、ネットワークシステム全体としては、何ら意味を持たない。すなわち、図１の確立ストリーム経路通知（１９７）では、たとえば、図３に示すコネクション（１２０）が確立された場合、（３，１）、（１，４）という情報が送信されるとする。

ちなみに、ここでは、（３，１）と（１，３）とは、全く等価であると判断される。さらに、たとえば図３に示すコネクション（１２１）確立時には、経路通知（図１の（１９７））において、（５，１）、（１，６）という情報が送信される。

すなわち、図３に示すストリーム送信端末であるカメラ３（１１３）は、（１２０）、（１２１）のコネクション確立時に、それぞれ、（３，１）、（１，４）と、（５，１）、（１，６）という経路情報を受け取り、カメラ３（１１３）の内部では、Ｌ１（３，１）、Ｌ２（１，４）、Ｌ３（５，１）、Ｌ４（１，６）という既設チャネルの経路情報が蓄積される。

さらに、ここで、図３に示すコネクション（１２２）が、これから新たに開設されようとすると、図３に示すカメラ３（１１３）は、映像出力装置３（１１５）から、上記手順によって、これから開設されようとしているコネクション（１２２）の経路が、（５，１）、（１，３）であることが伝えられる。

これを受けたカメラ３（１１３）は、この経路情報については、これから開設されるリンクであると認識し、Ｒ１（５，１）、Ｒ２（１，３）を内部的に記憶する。すなわち、カメラ３（１１３）では、この段階（★３）で、図１に示す（１７３）におけるこれから開設するチャネル経路の比較と、チャネル開設判断とを行う。

次に、上記実施例におけるチャネル開設判断について、説明する。

図１０は、上記（１７３）におけるチャネル開設判断の動作を示すフローチャートである。

カメラ３（１１３）が、上記段階（★３）に至ると、カメラ３は、新チャネル開設可否判断を開始（２５０）する。まずは、検索リンクのインデクスについて、既存経路用インデクスｎと、これから開設するための経路用インデクスｍとを、それぞれ、１に初期化する（２５１）。

次に、これから開設しようとするチャネルの経路Ｒｍを読み込む（２５２）。ここで、経路用インデクスｍは、１に初期化されているので、Ｒ１（５，１）を読み込む。次に、既存チャネル経路Ｌｎを読み込む（２５３）。ここで、ｎは、１に初期化されているので、Ｌ１（３，１）を読み込む。

次に、既存チャネル経路Ｌｎと、これから開設しようとするチャネルの経路Ｒｍとを比較する。ここで、ｎ、ｍが、ともに１であるので、まずは、Ｒ１（５，１）と、Ｌ１（３，１）とを比較する（２５４）。Ｒ１とＬ１（ＳＷ５とＳＷ１のリンクと、ＳＷ３とＳＷ１のリンク）とは、経路としては異なると判断できるので、次のＬｎと比較するために、ｎをインクリメントし（２５６）、次の既存チャネルリンクＬ２（１，４）を読み込む。

Ｒ１とＬ２とは、経路としては異なるので、再び次のＬｎと比較するために、ｎをインクリメントする（２５６）。ここで、Ｌ３（５，１）を読み込む。Ｒ１（５，１）とＬ３（５，１）とを比較すると、この経路は同じ経路であると判断できる。すなわち、Ｒ１は、既存のアイソクロナスチャネル経路Ｌ３（５，１）で競合していることが判明する。

ここで、カメラ３は、Ｌ３（５，１）が、新設のアイソクロナスチャネルと競合していることを記憶する（２５５）。これと同様にして、新設チャネルの経路Ｒ１、Ｒ２と、既設チャネルの経路Ｌ１−Ｌ４とを比較し、既設チャネルと新設チャネルとが、どの経路で、いくつ競合しているかをカウントする。

ここで、新設チャネルの経路Ｒ１、Ｒ２の読み込みと比較とが完了した時点で、Ｌ３がカウント１になり、Ｌ２がカウント１になる。この数値に基づいて、アイソクロナスチャネル新設が可能であるかどうかを判断する（２５８）。

ここで、ストリームを送信する端末（この場合は、カメラ３）は、各経路に何本のアイソクロナスチャネルを開設可能であるかを、予め登録する必要がある。本実施例では、この許容カウントが３であると設定されている。Ｌ３もＬ２も、カウントが３以下であるので、カメラ３（１１３）は、映像出力装置３（１１５）へのアイソクロナスチャネルは、成立可能であると判断する（２５９）。

もし、各経路カウントのうちのひとつでも、許容カウントを上回っている場合、新設チャネル確立不能であると判断する（２６０）。このようにして、新設チャネル開設可否の判断を終了する（２６１）。その後に、アイソクロナスチャネル送信端末は、図１における（１７３）よりも先の手順へ進む。

上記実施例によれば、図４に示すように、ネットワーク（１２５）に接続されているカメラ１（１１０）、カメラ２（１１２）、カメラ３（１１３）と、映像出力装置１（１１６）、映像出力装置２（１１４）、映像出力装置３（１１５）等のストリーム端末のみの構成によって、管理主体を設置せずに、ベストエフォート型のネットワーク形態を用い、アイソクロナス性（等時性）のあるリアルタイムデータを送受信することができる。

また、そのアイソクロナス送信端末は、アイソクロナスチャネル確立に先立ち、ネットワークのＱＯＳ管理主体に、これから開設するアイソクロナスチャネルの成立、不成立についての判断を問い合わせることなく、該アイソクロナス送信端末内で、その判断を行うことができる。

さらに、このアイソクロナス受信端末は、アイソクロナスチャネル確立時に、そのチャネルに関する情報、特に、コネクション管理に当たり、一般に管理主体に通知する必要がある送信端末ＩＤ、受信端末ＩＤ、コネクションそのものに割り振られたＩＤについて、管理または通知をする必要がない。

本発明の実施例１である送受信端末がアイソクロナスチャネルを確立する場合の手順を示すフローチャートである。 従来例における映像ストリームを示す図である。 実施例１が想定するネットワークシステムの構成を示す図である。 ネットワークのイメージを示す図である。 ネットワークのイメージを示す図である。 上記実施例において、ストリーム送信端末（１５０）とストリーム受信端末（１５１）との間における交信を示す図である。 上記実施例における既設チャネル保持動作を示すフローチャートである。 上記実施例における既設チャネル保持動作を示すフローチャートである。 上記実施例において使用する経路の表現方法を示す図であり、図３におけるコネクション（１２０）、（１２１）、（１２２）を示す図である。 上記（１７３）におけるチャネル開設判断の動作を示すフローチャートである。

符号の説明

１００…ＳＷ１、
１０２…ＳＷ３、
１０３…ＳＷ４、
１０４…ＳＷ５、
１０５…ＳＷ６、
１１０…カメラ１、
１１２…カメラ２、
１１３…カメラ３、
１１４…映像出力装置２、
１１５…映像出力装置３、
１１６…映像出力装置１、
１５０…ストリーム送信端末、
１５１…ストリーム受信端末。

Claims (10)

1. ノードを介して受信装置にデータを送信する送信装置であって、
   他の送信装置が他の受信装置にノードを介してデータを送信するために使用している、前記他の送信装置から前記他の受信装置までのノードを介した第１の経路の経路情報を前記他の受信装置から取得する取得手段と、
   前記送信装置が前記受信装置にノードを介してデータを送信するために使用する、前記送信装置から前記受信装置までのノードを介した第２の経路を前記受信装置に確認する確認手段と、
   前記取得手段により取得した前記第１の経路の経路情報と前記確認手段により確認した前記第２の経路の経路情報とに基づいて、前記送信装置から前記第２の経路上のノードを介して前記受信装置に至るチャネルの開設の可否を判定する判定手段と、
   を有することを特徴とする送信装置。
2. 前記判定手段による判定の結果を前記受信装置に伝える伝達手段をさらに有することを特徴とする請求項１に記載の送信装置。
3. 前記判定手段は、前記第１の経路上と前記第２の経路上とで共通に存在する各ノードが開設しているチャネルの数に基づいて、前記送信装置から前記第２の経路上のノードを介して前記受信装置に至るチャネルの開設の可否を判定することを特徴とする請求項１または２に記載の送信装置。
4. 送信するデータが終了することを前記受信装置に通知する通知手段をさらに有することを特徴とする請求項１乃至３のいずれか１項に記載の送信装置。
5. ノードを介して送信装置からのデータを受信する受信装置であって、
   前記送信装置が前記受信装置にノードを介してデータを送信するために使用する、前記送信装置から前記受信装置までの経路を、前記送信装置からの要求に応じて確認する確認手段と、
   前記確認手段により確認した前記経路の経路情報を前記送信装置に送信する送信手段と、
   前記送信装置から前記経路上のノードを介して前記受信装置に至るチャネルの開設が可能であると前記送信装置が判定したことを前記送信装置から通知されると、前記経路を使用することを報知する報知手段と、
   を有することを特徴とする受信装置。
6. 前記報知手段は、前記送信装置から送信するデータの終了の通知に応じて、前記送信装置から前記経路上のノードを介して前記受信装置に至るチャネルの開放を報知することを特徴とする請求項５に記載の受信装置。
7. 前記確認手段は、前記経路上のノードをトレースルートによって検出することにより前記経路を確認することを特徴とする請求項５または６に記載の受信装置。
8. 前記確認手段は、前記経路上のノードが前記送信装置からの要求に付加した情報によって前記経路を確認することを特徴とする請求項５または６に記載の受信装置。
9. ノードを介して受信装置にデータを送信する送信装置の制御方法であって、
   他の送信装置が他の受信装置にノードを介してデータを送信するために使用している、前記他の送信装置から前記他の受信装置までのノードを介した第１の経路の経路情報を前記他の受信装置から取得する取得工程と、
   前記送信装置が前記受信装置にノードを介してデータを送信するために使用する、前記送信装置から前記受信装置までのノードを介した第２の経路を前記受信装置に確認する確認工程と、
   前記取得工程により取得した前記第１の経路の経路情報と前記確認工程により確認した前記第２の経路の経路情報とに基づいて、前記送信装置から前記第２の経路上のノードを介して前記受信装置に至るチャネルの開設の可否を判定する判定工程と、
   を有することを特徴とする送信装置の制御方法。
10. ノードを介して送信装置からのデータを受信する受信装置の制御方法であって、
    前記送信装置が前記受信装置にノードを介してデータを送信するために使用する、前記送信装置から前記受信装置までの経路を、前記送信装置からの要求に応じて確認する確認工程と、
    前記確認工程において確認された前記経路の経路情報を前記送信装置に送信する送信工程と、
    前記送信装置から前記経路上のノードを介して前記受信装置に至るチャネルの開設が可能であると前記送信装置が判定したことを前記送信装置から通知されると、前記経路を使用することを報知する報知工程と、
    を有することを特徴とする受信装置の制御方法。
    

Images