(57)【要約】【課題】ＵＤＰのような信頼性のないプロトコルに依存するアプリケーションの頑強性を高めるシステム及び方法を提供する。【解決手段】少数の時間制約型パケットが伝送されるアプリケーションにおいて、ＵＤＰのような信頼性のないプロトコル利用の頑強性を高めるための方法が得られる。この方法は、通信ネットワークに通信可能に結合された複数のデバイスのローカル・クロックを同期させるステップと、前記通信ネットワークを介して、前記複数のデバイスのうちの１つから、信頼性のないプロトコルで、前記１つのデバイスの前記ローカル・クロックを基準とするタイムスタンプを含む、少なくとも１つのデータ・パケットを送信するステップと、定義済みの遅延後、前記通信ネットワークを介して、前記信頼性のないプロトコルで、前記タイムスタンプを含む前記少なくとも１つのデータ・パケットを再送信するステップと、を有する。【選択図】図１
2006081193.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークに通信可能に結合された複数のデバイスのローカル・クロックを同期させるステップと、
前記通信ネットワークを介して、前記複数のデバイスのうちの１つから、信頼性のないプロトコルで、前記１つのデバイスの前記ローカル・クロックを基準とするタイムスタンプを含む、少なくとも１つのデータ・パケットを送信するステップと、
定義済みの遅延後、前記通信ネットワークを介して、前記信頼性のないプロトコルで、前記タイムスタンプを含む前記少なくとも１つのデータ・パケットを再送信するステップと、
を有する方法。
【請求項２】
前記信頼性のないプロトコルが、ユーザ・データグラム・プロトコル（ＵＤＰ）である、請求項１に記載の方法。
【請求項３】
前記送信するステップが、通信ネットワークを介した前記少なくとも１つのデータ・パケットの同報通信するステップを含む、請求項１に記載の方法。
【請求項４】
もう１つの定義済みの遅延後、前記通信ネットワークを介して、前記信頼性のないプロトコルで、やはり前記タイムスタンプを含む前記少なくとも１つのデータ・パケットを再送信するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記同期させるステップが、ＩＥＥＥ１５８８、ネットワークタイムプロトコル（ＮＴＰ）、及び、全地球測位システム（ＧＰＳ）から構成されるグループから選択される１つを利用する、請求項１に記載の方法。
【請求項６】
前記同期させるステップは、前記複数のデバイスが対話して、そのローカル・クロックを能動的に同期させるステップを含む、請求項１に記載の方法。
【請求項７】
前記複数のデバイスの少なくとも１つが、前記送信及び前記再送信から前記少なくとも１つのデータ・パケットを少なくとも１回受信するステップをさらに含む、請求項１に記載の方法。
【請求項８】
前記複数のデバイスの少なくとも１つが、前記少なくとも１つのデータ・パケットを受信して、前記少なくとも１つのデータ・パケットに含まれる前記タイムスタンプ関連した時間依存操作を実施できるか否かを判定するステップをさらに含む、請求項７に記載の方法。
【請求項９】
通信ネットワークに通信可能に結合された複数のデバイスを有し、
前記複数のデバイスのそれぞれが、能動的に同期されたローカル・クロックを含み、
前記複数のデバイスのうちの少なくとも第１のデバイスが、前記通信ネットワークを介して、前記複数のデバイスのうちの少なくとも第２のデバイスに伝達されるメッセージを生成し、
前記複数のデバイスのうちの前記少なくとも第２のデバイスが、前記メッセージを受信し、前記メッセージに応答して、時間依存アクションを実施する働きが可能なアプリケーションを含み、
前記複数のデバイスのうちの前記少なくとも第１のデバイスが、前記生成されたメッセージで、前記複数のデバイスのうちの前記少なくとも第１のデバイスのローカル・クロックを基準とするタイムスタンプを含む、少なくとも１つの信頼性のないプロトコル・データ・パケットを形成し、
前記複数のデバイスのうちの前記少なくとも第１のデバイスが、少なくとも定義済み時間遅延１つ分だけ分離された複数の回数、前記少なくとも１つの信頼性のないプロトコル・データ・パケットを送信する、
システム。
【請求項１０】
前記少なくとも１つの信頼性のないプロトコル・データ・パケットが、ユーザ・データグラム・プロトコル（ＵＤＰ）データ・パケットである、請求項９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ通信に関する。
【背景技術】
【０００２】
インターネット・プロトコル（ＩＰ）を利用した通信ネットワークの場合、多量のデータが、伝送制御プロトコル（Transmission Control Protocol、ＴＣＰ）のような信頼性のある通信プロトコルを利用して伝送される。ＴＣＰは、データ・パケットが最終的に宛先に届くことを保証された「信頼性のある（reliable）」プロトコルとみなされている。その宛先に達する前に、パケットの損失が生じると、そのパケット損失は、宛先ノードによって検出され（送信元と宛先との間におけるハンドシェークの結果として）、従って、宛先ノードは、損失パケットの再送信を要求することができる。例えば、ＴＣＰの場合、最初の送信時に、パケットに番号付けと順序付けが施されるので、再試行または再送信時には、パケットの正しい順序付けが可能になる。ＴＣＰは、通常、テキスト・バイナリ・ファイル転送、及び、リアルタイム転送を必要としない他のタイプのデータの転送に利用される。ファイルがＴＣＰによって伝送される場合、宛先ノードでは、ファイルの全パケットを受信し、ファイルに再アセンブルしてから、ユーザへの（または宛先アプリケーションへの）ファイル提示を開始する。
【０００３】
オーディオ及び／またはビデオ（Ａ／Ｖ）データ（例えば、ボイスオーバＩＰ（voice-over-IP）、映画、音楽、及び、他のタイプのストリーミング・データ）の通信を受信するリアルタイム・アプリケーションのような高速アプリケーションの場合、データは、一般に、ユーザ・データグラム・プロトコル（User Datagram Protocol、ＵＤＰ）のような信頼性のないプロトコルを利用する通信ネットワークを介して伝送される。ＵＤＰは、伝送中に失われたデ−タ・パケット（「データグラム（datagram）」とも呼ばれる）の再試行または再送信が行われないので、「信頼性のない（non-reliable）」プロトコルと呼ばれる。すなわち、本明細書において用いられる限りにおいて、信頼性にかけるプロトコルとは、パケット損失の有無を検出するため、送信元と宛先の間でハンドシェークが実施されないプロトコルを表わしている。ＵＤＰの場合、ハンドシェークは実施されず、（その宛先に届かない）損失パケットの再送信が後で実施されることもない。従って、ＵＤＰは、信頼性のないプロトコルの一例である。ＵＤＰが利用される大部分のストリーミング・メディア・アプリケーションでは、損失ＵＤＰデータ・パケットをすぐ後で再送信すると、受信者によるデータ再生の結果は、順序が狂ったビデオまたはオーディオ・フレームでとごちゃまぜになる可能性がある。
【０００４】
一般に、ＵＤＰは、ＩＰネットワークのコンピュータ間におけるメッセージの交換時に、制限された量のサービスを提供する通信プロトコルである。ＴＣＰと同様、ＵＤＰは、インターネット・プロトコルを利用して、実際に、１つのコンピュータから別のコンピュータにデータ・パケットを送り届ける。しかし、ＴＣＰとは異なり、ＵＤＰでは、メッセージをパケットに分割し、そのもう一方の端部で再アセンブルするサービスが得られない。すなわち、ＵＤＰでは、データの到着形態であるパケットの順序付けが行えない。ＵＤＰが一般に利用されるのは、多量のデータが宛先に伝送され、宛先のアプリケーションにおいて、こうした全データの受信前に、データ再生の開始が望まれる場合である。ＵＤＰは、一般に、通信ネットワークによるデータの同報通信が望まれる場合にも用いられる。
【０００５】
クライアントに情報を提供するためのテクノロジのうち、ますます人気が高まっているタイプは、「ストリーミング・メディア」として知られるものである。ストリーミング・メディアは、データ・パケットの伝送にＵＤＰのような信頼性のないプロトコルが一般に利用されるアプリケーションの１つである。ストリーミング・メディアは、コンピュータ技術において周知のテクノロジである。一般に、ストリーミング・メディアは、ストリーミング方式または連続方式でクライアントにデータ（例えば、一般にオーディオ及び／またはビデオ）を提示する。すなわち、クライアントは、提示の開始前に、提示する情報を全て受信する必要がなくなる。それどころか、ストリーミング・メディア・ファイルによる情報の提示は、クライアントが全ファイルを受信する前に開始することが可能であり、受信したファイルの一部を提示しながら、ファイルの後続部分がクライアントによって受信され、後続の提示に備えることになる。従って、ストリーミング・メディアには、サーバ（メディア・サーバ）からクライアントに伝送され、完全にダウンロードする前にクライアントにおける再生が開始されるメディア（例えば、一般にはオーディオ及び／またはビデオ）が含まれる。
【０００６】
ストリーミング・メディアは、サーバからクライアントへのオーディオ及び／またはビデオ・ファイルの伝達にとりわけ人気のある技法である。オーディオ及び／またはビデオ・ファイルは、圧縮後においても極めて大きい傾向にある。ストリーミング・メディアを利用しなければ、一般に、クライアントによるファイルの再生が可能になる前に、全てのファイルをクライアントにダウンロードする（例えば、ＴＣＰによって）ことが必要になる。こうしたダウンロードは、クライアントによるファイルの再生が可能になる前に、望ましくないほどの長い遅延を必要とする可能性がある。ストリーミング・メディア（例えば、ストリーミング・オーディオまたはストリーミング・ビデオ）を用いると、クライアントは、全ファイルのダウンロードが済むまで、再生を待つ必要はない。むしろクライアントは、ダウンロードしながら、ファイルの再生を開始する（例えば、ビデオ及び／またはオーディオをユーザに提示する）ことが可能になる。
【０００７】
ストリーミング・メディア・アプリケーションでは、一般に、ＵＤＰを利用してデータ・パケット・ストリームの通信が行われる。上述のようにＵＤＰでは、間違った配置または他の問題が生じると、ＴＣＰのようにパケットの再送信が続けられないが、これは、ほとんどのストリーミング・メディア・テクノロジにとって望ましい。ＵＤＰは、ＩＰネットワークを介して既存のテレビ局及びラジオ局からの番組の送信のような、データの放送送信に用いられることが多い。
【０００８】
上述のように、ＵＤＰは信頼性のないプロトコルであり、従って、ＴＣＰとは異なり通信ネットワークを介して送られるＵＤＰパケットの宛先への到達が保証されない。ＵＤＰの目的とする用途は、ネットワークを介して多数のパケットを高速で送ることであるため、その信頼性の欠如（ハンドシェークの欠如）は、一般に、その対象とするアプリケーションにおいて問題にはならない。受信デバイスは、信号処理技術によって情報を「充填」することが可能な場合が多い（ボイスオーバＩＰの場合のように）。各パケット毎にシーケンス番号を含めることにより、ＵＤＰ通信の信頼性を向上させるいくつかの技法が提案されている。従って、宛先ノードは、パケットの受信を開始すると、シーケンス番号を利用してある特定のパケットの受信を確認することができ、シーケンス番号によって損失パケットの再送信を要求することが可能である。
【０００９】
しかし、上記技法は、伝送されるパケットが少ない状況ではうまく機能しない。例えば、単一ＵＤＰパケットが伝送される場合、対象とする受信側には、パケットの到着時間について、あるいは、そもそもパケットを期待して待つべきか否かさえ、知る術がない。ＵＤＰパケット損失は、バッファのオーバフロー問題によって、「爆発的」に生じる傾向があるので、同じことが少数のＵＤＰパケットに当てはまる。
【００１０】
アプリケーションによっては、ＵＤＰによって高速能力が得られるため、ＵＤＰを利用したデータ通信を望むものもあり得るが、少数のパケットしか伝達できない。上記に鑑みて、少数のパケット通信しか行えない状況でも、頑強性を向上させることが可能な、ＵＤＰによる通信の頑強性（robustness）を向上させるための技法が求められている。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、ＵＤＰのような信頼性のないプロトコルに依存するアプリケーションの頑強性を高めるシステム及び方法を提供することにある。
【課題を解決するための手段】
【００１２】
さらに後述するように、少なくとも１つの実施態様によれば、少数の時間制約型パケットが伝送されるアプリケーションにおいて、ＵＤＰのような信頼性のないプロトコル利用の頑強性を高めるための方法が得られる。例えば、ネットワーク上のデバイスの調整をとるシステムにおいて、ネットワーク上のデバイスは、それ自体関する情報を他のデバイスに同報通信する（broadcast）ことが可能である。受信側デバイスは、同報通信情報の受信に応答して、時間制約型アクションを行うことが可能である。例えば、それぞれ、少数のパケットにカプセル化することが可能なＵＤＰメッセージの伝達は、個々のデバイスのアクションの調整／同期に頼ることが可能である。後述するさまざまな実施態様によれば、信頼性のないプロトコルによるデータ・パケットの冗長再送信と、信頼性のないプロトコルによるデータ・パケットに組み込まれるタイムスタンプを組み合わせて利用することによって、信頼性のないプロトコルによるデータ・パケット通信に依存するアプリケーションの頑強性が向上する。
【００１３】
実施態様例の１つでは、複数のデバイスが、通信ネットワークに通信可能に結合されている。デバイスは、それぞれ、ローカル・クロックを備えており、ローカル・クロックは、同期がとられている。デバイスのうち第１のデバイスが、少なくとも１つの定義済み時間遅延によって分離された複数の回数、通信ネットワークを介してＵＤＰデータ・パケットの通信を行うが、この場合、ＵＤＰデータ・パケットが伝送される複数時間のそれぞれにおいて、ＵＤＰデータ・パケットには、第１のタイムスタンプが組み込まれる。従って、ＵＤＰデータ・パケットの冗長再送信が利用されるが、この場合、ＵＤＰデータ・パケットの最初の送信が実施され、次に、所定の時間遅延後の、少なくとも１つの追加時間に再送信が実施される。
【００１４】
ＵＤＰデータ・パケットの各伝送毎に、例えば、送信側デバイスのローカル・クロックを基準にしてＵＤＰデータ・パケットの最初の伝送が生じた時間に対応することが可能なタイムスタンプが組み込まれる。受信側デバイスは、少なくとも１回ＵＤＰデータ・パケットを受信してタイムスタンプを評価し、受信したＵＤＰデータ・パケットに応答して、時間依存型アクションを実施可能であるか否かを判定する。
【００１５】
少なくとも１つの実施態様によれば、通信ネットワークに通信可能に結合された複数のデバイスのローカル・クロックを同期させるステップを含む方法が得られる。この方法には、さらに、通信ネットワークを介して、複数のデバイスの１つから、信頼性のないプロトコルによる少なくとも１つのデータ・パケットを送るステップが含まれているが、この場合、少なくとも１つのデータ・パケットには、少なくとも１つのパケットを送リ出すデバイスのローカル・クロックに基づくタイムスタンプが組み込まれている。この方法には、さらに、定義済みの遅延後、通信ネットワークを介して、信頼性のないプロトコルによる少なくとも１つのデータ・パケットを再送するステップも含まれているが、この場合、少なくとも１つのデータ・パケットには、やはり、タイムスタンプが組み込まれている。
【００１６】
以上は、下記の本発明の詳細な説明のより明確な理解が得られるように、本発明の特徴及び技術的利点についてかなり大まかに概説したものである。本発明の請求の範囲の内容をなす、本発明のさらなる特徴及び利点については、後述することにする。開示の概念及び特定の実施態様が、本発明と同じ目的を実施するための他の構造の修正または設計を行う基礎として容易に利用可能であることは明らかである。やはり、当然明らかなように、こうした同等構成は、付属の請求の範囲に記載の本発明から逸脱するものではない。その構成及び動作方法の両方に関して、本発明に特有のものであると思われる新規の特徴、並びに、さらなる目的及び利点については、添付の図面に関連づけて検討すれば、下記の説明からより明確な理解が得られるであろう。ただし、明確に理解しておくべきは、図のそれぞれは、例証及び解説のためだけに提示されており、本発明の限界を定義することを意図したものではないという点である。
【００１７】
次に、本発明のより完全な理解が得られるように、添付の図面に関連してなされる下記の説明に言及することにする。
【発明を実施するための最良の形態】
【００１８】
上述のように、アプリケーションによっては、信頼性のないプロトコルによって高速及び／または同報通信機能が得られるため、ＵＤＰのような信頼性のないプロトコルを利用したデータ通信が求められる場合もある。さらに、アプリケーションの中には、ある特定のＵＤＰメッセージにおける少数のパケットの通信しか行わないものもあり得る。一例を挙げると、測定システムは、正確な測定結果の取得を可能にするため、いくつかのデバイスの動作を適正なやり方で同期させる（または調整する）ことが必要とされる場合が多い。例えば、スペクトル・アナライザは、信号源がその出力周波数の整定に十分な機会を得た後で、測定を行うように調整するのが望ましい。その開示が、参考までに本明細書において援用され、同時に提出されて譲渡先が共通の、「ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＹＮＣＨＲＯＮＩＺＩＮＧ  ＯＰＥＲＡＴＩＯＮＳ  ＯＦ  Ａ  ＰＬＵＲＡＬＩＴＹ  ＯＦ  ＤＥＶＩＣＥＳ  ＶＩＡ  ＭＥＳＳＡＧＥＳ  ＯＶＥＲ  Ａ  ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＮＥＴＷＯＲＫ」と題する米国特許出願（代理人整理番号１００４１３２９−１）にさらに解説されているように、メッセージは、計器のそれぞれの動作を同期させるため、ＵＤＰを利用し、通信ネットワークを介して、測定システムのさまざまな計器間においてやりとりすることが可能である。同期に用いられるメッセージのそれぞれは、ほんのわずかなパケットで伝送することが可能である（実施例によっては、１パケットだけの場合もある）。さまざまな計器の動作を同期させる上記アプリケーションの場合、メッセージは、時間制約型のため、ＵＤＰは魅力のあるプロトコルである。さらに、「ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＹＮＣＨＲＯＮＩＺＩＮＧ  ＯＰＥＲＡＴＩＯＮＳ  ＯＦ  Ａ  ＰＬＵＲＡＬＩＴＹ  ＯＦ  ＤＥＶＩＣＥＳ  ＶＩＡ  ＭＥＳＳＡＧＥＳ  ＯＶＥＲ  Ａ  ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＮＥＴＷＯＲＫ」と題する米国特許出願（代理人整理番号１００４１３２９−１）にさらに解説されているように、実施態様によっては、メッセージが通信ネットワークで複数の計器に対して同報通信される場合もあり、ＵＤＰはメッセージの同報通信に利用可能であるため魅力的である。しかし、さまざまな計器の同期がＵＤＰメッセージの受信によって左右されるので、ＵＤＰの頑強性を向上させることは望ましい。
【００１９】
本明細書では、ＵＤＰのような信頼性のないプロトコルに依存するアプリケーションの頑強性を向上させるための方法が提示される。さらに後述するように、本明細書に開示のいくつかの実施態様によれば、いくつかの事例において信頼性が向上する。さらに、それらの実施態様によれば、対象とする受信側が、パケットによってトリガされるように意図した時間依存処理を実施するための十分な時間内に、パケットの受信にいつ失敗したかを検出できるようにするエラー検出も可能になる。従って、この信頼性の向上とエラー検出によって、頑強な解決法が得られる。
【００２０】
ＵＤＰの信頼性を高めようとした先行技法は、ビデオまたは音声アプリケーションにおいて用いられるような、多数のパケットのＵＤＰ伝送を対象としたものであるが、本明細書に開示の方法は、ＵＤＰ伝送されるのがわずか数パケットにすぎないアプリケーションに有効である。もちろん、本明細書に提示の方法は、多数のパケットに関するＵＤＰ伝送の頑強性を向上させるために利用することも可能である。本明細書に記載の方法は、「ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＹＮＣＨＲＯＮＩＺＩＮＧ  ＯＰＥＲＡＴＩＯＮＳ  ＯＦ  Ａ  ＰＬＵＲＡＬＩＴＹ  ＯＦ  ＤＥＶＩＣＥＳ  ＶＩＡ  ＭＥＳＳＡＧＥＳ  ＯＶＥＲ  Ａ  ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＮＥＴＷＯＲＫ」と題する米国特許出願（代理人整理番号１００４１３２９−１）に開示のような、計器の動作を同期させるためのメッセージの伝送に用いられる場合に、ＵＤＰの頑強性を高めるのにとりわけ有効である。しかし、本明細書に解説のＵＤＰの頑強性を高めるための方法は、データの伝送にＵＤＰが求められる他のアプリケーションにも同様に適用することが可能である。さらに、ＵＤＰは、本明細書に解説の特定の実施態様例に用いられるが、提示の方法は、損失パケットの検出のため、ハンドシェークを行わない他の信頼性のないプロトコルにも容易に拡張することが可能である。
【００２１】
さらに後述するように、少なくとも１つの実施態様によれば、少数の時間制約型パケットが伝送されるアプリケーションにおいてＵＤＰの頑強性を高めるための方法も得られる。例えば、ネットワーク上のデバイスを調整するシステムにおいて、ネットワーク上のデバイスは、それ自体に関する情報を他のデバイスに同報通信することが可能である。この情報は、時間制約型とすることが可能である。ＵＤＰプロトコルは、ネットワークにおける効率の良い情報の同報通信に利用できるので（ＴＣＰのような２地点間チャネルとは対照的に）、この目的にとって適切な選択である。受信側デバイスは、情報を確実に受信する必要があり、迅速に受信する必要がある。さらに、パケットの全てが失われる場合、対象とする受信側がこのエラーを検出する必要がある。伝送されるパケット数が少ないので、パケットが多数の場合にうまく機能する上述の先行方法では、役に立たない。従って、伝達されるパケットがほんのわずかしかない状況でも、信頼性の向上及び／またはエラー検出を可能にする、ＵＤＰを介した通信の頑強性を高めるための方法が提供される。
【００２２】
後述のさまざまな実施態様によれば、ＵＤＰデータ・パケットの冗長再送信と、ＵＤＰデータ・パケットに組み込まれるタイムスタンプを組み合わせて利用することによって、ＵＤＰの頑強性が向上する。実施態様例の１つでは、複数のデバイスが、通信ネットワークに通信可能に結合されている。デバイスは、それぞれ、ローカル・クロックを備えており、ローカル・クロックは、同期がとられている。デバイスのうち第１のデバイスが、少なくとも１つの定義済み時間遅延によって分離された複数の回数、通信ネットワークを介してＵＤＰデータ・パケットの通信を行うが、この場合、ＵＤＰデータ・パケットが伝送される複数時間のそれぞれにおいて、ＵＤＰデータ・パケットには、第１のタイムスタンプが組み込まれる。従って、ＵＤＰデータ・パケットの冗長再送信が利用されるが、この場合、ＵＤＰデータ・パケットの最初の送信が実施され、次に、所定の時間遅延後の少なくとも１つの追加時間に再送信が実施される。一例として、ＵＤＰデータ・パケットの最初の送信を行い、１ミリ秒（ｍｓｅｃ）の遅延後の第２の時間に再送信を行い、さらに、１０ｍｓｅｃの遅延後の第３の時間に再送信を行うことが可能である。
【００２３】
ＵＤＰデータ・パケットの各伝送毎に、送信側デバイスのローカル・クロックを基準にして、ＵＤＰデータ・パケットの最初の伝送が生じた時間に対応することが可能なタイムスタンプが組み込まれる。受信側デバイスは、少なくとも１回ＵＤＰデータ・パケットを受信して、タイムスタンプを評価し、受信したＵＤＰデータ・パケットに応答して、時間制約型アクションを実施可能であるか否かを判定する。例えば、ＵＤＰデータ・パケットによってその受信側がトリガされ、ＵＤＰデータ・パケットに含まれるタイムスタンプから１０ｍｓｅｃ後に測定を実施するものと仮定する。この例では、受信側及び送信側のローカル・クロックの同期がとれている点に留意されたい。従って、例えば、メッセージに含まれるタイムスタンプの１ｍｓｅｃ後に、ＵＤＰデータ・パケットの最初の送信を受信する場合、受信側はこの時間依存測定を実施することが可能である。ＵＤＰデータ・パケットの最初の送信を受信せず、代わりに、例えば、メッセージに含まれるタイムスタンプの２ｍｓｅｃ後に、ＵＤＰデータ・パケットの第２の送信を受信する場合、受信側では、それでも、この時間依存測定を実施することが可能である。従って、信頼性が向上することになる。さらに、ＵＤＰデータ・パケットの最初の送信も第２の送信も受信せず、代わりに、例えばメッセージに含まれるタイムスタンプの１１ｍｓｅｃ後にＵＤＰデータ・パケットの第３の送信を受信する場合、受信側は、メッセージに含まれるタイムスタンプから１０ｍｓｅｃ後にその測定をトリガすることはできない。しかしこの場合、受信側は、測定の要求に気づかない場合とは違い、エラーをトリガすることが可能である。従って、この少数パケット（例えば、１パケット）を利用する場合の、エラー検出が改善される。
【００２４】
図１を参照すると、この例の場合、ＵＤＰである信頼性のないプロトコルの頑強な利用のための実施態様の１つによるシステム例１０が示されている。システム例１０には、ローカル・エリア・ネットワーク（ＬＡＮ）、インターネットまたは他の広域ネットワーク（ＷＡＮ）、公衆交換電話網（ＰＳＴＮ）、無線ネットワーク、上記の任意の組み合わせ、及び／または、現在知られているか、または、今後開発されることになる、少なくとも１つのデバイスから少なくとも１つの他のデバイスへの情報伝達のための他の任意のネットワークとすることが可能な通信ネットワーク１３を介して通信可能に結合された、第１のデバイス１１（デバイスＡ）と第２のデバイス１２（デバイスＢ）が含まれている。
【００２５】
第１のデバイス１１及び第２のデバイス１２のそれぞれには、中央演算処理デバイス（ＣＰＵ）（図示せず）を含むことが可能である。さらに、第１のデバイス１１及び第２のデバイス１２のそれぞれには、この例の場合、同期のとれたローカル・クロックが含まれている。ネットワーク化デバイスのクロックを高い精度で同期させるためのさまざまな技法が知られている。一例として、ネットワークタイムプロトコル（Network Time Protocol、ＮＴＰ）は、コンピュータ・ネットワークにおけるコンピュータ・クロック時間の同期に用いられるプロトコルである。同様のプロトコルと同じように、ＮＴＰは協定世界時（Coordinated Universal Time、ＵＴＣ）を利用して、１ミリ秒以内まで、場合によっては、何分の１ミリ秒以内まで、コンピュータ・クロック時間を同期させる。もう１つの例として、電気電子技術者協会規格協会（ＩＥＥＥ−ＳＡ）によって、ＩＥＥＥ１５８８「ネットワーク化測定及び制御システムのための精密同期プロトコルに関する規格」と呼ばれる、ネットワークにおけるクロック間の同期性を維持するための新規の規格が承認されている。一般に、このＩＥＥＥ１５８８規格では、クロックを同期状態に保つため、ネットワーク化デバイス間におけるタイミング情報の交換に利用することが可能なメッセージが定義されている。ＩＥＥＥ１５８８規格によれば、ＮＴＰによって得られるよりいっそう高精度の（例えば、１マイクロ秒以内までの）クロック同期が可能になる。ＮＴＰまたはＩＥＥＥ１５８８のような技法を利用する場合、デバイスが互いに対話して、用いられる特定の同期技法に従ってそれぞれのローカル・クロックを同期のとれた状態に維持するので、デバイスのローカル・クロックは、「能動的に同期された」と称される。代替実施態様の場合、ＧＰＳ（全地球測位システム）受信器等を用いてローカル・クロックを同期させる、他の技法（例えば、受動技法）を用いることも可能である。
【００２６】
図１のこの特定の例ではＩＥＥＥ１５８８が利用されており、第１のデバイス１１はＩＥＥＥ１５８８クロック１０１Ａを使用し、第２のデバイス１２はＩＥＥＥ１５８８クロック１０１Ｂを使用している。もちろん、他の実施例では、ＮＴＰを用いるといったように、ローカル・クロックを能動的に同期させるための他の技法を用いることもできるし、あるいは、ローカル・クロックを受動的に同期させるための他の技法（例えば、ＧＰＳ）を用いることも可能である。従って、第１のデバイス１１及び第２のデバイス１２は、共通時間感覚を備えるように、ローカル・クロック１０１Ａ及び１０１Ｂに高精度の同期が施される。
【００２７】
この例の場合、メッセージは、この例ではＵＤＰである、信頼性のないプロトコル１４を利用し、通信ネットワーク１３を介して第１のデバイス１１から伝送される。この例の場合、メッセージは、２つのＵＤＰパケットのような少数のＵＤＰによって形成される。実施例によっては、メッセージが、単一ＵＤＰパケットによって形成される場合もある。この例の送信技法では、まず、第１のＵＤＰパケット（UDP Packet１）１０２Ａの送信が実施され、これには、タイムスタンプＡが含まれている。タイムスタンプＡは、第１のデバイス１１のローカル・クロック１０１Ａを基準にしており、例えば、ＵＤＰパケット１０２Ａを送信する時間とすることが可能である。その後、第１の遅延（遅延Ａ）１０４Ａを生じ、第１のデバイス１１は、こうした遅延時間を待機した後、第１のＵＤＰパケットを再送信する。ＵＤＰパケット損失は、まとまって生じる傾向があるので、時間間隔をあまりに密にして送信すると、多数のパケットが全て失われることになる。従って、時間遅延Ａ１０４Ａが、UDP Packet１の最初の送信１０２ＡとUDP Packet１の第２の送信１０２Ｂとの間に挿入される。
【００２８】
遅延Ａ１０４Ａの後、パケット１０２Ｂとして示され、やはりタイムスタンプＡを含むUDP Packet１が再送信される。留意すべきは、UDP Packet１の最初の送信１０２ＡとUDP Packet１の第２の送信１０２Ｂの両方に、同じタイムスタンプ（タイムスタンプＡ）が含まれているという点である。その後、第２の遅延（遅延Ｂ）１０４Ｂを生じ、第１のデバイス１１は、こうした遅延時間を待機した後、第１のＵＤＰパケットの３回目となる再送信が行われる。遅延Ｂ１０４Ｂは、遅延Ａ１０４Ａと同じ遅延量とすることもできるし、あるいは、異なる遅延量として定義することも可能である。さらに、この例では、UDP Packet１は全部で３回送信されるが、ＵＤＰデータ・パケットの冗長送信回数は、この特定の例に制限されるものではない。それどころか、代替実施例では、UDP Packet１は、各送信間に遅延を挟んで、２回以上送信することが可能である。
【００２９】
図１の特定の例の場合、遅延Ｂ１０４Ｂの後、パケット１０２Ｃとして示され、やはりタイムスタンプＡを含むUDP Packet１が再送信される。留意すべきは、UDP Packet１の送信１０２Ａ〜１０２Ｃの全てに、同じタイムスタンプ（タイムスタンプＡ）が含まれているという点である。その後、まず、第２のＵＤＰパケット（UDP Packet２）１０３Ａが送信されるが、これには、タイムスタンプＢが含まれている。タイムスタンプＢは、第１のデバイス１１のローカル・クロック１０１Ａを基準にしており、例えば、ＵＤＰパケット１０３Ａを送信する時間とすることが可能である。実施例によっては、タイムスタンプＢは、タイムスタンプＡと異なる場合もあるし、一方、他の実施例では、タイムスタンプＡとＢが同じという場合もある。例えば、タイムスタンプＢは、第１のＵＤＰパケット（UDP Packet１）の最初の送信時とすることが可能である。その後、第１の遅延（遅延Ａ）１０５Ａを生じ、第１のデバイス１１は、こうした遅延時間を待機した後、第２のＵＤＰパケットを再送信する。図１には示されていないが、第２のＵＤＰパケットは、第１のＵＤＰパケットについて特に図示され、解説されているように、１回以上再送信することが可能である。
【００３０】
実施例によっては、第２のＵＤＰデータ・パケットの最初の送信前に、第１のＵＤＰデータ・パケットの再送信の全てが実施される必要のないものもある。例えば、図２には、この例の場合ＵＤＰである信頼性のないプロトコルの頑強な利用のための実施態様の１つによるシステム例１０Ａが示されている。システム例１０Ａには、やはり、通信ネットワーク１３を介して通信可能に結合され、それぞれ、ＩＥＥＥ１５８８による同期のとれたクロック１０１Ａ及び１０１Ｂを導入した、第１のデバイス１１及び第２のデバイス１２が含まれている。
【００３１】
図２のこの例の場合、メッセージは、この例ではＵＤＰである信頼性のないプロトコル１４を用いて、通信ネットワーク１３を介して第１のデバイス１１から伝送される。この例の場合、メッセージは、２つのＵＤＰパケットによって形成される。図２の伝送技法例の場合、まず、第１のＵＤＰパケット（UDP Packet１）１０２Ａの送信が実施され、これには、タイムスタンプＡが含まれている。タイムスタンプＡは、第１のデバイス１１のローカル・クロック１０１Ａを基準にしており、例えば、ＵＤＰパケット１０２Ａを送信する時間とすることが可能である。その後、第１の遅延（遅延Ａ）１０４Ａを生じ、第１のデバイス１１は、こうした遅延時間を待機した後、第１のＵＤＰパケットを再送信する。上述のように、ＵＤＰパケット損失はまとまって生じる傾向があるので、時間間隔をあまりに密にして送信すると、多数のパケットが全て失われることになる。従って、時間遅延Ａ１０４Ａが、UDP Packet１の最初の送信１０２ＡとUDP Packet１の第２の送信１０２Ｂとの間に挿入される。
【００３２】
遅延Ａ１０４Ａの後、パケット１０２Ｂとして示され、やはりタイムスタンプＡを含むUDP Packet１が再送信される。留意すべきは、UDP Packet１の最初の送信１０２ＡとUDP Packet１の第２の送信１０２Ｂの両方に、同じタイムスタンプ（タイムスタンプＡ）が含まれているという点である。その後、第２の遅延（遅延Ｂ）１０４Ｂを生じ、第１のデバイス１１は、こうした遅延時間を待機した後、第１のＵＤＰパケットの３回目となる再送信が行われる。遅延Ｂ１０４Ｂは、遅延Ａ１０４Ａと同じ遅延量とすることもできるし、あるいは、異なる遅延量として定義することも可能である。この例の場合、遅延Ｂ１０４Ｂの間に、まず、第２のＵＤＰパケット（UDP Packet２）１０３Ａの送信が実施され、これには、タイムスタンプＢが含まれている。タイムスタンプＢは、第１のデバイス１１のローカル・クロック１０１Ａを基準にしており、例えば、ＵＤＰパケット１０３Ａを送信する時間とすることが可能である。実施例によっては、タイムスタンプＢは、タイムスタンプＡと異なる場合もあるし、一方、他の実施例では、タイムスタンプＡ及びＢが同じという場合もある。例えば、タイムスタンプＢは、第１のＵＤＰパケット（UDP Packet１）の最初の送信時とすることが可能である。その後、第１の遅延（遅延Ａ）１０５Ａを生じ、第１のデバイス１１は、こうした遅延時間を待機した後、第２のＵＤＰパケットを再送信する。
【００３３】
遅延Ａ１０５Ａの間に、パケット１０２Ｃとして示されたUDP Packet１が再送信され、これには、やはり、タイムスタンプＡが含まれている。留意すべきは、UDP Packet１の送信１０２Ａ〜１０２Ｃの全てに同じタイムスタンプ（タイムスタンプＡ）が含まれているという点である。その後、パケット１０３Ｂとして示された第２のＵＤＰパケット（UDP Packet２）が送信されるが、これには、やはり、タイムスタンプＢが含まれている（実施例によっては、タイムスタンプＡと同じであってもよい）。図２には示されていないが、第２のＵＤＰパケットは、第１のＵＤＰパケットについて特に図示され、解説されているように、１回以上再送信することが可能である。
【００３４】
次に図３を参照すると、やはりシステム１０が示されており（図１のシステム１０または図２のシステム１０Ａとすることが可能である）、第２のデバイス１２が、１つ以上の冗長送信された第１のＵＤＰパケット（UDP Packet１）を受信する。もちろん、第２のＵＤＰパケットの通信が、図１及び図２の上記例のように実施される場合、第２のＵＤＰパケットの１つ以上がデバイス１２によって同様に受信されることになる。デバイス１２には、パケットを受信すると、パケットに含まれるタイムスタンプとローカル時間（ＩＥＥＥ１５８８クロック１０１Ｂによって確認される）を比較するＵＤＰパケット・マネージャ３０１が含まれている。この結果、パケットの到達に要する時間量の極めて正確な推定値が得られる。ＵＤＰパケット・マネージャ３０１には、各パケット毎に「時間切れ」の再プログラミングを施すことが可能である。時間切れ期間は、パケットによって識別される事象のような、パケットの他の内容に従って変動する可能性がある。測定時間が時間切れ期間を超えると、ＵＤＰパケット・マネージャ３０１は、エラーとみなし、適切な措置を講じることが可能である。さらに、最初に送信されたＵＤＰパケットの１つを受信すると、ＵＤＰパケット・マネージャ３０１は、こうした最初のＵＤＰパケットに後続する冗長ＵＤＰパケットの受信を無視することが可能である。
【００３５】
図１〜３の方法例は、冗長送信及びタイムスタンピングの両方に依存して、信頼性のないプロトコル通信に依存したアプリケーションの頑強性を向上させる。タイムスタンピングについては、ネットワークデバイスにおいて、ＩＥＥＥ１５８８または同様の高精度クロック同期方式が実施される。
【００３６】
損失ＵＤＰパケットを直接検出または回復する方法はないので、全てのＵＤＰパケットが複数回数にわたって送信される。しかし、上記例の場合、ＵＤＰパケットの損失はまとまって生じる傾向があるため、すぐには再送信が行われず、従って、時間間隔をあまりに密にして送信すると、多数のパケットが全て失われることになる。代わりに、各パケット送信間に、時間遅延が挿入される。適正な時間遅延は、生じる再送信回数のように、アプリケーションによって決まる。例えば、ＵＤＰパケットを１ｍｓｅｃ後に再送信し、さらに、１０ｍｓｅｃ後に再送信することも可能である。通信ネットワークにおけるトラフィックの量が多い場合には、より多くの再送信が必要になる可能性がある。受信デバイスは複数回数にわたって到着するパケットを無視することが可能であるが、とりわけ、マルチキャストの場合、ＵＤＰパケットは、いくつかの異なる経路を介して受信デバイスに到達する可能性が多いので、ＵＤＰパケットの受信側は、ともかく、この機能を備えているのが一般的である。
【００３７】
各パケットは、タイムスタンプを備えている。上記の例では、ＩＥＥＥ１５８８プロトコルを用いて、システム内の全てのクロックを同期させ、各ＵＤＰパケット毎に、タイムスタンプも生成する。パケットを受信すると、受信側デバイスユニットは、パケットに含まれるタイムスタンプとローカル時間（受信側デバイスのＩＥＥＥ１５８８クロックによって確認される）を比較する。この結果、パケットの到達に要する時間量の極めて正確な推定値が得られる。受信側デバイスユニットには、各パケット毎に「時間切れ」の再プログラミングを施すことが可能である。（時間切れ期間は、パケットの他の内容に従って変動する可能性がある。）測定時間が時間切れ期間を超えると、受信側は、エラーとみなして適切な措置を講じることが可能である。
【００３８】
発信源がその周波数を変化させて、受信側にメッセージを送り、受信側をトリガして、メッセージに含まれるタイムスタンプの１０ｍｓｅｃ後に測定を実施させる下記の例について考察することにする。すなわち、発信源デバイスは、その周波数の変更後に、その周波数変更時のタイムスタンプを含むメッセージを送ることが可能である。このメッセージには、さらに、１番事象の識別子が含まれている。受信側には、１番事象を識別するメッセージの受信に応答して、こうしたメッセージに含まれるタイムスタンプの１０ｍｓｅｃ後に発信源の信号の測定を実施するようにプログラムされている（その結果、変更周波数の整定後に測定が実施されることになる）。さらに、発信源によって、１番事象を識別するメッセージと、単一ＵＤＰパケットにおいてその周波数を変更した時点のタイムスタンプが送られるものと仮定する。
【００３９】
この例の場合、発信源によって、ＵＤＰデータ・パケットの最初の送信が行われ、１ミリ秒（ｍｓｅｃ）の遅延後に、２回目となる再送信が行われ、さらに、１０ｍｓｅｃの遅延後に、３回目となる再送信が行われる。ＵＤＰデータ・パケットの各送信毎に、発信源のローカル・クロックを基準にした、発信源がその周波数を変更した時点のタイプスタンプが含まれる。受信側は、ＵＤＰデータ・パケットを少なくとも１回受信し、このＵＤＰデータ・パケットの最初の受信時に、受信側（例えば、そのＵＤＰパケット・マネージャ）が、そのタイムスタンプを評価して、受信したＵＤＰデータ・パケットに応答して、時間依存測定を実施可能であるか否かを判定する。従って、例えば、メッセージに含まれるタイムスタンプの１ｍｓｅｃ後に、ＵＤＰデータ・パケットの最初の送信を受信する場合、受信側は、メッセージに含まれるタイムスタンプの１０ｍｓｅｃ後に実施することになっている測定を実施することが可能である。ＵＤＰデータ・パケットの最初の送信を受信せず、代わりに、例えば、メッセージに含まれるタイムスタンプの２ｍｓｅｃ後に、ＵＤＰデータ・パケットの第２の送信を受信する場合、受信側では、それでも、この時間依存測定を実施することが可能である。しかし、ＵＤＰデータ・パケットの最初の送信も、第２の送信も受信せず、代わりに、例えば、メッセージに含まれるタイムスタンプの１１ｍｓｅｃ後に、ＵＤＰデータ・パケットの第３の送信を受信する場合、受信側は、メッセージに含まれるタイムスタンプから１０ｍｓｅｃ後に、その測定をトリガすることはできない。しかし、この場合、受信側は、測定の要求に気づかない場合とは違い、エラーをトリガすることが可能である。受信側が、信号を連続測定して、その結果を循環バッファに緩衝記憶するように実施される場合、メッセージに含まれるタイムスタンプの１１ｍｓｅｃ後までメッセージを受信しなかったとしても、受信側は、メッセージのタイムスタンプの１０ｍｓｅｃ後の時間に対応する測定結果を検索できる可能性がある。この場合、所望の時間（例えば、タイムスタンプの１０ｍｓｅｃ後）の測定結果がもはや受信側のバッファになければ、受信側は、エラーを発生することが可能である。
【００４０】
図４を参照すると、実施例の１つに関するオペレーショナル・フロー例が示されている。操作ブロック４１では、通信ネットワークに通信可能に結合された複数デバイスのローカル・クロックの同期がとられる。上述のように、実施態様によっては、ローカル・クロックの同期に、ＩＥＥＥ１５８８またはＮＴＰのような能動的同期技法を用いることが可能なものもある。ブロック４２では、少なくとも１つのＵＤＰデータ・パケットが、通信ネットワークを介して複数のデバイスの１つから伝送される。実施態様によっては、通信ネットワークを介したＵＤＰデータ・パケットの同報通信が行われる場合もある。ＵＤＰデータ・パケットには、送信側デバイスのローカル・クロックを基準にしたタイムスタンプが含まれている。次に、ブロック４３では、定義済みの遅延後、ＵＤＰデータ・パケットが通信ネットワークを介して再送信されるが、やはり、これにもタイムスタンプが含まれている。
【００４１】
図５を参照すると、実施態様の１つに関するもう１つのオペレーショナル・フロー図が示されている。操作ブロック５１では、通信ネットワークに通信可能に結合された複数デバイスのローカル・クロックの同期がとられる。やはり、実施態様によっては、ローカル・クロックの同期に、ＩＥＥＥ１５８８またはＮＴＰのような能動的同期技法を用いることが可能なものもある。操作ブロック５２では、ＵＤＰデータ・パケットが、少なくとも定義済み時間遅延１つ分だけ分離された複数の回数、通信ネットワークを介して、複数のデバイスのうち第１のデバイスから送り出される。実施態様によっては、通信ネットワークを介したＵＤＰデータ・パケットの同報通信も行われる。ＵＤＰデータ・パケットの複数の送信時のそれぞれにおいて、ＵＤＰデータ・パケットには、第１のタイムスタンプが含まれている。例えば、こうしたタイムスタンプは、ＵＤＰデータ・パケットの最初の送信時における、第１のデバイスのローカル・クロックにおける時間に対応することが可能である。操作ブロック５３では、複数のデバイスのうち少なくとも第２のデバイスが、少なくとも１回、ＵＤＰデータ・パケットを受信する。受信側デバイスは、タイムスタンプを評価して、受信したＵＤＰデータ・パケットに応答して時間依存アクションを実施できるか否かを判定する。上述のように、ＵＤＰデータ・パケットの受信が遅すぎて、受信側で時間依存アクションを実施できないと判定すると、受信側では、エラーの発生といった、適切な措置を施すことが可能である。
【００４２】
上記例の解説は、ＵＤＰプロトコルに関して行われたが、もちろん、他の信頼性のないプロトコルへの利用にも容易に拡張して、それらのプロトコル利用の頑強性を高めることが可能である。さらに、本明細書に解説の方法は、「ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＹＮＣＨＲＯＮＩＺＩＮＧ  ＯＰＥＲＡＴＩＯＮＳ  ＯＦ  Ａ  ＰＬＵＲＡＬＩＴＹ  ＯＦ  ＤＥＶＩＣＥＳ  ＶＩＡ  ＭＥＳＳＡＧＥＳ  ＯＶＥＲ  Ａ  ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＮＥＴＷＯＲＫ」と題する米国特許出願（代理人整理番号１００４１３２９−１）に開示のような、計器の動作を同期させるためのメッセージの伝送に用いられる場合に、信頼性のないプロトコルの頑強性を高めるのにとりわけ有効であるが、本明細書に解説の方法は、データの伝送に信頼性のないプロトコルが求められる他のアプリケーション、とりわけ、ほんのわずかなデータ・パケットだけしか伝送されないアプリケーションにも同様に適用することが可能である。
【００４３】
本発明及びその利点について、詳述してきたが、もちろん、付属の請求の範囲で定義される本発明から逸脱することなく、さまざまな変更、置換、及び、改変を施すことが可能である。さらに、本出願の範囲は、本明細書に記載のプロセス、機械、製造、合成物、手段、方法、及び、ステップの特定の実施態様に制限されるものではない。本開示から容易に明らかになるように、本明細書に記載の対応する実施態様とほぼ同じ機能を実施するか、または、ほぼ同じ結果を実現する、現存する、または、今後開発されることになるプロセス、機械、製造、合成物、手段、方法、または、ステップを利用することも可能である。従って、付属の請求の範囲は、その範囲内に、こうしたプロセス、機械、製造、合成物、手段、方法、または、ステップを包含することを意図したものである。
【図面の簡単な説明】
【００４４】
【図１】実施態様の１つによる信頼性のないプロトコルの頑強利用のためのシステム例を示す図である。
【図２】もう１つの実施態様による信頼性のないプロトコルの頑強利用のためのシステム例を示す図である。
【図３】図１または図２による、受信側デバイスが信頼性のないプロトコルによって伝送されるデータを受信するシステム例を示す図である。
【図４】実施態様の１つによる信頼性のないプロトコルの頑強利用のためのオペレーショナル・フローを示す図である。
【図５】もう１つの実施態様による信頼性のないプロトコルの頑強利用のためのオペレーショナル・フローを示す図である。
【符号の説明】
【００４５】
１１、１２  デバイス
１３  通信ネットワーク
１０１Ａ、１０１Ｂ  ローカル・クロック
３０１  アプリケーション
【図１】
2006081193.tif 000003
【図２】
2006081193.tif 000004
【図３】
2006081193.tif 000005
【図４】
2006081193.tif 000006
【図５】
2006081193.tif 000007