(57)【要約】【課題】  ネットワーク全体で管理する必要がなく、その情報に基づいて、スイッチに、リアルタイムストリームパケットの送信周期に関する設定をせずに、スイッチ自身で、リアルタイムストリームパケット発生周期を検出し、そのための資源予約行為をスイッチ自身で完結することができるようにする。【解決手段】  受信したパケットがリアルタイムストリームパケットであるか否かを検出する手段と、そのパケットがリアルタイムストリームを構成するパケットである場合、そのパケットが送信端末から送信されてからスイッチに到着するまでの遅延時間について揺らぎが発生しているかどうか判断する手段と、遅延時間揺らぎが発生していないリアルタイムストリーム構成パケットであれば、リアルタイムストリーム受信周期を測定する手段が、次にリアルタイムストリームパケットを受信する時刻を予め検出する。【選択図】  図１
2005268872.tif 000002
【特許請求の範囲】
【請求項１】
ステーションとネットワークスイッチとによって構成され、ステーションが等時性を要するリアルタイムストリームを送受信するネットワークシステムにおいて、
リアルタイムストリームを送受信するステーションとネットワークスイッチと以外のネットワーク管理主体を必要とせずに、ステーション間に設立されたリアルタイムストリームチャネルの等時性を維持することを特徴とするリアルタイムデータストリーム送受信ネットワークシステム。
【請求項２】
ネットワークを構成するネットワークスイッチにおいて、
リアルタイムストリームパケットを識別する識別手段と；
受信したリアルタイムストリームパケットのうちで、以後に続くリアルタイムストリームパケットのパケット受信周期が揺らいでいない先頭のリアルタイムストリームパケットを検出する先頭のリアルタイムストリームパケット検出手段と；
上記受信周期が揺らいでいない先頭のリアルタイムストリームパケットと、次のリアルタイムストリームパケットとの受信間隔を測定することによって、リアルタイムストリームパケットの受信周期Ｔと、それ以降のリアルタイムストリームパケット受信時刻とを検出する受信周期・受信時刻検出手段と；
リアルタイムストリームパケットの受信とその中継のための送信との資源を予約し、非リアルタイムデータパケットに対して、リアルタイムストリームパケットを優先してポートから出力する出力手段と；
を有することを特徴とするネットワークスイッチ。
【請求項３】
等時性を要するリアルタイムストリームパケットを送信するステーションにおいて、
リアルタイムストリームパケットであることを示す識別子を付ける識別子付与手段と；
上記リアルタイムストリームパケットを一定時間間隔で送信する送信手段と；
一定時間間隔を守って送信するリアルタイムストリームパケットに、一定時間間隔で送出されたパケットである旨を示すマークを、当該パケットに付与するマーク付与手段と；
を有することを特徴とするリアルタイムストリームパケット送信装置。
【請求項４】
請求項２において、
上記出力手段により出力するリアルタイムストリームパケットのうち、上記受信周期Ｔの間隔を保って出力されたパケットに、一定時間を保って出力されたパケットである旨を示すマークを付与し、他のネットワークノードに、送信周期が一定に保たれているパケットであることを明示する付与手段と；
を有することを特徴とするネットワークスイッチ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リアルタイムストリームデータを受信送信する中継機能を持つスイッチに関する。
【背景技術】
【０００２】
ＣＳＭＡ／ＣＤ方式や全２重方式によるベストエフォート型ネットワークにおいて、音声や映像等のリアルタイムデータのストリームを伝送するニーズが高まっている。
【０００３】
しかし、ベストエフォート型ネットワークの性質上、リアルタイムな映像や音声のストリーム（情報）を、決められた時間内で決められた量で、確実に伝送することは、そのままでは困難性を有する。この困難性は、リアルタイム性を必要とするアプリケーションに対するＱＯＳ（Ｑｕａｌｉｔｙ  Ｏｆ  Ｓｅｒｖｉｃｅ）の保証の課題として定義されている。この保証を、これを大きく分類すると、遅延保証、遅延分散保証、帯域保証、パケット損失率保証の４つとして捉えることができる。これらの保証を実現する技術として、次の（ａ）〜（ｄ）の４つの技術要素が挙げられる。
【０００４】
（ａ）クラス分類（Ｃｌａｓｓｉｆｉｅｒ）
クラス分類は、ルータやスイッチにおいて、到着したパケットを、送信元や送信先、ＴＣＰ／ＵＤＰポート番号、Ｔｏｓフィールドに基づいて、トラフィックを分類する。
【０００５】
（ｂ）アドミッション制御（Ａｄｍｉｔｉｏｎ  ｃｏｎｔｒｏｌ）
アドミッション制御は、セッション毎に資源の予約をコントロールする方法であり、セッション開始時に、セットアッププロトコルによって、パス上の資源を確保し、確保に失敗すると、セッションは開始されない。
【０００６】
（ｃ）パケットスケジューラ（Ｐａｃｋｅｔ  ｓｃｈｅｄｕｌｅｒ）
パケットスケジューラは、グループ分類されたパケットを送出するスケジュールを調整する方法であり、キューイング方法やバッファ管理方法によって様々な方法がある。
【０００７】
（ｄ）トラフィックシェーピング（Ｓｈａｐｅｒ）
トラフィックシェーピングは、流入するバーストトラフィックを、一定レートにならす技術である。
【０００８】
また、これらの技術を実現するための枠組みとして、Ｉｎｔ−ｓｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ）や、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）や、Ｄｉｆｆ−ｓｅｒｖ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ）が挙げられる。
【０００９】
リアルタイムな映像や音声等のストリームデータを扱いたいネットワーク端は、上記枠組みで決められた手順に従い、ネットワークまたはネットワークの管理主体に、リソース予約行為を行い、この予約を受けたネットワークは、ネットワークを構成するルータやスイッチの内部において、上記技術要素であるクラス分類、アドミッション制御、パケットスケジュールを行い、ＱＯＳ保証を試みる（たとえば、特許文献１参照。）。
【００１０】
このときに、ネットワーク端は、予約したリソースの範囲内に、トラフィックをシェーピングする必要がある。
【００１１】
このような技術の中で、ネットワークを構成するスイッチにおいて、リアルタイムストリームパケットの送信端から、受信端までの遅延分散を保証するために必要な技術要素として、すなわち、遅延揺らぎを一定の範囲内に保証するために必要な技術要素として、クラシファイア、アドミッション制御、パケットスケジュール制御等が挙げられるが、中でも、パケットスケジュール制御方法として、厳格優先制御や、ＷＦＱ（Ｗｅｉｇｈｔｅｄ  Ｆａｉｒ  Ｑｕｅｕｉｎｇ）、ＤＲＲ（Ｄｉｆｉｃｉｔ  Ｒｏｕｎｄ  Ｒｏｂｉｎ）等が挙げられる。
【００１２】
ここで、スイッチがリアルタイムストリームデータを厳格に絶対的に優先する場合、厳格優先制御が行われるが、この厳格優先制御において、一定周期で発生するリアルタイムストリームデータのパケットのために、スイッチが資源を予約しておくためには、そのリアルタイムストリームデータのパケット発生周期や、いつリアルタイムストリームパケットが発生するかについて、スイッチが何らかの手段で知っておく必要がある。
【００１３】
このような場合、通常のスイッチにおいて、リアルタイムストリームのパケット発生周期や発生時期に関する設定を、スイッチに予め行うか、またはリアルタイムストリームチャネルに関して集中管理している管理主体から、スイッチが中継するリアルタイムストリームチャネルに関するパケット発生周期や、発生タイミングについての情報を取得するか、またはリアルタイムストリームを発生する端末からそのリアルタイムストリームパケットの発生周期や発生タイミングについて、ストリーム開始時に、情報取得する方法が取られる。
【特許文献１】特開２００３−３０９８３２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかし、ネットワーク規模の大小に関わらず、ネットワーク全体において、リアルタイムストリームチャネルがどのような経路で、どの程度存在し、各ネットワークスイッチにおいて、どのような周期で、何時、リアルタイムストリームパケットが発生するかという情報を、管理主体が一元管理し、その情報をリアルタイムストリーム発生前後に、スイッチに設定する手順は、あまりに煩雑であるという問題がある。
【００１５】
本発明は、リアルタイムストリームコネクション（チャネル）について、ネットワーク全体で管理する必要がなく、スイッチ自身で、パケットのリアルタイム性を維持することを目的とするものである。
【課題を解決するための手段】
【００１６】
本発明は、スイッチが、受信したパケットがリアルタイムストリームパケットであるか否かを識別し、そのパケットがリアルタイムストリームを構成するパケットである場合、そのパケットが送信端末から送信されてからスイッチに到着するまでの遅延時間について遅延時間揺らぎが発生しているかどうか判断し、遅延時間揺らぎが発生していないリアルタイムストリーム構成パケットであれば、リアルタイムストリーム受信周期を測定して、資源予約を行うことで、以降のパケットの送信間隔を一定に維持する。
【発明の効果】
【００１７】
本発明によれば、リアルタイムストリームコネクション（チャネル）について、ネットワーク全体で管理する必要がなく、スイッチ自身で、リアルタイムストリームパケットのリアルタイム性を維持してパケットを送信することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１８】
発明を実施するための最良の形態は、次の実施例である。
【実施例１】
【００１９】
図２は、本実施例におけるネットワーク構成を示す図である。
【００２０】
ＳＷ１（１００）には、ＳＷ２（１０１）、ＳＷ３（１０２）、ＳＷ４（１０３）が接続され、ＳＷ４（１０３）には、制御端末Ａ（１０９）、カメラ１（１１０）が接続され、ＳＷ２（１０１）には、ＳＷ５（１０４）、ＳＷ６（１０５）が接続され、ＳＷ５（１０４）には、制御端末Ｂ（１１１）、カメラ２（１１２）が接続され、ＳＷ６（１０５）には、映像出力装置２（１１３）が接続され、ＳＷ３（１０２）には、制御端末Ｃ（１１４）、映像出力装置１（１１５）が接続されている。
【００２１】
カメラ１（１１０）は、映像出力装置１（１１５）に、リアルタイム映像ストリームを送信し、このチャネルを（１２０）で示している。このチャネル（１２０）の経路は、ＳＷ４（１０３）、ＳＷ１（１００）、ＳＷ３（１０２）である。制御端末Ａ（１０９）は、映像出力装置１（１１５）を制御し、すなわち、制御端末Ａ（１０９）から映像出力装置（１１５）には、頻繁な非リアルタイムデータパケットが、非同期に頻繁に送信されているとする。この制御チャネルを、（１２１）で示している。
【００２２】
制御チャネル（１２１）の経路は、ＳＷ４（１０３）、ＳＷ１（１００）、ＳＷ３（１０２）である。また、映像出力装置１（１１５）は、複数の端末からの制御を受け、制御端末Ｂ（１１１）、制御端末Ｃ（１１４）から、制御チャネル（１２２）、（１２３）を介して、頻繁な非リアルタイムデータパケットを、非同期に受信することができる。制御チャネル（１２２）の経路は、ＳＷ５（１０４）、ＳＷ２（１０１）、ＳＷ１（１００）、ＳＷ３（１０２）であり、制御チャネル（１２３）の経路は、ＳＷ３（１０２）である。
【００２３】
このようなネットワーク環境下で、リアルタイムストリームの伝送遅延が、従来どのように揺らぐ可能性があるかについて説明する。
【００２４】
図１は、上記実施例におけるストリームを示す図である。
【００２５】
図１では、軸上の右に行く程、古いパケットであり、左に行く程、新しいパケットを示す。また、リアルタイムストリームを構成するパケットを、Ｉ１からＩ８で表し、非同期パケットを、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、Ｌで示す。
【００２６】
さらに、端末から送信された送信周期を維持しているパケットを、網掛けで示し、送信周期を維持できないパケットを、斜線で示す。
【００２７】
カメラ１（１１０）が、リアルタイムストリームデータを送信する様子を、図１の最上段（１０）に示す。
【００２８】
ここでは、リアルタイムストリームを構成するパケットＩ１からＩ８が、定期的に送信されている様子が示している。また、制御端末Ａ（１０９）が制御用の非同期データを送信する様子を、図１の２段目（１１）に示している。
【００２９】
ここでは、非同期パケットＢ、Ｃ、Ｄ、Ｅ、Ｆが送信されている。これらのパケットをＳＷ４（１０３）が受け、単純に受信した順番通りに、チャネル（１２０）、（１２１）の次の経路であるＳＷ１（１００）に、パケットを送信したとすると、図１の３段目（１２）に示すように、制御端末Ａ（１０９）とカメラ１（１１０）とのパケットの内で、制御用の非同期パケットとリアルタイムパケットとが、時間的に衝突した部分について、リアルタイムパケットの送信間隔に揺らぎが発生している。
【００３０】
なお、「パケット送信間隔（周期）が揺らいでいる」とは、送信間隔（周期）が大きく変化していることであり、また、「パケット受信間隔（周期）が揺らいでいる」とは、受信間隔（周期）が大きく変化していることである。
【００３１】
すなわち、リアルタイムパケットＩ１からＩ４は、非同期パケットＢ、Ｃ、Ｄ、Ｅ、Ｆの影響を受け、ＳＷ４（１０３）からの送信周期は、元のカメラ１（１１０）からの送信周期を保つことができない。これらＳＷ４（１０３）からのパケット列（１２）と、ＳＷ２（１０１）からのパケット列（１３）とを、ＳＷ１（１００）が受信し、ＳＷ１（１００）が単純に受信した順番通りに、次の経路であるＳＷ３（１０２）にパケット列を送出する様子を、図１の５段目（１４）のパケット列として示してある。
【００３２】
ここでは、ＳＷ４（１０３）から送信されたパケットの内で、送信周期を維持しているＩ５からＩ７のパケットにも、ＳＷ２（１０１）からの非同期パケットＪ、Ｋ、Ｌと衝突し、結果的に、送信周期を維持しているリアルタイムパケットは、Ｉ８のみである。
【００３３】
このパケット列（１４）が、ＳＷ１（１００）からＳＷ３（１０２）に送出され、ＳＷ３（１０２）が、制御端末Ｃ（１１４）から図１の６段目（１５）のようなパケット列を送出する場合、ＳＷ３（１０２）から映像出力装置１（１１５）に送出するパケット列は、図１の７段目（１６）に示すようになる。
【００３４】
ここでは、ＳＷ３（１０２）までは、周期性が保たれているリアルタイムパケットＩ８についても、ＳＷ３（１０２）において、制御端末Ｃ（１１４）からの非同期パケットＰと衝突を起こし、結果的に、映像出力装置１（１１５）に周期性を維持できずに届いたリアルタイムパケットは、１つも存在していない。
【００３５】
映像出力装置１（１１５）において、これらパケットＩ１−Ｉ８の揺らぎを充分吸収できる大きなバッファを持っている場合は、問題ないが、充分な揺らぎ吸収バッファを持っていない場合、バッファアンダーラン、バッファオーバフローを起こし、正常な映像再生を実現できない。
【００３６】
この場合、非リアルタイムパケットが先着し、そのパケットを完全に送出する前に、リアルタイムパケット受信を完了した場合、リアルタイムパケットの送出が待たされ、結果として、リアルタイムパケットの送信間隔が揺らぐ。
【００３７】
この状況を発生させないためには、リアルタイムパケットの受信間隔（送信間隔）を、スイッチが予め知り、リアルタイムパケット送信予定時刻に、非リアルタイムパケットを送信することを回避する必要がある。このリアルタイムパケットの送信間隔をスイッチが知るために、本実施例では、図１の最上段（１０）に示すように、ストリーム送信元からの送信データが、送信間隔を維持されていることに着目する。
【００３８】
具体的には、カメラ１（１１０）が直接接続されているＳＷ４（１０３）が、カメラ１（１１０）から受信するリアルタイムストリームパケットの送信間隔は、一定に維持されている。すなわち、ＳＷ４（１０３）は、カメラ１（１１０）から受けたリアルタイムストリームパケットの受信間隔を測定すれば、その送信周期Ｔを知ることができる。
【００３９】
すなわち、図１の最上段に示すＩ１とＩ２との受信間隔を、ＳＷ４（１０３）が測定すれば、Ｉ３が次に来る時刻を予想可能であり、リアルタイムパケットＩ３のために、その送信時刻において、非リアルタイムパケット送信中にならないように、非リアルタイムパケットの送信を抑制し、本来優先して送出すべきリアルタイムパケットＩ３を優先して送出することができる。
【００４０】
この様子について、より詳細に説明する。
【００４１】
図３は、本実施例の動作説明図である。
【００４２】
カメラ１（１１０）と制御端末Ａ（１０９）とが直接接続されているＳＷ４（１０３）が、カメラ１（１１０）からリアルタイムストリームデータＩ１を受信すると、次のリアルタイムストリームデータＩ２を受信するまでの時間間隔を測定開始する（３５）。
【００４３】
次に、Ｉ２を受信した時点で、カメラ１（１１０）のリアルタイムストリームデータの受信間隔Ｔを確定し（３６）、また、次のリアルタイムストリームデータの受信時刻について、「Ｉ２受信時刻」＋「受信間隔Ｔ」であると予想する（３７）。
【００４４】
仮に、その時刻に、ＳＷ４（１０３）が、制御端末Ａ（１０９）から非リアルタイムパケットＥを受けたとしても、これをＳＷ１（１００）に直ちに送信せずに、留め（３８）、予想した時刻に到着したＩ３を、ＳＷ１（１００）に送信してから、上記非リアルタイムパケットＥを送信する（３９）。このようにすることによって、ストリームと非同期データとを集約しているＳＷ４（１０３）のポートからの送信データ（パケット列）は、図３の３段目（２３）に示すようになる。
【００４５】
すなわち、ＳＷ４（１０３）からの出力パケット列において、１番目と２番目のリアルタイムストリームパケットであるＩ１、Ｉ２は、非同期パケットの影響で、送信周期が揺らぐ可能性があるが、３番目のリアルタイムストリームパケットであるＩ３の送信周期は、揺らいではいない。
【００４６】
これらストリームと非同期パケットとを集約しているＳＷ４（１０３）からの送信データ（２３）が、ＳＷ４（１０３）からＳＷ１（１００）に送信されるときに、ＳＷ１（１００）の他のポートの延長経路上に接続されている制御端末Ｂ（１１１）から、非同期データが、（２４）に示すように、ＳＷ１（１００）に受信された場合について考える。
【００４７】
ＳＷ１（１００）が受信するリアルタイムデータパケットの内で、Ｉ１とＩ２とについては、間隔が揺らいでいるが、Ｉ３以降のパケットは、間隔が揺らいでいないことは、上記のとおりである。
【００４８】
このことから、原則的には、ＳＷ１（１００）は、Ｉ３を受信した時点から、受信間隔の測定を開始し（４０）、Ｉ４を受信した時点で、リアルタイムデータパケットの受信間隔Ｔを確定し（４１）、Ｉ４を受信してから、リアルタイムストリームパケットの受信周期Ｔ後に、次のリアルタイムデータパケットが受信されることを予想することができる（４２）。
【００４９】
このことから、ＳＷ１（１００）は、Ｉ４受信時刻から受信周期Ｔ後に、非同期パケットを送信中にならないように、非同期パケットの送信を抑制し（４３）、予想していたＩ５を受信し、ＳＷ３（１０２）に送信してから、非同期パケット（ここではＨ）を送信する。
【００５０】
上記のように、ＳＷ１（１００）がＳＷ３（１０２）に送信したパケット列を、ストリーム１チャネル（１２０）と、非同期データ２チャンネル（１２１）、（１２２）とを合流させたＳＷ１（１００）の送信データとして、（２５）に示す。
【００５１】
さらに、これと同様に、ＳＷ３（１０２）が受信するリアルタイムストリームパケットにおいて、Ｉ１、Ｉ２、Ｉ３、Ｉ４は、間隔が揺らいでいる可能性があるが、Ｉ５以降のリアルタイムパケットの間隔は、揺らいでいない。
【００５２】
したがって、ＳＷ３（１０２）は、Ｉ５受信時に、リアルタイムストリームパケット受信間隔の測定を開始し（４５）、Ｉ６を受信したときに、ストリームデータパケットの受信周期Ｔを確定し（４６）、Ｉ６受信時刻から受信周期Ｔ後に、Ｉ７が受信されることを予想し（４７）、Ｉ７受信時刻近傍で受信された非リアルタイムパケットＯについては、送信を控え（４８）、Ｉ７受信送信後に、非リアルタイムパケットであるＯを送信する（４９）ことが可能である。
【００５３】
この結果、ＳＷ３（１０２）に接続されている映像出力装置１（１１５）が受信するリアルタイムデータパケットの内で、データＩ１、Ｉ２、Ｉ３、Ｉ４、Ｉ５、Ｉ６について、受信間隔に揺らぎが発生するが、Ｉ７以降のリアルタイムデータパケットの受信間隔は保障される。映像出力装置１（１１５）が受信するパケット列を、ストリーム受信先が受信するデータとして、（２７）に示す。
【００５４】
ここまで図３に関して説明した内容のうちで、ネットワークスイッチにおけるリアルタイムストリームパケットの送信周期の検出方法において、解決されていない点は、どのリアルタイムパケットから、その受信周期Ｔが揺らいでいないと、あるネットワークスイッチが判断し、受信周期Ｔの測定を開始するかという点である。
【００５５】
本実施例では、上記解決されていない点を、次の方針（１）、（２）で解決する。
【００５６】
方針（１）…あるスイッチにおいて、そのスイッチとストリーム送信端末との間のスイッチの数をＮとすると、そのスイッチにおいて、送信周期Ｔが揺らいでいないと見なせるリアルタイムパケットは、Ｎ＊２＋１個目のパケット以降である。
【００５７】
方針（２）…受信したリアルタイムフレームに、周期が守られていることを示すマークが付与されている場合、そのマークが付与されているフレーム以降のフレームは、周期Ｔが揺らいでいないと見なせる。
【００５８】
次に、上記実施例において、スイッチがリアルタイムストリームパケット間周期Ｔの測定を開始し、確定するまでの流れについて、説明する。
【００５９】
まず、スイッチで一般的に行われるフレームの受信送信処理について説明する。
【００６０】
図４は、スイッチで一般に行われるフレームの受信送信処理を示すフローチャートである。
【００６１】
スイッチは、パケットを受信すると、その受信パケットの内容をチェックする（２０１）。一般的には、ここで、スイッチは、送信元ＭＡＣアドレスと宛先ＭＡＣアドレスとを確認し、その宛先ＭＡＣアドレスを持つ端末がどのポートに接続されているかを確認する。次に、スイッチは、そこで確認されたポートについて、パケットのスイッチ処理を行う（２０２）。さらに、ポートにおいて、送信すべきパケットが、送信データキューに挿入されると、そのパケットの送信処理を行う（２０３）。
【００６２】
この流れのうちで、本実施例におけるリアルタイムストリームパケットの受信周期検出は、主に受信パケットの内容チェック（２０１）の段階で行われる。受信パケットの内容チェック（２０１）のうちで、受信周期検出に関わる部分について説明する。
【００６３】
図５は、上記実施例において、受信パケットの内容チェック（２０１）のうちで、受信周期検出に関わる部分の動作を示すフローチャートである。
【００６４】
受信パケットのチェック処理が開始されると（２０１）、受信パケットがリアルタイムストリームデータであるかどうかを判断する（２０５）。このために、リアルタイムストリームデータパケットには、そのパケットがリアルタイムデータパケットであるか、非リアルタイムデータパケットであるかを識別するフラグが必要であり、このフラグは、リアルタイムストリームパケット送信元の機器によって付けられる。
【００６５】
リアルタイムストリームデータであるかどうかを判断（２０５）する場合、パケットがリアルタイムストリームデータではなければ、受信周期検出に関する受信パケットの内容チェック処理は終了する。
【００６６】
もし、リアルタイムストリームデータパケットであれば（２０５）、そのリアルタイムストリームは、受信周期測定中であるか否かを判断する（２０６）。もし、周期測定中でなければ、そのリアルタイムストリームパケットで、受信周期Ｔの測定を開始するか（２０７）どうかを判断し（※）、測定を開始すれば、そのフレームの受信時刻を保存する（２０８）。リアルタイムストリームデータの受信周期測定中であれば、受信したリアルタイムストリームデータパケット受信時刻と、前リアルタイムストリームデータ受信時刻との差分に基づいて、リアルタイムストリームデータ受信周期Ｔを算出する（２０９）。
【００６７】
周期Ｔが判明したら、フレーム送信処理の送信スケジューラに、次期リアルタイムストリームデータ受信時刻を通知する（２１１）ことによって、その時刻に、送信ポートが非リアルタイムデータ送信中の状態にならないように、非リアルタイムデータ送信の抑制を依頼する。
【００６８】
次に、リアルタイムストリームパケットで受信周期Ｔの測定を開始するか（２０７）どうかを判断する動作（上記※部分の動作）について説明する。
【００６９】
図６は、上記実施例において、リアルタイムストリームパケットで受信周期Ｔの測定を開始するか（２０７）どうかを判断する動作を示すフローチャートである。
【００７０】
ネットワークスイッチがリアルタイムストリームデータパケットを受信すると、そのリアルタイムストリームデータパケットを用いて、パケット周期Ｔを測定開始するかどうかを判断する（２０７）。スイッチにおいて、リアルタイムストリームデータの送信元からのホップ数（経由スイッチ数）が判明していれば（２３０）、そのリアルタイムストリームデータの送信元までのホップ数を確認する（２３１）。
【００７１】
ホップ数の確認方法については、ここでは細かく規定はしないが、トレースルートによる方法や、端末からのスイッチ段数についての設定を、スイッチに予め行っておくか、または、特定のプロトコルを用いてその段数（ホップ数）をスイッチが検出しておく等の方法が考えられる。
【００７２】
このような方法において取得されたスイッチと、リアルタイムストリーム送信元端末との間の経由スイッチ数がＮ個である場合、図３に示すように、Ｎ＊２＋１個目のパケット以降のパケット受信周期は揺らいでいないと判断できるので、その個数目のパケットを受信するまで、リアルタイムストリームデータパケットの個数をインクリメントしつつ、パケットを見送る（２３２）、（２３４）、（２３５）。
【００７３】
スイッチが、Ｎ＊２＋１個目のパケットを受け取ると（２３２）、（２３３）、そのパケット受信時点から、次のパケット受信時点までの時間の測定を開始する。この測定において、測定するか否かを判断してから、測定を開始するようにしてもよいが、より正確な周期測定を行うためには、リアルタイムストリームパケットを予め受信した時点で、常に測定を開始し、その測定が有効であるか否かを、ここで示した測定開始条件によって判断することが望ましい。その後、次のリアルタイムパケットを受信した時点で、リアルタイムパケット間の周期Ｔを確定することができる。
【００７４】
スイッチにおいて、リアルタイムストリームパケット送信元との間の経由スイッチ数が判明していない場合、ストリーム送信端末やスイッチが、そのリアルタイムストリームパケットの送信周期を守っていると判断した場合、周期が守られていることを、パケットにマークすることを前提に、受信したフレームに受信周期が守られていることを示すマークが入っていることを、フレーム受信スイッチで判断し（２２０）、（２２１）、もし、受信フレームに周期維持マークが入っていなければ、そのフレームによって受信周期Ｔの測定は開始しない（２２３）が、受信周期が守られていることを示すマークが入っていれば（２２１）、受信周期Ｔの測定を開始する（２２４）。
【００７５】
このときに、このスイッチは、受信周期Ｔが確定するまでは、受信したリアルタイムデータパケットの予め定められた周期が守られていることを示すマークに、周期が守られていない旨を示した上で（２２７）、パケット中継のための送出を行う必要がある。
【００７６】
このときに、リアルタイムストリームパケットのどの部分に、その送信周期（受信周期）が守られているかどうかのマークを入れるかを、考慮する必要があるが、本実施例では、ＭＡＣフレームの長さタイプフィールドに入れることを想定している。
【００７７】
また、もし、スイッチのＩＰヘッダにそのマークを入れることが、能力的に可能である場合、ＴＯＳフィールドに入れることも考えられる。また、上記リアルタイムパケットであるか非リアルタイムパケットであるかを示す識別子を、ヘッダに加えれば、この周期性保持フラグと合わせて、２ビットを長さタイプフィールドまたは、ＴＯＳフィールドに消費する。ただし、ポート番号やペイロードで、リアルタイムデータと非リアルタイムデータとの識別を行う場合は、この限りではない。
【００７８】
周期性保持マークをつけ外しする機会については、システムの構成によって様々な場合が考えられる。まず、端末において、周期性が保持されているマークを付け、スイッチにおいて、パケットの周期性が保障されるまでは外し、保障された時点で、マークを付ける方法があり、また、端末にマークをつけずに、端末に直結しているスイッチに、そのパケットの周期性を確認した時点で、またはパケットの周期性を確認するまでもなく、スイッチに端末を直結しているので、パケットの周期性が維持されていることを明らかに判断できる場合に、そのスイッチで、周期Ｔを確定できた時点で、マークを付ける方法等が考えられる。
【００７９】
本実施例によるスイッチを用いて、図２に示すシステムを運用した場合に、それぞれのネットワークノードからの送信パケット列について、図１の下半分を用いて説明する。
【００８０】
カメラ１（１１０）がリアルタイムストリームデータを送信している様子を、図１の（２１）に示す。
【００８１】
ここでは、リアルタイムストリームを構成するパケットＩ１からＩ８が定期的に送信されている様子が示されている。また、制御端末Ａ（１０９）が、制御用の非同期データを送信する様子を、図１の（２２）に示してある。
【００８２】
ここでは、非同期パケットＢ、Ｃ、Ｄ、Ｅ、Ｆが送信されている。ＳＷ４（１０３）では、Ｉ１、Ｉ２によってリアルタイムストリームパケット間の周期Ｔが確定されているので、Ｉ２受信時刻からＴ後には、Ｉ３が受信されることが予想され、このための送出資源が予約されている。
【００８３】
したがって、ＳＷ４（１０３）からの送信パケット列は、（２３）に示すように、Ｉ３以降Ｉ４、Ｉ５、Ｉ６、Ｉ７、Ｉ８…のリアルタイムストリームパケットの送信周期は、ストリーム送信端末と同様に維持される。
【００８４】
これらＳＷ４（１０３）からのパケット列（２３）と、ＳＷ２（１０１）からのパケット列（２４）とを、ＳＷ１（１００）が受信し、ＳＷ１（１００）が、次の経路であるＳＷ３（１０２）に、パケット列を送出する様子を示したものが、図１の（２５）のパケット列である。
【００８５】
ＳＷ１（１００）では、Ｉ３からパケット周期測定Ｔを開始し、Ｉ４受信時点では、次のＩ５受信時刻が、Ｉ４受信時刻のＴ後であることが判明しているので、Ｉ５以降Ｉ６、Ｉ７、Ｉ８…のリアルタイムストリームパケットの送信周期を、ストリーム送信端末と同様に保つことができる。
【００８６】
このパケット列（２５）が、ＳＷ１（１００）からＳＷ３（１０２）に送出されることになり、ＳＷ３（１０２）が、制御端末Ｃ（１１４）から、（２６）のようなパケット列を送出した場合、ＳＷ３（１０２）から、映像出力装置１（１１５）に送出するパケット列は、（２７）に示すようになる。
【００８７】
ＳＷ３（１０２）では、Ｉ５を受信すると、受信周期Ｔの測定を開始し、Ｉ６受信時点で受信周期Ｔを確定し、Ｉ６受信時刻からＴ後に、Ｉ７を受信することが判明している。
【００８８】
ＳＷ３（１０２）では、Ｉ７受信時刻に、そのための送信資源を確保しているので、Ｉ８以降Ｉ９……のリアルタイムストリームパケットの送信周期を、ストリーム送信端末と同様に維持することができる。
【００８９】
本実施例において、さらに、リアルタイムストリーム送信元であるカメラ１（１１０）は、本当のリアルタイムデータを載せたリアルタイムストリームパケットを送信するに先立って、スイッチネットワークの段数深度に応じた予備（ダミー）リアルタイムストリームパケットを送信することを想定している。
【００９０】
すなわち、カメラ１（１１０）が初めに送信するリアルタイムストリームパケットＩ１からＩ６は、送信周期を保ったリアルタイムストリームパケットではあるが、パケットデータの内容としては、ダミーデータが詰め込まれている。
【００９１】
このために、受信側映像出力装置１（１１５）において受信された結果的に揺らぎのあるリアルタイムストリームパケットＩ１から、Ｉ６のパケットが破棄されても、システムとしては問題ない。その後に、受信側映像出力装置１（１１５）が受信するＩ７以降のリアルタイムストリームデータは、送信側カメラ１（１１０）によって、実データが詰め込まれているが、受信側映像出力機器１（１１５）がパケットを受信した際に、継続して周期Ｔが守られたリアルタイムストリームデータパケットになり、映像出力時に、特別な伝送遅延揺らぎ吸収バッファを用意する必要性がなく、また、非常に小さいバッファのみを用意することによって、正常な映像再生が可能になる。
【図面の簡単な説明】
【００９２】
【図１】本発明の実施例におけるストリームを示す図である。
【図２】本実施例におけるネットワーク構成を示す図である。
【図３】上記実施例の動作説明図である。
【図４】スイッチで一般に行われるフレームの受信送信処理を示すフローチャートである。
【図５】上記実施例において、受信パケットの内容チェック（２０１）のうちで、受信周期検出に関わる部分の動作を示すフローチャートである。
【図６】上記実施例において、リアルタイムストリームパケットで受信周期Ｔの測定を開始するか（２０７）どうかを判断する動作を示すフローチャートである。
【符号の説明】
【００９３】
１００…ＳＷ１、
１０１…ＳＷ２、
１０２…ＳＷ３、
１０３…ＳＷ４、
１０４…ＳＷ５、
１０５…ＳＷ６、
１０９…制御端末Ａ、
１１０…カメラ１、
１１１…制御端末Ｂ、
１１２…カメラ２、
１１３…映像出力装置２、
１１４…制御端末Ｃ、
１１５…映像出力装置１。
【図１】
2005268872.tif 000003
【図２】
2005268872.tif 000004
【図３】
2005268872.tif 000005
【図４】
2005268872.tif 000006
【図５】
2005268872.tif 000007
【図６】
2005268872.tif 000008