(57)【要約】    【課題】  リアルタイムデータを確実に伝送し得る伝送システム、及び制御方法を提供する。    【解決手段】  中継装置としてのスイッチ装置、及びルータは、アイソサーバから指定されたタイミングで各アイソデータサーバから所定のターミナルに送出されるアイソデータパケットを中継する。この際、複数のアイソデータパケットが伝送経路において競合する場合は、スイッチ装置、及びルータは、当該複数のアイソデータデータパケットを纏めて連続して出力する。【選択図】      図１
2006279852.tif 000002
【特許請求の範囲】
【請求項１】
アイソクロナスデータパケットをデータ出力サーバからターミナル装置に伝送する際の伝送タイミングを指定するための同期制御用パケットを、前記データ出力サーバに一定の時間間隔で供給する同期制御サーバと、前記アイソクロナスデータパケット及び同期制御用パケットの伝送を中継する中継装置とを有する伝送システムであって、
前記中継装置は、前記アイソクロナスデータパケットの伝送経路において複数のアイソクロナスデータパケットが競合した場合に、当該複数のアイソクロナスデータパケットを纏めて連続して出力する出力制御手段を有することを特徴とする伝送システム。
【請求項２】
前記同期制御サーバは、伝送タイミングを指定するためのカウンタ値を前記同期制御用パケットに設定することを特徴とする請求項１に記載の伝送システム。
【請求項３】
前記中継装置は、前記同期制御サーバから前記データ出力サーバに供給される前記同期制御用パケットを中継する場合は、当該中継装置での中継処理に要する時間に応じて前記カウンタ値を更新することを特徴とする請求項２に記載の伝送システム。
【請求項４】
前記データ出力サーバは、前記同期制御用パケット中の前記中継装置により更新されたカウンタ値をカウントし終えた時点で所望の前記アイソクロナスデータパケットを所望の前記ターミナルに伝送することを特徴とする請求項２又は３に記載の伝送システム。
【請求項５】
アイソクロナスデータパケットをデータ出力サーバからターミナルに伝送する際の伝送タイミングを指定するための同期制御用パケットを、前記データ出力サーバに一定の時間間隔で供給する同期制御サーバと、前記アイソクロナスデータパケット及び同期制御用パケットの伝送を中継する中継装置とを有する伝送システムにおける制御方法であって、
前記中継装置は、前記アイソクロナスデータパケットの伝送経路において複数のアイソクロナスデータパケットが競合した場合に、当該複数のアイソクロナスデータパケットを纏めて連続して出力することを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、伝送システム、及び制御方法に関し、特にリアルタイムでデータを伝送する場合の伝送制御技術に関する。
【背景技術】
【０００２】
従来、ストリーミングのようにリアルタイムでデータを伝送する場合のプロトコルとしては、ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）が広く使用されている（非特許文献１，２参照）。
【０００３】
このＲＴＰは、データ本体であるペイロードの伝送を行うプロトコルと、そのペイロードの伝送制御を行うプロトコル（ＲＴＣＰ：ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を有している。上記のペイロード自体を伝送するプロトコルとしては、パケットの到着確認応答をせず、不着のパケットがあっても無視するＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）が用いられる。一方、ＲＴＣＰは、ＴＣＰ／ＩＰ上に実装され、伝送メディアのネゴシエーションやＱｏＳ（Ｑｕａｌｉｙ  ｏｆ  Ｓｅｒｖｉｃｅ）の監視、セッションの開始／終了などを制御する。
【０００４】
ＲＴＰでは、或るＲＴＰパケットのフォーマットを変換するトランスレータと、複数のＲＴＰパケットのフォーマットを１つのフォーマットに纏めるミキサが想定されている。このことから、ＲＴＰパケットのフォーマットとしては、図８に示したフォーマットを使用している。図８のフォーマットにおけるＳＳＲＣ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｓｏｕｒｃｅ）Ｉｄｅｎｔｉｆｅｒは、ＲＴＰパケットの送信元を示す同期送信元識別子である。また、ＣＳＲＣ（Ｃｏｎｔｒｉｂｕｔｉｏｎ  Ｓｏｕｒｃｅ）Ｉｄｅｎｔｉｆｉｅｒは、寄与送信元識別子であり、当該ＲＴＰパケットの送信に寄与した送信元のリストを示すものである。トランスレータを経由した場合は、ＣＳＲＣ識別子に対してトランスレータの識別子が追加される。また、ミキサを経由した場合は、以前のＳＳＲＣ識別子がＣＳＲＣ識別子に追加されて、ミキサの識別子が新たなＳＳＲＣ識別子となる。
【０００５】
シーケンス番号は、当該ＲＴＰパケットのペイロードに割り当てられた通し番号であり、ＲＴＰパケットを送信するごとに「１」ずつ単調に増加されるものである。また、タイムスタンプは、当該ＲＴＰパケットを送信した時刻を示すものである。ただし、この時刻は実際に当該ＲＴＰパケットを送信した実時刻ではなく、他のＲＴＰパケットの送信時点との相対的な時刻であり、３２Ｂｉｔで与えられるものである。
【０００６】
このようなフォーマットのＲＴＰパケットは、基本的には、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａ  Ｐｒｏｔｃｏｌ）を用いて送信元から送信先にダウンロードされる。受信側では、ＲＴＣＰにより、このダウンロードの状況（通信状態、回線状態）を上記のシーケンス番号、タイムスタンプ等に基づいて判断し、そのレポートを定期的に送信元にする。そして、送信側では、ＲＴＣＰにより、この回線状態のレポートに基づいてペイロードの品質を調整する等の伝送制御を行う。
【０００７】
このようなＲＴＣＰ／ＲＴＰによる伝送制御の概要を図９に基づいて説明する。図９において、クライアント（受信側）は、［ＯＰＴＩＯＮＳ］コマンドをサーバ（送信側）に送信することにより、サーバとの間で相互に機器情報を交換する。次に、サーバは、［ＤＥＳＣＲＩＢＥ］コマンドにより伝送コンテンツに関する情報をクライアントに告知する。クライアントは、告知された情報に基づいてコンテンツの伝送方法を決定し、その伝送方法を［ＳＥＴＵＰ］コマンドによりサーバに通知する。そして、クライアントは、［ＰＬＡＹ］コマンドをサーバに送信することにより、サーバに対してコンテンツの伝送を要求する。    
【０００８】
ここまでの一連の交信は、ＴＣＰ／ＩＰ上に実装されたＲＴＣＰを用いて、情報の欠落を招くことなく行われる。すなわち、ＴＣＰ／ＩＰが用いられているので、伝送路上でパケットが欠落した場合は、そのパケットの欠落状態がＴＣＰ／ＩＰにより認識されて、当該パケットが再送されることになる。
【０００９】
次に、ＲＴＰを用いて、サーバからクライアントにコンテンツ（ＲＴＰパケット）が連続的に伝送される。この伝送に用いられるＲＴＰはＵＤＰ／ＩＰ上に実装されているので、ＲＴＰパケットが欠落した場合でも再送されることなく連続的にＲＴＰパケットが伝送される。
【００１０】
最後に、ＲＴＣＰにおける［ＴＥＡＲＤＯＷＮ］コマンドがクライアントからサーバに送信されると、サーバはＲＴＰパケットの送信を停止する。なお、クライアントは、ＲＴＣＰに基づいてＲＴＰパケットの欠落等を検出しており、ＲＴＰパケットの欠落等を検出した場合は、ＵＤＰに基づくＲＴＰパケットの連続受信が完了した後に、ＲＴＣＰに係る［ＲＥＳＥＮＤ］コマンドをサーバに送信することにより、欠落したＲＴＰパケットの再送信を要求する。
【００１１】
このようなＲＴＣＰやＲＴＰを用いた伝送では、データの伝送に必要な回線の帯域を確保するための制御は行われていない。そこで、ＲＦＣ２２０５（非特許文献３参照）において、帯域制御プロトコルＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｃｏｌ：リソース予約プロトコル）が策定されている。このＲＳＶＰでは、一連のストリーミングデータについて、リソース、すなわち回線の帯域を予約する。
【００１２】
図１０は、ＲＳＶＰにより回線の帯域を予約する場合に使用されるホストとルータの構成を示す。図１０のホストにおいて、アプリケーションによりＲＳＶＰＰｒｏｃｅｓｓに対して優先権主張がなされ、その優先権主張がＡｄｍｉｓｓｉｏｎＣｏｎｔｒｏｌにより認証されると共にＰｏｌｉｃｙＣｏｎｔｒｏｌによりポリシィ制御が行なわれると、パケットクラシファイアは、アプリケーションから発生したリアルタイムストリームに対して優先度の高い分類パラメータを付与し、パケットスケジューラは、アプリケーションから発生したリアルタイムストリームに係るパケットに対して優先的に帯域の予約を行う。
【００１３】
これらのプロセスがホスト→ルータ→…→ルータ→ホストとういう伝送経路上の一連のルータに対して行なわれることにより、リソースの確保が行われる。このように、ＲＳＶＰでは、ホスト−ホスト間の伝送経路に対してＱｏＳが設定され帯域が確保される。
【非特許文献１】ＩＥＴＦ標準  ＲＦＣ１８８９  Ｉｎｔｅｒｎｅｔ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１８８９．ｔｘｔ？ｎｕｍｂｅｒ＝１８８９
【非特許文献２】ＩＥＴＦ標準  ＲＦＣ１８９０  Ｉｎｔｅｒｎｅｔ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１８９０．ｔｘｔ？ｎｕｍｂｅｒ＝１８９０
【非特許文献３】ＩＥＴＦ標準  ＲＦＣ２２０５  Ｉｎｔｅｒｎｅｔ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２０５．ｔｘｔ？ｎｕｍｂｅｒ＝２２０５
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、このような従来の伝送方式では、スイッチやルータなどのネットワークの中継機器において生じる伝送遅延、ゆらぎ、パケット損失等の影響により、画像や音声などのストリーミングデータ（リアルタイムデータ）を確実に伝送できない場合があった。
【００１５】
本発明は、このような背景の下になされたもので、リアルタイムデータを確実に伝送し得る伝送システム、及び制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１６】
上記目的を達成するため、本発明は、アイソクロナスデータパケットをデータ出力サーバからターミナル装置に伝送する際の伝送タイミングを指定するための同期制御用パケットを、前記データ出力サーバに一定の時間間隔で供給する同期制御サーバと、前記アイソクロナスデータパケット及び同期制御用パケットの伝送を中継する中継装置とを有する伝送システムであって、前記中継装置は、前記アイソクロナスデータパケットの伝送経路において複数のアイソクロナスデータパケットが競合した場合に、当該複数のアイソクロナスデータパケットを纏めて連続して出力する出力制御手段を有することを特徴とする。
【発明の効果】
【００１７】
本発明によれば、リアルタイムデータを確実に伝送し得る伝送システム、及び制御方法を提供することが可能となる。
【発明を実施するための最良の形態】
【００１８】
図２は、本発明の実施の形態に係る伝送システムを適用したネットワークの構成例を示す図である。本ネットワークには、アイソサーバ２０１、データサーバ２０４，２０５、ターミナル２０２，２０３、スイッチ装置２０６〜２１０、ルータ２１１，２１２が接続されている。
【００１９】
アイソサーバ２０１は、データサーバ２０４，２０５による映像、音声等のアイソクロナスデータ（リアルタイムデータ）の同期伝送を保証するために、送信タイミングを指定するためのパケット（以下、アイソパケットと称する）を一定の時間間隔でデータサーバ２０４，２０５に送信する（図２の一点鎖線参照）ものであり、同期制御サーバとして機能する。
【００２０】
このアイソパケットのＭＡＣ層におけるフレーム形式は図６（ａ）、ＩＰ層におけるフレーム形式は、図７（ｂ）又は（ｃ）のようになっている。これらフレーム形式については、後で詳細に説明するが、最大の特徴点は、カウンタ値により送信タイミングを指定する点である。
【００２１】
データサーバ２０４，２０５は、アイソサーバ２０１から一定の時間間隔（周期）で送信されるアイソパケット内の上記カウンタ値に基づいて、一定周期でターミナル２０２，２０３に対してアイソクロナスデータを送信する（図２の破線参照）。このアイソクロナスデータは、実際にはパケットで送信され、本明細書では、アイソクロナスデータをペイロードとして有するパケットをアイソデータパケットと称している。
【００２２】
スイッチ装置２０６〜２１０は、同一ネットワーク内のステーションを相互に接続するものであり、ＭＡＣ層の情報に基づいて伝送路を切換える。ルータ２１１，２１２は、ネットワーク同士を相互に接続するものであり、ＩＰ層の情報に基づいて伝送路を切換える。
【００２３】
図３は、スイッチ装置２０６〜２１０の概略構成を示すブロック図である。図３において、３０１はＥｔｈｅｒｎｅｔ（登録商標）−Ｐａｃｋｅｔの交換を行うスイッチ装置、３０２，３０４，３０６は受信したフレームをＥｔｈｅｒｎｅｔ（登録商標）−Ｐａｃｋｅｔに分解するメディアアクセスコントローラ装置（以下、ＭＡＣと略称する）、３０３，３０５，３０７は送受信するフレームを電気信号や光信号に変換する物理層装置（以下、ＰＨＹと略称する）である。
【００２４】
ＰＨＹ３０３，３０５，３０７の間には、ＭＤＩＯと呼ばれる制御用のインタフェースが設けられている。また、各ＰＨＹ３０３，３０５，３０７と対応して、ＭＤＩＯ  Ｒｅｇｉｓｔｅｒ３２１、ＭＤＩＯ  Ｃｏｎｔｒｏｌｌｅｒ３２２、ＭＩＩ／ＧＭＩＩ  ＭＤＩＯ  Ｉｎｔｅｒｆａｃｅ３２３が設けられ、ＰＨＹ３０３，３０５，３０７は、それぞれ対応するＭＤＩＯ  Ｒｅｇｉｓｔｅｒ３２１、ＭＤＩＯ  Ｃｏｎｔｒｏｌｌｅｒ３２２、ＭＩＩ／ＧＭＩＩ  ＭＤＩＯ  Ｉｎｔｅｒｆａｃｅ３２３を介して制御される。
【００２５】
ＭＡＣ３０２，３０４，３０６は、受信系と送信系に大別され、受信系では主にフレームの解析、送信系では主にフレームの付加を行っている。また、ＭＡＣ３０２，３０４，３０６は、図６（ａ）に示すＣｏｕｎｔｅｒ拡張Ｔａｇを有するアイソパケットを受信した場合に備えて、カウンタ値に関する処理を行なうＣｏｕｎｔｅｒ抽出ＩＤ付与部３１０、カウンタ群３１１、ＩＤ符号Ｃｏｕｎｔｅｒ付与部３１７等を有している。なお、このＭＡＣ３０２，３０４，３０６の詳細な構成及び動作は、後で説明する。
【００２６】
図４は、ステーションとしてのアイソサーバ２０１、ターミナル２０２，２０３、及びデータサーバ２０４，２０５のネットワークインタフェース部の構成を示すブロック図である。
【００２７】
図４の構成において、データサーバ２０４，２０５は、送信イベントが発生すると、送信データは、ＴｘＦＩＦＯ（送信バッファ）４０２に一時的に格納された後、ＣｏｕｎｔＲｅｇｉｓｔｅｒ４０１による計時時間に基づいてＦｒａｍｅＧｅｎｅｒａｔｏｒ４０４に転送される。ＦｒａｍｅＧｅｎｅｒａｔｏｒ４０４は、送信データに基づいて送信フレームを生成する。この送信フレームは、ＦｒａｍｅＣｈｅｃｋＳｅｑｕｅｎｃｅ４０３により誤り検出符合が付加された後、ＭＩＩ／ＧＭＩＩＴｘＩｎｔｅｒｆａｃｅ４０５、送信ＰＨＹ４０６を介してＭＥＤＩＵＭ（伝送路）へ出力される。
【００２８】
一方、受信側では、ＰＨＹ４０６で受信されたフレームは、ＭＩＩ／ＧＭＩＩＲｘＩｎｔｅｒｆａｃｅ４０７を介して入力され、フレーム解析部４０８でフレーム解析が行なわれ、フレーム本体は、ＲｘＦＩＦＯ４１１を介してＩｎｓｉｄｅＢｕｓ４１７へ入力される。そして、ＣＰＵ４１６の指示によってはメモリ４１５に格納される。
【００２９】
また、フレーム解析部４０８でのフレーム解析により、Ｃｏｕｎｔｅｒ拡張Ｔａｇが検出された場合は、Ｃｏｕｎｔｅｒ抽出部４０９によりカウンタ値が抽出される。そして、Ｃｏｕｎｔｅｒ４１０では、抽出されたカウンタ値のカウントダウンによる計時処理が行なわれ、カウントダウン値が「０」になった時点、すなわちアイソサーバ２０１が意図したタイミングでアイソデータパケットが送信される。
【００３０】
ここで、本実施の形態に特有なアイソパケットのフレーム構成を説明する前に、ＩＥＥＥで定義されている標準のパケットのフレーム構成を図５（ａ），（ｂ）に基づいて説明しておく。
【００３１】
図５（ａ）は、ＩＥＥＥ８０２．３で定義されている通常のパケットのフレーム構成を示している。このフレームの最初のフィールドはプリアンブルと呼ばれる物理層に用いられるヘッダであり、フレームの最初を示す６４ｂｉｔの「１」と「０」が交互に繰り返されるパターンになっている（ただし、最後の２ｂｉｔだけは「１１」である）。次に、４８ｂｉｔ送信元のアドレスを示すＳｏｕｒｃｅＡｄｄｒｅｓｓフィールド、続いて４８ｂｉｔの宛先アドレスであるＤｉｓｔｉｎａｔｉｏｎＡｄｄｒｅｓｓフィールドとなっている。
【００３２】
イーサネット（登録商標）フレームでは、次のフィールドは、Ｔｙｐｅ／Ｌｅｎｇｔｈフィールドとなる。このＴｙｐｅ／Ｌｅｎｇｔｈフィールドには、ペイロードの種別又は長さの情報が格納される。Ｔｙｐｅ／Ｌｅｎｇｔｈフィールドに０ｘ６００（１６進）以上の値が入っているときは、Ｔｙｐｅフィールドとして認識される。例えば上位層にＩＰを使用している場合には、０ｘ８００（１６進）が格納される。
【００３３】
また、図５（ｂ）に示したように、ＶＬＡＮ（ＩＥＥＥ標準８０２．１Ｑ参照）では、Ｔｙｐｅ／Ｌｅｎｇｔｈフィールドに０ｘ８１００（１６進）が格納される。Ｔｙｐｅ／Ｌｅｎｇｔｈフィールドに０ｘ８１００が設定されると、次の２バイトにＶＬＡＮタグ制御情報が入っていることを表し、続いてペイロード、ＦＣＳ（フレームチェックシーケンス）と続く。このＴｙｐｅ／Ｌｅｎｇｔｈフィールドの管理は米国ＩＥＥＥ８０２委員会が行っており、公に使用されているＴｙｐｅフィールドはインターネット＜ｈｔｔｐ：／／ｓｔａｎｄａｒｄｓ．ｉｅｅｅ．ｏｒｇ／ｒｅｇａｕｔｈ／ｅｔｈｅｒｔｙｐｅ／ｔｙｐｅ−ｐｕｂ．ｈｔｍｌ＞で知ることができる。
【００３４】
本実施の形態に係るアイソパケットでは、ＬｅｎｇｔｈフィールドではなくＴｙｐｅフィールドとして認識されるようにし、さらに図６（ａ）に示したように、定義済みのフィールド値以外の値をＣｏｕｎｔｅｒ拡張Ｔａｇとして用いている。すなわち、本実施の形態に係るアイソパケットでは、ＶＬＡＮ拡張Ｔａｇと同様に識別可能なＴａｇをＣｏｕｎｔｅｒ拡張Ｔａｇとして使用しており、この拡張Ｔａｇに続いてＣｏｕｎｔｅｒ値が記述されている。
【００３５】
従来のスイッチ装置でＣｏｕｎｔｅｒ拡張Ｔａｇ付きのパケットを受信した場合は、未定義のフィールドであるためにこのパケットは無視されるが、本実施の形態に係るスイッチ装置２０６〜２１０では、Ｃｏｕｎｔｅｒ拡張Ｔａｇに対応して、Ｃｏｕｎｔｅｒ拡張Ｔａｇと、それに続くＣｏｕｎｔｅｒ値を共に検出するようにしている。
【００３６】
図７（ａ）は、従来のパケットのＩＰ層を含むフレーム形式を示している。レイヤ１のプリアンブル、レイヤ２のＭＡＣヘッダに続いてレイヤ３の先頭にＩＰ層のＩＰヘッダが記述されている。図７（ｂ）、（ｃ）は、本実施の形態に特有なＣｏｕｎｔｅｒ値を記述するために考えられるアイソパケットの同期ＩＰフレーム形式を示している。
【００３７】
図７（ｂ）、（ｃ）において、レイヤ２のＭＡＣ層のヘッダでは、共にＣｏｕｎｔｅｒ拡張ＴａｇとＣｏｕｎｔｅｒ値が付与され、続いてＴｙｐｅ／Ｌｅｎｇｔｈフィールドとなっている。レイヤ３のＩＰ層のヘッダにおいても同じＣｏｕｎｔｅｒ拡張ＴａｇとＣｏｕｎｔｅｒ値を格納している。すなわち、図７（ｂ）の同期ＩＰフレーム形式では、レイヤ３のＩＰヘッダにおいて、ペイロード長のデータの後にＣｏｕｎｔｅｒ値を格納している。一方、図７（ｃ）の例では、ヘッダ長を拡張してＩＰヘッダオプションとしてＣｏｕｎｔｅｒ値を格納している。
【００３８】
図４の構成において、アイソサーバ２０１では、アイソパケットのヘッダにおけるＤｉｓｔｉｎａｔｉｏｎＡｄｄｒｅｓｓとＴｙｐｅ／ＬｅｎｇｔｈフィールドのデータがＴｘＦＩＦＯ４０２に蓄積される。そして、一定の時間間隔でアイソパケットの送信イベントが発生すると、フレーム生成部４０４により、図６（ａ）のようにユニークなＣｏｕｎｔｅｒ拡張Ｔａｇを挿入し、さらにＣｏｕｎｔｅｒ値を付加する。このＣｏｕｎｔｅｒ値は、或る時間単位をもち、当該アイソパケットを送出するステーションに対して任意のプロセスを実行するタイミングを指定するものである。
【００３９】
さらに、フレームチェックシーケンス部４０３により、誤り検出符号であるＣＲＣ３２をフレーム全体に渡って算出し、その算出値をフレームの最後に付加する。このようにして、アイソパケットの送出フレームが作成され、ＭＩＩ／ＧＭＩＩＴｘＩｎｔｅｒｆａｃｅ部４０５からＰＨＹ４０６に転送されてＰｒｅａｍｂｌｅなどの物理層のヘッダ情報が付加され、伝送路へ出力される。
【００４０】
アイソサーバ２０１から送出されたアイソパケットのフレームは、図２のネットワーク構成では、スイッチ装置２０６にて受信される。図３に示した構成例では、各スイッチ装置２０６〜２１０において受信されたフレーム情報は、物理層のブロックであるＰＨＹ３０３，３０５，３０７等により物理層のヘッダ情報であるＰｒｅａｍｂｌｅが除去されて、ＭＡＣブロックのＭＩＩ／ＲｘＩｎｔｅｒｆａｃｅ３０８に転送され、フレーム解析部３０９によりＴｙｐｅ／Ｌｅｎｇｔｈ情報に基づいてフレーム解析が行われて、受信ＦＩＦＯ３１２に一旦保存される。
【００４１】
フレーム解析部３０９でのフレーム解析の結果、Ｃｏｕｎｔｅｒ拡張Ｔａｇが付加されている場合は、Ｃｏｕｎｔｅｒ抽出ＩＤ付与部３１０で任意のＩＤ値が付与される。この際、フレーム情報中のＣｏｕｎｔｅｒ値は、Ｃｏｕｎｔｅｒ群３１１の上記のＩＤ値に対応するＣｏｕｎｔｅｒに保持されると共に、その保持Ｃｏｕｎｅｒに対応するＩＤ値に置換される［図６（ｂ）参照］。
【００４２】
受信ＦＩＦＯ３１２に一旦保存されたフレーム情報は、ＳＷＦａｂｒｉｃ３０１にてスイッチング先がＤｉｓｔｉｎａｔｉｏｎＡｄｄｒｅｓｓへスイッチングされる。スイッチング先がＭＡＣ−Ｎであった場合は、ＰｒｉｏｒｉｔｙＣｏｎｔｒｏｌｌｅｒ３１３により決定された優先順位に従って送信パケットが送信ＦＩＦＯ３１６に蓄積される。この送信パケットがＣｏｕｎｔｅｒ拡張Ｔａｇを持ったフレームの場合、すなわちアイソパケットのフレームの場合には、ＩＤ符合Ｃｏｕｎｔｅｒ付与ブロック２１７により、上記のＩＤ値を、当該ＩＤ値と合致したＩＤを持つＣｏｕｎｔｅｒのＣｏｕｎｔｅｒ値´に置換し、フレーム生成部３１８に転送してフレームを構成し直す。
【００４３】
この場合、フレーム生成部３１８により生成したアイソパケットのフレームは、Ｃｏｕｎｔｅｒ値が変化しているため、フレームの末端のＦＣＳ（フレームチェックシーケンス）を算出し直す必要がある。このＦＣＳ´をフレームチェックシーケンス部３１９にて算出し、従前のＦＣＳと置換する［図６（ｅ）参照］。このＦＣＳ´への置換がなされたアイソパケットのフレームは、ＭＩＩ／ＧＭＩＩＴｘＩｎｔｅｒｆａｃｅ３２０、ＰＨＹ３０３，３０５，３０７を介して伝送路へと送出される。
【００４４】
この場合、Ｃｏｕｎｔｅｒ群３１１は、フレームがＴｘＦＩＦＯ３１６、ＲｘＦＩＦＯ３１２に蓄積されている時間やＳＷＦａｂ．３０１に滞留している時間も含めてＣｏｕｎｔｅｒ値を所定の時間間隔でカウントダウンしているので、上記の置換されたＣｏｕｎｔｅｒ値´は、スイッチ装置でのスイッチング処理により生じたアイソパケットの伝送遅延時間を反映したものとなる。このようなＣｏｕｎｔｅｒ値´への置換処理は、全てのスイッチ装置２０６〜２１０で行なわれている。
【００４５】
なお、ルータ２１１，２１２においても、スイッチ装置２０６〜２１０と同様に、アイソパケットの伝送遅延時間をＣｏｕｎｔｅｒ値に反映させるための処理を行なっている。すなわち、ルータ２１１，２１２では、レイヤ２のヘッダにおいてＣｏｕｔｅｒ拡張Ｔａｇの有無を検出し、Ｃｏｕｎｔｅｒ拡張Ｔａｇが検出された場合には、ルーティングの所要時間を計時し、当該ルータ２１１，２１２にアイソパケットが伝送されてきた際のＣｏｕｎｔｅｒ値を、その所要時間の分だけカウントダウンして送出している。
【００４６】
従って、アイソサーバ２０１により当初設定されたＣｏｕｎｔｅｒ値は、データサーバ２０４，２０５に当該アイソパケットが到達した時点では、このアイソパケットが通過してきた各スイッチ装置及びルータ（中継機器）での処理に伴う合計の伝送遅延時間の分だけカウントダウンされたものとなる。
【００４７】
なお、アイソサーバ２０１は、アイソパケットをルータ２１１，２１２を介してデータサーバ２０５に送信する場合は、図７（ｂ）又は（ｃ）のＩＰフレーム形式を使用する。従って、ルータ２１１，２１２は、図７（ｂ）又は（ｃ）のＩＰフレーム形式におけるＣｏｕｎｔｅｒ値に対して、上記のルーティング所要時間の分のカウントダウンを行なう。
【００４８】
データサーバ２０４，２０５では、各中継機器での処理に伴う伝送遅延時間が反映された上記のＣｏｕｎｔｅｒ値（以下、このＣｏｕｎｔｅｒ値を残りのＣｏｕｎｔｅｒ値という）を有するアイソパケットを受信すると、図４の構成において、ＰＨＹ４０６により物理層ヘッダのＰｒｅａｍｂｌｅが取り除かれ、ＭＩＩ／ＲｘＩｎｔｅｒｆａｃｅ４０７を介してフレーム解析部４０８に転送され、ペイロード部分は、ＲｘＦＩＦＯ４１１に一旦格納された後、ＣＰＵ４１６の命令により、ＩｎｓｉｄｅＢｕｓ４１７を介してメモリ４１５に格納される。
【００４９】
フレーム解析部４０８でのフレーム解析により、受信に係るアイソパケットがＣｏｕｎｔｅｒ拡張Ｔａｇ付きのヘッダを有することが確認されると、Ｃｏｕｎｔｅｒ抽出部４０９により残りのＣｏｕｎｔｅｒ値が抽出され、残りのＣｏｕｎｔｅｒ値がＣｏｕｎｔｅｒ４１０により所定時間間隔でカウントダウンされる。
【００５０】
また、Ｃｏｕｎｔｅｒ４１０は、残りのＣｏｕｎｔｅｒ値をカウントダウンしていき、そのカウントダウン値が「０」になると、その旨をＣＰＵ４１６に通知する。ＣＰＵ４１６は、この通知を受けて、アイソデータパケットの送出等の所望のプロセスを起動する。この場合、Ｃｏｕｎｔｅｒ４１０が残りのＣｏｕｎｔｅｒ値をカウントダウンして、そのカウントダウン値が「０」になった時点は、これまでの説明から推測できるように、各中継機器での伝送遅延時間を吸収したものであり、アイソサーバ２０１が意図したプロセスを起動時点とマッチする時点となる。
【００５１】
換言すれば、中継機器で伝送遅延が生じたとしても、データサーバ２０４，２０５は、アイソサーバ２０１がアイソパケットで指定した時刻に正確に、且つ確実にアイソデータパケットを送信することができる。また、アイソサーバ２０１は、一定時間間隔で上記のアイソパケットをデータサーバ２０４，２０５に送出しているので、データサーバ２０４，２０５は、音声や映像のストリーミングデータを安定して送出することができる。
【００５２】
図３の構成において、スイッチ装置２０６〜２１０、及びルータ２１１，２１２は、Ｃｏｕｎｔｅｒ拡張Ｔａｇが付与されたパケット（アイソデータパケット）が受信され、ＳＷ−Ｆａｂ３０１にてパケット交換が行なわれると、そのパケットは、Ｉｓｏ−Ｂｕｆｆｅｒ３１４に一旦格納される。そして、ＩｎｔｅｒｖａｌＣｏｕｎｔｅｒ３１５が起動され、次にアイソデータパケットが入力されるまでの時間間隔が計測される。
【００５３】
ＰｒｉｏｒｉｔｙＣｏｎｔｏｒｏｌ部３１３は、計測された時間間隔に基づいて、次のアイソデータパケットが入力される時間を予測し、その予測時間から非アイソデータパケットの最大パケット長である１５００Ｂｙｔｅ長に相当する時点まで遡った時点までの区間を、非アイソ抑制区間として通常の非アイソパケットの出力を抑制する（図１の最下部参照）ことにより、中継機器内でのデータ衝突を回避する。
【００５４】
しかしながら、例えば図２のデータサーバ２０４からターミナル２０２に送出されるアイソデータパケットと、データサーバ２０５からターミナル２０３に送出されるアイソデータパケットは、スイッチ装置２０８とスイッチ装置２０９との間の伝送路において多重されるため、何も制御せずにスイッチ装置２０８からスイッチ装置２０９にアイソデータパケットを出力した場合は、図１の「アイソクロナスをまとめないＳＷ出力」で示すように、非アイソデータパケットの出力が抑制されている期間が長くなってしまう。
【００５５】
そこで、本実施の形態では、スイッチ装置２０８は、上流のスイッチ装置２０７からのアイソデータパケットの出力間隔をＩｎｇｅｔｖａｌ  Ｃｏｕｎｔｅｒ３１５にて計測し、スイッチ装置２０７から前回投入されたアイソデータパケットはＩｓｏ−Ｂｕｆｆｅｒ３１５に一時保存しておき、スイッチ装置２０７から次に投入されたアイソデータパケットが到来したときに、前回投入されたアイソデータパケットに続いて次に投入されたアイソデータパケットを出力する（図１の「アイソクロナスをまとめたＳＷ出力」参照）。
【００５６】
このように、通常の非アイソデータパケットとアイソデータパケットの出力タイミングを明確に時分割して出力することで、アイソデータパケットのストリームが多重化された伝送路においても、非アイソデータパケットの出力が抑制される期間が短縮され、伝送路を効率的に利用することが可能となる。
【００５７】
なお、本発明は、上記の実施の形態に限定されることなく、例えば、中継機器、及びデータサーバにおけるＣｏｕｎｔｅｒ値のカウント処理は、カウントダウンではなく、カウントアップにより行なうことも可能である。また、ネットワークの構成に応じて、上記のスイッチ装置２０８と同様の出力処理を他のスイッチ装置やルータで行なうことも可能である。
【図面の簡単な説明】
【００５８】
【図１】本発明の実施の形態における中継機器でのアイソクロナスパケットの送信処理を示すタイムチャートである。
【図２】本発明の実施に形態に係る伝送システムを適用したネットワークの構成例を示す図である。
【図３】上記ネットワーク上の中継機器（スイッチ装置）の概略構成を示すブロック図である。
【図４】上記ネットワーク上のステーション（アイソサーバ、データサーバ、ターミナル）のネットワークインタフェース部の構成を示すブロック図である。
【図５】パケットのレイヤ２の標準のフレーム形式を例示した図である。
【図６】本発明の実施の形態で使用されるアイソパケットのレイヤ２のフレーム形式を例示した図である。
【図７】本発明の実施の形態で使用されるアイソパケットのレイヤ３のフレーム形式を例示した図である。
【図８】従来のＲＴＰパケットの形式を示す図である。
【図９】従来のＲＴＰ／ＲＴＣＰのシーケンス図である。
【図１０】従来のＲＳＶＰによる帯域確保を説明するためのホストとルータの構成を示す図である。
【符号の説明】
【００５９】
２０１…アイソサーバ、２０２，２０３…ターミナル、２０４，２０５…データサーバ、２０６〜２１０…スイッチ装置、２１１，２１２…ルータ、３０２，３０４，３０６…ＭＡＣ（Ｅｔｈｅｒｎｅｔ（登録商標）層の制御部）、３１０…Ｃｏｕｎｔｅｒ抽出ＩＤ付与部、３１１…Ｃｏｕｎｔｅｒ群、３１５…Ｉｎｇｅｔｖａｌ  Ｃｏｕｎｔｅｒ、３１７…ＩＤ符号Ｃｏｕｎｔｅｒ付与部、４０９…Ｃｏｕｎｔｅｒ抽出部、４１０…Ｃｏｕｎｔｅｒ
【図１】
2006279852.tif 000003
【図２】
2006279852.tif 000004
【図３】
2006279852.tif 000005
【図４】
2006279852.tif 000006
【図５】
2006279852.tif 000007
【図６】
2006279852.tif 000008
【図７】
2006279852.tif 000009
【図８】
2006279852.tif 000010
【図９】
2006279852.tif 000011
【図１０】
2006279852.tif 000012