(57)【要約】【課題】  リアルタイム通信方式において、時刻を保証した上で、プロセスを実行することを保証することができ、すなわち、ＲＴＰを用いてストリームデータを送信した場合、受信側での再生時刻を制御することができる通信ネットワークシステムを提供することを目的とするものである。【解決手段】  自らデータを送受信する複数のステーションと、上記複数のステーション同士を相互に接続する伝送路と、上記伝送路を中継する中継器とによって構成されているネットワークシステムにおいて、データを送信する送信ステーションから、データを受信する受信ステーションまでの経過時間を計時する経路上の中継器と、上記送信ステーションからのデータと、上記計時した情報とを、上記受信ステーションに通知する通知手段とを有する通信ネットワークシステムである。【選択図】  図１
2005295100.tif 000002
【特許請求の範囲】
【請求項１】
自らデータを送受信する複数のステーションと、上記複数のステーション同士を相互に接続する伝送路と、上記伝送路を中継する中継器とによって構成されているネットワークシステムにおいて、
データを送信する送信ステーションから、データを受信する受信ステーションまでの経過時間を計時する経路上の中継器と；
上記送信ステーションからのデータと、上記計時した情報とを、上記受信ステーションに通知する通知手段と；
を有することを特徴とする通信ネットワークシステム。
【請求項２】
請求項１において、
上記中継器は、特定のパケットを受信してから計時を開始し、当該パケットを出力するまでの計時結果と、当該パケット内の計時情報から算出した計算結果とを、出力するパケットに書き込むものであることを特徴とする通信ネットワークシステム。
【請求項３】
請求項２において、
上記中継器は、上記中継器に直接接続されている中継器まで、またはステーションまでの伝送遅延を予め測定し、上記計時結果に、上記予め測定された伝送遅延を加算するものであることを特徴とする通信ネットワークシステム。
【請求項４】
請求項１において、
特定のパケットを受信してから計時を開始し、当該パケット内の情報と計時情報都に基づいて、特定のプロセスを起動することを特徴とする通信ネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークシステムにおける末端で送受信するステーション装置と、通信を中継するスイッチ、ルータ等の中継装置とに係り、特に、リアルタイムデータの送受信に関する。
【背景技術】
【０００２】
リアルタイムデータを伝送する従来の技術として、ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｃｏｌ）が広く使われている（たとえば、非特許文献１、非特許文献２参照）。
【０００３】
「ＲＴＰパケット」は、通常、トランスポート層プロトコル（ＵＤＰやＴＣＰ）等の上のレイヤを用いて伝送されるプロトコルであり、リアルタイムデータを伝送するＲＴＰと、ＱｏＳの監視やセッションの開始／終了を制御するＲＴＣＰ（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｃｏｌ）とによって構成されている。
【０００４】
ＲＴＰは、あるストリームのペイロードフォーマットの変換を行うトランスレータと、複数のストリームのペイロードフォーマットを、１つのペイロードフォーマットに組み合わせるミキサとが想定されている。
【０００５】
図７は、ＲＴＰにおけるフォーマットを示す図である。
【０００６】
ＲＴＰでは、図７に示すフォーマットを使用している。
【０００７】
このフォーマットで示すＳＳＲＣ（Ｓｙｎｃｈｎｏｎｉｚａｔｉｏｎ  Ｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｅｒ：同期送信元識別子）は、ストリームの送信元を示す識別子である。また、ＣＳＲＣ（Ｃｏｎｔｒｉｂｕｔｉｎｇ  Ｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ：寄与送信元識別子）は、ストリームに寄与した送信元のリストである。トランスレータを経由した場合、ＣＳＲＣに、トランスレータの識別子を追加し、ミキサを経由した場合は、以前のＳＳＲＣをＣＳＲＣに追加し、ミキサの識別子が新たなＳＳＲＣになる。
【０００８】
「シーケンス番号」は、あるストリームデータに割り当てられたランダムな数値であり、後に続くパケットに対して、「１」ずつ単調に増加される。
【０００９】
「タイムスタンプ」は、送信元のパケットが送信される時刻を、相対的な値で、３２Ｂｉｔ与える。このようにして作成したＲＴＰパケットを、一般的には、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａ  Ｐｒｏｔｃｏｌ）を用いて送信する。このプロトコルは、ステーション間のメッセージの送受信が最小になる代わりに、信頼性のない転送の可能性や、メッセージの重複の可能性が生じる。このことから、ＵＤＰ上のＲＴＰを用いたリアルタイムデータの転送は、データの信頼性や、データの転送に必要なトラヒックの確保という制御をしていない。
【００１０】
このために、ＲＦＣ２２０５（たとえば、非特許文献３参照）において、帯域制御プロトコルＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｃｏｌ：リソース予約プロトコル）が策定されている。ＲＳＶＰがリソースを予約する際には、一連のストリームに対して行う。
【００１１】
図８は、ＲＳＶＰに使用されるＨｏｓｔと、Ｒｏｕｔｅｒとの構成を示す図である。
【００１２】
図８において、アプリケーションがＲＳＶＰＰｒｏｃｅｓｓに対して優先権を主張するポリシ制御と、認証（ＡｄｍｉｓｓｉｏｎＣｏｎｔｒｏｌ）とが行われると、アプリケーションから発生したリアルタイムストリームに対するパケットクラシファイアにおけるパラメータが、設定パケットスケジューラの設定を完了する。
【００１３】
これらのプロセスをホスト→ルータ→・・・→ルータ→ホストの送信から、受信までの一連の通信路のリソースの確保が行われる。上記のように、ＲＳＶＰは、ホスト・ホスト間の一連の通信路に対して、ＱｏＳが設定され、帯域が確保される。
【非特許文献１】ＩＥＴＦ標準  ＲＦＣ１８８９  Ｉｎｔｅｒｎｅｔ＜ＵＲＬ：http://www.ietf.org/rfc/rfc1889.txt?number=1889＞
【非特許文献２】ＩＥＴＦ標準  ＲＦＣ１８９０  Ｉｎｔｅｒｎｅｔ＜ＵＲＬ：http://www.ietf.org/rfc/rfc1889.txt?number=1890＞
【非特許文献３】Ｉｎｔｅｒｎｅｔ＜ＵＲＬ：http://www.ietf.org/rfc/rfc2205.txt?number=2205＞
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかし、上記従来のリアルタイム通信方式では、ストリーム、ストリーム間の同期をとることは、ある程度の精度でできるが、時刻を保証した上で、プロセスを実行する保証はできない。すなわち、ＲＴＰを用いてストリームデータを送信した場合、受信側での再生時刻を制御することができないという問題がある。
【００１５】
本発明は、リアルタイム通信方式において、時刻を保証した上で、プロセスを実行することを保証することができ、すなわち、ＲＴＰを用いてストリームデータを送信した場合、受信側での再生時刻を制御することができる通信ネットワークシステムを提供することを目的とするものである。
【課題を解決するための手段】
【００１６】
本発明は、自らデータを送受信する複数のステーションと、上記複数のステーション同士を相互に接続する伝送路と、上記伝送路を中継する中継器とによって構成されているネットワークシステムにおいて、データを送信する送信ステーションから、データを受信する受信ステーションまでの経過時間を計時する経路上の中継器と、上記送信ステーションからのデータと、上記計時した情報とを、上記受信ステーションに通知する通知手段とを有する通信ネットワークシステムである。
【発明の効果】
【００１７】
本発明によれば、ネットワーク上の特定のステーションの時刻情報に基づいて、複数のステーションのプロセスを同期制御することができるので、時刻情報が正確なメディアの配信、機械の制御等を行うことができるという効果を奏する。
【発明を実施するための最良の形態】
【００１８】
発明を実施するための最良の形態は、次の実施例である。
【実施例１】
【００１９】
図１は、本発明の実施例１である通信ネットワークシステム１００を構成するステーション内部におけるネットワークインタフェースブロックの詳細を示す図である。
【００２０】
ネットワークインタフェースブロックは、カウントレジスタ、カウンタヘッダの初期値を保存するカウントレジスタ１０１と、送信用ＦＩＦＯ１０２と、ヘッダ、およびペイロード部分のＣＲＣ３２をＦｒａｍｅＣｈｅｃｋＳｅｑｕｅｎｃｅ（ＦＣＳ）として算出するブロック１０３と、送信ＦＩＦＯ１０２から出力されるヘッダ、ペイロードとともに、ＦＣＳ１０３を付加するフレーム生成ブロック１０４と、ＭＩＩ／ＧＭＩＩインタフェースに変換するブロック１０５とを有する。また、ＰＨＹ１１６を通して通信媒体であるＭＥＤＩＵＭに出力される。
【００２１】
次に、入力側について説明する。
【００２２】
ＭＥＤＩＵＭからＰＨＹ１１６が受信したデータは、ＭＩＩ／ＧＭＩＩ受信インタフェース１０６を通して、フレーム解析ブロック１０７に入力される。フレーム解析の結果、ＦＩＦＯ１０８が、カウントヘッダのカウント値を抽出し、カウンタ１０９に入力される。カウンタ１０９は、残量をカウントした後に、イベントの発生を、内部バス１１５を通じて、ＣＰＵ１１４に通知する。一方、データのその他のヘッダ、ペイロード部分は、受信ＦＩＦＯ１１０に入力され、内部バスへ出力される。
【００２３】
図２は、本発明の実施例１であるネットワークシステムを構成するノード装置の中で、同一ネットワークのステーションを相互に接続するスイッチ装置におけるネットワークインタフェースブロックを示す図である。
【００２４】
このブロックにおいて、スイッチ装置２０１は、任意のＭＡＣから任意のＭＡＣへフレーム単位で情報の交換を行うスイッチ装置であり、第１のＭＡＣブロック２０２と、第１のＰＨＹ２０３と、第２のＭＡＣブロック２０４と、第２のＰＨＹ２０５と、第Ｎ番目のＭＡＣブロック２０６と、第Ｎ番目のＰＨＹ２１２とが設けられている。
【００２５】
ＭＥＤＩＵＭから入力されたフレームは、ＭＩＩ／ＧＭＩＩインタフェースブロック２１３を通して、フレーム解析し、通常のフレームであれば、そのまま受信ＦＩＦＯに入力され、カウンタヘッダ付のフレームが入力された場合、カウンタ値を一意に定まるＩＤ値に書き換えた後に、スイッチ装置２０１に入力される。
【００２６】
カウンタ２１６に分離されたカウンタ値は、スイッチングされている間、カウントを継続する。
【００２７】
次に、スイッチ装置２０１からＭＥＤＩＵＭへ出力される場合、まず、送信ＦＩＦＯ２０７に蓄積された後に、ＩＤ付のフレームであれば、フレーム内のＩＤを符合したカウンタ２１６で計時されたカウント値に付け替え、フレーム生成ブロック２１０に入力される。ここで、再構成されたフレームのＦＣＳ（ＣＲＣ−３２）を再度計算し、その計算結果を新しいＦＣＳとして付け替え、ＭＩＩ／ＧＭＩＩインタフェース２１１を介して、ＰＨＹ２１２へ出力される。
【００２８】
ＭＡＣの他にも、ＰＨＹの状態を監視／制御するＭＤＩＯと呼ばれるインタフェースを制御するために、ＭＤＩＯＲｅｇｉｓｔｅｒ２２０、ＭＤＩＯＣｏｎｔｒｏｌｌｅｒ２１８、ＭＤＩＯＩｎｔｅｒｆａｃｅを介して、各々のＰＨＹがコントロールされる。なお、上記ＭＤＩＯＩｎｔｅｒｆａｃｅは、ＭＤＩＯＣｏｎｔｒｏｌｌｅｒ２１８とＰＨＹ２１２とを接続している線と、ＰＨＹ２０３と２０５とを接続し「ＭＤＩＯ」と記述されている線と、ＰＨＹ２０５と２１２とを接続し「ＭＤＩＯ」と記述されている線とである。
【００２９】
次に、実施例１における上記ネットワークシステムの動作について説明する。
【００３０】
図３は、本実施例におけるネットワークシステムの一構成例を示す図である。
【００３１】
図３に示す構成例において、ネットワーク上にステーションとして、Ｔｅｒｍｉｎａｌ１〜３が接続され、同一ネットワーク内のステーションを相互に接続する手段として、ＳＷ１〜ＳＷ４が使用されている。図３に示す例において、図示していないが、これらのＴｅｒｍｉｎａｌ以外にも、ステーションが存在すると考えてもよい。
【００３２】
図３に示す例において、Ｔｅｒｍｉｎａｌ１から、同期フレームと呼ばれるパケットが各ステーションに出力される。
【００３３】
図４（ａ）は、ＩＥＥＥ８０２．３で定義されているＭＡＣフレーム構造を示す図である。
【００３４】
フレームの最初のフィールドは、Ｐｒｅａｍｂｌｅと呼ばれる物理層に用いられるヘッダであり、フレームの最初を示す６４ｂｉｔの“１”と“０”とが、交互に繰り返されるパターンである（ただし、最後の２ｂｉｔだけは“１１”である）。
【００３５】
次に、４８ｂｉｔ送信元のアドレスを示すＳｏｕｒｃｅＡｄｄｒｅｓｓフィールドであり、続いて、４８ｂｉｔの宛先アドレスであるＤｉｓｔｉｎａｔｉｏｎＡｄｄｒｅｓｓフィールドである。
【００３６】
イーサネット（登録商標）フレームの次のフィールドは、Ｔｙｐｅ／Ｌｅｎｇｔｈフィールドである。ここには、ペイロードの種別または長さ情報が格納されている。Ｔｙｐｅ／Ｌｅｎｇｔｈフィールドに、０ｘ６００（１６進）以上の値が入っているときは、Ｔｙｐｅフィールドとして認識される。
【００３７】
たとえば、上位層にＩＰを使用していれば、０ｘ８００（１６進）が格納される。また、ＶＬＡＮ（ＩＥＥＥ標準８０２．１Ｑ参照）では、０ｘ８１００（１６進）が格納されている（図４（ｂ））。
【００３８】
Ｔｙｐｅフィールドに、０ｘ８１００が設定されると、次の２バイトに、ＶＬＡＮタグ制御情報が入っていることを表し、続いて、ペイロード、ＦＣＳと続く。このＴｙｐｅ／Ｌｅｎｇｔｈフィールドの管理を、米国ＩＥＥＥ８０２委員会が行い、公に使用されているフィールドは、インターネット＜http://standards.ieee.org/regauth/ethertype/type-pub.html＞で知ることができる。
【００３９】
図４（ｃ）は、実施例１における同期フレーム形式を示す図である。
【００４０】
図１に示す通信ネットワークシステム１００によれば、通常のフレーム形式におけるＤｉｓｔｉｎａｔｉｏｎＡｄｄｒｅｓｓと、Ｔｙｐｅ／Ｌｅｎｇｔｈフィールドとが、ＴｘＦＩＦＯ１０２に蓄積され、ｅｖｅｎｔ発生とともに、図４（ｃ）に示すように、ユニークなＣｏｕｎｔｅｒ拡張Ｔａｇを挿入し、これに続いて、Ｃｏｕｎｔｅｒ値を付加する。
【００４１】
このＣｏｕｎｔｅｒ値は、ある時間粒度をもち、送出先のステーションに、指定の時間に、任意のプロセスを実行させるための値である。
【００４２】
さらに、誤り検出符号であるＣＲＣ３２を、フレーム全体に渡って算出し、算出した値を、フレームの最後に付加する。
【００４３】
上記のようにして、送出フレームが作成され、ステーションから発行される。
【００４４】
図３に示す実施例によれば、Ｔｅｒｍｉｎａｌ１から送出されたフレームは、スイッチング装置であるＳＷ２によって受信される。図２に示すスイッチング装置によれば、ＭＥＤＩＵＭから受信されたフレーム情報は、物理層ブロックＰＨＹ（２０３、２０５、２１２等）等で受信され、ＭＡＣブロックに送られる。たとえば、ＭＡＣ−Ｎブロックに送出された場合、フレーム情報のうちで、Ｐｒｅａｍｂｌｅ部が除去された状態で、ＭＡＣ−ＮブロックのＭＩＩ／ＧＭＩＩＲｘＩｎｔｅｒｆａｃｅ２１３で受信され、Ｔｙｐｅ／Ｌｅｎｇｔｈ部等によって、フレーム解析２１４が行われる。
【００４５】
この結果、Ｃｏｕｎｔｅｒ拡張Ｔａｇが付加されている場合、Ｃｏｕｎｔｅｒ値は、Ｃｏｕｎｔｅｒ群２１６のいずれかのＣｏｕｎｔｅｒに保持され、保持されたＣｏｕｎｅｒに対応するＩＤ値を、フレームのＣｏｕｎｅｒ部に付与する。その後に、受信ＦＩＦＯ２１７に一旦保存されたフレームは、ＳＷＦａｂｒｉｃ２０１によって、ＤｉｓｔｉｎａｔｉｏｎＡｄｄｒｅｓｓ先へスイッチングされる。
【００４６】
スイッチング先が、ＭＡＣ−Ｎであれば、送信ＦＩＦＯ２０７に蓄積されているフレーム情報は、ＩＤ符合Ｃｏｕｎｔｅｒ付与ブロック２０８において、Ｃｏｕｎｔｅｒ拡張Ｔａｇを持っているフレームの場合に、ＣｏｕｎｔｅｒＩＤと合致したＩＤを持つＣｏｕｎｔｅｒ値を、ＣｏｕｎｔｅｒＩＤと置換し、フレーム生成部２１０へ送出する。
【００４７】
Ｃｏｕｎｔｅｒ群２１６は、フレームが送受信ＦＩＦＯに蓄積している時間や、ＳＷＦａｂ．に滞留している時間も含めて、Ｃｏｕｎｔｅｒ群をカウントダウンさせているので、これらの時間を正確に計時することができる。
【００４８】
図４（ｃ）に示すように、フレーム情報内のＣｏｕｎｔｅｒ拡張Ｔａｇに続くＣｏｕｎｔｅｒを、Ｃｏｕｎｔｅｒ’に置き換えた後に、ＦＣＳを計算し直した値に更新した後に、ＭＩＩ／ＧＭＩＩＴｘＩｎｔｅｒｆａｃｅ２１１を経由し、フレームの先頭にＰｒｅａｍｂｌｅが付けられてＰＨＹからＭＥＤＩＵＭへ送出される。
【００４９】
ここまでの動作によって、Ｔｅｒｍｉｎａｌ１から送出されたＣｏｕｎｔｅｒ拡張Ｔａｇ付フレームは、ＳＷ２を経由することによって、ＳＷ２で生じた遅延時間Ｄ２が、Ｃｏｕｎｔｅｒに、情報として付加され、スイッチング装置ＳＷ２へ送出される。
【００５０】
これと同様に、Ｔｅｒｍｉｎａｌ１からＴｅｒｍｉｎａｌ３へ、Ｃｏｕｎｔｅｒ拡張Ｔａｇ付フレームを送出した場合、ＳＷ１→ＳＷ２→ＳＷ３を経由し、Ｔｅｒｍｉｎａｌ３へ送出されるので、当初付与されたＣｏｕｎｔｅｒ値から、ＳＷにおける遅延値ＴＤ１２３＝Ｄ１＋Ｄ２＋Ｄ３が減算され、この減算結果を、Ｔｅｒｍｉｎａｌ３が受信する。
【００５１】
また、ネットワークを越えて通信するＴｅｒｍｉｎａｌ１から、Ｔｅｒｍｉｎａｌ４へ、同期フレーム送出する場合、Ｒｏｕｔｅｒを介して、通信されるので、Ｒｏｕｔｅｒでは、ＲｏｕｔｅｒがもつＭＡＣアドレスを、ＳｏｕｒｃｅＡｄｄｒｅｓｓに書き換え、送出する。
【００５２】
Ｒｏｕｔｅｒ内では、スイッチング装置と同様に、Ｌ２ヘッダであるＣｏｕｔｅｒ拡張Ｔａｇの有無を検出し、Ｃｏｕｎｔｅｒ拡張Ｔａｇが検出された場合、ルーティングのためにかかった時間を計時し、ペイロード内のＣｏｕｎｔｅｒ情報を更新し、次のスイッチ装置やルータ装置に送出する。
【００５３】
上記のように、宛先ステーションにおいて受信されたフレーム情報は、物理層ヘッダが、ＰＨＹ１１６によって取り除かれた後に、ＭＩＩ／ＧＭＩＩＲｘＩｎｔｅｒｆａｃｅ１０６において受信され、フレーム解析される。Ｃｏｕｎｔｅｒ拡張Ｔａｇ付ヘッダが確認されると、Ｃｏｕｎｔｅｒ値が抽出され、残りのＣｏｕｎｔｅｒ値が、受信ステーション内のＣｏｕｎｔｅｒにおいて減算される。
【００５４】
指定カウント数になると、ｅｖｅｎｔが受信された旨を、システムに通知し、所望のプロセスを起動することができる。
【００５５】
上記のように、実施例１において、フレーム内に拡張Ｔａｇと拡張Ｔａｇとに付随するＣｏｕｎｔｅｒ値を付加し、さらにフレームの途中経路であるＳＷ／Ｒｏｕｔｅｒから、スイッチング等にかかる遅延時間を減算することによって、同一ネットワーク内において、フレーム送付先のステーションに、フレーム送出元の指定する任意の時間に、特定の処理を行うことを指示することができる。
【実施例２】
【００５６】
図５は、本発明の実施例２であるネットワークシステムの構成例を示す図である。
【００５７】
実施例２は、図３に示すネットワークシステムに、スイッチ装置ＳＷ５と、Ｔｅｒｍｉｎａｌ４とによって構成されるネットワークが追加され、ネットワークを相互に接続するために、Ｒｏｕｔｅｒ１とＲｏｕｔｅｒ２とを使用している。Ｒｏｕｔｅｒ１およびＲｏｕｔｅｒ２はＷＡＮを介して接続されている。これらを接続するネットワーク機器においては図２に示した、本発明の請求項１の概念に基づくノード装置が用いられているものとする。
【００５８】
実施例１と同様に、Ｔｅｒｍｉｎａｌ１からＴｅｒｍｉｎａｌ４へ同期フレームを送出した場合、Ｔｅｒｍｉｎａｌ１とＴｅｒｍｉｎａｌ４は別のネットワークに属するため、Ｔｅｒｍｉｎａｌ１から送出されるヘッダ構成は、Ｌ２ヘッダの宛先ＭＡＣアドレスにおいてはＲｏｕｔｅｒ１のＭＡＣアドレス、Ｌ３ヘッダの宛先ＩＰアドレスにおいてはＴｅｒｍｉｎａｌ４のＩＰアドレスが付与される。Ｒｏｕｔｅｒ同士の通信においても同様の通信がなされ、Ｒｏｕｔｅｒ２はＴｅｒｍｉｎａｌ４の宛先のパケットが到着すると、Ｌ２ヘッダの宛先アドレスをＴｅｒｍｉｎａｌ４のＭＡＣアドレスに書き換えてパケットを送出する。このようにしてＲｏｕｔｅｒを超える通信においては、Ｌ２ヘッダが書き換えられるために、実施例１においてＬ２ヘッダ上に時刻情報を示すようなオプション情報を付与しても、書き換えられてしまう可能性がある。そこでＩＰ−Ｒｏｕｔｅｒを超える必要がある場合、もしくはＩＰ情報を元にスイッチングを行うＬ３スイッチを使用して通信する場合においては、Ｌ３ヘッダ（ＩＰヘッダ）上に時刻情報を付加することで問題点を解決することが出来る。
【００５９】
図６は、Ｌ３ヘッダのオプション情報として時刻情報を付加したフォーマット例である。
【００６０】
図６（ａ）は、代表的なＬ３ヘッダを含んだフレームの例である。Ｌ３ヘッダには様々なＩＰに関する情報が記述されており、その中のＨｅａｄｅｒ  Ｌｅｎｇｔｈ（Ｈ．ｌｅｎ）部にＬ３ヘッダのヘッダ長が記述されている。このヘッダ長を長く定義し直すことでＬ３ヘッダにＣｏｕｎｔｅｒ情報を付加したものが図６（ｂ）である。図６（ｂ）では、Ｈｅａｄｅｒ  ＬｅｎｇｔｈがＣｏｕｎｔｅｒを含んだヘッダ長に書き換えられ、宛先ＩＰアドレスであるＤｉｓｔｉｎａｔｉｏ  ＩＰ  Ａｄｒｓの後に、Ｃｏｕｎｔｅｒ情報として１６ｂｉｔ付加されている。
【００６１】
これらをふまえて、Ｔｅｒｍｉｎａｌ１からＴｅｒｍｉｎａｌ４へ、あるＣｏｕｎｔｅｒ値を付けた同期フレームを出力した場合、まず、Ｒｏｕｔｅｒ１に到着した同期パケットには、Ｔｅｒｍｉｎａｌ１からＲｏｕｔｅｒ１までのＬ２スイッチによる初期のＣｏｕｎｔｅｒ値から、遅延情報［Ｄ１＋Ｄ２］が減算され、更新されたＣｏｕｎｔｅｒ値が、Ｌ２ヘッダに存在している。Ｔｅｒｍｉｎａｌ１が所属しているネットワークのゲートウェイであるＲｏｕｔｅｒ１においては、これまでのＬ２ヘッダ上の遅延情報をＬ３ヘッダ上に載せ替えた上で新しい遅延情報［Ｄ１＋Ｄ２＋ＤＲ１］が減算されたＣｏｕｎｔｅｒ値に更新される。さらに、Ｒｏｕｔｅｒ２では、Ｒｏｕｔｅｒ２までの減算された遅延情報は［Ｄ１＋Ｄ２＋ＤＲ１＋ＤＮＷ］がＬ３ヘッダ上に有り、Ｒｏｕｔｅｒ２での遅延情報［Ｄ１＋Ｄ２＋ＤＲ１＋ＤＮＷ＋ＤＲ２］をＬ２ヘッダに移し替えてＳＷ５あてに送出する。
【００６２】
上記動作により、Ｔｅｒｍｉｎａｌ１から送出された同期パケット出力は、Ｌ２上のＣｏｕｎｔｅｒヘッダ上に遅延情報が書き込まれて、Ｔｅｒｍｉｎａｌ４において受信される。
【００６３】
このようにして、実施例２においては、Ｌ３ヘッダ（ＩＰヘッダ）上に遅延情報を付加することで、ネットワークを超えた通信であった場合においても、遅延情報を扱うレイヤを適宜移動させることにより適切な遅延情報が別ネットワーク間で送信できる。
【図面の簡単な説明】
【００６４】
【図１】本発明の実施例１および実施例２である通信ネットワークシステム１００を構成するステーション内部におけるネットワークインタフェースブロックの詳細を示す図である。
【図２】本発明の実施例１および実施例２であるネットワークシステムを構成するノード装置の中で、同一ネットワークのステーションを相互に接続するスイッチ装置におけるネットワークインタフェースブロックを示す図である。
【図３】本発明の実施例１におけるネットワークシステムの一構成例を示す図である。
【図４】ＩＥＥＥ８０２．３で定義されているフレーム構造および本発明の実施例１および実施例２で使用するフレーム構造を示す図である。
【図５】本発明の実施例２におけるネットワークシステムの一構成例を示す図である。
【図６】本発明の実施例２におけるレイヤ３のパケットフォーマットの例である。
【図７】ＲＴＰにおけるフォーマットを示す図である。
【図８】ＲＳＶＰに使用されるＨｏｓｔとＲｏｕｔｅｒとの構成を示す図である。
【符号の説明】
【００６５】
１００…通信ネットワークシステム、
１０１…カウントレジスタ、
１０２…送信用ＦＩＦＯ、
１０３…ブロック、
１０４…フレーム生成ブロック、
１０５…変換ブロック、
１０６…インタフェース、
１０７…フレーム解析ブロック、
１０８…ＦＩＦＯ、
１０９…カウンタ、
１１０…受信ＦＩＦＯ。
【図１】
2005295100.tif 000003
【図２】
2005295100.tif 000004
【図３】
2005295100.tif 000005
【図４】
2005295100.tif 000006
【図５】
2005295100.tif 000007
【図６】
2005295100.tif 000008
【図７】
2005295100.tif 000009
【図８】
2005295100.tif 000010